测试团队一直在自动化测试上面花费的大量的时间和尽力。这样的开销似乎并不符合预期。另外，应用程序的架构，开发的使用方式也在不断的发生变化，这样一来也增加了测试的复杂性和软件故障。
鉴于当下应用程序交付的复杂性和交付速度的增加，软件测试人员如何辅助控制业务风险？--进入连续测试。
连续测试？？#
持续测试是将自动化测试作为软件交付管道的一部分的执行过程。便于尽快获得与软件发布相关业务风险的反馈。
自动化测试皆在生成一个应用程序定义好或相关的"通过"/"失败"的数据点。另外，持续测试侧重于业务风险，并提供有关软件是否可以继续发布的“见解”。
要实现上述，我们必须从“我们是否进行测试某个功能？”我们是否进行了测试？“转到”即将发布的应用程序的风险是否在可接受的范围内。“
为什么需要持续测试？？#
当下的测试内容更多，使用传统工具和方法作用于自动化测试上实现更困难。
1, 应用程序体现结构分散和复杂，包括云，API，微服务等，并且这些在业务中通常都是不同的协议和技术组合。
2，对于Devops中的持续交付中，更多的应用程序从每周发布一两次，到每天发布无数次。因此，用于测试设计，维护和执行时间也会大大缩小。
3，软件程序故障也就是业务故障，如果影响到用户体验，即使看起来微不足道的小故障也会产生不可预计的后果。因此，与应用相关的风险仍然是非技术性业务支撑团队需要关注的点。
自动化测试与连续测试不同？#
连续测试与自动化测试最大的区别可分为：风险，广度，时间
风险#
在当下企业中，应用程序涉及到的业务范畴非常广，例如：一个购物商城不单单只有我们看到的货架种类，推荐消费等，还有积分处理，账单处理，物流信息等。向用户提供越多的功能同时也意味着的潜在故障点的数量，种类和复杂性。
如果测试用例中没有考虑到业务风险，那么测试结果将无法评估风险中所需的洞察力。如果测试皆在提供产品是否实现需求的低层次信息，而不是评估发布的版本是否存在高风险。
如果没有，那么你的测试与业务风险不一致。
在进行低粒度测试的同时仍然需要更多的措施来评估或者阻止高风险的发生。
广度#
即使一些微不足道的故障，也会带来不必要的麻烦。特别是在用户体验差强人意的时候，亦或者某些部分出现问题的时候。
单单从单元测试和UI测试通过并不是说这些修改会影响到用户整体体验。为了更好的保护用户的最终体验，需要足够广泛的测试来检测应用程序更改没有在无意中影响到用户所依赖的功能。
时间#
当下，软件迭代的速度也成为了许多团队的竞争优势，很多都在转向敏捷和devops以加速其交付流程。
当自动化测试出现，测试根据瀑布式开发过程构建和更新。这种条件下，在测试没有完成之前，当下进度将会暂停。
这并不敏捷。测试必然需要和开发并行开始，否则，产品不太可能在极短的时间内完成迭代，并进行测试宣告完成。
如果已经开始devops并且正在执行持续交付，则可能每个小时或更频繁的发布应用软件。这种情况下，每个阶段的过程反馈不能只是快速，几乎是瞬间完成的。如果质量不是应用程序首要考虑因素(例如：生产中发生缺陷影响较小)，则在每个版本运行一些单元测试和冒烟测试就足够了。但是，如果企业希望最大限度的降低故障，则需要一些方法来实现必要的风险覆盖水平并快速测试。
对于测试，有几个重要的影响：
- 测试必须成为开发过程的一部分，而不是在开发完成时处理”尿不湿“的任务
- 几乎在使用相关功能后，测试必须准备好并运行
- 团队必须有办法确定在交付管道中的不同阶段进行正确有效的测试，如：烟雾测试，集成后的API和消息层测试，系统级别的端对端测试等等。
- 每组测试必须足够快的执行，以避免软件交付的某个阶段产生瓶颈
- 需要一种稳定的测试环境方法来避免频繁更改造成的大量报警
自动化测试不等于连续测试#
自动化测试不等于连续测试，连续测试大于自动化测试。
即使是使用传统测试自动化早已成熟的团结，当采用交付方法时候，也会出现很多问题，比如：
- 无法足够快或足够频繁的创建和执行测试
- 持续应用程序更改会导致大量的错误报告，这些大多可能都是误报，需要看似永无止境的测试维护量
- 无法即时了解发布版本是否存在风险太大而无法通过交付管道
最后，我想说没有任何工具或者技术可以立即做好连续测试，与敏捷和Devops一样，连续测试需要在整个人员，流程，技术方面进行变革。然而，当目前技术不能够完成任务，尝试做一些人员和流程的变化。这仍然可能会导致失败。