0. 简介

在开发大型的机器人工程时候,我们会发现团体开发以及代码的review的会非常重要。而这些离不开敏捷开发(Scrum)以及Git管理。而最常用敏捷开发流程就是DoD。本文也将介绍和学习这种方式,来辅助各位能够在实验室和工作中团体开发中有效的管理自己以及团队。

1. 常见的迭代DoD条款

  1. 所有完成的用户故事得到PO的验证
  2. 所有代码得到静态分析,纠正最高级别的不符合项
  3. 所有新增代码得到人工评审
  4. 所有完成的用户故事都有对应的测试用例

早期的迭代成果一般是为了内部或者可控范围内的展示,相对发布而言,要求较低,所以适用时间箱方法,当然迭代本身就是时间箱,迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处,在这样的安排下,回归覆盖率就应当是一个变量,用于观察,而不应当是一个要求指标。
在这里插入图片描述

2. DoR与DoD

2.1 就绪定义(Definition of Ready,DoR)

DoR是指一个需求能够被团队接受的标准,认为该需求已经准备就绪,并可以流入到研发的任务队列中,是需求准入的标准。该方式可以有效防止“低质量需求”流入研发侧,产生浪费!DoR是研发侧针对策划的要求。

2.2 完工定义(Definition of Done,DoD)

DoD的目的就是为了让大家对“完成”的标准有一个统一的认知,防止理解偏差。可以拆分成不同的维度去定义。

对于DoD的制定,不同的DoD任务需要有不一样的需求:

产品需求 / 用户故事 DoD
a)用户故事的描述及拆解符合INVEST
b)用户故事有验收标准AC(Acceptance Criteria)

产品开发任务 DoD
a)代码已经提交到代码库
b)代码通过单元测试
c)代码经过Code Review
d)代码通过集成测试

产品迭代 DoD
a)所有代码通过静态检测,严重问题都已修改
b)所有新增代码都经过Code Review
c)所有完成的用户故事都通过测试
d)所有完成的用户故事得到PO的验证

产品发布 DoD
a)完成发布规划所要求的必须具备的需求
b)至少完成一次全量回归测试
c)符合质量标准(Quality Gate),所有等级为1、2的缺陷均已修复;3、4级缺陷不超过10个
d)发布通知(Release Notes)
e)有用户手册
f)产品相关文档已全部更新
g)代码已部署到发布服务器上,并冒烟通过
h)原始需求提交完成UAT
i)对运维、市场、客服的新功能培训已完成

3. 来自个人的日常DoD与每周DoD

3.1 日常DoD

每日DoD,该DoD适用于研发人员的每日工作,其条款有:

  1. 搭建每日构建环境,晚上自动静态代码检查、编译、部署和测试,每日修复前一日构建和测试发现的缺陷和问题。
  2. 下班前必须检入当天书写的代码
  3. 当天的代码必须在当天或者第2天邀请同伴进行代码评审
  4. 搭建持续集成环境,当天上下午必须至少各检入代码一次(这与第1条可能冲突)
  5. 凡是检入的功能代码必须要有对应的单元测试

3.2 每周DoD

如果工作量过于庞大,无法在1天之内开发测试完成,开展每周全量回归自动化测试,这样就有每周DoD,典型条款有:

  1. 上上周发现的缺陷是否解决
  2. 上周新增功能的自动化测试是否加入到每周测试集。

4. 开发过程中的测试

单元测试
开发阶段,开发人员代码级别的测试

功能测试
某个功能或特性完成后,测试人员对这个功能或特性进行的单独的测试。在这个阶段,一般功能不会互相影响,测试的关注点比较单一

回归测试
对于已经实现的功能进行的测试,这个功能已经经过了一轮或者多轮测试,回归测试用于保证这些功能的完整性

可用性测试和冒烟测试
这里的可用性测试很多人称为Sanity Test,可用性测试的目的主要是保证代码的提交不会对软件产生影响,而冒烟测试主要用于验证整个系统的关键功能是否正常。这两种测试经常会有人混淆,或者当做一回事来看待。这是因为,这两种测试的特点就是只运行关键的测试用例,以保证一些基本且重要的功能没有问题。

系统测试
系统测试是一个比较笼统的概念,通常很多团队会有系统测试部门对产品进行一系列的测试,比如端到端的测试、异常测试、压力测试、性能测试等。这种测试一半都是系统级别的,测试规模比较大,测试时间比较长,测试人员更容易脱离测试用例,根据自己的测试经验发现系统的问题。

5. 参考链接

https://blog.csdn.net/zhangmike/article/details/82925876
https://zhuanlan.zhihu.com/p/157230441
https://www.jianshu.com/p/604519867e9f