首先我们写用例的依据有几种，其中之一就是需求设计及相关文档，有人说UC有很多问题，UC不可靠，我个人觉得这种说法是不对的，虽然UC有问题，但是我们还要依靠UC，总不能说今天中午的午饭不好吃，我们自此不再吃午饭吧。同样的道理，UC有问题，我们要想办法解决这些问题，而不是因噎废食。
同样，一个好的UC不仅仅节约测试的时间，也节约开发人员的时间，一个书写简单的UC虽然编写的时候节约时间，但是在以后的过程中需要不停的修改，测试也需要为一些小的问题不停的找开发人员确认，你烦我烦大家都很烦。一个好的UC让大家都一劳永逸。
其次用例的编写还依赖于与开发组交流对需求的理解。这点就要求开发和测试之间建立良好的沟通，即使CHECK发现的各种问题。有问题及时解决，及早避免南辕北辙离题千里的尴尬境地。
最后我们写用例的依据还来自原型界面，以此次用例PK为例，我们不可能为了进行PK让开发那边再重新编写用例，而且我们对于发布宝贝的过程都是很熟悉的，再重新写UC显然是不切实际的。
现在，我们有了编写用例的依据，那么先就需要做好用例设计，在我们公司用的是流程图，让UC上的文字更加直观。但是不仅仅是将这些主流程文字搬上去就可以了，我开始画设计图的时候每次注释的时候直接贴上一大块文字，后来发现，其实这个只是把UC上的文字挪个窝而已。
对于一些输入项，比如说是必填项完全可以用判断符号来判断是否填写，总比旁边的注释框中的必须输入四个字直观得多。另外，画设计图的时候是详细了解流程的时候，如果设计图画的流程不正确，即使你纠缠于细节，每个边界值设定都非常正确。只能说当你发现你错误的时候，会很很很抓狂滴~~~
最后到了写设计用例的时间了，有人说，写设计用例是很痛苦的个过程，确实有点，很长一段时间总是纠结在长度类型，边界值，和特殊符号中……但是，我不知道是不是支持这种方法，我开始写用例的时候是老老实实的一个个的写的，然后就发现有些用例是有共通之处的，比如说对于名称的校验，无非是长度，类型，在各种名称的校验中都是换汤不换药的，所有建立一个模板总汇，直接COPY就好了，当然记得COPY后要修改下。
我发现用模板编写的效果除了效率变高外，还可以保证格式上的一致。格式一致的好处就不多说了，至少看起了也好看不是。
但是我担心的一个问题是过于依赖于模板，导致有些细节的地方没有挖掘出来，毕竟一个个编写用例的同时，我们也许会偶尔灵感一现。于是我们就有另一个方法，先搭建整体的框架，先整体考虑出那些框框条条的内容，最后的过程就是填空啦。
其实说来简单，在编写用例的过程中总会遇到很多的问题，比如说需求变更，但是也许唯一不变的就是变化，如果变更了这么办?拥抱变化，跟着变更呗，但是，这里有个问题是：测试组最无奈的事情是——开发人员变更了需求，但是测试这里却不知道。如果再给我一个机会，我一定要在项目开始之前就和测试组约定好!
文章来源于领测软件测试网 https://www.ltesting.net/
