怎么控制Free testing/ad-hoc testing......（2010-6-22）（获奖名单已公布）

默默巫

Free testing/ad-hoc testing/exploratory testing是一种基于测试人员自觉性、测试人员个体经验的测试，经常看到很多测试人员碰到这种测试就是随便玩玩，比如看看网页，很少或者根本没有测试人员去尽量的发现Bug。作为测试组的负责人，怎么控制Free testing/ad-hoc testing/exploratory testing及其质量呢？



如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	rolei	价值50元的充值卡	12#

msnshow

还是从BUG方面着手，例如说，先安排这样的人做一轮测试，然后再让做事比较认真的人来做测试

如果先测试的人有比较明显的BUG都没有发现，那肯定就是不认真了

zdlzx

首先更正一下explorery testing应为exploratory testing

Exploratory testing是与scripted testing相对应的概念，强调test case design和execution不是严格顺序关系，而是tester在边测试边学习的过程中，通过对被测系统的不断学习和了解来对test case design 和execution进行不断优化，达到更有效地测试的目的。必须强调的是exploratory testing是在一定框架指导下的适当发挥自由的测试，而非毫无目的瞎撞，希望瞎猫能逮到死耗子。而ad-hoc testing 更随意些，更多的时候是天马行空突发奇想。这类测试因为不特别强调事先的准备或者说文档，而有点骑驴看唱本的味道，与传统的按照test case执行测试相比，其完成情况比较难度量。

“作为测试组的负责人，怎么控制Free testing/ad-hoc testing/exploratory testing及其质量呢？”其实测试有效性不是组长控制出来。不能通过这种原本应该很有效的测试方法发现足够多的bug，可能最大的原因是不了解这种技能，因此不能正确地使用它。所以作为测试组的负责人首先要帮助组员掌握exploratory testing/ad-hoc testing相关的技能：消除ad-hoc testing就是随便点点的误解，并了解从哪些大的方面去考虑，才可能在看似无意的测试中找到有价值的缺陷，如数据的多样性、操作步骤的顺序、对空值的判断、特殊字符的处理、环境的差异等等。其次可以通过经常的bug sharing（包括对于一些奇怪的bug的根本原因的分析）在组内帮助大家集思广益，互相启发，互相学习，从而发现更多的潜在（而非严格与需求相关）的bug。另外，更多地了解用户的使用习惯，更多地了解产品架构、技术、设计甚至编码也能帮助启发tester想到可能出现的bug。组员掌握了基本技能后，通过长期的经验积累、敏锐的洞察力、丰富的想象力可以进一步提升测试的有效性，从而达到武林高手的境界：手中无剑，心中有剑。即便不按照写好的test case出招，也能手到擒来，快速找到有价值的隐藏又比较深的缺陷。每个组员都具备了这种能力，组长就无需控制了。*_*

[ 本帖最后由 zdlzx 于 2010-6-22 21:51 编辑 ]

Jackc

针对ad-hoc testing的评估是可以量化的。

主要有以下三个数据：

1、ad-hoc testing的error发现率 = ad-hoc testing有效error / 有效error总数
考核参数通常取前3个周期发现率的平均数。
比如前3周期的error发现率为50%、65%、60%，那么对于第4周期ad-hoc testing的要求为：ad-hoc testing发现的error数应该占总error数的58%以上。

2、ad-hoc testing的error级别分布
ad-hoc testing发现的所有有效error的严重级别分布曲线图，主要衡量整个ad-hoc testing过程中，发现error质量的评估。

3、ad-hoc testing的error有效率
ad-hoc testing过程中，有效error占上报error总数的比率。主要对测试人员报error质量的评估。取

[ 本帖最后由 Jackc 于 2010-6-23 11:08 编辑 ]

默默巫

原帖由 zdlzx 于 2010-6-22 21:50 发表
首先更正一下explorery testing应为exploratory testing

Exploratory testing是与scripted testing相对应的概念，强调test case design和execution不是严格顺序关系，而是tester在边测试边学习的过程中，通过对被 ...

谢谢提醒。

chen91199

以我之前的经验，测试之行人员在执行测试用例的时候，当发现的BUG属于测试用例以外的话，我们就会把该BUG作为Free testing所发现的BUG，作为Free testing提交BUG。而不会有专门的时间去做Free testing。

applejuzi

测试要有重点，这种情况下还是针对改动比较频繁的模块多做测试，做之前要求写简单的测试点，然后让有经验的人简单的评审下，有遗漏的再补充。

havards

个人感觉：
1.测试人员能力较差，自制力不强，经验较少的情况下，尽量不要采用这种测试，以免适得其反。
2.如果测试人员能力较强，自制力也可以，经验也比较丰富的情况下，可以采用这种测试来达到发现一些盲点，但是建议最好结合测试的重点来选择测试范围，这就强调测试策略的重要性，最好是基于风险来选择测试范围。
3.如果一定要用这种测试的话，建议建立一个自由测试也好，探索测试也好，这种测试用例库，发现不错的测试点子或者通过一些测试步骤可以发现严重的BUG等，这样也可以给日后再进行类似测试提供思考的基础。
4.还是建议这类测试少用，因为这些测试发现出来的缺陷很难跟踪，不好确定覆盖率，最好都是执行测试用例而出现的缺陷，这时候可能有人会说了，在产品开发后期，执行测试用例很少能发现缺陷了。难道你不会更新用例库吗，是否可以引入新的测试用例设计方法？
说的不对的还请轻拍

archonwang

额外的成本支出啊，风险、投入和产出可能并不能如预期的一样。

如果是开创性的产品或项目，或许可以尝试。

roger_ge

无论是探索性测试，还是ad-hoc测试，期间都加入了很多测试人员的自主性。如果当你对被测试的软件产生疲态，即出现审丑疲劳的时候，在进行这类测试的时候，思维多少会出现点野马脱缰。
有压力，有限制才能调动人的能动性，可按照如下几点进行尝试：
1. 限定探索性测试和随机测试的时间，如2小时或更少，要求测试人员调动一切行动思维，快速找出缺陷。
2. 要求测试人员在日报或类同报告中指出进行探索性测试或随机测试所覆盖的测试区域，所采用的测试方法，期间做出的思考，特殊性测试数据等等，总之即使在测试过程中没有发现缺陷，也要让领导者知道你至少做了很多事情，而不是简单的在日报中列出一项Ad-hoc testing
3. 可采用两人一组，一人测试，另一人观看当前发生的测试行为（用户的使用行为之间有时会有比较大的区别，观看别人的行为或许能有所启发，并且当前测试的人员在别人的关注下势必会认真许多），在进行一段时间（如半个小时左右）后，角色相互转换，再次进行
总之，有点压力，才能将活做好，而不能一味得依靠自主性和自觉性

[ 本帖最后由 roger_ge 于 2010-6-29 15:51 编辑 ]

rolei

1、也许这些测试只能证明我们已有的测试用例的漏洞，通过数据对比可以评价测试用例的质量，补充新的用例，提高测试覆盖率；

2、无论什么样的测试都应当是有方向的、有目的的。
Free testing/ad-hoc testing/exploratory testing的测试应来自于对前期测试问题的分析，结合测试经验、行业经验，对所测试系统的合理性评估；
“测试应避免随意性”，这应当是Free testing/ad-hoc testing/exploratory testing控制的关键；

3、如果测试很随意，就好像“大海捞针”，“瞎猫碰死耗子”，效率和效果自然可以想象，也就没有必要去控制，更谈不上去评估质量了；

4、如果很free的测试就能发现问题，就不用再评价这样的测试质量如何了，首先解决前期的测试质量问题再说；

5、执行Free testing/ad-hoc testing/exploratory testing，也需要有合理的方向、用例（也许只是一些假设），通过对系统“分析猜测假设”的验证，确认此类测试结果（无论是否发现问题，这一类的测试的执行都是有效的），未发现问题只能证明这次测试是不“成功的”，设计的测试用例并不“好”；

6、“一个好的测试用例在于能发现至今未发现的错误。”、“一个成功的测试是发现了至今未发现的错误的测试。”
通过这两条标准来评估Free testing/ad-hoc testing/exploratory testing的质量足够了；

justin1113

我也来谈谈这个问题，作为学员，我对于Free testing/ad-hoc testing/exploratory testing这几种测试并不是很了解，也没有实践过。
大虾们都提到这些测试需要测试人员的自觉性和个人经验，所以我来谈谈我的几个方法
1.分配任务时，需要2人一组，负责同样模块，最好是一个资深+一个新手，这样可以进行比较且有压力，资深的肯定不好意思做的比新手差，而新手会更有动力，而且对其经验提升会有帮助。
2.每周（或每隔一段时间），抽取2个小时，进行Free testing/ad-hoc testing/exploratory testing沙龙，由每位成员进行这周测试回顾，并且自己准备1个自己发现的比较特殊或者比较典型的BUG进行讲解，包括测试思路，发现过程，日后借鉴价值等。当然对于不同经验与能力的成员，要求是不一样的，资深的成员当然更侧重于技术分享，新手们更侧重于心得分享。当然沙龙气氛要好，多提问多讨论，可以请大家边喝下午茶边聊。
3.把这些经验记录成文档汇总，在项目完成后归档，这样每个项目完成后，大家的经验是一起提高的，另外以后也可以拿出来做参考，或给新近人员作资料。
我觉得这样既能保证成员们会有压力，也能使成员们的经验提升更快。
还没正式进入软件测试行业，讲的不是很专业，呵呵，见谅。

fengzhulin

如果仅仅是针对这个问题，我们只需要关注两点
1、项目已经使用了Free testing
2、负责人如何控制质量

所以如果是基于这两点，那么给出以下个人意见
一、该测试方法的使用场景
    首先，对于一个项目，我们有不同的测试阶段，那么是哪个阶段使用了free testing，哪种测试类型使用了free testing是需要明确下来的。比如冒烟测试，就我们目前的项目来说就等同于free testing，测试人员拿到产品后，先就报着玩玩的态度试用一下，以看是否有重大影响使用的崩溃和问题。在这个阶段，因为重大问题不是各个模块都能遇到的，所以如果相关模块负责人上报此模块没有问题，而在正式进入功能测试后却发现该模块有重大问题，就说明此模块的负责人根本没有负责的进行测试。（当然，这里重大问题要看是必现还是非必现）。
二、测试人员的态度
   新人进入测试组后，态度其实也是跟整体的人文环境有关系的，所以应该首先建立一个认真、自觉、负责的测试体系，然新人耳濡目染，并且不断强调自觉的重要性。这样可以在一定程度上避免人们懒散的态度，当然这只是从人文角度来说。
三、如何控制质量
    首先，当做free testing的时候，一定要分田到户。就是专人负责专门模块。这样无形中会形成一种责任感。
    其次，模块交叉测试。当测试达到一定阶段后，成员内部互换模块进行测试，这样之前负责模块的成员如果散漫进行测试的话，必定会出现后来的成员发现自己负责模块的很多bug，这样面子上和领导那边也过不去，所以自然而然会认真进行测试。
四、成员技能培训
   管理人员不能一味要求成员态度认真、自觉，仅仅有这些是不够的，任何人都希望提高，希望能在自己的工作岗位上做出成绩。所以上级部门也应该积极组织技能培训，针对free tesing或者其他相关技术。只有组员掌握 了好的技能，在实际测试过程中才能积极、迅速、高效的发现问题所在。否则没有技能，看到网页、软件无从下手，即使发现了一个bug可能因为专业知识不够而忽略掉。

yhryan

原帖由 fengzhulin 于 2010-7-1 12:14 发表
如果仅仅是针对这个问题，我们只需要关注两点
1、项目已经使用了Free testing
2、负责人如何控制质量

所以如果是基于这两点，那么给出以下个人意见
一、该测试方法的使用场景
    首先，对于一个项目，我们有 ...

lixiaoyan_smart