探索性测试及应用

告诉你什么是探索性测试？　　第一次听到探索性测试这个词是去年的10月份。一个微博上的朋友写了一篇关于探索式测试的blog，之后断断续续的阅读了不少相关资料，参加了数场相关讨论，但是还是没有得到一个系统的理解。8月29日晚上有幸聆听了测试顶级专家Micheal Bolton(不是唱歌的那个，是做测试的)关于探索性测试的演讲，解决了数个困扰我很久疑惑。我终于得以把这些知识理清，下面我会把我所理解的探索性测试跟大家做一个分享。　　探索性测试的历史和主旨　　探索性测试是近十几年内才形成体系的一种测试思想，它的核心理论由Jame Bach在1995年提出，并在数年间由学者和业界的测试工作者不断完善而形成的理论。测试大师Cem Caner在02年首次以“Exploratory Testing”(探索性测试)的名称在学界和业界开始相关的演讲和培训。探索式测试的方法论在这10余年期间不断被测试先锋们不断磨炼和修正，终于在11年，担任过微软和Google测试总监的James Whittaker出版了《探索性测试》一书，让探索式测试在业内获得了广泛关注，并掀起了一股学习和研究热潮。　　探索性测试的核心思想是：测试是一个不断学习，不断探索的创造性过程。测试计划、分析、设计、执行其实是相辅相成，相互交织的。依照传统的测试理论，把这四部分在时间上严格区分会限制人的创造性和，进而影响测试效果。同时静态的测试方案和测试用例不足以覆盖对动态系统的测试。探索性测试强调不断的学习、探索，不断的修正测试方法，十分强调人的能动性是它最大的亮点。　　探索性测试实际上是将戴明环方法(PDCA)做到了极致，也可以说做到了时间上的交织和同步------在做测试执行的时候，测试者也在做测试分析与设计，同时还可能在修改测试计划，这时候我们就会发现我们现在沿用的一些测试文档例如测试计划文档、测试需求、测试用例这些东西就不大好用了，因为修改频繁，全部记录下来代价太大，且强制划分文档类型会打乱思维。因此探索性测试强调灵活的记录测试的产物,而不必循规蹈矩，这在形式上与传统的测试(探索性测试将传统称为依托脚本的测试，script test)是有极大矛盾的，这也是探索性测试在业界引起的最大争议。　　探索性测试有迹可循么?　　　其实探索性测试和所谓的传统测试并不是冲突和矛盾的，在实践过程中也不会走两个极端。我在交流过程中问了Micheal Bolton他们是否矛盾的问题。他的回答是：“我们可以找两个端点，一端是把人当作生产线螺丝的严格依照脚本进行测试方式，一端是把人比作一个小孩的完全探索性测试，实际工作中，我们肯定是在这两个点连线中的某一个点。具体这个点在哪里，要看它在哪里能够更好的开展测试。”正所谓法无定法，我们其实完全没有必要去恪守、捍卫教条，并非争出个高下来，黑猫白猫，抓住老鼠就是好猫。　　探索性测试的应用情况　　据我所知，目前探索性测试还处在一个方兴未艾的阶段。国外的少部(微软，google等)已经从某种程度上应用了探索性测试方法。在国内，百度，淘宝等知名企业也开始从一定程度上来使用探索性测试，在近期的Chinatest大会上，他们也都各自分享了自己的实践方案，值得一提的是，Chinatest大会上，探索性测试分会场是最火爆的，参与人数是其它会场的快2倍了。因此在国内大家还是对探索性测试相当有兴趣，大家都希望能够把它引入实践来提升实际测试能力。相信在未来的几年，一定是探索性测试大发展的时期。　　探索性测试能应用到我们的工作中来么?　　答案必然也是肯定的。依照我的判断，它对于我们近期重点工作项都可能会带来一定的益处。　　Ø 于分布式测试　　目前我们和重庆的分布式测试合作主要采取了“分层测试”的模式，即北京同事编写测试用例，重庆的同事来进行执行。从目前的情况来看，分层测试有效的实现了北京重庆之间的测试协作，分流了很多北京的测试工作量，且保持了测试质量不下降，测试进度没有延长，可以说分层测试是比较成功的。但是，我们的分布式测试是否还可以做进一步改进呢?仔细想想还是有的。　　随着分布式测试的不断发展，由于重庆测试资源的源源不断补充，解决测试人力资源不足问题将不再会是工作的重点，工作的重点将会慢慢转移到如何提高整体测试能力上来。目前，重庆测试人员能力在逐步提高，已经有了一定的测试设计能力，严格依照测试用例进行测试的方式会一定程度上限制他们能力的发展，但是项目的复杂性及重庆的异地因素又导致重庆无法有效独立完成测试的分析及设计工作。再者，测试工作的精华很大一部分在于测试执行部分，如果放弃测试执行，也不利于北京测试人员的发展。探索式测试的核心思想认为测试过程是不能被简单分割的，我们可以采用这个思想对我们的测试流程做一定改造。