从瀑布流到敏捷和DevOps，测试该如何改变

最新推荐文章于 2023-08-02 08:19:13 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2023-08-02 08:19:13 发布

阅读量379

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89152760

版权

Laurent Py在Hiptest上发表了博客《向左走向右走：测试的摇摆》，其中描述了当研发模式从瀑布流到敏捷到随后的DevOps，会如何影响测试。在敏捷测试日2015（Agile Testing Days 2015），他以此做了演讲。

InfoQ采访了Laurent Py，了解他们转型到敏捷和DevOps的原因和从“测试摇摆”获取的益处；在测试自动化策略和实施方便，如何通过度量行为改变，来找出一个特性是否是有价值的；以及他预计测试将会带来的特性。

InfoQ：在博客中，你探索了当研发模式从瀑布流到敏捷和现在的DevOps对于测试的改变。你能详细描述下为什么会做出这样的改变？

\
Py:这主要因为反馈的速度和精益启动的实践。10年前我的团队使用Java和Eclipse进行产品开发。我们每年做两次发布。这个流程的问题是反馈速度。在几个月里，我们开发和创建一个“资产”。但是由于它还没有交付到用户手上，这个资产的价值为0。从商业角度来说，当每年只有2次机会，我们很难快速适应和转变。
\\
因此，最初我们采用了敏捷，同时简化了流程。从工程师角度来看，这是非常有益的，因为我们每两周会出一个工作产品。但是由于这些产品无法立即部署到生产环境，我们同样有反馈速度的问题。用户不会希望没两周就安装一个发布版本。
\\
现在，团队在云上开发新的产品，一个为敏捷团队使用的测试管理平台（hiptest.net）。开发和运维协同工作，并且开始持续部署。由此，我们不仅有了优秀的工程流程，而且最终我们能够从用户获取反馈并且实时做出响应。对我来说，这就是实施敏捷和DevOps而获得的最大收益。
\

InfoQ：你从敏捷和DevOps中得到了什么收益？

\
Py:开发出产品是其一；将产品交付给用户是另一方面。因此获取快速反馈的能力，确实提高了团队的参与度。作为一个团队成员，我们能够看见所做功能的影响，并且不用再像以前那样，需要花费几个月才能得到结果。从工程角度来讲，这是非常困难的，并且需要许多训练，但这显然是值得努力的。我相信最终只有一个结局：用户和客户。介于二者之前的其他结果都不能算是成功。
\

InfoQ：你能解释下你所说的“测试摇摆”的含义吗？

\
Py:“测试摇摆”我主要想表示向左走和向右走。以前，测试基本上都在开发阶段之后和产品上线之前完成。目前，部分测试活动已经向左移：测试在开发阶段之前设计。这就是行为驱动开发（Behavior Driven Development，BDD）的实践。这能够使得团队成员对他们的最终产品的定义理解相同。所有利益相关方（测试、开发、产品负责人、市场）协作于：
\\
产品验收标准：样本\\
商业验收标准：待验证的假设\

然后，我们需要向右走：测试（A/B测试）和直接在产品中监控。重要的是，我们有一个实时用户反馈（通过实时聊天），以获取以前可能无法获取的问题。有的时候，错误的行为可能不是源于代码的错误，而仅仅是一个坏的用户体验或者数据达到一定量的时候才会出现。由于我们有快速的反馈，并且拥有持续部署的能力，我们能够在出现问题的时候快速反应。
\

InfoQ：在博客中，你提到了你在通过度量用户行为的改变，来判断一个新功能对于用户是否是有价值的。对此能否给一些示例，说明你是如何做到的？

\
Py：我们在Hiptest中加入了测试重构功能。这是一个关键的区分点，我们可以度量有多少用户真的使用了这项功能。但是度量影响是更重要的。我们已经度量到了，使用这个新功能的用户，增强了自动化水平，同时增加了Hiptest的使用度。因此，当开发一个新功能，并且度量它的价值，不仅仅是询问“是否有用户在使用？”，而是关于对我们商业上的影响和对用户工作流程的影响。
\

InfoQ：对于测试自动化，你的策略和实践是怎么样的？

\
Py:每个测试用例都应该讲一个关于应用程序的故事。当一个测试用例使用一致的业务术语定义（行为驱动开发实践），它的可读性会比较高，且容易自动化。这也是Hiptest支持的哲学。顺便说一下，我们使用Hiptest来测试Hiptest，并且使用我们的测试脚本实现100%的自动化。自动化部分通过图形用户界面实现，余下的直接使用API。当然，自动化测试用例和持续集成结合。再次强调反馈速度对于开发者来说是非常关键的。当开发者提交代码时，他需要快速知道这些代码是否破坏了什么东西。
\

InfoQ：你期望未来测试领域会给我带来什么？

\
Py：我希望测试会更加面向商业。一些人担心质量保证岗位会消失。我认为这是一个机会——如果能把握住的话。如果一个功能没有使用，或者没有给产品带来显著的价值，在功能正确性和性能上投入大量精力又有什么意思？这是测试人员的批判性思维能够发挥作用的时候。为什么我们要构建这个产品？我们构建这个产品的假设是什么？如果答案是肯定的，那么确保正确性才有意义。
\

查看英文原文：How Testing Changed When Moving from Waterfall to Agile and DevOps

感谢张龙对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）。