敏捷开发

作者：华为云专家｜ 人民副首席码仔 上世纪60年代爆发的软件危机催生了软件工程，人们寄希望于借助工程化的手段管理、设计、构建和维护软件，自此，聪明绝顶的工程师便在追求更美好软件的漫漫长路上艰苦求索。 开发语言经历了汇编、C、C++、Java、Erlang、Python；编程范式涵盖了面向过程（POP）、面向对象（OOP）、泛型（GP）、函数式（FP）；软件架构从单机到分布式到云原生，包括巨石，库组件模块服务，分层，微服务，MVC/ServiceMesh/Serverless等；而软件工程思想和方法论则包括以生命周期管理为核心注重工序的瀑布模型（Waterfall Model），以需求进化为核心注重迭代渐进的敏捷开发（Agile Development），以边界划分和控制为核心注重领域建模的领域驱动设计（DDD：Domain Driven Design）。 世界是缤纷复杂的，要把真实世界映射到虚拟软件注定不会是一件容易的事，软件开发是权衡抉择的艺术，譬如快速交付和安全生产常常背道而驰，开发效率和运行效率总是难以一致。 所以在软件发展的历史长河中，人们发明一种方法解决一个问题，而几乎总是会引入另一个问题，软件工程师不得不面对混沌不堪的世界。 面向过程（C）认为一切皆过程，现实世界都可以封装为一个个过程，通过过程串联和编排模拟世界。但随着软件被大规模用于解决复杂的商业问题

ET·ci 提供了编译-测试-发布解决方案，包括：自动提取配置库代码进行自动构建, 自动调度静态测试工具（如 QAC）进行静态测试，自动调度单元测试工具（如 Tessy）开展动态测试，自动调度 HIL 自动化测试系统等。使得开发、测试团队在软件开发、测试和交付生命周期中对研发过程进行可视化管理，帮助软件开发组、测试组轻松、高效地完成复杂的软件项目，缩短软件的整体测试周期和研发周期。ET·ci可应用于嵌入式软件测试自动调度，也是持续集成（continuous integration）解决方案的重要组成部分。 产品介绍 平台组成 典型的全自动软件测试调度平台主要由基础服务与框架模块、管理与配置模块、与基础服务交互的模块、配置管理工具集成模块、编译工具集成模块、静态测试工具集成模块、软件运行时间评估工具集成模块、单元/集成测试工具集成模块（可以扩充其他自动化测试工具，如HIL自动测试）等。 • 基础服务与框架模块 ♦ 定时获取配置库上稳定版本代码以及测试用例，自动进行测试 ♦ 监视配置库代码库/用例库，识别变更自动进行测试 ♦ 根据一键输入进行自动测试 ♦ 测试流程自动化执行及分析 ♦ 执行监控和过程数据抓取及生成报告并发送信息给相关授权人 • 管理与配置模块 ♦ 该模块一般包括项目管理、环境配置和日志管理 • 各集成模块 ♦ 配置管理工具集成 ♦ 编译工具集成 ♦ 静态测试工具集成 ♦

摘要： 影响地图，作为完全以业务目标为导向，业务+产品+研发在一起的工具，每一个碰撞出来的点子都直接和业务结果强相关，并采用探索、低成本试错的方式，通过迭代快速持续开发实现。 当一个项目或一个需求给到研发的时候，通常业务最关心的是工期与成本。研发是基于上述要求交付产品的，这实际上是一种契约关系。契约关系的优点在于权责分明，而最大的问题是研发辛辛苦苦生产出来的产品，真的能够创造业务价值，为公司带来收益吗？ 研发对于商业结果并没有强烈的直接关系。我相信研发内心是希望有这样的关联关系的，因为研发的成就感不是来自于做完而是来自于做的有价值。 不对的产品做得质量再高、速度再快也是一种浪费。但是业务和研发之间似乎总有一堵看不见的墙，难以逾越。 何为影响地图 影响地图是这样一种方法或工具：完全以业务目标为导向，业务+产品+研发在一起共创，每一个碰撞出来的点子都直接和业务结果强相关，并采用探索、低成本试错的方式，通过迭代快速持续开发实现。 影响地图的基本模型：（分为WHY-WHO-HOW-WHAT四层级） 影响地图的第1层（WHY）：确立切实可行的商业目标（符合SMART原则）。 影响地图的第2层（WHO）：要分析出对业务目标产生影响的角色。如下图示例。 影响地图的第3层（HOW）：角色实施怎样的行为可能会对目标产生影响。 影响地图的第4层（WHAT）

什么是自动化测试 把人对软件的测试行为转化为由机器执行测试行为的一种实践。 例如GUI自动化测试，模拟人去操作软件界面，把人从简单重复的劳动中解放出来 本质是用代码去测试另一段代码，属于一种软件开发工作，已经开发完成的用例还必须随着被测试对象的改变而更新，因此，还有额外的维护成本。 自动化测试有哪些分类 按测试目的分类 功能自动化测试 性能自动化测试 按测试对象分类 Web应用测试 APP测试 接口测试 单元测试 为什么需要自动化测试 可以替代大量的手工机械重复性操作，测试工程师可以把更多的时间花在用例设计和新功能的测试上 可以大幅度提升回归测试的效率，非常适合敏捷开发过程 可以更好地利用无人值守时间，去更频繁地执行测试 可以高效实现某些手工测试无法完成或代价巨大的测试类型，例如：7*24小时持续运行的系统稳定性测试和高并发场景的压力测试 可以保证每次执行的操作具有一致性和可重复性，不会受人的感情因素影响。 Postman自动化测试演示 postman大家都用得挺多的，使用方法就不介绍了 1.新建集合 就是为了给待测试接口统一分类一下用： 2.新建接口 下面是我添加的： 3.填写自动化测试脚本 例如，我需要测试几点： http状态码200 返回的json的code码是0 接口返回时间不小于1000毫秒，脚本如下 //查看 httpCode码tests[ "接口状态码200"] =

这个作业属于哪个课程 2020春-S班(福州大学) 这个作业的要求在那里 团队作业第六次——beta冲刺+事后诸葛亮 团队名称 Hail Hydra(九头蛇) 这个作业的目标 Beta冲刺1 作业正文 作业正文 其他参考文献 冲刺日志集合 1. SCRUM部分 1.1 成员描述 成员姓名 完成任务 遇到问题 明日安排 翁绍鸿 实现增加用户功能，完成问题模块单元测试 暂无 完成分类、匿名与后端的交互，完成用户模块单元测试 张嘉伟 讨论制定测试计划 暂无 完成修改关注、点赞、回复模块单元测试 黄忠雄 完成冲刺随笔集合的撰写 暂无 跟进博客 唐志豪 addUser界面的批量增加按钮格式优化，增加其批量增加记录表格 修改上传file的按钮格式 完成左侧导航栏格式固定 黄子峻 积分兑换规则制定 暂无 完成功能测试文档编写 袁锦辉 前端添加匿名与问题分类 暂无 完善匿名前端部分，美化分类导航栏 韦琛 制定积分兑换规则，绘制燃尽图 暂无 完成后台功能测试文档编写 刘成华 讨论制定测试计划 暂无 开始后端回复模块、临时版块、奖励模块的单元测试 郑逸豪 因生病无法参与 因生病无法参与 因生病无法参与 1.2 今日成果截图 前台问题分类及匿名 批量增加用户功能 问题模块单元测试记录 问题模块（QuestionService）的单元测试已经基本完成，如图所示覆盖率100%，测试已经全部通过

1. SCRUM会议 会议记录表(2020-05-27) 组员 昨天完成的任务 今天花了多少时间 还剩余多少时间 遇到什么困难 今天解决的进度 明天的计划 221701224叶博宁 发布通知页面布局优化 4.0 4天 nz-list的loadMore属性还在研究中 群组详情页面1.群成员列表改为ant-design的list2.群组信息改为放在右侧抽屉3.群通知的展示尝试了列表、时间线、表格等形式，最终还是用表格实现 完成群组详情页面 221701340沈志峰 通知中心模块迁移到微服务 通知中心模块模块错误处理完善 3.0 4天 暂无 通知群组待办事项自动添加部分功能 通知群组待办事项自动添加功能 错误处理完善 221701220赵伟男 完善用户头像上传功能 1.5 4天 上传文件命名可能会有冲突，通过使用MD5计算文件名称得以解决 完成了用户头像文件上传并显示的功能 初步实现注册邮件发送时间间隔限制 221701331陈赐 大致实现了待办事项的搜索逻辑，按照志峰的要求编写了通知转换待办的接口框架 1.0 4天 暂无 删除了错误判断的冗余代码，完善了 完善错误机制 221701233岳逾先 完成通知中心详情页面优化登 3.0 4天 暂无 登录注册页面优化和debug登录失败提示 debug登录提示，代码规范 221701103郑澜 添加了头像上传框与相关的ts代码 2.5 4天

之前我写过一篇文章，关于 敏捷坑人系列不清晰的完成 ，在这篇文章当中，描述了完整的定义和验收标准之间的区别，但是最近的课程当中依然有不少小伙伴在提问关于完成的定义，那今天的来说一下，为什么我们要设定完成的定义（即其重要性） 完成？！ 在工作当中往往我们会说这个事情我完成了。当我们说完成的时候，每个人对于这个完成是有不同的定义。比如PO认为完成是需要包含完成编码，提交到代码库，完成单元测试，完成集成测试，完成功能测试，等等一系列的测试。 而开发小伙伴可能认为完成只包含代码，以及在自己的电脑上测试，没有问题就算是完成了。 那这两个完成之间是有很大的一个差距，而这个往往会造成大家对于完成的理解误区，及同时也会造成沟通上的冲突。 完成的定义 Definition of Done 在这个背景下，团队需要对于完成有一个统一的认识。这个完成会包含很多不同的层面及不同的步骤。 举例说，如果说一个产品功能完成了会包含什么？如果开发完成了会包括什么，如果测试完成会包括什么，这是不同的层面。但是在 Scrum指南 中完成默认是指的产品完成。 完成的定义就像是一道门槛 团队一起设好了门槛，能跳过去的功能（PBI）就是完成了，跳不过去的，就是没完成。没有完成一半或者完成90%这样的概念。 所以对于这道 门槛 我们要设多高，这个是看团队对于自己的要求是多少，以及团队对质量的要求是多少，这是非常重要的一一个概念

在项目的实际开发过程中，我们经常会遇到Tab页面的开发 EciTab控件有多种使用方式： 下面介绍Frame容器方式： 下面介绍的Tab页面采用的策略是 Tab页面管理几个子页面，页面组织上用Iframe管理的模式 采用Iframe的原因主要有两个 1.开发简单，每一个页面都是简单的画面 2.性能考虑，打开一个复杂的Tab页面，不见得所有Tab都会点击，这时候可以采用选项卡懒加载的方式 没有点击的选项卡可以DOM都不加载。 下面介绍，从列表页面进入到EditTab页面的过程，一起来分析Tab页面需要写的代码 如上图，列表页，Tab 管理页 (管理了两个页面 EnterpriseEdit 企业编辑页，EnterpriseInvoice 企业开票抬头信息列表页） 从列表页面，有两种方式进入 Tab页面 1.新增 2.点击行内已有数据进入（也就是编辑） 我们一起来看下 Tab页面的源代码 Tab组件，设计了两个选项卡 head kpInfo 分别对应企业信息维护画面、企业开票抬头列表画面 实际上 上面的URL和 lazyURL写上去都是没有意义的，因为实际情况远没有这么简单，需要应对变化的过程。 分析一下到底有哪些变化： 进入这个Tab页面的两种方式： 新增方式：表现来看，没有传入主键 编辑方式：表现来看 就是传入了 列表页面上选中行的主键值 id=xxxx 如果传入主键

1. SCRUM会议 会议记录表(2020-05-27) 组员 昨天完成的任务 今天花了多少时间 还剩余多少时间 遇到什么困难 今天解决的进度 明天的计划 221701224叶博宁 发布通知页面布局优化 4.0 4天 nz-list的loadMore属性还在研究中 群组详情页面1.群成员列表改为ant-design的list2.群组信息改为放在右侧抽屉3.群通知的展示尝试了列表、时间线、表格等形式，最终还是用表格实现 完成群组详情页面 221701340沈志峰 通知中心模块迁移到微服务 通知中心模块模块错误处理完善 3.0 4天 暂无 通知群组待办事项自动添加部分功能 通知群组待办事项自动添加功能 错误处理完善 221701220赵伟男 完善用户头像上传功能 1.5 4天 上传文件命名可能会有冲突，通过使用MD5计算文件名称得以解决 完成了用户头像文件上传并显示的功能 初步实现注册邮件发送时间间隔限制 221701331陈赐 大致实现了待办事项的搜索逻辑，按照志峰的要求编写了通知转换待办的接口框架 1.0 4天 暂无 删除了错误判断的冗余代码，完善了 完善错误机制 221701233岳逾先 完成通知中心详情页面优化登 3.0 4天 暂无 登录注册页面优化和debug登录失败提示 debug登录提示，代码规范 221701103郑澜 添加了头像上传框与相关的ts代码 2.5 4天

软件测试发展了几十年，留下了不少经典的著作。 本篇文章是从我个人的角度推荐的15本测试人员必读书籍，主要推荐的依据更多的以开宗立派或者有提出方法或体系为主的书籍。而像一些测试工具操作相关的工具书没有考虑在里面，因为个人觉得相比工具书而言，前者的难度和含金量会更大。 当然，由于篇幅关系，还有很多好的书籍没有包含在里面，希望在未来有机会能推荐更多的书籍。 测试基础书籍 1.《软件测试》第2版 推荐理由： 测试人员启蒙的经典书籍，对于测试的概念及测试类型等都有非常经典的阐述。建议初级测试从业者阅读。 2.《软件测试的艺术》第3版 推荐理由： 测试人员的又一本经典书籍，对于软件测试的技术特别是用例设计方面有很详细的介绍，同样建议初级测试从业者阅读。 3.《全程软件测试》第3版 推荐理由： 朱少民老师的著作，已经写到了第3版。虽然还是按照测试的流程为主线，但是却增加了很多近年比较火的比如AI测试等内容，是一本难得的测试大全。 敏捷测试基础书籍 4.《谷歌软件测试之道》 推荐理由： 这本书颠覆了很多测试人员的传统观念，而且也让测试人员意识到了危机。个人认为这本书是敏捷测试的基石，虽然书中没有提到敏捷，但是核心做法和理念与敏捷是不谋而合的。 5.《敏捷软件测试》 推荐理由： 这本书是敏捷测试中最出名的一本书，没有之一。如果要学习敏捷测试，这本书应该是必读作品之一。 敏捷测试实践书籍 6.《BDD