鉴于软件交付的复杂性和速度的增加，软件测试专业人员如何帮助控制业务风险呢？
重要的是要认识到没有任何工具或技术可以立即给你持续测试。与Agile和DevOps一样，持续测试需要在整个人员，流程和技术方面进行变革。然而，当你的技术无法完成任务时，尝试启动人员和流程的相关变化，从一开始就是一场艰苦的战斗......最终会失败。
即使一家企业设法避开大型软件失败成为头条新闻，即使是看似微不足道的故障仍然可能会造成麻烦。如果用户体验的任何部分未能满足他的期望，您不仅有可能将该客户丢失给竞争对手-如果该用户决定将他的问题带到社交媒体上，您还可能面临品牌损害风险。
只知道单元测试失败或通过UI测试并不能告诉您最近的软件更改是否会影响整体用户体验。为了保护最终用户体验，您需要足够广泛的测试来检测软件更改何时无意中影响用户所依赖的功能。
持续测试>自动化测试
为什么我们需要持续测试？
你需要的是持续测试。
持续测试和自动化测试之间的主要区别可分为三大类：风险，广度和时间。
持续测试>测试自动化
CC先生说，持续**的名词模式已经成为现在企业转型的一个热度词汇。
今天，整个行业的变化要求测试更多，同时使自动化测试更难实现：
他们不能足够快或足够频繁地创建和执行真实的测试持续的软件更改会导致大量的误报，并且需要看似永无止境的测试维护量他们无法提供关于发布版本是否风险太大而无法通过交付渠道的即时洞察
自动化测试≠连续测试
需要明确的是：我们并不是说低粒度测试没有价值;我们要说的是，需要更多的措施来阻止高风险的版本失去控制。
持续测试与自动化测试有何不同？
持续进化终归是演进的一个大前提。
大规模的“软件失败”产生了如此严重的业务影响，以至于与应用相关的风险现在成为企业公共财务报告的重要组成部分。鉴于[值得注意的软件故障导致股票价格平均下跌-06％]，企业领导人正在注意并期望IT领导者采取行动并不奇怪。
如果您的测试用例没有考虑到业务风险，那么您的测试结果将无法提供评估风险所需的洞察力。大多数测试旨在提供有关用户故事是否正确实现要求的低级详细信息，而不是高级别评估发布版本是否风险太高而无法发布。你会根据测试结果立即停止发布吗？如果没有，您的测试与业务风险不一致。
不管是精益中提倡的持续改善，还是Devops里提倡的CI-CD-CT-CD
自动化测试旨在生成一组与用户故事或应用程序要求相关的通过/失败的数据点。另一方面，持续测试侧重于业务风险，并提供有关软件是否可以发布的判断。要实现这一转变，我们需要停止询问“我们是否已完成测试？”而是集中精力在“发布版本是否具有可接受的业务风险级别？”
即使是使用传统测试自动化工具取得了相当成功的团队，当他们的组织采用现代架构和交付方法时，也会遇到严重的障碍：
测试必须成为开发过程的一部分实现完相关功能后测试必须马上准备好运行组织必须有办法确定在交付管道的不同阶段执行的正确测试每组测试必须足够快地执行，以免在软件交付管道的相关阶段产生瓶颈需要一种稳定测试环境的方法来防止频繁更改导致大量误报
现在，组织运送软件的速度已成为竞争优势，绝大多数组织正在转向敏捷和DevOps以加速其交付流程。
什么是持续测试？
今天的企业不仅向最终用户展示了他们的许多内部应用程序，他们还开发了大量额外的软件，可以扩展和补充这些应用程序。例如，航空公司远远超出了飞机预订系统。他们现在让客户计划和预订完整的假期，包括酒店，租车和游玩活动。向用户展示越来越多的创新功能现在是竞争优势-但它也增加了潜在故障点的数量，种类和复杂性。
对于测试，有几个重大影响：
如果您的组织正在开始或扩展您的持续测试自动化工作，我们建议您查看Forrester和Gartner的两项新研究。这两份报告都提供了对持续测试和测试自动化趋势的深入了解，以及顶级持续测试工具的比较。
面试资料
当自动化测试出现时，它专注于测试根据瀑布式开发过程构建和更新的内部系统。系统都在组织的控制之下，在测试阶段准备好开始之前，一切都已完成并准备好进行测试。既然敏捷流程正在成为常态，那么测试必须与开发并行开始;否则，用户故事不太可能在极度压缩的迭代时间范围内进行测试并被视为“完成”。
测试人员多年来一直在与自动化测试进行斗争，但大多数团队对他们当前的自动化测试水平或维护它所需的开销不满。此外，在过去几年中，软件的架构，开发和使用方式也发生了翻天覆地的变化-增加了测试的复杂性和软件故障的业务影响。
持续测试是一个过程，它将自动化测试作为软件交付通道中内嵌的一部分，以尽快获得软件发布后业务风险的反馈。
文章为作者独立观点，不代表股票交易接口观点
相关文章
股民评论