测试用例这种东西对于刚入行的人来说是一种诱惑，初入测试的人急于掌握这门学问，所以一开始就会问测试用例怎么写，问的同时或许还包含了一些期望。其实测试用例就是一个测试矩阵，任何人没有必要注重形式问题，如果你现在或者未来的公司有套非常完善的文档管理体系，那么你可以参考标准模版，如果没有你们大可跟我一样使用下面的格式：
-------------------------------------------------------------------------
- ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE
-------------------------------------------------------------------------
我认为没有什么问题，ID代表标号（如果你愿意可以用这个ID对应需求文档的ID或者使用详细设计的文档的ID，间接连接需求），ACT代表一种动作，因为测试动作非常复杂，如果手动执行或者自动执行，或者或者是一种异常状态都可以占用此位置，但是注意不能使用性能、数据或者安全测试替代，为什么请各位自己考虑。DATA代表数据，很多的测试类书籍中虽然没有直接讲明测试数据的划分，但是通常我们引用三种数据“正常”、“异常”、“错误”，分别对应关键字“PASS”、“ERROR”、“FAIL”，对于数据的划分我以前曾经说过这里不再细谈，为什么会在一个文档中体现着点，主要是为了以后数据程序化作接口，一个不能将手动测试转为自动测试的人员注定是平庸的。EXPECTED、ACTUAL分别代表期望和实际，我们做这一行的经常对这两种值的差异感到困惑，是不是“正常”、“异常”、“错误”就看个人的经验了。T/F的引入是因为有这样的一种情况介入，如果EXPECTED、ACTUAL是不同的，但是我们还是要给个T，因为对于单项的是否通过测试人员有着使用权，但决定权在于市场或者高层决策。DATE是一种好习惯，通常记为发现“PASS”、“ERROR”、“FAIL”的时间，很多人会忽略这个值，当然对于我们来说没什么损失，对于QA团队来说，仅仅提供给他们T/F是不够的。
我觉得这就是一种构造朴实的测试用例的方式，不要过于在意一份文档的表现形式，如果你有很多的时间，如果你一年才写一个这样的文档，那么你可以从互联网上下在很多的资源把这份文档修饰的像APPLE一样。
入行的人员会更进一步的发挥测试偏执狂的能力，这时候他们急需一种数量，例如：我们一个动态库的测试用例就有3000多个厉害吧？厉害，我当然说你厉害，你难道不厉害吗？我记得有个500强的面试题就是你能为LOGIN动作写多少的测试用例？我想了半天我说就三个，或者四个，在听到了一声深深叹息后，我惶恐的说大概我能写5个吧？！当然我自己也没底，我就能写出三个。LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的测试用例就是他们的衍生，一种本源的问题。我们继续讨论3000多个测试用例的事情，有人明眼就会说：这家伙肯定是微软的，没错，除了这种大公司有了充足的资源和技术支持，哪家公司能跟他们一样呢？当然了，写3000个我想入行久了谁都可以，并且跟你对系统的熟悉程度，工作经验有莫大的关系，但是这里我又想说说关于构造朴实的测试用例的问题了。
单元测试、集成测试这些说明的是测试范围，功能测试、性能测试这些说明的是测试的手段，也可以这样说某个功能测试包含了若干个功能测试也内隐含了若干个单元测试的联动，当你开始测试的时候，实际上最终是对代码设定路径的一种验算，如果我们都生活在单线程、无UI的年代你可以更清楚的看到“PASS”、“ERROR”、“FAIL”三种状态，可我们已经错过了这个年代，我们有了包装的UI，有了封装的API，有了各种各样的MESSAGE，所以你就要承受更多ERROR的打击。这个时候有人就会通过增加测试用例的数量来回避这些陷阱，出发点是好的做法是累死人的，如果你愿意你可以为机器码写1亿个测试用例，如果你还是很偏执，你可以为门电路写上1万亿个测试用例，你有命执行吗？
我通常不愿意写太多的测试用例，很多人认为我工作态度有问题，我认为这更能说明我的态度：我愿意朴实的构造我的测试用例，但是我有原则来保证我的测试用例：
1、接到任务不急于作而在于多思考，首先在纸上构造一个大致的业务流图
2、流图构造好，快速剔除公用的测试用例
3、构造测试用例先写符合主路径的三种“PASS”、“ERROR”、“FAIL”
4、精化测试用例努力为ERROR多构造1-7种假设
5、执行测试用例强化FAIL的标准化失败输出，但是对应减少PASS测试用例
6、进一步精化测试用例，使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10
如果我还是测试，我将继续我的朴实理论，多出来的安全时间我可以看看蓝天享受享受生活！
推荐阅读：
