高度自动化(三)-发布可靠软件的系统方法一书

部署流水线

1. 什么是部署流水线

从版本控制库到用户手中这一过程中的自动化表现形式

2. 大多数来自测试和运维环境的场景

• 构建和运维人员一直在等待说明文档或缺陷修复；
• 测试人员等待好的版本构建出来；
• 新功能开发完成后，开发人员才收到缺陷报告；
• 开发快完成时，才发现档位的软件架构无法满足该系统的一些非功能需求

验收测试的好处：

3. 基本的部署流水线

根本目的： 尽快得到反馈

代码提交阶段的评估：

• 测试覆盖率（如果提交测试只覆盖了代码库的5%，那么这些测试发挥不了太大作用）；
• 重复代码的数量；
• 圈复杂度；
• 输入耦合度和输出耦合度；
• 编译警告的数量；
• 代码风格

        自动化验收测试

• 验证新的修改是否在现有功能中引入了回归缺陷
• 是识别候选发布版本过程中第二个重要的里程碑
• 真个团队都是验收测试的所有者。如果验收测试失败了，必须马上修复它。
• 验收测试的创建和维护成本非常高，验收测试也是回归测试。不要盲目把所有东西都自动化了

后续的测试阶段（自动化验收让测试人员有更多时间做高价值的活动）

• 手工测试（探索性，易用性和演示，兼容性，界面等）
• 非功能测试（容量，安全性）

4. 软件交付度量

• 全局度量指标： 缩短交付的周期时间

1） 找出约束的瓶颈。构建，测试，部署，发布流程中的瓶颈

2）自动化节省的时间

• 其他指标

自动化测试覆盖率

代码库的某些特征，比如重复代码量，圈复杂度，输入耦合度，输出耦合度，代码风格问题等；

缺陷的数量；

交付速度，即团队交付可工作，可测试并可以使用的代码的速率；

每天提交到版本控制库的次数；

每天构建的次数；

每天构建失败的次数；

每天构建所花的时间，包括自动化测试的时间

构建与部署的脚本化

• 使用同样的脚步向所有环境部署

• 测试管理

单元测试放在与包名对应的目录中（某个类的测试应该与该类放在同一个包中）；

其他测试（验收测试，组件测试等）放在test目录下

提交阶段

     可以参考：如果单元测试的通过率小于阈值，就判断为不通过

自动化测试金字塔

提交测试套件的原则

• 避免用户界面

1） 用户界面是用户最容易找到缺陷的地方

2）用户界面测试的困难：

涉及很多组件，花时间去准备各种各样的组件和数据，容易出问题；

用户界面是提供给用户手工操作的，而手工操作的速度和计算机操作的速度相比，慢很多

注意：如果可以避开上面的2种困难，也可以进行界面测试

• 单元测试中避免异步

• 使用mock技术

• 并行测试

selenium 

非功能测试

容量度量：

• 容量（真实的容量数据，用户数，行为模式）

• 吞吐量（一定时间内处理事务的数量，页面点击）
• 性能（处理单一事务花的时间，只需要O(1)的性能，就不要用一个O(n)的算法）
• 安全性（敏感数据，用户权限，多线程处理）
• 可配置性
• 可扩展性

服务器数，线程的增加，单个请求的响应时间和并发用户数的支持会如何变化

识别出系统代价最高的事务，并在系统中把它变成2，3倍的数量

• 持久性

长时间运行应用程序时，看性能变化，如内存泄漏或稳定性问题

• 负责测试

当系统负载增加到类似生产还大小或超过它时，系统的容量如何

自动化容量测试

目标

• 测试具体的现实场景
• 预先设定成功的门槛
• 尽可能让测试运行时间短一些
• 组合大规模的复杂场景，这样就可以模拟真实的用户使用模式
• 可重复的，既能串行执行，又能并行执行，以便可以做负载测试，又可以做持久性测试

容量测试的切入点

举例：一个人背X斤
负载测试：200斤情况下，是否能坚持5分钟。
压力测试：200,300,400...斤情况下，他的表现，什么时候失败，失败之后什么表现，重新扛200是否正常。
容量测试:在坚持5分钟的情况下，他一次最多能扛多少斤。

容量测试纳入测试流水线

探测内存泄漏

持久性测试

评估垃圾回收

其他

高质量的日志

数据库的脚本化管理

• 数据库数据的兼容性
• 代码回滚时，对新产生数据得劲兼容
• 数据库的备份，迁移
• 各个阶段的测试数据