小侠接触搜索测试已经快一年了，平常接手的项目也不少，对于测试理论、方法和实践有了一套自己的心得体会，长期以来，形成了自己设 计测试用例，以及测试执行的方法，工作效率有了提高，当然是很高兴的，然而，慢慢也有了迷惑，想了解别人是如何设计测试用例的。开发有 codereview，测试有casereview。最近有个大项目，整个项目的逻辑比较复杂，趁着用例评审会议，正是学习的大好时机。

　　小侠接触的测试以业务逻辑为主，一般的测试方式是构造数据的输入，根据需求和设计的逻辑，验证输出的字段是否符合预期。这次的项目，涉及到8个全新 的字段，和1个原有字段的逻辑修改，占原有字段数的10%。包括师兄师姐在内，全组几个人全部参与到项目中，分别设计测试用例，在会上汇总讲解。通过比较 以及后续的用例执行，发现了测试中存在的一些问题和可以改进的测试方法。

　　一、测试用例设计的不同维度

　　测试用例设计的时候，可以有不同的维度来考虑。小侠是按照开发的流程和数据的准备过程设计的测试用例。由于逻辑较多、数据流较复杂，造成用例图很 大，分支很多。进行case评审，讲解的时候比较麻烦。对case进行设计，可以按照用户的维度或者说是功能的维度进行考虑。例如涉及到字段逻辑的，列出 来有哪些字段，按照每一个字段的逻辑来书写case，这样讲解的时候会比较直观，同时后续接手的时候看起来也会比较清晰。

　　当逻辑较少时，两者相差无几；但是逻辑字段较多，第二种用户维度的case设计就有了较大的优势，直观，能够为测试执行提供一个清晰思路，不会漏测，也不会做重复的无用功。

　　二、测试用例的粒度

　　测试用例设计的粒度，是否应该包括测试数据的准备全过程。小侠的想法是，一个完整的测试用例，是需要包含测试数据的准备过程的。即测试用例图中，针 对每一个功能点，包含完整的数据流，可以完全按照测试用例的分支构造数据，而不需要别的文档辅助。但是这样会有一个问题，每一个分支只能覆盖一个功能，也 就是说，每一条测试数据，仅能够覆盖一个功能的分支，在测试执行方面会比较花时间。尤其是同一条数据，可以验证多个相似功能点，但由于测试用例设计中将多 个相似功能的区分开，执行时需要构造多条数据。测试的时间大部分花在重复构造数据阶段了。

　　对于比较复杂的逻辑，在设计测试用例的时候，可以有两份，一份是很完整的包含测试数据准备的，每一条分支划分很细致的用例；另一份是用来测试执行的，将能够一次覆盖的多个分支合并到一起的用例，两个用例图互相参照。对于测试人员的思维来说，是一个先分再合的过程，先将逻辑拆散，细化到每一个分支，再将相似或者相同的分支合并，这里面使用了等价类划分的测试执行方法，即正常用例的时候，一次尽可能多的覆盖。

　　三、测试用例传承

　　有的时候看之前wiki的内容，虽然有测试用例图，但是看不太懂，接手的时候还是需要再问。如果需要在线上对逻辑进行验证，花的时间很多。从需求设 计文档的文字到测试用例的图形，是有一个归总的规程。每个人的思维不同，归纳整理的思路也是不同的。以后的业务逻辑整理到wiki的时候，能够在保留用例 图的同时，将文字的描述也写进去，同时写清冒烟的时候该怎么找验证。即wiki包含三部分内容，一部分是从数据源到输出结果，即需求设计文档描述的，经过 测试人员思维整理细化的文字描述；另一部分是从输出结果反推到数据源的过程，即根据输出，追溯到输入数据，验证输出是否是由输入数据经过规定的逻辑得来 的；最后一部分是测试用例图。这样后续接手会方便，冒烟的时候哪怕不了解这个业务的逻辑，按照wiki手把手的讲解，也可以顺利验证问题。