3、特定切面用例设计
　　所谓特定切面，其实是从另一个角度切割出来的用例面，所以具体的用例撰写方式其实与功能切面是一致的。
　　4、隐含切面用例设计
　　隐含切面分以下几种情况：
　　（1）、无界面的后台功能
　　对这类测试项，需要通过参数设置、代码调用等方式来实现测试，但具体的测试设计其实与普通功能测试并无二致。这里要注意，因为测试时往往前台、后台是分开来分别进行的，而实际运行时两者很可能是交集的，所以测试时要多注意后台功能的执行与前台的一些功能执行会否产生冲突？比如后台有个文件搬运的服务，那有没有可能在前台文件生成过程中，后台执行文件搬运了？若有可能要注意会否出现问题了。
　　（2）、与业务流相关的测试
　　这类测试用例的设计，要从完整业务角度来设计数据了。从理论上来讲，应该要将各个功能可能出现的各种数据排列组合到一起，按业务流程逐一进行测试。但实际上我们不可能去做全覆盖。所以设计这类用例时，好有一张草稿，将所有相关功能按业务流程逐一列示，然后再将每个功能可能出现的特定数据一一标上，后将图中可能出现的、可能出错的、核心的数据取出来，分别组合成一个个完整的业务数据用例，来进行测试。这样可以按清晰的思路，找出实用、有效的测试数据。
　　（3）、其它测试类型
　　这一类的测试通常都有其特定的方法。如要测可靠性准备大量数据不停地执行；要测安全性考虑数据的加密、数据的传输、数据的破坏；恢复性一般从网络、电源方面着手；配置安装则根据系统可支持的配置，搭建相应环境进行功能验证，此处的验证也要掌握技巧，即要多测试那些涉及到：数据库读写、磁盘文件读写、文件上传下载、文件加解密、数据统计、图表展现、打印等方面的功能。
　　三、测试数据的设计
　　每一个测试思路终都要转化成具体的数据才能来执行。关于测试数据设计的方法也不外乎那几种，不再赘述了。此处单一些经常易犯的错误，提出一些注意点，作为用例数据设计时的参考：
　　1、尽量避免可能出现歧义测试结果的数据：即你设计的数据必须能正确地反映出你所希望测试的结果。比如一组测试数据，有可能得到结果A或结果B，此时单用此数据来测试预期结果为A的用例，那明显产生了歧义。
　　2、对于不便具体列示的数据，则必须详细描述其各项特性：有时我们在设计用例时为节约时间，不一定要到具体的一个数值，这也是允许的，但前提是你必须要详细描述清楚你要测试的数据特性。比如数据库字段限长20，要测试超长数据时，可以描述为：尝试输入长度为21位的半角英文字符；尝试输入长度为19位的半角英文字符，然后切换到中文全角再输入一位全角字符等。千万不能写成：尝试输入超长字符，因为这只能是测试方案，作为方案是可以这样写，但到用例阶段，必须要是具体的、明确的、可操作的。
　　3、测试数据的设计必须有明确目的性：即测试数据是从测试方案衍生而来的。如上例测试方案是测超长字符输入控制，所以测试数据要根据具体字段长度来录入超长数据，如果一味录入长15位、长16位的数据那没意义了。好的测试数据是可以同时针对多个测试方案的，此时可以在用例边注明一下该数据的测试目的，因为随着时间推移，对着具体的数据你也许会忘了它到底是测什么的，而这对你后总结测试，查验测试覆盖率是非常不利的，所以随时记下你的思路想法吧，好记性不如烂笔头。
　　4、测试数据可省略描述：测试数据描述以能让人看懂为准则。所以写用例时当碰到连续几个用例，仅某几个关键数据值改动，其余均是一样的情况下，不必每个用例都要重复描述所有数据，可以在第一个用例描述完整之后，其余用例中仅列示不同的数据，并标明其余数据同上第X个用例，即可。这样测试时仍能复原测试数据，且该用例的测试目的一眼明，增加了用例的清晰性。
　　至些，我根据测试用例设计的顺序，从测试数据的切面设计（即测试项划分），到详细测试用例设计，再到测试数据设计三个层面，逐一介绍了如何来提高测试用例的覆盖度。因为具体项目中的具体情况太多，以上叙述的内容也只能是管窥蠡测。至于其中的疏漏错误之处应也难免，只希望各位阅后能打开思路，从自己多年的测试经验中多总结、提炼出一些想法思路，进一步补充完善这个文档，使大家的测试用例设计能力都能进一步提升。