51Testing软件测试论坛

标题: 大型系统的业务流程、逻辑特别复杂的用例适合自动化吗？ [打印本页]

作者: 戒情人 时间: 2009-10-22 10:22
标题: 大型系统的业务流程、逻辑特别复杂的用例适合自动化吗？
单个界面的增、删、查、改这些操作都非常简单，写自动化脚本也都非常容易。但是大型系统的业务一般都比较复杂，要完整的测试一个功能流程都需要很多步骤，可能需要从步骤A—>B--->C--->D--->E----F等等，我想做过大型系统测试的朋友都有体会。当然我说的这种测试是在对系统业务理解非常好的情况下，对整个系统流程做的比较深的测试。算是很有价值的测试。如果不把每个步骤关联起来，只在A界面或B界面点来点去，则不属于我说的这种情况，这种测试在大型系统的测试中基本没什么价值，因为每个界面的简单功能开发人员一般不会出错。难的就在复杂业务流程的实现上。所以很多做大型系统的公司招人时都要求有那个行业的经验。有些还是必须的条件，除非是招应届生。要完整的测试一个业务流程需要非常细心认真，执行完每一个步骤，都要去看相关联的其他地方是否有相应的正确的改变，然后再去执行下一步，执行完下一步，导致后面的步骤也会有相应的改变，有的也会对前面的步骤做出改变。比如A步骤产生数据给B步骤，B步骤把数据处理后传给C步骤，同时因为B步骤已经对A步骤产生的数据做了处理，则A步骤的数据不允许再编辑等等，总之业务很复杂，很多方面都要来回反复的考虑到。如果对业务很熟悉后，手工测试这种业务流程基本没什么问题。但是这么复杂的一个测试流程适合用一个自动化测试用例来实现吗？请有经验的朋友来指点一下。

[ 本帖最后由戒情人于 2009-10-22 11:46 编辑 ]

作者: 戒情人 时间: 2009-10-22 10:36
请朋友们帮忙指点一下。我做自动化测试也很长时间了，甚至现在是专门做自动化测试。但是上面说的问题真的是一个难题，如果那么复杂的测试去用自动花实现，中间要查看很多状态和数据，步骤又很多，写脚本一定很复杂。如果中间的数据或状态那里有一点问题，整个复杂的脚本可能就无法运行下去。但是如果把复杂的流程拆分过一个个小过程，然后写脚本，虽然简单但又没有什么意义，因为那些流程在现实中是一气走完的，拆开测没现实意义。我们测试应该模仿系统在现实中的真实使用情况，应该模仿用户的使用情况，这样才能找到有价值的问题，才有意义。

[ 本帖最后由戒情人于 2009-10-22 10:53 编辑 ]

作者: 戒情人 时间: 2009-10-22 11:12
我顶

作者: roger_ge 时间: 2009-10-22 11:42
看看能不能把流程图画清楚，毕竟这是编程的基础
如果能画清楚，路径覆盖不知道可不可以

作者: 戒情人 时间: 2009-10-22 12:49
标题: 好问题
值得讨论

作者: heavy200t 时间: 2009-10-22 13:23
对复杂流程系统测试会碰到以下困难：
1、流程组合复杂，路径多；
2、业务复杂会有设计上考虑不周的漏洞；
对于前者，可以通过刻画关键流程，组件化测试脚本的方式来解决。
对于后者，这个本不是自动化测试能解决的问题，不用讨论了。

自动化测试的目标是通过机器验证设计中的测试用例，提高测试效率和质量。
至于想要通过软件发现人没有考虑到的漏洞，那就是fuzz testing范畴的问题了。

作者: dreamever 时间: 2009-10-22 13:37
业务流程的测试本身就是很麻烦的，因为业务流程中每个操作步骤每个输入数据都可能会影响到后续的操作，所以没别的办法，就一个操作一个操作的实现吧，我现在写的最复杂的业务用例脚本有将近1100多行的脚本……

作者: 戒情人 时间: 2009-10-22 13:51
标题: 回复 7# 的帖子
确实是你说的那么回事，我一直在做大型系统的测试，对此深有体会。每一个操作步骤每一个输入数据都会影响到后续的操作，所以手工测试比较灵活。根据你的经验，这么复杂的业务测试用例在实际工作中到底起了多的啊的作用？是不是非常有效？

作者: hsjzfling 时间: 2009-10-22 13:58
是否适合用QTP来实现自动化主要取决于2个方面，一个是对象识别，第二个是重复度。

LZ关心的业务复杂度应该是与自动化的覆盖率扯上关系，再复杂的业务，对QTP来说，也只是执行一组操作。如果对该业务的覆盖率要高一点，那就弄成数据驱动，不同的数据输入可能执行不同的业务操作。

大型的系统要特别注意业务的分割，尽可能的将业务操作分割成粒度较小的独立业务操作，将之封装成公用的Action或者Function，一个完整的业务操作就可以看成是这些一个个子操作的组合。

切忌对脚本期望过高，如果希望脚本能处理该业务能允许的所有操作，那性价比将会非常低，实际上对用户来说，他们常用到的业务功能可能只占到整个系统的20%。

作者: 戒情人 时间: 2009-10-22 14:11
标题: 谢谢大家的帮助
谢谢大家的帮助，我现在有了一点点认识，可是对这个问题理解的还不是那么透彻。

作者: weinicm 时间: 2009-10-22 14:27
我认为如何颗粒化我们的业务流程这才是使用QTP测试的精髓，使用QTP测试，不再于你写出了多么复杂的脚本，而在于对软件的分割，不只是在物理上的分割，也包括业务流程上的分割。过长的脚本，产生的结果只有一个，业务流程一但稍有改变，也许只是顺序上的稍有不同，你就得过重新写脚本。

作者: 戒情人 时间: 2009-10-22 14:55
大家指点的都非常好，欢迎大家继续来指导，非常感谢大家

作者: 戒情人 时间: 2009-10-23 11:08
欢迎大家继续讨论

作者: 戒情人 时间: 2009-10-26 14:11
欢迎大家继续讨论

作者: lyscser 时间: 2009-10-26 21:01
不才以为，也只有大型的系统才适合做自动化，因为小规模的自动化成本很难收回来，不系统化，规划的成本太高

作者: intothehit 时间: 2009-10-27 16:42
看来楼主的功力尚浅，做了很长时间自动化测试都没搞清楚自动化测试是怎么回事

作者: 戒情人 时间: 2009-10-27 17:09
标题: 回复 16# 的帖子
这位朋友看来你很在行，给大家讲讲怎么样？

作者: intothehit 时间: 2009-10-27 17:24
其实就一句话，你做的是测试，不是开发

作者: lantianwei 时间: 2009-10-27 18:04

原帖由 lyscser 于 2009-10-26 21:01 发表
不才以为，也只有大型的系统才适合做自动化，因为小规模的自动化成本很难收回来，不系统化，规划的成本太高

相当有才阿！

作者: june.diny 时间: 2009-10-27 18:39
9#，11# 都是高人啊，学习了〉。。。

作者: yangtesting 时间: 2009-10-28 11:54
写的在多些 ,越看越糊涂

作者: linhd030 时间: 2009-10-29 10:29
9楼兄弟写的很好！

我做的也是一个大型系统

负责回归测试，保证各个不同流程的通畅及数据的正确

可以根据系统的实际情况将其切割成几个模块，各个模块之间组合起来可以完成一条完整的流程，然后可以根据实际情况配置驱动表设计不同的案例，覆盖不同的需求。这里涉及到框架知识，相信玩转QTP的人大都懂一点框架。

作者: sdm_0915 时间: 2009-10-29 11:23
基本的增、删、改、查等操作用适合自动化测试，投入产出比高，复杂业务逻辑适合用手工测试，整个测试中自动化部分能占50%已经很高了。
自动化适合回归测试，而回归测试中经常出问题的功能往往是基本的增删改操作，复杂业务逻辑一般只要曾经测试过，再次出错相同错误的概率会比较小。

作者: 戒情人 时间: 2009-10-29 11:29
真的谢谢给位了。各位都是高人，各位的指点我真是受用无穷啊。看来自动化的路很长，我才刚刚上路。

作者: aishifu1 时间: 2009-10-29 12:10
回归到LZ的问题
为什么觉得复杂的流程适合做手工测试呢？
难道是复杂的业务用手工测试可以随心所欲的去测。
在复杂的业务去测试它的时候，首先将他分解成多个案例，或者多条业务流，假如需要把这些案例和业务流记录下来，这个工作相对较繁琐。更何况需要将他录制成脚本。但是狠下心去实现它的时候。势必为这部分的功能的测试带来比较好的完整性和继承性。
用手工测试的方式去测，这些案例存放在测试人员的大脑里面，想到那测到那。所以看上去测试跟轻松一下。但是这个完全依靠人的自觉性，根据人的惰性，1次2次是可以的。多次是肯定会有遗漏的。
所以自动化测试应该是不分复杂业务或者简单业务。

作者: meteor_li 时间: 2009-10-29 12:20
学习了

作者: 戒情人 时间: 2009-10-29 12:39
标题: 回复 25# 的帖子
谢谢你的指点。复杂的业务测试起来很麻烦，需要关注很多环节的相应变化，有时候一个数据或者业务状态有问题，可能导致业务流程进行不下去，需要做一些修改步骤，以使测试继续下去，所以手工测试相对的说灵活一下，因为我们一直在关注各种情况。不过手工测试真的很费力，我以前都是先写一个文档，写上那些地方需要测试，那些状态变化和数据变化需要关注，然后就按着这个文档去测试。所以每次手工测试也不会遗漏什么。但是做过大型系统的朋友应该有体会，把一个完整的业务流程测试完整真的既费时间又费脑力。所以我才在这里请教大家。

作者: blueguitar 时间: 2009-10-29 13:15
参照一下业务流程式样书吧，一般大型业务系统开发前因该设计好了业务流程图的。还有就是自己对业务知识的了解了，这个很重要。
其实你在实现自动化测试时，已经做了一次或多次人工测试了。所以就要看你导入自动化测试的目的是什么，是用来实现单体自动化还是做回归测试。
还有一个好的自动化框架能提高不少效率。

作者: black_tulip 时间: 2009-10-29 13:52
赞同23楼。

作者: unisoft 时间: 2009-10-30 17:15
标题: 大型复杂业务系统尤其适合做自动化测试
为什么说适合呢？
是否做自动化测试是有两个因素决定的，一个是投入的成本，另外一个就是执行的次数。对于大型复杂系统来讲，测试的次数肯定是要多次重复测试的；那么从投入的成本方面去考虑，因为业务复杂，每次准备初始化数据、理清业务逻辑、然后比对结果，尤其是互相干扰的业务影响；测试一遍需要理一遍的；那么如果自动化测试的话，实际上只需要理一遍就行了，QC中的组件化管理、对象管理、公用类等都对自动化提供了很好的支持，还有数据库检查点的应用，可以有效解决比对动态数据的问题。

那么实施自动化测试的难点在哪里呢？就是脚本的重复使用，决定脚本能否重复使用的因素是初始的数据环境。那么在自动化测试规划时，应该充分考虑数据的准备以及测试之后的回滚问题。如果把复杂业务的一个流程作为一段可回滚的单元的话，数据的初始化以及回滚（清除）还是容易做到的。这个难点一解决，自动化测试自然不成问题。

作者: garyyes 时间: 2009-11-3 15:08
标题: 回复 1# 的帖子
自动化测试被称为测试中的软件开发！这说明什么？说明自动化测试并不是简单的录制、回放那么简单的。而是需要精通编程、有众多项目经验积累的。对测试人员的要求很高。
自动化测试要收回成本，就与应用系统本身的成熟度、稳定性、生命周期等有关系，与是否大型系统关系不大。
但自动化测试是一种风险较大的测试类型，没有经验丰富的测试人员主导的话，通常结果往往是投入了一堆人做事，出来的东西却无用处，所以项目前期的评估、计划十分重要。
我这几年来做的都是大型系统的自动化测试，有：银行的核心业务系统、保险系统、移动BOSS系统等等。面对的问题，主要考虑的问题是：脚本的健壮性，对象的可维护性和重用性，业务模块的可重用性，测试数据如何复用、如何与业务模块结合，自动生成可读性更强的测试报告，完善的错误处理机制来保证全部脚本可在无人看守情况下执行完毕。

作者: garyyes 时间: 2009-11-3 15:14
标题: 回复 30# 的帖子
虽然我已经用了4年QC和QTP了，已获得QC和QTP的认证。
但项目实践告诉我，QC和QTP并不适合集成使用。

作者: garyyes 时间: 2009-11-3 15:20
标题: 回复 25# 的帖子
单单从理论来说，复杂的业务的确是比较适合手工测试、简单的业务比较适合自动化测试。
而且，也并不是所有的业务都能通过自动化来测试的。
因此，在实际项目中，肯定是要手工测试和自动化测试相结合。

作者: wugecat 时间: 2009-11-4 09:54
不管是复杂的业务流程测试，和简单的单点测试，前提都要编写好测试用例，也就是写成文档的那种，所以我认为没有什么适合不适合的，只要你用例覆盖全面了，都是可行的，自动化工具不过是实现这些用例而已。。。。还有就是产品相对稳定，决定了脚本的可重复执行的次数，减少测试成本。

作者: chendianxiao 时间: 2010-1-12 01:16
学习。同意公共的方法，这样的话，出错几率会小很多，修改维护都相对简单。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)