测试构想

　　一般来说，大多数人做事之前先打个“草稿”。同样，在测试实践中，我们有这样的经验：喜欢在做事之前，预想一些案例，这些案例很“杂乱”，是凭着测试者的先期经验或者感觉，进行编写。做这个工作，应该在测试计划之前，有点像部队推演“沙盘”。对于没有测试经验的测试者，也会根据一些所学，进行这类活动的。在平时，或多或少对新手和老手，或者水平高的对水平低的测试者观察了一番，觉得这“打草稿”，还真的有些学问。

　　先不妨引入一个叫“测试构想”的词语，关于“测试构想”，可以这样认为：就是你用它来找出BUG的测试要点，是你编写测试用例的基础，或者就是测试用例的一种升华或抽象。是测试中的一种感性概念，实例化可以举画画中画轮廓类比，主要是一种测试感觉。

　　有“测试构想”这个东西，还是好好研究一下。意图是形成测试构架观。测试时，先做一种预处理工作，将测试“经验”、“灵感”变成一种针对具体项目的“简构架”，这个构架可以很方便的去让事情畅快运行，你在过程中就可以轻松的做好事情。主要目的还是想通过整理，有效的指导工作。

　　曾经编写过一些测试案例指导测试员测试，在编写之前，脑子中就会有相关的测试项目出现的问题，还有一些相关的经典案例。这些东西，并不是较全面案例，但是，一旦组入案例中，这些东西，往往有一些效果，特别是做衍生机型。

　　如何去走这样的路？

　　1、有效的进行积累工作。

　　凡是在工作实践中的事情，有些事潜移默化的，你自然记住，这些东西一般来说，就是工作感觉。对于这类感觉，个人比较赞成，进行阶段性总结，做好思想笔记。还有一类是，突发事件，对于项目中的某些很特殊很有“味道”的问题，最好也是做好工作笔记。其实，整个工作的过程，就是积累过程，但是这个积累，必须要有好的方法去消化，记住。否则，时间久了，也就忘记了，积累也就没有了，那如果做一个类似项目，你有得重新做起。

　　这个好像跟“测试构想”没有多大关系吧？不是。测试构想是没有积累就可以有，但是这个构想有用与否，是否可以产生作用，是跟积累有很大的关系。同样的一个测试项目，有些工程师考虑的周全一些，有些就粗糙一些，跟测试积累有很大关系。这里强调积累，有助于产生高效的构想。

　　2、尽量形成一个“测试构想目录”。

　　引用一篇文章中提到的一个定义和实例，如下：

　　定义：测试构想目录就是列出了最有可能发现大多数可能存在的软件故障的测试构想列表。

　　如一个查询功能，你的测试构想是什么?

　　设有以下几点：1)、无条件；2)、一个或者几个查询条件；3)、是否支持模糊查询；4)、是否可用OR ,ADN等连接；5)、结果是否导出；6)、结果是否支持排序……

　　那么，这个构想，你记录了吗?抽象了吗?在以后的测试编写中使用了吗?完善了吗?如果答案是肯定的。那么你的测试构想积累的多了，形成了目录了，那么你的经验也就是慢慢积累了。之后，就是具体化工作了。

　　3、如何能做成一本好的目录呢?

　　首先：它包含好测试构想（这是针对于测试的深度和广度来说），这时，需要继承一些积累，预估一些问题，还可以有自己内心中的一个与类似东西的差分表。

　　其次：易于快速阅读(略读)、好查、好用，可以很容易地找到你想到的，忽略你不要的。

　　最后：只包含你要的。

　　不同的领域做不同的构想。就象你编程时，不同的业务构建不同的模块一样。

　　当然，通用的，可以创建通用的目录。

　　目录的内容涉及，需要你的经验积累，甚至包含一些自己对测试对象的了解，有句话“了解有多深测试有多深”。

　　4、将目录草图进行沟通

　　预则立不预则废，这里的“预”不是一个人在做。

　　形成自己的目录后，和你的工作伙伴沟通，彼此再构想一下。因为是构想，所以其中的每一个点是很抽象的，他代表了一大片东西。一般来说，构想中存在差异，具体执行中也许就是一大片存在的差异。

　　每个人的测试思维都是独立的，覆盖面也是不一样。大家在一起，互补一下，可以扩大有效抽象面，减少无效面。对于执行团队来说，是少做了一些无用功。

　　同时，做好差异化分析，取长补短，总结积累。

　　测试构想之后，就应该形成具体一点的东西，可以是测试计划，案例草案等等。