看完这篇文章，才发现我的测试用例写的就是垃圾

测试用例编写作为测试技能最基础的一个能力，大家应该或多或少都有自己写用例的习惯和思考方式，这里分享一些需求分析和编写用例的经验，主要针对功能测试，旨在尽量降低测试遗漏的可能性，而对于新同学来说，则希望可以达到入门的效果。最后会分享一个小工具，梳理一些比较复杂的业务需求时，可以协助做快速的分析。

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一遍是否存在无效用例。

---

学习资源分享

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….

如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入下方我的qq群大家一起讨论交流，里面也有各种软件测试资料和技术交流。