软件开发模型-从传统瀑布模型到DevPos
软件开发流程
前言：
想要更得进行软件测试，明白软件测试流程是必不可少的，最基本就是了解软件开发的流程。
软件是什么
传统的定义是：
软件是与计算机系统操作相关的计算机程序、可能有的文件、文档以及数据
可以理解为‘软件=程序+文档文件+数据结构’
程序就是代码部分。
文档文件表示开发流程中所有涉及的文档：PRD、设计文档、测试策略等。
数据结构代办储存数据的方式和方法，可以看看有关数据结构的文档。这里不展开细讲。
按照这思路走，软件测试是不是就不只是对程序质量的检验那么简单了？
什么是开发模型？
就是在开发流程中不断积累经验，最后总结出来的模式。
软件开发流程的演变：
(比较重要的三个模型)
传统瀑布模型(老版本)：
需求分析：
需求来自用户，B端和C端的用户是不太一样的，B端的用户是看得到摸得到的人，C端的用户可能是用户画像，是根据痛点虚拟出来的人。有兴趣的可以去了解了解。
需求分析简单来说就是对产品经理的需求文档进行查缺补漏，并且保持所有人对需求的理解一致。
需要注意的是，瀑布模型的这个阶段是没有需求评审的，那就是说它并不具备迭代的性质。
现在在需求分析阶段，常常需要测试团队和开发团队的共同努力，尽可能把用户的需求全部挖掘出来，清除一切模糊的需求描述。（需求评审的场景大概是这样的，产品经理在上面站则讲这个需求怎么怎么样，我们在下面对他说的内容指指点点，如果遇上牛一点的开发，产品可能得汗流浃背）
概要设计和详细分析：
现在的概要设计叫体系结构设计。详细分析现在叫详细设计。
体系结构设计是将软件需求转化为数据结构和软件的系统结构。
详细设计是详细写功能是如何如何实现，使用什么什么框架，有的详细设计设计得特别特别详细，开发可以直接抄的程度。
现在一般由‘软件架构师’或者‘系统架构师’来干这个活，对各个模块需要的知识可想一般。
需要注意一下，这两块内容也应该包括UI设计、交互设计。
编码：
开发们猛猛写的阶段。
这里可以了解一下：开发的思维是正向思维，开发所希望的是软件能正常工作。
单元测试：
单元测试由谁来做？
这个问题其实不同的开发模式、不同的场景、国内国外都不尽相同。
但其实无非就两组人来做：测试、开发。
单元测试是测什么？
模块或组件、类和函数。
单元测试怎么测？
一般是用现成的框架或者工具，java现在是testNG、Junit、python现在是unittest、pytest。
现在也有了AI智能单元测试。
集成测试：
这里的集成测试应该包含系统测试，可见这个模型是多么老
集成测试就是将通过单元测试的模块或组件组合起来再进行测试，以检查这些单元之间的接口是否存在问题。
一般是将组件一个一个地添加，最后组成整个软件，完成一个系统。之后才进行系统测试。
维护：
对软件以及服务器的故障修改、功能完善、内容更新等，运维的工作为主
瀑布模型的特点：
软件开发的各项活动严格按照线性方式进行
当前活动接受上一项活动的工作结果
当前活动的工作结果需要进行验证
可以发现， 瀑布模型是线性的，先有的设计和开发，才到软件测试。
优点很明显：层次分明，项目管理者可以更好地把握项目的内容和进展。每个阶段都有文档产生。
缺点也很明显：各个阶段只与前后的阶段关联，测试的介入时间很晚。测试方面也只停留在动态测试，我们常说瀑布模型是狭义的测试。而且没有反应SDLC的本质。（SDLC:Software Development Life Cycle 软件开发生命周期）
新版本的瀑布模型：
这样一个各个阶段严格线性分离的模型，是非常缺少灵活性的。举个例子，到了测试阶段，你的客户希望修改一个需求，那这个时候，你又得重新需求分析开始往下走。或者到测试阶段发现一个需求层面的错误，那也得重新走一遍。
现代软件开发越来越倾向于迭代和敏捷的开发模式，这也导致了瀑布模型的没落。
虽然大家都说瀑布模型是被淘汰的模型，其实不尽然，这个模型虽然对需求的稳定性要求比较高，但是还是有部分需求不大的项目在使用，而且现在大部分新兴的开发模型也有瀑布模型的影子。
敏捷开发模型
现在的互联网产品，用户的需求在不断增大和变化，这时候产生了敏捷开发模型。
适用场景：需求时常变化、需要快速开发。
XP-极限编程
在了解极限编程之前，我们先了解一下什么是测试驱动开发。(Test Driven Development,简称TDD)
测试驱动开发：
测试在先，编码在后。
测试先行。
这两个都是TDD的说法
先测试，后开发
先写测试脚本或设计测试用例，然后再进行编程。
这样可以给开发对自己的设计更大的信心，同时也有信心进行代码的重构。why?因为重构是有风险的，一般进行重构需要相关测试设计完毕(test is ready)。
有利于开始迭代、快速开发。
还有一个比较有意思的TDD实例,叫自动化冒烟测试脚本，开发可以拿这个脚本来对基本功能进行验证，是不是方便了不少呢。之前也说过，缺陷越早发现越好，可以降低成本，给开发这个脚本是不是也可以起到这个效果呢。
TDD主要分两类：
单元测试驱动开发(UTDD)
我们可以这样想，测试先正向设计输入和输出的用例，因为开发要的是结果正确，一个模块的输出正确了那就可以正确地输入另外一个模块。所以我们先设计好所有模块正确输入输出的用例，而且这样设计是不是还能减少耦合性？我们还可以反向设计，设计一些容易出错的用例，开发根据这个用例对代码进行修改和补充。
所以UTDD是先写单元测试类，再写功能类。
这一定程度上约束了开发随意地写代码。而且能消灭先开发后测试发现缺陷后的定位花的时间，还有的开发可能都忘记自己代码怎么写了的。
验收测试驱动开发（ATDD）
怎么理解？就是先写验收测试。
why?一个用户故事如下：
用户先添加商品到购物车，点击付款，然后扣款。
开发看到这个用户故事：明白了，一拍脑袋，添加商品是数据库+1，点击付款是计算总和然后显示，提示支付，最后别忘了库存-1，完美。
但是实际上可能还有商品货物不足不能加入购物车、商品货物正好下架不能加入购物车、购物车没有商品点击付款显示没有商品等等等等情况。
所以给用户故事添加“验收标准”可以更好地让开发更加明确这个用户故事，也才具有可测性。
回到极限编程模型
极限编程有三个层次，最内圈叫编程方法，中间圈叫小组实践，最外圈叫交付和管理。三个层次由内到外。
测试驱动开发讲了，然后到重构，重构就比如提取方法（将独立的代码放到方法或函数当中）、重命名变量、消除重复代码、优化条件表达式等。
简单设计：用简单方法实现每一个小需求，只需要设计满足用户当下的需求。后续再进行调整和优化。
结对编程：A注重代码的细节，B关注整体结构，B对A的码进行审查
共同拥有代码(代码归集体所有)：每个人都需要对代码进行负责。每个人都可以去改代码。
编码标准：由于代码归集体所有，所以统一代码格式是很重要的，其他人才能去读懂另外一个人的代码。
稳定高速步伐：保持长期稳定的工作节奏。
持续集成：就是将大伙写的代码提交到同一地方进行管理和测试，测试通过则可以去构建。持续集成需要自动化的构建。比如jenkins。
隐喻：帮助我们的小组成员对代码进行理解：比如搜索引擎我们叫蜘蛛在蜘蛛网上定位猎物。
小规模发布：发布一个版本只需要一到三周，然后这个版本是一个功能一个功能地上线，所以叫小规模发布。
计划游戏：在交付日期到来前，我们可以完成哪些工作，现在需要做什么，未来需要做什么，简单来说就是规划。
完整的团队：需要成员进行紧密合作，每天坐在一起，才是一个完整的团队。
现场客户：团队是围绕现场客户来进行工作的，客户需要在线现场解决我们的一些业务问题。
测试主要在测试驱动开发和持续集成两个部分
极限编程模型对开发和测试的要求都是比较高的，这样模型才能运转成功，其实很多开发不能适应UTDD的模式，然后可能会使用ATDD,或者其延伸出来的BDD(行为驱动开发)就是将验收标准更加实例化。次模型一般用于小项目。
SCRUM
SCRUM是使用比较多的敏捷开发模型
首先得明确一个基础概念：SPRINT(迭代周期)
Product Backlog。其中包含功能的优先级。
然后拿着这个Product Backlog到Sprint planning Meeting计划会议中进行需求的评审。讨论出要开发的需求，将这些需求汇总生成一个Sprint Backlog。
每日站会daily Scrum，在每日站会上会检查项目的进展，就是对今天工作成果进行验收，和对第二天的工作进行规划安排。
每个迭代周期结束，会交付一个包含了Sprint Backlog文档中的需求功能的产品增量（也就是添加了新功能）
之后还会进行一次sprint的评审会议，和一次sprint的回顾会议，sprint评审会议会展示这一次迭代的成果，sprint回顾会议会对这次迭代周期进行复盘，哪些地方执行得好，哪些地方执行得不好，都会在这次会议上讨论。
测试在什么时候介入的呢？
其实在生产Product Backlog的时候已经介入，包括用户故事评审、明确用户故事验收标准等。
SCRUM的测试流程
对敏捷模型进行总结：
增量迭代-每个迭代周期增加一点新功能
小布快跑-大约两周迭代一次（快）
DevOps
有没有一种模型比敏捷开发模型更快？DevOps
DevOps能讲的实在太多了，其实DevOps在2004年就已经出现，至今也在不断改进和变化
它想解决一个什么问题？
希望构建、测试、发布可以更快地进行、更频繁、更可靠。希望我们的软件能够更快速地上线
那如何解决这个问题？
实现各个部门更加紧密的合作。
适用于什么样的项目？
需求频繁变化的项目。
DevOps特别关注我们的开发、运维和测试三个部分，有以下显著特点：
①打通用户、PMO、需求、设计、开发、测试、运维等各上下游部门或不同角色。
②打通业务、架构、代码、测试、部署、监控、安全、性能等各领域工具链。
从研发周期向右扩展到部署、运维，不仅打通研发的“需求、开发与测试”各个环节，还打通“研发”与“运维”。DevOps 适合“软件即服务”(SaaS)或“平台即服务”(PaaS)这样的应用领域。
DevOps在软件构建、集成、测试、发布到部署和基础设施管理中大力提倡自动化和监控，形成软件研发完整的生态。
DevOps生命周期
持续开发
计划阶段：使用项目管理平台比如jira对整个项目进行管理
编码阶段：使用git或者SVN来维护不同的版本代码
构建阶段:使用打包工具，比如Maven工具，把代码打包到可执行文件。
持续测试
使用自动化测试工具，比如Appium\selenium
还需要配合测试框架进行使用
在这个阶段使用Docker容器实时模拟‘测试环境‘’也是非常方便的
持续集成
可以使用Junkins,目前最流行的持续集成工具
持续部署
首先需要保证只有通过了持续测试的正确代码，才能被部署到服务器上
运维人员可能还需要扩展服务器来容纳更多用户。
如果可以实现持续部署，就可以通过配置管理工具快速、频繁地执行部署任务。
持续监控
通过线上的监控可以帮助提高软件的质量，监控软件的性能。
在这个阶段，可以使用 ELK Stack。这是一个搜集线上数据，并且分析展示的平台。通过这个工具可以自动的去搜集用户的动作，产品的一些线上的 bad case，通过分析这些数据，可以为产品将来的发展方向做出指导。
持续集成
持续集成(Continuous integration，缩写为CI)是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布自动化测试)来验证，根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续交付
持续交付(Continuous delivery，缩写为CD)，是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
