论进的V测试模型综述

1、本文格式为Word版，下载可任意编辑 论进的V测试模型综述 简介： 马俊，男， 24岁，西南大学硕士研究生，主要研究方向：计算机软件与理论；丁晓明，男，40岁，西南大学计算机科学与信息学院副教授，硕士生导师。 随着计算机技术的飞速发展，软件行业的竞争日益强烈，在开发软件的过程中，人们使用了大量保证软件质量的方法来分析、设计和实现软件，以保证自己生产的软件在竞争中的不败。但开发人员难免会在工作中犯错误，特别是对于规模大，繁杂性高的软件更是如此。这样，在软件产品中就会隐蔽大量错误和缺陷。这些错误和缺陷假如遗留到软件投入运行之时，终将会暴露出来。1996年，由于阿里亚纳（Ariane）5号火箭上的软

2、件系统失败，损失了多个卫星，造成的间接经济损失达到数十亿美元1。象这种要求极高的系统的验证工作比其他类型的系统更为重要，而且成本也高得多。但若不进行足够的验证而出现Ariane 5号火箭这种状况，则造成的损失比验证的成本要高得多。大量类型的软件所使用的领域还涉及到人类的生命安全。譬如医用领域的胰岛素注射系统，若因软件的缺陷而造成系统故障，向病人注射过量的胰岛素，会导致脑功能障碍甚至死亡。以上提到这些风险及大的软件系统，在开发过程中必需经过严格的测试，以验证软件系统的可靠性。就算一般的系统，虽然不会对人的生命造成危害，但是在经济方面的损失是不可估量的。譬如银行的管理系统，若出现系统崩溃的状况，经

3、济损失巨大。所以不管什么系统，都必需在经济允许的状况下，进行足够的测试，已保证软件的质量。 软件测试有以下几项原则： （）在软件开发生命周期中尽早地和不断地进行测试2。 质量保证协会的调查说明，应用系统每1000个源语句中存在大约60个缺陷，这些缺陷中有2/3是出现在系统的需求和设计阶段的。假如拖到后面的阶段解决这些缺陷，将增加大量费用。 （）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。 （）程序员应避免测试自己的程序。假如程序员测试自己的程序，他会按自己开发时的思维方式来对待自己的程序，总认为自己的程序是正确的，不利于找到缺陷。 （）要合理保存测试计划、测试用例、出错统计和

4、最终分析报告，这些文档会为维护人员维护阶段的工作提供便利。维护阶段是软件交付后的阶段，有可能维护人员是用户方的人而不是开发人员，保存这些文档就尤为重要。 其左边每个开发活动都与右边的测试活动相对应,它描绘了软件开发过程中,需求、总体设计、详细设计和编码逐步实现，针对这些开发阶段的测试，其开展的次序正好相反。也就是说，代码最终被开发出来，而相应的单元测试首先被执行；需求最早开发，但相应的验收测试是最终才进行的。这个传统的模型是早期开发出来的，和现代软件工程中测试的原则不相适合。 V模型的缺点： （）V模型是等到编码终止才开始进行单元测试，和前面提到的要在软件开发生命周期中尽早地和不断地进行测试这

5、个最重要的测试原则相矛盾。 （）应当开发和测试并行，开发小组和测试小组通力合作，而传统的V模型的这种方式很可能出现这种状况，开发人员编码完成，就等着测试小组提交缺陷报告，然后修改程序。这种就对比空闲，不利于人力资源的利用，也不利于小组间的合作。 （）这个模型测试过程和开发过程在时间上严格的划分开，这样不利于测试计划、测试用例、出错统计和最终分析报告等文档的保存。 基于以上原因以及传统V测试模型的缺点，提出了改进的测试模型，如下图。 这个模型左边是开发阶段，右边是与各个开发阶段对应的测试。他们的执行顺序都是从上到下，测试与开发并行进行。如需求分析阶段就有制定测试计划和测试需求这两个测试步骤；软件

6、设计阶段就设计此阶段的测试用例并测试设计阶段得出的结果。每个阶段都要设计相应的测试用例，一旦得出了可测试的结果，就对其进行测试。这也符合尽早地和不断地进行测试这个原则。而且这样的话测试小组和开发小组就可以更好地合作，有利于资源利用。 该模型从一开始的需求阶段就制定测试计划，在需求分析的过程中，对可测试的需求文档进行需求测试。测试计划的目标是描述所有要完成的测试，包括完成所需的资源和进度。测试计划应给出被测试软件的背景信息、测试的目标和风险，以及所要执行的特定测试。测得太多不行，浪费人力财力；测得太少也不行，软件的质量得不到保证。有效的测试方法就是明确和评价计算机系统的各种风险。能把这些风险缩小

7、到测试范围内是很重要的。要确定能接受多少风险，然后制定测试计划实现这个目标。风险的概念确定了从经济学的角度考虑需要完成多少测试或测试类型，而不是进行不可能完成的穷举测试或者凭直觉胡乱地测试。所以有经验的测试人员会基于风险找到一个平衡点，逐步完成测试计划。需求测试的目的是要确保需求得到了正确的记录，保证信息服务工程小组正确解释了需求。由于需求阶段应当是用户占主导地位的阶段，所以测试必需要确定需求很好地代表了用户的需要，确定已经文档化了需要。 接下来是对总体设计和详细设计的测试。这个阶段执行设计评审以及审查可交付的设计结果。此阶段的测试和需求阶段的测试都是静态测试，没有可执行的代码，只有文档和可交

8、付结果用于审查。假如将缺陷遗留到后面的阶段解决，会增加大量花费。这也不符合及早地不断地进行测试的原则。可交付结果包括：输入规格说明、处理规格说明、输出规格说明、操纵规格说明、系统流程图等等，基本上就是对这些文档进行测试。这个阶段有几个任务需要完成：分析设计因素、进行设计评审、审查设计阶段可交付的结果。 编码阶段进行的测试，主要是针对代码进行测试，已白盒测试技术为主，已黑盒测试为辅。白盒测试技术中的语句覆盖、条件覆盖、路径覆盖等技术都可用于代码的测试阶段。从这个阶段开始，就有了可执行的代码，所以此阶段和之后的阶段都是进行动态测试。 编码阶段终止后就进入了传统的测试阶段，这个阶段要进行单元测试，然后在软件模块的集成过程中要进行集成测试，在进行系统测试和用户的验收测试。系统测试和验收测试里面也包括了对系统功能的测试。这个阶段基本上就按传统的测试阶段进行，但是由于此前做了大量测试工作，这个阶段的大量步骤比传统测试阶段的步骤更简单，返工的工作也更少，花费也更小。开发阶段的测试就到此为止，形成了成品软件，交付给用户方。