├── README.md
├── application_design_and_development.md
├── continuous_delivery.md
├── docs
└── image-20181112175220160.png
├── preface.md
├── project_and_development_management.md
├── security_delivery.md
├── security_development.md
├── test_automation.md
├── test_management.md
└── toolset.md
/README.md:
--------------------------------------------------------------------------------
1 | # 研发运营一体化(DevOps)能力成熟度模型 第9部分:系统和工具
2 |
3 | 研发运营一体化(DevOps)能力成熟度模型 第9部分:系统和工具(DevOps 产品标准)属于研发运营一体化(DevOps)能力成熟度模型系列标准的一部分,旨在通过行业的力量,规范化DevOps产品的功能特性,帮助企业建设、选型和购买DevOps产品工具。
4 |
5 | 本标准由DevOps标准工作组下DevOps产品工作小组负责编写和维护。
6 |
7 | ### 目录
8 |
9 | #### 0. [前言与术语](preface.md)
10 |
11 | #### 1. [项目与开发管理](project_and_development_management.md)
12 |
13 | #### 2. [应用设计与开发](application_design_and_development.md)
14 |
15 | #### 3. [持续交付](continuous_delivery.md)
16 |
17 | #### 4. [测试管理](test_management.md)
18 |
19 | #### 5. [自动化测试](test_automation.md)
20 |
21 | #### 6. 技术运营(待定)
22 |
23 | #### 7. [安全开发](security_development.md) \ [安全交付](security_delivery.md) \ 安全运营
24 |
25 |
26 | ### 协作模式
27 |
28 | 该标准基于Markdown(纯文本)的方式编写,采用Github进行统一的版本管理和变更管理。
29 |
30 | #### 1. 协作流程
31 |
32 | 1. 如何下载标准内容:`git cloe git@github.com:docmm/09-devops-system-tool.git`
33 |
34 | 2. 如何修改并提交标准内容:
35 |
36 | 1. Fork仓库或在本地创建分支
37 |
38 | 
39 |
40 | 在Github Desktop 中点击创建分支,输入分支名称即可
41 |
42 | 2. 参考Markdown[格式说明](http://www.markdown.cn/),在本地采用Markdown编辑器进行内容修改即可
43 |
44 | 3. 提交到Github(git add->git commit->git push origin 分支名称)
45 |
46 | 4. 发起Pull Request,申请合并修改内容,请详细描述Pull Request理由
47 |
48 | 5. 各能力项组长Review提交内容后确认是否接受Pull Request
49 |
50 | 3. 如何管理长期的待办事项
51 |
52 | 1. 创建Issue,填写待办事项
53 |
54 | #### 2. 推荐工具
55 |
56 | 1. Markdown 编辑器
57 | 1. Typora:https://typora.io(Window/Mac/Linux)
58 | 2. Github 管理
59 | 1. GitHub Desktop:https://desktop.github.com
60 | 2. 其他工具:Git/TortoiseGit等
61 | #### 注意事项
62 |
63 | 1. 注意修改前请获取最新的提交
64 |
65 | ### 分工表
66 |
67 | #### 1. [项目与开发管理](project_and_development_management.md)
68 |
69 |
70 | | 能力项 | 项目管理 | 需求管理 | 计划与任务管理 | 文档与知识管理 | 团队协同 | 统计度量 | 项目集管理 |
71 | | ------ | -------- | ---------------------- | ------------------------------- | ---------------------- | --------------------------- | ---------------------- | ---------------------- |
72 | | 组长 | 空缺 | 空缺 | 亚信科技 | 华为云 | 华为云 | 阿里云 | 阿里云 |
73 | | 成员 | 空缺 | 腾讯云/华为云/浙江移动 | 腾讯云/华为云/亚信科技/浙江移动 | 腾讯云/华为云/浙江移动 | 腾讯云/华为云/泰岳/浙江移动 | 华为云/阿里云/浙江移动 | 腾讯云/华为云/浙江移动 |
74 |
75 |
76 |
77 | #### 2. [应用设计与开发](application_design_and_development.md)
78 |
79 | | 能力项 | 应用框架 | 云IDE |
80 | | ------ | ----------------------- | ------------- |
81 | | 组长 | 腾讯 | 华为云 |
82 | | 成员 | 华为云/阿里云/腾讯/谐云 | 华为云/阿里云 |
83 |
84 | #### 3. [持续交付](continuous_delivery.md)
85 |
86 | | 能力项 | 源代码管理 | 构建管理 | 持续集成 | 流水线 | 制品管理 | 发布管理 | 环境管理 | 数据管理 | 应用配置管理 |
87 | | ------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | :----------------------------------------------------------: |
88 | | 组长 | 腾讯云 | 腾讯云 | 灵雀云 | 华为云 | 阿里云 | 腾讯云 | 优维科技 | 待定 | 阿里云 |
89 | | 成员 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/浙江移动 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/浙江移动 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/亚信科技/浙江移动 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/优维科技/亚信科技/浙江移动 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/浙江移动 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/优维科技/浙江移动 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/优维科技/浙江移动 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/浙江移动 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/优维科技/浙江移动 |
90 |
91 | #### 4. [测试管理](test_management.md)
92 |
93 | | 能力项 | 用例与测试计划管理 | 缺陷管理 | 测试数据管理 |
94 | | ------ | ------------------------------------------------------------ | ---------------------------------------------------- | ---------------------------------------------------- |
95 | | 组长 | 中兴 | 阿里云 | 华为云 |
96 | | 成员 | 华为云/腾讯云/中兴/阿里云/京东云/电信研究院/亚信科技/浙江移动 | 华为云/腾讯云/中兴/阿里云/京东云/电信研究院/浙江移动 | 华为云/腾讯云/中兴/阿里云/京东云/电信研究院/浙江移动 |
97 |
98 | #### 5. [自动化测试](test_automation.md)
99 |
100 | | 能力项 | 代码质量管理 | 单元测试 | 接口/服务测试 | UI测试 | 移动应用测试 | 性能测试 |
101 | | ------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ---------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------ |
102 | | 组长 | 腾讯云 | 亚信科技 | 华为云 | 阿里云 | 腾讯云 | OneAPM |
103 | | 成员 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴/浙江移动/亚信科技 | 华为云/腾讯云/中兴/阿里云/京东云/电信研究院/亚信科技/浙江移动 | 华为云/腾讯云/中兴/阿里云/京东云/电信研究院/亚信科技/浙江移动 | 华为云/腾讯云/中兴/阿里云/京东云/电信研究院/浙江移动 | 华为云/腾讯云/中兴/阿里云/京东云/电信研究院/浙江移动 | 华为云/腾讯云/中兴/阿里云/京东云/电信研究院/OneAPM/MicroFocus/浙江移动 |
104 |
105 | #### 6. 技术运营(待定)
106 |
107 | #### 7. [安全开发](security_development.md) \ [安全交付](security_delivery.md) \ 安全运营
108 |
109 | | 能力域 | 安全开发 | 安全交付 | 安全运营 |
110 | | ------ | ------------------------------------------------------- | ------------------------------------------- | -------- |
111 | | 能力项 | 代码安全与合规管理 | 安全测试 | 暂无 |
112 | | 组织 | 华为云 | 阿里云 | 腾讯云 |
113 | | 成员 | 阿里云/腾讯云/华为云/京东云/灵雀云/电信研究院/谐云/中兴 | 华为云/腾讯云/中兴/阿里云/京东云/电信研究院 | |
114 |
115 |
116 |
117 |
118 |
119 |
--------------------------------------------------------------------------------
/application_design_and_development.md:
--------------------------------------------------------------------------------
1 | ## 应用设计与开发
2 |
3 | ### 1. 应用框架
4 |
5 | 应用设计与开发是指提供一套含服务发现、自动注册、负载均衡、开发组件、契约规范、高性能通信、公共组件、多语言支持等完善开发框架及支撑平台,以提升开发和运营效率。
6 |
7 | ##### 应包含以下基本功能:
8 |
9 | ——服务发现:服务发现是对计算机网络上的设备和由这些设备提供的服务的自动检测,旨在减少用户的配置工作量。
10 |
11 | ——自动注册:服务注册中心可以给客户端提供可供调用的服务列表,客户端在进行远程服务调用时,根据服务列表然后选择服务提供方的服务地址进行服务调用。而自动注册是由服务实例负责在服务注册中心注册和注销,同时需要发送心跳来保证注册信息不会过时。
12 |
13 | ——负载均衡:负载均衡是一种计算机技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的,用于解决互联网架构中的高并发和高可用的问题。
14 |
15 | ——开发组件:基于组件的开发是一种软件开发范型,通过复用已有的组件,软件开发者可以“即插即用”地快速构造应用软件。这样不仅可以节省时间和经费,提高工作效率,而且可以产生更加规范、更加可靠的应用软件。
16 |
17 | ——契约规范:契约式设计是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的、精确的并且可验证的接口,以生成规范、可靠的应用软件。
18 |
19 | ——高性能通信:
20 |
21 | ——公共组件:基于组件的开发是一种软件开发范型,通过复用已有的组件,软件开发者可以“即插即用”地快速构造应用软件。这样不仅可以节省时间和经费,提高工作效率,而且可以产生更加规范、更加可靠的应用软件。
22 |
23 | ——多语言支持:语言无关规范是一种编程语言规范,它提供了一个公共接口,可用于定义适用于任意语言绑定的语义,以支持多种语言,减少或消除不同语言无法使用同一种应用的情况。
24 |
25 | ——支撑平台:支撑平台是一个信息的集成环境,是将分散、异构的应用和信息资源进行聚合,通过统一的访问入口,实现结构化数据资源、各种服务跨数据库的无缝接入和集成,提供一个支持信息访问、传递、以及协作的集成化环境,实现个性化业务应用的高效开发、集成、部署与管理。
26 |
27 |
28 | ##### 可以包含以下高级功能:
29 |
30 | ——xxxx
31 |
32 | ——xxxx
33 |
34 | ### 2. 云IDE
35 |
36 | 云IDE是指基于云的集成开发环境(IDE),通过浏览器即可使用。
37 |
38 | ##### 应包含以下基本功能:
39 |
40 | +是否应当在描述列出使用场景(京东)
41 |
42 | --支持在线编写、构建、运行、断点调测代码
43 |
44 | --支持多种编程语言,包括但不限于Java/Node.js/Android/.Net/C/C++/python/php等
45 |
46 | --支持管理工作空间
47 |
48 | --可以在云端创建工作空间
49 |
50 | --可以自动生成用户工作空间
51 |
52 | --可以定制工作空间资源 支持用户定制化资源分配(表述不清)
53 |
54 | --可以切换界面风格和视图
55 |
56 | --支持语法加亮、关键词自动补全及智能提示
57 |
58 | --支持技术栈自动关联和构建软件包 可自动关联技术栈库文件,快速生成软件包(表述不清)
59 |
60 | --支持通过插件机制扩展场景
61 |
62 | --支持对接其他服务,包括但不限于代码托管、代码检查
63 |
64 | --支持查看所选代码的相关缺陷
65 |
66 | --支持访问后端环境,可实现跨网络/跨容器联调
67 |
68 |
69 | ##### 可以包含以下高级功能:
70 |
71 |
72 | --支持人工审批与主流代码仓库对接,可实现代码自动下载、更新与智能提交(描述不清)
73 |
74 | ——宜集成代码静态检查,快速发现低级源码错误
75 |
76 | ——宜提供多种开发框架和运行环境的例程代码,支持用户快速入门和后续编码
77 |
78 | --支持多地协同开始时候的代码同步/协同编辑
79 |
80 | --安全相关:防止拍照等,支持用户快速入门和后续编码
81 |
82 | --支持插件机制快速添加技术栈
83 |
84 | --支持对接调用其他服务 可与DevOps其他交付环节无缝集成(描述需要再准确些)
85 |
--------------------------------------------------------------------------------
/continuous_delivery.md:
--------------------------------------------------------------------------------
1 | ## 持续集成与持续交付
2 |
3 | ### 1. 版本控制系统
4 |
5 | 版本控制系统又称源代码管理系统,是指一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。
6 |
7 | ##### 版本控制系统应包含以下基本功能:
8 |
9 | ——支持浏览、查阅、复刻、归档版本仓库
10 |
11 | ——为版本仓库指定成员,并根据可访问、可读取、可写入等不同能力将成员划分为管理员、负责人、开发者、协作者等不同角色,并能在不同对象上(如团队、项目等)定义
12 |
13 | ——支持浏览、查阅、创建和删除分支,可根据分支查看变更历史,并查看分支对应的版本文件
14 |
15 | ——能够在分支上定义合并策略,限制不同开发人员在分支上的合并权限
16 |
17 | ——可查看某个变更的当前全部版本文件,并将版本文件拉取到本地
18 |
19 | ——可将本地修改提交到版本仓库,完成变更
20 |
21 | ——支持在线对比两个不同变更之间的文件差异,查看变更的历史记录以及变更之间的关联关系。并可将一个或多个变更创建为合并评审,用于合并到待合并分支
22 |
23 | ——查看合并评审的历史列表,以及每个合并评审引入的变更,可设置经过评审后才可合并
24 |
25 | ——支持将某个变更标识为Tag,并作为基线管理
26 |
27 | ——查看基线对应的版本文件,并能将对应的版本文件下载到本地
28 |
29 | ——查看不同变更间、不同基线间、变更与基线间、分支与基线间的文件差异
30 |
31 | ——变更被提交时,提供Hooks用于触发自动化集成和检测
32 |
33 | ——发起代码审查,邀请审查人在不同时间和地点查看版本差异并给出意见
34 |
35 | ——同一个版本仓库能够支持多份存储写入,当存储故障时可切换备份存储
36 |
37 | ——提供实时和定时的备份机制,可使用备份还原版本仓库
38 |
39 | ——应唯一确定访问账号身份,保证无法越权访问
40 |
41 | ——应能够保留访问记录和危险操作记录,用于审计回溯
42 |
43 | ——应支持如https / SSH等加密传输方式,保证传输过程的网络包被截获后无法轻易解密
44 |
45 | ——应为变更、合并和评审提供Hook,用于触发自动化流程
46 |
47 | ——应提供CI/CD中基本功能的API,用于其他系统调用接入
48 |
49 |
50 |
51 | ##### 版本控制系统可以包含以下高级功能:
52 |
53 | ——建立团队或路径等方式,并在其中指派不同角色的成员,将版本仓库按一定模式归类存放
54 |
55 | ——更改版本仓库的可见性为全员共享或部分可见
56 |
57 | ——限制仓库总大小,限制仓库的单文件大小,对限制额度进行缩小或提额
58 |
59 | ——定义分支创建规则,对分支的创建进行限定,在分支上定义角色,指认分支的管理员,定义读取、写入和合并权限
60 |
61 | ——针对变更进行讨论
62 |
63 | ——合并评审可根据代码扫描、持续集成与自动化测试系统反馈情况,阻止有风险的版本合入
64 |
65 | ——定义基线的命名规则,阻止不符合规则的基线创建
66 |
67 | ——对代码审查进行数据度量
68 |
69 | ——审查人能在移动终端查看代码审查、讨论并给出意见
70 |
71 | ——能与主流的即时通讯服务或团队协同工具集成,提供实时的消息通知
72 |
73 | ——同一个版本仓库能够提供多地存储,在有多地访问需求时,能提供就近访问
74 |
75 | ——大量复刻并修改同一版本仓库时,能让存储容量不随复刻数线性增长
76 |
77 | ——支持使用通用的文件存储系统(如x86平台的存储系统)
78 |
79 | ——支持OAuth等安全的三方认证能力,保证需求敏捷、持续集成、持续交付、代码检测、自动化测试等工具在访问版本资源时,访问权限受到当前操作人角色权限的限制
80 |
81 | ——提供研发生命周期中所需功能的API,用于其它系统深度集成
82 |
83 | ——可提供项目维度和团队维度的动态墙用于汇聚研发过程有关的消息和事件,使用会话的形式聚合研发过程中发生的事件与关键结点,并可使用移动终端查阅。
84 |
85 | ——会话墙能力可允许需求敏捷、持续集成、持续交付、代码检测、自动化测试等工具调用
86 |
87 |
88 |
89 |
90 |
91 | ### 2. 构建管理
92 |
93 | 构建是指从代码或其它产物构建出指定输出物的过程,构建管理是指管理以上过程涉及的任务、过程、策略和环境等必要因素。
94 |
95 | ##### 应包含以下基本功能:
96 |
97 | ——通过配置模板或脚本初始化构建环境。
98 |
99 | ——通过配置模板或脚本定义构建任务。
100 |
101 | ——初始化环境和构建任务的配置模板或脚本的存储有版本管理,可配置标签。
102 |
103 | ——构建过程的输出可重定向到文件或日志服务,能够持久化存户和查询。
104 |
105 | ——构建过程可以设定执行时间,针对超时的情况可设定超时策略。
106 |
107 | ——构建过程的输出物设定输出地点、传输协议,针对输出失败的情况设定失败策略。
108 |
109 | ——构建过程的触发支持通过 HTTP RESTFUL 、GRPC 等多种方式触发任务执行。
110 |
111 | ——构建过程的结果可设定多中通知策略,支持 Email、IM 等。
112 |
113 | ##### 可以包含以下高级功能:
114 |
115 | ——管理构建资源,针对构建任务设定优先级进行调度。
116 |
117 | ——能使用分布式系统管理构建任务。
118 |
119 | ### 3. 持续集成
120 |
121 | 持续集成是指通过源代码构建软件的流程。
122 |
123 | ##### 应包含以下基本功能:
124 |
125 | 持续集成是指通过源代码构建软件的流程。应该包含以下基本功能:
126 |
127 | ——保存多个构建任务
128 |
129 | ——设置代码仓库地址,以及拉取源代码的凭据
130 |
131 | ——设置一个或多个构建命令
132 |
133 | ——支持多种源代码语言的编译
134 |
135 | ——支持多种源代码托管软件
136 |
137 | ——设置自动触发条件:定时触发,源代码变更触发
138 |
139 | ——构建任务应该含多个执行记录
140 |
141 | ——构建执行记录展示记录状态,以及结果
142 |
143 | ——构建执行记录展示构建过程产出的日志
144 |
145 | ——支持构建命令中执行软件单元测试
146 |
147 | ——支持执行静态源代码扫描
148 |
149 | ——支持定义构建执行环境
150 |
151 | ##### 可以包含以下高级功能:
152 |
153 | ——可以支持提供执行持续集成依赖的服务,例如:数据库服务,缓存服务等
154 |
155 | ——构建执行记录中可以保存构建产出物
156 |
157 | ——构建执行记录中可以保存构建报告,单元测试报告,测试覆盖率报告
158 |
159 | ——可以保存构建产出物到第三方软件
160 |
161 | ——可以支持在一个构建任务中多个源代码仓库的
162 |
163 | ——可以支持定义构建任务超时时间,并在执行过程不允许
164 |
165 | ——支持构建容器镜像,以及推送构建的容器镜像到第三方软件
166 |
167 | ——支持源代码缓存
168 |
169 | ——支持触发其它构建任务,或者其它第三方软件
170 |
171 | ——支持定义执行超时时间
172 |
173 | ——建议在高级功能中添加:
174 |
175 | ——支持源码多分支管理策略的构建场景
176 |
177 | ——支持动态可伸缩的构建执行环境
178 |
179 | ——支持构建结果通知(及时消息、邮件等)(10.9)
180 |
181 | ### 4. 流水线
182 |
183 | 流水线是将代码提交到部署上线整个过程中的自动化实现。
184 |
185 | ##### 应包含以下基本功能:
186 |
187 | ——支持集成调度代码托管、代码检查、编译构建、部署、测试、发布等任务,应实现提交代码后的端到端的产品自动化交付与发布
188 |
189 | ——支持业务流程按需定制,可选择要执行的步骤和顺序
190 |
191 | ——支持级联调度与分层分级(是否增加描述1101)
192 |
193 | ---增加串行并行能力的描述(1101)
194 |
195 | ——支持按时间计划或代码提交等多种触发方式
196 |
197 | ——支持流水线状态可视化,宜清晰呈现价值流动,宜及时准确定位问题
198 |
199 | ——支持参数配置
200 |
201 | ++增加质量管理控制,支持多种条件判断
202 |
203 | ##### 可以包含以下高级功能:
204 |
205 | ——支持人工审批
206 |
207 | ### 5. 制品管理
208 | 专家建议:增加制品版本控制模块;另外是高级功能和基本功能划分的问题。
209 |
210 | 制品管理是对软件研发过程中生成的产物的管理,一般作为最终交付物完成发布和交付。 制品即构建过程的输出物,包括软件包,测试报告(存疑,招商银行,是否作为元数据),应用配置文件(是否适合作为制品,应当能够作为元数据1101)等。 比如jar包、zip包、rpm包、docker镜像等。
211 |
212 | ##### 应包含以下基本功能:
213 | --(缺少制品添加方式的描述(谐云科技)1101)
214 |
215 | ——支持至少一种制品类型;
216 |
217 | ——为制品添加版本信息等元数据信息(元数据信息希望能细化,烽火科技1101);
218 |
219 | ——使用制品的审计日志;
220 |
221 | ——基本的权限管理;
222 |
223 | ——代理其他制品库;(不应该作为基本功能,应作为高级功能,一些企业无法实现代理能力,平安银行1101)
224 |
225 | ——检索制品;
226 |
227 | ——备份和恢复
228 | ##### 可以包含以下高级功能:
229 |
230 | ——支持多种制品类型;
231 |
232 | ——制品分发支持大规模并发、全球加速;(应当增加对场景的限制1101)
233 |
234 | ——与持续交付系统高度集成;(描述有欠缺,是否和API一行合并谈集成能力1101)
235 |
236 | ——基于元数据信息实现制品的安全管控、晋级
237 |
238 | ——当特定制品的特定版本由于某种原因需要召回时,具备快速阻断机制,立即禁止被再次引用/访问;
239 |
240 | ——REST API支持;
241 |
242 | ——通过关键字、坐标数据、CheckSum等多种方式检索制品
243 |
244 | ——基于角色的权限管理
245 |
246 | ——基于自定义策略的访问控制
247 |
248 | ——制品文件安全扫描
249 |
250 | ——分析和查看制品依赖关系
251 |
252 | ——基于CheckSum的制品去重存储;
253 |
254 | ——自定义制品清理/归档策略(是否应该改为基本功能,平安银行,征求下云产品的建议1101)
255 |
256 | --(是否增加配额管理能力作为高级功能1101)
257 |
258 | ——制品存储不依赖于特定厂商或存储源
259 |
260 | ### 6. 部署管理
261 |
262 | 专家建议:生产环境的管理还是测试环境?此处是生产管理的,专家建议包含生产环境和测试环境。(增加对测试等各类环境的描述1101)
263 |
264 | 部署管理是DevOps持续交付中的一个重要环节,它借助自动化工具与统一规范,实现仓库版本到生产环境的自动化部署,提升开发和运维人员快速部署的能力。应该包含以下基本功能:
265 |
266 | ##### 应包含以下基本功能:
267 |
268 | ----是否应该有 权限管理(1101)
269 |
270 | ——部署工具应具备批量(海量)并发部署的能力;
271 |
272 | ——支持灰度、全量(是否是发布管理的概念,而不是部署管理1101)等部署方案的实施,实现对生产环境的平滑升级;
273 |
274 | ——部署前支持备份上一版本的生产环境,在当前版本出现问题后能支持版本快速回退;
275 |
276 | ——支持业务配置文件的自动生成与下发以及统一管理;
277 |
278 | ——当业务架构调整后(存在疑问,mark1101),部署方案(范围较大1101)仅需调整布署节点配置项即可(布署节点指的是什么,京东云1101);
279 |
280 | ——部署工具与业务架构松耦合,无需业务因布署方案或工具做任何改造;
281 |
282 | ——部署对象服务器支持windows、linux等主流操作系统;
283 |
284 | ——部署对象服务器在CMDB集中管理,与部署工具联动实现任意组合集群的版本部署;
285 |
286 |
287 | ##### 可以包含以下高级功能:
288 |
289 | 可以包含以下高级功能:
290 |
291 | ——部署工具具备调度编排的能力,能同时对不同功能模块版本实现一次性全流程部署;
292 |
293 | ——支持上下文传输部署,即上一部署节点的输出能作为下一节点的前置条件或输入参数;
294 |
295 | ### 7. 发布管理
296 |
297 | (如何描述对业务影响) 发布管理是指一个应用或多个集成应用程序从测试完成开发测试到生产环境用户可见的完整发布流程(定义混淆,如何和部署区分,华为1101)。
298 |
299 | ##### 应包含以下基本功能:
300 |
301 | ——发布计划,规划软件程序的整体发布计划,包含但不限于:谁在何时、何地、怎样、发布了什么。以及对比发布计划和发布状态的能力。
302 |
303 | ——发布定义,定义发布流程和审批工作流。
304 |
305 | ——发布策略,通过选择进行发布的目标环境、超时时间、暂停点、灰度发布等发布的具体策略,执行对应的发布动作;发布策略包含并不限于一键式发布,零停机发布、灰度发布、金丝雀发布等
306 |
307 | ----(与布署管理关联1101)
308 |
309 | ——发布执行,自动化地执行发布策略,如策略中有暂停点,应验证后继续执行发布
310 |
311 | ——发布确认,通过发布规划中软件发布的确认点,进行发布确认,如与预期不一致,可快速回滚到发布前的软件版本
312 |
313 | ##### 可以包含以下高级功能:
314 |
315 | 可以包含以下高级功能:
316 |
317 | ——发布决策,实现个角色的协同,评审决策,控制应用版本向后续环境的流动
318 |
319 | ——风险评估与质量门禁,提供发布影响分析视图,可快速查看发布产品的发布风险,在关键节点控制版本质量,支持自动质量门禁
320 |
321 | ——发布度量,发布报告视图,提供发布的状态报告与历史发布数据
322 |
323 | ### 8. 环境管理
324 |
325 | 环境管理是一种配置管理活动,确保应用在多个环境之间达到持续交付的目的。
326 |
327 | ##### 应包含以下基本功能:
328 |
329 | ——可以定义不同的环境类型(开发、测试、预发布及生产环境);
330 |
331 | ——可以定义不同的环境依赖资源信息及其配置,比如主机、容器集群、DNS、中间件、其他基础设施服务等等;
332 |
333 | ——可以根据环境的配置快速生成交付(交付一词不妥1101 ) 环境;
334 |
335 | ——可以让环境的配置信息存储在构件库中,版本化控制配置信息;(构件库的含义不清,应当澄清)
336 |
337 | ——可以支持应用运行的环境是静态主机集群或者是动态的容器集群;
338 |
339 | ——可以支持不同的应用有不同的基础设施及服务依赖;
340 |
341 | ——可以支持不同的对象分块构建,比如说构建基础设施、构建中间件或者操作系统环境等等;
342 |
343 | ——可以支持不同的环境采用不同的构建技术,比如说虚拟化、容器等等,但测试环境和生产环境必须类似;
344 |
345 | ——可以支持环境的配置信息与应用或者项目关联;
346 |
347 | ——对环境提供监控功能;
348 |
349 | ##### 可以包含以下高级功能:
350 |
351 | 可以包含以下高级功能:
352 |
353 | ——提供与不同的配置管理工具对接功能;
354 |
355 | ——提供与不同制品构件库对接功能,比如说maven仓库和容器仓库artifactory、harbor等等(1101);
356 |
357 | ——提供开放式的API供外围平台编排调用;
358 |
359 | ——提供所有环境的变更日志和审计功能;
360 |
361 | ——提供环境配置信息的权限控制;
362 |
363 | ——提供测试验证的工具来验证环境的有效性;
364 |
365 | ### 9. 数据管理(待定)
366 |
367 | 数据管理是xxxx。
368 |
369 | ##### 应包含以下基本功能:
370 |
371 | ——xxxx
372 |
373 | ——xxxx
374 |
375 | ##### 可以包含以下高级功能:
376 |
377 | ——xxxx
378 |
379 | ——xxxx
380 |
381 | ### 10. 应用配置管理
382 |
383 | 应用配置是指应用启动或动态运行时影响应用行为的配置项,典型例子如数据库连接串(含用户名密码),本地服务线程池数,RPC连接超时时间设置,三方软件LicenseKey,等。应用配置管理,是对应用配置进行集中式管理的系统和方法。采用应用配置管理,可以让配置发布有效解耦程序开发,程序发布等流程,并让程序能动态响应配置的变更,提高DevOps效率。
384 |
385 | ##### 应包含以下基本功能:
386 |
387 | ——配置的最小粒度应对应单一配置ID,其内容应不限于KV,Json, XML等格式,用户应能自由配置。
388 |
389 | ——配置内容大小应有限制,但是不宜太小,如应超过100KB以上。
390 |
391 | ——配置应能基于租户,分组,或其他不同粒度规则进行隔离。
392 |
393 | ——对配置的访问应有鉴权,以控制账号对相关配置项的读写权限操作。
394 |
395 | ——应提供相应程序接口供应用程序实现读、写配置的功能。
396 |
397 | ——应提供相应程序接口供应用程序实现配置订阅的功能,如配置变更,则程序可在短时间内做出响应。
398 |
399 | ——应用程序应可以基于各类语言如java, go, node, c++等多语言SDK来操作配置。
400 |
401 | ——应用配置管理应能和各类CI/CD工具集成,如github,等。
402 |
403 | ##### 可以包含以下高级功能:
404 |
405 | 可以包含以下高级功能:
406 |
407 | ——配置发布时应支持灰度发布,如根据某类机器的IP或某类机器的Label。
408 |
409 | ——应提供配置订阅监控,可查看配置被哪些机器订阅。
410 |
411 | ——配置应能区分版本,不同版本之间能一键回滚,以降低配置发错的风险。
412 |
413 | ——配置管理应能充分集成各类加密工具,如AWS KMS,Aliyun KMS,Hashcorp Vault,(不应出现具体产品1101)以保证配置安全性。
414 |
415 | ——配置管理中心以成为系统单点,如管理中心宕机,应用应能正常运行。(但新配置不能发布)
416 |
--------------------------------------------------------------------------------
/docs/image-20181112175220160.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/512mouse/09-devops-system-tool/ac8ac26863e68d3007537791a82b4ba3fccaa4d5/docs/image-20181112175220160.png
--------------------------------------------------------------------------------
/preface.md:
--------------------------------------------------------------------------------
1 | # 研发运营一体化(DevOps)能力成熟度模型 第9部分 系统和工具
2 |
3 |
4 | ## 1. 范围
5 |
6 | 本标准规定了研发运营一体化(DevOps)的xxxxx。
7 |
8 | 本标准适用于具备IT软件研发交付运营能力的组织实施IT软件开发和服务过程的能力进行评价和指导;可供其他相关行业或组织进行参考;也可作为第三方权威评估机构衡量软件开发交付成熟的标准依据。
9 |
10 | ## 2. 规范性引用文件
11 |
12 | 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
13 |
14 | [1] GB/T 32400-2015 信息技术 云计算 概览与词汇
15 |
16 | [2] GB/T 32399-2016 信息技术 云计算 参考架构
17 |
18 | [3] YD/2441-2013 互联网数据中心技术及分级分类标准
19 |
20 | [4] GB/T 33136-2016 信息技术服务数据中心服务能力成熟度模型
21 |
22 | [5] GB/T 31496-2015 信息技术 安全技术 信息安全管理体系实施指南
23 |
24 | [6] GB/T 22080-2016 信息技术 安全技术 信息安全管理体系要求
25 |
26 | [7] GB/T 30975-2014 信息技术 基于计算机的软件系统的性能测量与评级
27 |
28 | ## 3. 术语
29 |
30 | 下列术语和定义适用于本文件。
31 |
32 | **3.1 项目 project**
33 |
34 | 需要协同工作的一组任务,其目的在于开发和(或)维护一个具体的产品。产品可以包括硬件、软件或其他成分,一般项目有自己的经费、成本核算和交付进度。【GB/T11457-2006:2.954】
35 |
36 | **3.2 项目集 program**
37 |
38 | PMI将项目集定义为经过协调管理以获取单独管理所无法取得的收益的一组项目、子项目集和项目集活动。
39 |
40 | **3.3 子项目集 sub program**
41 |
42 | 作为另一个项目集的组成部分而被管理的一个项目集
43 |
44 | **3.4 构建项目 Build project**
45 |
46 | 作为一个构建软件的配置,以及流程。
47 |
48 | **3.5 执行记录 Build history**
49 |
50 | 执行构建的信息,以及结果。
51 |
52 | **3.6 构建产出物 Build output**
53 |
54 | 构建项目中生产的文件。
55 |
56 | **3.7 凭据 Credentials**
57 |
58 | 保存用户保密信息,例如:用户名和密码。
59 |
60 | **3.8 容器镜像 Container Image**
61 |
62 | 容器技术中运行容器软件。包含基本操作系统以及依赖的软件。可以包含构建的产出物。
63 |
64 | **3.9 运行环境 Runtime environment**
65 |
66 | 构建中运行的环境或者计算机。
67 |
68 | **3.10 源代码托管软件 Source code management software**
69 |
70 | 保存源代码的软件。
71 |
72 | **3.11 软件单元测试 Software unit test**
73 |
74 | 软件中研发的自动化测试。
75 |
76 | **3.12 发布**
77 |
78 | 发布通常是软件程序的变动,将线上的流量转移到新的软件版本的过程
79 |
80 | **3.13 原地发布**
81 |
82 | 将新的软件版本直接推送到服务器上覆盖旧版本,发布过程可能会引起服务的中断,是一种最直接的发布方式
83 |
84 | **3.14 金丝雀发布**
85 |
86 | 是指在黑与白之间,能够平滑过渡的一种发布方式。又称灰度发布,A/B测试就是一种灰度发布方式,让一部分用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度范围的一种发布方式
87 |
88 | **3.15 蓝绿发布**
89 |
90 | 在发布过程中,新旧版本相互热备,发布过程是不停止老版本,直接部署新版本然后进行测试,通过切换路由权重的方式(非0即100)实现将流量切到新版本,然后老版本同时也升级到新版本,是一种可以保证系统在不间断提供服务的情况下的发布方式
91 |
92 | **3.16 回滚**
93 |
94 | 回滚(Rollback)指的是程序或数据处理错误,将程序或数据恢复到上一次正确状态的行为。回滚包括程序回滚和数据回滚等类型
95 |
96 | **3.17 环境 Environment**
97 |
98 | 是指应用程序运行所需的所有资源和它们的配置信息,通常分成两大类:基础设施资源及其配置;应用程序独立运行所需要的操作系统和中间件资源及其配置信息。
99 |
100 | **3.18 配置项 Configuration item**
101 |
102 | 一个配置中的实体,它满足一项最终使用功能,并能在给定的基准点上单独标识。【GB/T 8566-2001:3.6】
103 |
104 | **3.19 配置管理 Configuration Management**
105 |
106 | 是一个过程,通过该过程,可以维护一切与环境相关的信息,这些信息可以被定义、修改、存储和检索。应用技术和管理的指导和监控方法以标识和说明配置项的功能和物理特征,控制这些特征的变更,记录和报告变更处理和实现状态并验证与规定的需求的遵循性。【GB/T11457-2006:2.313】
107 |
108 | **3.20 开发环境 Development Environment**
109 |
110 | 用于维持开发过程的一个或者一组资源及其配置信息,面向的是开发者。
111 |
112 | **3.21 测试环境 Test Environment**
113 |
114 | 用于维持测试过程的一个或者一组资源及其配置信息,面向的是测试者。
115 |
116 | **3.22 生产环境 Production Environment**
117 |
118 | 用于维持开发过程的一个或者一组资源及其配置信息,面向的是运维,但其运行服务面向的是用户或者客户。
119 |
120 | **3.23 基础设施 Infrastructure**
121 |
122 | 支持应用运行的所有服务,包括DNS服务器、防火墙、路由器等等。
123 |
124 | **3.24 中间件 Middleware**
125 |
126 | 是处于操作系统和应用程序之间的软件。一种类型的软件模块,它处在系统软件和应用软件之间,依赖系统软件的支持,又为应用软件提供支持,以方便应用软件的开发。【GB/T11457-2006:2.954】
127 |
128 | **3.25 性能测试(performance test)**
129 |
130 | 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。评价系统或部件与规定的性能需求的依从性的测试行为。【GB/T11457-2006:2.1135】
131 |
132 | **3.26 负载测试(load testing)**
133 |
134 | 通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。
135 |
136 | **3.27 压力测试(stress testing)**
137 |
138 | 压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间或超大负荷地运行测试软件,来测试被测系统的性能、可靠性、稳定性等。
139 |
140 | **3.28 稳定性测试(stability test)**
141 |
142 | 通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数,持续执行一段时间业务,通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。
143 |
144 | **3.29 活动(activity)**
145 |
146 | 由用户或模拟用户向在册系统(SUT)提交的一种命令:要求依界定的算法来执行数据处理操作,从特定输入数据和(若要求时的)既存数据产生特定输出数据。
147 |
148 | **3.30 活动类型(activity type)**
149 |
150 | 对执行同一算法所界定的各种活动的分类。
151 |
152 | **3.31 链(chain)**
153 |
154 | 以界定的顺序向STU提交的一个或不止一个任务。
155 |
156 | **3.32 链型(chain type)**
157 |
158 | 对由任务(类)型序列所界定的链所作的分类。
159 |
160 | 模拟用户只向SUT提交规定链型的链。
161 |
162 | 所指链型当前序号的数学符号为L,链型总数的数学符号为u。
163 |
164 | **3.33 模拟用户(emulated user)**
165 |
166 | 就用户提交任务及其时变行为实施模仿的技术系统。
167 |
168 | **3.34 执行时间(execution time)**
169 |
170 | 从任务提交至任务完成所经历的时间。
171 |
172 | **3.35 平均执行时间(mean execution time)**
173 |
174 | 在评级区间内提交的第j型所有任务的执行时间的均值。
175 |
176 | **3.36 平均执行时间参考值(mean execution time reference value)**
177 |
178 | 模拟用户可接受的最大平均执行时间。
179 |
180 | **3.37 响应时间(response time)**
181 |
182 | 指用户发起一个请求开始,服务器完成对该请求的处理并返回处理结果所经过的时间。
183 |
184 | **3.38 观测期(observation period)**
185 |
186 | 为汇集(日志记载)用户评级或确认的测量结果而观测测量规程的时间区间。由评级区间和补充运行时间组成。
187 |
188 | **3.39 准备时间(perparation time)**
189 |
190 | 任务提交之前经历的时间。启动准备时间的事件取决于对后一任务的任务模式的界定。准备时间的值是带有界定的均值和标准差的分布式变量的随机值,这取决于后一任务的任务类型和生成此任务的模拟用户的类型。
191 |
192 | **3.40 评级区间(rating interval)**
193 |
194 | 测量规定从SUT达到操作稳定状态的时间开始,到测量结果满足所需统计显著性的时间为止的时间区间。
195 |
196 | **3.41 相对链频(relative chain frequency)**
197 |
198 | 第i型的模拟用户使用第l型链的相对频数。
199 |
200 | **3.42 稳定化阶段(stabilization phase)**
201 |
202 | 测量规程从RTE提交任务开始,到SUT达到稳定操作状态位置的时间区间。
203 |
204 | **3.43 补充运行时间(supplementary run)**
205 |
206 | 测量规程从测量结果达到满足所需统计显著性的时间开始,到评级期间已提交的所有任务全部完成时间为止的时间区间。
207 |
208 | **3.44 在测系统(system under test,SUT)**
209 |
210 | CBSS中接受测试的个部分。影响SUT时变行为的所有部件都应是SUT的组成部分,如果此种影响取决于某一工作负载,则该负载也应由RTE来标识。除非对时变行为的影响不可能或不明显时,对其余部分的模拟才可省略。
211 |
212 | **3.45 任务(task)**
213 |
214 | 特定活动,由特定适时性函数界定的所需执行时间,特定任务模式。
215 |
216 | **3.46 任务完成(task completion)**
217 |
218 | 对特定任务的如下适时时间:由模拟用户或另一实例全部收到整个输出串,或者在输出串集的情况,收到该集合的所有部分。该任务未向用户(即测量期间向RTE)提交输出时,可为该任务添加一个功能,即产生“人工输出”来指明该任务完成,供测量期间使用。
219 |
220 | **3.47 任务模式(task mode)**
221 |
222 | 对用户的准备时间是在前一任务提交后立即开始(值=0,即“不等待”)还是当前一任务完成时(任务完成)开始(值=1,即“等待”)所做的指示。
223 |
224 | **3.48 任务提交(task submission)**
225 |
226 | 当输入串完整的从模拟用户提交SUT时,该任务即可开始执行,而不管SUT是否立即执行的适时事件。任务提交还可通过这一任务的模拟用户行动结束时间来指示。根据本标准,任务提交不应该由以下事件来界定(和测量):SUT收到或解释完输出串,或模拟用户接收一个可由SUT在接收和解释之后送出的收据串。
227 |
228 | **3.49 任务类型(task type)**
229 |
230 | 任务所有分类:
231 |
232 | 活动类型,或属于同一实时性函数和任务模式的所有活动类型的集合;
233 |
234 | 适时性函数;
235 |
236 | 任务模式。
237 |
238 | **3.50 吞吐量(throughput)**
239 |
240 | 提交给SUT某一任务型所有任务的速率(即评级区间内单位时间的平均数)
241 |
242 | **3.51 吞吐量参考值(throughput reference value)**
243 |
244 | 实际吞吐量与吞吐量参考值之比(对应于第j任务型)
245 |
246 | **3.52 时间类别(time class)**
247 |
248 | 与一种相对频数相结合,用于和(特指任务型的)任务的执行时间相比较的时限。其中的相对频数对应于执行时间小于等于对应时限的(特定任务型的)任务数和(该特指任务型)任务总数之比。
249 |
250 | **3.53 实时吞吐量(timely throughput)**
251 |
252 | 对应于适时性函数,执行时得以接收的所有任务的吞吐量。
253 |
254 | **3.54 用户(user)**
255 |
256 | 通过终端(或等效的机器用户接口)使用CBSS功能来提交任务并接收算出结果的人(或实例)。
257 |
258 | **3.55 虚拟用户(virtual user)**
259 |
260 | 通过函数或任务模拟的方式完成等效机器用户接口功能,使用CBSS功能来提交任务并行接收算出结果的特定程序集合。
261 |
262 | **3.56 最大并发用户数(maximum number of concurrent users)**
263 |
264 | 系统能够承受的同时使用系统服务或资源的用户数的极限,超过该用户数,将导致系统效率严重下滑,并可能导致系统崩溃、失效。
265 |
266 | **3.57 最大并发请求数(maximum number of concurrent users)**
267 |
268 | 系统能够承受的同时接收到的请求数的极限,超过该请求数,将导致系统效率严重下滑,并可能导致系统崩溃、失效。
269 |
270 | **3.58 用户类型(user type)**
271 |
272 | 对由下列两项的组合所界定的模拟用户的一种分类:
273 |
274 | 使用链类型的相对频数;
275 |
276 | 准备时间(均值及其标准差)
277 |
278 | **3.59 事务(transaction)**
279 |
280 | 事务是脚本的一个特性,每个事务都包含开始事务和结束事务。事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。你可以将开始事务放置在脚本中某行代码的前面,将结束事务放置在该行代码的后面,在该脚本的虚拟用户运行时,这个事务将衡量该行代码的执行花费了多长时间。
281 |
282 | **3.60 事务吞吐容量(transaction throughput capacity)**
283 |
284 | 在一定的时间单位内,系统能够处理完成的最大事务量。
285 |
286 | **3.61 数据吞吐容量(data throughput capacity)**
287 |
288 | 在一定的时间单位内,系统能够处理完成的最大数据量。
289 |
290 | **3.62 延迟(delay)**
291 |
292 | 完成一个请求的延时。
293 |
294 | **3.63 业务交易(business transaction)**
295 |
296 | 业务交易分为业务层面和技术层面两种定义。业务层面交易是指完成一次完整的业务操作,技术层面的交易是指进行一次应用程序至应用程序、或者应用程序至数据库的系统操作。
297 |
298 | **3.64 CPU利用率(CPU utilization)**
299 |
300 | 系统或软件产品在运行过程中CPU的使用率。
301 |
302 | **3.65 内存利用率(Memory utilization)**
303 |
304 | 系统或软件产品在运行过程中内存的使用率。
305 |
306 | **3.66 传输利用率(transmission-untilization ratio)**
307 |
308 | 系统或软件产品在执行规定的数据传输功能时,传输吞吐率占传输设备最大传输吞吐率的百分比。
309 |
310 | **3.67 构建环境**
311 |
312 | 构建环境是指执行构建任务时所在设备的软件和硬件环境。
313 |
314 | **3.68 构建任务**
315 |
316 | 构建任务是指定义从输入到输出过程对构建环境、构建方法等必要因素的定义。
317 |
318 | **3.69 构建过程**
319 |
320 | 构建过程是指构建任务从开始执行到结束。
321 |
322 | **3.70 构建策略**
323 |
324 | 构建策略是指针对构建过程的特定结果设定的处理策略。
325 |
326 | **3.71 复刻(Fork)**
327 |
328 | 复刻是指在软件开发中,开发者为一个版本仓库创建一份拷贝,并在拷贝上进行独立于源版本仓库的开发,从而分离出一个新的软件副本的活动。复刻不仅仅创建了一个分支,还将软件开发活动与源版本库分离开来。
329 |
330 | **3.72 合并(Merge)**
331 |
332 | 是指当一个版本在多个独立分支中被修改后如何合并这些修改成为同一个版本的操作。
333 |
334 | **3.73 合并评审(Merge Requests)**
335 |
336 | 是指在合并之前,允许多人对合并时所提交的变更内容进行代码审查,并给予合并意见的过程。
337 |
338 | **3.74 基线(Baseline**
339 |
340 | 基线是版本仓库中每个版本在特定时期的一个“快照”。它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。
341 |
342 | **3.75 版本仓库(Repositories)**
343 |
344 | 版本仓库又称源代码仓库,被用来存储源代码等版本文件。
345 |
346 | **3.76 代码审查(Code Review)**
347 |
348 | 是指对计算机源代码系统化地审查,常用软件同行评审的方式进行,其目的是在找出及修正在软件开发初期未发现的错误,提升软件质量及开发者的技术。代码审查常以不同的形式进行,例如结对编程、非正式的看过整个代码等。
349 |
350 | **3.77 测试计划(Testing plan)**
351 |
352 | 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排,以及任何偶发事件的风险。
353 |
354 | **3.78 测试脚本(Testing script)**
355 |
356 | 一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。
357 |
358 | **3.79 构建任务 Build task**
359 |
360 | 作为一个构建软件的配置,以及流程。
361 |
362 | **3.80 凭据 Credentials**
363 |
364 | 保存用户保密信息,例如:用户名和密码。
365 |
366 | **3.81 运行环境 Runtime environment**
367 |
368 | 构建中运行的环境或者计算机
369 |
370 | **3.82 源代码托管软件 Source code management software**
371 |
372 | 保存源代码的软件
373 |
374 | **3.83 执行记录 Build history**
375 |
376 | 执行构建的信息,日志,以及结果。
377 |
378 | **3.84 构建产出物 Build output**
379 |
380 | 构建任务中生产的文件
381 |
382 | **3.85 软件单元测试 Software unit test**
383 |
384 | 软件中研发的自动化测试
385 |
386 | **3.86 静态源代码扫描 Static code analysis**
387 |
388 | 对源代码执行静态的分析,指出源代码质量(10.9)
389 |
390 | **3.87 (制品的)晋级 Promotion**
391 |
392 | 制品管理中,通常是指自构建产物通过某一级别质量关卡后,将其标记为更稳定状态的过程。例如从发布待定(release-candidate)升级为可发布(release)。晋级过程通常会伴随虚拟文件夹的切换。
393 |
394 | ## 4. 缩略语
395 |
396 | 下列缩略语适用于本文件。
397 |
398 | CI Continuous Integration 持续集成(样例)
399 |
400 | CD Continuous Delivery 持续交付(样例)
--------------------------------------------------------------------------------
/project_and_development_management.md:
--------------------------------------------------------------------------------
1 | ## 项目与开发管理
2 |
3 | ### 1. 项目管理(未确定编写专家)
4 |
5 | 项目管理xxxx。
6 |
7 | ##### 应包含以下基本功能:
8 |
9 | ——xxxx
10 |
11 | ——xxxx
12 |
13 | ##### 可以包含以下高级功能:
14 |
15 | ——xxxx
16 |
17 | ——xxxx
18 |
19 | ### 2. 需求管理(未确定编写专家)
20 |
21 | 需求管理是xxxx。
22 |
23 | ##### 应包含以下基本功能:
24 |
25 | ——支持需求的创建、修改、删除、查询管理
26 |
27 | ——支持需求的可视化管理,比如:看板、列表
28 |
29 | ——需求有优先级区分
30 |
31 | ——支持需求的指派、认领
32 |
33 | ——支持需求到期时间设置,到期未完成有预警
34 |
35 | ——支持需求依赖、关联
36 |
37 | ——支持需求变更历史的查看、追溯
38 |
39 | ——支持需求的导入、导出
40 |
41 | ——支持记录预计工时、实际工时
42 |
43 | ——支持拆分子需求
44 |
45 | ##### 可以包含以下高级功能:
46 |
47 | ——需求状态可自定义
48 |
49 | ——需求可新增自定义字段
50 |
51 | ——支持需求评审(审批)
52 |
53 | ——需求支持评价、留言
54 |
55 | ——关联查看对应的代码提交记录
56 |
57 | ——支持需求变更/指派/过期等消息【通知】机制
58 |
59 | ——支持需求工作流,工作流可控制状态流转方式和权限
60 |
61 | ### 3. 计划与任务管理
62 |
63 | 计划与任务管理是对于项目与开发过程中所有计划与任务的管理活动。
64 |
65 | ##### 应包含以下基本功能:
66 |
67 | ——开发计划管理宜支持看板协作项目计划管理与Scrum项目计划管理【仅描述看板协作与Scrum是否过于局限】
68 |
69 | —— 【**建议增加:任务需要与项目、需求、缺陷等关联**】
70 |
71 | ——支持迭代/里程碑规划,创建、修改、删除、查询
72 |
73 | ——支持面向任务及面向迭代的视图迭代规划
74 |
75 | ——支持展示按迭代/里程碑展示任务
76 |
77 | ——支持创建、修改、删除、查询任务管理
78 |
79 | ——任务参数字段宜包含:标题、类型、标签、描述、优先级、重要程度、处理人、抄送人、项目、状态、迭代、父任务项、计划日期、预计工时、实际工时、发布版本、附件、完成度。
80 |
81 | ——支持任务拆分子任务
82 |
83 | ——支持为任务添加关联任务
84 |
85 | ——支持任务指派、再指派、认领、二次认领
86 |
87 | ——支持记录任务的状态,如:未开始、进行中、已完成
88 |
89 | ——支持可视化的任务跟踪,如:看板
90 |
91 | ——支持任务列表的导入导出
92 |
93 | ——支持以树形视图或表格视图式呈现的任务项列表
94 |
95 | ——提供多维度的项目统计报表,展现项目宏观和微观进展
96 |
97 | ##### 可以包含以下高级功能:
98 |
99 | ——支持【任务/】迭代/里程碑关联源代码对应分支,关联对应分支的CI/CD运行结果
100 |
101 | ——支持【任务/】迭代/里程碑自定义配置关联的资源,如文档文件
102 |
103 | ——支持设置迭代/里程碑的查看、添加、修改、删除权限【**建议调整为统一功能**】
104 |
105 | ——支持批量编辑任务、任务处理人及状态
106 |
107 | ——支持任务添加富文本信息
108 |
109 | ——支持设置任务参数显示列【**建议更加清楚的描述**】
110 |
111 | ——支持设置任务上传附件的数量与大小【**建议删除**】
112 |
113 | ——支持对任务进行评论
114 |
115 | ——支持按自定义条件筛选任务集【**什么是任务集,且是否有必要将任务集群管理**】
116 |
117 | ——支持以看板、表格方式展示任务集
118 |
119 | ——支持以不同属性维度对任务集进行分组,排序后展示
120 |
121 | ——支持设置任务的查看、添加、修改、删除权限【**建议调整为统一功能**】
122 |
123 | ——支持任务配置状态工作流
124 |
125 | ——支持状态工作流设置状态变更权限
126 |
127 | ——支持任务变更/分派/逾期消息【通知】机制
128 |
129 | ——支持任务操作日志
130 |
131 | ——支持用户自定义仪表盘,将用户关注的信息整合到一个页面上显示
132 |
133 | ——提供二次开发的API接口
134 |
135 | ###
136 |
137 | ### 4. 文档与知识管理
138 |
139 | 文档与知识管理是对针对文档和知识的管理活动,应包含文档管理和知识管理两个部分。
140 |
141 | #### 4.1 文档管理
142 |
143 | 文档是产品交付的核心研发资产之一。常见文档类型包括架构设计文档、用户帮助手册、系统原型文档等。常见文档格式包括微软Office
144 | WORD/PPT/EXCEL、PDF、WPS Office文档、JPG等格式的图片文档。
145 |
146 | ##### 应包含以下基本功能:
147 |
148 | ——支持用户按照一定的目录结构对各种文档进行分门别类地管理
149 |
150 | ——支持通过批量上传本地目录或文件至文档管理服务中
151 |
152 | ——支持批量下载文档
153 |
154 | ——支持常见格式文档的在线预览
155 |
156 | ——支持文档版本管理,用户可以选择文档的某个版本进行过查看、下载等操作
157 |
158 | ——支持搜索功能,用户可以通过文件名或文件名关键字等快速查找到所需的文档
159 |
160 | ##### 可以包含以下高级功能:
161 |
162 | ——支持本地与远端文件的同步【**建议删除**】
163 |
164 | ——支持回收站功能,以防止用户误删除文档
165 |
166 | ——支持文档的在线编辑及多人并行编辑
167 |
168 | ——支持对文件内容进行搜索
169 |
170 | ——支持共享功能,可以在不同用户之间进行共享【**共享的含义比较模糊,是权限控制还是为分享?**】
171 |
172 | #### 4.2 知识管理
173 |
174 | 知识管理涵盖产品交付过程中个人或者团队的各种知识内容,例如会议纪要、版本ReleaseNotes、技术材料等等。
175 |
176 | ##### 应包含以下基本功能:
177 |
178 | ——支持词条创建、编辑
179 |
180 | ——支持多人协同编辑
181 |
182 | ——支持词条分享
183 |
184 | ——支持搜索
185 |
186 | ——可导出为常见文档格式(例如Word、pdf)
187 |
188 | ——宜支持Wiki格式
189 |
190 |
191 |
192 | ### 5. 团队协同
193 |
194 | 团队协同是将同一个开发组织内不同角色、不同个体、不同阶段的资源整合形成协同效应,可以增加研发组织的信息透明度和信息流动速度,实现组织决策的高效和准确性。
195 |
196 |
197 |
198 | ##### 应包含以下基本功能:
199 |
200 | ——支持将研发工作过程、工作结果在组织内进行公开展示
201 |
202 | ——支持将项目规划、需求、工作项、代码、测试用例、缺陷、构建任务、部署任务、流水线任务等向指定人员开放展示
203 |
204 | ——支持不同角色基于工件进行协作
205 |
206 | ——支持多角色协作进行分析需求、工作项流转、代码合并、主流代码分支模型、代码评审、多语言并行构建、依赖包管理、镜像仓库等工作
207 |
208 | ——支持团队仪表盘、项目仪表盘、可视化看板、Wiki、文档管理、Git代码仓库、聊天室等团队协同工具,以将度量数据标准化一致呈现给所有角色和个体、分享知识经验、信息透明传递。
209 |
210 | ——支持记录所有人在平台上的所有操作,以回溯经验和教训,并满足审计合规
211 |
212 | ##### 可以包含以下高级功能:
213 |
214 | ——xxxx
215 |
216 | ——xxxx
217 |
218 |
219 |
220 | ###
221 |
222 | ### 6. 统计度量
223 |
224 | 统计度量是对DevOps过程的进度、质量、效率相关数据化指标展示。
225 |
226 | ##### 应包含以下基本功能:
227 |
228 | ——进度相关指标【包含但不仅限于】:需求累计流图、缺陷趋势图、需求完成数、新建缺陷数。
229 |
230 | ——【董越】进度相关指标:包括但不限于需求累计流图、缺陷趋势图、需求完成数、新建缺陷数。
231 |
232 | ——代码内在质量相关指标【包含但不仅限于】:包括但不限于代码质量、千行代码bug率、缺陷Reopen率、测试通过率。
233 |
234 | ——【董越】代码内在质量相关指标:包括但不限于代码质量、千行代码bug率、缺陷Reopen率、测试通过率。
235 |
236 | ——交付外在质量相关指标【包含但不仅限于】:包括但不限于故障率、线上问题率、发布回滚率。
237 |
238 | ——【董越】交付外在质量相关指标:包括但不限于故障率、线上问题率、发布回滚率。
239 |
240 | ——需求交付时长相关指标【包含但不仅限于】:需求从提交到交付的时长。
241 |
242 | ——【董越】需求交付时长相关指标:包括但不限于需求从提交到交付的时长。
243 |
244 | ——缺陷解决时长相关指标【包含但不仅限于】:包括但不限于缺陷从创建到关闭的平均时长,表征解决缺陷的效率。
245 |
246 | ——【董越】缺陷解决时长相关指标:包括但不限于缺陷从创建到关闭的平均时长,表征解决缺陷的效率。
247 |
248 | ——代码交付时长相关指标【包含但不仅限于】:代码从提交到交付的时长。
249 |
250 | ——【董越】代码交付时长相关指标:包括但不限于代码从提交到交付的时长。
251 |
252 | ——人效相关指标【包含但不仅限于】:对使用人员的基本产出能力度量, 包括但不限于完成需求数、解决缺陷数、完成任务数、提交代码量。
253 |
254 | ——【董越】人效相关指标:对使用人员的基本产出能力度量, 包括但不限于完成需求数、解决缺陷数、完成任务数、提交代码量。
255 |
256 | ——【董越】统计度量的维度:项目维度的统计和度量。个人维度的统计和度量。(项目维度和个人维度等描述不好理解9.27)
257 |
258 | ——【董越】统计度量的维度【包含但不仅限于】:项目维度的统计和度量,即统计特定项目的进度、需求交付时长等相关指标。个人维度的统计和度量,即统计特定个人的代码内在质量、人效等相关指标。(项目维度和个人维度等描述不好理解9.27)
259 |
260 | ——【董越】统计度量的维度:项目维度的统计和度量,即统计特定项目的进度、需求交付时长等相关指标。个人维度的统计和度量,即统计特定个人的代码内在质量、人效等相关指标。
261 |
262 | ##### 可以包含以下高级功能:
263 |
264 | ——进度相关指标:迭代燃尽图、需求控制图。【这是展示方式不是指标】
265 |
266 | ——【董越】进度相关指标:通过迭代燃尽图、需求控制图等方式展示。
267 |
268 | ——需求交付时长相关指标:对需求每个阶段的度量,包括但不限于需求响应时长、需求分析时长、需求设计时长、需求排期时长、需求开发时长。通过各种时长,能够定位需求交付瓶颈角色,用于改进。
269 |
270 | ——代码交付时长相关指标:对交付上线的每个阶段进行分解。包括但不限于代码提交、构建、单测、集成、部署、集成测试时长、等待时长。能够定位和反交付过程中的各个步骤,用于改进交付过程。
271 |
272 | ——人效相关指标:人力分配和人力负载的度量。人力分配:包括但不限于每个项目的真实人员投入量。人力负载:包括但不限于项目并发度、需求并发度。
273 |
274 | ——统计度量的维度:组织维度的统计和度量,即从企业组织架构和团队维度提供整体的统计和客观的分析。【董越】应用交付过程的效率和质量透明。应用维度的度量,即应用交付过程的效率和质量透明。
275 |
276 | ###
277 |
278 | ### 7. 项目集管理
279 |
280 | 项目集管理对项目集运作过程中,项目、子项目集的运作情况进行管理的活动。
281 |
282 | ##### 应包含以下基本功能:
283 |
284 | ——项目集中可以包含多个项目和子项目集
285 |
286 | ——设置项目集PM,以及其他参与人
287 |
288 | ——设置以及展示项目集的进度、健康度【**请详细解释设置的含义,由于与任务与计划管理中进度相关联**】
289 |
290 | ——设置里程碑,分配负责人【**项目集有里程碑吗?**】
291 |
292 | ——录入需求、任务【**建议调整为录入或关联需求与任务**】
293 |
294 | ——填写及展示项目集的进度、健康度
295 |
296 | ——录入或关联需求任务
297 |
298 | ——记录跟踪项目集风险【**请解释如何进行风险管理**】
299 |
300 | ——展示它包含的所有项目或项目集的进展情况
301 |
302 | ——里程碑快到期发送消息通知给PM和里程碑负责人。
303 |
304 | ##### 可以包含以下高级功能:
305 |
306 | ——项目或项目集,可以属于多个项目集;
307 |
308 | ——树形展示项目集中包含的项目和子项目集,子项目集可以逐层下钻;
309 |
310 | ——包含的项目和子项目集中的里程碑和需求任务等在同一甘特图中展示;
311 |
312 | ——根据里程碑进展、需求任务完成情况,以及包含项目和子项目集的进度和健康度,自动计算项目集的进度和健康度;
313 |
314 | ——汇总包含的项目和子项目集中的需求、任务、风险;【**是否有必要?**】
315 |
316 | ——包含的项目和子项目集中的风险,可以自行决定是否透出到项目集中;
317 |
318 |
--------------------------------------------------------------------------------
/security_delivery.md:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/512mouse/09-devops-system-tool/ac8ac26863e68d3007537791a82b4ba3fccaa4d5/security_delivery.md
--------------------------------------------------------------------------------
/security_development.md:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/512mouse/09-devops-system-tool/ac8ac26863e68d3007537791a82b4ba3fccaa4d5/security_development.md
--------------------------------------------------------------------------------
/test_automation.md:
--------------------------------------------------------------------------------
1 | ## 自动化测试
2 |
3 | ### 1. 代码质量管理
4 |
5 | 代码质量管理xxxx。
6 |
7 | ##### 应包含以下基本功能:
8 |
9 | ——xxxx
10 |
11 | ——xxxx
12 |
13 | ##### 可以包含以下高级功能:
14 |
15 | ——xxxx
16 |
17 | ——xxxx
18 | ### 1. 静态代码检查
19 | 静态代码检查是持续交付流水线中的一个重要环节,利用商用/开源/自研的代码检查工具在开发阶段发现缺陷,让缺陷在最短路径闭环。
20 |
21 | ##### 应包含以下基本功能:
22 |
23 | ——对代码进行静态扫描,发现代码缺陷、安全漏洞及编程规范、重复代码、复杂度高等代码坏味道问题
24 |
25 | ——能够自动触发/立即分析/定时开展,实时展示扫描进展状态,及时反馈代码检查结果
26 |
27 | ——方便查看告警及错误代码片段,提供规则描述及告警修复指导
28 |
29 | ——检查结果有优先级/严重程度的划分,能跟踪到状态
30 |
31 | ——支持检查规则配置,支持单个告警/批量告警/告警路径屏蔽等功能
32 |
33 | ——自动生成代码检查报告,有新增/修复/遗留告警等质量度量指标
34 |
35 | ——多种工具检查结果能够整合展示在报告中便于开发团队修复
36 |
37 | ##### 可以包含以下高级功能:
38 |
39 | ——能够开展增量代码扫描,自动识别问题引入者
40 |
41 | ——能够集成进IDE中在编码更前端开展检查
42 |
43 | ——根据项目实际场景支持检查规则定制
44 |
45 | ——支持和缺陷管理系统打通,具备跟踪和驱动修复的能力
46 |
47 | ——代码检查报告中自动生成新增/修复/遗留告警趋势量化展示项目代码质量状态
48 |
49 | ——代码检查工具支持集成到持续交付流水线中自动运行实施
50 |
51 | ——支持配置项目代码质量符合度标准,在流水线中自动化实施,作为下一个环节的准入条件
52 |
53 | ### 2. 单元测试
54 |
55 | 单元测试是项目的开发质量管理活动。单元测试具备自动化、独立性、可重复执行的特点。
56 |
57 |
58 | ##### 应包含以下基本功能:
59 |
60 |
61 | ——每个CASE有assert 来验证
62 |
63 | ——单元测试的CASE有手工编写和自动化生成2种,文件名要区分
64 |
65 | ——每个单元测试CASE执行时间不超过1秒,可以指定超时时间。
66 |
67 | ——单元测试的报告中必须有分支覆盖率,CASE总数,成功执行总数,失败总数,异常总数,执行跳过总数
68 |
69 | ——单元测试和源代码用目录结构区分开
70 |
71 | ——使用单元测试框架
72 |
73 | ——支持排除目录文件
74 |
75 | ——单元测试支持修改记录
76 |
77 | ——单元测试支持评审记录,和源代码评审保持一致。
78 |
79 |
80 |
81 | ##### 可以包含以下高级功能:
82 |
83 | ——使用MOCK
84 |
85 | ——单元测试的参数范围支持开发和测试提供的数据范围
86 |
87 | ——使用工具自动化生成单元测试
88 |
89 | ——单元测试支持并行运行
90 |
91 | ——单元测试数据支持来自NLP分析得到的数据
92 |
93 | ### 3. 接口/服务测试
94 |
95 | 接口测试是通过直接在消息层向测试软件接口,确定功能、性能、可靠性、安全等是否满足预期的软件测试方法。REST风格接口是Web应用前后端和微服务之间主要的接口形式。
96 |
97 | ##### 应包含以下基本功能:
98 |
99 | ——支持针对REST风格接口的测试
100 |
101 | ——支持HTTP、HTTPS协议GET、POST、PUT、DELETE等主要方法的测试
102 |
103 | ——支持基于Swagger或Open API文档辅助编写接口测试逻辑(建议放到高级)
104 |
105 | ——支持基于录制的接口请求和响应生成测试逻辑(建议放到高级)
106 |
107 | ——支持定义HTTP请求的URL、请求头、请求报文
108 |
109 | ——支持表单、文本、JSON、XML等多种格式的请求报文
110 |
111 | ——支持Basic认证、Token认证等接口鉴权认证方式
112 |
113 | ——支持针对HTTP响应的响应报文、响应头、响应码定义测试断言
114 |
115 | ——支持提取HTTP响应的内容,基于上下文创建后续HTTP请求
116 |
117 | ——支持循环、判断、暂停等测试逻辑 (建议描述为接口测试流程控制)
118 |
119 | ——支持定义不同测试环境的测试参数
120 |
121 | ——支持测试关键字,以复用测试逻辑(术语中增加关键字驱动,复用测试逻辑建议作为单独特性)
122 |
123 | ——支持测试套件编排测试用例串行顺序执行或并行执行(可能不是接口测试专有特性)
124 |
125 | ——支持调试测试用例,以验证测试逻辑(可能不是接口测试专有特性)
126 |
127 | ——支持记录测试执行日志和结果(可能不是接口测试专有特性)
128 |
129 | ——支持定义接口Mock,以解耦开发和测试依赖(目的建议去掉)
130 |
131 | ——支持流水线调用接口测试实现持续集成和持续测试
132 |
133 | ——支持接口测试覆盖率和测试通过率统计
134 |
135 | 专家评审:
136 | 1、rest风格描述过细,其它接口测试没有提到;
137 |
138 | ##### 可以包含以下高级功能:
139 |
140 | ——xxxx
141 |
142 | ——xxxx
143 |
144 | ### 4. UI测试
145 |
146 | UI测试是用户界面测试,英文名为User interface testing的简称。它通过浏览测试对象可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法 (Tab 键、鼠标移动和快捷键)的使用,且窗口的对象和特征都符合需求。
147 |
148 | ##### 应包含以下基本功能:
149 |
150 | ——在实际运行环境或模拟器中打开被测对象
151 |
152 | ——模拟用户通过键盘、鼠标等进行的人机交互操作
153 |
154 | ——被测对象的内容和属性的检查
155 |
156 | ——测试步骤局部修改
157 |
158 | ——测试过程用例管理
159 |
160 | ——测试过程的本地回放、执行
161 |
162 | ##### 可以包含以下高级功能:
163 |
164 | 可以包含以下高级功能:
165 |
166 | ——测试过程局部调试
167 |
168 | ——自动录制测试过程
169 |
170 | ——参数化测试过程中相应数据
171 |
172 | ——被测对象相应内容(文案、数值等)支持数据库对比
173 |
174 | ——重复过程的公共方法
175 |
176 | ——支持一套脚本在不同环境(如本地开发环境、云端测试环境等)中执行
177 |
178 | ——支持对云端执行的测试任务的管理
179 |
180 | ——定时执行
181 |
182 | ### 5. 移动应用测试
183 |
184 | 移动应用测试是指针对市场主流移动端(Android、iOS、H5、小程序等)利用自动化技术进行功能性和各项非功能性专项测试。包含适配兼容测试、移动自动化测试、客户端性能测试三大类测试。
185 |
186 | #####适配兼容测试
187 |
188 | 适配兼容测试利用移动终端真机实验室,移动应用需要在各种参数搭配的机型上进行测试,以确保移动应用兼容用户使用的手机机型, 最大化客户群体。
189 |
190 | ##### 应包含以下基本功能
191 |
192 | ——按需的机型选择
193 | a)Android/iOS操作系统版本
194 | b)主流厂商的定制ROM
195 | c)屏幕分辨率
196 | d)硬件配置(CPU、GPU、内存)
197 | e)市场Top用户占比机型
198 | f)支持自选机型
199 | 针对H5
200 | g)各大厂商的浏览器和内核
201 | h)WebView(如微信)
202 |
203 | ——安装、拉起、Monkey遍历、卸载
204 |
205 | ——适配问题的检测能力(崩溃、无响应、安装失败、拉起失败、卸载失败、UI异常、Exception)
206 |
207 | ——测试执行步骤的还原(操作和截图)
208 |
209 | ——基础性能指标采样(安装时间、启动时间、CPU、内存、流量、FPS)
210 |
211 | ——系统日志的收集
212 |
213 | ##### 可以包含以下高级功能:
214 |
215 | ——用户账户自动登录
216 |
217 | ——支持运行主流自动化框架(如Appium、UIAutomator、XCTest)和自定义框架编写的兼容测试脚本(主流自动化框架,建议举例或修改描述,安卓官方、或苹果官方?此处是否体现自定义框架?已修改)
218 |
219 | ——支持自定义日志上报和导出
220 |
221 | ——支持API接口提交任务和接口文档
222 |
223 | ——能够对出现具体问题的设备进行远程调试
224 |
225 | ##### 移动自动化测试:
226 |
227 | 移动自动化测试,英文名为Mobile Test Automation的简称,它是将移动应用作为测试对象,把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计与编写用例脚本后,由测试人员上传至移动终端真机实验室自动执行测试,得到实际结果与期望结果的对比评估。在此过程中,达到节省人力、时间或硬件资源,增强测试深度,提高测试效率等效果。
228 |
229 | ##### 应包含以下基本功能
230 |
231 | ——支持通用的自动化测试框架
232 |
233 | ——模拟用户对应用的操作(点击、滑动、长按、轨迹操作、文本输入等)
234 |
235 | ——基本的识别能力(标准控件识别)
236 |
237 | ——测试信息管理能力(用例、日志、缺陷、报告)
238 |
239 | ——移动设备的管理运维能力(故障等重连、重测机制,设备稳定性)
240 |
241 | ##### 可以包含以下高级功能:
242 |
243 | ——支持用户修改过的开源框架
244 |
245 | ——提供插件集成到开发IDE中
246 |
247 | ——提供丰富的Open API(包含设备信息获取,筛选,提测,结果拉取等灵活,详细的API能力)
248 |
249 | ——在云端设备上进行脚本调试
250 |
251 | ——进阶的识别能力(OCR识别,UI识别,游戏引擎层控件识别等)
252 |
253 | ——脚本录制及精准回放能力
254 |
255 | ——任务运行可视化及灵活干预能力(以单台设备为粒度进行终止、重测等干预操作)
256 |
257 | ——性能数据采集调试能力(包含FPS、内存等通用性能,以及引擎层的性能)
258 |
259 | ——云端设备灵活配置和高效调度能力
260 |
261 | ##### 客户端性能测试:
262 | 客户端性能测试利用移动终端真机实验室,通过在不同参数搭配的各档机型上利用性能测试工具获得各项性能指标,定位性能瓶颈和问题根本原因,提升移动应用的性能表现,以保障用户获得流畅、稳定的最佳使用体验。
263 |
264 | ##### 应包含以下基本功能
265 |
266 | ——机型性能天梯(机型分档)
267 |
268 | ——基础性能指标采样(安装时间、首屏时间、响应时间(启动、滑动、界面切换等)、CPU、内存、流量、FPS、耗电量、温度、IO)-客户端必要的指标
269 |
270 | ——测试执行步骤的还原(操作和截图)
271 |
272 | ——系统日志的收集
273 |
274 | ——测试报告的导出
275 |
276 | ##### 可以包含以下高级功能:
277 |
278 | ——支持运行主流自动化框架(如Appium、UIAutomator、XCTest)和自定义框架获取性能数据(跟前面的主流自动化框架描述问题一样已修改)
279 |
280 | ——支持版本对比、竞品对比
281 |
282 | ——支持API接口批量获取性能数据
283 |
284 | ——过度绘制检测
285 |
286 | ——支持性能问题根因分析
287 |
288 | ——支持多性能指标组合分析(建议高级增加 支持性能指标组合分析已添加)
289 |
290 | ——针对游戏提供unity3d,unreal 4引擎的深度性能数据
291 |
292 | ——针对H5提供瀑布流视图,连接视图,提供实时抓包、修改功能
293 |
294 | 专家评审:
295 | 1、建议高级增加 支持性能指标组合分析
296 |
297 |
298 | ### 6. 性能测试
299 |
300 | 性能测试xxxx。
301 |
302 | ##### 应包含以下基本功能:
303 |
304 | ——支持性能测试项目的测试脚本、测试结果、测试报告的基本管理功能;
305 |
306 | ——支持主流测试协议;
307 |
308 | ——支持负载参数集读取数据文件功能;
309 |
310 | ——支持负载参数集自动生成序列数字、随机数字等功能;
311 |
312 | ——负载参数集数据读取支持:顺序、随机、数据文件读取、数据文件分段读取、文件读取的功能;
313 |
314 | ——支持脚本逻辑控制功能,脚本编辑功能;
315 |
316 | ——支持性能测试结果数据输出,包括测试发送数据及服务端响应数据等;
317 |
318 | ——支持思考时间设置功能;
319 |
320 | ——支持请求超时、响应超时设置功能;
321 |
322 | ——支持性能测试执行过程中服务端回送数据正确性检查的功能;
323 |
324 | ——支持长连接、短连接设置;
325 |
326 | ——支持数据上下文关联的功能;
327 |
328 | ——支持性能测试场景设置功能,性能场景:性能测试过程中模拟真实用户的服务流程或业务处理过程的一系列动作的集合;
329 |
330 | ——支持性能测试指标数据实时输出的功能;
331 |
332 | ——支持性能测试报告查看及导出功能;
333 |
334 | ——支持采集性能监控指标的功能;
335 |
336 | ——支持性能测试过程中各类错误显示、汇聚的功能;
337 |
338 | ——HTTP、HTTPS协议应支持GET、POST方法的测试;
339 |
340 | ——支持HTTP协议COOKIE设置;
341 |
342 | ##### 可以包含以下高级功能:
343 |
344 | ——当分布式压力源未用尽时,系统支持多个测试用户同时调用压力源发起性能测试直到压力资源满载;
345 |
346 | ——支持多种协议的性能测试;
347 |
348 | ——支持自定义协议的性能测试;
349 |
350 | ——支持测试数据集可通过脚本或程序灵活生成;
351 |
352 | ——支持从数据库中自动读取负载参数集的功能;
353 | (这类需求的适用场景相对狭窄,且产品自研的实现成本非常高,我们对它是否需要写进一个国家标准存疑)
354 |
355 | ——支持灵活配置、快速扩充压力源的功能;
356 |
357 | ——支持测试节点调用互联网公有云资源、局域网私有云资源、或其它可用的虚拟及物理资源;
358 |
359 | ——支持相同测试场景执行报告比对功能;
360 |
361 | ——支持采集各种性能指标的功能,如:网络通信指标、中间件指标、数据库指标等;
362 |
363 | (如果全部都要采集实现成本非常高,且系统本身已经有替代功能。是否有必要写进国标?
364 |
365 | 如果坚持要写,那么希望可以列清楚需要具体需要采集哪些)
366 |
367 | ——支持可配置的性能测试挡板。性能测试挡板:在跨系统测试中由于客观原因等无法模拟全部测试流程中的非主要测试系统资源,故通过软件或程序来模拟其他相关系统的操作,该软件或程序称之为挡板,主要目的是保证测试流程的完整性;(希望可以把“挡板”的解释放进“术语定义”章节)
368 |
369 | ——支持集成外部工具进行性能分析;(是进行“性能测试”还是“性能分析”?如果是性能分析,主要是指哪个层面?)
370 |
371 | ——HTTP、HTTPS高级功能支持OPTIONS、HEAD、PUT、DELETE、TRACE、CONNECT方法的测试;(从经验来看,用户较少用这些方法,是否需要都加上?用户基本用不上,且实现这个功能没什么技术难度,对于产品来说,这个应该算不上加分项。)
372 |
373 | ——HTTP、HTTPS、Socket协议支持脚本自动化录制、回放功能;(加列了socket协议的原因是?如果加上socket,那TCP、PB的录制是否也需要加上?)
374 |
--------------------------------------------------------------------------------
/test_management.md:
--------------------------------------------------------------------------------
1 | ## 测试管理
2 |
3 | ### 1. 用例与测试计划管理
4 |
5 | 用例与测试计划管理是对用例与测试计划的管理活动,包含用例管理和测试计划管理两大部分。
6 |
7 | ### 1.1 用例管理
8 |
9 | 用例管理是对用例集、子用例集和用例的管理活动。
10 |
11 | ##### 应包含以下基本功能:
12 |
13 | ——用例集中可以包含多个用例和子用例集
14 |
15 | ——树形展示用例集中包含的用例和子用例集,子用例集可以逐层下钻
16 |
17 | ——设置用例的测试步骤,包括步骤描述、输入测试数据,期望结果
18 |
19 | ——用例支持不同的优先级、重要程度。
20 |
21 | ——可以区分手工和自动化用例
22 |
23 | ——用例集、子用例集和用例支持标签分类
24 |
25 | ——支持用例集、子用例集、用例和版本、需求、特性、故事关联
26 |
27 | ——支持自动化测试用例和测试脚本关联
28 |
29 | ##### 可以包含以下高级功能:
30 |
31 | ——用例或子用例集,可以属于多个用例集
32 |
33 | ——支持在用例上添加附件
34 |
35 | ——不创建测试计划情况下用例可以随机执行
36 |
37 | ——可以从用例关联到测试计划
38 |
39 | ——支持对版本、需求关联用例的统计分析
40 |
41 | ——支持对用例执行情况的统计分析
42 |
43 | ### 1.2测试计划管理
44 |
45 | 测试计划管理是对测试计划的管理活动。
46 |
47 | ##### 应包含以下基本功能:
48 |
49 | ——支持测试计划创建和变更
50 |
51 | ——可以将用例集、子用例集和用例添加到计划以关联到用例
52 |
53 | ——可以按照标签批量添加用例集、子用例集和用例
54 |
55 | ——测试计划可以支持多轮次执行
56 |
57 | ——计划执行可以设置测试版本、测试环境、测试周期
58 |
59 | ——计划执行支持不同用例给不同测试人员执行,可以是指派或认领方式
60 |
61 | ——计划执行测试人员可以反馈用例的测试结果,自动给出计划执行进展和结果
62 |
63 | ——测试用例可以反馈失败原因
64 |
65 | ——失败原因是版本故障的用例,可以关联到缺陷
66 |
67 | ——可以对测试计划执行情况统计分析
68 |
69 | ##### 可以包含以下高级功能:
70 |
71 | ——测试计划可以直接从需求自动添加关联的测试用例
72 |
73 | ——支持将测试用例设置到不同的测试环境执行
74 |
75 | ——用例执行测试时可以针对每个测试步骤测试并反馈结果
76 |
77 | ——自动化用例可以驱动测试工具执行脚本并自动反馈测试结果
78 |
79 | ——自动化用例驱动测试工具执行后可以自动分析用例的失败原因
80 |
81 | ——测试计划执行自动化用例对接测试工具具有可扩展性
82 |
83 | ——失败原因是版本故障的用例,可以自动向缺陷管理系统提交缺陷
84 |
85 | ——可以基于版本、需求对测试计划执行情况统计分析
86 |
87 | ——可以对测试计划执行效率进行统计分析
88 |
89 | ### 2. 缺陷管理
90 |
91 | 专家建议:严重程度放到基本功能里面。-已改
92 | 缺陷管理是指在软件生命周期中识别、管理、沟通任何缺陷的过程,确保缺陷从被识别到解决关闭的过程被跟踪管理而不丢失。应包含以下基本功能:
93 |
94 | ##### 应包含以下基本功能:
95 | ——【董越】标记缺陷优先级;
96 |
97 | ——【董越】标记缺陷优先级和严重程度;
98 |
99 | ——将缺陷指派给特定的人;
100 |
101 | ——标记缺陷的不同状态,状态覆盖从新建到解决关闭的整个过程。
102 |
103 | ——缺陷可以关联截图、视频等;
104 |
105 | ——可区分缺陷类型;
106 |
107 | ——可按解决者、作者、优先级严重程度、当前状态等字段过滤;
108 |
109 | ——缺陷可关联到需求和用例;
110 |
111 | ##### 可以包含以下高级功能:
112 |
113 | ——可添加评论;
114 |
115 | ——指派缺陷、更改缺陷状态,发送消息给相关人员;
116 |
117 | ——缺陷可关联到修复该缺陷的代码。
118 |
119 | ——可过滤未关联需求或用例的缺陷。
120 |
121 | 专家评审:
122 | 基本功能:
123 | 1、文本框不需要具体讲
124 | 2、缺陷可以关联截图、视频等
125 | 3、过滤建议放到基本
126 | 4、建议增加 记录缺陷关联到的需求和用例
127 | 5、建议增加 缺陷分类属性?
128 | 高级功能:
129 | 1、权限控制属于通用的,是不是需要单独提出?
130 | 2、高级5建议去除?
131 | 3、可以过滤未关联用例和需求的缺陷;
132 |
133 | ### 3. 测试数据管理
134 |
135 | 测试数据管理指的是针对测试过程中所使用和产生的数据进行的管理。
136 |
137 | ##### 应包含以下基本功能:
138 |
139 | ——支持基于CSV、关系型数据库、文档数据库等类型的数据源提取生成测试数据
140 |
141 | ——支持录制接口请求和响应生成测试数据
142 |
143 | ——支持定义测试数据的元数据信息
144 |
145 | ——支持创建和编辑CSV形式的测试数据
146 |
147 | ——支持把CSV、关系型数据库、文档数据库等作为外部存储库存储测试数据
148 |
149 | ——支持设置规则批量生成测试数据
150 |
151 | ——支持使用脚本语言批量生成测试数据
152 |
153 | ——支持按照指定逻辑提取测试数据
154 |
155 | ——支持按照指定逻辑转换测试数据
156 |
157 | ——支持按照指定样式展示测试数据
158 |
159 | ——支持发现、清洗、保密敏感数据
160 |
161 | ——支持测试数据回滚
162 |
163 | ——支持分环境管理测试数据
164 |
165 | ——支持手工测试、自动化测试、Mock引用测试数据
166 |
167 | 专家评审:
168 | 1、建议不独立成章,可放到环境管理中;
169 |
170 | ##### 可以包含以下高级功能:
171 |
172 | ——xxxx
173 |
174 | ——xxxx
175 |
--------------------------------------------------------------------------------
/toolset.md:
--------------------------------------------------------------------------------
1 | # 研发运营一体化(DevOps)能力成熟度模型 第9部分:系统和工具
2 |
3 | 研发运营一体化(DevOps)能力成熟度模型 第9部分:系统和工具(DevOps 产品标准)属于研发运营一体化(DevOps)能力成熟度模型系列标准的一部分,旨在通过行业的力量,规范化DevOps产品的功能特性,帮助企业建设、选型和购买DevOps产品工具。
4 |
5 | 本标准由DevOps标准工作组下DevOps产品工作小组负责编写和维护。
6 |
7 | ### 工具箱列表
8 |
9 | 说明:如果该工具
10 |
11 | #### 1. [项目与开发管理](project_and_development_management.md)
12 |
13 |
14 | | 项目管理 | 需求管理 | 计划与任务管理 | 文档与知识管理 | 团队协同 | 统计度量 | 项目集管理 |
15 | | --------------------- | --------------------------- | --------------------- | --------------------------- | ------------------- | --------------------- | ---------------------- |
16 | | JIRA
(国外/商业) | JIRA+Confluence | JIRA | Confluence | Slack | Hygieia
(国外/开源) | Portfolio
for Jira |
17 | | Redmine | 百度:iCafe | 华为DevCloud:项目管理 | 华为DevCloud:Wiki和文档管理 | 华为DevCloud:HiChat | MirrorGate | 华为DevCloud:项目管理 |
18 | | 华为DevCloud:项目管理 | 华为DevCloud:项目管理 | 阿里云效:项目协作 | ONES Project | Mattermost | 华为DevCloud:项目管理 | 阿里云效:项目协作 |
19 | | 阿里云效:项目协作 | 阿里云效:项目协作 | ONES Project | | | CloudBees DevOptics | Oracel Primavera |
20 | | ONES Project | ONES Project | MS Project | | | JIRA EasyBI | |
21 | | | Rational RequisitePro/DOORS | | | | | |
22 |
23 |
24 |
25 | #### 2. [应用设计与开发](application_design_and_development.md)
26 |
27 | | 应用框架 | 云IDE |
28 | | -------- | ------------- |
29 | | Dubbo | AWS Cloud9 |
30 | | TARS
(国产/开源) | Eclipse Che |
31 | | EDAS |Codenvy |
32 | | 灵雀云(Alauda EE PaaS) | 华为DevCloud:CloudIDE
(国产/商业) |
33 | | 华为云 ServiceStage | Coding:WebIDE |
34 | | EMAS | OrionHub |
35 | | 谐云(观云台) | |
36 |
37 | #### 3. [持续交付](continuous_delivery.md)
38 |
39 | | 源代码管理 | 构建管理 | 持续集成 | 流水线 | 制品管理 | 发布管理 | 环境管理 | 数据管理 | 应用配置管理 |
40 | | ----------- | -------- | -------- | ------ | -------- | -------- | -------- | -------- | :----------: |
41 | | Github | | | | | | | | 携程Apollo |
42 | | Gitlab:代码 | | | | | | | | |
43 |
44 | #### 4. [测试管理](test_management.md)
45 |
46 | | 用例与测试计划管理 | 缺陷管理 | 测试数据管理 |
47 | | ------------------ | -------- | ------------ |
48 | | | JIRA | |
49 | | | | |
50 |
51 | #### 5. [自动化测试](test_automation.md)
52 |
53 | | 代码质量管理 | 单元测试 | 接口/服务测试 | UI测试 | 移动应用测试 | 性能测试 |
54 | | ------------ | -------- | ------------- | ------ | ------------ | -------- |
55 | | SonarQube | | | | | |
56 | | | | | | | |
57 |
58 | #### 6. 技术运营(待定)
59 |
60 | #### 7. [安全开发](security_development.md) \ [安全交付](security_delivery.md) \ 安全运营
61 |
62 | | 安全开发 | 安全交付 | 安全运营 |
63 | | -------- | -------- | -------- |
64 | | | | |
65 | | | | |
66 | | | | |
67 |
68 |
69 |
70 |
71 |
72 |
--------------------------------------------------------------------------------