软件测试策略:从端到端测试到消费驱动测试
1. 端到端测试的挑战
端到端测试存在诸多挑战。当开发者完成其他任务后再回头处理端到端测试问题时,大脑的上下文切换十分痛苦。虽然可以通过并行运行测试(如使用 Selenium Grid 工具)来缓解部分问题,但这不能替代真正理解测试需求并移除不再需要的测试。
移除测试是一项棘手的工作,就像移除机场安检措施一样,无论这些措施多么无效,讨论移除它们时总会引发一些本能的反对,认为这是不关心安全或让恐怖分子得逞。在评估测试的价值和负担时,很难进行平衡的讨论,这也是一个艰难的风险/回报权衡。例如,移除一个测试可能会得到感谢,但如果移除的测试导致了一个漏洞进入生产环境,就肯定会受到指责。
端到端测试的长反馈周期不仅影响开发者的生产力,还会导致部署问题。如果测试套件很长,修复测试中的问题需要很长时间,这会减少端到端测试通过的时间。如果只部署通过所有测试的软件,那么可部署到生产环境的服务就会减少,从而导致积压。随着部署范围的扩大和发布风险的增加,出现问题的可能性也会增大。确保频繁发布软件的关键是尽快发布小的变更。
2. 元版本的问题
在端到端测试过程中,很容易产生将多个服务一起部署并使用一个版本号的想法。但这样做会放弃微服务的一个主要优势,即能够独立部署单个服务。随着时间的推移,多个服务一起部署的方式可能会导致服务之间的耦合,原本独立的服务会变得越来越纠缠在一起,最终可能比单体应用的情况更糟糕。
3. 测试旅程而非故事
对于一两个服务,端到端测试可能还可以管理,但随着服务数量的增加,测试套件会变得臃肿,测试场景会呈笛卡尔式爆炸。如果为每个新功能都添加一个新的端到端测试
超级会员免费看
订阅专栏 解锁全文
1300

被折叠的 条评论
为什么被折叠?



