代码大全第二版读书笔记 第五部分-代码改善 二十二、开发者测试

开发者测试（p499）

软件测试一般分为这么几种

• 单元测试
  将一个程序员或者一个开发团队所编写的，一个完整的类、子程序或者小程序，从完整的系统中隔离出来进行测试
• 组件测试
  将一个类、包、小程序或者其他程序元素，从一个更加完整的系统中隔离出来进行测试，区别在于这些代码涉及到多个程序员或者多个团队
• 集成测试
  是对两个或更多的类、包、组件或者子系统进行的联合测试。
• 回归测试
  是指重复执行以前的测试用例，以便在原先通过了相同测试集合的软件中查找缺陷

• 系统测试
  是指在最终的配置下运行整个软件。以便测试安全、性能、资源消耗、时序方面的问题，以及其他无法在低级集成上测试的问题

  测试通常分为两大类：黑盒测试和白盒测试，或者玻璃盒测试。

1. 开发者测试在软件质量中的角色(P500)

对于任何软件质量规划来说，测试都是一个重要的组成部分，并且在许多情况下它是唯一的组成部分。

你必须期望在你的代码里有错误。尽管这种期望似乎有悖于常理，但是你应该期望找到这个错误的人是你，而不是别人。

• 构建中测试

假如每次只将一个子程序加入到此前经过测试的子程序集合中，那么一旦发现了新的错误，你就会知道这是新子程序或者其接口所引发的问题，调试工作就轻松多了。

2. 开发者测试的推荐方法(P503)

• 对每一项相关的需求进行测试，以确保需求都已经被实现。在需求阶段就计划好这一部分的测试用例，或者至少尽早开始。注意需求里面常见的疏漏：安全级别、数据存储、安装过程以及系统可靠性等。
• 对每一个相关的设计关注点进行测试，以确保设计已经被实现。
• 用基础测试来扩充针对需求和设计的详细测试。比如：增加数据流测试。
• 使用一个检查表，其中记录着你在本项目迄今为止所犯的，以及在过去的项目中所犯的错误类型。

测试先行还是后行

1.这个问题只是调整了一下测试用例编写活动的工作顺序而已
2.如果先编写，那么你将可以更早发现缺陷以及修正它们
3.先编写可以迫使你自己在开始写代码前至少思考一下需求和设计，往往可以催生高质量的代码
4.能够更早的暴露需求上的问题
5.如果你保存了最初编写的测试用例，先测后测都没有绝对的顺序

开发者测试的局限性

1.开发者测试倾向于“干净测试”
2.开发者测试对覆盖率有过于乐观的估计
3.开发者测试往往会忽略一些更复杂的测试覆盖率类型

如果要保证质量，仅仅进行开发者测试是不够的。

3. 测试技巧锦囊(p505)

1. 不完整的测试
   进行完全测试实际上是不可能的，因此敲门就在于选择那些最有可能找到错误的测试用例。
2. 结构化的基础测试
   你需要测试程序中的每一条语句至少一次。
   所需基础测试用例的最少数量可以用下面的简单方法计算：
   
   1. 对通过子程序的直路，开始的时候记1
   2. 遇到下面的每个关键字或者其等价物时，加1：if、while、repeat、for、and、以及or
   3. 遇到每一个case语句就加1，如果case语句没有缺省情况，则再加1

3. 数据流测试

   Beizer声称全部代码(错误)中至少有一半是数据声明和初始化。

   数据的状态可以是下列三种状态中的一种：

   • 已定义
   • 已使用
   • 已销毁

   为方便起见，还应该有一些术语来描述对变量进行某种操作之前之后，控制流进入或退出某个子程序的状态。

   • 已进入
   • 已退出

   几种有问题的组合

   • 已定义-已定义
   • 已定义-已退出
   • 已定义-已销毁
   • 已进入-已销毁
   • 已进入-已使用
   • 已销毁-已销毁
   • 已销毁-已使用
   • 已使用-已定义

   推荐检查所有已定义-已使用的组合，效率更高。

4. 等价类划分
   如果两个用例能揭示的错误完全相同，那么只要一个就够了。

5. 猜测错误
   见以下几个小结
6. 边界值分析
   
   • off-by-one
     即当你想用num时写成num-1，想用”>”的时候用了”>=”
   • 小于max的某个范围数值测试
     有三种情况：小于max、等于max、大于max
   • 复合边界值
     比如两个变量相乘得到一个大数、负数或者0
7. 几类坏数据
   
   • 数据太少(没有数据)
   • 太多的数据
   • 错误的数据情况(无效数据)
   • 长度错误的数据
   • 未初始化的数据

8. 几类好数据

   正常的情况也可能暗含错误。

   • 正常的情况—大路正中间，所期望的值
   • 最小的正常局面
   • 最大的正常局面
   • 与旧数据的兼容性
9. 采用容易手工检查的测试用例
   使用120000000000和1239078382346对计算机而言并没多少不同，然而前者在手工计算上会轻松得多

4. 典型错误

1. 哪些类包含最多的错误
   

   • 80%的错误存在于项目20%的类或者子程序当中
   • 50%的错误被发现存在于项目5%的类当中
     

   维护工作应该围绕如何确定出问题的子程序，如何把这些部分推倒重来，重新设计并编写代码。

2. 错误的分类

   • 大多数错误的影响范围是相当有限的
     85%的错误可以在修改不超过一个子程序的范围内得到修正
   • 许多错误发生在构建的范畴之外
     调查发现三种最为常见错误的源头：
     
     • 缺乏应用领域知识
     • 频繁变动且相互矛盾的需求
     • 沟通和协调的失败

   • 大多数的构建期错误是编程人员的失误造成的
     许多年前的研究发现

     • 程序员占大约95%
     • 系统软件占大约2%
     • 其他软件2%
     • 硬件1%

     现代程序员所占的比例更能更多

   • 让人惊奇的是，拼写错误是一个常见的问题根源
   • 研究程序员所犯错误原因时，错误理解设计这条会经常出现
   • 大多数错误都很容易修正
   • 总结所在组织中对付错误的经验
3. 不完善的构建过程引发错误所占的比例
   有一点是确定的，构建总会出现大量的错误。
4. 你期望能发现多少错误
   开发高质量的软件，比开发低质量软件然后修正的成本要低廉。

5. 测试本身的错误

   “花了无数小时跟踪调试，最终却发现错误存在于测试数据而非代码中！”

   • 检查你的工作
   • 开发软件的时候就要计划好测试用例
   • 保留你的测试用例
   • 将单元测试纳入测试框架

5. 测试支持工具

1. 为测试各个类构造脚手架
2. Diff工具
3. 测试数据生成器
4. 覆盖率监视器
5. 数据记录器/日志记录器
6. 符号调试器
7. 系统干扰器
8. 错误数据库

6. 改善测试过程

1. 有计划的测试
2. 重新测试（回归测试）

7. 保留测试数据

除了使测试过程有重复之外，你还需要对整个项目进行量化评估，以确定所做的修改是使程序质量有所提高还是降低。