破防了！测试自动化模型分析，让测试效率狂飙

📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

在软件测试领域，尤其是自动化测试范畴，许多从业者在职业生涯早期便接触到测试自动化金字塔这一概念，我也不例外。尽管多年来，该模型在测试领域屡遭质疑，但在实际工作中，我仍会不时参考使用。

不可否认，测试自动化金字塔模型在一定程度上仍具有实用价值。对于初涉软件测试与自动化领域的人员而言，它能够帮助其快速了解测试范围与测试层次，更重要的是，引导他们深入思考并探讨如何在不同测试范围之间实现恰当的平衡。鉴于该模型在行业内的广泛存在，我期望新人能够在实际情境中对其形成全面认知。

然而，近期我开始以全新的视角思考并探讨自动化测试的分类，引入了一种截然不同的思维模型。我认为，与同行们分享这一模型，或许能为大家带来新的启发与帮助。

需特别说明的是，在本篇博客后续内容中，当提及“测试”时，均特指自动化测试/检查，其目的在于证实或证伪对产品行为的预期。我初步判断该模型并不完全适用于探索性测试活动，当然，若后续研究证明我观点有误，我亦欣然接受。

01 为何寻求新模型？

测试自动化金字塔模型虽在某些场景下仍具一定价值，但也存在明显的缺陷：

1. 模型自身局限性

   ：该模型完全未体现测试的价值。诚然，所有模型都存在局限性，但我们在日常工作中，常常聚焦于测试量、自动化比例、单元/集成/端到端测试的占比以及覆盖率等指标，却甚少关注测试的价值。而我认为，我们亟需一个至少将测试价值纳入考量的模型。

2. 模型应用与讨论偏差

   ：当前，许多人在讨论该模型时，过于关注其形状以及所代表的单元测试、集成测试和端到端测试的比例。但在我看来，测试的比例并非关键所在，无论其呈现为金字塔（实际为三角形）、沙漏、冰淇淋甜筒或其他任何形状，只要测试具备高效性与高价值，便是可行的。换言之，我们需要一种更优的方式来探讨测试及其所创造的价值，而这需要一个全新的模型作为支撑。

02 测试分类思维模型

回顾自动化测试的初衷，我们之所以采用自动化以及借助工具进行测试，是期望以高效的方式获取并呈现关于产品状态和潜在风险的有价值信息。基于此，测试自动化中有两个核心要素：一是信息，尤其是高价值信息；二是效率，即获取所需信息的资源投入量。

基于以上两点，我在讨论自动化测试时采用的思维模型为象限图，可将其称为测试自动化象限。这是一个较为简单的模型，当然，它也不可避免地存在一些细节上的缺失，但这正是模型的特性。接下来，我将详细阐述该模型的构建逻辑及背后的思考过程。

在横轴上，衡量的是信息价值。作为测试人员，我们的核心工作是发现并呈现信息，具体而言，是关于产品状态的信息。但并非所有信息都具有同等重要性，能够发现并呈现有价值信息的测试，其本身价值更高。信息价值与风险密切相关，与高风险问题相关的信息价值更高。这里的信息，指的是对产品状态或行为的假设、信念或预期的证实或证伪。由于讨论的是自动化测试，大部分工作集中在通过断言来证实已编码的预期，但自动化测试并不局限于此。此外，信息价值不仅取决于信息本身及产品状态，还包括信息的可靠性，不可信的测试即便反馈产品问题也毫无意义。

在纵轴上，衡量的是效率。在其他条件相同的情况下，效率更高的测试通常更受青睐。效率涵盖阅读、编写、运行和维护测试的时间，以及测试失败时分析根本原因所需的时间。除时间外，还需考虑编写和运行测试所需的硬件和软件成本，以及其他与效率相关的因素。

与测试自动化金字塔不同，该模型未将测试范围或规模纳入考量。端到端测试、单元测试和集成测试的效率和信息价值均有高低之分，且该模型同样适用于自动化性能测试、安全测试等其他类型的测试自动化，这些测试都可能产生不同价值的信息，并以不同效率的方式执行。

03 利用测试自动化象限评估现状

当决定采用该模型时，建议首先将测试置于相应象限中。不同类型测试甚至单个测试的具体位置各异，这也正是该模型的优势所在，它可应用于整个测试套件、不同类型测试，乃至单个测试用例。

理想状态下，大多数测试应位于右上角象限，即能够提供有价值信息的高效测试。但并非所有测试都会处于此象限，这也并非坏事，目前我们只是在评估现状。

例如，右下角象限的测试虽能产生高价值信息，但效率较低，可能是编写或运行时间长，或需大量系统设置工作等原因。尽管如此，因其能产生有价值信息，保留它们或许是有益的。

再看左边两个象限，左上角象限的测试编写和运行效率高，但信息价值低。建议对这类测试设置较低优先级，仅在有时间和资源时处理，甚至可考虑放弃。

至于左下角象限的测试，强烈建议停止投入时间，既不编写新测试，也应考虑舍弃现有测试，因其投入产出比过低。

04 利用测试自动化象限改进自动化工作

在完成对单个测试、一组相关测试或整个测试套件的现状评估后，第二步是确定并采取措施，使部分或全部测试向象限右上角靠拢，可通过向上或向右移动，或两者兼具的方式实现。

将测试向上移动，意味着在不降低信息价值的前提下，提高现有测试的效率。具体方法因具体情境而异，例如将端到端测试分解为更小、更具针对性的测试，重构难以测试的应用程序代码，使用第三方依赖的Mock版本等。

将测试向右移动，意味着改进产生低价值或不可靠信息的测试。可采取从不稳定测试中收集数据以找出不稳定原因并解决、测试测试用例（如使用变异测试技术）、改进测试套件报告等措施。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】