系统软件测试中的测试需求分析

系统软件测试中的测试需求分析

摘要：随着人们对软件工程化的重视以及软件规模的日益扩大，软件分析、设计的作用越来越突出，有资料标明，60%以上的软件错误不是程序错误，而是分析和设计错误，因此，做好软件需求和设计的测试工作就显得非常重要。这也是我们提倡的测试概念扩大化，提倡软件全生命周期测试的理念。

关键词：系统软件测试；测试；需求；分析

中图分类号：tp311

1 什么是测试需求

简单来说，测试需求就是确定在项目中需要测试什么。测试需求描述测试的目标，特别是描述了产品的质量需求，测试需求分析目的是帮助定义测试对象和测试范围，发现软件需求中不完善和不明确的地方并加以完善以节省测试时间的投入，便于软件需求基线化和跟踪业务需求的变更。

一条有用的测试需求是唯一的、精确的、有边界的、可测试的。例如：软件产品可能有这样一个测试需求“系统主要事务的响应时间能满足系统要求”。这就是一个不符合要求的测试需求，怎样的指标是“满足”？系统的要求又是什么都不清晰，测试就无法开展。一个完整清晰的可测试的软件测试需求是这样的：在1g内存和1.73兆主频的计算机上在25个并发用户执行插入、更新和删除操作时端到端的响应时间在3秒时间内。符合标准的测试需求是存在一个明确的可预知的结果，可以通过某种方法对这个结果进行判断

和验证

测试需求应覆盖已经定义的业务流程，功能及非功能方面的需求。

2 为什么要做测试需求分析

测试需求是测试计划的基础与依据，我们在测试活动中，首先需要明确测试需求（what），才能决定怎么测（how），测试时间（when），需要多少人（who），测试的环境是什么（where）。是衡量测试覆盖率的重要指标。

确立测试需求是为了保证测试质量与进度，测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。在软件工程项目中，存在一些普遍的现象例如：需求阶段的问题，到测试的最后阶段才被发现；开发、测试、市场等不同角色的人员对软件功能细节存在理解歧义。确立测试需求可以避免这些问题的产生。

3 什么时候开始做测试需求分析

软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。因此一旦软件需求确定后，即可开始进行测试需求分析。

4 如何做测试需求分析

做测试需求分析有两个关键词，一个是“测试需求”，一个是“分析”，下面我从以下几个步骤来说明如何做测试需求的分析。

4.1 对软件需求说明书进行需求验证

一个良好的软件需求应当具有一下特点：（1）清晰性；（2）组织和完整性；（3）一致性；（4）可修改性；（5）可跟踪性；（6）可检验性；（7）接口：界面、接口的说明；（7）质量、性能属性；（8）可靠性；（9）软硬件；（10）特殊问题。

4.2 搜集和提取测试需求（包括隐性的需求）

测试需求并不等同于软件需求，它是从测试的角度出发并根据软件需求整理出一个测试列表，作为该软件的主要测试内容。提取测试需求要以软件需求说明书及规格说明书为依据，以业务功能为中心，深刻理解业务规则和隐式需求，通过与客户深入沟通，明确测试范围和质量目标，达到测试分析和设计全面、无遗漏。隐形需求包括：用户隐式的需求如业务规则；行业规范；编写人员的技术能力所限等。提取方法可通过列表的方式对软件开发需求进行梳理，先提取出所有的需求点。这些需求点可能存在重复和冗余，再根据项目的功能模块进行组织归类，删除重复的需求、细化测试粒度太大的需求、合并相关联的需求，最后根据业务规则及相关文档等，对测试需求进行检查和完善。测试需求主要通过以下途径来收集：（1）与待测软件相关的各种文档资料。如软件需求规格、usecase、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。（2）与客户或系统分析员的沟通。（3）业务背景资料。如待测软件业务领域的行业标准及知识等。（4）正式与非正式的培训。（5）其他途径。

4.3 根据测试阶段和重点，整理测试需求

测试处于不同的阶段，测试的重点也是不同的，例如集成测试阶段主要是检验程序单元或部件的接口关系；系统测试阶段，重点是为了验证和确认系统是否达到了其原始目标，通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方。因此确立测试阶段和重点，才能在测试需求分析时，做到方向正确、目标明确。除了需要确保要求实现的功能正确，还要考虑软件的特性。银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，erp强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。关注测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。系统功能测试需求分类：（1）业务功能测试需求；（2）可靠性测试需求；（3）安全性测试需求；（4）易用性测试需求；（5）可移植性测试需求；（6）可维护性测试需求。

5 测试需求评审

测试需求的评审是质量保证的必须步骤，通过评审可保证测试需求获得相关干系人的认可，做到有据可依。测试需求评审的内容包括完整性审查和准确性审查。完整性审查是检查测试需求是否覆盖了所有的软件需求、以及软件需求的各项特征，关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束、行业标准等。同时还要关注系统隐含的用户需求。准确性审查是检查测试需求是否清晰、没有歧义、描述准确，是否能获得评审

各发的一致理解，在测试需求之间以及与开发需求没有矛盾和冲突，每一项测试需求都可以作为设计测试用例的依据。

测试需求评审的形式没有固定的要求，有条件可以采用正式的小组会议形式进行评审，在评审之前确定好参会人员的各个角色和相关的责任，确保评审之前参会人员已经拿到了评审材料并有了足够的了解，评审结束时以签名及会议纪要的方式把评审结果通知相关单位及人员。此方式的优点是有计划有组织地进行，评审更加有效和权威，缺点是需要协调相关人员时间及会议场地等，在很多实际项目中有较大难度。测试需求评审还可以采取非正式的走查和轮查形式，将需要评审的内容发给相关人员，收集他们的意见，并把统一意见修改确立后的测试需求再发给相关评审人员进行确认。这种方式的优点是方便有效，缺点是少了多方人员的讨论和沟通。对于大型的重要项目，可能还会采取正式审查方式进行评审，包含了制定评审计划、组织会议、会后跟踪分析审查结果等。参与测试需求评审的人员至少要包含：项目经理、开发负责人、测试负责人、系统分析人员、相关开发和测试人员。测试需求评审通过以后，才可以跟进测试需求来制定测试计划及编写测试用例。

6 测试需求维护

在实际的软件工程中，软件需求的变更是很常见的，甚至频繁变更软件需求。如果一直使用初始的测试需求来指导我们的测试工作，必然造成测试的结果存在错误和差异。因此必须及时维护测试需求，适应实际工作的需要。在需求变化频繁的情况下，作为测试