2013年度持续集成实践小结[1] ?UI自动化

　　背景介绍
　　按照组织上的安排，咱游击到了S产品（一个快速成长中的Web产品）开搞持续集成。
　　考虑到S产品核心业务单一明确，前端功能简单，业务逻辑主要在后端的特点，制定了持续集成的实施策略：
　　UI自动化为辅，用例少一点，精一点，降低维护成本，用例设计以冒烟和页面跳转，走通业务流程为主，目的是保障一个高可测性的测试环境；
　　单元测试重点跟进，自顶向下逐步覆盖各层接口，多覆盖各种分支路径，与UI自动化形成互补。
　　这里有个小插曲，我和S产品的测试负责人关于UI自动化用例的粒度和覆盖度有一些歧义，测试负责人坚持UI自动化要尽量覆盖大大小小各种流程与细节，接近于手工测试。后，咱还是坚持了己见
　　虽然，实施策略中设计了以单元测试（这里必须澄清一下，此处的单元测试实为集成测试/接口测试，没有完善的mock，仍有一些外部依赖；但是考虑到使用了JUnit/TestNg，一般也笼统地称之为单元测试了）为主，后续工作中确实也在这方面寄予厚望，投入较多，但由于种种原因，颇有鸡肋之感，此处暂时按下不表。
　　框架选择
　　网易杭州研究院开源的，简单易用的，结实耐操的Dagger框架
　　用例建模
　　考虑到UI自动化在S产品中的预定角色，我们将用例分成三大类：
　　UserStory，产品的核心业务流程，一个用例包括一系列步骤，模拟用户在S产品网站的真实运动；这些用例如果失败将明显干扰QA正常测试，一旦上线，将是严重故障；
　　Topic，包括一些冗长的特定业务（例如，下图所示的Topic 1：团购超市卡），以及对UI自动化所依赖的外部环境的检测（例如，Topic 2：与供应商保持联系）；
　　BugCover，出现过线上Bug的功能点补充用例。