技术分享网站,技术分享会

　　从事软件测试行业，我们每天面对的测试对象都是软件。想要更好的完成测试工作，需要对被测对象，也就是软件有一个基本的了解。

　　与计算机系统操作相关的软件计算机程序、可能的文件、文档和数据。

　　好的程序理解才是可以操作的产品。比如wps，微信，QQ，网页等等都是程序。比如需求文档、设计文档、用户手册都是文档。页面上显示的内容，用户输入的内容，都是数据。

　　所以程序、文档和数据的组合就是一个完整的软件。

　　软件开发过程的演变软件开发过程的演变实际上是软件开发模式的演变。

　　软件开发模型是软件开发的过程，在这个过程中逐渐总结出大量的经验，并将这些经验提炼总结成开发模型。比如第一个瀑布模型，然后是敏捷开发模型，一直发展到目前最火的DevOps模型。

　　下面，分别介绍这几种开发模式。

　　传统的瀑布模型瀑布大家都很熟悉，水是从上往下流的。瀑布模型也是如此，像水流一样从上到下一步步进行。

　　需求分析无论做什么，分析的工作肯定是必不可少的。瀑布模型也是如此。首先要做的是需求分析。

　　需求是产品人员从用户那里了解和收集的。知道用户想要什么后，提炼成文档。文件会明确列出系统的一般主要功能模块，主要功能模块有哪些次要功能模块，还会列出相关的接口和接口功能。有了这个文档，产品的UI界面和功能就确定了。

　　需求分析之后，开始设计。有两个方面需要设计：

　　界面设计：UI设计师根据需求设计一份前端界面的设计稿。编程：设计基本的业务流程，如何划分模块，接口的规范等。所有的设计都做好之后，开发者就可以进入编码阶段了。

　　在编码软件编码阶段，开发者会根据设计好的方案，通过代码实现这些方案。

　　实现相当于开发的代码已经实现了需求中的这些功能。

　　测试实现后，测试人员可以进行干预。这就是瀑布模型的过程。一旦有了代码，就进行测试。

　　发布和测试工作完成后，发布产品上线，继续维护产品。

　　特点在瀑布模型中，软件开发的所有活动都是严格以线性方式进行的。当前活动接受上一个活动的工作结果，当前活动的工作结果需要验证。

　　瀑布模型是一种线性模型。它在所有开发模式中占有重要地位，是所有其他模式的基础。其他模型是从这个线性模型发展而来的。

　　瀑布模型优势明显，每个发展阶段清晰，强调前期规划和需求调研，更适合需求稳定的产品开发。

　　但由于开发模式是线性的，增加了开发的风险，早期的错误可能要到开发后期才能发现。

　　为了解决瀑布模型中的这些问题，已经开发了其他开发模型。

　　敏捷开发模型敏捷开发模型是20世纪90年代以来逐渐引起广泛关注的一种新型软件开发方法。这种开发模式更适合需求变化频繁、开发速度快的场景。

　　常见的敏捷开发模型是XP和Scrum。这里分别介绍两种开发模式。

　　XP(极限编程)是一种近乎螺旋式的开发方法。它将复杂的开发过程分解成相对简单的小循环。在每个周期中，项目人员和客户都能非常清楚开发进度、变更、需要解决的问题和潜在的困难，并能根据实际情况及时调整开发过程。

　　从上图可以看出，极限编程从三个维度组织开发过程。

　　编程方法首先是编程方法的维度。在这个纬度上，规定了开发者的开发方法。

　　简单设计：XP要求用最简单的方式来实现每一个小需求。只要这些设计能满足客户目前的需求，就不需要做更高级的设计。这些设计会在后续的开发过程中不断调整优化。结对编程：是指代码由两个人共同完成。一个主要考虑编码细节。另一个人专注于整体结构，并不断审查第一个开发人员编写的代码。测试驱动开发：测试驱动开发的基本思想是先写测试代码，再开发功能代码。测试代码写好之后，再写能通过测试代码的功能代码。这允许测试驱动整个开发过程。这样做有助于编写简洁、可用、高质量、高灵活性和健壮性的代码。重构：XP强调简单设计，但简单设计不是没有任何结构的流水，也不是缺乏复用性的程序设计。XP提倡重构代码，主要是为了减少程序和设计的重复部分，增强程序和设计的可重用性。实践小组实践是从团队合作的维度来定义工作方法。

　　代码的集体所有权：代码的集体所有权意味着每个人对所有代码负责。这反过来意味着每个人都可以更改代码的任何部分。编码：因为每个人都可以更改代码，所以开发团队中的每个人都需要遵循统一的编程标准。所有这些代码看起来好像是一个人写的。因为有了统一的编程规范，每个程序员更容易读懂别人写的代码，这是实现代码集体所有权的重要前提之一。高速的节奏：球队只有坚持很久才能赢。你可以把这项赛事想象成一场马拉松，而不是全速冲刺。要求团队成员保持长期稳定的工作节奏。持续集成：集成就是把大家的代码融合在一起。团队成员需要经常整合他们的工作。每一个集成都通过自动化构造(包括自动化测试)来验证，这样可以尽早发现集成错误。隐喻：为了帮助每个人一致而清晰地理解要完成的客户需求和要开发的系统功能，团队需要使用许多形象化的隐喻来描述系统或功能模块是如何工作的。例如，对于一个搜索引擎来说，它的系统性隐喻可能是“一群蜘蛛，在互联网上搜索一些东西来捕捉，然后带回家。”最后，交付管理是发布管理的维度。交付是将产品交付给客户。发布就是把产品放到网上，让用户可以访问。一般来说，交付和发布都是为了让用户可以使用产品。

　　小规模释放：有多小？也就是每次迭代需要1-3周。在每次迭代结束时，团队交付可运行的和经过测试的功能，这些功能可以立即投入使用。计划游戏：预测交付日期前可以完成多少工作，确定现在和下一步要做什么。不断回答这两个问题，就是直接服务于如何实现和调整开发过程。完整的团队：每个项目贡献者都是“团队”不可或缺的一部分。这个团队是围绕着一个业务代表3354“客户”建立起来的，他和团队坐在一起，每天一起工作。现场客户：在XP中，“客户”不是为系统付费的人，而是实际使用系统的人。XP认为客户应该总是当场解决问题。从XP开发模式可以看出，开发和客户是主导。测试工作基本上以自动化的方式进行。例如，编码过程中的测试驱动开发和持续集成也包括自动化测试。一般来说，这种开发模式对开发和测试的要求非常高，团队中的所有人都必须有非常高的水平，才能让这种模式成功运行。这是开发小规模项目的理想情况，但这很难实现。

　　Scrum在SCRUM模型中，最基本的概念是Sprint。冲刺其实就是冲刺，通俗地说就是一个迭代的周期。

　　在整个项目开始之前，会有一个产品积压。使用产品积压来管理产品需求。这是整个项目的总结文件。Backlog是按照业务价值顺序排列的需求列表，列表条目通常包含在用户故事中。

　　Scrum团队从产品Backlog中选择最高优先级的需求进行开发。选择要求在冲刺规划会议上讨论。

　　经过对Sprint的讨论、分析和评估，相应的任务列表可以称为Sprint Backlog。

　　在Scrum中，整个开发过程由几个短的迭代周期组成。一个短的迭代周期称为Sprint，每个Sprint的推荐长度是两到四周。

　　在每个迭代周期中，Scrum团队将召开每日会议。在每日例会上检查冲刺目标的进度，并做出调整，优化第二天的工作。

　　在每次迭代的最后，Scrum团队将提交潜在的可交付成果。

　　在每个迭代周期的末尾，需要召开一个Sprint评审会议，以便团队可以向产品所有者和利益相关者展示完成的功能。

　　在冲刺评审会议之后，在下一次冲刺计划会议之前需要召开一次冲刺评审会议。评审的目的是找出哪些做得好，哪些做得不好，团队在冲刺过程中可以做哪些改进。

　　这是整个SCRUM模型的工作流程。每一次冲刺，也就是一个迭代周期，其实就是一个小瀑布。在每一个迭代周期中，都会完成一个从需求分析-设计-编码-测试-上线的完整过程。不同的迭代周期可能部分重合。例如，第一次迭代已经到了测试阶段，第二次迭代的需求分析可能已经开始了。这种无休止的循环迭代继续下去。

　　DevOps(开发模型DevOps(开发和运营的结合)，涉及软件开发生命周期的各个阶段。

　　Ops是一种非常注重开发(dev)、运维(ops)、测试人员之间的交流与合作的开发模式。

　　在DevOps中，通过自动化的软件交付过程，可以更快、更频繁、更可靠地构建、测试和发布软件。

　　它的出现其实是因为现在的软件需要更快的上线，如果想实现可以每天上线的新功能。但是敏捷开发模式，还需要一个星期，不能满足这个要求。于是大家意识到，为了更快上线，开发、测试和运维工作必须紧密配合。所以DevOps更适合用在需求变化频繁，开发、测试运维都需要敏捷性的场合。

　　我们来看看DevOps模型包括哪些阶段。

　　持续开发这是DevOps生命周期中持续软件开发的阶段。与瀑布模型不同，软件可交付成果被分解成几个开发周期短的任务节点，在短时间内开发交付。

　　这个阶段包括规划、编码和构建。

　　规划阶段：可以使用一些项目管理工具，比如JIRA，对项目的整个编码阶段进行管理；你可以使用Git或SVN来维护代码构建阶段的不同版本；您可以使用打包工具，比如Maven工具，将代码打包成可执行文件，以便进行连续测试。在这个阶段，开发的软件将被持续测试。

　　对于连续测试，可以使用一些自动化测试工具，比如Selenium和Appium。Selenium是web自动化的工具，Appium是app自动化的工具。自动化工具还需要和测试框架一起使用，比如Java中的TestNG和JUnit，python中的unittest和pytest。有了这些自动化测试工具，我们可以不断地测试开发的软件。

　　在这个阶段，使用Docker容器实时模拟“测试环境”也是非常方便的。

　　持续集成(CI)一旦新提交的代码通过了测试，它将与现有的代码持续集成。这就是不断融合的过程。

　　这个时候可以使用Jenkins，它是持续集成最流行的工具。使用Jenkins，您可以从Git库中提取最新的代码并生成一个构建，该构建最终可以部署到测试或生产服务器。

　　您还可以设置Jenkins在Git存储库中找到新提交的代码时自动触发新的构建，或者在您单击按钮时手动触发新的构建。有了Jenkins，完成持续集成非常方便。

　　经过不断的部署和集成，代码可以直接部署到各种环境中。在这个阶段，有必要确保只有通过持续测试的正确代码才能部署到服务器。

　　如果推出新功能，将会有更多用户使用该产品。在这种情况下，运维人员可能需要扩展服务器来容纳更多的用户。如果可以实现连续部署，那么可以通过配置管理工具快速频繁地执行部署任务。让产品更快的与用户见面。这就开辟了一条从开发、测试到上线的快速通道。

　　在这个阶段，容器工具Docker也扮演着重要的角色。它可以帮助保持各种环境的一致性。比如测试环境，生产环境等等，因为不同的环境也可能导致一些bug。

　　持续监控部署上线后，就是持续监控阶段。这是DevOps生命周期中的一个关键阶段。在线监控有助于提高软件质量并监控其性能。

　　还会涉及到运营团队的参与，运营团队也会监控用户在使用产品过程中的一些错误行为，为未来进一步优化需求提供数据支持。

　　现阶段可以使用ELK Stack。这是一个收集在线数据并进行分析和展示的平台。通过这个工具，你可以自动收集用户的行为和产品的一些在线不良案例。通过分析这些数据，可以引导产品未来的发展方向。

　　这些内容就是DevOps的整个生命周期。

　　转载请联系作者取得转载授权，否则将追究法律责任。评论0发表评论

　　wx6295e0fca1591

　　2022-06-13 13:47

　　只是一个大男人，遥不可及。我将与你分享它。你们是亲戚吗？

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。