今天是2020年4月15日 星期三,欢迎光临本站 

更多
新闻推荐

行业动态

技术分享 想测试入门就必须要懂的软件开发流程

文字:[大][中][小] 手机页面二维码 发布时间:2022-09-30 03:56:02 来源:牛宝体育官方网站 作者:牛宝体育官网     浏览次数:17    

  从事软件测试行业,每天面对的被测对象都是软件。如果想要更好的去完成测试工作,首先需要对被测对象,也就是对软件要有基本的了解。

  程序好理解,就是可以操作的产品。比如 wps、微信、QQ、网页等等这些都是程序。比如说需求文档、设计文档、用户手册这些东西都属于文档。在页面中展示的,还有用户输入的内容这些都是数据。

  软件开发模型就是在软件开发当中,逐渐总结了很多的经验,这些经验经过提炼总结就变成了开发模型。比如最开始的瀑布模型,后来到了敏捷开发模型,一直发展到现在最火的 DevOps 模型。

  瀑布大家都熟悉,水是从上到下的流下来的。那瀑布模型也是一样,像水流一样从上往下一步一步进行的。

  不管做任何事情,分析的工作是肯定是必不可少的。瀑布模型里面也是这样,首先要做的就是需求分析。

  需求文档是产品人员从用户那里了解并搜集到的。了解清楚用户想要什么之后,再把它细化成为一个文档。文档会清楚列出系统大致的大功能模块,大功能模块有哪些小功能模块,并且还列出相关的界面和界面功能。有了这个文档,产品的 UI 界面、功能就都确定下来了。

  实现之后测试人员就可以介入了。这就是瀑布模型的流程,有了代码,再去做测试。

  在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,当前活动的工作结果需要进行验证。

  瀑布模型是线性模型的一种。它在所有的开发模型当中占有重要的地位,是所有其他模型的一个基础。其他的模型都是根据这个线性模型演变过来的。

  瀑布模型的优点很明显,开发的各个阶段比较清晰,强调早期计划及需求调查,比较适合需求稳定的产品开发。

  但是因为开发模型是线性的,增加了开发的风险,所以早期的错误可能要等到开发后期的阶段才能发现。

  敏捷开发模式是一种从 90 年代开始逐渐引起广泛关注的一些新型软件开发方法。这种开发模型更适用于需求频繁变化和需要快速开发的场景。

  常见的敏捷开发模型有 XP 和 Scrum,下面分别介绍下这两种开发模型。

  XP(eXtreme Programming)是一种近螺旋式的开发方法。它是把复杂的开发过程分解为一个个相对比较简单的小周期。在每一个周期里面,项目人员和客户都可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,而且可以根据实际情况及时地调整开发过程。

  首先是编程方法这个维度。在这个纬度当中,对开发人员的开发方法做出了规定。

  :XP 要求用最简单的办法实现每个小需求。这些设计只要能满足客户在当下的需求就可以了,不需做更高深的设计,这些设计都将在后续的开发过程中可以不断地调整和优化。

  :指代码由两个人一起完成。一个人主要考虑编码细节。另外一个人主要关注整体结构,不断的对第一个开发写的代码进行评审。

  :测试驱动开发的基本思想就是在开发功能代码之前,先编写测试代码。测试代码编写好了之后,再去编写可以通过测试代码的功能代码。这样就可以让测试来驱动整个开发过程的进行。这样做,有助于编写简洁可用和高质量的代码,有很高的灵活性和健壮性。

  :XP 强调简单的设计,但简单的设计并代表是没有任何结构的流水,也不是缺乏重用性的程序设计。XP 提倡重构代码,主要是努力减少程序和设计中重复出现的部分,增强程序和设计的可重用性。

  :代码集体所有意味着每个人都对所有的代码负责。反过来又意味着每个人都可以更改代码的任意部分。

  :因为大家可以都可以改代码,那开发小组中的所有人都需要遵循一个统一的编程标准。这样所有的代码看起来好像是一个人写的。因为有了统一的编程规范,每个程序员更加容易读懂其他人写的代码,这是实现代码集体所有的重要前提之一。

  :团队只有持久才有获胜的希望。可以把项目看作是马拉松长跑,而不是全速短跑。需要团队成员保持长期稳定的工作节奏。

  :集成就是要把大家的代码合并到一起。团队开发成员需要经常集成它们的工作。每次集成都通过自动化的构建(这其中还包括了自动化测试)来验证,这样才能尽快地发现集成错误。

  :为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能,团队需要用很多形象的比喻来描述系统或功能模块是怎样工作的。比如,对于一个搜索引擎,它的系统隐喻可能就是“一大群蜘蛛,在网上四处寻找要捕捉的东西,然后把东西带回家中。”

  最后一个就是发布管理的维度了。交付是把产品交到客户手上。发布就是把产品上线,让用户可以访问。总体来说,交付和发布都是让用户可以拿到产品去使用。

  :那规模有多小呢?就是每个迭代 1-3 周时间。在每个迭代结束的时候,团队交付可运行的,经过测试的功能,这些功能可以马上投入使用。

  :预测在交付日期前可以完成多少工作,确定现在和下一步该做些什么。不断的回答这两个问题,就是直接服务于如何实施及调整开发过程。

  :每一个项目贡献者都是“团队”完整的一部分。这个队伍是围绕着一个每天和队伍坐在一起共同工作的商业代表——“客户”建立起来的。

  :在 XP 中,“客户”并不是为系统付账的人,而是真正使用该系统的人。XP 认为客户应该时刻在现场解决问题。

  从 XP 开发模型可以看出来,里面开发和客户是占据主导地位的。测试的工作基本都是通过自动化的方式来进行。比如在编码过程中的测试驱动开发这个环节,还有持续集成中也包含了自动化的测试。总体而言这个开发模型对开发和测试的要求都是非常高的,团队里面的人必须都有非常高的水平,这个模型才能运转成功。这是开发小型项目的一个理想状态下的情况,比较难实现。

  在 Scrum 模型里面,最基本的概念是 Sprint。Sprint 其实就是一个冲刺,通俗一点来说就是一个迭代周期。

  整个项目开始之前,会先有一个产品 Backlog。使用产品 Backlog 来管理产品的需求的。它是整个项目的概要文档。Backlog 是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。

  Scrum 团队从产品 Backlog 中挑选最高优先级的需求进行开发。挑选的需求在 Sprint 计划会议讨论。

  在 Sprint 上经过讨论、分析和估算得到相应的任务列表,可以称为 Sprint Backlog。

  Scrum 中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个 Sprint,每个 Sprint 的建议长度是二至四周。

  在每个迭代周期中,Scrum 团队会举行每日站会。在每日站会上检验 Sprint 目标的进展,做出调整,从而优化次日的工作。

  在每个迭代周期最后,需要进行一次 Sprint 评审会议,让团队向产品负责人和利益相关者展示已完成的功能。

  Sprint 评审会议结束之后,下一个 Sprint 计划会议之前,需要进行 Sprint 回顾会议。回顾会议是要找出 Sprint 过程中,哪些地方执行的很好,哪些地方执行的不好,团队可以做哪些改进。

  这就整个 SCRUM 模型的工作流程。在每一个 Sprint,也就是一个迭代周期中,其实是一个小的瀑布。在每个迭代周期中,都会完成一个从需求分析 - 设计 - 编码 - 测试 - 上线这样的完整流程。不同的迭代周期可能是部分重合的。比如说第一个迭代周期进行到了测试阶段,第二个迭代周期的需求分析可能已经开始了。这样不停的循环迭代往下进行。

  DevOps 是非常关注开发(Dev)、运维(Ops)、以及测试人员之间沟通合作的一个开发模型。

  在 DevOps 里,是通过自动化的软件交付的流程,来让构建、测试、发布软件能够更加地快捷、频繁和可靠。

  它的出现其实就是因为现在的软件需要更加快速的上线,如果想实现每天都能上线新功能。但是敏捷开发模型,它再快也得一周的时间,实现不了这个需求。所以大家意识到了,为了能够更加快捷的上线,开发、测试和运维工作必须紧密合作。所以说 DevOps 更适合使用在需求频繁变化、开发、测试运维都需要敏捷的场景下。

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

  对于持续测试,可以使用一些自动化测试工具,比如说 Selenium、Appium。Selenium 是做 web 自动化的工具,Appium 是做 app 自动化的工具。自动化的工具还需要配合测试框架一起去使用,比如 Java 中的 TestNG、JUnit,python 中的 unittest、pytest。有了这些自动化测试的工具,就可以持续的对开发出来的软件进行测试了。

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

  一旦新提交进来的代码测试通过,就会不断地与现有代码进行集成。这就是持续集成的过程了。

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

  还可以把 Jenkins 设置成发现 Git 库里有新提交的代码,就可以自动触发新构建,也可以在单击按钮时手动触发一个新的构建。有了 Jenkins 这款利器,就可以非常方便的完成持续集成的工作。

  持续集成完成之后,就可以直接把代码部署到各种环境中。在这个阶段,需要保证只有通过了持续测试的正确代码,才能被部署到服务器上。

  因为如果上线了新功能,产品就会有更多用户去使用。这样的话,运维人员可能还需要扩展服务器来容纳更多用户。如果可以实现持续部署,就可以通过配置管理工具快速、频繁地执行部署任务。让产品能够更快的和用户见面。这就打通了开发、测试到上线的一个快速通道。

  在这个阶段,容器化工具 Docker 也发挥着重要作用。它可以帮助保持各种环境是一致的。比如说测试环境、生产环境等等这些,因为环境的不同也可能会导致一些 Bug 出现。

  部署上线之后,就到了持续监控的阶段。这是 DevOps 生命周期中非常关键的阶段。通过线上的监控可以帮助提高软件的质量,监控软件的性能。

  这里也会涉及运营团队的参与,他们也会监控用户在使用产品过程中的一些错误行为,为以后需求的进一步优化提供数据支持。

  在这个阶段,可以使用 ELK Stack。这是一个搜集线上数据,并且分析展示的平台。通过这个工具可以自动的去搜集用户的动作,产品的一些线上的 bad case,通过分析这些数据,可以为产品将来的发展方向做出指导。

返回上一步
打印此页
021-54339850
浏览手机站