始终都没有很坚定想去做一份职业，大概就是缺少对互联网的热爱与坚持，对于我个人而言，大概需要的是简单而明确的方向，比如考研：选中一个学校并开始各个科目的学习和延伸。但是，找工作完全不一样，研究生两年已经脱离了我原本的想法和期待，现在的我已然变成了一个理想主义的清醒废物。但是，我还是想着要改变，在实习结束之际，在重新回到学校压抑科研生活之际，我决心记录些什么，好让自己残留一些对工作的向往和希冀。当只有一个选择的时候，人势必就只能去坚持做好，所以我决定放弃plan b的公务员啦，好好做码农，这是我当下的抉择！
一、敏捷测试
Wikipedia对敏捷测试的定义：
Agile testing is a software testing practice that follows the principles of agile software development.1
译文：敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。
这是通过一种敏捷的做事方法，可以让团队协作更紧密、工作效率更高，确保以可持续的速度频繁地交付客户所期望的业务价值。
1、敏捷测试与传统测试的区别：
- 传统模式是把软件开发分为“软件需求”、“软件开发（设计&编码）”、“软件测试”、“软件发布”四个阶段，一般利用里程碑的方式对各阶段进行明确定义。
1.软件测试是研发过程中的一个阶段，而且一般都属于项目的最后阶段；测试团队都是立场比较明确，与团队之间的沟通以正式为主
2.测试以需求为依据，要求有需求规格，自动化测试不作为要求
3.测试计划做得比较详细，对测试活动都会做好周密的安排
4.需求方确定需求后，中间环节参与较少。
- 在敏捷模式里，相对传统模式，软件测试不再是一个独立的阶段，测试是融入在软件开发过程中的一个组成部分，发生在每一次迭代中，也包含所有类型的测试，如单元测试、集成测试、系统测试、验收测试等。
1.测试人员与开发人员工作更紧密，非正式的直接沟通成为了一种常态
2.测试以最终用户为准，辅以用户场景或用户故事作为测试的依据
3.测试追求快速高效，自动化测试在测试中扮演了及其重要的角色，敏捷测试人员辅以探索性测试跟踪核心业务场景
4.敏捷测试拥抱变化，测试计划比较灵活，按业务价值交付顺序执行
5.需求方需求定义后，参与每一次产品演示，确认每一次迭代产物，全程参与项目
2.典型的敏捷软件开发过程
3.为什么需要敏捷测试？
1.缩短价值交付周期
开发团队通过提供最小化可用产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到一个相对稳定的阶段产品。在此过程中，敏捷测试人员快速验证团队的目标，快速试错
2.降低软件质量风险
a.敏捷测试要求测试人员尽早进入测试，与开发人员形成统一战线，尽早发现系统缺陷及其它问题，避免大量问题在项目后期才发现，形成质量风险不可控的结果。
b.启用日构建，通过BVT进行持续测试，让每天的迭代代码都能得到验证。
3.提高团队质量意识
敏捷测试人员以专业的能力，引导项目全体成员开展测试，编写自动化测试用例，关注自动化测试执行结果，以稳定的每次编译及测试均未发现缺陷为目标
4.节省项目研发成本
敏捷开发偏向项目型的组织架构，测试人员与产品经理、程序经理、需求人员、开发人员等构成一个团队，采用扁平化的方式进行管理，构建一种和谐的工作氛围，共同为交付价值而努力
5.加速个人能力提升
在一个敏捷迭代周期里，一般团队规模78人，敏捷测试人员至少23人，测试工作不在是一个萝卜一个坑，每个人承担的事情种类较多，要求的知识面更广泛，个人技术栈会越来越丰满，独挡一面的能力更强
二、CI/CD/CT
1、概念介绍
CI(continus integration)持续集成
是在源代码变更后，自动检测、拉取、构建、进行单元测试的过程。
持续集成的目标是快速确保开发人员提交的代码变更是好的，并且适合在代码库中进一步使用
CD(continus delivery)持续交付
指的是整个流程，他自动检测代码变更，并通过构建、测试、打包。
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中
谈到CD，其中是包含了两层内容：持续交付和持续部署。
有时候很多人会把持续交付误认为成持续部署，然而两者是两个不同层次的能力。
持续交付：
持续交付是持续集成的延伸或者看作持续集成的下一步，它将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题，可以继续手工部署到生产环境中。它强调的是，不管怎么更新，软件是随时随地可以交付的。
持续部署：
持续部署是持续交付的下一步，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署稳定的构建版本，持续部署的目标是代码在任何时刻都是可部署的，并可自动进入到生产环境。
总结：
1.持续交付是指团队确保每个变更可以部署至生产环境，但也许并不需要实际部署，这通常可能是出于业务方面的原因。
2.持续部署是指每个变更可以自动部署到生产环境。只有成功实现持续交付的前提下，才能进行持续部署。
CT(continus testing)持续测试
完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
2、相互联系
敏捷测试要取得好的效果，CI、CD及CT3是必不可少，缺少任何一项，整个流程就会不顺畅，效果也就大打折扣。
但要做好这CI、CD和CT，除了需要合适的工具提供支撑，还需要项目整体团队紧密协作。测试团队还需要具备一定的技术能力，在过程中提供驱动力，推动整个过程有序进行。
a.持续集成
敏捷研发过程中，测试的版本更换比较频繁，要求代码集成要快，整个构建一般需要控制在15分钟，构建的项目较多，我们采取并行及分布式执行。编译构建产物存放介质仓库，支持通过Web方式下载，供项目组成员取用。在我们的敏捷研发过程中，主要基于普元的DevOps平台实现持续构建。
b.自动化部署
配置与介质分离，按不同环境进行组合，使用普元DevOps平台标准化的部署流程，快速部署程序包并启动，定时进行健康检查。
使用DevOps进行测试环境的部署，可以解决一些关键问题，如部署目录的规范化、部署行为的规范化、部署过程的透明化、对部署结果进行初步检查以及支持部署异常的快速回滚。
通过DevOps平台的支持，可以避免无关人员获得敏感配置值，避免无关人员操作无关进程，通过页面交互方式，可以方便快捷搭建好所需环境，也大大减少了手动部署带来的压力。
c.自动化测试
自动化测试是敏捷测试非常重要的组成部分。
在敏捷开发这种极短的交付周期内，如果仅仅靠手工测试，则非常难以满足快速发布要求的。所以自动化测试是必不可少的一种手段。
另外这里谈到的自动化测试不仅仅只是指功能的自动化测试，还包括单元测试、静态质量扫描、性能测试、安全扫描等，也涉及自动化测试如何集成在整个交付管道中，缩减整个交付时间，最终给项目带来价值。
在普元产品的敏捷测试中，我们主要是基于普元统一测试平台UTP完成自动化测试，它不仅支持微服务接口的自动化测试、Web
UI的功能测试、移动App的兼容性测试等。
3、DecOps
3.1 介绍
单纯从字面上来理解，DevOps 是Dev（开发人员）+Ops（运维人员）【Open Pluggable Specification（OPS）】，虽然名字来源于开发和运维的缩写，但DevOps并不是简单的就是开发加运维。
DevOps 所涵盖的角色范围会更广：除了开发、测试、运维还会涉及到项目经理、产品经理，甚至和销售、市场等各个部门，跨职能部门互相合作，完成某一项目或任务。
3.2 一些误解
误解一：DevOps不是一种工具，有人可能会说我在用Docker又或Jenkins等工具，是不是就表明在做DevOps了？然而这些并不意味着就在做DevOps的事情。
误解二：DevOps不是一个新角色或者说是一个新的职位， 虽然说国内确实有些公司有单独的职位是DevOps工程师，但并不代表，DevOps是一个职位，严格来说它是一类工程师的统称。
误解三：还有人说，DevOps出来之后，是不是由一个独立的团队去做所有事情，从开发到运维，一个部门就都干掉。
总结：DevOps从需求到设计到开发、到测试到运维，甚至是线上的运营反馈整个全生命周期的，所以它应该是一个打通多个部门协调，协作的这样的一个平台。至于工具和自动化实际上只是DevOps实现的一种手段。或者说DevOps是通过工具，自动化，来达到这种通过工具链与持续集成、交付、反馈、优化进行端到端整合，完成无缝的跨团队、跨系统协作。
3.3 DevOps包含一系列工具链、平台
DevOps融合了一系列基本原则和实践的方法论，并从这些实践中派生出了各种工具，这些工具体现在软件开发和交付过程的不同阶段：
- 编码：代码开发和审阅，版本控制工具、代码合并工具
- 构建：持续集成工具、构建状态统计工具
- 测试：通过测试和结果确定绩效的工具
- 打包：成品仓库、应用程序部署前暂存
- 发布：变更管理、发布审批、发布自动化
- 配置：基础架构配置和部署，基础架构即代码工具
- 监控：应用程序性能监视、最终用户体验
3.4 国内主流的三大DevOps管理平台
除了上面说的这些工具链以外，也有一些DevOps管理平台服务，国内比较出名的就三个：
- 云效
- TAPD
- 灵雀云
其中云效和TAPD属于SaaS类平台，灵雀云是基于容器技术，以DevOps为理念，面向微服务应用的新一代PaaS平台。
Tip：Software as a Service（软件即服务），Platform-as-a-Service：平台即服务
3.5 DevOps提倡的原则
- 从瓶颈点着手
- Start Small,从小做起
- 痛苦的事情优先解决
- 工具也是一种文化
- 自动化别人，先自动化自己
- 价值拉动，而非事务驱动
- 构建指标，驱动DevOps落地。
- 创建从开发过程下游至上游的反馈环。
- 强调全局优化，避免局部优化。
- 持续做试验和学习的文化，通过反复实践来达到精通。
三、软件开发 CI/CD/CT的简要思维导图，以及常用的软件
2.企业DevOps研发模式下CI/CD实践详解指南 ：https://www.cnblogs.com/jinjiangongzuoshi/p/12001708.html
3.软件开发 CI、CD的简要思维导图，以及常用的软件：cnblogs.com/lin-kid/p/11345308.html
附：博客园狂师【测试开发技术】
https://www.cnblogs.com/jinjiangongzuoshi/
版权归原作者 82号维他命小狗 所有， 如有侵权，请联系我们删除。