测试过程中的一些疑问（缺陷发现率、测试结束标准等）
已进入测试行业两年，测试过程中一直存在以下几个疑问：1.测试过程中怎样才能提高缺陷发现率，使测试的问题尽量在第一、二轮发现，降低每轮层出不穷的bug数？
2.怎样才算一轮测试结束，可以达到测试结束标准？
3.对于对于比较隐蔽的缺陷，怎样才能尽早发现？ 随便说说自己的看法，仅作参考。
1.测试过程中怎样才能提高缺陷发现率，使测试的问题尽量在第一、二轮发现，降低每轮层出不穷的bug数？
缺陷发现率，更多的要了解程序和业务，换句话说，你是否了解开发的软件和开发的人。如果有单元测试、集成测试等，到测试人员手里，大部分的问题应该都解决了的，但是现在很少能做到，更多的是开发人员做完了就给测试，前期缺少甚至没有文档，开发人员的水平也高低不同，责任心更是天差地别。
在这样的条件下，测试人员能做的，只能保证自己的部分，比如更多的研究已有的文档，更细致的了解需求，收集曾经有过的问题，等等。
提高缺陷发现率，更多的不在测试这里，是一个整体流程才能更好的保证。测试人员不保证软件质量，那是QA的事情，测试的责任在发现程序存在的缺陷。
其实大部分情况下，软件开发完，质量就固定了，测试只是在到处漏水的桶上，告诉做桶的哪里有洞，到处打打补丁而已。
2.怎样才算一轮测试结束，可以达到测试结束标准？
一轮测试结束和测试结束是两回事的吧。通常有用例，把用例执行一遍，就可以说一轮测试完毕了；没有测试用例，把各个模块测试一遍也算一轮。
测试结束标准看公司的规定。比如没有致命的缺陷，剩下的缺陷不影响软件功能等等，看公司的标准。没有标准的，测试和开发扯扯皮，通常在进度的压力下，手松松有问题的软件也就那么过去了。反正大部分的软件，有问题也大多能对付过去。实在不行，客户的压力比测试有效很多，测试通常没有很大的权力去控制软件的走向。
3.对于对于比较隐蔽的缺陷，怎样才能尽早发现？
还是第一个的问题一样，既然隐藏，那么就需要了解需求和软件。没有发现就不不知道，发现了也就没什么隐藏一说了。其实感觉隐藏的缺陷更多的是测试人员自己爽一下，说看看，这么曲折的问题I find it。测试人员都觉得隐藏的问题，客户发现的几率会更小的。
隐藏的问题，通常测试用例等方法不很有效，用探索性这样的测试方法，对付这样的问题应该更有效率。 回复 2# luming
其实我问的这3个问题还是归于一个项目的测试引发的，测试了四五轮，问题数虽有递减的趋势，但总有新问题出现，领导说我们测试不仔细，有些问题是可以在第一、二轮就可以发现的，现在发现的晚，还影响项目进度。
还问我们怎么判断一轮测试可以结束的？我们现在做的项目比较多，测试人员比较少，一般一轮测试就是修复问题的验证，再加相关联问题的随机测试{:4_102:} 本帖最后由 luming 于 2011-7-17 12:39 编辑
回复luming
其实我问的这3个问题还是归于一个项目的测试引发的，测试了四五轮，问题数虽有递减 ...
amy1985 发表于 2011-7-17 09:35 http://bbs.51testing.com/images/common/back.gif
有新问题是正常的，咱们先不提修复问题引起的新缺陷，只说因为随着测试的进行，测试人员对系统更多的了解，才能发现更深层次的问题。
还是前面说的，是否测试可以做前期的工作，比如存在需求、设计文档，测试人员可以预期做测试计划、测试需求分析、测试用例编写；或者进一步的测试是否从需求阶段就可以接触到项目，不奢望需求阶段测试方面参与评审，测试至少应该对项目的进度、内容等进行了解。
没有上面的那些，软件直接提交到测试，测试只能在测试过程中不停的进行摸索，了解需求、了解软件，当然会花费更多的时间，因为前期的时间集中到最后了。这是任何一个人都无法解决的问题，只能等待随着测试人员对业务的了解，对下一个项目才能更快的进行测试。
通常情况下，没有上面说的前期阶段直接测试的条件下，第一轮就发现发现表明的问题，让软件能跑下去而已。第二轮才能了解程序整体的走向，比如数据的流转。第三轮测试才能真正的了解软件，明白软件到底需要达到什么样的目的，到底内在需要什么样的功能。没有5轮以上的测试过程，系统测试很难结束的，所以你说的问题根本不称为问题，这是大环境决定的，测试方面无能为力。
测试是良心活，开发至少要拿出能用的东西，测试测没测过只有自己知道。测试用例其实就是保证测试人员的工作进程的；没有测试用例，测试完毕后发现问题顶多说自己马虎了，一些地方没有测到。开发有进度压力，可能开发出很糟糕应急的软件；测试也一样，没有时间只能马虎的测试一下，没有大概的问题也就那样。
嗯，上面的是测试方面的理由，自己知道就行了，和领导没有必要这么说，上面一般不会接受这些东西的，因为这么说责任和压力就在项目经理和领导头上了。只能潜移默化的影响领导，比如知道要测试什么东西，随时和项目经理要需求设计文档，没有的话，在不经意间和上面说说，说因为没有这些文档，测试不好开展。不要直说，因为直说如果真的让上面让项目经理补这些文档，项目经理一定会抓狂的，对测试也会有看法，说这些仅仅说明测试工作不好做而已。有时间写写测试用例，给上面领导看看，说明除了测试，我们还开展的正规的工作，能让项目经理评审一下就更好了，这个是推脱责任的利器，以后客户方面发现问题，只要说测试用例中忘记了，下次补充上，就能推卸不少的责任，至少态度在那里不是。
测试进度忙，多加加班，至少样子在那里，领导说测试不仔细，就回答时间实在太急，测试的项目太多，每个都详细测试没有时间，嗯，随便拿两个自己测试发现的缺陷说一下，说开发那边的进度也一样，太急了，很多东西都没做太好就拿过来了，当然了，只说问题，千万别提具体的项目或具体的人。
领导问如何判断一轮测试结束，告诉他，明天来一个新项目，无论如何，测试这边今天必须结束，否则测试项目就堆积了。工作找借口是件最容易不过的事情了，很多时候，领导也只是找个借口，说明他在起作用，确实在管理而已，并不在乎你的回复是什么。
嗯，大概就是这些了，不是很理论化，但是我想实际工作应该理解和用得到，也许和你们公司的实际情况有差别，但是我想大多数的测试人员都无法避免这些事情的。 回复 4# luming
谢谢，学到不少东西，至少同事不会跟我说这些:) 165403315
该群可能 有人知道 本帖最后由 Carl_Lew 于 2011-7-19 17:41 编辑
1.测试过程中怎样才能提高缺陷发现率，使测试的问题尽量在第一、二轮发现，降低每轮层出不穷的bug数？
请有经验的测试工程师，事先对测试案例进行审阅，按照测试案例的重要程度进行分级，可以分为：关键的，重要的，一般的。把关键的重要的放在最前面测试。通过渐进的方式保证严重问题可以第一时间发现，绝对要避免不分轻重的“地毯式轰炸”。
2.怎样才算一轮测试结束，可以达到测试结束标准？
测试前要制定测试计划，也就是说要目标导向，对每轮测试目标进行定位，只要达到这个目标就可以进入下一轮，也可以说达到一个里程碑。比如说，第一轮要保证功能完整，消灭功能缺失问题；第二轮要保证功能实现细节正确；第三轮。。。。。个人认为不能以BUG多少去衡量。
3.对于对于比较隐蔽的缺陷，怎样才能尽早发现？
之所以隐蔽，一般可分为两种情况：一是测试人员技能欠缺，对被测试对象缺乏深入了解；二是模块相互作用时才会出现。第一种情况就是尽量使用有经验的人、细心的人，第二种情况是尽量避免配置单一化，测试过程多变换配置，并且测试人员间要加强沟通和信息发布。 1.缺陷发现率：如果要严格来说，缺陷发现率是跟测试用例关联的，如果测试用例不完整，或者发现的BUG不在测试用例范围内，那这个缺陷率也就不好衡量；这里的缺陷发现率，我觉得更多是是从测试用例上着手，先从测试用例的覆盖需求上评估，评估玩后再关联BUG，从而达到所谓的缺陷发现率；
2.测试结束标准：我个人也做过测试执行，我发现在跟踪版本，特性的时候，有时候测试结束的并没有标准，这里不能用一个点去衡量，而应该用度去衡量，测试完成了，那就要review 提交BUG剩余多少，剩余BUG是否都需要解决、可不可结束这些可由pm、产品、测试一起讨论决定； 回复 8# andyfly_001
我们测试前会根据需求、设计写用例，测试过程中也会根据发现的问题再补充用例，但还是每轮都会再发现那么几个问题，老是感觉结束不了测试 1、尽量熟悉业务，细化业务，已经业务行业知识；项目代码实现工作原理，每个流程都细化了解
2、一般按计划完成测试预订的测试任务即可
3、细化广泛思维业务 受益了,新手上路:victory: 受益良多
页:
[1]
