关于测试执行过程中的常见“拦路虎”！
经常听大家说，测试执行工作非常简单，没有什么技术含量，我个人不这样认为！从非专业的角度讲，测试执行就是拿着别人已经写好的用例执行就好了，如果发现bug，进行一个记录，仅此而已，但其实正是因为大家对测试执行过程中出现的一些常见问题，已经见怪不怪了，认为这些都是正常的情况，反而大大降低了测试执行的效率和效果。不说别的，就拿回归测试这项工作而言，反复的回归，反复的修改，好多缺陷都无法在第一时间快速关闭，真的就没有办法了吗？难道我们测试人员必须任由开发人员这样拖延下去吗？难道我们只需要发现问题，别的事情我们真的无能为力吗？下面我就列一些测试执行中常见问题，希望大家能就这些方面提出一些可行的解决方案，一定会让我们的测试执行工作更有效！更专业的！
问题1：测试执行过程中发现的bug数量庞大，我们还需要测试吗？
问题2：测试执行过程中遇到许多严重性甚至致命性缺陷，我们还需要测试吗？
问题3：测试执行过程中我们一个版本还没有测试执行结束，开发又提交了新的版本，我们是放弃这个版本，测试新的版本？还是要继续坚持测试旧的版本？
问题4：有些bug在测试环境下存在，但是在开发环境下却不出现，我们要记bug吗？
先提这几个问题，如果大家感兴趣，后续还有几个问题我们可以陆续进行讨论。
回复 1# 的帖子
我是个测试新手，还在学习中，很多问题记得不太清，请大家原谅；问题1 测试执行过程中发现BUG数量庞大，我们还需要测试吗？
答：我认为还是要测试，首先要分析数量庞大BUG的原因，是同一类问题，还是开发的问题，还是需求分析的问题，或是需求变更的问题，解决办法：分析原因后具体问题具体分析 ，如果是同一个问题，应该向对应的开发提供一个建议。如果是开发的问题 ，就要找开发经理进行商谈；如果是需求分析和需求变更的问题，那就要测试主管和开发主管还有对应的开发 坐到一起进行商量 商量一个解决变法；
问题2 测试执行过程中遇到需到严重性甚至致命缺陷，我们还需要测试吗？
答：我还是认为需要测试，我认为测试计划和方案中会有出现严重性和甚至致命缺陷问题挂起的条件和解决方法；但是我们为公司工作，如果不出现用例阻塞的话，那继续测；如果出现用例阻塞的话，要和测试经理商量解决办法，把这个模块解决，等开发解决这个问题后在最短的时间把剩下的阻塞用例测完；
问题3 测试执行过程中我们一个版本还没测试执行结束，开发又要提交新的版本，我们是放弃这个版本，测试新的版本？还是要继续坚持测试旧的版本？
答：首先我们要明确一个最终提交版本，假如版本有V1.0,V2.0,V3.0,V4.0我们定为版本V4.0是最后版本，并确定最后提交日期，然后我们要测V2.0中，当开发提交新版本，首先要问开发修改后相关联的哪些模块，进行回归测试，再测未测模块，如果开发不知道，那你就把版本V2.0和最后版本V4.0都测完就好，对于新版本 你可以只测开发修复缺陷的那一版本；
问题4：有些BUG在测试环境下存在，但在开发环境下却不出现，我们要记BUG吗？
答：这个BUG要提，还有把开发叫过来来分析这个BUG产生的原因；
希望大家对我的答案有问题提出来，进行讨论和交流
测试的最高境界是预防错误的发生！
我认为当出现大量或严重性缺陷导致测试无法继续时，做为测试人员，首要的事情是将bug情况（包括bug类型，出现场景）大致分类，并在第一时间与负责人或相关人员沟通，共同讨论如何开展后续工作？若结果是放弃该版本，知道bug产生的原因了，有能力的情况下，建议有选择性地继续测试，这样可以多积累些经验！:victory:
问题1：出现此种情况多数是因为某个共用部分出现问题，导致与其关联项出现大量错误，当bug出现场景一致时，可先暂停此类用例，继续执行其他用例；
问题2：应立即将详细情况与相关人员进行沟通，找出bug产生的原因，再根据具体情况决定是否继续执行？
问题3：如果提交新版本的速度很快，没有足够的时间时，可只测试第一和最后一个版本；如果时间不是很紧时，可取第一，中间和最后的版本进行测试；前面l回归的版本可以只测优先级高的功能，但最后一个版本所有的用例一定要全部执行。此种情况频繁发生时，可委婉建议领导增加回归控制的流程，比如回归的总次数，修改后提交的标准等等，这样可以让开发人员重视开发的质量，测试人员的目标是提升软件的质量。
问题4：（第一次遇到这种情况时）首先要记bug，确认在开发环境下不出现时，检查是否自己的测试环境有问题，如果是自己的原因造成的，要注明原因；
如果以后遇到类似情况，例如，数据库数据有误，第一要想到的是自己的环境搭建是否有误，首先进行自我排除，确定是开发的原因造成时，再做记录。
第一次要做记录，不是为了体现出我们找出一个bug而做记录，因为没有经验造成的！是我们的错误就要勇于承担，难得的是：不再犯同样的错误！同理，后面的记录也不是为了体现开发人员又犯同样的错误而提交！
相信这样做之后，你的地位也会因测试工作而在开发人员心目中得到提升！:loveliness:
[ 本帖最后由 依米花 于 2010-1-27 21:14 编辑 ]
具体情况具体分析，绝对不能搞一刀切！
测试执行，就是将测试准备工作真正应用、发现软件存留缺陷的过程，这个过程是将提高软件质量的目标变成现实的过程。这中间存在的问题（如楼主所说）我个人的看法如下：
问题一、二：
答：测试执行过程中发现的bug数量庞大，这只能说明，开发人员提交的软件存在着很大的问题；至于还要不要继续测试下去，需要看情况而定。
1.如果已经发现的缺陷绝大多数都是同一个模块里或者重要的模块里，并且严重级别较高，直接影响到用户基本的正常使用了。那就没有必要继续测试下去了。说明开发人员的预测试工作的质量比开发还要粗糙。直接返回给开发人员，要求其做完必要的预测试，保证软件正常的执行和使用没有问题了，再提交给测试人员测试。
2.如果已经发现的缺陷绝大多数都是严重或者致命，但是不影响用户的正常使用，那就要全心全意，一个不落的完整记录下来，交给开发人员修改，并做好准备工作开始进行回归测试。
3.数量大不要紧，关键是测试人员分析已经发现的缺陷种类，类型，是什么个情况。也就是具体情况具体分析，决定我们的下一步做什么。也就不会为眼前的状况而烦恼拿不定主意了！
问题三：
答：1.如果，我们测试的软件像微软操作系统等等一样的大软件版本，并且每一个版本都不可能被下一个版本所替代的话，那就继续测试。不过话说回来，真的是这种每个版本短时间内无法替代的话，该软件公司都不小，测试人员肯定相当多。那就可以考虑分组测试版本；将测试重心按照公司的需要进行必要的调整，并不是搞一刀切！
2.如果我们测试的软件版本是替代性的，如小的应用程序软件。下一个版本出来了，那么新版本的功能肯定会包含旧版本的。那这样的话，就直接放弃旧版本，开始测试新版本了，是吧？！
3.在我看来，在大型的软件公司或者部门开发的软件，版本是由市场定义的，谁说都不行；但是在小公司，软件版本的定义和提交应该是由测试人员根据客户提出的无尽的变更和开发人员对已发现的缺陷关闭情况决定的，这样测试人员就不会被动的被开发人员牵着鼻子走了，还受气！嘿嘿！:lol
问题四：
答：这种情况一看就知道，是开发环境和软件应用环境的差别，这样发现的问题，当然要记录了。我们先要明白一个关系：测试人员，是相对于用户来说是比较专业的应用人员。所以说测试人员的应用环境跟各户的环境是一回事或者一摸一样，如果在测试环境下能出现的问题，在客户那里肯定也会出现。客户认可的永远是他们的应用情况，并不是你开发人员的开发环境。所以，这样的环境缺陷因素必须要记录，而且级别还不低！:victory:
呵呵！这些是我个人的观点，有什么地方不对的或者不妥的，望大伙儿指正！谢啦！
回复 2# 的帖子
看了你的回复，很赞同你的一些观点，就是我们不要一遇到问题就退缩，而是要积极寻找解决问题的办法。如何寻找解决问题的办法，可以有以下思路：
1、分析问题产生的原因，我们就拿发现bug很多这件事情而言，当我们看到这个问题时，可能已经是编码完成之后了。
但其实从需求阶段开始问题已经存在了，只是没有爆露出来而已。所以越是不规范的流程，越是时间进度较紧的项目，越是业务复杂度较高的模块，问题也就越多一些。
关于这些问题要想从根本上减少它，可以制定近期目标和长期目标，近期目标就是如何顺利的让这个项目验收，长期就是从上游的工作下功夫。
我们先说近期也是紧急的目标，当测试人员发现大量缺陷时，其实不光是证明了开发存在很多问题，而且对开发和整个团队的自信心也是一个极大的打击。测试人员也是同样，发现了大量的缺陷，也就意味着要进行大量的回归操作，工作量也会越来越大的。
我们首先要保持冷静，要与开发负责人就测试版本进行明确的定义，先将最低限的版本测试目标定义明确。所谓的最低限就是这个产品交付到用户手中，如果输入的数据和操作流程是正确的话，输出的结果是符合需求的，这就是最低限即这个产品是可用的。
定义好版本基线后，我们再来分析一下目前的问题，哪些问题不在这个版本中考虑的，就可以延期修改，在这个版本中必须修复的缺陷，就一定要高质量修改完成。这样因为bug的明确划分，也会极大的鼓舞和增强开发人员的信心。
接下来就是等一个版本稳定后，我们可以和开发一起来规划下一个版本，一个山头一个山头的攻破！
随着大家信心的增强，bug也会趋于稳定的！
所以一名优秀的测试人员不是在乱上添乱的人，而是给团队信心和方向的人！
回复 4# 的帖子
分析的非常客观，也很全面，有做主管的潜力！米西米西
米西米西 来吃一口！ 看了楼上各位的回答，我也发表自己的发法：问题1：遇到大量的BUG，如果数量级超过原先的预计，建议先召集QA，开发经理，测试经理，项目经理开会。对已发现问题的分布以及原因进行讨论。是使用的技术不成熟，框架不适合，程序版本控制，人员问题等等？？相信对任何项目，开发会自己进行比较简单的测试，开发经理也会知道代码可能的质量会如何。测试人员是有我们的职位操守，但并不代表我们要超越职责。
问题2：一般到了这种严重程度的问题，都是阻塞型的问题了。会直接影响测试工作，并且很有可能导致连冒烟测试都无法通过。这种情况下，当然直接放弃测试，直接把版本打回。
问题3：这种情况直接找QA或者项目经理解决。到底是想弄并行性的项目版本，还是版本控制没做好？既然是让我们执行测试但又不管我们的测试进度开发就自行发后续版本。这种已经不是测试策略的问题了，而是部门小组之间沟通的问题。
问题4：环境问题记录并反馈具体环境。
最后想说得一点是，虽然觉得上面几位说得都非常好，也非常有责任心，都选择了坚持到底。但测试组是整个项目组织中的一个环节。有些责任，有些决定不在我们，交由其他人也许会效果更好。
页:
[1]
