我近日参加了一些case的review，有一些体会，想和大家分享一下。
    首先，我们没必要认为前人肯定做得很好，所以没有必要站在一个比较低的位置去仰视他们。说实话，也许是对质量的不够重视，我感觉很多继承过来的case写得很不好，也许测试的人根本就不是按照case来测的，他们能够发现问题，但是不善于传播他们的经验和知识。继承过来的一些case，有些写得很乱，有些干脆就是把需求直接copy过来，有些又写得过于详细，总之可读性很差。当然也有写得好的，这是我们应该去学习的。
    case里应该写些什么，应该怎么写，我想这个大家都知道，但是真正操作起来并不容易，所以这也是为什么我们要强调case review的原因。case的重要性在于它是我们测试的指导，并不是说case写成一个样，测试做成另一个样，没有任何可记录可遵循的东西。那样还不如没有case呢。所以，常规测试必须按照case来做（包括error case），除去常规测试，还可以增加探索性测试，就是在case之外，随意地配置和操作，折腾这个系统，发现一些常规操作难以发现的问题。但是常规测试为主，探索性测试为辅，不能所有的都是探索性测试，因为这样根本无法控制，也无法检查测试覆盖率。
    case的风格应该是简洁明了，无歧义。如果能够一句话表达清楚，就不要用两句话。比如我说从冰箱里拿个苹果，大家都明白什么意思，就OK了。没有必要说：先找到冰箱的把手，然后拉开门，expect result：门打开了，里面有个苹果，然后拿出来，再把冰箱门关上，expect result:苹果拿出来了。我们没有必要把case写得滴水不漏，只要正确表达意思就可以了。写得过于繁琐反而影响了可读性。
    case写的是测试人员如何来测一个功能，而不是说这个功能是什么。所以把需求文档或者实现文档原封不动地摘抄过来是绝对不行的。
    最重要的一点是，必须明确case到底在测什么东西，这个在一开始的purpose或者decription里面必须写得非常清楚。不能摘抄一段需求文档或实现文档里的话就OK了，一个case最重要的内容在这里，下面只是具体的操作步骤了。不能让读者必须读完整个case才知道它到底在做什么。
    我说的这些东西都很基本，似乎都是大废话。但是在实际工作中，却发现很多问题。希望大家能够重视case的写作过程，这是我们的output，一旦署上你的名字，这个case就是你的了，就青史留名了，呵呵。