根据当下在产品型测试实践梳理的几点想法：

　　一、人才

　　a、配管

　　懂常用持续集成服务器，如cruisecontrol/continuum， buildbot 等原理及安装配置。

　　另外，需要了解java 编译，c++ makefile，subversion等配置管理知识。

　　b、研发/QA：  合格的。 最最重要的是有良好的质量意识及实践能力。

　　c、主管/经理：

　　他们是有力后盾，当涉及资源及机制时，是一锤定音者。

　　二、技术

　　最核心的是良好的单元测试编码， 集成测试编码，系统测试编码， web ui层自动化等不同level的自动化能力。

　　为了确保单元测试代码有效性，可以考虑：

　　1） 对单元测试代码做code review

　　2） 研发交叉编写单元测试代码

　　3） QA参与单元测试设计 或者编写单元测试代码

　　研发编码水平，QA测试开发能力都应该在一个较高水位。

　　三、机制

　　实践中，这个也是影响面最大的， 没有好的机制粘合，要做好持续集成基本不现实。

　　在当下，我面临的问题：

　　1）源代码规范及makefile规范，  避免硬编码以满足buildbot需求

　　2）统一c++单元测试框架。

　　3）统一单元测试输出结果

　　4）单元测试代码编写方面做更多摸索（研发交叉编写单元测试？QA前期介入单元测试设计？）   涉及到资源计划

　　5）集成测试方面的探索， 减少外部依赖

　　6）对buildbot /continuum 结果的快速响应以及相关的约定 （ 进入集成测试后，build 失败次数〈n 以及每次build修复时间〈n小时）

　　7）研发提交QA的标准， 〉50%代码覆盖率应在持续集成后一直保持并且经过有效review

　　8）项目退出标准细化 （需要保证连续n天0个高优先级bug 并且持续集成连续成功n天以上）

　　9）……

　　四、设备

　　用钱能解决的问题最容易解决。^_^

　　当同时做持续集成时，需要确保编译，运行测试验证，发送报告时间不要太长。

　　（以上言论仅代表作者的个人观点，不代表51Testing观点）

版权声明：本文出自liangjz的51Testing软件测试博客：http://www.51testing.com/?13997

原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。