实现快速可靠的自动化测试 - 《DevOps 实践指南》

让开发人员在日常工作中创建自动化测试套件

自动化单元测试

自动化验收测试

测试团队提供自动化测试套件

• 全面且可靠的自动化测试套件，用于验证可部署状态

• 一种在验证测试失败时，可以”停掉整条生产线”的文化

• 开发人员在主干上工作，并小批量提交变更，而不是在生命周期很长的特性分支上工作

自动化测试分类：

• 单元测试：确保代码按照开发人员的设计运行
• 验收测试：通过整体测试应用，确保各个魔能模块按照设计正常工作，而且没有引入回归错误
• 集成测试：保证应用能与生产环境中其他应用和服务正确地交互

自动化测试套件的一个设计目标：能尽早地在测试中发现错误，并且减少对手工测试的依赖

要确保自动化测试可靠，最有效的一个方法是通过测试驱动开发(Test-Driven Development TDD)和验收测试驱动开发(Acceptance Test-Driven Development ATDD)

通过执行自动化测试，所有测试人员(包括测试人员)得以去做那些不能被自动化的高价值活动，如探索性测试或优化测试流程本身

执行少量可靠的自动化测试，往往优于执行大量手动测试或不可靠的自动化测试，应该专注于将能验证业务目标的测试自动化，如果放弃某个测试之后，生产环境出现缺陷，那么应该讲这个测试重新加入手动测试套件，但最终还是应该将它自动化

应该从少量可靠的自动化测试开始，并随着时间的推移不断增加，这样一来，系统的保障级别随之提高，并能快速检测出所有让代码偏离可部署状态的变更

阅读的目的

• 增加资讯

• 增加理解力

  要能被启发，除了知道作者所说的话之外，还要明白他的意思，懂得他为什么会这么说

思考只是主动阅读的一部分。一个人还必须运用他的感觉和想象力，一个人必须观察，记忆，在看不到的地方运用想象力

阅读的层次

• 第一层次的阅读：基础阅读

  可以学习到阅读的基本艺术，接受基础的阅读训练，获得初步的阅读技巧

  “这个句子在说什么？”

• 第二层次的阅读：检视阅读

  必须在规定的时间内完成一项阅读的功课

  在一定时间之内，抓出一本书的重点

  略读/预读，检视阅读是系统化略读

  “这本书包含哪些部分”

• 第三种层次的阅读：分析阅读

  全盘的阅读、完整的阅读，或者说优质的阅读

  分析阅读用永远是一种专注的活动

  特别在追寻理解

• 第四种层次的阅读：主题阅读

  比较阅读

  能够架构出一个可能在哪一本书都没提出的主题分析

文化准则1： 我们只招成年人

• 只雇佣、奖励和容忍完全成熟的成年人

• 让员工加入到让他信任和钦佩的同事团队中

• 打造尽可能简洁的工作流程和强大的纪律文化

• 不要让规章和制度限制了高绩效者

文化准则2：要让每个人都理解公司业务

• 建立新员工大学，保持沟通的强节奏

• 双向沟通，为员工提供向所有管理者提问的机会

• 让每一位员工了解，他为客户带来的体验是如何直接影响公司利润的

• 如果只选择一门课程面向公司全员开授，请选择公司业务运作和客户服务的基础知识

• 最好的福利，是让员工有机会去更好地了解业务和客户

一个人要获得成功最重要的品质是什么?

从容

成功的最大障碍是什么？

把一切看得太重

如果要获得成功，天赋和努力哪个重要？

• 努力
• 性格

向世界学习还是质疑这个世界？

质疑世界

坚持到底还是懂得何时放弃？

懂得放弃

成功与快乐，哪个重要？

快乐

如果成功的代价是孤独，你会追求这样的成功吗？

不会，我不喜欢孤独

对于年轻人而言，事业为重还是爱情优先？

爱情

• 目标管理法基于两个原则：

  • 不要告诉下属具体怎么做，只要告诉他们你要什么，他们就会给你满意的结果
  • 用关键结果衡量工作绩效

• 转型是一件很正常的事情，就是在战略目标不变的情况下调整一些策略

• 换一个CEO的思维模式

  以前，在英特尔遇到一个不好定夺的决策，很多人都会提起这个故事，20世纪80年代，日本抢夺了存储器的市场，英特尔因此损失了很多钱，内部的争论不计其数，但对于英特尔到底应该怎么办一直没有定论，这可是直面生死的争论啊，有一天安迪.格鲁夫和戈登.摩尔商议此事，格鲁夫问摩尔：“如果我们被解雇了，董事会会重新找一个首席执行官，你觉得他会怎么做？”，摩尔毫不犹豫地回答：“他会让我放弃存储器”，格鲁夫对这个简短而明确的大难还是有些吃惊

• 一次说太多，就和什么都没说一样

关键内容汇总

人物关系图

三步工作法

• 第一工作法：关于从开发到运维再到客户的整个自左向右的工作流

为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作重心，并行不断为了整体目标进行优化，

必要的做法：

- 持续构建、集成以及部署

- 按需创建环境

- 严控半成品，以及构建起能够顺利变更的安全系统和组织

[TOC]

软件测试工程师的“三年之痒”

软件测试发展简史

1975年《软件数据选择的原理》：证明软件的工作是正确

1979年《软件测试艺术》：发现错误而执行的活动

1983年《软件测试完全指南》：测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量

2002年《系统的软件测试》：测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程

中国软件测试行业

• 软件测试整体起点较高

• 困境和迷局

  • 后备软件测试人员对软件测试不了解

  • 软件管理决策者对软件测试缺乏正确理解

  • 喜忧参半：软件测试外包

• 迷茫的软件测试工程师

Git分支管理实践

Git分支管理的引入其实在团队逐步扩大，开发特性逐步增多的情况下引入时，其优势才会突显，否则将会带来为谓管理开销。

不同的Git分支管理

Master单分支

当团队较小时，往往只需要单独的master分支，大家都在本地master分支上进行特性开发，完成后即可推送到远程分支，推送后触发CI构建，单元测试，集成测试等，通过后即可上线发布。

此时的迭代周期应该较短，发布频率会比较高，上线后发现的问题可以快速的通过新版本迭代进行修复，生产环境的bug fix和新功能可以同步进行。

但是随着业务的逐步扩张，业务复杂度开始增加，上线后出现的问题较多，同时迭代周期逐步被拉长的时候，就无法快速响应生产环境的bug fix。而实际情况下我们团队采用了局部包的方式为生产环境打补丁，但是在bug验证的过程中无法保证验证环境与生产环境一致，会引入一定的风险。