51Testing软件测试论坛

标题: 测试用例的编制 [打印本页]

作者: snail2011 时间: 2005-8-9 16:40
标题: 测试用例的编制
大家好，我是刚进入一家公司不久，但是我进来后就写测试计划，测试用例，现在我对测试用例的编写只是在功能测试这一块，也得也很浅显，我想写的更深入一些，应该怎么写呢。请大家给个意见。

作者: ww0221542 时间: 2005-8-9 17:19
不一定要写得很深入，只要能完成测试目的就好。

作者: davids 时间: 2005-8-10 10:33
大家写的黑盒的测试用例都是怎么写的啊？？

作者: Tender 时间: 2005-8-10 12:39
记住一个原则，用例是功能的简单描述，但不要写成操作手册。如果让一个完全不懂的人按照测试用例尽能够完成所有的测试操作，是很危险的，这是我的理解！

作者: beginnl 时间: 2005-8-12 12:29
功能用例的设计除了覆盖需求规格说明书中的所有功能外，还可从软件的架构（如流程），各功能模块之间的结合方面考虑。
另外，我觉得很重要的一点是，每次测试完成后，应该把测试执行过程中发现的遗漏的用例补充完整，并分析下当初测试用例是如何设计的，为什么没有这方面用例的考虑，这样用例设计的经验就会逐步累计起来了。

作者: 大妮 时间: 2005-8-12 14:12
同意

Originally posted by beginnl at 2005-8-12 12:29:
功能用例的设计除了覆盖需求规格说明书中的所有功能外，还可从软件的架构（如流程），各功能模块之间的结合方面考虑。
另外，我觉得很重要的一点是，每次测试完成后，应该把测试执行过程中发现的遗漏的用例补充 ...

“覆盖需求规格说明书中的所有功能，软件的架构（如流程），各功能模块之间的结合”这三项那一项是最重要的呢？

个人认为第二、三项比较重要，很多严重等级的BUG就是在这里发现的，对于第一项来说，对于黑盒测试，开发人员提交给你的，一般是主要功能都实现了的系统，不是说不重要，而是说BUG的严重等级大多不如第二、三步的严重。

作者: beginnl 时间: 2005-8-12 22:15
对于三者哪个重要，我的理解是因为开发的软件最基本的要求就是实现需求规格说明书中的功能，所以开发人员对这个会比较关注，因而这方面的BUG可能会少些；
从另外两项考虑设计的用例，因为各开发人员负责开发不同的模块，或者开发时考虑不全面，所以一旦出问题，就是较严重的了。
所以偶觉得需求规格说明书中的功能点是基础，其它两项的设计都是基于它上面的。有点才能串成线嘛。:d

[ Last edited by beginnl on 2005-8-12 at 22:16 ]

作者: zlmxjt 时间: 2005-8-14 00:19
我个人认为，设计测试用例的目的是验证软件的质量，帮助开发人员发现隐藏在内部的缺陷，所以用例要用较少的数量达到较高的测试覆盖率，一般常用的方法有等价类划分法和边界值法，还有就是根据长期总结的经验去猜测一些问题。
当然还可以用输出域、状态迁移法、正交分析法、因果图法去补充自己的用例，使之更加充实。
还有用例的写作最好采用一定的格式，这样测试起来一目了然！其内容包含如下信息：
1、编号
2、标题
3、重要级别
4、预置条件
5、输入
6、操作步骤
7、预期输出
希望你能把你工作中的经验拿出来该大家分享，共同学习！
谢谢！

作者: swallow0918 时间: 2005-8-14 16:46
楼上的一看就知道很专业，呵呵~
完全赞同你说的！不过我们公司现在是这么干的：没有“操作步骤”这个，“输入”对应的就是“预期输出”，最后还补充了一个“实际输出结果”。并且要求一个“输入”项对应一个“预期输出”项，这样可以很直观的看出到底是哪一步出现问题。
不知道别的公司是如何写测试用例的？

作者: Tender 时间: 2005-8-15 08:37
楼上的，没有操作步骤是对的，我赞同！

作者: flytigerboy 时间: 2005-8-15 14:10
我们公司里的也和楼上的楼上的一样！
只不过我还是新手，都不知道要怎么去写这些东东啊！

作者: zhaozstone 时间: 2005-9-1 09:30
你首先应该了解可以从哪几个方面编写用例，比如等价类，边界值，正交实验法等。可以看一些这方面的书籍，好多的

作者: flytigerboy 时间: 2005-9-2 08:43
以前学软件工程的时候学过等价类，边界值，正交实验法，但是已经都记不清了！

作者: fly-bird 时间: 2005-9-5 10:33
我最近写的一个网站的测试用例，发现好肤浅哦。。。人家说有什么功能我就写写捕获这个功能，然后实现这个功能输入什么，期望输出什么，其他细节的东西就写不出来，感觉都没什么用处，因为公司我是第一个写测试用例的人，所以也没什么经验可借鉴，也不知道自己写的对还是不对，以至于我现在很恐慌，怕交上去不合格！可是我看着需求就是只能这样写出来～～～怎么办？

作者: testerli 时间: 2005-9-5 14:16
我们公司的测试用例是最简单的，就是描述步骤然后就是预期的结果，难的只是要用英文来写，郁闷阿！

作者: snail2011 时间: 2005-9-12 13:07
其实我现在才发觉我当初设计的测试用例模板有点复杂，但已被公司定为标准模板，不太好修改。
现在我对有些功能真的不好去把握，比如一个导出功能，在一个界面是正常的，但如果再链接到另一个页面，再返回后就不正常了。我测试时发现的，领导说让我加上这个测试用例，以及相关的，哎，头疼，不好加，也还真不知道怎么写好点，主要是有操作步骤这一项。（我本来想去掉，头不同意），这个操作步骤还真是个头疼的问题呢。

作者: hongelicome 时间: 2005-9-12 14:25
真羡慕你们的测试都好正式．我们公司的测试还是属于最低级的工作，特随便，真想尝试一下正统测试的滋味．

作者: beck3000 时间: 2005-9-12 14:39
snail2011，fly-bird，以及各位困惑的小MM们：
不要慌阿，你觉得写的肤浅，可能不是你的错阿，有可能是需求写的有问题，不好的需求确实是没法测试的。
要对自己有信心，多看看讲测试和软件工程的书，保持谦虚的同时也要勇于指出别人的缺陷。
冷静下来查找问题原因才是你现在要做的事情。

作者: dreaming1228 时间: 2005-11-18 15:28
那开发人员应该提供什么文档给测试人员,以帮助测试人员来书写测试用例呢?

作者: qinbob 时间: 2005-11-18 15:43
何为预置条件?望指教,新手上路.......

作者: wmty 时间: 2005-11-18 17:07
面面俱到，越详细越好

一个小测试点就可以写很多内容
比如测一个窗口
先看界面，这里可以写上你所想到的所有界面要求

按钮，也可以写很多
有输入的话，可以写输入字符限制：空、任意字符（中文、英文、数字、特殊字符、全角字符、半角字符）；输入项之间的约束关系等
总之分成很多小的测试点，直到认为无法在细化为止
在加上一些异常的操作，也可以在测试时，随时发现问题，随时补充测试用例

其实，在测试的时候，发现的问题多了，就不怕写用例了。用例也是在测试过程中不断补充积累起来的

作者: gongliang 时间: 2005-11-22 12:50
恩！同意楼上的！

作者: 2005_wei 时间: 2005-11-22 15:07
回qinbob：预置条件我认为是执行该用例的前提条件，比如测登录界面的用户名，前提条件是打开登录界面。

作者: reddragonfly 时间: 2006-2-22 11:10
最近好烦

作者: 老家伙 时间: 2006-3-1 20:27
写用例其实就是测试设计工作中一个比较靠后的程序了，我认为一般针对某一个功能来考虑：
1、先要分析熟悉这个功能的特点、组网要求、应用场景等等，提取测试需求
2、然后设计一个可行的测试方案，分析好该功能的所有的独特测试点以及跟其他功能交互的测试点以及异常测试
   点！当然也逃考虑好测试周期、成本，选择软件工程里面最适合的一种或者几种方法！
3、根据测试方案设计用例，一般拿来专项测试的软件都不小，建议先分好测试项目：
   1、项目编号
   2、项目标题
4、在每一个测试项目里面写作具体的用例，楼上的一家已经说得无可挑剔了
   “1、编号
   2、标题
   3、重要级别
   4、预置条件
   5、输入
   6、操作步骤
   7、预期输出”
不过我建议再加上一项
：7、说明——主要以被测试执行是加上一些说明，如相当特殊的地方，以及对该用例本身有异议都可以在这里注释一下！
——希望大家都说说，给他人共享一下！

作者: niuniu_8000 时间: 2006-3-6 16:51
关于测试，我经验不多，是从开发刚刚转做白盒，所以请问一下，单元测试的测试用例如何写，也和功能测试一样的吗，大家所说的覆盖率又是什么意思？

作者: 粉色的小猪 时间: 2006-3-7 18:05
呵呵!大家都说的很好呀!我们公司的测试用例写的很简单,而且很粗陋(公司的模板一直是这样,我们都是照着写写)!真做测试的时候几乎没什么用,和看需求没什么不同!一般我都不看,测试路径全凭自己想:D

作者: edwin_chen 时间: 2006-3-8 19:35
楼主：你这个问题（如何写好的测试用例）；
我觉得可以从两个方面来回答
第一：从形式上，也就是应该包括必须包括的，如：用例编号，输入，输出………………
第二：从思想上，有句话说的好，好的测试用例是发现了别人没有发现缺陷的测试用例。所以用例的设计思想上更加重要。当然不要看了这句话就绞尽脑汁去想一些刁钻的问题，记住一点：测试的最终目的是为了提高软件质量，而不是发现bug ：）

作者: luopapa 时间: 2006-3-8 20:10
叙述清楚，过程和步骤，预期的输出和实际结果都很重要。我觉得黑盒测试主要还是软件功能上的测试，要想更加深入就必须对系统有个清楚的了解，实现原理，整个流程，这会帮助你从多个方面考虑用例的设计，也才更能发现深层次的问题。当你对系统已经很清楚了，你可以考虑从代码逻辑上去考虑测试的流程。

作者: luopapa 时间: 2006-3-8 20:13
另外在测试前，有一个测试模型是很重要的，他可以是你的测试一直围绕一个问题来展开，不致于迷失方向，同时也可以有效地保证测试的覆盖率，不致于有太多的遗漏。

作者: mistletoe82 时间: 2006-3-9 09:19
楼上所说的测试模型指什么？

作者: 983221wy 时间: 2006-3-11 11:57
谢谢了！！！！

作者: linyuanfu 时间: 2006-3-11 13:33
预置条件就是你要执行这个测试用例之前要准备的工作，比如测试软件的基本功能，首先要把软件成功地安装好，在接着做他的功能测试，就是执行这个测试用例的前提．

作者: qqwc 时间: 2006-3-16 20:53
做为一个新人，很感谢你们分享的这个宝贵的经验

作者: 阿珊 时间: 2006-3-24 15:51
为什么不要写很详细的操作步骤呢？
我一开始操作步骤也写得很笼统，可使被告知，一定要写很详细的操作步骤，不然开发人员会找不到错误，或者说他们在执行的时候没有发生错误。
能不能给解释一下。

作者: vincent_wks 时间: 2006-3-27 10:08
看了各位的回帖，受益匪浅

作者: xiaduo 时间: 2006-4-1 15:56

原帖由阿珊于 2006-3-24 15:51 发表
为什么不要写很详细的操作步骤呢？
我一开始操作步骤也写得很笼统，可使被告知，一定要写很详细的操作步骤，不然开发人员会找不到错误，或者说他们在执行的时候没有发生错误。
能不能给解释一下。

这个牵涉到 bug的重现问题，很多时候，你第二次再去找这个bug会出现逃逸现象，当然，随时开着桌面捕捉程序是一个必须的习惯，文字永远没有图形来的直观。

另外，正规体系测试设计和测试执行时分开的，不知道你们公司怎么样，你写的用例只有自己能够操作的话，那么那些做执行的就比较郁闷了。当然了，目前大环境貌似用例执行都是一个人做的-____-

作者: ivenhua 时间: 2006-4-3 17:30
我也是新到公司做测试不久的，也做的是功能测试，自己感觉这东西刚开始是写不出什么的，就象刚来发现的BUG都比较浅显，过了两个礼拜，就可以发现一些逻辑错误上的BUG了。
我很想进行一下系统的培训，可惜真的是没有时间啊~~~~~~

作者: LecoChen 时间: 2006-4-5 10:03
我想了解一下大家对于每一次测试后的总结是如何进行的，我觉得测试后总结是很重要的，但好像很难下手

作者: ghbb77 时间: 2010-10-17 17:36
恩，你说很好哦，支持你！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)