软件测试并不是一项一成不变的工作，南京达内提醒大家要善于发现软件测试中存在的一些问题，通过不断改进的测试方法来让自己进步。

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

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

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

　　二、软件测试用例的粒度

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

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

　　三、软件测试用例传承

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

　　发现问题，找出办法，解决问题，是每一行每一个人想要进步的普遍定律。