测试用例的功效

相关推荐

测试用例的功效

随着软件行业的快速发展，大家对软件的质量也越来越看重，关注。软件测试做为能尽可能发现软件中的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，写测试用例之前，最好在纸上画一个框架出来，按照什么顺序来写，比如是按照操作系统的分类先，还是按照正常，异常情况先来写，下面模板中的一级分类，二级分类就是这个效果

测试用例的作用2017-05-10 15:15 | #2楼

4年前我刚入职测试的时候也是对测试用例的实际价值和具体应用有过相当一段时间的不解，不过当时没人能给我一个真正合理并具有说服性的理由，只知道很重要，就这样一直做下来，直到4年后现在的我，当带别人的时候我也会说测试用例很重要，是一个测试人员的核心能力，测试的好坏一半取决于你对测试用例的编写能力，另一半来自于你对业务的发散性思维，来自于测试人员测试时的状态。

不要说时间紧迫，需求变化较快，如果你提前在心里就为自己找好了不去做的理由，那么对这项工作你会永远都保持着抵触的情绪，进而越发的觉得测试用例没用。我具体说几点希望能让你对测试用例有所改观：

1、先说说你所说的编写用例和临时的灵感之间的区别，这也是现在很多测试人员的困惑，因为工作中所有的感觉都在告诉我们，临时的发挥往往发现更多更隐蔽的bug，而测试用例中往往也都是开发人员已经注意过的地方，能出现让你感觉很有成就感的bug实属不易，但我前面说了，这仅仅限于我们的感觉，举个大学时的例子来解答你这个困惑，我记得我大学的时候我的高数老师在讲课的同时不忘提醒我们该以怎样的态度对待目前的知识，我想大多数同学都会有我这样的想法，看看书本上的东西，这么简单还用学么，临时看看就会了，况且学了能有什么用呢？有一天老师在讲一个简单的公理时突然说了一句话，他说这个公理是很简单，是最基础的，但我提醒大家最基础不是不重要，相反它是最重要的，如果没有这个基础公理后续课程中所有的理论都不存在。这句话我一直记在心里，基础的是最重要的，这也是我一直很痛心的地方，因为平时我看着都会的东西，一个学期过去，我居然什么都不会了，我很鄙视同学平时不断的做着我看着都会的题目，可到最后我都答不上来了，可同学却很轻松的交卷了。

不知道你对我所说的能否理解，编写测试用例我们都很不耐烦，觉得自己到时候也知道这些，写了又有什么用呢？可真正到了测试的时候你凭什么说你都知道呢，这不过是一厢情愿的想想罢了，就像我面对刚开始简单的公理，我反复做这个公理的题有什么用呢，多简单啊，可对简单的都无法理解吃透，又如何在简单的基础上进行发散性思考？一个系统连基本的保障都没有，仅靠临时的灵感去挖掘我们不太容易发现的问题，我想你自己心里对系统都没底吧。简单的说，编写是基础，临时的灵感是深度挖掘。

2、如果说上面的理由不足以说服你，那么再看看这一点如何。不靠谱的灵感——如论是哪个测试人员，都会承认，测试与我们本身的状态有相当紧密的关系，如写文章一样，状态好时文思如泉涌，状态不好时提笔忘字，甚至生厌，毕竟我们大多仍然还执行着手工测试，工作的单调和枯燥不会让你像一直打了兴奋剂一样，此时你如何保障你的测试是有效的？

3、盲点。不知道你是否听过这个词，由于每个人的逻辑思维迥异，看待事物必然不同，针对一个测试点每个人编写的测试用例也会有不同，我不相信一个人可以把一个系统想得方方面面滴水不漏，bug总是源源不断超出你的想象，这些你想不到的即是你的盲点，当你把编写好的测试用例上交评审时，你会发现别人总是会提出这样那样的问题，你会发现你原有的逻辑竟然暗藏n多漏洞，更可怕的是随着工作的进行，当你对系统进行多次的回归，你会发现你可测的越来越少，为何？不是你的错，每个人在持续的重复同样的活动时，都会渐渐失去原有状态，渐渐麻木，那么我们的盲点也会偷偷的加大，如果没有提前的测试用例保证，你可以保证你在系统交付前的测试与你第一遍测试的内容完全一致么？如果不完全一致，那些落下的测试点，你测试过吗，测试几次呢？现在是正确的吗？

4、管理成本。这个应该说和部门对项目的长期管理有关，面对现今it业人员流动大的特性，每个部门对项目的管理成本在加大，老员工离职留下一堆问题，新员工入职业务不熟，无法马上接手，之前的系统如何，由谁去给他讲解？对于测试，我想如果我是管理者，我会直接给他一些模块的测试用例，按着这些用例去测试，从这些用例中去理解系统，即增加了一点人手，也极大提高他学习的速度，4年的经历告诉我一个新入职的测试人员仅仅是看需求说明来学习，效率异常低下，并且一旦实际接手测试任务，之前所学习的基本还得对着系统重来一遍，记得，企业招聘员工，要尽可能要你来创造更多的效益，当然这个效益创造的越早越好，而不是真的让你来学习。

或者整体来说，测试用例是测试对系统的一个基本的质量保障，是一个项目可持续化管理的有效手段之一，当然，不是说写了测试用例就万事大吉，软件就毫无问题，还是我老师那句话，这是最基础的，也是最重要的，你的那些灵感会使你的测试大放异彩，但绝不要被这色彩蒙住你的眼睛，导致你看不清基石而摔下来。

最后回到我开始说的，"不要说时间紧迫，需求变化快"，这个问题我不想多说，因为这个问题只要我们想解决，总会有办法，关键是看你以什么样的态度对待，想克服就不是什么大问题，不想克服，那就无解。

以上只是简单说了下测试用例实际的好处与作用，当然不止这些，既然有这些好处，至于你执行多少全在自己，现在很多企业都想采用敏捷开发的方式，对测试也发起了新的挑战，也有人用测试点或者需求列表的形式来代替，无论什么形式都无所谓，选择一条最适合当前部门状况的方式，但你所说的灵感是绝不靠谱的事情，两者无法比较。

自己也曾经疑惑过用例和作用，并想方设法提高用例对于异常场景的覆盖。其实这类灵光一现的异常场景有用例设计初期是无法做到太多的覆盖，只能根据以往的测试经验来写。在测试过程中如果有新的场景想到，一定要及时补充到用例中，而不是测试过一次就忘了~~还是那句老话：测试用例是需要维护的，不是死的！

【测试用例的功效】相关文章：

测测能申请哪个档次学校04-17

课例研修心得02-11

收入证明样例05-06

物理课例反思05-21