探讨一下探索式测试

探讨一下探索式测试

探索式测试(Exploratory Testing，以下简称ET)是什么?

现在可能越来越多的测试同仁们，测试论坛开始讨论ET。ET现在炙手可热，但是否ET适合自己所处的环境?是否适合任何一个项目?执行ET的过程中又碰见哪些问题呢?传统的瀑布流又在什么位置呢?我们来一起做一下探讨吧!

现在很多的呼声会说ET只适合于中小企业和迭代周期快的项目。说的很对，但是笔者的理解却稍有不同。只要企业的产品有测试这个环节，无论你是一个资深测试还是一个初入测试门的新人，只要想进行ET，那么无论项目大小，无论测试人员多少，无论项目进行到哪个节点都能够进行ET。

大部分的企业目前都是处于使用ST(Script-base Test或ScriptedTesting)的方法进行测试。那么我们应该怎么适当的使用ET，让ET能够在不降低当前产品质量的前提下很顺利的合入公司的测试活动中呢?下面会进行详细的说明，不过在这之前，我们需要来明确一些前提，只有在理解这些前提的情况下，才能够做好测试：

● ST和ET不是万能的方法，不能仅仅依靠其中的某种方法一路走到底。

● 计划永远赶不上变化，测试活动必须适当的适应实际情况

● 任何的测试都应该基于风险的评估

● 任何的测试都应该基于上下文环境进行实施

● ST中所有的步骤在ET并非是省略，而是进行适当的简化，从而达到更高的测试效率

● 测试活动并非局限于一个周期，而是一个长期的活动，是一个循序渐进，不停改进总结提升的过程。

认同这些前提之后，我们来看一下在实施ET的过程中可预见的一些问题以及解决的方法：

1、公司或者测试团队如何先踏出第一步

首先如果你是一个leader或者manager，你想推ET的话需要先考虑好过程中的一些细节问题，怎么推，怎么考评，怎么引导大家去做等。考虑成熟之后再进行推广，否则不仅不会提升测试的效率还会弄的公司一团糟。如果公司的上层很好沟通，那么你可以选择和公司上层直接进行沟通表达测试团队接下来会引入一种新的测试方法以及引入带来的利弊。上层并非那么容易说服的话，那么你可以先和你团队中经验丰富的测试先进行一部分功能的ET，将结论总结好然后再去和上层交涉，这样的话相对也更加有说服力。针对测试团队来讲，应该进行相应的概念和方法的培训，让测试团队的每个成员充分的了解什么ET，ET和ST的区别是什么，ET的优缺点分别是什么，测试团队为什么要引入这样的方法等。以上这些是你要推广和实施ET前必须要做的事情。

2、怎么在风险可控的前提下施行ET，ET中的人员KPI又怎么评定

其实测试的模式中有很多的模式能够很好的辅助进行ET。

其中一个方法就是交叉测试。无论哪个测试人员，其测试的时候总会有所谓的测试盲点，总会有某些测试点遗漏。此时交叉测试模式既能够加强ET测试的覆盖面又能够同时给测试人员带来更多的想法。不失为一种很好的方法。

另外一个方法就是结对测试。结对测试主要的作用是能够让一个测试新人更快的积累经验，更快的成长。一般情况下是一个资深测试和一个测试新人结对同时进行测试，资深的测试人员可以对测试过程中对于业务和测试方法进行指导，同时也可以学习新人进行测试时候的思想并总结。

还有一个就是Bug Bash。在每个项目发布前的一段时间最好能够组织全公司或者全team进行bug bash。每次bash时间一般在3个小时，现在这个方法越来越多的公司引入并成功找到产品隐藏的缺陷。这种活动可以看作为全员在做测试，结果对于ET的补充和总结很有帮助。

测试的KPI考评永远是一个难题，更加就不用说在ET下考评。我在推荐一种自己总结的方法，将ET的每个活动都定成Task，其中高风险高优先的全部由测试leader主动分配给测试人员，低风险低优先的由团队成员自由领取执行或者创建新的Task执行。每个Task中都需要测试人员写明ET的目的，使用的方法，测试范围，时间等。最终根据每个测试人员对于高低风险Task的完成数量，完成时间，完成质量加权之后进行相对应的考评。这样也很有说服性。

3、ET要写测试用例么?和ST的用例一样吗?回归测试怎么做?发现了bug之后应该怎么总结

笔者觉得ET的测试用例更加像一种思维导图，或者思维引导，并没有具体的形态。但是我们需要记录的是一种思维，并非一种特定的现象(如果某些功能测试步骤和测试结果一直不变，比如数据库的测试，比如一些对话框的测试，那么可以将他们列入ST的测试用例中，也可以在ET的思维导图中备注一下)ET所需要的其实是一种思维，引导测试应该从什么测试点入手，每个功能适合用什么切入点去测试。在第2点中我提到的Task中测试leader就必须写清楚测试切入点，可能出现的问题点，这样一来降低了因为测试人员能力不同而导致的风险，二来同时也引导了新的测试人员，将经验很好的传达给了他们。

针对回归测试，可以通过回归在上一个周期中已发现的缺陷来达到相应的目的。另外你也可以建立ET的用例库，将高风险的缺陷或者测试点总结放在其中，然后作为回归测试来执行。

ET发现缺陷，缺陷首先你肯定需要在你的系统中进行记录，其次就是要记录到你或者整个团队的一个库中。它是一种思路，一种经验，以便于引导下次测试该模块的测试人员。

4、进行ST和ET的权限，什么时机是执行ET最好的时期呢

怎么权衡ST和ET，可能每个执行的测试人员都会纠结这个问题，以下我假设两个测试环境以及对应的方式你就会明白了。

假设你的团队成员经验都不是很多，产品也还没有进入缺陷稳定的周期，同时也没有很完善的自动化辅助测试。那么你需要将高风险的功能点总结出来，然后组织团队进行测试用例的编写。那么这部分的功能就是主要以ST为主，ET为辅的方式进行测试。而其余的功能你可以一半时间使用ST，一半时间使用ET。其思路就是ST保证高风险功能点以及产品的各个基本功能点，产品经过ST之后不会产生高风险的问题。同时结合ET，让产品从用户体验、界面友好性等各个方面进行测试验证。

假设团队成员都已经非常有经验，产品也是处于稳定期。那么你就可以使用ET为主，ST为辅的方式。同样的这样会加快团队使用ET的经验。ST同样是为了保证基本功能点以及一些固定数据的测试点，ET就能够在短时间内更多的发现产品的缺陷。

任何一种方法都不会在马上见成效，很多测试会觉得ET没有成效。因为以上所有的策略都是基于风险能够评估之后制定出来的。而风险如何评估需要测试团队长期对于产品的一种了解，一种数据的积累分析而得出。而风险的高低在项目中又是不断变化的，所以我们必须在项目中灵活的进行ST和ET的安排，而不是完全根据计划按部就班。什么时候是施行ET最好的时期呢?根据项目实际情况，你认为合适的时期就是合适的。ET也需要经验的积累，思维的积累，流程的改善等过程，只有经过了几个迭代周期的考验才会看得更加清楚，效果才会显著。

最后来谈一下自动化测试和ET的关系。ET的思维，方法也同样能够运用在自动化的用例设计中。而自动化同样的也是能够让测试人员更好的进行ET的工具。举个例子来讲，如果需要测试一个功能的边界，需要在界面上大量的输入数据从而查看界面的显示。此时你有两种方法，人工的进行输入，又或者编写自动化脚本生成大量的输入数据。两种方法都是可行的，但自动化的方法能够让测试效率大大提升。这也是我们一直说测试其实是和时间战斗的一个主要原因。

探索是方法，探索是过程，探索是思维，探索也是一种精神。不过任何东西物极必反，所以不要盲目追求探索，不要盲目追求全覆盖测试，不要盲目追求完美的自动化，更加不要盲目追求别的企业的工程的流程等。所谓探索就是为了在项目变化中更好的进行测试，这种变化只为了达到自己的测试目的，每个企业，每个测试人员面对的环境，产品都不同。什么是最好的?能达到自己的测试目标，能够满足自己企业，自己眼前的测试需求，就是最好的。

最后希望大家能够通过这篇文章更好的认识探索式测试，并运用到项目流程中去。