王工
前端销售又再次完美签单，真是要为大业务部鼓掌~~~
小李
鸭梨山大啊，我们又要通宵加班了呢！
王工
有压力才有动力啊，作为助理今天我们就来啃啃软件测试这块骨头
小李
好的王工，论软件测试需求的确你可是资深呢~学习学习
说到软件测试，测试需求就变得尤为重要，而想要明确测试需求，却并非易事，常常会带给测试人员各式的烦恼：
· 用户需求太多，想要按时按期完成太难；
· 基于每个人的测试能力和测试经验不同，其对于需求的理解也会不一致，因此测试出来的产品跟用户需求能不能匹配也要打个问号；
· 用户的需求处于永恒的变动状态中，不能固定；
测试人员在说起上述情况时，总是心悸难平，要随时应付因为需求理解有误或者变更带来的返工、推翻重来等，最终耗时耗力。斑斑血泪史，也使的我们测试成员不得不静下心来思考一下需求管理的情况。
对于需求而言，从获取阶段开始，就一直贯穿于整个项目周期之中，因此我们将按照项目进展阶段的方式来进行思考。所谓，我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等。以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不等同于软件需求，它是以测试的观点根据软件需求整理出一个checklist，作为测试该软 件的主要工作内容。
测试需求主要通过以下途径来收集：
与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。
与客户或系统分析员的沟通。
业务背景资料。如待测软件业务领域的知识等。
正式与非正式的培训。
其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。
在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。
任何一个项目都会有一定的业务流，也就是用户用该项目来实现自己实际业务的一个流程。简单的来说，在做测试需求分析时需要列出以下类别：
常用的或规定的业务流程
各业务流程分支的遍历
明确规定不可使用的业务流程
没有明确规定但是应该不可以执行的业务流程
其他异常或不符合规定的操作
然后根据项目需求理出业务的常规逻辑，按照以上类别提出的思路，一项一项列出各种可能的测试场景，同时借助于项目的需求以及其他信息，来确定该场景应该导致的结果，便形成了项目业务流的基本测试需求。
在做完以上步骤之后，将业务流中涉及的各种结果以及中间流程分支回顾一遍，确定是否还有其他场景可能导致这些结果，以及各中间流程之间的交互可能产生的新的流程，从而进一步补充与完善测试需求。而我们在不断摸索过程中，发现多年以前日本品管大师狩野纪昭提出的卡诺模型也叫做狩野模型（Kano Model），可以在一定程度上帮助我们缓解需求确认的这个难题。
卡诺模型的核心是将产品品质分为五个部分：
Ø 无差异品质（Indifference）：无论提供或不提供此品质，用户满意度不会改变，换句话说，这种品质用户根本不在意甚至不会用；这种品质是产品设计中需要尽力避免的。
Ø 魅力品质（Attractive）：用户想象不到的品质，如果不提供此品质，不会降低用户的满意度，一旦提供魅力品质，用户满意度会大幅提升。
Ø 一维品质（One-dimensional）：一维品质又称为线性品质，若品质好，客户满意度高，反之，品质差客户便给予负面评价。
Ø 必要品质（Must-be）：这是产品的基本要求，无论必要品质如何提升，客户都会有满意度的上限，但不提供此需求，用户满意度会大幅降低。
Ø 反向品质(Reverse)：用户根本都没有此需求，提供后用户满意度反而会下降。
