Q:为什么你做了那么多自动测试，却很少能发现缺陷？
A:为什么自动化测试要发现缺陷？
在讨论问题时，首先要对问题是否存在达成一致，而不是直接跳到解决方案。
前一阵子，笔者在某个高端测试群里面丢了一个小石头，引出了诸多测试大佬的讨论。不少人首先就不认同这个问题，认为自动化测试的目标就不是发现缺陷，而是其它。
笔者来介绍一下一个和自动化测试无关的问题。
回归测试的故事
在十多年前的外企时代，笔者所服务的公司有一个团队负责一款行业标杆产品的测试。那时候的发布节奏比较缓慢，大型产品功能和架构升级是一年一次，常规新功能是一个季度发布一次，期间每月发布一次补丁包，夹杂若干VVIP用户的特定补丁。对于测试团队来说，在季度版本以上规格的发布就要求进行全回归，并且年度版本至少要两个轮次。整个用例集大概有10K,以每人每天执行50条用例计，每轮次的全回归要至少200人天。对于一个10人的测试团队来说，这也几乎是一个月的工作量了。没错，抛去其他的工作和非测试相关的杂事，一个测试人员的工作当量就是50条回归测试用例的执行。
根据笔者的统计结果，这种级别的回归测试，其测试用例的通过率一般稳定在99%左右。也就是说，作为一个测试人员，对照着测试用例说明书和被测应用点2天，才能发现一个缺陷。
如果你是这个团队当时的成员，一定会选择成就感更高的新功能测试，而不是去连续点点点回归一个月，因为那简直是一场折磨，而且每个季度都要来一次。
这也是当年笔者在公司内部推行探索式测试试验获得了大家的追捧，不是因为实测效果是可以在回归版本上1天发现2个缺陷，而是可以从那机械地、重复地，最关键是不能发现缺陷的测试活动中脱离开来。
自动化回归测试的故事
再来说一个和自动化相关的问题，
在若干年后，该公司在公司的当家产品上实施了大型的自动化测试项目，整个测试组织（200 ）为此积极努力了1年多，终于攒到了约1万条UI自动化测试用例，并且每周进行一次全回归。整个组织发现，虽然实现了自动化，但是还是陷入了泥沼当中，UI自动化测试用例的脆弱性全面爆发，通常在一个新的季度版本的首次提测，自动化测试用例的通过率会低到60%以下。根据前面99%的通过率数据，这些都是各种问题导致的自动化测试用例的假失败(FALSE Failure)。团队虽然用自动化解决了回归测试耗时耗力的问题，但是额外引入了高昂的自动化维护成本，更为重要的是，临时被拉出来组成自动化用例维护小组的同学们心理都清楚，这些失败都是假失败，并不是因为发现缺陷了缺陷。再一次，测试同学陷入了工作缺乏价值感的沮丧当中。
要赢
当然也有同学说，这些都是老黄历了，现在都是微服务 接口自动化测试了。
没错，那回过来说，为什么自动化测试还是不能发现缺陷呢？
在那场讨论中，也有测试大佬认为双方处在不同的宇宙，价值观不同，这根本不应该是个问题。
笔者想问的是，为什么自动化测试就是要发现缺陷呢？为什么测试就是要发现缺陷呢？
因为要赢。
去嚼别人嚼过的甘蔗，再怎么努力也榨不出太多的汁水。
以下是ChatGPT说的车轱辘话，赢是带领团队的一件最重要的事情，因为一个成功的团队需要具备强烈的目标和动力，通过追求胜利，团队可以更好地激发成员的工作热情和创造力，增强团队凝聚力和向心力，不断提高自身的竞争力和市场价值。此外，赢也意味着团队能够取得更多的经验和成就，并得到更多的认可和回报，这将进一步推动团队成员个人和职业的发展。所以，赢对于团队来说是非常重要的一个目标和动力。
对于一个普通的测试人员来说，赢就是能快速、准确、全面的发现缺陷。通过发现缺陷，帮助团队更及时地解决问题，提高软件质量，降低风险，确保软件能够满足用户的需求。通过发现并解决缺陷，团队可以更快速地交付高质量的软件，从而提高在市场竞争中获得优势的可能性。这是测试人员基本价值的发挥。抛开这些去谈别的价值，是舍本逐末。
所以发现缺陷是测试工作的一个基本目标，自动化测试作为一项测试活动，也是为这个目标服务的。
也有测试同学支出，通过自动化测试的快速回归快速反馈，可以有效支持测试人员进行新功能测测试，也有助于发现缺陷。因此，自动化测试也是为发现缺陷服务的，不用太拘泥于自动化测试是否直接发现了缺陷。
这个话基本上是正确的，也代表了目前的主流观点。或者说，80%（数字都是我胡乱猜测的）的团队目前甚至还达不到这样的水平，而99%的团队会将此作为目标。
而只有1%的团队会将自动化测试发现缺陷作为目标，因为这是他们做测试的主要手段。
什么样的团队这样的呢？
2010年的Google。在某个ppt中，Google说每天执行1亿条次的用例，当然相信这些都是small类型的用例（可以阅读一下 how gogole tests software来了解一下s/m/l类型的测试和测试认证）。
某些实施了TDD/ATDD/BDD的团队。所有需求的澄清都是以自动化测试用例的形式。
如果去观察一下，可以发现一个特征。那就是，
针对某个需求的新增测试用例的执行，是否是以自动化测试的方式执行的。
原因很简单，因为新需求也带来了新的缺陷。软件测试的一大流派就是基于风险的测试，也是这样一个道理。
所以，针对自动化测试是否应该以发现缺陷为目标的讨论，其实应该转换成能否将测试用例的首次执行是按照自动化测试的方式来执行？
你的用例的第一次执行，是用手点的，还是流水线调起的？
这就是99%和1%之间的区别。
这也就意味着，某些测试组织中设置了单独的自动化测试团队，专注于将（回归）测试用例实现自动化。这种模式是难以实现上述目标的。
笔者层级在某个核心系统的测试中推行过“手自一体”的测试模式。核心系统天然是可以独立运行的系统、通过接口与外部进行交互，包括行业协议接口、配置文件接口和数据库接口。
通过做好环境、配置尤其是数据的维护工作，实现了上述目标，也就是测试用例在设计时就是按照自动化用例进行设计。用例在首次执行时，测试人员判断是否符合测试预期。如果不符合预期，则报告缺陷。如果符合预期，则将该用例纳入用例库，作为自动化用例进行回归。
这种方式改变了过去团队先手工测试一遍，然后再在下一个迭代时再进行实现自动化的模式。
如果说团队已经实现了TDD/BDD/ATDD，则更加符合上述特征，因为自动化测试的设计和执行的时机更为提前。相信在这样的团队中也不太会有人关注到底自动化测试应不应该发现缺陷。因为自动化测试就是他们主要甚至是唯一的用例执行方式。
这就是99%和1%之间的区别。
