测试用例评审检查项都有哪些

trademark

大家都聊聊平时做项目时,完成测试用例后项目组对测试用例进行评审时,都检查测试用例哪些项?

fucheng_007

楼主?
你有测试用例评审检查单?分享一下!
fucheng_007@163.com

dream.ttt

mark,12#

阿来八八

学习一下，目前我们公司还没时间评审我们的测试用例，自己先保证能全面覆盖需求，跟上需求的变更就行了

gosien

1        《需求规格说明书》是否评审并建立了基线？
2        是否按照测试计划时间完成用例编写？
3        需求新增和变更是否进行了对应的调整？
4        永是否按照公司定义的模板进行编写？
5        测试用例是否覆盖了《需求规格说明书》？
6        用例编号是否和需求进行对应？
7        非功能测试需求或不可测试需求是否在用例中列出说明？
8        用例设计是否包含了证明、反面的用例？
9        每个测试用例是否清楚的天下了测试特性、步骤、预期结果？
10        步骤/输入数据部分是否清晰，是否具备可操作性？
11        测试用例是否包含测试数据、测试数据生成办法或者输入的相关描述
12        测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法？
13        终端需求用例设计至少要有三种方法？
14        每个测试用例是否都阐述预期结果和评估结果的方法？
15        需要进行打印、表格、导入、导出、结果是否存在打印位置、表格名称、制定数据库表名或文件位置；表格和数据格式是否有说明或附件
16        用例覆盖率是否达到相应的质量指标？
17        用例预期缺陷率是否达到相应的质量指标？

mating1983

我觉得我们还不如评审下测试人员对业务的理解和测试的思路呢

xianzi

用例评审主要是QA、产品人员、开发人员和测试人员针对测试用例能否用于项目的测试而做的，主要侧重以下几方面：
1、测试用例是否覆盖到了项目需求中的所有功能，这些功能的数据输入与输入出描写是否清晰
（上面这一点是主要考察的方面，此项目做的不好用例就肯定不能通过）
2、项目中实际用到的一些例外处理方式与需求方是不是一致。
（开发方比较在意，因为有的项目中技术无法实现）
总体来讲就是以上两点，有不全面之处大家可以补充一下。因为，测试用例是给测试人员执行用的，所以要求尽量的详细而不冗余，精湛而不纰漏，至于一些覆盖率的问题还是测试内部评审时要考虑的问题，与项目的用例评审没有关系。产品方和开发方都要不会注意这些的（偶说的是功能方面的，性能方面的还请专业人员做补充）

鱼鳞

了解学习中

sunxy5291

1. 用例设计策略
2. 用例覆盖率
3. 用例书写格式
4. 用例可读性
5. 用例可执行性

lj1981727

我们最近也是在做一个测试用例检查表
主要包含了以下几个部分
1 测试用例文档的相关填写是否按照测试用例文档的规范
2 用例是否覆盖了需求中提到的功能点，如果没有覆盖完，就认为没有通过检查，没有通过的话说明中需要列出没有覆盖的功能点
3测试用例的输入和预期结果描述的是否清楚，是否有不确定的预期结果。如果有不清楚的地方写出不清楚的测试用例编号
4测试用例的名称是否能让人领会到测试用例测试的功能点。
还有几个我记不太清楚了。

针对测试用例的细节部分没有在检查表里体现。这部分不太好放在检查表里面。只是有一个单独的测试用例公共库去参考。

因为每个系统的用例如果一旦和业务关联起来，检查时都是看设计的用例是否覆盖到了所有的功能点，有没有漏掉需要测试的功能点，
还有一些测试过程中经常容易出错的地方看测试用例是否考虑。

不知道其他公司里面有没有类似于测试用例检查表的东西，如果有的话，希望能够在制定测试用例检查表这个方面交流一下

[ 本帖最后由 lj1981727 于 2006-8-24 21:39 编辑 ]

trademark

你说的应该是评审所要的规格吧,我不认为内容不重要,如果没有内容还评什么.那么进行评审前肯定是出一份评审所依据的规格出来的.这样才不会疏漏.

ilovejolly

这种评审需要有严格的规范才能进行,内容倒没什么好说的,需求的覆盖率这么简单一句话,你做起来看看,真正的难

我加两个我觉得重要的,粒度是否合适,表述是否清晰

trademark

你误解了我的问题,我的问题的答案比如说检查所设计的用例是否完全覆盖需求

ouyu

测试用例的数据的输入，执行步骤，输出结果。