自动化测试策略与决策

需积分: 0 120 浏览量更新于2024-08-01 收藏 122KB PDF 举报

"自动化测试是软件测试领域的重要组成部分，它旨在通过使用专门的工具和技术来减少手动测试的工作量，提高测试效率和准确性。本文由Brian Marick撰写，探讨了何时应该进行自动化测试以及如何做出理性的决策。 Brian Marick指出，尽管自动化测试能有效地找出程序中的错误并确保代码质量，但并不意味着所有测试都应该自动化。他强调测试人员的主要职责是成本效益，而不是单纯追求舒适感。有时候过度自动化可能会导致资源浪费，因为有些自动化测试在多次运行后并未发现新的错误，未来也未必能有效捕获问题。作者提出，决定是否自动化测试的关键在于权衡。在为产品特性设计一系列测试时，测试人员需要评估每个特定测试的自动化价值。他建议考虑以下几个场景： 1. **重复性**：如果一个测试需要频繁执行，如回归测试，自动化可以显著提高效率，减少人工错误。 2. **复杂性**：对于涉及大量步骤或需要精确控制环境的复杂测试，自动化可以确保一致性和可重复性。 3. **稳定性**：稳定的测试用例更适合自动化，因为它们不太可能因软件修改而频繁变更。 4. **成本**：自动化测试的开发和维护成本必须低于其带来的长期收益。包括时间、人力和资源在内的成本应纳入考量。 5. **回归价值**：考虑测试在未来的回归测试中找出新错误的能力。如果一个测试在过去没有发现过重要的bug，自动化它的价值可能就相对较低。此外，Marick还提到，**变更频率**也是一个重要因素。如果代码经常变化，自动化测试可能需要频繁更新，这增加了维护负担。相反，对于相对稳定的部分，自动化测试可以提供更稳定的保障。在做决策时，测试人员还需要考虑团队的技能和自动化工具的适用性。选择合适的自动化框架和工具对实现高效自动化测试至关重要。同时，培训团队成员掌握自动化测试技能也是必要的投入。自动化测试是一种策略，而非目标。测试人员应当基于具体项目的需求和资源，理性地判断哪些测试适合自动化，以实现最佳的测试效果和投资回报。通过这种方式，可以确保自动化测试真正成为提升软件质量的有力武器。"

When Should a Test Be Automated?

Or you might be a testing version 1.0 of a shrinkwrap product whose product direction

and code base has changed wildly in the last few months. Your answer might be "Ha! I

don’t even have time to try all the obvious tests once. In the time I would spend

automating this test, I guarantee I could find at least one completely new bug." For you,

the cost of automation is high.

My measure of cost - bugs probably foregone - may seem somewhat odd. People usually

measure the cost of automation as the time spent doing it. I use this measure because the

point of automating a test is to find more bugs by rerunning it. Bugs are the value of

automation, so the cost should be measured the same way.

A note on estimation

I’m asking you for your best estimate of the number of bugs you’ll miss, on average, by

automating a single test. The answer will not be "0.25". It will not even be "0.25 ±

0.024". The answer is more like "a good chance at least one will be missed" or "probably

none".

Later, you’ll be asked to estimate the lifetime of the test. Those answers will be more like

"probably not past this release" or "a long time" than "34.6 weeks".

Then you’ll be asked to estimate the number of bugs the automated test will find in that

lifetime. The answer will again be indefinite.

And finally, you’ll be asked to compare the fuzzy estimate for the manual test to the fuzzy

estimate for the automated test and make a decision.

Is this useful?

Yes, when you consider the alternative, which is to make the same decision - perhaps

implicitly - with even less information. My experience is that thinking quickly about these

questions seems to lead to better testing, despite the inexactness of the answers. I favor

imprecise but useful methods over precise but misleading ones.

How Long Do Automated Tests Survive?

Automated tests produce their value after the code changes. Except for rare types of

tests, rerunning a test before any code changes is a waste of time: it will find exactly the

same bugs as before. (The exceptions, such as timing and stress tests, can be analyzed in

the roughly same way. I omit them for simplicity.)

But a test will not last forever. At some point, the product will change in a way that

breaks the test. The test will have to either be repaired or discarded. To a reasonable

approximation, repairing a test costs as much as throwing it away and writing it from

I first learned to think about the cost of automation in this way during conversations with Cem Kaner. Noel Nyman

points out that it’s a special case of John Daly’s Rule, which has you always ask this question of any activity: "What

bugs aren’t I finding while I’m doing that?"

剩余19页未读，继续阅读

moofox

粉丝: 1
资源: 7

自动化测试策略与决策

软件测试之自动化测试.docx

软件测试自动化 软件测试自动化

软件测试之自动化测试流程

软件测试 自动化测试

软件测试自动化课堂笔记

Python软件测试自动化课件

软件测试接口测试跟自动化测试是什么

软件测试自动化pdf

软件测试自动化如何学习

软件测试大赛自动化测试答案

最新资源

软件测试自动化软件测试自动化

软件测试自动化测试