背景
笔者最近换了新工作，可能是跟下属不熟悉的关系，昨天在会议上要求他们在用例中说清楚测试点。这句话引起了下属的一些情绪。我觉得这个问题有必要拿出来说一说，而且讨论这个问题的时候很容易从A变成B，这需要管理者警惕。
昨天讨论的问题，归结起来有三点：
1、为什么测试用例标题中要把测试点描述清楚？
2、为什么写测试用例？
3、测试用例应该写成什么样的粒度？
这几个问题，测试新手大都能说出个一二三来，不过据我了解，很多测试工作很多年的同行，在工作中仍会对此产生困惑。
为什么测试用例标题中要把测试点描述清楚？
首先申明，这个要求是基于我们公司的情况而定的，并不一定适用于读者所在的公司。
?我们公司用工具来管理测试用例，如果不在标题中写清楚测试用例，后期创建测试套件和安排测试都会受到影响，不好操作，必然会返工。
?虽然当时大家没说，我猜测不止一个人会觉得，用例写出来都是自己执行，自己都知道要测试什么。这句话我们分两方面来深入分析一下：
1）以后要区分产品线、也会不断来新员工、也会结对测试。。。。这都意味着其他人会执行你们写的用例。如果不写清楚测试点，别人必然要花更多的时间在你们的用例上，甚至还不一定能正确理解。这不是给别人制造麻烦吗？到时候就算别人不说，心里也会有想法吧，而且从风险控制的角度，怎么判断执行了这些用例就代表测试工作覆盖了全部需求？22）如果只是自己执行测试，那就带来一个问题，有必要写这些用例吗？把更多的时间放在测试执行上岂不更好？反正这些东西都在心里面有？
为什么写测试用例？
在这个问题上产生疑惑，大都是在测试时间紧张的时候应不应该写测试用例。
我的看法：如果用例只用一次，那可能确实没必要写。但我们现在一是在测试产品，用例必然反复使用，其次这个用例并没有让大家立刻写出来，没有影响到现在的工作。所以，当有人遇到这种情况时，先不要急着起情绪，先把问题搞清楚。换个角度说，我听到时间紧张就叫嚣不要写用例，我心里都觉得这句话换个说法就是时间紧张了，是不是就意味着我们可以对工作放低要求？
再说，用例是辅助我们测试的，即使时间再紧张，只写写测试点不过分吧？（这其实就是测试点了）
测试用例应该写成什么样的粒度？
首先申明，我很赞同做一些探索式测试，并不是非要大家把用例写的多么规范、步骤多么详细，做了一些要求也不是因为刚上任为了所谓的三把火可以的制定新规。
用例颗粒度要多细？原则上就是覆盖需求，但基于我们的情况，需求本身很多时候都不清楚，没有文档，产品是买的第三方公司的，大家对这个行业也没有多丰富的了解。那必然带来一个问题，就是很难把需求覆盖全面。
在这样的背景下，用例还不把测试点写的清晰一些，是不是留下隐患、自讨苦吃呢？