软件开发敏捷软件开发

软件开发敏捷软件开发

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