The art of software testing 阅读笔记(二)

zerray | 一月 23rd, 2006 - 11:04

第二章 测试的心理学与经济学

心理学

一个不好的程序测试的主要原因是,大多数程序员是以一个错误的定义开始的。他们可能 会说:

“测试是证明没有错误的过程。”
或者
“测试的目的是展示程序实现了正确的功能。”
或者
“测试是确 立程序能够正确执行的信心的过程。”

这些定义是本末倒置的。

当你测试一个程序,你是想为它加入价值,也就是提高质量和可 靠性。提高可靠性意味着找出并移除错误。所以,不要为了证明程序正确而测试,而要为了找出尽可能多的错误。

所以,对于测试一个更好的定义 应该是:

“测试是带着寻找错误的目的执行程序的过程。”

测试是一个破坏的过程,甚至是一个虐待的过程。(其实大多数人都 是倾向于建设而不是破坏的。虽然曾听一个老师说过人的本性是破坏性的,就好像幼儿园中的小孩子,当他把积木搭得很高的时候没有一下子把积木推倒时那么高 兴。看来,选择了测试这行,就要做一个”bad boy”了,呵呵)

一个好的测试用例是很可能发现未发现错误的用例。
一个成功的 测试用例是发现了一个未发现错误的的用例。

这就好像是去看医生,你并不是为了让医生告诉你你很健康,而是要让医生告诉你你哪里出了问题。

经 济学

黑盒测试,即便像判断三角形类型这样的程序也无法穷举所有可能输入,更不用说像编译器,操作系统,数据库这样的程序了。
白盒 测试,或许可以做到语句覆盖,条件覆盖,甚至是路径覆盖,但还是确定程序符合需求,无法测试出缺少的路径,也无法测试出一些与数据相关的错误。
穷 举测试是不可能的,所以需要考虑测试中的经济学,怎样用有限的测试用例找出尽可能多的错误。

测试的十条原则

1 定义期望的输出或结果是测试用例的一个必要组成部分。
2 一个程序员应避免测试自己的程序。
3 一个工作组不应该测试他们自己的程序。
4 彻底检查每个测试的结果。
5 测试用例除了要有合法的输入,还要有非法的输入。
6 检查程序是否没有完成应完成的功能只是工程的一半,另一半是看程序是否做了不应该做的事。
7 避免一次性的测试用例,除非程序真是一次性的。
8 不要在默许没有错误会被发现的假设下做测试。
9 一段程序中可能存在更多错误的可能性与这段程序中已经被发现的错误数成比例。
10 测试是一项非常挑战创造力和智力的工作。

The art of software testing 阅读笔记(一)

zerray | 一月 23rd, 2006 - 11:02

第一章 自测

测试一个判断三角形类型的小程序,程序从对话框读入三个整数,代表三边长度,输出该三角形所属类型,即不等边,等腰,等边三角形。

书中给出的应包括如下几点:

1. 有一个测试用例构成一个合法的不等边三角形。
2. 有一个测试用例构成一个合法的等边三角形。
3. 有一个测试用例构成一个合法的等腰三角形。
4. 至少有三个测试用例是一个合法的等腰三角形三边的全排列情况(如3,3,4;3,4,3;4,3,3)。
5. 有一个一边为0的测试用例。
6. 有一个一边为负值的测试用例。
7. 有一个测试用例三边为正数,其中两边之和等于第三边。
8. 至少有三个测试用例是第7条中的全排列情况。
9. 有一个测试用例三边为正数,其中两边之和小于第三边。
10. 至少有三个测试用例是第9条中的全排列情况。
11. 有一个三边全为0的测试用例。
12. 至少有一个测试用例中有非整数值。
13. 有一个测试用例给出少于或多于三个数。
14. 每一个测试用例中相对于输入都应该有一个期望的输出。

我没有考虑到的有4,8,10,14,只比职业程序员的平均值(7,8)多了2个,不过我还想到了输入不是数字的情况,看来我对做测试还是有一点点悟性的:)