在如今的软件迭代过程中，在测试用例上投入的大量时间和亟需提升的研发效率正在成为日益凸显的巨大矛盾。如何在两者之间取得平衡，笔者认为测试用例应该具备以下特点：
一、独立性
所谓独立性是指每组（个）测试用例可以单独维护、执行，不影响其他的测试用例组，如果测试用例之间是强耦合的，考虑对它们进行合并。这样设计的好处是当迭代出现变更时，可以对测试用例组进行增删改的操作而不相互影响。
例如一些操作是针对登录用户的，那么登录相关的用例和这些操作用例就是强耦合的。或者在一个场景中，存在上下文数据的传递关系，必须组合使用，但是单独任何一个步骤拿出去都是不可执行的，那么这种场景就需要设计成一个完整的测试用例，因为每个步骤都是不可分割的。
二、易用性
易用性顾名思义就是测试用例应该是尽量简洁，同时又要易于理解的。这样描述听起来有些简单，但是实际操作起来并不容易把握尺度。
举例来说，按传统方法设计的一个测试用例，具备以下几个要素：ID、标题、优先级、前置条件、复现步骤、错误描述、期望结果，这样一个测试用例从构思到完成大概需要十分钟，所以每小时大约能够完成六个用例设计，按每天八小时工作制计算每天可以设计四十八个测试用例。这样的效率在如今的研发迭代是难以接受的高成本，因此许多公司引入了思维导图设计测试用例的方法，这种方法不再强调格式，而是强调自由发散，因此大部分测试用例类似于一句话，例如“新注册用户首次进入主页则展示引导蒙层，手指点击屏幕任何地方即可领取奖励，且弹窗展示成功图片”，这样就大大提高了用例的设计速度，大概完成一个需要两分钟，所以每小时能够完成三十个用例设计，每天就能完成二百四十个用例。较传统方法提高了四倍效率。
三、有效性
测试用例的有效性是有几个要点可以阐述的。首先测试用例不是空想得来，必须来源于真实的产品需求，否则就是无效的测试用例；其次测试用例应该是对产品内核的充分理解，不应该是对产品文档的复述，否则就是无效的测试用例。很多初级的测试人员就是辛苦的搬运工，把产品经理的文档拆解成一条条，再搬运到测试用例管理系统，你不能说它是错误的，但是其实它就是无效的；然后每组测试用例对应一个独立产品模块，产品模块变更触发用例变更（新增、修改、删除），如果不能跟随变化，就是无效的测试用例，这一点尤为常见。大多数国内公司的测试人员每天都疲于设计新的测试用例，但是数据库中堆积了数万数十万的废弃测试用例无人问津。
四、进化性
建议测试人员尽量早地交付一个测试用例版本，并随着客户需求的变化而层层递进，这个最早的版本一定是较为粗犷和简约的，但是它为将来的细化设定了“锚点”，后续的设计工作都将由这些锚点展开。测试人员应该定期反思和回顾测试用例的设计，时间周期上可以跟随迭代，不断地对譬如颗粒度、数据流向、场景，进而调整设计策略。同理，由于测试用例的设计是基于需求的，所以测试用例设计绝对不是一次性工作，因此需要“欣然面对需求变化”，跟随迭代不断优化。
最后，根据以上内容，
我提炼出测试用例的十条设计建议，作为设计测试用例的原则，供大家参考：
- 每组测试用例 可以单独维护、执行，不影响其他的测试用例组；
- 如果测试用例之间是强耦合的，考虑对它们进行合并；
- 每组测试用例之间可以传递数据、状态；
- 测试用例应该是尽量简洁，易于理解的；
- 好的测试用例应该是对产品内核的充分理解，不应该是对产品文档的复述；
- 每组测试用例对应一个独立产品模块，产品模块变更触发用例变更（新增、修改、删除）；
- 尽量早地交付一个测试用例版本，并随着客户需求的变化而层层递进；
- 测试用例的设计应该是基于需求的，所以不是一次性工作，因此需要“欣然面对需求变化”，跟随迭代不断优化；
- 应该定期反思和回顾测试用例的设计，譬如颗粒度、数据流向、场景，进而调整设计策略；
- 邀请开发、产品和其他团队的测试参加测试用例评审，避免个人盲区。
源自公众号 三国测