还好
:victory: 原帖由 skyjun 于 2008-12-3 10:43 发表 http://bbs.51testing.com/images/common/back.gifQTP 高效的完全回归测试方法。。。对修改的模块进行周边回归测试验证是否引起水波效应
若实现自动化，那就是不间断测试，回归也只是验证自动化脚本，达到预期效果
但这不现实，大多数还是手动的，凭借测试人员的经验来回归，保证修改功能的正确性，对整体不能掌控
有效回归测试与高效回归测试
是否可以先解决一个问题：为什么项目会频繁改动？需求的原因？开发送测质量的原因？测试是否彻底？－－希望能把回归测试的有效和高效放在一起来谈－－
1. 有效性，频繁的改动须保证每次回归测试的有效性，如果只是为了完成了回归而做回归，对回归测试版本的控制，BUG的修改控制没有做到位的话，任何所谓高效的回归测试也只能是在做些无用功。控制好测试版本，严控测试的出口和入口是进行回归测试首先要解决的问题；
2. 若是提到高效回归，肯定会谈到自动化，希望能通过自动化来解决回归测试的效率问题（关于自动化测试对人员、时间、资源的要求不在重复）。是否选择自动化、如何实现自动化就看所做产品／项目的情况了（较成形的大型产品都会涉及自动化测试，前期设计好的、需求变化不大的项目会用部分的自动化进行回归）。
3. 进行回归测试需要关心的另一个问题是：主要流程和修改涉汲的主要问题。
1）主要流程是用户实际操作运用最多的，当然要首先保证。
2）修改涉汲的主要问题可以帮我们分析问题，确定测试范围和测试重点。全面的测试当然最好，考虑到时间关系，最好是能有所侧重。
4.关于问题修改的方式问题
高内聚，低耦合。从这个关点来看，除非是操作流程引起的实现方式的改变，每个问题所涉汲的修改内容应当是有效和可控的。如果修改一个问题所关联的是全流程，一方面要全面测试，另一方面建议开发对功能进行剥离，减少耦合度。毕竟高质量的修改代码所能产生的问题的可能性也会大大降低，测试人员可以将关注点集中在主要问题影响，而不只是些问题的表像。
5.沟通合作问题
与需求和开发的沟通是有效和高效进行回归的关键问题，只有明确了对上一版本的修改状况，修改内容，以及修改的方式、方法，才能更有效的展开测试问题分析、测试进度安排、测试有例覆盖，才能更有效和高效的展开回归测试。 1.如果人手充足，可以调配资源，换不同的测试人员执行回归测试，这样可以减少重复性工作的厌烦心理。
2.稍有经验的测试人员，或者有开发经验的测试人员，可以对修改内容所能影响到的功能进行猜测判断。在执行回归测试时，除对bug发生功能进行测试外，并对涉及到的功能进行测试，并小范围扩展测试。
3.可以和开发人员沟通，请他们提供修改时可能涉及到的功能，依据这些来判断回归测试的范围。
4.用自动化工具执行的测试比较好办了，维护更新好脚本后直接执行。
当然，每次回归测试应该把用户常用到的业务都执行一下
其他的方法再想想
[ 本帖最后由 ancharfox 于 2008-12-4 16:13 编辑 ] 关于这个问题 我觉得可以从几个方面来提高
1. 测试提早介入
不管是开发新的功能还是FIX BUG, 测试的提早介入会让后期的很多不必要的工作减少很多.
在开发完成CODE后,让测试的兄弟过去看下,并在开发的机器上进行VERIFY工作, 第一可以确定相应的功能是符合需求的; 第二, 在进行VERIFY的时候可以稍微延伸一下, 确保关联的其他部分不会因为这部分的改动被影响到.这样的话就可以从开发那边就减少了回归BUG的产生, 甚至一些与需求相孛的现实.
2. 要有场景测试, 类似于Smoking test, 但比Smoking要详细, 这个场景测试的目的不仅为了确保所拿到的包是一个可以作为测试用的输出, 还应该确保这个包中所有主要的功能是可以WORK的, 覆盖一些在这个阶段没进行选择性重复测试的模块以确保这些模块大体是没问题的.
3. 在做PLAN之前与开发一起对新的功能和FIXED BUG所带来的影响进行分析,并根据模块被影响的大小排序, 这样就可以在有限的时间里测到影响最大的模块. 这是测试用例的选择性重复测试.
4. 在一定的周期里要确保所有的测试用例都被测到过. 从大的宏观上看, 这一个周期就是一个完全重复测试, 如果资源足够的话, 这个周期可以相应缩短一点.
5. 自动化. 最高效莫过与全部将其自动化了, 但现实是残酷的, 不可能的事情, 我们可以部分实现, 比如说上面提到的场景测试. 这个就不详细描述了.
6. 接着还可以从流程角度来谈这个问题, 其实如果一个项目的流程比较好的话, 大部分无谓的问题都可以避免, 但事实是, 就算有一个好的流程, 这些问题还是会不停的发生, 唯一的原因是大家不遵守, 不去重视. 所以, 避免回归, 实现高效还应该抓流程, 比如说版本控制; 修改的限制(评估修复BUG带来的风险, 对风险的BUG可以暂时搁置); 等等.
暂时想到就这么多, 有点乱. :) 我谈一下我的看法，目前自动化测试还没有推广起来，商业化的自动化测试工具价格不菲，测试脚本的开发代价也很大，自己开发测试框架就更难了，不是大多数公司能做到的，为了优化回归测试的效率，还是要从测试本身出发，从测试设计着手，要清楚所有测试用例对应覆盖的需求，在做过大量的测试分析后，会对各个模块及模块间的关联有比较清楚的认识，对用例划分重要程度，根据测试需要可以舍弃部分不重要的用例。另外，要对开发的变更管理好，要开发设计人员，对每次变更评估涉及范围，如果明确涉及的面比较小，就没必要全部回归了。 个人认为：鱼和熊掌不能兼得，完全回归测试不现实，抓重，弃轻
分析问题，解决问题
在回归测试之前，首先要分析问题，然后就是计划，最后就是解决问题啦，下面我就个人经验发表下想法，请大家讨论：1，分析回归测试前后的版本的变化之处；
2，list出和改动之处密切相关的边角功能点；
3，design出系统的主要流程；
4，有条件的话可以进行自动化测试，那就是准备自动化脚本了；
其实上面的除了1，2，其他的都是测试前期和过程中就要准备好的了。
测试的step可以为：
step1：进行主流程测试，保证整个流程没有受影响；
step2：进行1中的bug验证，并对改动部分进行联合测试；
step3：对2中的list进行测试，最好结合step1进行逻辑验证；
step4：run 自动化脚本，可以每天run一次；
step5：主流程测试，不同的人进行下不同的手工还是必要的。
其中step可以根据实际情况来灵活安排，重点就是1到4的分析要做到位。
开发人员与测试人员共同的事
看到这个问题，好多人觉得这是测试人员的事，其实我觉得如何更高效的进行回归测试应该是开发人员和测试人员共同的事。为什么这么认为呢？举个简单的例子：一些开发人员修改完bug，他们觉得自己的bug都已经fixed，然后兴高采烈地通知配置管理员发布新的版本，结果测试人员刚跑几个模块，系统就崩溃了。这怎么让回归测试进行下去呀？所以我觉得要进行高效的回归测试，按角色分
应该从以下几个方面着手。
首先，开发人员应该做到以下两个方面：
第一， 开发人员在发布新的版本之前要做smoke testing,尽可能早的发现一些影响测试的严重bug;
第二， 开发人员在修改bug状态的时候，要注明修改了哪个模块的哪些函数，这些信息有助于懂代码的测试人员去分析判断该bug是否真的修复好并对系统产生哪些影响。
其次，测试人员应该尽可能的从以下几个方面着手：
第一， 要熟悉系统的业务流程。对于该bug（或新增功能）的业务需求以及关联模块要很清楚，可以尽快进入测试状态并保证测试的质量
第二， 及时更新测试用例，保证执行的测试用例是最新的
第三， 要掌握测试用例的优先级别，也就是分清孰轻孰重，把时间花在刀刃上。对于优先级高的功能优先并充分测试，时间允许的前提下再测试优先级低的功能
第四， 借助自动化工具测试相对稳定的功能
第五， 沟通，及时与开发人员进行有效的沟通，更多地了解业务及系统，及时反馈测试情况
第六， 有效的测试管理，作为测试经理应该对于自己的组员有足够的了解，根据测试人员的技能，合理分配测试任务
最后，我觉得测试人员应该熟悉系统开发的语言。
以上是本人的一些想法，希望大家补充啊！ ddd 好哈哈哈哈
回归测试的把握有点困难那，需要测试经验
先说发生在身上的事情，完全回归产生的问题，在着急上线的情况下，开发人员改好bug，直接送测，因为不能保证开发自测通过，所以第二次完全回归还剩下百分之六十的问题，还让我们三个测试人员花了两天的时间，下次送测的时候又考虑要全面回归，结果把这次升级的战线拉的很长，版本迟迟不能发布，好的功能依然好着，不好的功能依然不好，所以我深深考虑到如此回归测试不是办法。如何高效的进行回归测试能，我想需要主要下面几点
1、自动化测试工具的使用，如果条件允许，项目也适合自动化的时候，最好在每次回归时，还是要自动化去运行整个重要的场景，这样可以整个软件的质量，最起码冒烟测试是通过的，自己手工在验证一些待回归的bug和一些问题比较重要自动化测试又没有跑到的点，这样回归测试的质量就比较高了，也比较能保证软件的质量
2、没有自动化的情况下，并不是所有公司都能做到软件的自动化也不是所有的项目适合自动化，在不能自动化的情况下，我觉得重要的是如何又快又好的回归，缩短回归问题的周期呢？
a、每一轮测试结束，总结发现的问题，总结问题的严重性，如果有比较严重的级别，冒烟不通过，这种bug的修改成功影响到了测试继续的进行，就可以写给开发email，下次送测必须解决的问题，因为这些问题影响到继续测试，当下个版本发过来，首先验证该问题，如果没有解决这些问题，可以直接打回，不再做其他的测试，让开发尽快修改
b、如果问题都不是特别严重的话，考虑修改的情况，大概有百分之多少修改了，如果超过百分之五十的问题没有修改，打回去重新修改，等待下次送测
c、满足上面两个条件都没有被打回去的情况下，尽可能完全测试，只有经过反复完全测试的版本才是稳定的
建议第一二次要完全测试，因为测试往往不能在第一次测试中发现所有的问题，最后一次一定是完全测试，保证测试的质量，如果这些时间都没有，那回归测试只能针对bug回归了，这是就一定给用例分出优先级，一定要测试最高优先级的用例，保证软件基本质量。
新人学习
嗯`不错！个个都说得很好~:)
页:
1
[2]
