探索式测试的定义在我的blog都做了较多说明,其中也谈到了探索式测试在项目的实践方式,接下来会详细的说明其中来亮个实践方式的具体实施过程。
探索式测试是一种测试风格和思考方式,它强调的是学习在测试过程中的作用。无论测试人员在做功能测试、性能测试、安全测试或其他类型的测试,都可以使用探索式测试的思维方法,来帮助自己找到初始测试设计未考虑到的危险区域。
测试专家James Bach曾经对探索式测试(ET)和脚本测试(ST)在项目实践过程的变化进行了对比,请看图
1
从严格的脚本测试到自由式的探索式测试,James Bach做了如下解释:
最左边的Pure Scripted,是严格的按照测试用例来执行测试,而且测试用例非常详细,在项目测试过程中较少存在这种现象。
最右边的Freestyle ET,是自由式的探索式测试,在测试执行的时候不依赖于测试文档,只记录产品缺陷和风险除外;测试执行之前不需要任何特别的准备,比如测试设计。
ET。比较好的办法是在项目中混合脚本测试和探索式测试,并在不同的项目中采取不同的混合方式来制定项目测试计划。在大部分的项目测试过程中,综合脚本测试和探索式测试的优点可以得到较好的效果。
目前许多测试团队以脚本测试为主导,偶尔在测试执行的时候发散性地去测试有疑惑的地方,但该发散性测试受经验、时间、功能特性、测试任务等众多因素影响,其结果无法跟踪,且经验不能传承。为了更好的组合脚本测试和探索式测试的优点,可以考虑尽量减少编写文档的时间,也可以考虑增加在测试执行时学习产品和技术的时间,从而带来更强的思维扩展性。
Vague Scripted:比较简要的测试用例,是对脚本测试(ST)的初步简化,可以理解为测试人员需要编写测试用例,(但不必编写详细的预期结果)。测试用例可以包含操作步骤,但描述比较简单,其目的是留下更多的空间给测试人员在测试执行的时候自由发挥。
Fragmentary test cases:使用一句话或几个词语描述的测试用例,类似于脚本测试中的测试用例标题。
Charters:探索式测试过程中使用到的一个非常清晰的任务列表,指出了要测试什么、怎么测试(强调策略,不是详细测试步骤)、寻找什么样的Bug、有哪些风险、要去检查什么文档等。
Roles:测试过程中确定每个测试人员一个独立的角色去测试产品的某个部分。由测试人员自己掌控测试任务的进度和质量。
展示了不同目的的探索式测试象限。
Testing)的形式,或进行探索式测试之后采用全民分享(All Sharing)方式来分享更多的测试经验。探索式测试属于软件测试的上下文驱动学派(Context-Driven
School),具体采用何种方式来进行探索式测试实践,或如何组合多种实践方式都是依赖于项目当时的情境,也就是项目本身的上下文环境。
(Bug Bash)在微软使用得非常普遍,且效果非常好。结对测试(Pair
Testing)是与结对编程相对应,由两名或多名测试人员在一起同时测试一个SUT,并相互给出建议和指令,共享通过使用系统得到的(隐含)信息,从而不断的积累系统知识和测试经验。全民分享(All
Sharing)是测试执行前或执行后所进行团队分享的一个活动,具有不同背景和特长的测试人员分享自己发现Bug的思路,分享自己如何去测试软件,分享自己在某种测试类型上的策略。
熟悉微软测试流程的测试人员应该都听说过缺陷大扫除(Bug Bash。它是一项短期的全员测试活动。在微软,许多开发团队会在里程碑(Milestone)的末期执行缺陷大扫除。程序员、测试员、程序经理、用户代表、市场人员在1~3天的窗口中,运用各自的技能和职业背景,集中精力来搜寻软件的缺陷。通常,每位参与者会获得一个小礼品,发现缺陷数目最多的冠军会获得一份大奖。
一般缺陷大扫除的组织者需要准备如下的内容:
l
l
l
l
l
l
l
l
l
(2) 团队学习。团队举行“缺陷检讨”会议,总结缺陷模式(bug
pattern),完善测试策略,补充测试检查列表(check list)。这是一种积极的集体学习行为。在此过程中,测试人员可以积累经验、分享技能,测试团队可以沉淀知识、凝聚士气。
总体上来说,Bug Bash
不仅仅能给项目的质量带来新的思考方法和参考指标(质量和用户体验上都有所提升),而且还会驱使Bug Bash的参与者更加有激情和热度去从事测试工作。至于Bug
Bash活动的相关细则可以根据自己团队的特点来定制化,目标就是提升项目的质量和提高测试人员的测试敏感度、测试关注度、创造性思维、团队分享精神。
当开发人员都在关注结对编程的时候,测试人员应该关注什么呢,如何来解决单人测试带来的测试遗漏这个问题呢,结对测试行不行呢?结对测试是软件开发中的一种技术,它允许团队中两个人一起测试某个产品,一个测试人员实际操作测试产品,另一个测试人员分析或评审测试过程和测试结果。
结对测试也未必一定是两个人,多个测试人员合作共同测试的时候就称为结队测试。测试人员都是很敏感的,在自己执行测试的时候,程序稍有一点反常,都会意识到可能是缺陷,一定会去究根追底,去确认到底是缺陷还是操作问题引起的。当测试人员互相交流发现的缺陷的时候,可能会互相启发去发现更多的缺陷。一个测试人员发现了一个缺陷,另一个测试人员可能发现和这个缺陷类似的更多缺陷,特别是在复杂环境下的测试。
(1) 至少有一个测试人员可以被信任且能在没有指导的情况下进行测试。
(2) 另一个测试人员需要参与到测试设计过程中。
(3) 两个测试人员必须要有一起合作的能力和心态。
在结对测试过程中,实践者需要注意以下关键因素。
在很多活动过程中,将你的想法解释给其他人听是一个负担,但是在测试活动中,这将是一种收益。因为测试的过程就是一个测试想法生成的过程,解释和质疑的过程有助于培养出更多新的测试想法。尤其当某个测试人员的知识远少于另外一个测试人员时更是这样。很多情况下,一个测试人员单独的测试容易陷入到一个错误的结论,除非另一个测试人员质疑该结论,否则他也不会重新审视该结论。
我们不知道每个测试人员的个人特质,如脾气、技能、经验对结对测试的效果有多大的影响。但是结对测试的实践表明该活动非常有趣,无论你的经验是丰富还是欠缺。当然,测试人员必须是友好相处的,且在过程中有一定的承诺,如果某一个测试人员在工作过程中感觉到被攻击、失去自主权、或变得沮丧都会影响结对测试的效率。结对测试是一个比团队测试更加特殊的组织方式,结对意味着最大化每个测试人员的贡献。在某个主管和其下属的结对情况下,通过结对的提问和测试的演示可以让主管更加信任测试的质量。
我们在结对测试的过程中,可以在早期选择好需要结对测试的测程,测程的概念在我之前blog中已经做了详细描述。在一个测程中,结对的测试人员有一个清晰的目标和测试策略。当然,由于结对测试充满着乐趣,则结对测试的时间段可以是测试人员的测程的间隙。