作者：测试蔡坨坨
你好，我是测试蔡坨坨。
当你学会了如何设计测试用例之后，接下来便是开始用例的编写。
测试用例的编写是每一个测试工程师安身立命的家伙，也是测试的基础，更是软件测试的核心内容，正所谓“基础不牢，地动山摇”，所以一定要掌握好，有些转行的小伙伴一上来就开始自动化、性能的学习，却忽略了最基础的东西，这是不对的。
在编写测试用例之前，首先应该根据所在公司、项目组的特点，提前制定好对应的测试用例模板以及用例维护方式，比如：Excel、XMind、TestLink、禅道等。
-
用例标题
一个好的测试用例应该关注标题的规范性，一般来说如果设计用例标题不规范，别人在使用你的测试用例时，就无法做到清晰明了，就会浪费很多时间在沟通上。
-
功能模块
-
测试目的
-
前置条件
测试用例其实就是在某种场景下，执行一定的动作，达到什么样的结果。而前置条件决定了“在某种场景下”，所以是不可或缺的。
-
根据需求的优先级来定义，高优先级要覆盖核心业务，重要特性以及使用频率比较高的部分。
冒烟测试（高）、基础用例（较高）、特殊场景用例（中）、错误场景用例（低）。
-
操作步骤
用例步骤一般不多于7步，不少于2步。
-
测试数据
-
预期结果
预期结果关系到用例需要达到什么样的结果，所以也是不可或缺。
-
执行结果
预期结果一般不超过5个，不少于1个。
-
每条测试用例执行不通过后再记录对应一条Bug，例如：BUG-1219。
-
用例对应的编写人员，填写编写人员姓名，例如：测试蔡坨坨。
-
用例对应的执行人员，填写执行人员姓名，例如：测试蔡坨坨。
-
备注
用例编号
项目名称各中文首字母大写+六位数字构成，例如：“蔡坨坨电商项目”在登录功能子模块的第一条用例编号可取值为CTTDS_000001。
测试用例的编写并没有好坏和对错之分，每个人编写用例的思路也是各不相同，适合当前团队就是最好的，不要盲目把所有的字段都加上，应根据实际场景进行取舍。
例如：
场景+预期结果 进行描述，比如：输入正确的用户名和密码，成功登录系统；
用例之间要解耦，日常工作中经常遇到几个用例有先后顺序的情况，比如：在测试编辑之前肯定要先新建一条数据，最好把新建放在编辑用例的前置条件中，每条用例都能实现闭环；
拒绝冗余，用例可以多，但不要冗余，尽可能以最小场景覆盖最全的范围，同一个等价类只需测一条数据，当然，因为测试不可穷尽性，测试场景肯定不会最全面，往往会受限于时间和资源等成本，这时需要在有限的资源下，寻求质量和效率之间的平衡点，优先级这个字段就起到了作用，再引申就是测试策略的问题了，整体上采取基于风险驱动的模式，有侧重点地去验证一些场景，优先核心功能，或者增加资源和延长周期，同时寻求自动化相关技术去提升整体效率。