测试策略设计四：基于需求的测试策略

    基于需求的测试策略是我们最常用的测试策略，其实也是我们最常用的流程：分析需求、列测试点、用测试设计方法进行用例设计，这里重点说自己做需求分析上的一点经验。

    测试人员做需求分析的目的是解决我们要测什么的问题，一般分为两部分，一是功能需求，即产品必须具备的功能特性，以满足用户的基本使用需求；包括界面、按钮、数据、流程等。二是非功能需求，即指定软件或系统应具备的属性或质量，而不是具体的操作或功能；包括系统性能、安全性、可用性、可维护性等方面的要求。

一.前置工作：

      分析的前置工作是要理解用户的实际需求，主要通过需求文档、PO沟通、老系统体验、一线交流、网上搜索相关的业务制度规则的等几个方式

二.分析的方法：

      1.需求分析的五个步骤：

        检：就是检查需求规范包括背景、功能、影响点、验收标准、原型；找就是找出有歧义、有问题、有遗漏的地方；

        找：就是找出有歧义、有问题、有遗漏的地方；

        问：就是对找出来的地方刨根问底；

        画：就是可以画一下图，辅助发现测试点；

        列：这项是比较重要的，要列策略范围和测试点；

      画图的方法：

        第一步：基于需求标准业务建模，设计主体活动的并联关系；一般需求文档都会给出一个基础的业务流程，我们把它拿出来做主流程建模。

        第二步：找出分支活动业务类型，每种类型的特征，将业务分支进行特征拆分。比如考察打分这个业务类型，下面的业务特性有单人打分、多人打分、不同组织打分等业务特性。

        第三步：确定业务特征涉及到的功能点有哪些，梳理清楚功能点类别。例如打分的功能点，有编辑、提交、退回、修改、转交等

        第四步：根据功能点叠加判断条件生成整体的场景图。例如单人打分后提交-退回-再编辑-再提交-审批通过等，

        图中若干个开始结点和结束结点，从每个开始结点到每个结束结点间的所有路径，就是所有可能的用户真实场景。这样就可以保证复杂业务流程的覆盖、达到易理解、易评审、易维护的目的。并且后期的场景用例可以按图生成，减少人工设计成本。而且符合敏捷开发模式，通过一次次迭代来新增特性和完善功能，从业务流程图上来看，就是结点逐渐增多，用户路径逐渐丰富。相比不断堆积测试用例维护测试点的方式，更为高效、简洁、直观，对于项目成员也更有参考价值。

      列策略范围和测试点的方法：

        当我们做分析时，要思考哪些需求需要用到测试策略，类似打仗一样，一个需求就是一个堡垒，有些需求实现复杂，影响广，就好像有重兵把守，需要设计策略、方法突破；有些简单需求比如bug衍生的需求、小优化等，读完就能识别到怎么充分覆盖，就不需要详细的策略设计；我们可以从复杂程度、工作量大小、测试的深度和广度去衡量需不需要做策略。再就是测试点，测试点可以从三个方面提炼，单功能测试点、关联关系测试点以及业务流程测试点；可能会认为即使从这三个点来分析，测试点也有很多，所以就要我们做取舍，有个简单方法，把需求分析完后，过滤掉你比较清晰的测试点，因为这部分已经有底，即使有遗漏，在后面的用例设计还有一层把关；留下比较模糊、拿捏不定的测试点，这些点就是测试设计的重点。