软件测试分析方法研究

软件测试分析方法研究

摘要：软件测试分析在整个测试过程中占据很重要的位置。软件测试分析完成了，可以在测试前期就发现一些项目设计考虑不足的地方，降低了项目的风险，提高了测试效率，节约了测试成本。文中最后分析了测试终止条件和时机，以控制测试成本。

关键词：需求规格；分析；风险；终止测试

1 测试分析的重要性

测试分析设计体系，一个最主要的目的就是使测试工作往前移，增强测试需求分析阶段的活动。在软件分析设计阶段就介入测试，可以发现早期的一些设计方面的不完整的方面，降低项目的成本。 实际经验证明，测试成本随着产品逐步成形而增加。假如需求分析、设计阶段的一些问题没有被发现，等到编码阶段完成后，通过测试发现这些问题，而这些问题只能由更改设计来修复的话，那么不论是测试还是开发的成本就在无形中放大了好几倍，项目如期交付的风险会很大。目前，多数情况的测试工作都是在编码阶段结束或者即将结束才介入的，存在前期投入不足的问题。并且，目前还存在的问题是没有足够的人力和时间做测试需求分析，有时候在测试什么都不是十分清楚的情况下就开展测试设计工作，在被测试对象都不是十分清楚的情况下就着手测试的，在测试的过程中才慢慢的了解被测系统。这样导致发现的bug 数不是一个正常的曲线(刚开始bug 数很多，几个版本后，bug 数趋于收敛，到最后bug 数很少或没有严重、致命的bug) ，而是刚开始很少，到后期越来越多的趋势，而且很多隐藏比较深的bug 也是在软件快要交付的时候才被发现，甚至在软件系统试验后。这样的情况，往往在规定的时间测试无法正常结束，项目也就不能按时交付，产品成本很高。测试分析强调的是测试需求分析阶段的活动，这个阶段要求有足够的资源保证测试需求分析相关任务完成。一方面要求有经验的人员投入，另一方面要有资料的资源。这个阶段投入的是测试部门里有经验的专家或者骨干，或者是系统组成员，他们充分和开发人员、设计人员进行交流，输出测试需要的内容。同时在测试需求分析过程中，会发现需求或者设计规格错误或者不合理的或有遗漏的地方，应及时提出问题，督促开发人员、设计人员进行修改，避免这些问题在测试执行阶段才发现。另外，要求测试人员介入的一个原因是在设计需求、设计规格或者客户需求不明确的情况下，通过测试需求分析相关的活动，尽可能获取完整的信息。现实中，经常遇到这种情况，如果直接进行用例设计，测试完备性无法保证，此时更要加强测试需求分析阶段工作，只有弄懂测试的原始需求才能开展测试设计工作，清楚我们所要测试的系统是在什么环境、场景下运行的，测试设计中才能更逼真的模拟被测对象实际运行的场景，构造一些测试场景，使得测试做的更加充分。如何获取这些需求也是测试的核心能力之

2 需求明确条件下的测试分析

IEEE 对需求有以下两种定义的方式：

a) 解决用户问题或达到用户目标需要具备的条

件或能力；

b) 遵守合同、协议、规范或其他要求。

我们常说的需求，其实并不是需求规格说明书。

需求是对要实现功能的粗略描述，而需求规格是对需求的精确定义。在软件开发过程中，只有得知了需求的精确定义，才能开展工作。比如功能方面，编辑框能支持多少位字符；性能方面，时问和容量规定等。当然还包含其他非功能、性能方面的定义。除了以上所说的需求，对于测试人员，还必须了解测试需求，清楚需要测试哪些方面，软件是否可测，需要增加哪些开发需求等。需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当和委托方以及被测方合作时，就将会问一些问题，并取得他们所提供的信息。同时，处理并理解这些信息，把它们分成不同的类别，还要把委托方需求同可能的软件需求相联系。然后，可以使测试需求信息结构化，并编写成文档和示意图。下一步，就可以让专家代表评审文档并纠正存在的错

误。

由于软件开发项目和组织文化的不同，对于测试需求分析没有一个简单的、公式化的途径。下面仅为系统级的软件测试分析列出了9个步骤，可以指导测试分析活动：

a) 确定需求决策者和他们的决策过程；

b) 定义项目的级别和范围；

c) 确定测试类型和测试要求；

d) 选择所用的测试技术和测试工具；

e) 对作为系统一部分的使用实例进行预设并设

置优先级；

f) 从用户那里收集质量属性的信息和其它非功

能需求；

g) 详细拟订使用实例的充分性和测试约束；

h) 评审使用实例的描述和功能需求；

i) 回归测试影响域分析。

3 需求不明确条件下的测试分析

在没有明确需求，需求规格，测试需求的情况下，如何进行测试? 当测试人员接手一个项目后，第一件事情一定是想了解这个系统的功能、背景、架构。如果根本没有需求文档，或者文档根本不具备参考价值时，可以试着从以下几个步骤着手：

3．1 查阅文档

有时，我们的项目可能是在原有产品的基础上，进行版本升级。这时，先去找找有没有原有版本的需求，或者用户手册等文档。从这些文档中，了解项目的背景，系统的基本功能。这对了解新项目是有很大好处的。并且，在产品升级的项目中，验证老版本的功能在新版本中是否正常，也是一个必要的工作。可以先参考老版本的相关文档，设计新版本中的用例。另外，我们的项目可能是一个行业项H ，测试人员可以参考一些行业知识的书籍。这对理解系统也有很大的好处。在测试人员对系统已经有了一些了解时，要生成记录文档。还要注意及时更新文档。因为测试人员对系统的理解，随时都在变化，一定要保证文档和对系统当前的理解是一致的。

3．2 根据经验和常识猜测

既然没有需求，可以推测该项目的管理一定是混乱的，对测试也不会投入很大的成本。因此，测试人员般都是在编码完成后才进入项目，这时应该已经可以看到成型的系统了。在没有需求的情况下，试着先用一下系统，可对系统有更深人的认识，此时可以排除部分上一阶段遗留下的疑惑或是猜测。系统可能是针对某个专业领域，测试人员也应具备行业知识，当测试人员了解业务知识后，会进行更深入的思考，来全面测试系统。最后加上测试人员的判断，如对系统的整体感觉，是否越用越厌烦，系统的反应速度是否可以容忍，细节处理是否仔细等等。在认识系统的时候，可以使用一些更有效率地方法，比如画流程图。

3．3 沟通

需求规格不一定非要以文档的形式表现出来。软件既然需要开发，那肯定是有需求的。而最清楚需求的，一定是软件的开发人员。因此，测试人员一定要主动和开发人员沟通，可以安排会议，让开发人员给测试人员介绍系统，并演示系统，让测试人员对系统有一个整体了解。然后测试人员能进行更细致的测试。在进行细节测试的时候，一定会有更多不明确的地方，这时可以利用自己的行业知识，猜测一部分，也需要和开发人员及时保持有效沟通。有些项目中，客户会直接参与到项目组来。客户的需求，是最原始的需求。但是，客户未必有良好的表达能力来描述希望的功能，也未必有计算机软件知识，因此不能描述出一些专业的需求。测试人员和客户进行交流，不仅可以帮助客户正确描述出真实需求，测试人员也能详细了解需求。但是项目是要考虑成本的，客户的期望是无限制的，在客户提出需求以后，测试人员要先和项目负责人或其他相关负责人沟通后，才能将客户的需求，

作为测试的依据。同时，将最新的信息第一时问告知相关开发人员，并记录成文档，这时，你就将非文档形式的需求，转换为文档形式了。有时候，也会根本找不到可以沟通的人。比如测试一个开源软件，测试外包或者软件项目组的部分人员已经联系不上等等。这时候，一方面需要项目负责人协调获取相关资料，联络相关人员；另一方面，测试人员可以利用集体智慧，共同探讨和猜测软件中的各个环节，也可以让尽可能多的人员参与随机测试，获取具有创造性的意见。

4 测试终止条件和时机分析

软件评测机构得到的测试终止时间往往是随产品的预定发布或交付时问来定的。甚至有的产品发布或交付前一周还在写新功能，测试时间不足，且无法估算测试工作量。个合理的测试终止条件只能来源于一个清晰的测试目标。如果测试的目标是找到所有的缺陷，那么无论多少时间都是不够的。合理的终止条件应当从以下两个方面考虑。

首先，测试是为了保证软件的质量，而软件的质量标准是由用户来决定的。这个标准应当在软件开发初期从用户需求调查中获得。如果每一需求项都列出了可测试的、被共同利益者认可的标准和写入测试计划之中的测试用例，这样软件测试结束的第一个必要条件就是所有在测试计划中所列出的测试项和标准都通过测试。

其次，通常来说，早期找到并排除的缺陷越多，运行维护成本就越少，但密集的测试就会导致测试成本的增高。而对测试来说，随着旧的缺陷不断地被找到并修复，软件的质量也就越来越好，后继的服务成本就越来越低；相应地，新缺陷也就越来越难找，即测试成本越来越难高。所以售后服务的成本和测试的成本大

致可以用图1来表示。

图1 测试和服务的成本关系

由图1可知，当找到并解决的缺陷占总缺陷的比例达到 时，可终止测试。因为再要通过测试去发现一个缺陷成本比发布后再去维护的成本要高了。其实从企业利润的角度看，就要使这两部分的成本之和最小。当然在实际情况下，这两条曲线是无法准确估计的，测试人员往往按拇指规则，即假设残留的缺陷数与最后一阶段排除的缺陷数相等。当一段时间内(通常是一个星期) 测试不出新缺陷时，或按测试效益规则，当找到的新缺陷的实际价值低于相同时间的测试运行费用，或测试成本与维护成本之和达最小值时，或在3～5倍企业同类软件开发项目的平均缺陷测试时间内仍测试不出的新缺陷时，这些情况可做为较合理的终止条件。

5 结束语

整个的测试分析阶段是为后续的测试用例设计做 准备的。前期准备工作不充分，后期的工作也就无法 保证。因此，测试分析是软件测试工作中必不可少重 要环节。

参考文献

[1]戴金龙．软件测试全过程[J]．软件世界，2007，24(3)：66- 67．

[2]樊庆林，吴建国．提高软件测试效率的方法研究[J]．计算 机技术与发展，2006，16(10)：52-54．

[3]王虎．软件需求分析探讨[J]．科技情报开发与经济， 2008，18(13)：148—149．

[4]毛利峰．对软件需求分析的一些思考[J]．计算机时代， 2008，26(7)：63-64