第七章软件测试.doc

第七章 软件测试 编码完成之后，就是对源程序进行测试。软件测试是一项“劳民伤财”的工作，统计表明，开发大规模的软件，有40%以上的精力是耗费在软件测试上（40-20-40规则，Myers认为软件测试占大约50%的项目时间和超过50%总成本）。为了保证软件的正确可靠、为了防患于未然，无论怎样强调软件测试的重要性，都不过分。 关于软件测试，曾有种种似是而非的说法，众多的术语和测试技术，也常使我们眼花缭乱。在这里我试尝给大家勾画出一个清晰的逻辑轮廓。 7.1 基本概念 7.1.1 软件测试的目的（与地位） 说测试不能不提到G.J.Myers的经典著作《软件测试技巧》，他在书中说道：“测试是为了发现错误而执行程序的过程。” E.W.Dijkstra则说：“程序测试能证明错误的存在，但不能证明错误不存在。” 在这里，他们明确指出：测试的目的是发现程序中的错误，是为了证明程序有错，而不是证明程序无错。（其实你也证明不了） 在软件开发过程中，分析、设计、编码等工作都是建设性的，唯独测试带有“破坏性”，因为它抱着“吹毛求疵”的目的，明确宣布要在程序中“找岔子”。他们认为这种吹毛求疵的态度是至关重要的(态度决定一切！)。如果你是为了证明程序无错而去进行测试，错误就可能在你的眼皮底下漏过，反之，只要你抱着证明程序有错的目的去测试，就会尽心尽力去找程序中的错误。 根据Myers的说法，测试又是一个“（在计算机上）执行程序的过程”。分析和设计阶段都要对文档进行技术审查和管理复审，源程序完成后，也要进行代码复审（code review）））） [注] （1）机器测试和人工测试 程序通过编译后，先要经代码复审，然后再进行机器测试。机器测试是用设定的测试数据(test data)执行被测程序的过程，故又称为动态测试（dynamic testing） （3）穷举测试和选择测试 能不能通过动态测试，发现程序中的所有错误呢？ 人们自然地想到：应该让被测程序在一切可能的输入情况下执行一遍，这就是所谓的“穷举测试”。 那么穷举测试可能吗？请看： [试对一个“C++编译器”进行黑盒穷举测试] 一方面要编写出所有能够想象出来的合法的C++程序让它编译，另一方面又要编写出一切不合法的C++程序，看它能否指出程序的错误。显而易见，合法与不合法的C++程序的数量都是无穷的，因此，用黑盒测试方法进行穷举测试是不可能的。 [试对下图所示的程序进行白盒穷举测试] [注]51+52+53+ …… +520≈1014=106亿=102万亿=100万亿这意味着若能每秒完成一次测试，也得用漫长的320万年才能完成这次测试任务。 由此可见，穷举测试是不实现的，这就是我们所说的测试不能保证程序无错的原因。 在实际测试中，我们只能选择一些有代表性的、典型的测试用例，对程序进行有限的测试，通常称这种测试为选择测试。 7.1.3 软件测试的步骤 按照软件工程的观点。软件测试依次由以下四个层次的测试组成： 单元测试：在编码阶段完成；以模块为单位，包括代码复审、动态测试；确定测试用例时，可综合运用白盒和黑盒两类测试技术； 综合测试：以软件的设计信息为依据，采纳一定的“测试策略”进行测试；主要用黑盒测试技术确定测试用例； 确认测试：以软件的需求信息为依据，采纳一定的“测试策略”进行测试；主要用黑盒测试技术确定测试用例； 系统测试：指整个计算机系统（包括软件与硬件）的测试，可与系统的安装和验收结合进行。 [注]1）各级测试均须事先制订测试计划，事后写出测试报告； 2）测试应由独立的测试小组进行，并挑选有经验的优秀程序员来担任； 3）图：软件测试的步骤。 7.2 代码复审 代码复审在程序通过编译之后，动态测试开始之前进行。决不能以为程序通过编译就问题不大，其实编译只能发现极小部分错误，特别对大型软件更是如此。 7.2.1 代码会审 代码会审以小组会的方式进行，会审小组一般由3到4人组成，包括组长一人、程序作者一人。会前要先把源程序清单分发给与会者，还应把复审的要点编成“错误检验表”，供与会者参考。 ***程序错误检验表 数据引用错误 例如使用未赋过值或未初始化的变量 数据说明错误 例如变量类型与初始化的值不符，变量未说明 数据计算错误 例如混合类型运算，用零作除数 数据比较错误 例如在不同类型的变量间作比较 控制流程错误 例如多做或少做了循环，子程序等最后未终止 接 口 错 误 例如实参和形参类型、顺序或数量不符 输入输出错误 例如忘记打开或关闭文件，I/O出错处理不对 ………… ………… 开会时，程序作者逐句朗读和讲解程