实战：忘不掉的回归测试_忘不掉回忆

先说我理解的回归测试，需求或缺陷编码完成后，除了跑新改动相关的单元测试，集成测试，系统测试外，还得对现有功能相关的测试集合跑一遍的过程。新功能逐步成为旧功能，当然也应该成为测试回归的一部分。不管是电信行业、电商行业，还是自动驾驶行业，只要涉及软件开发，都理应如此。

喜欢晴天

前两天听公司测试工程师在讨论，什么样的场景应该跑回归？按照我的理解，理想情况，如果人力、机器允许，所有经过维护的测试用例都应该进行回归。理想一般不太可能实现，那怎么办？花最少的成本最快的发现问题，先跑出来最可能出错的场景，一旦失败就不往下跑了，解决问题后重新开始，以便达成快速反馈的目的。

在时间充足，资源齐全，成本可控的前提条件下，还是首要考虑全面测试，资源稀缺本来就是常态，这也是管理学的魅力之一。只有有效的从源头避免风险，才能有效的进行回归测试。那么首先应该做什么呢？先定义核心场景，根据ABC法则等定义把最容易出错、最核心功能、新功能相关按照场景提炼出来，冒烟、高、中、低等。同时，系统能够设置不同的标签来区分场景，比如哪些是新功能，哪些是这个模块的，哪些是另一个模块的，方便紧急情况下，灵活按需跑回归测试。比如，明天需要给客户demo今天刚刚开发完成的功能，就把测试用例中级别比较高的用例先执行一遍，确保核心功能没有问题。

还得综合考虑效率和覆盖度，回归测试用例的筛选考虑一些原则：验证产品核心功能相关的用例、系统新增功能相关的用例、系统新增功能的关联功能用例、系统最有卖点或最有亮点的部分功能用例、系统最致命的功能（比如自动驾驶安全隐患）用例、系统比较脆弱的部分用例、经常有缺陷的用例、用户频繁使用的功能用例、变化较多和最新变化的用例、开发者最没有信心的功能相关的用例。

最安全的方法是自动化测试+手工测试相结合，探索性测试&交叉测试要用起来：每日持续构建跑回归测试用例；编写用例时一定要分级别（按照风险度，常用度，重要度等角度）；前期单元测试时加强回归测试，引入代码评审；确保集成和系统级的测试时，加强测试用例评审；定期维护测试用例增，删，保持最新状态；发现问题及时分析，补充对应的测试场景（若需）；增加随机测试，避免回归测试盲点；基于交叉测试：多人互动的回归测试，尤其在核心的功能点，交互性比较的。

我接下来会做的建议：利用标签区分用例级别、子系统、特征场景等，在持续集成环境下按照优先级区分每日构建计划，确保经过二八选择筛选出来的高优先级的用例先跑回归，快速反馈，每天跑一次全集。若有紧急需要需要落地，可以结合子系统、特征场景等标签，先跑优先级高的特定场景。

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/te-hg/8569.html