[如需转载，请在转载时注明出处，并保证本文的完整性] 

         2007年写的一篇组内分享文档：

“如果把测试比喻成树的话,那么测试思想是主干,工具是支干和叶子,支干和叶子的茂盛使树显得更强盛,但如果少了主干的支撑,支干也就无扬展的空间。”

 快速测试是一种思想，最近在网上看到了介绍快速测试的文章，然后发现在项目组内优秀的提交bug率较高的测试人员，在某些阶段或多或少的会应用到快速测试的思想。

快速测试具有几个特性：

1、消灭掉任何不必要的活动；

2、估算一下软件的形势，立即开始执行的最快、最有用的行动；

3、测试技巧的重要性；

4、投入主要精力来测试最有风险的问题；

5、探索性测试：发散性的思维、充分联想；

6、启发法：当心高估所测试的问题；

7、团队合作：充分利用资源；

8、思考和反省：多问为什么。

我们最近读了《高效能人士的七个好习惯》，其中“要事第一”的习惯在快速测试思想中得到了充分的应用。相对与我们项目组任务重时间紧的现状，我们测试人员的目标就是保证重点功能的质量并及早关键发现问题所在，提高整个项目组的进度。

在我们的测试工作中如何应用快速测试呢？我说下我的想法：

一般在测试前期软件问题比较多的情况下为了及时发现问题，我们的测试效率尤为重要。新版本出来后，这里指没有冒烟的版本，我们测试人员要像嗅觉灵敏的狼，及时得发现目标，也就是测试重点模块。这时的测试重点主要就是新增加或修改功能，也许开发人员没有及时告知哪里新增加了功能，哪里刚修改了重大bug。这时就要充分发挥团队合作精神，充分利用资源。可以做的方法有：1、与开发人员沟通，从产品的直接开发者那里得到最新的消息；2、分析bug修改状况：通过TD库的最近重大bug修改情况来得知程序最近修改的功能。

不要被文档所禁锢，我们测试工作中会有很多文档：《相关需求文档》、《测试用例》、《封版测试记录checklist》等等。如果不是初学测试者，我们就不必要在工作中，对着需求特性来一条一条测试、按着用例或checklist一步一步走。过多得对文档的依赖，只会浪费过多时间和降低测试效率。我以前的工作中就是这样，有时会感觉任务总是完不成，难道是计划的问题，可是考虑项目组的现状，只能从自身上找原因，找方法。

个人认为需求文档的理解应该在前期多花费一些时间，充分的理解，在测试过程中要尽量减少翻阅文档的次数；测试用例，对于不熟悉的模块或第一次测试某个模块，可以来走一下用例，测试用例中包含了编写者的测试思路，如果只是按照用例编写者的思路或完全按照自己的思路测试，都是不正确和不全面的，最好的方法是结合两者；《封版测试记录checklist》：当然在完整和标准的封版测试过程中，是需要严格按照checlist来执行的，用来保证覆盖率和记录问题。还是考虑现状，现在测试一个地区，每个人在封版测试时都要过四五个库，而有时每个库都会有2~3个模板，而时间只有4~5天时间。不可能每个库每个模板都走一遍的。这时就要分清主次，重点库重点测试，运用等价类划分，同类模板重点测试一个。我认为好的做法就是在熟悉软件功能的前提下，脱离checklist来测试，测试完了再来看一下checklist，然后看有没有漏掉的地方。

无论什么思想、什么方法都要通过实践来检验，在以后的测试工作中还要不断总结、不断思考。没有一个方法或思想是为我们量身定做的，因此我们还要多多结合我们的测试工作来应用。

                                                     GBQ  熊志男

                                                          2007-12-30