一条好的测试用例，到底应该是什么样的？
在整个测试的过程中，提测之前，准确说，应该在需求评审、技术方案确认之后，那我们就需要去编写测试用例，通过测试用例来执行测试。本篇只是单纯的描述如何编写一条用例，针对用例本身，比如：包含哪些必要字段、可以有哪些扩展字段，每个字段应该编写到什么样的程度；不包括如何分析、设计用例，如何设计一套完整的用例，会有另外一篇文章来专门介绍。
好的测试用例有诸多的好处：
任何人测试人员都可以执行：可以给不是很熟悉该业务或者该模块的同学直接去执行，而不需要去反复再同开发、产品对齐，或者是猜测该条用例的意思或者意图；
减少不必要的沟通成本、节省实际执行时间：一条步骤清晰的用例，完全可以照着一步步执行；预期结果清晰，则可以很容易的断定该条用例是否通过；前置条件清楚明白，则可以顺利执行；
尽可能的减少重复劳动：在实际的工作中，我们会发现A同学写的用例交接给B同学之后，由于用例步骤不详细、前置不清晰等，导致无法理解、执行，导致会去重写该模块的用例，这就导致工作成本的增加；
归档：为后续的迭代、回归，回溯或者交接等提供清晰的依据以及指导。
一条基本的用例应当包含哪些字段：
用例名称、前置条件、输入步骤、预期结果，这几个字段是必不可少的，在保证基本字段清晰的情况下，根据需要，我们可以适当添加一些字段，比如：用例编号、优先级、使用平台、是否自动化、关联需求、是否通过、网络、备注等等；
基本字段必不可少，而且还要清晰描述：
用例名称
能完整且简洁的描述该条用例要做什么；
前置条件
用例执行需要做哪些前置步骤，或者需要哪些条件才能使该条用例顺利的执行下去；一般来说，在功能模块之前存在关联时或者依赖时，此时需要将前置条件写清楚，因为这些依赖和关联的点，可能只有当时相关的测试和开发比较清楚。
比如：限免时段内，重复领取福利；
例：
那么在前置条件或者备注里，最好解释一下限免规则；
发布限时免费的活动到测试环境；
同一时段内，领取过一次；
用例步骤或者输入步骤
这里也是指导用例执行的关键，需要将每一步写的比较清楚，否则其他人来执行的话，很容易出错或者理解错，比如：下载QQ表情的过程中，退出手机QQ这么个用例：
例：
手机登录QQ
打开一个聊天窗口
点击表情
点击“+”，进入表情商城首页
点击表情包，进入详情页
点击下载
当下载到50%之后，手机操作退出详情页面返回到aio界面
退出之后，检查是否可以正常下载完
预期结果
预期结果非常重要，不仅要将相关的检查点写的清晰、完整，而且还要严谨、不易产生误解，能够让其他人执行用例之后，明确判断该条用例是否通过；
比如点击下载某个表情包或者文件，这里的检查，包括前端、后端、数据、本地文件等检查;
下载过程中进度条的检查；
下载完成之后文件是否完整、正常打开，内容是否正确；
如果存在状态，状态是否变化；
如果存在数据存储，数据库检查等；
用例编号
代表着用例ID，可以通过多种方式来定，只要清晰明了即可；一般可以是：需求编号+功能模块代号+测试类别+编号；
优先级
用例优先级一般分为3个级别，P0\P1\P2，P0为最高级别，P2为最低级别；在测试活动中，P0级别用例通常会作为开发提测前的自测用例，因此，P0级别的用例比较重要，但量不能太多，在后续的迭代功能、回归测试中，会起着比较重要的作用。一般为正常功能、主流程用例。
使用平台
一般是指测试平台，比如：android、IOS、或者PC、mac等；
是否自动化
一般是指UI自动化或者接口自动化，如果已经自动化的用例，后续在回归测试以及迭代版本的冒烟测试上可以使用自动化来替代，方便区分、统计；
关联需求
这个一般是指需求的链接，或者需求名称（如果没有链接的话）；方便后续回溯，以及其他人来使用或者熟悉该模块的测试以及开发。
是否通过
标注当前测试用例是否通过；
网络
测试需要使用网络，比如：3G、4G、wifi、弱网或者弱网详细参数，比如：丢包、延迟、具体网速等；
备注
一般说明该用例需要注意的事项或者特殊的事项。
页:
[1]
