如何针对这样的系统进行自动化测试设计？（08-11-24）（获奖名单已公布）

默默巫

客户化很多的大型系统，是否可以进行自动化测试？如果可以，如何进行自动化测试的设计？
比如一个报销系统，含有若干个客户，虽然用一套core，但是每个客户都有从外观到细节不同的地方。这样的系统，是否可以进行自动化测试，如何针对这样的系统进行自动化测试设计？

感谢版主tengmy提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
二等奖	xazaj	300论坛积分	5#
二等奖	1316016	100论坛积分	22#
三等奖	liuqixun	100论坛积分	16#

阿七

人好少哦...

1316016

我觉得这个问题从字面上看，有点牵强，楼主是否可以补充些information，

针对这个问题，我想问的是为什么不能自动化 赫赫

    首先，自动化目的不是要取代所有的手动测试，它只是手动的一个补充，从这个角度看，必然可以用自动化。
    其次，针对客户化很多的大系统，同一份core，并且针对不同的客户发布不同的版本，最流行的就是国际化等等了，这不仅可以自动化，而且是自动化的很好Case。
    再次，就是如何设计自动化了，我想，从以下几个方面可以考虑：
       1. 大系统用的人也比较多，肯定是要验证性能
       2. 客户多，发布的版本很频繁，可以针对基本功能做冒烟测试的自动脚本
       3.发给不同客户的版本有些许变化，可以对共同的部分功能开发自动化
       4. 针对客户各种稀奇古怪的操作，我们需要对每一个功能进行地毯式的测试，如：查询功能，需要对查询项中的各个栏位遍历查询，验证结果，这往往是手动无法实现的（手动测试只是抽几个重点的栏位验证，很容易有遗漏）
     暂时想的就这么多了，希望楼主再给点info，脑力激荡下，看还有没有其他的方面。

weever

既然有core，那肯定有共同的地方，如果没有公用的模块，那就是几套不同的系统了。
所以，可以对那些公用的模块作自动化，比如内部接口的测试，抛开界面因素，只保证逻辑上的正确性。
对于其他不同的模块，说实话我没啥太好的办法，要不要搞公用的自动化测试还是要看代价多大，如果异常麻烦，且后期可见改动会比较大，那还不如单独各做一套算了。

coffeg

没看太明白，是从界面到各系统内部，还有各系统之间的协议都自动化测试，还是怎么着？具体问题得具体分析中，太抽象没法说能还是不能自动化测试，还是部分自动化部分手工比较科学。

xiaocao521

我想可以进行自动化测试,客户需要的个性化虽然不一定都一样,但是他所设定的里面细节或者界面的模块(我暂时这样称呼)都是程序中存在的.
只是这样的模块,一类有很多个.用户进行个性化设计,只不过是对这些模块进行排列组合而已,实质都是一样的.
就拿中国地图来说吧,上面有30多个省,你要从一个省到另一个省,可以有很多不同的路线,这就有点像客户的个性化选择,所以,你只要保证这30多个省中的任意两省能走通就OK.

同一类模块里面的代码设计大都类似,so..写好每一类的测试脚本,然后将不同类的测试脚本排列组合一下,看能不能从始点跑到终点..如果能,那么OK,如果不能,那就看哪个模块发生问题了..
额,我做开发,测试我是外行,不知道这样想对不对..不过现在有点想去做测试,发现也是件挺有意思的工作.

AwL_1124

期待高手 解答·

velata

最近项目组开始做自动化测试，有空再来回答

liuqixun

如果是有个性化需求，我想重点可能要放在集成测试。
在内核不变的情况下，只是外观和细节不同的话，针对用户个性化需求测试也应该只是在产品的系统测试后期和验收测试时期做，并不影响系统的整体功能的实现与测试。
所以我认为并不会影响系统的自动化测试，就像很多公司在做产品时，同一个产品面对了大量的客户，但并不影响自动化测试的进行。

发表一点个人意见，至于怎么做，等待高人。。

[ 本帖最后由 liuqixun 于 2008-11-25 17:29 编辑 ]

wy51testing

自动化测试接触的少，期待指导

wzb521

共性与个性的问题
自动化显著的作用是迭代，当然，你不能拿产品时期的自动化代码用到项目里，这有本质的差别，要考虑移植
当然，如果你说客户在3月的需求和4月的需求截然不同，那就是另外的问题了

wzb521

那我在下面点火，准备烤……

gudupiao213

占位，期待高手指点···

啊乖

没事看看。。。。

xumeiwen

我也很想知道什么样的系统可以进行自动测试，换句话说，就是自动化测试的适用范围。另外由于我对自动化测试的了解很少很少，很想知道一个系统在自动化测试时，画面测试也可以自动化吗？哪些地方需要自动化测试？

一一

最近也正在思考这个问题
做了一个人事系统，有相关的员工管理，考勤管理，培训管理，招聘管理，工资管理等将近20个模块
核心不变，但是每个客户会自定义流程，或者根据要求再进行二次开发，为了保证质量，如何有效的做自动化测试？
最近我们讨论要采用fitness做大规模的测试

xiao*

可以实现，没有任何问题！

liao11511

占个坑

尛蟲蟲

占茅坑……

xazaj

此文同时发布于：http://www.zhuaijun.cn/archives/65
欢迎交流。。
人之间的不同会产生矛盾，国家之间的不同会产生战争，思想之间的不同会产生知识。
================================================================================================
一、讨论一下这个报销系统自动化的目的

在讨论是否能做自动化测试之前我们应该先考虑自己的系统做自动化测试的目的，我觉得自动化测试的目的可以完完全全的定位在解放双手直立行走，当然其他的目的也许有很多很多，不过我们怀着这个朴素的目的来讨论一下本次的话题。
根据本次题目如下：

客户化很多的大型系统，是否可以进行自动化测试？如果可以，如何进行自动化测试的设计？
比如一个报销系统，含有若干个客户，虽然用一套core，但是每个客户都有从外观到细节不同的地方。这样的系统，是否可以进行自动化测试，如何针对这样的系统进行自动化测试设计？

经过字字推敲大概描述一下这个项目可能的情况：

某公司研发一个大型的报销系统，出售给公司甲，公司乙，公司丙，公司丁，公司点点点，但是这些公司提出一些客户化需求，这些客户化需求包括了UI和部分业务逻辑。
出题者没有给出详细信息，根据以上分析，类比一个比较通俗的案例来说明：
wordpress博客核心程序 相当于 大型报销系统core
使用wordpress搭建博客1：www.zhuaijun.cn 相当于 使用报销系统公司甲
使用wordpress搭建博客2：http://rdc.taobao.com/blog/qa/ 相当于 使用报销系统公司乙
使用wordpress搭建博客3：其他使用本核心的博客 相当于 其他使用系统客户

有了这个对应关系以下举例就脱离大型报销系统，直接用worpress举例，因为给出两个网址，大家可以用这两个网址体验一下外观和业务逻辑做了客户化以后自动化测试的侧重点。

经过以上分析，我们自问几个问题：
1、这样的系统我们为何要做自动化测试？因为每次系统的搭建都会修改程序，那就不能保证原来的稳定的系统在客户化之后仍然所有功能都可用，而具体客户化会影响到哪些功能是未知的，最保险的方式就是将所有的业务逻辑都验证一遍，因为我们的功能测试团队不能完成这个繁琐的工作，所以才要做自动化，这也就是我们使用自动化测试最朴素的目的。

2、我们对这样的系统做自动化测试应该侧重哪些方面？程序不但对业务逻辑做了客户化，还对外观UI做了客户化，并且每个客户搭建的程序外观都会不一样，比如博客1关注的是显示速度，所以外观不要求华丽，颜色清淡不需要图片、flash等元素，而博客2由于是公司博客所以可能需要加一些图片或者flash表现公司文化，如果自动化测试需要验证这些每个客户都有差异的界面UI，那这个目的就相当华丽了，并且这样的测试脚本没有重用性，个人觉得UI属于心理学范畴，勉强用工具实现了也是付出大于回报；而对于系统基本的功能（比如博客的发表文章功能，留言功能）所有的客户都是不会变的，这些才是做自动化的范围。

OK，确认了自动化的目的和范围，接着看一下我们该如何做。

二、自动化工具

我所接触到的功能测试工具只有QTP和RUBY，所以最好选择了（这话有点无奈），QPT感觉比较万能，就是价格贵，而RUBY免费脚本强大，不过是针对web程序并且要程序基于com的，简单的js弹窗也需要借用第三方工具，js驱动的页面它就更无能为力了。不过还好wordpress博客核心是完全支持用RUBY做自动化测试的。而大型报销系统估计需要购买QTP来做了，这样的话要估算成本了，高价购买的工具和高价聘请的自动化测试工程师是否能缩减软件维护成本，要请高层做好决策了，据说过高的期望是导致自动化测试失败的原因之一。所以工具的选择要兼顾价格和功能。

三、如何做自动化测试

本项目要做自动化测试我觉得最重要的测试测试粒度的选择，普通的项目可能会权衡一下粒度和项目进度的关系来决定，而本案例我觉得要做到粒度尽量的小，尽管工作量大但我们不得不这么做。

结合wordpress做自动化测试的目的，我们是为了在做了部分业务逻辑变动后验证其他业务逻辑仍然正常。博客三个基本功能：注册用户，发表文章，留言为例，如果功能稳定我们可以直接分成这三个功能来做自动化脚本，但是发表文章这个功能流程包括了写文章，文章审核两个功能，如果我们脚本将两个操作做成一个发表文章的脚本，哪天客户要求改变文章审核功能，那整个脚本就要重写了或者做大手术，如果我们在前期做脚本时，能足够的细，每次客户化时就可以根据客户化内容筛选脚本，将所有业务逻辑有所改动的脚本删除，对可运行脚本进行优化排序运行，一边进行程序的客户化，一边有针对性的补充脚本，或者客户化的功能直接手工测试。

测试脚本编写的阶段，脚本的维护和普通的自动化测试没有太大的区别，不在此多论。以上针对51testing每周一问答题，多谢指正。

[ 本帖最后由 xazaj 于 2008-11-29 01:09 编辑 ]