naonao0919cn 发表于 2007-9-4 16:36:37

关于功能测试的几个小问题

1.如何进行测试需求的跟踪分析?
2.缺陷统计分析的方法有哪些?每个方法的作用是什么?
3.缺陷的优先级和严重级有什么区别?

这几个问题是我面试时候的笔试题,我答的不是很理想,和大家交流一下,希望能得到比较满意的答复!sdlkfj2

tugang11 发表于 2007-9-4 16:38:11

沙发~~~·
    等下在回答~~~现在没时间

naonao0919cn 发表于 2007-9-4 16:50:31

呵呵,先谢了,期待ing......!

naonao0919cn 发表于 2007-9-4 22:39:36

怎么没人关注哦?是不是我提的问题不够水准?
sdlkfj9 sdlkfj9 sdlkfj9

dpdpdp 发表于 2007-9-4 23:09:35

试着回答一下,答不好别打我脸sdlkfj5
1。是否是利用需求跟踪矩阵
2。不懂
3。严重级别是指缺陷对质量的破坏程度来讲的尤其要站在用户的角度来考虑问题
优先级别应该是用来确定修复缺陷的先后次序
打个比方有两个缺陷A是在项目中把客户的公司名称写错,B是在实现某个功能时时间效率比较差
A的严重级别高B的优先级别高

easyabc 发表于 2007-9-4 23:14:14

我也不懂,期待高人

dpdpdp 发表于 2007-9-4 23:33:58

2.缺陷统计分析的方法有哪些?每个方法的作用是什么?
1.缺陷发生的日期统计(缺陷发现趋势图)
2.缺陷性质统计(缺陷变更,需求变更)
3.缺陷状态分布(关闭,修复中,挂起等)
4.缺陷按子系统(模块)分类统计
5.缺陷引发原因分类统计
6.缺陷来源统计(缺陷提交人或提交方)
来自牛人(Fin)的回答该是属于SQA的工作内容吧

xianzi 发表于 2007-9-5 10:39:47

总结dpdpdp 的回复就是很环确的答案

dpdpdp 发表于 2007-9-5 10:45:31

sdlkfj8 sdlkfj8 环确??

naonao0919cn 发表于 2007-9-5 18:06:45

十分感谢dpdpdp,又长了不少知识!
2,3题的答案我没异议,第一题你说的是否利用跟踪矩阵,关于跟踪矩阵不是很了解,能否详细解释一下?谢了!sdlkfj6 sdlkfj6 sdlkfj6

arlenexhl 发表于 2007-9-9 15:50:29

回复 #10 naonao0919cn 的帖子

1 需求跟踪矩阵(RTM)有什么作用?

   (1) 在需求变更、设计变更、代码变更、测试用例变更时,需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具,如果不借助RTM,则发生上述变更时,往往会遗漏某些连锁变化。

(2) RTM也是验证需求是否得到了实现的有效工具,借助RTM,可以跟踪每个需求的状态:是否设计了,是否实现了,是否测试了。

   

2 需求跟踪矩阵分为哪几类?

(1) 纵向跟踪矩阵,包括如下的3种:
需求之间的派生关系,客户需求到产品需求
实现与验证关系:需求到设计,需求到测试用例等
需求的责任分配关系;需求由谁来实现

(2) 横向跟踪矩阵:
需求之间的接口关系



3 在实践中,如何把握该建立哪些RTM?

(1) 在SEI的调查中达成的基本共识是:纵向跟踪是必须的,如果没有,则 REQM SP1.4无法通过。横向跟踪如果不作,则是大部分实施。
   (2) 对于纵向跟踪矩阵:

必需的:

Ø         客户需求与产品需求的跟踪

Ø         产品需求与测试用例的跟踪

Ø         100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵

Ø         全局性需求要建立跟踪矩阵,包括:客户需求-产品需求-设计-编码-测试用例的跟踪矩阵

Ø         核心需求要建立跟踪矩阵

       并非必需的:

Ø         性能需求可以不建立跟踪矩阵

Ø         不影响系统架构的功能需求



4 需求跟踪矩阵由谁来建立?

   有多个角色参与建立RTM。需求开发人员负责客户需求到产品需求的RTM建立,测试用例的编写人员负责需求到测试用例的RTM建立,设计人员负责需求到设计的RTM的建立等等。PPQA负责检查是否建立了RTM,是否所有的需求都被覆盖了。



5 RTM是否纳入基线管理?

RTM要纳入基线管理。纳入基线后,每次变更都要申请,RTM的变更一般是和其他配置项的变更一起申请,很少单独申请变更RTM,除非RTM有错误。





6 如何简化RTM的工作?

   由于在RTM中,需求可能有很多项,设计、测试用例、代码等都有多项,所以建立和维护RTM的工作量还是比较大、比较烦琐。对于变化频繁的项目,更是如此。在实践中,为了简化该RTM的建立与维护工作,有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪,如需求为:r1,r2,……等编号,而设计的编号为:r1-d1,r1-d2,…….,测试用例的编号为:r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系,仅通过编号是无法实现这种关系的。如果不借助DOORS之类的需求管理工具,一般只能通过EXCEL来维护RTM,工作量就是比较大。要简化,就要平衡管理的投入与产出,平衡时,可以借鉴上面的问题3。

   当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小,但是那样RTM的作用就打了折扣,还是一个平衡问题。

kelequy 发表于 2011-4-29 22:08:00

回复 7# dpdpdp


    以上说的都是统计的工作,是很必要的。不过对于“分析”方面似乎没有提及。

东方明月1 发表于 2013-2-8 00:03:15

我也不懂,期待高人
页: [1]
查看完整版本: 关于功能测试的几个小问题