敏捷测试/传统测试方法

发布于 2024-10-07 09:53:14 字数 1436 浏览 2 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

八巷 2024-10-14 09:53:14

敏捷测试方法有哪些?传统的测试方法有哪些?

本身并不存在“敏捷测试方法”,而只有在敏捷环境中进行的测试。即使它们存在,您也无法在瀑布组织中成功使用“敏捷测试方法” - 所以您的概念在那里有点错误。

无论如何,为了给您一些建设性的反馈,测试功能很可能与瀑布一样,但在敏捷环境中以下可能有所不同:

  1. 气氛和文化将更加协作(更多面对面的互动),< /p>

  2. 测试人员会尽早参与,

  3. 团队会针对测试进行编码,而不是首先编码,然后创建测试计划,

  4. 您将是跨职能的,因此您可能必须编写代码或执行需求收集,您将与客户密切合作,

  5. 您将在 2 - 4 周迭代,

  6. 您将不断改进您的测试程序

  7. 您将不会进行 QA/测试部门

  8. 您的角色将是“拥有最多测试经验的团队成员”而不是“测试人员”

严重的是,传统方法大多与上面的检查列表完全相反。

What are the agile testing methods? And what are the traditional testing methods?

There are no "Agile Testing Methods" by itself as such but only testing done in an Agile Environment. Even if they exist, you cannot use "Agile Testing Methods" successfully in a waterfall organisation - so you have your concepts a little wrong there.

Anyway to give you some constructive feedback, the testing functions may very well be the same like waterfall, but the following may be different in an Agile Environment:

  1. atmosphere and culture would be more collaborative (more face to face interaction),

  2. tester involvement would be early,

  3. the Team would code to a test, rather than code first and then create a test plan,

  4. you would be cross functional so you may have to write code or do requirements gathering, and you will work closely with the customer,

  5. you would work in 2 - 4 week iterations,

  6. you would continually improve your testing procedures

  7. you will not have a QA/Testing department

  8. your role will be a "Team member who has most Testing experience" rather than "Tester"

Traditional methods are mostly the exact opposites of the check list above, seriously.

挽清梦 2024-10-14 09:53:14

在传统测试中,假设采用瀑布流程,测试发生在开发阶段之后。测试人员根据项目开始时收集的需求创建测试。从传统意义上来说,大型组织的 QA 部门与开发部门完全分开,开发部门负责编写最终的应用程序和文档来编写测试用例。

敏捷环境中,测试与开发异步进行,以便当开发人员完成任务时对其进行测试,以便在迭代结束时,利益相关者知道该任务是功能齐全且经过测试的。如果发现错误,可以在周期的早期修复它们,而不是在最后阶段修复。

这并不假设每个团队都使用 TDD 甚至 配对/极端编程。

敏捷的目标之一是改善团队成员之间的沟通。测试人员参与迭代计划和审查会议,使他们能够更深入地了解给定任务要完成的任务。这将帮助他们编写超出有时模糊的黑白要求的测试。

我不同意敏捷不能扩展到包含 QA 部门的大型项目的观点。是的,在许多情况下以及一些作者的建议中,敏捷团队的成员不足 10 人,但测试对于交付高质量项目来说是不可或缺的。挑战在于,当公司围墙限制了进展时,如何继续前进。如何在我的会议或团队中邀请测试人员?我们如何才能让 QA 更多地参与进来,让客户满意? ETC。

In traditional testing, assuming waterfall process, testing happens after the development phase. Testers create their tests from the requirements gathered at the beginning of the project. In the stereotypical sense, large organizations have a QA department completely separated from development departments where they are handed the final application and documentation to write test cases from.

In an agile environment testing occur asynchronously with development so that when a developer finishes a task it is tested so that at the end of the iteration the stakeholders know the task is a fully functional and tested. If bugs are revealed, they can be fixed earlier in the cycle, not in the final stretch.

This does not assume that every team writes using TDD or even pair/extreme programming.

One of the goals of agile is to improve communication between team members. Testers are included in the iteration planning and review meetings giving them more insight into what a given task is to accomplish. This will help them write tests beyond the sometimes vague black and white requirements.

I disagree with the notion that agile does not scale to larger projects that incorporate a QA department. Yes, in many cases and in some author recommendations agile teams are made of less than 10 but testing is integral in delivering a quality project. The challenge is how to proceed when corporate walls limit progress. How can I get a tester in my meetings or on my team? How can we get the QA more involved so that the customers are happy? etc.

柳若烟 2024-10-14 09:53:14

我不确定是否有任何敏捷专用的“测试方法”。

当然有“测试驱动”(tdd)和“行为驱动”(bdd)开发,但我不认为这些是“测试方法”。

单元测试对于敏捷或传统来说并不特殊。

正如 @khachik 提到的:(在开发过程中)设计和应用测试时通常会存在巨大差异。

传统 = 瀑布或 V 模型:测试最终完成(如果有的话)

敏捷:测试应该在编写代码之前编写。

I am not shure if there are any "testmethods" that are special to agile.

Of course there is "testdriven" (tdd) and "behaviordriven" (bdd) development but i donot see these as "testing methods".

Unittests are not special to agile or traditional.

As @khachik mentioned it: there is offen a huge difference when (in the develpment process) the tests are desigend and applied.

Traditional = Waterfall or V-Modell: Test are done in the end (if at all)

Agile : Test should be written before the code is written.

倦话 2024-10-14 09:53:14

您的问题有点不清楚,但如果我将其改写为“敏捷环境与瀑布型环境中的测试方法有何不同”,您可能会得到以下答案:

  • 在敏捷环境中,测试至少定期完成迭代(冲刺)。在瀑布式环境中,测试往往在开发完成后进行。
  • 在敏捷环境中,测试通常以测试驱动开发(TDD)的形式包含在开发中)。在瀑布环境中,测试是实施的一个单独阶段。

在实践中,这是一个深刻的话题,对于如何进行开发和测试有着复杂的看法。 TDD 是一个预先思考的过程,理论上消除了对终端测试人员的需求。一些人认为,无论定义的验收标准和测试有多少,仍然需要精通探索性测试的人员案例。

你的问题甚至我的改写中的挑战是软件测试并不是一件简单的事情在一处,也没有一种形状。至于实际上是如何做或应该如何做,有数千篇关于该主题的文章有很多观点。

Your question is a bit unclear, but if I rephrase it as "How do testing methods differ in Agile environments versus waterfall type environments" you may get answers along the lines of:

  • In an Agile environment testing is, at a minimum, done at regular iterations (sprints). In waterfall style environments, testing tends to be performed after development is complete.
  • In an Agile environment testing is often included within development in the form of Test Driven Development (TDD). In a waterfall environment, testing is a separate stage of implementation.

In practice, this is a deep topic with complex perceptions on how development and testing should be done. TDD is an up front thinking process and in theory removes the need for end testers. Some argue that people skilled in Exploratory Testing are still needed regardless of the number of defined acceptance criteria and test cases.

The challenge in your question and even my rephrasing is that Software Testing isn't a simple thing that fits in one place nor has one shape. As for how it is actually done or should be done, there are thousands of articles on the topic with many opinions.

a√萤火虫的光℡ 2024-10-14 09:53:14

我建议您首先查看 Bret Pettichord 关于不同软件测试流派的演示文稿。不仅有两种流派——敏捷流派与传统流派,而是至少有五流派。这是一个很好的总结,可以让您快速概览。

上面由 Lisa Crispin 和 Janet Gregory 发布的敏捷测试链接很好,但我也强烈推荐:

Elizabeth Hendrickson - 去年的 Pask 奖获得者。敏捷测试员。您为什么还没有点击该链接?

另外值得一读:上下文驱动测试原则

I'd suggest that you look up Bret Pettichord's presentation on the different schools of software testing, as a start. There aren't just two schools - agile vs traditional, but at least five. It's a great summary that will give you a quick overview.

The link posted above for Agile Testing, by Lisa Crispin and Janet Gregory is good, but I'd also strongly recommend:

Elizabeth Hendrickson - last year's Pask award winner. Agile tester. Why haven't you clicked on that link yet?

Also worth reading: the Context-driven Testing principles

安静 2024-10-14 09:53:14

在传统方法中,首先进行整个开发,然后开始测试,无论发生什么错误都由开发人员修复。

在敏捷方法中,测试是一个连续的过程,它与软件组件的开发同时完成。
从回归的角度来看,这种类型的测试会更有效。

与传统技术相比,敏捷测试是一个快速的过程。

In traditional methods first the entire development will takes place then testing will start,whatever bugs are occur are fixed by developers.

In agile methodology testing is a continuous process and it done concurrently with the development of the software components.
For regression perspective this type of testing will work more efficiently.

Agile testing is a fast process as compare to the traditional techniques.

怪我太投入 2024-10-14 09:53:14

(遵循敏捷软件开发原则的实践称为敏捷测试。)
用外行人的话说,测试可以指的是通过对一个人或一个组织施加压力来揭示他们的能力。具有挑战性的。它也可以指首先制定计划,实现目标,估计和规划所有程序和涉及的风险,然后测试是否正在朝着既定目标前进。如果没有,那么敏捷可以帮助改变和制定计划并解决障碍,以最终实现目标。通过敏捷测试,现在可以轻松检查过程之间的工作情况,这与瀑布方法不同。敏捷是一种迭代开发方法,其中需求通过客户和自组织团队之间的协作而发展,敏捷使开发与客户需求保持一致。

(A practice that follows the principles of agile software development is called Agile Testing.)
In a lay man’s term, testing can be referred to as revealing a person's or an organization’s capabilities by putting them under strain; challenging. It can also be referred to as making a plan first, realizing the goals, estimating and planning all the procedures and the risks involved and then testing- whether one is proceeding towards the decided goal or not. In case not, then agile helps to change and formulate the plan and fix the hindrances in order to meet the goal finally. With agile testing it has become easy now to check the workings in between the procedure unlike the waterfall method. Agile is an iterative development methodology, where requirements evolve through collaboration between the customer and self-organizing teams and agile aligns development with customer needs.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文