最近晚上很拼命，连续几天晚上不停的翻阅了James Whittaker的ET书籍以及jerry的实践之路（对不起jerry和史亮，james的书连续看了3遍，烂了已经。但是你们的由于刚到，所以才看了0.5遍，哈哈）
    最近在和测试同仁的交流中发现很多人对于我的现状很惊讶。我这里可以说明一下哟。哈哈
    本名：陈晔  已婚（2012年10月2号婚礼）  微博ID：monkey陈晔晔   各个论坛和qq网名：monkeytest或者monkeytest15  工作年限即将接近3年，上海本地人，目前工作地点在上海。乐于交流，提升测试技术和方法。
   
    其实另外可能很多人惊讶的就是我到底是一个技术测试，还是一个测试leader，工作环境到底有多少测试人员。其实我可以很奇葩的告诉大家，我长期工作的环境基本都是只有我一个测试。并不存在什么test team的概念。当然我有大项目的经验，我清楚大公司的流程，我也清楚各种方法，技术应该怎么运用到各个团队中去，自然有我的方法，这里就不透露了。

    同样的，我也会证明，没有什么技术，方法，理念是必须人多，必须一个team才能够执行的。人少，甚至就如我，一个人也同样能够做，同样得到很大的提升。到现在几乎可以说用过各种方法，实行过各种流程，当然不得不说，最大的受益人的确是我自己。

    所以我也没有办法，只能拼命看书，阅读别人的经验。这里说再谈，我相信我的理解已经比我第一次写ET的blog深了。两本书各有各的着重点，各有各的优点。这里再帮jerry打个广告，探索式测试实践之路绝对是不可多得的好书！
    测试是一种探索的过程，最初取名探索，自然有很深的意义在其中。
    我相信很多人会有这样一个疑问（这个我虽然没有怎么听到别人提起，但是我相信肯定会有这样的疑问），在业界软件测试用例的方法有很多种，很多人所知的“因果图，边界值，等价类，正交”等和ET的这些方法是否有关系。就我目前的理解我并不能说两者有必然的关系，但是我将原本的测试用例设计方法看成一本最原始的教科书，而探索性的方法是一种更贴近运用，更容易让人理解的一本书。两者从不同的切入点，让使用者从不同的角度进行思考，从而编织成一张很大的网，将缺陷全部网罗其中。
    其实目前大部分的测试有一个很大的问题，人多人少不是根本的问题，请广大的leader或者tester关注一下测试的效率。
    探索性测试是一种方法，这种方法能够大大提升测试的效率，能够在短时间内找到更多的缺陷。至于方法，两本书上都说的再详细不过了，这里我就不说明了。
    探索性测试是一种过程，这个过程可能是一次测试周期，一个项目的周期，也或者是好几个项目的周期。我们做测试，可以基于风险，可以基于经验，可以基于自动化，可以基于需求，可以从不同的切入点，最终给出很多有说服性的数据。而这些数据的来源的过程即是探索本身
    探索性测试也是一种思维。曾经有人说“做任何事情其实都是探索”。不错，不同的是每个人的探索方法不同，每个人为了如何更好的探索所作的功课不同。我们所说的自动化其实就是一个很好辅助探索测试的工具。

    我一个人的测试，很多时候时间来不及，我相信没有人会比我体会更深。09年接第一个富士康的项目，单单一个产品就有22个分支code。这里我举两个例子，我用最最简单的方法而节约了大量的时间。
    在工作中，往往会进行一些极限的测试。我曾经测试过一个移动端的产品，可以进行登陆服务器而发布不同的状态从而和好友互动。那么在探索的过程中，我发现有这样一条case要去走。我想发500条状态，500个数据流到我的服务器上。这个举动不是为了测试server的压力，否则我大可以用LR。而是我想看下在这种情况下，移动端app的界面化显示以及各种交互是否正常。但是这种case就我一个测试而言，我不可能手动去打500条，虽然手动打不失为一个办法。此时我通过httpclient4.0的basic验证api以及post请求进行数据循环的发送，从而反应到我的app上。
     //basic 验证
       httpclient.getCredentialsProvider().setCredentials(                                       new AuthScope(AuthScope.ANY_HOST,AuthScope.ANY_PORT),
new UsernamePasswordCredentials("username",
"password"));
    这种可能在很多人的眼里根本不能算自动化，所以我也一直说我自己只是一个黑盒的测试，也就是这样的道理。但是这种简单的方法的确让我的探索测试更好的进行了。提升了很大的效率。
    另外在过去的测试中，我也遇见过一个很棘手的测试模块。如同google search一样的功能。但是只是搜索一个手机中的相关信息。但是让测试头大的难点有两点：
    难点一是这种搜索支持很多种搜索方式，比如搜索jerry gao，你可以输入jg，gj，jeg，gaoj，jeryyg，jerrygao等等，所有你想的到的组合都能够搜索出来。你首先要保证你输入的字符能够搜索出你想要的结果
    难点二是搜索出来很多的结果，就算你能够保证你想要的结果在其中，你如何保证你要的结果在你想要的位置
    当时我先生成了大量的数据，数据包括了中文，英文，数字，各种小语种。其加起来可能是1w左右。要知道手机上的数据要达到1w个结果已经算极限了。然后我通过搜索的逻辑（前缀匹配，倒序匹配等）从1w个数据中反生成搜索case。最终当我运行每条case之后，我将这条case对应的数据到search result list中去对比，只要找到了就证明该搜索的逻辑能够正确搜索到我想要的结果。最后根据每次搜索的到的index进行一个从我测试角度的加权算法，算出一个数据来评价这个搜索的算法是否真的满足于用户的需求。
    同样的，就我一个人而言，可能这样的功能我根本就不想去测，因为是无止境的。但是这种探索很值得，结果是发现了很多严重的缺陷。而这种探索因为每个人使用的方法不同而效率不同，达到的效果也不同。
    探索是方法，探索是过程，探索是思维，探索也是一种精神。任何东西物极必反，不要盲目追求自动化，不要盲目追求全覆盖测试，不要盲目追求探索，更加不要盲目追求别的公司的规范的流程等。所谓探索就是不停的变化，这种变化只为了达到自己的测试目的，每个公司，每个人面对的环境，产品都不同。能很好的完成我们自己的测试，适合自己的就是最好的。
---------------------------------------------------------------------------------------------
转自：http://blog.sina.com.cn/s/blog_7022adbf01013h2u.html
作者：陈晔