探索式测试:探索是为了学习

发表于:2013-05-16来源:博客园作者:liangshi点击数: 标签:探索式测试
对于测试人员,软件测试是一个持续学习并实践的过程。他需要学习的内容可能包括: 行业知识:为什么需要这个软件?软件如何帮助使用它的人和团体去获得行业优势? 用户角色:目标用户是谁?他们有什么特点,有什么期望?软件如何帮助他们去获得个人

  对于测试人员,软件测试是一个持续学习并实践的过程。他需要学习的内容可能包括:

  行业知识:为什么需要这个软件?软件如何帮助使用它的人和团体去获得行业优势?

  用户角色:目标用户是谁?他们有什么特点,有什么期望?软件如何帮助他们去获得个人成就?

  软件产品:产品是一种解决方案。它解决了行业和用户所面临的问题吗?

  计算平台:只有深刻理解软件所依赖的计算平台(如操作系统、中间件、网络协议等),才能更好地测试。

  开发技能:理解项目所使用的具体技术,知晓典型的技术缺陷,具备测试开发能力。

  测试方法:针对当前项目,选择合适的测试方法,并能够熟练地应用。

  程序缺陷:研究当前(和相关)项目的缺陷,提炼错误模式(Pattern),制定缓解或预防方案。

  开发团队:语境(context)决定策略和实践。在一起工作的人,是所有项目语境中最重要的组成部分。

  测试者不需要在项目之初就掌握所有知识,他可以通过每天的工作去逐步理解用户、项目、技术和团队。更重要的是,他要在每天的工作中实践所学内容:规划测试方案,创建并执行测试用例,分析测试结果,编写测试报告。实践就是练习,是“学”的自然延伸。知行合一才构成“学习”的完整内核。

  如果学习非常重要,那么如何才能高效地学习呢?敏捷大师Andy Hunt在《Pragmatic Thinking and Learning》中指出“一种高效的学习环境应该允许你安全地做三件事情:探索、创造和应用”。

  探索就是在陌生的环境中玩(play)。你需要自由地探索才能学习。我们不仅仅接受信息,而是亲自探索和构建思维模型。

  玩引入了一种新奇的感觉,也就是乐趣。用一种好玩的方式学习新资料或者解决问题,可以让这个过程变得更让人享受,也让学习变得更容易。为了更好地学习,请更好的玩。

  你需要自由地创造——不介意自己的创造没有成功。通过构造来学习,而不是通过学习来构造。(这是“原型”、“曳光弹”、持续集成等方法获得成功的原因之一)

  你需要在日常实践中应用到你学到的东西。你持续使用和实践的技能会(在脑皮层竞争中)占据统治地位,大脑会为它们提供更多方便。

  这种探索应该相对没有风险,因为你肯定不想因担心害怕而止住探索的脚步。(安全有助于)更好地利用反馈,让失败也变得有意义。

  虽然Andy讨论的是广义的学习与探索,但是他的话解释了探索式测试的成功之道。正如Cem Kaner所言:

  探索式测试强调测试者的自由和责任,为了持续优化其工作的价值,将测试相关学习、测试设计、测试执行和测试结果解读,作为相互支持的活动,在整个项目过程中并行地执行。

  Exploratory software testing emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work, by treating test-related learning, test design, test execution and test result interpretation as mutually supportive activities that run in parallel throughout the project.

  探索式测试在本质上鼓励测试人员去自由地探索、创造和应用。

  《软件测试经验与教训》:“探索是带着使命在某个空间中有目的的漫游,但没有预先确定的路线。探索包括不断学习和实践”。

  在探索式测试中,测试者创造出一切有助于学习和实践的数据和工具。它们包括输入数据、结果检查脚本、数据分析报告、业务流程图表等。

  探索式测试者持续应用他所学到的知识。所谓“学而时习之,不亦说乎”,探索式测试将学习与应用作为相互支持的活动逐步展开,为测试者的知识提升提供了平滑的学习曲线。

  探索式测试是一项富有智力挑战的活动,充满了乐趣。如果你没有感到智力的快感,那么一定是哪里做错了。

  此外,Andy也指出,为了鼓励自由的探索,我们需要“安全的”环境。

  测试者应该拥有独立且隔离的测试环境,他的测试活动所照成的破坏性后果不会影响团队的其他成员。

  当测试者破坏了他的测试环境,他可以快速地创建新测试环境。虚拟化技术可以提供多样的软、硬件和网络配置。版本管理系统、自动化构建和全自动安装有助于部署特定版本的软件。

  在测试中使用产品数据甚至产品系统是有很有帮助的。这时,应该将测试环境置于某种沙箱(sand-box)中,使测试导致的产品崩溃或数据损坏不会被沙箱以外的系统所感知。

  测试环境中内建丰富的开发、测试、调试、监控工具。它们是探索所必需的指南针、GPS、电筒、绳索、背包和帐篷。有经验的探险家不会空手上路。

  最后,值得强调的是,所谓“探索”和“学习”都是隐喻(metaphor)。它们是指南针,不是规程手册。Steve McConnell在《代码大全》中用了整整第2章来讨论“用隐喻来更充分地理解软件开发”,很值得一读。通过丰富的案例和分析,他很好地论述了隐喻的威力和范围:

  与其说一个软件隐喻是一张路线图,还不如说它是一盏探照灯。它不会告诉你到哪里去寻找答案,而是告诉你该如何寻找答案。隐喻的作用更像启发性方法,而不是算法。

  A software metaphor is more like a searchlight than a road map. It doesn't tell you where to find the answer; it tells you how to look for it. A metaphor serves more as a heuristic than it does as an algorithm.

原文转自:http://www.cnblogs.com/liangshi/archive/2011/01/16/1936689.html