看完这篇文章，才发现我的测试用例写的就是垃圾
测试用例编写作为测试技能最基础的一个能力，大家应该或多或少都有自己写用例的习惯和思考方式，这里分享一些需求分析和编写用例的经验，主要针对功能测试，旨在尽量降低测试遗漏的可能性，而对于新同学来说，则希望可以达到入门的效果。最后会分享一个小工具，梳理一些比较复杂的业务需求时，可以协助做快速的分析。
01、如何拆解需求
一个需求的提出必然伴随着对现有系统优化的期望，一般来说有这几种类型：
新增功能以满足业务发展需要
功能优化，旨在改进存在的不足及影响业务发展的细节
满足监管部门政策
系统层级优化，不涉及业务层面，可能是SQL优化、代码重构等等
线上问题
接口，包括其他系统提供的以及自身提供给其他系统
定时任务，异步任务
对于不同类型的需求，我们的应对方式也会有差异，下面每一个点都会以这几种类型为前提逐一讲解。
1、新增功能
一般来说，此类功能会尽量避免影响原有功能，所以关联影响系数在几种类型中是最低的，可遵循以下思路进行拆解：
了解需求产生的背景，快速浏览需求，理清包含的菜单、模块、页面以及页面控件；
理清业务逻辑及数据录入控制；
根据需求的特点来大致划分测试用例/测试点的测试规格，一般可能有这几种：流程、页面/控件操作、数据展示、计算逻辑、易用性、兼容性等。
2、功能优化
此类功能的关联影响系数较高，除了从需求层面进行分析，开发设计也是辅助测试用例设计的关键。
了解需求产生的背景，理清优化点；
测试根据自身对系统的了解，或者系统文档等资料，初步对比变更前后的差异，并列举出来；
与开发沟通开发设计思路，理解代码、数据库层面的改动点，评估可能的影响点，并列举出来；
根据以上测试重点，划分测试特性。
3、满足监管部门政策
这类需求一般会比较紧急，大概率可能是上传数据或者逻辑控制之类的功能点，分析需求时侧重数据方面验证。
了解需求产生的背景，理清优化点；
根据需求列举数据类型、监管控制触发时点等；
自己分析，或与开发沟通是否存在关联影响，若存在则依照“功能优化”类需求继续分析；
根据以上测试重点，划分测试特性。
4、系统层级优化
这类需求由开发提出，一般为了提升代码执行效率、提高代码可复用性、降低代码复杂度等，会对现有功能产生关联影响。
与开发沟通优化方案，一定要了解清楚修改的前因后果，有任何不清楚的概念要打破砂锅问到底，因为任何一个疑问点都可能影响后续的用例设计；
确认验证方式，可能会通过页面功能遍历、SQL执行效率、页面响应时间等来验证；
根据1）分析优化到哪些功能，是单纯效率上的提升，还是也影响了原有功能的实现方式，若为后者，可能需要遍历该功能，依照“新增功能”类需求继续分析；
根据以上测试重点，划分测试特性。
5、线上问题
线上问题大致可分为紧急和一般两种级别
① 紧急级别对业务已经产生了阻断，需要通过数据修改、配置修改、少量代码修改当天上线
② 一般级别则是对业务暂时没有阻断影响，并且可能尚未分析到具体原因，不会在当天修复上线。
迅速找到问题对接人了解现象及操作步骤，并在测试环境进行重现；
若能重现且为近期上线功能引起的，需首先分析测试遗漏原因，若为历史问题，则需了解该问题被触发的原因及开发代码分析结果；若不能重现，则极大可能为配置及数据问题，非测试遗漏；
若进行了代码改动修复，则依照“功能优化”类需求继续分析，一般代码改动量很少，但此类情况下测试时间可能很少，需准确定位到代码改动点缩小测试范围。
6、接口
这种类型一般更偏重于数据组合的验证，界面上的测试比重较低，所以测试规格的划分会比较格式化。
了解需求产生的背景，理清优化点；
根据接口文档列举出入参组合情况；
确定接口调用频率，频率较高的话可能还存在其他潜在的测试需求；
确定数据是否落地（存入本地数据库），若是，则需列举落地的字段及数据处理方式，如插入、更新、删除情况下分别的处理方式；
确定数据是否用于页面展示，若是，则需列举展示的字段及展示形式；
确定接口是否用于触发另一功能的入口，若是，则需列举接口调用点，并列举接口数据与另一功能的关联关系；
根据以上测试重点，划分测试特性。
7、定时任务/异步任务
这类跟接口有点类似，一般不会存在于需求文档里面，而是在开发设计的时候实现需求的一种方式。一般会处理大批量的数据，并且调用频率没有接口那么高，这两种任务一般是为了降低系统即时处理数据的负担
了解任务处理过程中数据流向，是否有中间表，以及数据落地情况
任务触发时点
状态回写及重试机制
02、如何组合测试点和数据
了解需求类型并且写下了测试规格、测试点之后，需要进一步细化为测试用例，这时候可能会用到很多大家听过的方法，比如等价类、边界值、异常值、组合等等。大家应该发现了，这些方法其实都是协助筛选数据，把用例的数量控制在合理范围的手段。在一个版本的快速迭代中，测试时间很宝贵，我们不太可能无限制地设计测试用例进行全覆盖，因此我们需要对测试点和数据进行有效组合，将一个大的测试集转换成一个较小的测试集。
以最常见的用户登录系统作为例子：
1、对于登录操作来说
测试特性有：用户名输入，密码输入，登录
测试数据有：
已存在的用户，不存在的用户，包含特殊字符的用户；
与用户匹配的密码，
与用户不匹配的密码，包含特殊字符的密码。
登录作为预期结果的触发点
取值有：登录成功，用户名或密码不正确。
2、第一步梳理出来的测试特性和数据，如果进行全组合，会有18个测试用例，该功能只考虑功能测试的情况下，这样的用例数量太多了。试想下如果再增加输入框，用例数会成倍的增长，日常测试中功能逻辑比这个例子复杂的是绝大多数情况，这时候我们需要精简，用最少的用例达到尽量多的测试覆盖。
3、首先我们可以发现里面有一些组合是无效用例，比如“不存在的用户，与用户不匹配的密码，登录成功”这样的是无效的；第二，有一些组合可划分为等价类，即虽然特性取值不一样，但是达到的测试目的是一样的，比如“不存在的用户，与用户不匹配的密码，用户或密码不正确”、“不存在的用户，与用户匹配的密码，用户或密码不正确”，目的其实都是测试用户不存在的情况，可以进行用例精简。
4、至此，我们可以得到一份比较合理的测试用例文档，但是需要注意的是，我们精简用例的同时，必须保证测试路径的覆盖，涉及到的改动点是必须测试到的，上面的精简过程只是删减了对改动点进行了重复测试的部分。
03、确定测试方法
测试用例确定下来之后，还有一个重要的部分，测试方法的确定，包括执行方法和数据准备。日常测试中，比较普遍的方法是进行手工测试，但是有些情况下，通过手工测试来执行用例会相当耗时，在快速迭代过程中，会影响到测试进度。在执行阶段，比较常用的还有：接口测试、白盒测试、数据库脚本等。
1、接口测试适用于明确定义为接口的需求，以及提供了暴露到外部的service服务，尤其适用于组合情况非常多的测试用例，单纯的手工测试可能会涉及长时间的关联系统联调、页面流程遍历，而通过接口测试来覆盖，则可以在短时间内遍历完这些用例组合，快速发现逻辑层面的BUG，最后仅需要在联调、页面测试环节执行少数用例即可。
2、白盒测试一般来说用于开发环节比较多，但是在快速迭代的项目中，经常会出现后台逻辑方法开发完毕，但是页面还未开发完成，无法从界面上去执行用例，这时候就需要使用白盒测试。与接口测试的思路是类似的，但是这种情况一般不会有暴露到外部的service服务，没法从外围进行调用，需要到项目代码中编写单元测试调用。其余同接口测试。
3、数据库脚本一般应用在数据批量准备、数据批量修改，快速准备测试数据。了解数据流及关系是使用该方法的基础，通过数据库脚本模拟系统中数据的走向，输出测试所需要的数据。接口测试在某些情况下也可以达到这个目的。
04、PICT组合案例生成工具
PICT可以有效地按照两两测试的原理，进行测试用例设计·在使用PICT时，需要输入与测试用例相关的所有参数，以达到快速生成用例的效果，可以协助我们完成第二大点中的工作，极大提升效率。但工具生成的用例并不是完全可靠的，需要人工review一遍是否存在无效用例。