2011回顾之持续集成初步实践
2011回顾之接口性能测试
大概写下自己对持续集成的一些看法和做法：
持续集成初步实践
年初新到了一个部门，负责某个产品的测试工作，当时持续集成也是比较火的时候，不知道是啥样，理论看的太多了，来实践某个产品的持续集成测试吧。老大给了这个任务，我个人先分析了下该产品的特点等等，做了些规划和后续计划。
老大也找来自动化测试专家、接口测试专家一起来搞，争取把这个产品的持续集成做成佳实践。我其实真的不懂持续集成是啥，但是我有自己的目标，那是合理的划分功能模块，大化和优化的做页面自动化和接口自动化测试。
载体还是使用我喜欢的MM图（使用Freemind工具画出来的思维活动图），完成了合理分配和持续的测试脚本的开发。架构如下（由于涉及到产品业务逻辑，这里只是画出模板，不能贴上我负责产品的真实mm图）：
这么做的好处是：
1、该产品的手工测试用例、存在的自动化测试脚本或代码 一览无余，有了这个，一切都在你的掌控中
2、所有新增或修改的用例或脚本都可以在同一个地方表现出来，不需要去其他的地方进行同步更新
3、让你的老大很清楚你负责的产品的自动化测试情况、业务熟悉程度、测试脚本是否合理等
4、让所有新需求的自动化测试或手工测试能够快速响应，知道哪里已经有cover，哪里还存在风险
这么做的坏处是：
1、有时候维护也是需要一定的成本的
2、如果产品负责的话，该思维架构图很庞大，不利于查看方便
上面说到的是持续集成的准备工作，只要这些都确定下来了，你所做的脚本都做出来后，可以开始持续集成的初始化工作了。页面自动化脚本和接口测试代码可以在同一个测试平台进行回归和调试，随时check 脚本运行情况。daily bulid的check和跟踪会耗费大家的精力，但是会让大家对某些功能的代码更有信心。
个人认为持续集成的大好处是有新需求响应时，能充分利用自动化脚本的优势，快速进行探索式测试，反馈需求的质量，快速的发布新需求，那么对于新需求，较好的持续集成能达到什么样的效果呢，如下图：
（Automan脚本是页面自动化脚本；Hudson脚本是接口测试脚本；ET是探索式测试；日常环境是通常的测试环境；日常需求是较小的需求功能，开发时间在一周之内的）
当我们能快速响应这样的需求时，我们还怕什么呢。有人说持续集成的作用在敏捷项目中使用的多了，个人认为这个和敏捷项目并没有太大的粘性，迭代二利用迭代一的自动化脚本持续集成的优势，快速的测试迭代二的需求，并快速发布迭代二的功能需求。
我负责的产品能达到这样的效果，我的日常需求测试可以达到这样的效果，我持续的关注我的产品的持续集成的运行情况，我不担心该日常需求影响了其他的功能需求，如何将我们的功能需求和测试思路合理且有策略的分配在手工测试用例、页面自动化测试脚本、接口测试脚本中，是个较有难度的任务，这个需要对探索式测试、自动化测试框架或平台、业务逻辑复杂度、业务需求特征等有充分的了解，才可以较完美的产出该产品的思维架构图，才能更加的了解自己的产品、了解自己的测试框架或平台。
对于脚本多难维护的情况，后说下我师父侯风提出的持续集成不过夜机制，是说 每天的运行报告中Fail脚本当天解决，找到解决方案并当天处理。同样的问题不能在第二天的持续集成报告中出现，也是不过夜机制。I like it，尽管很难，对自动化脚本质量、测试环境、业务需求变化、快速响应能力都是个考验，也是个必须要面对且战胜的事情。
