在说怎么写测试用例之前呢，先来聊聊为什么要写测试用例。
理由有5点：
1.理顺思路，避免漏测和重复测试。
2.帮助预估测试排期，把控进度。
3.方便bug回归验证。
4.便于发现、记录并复现问题。
5.标记测试结果，即对于测试结果有个交代。
知道了写用例目的之后，你还需要知道，什么样的测试用例才是好的！
优秀测试用例的特征：
1.包含基本信息，包括测试人/开发/产品/需求文档链接地址/技术文档链接地址，等等你测试过程中需要的物料。
2.每一条用例，有很明显的突出测试预期和测试目的。
3.所有用例都是可执行的。
4.逻辑脉络清晰，几乎不存在重复的用例，简约而不简单。
5.用例做到分级分层。
6.待测功能点覆盖全面。
同时还是想要强调2个观点：
1.不要纠结测试用例的格式或形式！
2.测试用例并不是写得越细越好！
有了以上基础，接下来才能够讲明白如何去写好测试用例，不，确切的说是写好测试方案。
（为什么这里会提到测试方案呢？因为测试用例是测试方案的一部分，你不能仅仅只是会去写用例和执行用例，你还需要针对不同的测试场景去制定测试方案）
写测试用例（测试方案）的步骤
一、基础信息
摘自美团技术团队文章
这里再补充一点：测试排期/上线时间/Bug提交地址等。
所以，基础信息至少要包含：
1.标题：【xxx】测试用例
2.新功能简介（或者需求目的目标）
3.参考资料
4.干系人
5.测试排期
6.上线时间
7.Bug提交地址
如果项目有 业务流程图 或者 系统框架图，也可以po到测试方案里面去体现，方便熟悉业务目的或者上下游系统间的依赖。
二、测试方法
根据需求的不同，又可以分为多种测试手段（手段）
最主要的：
1.功能测试
2.单元测试
3.性能测试
4.稳定性测试
5.兼容性测试
6.安全测试
7.UAT测试
等等。
需要全部都写吗？
不需要！
根据测试项目的实际情况而定，比方说：你只是测试一个搜索框改了个默认提示文案，你就没必要去单独再去硬套模版测试性能了。
其实谈到写测试用例，大家更多的还是在写功能测试用例，所以这块重点讲。
功能测试用例，要做好分层设计（至少2层）：
第一层：冒烟测试用例
第二层：常规测试用例
冒烟测试用例，其实也可以当作是 提测准入测试用例 以及 验收回归测试用例
这部分用例相当于P0级的测试用例，主要是为了保证主流程是完全走通的，如果走不通，则测试有权利打回给开发，让开发把主流程跑通后，测试再继续往下进行。
摘自美团技术团队文章
常规测试用例，呵！这里就是八方神仙、各显神通了！
设计测试用例的时候，是有一些策略和方法可循的。
测试方法不必多言，掌握几种常用的黑盒测试方法即可：
1.等价类
2.边界值
3.场景法
4.判定法
5.正交试验法
6.因果图
7.状态迁移图
其中用得最多的，恐怕就是 等价类、边界值、场景法 了。
测试策略就比较有讲究，需要大量的测试实践，才能形成一套自己的测试策略。
我自己总结了几条：
1.二八原则：重点抓主流程进行测试，不过分钻牛角尖。
·80%的问题，集中在20%的模块里
· 80%的Bug，由20%的开发者写出（日久见人心，你懂）
2. 要模拟真实的用户场景，不要YY出来一个永远都不可能发生的场景。
3. 相互依赖的服务之间，最容易滋生Bug。
4. 金字塔原理编写法，可以自上而下或者自下而上，杜绝重复用例。
三、数据构造
很多人不注重数据的重复利用，每次测试，都花费大量时间在构造数据上。
但是假如你在些测试方案时，就把数据构造和数据构造的方法写上去。
包括一些SQL、表格数据、json数据、账号密码等等测试数据。
当下次还有相同的测试场景时，可以翻一翻之前的测试方案，就不用再花费太多精力在构造数据上了。
