从需求分析想到的测试人员业务分析方法
在设设计用例前，必然要了解业务如何来分析业务呢?
原文出处
前几天一兄弟接到一个IT运营的系统的活，说需求分析时出了问题，越分析越乱，我问他，是需求没讲清，还是说看不明白？他说，需求虽然不是特别清晰，不过基本业务还是有的，只是在建模时，对像的关系，越分析越乱，好像变成一张没有边际的网。
然后他开始和我讲业务（具体的审批流程，入库，报修等），我听了一会就打住了他，我说你别和我讲细节，讲我也记不住，你先告诉我整体的业务流程，然后他说大概就是，设备管理---à设备申请（设备领用，设备报修，设备采购等），还有一些办公资源的管理，审批流程的定制等。
接下来，我告诉他：“他的问题的根源是为因一下子钻进业务细节去了“，有点”不识庐山真面目，只缘身在此山中“
接下来，我和他从整体的业务流程开始，先理清设备管理的业务，同时也建立了设备管理中的概念模型，然后接下来再分析设备相关的申请并建立其概念模型，在分析的同时，并着重理清了，设备申请的相关业务和设备管理中设备的业务关系，这时关系模型就慢慢的丰富起来。同样的方法，我们顺着整体业务流程下来，整个系统的对像关系模型就建好了，解决了，他原来分析时，越分析越乱，好像变成一张没有边际的网的问题。
对于需求分析，一定要在整体视图（比如：整体的业务流）下，采取先全局，后局部，各个局步再串联(串联本质就是业务关联)的方式来分析。
对于软件测试来说，测试人员要了解业务，这是必然要求，那如何了系统中的业务呢？对于需求分析中的上述方法，同样可用于测试人员做业务析。为什么这样说呢，虽然两者的输出物不一样，但他们的前提是一样的。
原文出处 不错，实例讲解“需求逐层分解过程”，要是细节能再详细些就更好了。
需求总体结构图分析是需求分析阶段前期的主要工作。将其整理出来以后，针对各个细小分支的处理仍是重点。 不错，思想过程的原则把握确实要这样 我感觉就像测试人员对同一对象进行多次测试,就会发现越来越少的缺陷.这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。 赞同 学习了 学习，并赞同４楼的 有时候就是感觉越分析就发现问题越乱
页:
[1]
