1.前言

　1.1 什么是测试需求？

　　确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where），测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
　　就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。

　　1.2 为什么要做测试需求？

　　如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。
　　测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
　　如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把“软件”两个字全部替换成了“测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。

2.测试需求分析方法

2.1 测试需求分析依据

　　通常是以被测产品的需求为原型进行分析转变而来，测试需求主要通过以下途径来进行收集：
　　与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。
　　与客户或系统分析员的沟通。
　　业务背景资料。如待测软件业务领域的知识等。
　　正式与非正式的培训。
　　其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。

　　2.2 测试需求架构划分

　　测试需求分析应首先进行测试需求架构划分并先进行评审，通过后才进行后续的测试需求展开分析，从产品整体上考虑有哪些功能、测试类型需要进行分析，列出测试特性列表，也方便下一步展开具体分析。
　　首先，这里需要对功能进行一下定义以达成共识，功能是指能独立实现一个基本业务处理要求，为了降低测试需求设计的复杂性及依赖性，测试需求架构罗列的功能是指最小功能点，即不可再继续分解。
　　(1)应用程序：
　　A.一般是最底层的菜单项为最小功能点，若最底层的菜单项不能体现一个独立的业务流程时，可采用上一层
　　的菜单项为最小功能点。
　　B. 还有某些比较特殊没有体现在菜单项的功能也需要作为最小功能点考虑，如POS应用程序中交易的冲正功能
　　等。
　　(2)驱动：一般是以一个API为最小功能点。
　　然后，再考虑产品实际用户使用的场合及用户特点考虑哪些测试类型，如故障及恢复、功能集成、性能要求、安装测试、软硬件兼容性等，此处需要从产品层面考虑，而不是从功能点层面考虑。

2.3 测试需求分析过程

　　2.3.1 测试需求收集

　　测试需求的收集主要通过对测试依据进行分析整理，最后生成一个以测试的观点出发的checklist（检查表），用来作为测试该软件的主要工作内容。检查表的检查要点包括需求的正确性、必要性、优先级、明确性、可测性、完整性、一致性、可修改性：
　　在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。

2.3.1.1 测试类型划分

　　根据测试需求收集获得的checklist(检查表)，对每一条测试需求，从GB/T16260.1定义的软件质量子特性角度出发，确定所对应的质量子特性。即，从适用性、准确性、互操作性、保密安全性、成熟性、容错性、易恢复性、易理解性、易学性、以操作性、吸引性、时间特性、资源利用性、易分析性、易改变性、稳定性、易测试性、适应性、易安装性、共存性、易替换性和依从性方面的定义出发，确定每一条测试需求所对应的质量子特性。从而对这些质量子特性进行测试类型划分，如：功能测试、易用性测试（安装测试、功能易用性测试、用户界面测试、辅助系统测试）、兼容性测试、可靠性测试、文档测试、性能测试，强度测试等。

　　2.3.1.2 测试类型细化

　　对划分的每个测试类型进行细化。软件测试需求是开发测试用例的依据，测试需求分解得越详细精准，表明对软件的了解越深，对所有要进行的任务就越清晰，对测试用例的设计质量的帮助也越大，详细的测试需求还是衡量测试覆盖度的重要指标，测试需求是计算测试覆盖的分母，没有详细的测试需求就无法有效的进行软件测试覆盖计算。最好达到细化的结果是分支的最末端（测试项）针对的测试目的是单一的最小的功能点的测试，即每个测试项为一个测试功能点。

　　2.3.1.3 生成测试需求树

　　已细化的测试需求中，由于在提取时，可能存在着重复或冗余，需要进行删除和合并需求。删除测试需求中存在的重复的、冗余的含有关系的测试项。如果有类似的测试项，则需要对其进行合并。最终生成测试需求树。

　　2.3.2 测试风险分析

　　由于软件的输入、输出、处理存在一定的限制和约束，另一方面由于测试树中进行了必要的删除和合并，这导致测试需求不可能是全面的覆盖，从而形成了一定的测试风险。测试需求中必须对不分析或不测试部分给出相应的风险分析说明。
　

3.总结

　　以上主要描述了测试需求相关理论和获得测试需求树的一般过程。为具体项目实施测试中提供了一套获取测试需求树的参考方案。实际的测试类型划分和测试需求树生成的形式或粒度，因项目而不同，需灵活应用。

1.前言


　1.1 什么是测试需求？


　　确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where），测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
　　就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。

　　1.2 为什么要做测试需求？


　　如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。
　　测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
　　如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把“软件”两个字全部替换成了“测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。

2.测试需求分析方法

 

  2.1 测试需求分析依据


　　通常是以被测产品的需求为原型进行分析转变而来，测试需求主要通过以下途径来进行收集：
　　与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。
　　与客户或系统分析员的沟通。
　　业务背景资料。如待测软件业务领域的知识等。
　　正式与非正式的培训。
　　其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。

　　2.2 测试需求架构划分


　　测试需求分析应首先进行测试需求架构划分并先进行评审，通过后才进行后续的测试需求展开分析，从产品整体上考虑有哪些功能、测试类型需要进行分析，列出测试特性列表，也方便下一步展开具体分析。
　　首先，这里需要对功能进行一下定义以达成共识，功能是指能独立实现一个基本业务处理要求，为了降低测试需求设计的复杂性及依赖性，测试需求架构罗列的功能是指最小功能点，即不可再继续分解。
　　(1)应用程序：
　　A.一般是最底层的菜单项为最小功能点，若最底层的菜单项不能体现一个独立的业务流程时，可采用上一层
　　的菜单项为最小功能点。
　　B. 还有某些比较特殊没有体现在菜单项的功能也需要作为最小功能点考虑，如POS应用程序中交易的冲正功能
　　等。
　　(2)驱动：一般是以一个API为最小功能点。
　　然后，再考虑产品实际用户使用的场合及用户特点考虑哪些测试类型，如故障及恢复、功能集成、性能要求、安装测试、软硬件兼容性等，此处需要从产品层面考虑，而不是从功能点层面考虑。

2.3 测试需求分析过程


　　2.3.1 测试需求收集


　　测试需求的收集主要通过对测试依据进行分析整理，最后生成一个以测试的观点出发的checklist（检查表），用来作为测试该软件的主要工作内容。检查表的检查要点包括需求的正确性、必要性、优先级、明确性、可测性、完整性、一致性、可修改性：
　　在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。

  2.3.1.1 测试类型划分


　　根据测试需求收集获得的checklist(检查表)，对每一条测试需求，从GB/T16260.1定义的软件质量子特性角度出发，确定所对应的质量子特性。即，从适用性、准确性、互操作性、保密安全性、成熟性、容错性、易恢复性、易理解性、易学性、以操作性、吸引性、时间特性、资源利用性、易分析性、易改变性、稳定性、易测试性、适应性、易安装性、共存性、易替换性和依从性方面的定义出发，确定每一条测试需求所对应的质量子特性。从而对这些质量子特性进行测试类型划分，如：功能测试、易用性测试（安装测试、功能易用性测试、用户界面测试、辅助系统测试）、兼容性测试、可靠性测试、文档测试、性能测试，强度测试等。

　　2.3.1.2 测试类型细化


　　对划分的每个测试类型进行细化。软件测试需求是开发测试用例的依据，测试需求分解得越详细精准，表明对软件的了解越深，对所有要进行的任务就越清晰，对测试用例的设计质量的帮助也越大，详细的测试需求还是衡量测试覆盖度的重要指标，测试需求是计算测试覆盖的分母，没有详细的测试需求就无法有效的进行软件测试覆盖计算。最好达到细化的结果是分支的最末端（测试项）针对的测试目的是单一的最小的功能点的测试，即每个测试项为一个测试功能点。

　　2.3.1.3 生成测试需求树


　　已细化的测试需求中，由于在提取时，可能存在着重复或冗余，需要进行删除和合并需求。删除测试需求中存在的重复的、冗余的含有关系的测试项。如果有类似的测试项，则需要对其进行合并。最终生成测试需求树。

　　2.3.2 测试风险分析


　　由于软件的输入、输出、处理存在一定的限制和约束，另一方面由于测试树中进行了必要的删除和合并，这导致测试需求不可能是全面的覆盖，从而形成了一定的测试风险。测试需求中必须对不分析或不测试部分给出相应的风险分析说明。
　

3.总结

　　以上主要描述了测试需求相关理论和获得测试需求树的一般过程。为具体项目实施测试中提供了一套获取测试需求树的参考方案。实际的测试类型划分和测试需求树生成的形式或粒度，因项目而不同，需灵活应用。

软件测试需求分析方法相关推荐

  1. 软件测试需求分析方法有哪些，一起来看看吧

    目录 1.前言 1.1 什么是测试需求? 1.2 为什么要做测试需求? 2.测试需求分析方法 2.1 测试需求分析依据 2.2 测试需求架构划分 2.3 测试需求分析过程 3.总结 1.前言 1.1 ...

  2. 【转】软件需求分析方法

    软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的.可验证的一个基本依据. 软件需 ...

  3. 软件测试需求分析与跟踪

    软件测试需求分析与跟踪 软件需求 软件需求是(1)用户解决问题或达到目标所需条件或权能(Capability). (2)系统或系统部件要满足合同.标准.规范或其它正式规定文档所需具有的条件或权能. ( ...

  4. 需求分析的过程是什么?_7大需求分析方法与5大分析过程

    面对业务部门层出不穷的需求,如何入手进行需求分析?有没有需求分析的标准方法论可供参考?以下就是为大家推荐的8大类需求分析方法: 流程图 原型 用例图 用户故事(3C原则) 词汇表 实体关系图ERD 分 ...

  5. 如何进行软件测试需求分析

    如何进行软件测试需求分析 1.项目经理会根据前期调研的情况进行需求整理,召开项目组会议讨论需求整理的内容,如果是大项目的话,请一些有经验的专家来参与讨论.讨论的范围:用户提出的需求哪些是可以通过技术完 ...

  6. 面向对象的需求分析方法

    面向对象的需求分析方法 面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型.它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学. 面向对象的思想最初起源于 20世 ...

  7. 软件测试需求分析录音,谈一谈软件测试需求分析

    在软件测试过程中我们首先要做的就是分析测试需求,一般都是由客户方给出,测试需求应该全部覆盖已定义的业务流程,以及功能和非功能方面的需求.分析软件测试需求是一个不可或缺的步骤,因为它有利于保证测试的质量 ...

  8. 常见的需求分析方法（产品篇）

    需求分析方法 常见的需求分析方法有: 一.如何做结构化分析 二.如何做系统建模 三.需求加法 四.需求减法 总结 常见的需求分析方法有: 1. 结构化分析 2. 系统建模 3. 需求加法 4. 需求减 ...

  9. 软件测试基本方法介绍

    来源: http://oldchild.nbc.net.cn/jsjsj/spks/cps/rjcsff.htm 软件测试的方法和技术是多种多样的. 对于软件测试技术,可以从不同的角度加以分类: 从是 ...

  10. 设计需求分析方法与过程

    需求分析方法简介 1.分析业务需求: 业务需求=业务目的+业务目标 以注册功能为例,用户肯定不想注册填一堆信息这么麻烦,而是产品需要用户注册. 分析业务目的和目标 将业务目标转化为用户行为 2.分析用 ...

最新文章

  1. 如何避免死锁，我们有什么套路可循？
  2. java中isclosed_java.sql.SQLException: Conntion is closed.解决方法
  3. GDCM：gdcm::IOD的测试程序
  4. Laravel-admin 分类避免踩坑
  5. 机器学习算法（1）——贝叶斯估计与极大似然估计与EM算法之间的联系
  6. 实战OO设计——类的关系：依赖、关联、聚合和组合
  7. 企业无线网演进 2.4GHz或被5GHz频段取代
  8. python比较两个文件内容是否一样_python判断两个json文件是否相等
  9. ecs云服务器 mysql经常自动停止挂掉重启问题分析
  10. html中免费的四级联动,四级联动.html
  11. 计算机图形学流体仿真mac网格,正交网格下不可压缩流体的图形学模拟
  12. C++封装dll供C#调用获取U盘/磁盘序列号信息
  13. 艺赛旗（RPA）【服务端】修改服务器访问端口
  14. 【复试笔记】市政工程-流体力学
  15. 第七章Linux 系统——存储管理高级课程
  16. YSP的UI界面设计
  17. 小花梨的字符串 ——java 美登杯
  18. 市值破7000亿美元 贝索斯成全球新首富，成就亚马逊的正是人工智能
  19. 【大厂面试】三面三问Spring循环依赖，请一定要把这篇看完（建议收藏）
  20. 针对“PL2303HXA自2012已停产，请联系供货商”问题的解决办法

热门文章

  1. 编程实现恩格玛加密机(C++)
  2. 在线广告结算方式及对比
  3. 推荐系统系列——经典推荐算法
  4. Mutual Component Convolutional Neural Networks for Heterogeneous Face Recognition阅读笔记
  5. 将python 脚本转换为exe格式
  6. 人工智能：神经网络与深度学习
  7. 内网渗透-信息收集整合
  8. 慢就是快的人生哲理_快和慢人生感悟
  9. 数据分析师岗位 分析可视化
  10. SATA,SAS,SSD 读写性能测试结果