探索性测试心得(一)

 测试的关键在于思想和分析能力。在任何环节下，都要思考的几个问题。

这里面和理论上的东西很不一样，可以让步和需求不明确可以不覆盖，目的是以最终完成测试目标为原则。

介因存在了需求和过程不明确的比较槽糕的瀑布，计划和实际变化太大导致之前做的完全被推翻的情况，例如细节细谈讨论，但没有结果或者完全没讨论。那这个时候你该如何做呢？

在什么情况下需要进行哪一种测试？

哪些情况下需要停止测试？你知道现有工作最重要是什么？

哪些情况下必须进行测试而舍弃的一部分？

哪些情况下，完全配合项目组？

哪些情况下，不理会一些项目组的请求？

哪些情况下，可以不用测试。

 一切依赖于经验或者说是法则。

 介绍关于探索性测试的章节。

探索性测试来源于产品的测试法则。包含功能面，环境面，UED，验收等。

以上据个人不专业统计共含盖18种法则；

学院一点的探索性测试的关注点：

1） 输入（input）

2） 状态（state）

3） 执行环境（execution environment）

4） 用户数据（uesr path）

5） 代码路径（code path）

以上5点基本已经涵盖了探索性测试重要关注点，但如何去组合使用他。

探索性测试，我在思考中，发现它的奥妙是一个天生多线程的，把不同的方法揉捏在一起，又因为视角不一样而不同。

例如点：

用户因为某个功能购买了某个商品，那这个商品是否满足了用户的需求？

测试某个软件时，按步骤行走，是否满足测试和发生缺陷的预期？（软件本身的预期也包含在内，但似乎又不太重要了）

这个真是门好的知识。