摘要:在开发软件的过程中，必须进行有效的测试过程，以保证软件的质量，使企业在竞争中立于不败之地。本文首先总结了软件测试的原则，然后分析了传统的V测试模型的一些缺点，并在此基础上提出了改进的V测试模型。
关键字:V测试模型 测试原则 生命周期测试
作者简介：
马俊，男， 24岁，西南大学硕士研究生，主要研究方向：计算机软件与理论；丁晓明，男，40岁，西南大学计算机科学与信息学院副教授，硕士生导师。
1 引言
随着计算机技术的飞速发展，软件行业的竞争日益激烈，在开发软件的过程中，人们使用了许多保证软件质量的方法来分析、设计和实现软件，以保证自己生产的软件在竞争中的不败。但开发人员难免会在工作中犯错误，特别是对于规模大，复杂性高的软件更是如此。这样，在软件产品中就会隐藏许多错误和缺陷。这些错误和缺陷如果遗留到软件投入运行之时，终将会暴露出来。1996年，由于阿里亚纳（Ariane）5号火箭上的软件系统失败，损失了多个卫星，造成的间接经济损失达到数十亿美元[1]。象这种要求极高的系统的验证工作比其他类型的系统更为重要，而且成本也高得多。但若不进行足够的验证而出现Ariane 5号火箭这种情况，则造成的损失比验证的成本要高得多。许多类型的软件所使用的领域还涉及到人类的生命安全。比如医用领域的胰岛素注射系统，若因软件的缺陷而造成系统故障，向病人注射过量的胰岛素，会导致脑功能障碍甚至死亡。以上提到这些风险及大的软件系统，在开发过程中必须经过严格的测试，以验证软件系统的可靠性。就算一般的系统，虽然不会对人的生命造成危害，但是在经济方面的损失是不可估量的。比如银行的管理系统，若出现系统崩溃的情况，经济损失巨大。所以不管什么系统，都必须在经济允许的情况下，进行足够的测试，已保证软件的质量。
２ 软件测试的原则
软件测试有以下几项原则：
（１）在软件开发生命周期中尽早地和不断地进行测试[2]。
质量保证协会的调查表明，应用系统每1000个源语句中存在大约60个缺陷，这些缺陷中有2/3是出现在系统的需求和设计阶段的。如果拖到后面的阶段解决这些缺陷，将增加大量费用。
（２）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。
（３）程序员应避免测试自己的程序。如果程序员测试自己的程序，他会按自己开发时的思维方式来看待自己的程序，总认为自己的程序是正确的，不利于找到缺陷。
（４）要妥善保存测试计划、测试用例、出错统计和最终分析报告，这些文档会为维护人员维护阶段的工作提供方便。维护阶段是软件交付后的阶段，有可能维护人员是用户方的人而不是开发人员，保留这些文档就尤为重要。
３ 传统的V测试模型分析
传统的Ｖ模型如下图：
.jpg)
图1 传统V测试模型
其左边每个开发活动都与右边的测试活动相对应,它描绘了软件开发过程中,需求、总体设计、详细设计和编码逐步实现，针对这些开发阶段的测试，其开展的次序正好相反。也就是说，代码最后被开发出来，而相应的单元测试首先被执行；需求最早开发，但相应的验收测试是最后才进行的。这个传统的模型是早期开发出来的，和现代软件工程中测试的原则不相适合。
V模型的缺点：
（１）V模型是等到编码结束才开始进行单元测试，和前面提到的要在软件开发生命周期中尽早地和不断地进行测试这个最重要的测试原则相矛盾。
（２）应该开发和测试并行，开发小组和测试小组通力合作，而传统的V模型的这种方式很可能出现这种情况，开发人员编码完成，就等着测试小组提交缺陷报告，然后修改程序。这种就比较空闲，不利于人力资源的利用，也不利于小组间的合作。
（３）这个模型测试过程和开发过程在时间上严格的划分开，这样不利于测试计划、测试用例、出错统计和最终分析报告等文档的保存。
４ 改进的V测试模型
我们在整个开发过程中应该进行生命周期测试，即在开发过程中对系统进行持续的测试，测试活动应该在需求阶段就开始，而不是在传统的编码之后，并且软件测试进程应该是和软件开发的开发进程并行进行的。
基于以上原因以及传统V测试模型的缺点，提出了改进的Ｖ测试模型，如下图。
图2 改进的V测试模型
这个模型左边是开发阶段，右边是与各个开发阶段对应的测试。他们的执行顺序都是从上到下，测试与开发并行进行。如需求分析阶段就有制定测试计划和测试需求这两个测试步骤；软件设计阶段就设计此阶段的测试用例并测试设计阶段得出的结果。每个阶段都要设计相应的测试用例，一旦得出了可测试的结果，就对其进行测试。这也符合尽早地和不断地进行测试这个原则。而且这样的话测试小组和开发小组就可以更好地合作，有利于资源利用。
该模型从一开始的需求阶段就制定测试计划，在需求分析的过程中，对可测试的需求文档进行需求测试。测试计划的目标是描述所有要完成的测试，包括完成所需的资源和进度。测试计划应给出被测试软件的背景信息、测试的目标和风险，以及所要执行的特定测试。测得太多不行，浪费人力财力；测得太少也不行，软件的质量得不到保证。有效的测试方法就是明确和评价计算机系统的各种风险。能把这些风险缩小到测试范围内是很重要的。要确定能接受多少风险，然后制定测试计划实现这个目标。风险的概念确定了从经济学的角度考虑需要完成多少测试或测试类型，而不是进行不可能完成的穷举测试或者凭直觉胡乱地测试。所以有经验的测试人员会基于风险找到一个平衡点，逐步完成测试计划。需求测试的目的是要确保需求得到了正确的记录，保证信息服务项目小组正确解释了需求。由于需求阶段应该是用户占主导地位的阶段，所以测试必须要确定需求很好地代表了用户的需要，确定已经文档化了需要。
接下来是对总体设计和详细设计的测试。这个阶段执行设计评审以及审查可交付的设计结果。此阶段的测试和需求阶段的测试都是静态测试，没有可执行的代码，只有文档和可交付结果用于审查。如果将缺陷遗留到后面的阶段解决，会增加许多花费。这也不符合及早地不断地进行测试的原则。可交付结果包括：输入规格说明、处理规格说明、输出规格说明、控制规格说明、系统流程图等等，基本上就是对这些文档进行测试。这个阶段有几个任务需要完成：分析设计因素、进行设计评审、审查设计阶段可交付的结果。
编码阶段进行的测试，主要是针对代码进行测试，已白盒测试技术为主，已黑盒测试为辅。白盒测试技术中的语句覆盖、条件覆盖、路径覆盖等技术都可用于代码的测试阶段。从这个阶段开始，就有了可执行的代码，所以此阶段和之后的阶段都是进行动态测试。
编码阶段结束后就进入了传统的测试阶段，这个阶段要进行单元测试，然后在软件模块的集成过程中要进行集成测试，在进行系统测试和用户的验收测试。系统测试和验收测试里面也包括了对系统功能的测试。这个阶段基本上就按传统的测试阶段进行，但是由于此前做了许多测试工作，这个阶段的许多步骤比传统测试阶段的步骤更简单，返工的工作也更少，花费也更小。开发阶段的测试就到此为止，形成了成品软件，交付给用户方。
最后测试小组要总结项目的测试结果，以提高企业测试的过程，就要评价测试的有效性。这相当于是对项目测试过程的总结，有利于以后企业对项目进行测试的效率。这个时候测试计划、测试用例、出错统计和最终分析报告这些文档就有用处了。可以通过分析这些文档，加以总结，评价测试的有效性。
５ 结束语与进一步工作
本文指出了传统V测试模型的不足之处，结合测试原则进行分析，并提出了相应的修正措施，提出了改进的V测试模型。该模型在理论上具有比传统V测试模型优秀的地方。进一步的工作就是把该模型的思想用于实际的项目中检验，并进行分析，以从实践上论证该模型的可行性和优越性。
参考文献
[1]Ian Sommerville.软件工程[M].2005,3.
[2]William E.Perry.软件测试的有效方法[M].2004,3.
[3]李祎,陈嶷瑛.一种有效的软件测试模型[J].计算机工程与应用,2004,10:114－115.
[4]张海藩.软件工程导论[M].2003,12.
[5]Cem Kaner&Jack Falk.计算机软件测试[M].2004,5