软件开发敏捷软件开发

软件开发敏捷软件开发

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