大型系统的业务流程、逻辑特别复杂的用例适合自动化吗？

戒情人

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

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

chendianxiao

学习。同意公共的方法，这样的话，出错几率会小很多，修改维护都相对简单。

wugecat

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

garyyes

单单从理论来说，复杂的业务的确是比较适合手工测试、简单的业务比较适合自动化测试。
而且，也并不是所有的业务都能通过自动化来测试的。
因此，在实际项目中，肯定是要手工测试和自动化测试相结合。

garyyes

虽然我已经用了4年QC和QTP了，已获得QC和QTP的认证。
但项目实践告诉我，QC和QTP并不适合集成使用。

garyyes

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

unisoft

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

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

black_tulip

赞同23楼。

blueguitar

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

戒情人

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

meteor_li

学习了

aishifu1

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

戒情人

真的谢谢给位了。各位都是高人，各位的指点我真是受用无穷啊。看来自动化的路很长，我才刚刚上路。

sdm_0915

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

linhd030

9楼兄弟写的很好！

我做的也是一个大型系统

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

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

yangtesting

写的在多些 ,越看越糊涂

june.diny

9#，11# 都是高人啊，学习了〉。。。

lantianwei

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

相当有才阿！

intothehit

其实就一句话，你做的是测试，不是开发

戒情人

这位朋友看来你很在行，给大家讲讲怎么样？