软件测试需求
本人从事软件测试工作也有2年多的时间，自认没有师从名家，但自己还是搜罗广泛的资料进行了不懈的学习，呵呵，现将自己的一些浅显的见解发上来，希望大家能广开思路，让测试的前方一片光明，闲话少说，我今天想谈谈测试需求方面的东东。测试需求
1.定义：什么叫测试需求？
以测试的观点，根据参考资料整理出来的一份checklist，用来描述对被测对象要测试什么。
2.理解：
定义中所说的“参考资料”根据不同的测试项目会有不同的内容，具体可以参考测试需求分类中的相关描述。
3.区分：测试需求的分类？
根据软件项目过程的不同，测试需求有不同的分类。
一、对于全生命周期的软件项目，项目过程为：项目立项可行性分析需求分析概要设计详细设计编码测试实施维护，和这个过程匹配，软件测试也会经历单元测试集成测试系统确认测试验收测试这样一个过程。依据这样的过程，可以将测试需求分为：单元测试测试需求、集成测试测试需求、系统确认测试测试需求、验收测试测试需求4类。每一类测试需求都指导该类测试需求对应的测试阶段要测试什么。这种划分方式适合于公司内部的项目。这类项目，我们进行测试需求分析的思路是在项目进行需求分析阶段，测试人员便开始进行测试需求分析的整理，随着项目的进程发展，测试人员依据项目背景材料、项目行业业务知识、软件需求、软件设计不断完善测试需求，并以此测试需求为蓝本，整理出不同测试阶段的测试需求。如果可能，我们要在项目的进程中，肩负起检查需求和设计的重任，对软件需求进行检查，主要是检查两方面：1.需求的正确性，不迷信所谓的“都是用户提出的真实的需求”。作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解的；2.需求的可测试性，就是要保证所有的需要实现的需求在最终实现后，都可以用某种方法来明确的判断是否符合需求文档中的要求。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充――我们有理由相信，如果作为测试人员对需求无法产生准确的理解，那么开发人员也同样无法对同一条需求产生准确的理解。对软件设计的检查，主要是检查设计同软件需求的一致性，只有同需求中已经定义的部分相符的内容，才可以影响到我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，明确以哪一方作为基准，决定是调整软件需求，还是修改软件设计，最后对测试需求进行相应的增补或者调整。
二、对于测试人员不参与到实际项目中，只是接收某软件项目的软件产品执行测试时，测试类型有：登记测试、成果鉴定测试、确认测试和验收测试，可以将测试需求按照这几种测试类型，分为登记测试测试需求、成果鉴定测试测试需求、确认测试测试需求和验收测试测试需求。这类项目，我们的测试工作目标比较明确，参考资料也比较确定，就是委托测试方提交给我们的任何相关资料，测试过程中极少出现参考资料变更的情况。我们进行测试需求分析的思路是依照参考资料和测试类型，直接整理出高覆盖度的测试需求，指导后续的测试工作。
4.抽象：
对于测试需求，我们认为是从软件需求（系统需求）中分析得出，测试需求可以直接指导测试用例的设计。由于目前接触到的软件大部分都是比较复杂的，所以对于软件需求（系统需求）的分析以及对测试需求的分析，我们需要识别出其中的不同重要程度、不同优先级、不同工作量的需求项（软件需求项和测试需求项）。据此，软件需求和测试需求的模板如下（为方便编辑，最好是用excel）：（根据项目实际情况在下表格中添加体现系统层次关系的列）
表1 软件需求（系统需求）模板
版本号：
编号 需求名称 需求描述 重要性 优先级 工作量 追踪关系
数据项说明：【编号】一项随着记录数的增加从SRS1开始尾数按照自然数递增；【需求名称】一项标识需求项的名称，一般是功能的名称，也有可能是软件质量要求中的一些要求；【需求描述】一项要求对该项需求有一个详细的描述，描述清楚该项需求是想要完成什么功能或者想要达到什么要求；【重要性】一项标识该需求项的重要程度，取值为以下4个值中选其一：“核心级”、“重要级”、“一般级”、“建议（可选）级”。这4种取值的依据为：（1）核心级，针对于必不可少的功能需求、非功能需求及核心的业务流程的需求，这里面如果有未达到要求的项，用户不应该签字允许系统上线；（2）重要级，针对于关键的功能需求、重要的非功能需求及重要的业务流程的需求，这里面如果有未达到要求的项，则产品版本就不得发布；（3）一般级，对于一些为特定用户或业务需求而设的系统功能，由于这些系统功能使用频率相对较低，或者这些系统功能可以由其它的方法实现其替代功能，因而即使发布版中并未包括这些功能，也不会对收入或客户满意度造成太大的影响。针对于这些系统功能的需求称之为一般性需求。这些需求是否达到要求将不影响产品的发布；（4）建议级，针对于不重要的需求，如果受资源或时间的约束，在预定的产品发布时间，有可能不能完成对这些系统功能的需求，则这些系统功能的需求被定义为建议（可选）的；【优先级】一项只在公司内部项目分析时填写，用来标识需求项实现的先后顺序，这个主要是看软件项目的具体规划了，哪些先实现，哪些后实现，取值为以下3个值中任选其一：“高”、“中”、“低”；【工作量】一项只在公司内部项目分析时填写，用来标识需求项实现所花费的工作量的多少，该值是一个权重值，采用百分制。整个软件需求中工作量最大的为100，最小的为10，以10为增量进制；【追踪关系】一项用来标识该条软件需求分析出来的参考资料，及在参考资料中的具体位置（具体章节），如整份软件需求的参考资料只有一份，在此只写出依据该资料的具体位置即可；【版本号】一项用来标识当前软件需求表格的版本信息。
注：软件需求的粒度建议到软件的有效功能一级。有效功能是指在被测应用所涉及的实际业务中，当用户在原始状态下进行工作时，整个业务流程中对用户来说，具有实际意义那些功能。
表2 测试需求模板
版本号：
编号 测试需求描述 重要性 优先级 工作量 依据 适用阶段
数据项说明：【编号】一项随着记录数的增加从TRS1开始尾数按照自然数递增；【测试需求描述】一项要求对该项测试需求有一个详细的描述，描述清楚该项需求是想要测试什么；【重要性】一项标识该测试需求项的重要程度，取值为以下4个值中选其一：“核心级”、“重要级”、“一般级”、“建议（可选）级”。这4种取值的依据为：（1）核心级，针对于必不可少的功能需求、非功能需求及核心的业务流程的测试需求，这里面如果有测试不通过的，用户不应该签字允许系统上线；（2）重要级，针对于关键的功能需求、重要的非功能需求及重要的业务流程的测试需求，这里面如果有测试不通过的，则产品版本就不得发布；（3）一般级，对于一些为特定用户或业务需求而设的系统功能，由于这些系统功能使用频率相对较低，或者这些系统功能可以由其它的方法实现其替代功能，因而即使发布版中并未包括这些功能，也不会对收入或客户满意度造成太大的影响。针对于这些系统功能的测试需求称之为一般性测试需求。这些测试需求是否通过测试将不影响产品的发布；（4）建议级，针对于不重要的测试需求，如果受资源或时间的约束，在预定的产品发布时间，有可能不能完成对这些系统功能的验证，则这些系统功能的测试需求被定义为可选（建议）的；【优先级】一项用来标识测试需求项需要被执行的先后顺序，取值为以下3个值中任选其一：“高”、“中”、“低”；【工作量】一项用来标识执行该测试需求项所需花费的工作量的多少，该值是一个权重值，采用百分制。整个测试需求中工作量最大的为100，最小的为10，以10为增量进制；【追踪关系】一项用来标识该条测试需求分析出来所参考软件需求项，写出所参考的软件需求的版本及需求项的编号；【版本号】一项用来标识当前测试需求表格的版本信息；【适用阶段】一项只在公司内部项目分析时填写，用来标识该项测试可以用于什么测试阶段，测试阶段包括：“单元测试”、“集成测试”、“系统确认测试”、“验收测试”，该项的取值可以是多选。
注：测试需求的粒度建议写到功能的不同情况。
作者：mmm
邮箱：mmm369225@163.com
QQ:378284201 :victory: 呵呵，谢谢版主捧场哈:) 喜欢楼主的这种工作态度
:hug: 哈哈，干一行爱一行
页:
[1]
