BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

西门子医疗的持续测试经验

| 作者 Ben Linders 关注 29 他的粉丝 ,译者 李清玉 关注 0 他的粉丝 发布于 2015年3月12日. 估计阅读时间: 6 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

Marco Achtziger分享了西门子医疗在大规模敏捷项目中开展持续测试的经验。在德国举办的OOP 2015 大会上,他谈论了他们遇到的陷阱以及克服他们的方法。

InfoQ采访了Achtziger,谈论了持续测试和持续集成、持续测试中基础架构与社会性挑战、测试流程与工具以及改进持续测试。

InfoQ:您可否解释一下持续测试与持续集成是如何关联的?

Achtziger持续测试是持续集成的一部分。在大型项目中,持续集成的测试部分是非常复杂的,必须分别处理。但我认为他们互不分离。

InfoQ:在您的演讲中,您谈到持续测试在基础架构方面的一些挑战,可否详细阐述一下?

Achtziger你使用的工具非常重要,尤其是对于大型项目来说。作为产品软件本身,你也必须意识到这一点。例如基础架构的可扩展性或者可靠性。所以需要考虑的典型事情是:

  • 工具的可用性。理想情况下,测试执行的时候,开发人员不必做任何额外的东西。
  • 你是否必须并行地运行测试?如果是,基础架构是否支持?
  • 你的工具可否扩展?由此可以处理多台测试机器,并且能够简单地增加机器的数量?
  • 测试执行的瓶颈在哪里?例如,在我们的例子中,如果我们使用了工具提供的默认机制,那么虽然测试的执行不会有问题,但部署测试所需的二进制文件将会决定测试执行的时间。

InfoQ:您也谈到了持续测试所面临的社会性挑战。您都经历过哪些问题,以及如何解决的呢?

Achtziger你会发现这方面的主要问题就是“在我机器上好用”的老开发人员。在我看来,敏捷概念之前的软件开发流程支持了这样的思维模式(没有持续集成、测试仅在集成后运行,…)。不幸的是,并没有什么银弹来解决这个问题。在某种程度上必须做的就是改变开发人员的思维模式。在我们的环境中,有帮助的就是建立我们所谓的测试到处运行(TRA(Tests run anywhere))原则。通过给他们一些他们可以提供的帮助(“所有的测试到处都可以运行不是很好吗?”),就可能不会谈论负面的事情(“你做错了,因为它只在你的机器上工作”)。

InfoQ:您提到在测试流程中有多个阶段:团队整合、资源(Assets)整合以及系统整合。您可否分别描述一下不同的阶段,以及他们是如何在这个测试链中一起工作的?

Achtziger这是切分你的测试框架的一种简单方法。资源整合对我们来说就是工作在同一领域的几个团队的聚合。所以,如果你有这样的一个结构,你可以把你的测试按照这种方式划分:让团队执行单元测试,并且可能已经做了一些整合测试。下一阶段就是执行主要的整合测试,确保不同的团队不会互相影响,然后,作为最终的整合,所有资源的变化聚合到一起就称为所谓的系统整合。这样你就可以决定:是否要基于这些变化执行测试,或者是否想要建立一组静态测试,在其中包含所有的系统,并且确保它仍然工作。

InfoQ:对不同的阶段和构建,您是使用什么机制来选择那些必须执行的测试呢?

Achtziger原则上我们使用简单的XML文件,它与我们所编译的每个程序集文件共同放置在源代码控制系统中。该文件是可配置的,如果某些东西在那个地方做了更改,就应该执行什么样的测试。所以没有什么花哨的东西。非常简单有效。

InfoQ:当由于缺陷原因导致测试失败的时候,你们使用一种测试隔离的流程,它是如何工作的呢?

Achtziger首先应该清楚的是,测试的失败并不仅仅是由产品代码中的缺陷所造成的。当然有时测试代码本身也需要改进。但如果测试偶尔失败了,隔离流程就有效果了,你应该检查原因是什么。如果是一个严重的产品缺陷,接下来当然要修复缺陷了。如果缺陷不是很严重、问题出在测试代码本身,或者很难修复这个测试以使其重新回到绿色状态,你可以决定暂时关掉这个测试(例如使用NUnit的Explicit属性)。这样可以让你的编译回到绿色状态,他们再也不会被一系列的失败的测试用例所破坏。隔离测试的数量必须得到监控,应该尽可能地接近于0。所以整个的隔离是一个特例,用来处理偶发的测试失败,从而避免开发人员开始忽视编译结果,那样甚至会比偶发的测试失败更严重。

InfoQ:如果人们采用持续测试并且想要改进,您可否给一些建议?

Achtziger我认为首要的事情永远都是与系统的用户交谈。然后告诉开发人员并找出他们现有的痛点,以及在你的工具基础架构中如何支持。最好再看看其他一些事情:

  • 监控你的测试执行时间,并尝试不断地改进最慢的那部分。
  • 如果某个缺陷找不到,做一个深入的根本原因分析并且试图弥补差距。
  • 经常检查你的测试并且删除不需要的或冗余的测试。

如果你遵循这三件事情,我会说你涵盖了持续改进测试的主要部分。其他的事情通常是组织所特有的,并且是必须由组织自身处理的。

查看英文原文:Experiences from Continuous Testing at Siemens Healthcare


感谢邵思华对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT