作为一个测试人员，测试用例的设计是工作中必不可少的一项技能，优秀的测试用例设计不仅能够需求覆盖面，同时还能够提高工作效率。
测试用例的方法从现有的总结的方法中无非是等价类划分，边界值分析方法、错误推测法、因果图方法、判定表驱动分析方法、正交试验设计方法、功能图分析法、场景设计方法（具体操作查看测试用例设计白皮书）等等方法，回过头来想想自己设计测试用例真的只有这些设计方法么？我看未必，因为做黑盒测试的过程中，测试用例的设计过程中设计的思维方式可能很多，更多的设计的思维方式是可以归结为以上几种方式，我想要表达的是设计测试用例更应该灵活些，前辈们总结的测试方法是从实践中总结的理论知识，理论和实践是相辅相成，真实的测试过程中有很多是理论中还未总结出来的。
另外在测试过程中，有些公司的流程并不是很完善，而各个版本跌代又很快，尤其是APP开发过程中。在迭代过程中会有新功能，有原功能的优化，所以在测试中，可能需要将所有的功能都测试一遍，而这时候许多时候是测试人员根据对业务的熟悉程度执行测试，或者依据之前写的测试用例进行测试，那么可能会面临一个问题，如何在迭代版本的短时间内既要保证原有功能没有问题同时又能保证新开发功能没有问题？首先从测试用例入手，关于原有功能测试用例需要不断维护，是原有稳定功能的测试用例更加简练而功能点的覆盖率没有改变，其次新功能的测试用例在用例评审中划定优先级别。
我的印象中，测试用例的设计是建立在对业务需求理解的深度层次上的。当一个新员工刚进入接触一个软件时设计测试用例既要保证功能点覆盖率充足，在设计用例时更多的是从点入手，比如说，页面有什么控件，有什么功能，可以有哪些操作，从点到线，某个操作之后都会有什么结果，某一布的下一步可以是哪一步，逐渐了解整个软件的整个“面”，然而这时候设计的用例虽然保证了功能点的覆盖，然而却可能存在大量荣冗余的测试用例，优先级不清楚的用例，往会导致效率不高，级别较高的bug后发现。持续下去就会遇到上面一段中提到的问题，新功能和原有功能的测试如果以用例为依据测试的功能点覆盖率保障了，时间和效率降低了，以员工经验对业务理解为基础效率提高了，是否存在漏测的风险增加了。
在实际操作中，新功能或者新员工在写测试用例可以使用上面的比较方法，从各个功能点入手写测试用例，毕竟强制实现简洁的用例，较高的覆盖率的用例需要思考时间的。那么在测试用例的设计过程中，每个测试组的组员的设计用例模板一定保持一致。
其次，在随着对业务的理解加深和比较熟悉业务的人员在时间允许的情况下，完善测试用例，删除冗余的测试步骤，合并不同的预期结果。比如这样的一个功能，新注册用户第一次登陆，送积分奖励，同时系统中会发送消息，提示绑定手机号。可能在最开始的测试用例设计时会设计新用户登录一条、新注册的积分奖励一条、绑定手机功能一条用例，在随着业务的理解较深时就可以设计为一条用例，一个登录操作，验证多个功能点。不断的简化用例，设定用例的执行的优先级，等于随着时间的积累实现一个完整的用例库，每次执行按用例库的执行既能保证测试时间同时保证需求的覆盖率。