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

开发者测试p499
开发者测试在软件质量中的角色P500

开发者测试的推荐方法P503

测试技巧锦囊p505

典型错误

测试支持工具

改善测试过程

保留测试数据

开发者测试（p499）

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

单元测试

将一个程序员或者一个开发团队所编写的，一个完整的类、子程序或者小程序，从完整的系统中隔离出来进行测试

组件测试

将一个类、包、小程序或者其他程序元素，从一个更加完整的系统中隔离出来进行测试，区别在于这些代码涉及到多个程序员或者多个团队

集成测试

是对两个或更多的类、包、组件或者子系统进行的联合测试。

回归测试

是指重复执行以前的测试用例，以便在原先通过了相同测试集合的软件中查找缺陷

系统测试

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

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

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

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

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

构建中测试

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

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

对每一项相关的需求进行测试，以确保需求都已经被实现。在需求阶段就计划好这一部分的测试用例，或者至少尽早开始。注意需求里面常见的疏漏：安全级别、数据存储、安装过程以及系统可靠性等。

对每一个相关的设计关注点进行测试，以确保设计已经被实现。

用基础测试来扩充针对需求和设计的详细测试。比如：增加数据流测试。

使用一个检查表，其中记录着你在本项目迄今为止所犯的，以及在过去的项目中所犯的错误类型。

测试先行还是后行
1.这个问题只是调整了一下测试用例编写活动的工作顺序而已

2.如果先编写，那么你将可以更早发现缺陷以及修正它们

3.先编写可以迫使你自己在开始写代码前至少思考一下需求和设计，往往可以催生高质量的代码

4.能够更早的暴露需求上的问题

5.如果你保存了最初编写的测试用例，先测后测都没有绝对的顺序

开发者测试的局限性
1.开发者测试倾向于“干净测试”

2.开发者测试对覆盖率有过于乐观的估计

3.开发者测试往往会忽略一些更复杂的测试覆盖率类型

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

3. 测试技巧锦囊(p505)

不完整的测试

进行完全测试实际上是不可能的，因此敲门就在于选择那些最有可能找到错误的测试用例。

结构化的基础测试

你需要测试程序中的每一条语句至少一次。

所需基础测试用例的最少数量可以用下面的简单方法计算：

对通过子程序的直路，开始的时候记1

遇到下面的每个关键字或者其等价物时，加1：if、while、repeat、for、and、以及or

遇到每一个case语句就加1，如果case语句没有缺省情况，则再加1

数据流测试

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

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

已定义

已使用

已销毁

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

已进入

已退出

几种有问题的组合

已定义-已定义

已定义-已退出

已定义-已销毁

已进入-已销毁

已进入-已使用

已销毁-已销毁

已销毁-已使用

已使用-已定义

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

等价类划分

如果两个用例能揭示的错误完全相同，那么只要一个就够了。

猜测错误

见以下几个小结

边界值分析

off-by-one

即当你想用num时写成num-1，想用”>”的时候用了”>=”

小于max的某个范围数值测试

有三种情况：小于max、等于max、大于max

复合边界值

比如两个变量相乘得到一个大数、负数或者0

几类坏数据

数据太少(没有数据)

太多的数据

错误的数据情况(无效数据)

长度错误的数据

未初始化的数据

几类好数据

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

正常的情况—大路正中间，所期望的值

最小的正常局面

最大的正常局面

与旧数据的兼容性

采用容易手工检查的测试用例

使用120000000000和1239078382346对计算机而言并没多少不同，然而前者在手工计算上会轻松得多

4. 典型错误

哪些类包含最多的错误

80%的错误存在于项目20%的类或者子程序当中

50%的错误被发现存在于项目5%的类当中

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

错误的分类

大多数错误的影响范围是相当有限的

85%的错误可以在修改不超过一个子程序的范围内得到修正

许多错误发生在构建的范畴之外

调查发现三种最为常见错误的源头：

缺乏应用领域知识

频繁变动且相互矛盾的需求

沟通和协调的失败

大多数的构建期错误是编程人员的失误造成的

许多年前的研究发现

程序员占大约95%

系统软件占大约2%

其他软件2%

硬件1%

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

让人惊奇的是，拼写错误是一个常见的问题根源

研究程序员所犯错误原因时，错误理解设计这条会经常出现

大多数错误都很容易修正

总结所在组织中对付错误的经验

不完善的构建过程引发错误所占的比例

有一点是确定的，构建总会出现大量的错误。

你期望能发现多少错误

开发高质量的软件，比开发低质量软件然后修正的成本要低廉。

测试本身的错误

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

检查你的工作

开发软件的时候就要计划好测试用例

保留你的测试用例

将单元测试纳入测试框架

5. 测试支持工具

为测试各个类构造脚手架

Diff工具

测试数据生成器

覆盖率监视器

数据记录器/日志记录器

符号调试器

系统干扰器

错误数据库

6. 改善测试过程

有计划的测试

重新测试（回归测试）

7. 保留测试数据

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