3.1.24 重灾区的测试探索
经常听到这么一句话：80%的Bug出现在20%的功能点上，所以软件测试时，对于经常出现Bug的功能点，一定要小心，小心再小心，认真，认真，再认真。这样做往往会找到更多的Bug。有时需要一定的时间和一定数量的测试工程师对这些模块进行专注的测试。
案例3-26：购物车。
某网站增加了网上购物功能，经过前一段的探索式测试，发现购物车功能暴露出的缺陷最多，经过测试小组研究决定，准备让3位工程师集中精力，分别对这个子模块进行3个小时的基于测程的探索式测试。（关于基于测程的探索式测试，参见第三篇“软件测试管理篇”的“精益创业与探索式软件测试”的介绍）。
3.1.25 强迫症测试法的测试探索
强迫症测试法是James A. Whittaker在他的著作《探索式软件测试》中描述的。采取强迫症软件测试法往往会发现程序中出现的系统内存泄露等问题。
案例3-27：系统的登录与登出。
几年前，笔者在测试一个产品角色功能模块时，需要不断地登出、登录系统，后来发现经过多次登出、登录操作后系统就会出现死机现象，最后经过程序员排查，发现是程序中的一个指针用完后没有及时释放造成的。
由于不可能对所有模块都进行强迫症测试法，所以在哪里进行强迫症测试法需要依据测试工程师的经验。当然，还可以借助某些工具进行强迫症软件测试法，这样可以节省很多精力。
案例3-28：放入购物车与从购物车中移除商品
考虑到顾客进行购物时经常会出现的一个情形：对选购的商品犹豫不决，于是，使用脚本模拟了一个情形：用户每往购物车中放入3个商品，就移除两个，整个过程循环10000次。经过测试没有发现问题，从而增加了测试人员对产品的信心。
3.1.26 升级的测试探索
一个产品不可能一次就能满足用户的需求，肯定需要经过多个版本，尤其是敏捷开发概念提出后，版本发布越来越频繁。现在产品大多支持在旧的产品的基础上，不删除旧的产品，直接运行升级脚本，从而完成升级。对于一些实时性要求很高的产品，如通信产品，在升级的过程中还需要考虑不影响通信业务的正常运行。另外，软件测试升级操作失败后，都要将产品进行还原（Restore）操作，还原到升级之前的版本，以保证用户仍旧可以在旧的版本上继续使用。
案例3-29：电信领域的升级
在本篇第1章“可靠性测试”中提到电信领域的可靠性为5个9，即99.999%。然而，电信产品的升级是经常的，为了避免升级过程中造成业务中断，可采用如下主备机网络环境设置，如图3-6所示。
图3-6 主备机网络环境设置
主备机网络环境设置下，一台机器处于运行状态（图3-6中的服务器A），另一台机器处于待命状态（图3-6中的服务器B），运行状态的机器一旦发生故障，系统则立刻切换到待命机器，这样运行机器与待命机器的角色就发生了转换，即待命机变成了运行状态，而运行机变成了待命状态。当然为了转换后待命机能够立刻代替服务机进行工作，在待命机与服务机之间每隔一段时间通过心跳线的同步操作。
这种设计在增加可靠性同时，也给系统的无缝升级带来很大好处，如要对服务端软件从3.23.3升级到4.0，可以先升级服务器B，让服务器A处于工作状态；当服务器端B升级完毕，把服务器A断掉，系统自动切换到服务器端B进行运作，这样就可以升级服务器端A了。需要特别指出的是，不管在服务器A，还是在服务器B进行升级操作，一旦发生了问题，一定要能够返回到原始的版本。比如，在服务器B上升级成功，而在服务器A升级失败，必须能够在服务器A把版本复原到3.23.3，然后在服务器B也同样复原到3.23.3。
3.1.27 总结
探索式软件测试强调在一个测程内进行测试设计、测试执行，然后对测试结果分析总结，从而进一步学习业务知识、测试技巧、测试工具…。重新调整测试策略，然后进入下一个测程。所以，及时总结测试方法在探索式测试中是非常重要的，应该把这些测试方法放在一个大家都可以看到的地方，如WiKi，便于大家及时查看和学习。软件测试工程师学习软件测试方法可以提高自己的软件测试技能；开发工程师学习软件测试方法可以在开发时尽量避免发生错误，从而起到缺陷预防的效果。基于测程的方法，本书第三篇“软件测试管理篇”第13.7节“精益创业与探索式软件测试”中进行介绍。
顾翔凡言：
敏捷具有适用性，即使用了敏捷，也不要做成假敏捷，掌握敏捷的真谛。
