作者 | 曹巧晖
背景
经历过校招或社招的测试同学，都会被问到测试用例的设计、使用方法，以及用例的重要性。
大概了解过测试行业或者有一些测试基础的同学面试时能很好的回答上来，设计用例的方法，但是给一个真实场景需要简单编写测试用例的时候，往往就暴露了设计用例的短板。再进阶一些的测试同学，会很疑惑，测试用例有什么用呢？每次提测前，把测试用例照着需求文档抄写一遍，走个过场？提测后，照着用例点点点，执行完毕后没有测出任何bug，达到了上线状态？上线后，测试用例毫无价值，用完弃之，最后线上出现bug，无迹可寻。心里一百个怪写用例浪费时间，没有实际价值。
为什么要写用例？
为什么要写测试用例？或者说我们写用例到底有什么用？
1、方便理解需求，覆盖更多场景
2、有助于评估测试工时
3、便于了解测试数据流向
4、把控测试进度
5、上线前核心功能回归
6、提高测试效率，理清测试思路
所以，测试用例很有必要，是测试理解业务的必备能力，测试的立身之本。
那怎么写好测试用例呢？
设计测试用例：需求分析是关键、用例设计是核心、Case结构很重要
用例完整思路：
需求可行性分析-->业务流程分析→测试用例设计→测试用例评审-->维护/更新测试用例
1、需求可行性分析
从需求文档中，找出待测试软需求，通过自己的分析、理解，整理成为测试点，清楚被测试对象具有哪些功能。
测试需求的特点是：包含需求，具有可测试性。
测试需求应该在需求基础上进行归纳、分类或细分，方便测试用例设计。
2、业务流程分析
软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。
为了不遗漏测试点，需要清楚的了解产品的业务流程。建议在做复杂的测试用例设计前，先根据研发或产品提供的流程图，从测试角度对现有流程进行补充。业务流程图可以帮助理解需求的逻辑和数据流向，从而指导测试用例的设计。
从业务流程上，应得到以下信息：
主流程是什么
条件是什么
数据流向是什么
关键的判断条件是什么
3、测试用例设计
用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。
在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。
4、测试用例评审
测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审，在设计用例的时候，有不明确的需求，标记出来。在测试用例评审时，着重和产品、研发沟通确认。确认完后，更新测试用例。
5、测试用例更新
测试用例是“活”的，在软件的生命周期中不断更新与完善
5.1）遇到线上问题，复盘当时是否有遗漏这个测试点，更新测试用例
5.2）核心用例，在每次需求上线后，持续更新
6、测试用例结构
传统测试用例编写都是通过Excel表格，元素有：测试用例编号、测试用例标题、优先级、测试模块、前置条件、测试输入、测试步骤、预期结果。
同上，注册用例用Xmind格式呈现形式：
可以发现测试结构发生了很大变化，颗粒度也有所不同，相比Excel，xmind更结构化，更适合快速迭代的互联网。但是，大项目测试方案中测试点梳理，以及一些回归场景，更建议用Excel。
日常测试中，xmind测试用例注意点
那么我们日常测试中，如果用xmind梳理用例结构注意哪些点呢？
1、不需要复制粘贴需求文档
每次review组内用例时，会发现用例都会照搬需求文档，需求文档中有预期结果1、预期结果2等，用例也是结果1、结果2等等。我们需要把文档已有的结果1、结果2写清楚后，再拆解异常结果3、结果4……
2、测试用例一定是要可执行。
3、测试用例要体现测试目标，理解需求的预期结果是什么
4、优先级很重要，核心用例要标记
5、测试用例不仅仅是用例，数据流向也要体现出来。
理解了为什么要设计测试用例、设计用例的关键是什么？用xmind结构展示一下测试用例：
第一步，展示干系人信息
第二步，梳理接口、数据流向
第三步，设计功能测试用例
第四步，执行用例，转转统一用测试用例平台管理。
截图来源：zzcase用例平台
第五步，输出公用用例、上线前featurelist
最终用例效果呈现
end