核心：覆盖测试需求，尽可能的减少测漏，同时提高测试效率；这种核心本质上就是一种“提醒”的作用。
关键问题在于时间和可执行性，按照传统的方式，把用例写的很详细，各种前提条件，步骤，说明，预期结果，编写人，日期等等，这个时间成本是很高的，我觉得这样写的测试用例连编写人自己都懒得看，只会按照当前的想法来测试，更不用说让非编写人来执行，所以执行性就很低了，所以这种用例文档基本上就是摆设。
我认为，测试用例必须要写，而且必须精简，划分合理，见名知意
1.一看用例名就知道步骤以及预期结果的，只写用例名
2.仅看用例名不知道操作步骤/预期结果的，就把后者写出来（简写或直接以备注、提醒点、验证点、说明代替）
3.针对一些复杂的用例，步骤和预期结果都要写出来（比如一个用例中步骤繁多包括多个验证点）
4.技巧：适当备注（业务逻辑、规则、需求、预期结果、模块划分）
多研究产品，ui交互，对产品有感觉了自然就会发现哪个功能点击会出现什么结果
例子：
用例设计：
说明：
注意：
1.模块层级不能过多，有必要可以2-1子模块的形式；
2.模块下分“字段校验”“功能校验”，
划分依据：把可执行一个完整功能、业务功能的用例放在“功能校验”下，否则放在“字段校验”下；
3.这样写可以突出重点，必要时以功能校验优先。