软件测试的艺术－读书笔记

 

收获...

1. 测试思想，从否定的方面考虑测试达到目标

2.测试设计， 任何发现错误的测试都是成功的测试

1   软件测试评价

• 三角测试案例

2   软件测试的心理学和经济学

2.1 心里学和经济学

• 破坏性思维 ＋ 不可发现全部错误

2.2 软件测试原则

• 定义输出和期望
• 不可测试自己编写的软件
• 检查每次输出的结果
• 应该包含有效和无效的输入情况
• 验证做了正确的事以及没有做不该做的事
• *千万不要按照没有问题的方式计划测试
• 发现问题多的模块隐藏更多的问题
• 测试具有创造性和智慧的

 

3   代码检查、走查、评审

3.1 代码检查

按照检查表组织4人左右程序员，有编写人员进行代码逻辑演示，其他人员提出问题。

3.2 代码走查

研读代码，准备测试用例并组织6人左右进行代码走读，包括新程序员，资深程序员、维护程序员等多维度的程序员参与，通过推演和提问方式发现代码问题，类似简单的头脑风暴。

 

3.3 同行评审

• 多用于对代码评分
• 通常用于代码评分。

3.4 其他概念

此章节联想到最新的结对编程模式，通常2人为伴，编码，检查，单元测试均通过另一人完成，提高质量，降低人员变动风险。

 

4   测试用例设计

4.1 设计方法

通过黑盒方法设计测试用例，根据情况需要使用白盒测试的方法来补充测试用例。

4.2 白盒方法

路径覆盖 > 判定/分支覆盖 ^ 条件覆盖 > 判定+条件覆盖 > 多重条件覆盖

 

If a + b > 0 OR b <>0 then

 A = 1

Else

 B = 2

End if

 

路径覆盖 a=1,b=1

判定覆盖 a=1,b=1

a=0,b=0

条件覆盖 a=1,b=1

              a=-1,b=-1

              a=1,b=0

              a=1,b=2

4.3 黑盒方法

等价类划分

有效无效等价类

边界值分析

输入输出边界

因果图

根据条件组合生成测试用例的方法，通过逻辑图描述因果的方法，然后转化判定表，最后转化测试案例。

因果图用来暴漏规格说明书不完整或者模糊的逻辑的一种方法。

 

因果关系：

四种因果逻辑关系＝，Not, OR, And

原因约束：

E约束(a=1 or b=1 or [a<>1 and b<>1])，

I约束([a,b,c]至少有一个为1保证输出1)，

O约束(a,b必须有一个为1)

R约束（a= 1 then b =1, a = b）

结果约束：

M约束(a=0 > b=0)

 

5   模块测试

5.1 测试用例

输入：模块规格和源代码

方法：白盒方法 ＋ 黑盒方法 -目标->  全面覆盖

5.2 增量测试

BigBang 和 增量测试

 

自底向上 和 自顶向下 方法，建议结合使用。

 

6   高级别测试

 

 

6.1 功能测试

 

6.2 系统测试

 

 

 

6.3 测试结束的准则

某类测试用例设计的用例 ＋ 发现缺陷的总体数量 ＋ 发现缺陷趋势减缓 ＋ 遗留缺陷降低到可接受程度

 

测试覆盖率 － 需求覆盖率、执行覆盖率

7   调试

定位错误 和 修改错误；

 

暴力法、归纳法、演绎法、回溯法、测试法。。。

 

8   XP极限编程

软件开发方法：瀑布式，螺旋式，迭代式，敏捷软件开发,XP。

 

XP适用与小规模的VB,Java,C#等高级面向对象语言设计的应用系统，需求不确定或变化较快。

8.1  12个核心实践

1.    计划与需求

2.    递增发布

3.    系统隐喻

4.    简单设计

5.    连续测试

6.    重构

7.    结对编程

8.    代码集体所有权

9.    持续集成

10. 每周40小时

11. 客户在现场

12. 代码标准化

 

连续测试是XP成功的关键，单元测试占主要部分，持续的测试改进软件的质量并适用与重构，建立对软件信心

8.2  12个核心实践归纳的4个概念

1.    聆听客户同其他程序员的谈话

2.    客户参与规格定义和测试用例开发

3.    结对编程

4.    测试代码库

――个人总结――

客户参与和简单设计

增量发布和持续集成

连续测试代码库

 

8.3 单元极限测试

原则：开始编码前完成测试用例 ＋ 产品发布前必须通过单元测试

 

编码前设计单元测试用例会迫使我们了解规格和说明

8.4 验收极限测试