接到一个项目，一个大日常，跨很多应用，形成了标准的开发测试N：1，满心欢喜觉得自己终于可以独当一面了。可是当拿到N个UC的时候，就有种瞬间傻眼的感觉。
但是由于越觉得这个工程很庞大，越想早点开始启动自己的工作，遂会好不容易找到一个突破口就急于开始写用例。
刚冥思苦想出第一个文件夹的名字后，在这个模块下，想到什么写什么，想不出来的时候，又开始想第二个文件夹的名字，想下一个模块要写什么。当写到第十几个文件夹的时候突然想起第N个文件夹中好像少了一个用例，又每个文件夹，点开看里面的内容，回顾这个文件夹大致覆盖了哪些用例，看看缺少的这个用例该怎么补。也许庆幸的是，找到了那个文件夹补充好这个用例，但是当你写到第几十个文件夹时，过了几天以后，想到好像漏覆盖了什么功能点，那可能不是就仅仅浪费几分钟去找这个文件夹，而是可能会花上大段的时间去回想自己写了什么，这个时候的思路打断就会让你觉得不知道下一步该怎么走，思路越来越乱，下面的用例到底应该以什么纬度进行下去，还有多少的用例被遗漏掉了，什么用例是不需要写，什么用例是需要覆盖的，突然就会对用例有种不可控的感觉。
但是，如果一个测试人员对自己的用例都无法控制，那还有谁可以来了解用例的覆盖度，用例的纬度。后面的回归测试同学，如何来有序的进行回归，用例的迁移该会是多么痛苦的一件事。
其实每个人的测试思路会不同，测试习惯也会不同，所以用例可能就会用不同的方式来写。这些都固然没错，但是用例必须要有个纬度划分，有个整体的一个流线。有利于测试，也有利于用例的review及评审，思维可以顺着下来。
老人是一个很好的灯塔，他可以指引你怎么前进，有时候自己真的一点没有头绪的时候，可以看看以前的用例以怎样的纬度划分，找个较熟悉该应用的老大，问问如果是你，会怎么着手写这些用例。千万不要在自己没有头绪的时候就开始写第一个用例，有可能会越写越乱，写到最后漏了一大片，冗余了一大片。先确定好用例大体以怎么样的几个大方向来写，比如，按照应用来分，sell一块，mickley一块，forest一块；按照测试顺序，先后台建类目，再前台发布，等等。
确定一个方案还不够的，这个只是个骨架，这些只是好让你定好一级的文件夹名字。不要就开始写用例了，要不然你定好了几个文件夹名字后又会开始不知道怎么入手了，文件夹下要测试哪些东西呢？所以下面的测试设计很重要，列好几个一级文件夹，对照UC看下一级文件夹是什么，一直设计到叶子文件夹要写哪些功能点。最好可以进行测试设计评审，让开发和老人一起评估下，有没有测试用例覆盖漏掉的点，这个时候修改方向，补充漏写的点，很容易，一目了然。
虽然这可能会花去你一天的时间，你会觉得很可惜，但是这对后面的工作将会有很大的作用，对功能点已经比较熟悉，对用例编写的思路也很清晰，只要对照设计一步一步往下写就可以了，就不用说动不动就停下来绞尽脑汁在想要写什么东西，尤其是对新人来说，对已有的用例也不熟悉，不知道到底应该写哪些用例，需要测试哪些点，这个就尤为重要了。
300个用例并不可怕，但是不可控的100个用例就会让人很昏头转向。定好方向，做好设计，建好层级，个个攻破，500个用例都将是可控的。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/