软件测试反模式——杯型蛋糕简介 | TW洞见

今日洞见

文章作者来自: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%的自动化测试覆盖率。如此一来,衡量方法就被共享了,达到了双赢的效果。

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

最后,你有什么想法?

原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2016-03-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序员的知识天地

Facebook的bug终结者!程序员再也不用加班熬夜了!

“如果 Facebook 没有 AI,那它将失去根基。”去年@Scale软件工程大会上,Facebook AML 实验室负责人 Joaquin Candela ...

1443
来自专栏ThoughtWorks

TW洞见〡今日最佳答案:为什么互联网公司不开除测试?

点击上方“思特沃克”可以订阅哦! 本篇洞见内容来自知乎。 欢迎点击最底部【阅读原文】跳转至ThoughtWorks官方微博就此问题发表你的看法。 文章末尾另有关...

3655
来自专栏JAVA高级架构开发

有时候,解决问题比写代码更重要!

有时候程序员往往会陷入为了写代码而写代码的怪圈,没有意识到代码是为了解决现实问题的。当问题有更简便的解决方案时,写代码未必就是必须。记住:你不是别人花钱让你在屏...

350
来自专栏蓝天

电信系统架构方案

撰文/青润(本文来自《程序员》杂志2003年3期) 国内软件业曾有人对行业性软件进行划分,在几个较大的行业中,排行前几位的分别是:通信、电力、金融…… 但从...

1564
来自专栏从流域到海域

可视化微服务:设计微服务系统

原文地址:https://dzone.com/articles/visualizing-microservices-designing-a-microservi...

3807
来自专栏SDNLAB

Facebook开源Katran负载均衡器并公开Provisioning Tool

2256
来自专栏云端漫步

harbor源码分析之技术体系(一)

harbor作为一个中国人编写的项目,被CNCF组织接收,应该有着伟大的意义吧.简单的看了下harbor的源码,十分的庞大. 那么面对这个庞然大物,怎么办? 要...

1790
来自专栏python开发者

软件测试基本理论-IBM模式

软件测试基本理论(1) IBM生产模式 1   参考书目 《IBM-从菜鸟到测试架构师-一个测试工程师的成长日记》 出版社:电子工业出版社 印次:2013年6月...

2426
来自专栏Java技术栈

有时候,解决问题比写代码更重要!

有时候程序员往往会陷入为了写代码而写代码的怪圈,没有意识到代码是为了解决现实问题的。当问题有更简便的解决方案时,写代码未必就是必须。记住:你不是别人花钱让你在屏...

1173
来自专栏大数据

大数据驱动的未来网络:体系架构与应用场景(下)网络架构与场景详解

【学术plus】 新添加号内搜索功能! →输入关键词→一键检索您需要的文章。快来试试! 今日荐文 今日荐文的作者为首都经济贸易大学密云分校专家孙远芳,段翠华,中...

2068

扫码关注云+社区