理论上来说，测试用例应该是越详细越完整越好，一份好的测试用例应该能被不熟悉系统的人拿来直接执行测试。这是对的。
但现实中往往不是这样，或者说不需要这样。一方面由于时间、人员等因素的限制导致没有足够多的时间来将用例写得很详细，另一方面一个不熟悉业务的人实际上很难根据别人写好的测试用例完成有效的测试，所以很多时候编写详尽的测试用例意义并不大或者做不到。其实很多时候我们只需要告诉测试人员（经常就是自己）要测试/验证什么，而具体步骤甚至详细预期结果都可以不写明。
是不是觉得不那么认同？当然了，这个是根据具体情况来看的，有些系统迭代版本多，范围大，涉及的人员多，那可能对用例的要求就会比较高，这种情况下那就写详细就行了，而相反的情况时则就不需要或是没条件写得很详细，这时将测试点列出来就可以了。
举个小例子，比如有个需求是说一种钱数的计算方式，这个方式可能有些特殊（比如总钱数是数量x单价再按80%计算），那按照详细用例和测试点的方式分别写成测试用例就可能是下面这样：
详细：
1、输入数量10
2、设置单价 5.00
3、预期结果是 4.00
……粗略(列测试点)：
1、验证计算方法
2、预期结果是 计算方法正确
列出测试点的方式在不熟悉的人看来根本就没办法执行测试，可以看到，结果就一个“计算方法正确”，那怎么知道怎样是正确的？而熟悉系统和业务的人在执行测试时就会直接设置合适的数量和单价去验证，而他只需要知道现在是在验证这个计算方法。
这里其实也就是涉及到测试用例的粒度问题了，跟理解用户需求一样（既要达到用户指明的需求，又不要超过用户的需求），测试用例也并不是越详尽越好，而是合适就好。当然，我们不能因为想偷懒而故意将用例写得很简单，一般情况下还是要做到中规中矩。
有一点需要强调的就是，写得粗略点，并不代表不完整，不代表可以漏一部分，就是说在分解测试点的时候尽量不要遗漏，提取的测试点也不要太大，比如一个有很多元素的页面，你不能就写一句“页面显示正常”，而需要将页面中的各个控件进行分解，分解成多大合适呢？这就需要所谓的积累经验了。
源自公众号 软件测试相关