【分享吧】以软件系统为中心的探索性测试

一、探索性测试的定义
  探索性测试（ET）是敏捷世界里的一种重要测试方法，作为一个研究性的工具，它是用户故事测试和自动化回归集的重要补充。它是一种经过深思熟虑的测试方式，没有测试脚本，可以使你的测试超出各种明显已经测试过的场景。探索测试将学习，测试设计和测试执行整合在一起，形成一种测试方法。
  探索性测试的最大特色是在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。他的典型过程如下图：

  这相对于传统软件测试过程中严格的“先设计，后执行”来说，是具有很大区别的。

二、探索性测试的基本过程
  探索性测试的基本过程包括如下：

  识别软件系统的目的；
  识别软件系统提供的功能；
  识别软件系统潜在的不稳定的区域；
  在探索软件系统的过程中记录关于软件的消息和问题；
  创建一个测试纲要，使用它来执行测试。
  注意：上面的过程是一个循环的过程，并且没有很严格的执行顺序，完全能够先创建测试纲要，执行测试，然后在测试中进修软件系统；也能够先探索软件系统的各个区域，然后再列出需要测试的要点。
  探索性测试强调创新的测试思维，在测试过程中不断地出现许多关于测试的新想法，
  因而就像一把叉，下图就是一个所谓的“探索叉”（exploratory forks）。
  探索性测试强调测试过程中要有更多的发散思维，这也是与保守测试方式的最大区别。
  保守测试方式强调设想完善的测试用例，测试人员严格按测试用例执行测试，这多少限制了测试人员的测试思维，测试人员往往缺乏主观能动性。

  下图展示了一个发散思维的过程，探索性测试强调发散，但并不是盲目地发散，在适当的时候还要收敛回来。
  例如，当发觉在一个测试的分支路径上已经花了很长时间也没有找到问题的答案时，则能够考虑先放弃那个区域的探索，因为还有一个主线的测试任务。

  探索性测试尤其适合于那些需求不是很明确的测试任务，或者是一名刚刚接手一项新的测试任务的测试人员使用。这样的特点让我想到我们在工作中经常遇到的测试任务。

三、探索性测试在第三方交易系统中的应用
  1、传统测试方法可能造成不必要的资源浪费
  通常我们在接到第三方交易系统的测试任务时会按照传统的测试方法来执行，需求分析、测试设计、用例设计、用例执行。这样的方式对于一个全新的未经过发布的系统来说是无可挑剔的，但对于第三方的交易系统，系统开发商在发布前已经做过全面的测试，我们或许可以认为系统发布后，80%以上的功能可能都是正确的。而我们要以传统的测试方法对这样的系统展开全面的测试，必然会造成一定的测试资源浪费。
  2、结合业务很重要
  在对交易系统进行测试时，如果一味的按测试设计方法根据需求进行测试设计，由于交易系统的复杂性将产生大量的测试用例，从而导致测试人员在执行时也抓不住重点，往往在非重要功能上浪费了大量时间测试。而如果能结合业务进行测试，沿着每条业务线在测试中抓住重点，或许会事半功倍。
  3、软件系统即是业务实现
  当面对一个复杂而又陌生的交易系统，亦或是对交易业务摸不着头脑时，我们不妨可以用探索性测试的思维寻求测试的切入点。在对交易系统进行测试的同时学习被测系统，而交易系统即是业务的实现工具，执行测试的同时也掌握了业务，而每次对于业务的掌握又会产生许多测试的新想法，如此循环往复，探索交易系统的各个区域，然后再列出需要测试的要点。
  4、探索性测试可以用来找到深层次的BUG
  使用传统测试方法对交易系统测试时，由于测试很全面，往往会发现很多bug，而这些bug中很多在提交之后往往被贴上“不是缺陷”或“延期修复”的标签，这说明缺陷不重要或者优先级很低，短期不修复一样可以被容忍，而使用探索性测试的方法，测试人员往往是优秀的观察者，他们观察不正常和不期望的结果，并进行认真的思考，这种状态和按部就班的执行用例是不一样的，因此，它更容易发现一些隐藏的很深的问题、而这些问题正是客户的痛点所在。

四、总结
  尽管探索性测试是一种有效的测试方法，但是它不意味着是一种全面覆盖的测试方法。我们在进行三方交易系统测试时，可以适当将探索测试与传统测试相结合来提高测试效率，另外探索性测试可能特别适合公司的新人在不懂业务时采用，在学习业务和熟悉系统的同时，发现更多有价值的问题。
▼

【分享吧】以软件系统为中心的探索性测试

浏览过的版块