也说软件测试用例

　　前言：测试用例有很多种，不同类型的测试对应测试用例也不同，编写要求也不同，比如接口测试用例、性能测试用例和我今天想说的集成测试用例。同一对象的测试用例还可以分为冒烟测试用例，详细测试用例等。
　　我理解的测试用例是指测试人员对某个对象进行检查的方法总结。别人可以根据这个用例对这个对象进行检查。那么好的测试用例是不是越详细越好呢？如果被测对象是永远不变的那么越详细的用例当然越好，但是实际工作中，被测的对象是一直更新的，所以我认为测试用例不应该用详细与否来衡量好或差。
　　如果测试用例写得太详细至少存在以下几个缺点：
　　1、维护困难。例如把某个文字检查结果或者显而易见的步骤操作写得十分详细，带来的问题是当被测对象的更新后，需要及时而且耗费大量精力对用例进行详细检查更新，否则其他人按照这个用例回归时可能会出现结果对不上的情况，那么它的参考意义便不大，失去了测试用例的价值。
　　2、束缚测试思路。如果用例太详细带来的结果就是读者容易完全按照用例的思路来测试，这个是一大弊端。
　　3、编写、阅读时间太长。当然并不是说文字越少需要的时间越少，但是文字多花的时间肯定长，也累啊。就像一个看一眼就能覆盖的用例何必写太详细的步骤呢？在讲求效率、敏捷的这些年这个也算明显的缺点了
　　虽然详细、简单是一个相对的词语，是一个度的问题，详细的用例好处是可以让最小白的人看明白，不过今天进入软件测试的人都不是小白了，真正的小白是不会看用例的；详细用例还有一个好处就是容易转换为自动化测试用例。不过我还是更喜欢简单明了的用例，虽然过于简单的用例也有明显的缺憾，例如容易误导读者或者甚至无法让读者用其进行参考。我说说我认为好的测试用例应该如何写。
　　一个好的用例应该能够指导读者去检查用例描述的对象，激发读者的思考，这不是开玩笑，那么它应该包含如下内容
　　一、背景
     测试前要先了解被测对象的背景，提供背景可以让其他人了解被测对象的整体，甚至更深入的内容。背景可以包含如下内容：
　　1）需求背景，例如这个功能为了解决什么用户问题等；
　　2）开发方案背景，如涉及的dll模块、数据库、配置文件等等详细信息；
　　3）测试背景，例如测试重点，注意点；
　　4）文档背景，在测试本对象前需要查看什么文档，其实大多数时候我们不会喜欢再看一份文档才能开始干活的。
　　二、测试点
　　测什么——把被测对象细化，像庖丁解牛一样，根据对象不同可以按功能或者按模块细分，我建议是按功能，越细越好；如果针对的是功能改进而写的则对提测点进行细化；有一类较特殊，提测点不会提到的，就是容错，这种也需要单独列出来。读者看到细化后的对象后往往可以进行自由发挥。
　　怎么测——测试方法是整个测试用例中最占篇幅的部分了，得好好说，篇幅有些长;-)。
　　首先测试点需要覆盖界面和功能两部分的内容，界面不用多说，一句话即可；
　　至于功能，首先要考虑这个测试方法是否有依赖前置条件，如果有则应该写出来，软件讲求的是输入输出，把你能想到的输入方法写出来就是测试方法，如果方法复杂则配上操作步骤。一个功能的测试方法很可能非常多，建议优先考虑正常操作范围内的输入，想象小白用户使用这个功能时是如何操作的；然后考虑高级输入方法，即一个高级用户会如何使用这个功能；最后考虑错误的输入方法，当功能出现问题时应该有容错措施，容错输入又分常见容错和高级容错，容错输入应该是最依赖经验的输入了，这个无法避免；还有一种输入我觉得也可以特别说一下，就是变态输入，即在测试某些功能的时候采取了一些非常手段的测试来检查被测对象的功能，如果读者有进行发散思维的时候很容易就会想到这些输入方法，这个从测试管理角度看绝对是好事，虽然从产品角度看这些方法发现的bug一般优先级都极低。
　　另外，编写测试点时经常会用到测试古籍中介绍的“等价类划分”、“边界值”等。前面说了测试方法是整个测试用例中最占篇幅和最占工作时间的内容，所以它也最值得精简，例如优先级划分、精简步骤说明、精简预期结果说明等，尤其是步骤，尽量一句话描述即可，具体操作可以由读者自由发挥。正常输入输出、边界输入输出、普通容错输入输出应该是优先级最高的测试点，它们可以作为冒烟测试用例的测试点。