重新审视测试用例设计

    本阶段项目我们一共发现了千余个bug，通过场景及用例发现的bug只有10%；造成这种情况的原因一是因为产品处在维护阶段，先前通过用例及场景发现的问题已经不再复现、二是我们提倡以已有用例、场景激发思考，却没有将思考形成可见的交付物的导向。

    我们在每个项目的关键决策点上都在找各种产品质量状态、进度以及产品存在的潜在风险等的衡量标准，却把测试人员最根本最重要的一项工作：测试用例（场景）的设计给淡化甚而忽略了。测试用例的覆盖度、执行情况、通过情况恰是产品质量、进度及潜在风险最好的衡量指标项及参考项，也是制定测试计划、做测试跟踪的关键参考项。

    测试用例是测试人员做测试的根，测试用例设计是测试执行之前的'战略部署'，忽略了这个环节无疑是在给测试一开始就做的不合格打上的胎记。

    但是，对于一个生命周期已经处于维护阶段的产品，当先前设计的用例或场景在当前版本所发挥作用更多体现在作为验收（验证正确性）测试的依据时，如果在没有对用例及场景进行维护的背景下、在项目进度要求很紧张的大背景下，测试前期安排此类测试显然是不合适的。同时，当紧张的项目安排容不得测试进行详细用例设计便需要进入测试执行的情况下，又如何做到对测试场景及用例的持续更新呢？

    1、将测试用例的设计与编写常态化，不是说在一个项目结束而另一个项目开始之前插空，而是在测试执行过程中边测试边记录。这个被业界大师称之为探索性测试时的一项必做的测试任务，除了bug，它也是探索性测试的一个重要交付物。如果把测试过程中的想法形成交付物，大家又比较担心影响进度及所耗成本的问题，其实这个也好解决：试想一个测试人员测试了一整天，她/他当天测试思路及设计可能在下班前总结下花上半个小时便可以整理出来，只是缺乏这种意识，我们也没有这种导向，从而造成好想法及点子的流失和不可复用。这里提到了测试用例的设计而不是编写，也从一个层面上说明我们不必纠结是否要长篇大论把所有数据逻辑前后关系都写明白，只要把业务流程、关键验证点以及测试思路（等价类、边界值还是错误推测？）在原有的测试场景库上完善进去即可。但这个需要业务和测试技巧均比较熟练的测试人员才可以做到，初学者前期实施会比较吃力，同时粒度、深度、重要程度均需要制定规范并审核。

    2、真正的基于用户应用测试场景/用例设计：哪些业务流程或功能是用户经常使用的，这个前期我们在设计用户场景时也划分了优先级。但随着客户的增多、应用的逐步广泛，反馈问题的逐步积累，先前的测试场景无疑会显得过时了。也许先前认为用户不常使用的场景及功能点如今已经被新的用户作为重点使用，怎么办？及时维护，获取的渠道当然很明确来源于客户：样板及客户化组即内部客户，实施或用户反馈即外部客户。在任务没有直接关联的背景下，很难做到将此工作常态化，更合适的方法可以采用确定固定人员定期每月对客户（样板组、反馈组）进行一次访谈及问题梳理，再落实为任务单独安排1-2个工日做测试场景/用例完善。

    3、如何保证测试用例设计的8/2原则：可以解读为将80%的精力投入在重点测试用例的设计上，发现80%的bug，而不是投入在非重点的测试用例设计上；也可以解读为通过系统功能、模块覆盖度为20%的测试用例，发现80%的bug，即设计合理的测试用例保证bug覆盖度。这个可以通过各种途径熟悉用户应用模式、熟悉系统整体业务，掌握测试常用技巧及经验积累，这一点没有更好的办法，只能保持持续学习的一颗心，在任务中锻炼，循序渐进，一步一个脚印，踏实积累。

    ......

    天下无难事，只怕有心人，对于理论及方法已经相对成熟的测试用例设计，如果可以引起测试人员的重视并给与正确的引导，即使系统很庞大、业务很复杂、新手很多，也总会是方法会比困难多。怕的是没有被重视，没有人去规划。