有关怎样体现业务流程的测试用例编写问题？？？

heyifan7

有一个比较棘手的问题是
现在编写测试用例时是按模块去编写  这样功能点覆盖的非常全面   
但是有一些业务流程上的东西 在这样的编写过程中就体现不出来   业务流程是贯穿在模块之间的
怎样能把这些散的测试功能点能穿起来啊  这样的用例怎么编写呢   是我按角色去跑流程时把用到的测试用例都单揪出来吗  组成一个测试的一个业务流程似的用例 这样感觉用例是成线状的了  而不是零散的点
不知各位前辈有什么高见啊？

archonwang

原帖由 dionysus 于 2007-1-31 16:51 发表
可以在流程初期设计业务用例，并与开发和需求人员沟通一致，这样可以避免一些错误的理解。等到软件开始编写、界面开始出来后同时编写功能用例。
功能与业务分开是很必要的，不然会只见树木难成森林

同意。

这是两个阶段的测试，绝不可以混合。否则可能导致如下的问题：
1. 测试周期拉长；
2. 测试覆盖不完全；
3. 排错上存在一定的障碍，延缓进度；


把通过功能测试，作为业务流程测试的前提。建议按如下次序进行
1. 优先完成业务流程测试案例设计；
2. 在开发提交前完成功能测试用例；
3. 执行功能测试案例；
4. 修订业务流程测试案例；


基本原则：
1. 最先开始的最后结束
2. 持续修订，直到正式发布

feeling舞

大家有没有听说表单测试，这个跟前面两种测试有关系吗

19801106

学习了，个人觉得还是分开好。
我们是先进行 流程测试，看流程是否能跑通，再进行功能的验证测试

tommey

业务流程的用例应该以需求作为标准，再根据用例编写测试用例（就是把用例具体化），我现在正采用情境的方式写用例，因为是erp产品，如果分支多和集成化比较高还有些问题，正在找解决办法。
功能测试也必然要与业务流程测试分开，前者是重功能算法，后者是重逻辑。
测试本身就是一个费时费力的工作，不能投机取巧的，外国越是大型软件在测试方面投入的人力物力就越大，以oracle 11g 为例，测试时间达到了1500万个小时，开发工作量达到了3.6万人/月。

夭夭旭

顶一个。希望大家继续讨论。学习中。。。

applue

我主要是做企业管理软件的测试的,在写测试用例时尤其要考虑业务流程测试,对此也很茫然,看了很多朋友都说应该把功能点测试和业务测试分开考虑,不过对于一个大型的企业管理软件而言,感觉若真要完全按照此规格来写出所有测试用例,那是相当耗时和需要大量精力的,尤其对于模块较多的软件.而且感觉可能会有很多重复的工作,用例可能有很多冗余的吧,可能相对于人力成本太高了而且资源浪费大.
   我就在想可不可以在写功能测试点的时候就考虑到业务点呢,比如说对一个大型系统的某个模块写用例时就把各种数据的可能流向,各种路径都考虑进去,最后只需要在每个模块衔接处或数据流向点进行相关的测试,不知道这样测试能够完整而且不冗余的进行完全测试吗 ?!

wangjingying

说得太好了，受教~~

yangao1

假如是购物网站，页面上列出了几种商品的图片和简介，点击其上会出现该商品的详细，这样的话，对这几种商品而言，它们是否等价类，只点击测一种商品就可以了呢？请多多指教

cq0417

受教了~

chacha520

顶     顶     顶

camille123456

我觉得业务流程可以放在后

changlang530

根据流程分成各个模块测试。

camille123456

我之前也一直在思考这个问题，功能测试时尽量编写得到位一点，我是到最后，再设计业务流程用例来把整个系统跑一遍的。但感觉这样子有好处也有坏外。

好处是：心里踏实了，相当于对系统做了一个整体的验收
坏处是：感觉在跑完全部听功能点之后，再跑业务用例，感觉几乎找不出BUG。

听了以上的发言，有些体会，业务流程用例是应该单独例出来。还觉得有必要在功能测试前后都跑一遍

wyalgl

学习中！！

guaiguai

我在测试的过程中是将功能个流程方在一起走的，写得很累，但是分开写不晓得怎样写

tjj006

这么做，CASE量又增加了。。。

白菜叶子

分开写，业务流程可以用场景法写，一个业务流程一个场景。

luming

分开比较好。
比如测试功能的时候，只测试添加、删除、修改、查询、打印等具体功能是否实现。

测试流程再设计几个典型的用例，用典型数据经历各种路径。

dionysus

可以在流程初期设计业务用例，并与开发和需求人员沟通一致，这样可以避免一些错误的理解。等到软件开始编写、界面开始出来后同时编写功能用例。
功能与业务分开是很必要的，不然会只见树木难成森林