一、前言
测试用例，可以说是质量的保障中最关键的一环。 测试用例中没有的内容，可以说99%的情况下后续测试执行的时候，不会覆盖。当然不排除某些情况下，突发灵感，想起某些测试场景， 并将其加入测试用例中。但这是概率事件，非必然事件。
测试用例——广发意义上的，无论谁执行；
典型测试用例的用途： 无论谁在编写测试用例(新手、老手、哪怕是开发同学)，保障测试用例的场景覆盖
二、测试用例准备的难点
说起难点， 不妨看下以下测试用例的套路：
需求上x1需求点——对应几条测试用例；
需求上x2需求点——对应几条测试用例；
技术实现上Y1实现点——对应几条测试用例；
主流程回归
测试用例编写的难点在于：忽略了业务的独特性，只考虑了写在明面上的需求，技术实现，但忽略了最重要的东西
需求上有什么需求点，对应测试用例；技术实现上游什么点，对应测试用例，外加主流程回归。 这是写测试用例的套路。 类似套路，可以随手拿来套用到各个业务上。
但明显忽略了业务的独特性，只考虑了写在明面上的需求，技术实现，但忽略了最重要的东西：
需求文档/技术实现 没有明说，但却需要加入测试用例的东西。
隐含的东西包括：
旧数据如何处理/如何兼容；-----老数据/场景兼容测试
上下游域是否做了兼容；-----链路测试
业务实现本身有灰度开关----灰度测试
业务本身允许异常重试操作----异常重试测