当下，敏捷开发和敏捷测试成为越来越普遍的开发和测试方式，配合敏捷测试，探索性测试也越来越多的被部署到实际工作中。

　　然而，真的是每个tester都有能力来执行探索性测试吗？这里借助一段话来表明我的观点"探索性测试不是游览---->在一种极端的情况中，一个游客会到达一个地方，而她对这里的风景，动植物及人类文化都不是很了解，此时只有一个目标，那就是要去探究这里的风土人情。在这样的情况下，我们会把她叫做游客；而不会称她为人类学家或植物学家，亦或地理学家或考古学家。"

　　没错， 探索性测试不是游览，但是，我们如何让每个tester用最快的时间变成专家呢？我认为一个相对成熟测试用例集是最快也是最好的让tester变成专家的东东。

　　下面的问题又来的，测试用例难道要在探索测试中去执行吗？这和普通的测试有什么区别？怎么最优化？怎么自动化？

　　哈哈，请继续看下去。

　　这里我要引入一个常用的算法--->遗传算法

　　什么是遗传算法？ 请参考百度百科：http://baike.baidu.com/view/45853.htm

　　没错，通过遗传算法，不断的以现有的测试用例集为基础，让机器执行自动化测试并生成结果，之后根据测试结果，通过遗传算法，来不断的选出最优的测试用例，并使之作为下一次测试执行的父用例。

　　但是，这样也存在一个问题，就是我们的父用例越来越少，且计算结果会过于狭隘，怎么办呢？

　　接下来，我们可以引入变异用例，就像现实中遗传存在的变异一样，我们可以根据测试产品的特点和相应功能的特点以及前一轮的测试结果，来将这些变成变异用例，从而为生成下一轮测试用例提供足够的变异。当然，我们也可以根据我们的测试思路来生成变异用例，从而主导机器向我们想要测试方向前进。

　　由于根据遗传算法生成的测试用例都是若干轮中最优的，因此，可以最大限度在保证测试基本质量的前提下，朝着最优的方向不断探索。这样我们的就达到了我们最初的目的，即探索测试中最优测试方向的自动探索。

　　可能又会有人提出异议，测试用例是固定的，而我们的产品可不是一成不变的，但是，之前的文章中提到的最初的测试用例集要是不符合产品的特点，那么恐怕仅仅依靠之后的变异用例也不能使机器朝着最优的方向探索吧。

　　没错。这确实是是一个问题，但是我有其它的方式来解决它。靠人工去筛选符合的最初用例集吗？

　　我的回答是否定的，没错！还是靠自动化来筛选。至于怎么筛选，之后我还会陆续发表文章来阐述。

　　在竞争日趋激烈的今天，怎么能够用最少的人力，最好的解决问题是每个企业都关注的问题。而测试工作往往又是被公司最不太重视的。

　　因此，自动化也许是一个解决这个问题的方向，通过本文阐述的观点，也许我们可以用最少的人力来达到最好，最快的探索测试的效果。

　　希望大家能给予斧正，谢谢。

　　本文转载自：http://kan.weibo.com/con/3520213900161601?_from=image