关闭

频繁改动下的回归测试

204人阅读 评论(0) 收藏 举报
分类:
在拥抱变化的敏捷时代,这样的一个问题会有更多、更深入、更好的思考。
---------------------------------------------------------------
是否可以先解决一个问题:为什么项目会频繁改动?需求的原因?开发送测质量的原因?测试是否彻底?

--希望能把回归测试的有效和高效放在一起来谈--
1. 有效性,频繁的改动须保证每次回归测试的有效性,如果只是为了完成了回归而做回归,对回归测试版本的控制,BUG的修改控制没有做到位的话,任何所谓高效的回归测试也只能是在做些无用功。控制好测试版本,严控测试的出口和入口是进行回归测试首先要解决的问题;

2. 若是提到高效回归,肯定会谈到自动化,希望能通过自动化来解决回归测试的效率问题(关于自动化测试对人员、时间、资源的要求不在重复)。是否选择自动化、如何实现自动化就看所做产品/项目的情况了(较成形的大型产品都会涉及自动化测试,前期设计好的、需求变化不大的项目会用部分的自动化进行回归)。

3. 进行回归测试需要关心的另一个问题是:主要流程和修改涉汲的主要问题。
1)主要流程是用户实际操作运用最多的,当然要首先保证。
2)修改涉汲的主要问题可以帮我们分析问题,确定测试范围和测试重点。全面的测试当然最好,考虑到时间关系,最好是能有所侧重。

4.关于问题修改的方式问题
高内聚,低耦合。从这个关点来看,除非是操作流程引起的实现方式的改变,每个问题所涉汲的修改内容应当是有效和可控的。如果修改一个问题所关联的是全流程,一方面要全面测试,另一方面建议开发对功能进行剥离,减少耦合度。毕竟高质量的修改代码所能产生的问题的可能性也会大大降低,测试人员可以将关注点集中在主要问题影响,而不只是些问题的表像。

5.沟通合作问题
与需求和开发的沟通是有效和高效进行回归的关键问题,只有明确了对上一版本的修改状况,修改内容,以及修改的方式、方法,才能更有效的展开测试问题分析、测试进度安排、测试有例覆盖,才能更有效和高效的展开回归测试。
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:25732次
    • 积分:1003
    • 等级:
    • 排名:千里之外
    • 原创:127篇
    • 转载:18篇
    • 译文:0篇
    • 评论:2条
    文章分类
    最新评论