11软件测试【荐】.doc

第11章 软件测试 经过需求分析、设计和编码等阶段的开发后，得到了源程序，开始进入到软件测试阶段。由于在测试之前的各阶段中都可能在软件产品中遗留下许多错误和缺陷，如果不及时找出这些错误和缺陷，并将其改正，这个软件产品就不能正常使用，甚至会导致巨大的损失。目前，程序的正确性证明尚未得到根本的解决，因此，软件测试仍是发现软件中错误和缺陷的主要手段。 测试是一项非常艰苦的工作，其工作量约占软件开发总工作量的40%以上，特别对一些关系到人的生命安全的软件（如飞行控制软件、核反应堆软件等），其测试工作量可能相当于其他开发阶段工作量总和的3(5倍。 11．1 软件测试基础 测试软件前，需要设计若干个测试用例（Test case），一个测试用例由测试输入数据和预期结果组成，测试时通过输入数据，运行被测程序，如果运行的实际输出与预期结果不一致，则表明发现了程序中的错误。在介绍软件测试技术之前，我们首先要排除对测试的错误观点，明确测试的目的。 11．1．1 软件测试的目的 在人们的头脑中存在着不少对软件测试的错误观点，如有人认为“软件测试是为了证明程序是正确的，即测试能发现程序中所有的错误”。事实上这是不可能的。要通过测试发现程序中的所有错误，就要穷举所有可能的输入数据。对于一个输入三个16位字长的整型数据的程序，输入数据的所有组合情况有248( 3*1014，如果测试一个数据需1ms，则即使一年365天一天24小时不停地测试，也需要约1万年时间。所以我们只能通过测试发现软件中的错误，而不能证明软件中没有错误。还有人认为“程序测试是证明程序正确地执行了预期的功能”。实际上，一个程序不仅要完成它所需完成的功能，而且不应完成它不该做的事。如不能把边长为0、0、0的三条边判断为等边三角形。 Glen Myers在他关于软件测试的著作中给出了软件测试的目的： 1．测试是一个为了发现错误而执行程序的过程； 2．一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测试用例； 3．一个成功的测试是指揭示了迄今为至尚未发现的错误的测试。 根据这个测试目的，我们应该排除对测试的错误观点，设计合适的测试用例，用尽可能少的测试用例，来发现尽可能多的软件错误。 11．1．2 软件测试的基本原则 Davis提出了一组指导软件测试的基本原则： 1．所有的测试都应可追溯到客户需求：测试的目的是发现错误，而最严重的错误是那些导致程序无法满足需求的错误。 2．应该在测试工作真正开始前的较长时间就进行测试计划：从现代软件工程的眼光来看，测试计划可以在需求模型完成时就开始，测试用例可以在设计模型确定后立即开始。 3．Pareto原则可应用于软件测试：即测试中发现的80%的错误可能来自于20%的程序代码。这表明，如果测试模块A时发现的错误比测试模块B时发现的错误多，那么模块A中潜藏的错误可能仍比模块B中潜藏的错误多，此时不能放松对模块A的测试。 4．测试应从“小规模”开始，逐步转向“大规模”：先测试单个模块，再测试集成的模块簇，最后测试整个系统。 5．穷举测试是不可能的：例如，测试一个包含5个分支的循环程序，其循环次数为20，那么，该程序就有520条不同的执行路径，要穷举测试所有的路径是不可能的。 6．为了达到最有效的测试，应由独立的第三方来承担测试：“最有效”是指发现错误的可能性最高的测试。由于开发软件是一个创建软件的过程，开发者有成就感，而测试软件是一个发现软件错误的过程，测试者要千方百计从软件中找出错误，即证明软件中有错误，因此，由开发者或开发方组织来测试自己的软件，往往在心理上存在障碍，从而使测试不是最有效的。 还有一些其他的测试原则： 1. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。大量的实践表明，用户在使用软件时，常常因为不熟练或不小心，而输入一些非法的或不合理的数据。因此应测试非法的或不合理的数据是否会导致软件的失效。 2. 严格执行测试计划，排除测试的随意性。不按测试计划进行的测试，常常不能保证测试的充分性。 3. 应当对每一个测试结果做全面检查。不严格检查测试结果，会遗漏经测试发现的错误，从而白白浪费测试所付出的代价。 4. 妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。因为在改正错误后或维护后要进行回归测试（regression testing），即全部或部分地重复使用已做过的测试用例，以确保该修改未影响软件的其他功能。 5. 检查程序是否做了应做的事仅是成功的一半，另一半是检查程序是否做了不该做的事。 6. 在规划测试时不要设想程序中不会查出错误。如果在测试前就认为程序中没有错误，测试时就不会全力以赴地找错误，从而使测试不充分。 11．1．3 白盒测试和黑盒测试 测试用例的设计是软件测试的关键所在，我们必须设计出最有可能发