文章作者来自：ThoughtWorks-Fabio Pereira，译者：ThoughtWorks-张力文。

感谢ThoughtWorks校对小组：陈翔 、刘若然 、姚琪琳。欢迎联系我们加入小组。

本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。

要想帮助团队制定测试策略，编写出可靠可伸缩的测试，测试金字塔是最好的方式之一。 根据我多次的使用经验来看，它真的非常有用。

同时，我也经常会看到有的团队在尝试实践测试策略时掉进各种陷阱里。正如Alister Scott指出的，一个常见的陷阱就是冰淇淋甜筒状的反模式(anti-pattern)。这种模型形容在没有足够多的底层测试（单元测试、集成测试和组件测试）的情况下，创建了太多GUI（图像用户界面）测试，甚至更多的手动测试。

得益于自动化测试在软件开发界的普及，这种反模式现象正在减少。并且，加上TDD（测试驱动开发）和BDD（行为驱动开发）这些实践的大力推广和应用，我已经有很长一段时间没看到团队担心过底层测试（单元测试、集成测试、组件测试）了。

然而，与此同时我还观察到一些团队跌进了另一个非常危险的陷阱。这个新的反模式陷阱有如下非常明显的特征：

• 不同的团队写不同层次的测试。

• 一般由如下三类团队来写不同的测试：

• 开发人员写单元测试，集成测试和组件测试

• 另外一个团队通过界面来做黑盒测试

• 手动测试员进行一系列手动测试来测试功能

• 通常这些团队各自独立工作，合作甚少。

• 整个项目的工作流程流水式进行，并没有同步工作。首先是开发人员写出代码和对应的测试，然后测试人员手动地测试功能，之后GUI测试人员才编写他们的测试。这一流程看起来像什么？一个小型瀑布。

• 这三个团队在某场景是否应该被测试，或自动化测试的级别上，无法达成一致。这就导致了重复——相同的场景在不同级别上都进行了自动化测试。

在和同事Patrick和Tarso讨论此事时，我们对比了一下这个新的陷阱和之前提到的冰淇淋甜筒模型，然后开始思考这个新的反模式像什么。大致说来，它应该有个庞大的底部，宽阔的中部和一个巨型的顶部。Tarso灵光一闪，突然说道：“这不就是个杯型蛋糕(Cupcake)吗！” 他说得简直太对了。

下面介绍一下软件测试中的杯型蛋糕反模式：

这里有一些小贴士可以助你避开这个杯型蛋糕，甚至很有希望将其“扭转”回理想的测试金字塔模型：

• 合作：允许团队之间进行合作，然后讨论在哪一层写特定的测试才是最好的。以下是一些实用手段：

• 同步工作：当开发一个功能时，鼓励不同的团队之间同步工作，而不是线性工作，各自为政，像一个迷你小型瀑布一样。

• 跨角色结对：支持跨角色结对。比如，在一个Story快完结时，一个开发者可以和一个测试人员结对，决定在哪儿执行自动测试。

• Story Kickoff：这里有很多方法可以采用，比如三驾马车（The Three Amigos），或者有些人称之为story kickoff，目的都是为了帮助团队分享对需求的理解，减少沟通隔阂。

• 从最底层开始测试：在条件允许的情况下，从最靠近代码的地方开始测试一个功能，降低测试的深度。

• 如果可能，尽可能合并团队：有时你并不需要不同的团队，你所需要的只是在不同职位上的不同的人。比如说一个开发者可以成为某个功能的界面测试人员，即使如果他（她）并没有参与过开发这项功能。

• 在目标上达成一致：确保每个人都有相同的目标。比如，整个团队要对什么是“完成”达成一致意见，而不是一起工作“完成开发”或者是“完成测试”。

• 同时要达成一致的，还有衡量测试工作的方式。而一旦合适的衡量方式确立了，就要避免只能应用于某一特定层次的“横向衡量”，比如靠自动化测试的用例数目来衡量界面测试的质量。更合适的衡量方式应该是“纵向”的，这样就能把所有层次都囊括进来。就用上面的例子来讲，衡量方式应该改成这样——每个story不管在哪一层（UI测试、单元测试等）都至少需要有90%的自动化测试覆盖率。如此一来，衡量方法就被共享了，达到了双赢的效果。

当一个由开发者、手动测试人员和界面测试人员组成的团队，为了达成同一目标，齐心协力相互帮助的时候，我确信这个团队能够完成更好的测试策略，更好地确保软件质量。

最后，你有什么想法？