阿里云CAC_DevOps课程详细文字文档

考试说明和实操网址

考试环境说明：考试时候需要全程对着摄像头，脸部离开摄像头会出警告，会监测屏幕，不能切屏或弹窗【真假不知】；
考试说明：有这篇和下面链接中的这篇操作文档，这两篇文档中的内容用于考试的参考答案，足矣！

阿里云CAC_DevOps在线实验文档

说明

下面内容为购买阿里云CAC_DevOps考试后的视频内容，全部手敲为文字版本，作用是什么不许明说吧！
操作流程也有详细说明，也就是说，你阔以不用看视频，根据这个文档可以完成，实验，和通过该文档考试的所有题目！

课时一：课程总览

了解企业级大规模软件开发流程

掌握软件开发中各个环节包括：项目管理、需求分析、软件开发测试、devops持续集成、持续部署

掌握阿里云一站式研发效能平台云效（公有云版）基本功能

阿里云研发效能平台云效（公有云）功能

有三个模块：1、项目协作，2、代码托管，3、devops能力
企业级一站式研发协同平台，包含项目协作、代码托管、及DevOps全流程能力。

课时2：敏捷项目管理基础

项目管理和迭代开发方式

项目管理说明

• 项目的定义： 项目是一系列独特的、复杂的、相互关联的活动，这些活动有着一个明确明确目标或目的，并且必须在特定的时间和预算内依据规范完成。
• 项目管理（Project Management）：运用各种相关技能、方法与工具，为满足或超越项目有关各方对项目的要求与期望，所开展的各种计划、组织、领导、控制等方面的活动。

项目管理基础理论

• 项目的三角
  • 范围：定义了要求做什么，也规定了不能做什么
  • 时间：一个项目必须完成时间框架或者最后期限
  • 成本：可用于项目的费用
• 质量
  • 产品质量：项目的可交付成果质量
  • 过程质量：项目管理过程本身的质量
• 项目管理的目的是：
  在有限的资源投入条件下，在要求的时间内，实现既定的项目目标

迭代开发模式说明

• 迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
• 在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度的小项目，被称为一系列的迭代。
• 每一次迭代都包括了定义、需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前的启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作，再通过客户的反馈来细化需求，并开始新一轮的迭代。
• 迭代流程图如下：
  

Scrum方法 - 3 3 3 5

• 3个理论支柱
  • 高透明性（Transparency）
  • 检查（Inspection）
  • 适应（Adaptation）
• 3个角色
  • 产品负责人Product Owner
  • Scrum Master
  • 开发团队
• 3个工件
  • 产品代办列表
  • 迭代代办列表
  • 潜在可交付的产品增量
• 5个事件
  • 迭代
  • 迭代计划会议
  • 迭代评审会议
  • 迭代回顾会议
  • 每日立会
• Scrum方法框架图如下：
  
  框架图流程大致如下：
  The Agile：Scrum Framework at a glance 【敏捷：Scrum框架一览】
  Inputs from Executives,team,Stakeholders,Customers,Users 【高管、团队、利益相关者、客户、用户的意见 】
  由上诉所有人整理一份产品待办编号【Product Owner】，在这里面整理好需要办的事，也就是生成产品订单【Product Backlog】
  当通过上一步骤生成好待办事件以后，开一个迭代计划会议【Sprint Planning Meeting】，在该迭代会议中彰显出需要完成的事，也就是生成迭代代办列表；
  当通过上一步整理好待办列表以后，就知道了我们接下来要干什么，所以接下来进入迭代当中【task Breakout】，迭代其实是一个时间观念：
  我们通常认为：迭代时间一般为：1-6周，取决于公司内部对迭代自己的具体定义
  在迭代当中，会有每日立会，在每日立会中：团队成员会在15分钟时间内完成3个问题的回答：分别为：昨天做了什么，今天我要做什么，我在工作当中遇到了什么困难和障碍
  对于每日立会中遇到的问题都会由Scrum Master在线下找相应人员进行问题故障解决或排除
  当我们完成了1-6周的迭代周期以后，会产生一个潜在的可交付的产品增量【Finished Work】
  同时迭代完成以后会邀请客户，管理层，团队人员一起参加——迭代评审会议，在迭代评审会议中我们需要向客户展示我们完成的内容以及功能展示，同时如果客户给我们新内容的反馈，由产品负责人把客户的这些需求重新返回到产品待办列表排序和重新规划
  当迭代评审会议结束以后，内部会重新开一个回顾会议，在回顾会议当中，团队会重新回顾在整个迭代当中的工作过程，由此产生在迭代过程中我们觉得做得比较好的需要继续保持并产生一个【keep】，在本次迭代中认为不好活需要改进的，会产生一个【change】并做相应调整，还有认为需要尝试的好的办法或工具等，会产生一个【charts】
  当上述迭代完成以后，产品更新以后会进入下一个迭代【再次重复上述步骤】
  迭代周期一般为：1-6周

Scrum团队-紧密合作

PO产品负责人	Scrum Master	Dev Team开发团队
确定产品的功能，负责维护产品待办列表	保证团队资源完全可被利用并且全部是高产出的	在每个Sprint中将产品Backlog中的条目转化
决定产品的发布日期和发布内容	保证各个角色及职责的良好协作	交付潜在可交付的功能增量
为产品的投资回报率（ROI）负责	解决团队开发中的障碍	Scrum团队的规模控制在5-9人
根据市场价值确定功能优先级	作为团队和外部的接口，屏蔽外界对团队成员的干扰	Scrum团队是跨职能的团队
在每个Sprint开始前调整功能和调整功能优先级	保证开发过程按计划进行，组织每日站会，Sprint计划会议、Sprint评审会议和Sprint回顾会议
在Sprint结束时接受或拒绝接受开发团队的工作成果

团队共背业务目标，共背质量

KANBAN方法

• 看板： 一种可视化流程管理系统
• 三个原则：可视化，限制在制品，管理流动
• 五个核心事件：
  • 可视化工作（价值）流——如下图中的各个模块
  • 限制在制品数量 ——在工作流中本状态当中，每个工作下，它的本状态数量是有一个数量上限的，这个数量上限取决于团队能力
  • 度量和管理流动——当我们用看板方法的时候，要让其价值流动起来，让价值流动越快越好，流动是否顺畅用累计流量图衡量
  • 协同改进——当我们使用看板方法的时候，期待整个团队有协同改进 的机制，而不是当某个状态出现停滞的时候，只有当前负责人做扫清工作，希望由整个团队来突破某些瓶颈
  • 现实化流程规则——从下图中红色框中能表现出的规则中，我们可以设置，当上一个状态流转入到下一个时，我们需要设置哪些规则能满足该条件
    

风险管理

• 风险管理规划是指决定如何处理并进行项目的风险管理活动
• 四个阶段：
  • 1、风险识别
  • 2、风险分析 —— 对识别出来的风险进行评估，评估过程我们通常会用风险发生的概率以及风险后产生的影响来进行评估，当我们评估出风险的等级【高中低风险】，以及风险发生后对项目的影响
  • 3、风险应对计划——在风险发生前我们要有规避方案，当风险发生后，我们如何去减少风险造成的损失，也要有相应的方案
  • 4、风险监控和控制——在整个项目过程中，我们会对风险全程监控，监控过程当中，可能会出现新的风险，所以又会回到风险识别步骤，然后重复该流程【可能进入循环】
    
• 总结
  顺畅、高质量地交付有用的价值

课时3：云效敏捷项目管理

项目管理云效实操

• 在云效项目管理中，项目分为两类：
  • 第一类：标准的研发项目。
    项目团队在项目里一起协作，对需求进行分析、排期、迭代实现、测试和发布。
  • 第二类：业务空间。
    用来进行业务线划分，并管理各业务线的需求、文档和缺陷等。

项目类别	使用场景
研发项目	专项成立、有明确结束时间的项目。例如，双十一大促某专项项目：没有明确 结束时间，但研发团队比较固定，对某个产品或应用不断迭代实现功能、进行发布
业务空间	PD专用来管理产品或业务的需求池，用于进行业务划分的父子结构。例如，先在某个BU建立一个总的空间，然后按不同业务线划分子业务空间。

• 云效项目管理概述
  研发项目和业务空间在功能上没有差别，只是概念上的分离，且二者在默认启用的服务种类上有所区别。例如，创建业务空间时，默认启用的服务包括：需求、缺陷和图表；而研发项目还默认启用迭代、测试用例，应用等服务。但创建完毕后，业务空间和研发项目可以随意增减这些服务。
  

• 创建一个项目
  点击”新建项目“或+ 选择”新建项目“创建一个新的项目。
  你阔以根据自己的使用场景选择研发项目或业务空间。
  

• 项目搜索
  点击顶部“项目”导航，选择“项目列表”。页面展示用户收藏、参与的项目以及创建的项目集。此外还支持全站范围内搜索项目。
  

• 项目设置基本信息

  • 点击项目左侧导航栏“设置”进入项目基本信息页面。可填写所属项目集、项目计划起止时间、实际起止时间、健康度、进度和项目类别等信息。（如下图）
  • 角色权限
    1、项目归属信息：管理员，PM
    2、项目计划信息：管理员，PM
    

• 项目概况页

  • 服务
  • 项目公告
  • 项目设置
  • 里程碑
  • 风险汇总
  • 子项目
  • 成员管理
  • 项目动态
    

• 项目权限

• 权限类型

  • 管理权限
    • 项目中所有服务及数据的访问和操作权限（如创建编辑需求、人物、缺陷、创建编辑迭代，查看图表编辑图表等）
    • 项目相关信息的设置权限（如成员管理、配置需求末班工作流、编辑项目基本信息，结项或删除项目等）
  • 非管理权限
    • 项目中所有服务及数据的访问和操作权限（如创建编辑需求、人物、缺陷、创建编辑迭代、查看图表编辑图表等）

• 项目成员权限

  • 管理员：默认拥有管理权限
  • PM：默认拥有管理权限
  • 其他角色：默认拥有非管理权限，可在项目中修改

• 非项目成员权限

  • 公开项目：非项目成员默认拥有非管理权限，可访问项目，以及查看和操作所有数据（文档除外）
  • 私有项目：非项目成员无法访问项目，也无法查看操作任何数据

项目集管理云效实操

• 项目管理协会（PMI）把项目集定义为：经过协调管理以便获取单独管理这些项目适无法取得的收益和控制的一组相关联的项目。

• 云效的项目集管理功能可以让您轻松管理和监控多项目的进展和风险，更好地促进项目间协作。
  

• 项目集设置基本信息
  点击项目左侧导航栏“设置”进入项目集基本信息页面，咳填写所属项目集、关联项目（集——、项目计划起止时间、实际起止时间、健康度和进度等信息。
  

• 项目集概况页

  • 项目集可对项目的成员、服务、标签、里程碑等进行设置。
  • 项目集关联项目的进度、健康度等信息更新后，会在关联项目列表中显示。
    • 服务
    • 项目设置
    • 里程碑计划
    • 风险汇总
    • 关联项目
    • 项目动态
      

• 管理关联项目

  • 通过条目化项目列表管理，可以方便查看项目信息，了解项目进度、健康度和风险等信息。另外，通过标签功能，可以方便对项目进行任意维度的分组管理，以快速管理重点关注项目。
  • 在项目集概况页可直接关联项目。点击“查看全部“后进入关联项目列表页，可设置显示列、分组和排序、过滤、还可以给项目打标签。
    

风险管理云效实操

• 创建风险
  • 1、由项目左侧导航栏“风险”进入“风险”管理页面（若导航栏中无”风险“，可在”设置》服务“或顶部导航栏”服务“中启用）。
  • 2、新建风险
    • 点击“新建风险”，“保存”即可。
    • 风险列表支持两种试图方式：列表和树状列表（与需求管理的列表、树状试图相似）。
    • 风险分为高、中、低三个等级
      
• 风险详情
  • 在风险列表点击“标题”，右侧显示风险详情，点击“最大化”可进入全屏的详情页面。
  • 左侧主体为描述区，可编辑风险的描述内容。
  • 可新建子任务、设置关联关系、添加评论、查看描述的历史修订、查看操作记录。
  • 右侧为属性区，展示和编辑系统默认属性和自定义属性（可在“设置 需求配置 类型 风险 模版配置）
    

课时4：需求管理和版本规划基础

需求收集与分析

• 需求的定义

  • IEEE软件工程标准标准词汇表（97年）中定义需求为：
  • 用户解决问题或达到目标 所需的条件或全能（Capability）
  • 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或全能。
  • 一种反映上面（1）或（2）所描述的 条件或全能文档说明

• 软件需求包括以下几个层次

  • 业务需求
  • 用户需求
  • 功能需求
  • 非功能需求、软件需求规格说明等

• 需求管理流程
  需求收集→需求分析→需求分解与澄清→需求优先级与排期

• 需求收集
  原始需求→需求收集→用户需求
  需求获取方法
  访谈、调差问卷、需求讨论会、竞品分析、文档与数据、原型
  

• 需求分析
  用户需求→需求分析→产品需求
  针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。
  影响地图如下：
  
  why——确定目标，我为什么要做这个需求，其次，看影响到了谁，或谁对这个需求有影响
  who——我们如何影响的，
  How——我们怎么样被反过来影响的
  what——基于这个影响的分析决定要做什么样的产品需求。

基于用户故事的需求拆分与澄清

• 需求层级

  • 1.Epic Story 史诗故事
    简称为史诗，一般被定义为一个非常大的用户故事，是产品中的主干任务。
  • 2.Feature 特性
    特定是能对用户提供价值的完整功能。描述了产品具有一个完整功能，特性一般也比较大，可能持续数周，横跨几个迭代。
  • 3.User Stroy 用户故事
    特性一般可以拆分为多个用户故事，每个用户故事都对用户有价值。但是单个用户故事却又可能不能被用户正常使用或者是整个功能细分场景。
    

• 用户故事User Stroy

  • 用户故事是描述需求的一种表达形式，从用户的角度来描述用户渴望得到的功能。
  • 用户故事三要素：角色、活动、价值
    • 角色：谁要使用这个功能。
    • 活动：需要完成什么样的功能。
    • 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
  • 用户故事格式：
    • 英文： As a , I want to , so that .
    • 中文：作为一个<角色>，我想要<活动>，以便于<商业价值>
    • 举例：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

• 用户故事的3C原则

  • 3C原则：
    • 卡片（Card）-用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述估算等
    • 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
    • 确认（Confirmation） - 通过验收测试确认用户故事被正确完成。
      

• 验收标准AC（Acceptance Criteria）

  • 验收标准： 代表了用户故事3C中的Confirmation准则，同时INVEST属性的Testable的具体体现。在故事用户故事Card中，AC一般用Given-When-Then公式来书写
    • Given用户触发操作之前处于的系统状态
    • When 触发系统结果的操作
    • Then 系统预期返回的结果
  • 用户故事：作为（As）一个“网站管理员”，我（I）想要“统计每天有多少人访问了我的网站”以便（So）于“我的赞助商了解我的网站会给他们带来什么收益。”
  • 验收标准AC：
    • Given：网站运行一天后
    • When：当我点击首页访问人数按钮后
    • Then：我可以看到这一天一共有多少人访问了网站

• 需求拆分
  产品需求(Epic、Feature)→需求拆分→用户故事
  需求拆分满足INVEST原则：

  • 独立性（Independent）——要尽可能的让一个用户故事独立于其他的用户故事。
  • 可协商性（Negotiable）——一个用户故事的内容要是可以协商的，用户故事不是合同。
  • 有价值（Valuable）——每个故事必须对客户具有价值（无论是用户还是购买方）。
  • 可以估算性（Estimable）——开发团队需要去估计一个用户故事以便确定优先级、工作量、安排迭代。
  • 短小（Small）——一个好的用户故事在工作量上要短小，要确保是在一个迭代中能够完成。
  • 可测的（Testable）——用户故事必须是可测试的，只有成功通过测试才能说明该用户故事已经被开发完成。

• 需求评审
  • 产品定稿会： 一种仪式和承诺，项目个团体确认需求；
  • 产品负责人责任——产品设计初稿、召集评审、产品定稿归档；
  • 技术负责人（开发、测试）责任——参加review、提出意见确保逻辑完备性；

需求优先级与排期

• 排优先级的方法：

  • MoSCoW法则（Must/Should/Coudl/Would Not)
  • 矩阵分析法：
    重要且紧急>重要不紧急>紧急不重要>不重要也不紧急
  • 满足核心用户需求的优先(二八原则）
  • 满足核心业务的投入产出比最大的需求有限（ROI最大化）

• 需求排期
  

• 发布（版本）与迭代
  

	发布规划	迭代规划
时间的区间	3~9个月（或者更长）	1~4个周
计划中的项目	用户故事	任务

课时5：云效需求管理与迭代规划

需求录入与评审

• 需求录入-新建需求
• 新建需求
  • 步骤一：点项目左边“需求”TAB，出现新建需求的按钮。
  • 步骤二：点击“新建需求”按钮，弹出需求框。
    • 填上需求的标题和正文
    • 这里指派给：需求主负责人，可以抄送给需求相关方。
  • 步骤三：最后点“保存”即可。
    
• 需求澄清-需求讨论
• 需求讨论
  在形成结论之前，可利用“需求评论”功能对需求进行讨论。所有讨论会完整记录下来，且实时发送邮件和钉钉消息通知“指派给”和“抄送”用户（二者可在需求详细页指定），发出评论的人不会收到邮件和消息通知。
  
• 需求评审
  需求在线讨论后，形成结论产品经理（PD）把最终结论补充在需求描述正文，为了正式记录各方意见，PD可选择对需求进行正式评审。
  

需求细化

• 需求细化-需求拆分

• 需求拆分

  • 在需求进入迭代前，需要对需求进行细化。一个迭代一般是1-2周的周期，所以进入迭代的需求粒度不能太大，是用户故事级别。用户故事要符合INVEST原则。
  • 云效提供了需求细化的功能，首先要启用Story类型，之后可以在主需求下面创建子需求。

• 需求细化-启用Story类型

• 启用Story类型

  • 步骤一：点项目左边“设置”TAB
  • 步骤二：点击“需求配置”TAB
  • 步骤三：在隐藏未启用类型中选择Story，点击”启用“
    

• 需求细化-子需求

• 子需求
  - 云效需求支持不断拆分，直到Story级别。
  - 拆分后的子需求可以再由产品经理排出子需求优先级。
  

迭代规划

• 迭代管理
  迭代是敏捷开发的概念，它是有开始和结束时间的轻量级计划，用来明确规划在开始和结束时间之间需要实现的需求、需要修复的缺陷和需要完成的任务。一个典型迭代的周期从1到4周不等，团队可根据自己的节奏或业务的需要来确定迭代周期。
  以典型的Scrum为例，迭代规划的具体流程为：
  1、用户和业务放提出的需求和缺陷，由产品经理统一管理，经分析、评估、拆分和PK后，确定优先级，在计划会上和ScrmMaster（迭代负责人）、研发团队进行排期，进入迭代；
  2、迭代中，研发团队对需求进行任务拆分，拉代码变更分支，并且每天更新进度和状态；
  3、完成需求测试和验收后，进行发布，相关需求状态自动为完成；
  4、迭代完成后，如果有未完成的工作，移到下一个迭代。
  

• 迭代规则

  • 与团队一起规划迭代
    • 项目经理（PM）创建和管理迭代
    • 产品经理（PD），确定迭代优先级
    • 研发团队，根据用户故事估算，团队速率和可承受并发度等确定用户故事内容
      

• 迭代锁定
  

• 云效迭代锁定

  • 一个迭代周期内应该尽量保证内容的稳定性，不能随意增减和修改需求；
  • 云效迭代锁定后，只有迭代负责人和项目管理员才有权限，增减和修改需求内容；
    

需求变更

• 需求变更
  • 如果需求发生变更，需要走正式需求变更申请流程
  • 需求变更流程发起后，只有当需求变更评审人通过才能生效
    

需求看板

• 云效看板支持看板方法标准实践，帮助团队更好的协作和管理交付过程：
  • 更好低可视化短到端价值（需求）流动，确保产品，开发，测试等职能的前后拉通；
  • 支持任务按所属模块或不通端展开为子列，确保不通模块或不通端任务向所属的需求对齐；
  • 明确定义各列的流转规则，确保在交付过程中内建质量；
  • 限制各列工作项的并行数目，促进需求的快速持续交付；
  • 凸显交付过程中的问题、瓶颈和阻碍项，让团队聚焦应该关注的问题等。
    
• 需求看板工作流配置（1）
  
• 需求看板工作流配置（2）
  
• 需求和任务双层看板
  
• 定义流转规则
  所谓流转规则是指需求进入特定状态（某个列）的准入条件，明确定义流转规则帮助团队将质量内建到开发过程中，而不是依赖最后的环节。
  
• 限制各列工作项的并行数目
  限制并行数目，是看板方法的标准实践，它帮助团队更即时的发现瓶颈并采取应对措施，从而促进需求更快速的流动，而不是在过程中积压。当某列的实际数目达到或超过上限时，则不允许新的需求进入，或提醒用户超限。
  

课时6：软件代码与质量管理（更新版）

版本控制

• 版本控制-定义

  • 在软件工程学里，版本控制是指追踪和控制软件变更的时间；
  • 版本控制系统是用来辅助进行版本控制的工具；
  • 版本控制系统的发展历史
    • CVS
    • Subversion/ClearCase
    • git/hg/tfs
      

• 为什么需要版本控制系统

  • 记录谁在什么时间做了什么
  • 多人团队协作
    • 同步
    • 并行
  • 发布管理
  • Commit Message提供额外的信息，解释变更原因
  • Bug调试

• 分支策略

  • 管理简单
  • 主干问题会阻塞开发进程
  • 开发分支可以提供可靠的代码隔离
  • 主干问题会阻塞开发进程
  • 开发分支可以提供可靠的代码隔离
  • 主干的问题不回阻塞发布
  • 集成时间点可能延后
    

代码规约

• 代码规约-编程规约构成
  • 命名规约
  • 常量定义
  • 格式规约
  • OOP规约
  • 集合处理
  • 并发
  • 控制语句
  • 注释
  • 其他
    
• 编程规范实例
  • 命名错误说明
    
• 所有的相同类型的包装类对象之间值的比较，全部使用equals，不要用==
  
• 浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用equals来判断。
  
• 代码规约扫描工具-P3C
  • 本地结合线上：本地检测落地到IDE插件，线上检测落地到云效平台
  • 全量检测+增量检测
  • 一套规则，落地多端
  • 各个击破，以点到面，再到开源
    

单元测试基础

• 单元测试=什么是单元测试？

  • 单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确，通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
  • 例如：你可能吧一个很大的值放入一个有序list中去，然后确认该值出现在list的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。
  • 执行单元测试，是伪了证明某段代码的行为确实和开发者所期望的一致。

• 单测的理论基础-规模代价的平方定律

  • 定位并修复一个BUG所需的代价正比于目标代码规模的平方
  • 20行的代码在开发阶段发现bug，定位+修复时间可能只需要10分钟
  • 200行的代码在别人调用时发现问题，定位+修复时间可能就需要1个小时，代码评审又需要1个小时

• 单元测试-测试框架
  

• 单元测试-Mock
  

• 单元测试-A.I.R原则

  • A：Automatic（自动化）
  • I：Independent（独立性）
  • R：Repeatable（可重复）
    单元测试必须遵守AIR原则，且不能有时间限制（比如今天测试成功，明天测试失败）
    【说明】单元测试在线上运行时，感觉像空间（AIR）一样感觉不到它存在，但在测试质量的保障上，却是非常关键的，好的单元测试宏观上来说，具有自动化，独立性、可重复执行的特点。

• 单元测试-B.C.D.E原则
  编写单元测试代码遵守BCDE原则，以保证被测试模块的交付质量

  • B：Border，边界值测试，包括循环便捷、特殊取值、特殊事件点、数据顺序等。
  • C：Correct，正确的输入，并得到预期的结果。
  • DDesign，与设计文档相结合，来编写单元测试。
  • E：Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得到预期的结果。

• 好单测-总结下单测中的坏味道

  • 测试场景过于集中 —— 测试应该在某一个场景（功能）测试
  • 测试依赖运行环境——如果依赖环境了，就会单元导致测试不稳定
  • 测试缺少断言——我们打了log，用人眼观察是否能成功，如果需要人工干预，就会存在不稳定
  • 用例间存在依赖——如果存在依赖，影响太广
    

课时7：软件测试与质量保证

软件测试定义与分类

• 软件测试定义
  软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

• 软件测试类型

• 按测试目的

• 功能测试/系统测试（性能、容量、稳定性、可靠性、易用性、兼容性、安全性等非功能测试）

• 冒烟测试/回归测试
  冒烟测试：指在正式测试之前对软件进行简单测试，保证软件功能正常，能进行后面的正式测试工作
  回归测试：在修改了软件代码之后，重新测试，确保不会出现代码错误和其他错误

• 按测试阶段

• 单元测试→模块测试→集成测试→系统测试→验收测试

• 按测试方法

• 静态测试/动态测试
  静态测试：无需运行测试代码而进行的测试活动，包括评审软件文档和程序，度量程序静态复杂度和检查软件是否符合编程标准等等
  动态测试：通过运行被测程序，检查运行结果和预期结果差异并分析运行效率，正确性，健壮性等内容

• 白盒测试/黑盒测试

软件测试活动与设计方法

• 软件测试活动

• 测试规划

• 测试范围、时间、人员、优先级

• 测试方法、环境

• 测试风险

• 测试设计

• 测试用例设计

• 等价类、边界值

• 测试执行

• 创建、执行测试计划

• 环境、数据准备、

• 缺陷管理

• 测试报告

• 测试进度

• 缺陷趋势

• 软件测试设计方法-等价类

• 等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，或者进行相同的处理，测试某等价类的一组数据就等价于这一类其他值的测试

• 等价类分为有效等价类和无效等价类（即应该被系统拒绝的数据）

• 软件测试设计-边界值

• 人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是输入范围的内部，因此针对各种边界情况设计测试用例，可以查出更多的错误。

• 边界值也可以分为：有效边界值和无效边界值。

探索式软件测试

• 探索式软件测试定义

• 是一种测试风格

• 强调个体测试人员的个人自由和责任

• 通过把在测试相关的学习，测试设计，测试执行和测试结果解释当作项目中并行执行且相互支持的活动来不断优化工作价值。

• 探索式软件测试活动
  测试规划→测试设计→测试执行→测试报告
  

• 探索式软件测试的价值

• 1、理解学习被测软件

• 2、强波被测软件展现所有功能

• 3、快速发现重要缺陷

分层自动化

• 分层自动话建议
  

• 分层自动化

课时8：云效软件测试和质量保证

云效平台测试管理功能介绍

• 云效的【测试管理】功能包含对测试计划于执行用例的创建、编辑、规划与 关联等功能，让测试人员可以直接在云效的项目中进行测试工作的规划和执行进展反馈，并将【测试计划】与【需求】和【缺陷】一起进行管理。
  • 测试用例用于管理和组织手工用例，支持方便快捷编辑和查看用例。
  • 测试计划用于规划和执行手工用例。测试计划支持任务流概念，方便进行测试的评审。
  • 支持创建和关联缺陷，并提供全面的测试报告分析。

云效测试用例

• 【测试用例】是针对研发过程中测试用例库管理而提供的应用，支持用例库分组的创建、编辑、批量导入等功能，方便测试人员对用例进行标准化管理和沉淀，告别传统项目管理中测试用例重复撰写、用例信息共享不易的问题，成为测试人员专属的【武器库】。

• 思维导图

  • 作为传统的头脑风暴和思路梳理的工具，目前已经被很多测试团队广泛使用，用来进行测试用例的撰写。
  • 相比于传统的表格形式，使用思维导图来编写测试用例，更容易针对需求梳理测试路劲，也便于测试点快速定位和对于功能的查漏补缺；而且思维导图的维护和查看相比表格也更加容易。
  • 在测试计划以及测试用例应用中，可以使用思维导图文件导入测试用例。

• 云效用例集合用例

  • 用例集
    用例集是组织用例的方式，用于对用例进行分组，用例集支持嵌套用例集。
  • 用例
    名称：用例的一个简短描述。限定在100字以内。如果名称描述不清楚用例，请在描述中继续写。
    创建人：创建测试用例的人。克隆别人的用例不会更改作者。当然，作者是可以更改的，使用批量修改用例信息功能可以实现修改作者。
    步骤：用例的具体操作步骤
    注释：对用例的补充说明。
    优先级：用于表示用例执行的有限程度，可选值：P0,P1,P2,P3,默认P3【p0为最高优先级】.

• 云效测试用例
  界面如下
  
  操作顺序步骤见图中1~5
  

• 云效用例导出

  • excel导出
  • 脑图（mm、xmind）导出
    

• 云效用例导入

  • excel导入
  • 脑图（mm、xmind）导入
    

云效测试计划

• 用例加入测试计划才能执行，测试计划是用来规划一次测试过程的载体
  在测试用例界面选中测试用例或测试应用集，然后点击查看更多
  
  操作顺序步骤如下1~2：
  

• 新建测试计划
  

• 测试计划状态
  

云效测试用例执行与报告

• 云效测试用例执行
  测试计划中会展现测试进度，测试通过率和测试状态。
  
• 云效测试用例执行结果
  
  上图中暂缓测试意思为：当前情况下该用例不能被执行
• 云效缺陷模版
  可以点击添加，添加缺陷内容
  
  
• 云效测试执行报告
  在测试执行过程中或执行完毕以后，我们可以查看测试执行报告，报告内容如下图
  
• 云效测试报告邮件
  我们还可以用邮件的形式发送执行报告，邮件中看到的内容和我们通过官网查看到的内网是一样的
  邮件内容格式如下图：
  

课时9：云原生与devops

云原生的基本概念

• 云原生的定义
  云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网络、微服务、不可变基础设施和声明式API。——引自Cloud Native Computing Foundation Homepage https://www.cncf.io

• 云原生的定义一直在变

  • 不通组织有不同的定义：Pivotal & CNCF
  • 同一个组织在不同时间点有不同的定义
  • 同一个人在不同时间点也有不同的定义

• 云原生的定义未来还会变

  • CNCF最新的定义：版本V1.0

• 云计算的服务模型

  • 云计算模型
    SaaS：软件即服务
    PaaS：平台即服务
    IaaS：基础设施即服务
  • 云计算三朵云
    公有云
    私有云
    混合云
    

• 云原生的关注点

  • 微服务
  • 容器
  • CI/CD
  • DevOps
    

微服务

• 微服务架构演进

  • 单体架构
  • 垂直架构
  • SOA架构
  • 微服务架构
    

• 微服务带来的好处

  • 独立的可扩展性
    每个微服务都可以独立进行横向或纵向扩展，根据业务实际增长情况来进行快速扩展
  • 独立的可升级性
    每个微服务都可以独立进行服务升级、更新、不用依赖于其他服务，结合持续集成工具可以进行持续发布，开发人员就可以独立完成服务升级发布流程
  • 语言无关性
    研发人员可以选用自己最为熟悉的语言和框架来完成他们的微服务项目
  • 故障和资源的隔离性
    在系统中出现不好的资源操作行为时，将紧紧只会影响单个微服务

• 微服务带来的挑战

  • 分布式系统的复杂性
    • API数目成倍增加
    • 调试分布式系统很复杂
    • 跨服务的重构会很困难
    • 很难再测试中重建和生产环境一致的环境
  • 微服务的运维开销更大
    • 多个服务需要多种变成语言运行环境
    • 多个服务需要集群来处理故障转移，负载均衡
    • 需要高质量的服务监控和运维基础设施
    • 对健壮和自动化的部署要求更高
  • 对团队的要求更高
    • 组织结构需要转型到自治的，跨功能的团队
    • 团队的技术能力，技术栈需要扩展
    • 要求团队更高水平的DevOps水平

容器

• 什么是容器

  • 与系统其他部分离开的一系列进程 【可以把容器理解为轻量型的虚拟机】
  • 容器提供了一种逻辑打包机制，以这种机制打包的应用可以脱离其实际运行的环境
    

• Docker基本概念

  • 容器（Container）——镜像运行时的实体
    镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等 。
    容器的实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的命名空间。前面讲过镜像使用的是分层存储，容器也是如此。
    容器存储层的生存周期和容器一样，容器消亡时，容器存储层也随之消亡。因此，任何保存于容器存储层的信息都会随容器删除而丢失。
    按照Docker最佳实践的要求，容器不应该向其存储层内写入任何数据 ，容器存储层要保持无状态化。所有的文件写入操作，都应该使用数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。数据卷的生存周期独立于容器，容器消亡，数据卷不会消亡。因此， 使用数据卷后，容器可以随意删除、重新run，数据却不会丢失。
    -镜像（Images）——一个特殊的文件系统
    操作系统分为内核和用户空间。对于Linux而言，内核启动后，会挂载root文件系统为其提供用户空间支持。而Docker镜像（Image），就相当于是一个root文件系统。
    Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。 镜像不包含任何动态数据，其内容在构建之后也不会被改变。
    Docker设计时，就充分利用Union FS的技术，将其设计为分层存储的架构。 镜像实际是由多层文件系统联合组成。
    镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。比如，删除前一层文件的操作，实际不是真的删除前一层的文件，而是仅在当前层标记为该文件已删除。在最终容器运行的时候，虽然不会看到这个文件，但是实际上该文件会一直跟随镜像。因此，在构建镜像的时候，需要额外小心，每一层尽量只包含该层需要添加的东西，任何额外的东西应该在该层构建结束前清理掉。
    分层存储的特征还使得镜像的复用、定制变的更为容易。甚至可以用之前构建好的镜像作为基础层，然后进一步添加新的层，以定制自己所需的内容，构建新的镜像。
    -Docker File：获取地址路径
    -仓库（Repository）——集中存放镜像文件的地方
    镜像构建完成后，可以很容易的在当前宿主上运行，但是， 如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry就是这样的服务。
    一个Docker Registry中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。所以说：镜像仓库是Docker用来集中存放镜像文件的地方类似于我们之前常用的代码仓库。
    通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本 。我们可以通过<仓库名>:<标签>的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以latest作为默认标签。
    这里补充一下Docker Registry公开服务和私有Docker Registry的概念：
    Docker Registry公开服务是开放给用户使用、允许用户管理镜像的Registry服务。一般这类公开服务允许用户免费上传、下载公开的镜像，并可能提供收费服务供用户管理私有镜像。
    最常使用的Registry公开服务是官方的Docker Hub ，这也是默认的Registry，并拥有大量的高质量的官方镜像，网址为：hub.docker.com/ 。在国内访问Docker Hub可能会比较慢国内也有一些云服务商提供类似于Docker Hub的公开服务。
    除了使用公开服务外，用户还可以在本地搭建私有Docker Registry 。Docker官方提供了Docker Registry镜像，可以直接使用做为私有Registry服务。开源的Docker Registry镜像只提供了Docker Registry API的服务端实现，足以支持Docker命令，不影响使用。但不包含图形界面，以及镜像维护、用户管理、访问控制等高级功能。

• 容器、镜像、Docker File、仓库的关系如下图
  

• Docker工作流
  工作流程大概如下3个，流程可以参考上图

  • Build：从Dockerfile中导入到Images叫做build
  • Ship：将images，push到仓库叫做Ship
  • Run：将Images运行起来成为一个实例叫run

CI/CD及DevOps

• CI ——Continuous Integration 持续集成
• CD——Continuous Deployment 持续部署
• DevOps——从字面直观理解：开发运维一体化
  
• CI 持续集成流程
  • 持续集成是指：
    1、开发人员频繁低向代码库提交代码
    2、提交的代码需要经过构建、测试验证并及时得到结果反馈。
  • 可细分为3个模块
    自动构建
    自动测试
    自动结果通知
    
• CD 持续部署/持续交付
  CD——Continuous Deployment 持续部署的主要目标：
  • 持续部署是持续集成的延伸，将集成后的代码部署到生产环境
  • 频繁部署确保可以小批次发布，在发生问题时可以轻松排除故障。
    
• DevOps的定义
  • 维基百科：是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
  • DevOps经常被描述为“开发团队与运营团队之间更具协作性，更高效的关系‘。
    
• 阿里DevOps策略：打造一站式DevOps效能平台交付流水线
  

课时10：云效持续交付流水线

云效流水线简介

• 云效简介
  
• 云效流水线
  
• 云效部署能力概述
  

云效流水线实操

• 创建一条流水线【步骤一】

  • 步骤一：进入项目后，在左边菜单找到“流水线”并单击
  • 后点击新建流水线
    

• 选择模板【步骤二】
  

• 指定代码仓库【步骤三】
  

• 新建代码库【步骤四】
  

• 开通云效代码托管功能【步骤五】
  

• 开通云效代码托管功能【步骤六】
  

• 创建流水线【步骤7】
  

• 流水线状态页【步骤八】
  

• 编辑流水线【步骤九】
  

• 编辑流水线【步骤十】
  

• 设置部署环境【步骤十一】
  

• 关联ECS到部署环境【部署十二】
  

• 运行流水线【步骤十三】
  

• 部署成功【步骤十四】
  

• 部署成功【步骤十五】
  

整体课程总结

• 阿里云-云效
  云效，企业级一站式DevOps平台，源于阿里巴巴先进的研发理念和工程实践，致力于成为数字企业的研发效能引擎！云效提供从”需求→开发→测试→发布→运维→运营“端到端的协同服务和研发工具，支持公共云，专有云和混合云，多种部署形态，通过人工智能、自动化技术的应用提升开发者的研发效能，持续交付有效价值。