测试
借由运行被测试程式的功能，去检查程式里面的代码是否错误
这里追求被测程式的所有代码行都被测试功能所触及得到，即追求”测试覆盖率“
测试的分类
我们是以开发的身份去看待测试的，测试是一个非常繁杂的概念，根据不同的分类规则可以有很多种概念名词出现=>听得最多的就是黑盒测试，白盒测试
作为开发，主要是关注的是“按流程分类”的单元测试，其他心之所动，就随风而去吧。
测试按流程阶段，可以分为单元测试，集成测试，系统测试，验收测试，回归测试。它们有先后顺序
单元测试
验证各个组件的功能行为，通常是类别和功能级别。（测试对象是一般为类，方法，接口这样的小单元），单元测试一般由开发人员编写。
注意：编写时要尽可能保证测试用例相互独立（测试用例中不能直接调用其他类的方法，而应在测试用例中重写模拟方法）
单元测试的好处与不足？
好处：1.以最小代价发现错误纠正错误
2.单元测试存在的意义就是，可以让我放心的重构代码，可以在重构代码的时候省下测试重构的代码能否正确运行的时间。
不足：1、不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误；
2、每行代码需要3~5行代码进行单元测试，存在投入与产出的平衡。
测试覆盖
通过测试代码，尽可能地把所有业务代码都执行一遍
通常使用测试覆盖率来检验单元测试质量的好坏（一般公司都要要求95%以上）。相比凭空想象单元测试的有效性和代码的好坏，这会更加有效。
怎样获得测试覆盖率？
1.函数覆盖
指这个函数是否被测试代码调用了，这是最基本的测试要求
assertEquals(2, foo(2, 2)) #对函数 foo 要做到覆盖，只需assert调用一下
2.语句覆盖（行覆盖）
指的是某一行代码是否被测试覆盖了
同样的代码要达到语句覆盖也只需要一个测试就够了，如 assertEquals(2, foo(2, 2))。
但是，如果把测试换成 assertEquals(0, foo(2, -1))，那就无法达到所有行覆盖的效果了。通常这种情况是由于一些分支语句导致的
3.决策覆盖
指的是某一个逻辑分支是否被测试覆盖
和语句覆盖一样，常常没有达到所有条件，要达到所有的决策覆盖（即那个 if 语句为真和假的情况至少出现一次），我们需要至少两个测试，如 assertEquals(2, foo(2, 2)) 和 assertEquals(0, foo(-1, 2))
4.条件覆盖
指的是分支中的每个条件（即与，或，非逻辑运算中的每一个条件判断）是否被测试覆盖了
之前的代码要达到全部的条件覆盖（也就是 x>0 和 y>0 这两个条件为真和假的情况均至少出现一次）需要更多的测试，如 assertEquals(2, foo(2, 2))，assertEquals(2, foo(2, -1)) 和 assertEquals(2, foo(-1, -1))，如果有一个条件分支没有被覆盖（比如缺少测试 assertEquals(2, foo(-1, -1))），那么大家应该想想“那个条件判断是否还需要呢？
集成测试
验证组件分组在一起使用时的工作方式。集成测试了解组件之间所需的交互，但不一定了解每个组件的内部操作。它们可能涵盖整个网站的简单组件分组。
集成测试是将单独的模块组合成一个整体进行测试，它在单元测试之后进行。集成测试的例子有：
- 使用 Selenium 测试应用是否能在浏览器中正确运行
- 与第三方 API 进行真实测试
- 与 requestb.in 或 httpbin 交互来确认出站请求的有效性
- 使用 runscope.com 来确保 API 能正常运行
集成测试的缺点：
- 设置集成测试要花很多时间
- 运行速度非常慢。因此它是对整个系统进行测试
- 有错误抛出时，很难定位。例如，一个只对某类浏览器有影响的错误可能是由数据库层的 Unicode 转换引起的
- 相比单元测试更脆弱。某个组件中的一个小修改都可能会破坏它。
系统测试
将经过集成测试的软件，作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境下进行一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。
集成测试和系统测试之间的比较：
1、测试内容：集成测试是测试各个单元模块之间的接口，系统测试是测试整个系统的功能和性能；
2、测试角度：集成测试偏重于技术的角度进行测试，系统测试是偏重于业务的角度进行测试。
例如：商品模块测试主要测试商品的增删改查四个接口。
商城系统主要是测试，当购买一件商品时，主要测试“商品模块=>购物车模块=>订单模块=>付款模块”协同功能
验收测试
技术方面没问题之后，验证是否满足用户/客户的需求
也称为交付测试，是针对用户需求、业务流程进行的正式的测试，以确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。
验收测试包括alpha测试和beta测试，alpha测试是由开发者进行的软件测试，beta测试是由用户在脱离开发环境下进行的软件测试。
回归测试
回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。
这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。
扩展：持续集成、持续交付和持续
持续集成
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成
集成，就是在一起：
代码commit是集成（代码在一起），
编译是集成（逻辑在一起）；
部署是集成（部署包跟环境在一起），
测试是集成（功能在一起），
灰度是集成（系统在一起）
不断的做集成和集成结果的修正，就是持续集成；
持续集成的流程
使用持续集成时典型的开发流程：
- 开发人员编写代码，在本地运行测试，再将代码提交到代码库。
- 代码库通知自动化工具有关代码已提交待集成的信息。
- 自动化工具将代码集成到项目中，并构建出一个新版本。构建过程中有任何错误，都将拒绝该次提交。
- 自动化工具在新构建版本上运行开发人员写的测试。测试过程中有任何错误，都将拒绝该次提交。
- 开发人员将收到成功或失败的详细信息。基于这些报告，可以进行相应修改。如果没有失败，表示本次集成成功。
具体来说，根据持续集成的设计，代码从提交到生产，整个过程有以下几步。
1.提交
流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。
2.测试
代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。
测试的种类：
- 单元测试：针对函数或模块的测试；
- 集成测试：针对整体产品的某个功能的测试，又称功能测试；
- 端对端测试：从用户界面直达数据库的全链路测试。
第一轮至少要跑单元测试
3.构建
通过第一轮测试，代码就可以合并进主干，就算可以交付了。
交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。
常用的构建工具：
其中Jenkins和Strider是开源软件，Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。
4.第二轮测试
构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。
第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。
需要强调的是，新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。
5.部署
通过了第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（现在是可以使用docker容器技术，打包成镜像）存档，发到生产服务器。
生产服务器将从docker-registry 拉取镜像进行部署
注意：
- 当开始更改代码时，开发人员会从代码库（如 SVN、Git 等）获取当前代码库的副本。
- 当其他开发人员将更改的代码提交到代码库时，此副本将逐渐停止反映代码库中的代码。代码分支保持检出的时间越长，当开发人员分支重新集成到主线时，多个集成冲突和故障的风险就越大。
- 当开发人员向代码库提交代码时，他们必须首先更新他们的代码，以反映代码库中的最新更改。
- 当存储库与开发人员的副本不同，他们必须要花时间来先处理冲突。
持续的好处主要有两个：
（1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
（2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续交付
持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的
例如：每天将当天打包好的程序部署到测试环境上。也就是说，一个码农晚上 10 点之前提交了代码，那他第二天就可以在测试环境上看到自己新提交的代码的效果了。
持续部署
持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。持续部署的前提是能自动化完成测试、构建、部署等步骤
例如：每一个月要在生产环境上部署一个稳定的发布版本。