联系方式

联系方式
电话:0592-5794349
业务咨询:17350028151 15359409915
QQ咨询:1803977211 491666614
地址:福建省厦门市湖里区岐山路一号亿华中心608A
当前位置:首页> 新闻中心

软件开发敏捷软件开发

* 来源: * 作者: * 发表时间: 2020-02-09 0:34:20 * 浏览: 0
软件开发敏捷软件开发是一种新的软件开发方法,自1990年代以来已逐渐引起广泛关注。它是一种软件开发功能,可以响应快速变化的需求。作为一种新的开发模型,正在越来越多地使用它。应用到软件项目。敏捷软件测试是指在敏捷软件开发过程中与质量相关的一系列活动。与传统的软件测试有很多差异。因为敏捷软件测试的概念一直很模糊,所以人们经常会误会。 II在瀑布式软件开发模式下已经测试了好几年,所以当我第一次接触敏捷项目时,我也有一些误解,但是在与敏捷软件开发团队合作了近5年之后,我有了新的经验。在许多问题上的疑问。认识到以下以下几种常见的误解,并与大家分享我的理解。不需要测试策略。测试策略侧重于目标和方法,即如何有效地使用有限的资源以在有限的时间内实现预先设定的目标。通常,在制定测试策略时,首先要明确测试目标,然后才需要确定哪些测试类型。每种测试的大概比例,选择测试框架,然后计划以后再发布软件之前需要经历的测试阶段。许多人认为敏捷软件开发基于用户案例。专注于用户故事测试是否足够?根本不需要考虑测试策略吗?实际上,这是一个很大的误解,因为敏捷软件开发通常是迭代发布,周期相对较短,并且资源非常有限。这需要我们的总体规划。从小到用户故事,再到大到完整的用户功能,我们需要考虑如何合理利用测试资源,因此非常需要敏捷项目。测试策略。针对实际项目,团队通常在项目开始时制定测试策略(迭代0),明确目标(包括功能需求的目标和非功能需求的目标),然后确定哪些自动化测试在开发阶段需要添加(包括单元测试,界面测试,合同测试,集成测试,系统级UI用户场景测试),并指定这些测试的大致比例(与测试金字塔一致),选择一个自动化测试框架(例如XUnit)以及需要进行哪些手动测试(包括探索性测试,可用性测试等),并计划需要进行的测试阶段(例如新功能测试,回归测试等)在每个发布周期中执行,然后测试策略将在指导敏捷团队的开发和测试中扮演非常重要的角色,当然,每个团队都会因项目策略不同而有所不同。不需要测试文件。测试文件通常包括测试计划,测试用例,测试报告,测试缺陷和其他文件,以及可以指导测试的相应需求文件。许多人认为敏捷软件测试不需要文档。敏捷宣言中有一个“ ldquo”,并且工作的软件高于详细文档。尽管敏捷宣言稍后会提到,但正确的项目也很有价值。我们更加重视左侧的项目。有价值,但是人们倾向于忽略正确项目的内容,从而导致许多刚开始实施敏捷开发的团队拒绝测试文档的作用。首先,不可否认的是,在实际的敏捷项目中,实际上没有传统意义上的正式和专门的需求文档和测试文档,但这并不意味着敏捷项目中没有文档。例如,用户故事本身就是需求和用户故事的载体。接受条件是敏捷测试文档的一部分。此外,BDD中还开发了许多敏捷软件项目。测试用例以自然语言描述,业务人员可以理解,并与自动化结合以形成需求和测试的结合。一个文件,并为了解决问题c由于不及时的文档更新导致敏捷软件测试的快速变化,许多敏捷项目正在使用Livingdocument。纯自动化测试或纯手工测试有些刚接触敏捷的人认为敏捷软件开发发布周期很短,并且测试人员根本没有时间进行手动测试,因此应该使用纯自动化测试。人有些人还相信敏捷开发强调快速响应变化。如果投入的成本在自动化测试中,肯定会导致维护自动化测试所带来的资源浪费,因此应采用纯手工测试。这是两个极端的误解,尽管确实存在这两种观点所考虑的困难,因为在敏捷软件开发过程中,迭代通常很短,并且没有足够的时间进行手动测试,因此必须足够的自动化测试来保证这一点。但是,由于测试代码本身可能存在缺陷,并且许多部分难以由自动化测试覆盖(例如界面测试,可用性测试,探索性测试等),因此敏捷测试也与手动测试不可分割。至于对自动化测试维护成本的担忧,敏捷项目确实有很多变化,但通常它们离用户更近。因此,应尽可能减少依赖于界面的用户级自动化测试。易于更改的低级单元测试接口测试等。建议敏捷测试主要是自动测试,并以手动测试为补充。敏捷QA =敏捷测试人员在许多刚接触敏捷实践的团队中,每个人对敏捷QA的理解仍处于测试人员阶段。只要用户故事开发完成,QA就会进行全职测试并发现缺陷。这是一个很大的误会。首先,QA(质量保证/分析师)不是纯粹意义上的测试者。通过此角色的名称,我们可以看到Agile QA强调质量保证和分析,而不仅仅是测试产品。在实际项目中,敏捷质量保证通常从需求分析阶段就参与整个软件开发过程。通过不同阶段的合作以及团队中不同的角色,它可以帮助整个团队就质量达成共识。验证可以预防缺陷,而不是等待软件开发来发现缺陷,因此对于敏捷QA而言,目标是在软件开发完成后找到尽可能少的缺陷,而对于Tester,发现的缺陷越多,证明的缺陷越多工作完成了。非功能测试并不重要。非功能测试是指针对非功能需求进行测试(软件本身必须满足用户需求所必需的功能需求以外的某些功能,例如安全性,性能,可用性,兼容性等)。包括安全测试,性能测试,可用性测试,兼容性测试等。在敏捷软件项目中,需求被切成小单元。在裁切过程中,非功能性需求是一个更容易被忽略的部分,这导致的问题是,团队通常会忽略非功能性测试。随着时间的流逝,人们会误认为非功能测试并不重要。这种观点是非常错误的。首先,非功能测试的重要性不会随不同的软件开发模型而变化。特别是,安全测试和性能测试的重要性越来越受到重视,因为许多产品必须考虑到用户敏感信息的安全性和性能所引起的用户满意度,因此将在敏捷项目中尽早发布软件。如果这些非功能性需求有问题,则会产生较早的影响,并且该软件可能刚刚进入市场。失去大多数用户。因此,非功能测试和功能测试同等重要。在实际项目中,最好将这些非功能性需求添加到用户故事的接受条件中,并在整个敏捷开发过程中解决这些非功能性需求。性需求。质量是质量保证的问题受传统观念的影响,许多人仍然认为质量是质量保证的问题。如果发布后产品的质量是质量检查问题,则其他角色与质量无关。首先l,这种理解高估了质量检查在质量上的作用。软件质量在软件开发过程中逐渐形成。从需求分析阶段开始,客户是否真正了解客户想要的功能,以及在开发阶段是否已经足够地增加了功能。自动化的测试保证了是否编写了足够健壮的产品代码,引入功能后是否测试整个系统的可用性,在以后的测试阶段是否不同的用户路径都能正常工作等都是软件质量的组成部分。可以看出,在整个过程中,软件的质量与敏捷团队的各种角色密不可分,包括业务分析人员对需求的准确把握,开发人员对产品代码的高标准实施以及自动化测试。在整个过程中,保证质量的速率以及质量保证活动的实施和保证,包括在需求分析阶段从质量保证的角度对业务进行补充,对质量保证过程中的自动化测试进行审查开发阶段以及产品的探索性测试可用性测试。进一步保证质量。因此,在敏捷测试中,我们通常会淡化角色的概念,并强调团队中的每个人都要对质量负责,这将帮助团队中的每个成员将质量视为非常重要的部分,而不是依赖某人或某个角色。开发人员可以编写测试,而不再需要质量检查。因为敏捷团队强调每个人都对质量负责,所以开发人员将使用TDD和其他方法编写大量的自动化测试,因此不需要质量检查吗?对于这种观点,社区中经过大量的讨论,例如本文“我们需要专职的质量检查吗?”引起了很多争议。实际上,我个人认为本文中提到的质量检查是指Tester。参照先前的观点,除此以外,作者的某些观点实际上非常有价值。例如,作者后来提到质量是无法衡量的。必须确保在软件生命周期的各个阶段进行相关活动。不要打开质量检查参与者。首先,在需求分析阶段,质量保证可以从不同的角度提出,补充和修改需求。由于QA独特的技术背景以及对软件可用性的更深入了解,因此它通常可以提出不同于业务分析师和开发人员的建议。观点,在开发阶段,质量检查人员还将审查由开发人员编写的自动化测试,并通过质量检查人员的专业测试背景帮助开发人员编写更有价值的测试。例如,我们在项目中发现开发人员编写了许多没有商业价值的测试。 ,测试阶段,探索性测试,可用性测试,安全性测试,性能测试等都是质量检查人员正在做的事情。当然,如果业务分析师从各个角度全面,完美地分析业务,则开发人员可以编写非常有价值的测试,也可以执行各种类型的手动测试。消除全职质量检查并非不可能,事实并非如此。需要质量检查,但每个人都是质量检查。结论上面列出的七个要点是您第一次接触敏捷测试时容易产生的误解。在一些已经敏捷了很长时间的团队中仍然存在一些意见。这些视图很容易导致敏捷测试绕道而行。以上是一些个人的想法,结合实际的项目经验,希望对大家有所帮助。