论文部分内容阅读
软件质量保证是软件开发过程的重要一环。所谓软件质量保证就是使软件综合品质符合用户需求，软件质量保证的理论、技术、措施很多，测试是其中最重要的手段之一。实践证明，虽然软件的质量并不完全依赖于测试，但科学、合理、有效的测试方案却可以极大地提高软件质量。其中，基于需求的测试（RBT）就是软件质量保证的重要工具途径之一。相关权威研究表明，已发现的软件缺陷中超过50%的缺陷源于错误或者不恰当的软件需求。
保证需求与软件的统一
Richard Bender是基于需求的软件测试方法创始人。他认为：改进软件系统测试方法的最佳途径在于改进软件需求定义开发过程和功能测试设计过程，基于需求的测试是一种最根本的软件测试。
软件需求分析解决的主要问题是“软件产品必须或应该做什么”，软件需求分析的最重要成果就是需求说明书，需求说明书是软件产品的雏形，软件产品是需求说明书的最终展现成果。由于需求和软件之间是相互对应的，编码和测试用例之间也是相互对应的，所以需求和测试用例之间是互相对应的，在本质上也是互相关联、密不可分的，可以实现需求和测试用例之间的双向跟踪追溯。
值得一提的是，在软件开发过程中，编程和测试是紧密相关、相辅相成的活动，两者同等重要、缺一不可。测试的目的是为了发现尽可能多的缺陷，并期望通过修改完善缺陷以提高软件的质量。成功的测试在于发现了迄今尚未发现的缺陷，测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。
然而，在企业应用软件项目的实施过程中，普遍存在重编码轻测试、缺乏高素质软件测试人员的现象。事实上，设计与测试应该完全分离，好的开发者构建事务，好的测试者破坏事务，一个好的软件测试工程师应该要比开发工程师对整个系统的理解更加透彻。目前很多软件测试工程师处在软件项目组的最低职级，缺乏高层的重视和支持，自身对于整个应用系统“该做什么、要做什么、必须做什么”并不清楚，如果再加上与设计人员的沟通交流协作过程中不讲究原则性、策略性，其工作成效可想而知。
基于需求的软件测试方法
要实施基于需求的软件测试，其正确的工作步骤如下：
1．全面清晰地掌握用户需求
全面、清晰、准确地认识理解用户需求、软件平台架构是软件测试工程师开展一切测试工作的前提和基础。软件测试工程师应认真阅读、研究、分析《用户需求说明书》、《软件产品设计说明书》（分为概要设计和详细设计）等关键文档，清晰掌握平台架构设计、数据库结构设计、模块功能设计、核心算法、界面展现、人员权限角色分配、输入输出数据等要素，将业务操作流程和以上要素分别逐一对应关联。
2．明确测试的目标和任务
软件测试的任务就是验证软件是否准确地实现了用户需求，检验需求和软件之间是否一致。好的测试用例能发现软件中潜在的新缺陷，糟糕的测试用例在目标及任务尚不明确的情况下盲目进行评测，不仅效率低下，而且毫无效果。
3．分阶段制订测试计划方案
测试计划方案不是从头到尾一成不变的，应根据企业应用软件项目所处的不同阶段制订，不同的项目阶段所需的测试方法是不一致的。可以借鉴RBT理论关于基于需求的测试方法的最佳实践（参见链接）。
4．设计基于需求的复合测试用例
在很多情况下，单一的测试方法很难实现软件缺陷或错误的全面检查，在软件工程中使用最多的往往是组合多种测试方法的复合测试用例。例如黑盒测试和白盒测试两者的功能作用就可以互相弥补，实践中可以将两种测试方法组合起来设计复合测试用例。
5．妥善处理测试和设计之间的关系
测试是“破坏性”的，而开发却是“建设性”的。从行为学角度看，开发与测试是对立的。如果测试人员对开发人员的错误批评指责过多，容易导致双方的关系对立隔阂；如果测试人员对开发人员的错误疏忽怠慢，容易导致软件质量的隐形下降，实践中需要找到一个平衡点。
6．建立测试报告审批通报制度
建立测试报告审批通报制度对于提升软件质量具有明显作用。作为一名优秀的测试工程师，要养成书面起草测试工作报告的好习惯。将已经定位发现的缺陷或错误进行分析汇总，用统计数字、图表等方式说明缺陷或错误的根源，及时将测试工作报告提交上级主管领导审议，并通知研发设计人员，使设计人员做到对缺陷心中有数、控制有道，以防患于未然。
链接
基于需求的测试理论的五项最佳实践
1．转变“编码后进行测试”的传统观念。在软件编码开始之前的设计阶段就根据需求文档和设计文档开发出90%以上的测试用例，尽早发现和排除绝大部分的缺陷。
2．根据各项应用功能的优先级、重要性制订不同等级的测试方案、测试用例。重要的模块投入较多的测试资源（人力、时间、物资），次要的模块投入较少的测试资源。
3．尽早测试，频繁测试。测试进行得越早，缺陷发现越早，修复缺陷的代价越小；测试进行得越晚，缺陷发现越迟，修复缺陷的代价越大。
4．摒弃“经验至上”的想法。设计系统、严谨、合理的测试用例才能使测试达到实效。
5．加强对测试过程的监控跟踪。当用户需求发生变更时，软件需求文档和设计文档都随之发生变更，相应测试用例也应发生变更。要随时监控需求的变化，保证测试用例和用户需求的双向追溯统一。
保证需求与软件的统一
Richard Bender是基于需求的软件测试方法创始人。他认为：改进软件系统测试方法的最佳途径在于改进软件需求定义开发过程和功能测试设计过程，基于需求的测试是一种最根本的软件测试。
软件需求分析解决的主要问题是“软件产品必须或应该做什么”，软件需求分析的最重要成果就是需求说明书，需求说明书是软件产品的雏形，软件产品是需求说明书的最终展现成果。由于需求和软件之间是相互对应的，编码和测试用例之间也是相互对应的，所以需求和测试用例之间是互相对应的，在本质上也是互相关联、密不可分的，可以实现需求和测试用例之间的双向跟踪追溯。
值得一提的是，在软件开发过程中，编程和测试是紧密相关、相辅相成的活动，两者同等重要、缺一不可。测试的目的是为了发现尽可能多的缺陷，并期望通过修改完善缺陷以提高软件的质量。成功的测试在于发现了迄今尚未发现的缺陷，测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。
然而，在企业应用软件项目的实施过程中，普遍存在重编码轻测试、缺乏高素质软件测试人员的现象。事实上，设计与测试应该完全分离，好的开发者构建事务，好的测试者破坏事务，一个好的软件测试工程师应该要比开发工程师对整个系统的理解更加透彻。目前很多软件测试工程师处在软件项目组的最低职级，缺乏高层的重视和支持，自身对于整个应用系统“该做什么、要做什么、必须做什么”并不清楚，如果再加上与设计人员的沟通交流协作过程中不讲究原则性、策略性，其工作成效可想而知。
基于需求的软件测试方法
要实施基于需求的软件测试，其正确的工作步骤如下：
1．全面清晰地掌握用户需求
全面、清晰、准确地认识理解用户需求、软件平台架构是软件测试工程师开展一切测试工作的前提和基础。软件测试工程师应认真阅读、研究、分析《用户需求说明书》、《软件产品设计说明书》（分为概要设计和详细设计）等关键文档，清晰掌握平台架构设计、数据库结构设计、模块功能设计、核心算法、界面展现、人员权限角色分配、输入输出数据等要素，将业务操作流程和以上要素分别逐一对应关联。
2．明确测试的目标和任务
软件测试的任务就是验证软件是否准确地实现了用户需求，检验需求和软件之间是否一致。好的测试用例能发现软件中潜在的新缺陷，糟糕的测试用例在目标及任务尚不明确的情况下盲目进行评测，不仅效率低下，而且毫无效果。
3．分阶段制订测试计划方案
测试计划方案不是从头到尾一成不变的，应根据企业应用软件项目所处的不同阶段制订，不同的项目阶段所需的测试方法是不一致的。可以借鉴RBT理论关于基于需求的测试方法的最佳实践（参见链接）。
4．设计基于需求的复合测试用例
在很多情况下，单一的测试方法很难实现软件缺陷或错误的全面检查，在软件工程中使用最多的往往是组合多种测试方法的复合测试用例。例如黑盒测试和白盒测试两者的功能作用就可以互相弥补，实践中可以将两种测试方法组合起来设计复合测试用例。
5．妥善处理测试和设计之间的关系
测试是“破坏性”的，而开发却是“建设性”的。从行为学角度看，开发与测试是对立的。如果测试人员对开发人员的错误批评指责过多，容易导致双方的关系对立隔阂；如果测试人员对开发人员的错误疏忽怠慢，容易导致软件质量的隐形下降，实践中需要找到一个平衡点。
6．建立测试报告审批通报制度
建立测试报告审批通报制度对于提升软件质量具有明显作用。作为一名优秀的测试工程师，要养成书面起草测试工作报告的好习惯。将已经定位发现的缺陷或错误进行分析汇总，用统计数字、图表等方式说明缺陷或错误的根源，及时将测试工作报告提交上级主管领导审议，并通知研发设计人员，使设计人员做到对缺陷心中有数、控制有道，以防患于未然。
链接
基于需求的测试理论的五项最佳实践
1．转变“编码后进行测试”的传统观念。在软件编码开始之前的设计阶段就根据需求文档和设计文档开发出90%以上的测试用例，尽早发现和排除绝大部分的缺陷。
2．根据各项应用功能的优先级、重要性制订不同等级的测试方案、测试用例。重要的模块投入较多的测试资源（人力、时间、物资），次要的模块投入较少的测试资源。
3．尽早测试，频繁测试。测试进行得越早，缺陷发现越早，修复缺陷的代价越小；测试进行得越晚，缺陷发现越迟，修复缺陷的代价越大。
4．摒弃“经验至上”的想法。设计系统、严谨、合理的测试用例才能使测试达到实效。
5．加强对测试过程的监控跟踪。当用户需求发生变更时，软件需求文档和设计文档都随之发生变更，相应测试用例也应发生变更。要随时监控需求的变化，保证测试用例和用户需求的双向追溯统一。