用例名怎么写( 三 ) _用例名

话说，写用例、设计用例是需要时间的，而在追求速度的时代，似乎连这点时间都给不起。这不是我吹的，特别是互联网，大部分公司都采用敏捷开发模式，讲究快速，所以，时间往往是有限的，再加上很多公司对敏捷仅停留在概念阶段，以为“敏捷=快速” ，把时间花在用例设计上简直就是一种浪费….这样一来，用来设计用例的时间有时候，真是少之又少。如果按传统方式，把用例写得很详细，各种前提条件，步骤，说明，预期结果，编写人，日期啥的，这个时间成本是很高的。
再说可执行性。经常看到一些人写用例写得很认真，很详细、具体，把每一步的操作都写了，还有一些人一个用例下来，十几个步骤，包含了n个验证点。这种用例的可执行性咋样呢？按我的经历来看，这种类型用例，在测试的时候，用例编写人自己都懒得看用例，完全是按自己的当前时间的想法来测试，而非用例编写人呢？同样的，他也不会完全按照上面的步骤来执行，人嘛，都喜欢按自己的方式来做事，谁会看一下用例步骤，然后操作一下呢？所以，最后的结果是，用例文档就是摆设，放在那里，没人看。
怎么破？
我的观点是：测试用例必须写，而且还要“精炼”：能不写的尽量不写，能“简写”的尽量简写----“精简”的思维->；简而言之，当前面的部分，已经起到了足够的提醒作用时，后面部分就可以不写。这样做的好处是，不仅可以节省时间，而且还给执行用例的人留下一定的思考空间，有利于TA的成长。
思维导图编写用例为例：
1. 一看用例名，就知道步骤及预期结果的，仅写用例名
这里的用例名，也就是我们的测试点、需求验证点。
这里对编写测试用例的人有个要求：语言组织能力+思维能力，尽量做到划分合理，且见名知意。
2. 仅看用例名，不能预知操作步骤的，还须把操作步骤写出来
3. 仅看用例名，不能预知预期结果的，还须把预期结果写出来
4. 预期结果、操作步骤有时候都可简写：直接以备注、说明、提醒点替代
对比上面的，这样写可能会给人有点“乱”的感觉，但是换个思路想，
这里实际是把预期结果、操作步骤当作是子验证点（即子用例），采用第一条规则，这里的子用例仅写了用例名，即提醒点，验证点。也就是说，这条用例是由一组子用例构成的。
注：用例粒度可粗可细，结合时间成本考虑，做到合理的划分即可。
5. 针对一些步骤比较复杂的用例，步骤和预期结果都要写出来。
复杂情况下，一个用例包含多个操作步骤，这些操作步骤中，每个步骤可能都对应一个子测试点（预期结果）。如上，可以新增一个结点，填写预期结果，也可以和操作步骤写在同一个结点，以括号等不同方式进行区分，具体根据个人喜好或者大家达成共识的统一风格。