以DevOps的速度持续测试.docx

以DevOps的速度持续测试 “即使你有一辆玛莎拉蒂，你也需要一个知道怎么开车的司机。速度很重要,但是安全性和准确性也是关键”——鲍勃·艾洛Parasoft公司最近举办了一次由鲍勃·艾洛，CM中心的技术主编和Wayne Ariola，Parasoft公司首席战略官以及Continuous Testing的作者主讲的“在DevOps世界持续测试”的网络研讨会。网络研讨会座无虚席，反响热烈。关于研讨会的内容我们将在这里强调几点。什么是DevOpsDevOps是一组可以帮助你更有效地进行交流和合作的原则和实践。为什么呢？因为开发人员比起其他人员（如质量测试或运维人员）知道更多重要的信息。如果你的团队是想要迈向成功，你需要能够利用这些知识和经验。DevOps的一个关键部分是创建“自动部署流水线”，部署配置经常根据需求变化（如bug修复、新功能、架构的变化等）且需要绝对可靠。什么是持续测试摘自维基百科：持续测试是自动化测试的一个过程，也是软件交付过程的一部分，能及时获取软件候选版本相关经营风险的反馈。对于持续测试，测试范围是验证从下而上的需求，或者说通过使用场景以及首要的商业目标验证系统需求。我们是否做过测试？错误的问题！当评估一个候选发布版本风险的时候，大多数软件团队问这个问题，“我们是否做过测试”，从根本来说，这是一个错误的问题。伴随着DevOps和持续交付，快速高效地发布软件要求对软件发布相关的商业风险有及时的反馈。鉴于成本上升和软件故障的影响，你不可能接受开发一个版本，该版本可能破坏现有的用户体验，或引入新的功能导致团队出现新的安全性风险、可靠性风险或合规风险。为了防止这一点，该团队需要按照总体经营目标，自下而上的做系统需求评估。软件开发团队可以使用“该候选版本是否是可接受的业务风险”来取代“我们做测试”这句话。如果我们能够回答这个问题，我们可以确定该应用程序是否可以随时交付。下一代的测试是什么样子？首要目标将业务预期和开发/测试活动之间的差距缩小。首先，我们必须将业务（运行时）数据与实际用户体验关联到我们的测试环境中。同时我们也将使用模拟器来尽早的开始测试并以必要的频率持续运行。我们会不停的测试需求以及进行自下而上的变更验证。这仍需执行，但它需要被设计在一个环境中，以便将它集成到一个连续的回归套件用于验证用户体验。了解新功能对于整个系统的影响是准确的评估候选版本风险的关键。所有的测试都需要被放置到一个回归测试套件中来衡量业务目标，然后“智能程序”可以更好地理解该变化的影响。这将引导我们完成以下两点。第一点，更完善的探索性测试，边缘测试案例和更多的实验性测试可以带来更多不同的结果。第二点，自动化验收测试。这是为了确保对于现在的用户体验来说没有负面影响。从自动化测试到持续测试的关键因素是什么？自动化测试涉及到的自动化、持续集成执行的任何测试都是团队的积累。然而，如果这些测试中的一个失败了，这真的意味着：这是一个关键的商业风险，还是只是违反了一些没多少人遵循的命名标准？它失败时发生了什么？是否有一个根据商业风险优先级以及最重要问题排序的清晰的工作流程？对于每一个缺陷的认证、修复，是否有一个方法来暴露所有已被引用的问题，以防止同样的问题在未来重复发生？这是自动化和持续的最明显的区别。从自动化到持续，你需要以下几点：清晰定义每一个应用程序、团队和发布的业务风险。相对业务来说的自动优先级缺陷，并了解如何在版本发布之前释放这些风险。持续模拟完整测试环境中测试变更的影响，这是保护当前用户体验的关键缺陷预防反馈回路——寻找出现的模式，并以此为契机设计以及实施缺陷预防措施防止类似缺陷再次发生。虚拟化服务如何融入 DevOps 和持续测试？在团队开始加速他们的软件交付流程，他们经常指出那些范围需要测试，但是由于没有一个完整的测试环境而不能执行AUT。许多团队使用类似服务虚拟化之类的仿真技术来规避这些问题。例如：你的主机只有周六晚上可以使用两小时，你可以用它来记录AUT的互相作用并捕获这一虚拟资源，你可以同样的方式做数据库、第三方应用、SAP、等。仿真技术并不完美。但是为了让我们脱离该方法执行“大的块”并获取相关风险，我们需要执行探索性测试……所以我们不能没有模拟。为了真正保护最终的用户体验，我们需要大量的测试以及关键的端到端的处理。对于当前系统来说，这些处理需要大量不同的组件，所以它是非常难以适用于单元测试环境中。模拟技术帮助我们绕过这些问题。对于最正式的模拟环境，我们需要真正理解组件如何在运行环境中工作，并将此转换为模拟。马上看“在DevOps世界持续测试”研讨会想知道更多么？你可以在方便的时候观看完整的60分钟会议。原文：/continuous-testing-in-devops