软件测试基本功之——测试用例篇
随着软件行业的快速发展，大家对软件的质量也越来越看重，关注。软件测试做为能尽可能发现软件中的BUG，减少软件成本，也在不断的高速发展，受人们关注，重视的程度也越来越大。从最初的程序员自己测试到后面的测试部门，测试职位的设立。以及软件测试的一整套方案，流程等。 一，测试用例的重要性
什么是测试用例？测试用例有什么作用？
测试用例：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 测试用例的作用：
1，通过一个用例来证明被测软件的某功能符合需求说明书中规定的要求，可以通过设计正反两方面的测试用例来验证
2，可以保证一个软件被测试的有效性，使测试人员知道那些功能以被测，那些功能还需要测试，从而避免漏测，重复测，提高测试效率
3，指导测试的工作，保证测试是有计划的实施，而不是随意性的测试
4，为公司留下财富，为后期软件维护提高帮助，为公司新人进来提供指导，在测试的时候可以尽量把人为因素的影响减少到最小。保障软件测试质量的稳定 5，可以做为评估测试结果的，为编写测试报告提供依据。
6，分析缺陷的标准，通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。 二，测试用例的设计：
测试用例设计这部分主要是根据我自身的经验来写，可能很多不足的地方，请大家指出。（这里写的测试用例都以黑盒测试为准，不设计到白盒测试） 1，设计测试用例的模板：
我想，每个公司都应该有一套适合自己公司的测试用例模板。还是那句话，最好的并不是最适合自己的，适合自己的才是最好的。测试用例模板可以分为两部分：
1）介绍部分：可以有这些：公司名称，保密等级，编写人员，日期，审核人，版本号，测试对象的介绍，测试的范围和目的，测试环境，定义术语，参考文档，用例执行情况，测试用例设计思路等 2）测试用例部分：模块名称，测试类型，用例ID，用例目的，重要程度，测试过程分为（前提条件，测试步骤，期望结果，测试结果，测试结论）测试日期，备注。
现在打部分公司用来编写测试用例的软件应该都是EXECL和WORD（那个叫微软NB撒），感觉上，在进行模块测试和系统测试设计用例的时，用EXECL来编写比较好，方便统计，查找测试通过的，没通过的用例，EXECL统计功能很强大。但是对于验收测试用例和性能测试用例，使用WORD会好点，因为验收测试用例和性能测试用例，一般都是一个用例一页，方便打印，而进行验收测试的时候，必须要把验收测试用例打印出给客户，而且验收测试用例一般都没系统测试那边多，一般是一个功能就是一个用例。(下面有2种测试用例的模板)
2，测试用例设计的一些思路： 按照书上说的可以分为几大类： 1）等价类划分 2）边界值分析 3）错误推测 4）因果图
我认为测试用例的设计应该从深度和广度方面去想，即要考虑到被测模块所有功能，还要考虑他们的组合，以及和其它模块的组合。不单单要考虑正常情况下功能，还要考虑异常情况下软件的反应，不要仅只考虑一种测试环境下的情况，还要考虑多种环境下的情况，因为用户的环境是千变万化，不是能全部模拟出来的，只能尽可能的模拟，下面是我以前测试的一个模块： 禁用USB外接设备：
主要功能是：除了USB键盘和鼠标外，其它一切外接USB设备都不能使用。 （不知道大家能想到一些什么情况来设计测试用例），下面是我设计的一些思路： 1）正常情况下运行该功能后，看USB键盘和鼠标能否使用 2）正常情况下运行该功能后，USB键盘和鼠标拔插后能否使用
3）正常情况下运行该功能后，USB键盘和鼠标拔掉，接上外接USB设备，能否正常使用
4）正常情况下运行该功能后，USB键盘和鼠标拔掉，接上外接USB设备，插上 USB键盘和鼠标，USB键盘和鼠标能否使用，外接USB设备能否使用
5）正常情况下运行该功能后，接上外接USB设备（USB键盘和鼠标一直存在），外接设备能否使用 6）重复拔出外接USB设备，看USB设备能否使用，USB键盘和鼠标是否会影响 7）先插外接USB设备（能正常运行），再运行该功能，USB设备是否立即不能被使用 8）外接USB设备正在拷贝文件，运行该功能后，是什么反应
异常情况下该功能的反应，如运行该功能后，电脑重启，电脑死机等会导致什么后果，是否是我们期望的。
多个USB接口情况下，该功能是否正常
对于不同USB设备是否该功能都有效果：如USB的U盘，移动硬盘，MP3，USB打印机等。 该功能运行后，是否能还原。还原功能是否正常。
。。。。等，上面这些，大家也应该想的到，下面这些大家是否会考虑：
1）大家都知道禁止某设备运行后，在设备管理器会显示？号或者红叉，大家会不会设计手动从设备管理器去启动被禁止的外接USB设备的用例？
2）有的USB设备需要驱动才能运行，如USB接口打印机，是否会设计驱动卸载，重新安装后的用例？
3）现在也有那种USB转换器，比如把PS/2接口转换为USB接口，那外接USB能否使用？把USB接口转换为PS/2接口，PS/2接口的设备能否使用？
4）不同操作系统下，该功能是否有效，如LINUX，UNIX，WINDOWSXP，2000，2003等。 上面这些可能可能很难想到的地方，所有设计测试用例也并不是一件容易的事，需要发散性的思维，需要大量的经验。现在看到很多人有点本末倒置了，都去追求工具自动化，其实当你设计出一个完美的用例后，测试出的效果绝对是巨大的，要不怎么会说一个好的测试用例是发现从为发现的错误呢？基本功还是需要.
上面的那些情况只 是一部分，还可以设计出很多来，大家可以一起讨论下。 三，测试用例的一些技巧：
在软件测试中，有很多被测试的软件都是C/S结构的，而软件的界面估计是从头到尾都在改变中，这都测试用例的编写，维护是一件耗时，耗力的事。下面是我个人的一些经验：
1，界面测试用例和功能方面测试用例分开写，比如在一份EXECL测试用例中，界面的就单单写界面的，如写字体，排版，快捷键等，功能就只写逻辑方面，实现方面，这样当界面修改后，修改也快点。 2，比如说在编写一个弹出提示框用例时，以前我写用例的时，把预期结果写成提示的消息，如：“登陆用户名错误”，而当这个提示消息变为“用户名错误”时，有要去修改用例，很烦的。后面我就写“弹出一个提示消息框”，这样就解决了
3，写用例时，尽量分清层次结构，比如用户登陆模块，写的时先写正常情况下登陆，再写异常情况下登陆，不要一下写正常情况下，有写异常情况，然后再写正常情况下，让人感觉很混乱。
4，写测试用例之前，最好在纸上画一个框架出来，按照什么顺序来写，比如是按照操作系统的分类先，还是按照正常，异常情况先来写，下面模板中的一级分类，二级分类就是这个效果
基础功能测试的一些实质建议
1、对于旧的稳定的程序，一旦新添加功能，尤其是调用旧模块的功能的，回归测试的工作量大而枯燥，不可避免
针对此条，对于LEADER而言，最大的难处在于时间风险的估算。最好的解决方式是和开发人员开会，共同探讨模块的复杂性和测试时间。一般，开发，测试，修复，再测试的周期中，开发和测试的时间是1：2左右。甚至更多。
对于测试用例的设计人员而言，最大的难处并不在于新功能本身，而是如何设计覆盖路径，新旧版本之间的问题将非常严重。怎样设计组合用例，将是测试的重中之重。
活生生的例子： 我们的测试用例中没有设计到横向子模块的兼容性测试，因为旧版本没有该问题，而新版本也仅仅是调用这个模块。结果，在冒烟测试中，就发现，这个被调用的公用模块，在某一个相对特殊的子模块中，会发生菜单项无效的问题。随后再想到要设计横向模块的兼容性测试，并和旧版本做比较，浪费了很多时间。
2、一定要和旧版本一起，做至少一轮的随机测试
尤其是涉及到自定义的数据保存功能的情况下，用新版本的程序读取旧版本保存的数据看看。接口之间的古怪问题，一定会让你颇有成就感。另外，去有规律的做一些古怪的随机测试，比如，程序中产生报表或者示例图之后，最小化窗口，再还原看看。很有可能，图片和数据就变了，或者消失，或者残缺了。这种怪事就在我的测试中实际发生了。因此，这一轮的随机测试一定要做，思路越古怪越好。 3、不要嫌重复劳动麻烦
亲身经历了令人沮丧的事情。在某3天，我不停地测试一个功能，单元测试证明代码和算法没有错误，我也看过，的确不可能出错。前台依赖这个算法而显示的数据上万。不过还是出于负责而一条一条的检查，一直没有出现问题。最终，想放弃的时候，发现，这将近2万条数据，最后的10条果然出现了问题。你说妖怪不？早知道就应该从尾巴开始测试。哎。所以，不能放弃，知道不，测试就是要负责的。 4、关于不可重现的BUG
唯一能够告诉新手的就是，你每做一个动作，都必须保持脑子清晰。当你发现某些一定是不可重现BUG时（比如内存溢出，花屏等），别着急关闭你的屏幕，直接叫开发过来看，或者打开任务管理器，并截取图片保存。因为这是你的业绩。
基础功能测试的一些实质建议
1、对于旧的稳定的程序，一旦新添加功能，尤其是调用旧模块的功能的，回归测试的工作量大而枯燥，不可避免
针对此条，对于LEADER而言，最大的难处在于时间风险的估算。最好的解决方式是和开发人员开会，共同探讨模块的复杂性和测试时间。一般，开发，测试，修复，再测试的周期中，开发和测试的时间是1：2左右。甚至更多。
对于测试用例的设计人员而言，最大的难处并不在于新功能本身，而是如何设计覆盖路径，新旧版本之间的问题将非常严重。怎样设计组合用例，将是测试的重中之重。
活生生的例子： 我们的测试用例中没有设计到横向子模块的兼容性测试，因为旧版本没有该问题，而新版本也仅仅是调用这个模块。结果，在冒烟测试中，就发现，这个被调用的公用模块，在某一个相对特殊的子模块中，会发生菜单项无效的问题。随后再想到要设计横向模块的兼容性测试，并和旧版本做比较，浪费了很多时间。
2、一定要和旧版本一起，做至少一轮的随机测试
尤其是涉及到自定义的数据保存功能的情况下，用新版本的程序读取旧版本保存的数据看看。接口之间的古怪问题，一定会让你颇有成就感。另外，去有规律的做一些古怪的随机测试，比如，程序中产生报表或者示例图之后，最小化窗口，再还原看看。很有可能，图片和数据就变了，或者消失，或者残缺了。这种怪事就在我的测试中实际发生了。因此，这一轮的随机测试一定要做，思路越古怪越好。 3、不要嫌重复劳动麻烦
亲身经历了令人沮丧的事情。在某3天，我不停地测试一个功能，单元测试证明代码和算法没有错误，我也看过，的确不可能出错。前台依赖这个算法而显示的数据上万。不过还是出于负责而一条一条的检查，一直没有出现问题。最终，想放弃的时候，发现，这将近2万条数据，最后的10条果然出现了问题。你说妖怪不？早知道就应该从尾巴开始测试。哎。所以，不能放弃，知道不，测试就是要负责的。 4、关于不可重现的BUG
唯一能够告诉新手的就是，你每做一个动作，都必须保持脑子清晰。当你发现某些一定是不可重现BUG时（比如内存溢出，花屏等），别着急关闭你的屏幕，直接叫开发过来看，或者打开任务管理器，并截取图片保存。因为这是你的业绩。
