探索性测试(Exploratory Testing)是软件测试方法的一种,它的特点为在进行测试时,同时探索开发更多不同型态的测试方式,以便改善测试流程。当软件开始测试流程后,一般测试者会使用预先设立好的测试案例来进行程式测试,而探索性测试就是为了弥补传统的案例测试的缺点而产生。

探索性测试这个词是由Cem Kaner在1983年提出。他将探索性测试定义为:一种强调个人自由与责任的测试方法,让独立的测试者可以借由不断的学习来改善测试的规划与测试的执行,而在测试的过程中也会同时的改善专案达到相辅相成的效果。

历史 编辑

探索性测试常被许多富有经验的测试者所使用。

适用时机 编辑

  1. 当测试者是新手,可以一边训练一边测试
  2. 需要快速的对程式进行评估
  3. 在传统的测试脚本(Test Script)中发现新的问题需要快速验证
  4. 当有需要去确认另一位测试者的工作状况
  5. 当团队内有熟悉相关领域知识(Domain Knowledge)的测试者
  6. 当需要做烟雾测试
  7. 当程式设计完后并没有预先规划并准备好测试脚本
  8. 当专案使用敏捷软件开发
  9. 专案很复杂并且难以了解
  10. 当测试者并没有权限去创建测试案例
  11. 当想要针对某个程序错误进行深入调查
  12. 当专案尚未稳定到可以执行脚本测试(Script Test)
  13. 当想要扩大脚本测试的多样性时

使用时机 编辑

  • 专案初期
    • 在专案的初期,测试案例的建立并不完整,可以借由探索性测试来协助测试案例的建立以及修正。
  • 专案中后期
    • 当专案接近中后期时花点时间利用探索性测试可以探索更多软件的可能性与找出潜藏的程式缺陷,也可以对原本的测试脚本进行改善与评估。

优点与缺点 编辑

  • 优点
    • 鼓励创造性。
    • 可增加机会找到新的、未知的程式缺陷
    • 允许测试者花较多的时间去测试一些有趣或复杂的状况。
    • 可较快速的对受测的系统做出快速的评量。
    • 可让你知道系统是否容易使用。
    • 可变通的,有弹性的。
    • 它比脚本测试有趣,因为它不会一成不变。
  • 缺点
    • 不容易被协调及调整。
    • 无法对系统作全面性的测试。
    • 提供有限的测试可信度。
    • 非常的依靠测试者的领域知识(domain knowledge页面存档备份,存于互联网档案馆))以及技术。
    • 无法保证最重要的程序错误一定被发现。
    • 并不适用要执行很久的测试(例如执行一整个晚上的测试)。

差异 编辑

探索性测试常与即兴测试混淆,基本上探索性测试使用即兴测试的观念,而将测试的结果用于提升测试人员的水准与改善脚本测试流程,即兴测试未必会将测试结果用来改善脚本测试的流程。

参见 编辑