一、测试用例的写作规范
- 用例结构简单明了
好的测试用例应该包括构造输入数据、调用北侧对象、结果检查啊三个部分。
- 用例实现指责单一
一个用例只测试一个场景，用例禁止使用switch、if/else，测试代码是测试业务逻辑，实现逻辑尽量简单。
- 用例键独立无耦合
测试用例之间相互调用，用例执行应该与顺序无关。
- 结果检查充分
必须使用assert来进行自动校验；结果检查应该高效，避免陷入过多的实现细节。
- 代码简洁无重复
及时重构测试代码，封装跨测试的复杂或 这冗余代码。
二、测试坏味道
测试代码在实现上也与业务代码一样，长期不惊醒债务清理，则会产生坏味道，需要及时清除。
2.1 永不失败的测试
永不失败的测试坏味道来源于当代码出问题时，测试结果仍然通过，不会给出相应的错误告警。
重构建议：使用正确的断言。
2.2 脆弱的测试
DT测试代码应该尽量避免依赖外部资源，因为外部依赖不仅会导致测试时间长，状态不可控，也会影响测试结果，导致测试结果不确定。
重构建议：
- 用测试替身替换外部依赖，根据需要将其包装到适配层；
- 对于需要持久化的集成测试，建议使用内存数据库，用干净的数据集。
2.3 过度断言
过度断言是指断言对于关注行为的细节，检查项太多太细，以至于测试变得非常脆弱，甚至影响了其他更重要的测试意图，偏离的原本的测试目标。
重构建议：
- 基于测试的目的确定关键断言，识别无关紧要的细节并从测试中删除；
- 拆分测试，不同的检查项放在不同的测试用例中。
2.4 测试用例相关影响
一个测试用例作为套件的一部分时可以通过，但是单独执行却失败；原因是部分测试用例依赖测试套中的另一个测试的执行或结果，如测试中修改了全局变量值导致用例间产生耦合。
重构建议：
让测试自行建立所需的上下文，不要依赖于之前运行的任何测试。
2.5 断言意图不明确（基本断言）
断言的意义不直观，测试意图被隐藏在一长串看上去无意义的单词或者数字背后，难以理解，难以判断断言使用的正确性。影响代码的可读性。
重构建议：
- 去掉断言中的复杂逻辑，让检查更加直观；
- 从测试框架中找到更简洁更好的方式来优化代码，使其更容易表达意图。
2.6 测试功能不单一（模糊测试）
在一种测试方法中，验证了太多功能或暴露了许多与实际测试不相关的细节。
重构建议：
- 自动进行测试时，最好有一套独立的针对单一测试意图的测试用例，因为他们可以提供更好的缺陷定位。
2.7 条件测试逻辑
测试包含条件逻辑，该逻辑根据当前环境执行不同操作。
重构建议：
- 通过将测试与测试自动化的任何依赖关系脱钩，可以最好地解决灵活测试，确保测试用例的确定性。
