探索性测试的应用情况

探索性测试的应用情况

答案必然也是肯定的。依照我的判断，它对于我们近期重点工作项都可能会带来一定的益处。

● 于分布式测试

目前我们和重庆的分布式测试合作主要采取了“分层测试”的模式，即北京同事编写测试用例，重庆的同事来进行执行。从目前的情况来看，分层测试有效的实现了北京重庆之间的测试协作，分流了很多北京的测试工作量，且保持了测试质量不下降，测试进度没有延长，可以说分层测试是比较成功的。但是，我们的分布式测试是否还可以做进一步改进呢?仔细想想还是有的。

随着分布式测试的不断发展，由于重庆测试资源的源源不断补充，解决测试人力资源不足问题将不再会是工作的重点，工作的重点将会慢慢转移到如何提高整体测试能力上来。目前，重庆测试人员能力在逐步提高，已经有了一定的测试设计能力，严格依照测试用例进行测试的方式会一定程度上限制他们能力的发展，但是项目的复杂性及重庆的异地因素又导致重庆无法有效独立完成测试的分析及设计工作。再者，测试工作的精华很大一部分在于测试执行部分，如果放弃测试执行，也不利于北京测试人员的发展。探索式测试的核心思想认为测试过程是不能被简单分割的，我们可以采用这个思想对我们的测试流程做一定改造。

即，从一定程度上打破这种严格意义上的阶段区分，例如，如让重庆同事参与部分测试用例分析、设计工作，北京同事也参与用例执行工作等。两边可以进一步增进交流，进一步释放双方的能动性，达到提升航信测试部门整体测试水平的目的。

● 于自动化：

自动化是减轻重复劳动的利器，但是自动化是无法代替手工测试的。因为测试是一项依靠人的创造性的活动。人类可以感知，可以联想，可以推理，可以创造，这些元素都是测试执行期间必不可少的因素，而目前别说是自动化脚本，就是最好的人工智能程序也离上述元素差着十万八千里。因此自动化只能是测试活动的一部分。

由于自动化可以有效减轻重复劳动，探索性测试索要避免的就是被重复性劳动牵涉太多精力，其实两者是一个非常好的互补。有一个非常好的办法可以让两者很好的结合起来，那就是，及时的整理探索性测试中的用例，将它们及时变成自动化脚本。这种做法其实跟我们经常说的持续集成的思想是一致的。同时，良好的自动化脚本也是测试资产的一个积累，从某种程度上弥补了探索性测试不太注重文档的问题。

● 于敏捷：

探索性测试简直就是为敏捷而生的，敏捷宣言中的个体和互动高于流程和工具、工作的软件高于详尽的文档、响应变化高于遵循计划与探索性测试的核心思想不谋而合。随着敏捷开发在公司的深入开展，我们可以尝试性的将探索式测试与敏捷开发结合起来。根据同其它公司的同行交流，这种方法能够带来很好的效果。