啊，这是一个多么痛的领悟。
在近一个月前（6 月 7 号）刚写了一篇关于测试的文章： 这里 ，如今再次写关于这个话题，一个主要原因是，最近在工作中提交了带有缺陷的代码，造成严重事故（事故和代码细节不方便说了，大家不要太好奇🫣，见谅），我们开了一次分析会，在会上，我司 VP 和部门总监提出就此事而言的一个观点：谁都有可能提交带有缺陷的代码，不然软件开发中就不会有 Bug 存在了......那么应该如何改善和避免这样的问题？（记不太清楚原话了，但是这么个意思）。
作为开发者我需要做的最基本事情是：提供 完备的测试用例。
由于提交代码的“始作俑”者就是本人，我内心触动是非常大的（生气、愧疚、恐慌），当我看到缺陷的那一刻，我就知道它是严重且低级错误，但作为开发者的角色，我第一考虑到的点是 为什么测试用例没有捕获到如此低级的错误， 所以在修复之后罗列关于该模块的测试用例有 100 — 139 个之间，缩小范围精确到最接近缺陷的测试场景，发现 这部分测试用例大部分都只进行了正向断言 ，而缺陷恰好出现在了反向。
正反向断言
在上篇文章我有谈到 正反向断言 这一观点，但在那篇文章中并没有把优先级提的很高。
什么是正向断言，什么是反向断言？
比如用户输入正确的密码可以登录成功，所以测试步骤是：
- 输入正确符合预期的用户名、密码
- 断言登录成功
这就是一个正向断言，那么这个测试完善了吗？ 比如用户输入了一个错误的用户名/密码，是否也可以登录成功呢？这就是一个反向的测试， 显然在上面的测试中并不包含这部分逻辑的，如果生产环境真的恰好出现了我说的情况，我相信代价一定是沉痛的。
一定要加反向断言逻辑
从上面的例子可以发现是有可能出现密码错误也可以登录成功，意味着映射这段这段测试的程序逻辑是不起作用的，例如上面登录的场景转换成代码（很低级，只是为了说明问题，暂时没有想起更好的例子）
这段代码的一个正向断言逻辑，是可以通过的， 此时如果认为这段代码没有问题那么就大错特错了，完全没有考虑输入错误的数据的情况。
补充上反向断言逻辑：
后两种都可以检测出预期和实际输出不一致，这样就很容易捕获到漏洞，不会上到生产环境了。
最后
还有一种现象，大家可能会有一些这方面的意识，但是不够重视不够坚决，会侥幸或嫌麻烦就偷懒，比如本人有时候写程序/测试的就特别的细心写的非常全面，有时候就忘记一些反向测试，说到底不够重视，那后果就是总有一次会偿还的，所以也希望大家也重视起来测试，重视测试中的反向测试，如果你觉得你不会犯低级错误，就当这篇是水文，图一乐吧。
