第1章 一次自评价测试
所谓软件测试,就是一个过程或一系列过程,用来确认计算机代码全成了其应该完成的功能,不执行其不该有的操作。软件应当是可预测且稳定的,不会给用户带来意外惊奇。
我们要求设计一组测试用例(特定的数据集合),适当地测试一个相当简单的程序。为此要为该程序建立一组测试数据,程序须对数据进行正确处理以证明自身的成功。下面是对程序的描述:
这个程序从一个输入对话框中读取三个整数值。这三个整数值代表了三角形三边的长度。程序显示提示信息,指出该三角形究竟是不规则三角形、等腰三角形还是等边三角形。
1.是否有这样的测试用例,代表了一个有效地不规则三角形?(注意,如1,2,3和2,5,10这样的测试用例并不能确保“是”的答案,因为具备这样边长的三角形不存在。)
2.是否有这样的测试用例,代表一个有效地等边三角形?
3.是否有这样的测试用例,代表一个有效地等腰三角形?(注意如2,2,4的测试用例无效,因为这不是一个有效地三角形。)
4.是否至少有三个这样的测试用例,代表有效地等腰三角形,从而可以测试到两等边的所有三种可能情况(如3,3,4;3,4,3;4,3,3)?
5.是否有这样的测试用例,某边的长度等于0?
6.是否有这样的测试用例,某边的长度为负数?
7.是否有这样的测试用例,三个整数皆大于0,其中两个整数之和等于第三个?(也就是说,如果程序判断1,2,3表示一个不规则三角形,它可能就包含一个缺陷。)
8.是否至少有三个第7类的测试用例,例举了一边等于另外两边之和的全部可能情况(如1,2,3;1,3,2;3,1,2)?
9.是否有这样的测试用例,三个整数皆大于0,其中两个整数之和小于第三个整数(如1,2,4;12,15,30)?
10.是否至少有三个第9类的测试用例,例举了一边大于另外两边之和的全部可能情况(如1,2,4;1,4,2;4,1,2)?
11.是否有这样的测试用例,三边长度皆为0?
12.是否至少有一个这样的测试用例,输入的边长为非整数值(如2.5,3.5,5.5)?
13.是否至少有一个这样的测试用例,输入的边长个数不对(如仅输入了两个而不是三个整数)?
14.对于每一个测试用例,除了定义输入值之外,是否定义了程序针对该输入值的预期输出值?
第2章软件测试的心理学和经济学
测试是为发现错误而执行程度的过程。
所谓“不成功的”测试,仅指未能适当地对程序进行检查,在大多数情况下,未能找出错误的测试被认为是“不成功的”,这是因为认为软件中不包含错误的观点基本上是不切实际的。
黑盒测试又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试方法时,将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关,而是将重点集中放在发现程序不按其规范正确运行的环境条件。在这种方法中,测试数据完全来源于软件规范(换句话说,不需要去了解程序的内部结构)。如果想用这种方法来发现程序的所有错误,判定的标准就是“穷举输入测试”,将所有可能的输入条件都作为测试用例。
穷举输入测试是无法实现的。这有两方面的含义,一是我们无法测试一个程序以确保它是无错的,二是软件测试中需要考虑的一个基本问题是软件测试的经济学。也就是说,由于穷举测试是不可能的,测试投入的目标在于通过有限的测试用例,最大限度地提高发现的问题的数量,以取得最好的测试效果。
白盒测试或称逻辑驱动的测试,允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构进行检查,从中获取测试数据(遗憾的是,常常忽略了程序的规范)。
所谓穷举路径测试,即如果使用测试用例执行了程序中所有可能的控制流路径,那么程序有可能得到了完全测试。然而,这个论断存在两个问题。首先,程序中不同逻辑路径的数量可能达到天文数字。其次,虽然我们可以测试到程序中的所有路径,但是程序可能仍然存在着错误。这有三个原因:第一,即使是穷举路径测试也决不能保证程序符合其设计规范。第二,程序可能会因为缺少某些路径而存在问题。第三,穷举路径测试可能不会暴露数据敏感错误。
穷举输入测试要强于穷举路径测试。
软件测试的原则
1.测试用例中一个必需部分是对于其输出或结果进行定义
2.程序员应当避免测试自己编写的程序
3.编写软件的组织不应当测试自己编写的软件
4.应当彻底检查每个测试的执行结果
5.测试用例的编写不仅应当根据有效和预料到的输入情况,而且也应当根据无效和未预料到的输入情况
6.检查程序是否“未做其应该做的”仅是测试的一半,测试的另一半是检查程序是否“做了其不应该做的”
7.应避免测试用例用后即弃,除非软件本身就是一个一次性的软件
8.计划测试工作时不应默许假定不会发现错误
9.程序某部分存在更多错误的可能性,与该部分已发现错误的数量成正比
10.软件测试是一项极富创造性、极具智力挑战性的工作