51Testing软件测试论坛

标题: 从需求分析想到的测试人员业务分析方法 [打印本页]

作者: andytester    时间: 2011-1-10 14:07
标题: 从需求分析想到的测试人员业务分析方法
在设设计用例前,必然要了解业务
如何来分析业务呢?
原文出处

前几天一兄弟接到一个IT运营的系统的活,说需求分析时出了问题,越分析越乱,我问他,是需求没讲清,还是说看不明白?他说,需求虽然不是特别清晰,不过基本业务还是有的,只是在建模时,对像的关系,越分析越乱,好像变成一张没有边际的网。

然后他开始和我讲业务(具体的审批流程,入库,报修等),我听了一会就打住了他,我说你别和我讲细节,讲我也记不住,你先告诉我整体的业务流程,然后他说大概就是,设备管理---à设备申请(设备领用,设备报修,设备采购等),还有一些办公资源的管理,审批流程的定制等。

接下来,我告诉他:“他的问题的根源是为因一下子钻进业务细节去了“,有点”不识庐山真面目,只缘身在此山中“

接下来,我和他从整体的业务流程开始,先理清设备管理的业务,同时也建立了设备管理中的概念模型,然后接下来再分析设备相关的申请并建立其概念模型,在分析的同时,并着重理清了,设备申请的相关业务和设备管理中设备的业务关系,这时关系模型就慢慢的丰富起来。同样的方法,我们顺着整体业务流程下来,整个系统的对像关系模型就建好了,解决了,他原来分析时,越分析越乱,好像变成一张没有边际的网的问题。

对于需求分析,一定要在整体视图(比如:整体的业务流)下,采取先全局,后局部,各个局步再串联(串联本质就是业务关联)的方式来分析。

对于软件测试来说,测试人员要了解业务,这是必然要求,那如何了系统中的业务呢?对于需求分析中的上述方法,同样可用于测试人员做业务析。为什么这样说呢,虽然两者的输出物不一样,但他们的前提是一样的。

原文出处
作者: Jackc    时间: 2011-1-11 12:17
不错,实例讲解“需求逐层分解过程”,要是细节能再详细些就更好了。

需求总体结构图分析是需求分析阶段前期的主要工作。将其整理出来以后,针对各个细小分支的处理仍是重点。
作者: labalilee    时间: 2011-1-11 14:07
不错,思想过程的原则把握确实要这样
作者: Love_洋果子    时间: 2011-3-3 17:21
我感觉就像测试人员对同一对象进行多次测试,就会发现越来越少的缺陷.这种现象的根本原因就是测试人员对测试软件过于熟悉,形成思维定势。
作者: PS123456789333    时间: 2011-3-23 10:35
赞同
作者: 19801106    时间: 2011-3-23 18:17
学习了
作者: 微笑流淌    时间: 2011-3-24 08:54
学习,并赞同4楼的
作者: 依旧执着    时间: 2011-4-1 14:20
有时候就是感觉越分析就发现问题越乱




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2