持续测试及如何实现？

　　持续集成需要代码保持工作。持续交付和连续部署只是加大赌注，比如我们必须能够随时为生产推出一个工作配置。 证明代码和配置保持工作的唯一方法是测试它们。这就是为什么我们需要连续的测试。

　　在你自问如何可以用过去的方法使这一切自动化之前，不妨考虑一下：在 DevOps 和自主的"两个披萨饼"大小的开发团队取得成功而大型应用程序被分解成更小的独立组件之时，不仅是事情发生得更快了，而且更多的事情发生了。你怎么跟得上 那些呢?如果你喜欢等待的兴奋,那你可以就这样把未测试的代码投入生产,并让你的部分用户为你进行测试，直到用户在问题解决之前就受到影响；或者你可以找一个新的方法，在他们受到影响之前进行测试。

　　这个新的方法就是 持续的测试。面对现实吧:你有着一个庞大而且不断增长的“应用程序端点”列表，它们必须“始终工作”来为你实现持续交付。如果一切都变得“持续”了，所有这些新的测试将来自于哪里呢?如果有需要的话，是不是可能以每隔几分钟、每隔一天的频率来创建测试呢?

　　不要只是向左转变。朝着所有余下的方向转变，转向那些最了解你的代码之处

　　一些开发商店转变了“一路向左”的测试方式，他们知道答案。今天的软件工程师生活在这样一个世界里：DevOps成为常态,而bug在生产中是开发人员的个人问题。Dev's 受到了高度激励，来证明他们的代码做了应该做的。他们想立即(和远在任何事项部署到生产环境之前)知道他们正在做的代码更改是否打破了什么。

　　那么“一路向左”的转变意味者什么呢?它意味着测试与代码单元来自于同一个地方。这可能指的是开发人员、或敏捷测试人员在相同的小组中工作。秘诀就是将测试减少为简单但是有效的、人可读的代码，我们称之为"测试蓝图"。开发团队在本地进行测试以便在编码的同时获得即时反馈，然后同时检查代码和测试蓝图到源代码中。再也不用运行某一构建却只是为了发现代码是在保持工作，但是打破了一些现有的(下游建立的)测试。

　　在实现这一转变的组织中,性能工程师和“测试工程师”自动化专家们从构思一个测试构建工作的待办事项列表转变为由所有人共同促进测试。

　　一直有一个工作测试。当你需要任何测试时，在几秒钟之内运行，永不等待

　　当一个接一个客户开启这一新旅程之后，你就会清晰地发现：持续测试不仅仅是可能的，当开发人员配备了低摩擦测试的能力、并有望将使用任何新开发的或更新了的代码来检查工作测试蓝图时，它就是“新常态”。有了一路向左的测试转变，持续交付组织总是只需要几秒钟的时间就能证明代码已经准备好了并且在为可接受的服务水平工作着。

　　一旦你向左转变了，决定在没有人为干预的情况下要测试什么、组装测试和执行测试只是基本的CI。无论测试范围是一个代码模块还是一个完整的版本，正确的测试都是通过跟踪依赖关系联机组成，正如你在构建代码本身一样。更妙的是,人工只在测试失败时才参与和分配新的工作。这一切都以编程的方式发生于代码签入或构建或部署试验的 几秒钟之内。

　　顺便说一下，“几秒钟之内”是在持续交付中你负担得起的唯一的“性能测试待办事项列表”。

　　乍看之下这似乎太难了。再看一遍，总是再三查看（玛丽•安妮•拉德马赫）

　　那么，欢迎来到持续测试的时代。对许多人而言，持续集成本身在其第一次出现时，可能听起来是不可能的。但是很久以前的“总是有一个工作着的构建”已成为了新常态。持续测试将会走上同一条道路,只不过会走得更快。你可能仍然想知道，“在这一点上，这还仅仅是科幻小说吗？”基于我们与我们的客户已经看到的事实，威廉•吉布森是正确的。他说：“未来已经在这里了——只是分布不均匀而已。”

　　本文由寄云科技编译，未经授权谢绝转载。欢迎关注寄云科技订阅号（neuclouddy），这里有最新云服务行业资讯，更有与PaaS、运维相关的技术干货！