持续测试

定义

测试分类

常见的测试有以下几种类型： 测试方法分类：

1. 黑盒测试 不知道应用程序的内部代码结构的前提，下对代码进行测试，测试是基于需求和功能的
2. 白盒测试 利用对软件内部工作原理的了解来检查代码。 测试类型分类：
3. 功能测试 功能测试是一种黑盒测试方法，旨在验证软件系统是否按照其功能要求进行操作。这种测试不关注软件的内部代码结构，而是关注于输出是否符合预期，当给定特定输入时。
4. 系统测试 系统测试是在完整的、集成的软件系统上进行的测试，以评估系统是否符合其指定的要求。这是在软件开发生命周期中较晚的阶段进行的。
5. 极限值测试 极限值测试是一种测试设计技术，其中重点是输入值的边界条件。这是一种黑盒测试方法，用于检查系统如何处理边界值。
6. 性能测试 性能测试是一种评估软件应用程序的响应速度、稳定性、可扩展性和资源消耗的测试。 测试阶段分类：
7. 单元测试 是在软件开发过程的最早期进行的测试，主要针对软件的最小可测试部分，通常是单个函数、方法或类。
8. 集成测试 集成测试是在单元测试之后进行的，目的是测试多个单元、模块或组件在一起工作时的行为和接口。
9. 系统测试 系统测试是在整个软件系统的最终版本上进行的测试，以验证它是否满足指定的要求。测试期间使用真实的用户数据，以体现系统的运作是否稳定
10. 回归测试 回归测试是在软件更新、修复或增强后进行的测试，以确保新更改没有破坏现有的功能。

持续集成的理念和实践

在敏捷开发的世界中，持续集成（Continuous Integration，简称CI）扮演着至关重要的角色。它不仅加速了开发过程，还提高了软件质量和团队协作效率。通过理解并实践持续集成，团队能够更有效地管理复杂的软件项目，确保快速响应市场和客户需求的变化。

定义

持续集成是一种软件工程流程，它强调开发人员应将其工作成果频繁且定期地集成到共享主线中。这种做法有助于早期发现和解决冲突，减少集成过程中的问题。

整体流程

首先每个研发工程师将自己的代码提交到代码服务器中，项目组中的持续集成服务器从代码服务器中拉取代码进行构建。并进行自动化测试，最后持续集成服务器会将结果通知项目组成员，测试失败时，进行问题定位以及代码修改，持续集成服务器会在每个工作日结束之后启动。

敏捷开发的理念

开发流程区别

敏捷开发和传统的开发之间有着根本上的区别，一个是固定范围，弹性时间，一个是固定时间，弹性范围。因为瀑布流的流程核心在于计划，一切任务为计划所着手，一切为计划所驱动，而敏捷开发则是为业务所计划，一切以业务为中心，动态调整资源的投入。

敏捷开发的理念

敏捷开发的理念是: 个体和互动 高于 流程和工具， 工作的软件 高于 详尽的文档， 客户合作 高于 合同谈判 响应变化 高于 遵循变化。 左侧是重点强调的，但是不意味着右侧就不注重了。 以下是对各项的理解

1. 个体之间的互动旨在打通各个部门之间的隔阂，使得开发信息再各部门流通起来，部门中的个体强调积极互动，积极地交流自己在开发工程的过程中所遇到的问题和见解。
2. 工作的软件旨在工作的软件以实现业务为核心，让用户看到价值，而不是注重于文档的编写，对应文档应该凸显软件的价值在何处而不是单纯记录软件本身的功能以及流程
3. 客户合作在于已成就客户为目的，与客户之间并非是零和博弈，而是优先实现客户需求为主，而不是注重于合同谈判本身
4. 响应变化在于基于业务的变动对实践本身做动态的调整，初始的计划并非向瀑布流一样直接性完整的给出，而是分层次，由抽象层面逐步细致化。

用户故事

定义

描述了对用户，系统或者软件购买者有价值的功能，是敏捷开发方法中用来定义系统需要提供的功能和作为需求管理条目化的基础。总体思想就是将需求细化之后像一段故事讲出来，这和代码整洁之道说的理念有异曲同工之妙。

结构：

• 是一份书面的故事描述卡片用来做计划和作为提示
• 有关故事的交流，用户具体化故事细节
• 测试，用户记录和确认故事细节且可用于确定故事何时完成

具体使用

作为X [用户角色] 我希望Y [系统提供什么功能] 以便Z [达到什么目的或者实现什么价值]

敏捷开发的管理方法与模型

管理方法分两种：

1. KanBan
2. Scrum

KanBan（以下称看板）

看板是丰田公司提出的一个概念，用于制造业生产。

本质

后道工序需要时，通过看板(可视化卡片)向前道工序发出信号，前道工序只有收到信号时，才会进行工作，生产信号由下游控制，下游拉动上游，因为最下游是业务，所以也可以理解业务拉动生产。

特点

1. 控制库存
2. 灵活响应
3. 加速流动
4. 促进改善

敏捷开发的规划与设计

敏捷开发规划与设计的实现思路为：

1. 增量式交付
2. 影响地图
3. 用户故事地图

增量式交付

增量式交付是敏捷开发的基石，旨在及时反馈和频繁接纳向客户交付连续改善的工作产品 首先起步于粗糙的产品原型或者框架，作用是快速地让用户体验到工程价值所在，验证用户整体使用的场景，就是整体项目拆分至最小可用，逐步提交至用户，让用户去验证业务实现是否准确以及是否满足。 其次是在开发过程中让用户得到持续性的价值输入，让用户直观的感受到开发进度以及工程价值递增。 最后，通过早期对用户体现价值增量，让用户更加理解后面的需求改动以及整体改动。 总的来说就是打通开发与用户之间的理解壁垒，控制在开发过程中因沟通所导致的工程问题的产生。 增量式交付真正的问题是只见核心不见森林，不能方便地了解系统提供的功能完整性。