51Testing软件测试论坛

标题: 测试用例内部评审的标准？？ [打印本页]

作者: wonder 时间: 2004-12-9 09:01
标题: 测试用例内部评审的标准？？
求助:
测试用例写完以后，先要进行内部评审，
其它的人要看这个内部评审的结果，
我们内部评审通过的证据有哪些方法可以显示出来给他们看呢??
内部评审通过的标准大家都有哪些？？？

作者: wonder 时间: 2004-12-13 11:17
我现在想到一些：
比如对需求了解的程度，测试用例的覆盖率，单个测试用例是否单一，描述是否清晰准确，
测试计划全面与否，测试用例多少好坏，工作耗时；耗时与产出的比例；
总觉得很多标准有重复，不知道怎么去明确区分，很多东西都不知道怎么去量化，是很主观的东西。
大家觉得还有哪些标准？？提点意见吧。。。

作者: lotus 时间: 2005-1-29 17:22
wonder兄你好，我们公司也想进行测试用例评审，
但也是没有一个标准，没有开始
这测试用例是由不同的测试员完成的，每个人的工作方式不一样，不知道这样做是否太牵强了？？？？
1测试用例的评审，有哪些人参加，多长时间完成，是否会有效果？
2用例的书写标准化
3不同人员对测试注意点都不一样，往往领导是希望一次写完，一次就找出所有bug
领导层的软件质量思想有多少，很多？？？？
4软件出现bug数的多少，是测试人员用心测试发现的，还是开发人员水平次产生的，对测试人员以bug多少及等级评比，对测试人员是否公平，测试人员的权力多大，应该考虑的是软件最终的质量

难呀！！！！！！

作者: anny728 时间: 2005-1-31 18:18
系统分析员、程序员跟其他测试人员一起参加这个评审活动，主要要看测试用例对需求的覆盖率，测试用例的正确性、全面性、用例是否具有代表性（最少用例能测试最多的缺陷），测试用例是否描述清楚（期望结果是否说明）

作者: anny728 时间: 2005-1-31 18:20
系统分析员、程序员跟其他测试人员一起参加这个评审活动，主要要看测试用例对需求的覆盖率，测试用例的正确性、全面性、用例是否具有代表性（最少用例能测试最多的缺陷），测试用例是否描述清楚（期望结果是否说明）

作者: wangnan 时间: 2005-2-7 13:48
个人认为所有的流程和规范都是为了目标的实现
测试的目标是确保质量，提高客户满意度
寻找BUG永远都是手段而非目标，
流程应该越简单越好
简单的本身就可以提高效率
检验工作的完成程度就是你希望他做到的程度
如果别人不明白你的期望或要求
就不可能满足你的期望和要求，
所以建立规范之前，首先要想清楚公司的整体目标而后是该如何达到目标
另外最关键的是要把团队的目标和每个团队成员个人的目标结合起来
只有这样才会产生效果...

作者: asong401 时间: 2005-2-8 09:56
wangnan说的那些观点都挺正确.
但具体到评审测试用例的好坏,我认为可以通过下面几点考虑:
1.测试用例是否覆盖了所有需求.
2.测试用例内容是否正确,是否与需求目标一致.
3.测试用例内容是否完整,是否清楚包含输入和预期输出结果.
4.测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维.

作者: 中秋明月 时间: 2005-3-1 17:16
各位DX提到的很关键。
我们在评审的过程中也有几个方面考虑：
1.找出哪些需求不可测：无法准备环境、可测试性达不到等等原因；
2.对具体需求的实现结果，设计人员、开发人员、测试人员的认识是否一致，如果不一致，谁说了算；
3.对于被测对象的性能是否有要求，怎么测？（很多模块不能用loadrunner这样的工具）
4.是不是所有的测试用例都很有价值，有些测试用例是不是可以省略来降低成本？
5.是不是把最多的测试用例精力放在模块的最主要功能上了呢？

作者: 嘘garfield 时间: 2005-4-14 09:21
标题: 有点疑问
那如果是由不同的人员各自负责一部分的功能点,这样写出来的用例会存在上面提到的那种情况吗(把最多的测试用例精力放在模块的最主要功能上.)?

作者: dragon21 时间: 2005-5-10 08:36
感觉是内部标准不太统一，应该首先保证覆盖需求，然后考虑性能和压力。

作者: goal0813 时间: 2005-5-12 16:46
同意asong401的观点
1.测试用例是否覆盖了所有需求.
2.测试用例内容是否正确,是否与需求目标一致.
3.测试用例内容是否完整,是否清楚包含输入和预期输出结果.
4.测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维.
初期设计测试点时，应该进行测试组内部评审，当然首先是要保证需求全被覆盖，如果能在评审时，让需求分析人员参与进来，效果会更好。

作者: line 时间: 2005-5-13 09:27
标题: 补充
主要的一点还应邀请产品工程师来参加这个内部评审。目的是对测试用例中所覆盖的系统业务是否正确。

作者: yayachen1109 时间: 2005-6-16 11:02
首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。

如果是测试组内部的评审，应该着重于：
1. 测试用例本身的描述是否清晰，是否存在二义性
2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下
3.是否针对需求跟踪矩阵，覆盖了所有的软件需求，
4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。

如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如：
收集客户需求的人员注重你的业务逻辑是否正确；
分析软件需求规格的人注重你的用例是否跟规格要求一致；
开发负责人会注重你的用例中对程序的要求是否合理。

要清楚地一点是：为了保证测试用例设计的质量，以及评审的收益，在提交项目组评审之前，必须通过测试部门或测试组内部的评审。

作者: 迎风 时间: 2005-7-4 14:47
谢谢楼上各位前辈朋友的交流讨论，让我受益非常，刚好新公司要欲成立测试部，有幸作为其中的一份子，我深感内部优化的重要性。而作为其中起着关键作用的评审，今儿终于让我找到了完善的方向，再次感谢～～

作者: zhengyh1980 时间: 2005-7-14 21:41
开发部的人员参加，主要是看测试用例的覆盖面是否到位
测试部内部的人员参加是看些的规范性，是否冗余，是否合理等
反正与开发部门是由一点区别的

作者: 依伊卜舍 时间: 2005-8-1 21:08
开发部的人员参加，主要是看测试用例的覆盖面是否到位，可以指出重要测试点。

作者: xiaolinyou 时间: 2005-8-2 17:45
评审不光是审文档，还有个目的是看测试用例是否完善，方向是否有偏差。上一级主管及相关领域的测试负责人、开发人员都可参加

作者: bjcoic 时间: 2005-8-5 14:26
大家的提议都很好，其实最主要的是自己公司所执行的流程，然后在选择合适的评审方法，其实我更支持yayachen1109所说的内容，讲的很全面，也考虑的很周到了！根据自己公司的特点适当的剪裁才是最重要的！

作者: hxf 时间: 2005-8-8 15:46
我感觉对测试用例做内部评审是很重要的。
我个人认为：
（1）评审人员应该包括：开发人员、系统分析人员、项目经理、相关测试人员。
（2）主要评审的内容应该包括：
<1>测试用例是否覆盖了所有需求.
<2>测试用例内容是否正确,是否与需求目标一致.
<3>测试用例内容是否完整,是否清楚包含输入和预期输出结果.
这是个人的意见。

作者: liaoxj 时间: 2005-8-25 10:40
顶！我不知道说什么，学习！

作者: songfun 时间: 2005-8-26 19:26
标题: 我也学习学习:)
这篇帖子相当好！
尤其yayachen1109的回复相当精彩！

作者: zjsuperman1980 时间: 2005-9-14 13:24
标题: 没有，基本没用，大多时候是个走过场的茶话会
因为人的因素,没有，基本没用，大多时候是个走过场的茶话会

作者: wfq80825 时间: 2005-10-19 16:42
我们公司进行过几次测试用例的评审，基本是这样的流程。
先由测试组长给大家发出通知，而参与测试用例评审的人有：该项目的负责人，该项目的开发人员该项目的测试人员，该项目的系统分析人员。
做法：1.项目负责人与系统分析人员差不多一致态度，对测试用例整体把握，是否对某功能点理解有误，或者漏掉某个功能点等
      2.开发人员，个人认为开发人员的意见更具有实际意义。开发人员会对具体到某一个测试项提出是否有多余的step，应该这样测会更到位。
      3.后测试组会对评审过程中所提到的问题一一分析进行有效修改，如果有严重问题，还需修改后重新评审直道都通过。
      4.测试组长发布评审报告。
      5.测试组内部如果有时间会组织一次讨论，对流程的规范，对测试用例的编写上以后要加强的地方。这就是经验积累的地方。

作者: supperstar 时间: 2005-11-15 17:19
标题: 询问一下有哪位高人知道微软的LTK测试
有哪位高人可否指点下微软的LTK、CETK测试，主要是针对Smartphone.Thanks！

作者: pride 时间: 2006-1-13 19:43
标题: opinion
说点个人见解,
前段时间公司进行了几次评审,虽然都不识很规范,可是在评审过程中也是自己重新审视自己的作品的一个过程,而且在你和大家讨论时,会惊奇的发现许多曾经是认为不可能出现失误!
个人自我发现是很重要的

作者: freshrain 时间: 2006-2-21 17:30
标题: 说的不错
有道理

作者: hades 时间: 2006-3-6 12:43
标题: hades
测试用例检查（入口检查内容，结论和原因说明）

作者: slide 时间: 2006-3-30 21:44
前面说得比较全面了，我补充一点个人看法。
可以从几个方面来考察测试用例的质量。
一方面是从结果来看，直接考察测试用例的需求覆盖率。以覆盖率为指标，可以不受中间分析过程的设计习惯的影响，从根本上保证测试用例的不会出现遗漏。
令一方面，是从过程来看，考察测试用例的设计方法是否科学，对于需求进行了全面分析，选用分析方法和用例设计方法是否合适等等，正确的过程可以保证结果的质量。
最后，是测试用例本身，在考察描述是否正确，能正确执行的同时，可以适当考虑一下描述方式是否合理，是否采用了最佳的方式来描述，是否把过程和参数分离开了等等。

最基本的要求是保证用例对不对，进一步是保证用例好不好。

作者: liaoxj 时间: 2006-3-31 15:39
每个测试用例是否都说明/代表一个唯一的输入集或事件流？
测试用例是否可以追溯到产品需求？
测试用例是否100％覆盖产品需求要求的所有功能点？
用例是否覆盖了测试计划的测试类型？
所有的“前置条件”是否都是充分必要条件？
判断点中是否没有操作步骤？
测试步骤是否简练？
每个步骤是否描述了一个事件？
“测试步骤”中引用数据的格式是否统一？
“测试步骤”和“预期结果”中对界面文字的引用是否加引号？
预期结果是否描述完整？
文档使用的词语是否清晰明确、无歧义？
测试用例是否覆盖每个被测功能的所有可能的输入输出的组合？
测试用例是否覆盖正常的输入输出组合的所有可能的取值范围？
测试用例是否包括测试了被测试对象的初始化过程？
测试用例是否包含了被测对象中所有异常流的测试？

作者: studystudy 时间: 2006-4-4 18:15
看完后，收获不小。
个人认为还需要考虑：
1、测试用例的可测性。（即一个没有经验的测试人员也能很好的按照测试用例进行测试）
2、测试用例的测试策略性的正确性。（可以避免大量重复而无功效的测试用例，减少用例的编写时间与测试的时间）
3、测试用例的一个提升性。（即可以将其最大化做到测试用例的复用，减少重复劳动）

作者: 小一 时间: 2006-4-19 10:54
收获不少。SKS！

作者: wjmiao 时间: 2006-5-21 15:03
我么从来不进行测试用例评审的。看了后学到不少

作者: allismine 时间: 2006-5-30 14:18
测试用例的评审相当有必要，作为测试部分或者组织来说，不可能每个人的水平都一样高，而测试用例一般也是分模块来编写的，存在这样那样的错误也是再所难免的，所以评审是对整个测试组负责，更是对整个项目负责。毕竟测试发现错误越早，代价越低。

作者: allismine 时间: 2006-5-30 14:27
测试用例评审的时候，如果有可能，最好能够有最终用户的参与，这样才能真正的发现测试是否偏离了方向，是否过分强调对本部分的测试，而此部分并不是用户最关注的问题，而因此把时间浪费，那样测试的成本就太高了。

作者: oscar_wang0721 时间: 2006-6-23 14:38
太多理论东西了，真正一个会议的操作没有那么多....
1、测试用例评审会议组织者收集需要进行评审的工作产品－测试用例，一般是文档形式。
2、发送会议通知，确定会议人员，时间，地点等信息，并请参加会议人员浏览待评审用例，以及发出相关文档，比如相关需求。
3、评审会议
1）测试用例是否覆盖需求
2）测试用例是否正确体现需求
3）测试用例步骤是否符合设计
4）测试用例是否包含测试数据和期望结果
5）测试用例使用文字是否存在二义性
6）....
4、结束会议，确认会议评审结果
5、发送评审报告
1）测试用例对需求的覆盖度
2）测试用例对设计覆盖度
3）测试用例Bug捡出率
4）....

作者: sunicsu 时间: 2006-6-27 10:31
不错！

作者: fly-bird 时间: 2006-7-21 11:40
看了这么多收获也很多，也有一些疑问，我们公司虽然测试用例也在写，但是真正的评审却没进行过，我在想如果真的评审的话，那么多的测试用例，那么多的需求，要一个个看过来嘛？

作者: miny19 时间: 2006-7-21 14:56
fly-bird,我想，如果要评审的话，不会评审在此之前所有的用例吧。
个人认为，评审测试用例之前，参与评审的人员一定要看需求，而不是形而上学的。
我赞同oscar_wang0721 的观点，评审时太冗余的讨论和评价，通常会影响项目的进度和测试用例中真正的问题。

作者: roadxizi 时间: 2006-8-8 12:12
试题一　(15分)
　　阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。
[说明]
　　基本路径法设计出的测试用例能够保证在测试中程序的每一条可执行语句至少执行一次。以下代码由C什语言书写，请按要求回答问题。
　　void ReadPara( CString temp)
　　{
　　　if ( temp == ">=")
　　　　　m_oper.SetCurSel(0);
　　　else
　　　{
　　　　　if (temp == ">")
　　　　　　m_oper.SetCurSel(1);
　　　　　else
　　　　　{
　　　　　　if ( temp == "==")
　　　　　　　m_oper.SetCurSel(2);
　　　　　　else
　　　　　　{
　　　　　　　if( temp == "<=")
　　　　　　　　m_oper.SetCurSel(3);
　　　　　　　else
　　　　　　　{
　　　　　　　　if ( temp == "<")
　　　　　　　　　m_oper.SetCurSel(4);
　　　　　　　　else
　　　　　　　　　m_oper.SetCurSel(5);
　　　　　　　}
　　　　　　}
　　　　　}
　　　　}
　　　return;
　　}
[问题1]　(6分)
　　请画出以上代码的控制流图。
[问题2]　(3分)
　　请计算上述控制流图的环路复杂度V(G)。
[问题3]　(6分)
　　请使用基本路径测试法为变量temp设计测试用例，使之满足基本路径覆盖要求。

作者: dandan 时间: 2006-8-10 15:50
.........

作者: liaoxj 时间: 2006-8-31 17:09
http://bbs.51testing.com/thread-42156-1-1.html

大家可以下载下来看看!

作者: fanli2000_0 时间: 2006-12-27 15:07
标题: 我来说两句
首先执行用例其实只是一种手段而已, 而目的就是保证程序的正确性,健壮行,可维护性,本人认为越简单的用例执行起来就越高效.
再说项目的早期需求跟中后期需求都是有所不同的, 这就需要我们根据需求的不同而及时更改用例,方可达到用例优化的目的,这应该也是用例评审的目的。

作者: harric 时间: 2006-12-29 16:38
up

作者: aancting 时间: 2006-12-29 17:15
标题: 回复 #44 harric 的帖子
我说说我们公司目前测试用例的评审方法给大家参考一下:
1.最少在正式评审会议前一周将需要评审的用例发给需参与评审的相关人员.
2.评审人员包括:开发部经量\项目经理\项目组主要开发人员\测试经理\负责写测试的人员.
3.测试过程中主要是看测试用例与需求是覆盖情况,找是有需求说明书有的内容,但是在用例中没有相应的用例;测试用例是否详细\完整.目前我们公司涉及到具体的字段.
4.评审中将产生的问题,有专人整理,负责写用例的人需要根据评审发现的问题,对用例进行修改\完善.若用例评审的问题太多,需要安排时间进入再次评审.
5.整个评审小组通过后,测试用例才能提交负责测试的人员,进行测试.
6.测试用例的评审比较繁锁,一般测试流程不太规范的公司,评审效果很难体现.

作者: wanfali 时间: 2007-1-8 14:47
标题: 回复 #29 liaoxj 的帖子
直接实用，在以前的公司做测试用例的评审和这位同行介绍的基本一致！对于cmmi来说，测试用例的评审是必须的！

作者: sense 时间: 2007-1-9 16:11

原帖由 hxf 于 2005-8-8 15:46 发表
我感觉对测试用例做内部评审是很重要的。
我个人认为：
（1）评审人员应该包括：开发人员、系统分析人员、项目经理、相关测试人员。
（2）主要评审的内容应该包括：
<1>测试用例是否覆盖了所有需求. ...

真希望到这种环境中，我们公司根本就不进行评审，唉

作者: r_sunny 时间: 2007-1-12 10:15
路漫漫其修远,不光是个人测试用例的设计,还是公司开发过程管理都要好好提高!

学习,学习!

作者: gsclishen 时间: 2007-1-12 13:23

原帖由 wonder 于 2004-12-9 09:01 发表
求助:
测试用例写完以后，先要进行内部评审，
其它的人要看这个内部评审的结果，
我们内部评审通过的证据有哪些方法可以显示出来给他们看呢??
内部评审通过的标准大家都有哪些？？？

以下是我评审的时候的标准，供参考吧
1.测试用例是否覆盖所有测试需求点，最好对应需求的编号；
2.测试用例是否覆盖了用户最常见和较常见的操作，这些操作是通过和市场人员、实施人员以及PM讨论得出的；
3.测试用例是否覆盖了大部分的异常情况，这个就需要具体业务具体分析了。

作者: jumbynet 时间: 2007-1-15 18:38
学习中，写的很好。。。。
但个人经验与当时环境关系比较密切。。
最好搞一个规范。。。

作者: TIAOSA 时间: 2009-3-13 11:11
受教了！多谢！

作者: xiahuaoxiang 时间: 2009-4-20 09:18
wo ding

作者: xiaomili00001 时间: 2010-2-11 11:14
我现在在国内知名it公司内，对于这方面还是要好好斟酌一下

作者: yibei8535 时间: 2011-5-3 15:50
对于评审只是有点粗粗的概念，只是个人认为很有必要
受益匪浅，正在找这方面的实施策略，感谢各位DX的讨论

作者: ruirui。 时间: 2011-5-6 11:33
很早以前的帖子又给挖出来了。

作者: diudiucheng 时间: 2011-5-6 11:56
其实我认为，测试用例内部评审，不能只当做一个工作，而是对被评审和评审人员的一个提高：
通过被评审，写用例的测试人员可以看到不同角度的想法；
评审人员可以通过用例，来发现自己没有考虑到的地方，
确实是个很好的方法，个人觉得非常有必要实行。

作者: huazai_888 时间: 2011-5-17 22:58
hah

作者: jackdymo 时间: 2011-11-4 10:50
mark

作者: fwind1 时间: 2011-12-7 18:02
mark

作者: Biang 时间: 2012-1-6 17:49
学习！！！

作者: shanzengguang 时间: 2012-2-6 22:41
正式评审应该包括开发人员、QA、测试人员、项目经理等所有涉及到项目具体工作的人。测试部门内部评审应该不会很正式吧。用例评审主要还是参考需求规格说明书，然后用例的格式是否符合标准(已经经过正式评审的模板)，描述是否清晰易懂。根据个人工作的一些见解，仅供参考。

作者: an_qing_25 时间: 2012-2-27 17:33
说的非常好，学习

作者: breeder 时间: 2012-3-22 17:55
用例评审我们都做了一年了，感觉还是没到点子上，帮助不大

作者: judang 时间: 2012-4-9 13:39
学习一下

作者: yiwang_tao 时间: 2012-5-5 19:00
测试用例对需求的覆盖率，测试用例的正确性、全面性、用例是否具有代表性（最少用例能测试最多的缺陷），测试用例是否描述清楚（期望结果是否说明）
-------------------------------------------------------
其实，如果是功能方面的测试，测试用例之前要做好： 1. 测试分析 2. 场景设计

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