200602271215442.html

软件工程的红包书

<P>　　提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。</P>
<P>综合测试的基本方法</P>
<P><BR>　　 时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。</P>
<P>　　某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。</P>
<P>1 自顶向下集成</P>
<P>　　自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把M2、M3和M4与主控模块集成在一起，再将M5和M6 和其他模块集资集成起来。</P>
<P>　　自顶向下综合测试的具体步骤为：<BR>　　 1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；<BR>　　 2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；<BR>　　 3 每集成一个模块立即测试一遍；<BR>　　 4 只有每组测试完成后，才着手替换下一个桩模块；<BR>　　 5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。<BR>&nbsp;</P>
<P>　　 从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。下图中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。</P>
<P>　　自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。</P>
<P>2自底向上集成</P>
<P>　　自底向上测试是从“原子”模块（即<a href="200602282202575.html" tppabs="http://www.itisedu.com/phrase/200602282202575.html" target="_new">软件结构</a>最低层的模块）开始<a href="200604231409245.html" tppabs="http://www.itisedu.com/phrase/200604231409245.html" target="_new">组装测试</a>，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。</P>
<P>　　自底向上综合测试的步骤分为：<BR>　　 1 把低层模块组织成实现某个子功能的模块群（cluster）;<BR>　　 2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；<BR>　　 3 对每个模块群进行测试；<BR>　　 4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。</P>
<P>　　从第一步开始循环执行上述各步骤，直至整个程序构造完毕。</P>
<P>　　下图说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可对MaD3被去掉后，M3与模块群3直接接口，可对Mb进行<a href="200603111743305.html" tppabs="http://www.itisedu.com/phrase/200603111743305.html" target="_new">集成测试</a>，最后Ma、Mb和 Mc全部集成在一起进行测试。</P>
<P>&nbsp;</P>
<P>　　 自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。</P>
<P>　　此外，在综合测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：①对应几条需求；②具有高层控制功能；③复杂、易出错；④有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。</P>
<P>确认测试的基本方法<BR>　　 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。</P>
<P>1. 确认测试标准</P>
<P>　　实现软件确认要通过一系列墨盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。</P>
<P>　　确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。</P>
<P>2. 配置复审</P>
<P>　　确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。</P>
<P>3. α、β测试</P>
<P>　　事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“<a href="200603282249515.html" tppabs="http://www.itisedu.com/phrase/200603282249515.html" target="_new">验收测试</a>”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。</P>
<P>　　α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。</P>
<P>系统测试的基本方法</P>
<P>　　 <a href="200602281627065.html" tppabs="http://www.itisedu.com/phrase/200602281627065.html" target="_new">计算机软件</a>是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出<a href="200602281725525.html" tppabs="http://www.itisedu.com/phrase/200602281725525.html" target="_new">软件工程</a>的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作：<BR>　　 （1） 为测试软件系统的输入信息设计出错处理通路；<BR>　　 （2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；<BR>　　 （3） 参与系统测试的规划和设计，保证软件测试的合理性。</P>
<P>　　系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。下面简单讨论几类系统测试。</P>
<P>１、恢复测试</P>
<P>　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。</P>
<P>２、安全测试</P>
<P>　　安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。</P>
<P>３、强度测试</P>
<P>　　强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存<a href="200602281634075.html" tppabs="http://www.itisedu.com/phrase/200602281634075.html" target="_new">操作系统</a>崩溃或磁盘数据剧烈抖动的测试用例，等等。</P>
<P>４、 <a href="200603291559575.html" tppabs="http://www.itisedu.com/phrase/200603291559575.html" target="_new">性能测试</a></P>
<P>　　对于那些实时和<a href="200603112246585.html" tppabs="http://www.itisedu.com/phrase/200603112246585.html" target="_new">嵌入式系统</a>，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。</P>
<P><FONT face=Verdana><STRONG>五、软件测试的类型</STRONG></FONT></P>
<P><FONT face=Verdana>常见的软件测试类型有：</FONT></P>
<P><FONT face=Verdana>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BVT (Build Verification Test)</FONT></P>
<P><FONT face=Verdana>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BVT是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。如无大的问题，就可以进行相应的功能测试。BVT优点是时间短，验证了软件的基本功能。缺点是该种测试的覆盖率很低。因为运行时间短，不可能把所有的情况都测试到。</FONT></P>
<P><FONT face=Verdana>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Scenario Tests（基于用户实际应用场景的测试）</FONT></P>
<P><FONT face=Verdana>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 在做BVT、功能测试的时候，可能测试主要集中在某个模块，或比较分离的功能上。当用户来使用这个应用程序的时候，各个模块是作为一个整体来使用的，那么在做测试的时候，就需要模仿用户这样一个真实的使用环境，即用户会有哪些用法，会用这个应用程序做哪些事情，操作会是一个怎样的流程。加了这些测试用例后，再与BVT、功能测试配合，就能使软件整体都能符合用户使用的要求。Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况。</FONT></P>
<P><FONT face=Verdana>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Smoke Test</FONT></P>
<P><FONT face=Verdana>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。</FONT></P>
<P><FONT face=Verdana>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 此外，Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（<a href="200604051546475.html" tppabs="http://www.itisedu.com/phrase/200604051546475.html" target="_new">压力测试</a>）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等。</FONT></P>
<P><STRONG>六、软件测试支持工具</STRONG></P>