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

liangjz

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


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

学习下

liangjz

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

bzcyer

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

bzcyer

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

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

mianbaoshu

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

archonwang

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

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