布尔微信：Matongxue_6

经典自动化测试模型-金字塔模型

按照测试金字塔模型以及投入/产出比，我们得知越向下回报率越高。

所以应该使用大量的单元测试

全面的接口测试来覆盖产品提供的基本逻辑和功能

使用少量的集成（UI）测试来进行前端界面的功能验证。

上图是自动化测试方面经典的“金字塔”模型

• 越往上，越接近测试、业务/最终用户，越往下，越接近开发；
• 越往上，测试执行越慢，越往下，测试执行越快；
• 越往上，测试成本越高（越耗时，失败时的信息越模糊，越难跟踪），越往下，测试成本越低。

金字塔模型中的三类自动化测试

*从金字塔模式中引申出三类自动化

1)单元自动化测试

在计算机编程 (opens new window)中，单元测试（英语：Unit Testing）又称为模块测试，是针对程序模块 (opens new window)（软件设计 (opens new window)的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程 (opens new window)中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

2)接口自动化测试

接口自动化测试，主要验证“模块”间的调用返回以及不同系统、服务间的数据交换。接口测试自动化一般在业务逻辑层进行测试。调用被测试的接口，构造相应的请求数据，得到返回值，是成功或者失败。不管输入的参数是怎样的，我们都将得到一个结果，最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。

所以，接口测试关注的是数据。只要数据正确了，功能就做成大半，剩下的无非是如何把这些数据展示在页面上。

3)集成（UI）自动化测试

UI层是用户使用产品的入口，所有功能通过这一层提供给用户，目前测试工作大多集中在这一层，这种测试更贴近用户的行为，模拟用户点击了某个按钮、在输入框里输入了某些指令。有时可能用户看到登录成功了，自动化脚本通过例如 登录成功后页面右上角会显示“欢迎，xxx”，来判断功能点。当UI自动化登录成功后，就去获取这个数据进行断言，断言如果相等，测试通过；如果不相等，测试失败。

所以，UI自动化的关注点用户操作形为，以及UI上各种组件是否可用。

小结：

1.在项目中，我们应该分层逐步实现自动化。

自动化经典误区

经典偏见

自动化的目的就是减少测试员的数量。

自动化工具比代码来的简单，掌握工具即使会自动化了

自动化找不到bug/自动化没法提升效率

自动化的目的是代替手工测试

反模式

**冰激凌(ice cream cone)**这一反模式。从图形上看，这其实是一个倒置的自动化测试金字塔。这个模式的特点就是，整个组织的自动化测试主要还是针对于用户界面，对于单元测试和集成测试用例的数量或者投资要少许多。更为可怕的是，这个冰激凌桶上面有一大坨手工用例。这个冰淇淋吃起来，估计远不如哈根达斯或者暴风雪那么好的口味了。

图：自动化冰激凌

这一模式中庞大的手工用例数量，反映了工程团队对于自动化测试投资的不足。

许多开始进行自动化测试的团队，为了能尽快产出效果，获得收益，就采取了一些短平快的措施，从最容易上手的用户界面开始。

在传统的商用软件供应商或者某些新兴的SAAS服务提供商的系统中，往往用户界面中包含有非常多的业务逻辑，传统的测试团队过往主要依赖于通过手工测试来完成其业务的测试，评测产品的质量，因此提高手工测试用例的自动化替代率是一个显而易见的目标

这是一种非常典型的路径依赖，由此产生的结果就是，团队对于底层的自动化测试方面的关注相当不足。继而产生漏测 并且 难以提高自动化覆盖率

纸杯蛋糕反模式在引入敏捷和全员质量的意识之后，工程团队也愈加重视测试和产品质量，于是测试用例可能来自于以下三个团队:

1.开发团队编写单元测试、集成测试和组件测试用例

2.自动化测试团队编写UI自动化测试用例

3.手工测试团队编写手工运行的测试用例，以系统集成测试/业务场景测试为主

图：自动化纸杯蛋糕

根据提出者的介绍，纸杯蛋糕模式的形成原因，主要是因为开发和测试团队分属不同部门，两者中间有着厚厚的部门墙。从团队协作的角度上来讲，因为墙的存在，这些团队都各自为政，彼此间并不能很有效地协作。在测试的级别/类型/场景划分上，这三个团队是彼此没有协同的。这样就必然导致某些重复工作，有些用例被反复地进行自动化；而另一方面，质量拼图不完整也是不完整的，存在缝隙和漏洞，结果必然是1+1+1<3。

从流程上来讲，测试工作也依然是依次线性发生的，而不是同步的。首先，开发编写代码以及对应的测试用例；然后手工测试者设计并运行自己编写的用例；最后，自动化测试团队编写UI自动化测试用例并执行。这个场景可能某些读者非常熟悉，这就是许多声称已经敏捷化的团队的工作模式，在Scrum的流程中依旧使用传统的瀑布式开发模式。他们的Scrum模式，有同行给取了个名字，叫做

类似的模式还有“北方天使反模式”(Angel of North Anti-Pattern)等，这里就不一一赘述了。它们都不约而同地关注于协作与沟通、利益与壁垒等有关人员与组织层面的问题，而不仅仅集中在如何进行自动化测试自身。

当然，很多时候拘泥于部门间职责的切分，有些很好的建议，在现实中比较难以展开。如使用垂直分布的自动化测试度量目标，实现针对某个story或者某个发布在所有级别(UI, Unit)上与所有团队(开发、测试)进行共享。因为度量目标是分享的，更容易达到双赢和互相补位的结果。而现实中，有些Scrum团队的工作DOD(Definition of Done，完成的定义)并不包含测试团队或者测试人员的交付物。当在看板里把一个story置为“Done”的时候，那么很可能只是"Dev Done"(开发完成)，然后交付给测试去实现“Test Done”(测试完成)。另外，出于专注于本职工作，做精做细功能和非功能测试的考虑，一般独立的测试团队也很少去参与开发团队的测试，更不要说共同探讨如何分享测试资源、度量目标了。

注：

反模式：（英文：Anti-patterns或pitfalls）, 是指用来解决问题的带有共同性的不良方法。它们已经经过研究并分类，以防止日后重蹈覆辙（百度百科）

路径依赖：一旦人们做了某种选择，就好比走上了一条不归之路，惯性的力量会使这一选择不断自我强化，并让你轻易走不出去。相应的损失横向比较的能力（百度百科）

自动化测试需要什么能力？

1.代码能力

编写业务逻辑

使用库的能力

调试能力

2.熟悉被测系统

熟悉系统业务

熟悉系统架构

熟悉表和记录

3.掌握工具或者框架

了解工具 和 框架的使用成本，和场景

高效维护脚本

自动化环境的部署和维护（例如jenkins）

自动化使用的场景

*怎么让自动化“有用”

回归测试：验证版本主要功能是否达标，是否存在旧有缺陷

冒烟测试：在人工测试之前，对提测项目的主要功能 和 测试环境的连通性进行检测

线上巡检：用于对线上服务进行进行定时检查，保证核心功能。

构造测试数据：通过自动化生成基础数据，用于组内使用 和 组外输出价值。

固化资产：通过编写自动化case，可以将底层逻辑、测试框架、编码技巧等资料留存下来。

更符合测试团队实现的自动化模式---

菱形/纺锤/橄榄型自动化

对大部分团队来说，更符合实际测试模式是纺锤模型。

在项目中，单元测试主要依赖开发团队完成。测试团队较难控制单元测试的规模和质量。

所以先将重心放在**中间层（接口）**的测试上，这是因为

​ ①第一，中间层投入产出比较高，可以实现较高的自动化率；

​ ②第二，可以帮助加强开发跟测试人员之间的协作，提高测试质量。这一层需要开发跟测试人员共同定义，因为开发知道内部实现的细节，测试掌握业务场景。

对于Ui层，则采取控制规模的方式。进行高效编写和维护