查看完整版本: 阿里巴巴质量保证平台整合趋势

liangjz 2008-6-20 20:40

阿里巴巴质量保证平台整合趋势

当下阿里巴巴质量保证部门采用主要的平台、软件、工具有:


1) 项目管理工具: IBM  rpm 。系统架构: jboss4.2 + oracle9 + redhat 3.8 。

缺点:由于IBM SQL 加密以及数据库表结构未提供,经过几次系统调优,操作响应速度依然不尽如人意。
       目前所需要的部分报表是不满足的,需要导入到数据仓库平台分析。

  初步评估Microsoft share point。接触HP ppm(能够和quanlity center 、Microsoft project很好集成)。

   国内华为花费重点购买rpm以及昂贵的咨询费让IBM 一起提升软件开发规范度。

2) 需求管理工具
   
   需求部门采用confluence。系统架构: linux。

   用例颗粒度尚未符合软件工程的Use case,细致程度待提升。

   目前部分测试报告、测试文档也放在confluence。

   confluence用 wiki风格。其版本管理能力、交流能力稍弱。comment具有类似回帖功能。

3) 测试用例与缺陷管理

    采用quality center。 系统架构: jboss +IIS + sql server express+ windows 2003 server
    QA 经常使用的模块:测试用例分析与设计、缺陷管理、后台备份恢复等

    需求管理、dashboard报表系统未充分使用,另外有些团队测试实验室利用率稍低。
    由于web项目频繁变更,报表模板复用率偏低,故报表系统能力未充分发挥。
     
    主要缺点:每个全功能缺陷连接license在3-5万。

4) 测试部门文档管理

    采用svn。系统架构: apache + redhat linux
     
    缺点:全文检索能力弱。可以结合google 本地搜索功能或者MS的搜索功能
   
5) 内部技术论坛
   
   自主研发的论坛opentech。 系统架构: java + webx+ linux 。

   我个人认为还是相当不错的,功能齐全。有论坛、知识库,支持帖子搜索。且有高质量的文档。

   缺点:QA评价是有点阳春白雪:)  ,我看来缺点就是外部合作伙伴由于信任证书无法登录。

6) 即时通信
  
   采用阿里巴巴自主研发的贸易通。系统架构:c++ + linux。
   平常各个测试组建立群,可以在群上迅速交流。

   缺点:新来的员工无法看到先行者的一些讨论、分享。

7) 数据仓库平台
  
   MicroStrategy之上二次开发。后端Oracle。


从上面看,信息分散到不同的平台中,为了进一步提升使用效能,整合平台工具需求呼之欲出。
主线大致有几点:

1) 项目管理->需求分析->测试分析与用例设计->BUG 管理->报表、统计分析,一个环状的闭环系统。
  
   由于平台采用多家产品,整合难度提高。仅仅从数据层面流动意义不大。

希望上述多个环节能穿接起来,形成一个宏观层次提供报表、微观层次给测试工程师工作的平台

2) 需求分析->测试分析与用例设计->BUG 管理->源代码,形成一个需求和源代码的映射关系,做到需求和代码的有效变更跟踪

  sina 采用开源工具做。

3) 测试文档、交流、搜索功能一体化

   主要针对文档放在SVN,项目计划文档放Confluence,交流在贸易通上集散。
   
   希望能做到集文档、交流、全文检索功能于一身。这个过于个性化的需求,暂时没有找到开源工具解决。

   光针对全文检索需求,可以采用自主研发的isearch3.0或者开源lucense。带附件的帖子不能简单做搜索。

4) 其他
   
   针对项目管理平台RPM,改善成性能更好 、数据纬度更丰富、数据流/接口清晰的平台

...

   每一个需求真正融汇贯通,实现成本相当不菲。

echo5410 2008-7-7 10:45

学习下

liangjz 2008-7-7 21:49

别的公司的朋友没有遇上这种整合需求么?

bzcyer 2008-7-8 09:06

传说中,整个部门就1个测试兼QA兼配置的人飘过。。
这类高级的工作暂时做不了。

bzcyer 2008-7-8 09:19

1.需求管理、测试用例管理:以前用过段时间TestLink,输入需求规约,系统内自动导成测试用例。后来闪人了,在新单位没有用这类工具。不过现在感觉也不是很合适,软件需求到测试用例,中间应该还有一层测试需求,但TestLink直接去掉了,是软件需求直接到测试用例。

2.缺陷管理。原先有个项目组是用Bugfree,最后在我的蛊惑下,部门换用了Mantis,曾经Mantis用了很长时间,特别习惯。不习惯Bugfree过于开放的权限。

3.配置管理。大概花了2个礼拜时间用svn把部门的配置库建了起来,开始最痛苦的是svn的使用,以前只是简单的接触。但到后面痛苦的是领导的想法,对库及目录权限的分配完全是自己在瞎编,最后领导说这部合适,那不合适,配置文件写来写去一头恼火。

3.内部沟通。
公司给每个人都申请了MSN,但MSN的性能有些bug,有时候稍微加几个人一起会话,MSN就挂掉。速度也慢的有一拼,传文件也不是很稳定。不过公司没有封QQ,熟悉的同事之间用QQ交流更加方便。
Email,公司应该没有自己的邮件服务器,速度非常慢,所以Mantis那边邮件提醒都给关掉了。在原先单位每天Email都非常多,某次老板发神经,让配置把Mantis邮件提醒全开了,所有人,在Bug所有状态变化都收一份Email,结果每天几百封的来。

另外,公司自己架了wiki,技术部,市场部和产品部都参与进来,这个还是非常好玩的。

bzcyer 2008-7-8 09:20

现在还是在比较原始的状态,没办法,公司对测试根本不投入资源。

mianbaoshu 2008-9-9 10:06

个人觉得每个公司的情况不太一样,公司对测试的重视程度也不一样,但是很多好的想法在现实工作中其实很难开展,因为你要改变原来的模式,会有很多人抵触,也要花费一定的代价,在还没有启用的时候,没人保证百分百会有好的效果。

archonwang 2008-9-9 10:35

采用什么工具、平台不是重点,思想才是重点,执行是前提,流程规范、制度约束与考核是实现目标、促进执行的重要保障。

任何质量保证平台,无论整合与否,其最终目的是为了提高产品品质,促进生产力。如果当下的方法可以保障这些,即使平台不整合也没关系。何况,这种投入的价值不菲,考虑成本与风险的估值,认为也是一个必要的过程。
页: [1]
查看完整版本: 阿里巴巴质量保证平台整合趋势