软件测试心理学和经济学（一）
1、软件测试的心理学
在某些情况下，测试人员的态度可能比实际的测试过程本身还要重要。
（1）对于“测试”的误解
软件测试就是证明软件不存在错误的过程。
软件测试的目的在于证明软件能够正确完成其预定的功能。
软件测试就是建立一个“软件做了其应该做的”信心的过程。
（2）正确的理解
每当测试一个程序时，应当想到要为程序增加一些价值。如：提高程序的可靠性或质量。
测试是为发现错误而执行程序的过程。
软件测试是一个破坏性的过程，甚至是一个“施虐”的过程。
软件的错误包含两种：（1）程序没有实现预期功能。（2）程序做了其不应该做的。
2、软件测试的经济学
一般来说，要发现程序中的所有错误也是不切实际的，常常也是不可能的。
2.1 黑盒测试
黑盒测试是一种重要的测试策略，又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试方法时，将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。在这种方法中，测试数据完全来源于软件规范（不需要去了解程序的内部结构）。
如果想要用这种方法来发现程序的所有错误，判定的标准就是“穷举输入测试”，将所有可能的输入条件都作为测试用例。
穷举输入测试是无法实现的。两个含义：一、我们无法测试一个程序以确保它是无错的。二、软件测试中需要考虑的一个基本问题是软件测试的经济学。也就是说由于穷举测试是不可能的，测试投入的目标在于通过有限的测试用例，最大限度地提高发现的问题的数量，以取得最好的测试效果。
2.2 白盒测试
白盒测试，又称逻辑驱动测试，允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构进行检查，从中获取测试数据。（常常忽略了程序规范）。
使用测试用例执行了程序中所有可能的控制流路径，那么程序有可能得到了完全测试。此方法称为穷举路径测试。
穷举路径测试存在两个问题：一、程序中不同逻辑路径的数量可能达到天文数字，实际执行是不可能且不实际的。
二、虽然我们可以测试到程序中的所有路径，但是程序可能仍然存在着错误。
原因：
1.即使是穷举路径测试也决不能保证程序符合其设计规范。
如：要编写一个升序排序程序，但错误的编写成一个降序排序的程序。这样即使进行穷举路径测试也没多大价值，程序本身就是一个错误程序，不符合设计规范。
2.程序可能会因为缺少某些路径而存在问题。
穷举路径测试不能发现缺少了哪些必需路径。
3.穷举路径测试可能不会暴露数据敏感错误。
如：程序要比较两个数值是否收敛，也就是检查两个数值之间的差是否小于某个既定的值，而仅仅执行程序中的每条路径并不一定能找出错误。
if(a - b < c)
System.out.println("a - b < c");
程序的原意是将a - b的绝对值和c比较，要找出这样的错误，取决于a，b的取值，而仅仅执行程序中的每一条路径并不一定能找出错误来。
软件测试的原则
原则1：测试用例中一个必需部分是对预期输出或结果的定义。
事先精确定义程序的预期输出，鼓励人们对所有输出进行仔细检查。因此，一个测试用例必须包括两个部分：
1.对程序的输入数据描述。
2.对程序在上述输入数据下的正确输出结果的精确描述。
原则2：程序员应当避免测试自己编写的程序。
当程序员“建设性”地设计和编写完程序之后，很难让他突然改变视角以一种“破坏性”的眼光来审查程序。
原因有两个：
1.大多数程序员都不能有效地测试自己编写的程序，因为他们无法改变思维方式来尽力暴露自己程序中的错误。另外，程序员可能会下意识地避免找出错误来，担心受到同事、上司、客户或正在开发的程序或系统的主管的惩罚。
2.另一个原因，由于程序员错误地理解了疑难定义或规范，导致程序中存在错误。如果情况是这样，程序员可能会带着同样的误解来测试自己的程序。
以上论据不适合于“调试”，“调试”由程序的编写人员来完成会有效的多。
原则3：编写软件的组织不应当测试自己编写的软件。
由于一个软件项目或编程组织是一个有机的机构，具有与个体程序员相似的心理问题。
原则4：应当彻底检查每个测试的执行结果。
原则5：测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。
在软件产品中突然暴露出来的许多问题是当程序以某些新的或未预料到的方式运行时发现的。因此，针对未预料到的和无效输入情况的测试用例，似乎比针对有效输入情况的那些用例更能发现问题。
原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
这条原则是上一条原则的必然结果，必须检查程序是否有我们不希望的负作用。
原则7：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
由于测试用例用后即弃，一旦软件需要重新测试（如：当改正了某个错误或作了某种改进后），又必须重新设计这些测试用例。情况往往是这样的，由于重新设计测试用例需要投入大量的工作，人们总是避免这样做。因此，对该程序的重新测试极少会同上一次一样严格。这就意味着，如果对程序的更改导致了程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的。保留测试用例，当程序其他部件发生更动后重新执行，这就是我们所谓的“回归测试”。
原则8：计划测试工作时不应默许假定不会发现错误。
测试，是为了发现错误而执行程序的过程，不是证明程序正确运行的过程。
原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
错误总是倾向于聚集存在，而在一个具体的程序中，某些部分要比其他部分更容易存在错误，尽管没有人能够对这种现象给出很好的解释。
原则10：软件测试是一项极富创造性、极具智力挑战性的工作。
几个重要的测试原则（总结）
（1）软件测试是为了发现错误而执行的过程。
（2）尽量避免编码人员测试自己的程序。
（3）好的测试用例能够对未发现的错误高度敏感。
（4）成功的测试用例能够发现未知的错误。
（5）成功的测试用例需要仔细定义输入输出的期望值。
（6）成功的测试需要仔细研究分析测试结果。
|