“持续集成”、“持续部署”想必如今每个软件行业的小伙伴们都耳熟能详，传说中的“CI/CD”。

“持续交付”，另一个CD(Continuous Delivery)随着前一个CD“持续部署”也能很自然而然想到。

是不是小伙伴们听到的DevOps和敏捷开发流程大体是这样的？

上述三个“持续”环节，直观地涉及到了研发、运维，对吧？

软件研发流程中不可或缺的“测试”步骤去哪里了？

有小伙伴会辩解道“CI”过程或者“CD”过程，包含了单元测试，或云“TDD”、“ATDD”等。

老司机这里告诉诸位，上述过程是个残缺版的DevOps。

完整版的DevOps是需要包含“4C”的，除了上述的三个“持续”，“Continuous Test”自古以来就是整个流程不可分割的一部分。

什么是持续测试

持续测试是一个过程，它将自动化测试作为软件交付通道中内嵌的一部分，以尽快获得软件发布后业务风险的反馈。

自动化测试旨在生成一组与用户故事或应用程序要求相关的通过/失败的数据点。另一方面，持续测试侧重于业务风险，并提供有关软件是否可以发布的判断。要实现这一转变，我们需要停止询问“我们是否已完成测试？”而是集中精力在“发布版本是否具有可接受的业务风险级别？”

为什么需要持续测试

随着移动互联网、云计算、大数据、AI的爆发，整个行业的变化要求测试更多，自动化测试疲于应付(至少使用传统工具和方法)：

应用程序体系结构越来越趋向于分布式和复杂化，例如：云部署、微服务等，即使在单个业务事务中，也可能有不同协议和技术组合。

由于Agile，DevOps和“持续”，许多应用现在每两周发布一次，每天部署很多次。因此，可用于测试设计，维护和特别是执行的时间大大减少。

应用程序故障就是业务失败，业务失败绝对会影响用户体验。即使是看似微不足道的小故障也会产生严重后果。因此，与应用相关的风险已成为即使是非技术性商业领袖的主要关注点。

怎么做持续测试

可以落地实施的持续测试(CT)，至少应该包括如下几个步骤：

01尽早规划测试

使用像行为驱动开发(BDD)， 验收测试驱动开发(ATDD)和 基于模型的测试这类技术所使用的工具，如：cucumber， 可以确保业务主管，产品经理，开发人员和测试人员充分沟通并记录需求，定义清晰的测试用例，提早编写测试脚本，以达到一个流畅的测试过程。

02优化测试覆盖率

使用可视化模型让各种路径被探索优化，以便尽可能少的的测试用例覆盖多数业务场景。可以借助 Rally，JIRA等类工具管理测试用例、分发优化过的用例。

03实现「迭代内(in-sprint)」测试

迭代包含测试过程，可以在开发周期的早期运行。自动化测试覆盖UI, 功能，性能和安全。敏捷团队多个角色一起工作，一起以要交付给客户的业务价值为专注点。这需要对开发者友好的工具以及真正敏捷文化推广。

04快速提供测试环境

提供测试环境的能力对实现持续测试是至关重要的。虚拟机、Docker容器化，都可以满足迅速准备、部署测试环境需求。

05提供贴合实际的测试数据

为了准确的测试新功能，测试数据应该尽可能的跟生产环境时所应用遇到的数据相近。需要敏捷团队中的PO、SM角色跨部门甚至跨组织沟通，随着迭代进行不断完善。

06部署配合测试

比较时髦的说法叫：“测试右移”。使用开发周期和生产中的数据来优化测试周期、调整测试用例，以建立最佳回归测试套件。右移技术包括真实用户监控、金丝雀部署、A/B 测试等。更高角度来看，需要研发、测试、运维等几种角色通力配合完成。

07持续优化

建立跨团队协作，根据可行性分析和反馈机制不断优化。这正是敏捷精神所在。

带队伍的测试小伙伴们，除了测试用例、测试计划、测试工具、bug追溯，培养自己的策略性思维、寻找方法论支撑，是绝对必要的。

否则团队内部吵架都不在一个认知基本面上，怎么赢得尊重？更何谈地位？

免责声明：文章内容转载自公开网络，如有侵权，请联系我们删除。