这篇博文意在归纳分享课笔记，从功能性出发来了解基于脑图的需求分析和用例分析。
常规测试设计
（一）常规测试用例的特点
1.为了让不同的测试人员按照具体的操作步骤来进行测试，测试用例里面写死了数据、业务步骤
2.负责第一次编写测试用例的测试人员可能有思考，但是负责执行的测试人员就没有再继续跟开发交互测试
3.遇到业务流程繁杂时，即有十几个、甚至几十个步骤的功能，用例编写耗时
4.无用的机械步骤太多，太冗余
5.用例与需求的对接关系不太容易进行
6.用例的后期修改、完善、维护成本较高
（二）传统的测试用例设计、编写的痛点
1.在大型的信息系统产品、快节奏的迭代项目和敏捷项目，甚至是耦合度高的产品中，传统的用例编写方法明显表现为滞后
2.测试的设计人员过度关注于测试用例步骤的编写、修改，甚至是再修改，由此带来了较多冗余的工作量
3.由于测试用例的编写还要根据现有的设计原则保证其唯一性和可追溯性，导致同一条用例经过多人执行后永远得到相同的结果，严重阻碍了测试执行人员或相关人员的创新意识
4.根据测试用例的定义及其六要素的内容，测试项目在高强度快速的迭代中，由于每次迭代设计编写的测试用例包含了所有的测试要素，一旦项目有任何的变更，测试步骤必须要重新的修改和完善
（三）对业务已经烂透的我们，在测试时真正需要关注的
1.开发人员是否做了正确的功能
2.开发的功能是否做了正确的事情
3.做的事情是否达到了预期的效果
Tips：由于测试人员的时间是有限的，不要过分探究步骤的细节，而是把重点的思路放在运用哪些测试方法，和如何组合更加有效的覆盖率和更高的测试场景中
脑图测试设计
（一）基于脑图的测试设计的优势：
1.用脑图的方式可以让不同的人按照一定的思维方式设计的测试用例或执行的测试用例，其覆盖率更高
2.在整个测试过程中引入脑图，能够在很大程度上提高测试人员对于需求和产品的学习和理解能力
3.通过脑图进行测试分析和产品的测试分析，其分析结果具有很强的条理性，并在一定程度上增强测试人员对产品理解的深度和整体的把控能力
（二）基于脑图的测试设计和分析：
需求分析
（1）明确需求
软件的明确需求，其参考的指标可能主要是一些软件开发的合同、项目开发的计划、系统或者子系统的设计文档、软件需求规格和说明书，当然还可能包括接口需求规格说明、用户的需求说明书和软件设计说明，还包括一些继承的其他需求。
（2）继承需求
软件的继承需求，其参考的指标是相关产品或者上一个版本的软件需求规格说明书、相关产品或者是上一个版本的测试需求或者是测试报告，还有就是在使用过程中遇到并且需要解决的一些问题的汇总。简单举个例子，比如说阅时即购App的商家商品库页面，旧版需求是红人店已成功推广的商品需要先下架该商品才能删除，而新版需求已没有了红人店商品申请推广的功能，导致了新版App已上架的部分商品进行删除时接口返回“不能删除已推广的商品”。再举个例子，还是阅时即购App的商品库页面，旧版需求是只要是认证会员都有发布商品的功能，而新版的需求是只有商家才具有发布商品的功能即非商家的付费会员只有编辑分销商品的功能，导致了新版的商家用户使用App发生了发布商品失败的问题。
（3）隐含需求
软件的隐含需求，其参考的指标可能主要是产品的使用场景的一些数据的梳理，或者该产品或该项目在相关的一些行业的标准，还有一些非专业人士可能不清楚的且没有写到软件需求里面的内容，比如说六性要求、稳定性要求这样的一些性能要求。主要是对需要有丰富经验的测试设计人员的思考，即测试人员需要对这个项目或者产品非常的熟悉，甚至该产品所属的行业精细明了。
模块用例的分析
举例：功能性测试-子功能
1.风险识别
（1）任何项目都会有风险，我们需要提前想到各种可能会发生的风险，然后想办法去识别、解决或者避免他
（2）若没有识别的风险，也应该保留该子项用作警示，时刻提醒测试人员要有风险意识
2.目标和要素
（1）填写本子功能要达到的目标或者是要实现的效果，或者是为了达到目标而要解决的问题以及前提条件
（2）若本子功能由多个更小的模块组成，则需要填写各模块的情况
3.测试要点
（1）页面元素测试：遍历本模块UI功能响应情况
（2）测试描述：即我们要验证什么？要做什么？目标是什么？
①填写测试项所采用的的测试方法，如基本的边界值或者等价类等设计方法
②填写该模块正常执行和异常执行的结果反馈
4.业务场景
目的：尽可能设计少的业务场景，把本功能所有的功能点都贯穿进去，保证基本的业务流程是可以正常使用的。
5.业务总场景
目的：把测试产品的整个业务线连起来做一次较全面的测试，场景的数量要尽量少但是还是要精练，要把各个的要素、节点都包含进去。
（三）脑图设计时机的问题
1.从项目开始阶段介入，参与需求分析、记录需求要点
2.项目过程中，明确与模糊的需求点都记录到脑图中
3.全程软件测试中，不断完善需求与用例设计
4.真正与项目组互动起来，讨论测试功能点、测试场景及数据准备
（四）哪些情况不推荐使用本方法做用例分析
1.对业务不熟悉的人，建议不要使用本方法
2.团队及主管没有耐心，该方法需要积累才有效果，需要不断的探索、补充
3.外包测试，需要详细的测试用例，建议不适用本方法
4.项目管理流程不清晰，建议不要使用本方法
（五）重要说明
抱着通过思维导图设计能够把需求覆盖到百分之百、场景覆盖到百分之百，甚至bug为零。经过验证，测试其实永远达不到以上这三个目标，不光是使用思维导图达不到，用任何方式都不可能把bug消灭为零，我们的目标只能是尽量趋近于这个目标。
