自动化测试方法

时间:2009-11-05 10:29:01

标签: unit-testing testing automated-tests

我们编写了许多对我们来说非常有效的集成测试,我们确实尝试引入单元测试,但发现它更难以引入,因为它需要更长时间并且好处并不那么明显。

我们仍然让测试人员手动完成测试脚本。我们还有很长的路要走自动化测试流程,我们想知道其他人如何处理它以及您使用哪些工具?

谢谢,

7 个答案:

答案 0 :(得分:4)

“花费的时间更长,效益并不明显”

总是如此。质量似乎预先花钱。

“我们仍然让测试人员手动完成测试脚本”

人们声称这更便宜?怎么样或为什么?

“接近它,你使用什么工具?”

自动化一切。这不是可以谈判的。管理压力,以减少投入测试的时间是我总是翻译为“你的意思是降低质量,所以我们可以花更多的时间做返工?我不能。找到其他人喜欢做返工。我讨厌返工,因为它总是更昂贵并且比靠近前面更复杂。“

答案 1 :(得分:3)

众所周知,你需要进行单元测试。首先为新内容编写单元测试。 TDD在这里会很好;) 对于手动测试人员,如果你有很多,我会尝试切换自动功能测试。慢慢但不断地将所有手动测试转换为自动测试 让少数(最好的)手动测试人员进行探索性测试。让他们专注于新东西,因为其他一切都应该准备好自动套装。

所以你将进行自动化单元测试(持续集成,你现在?),自动化功能测试(回归和填充),以及新东西的手动探索性测试(直到功能足够稳定以便为它们创建自动化套装)。 / p>

至于工具。
对于单元测试,它取决于您使用的技术 至于功能性HP QTP(或IBM Rational Robot)。让惠普质量中心支持测试管理(或IBM tool set如果您愿意)可能是明智之举 至于探索性测试TestExplorer(它可以与HP Quality Center通信),但也可以使用简单的记录工具。

答案 2 :(得分:1)

修改 (因为有人投了票)
这个答案是关于你问题的一部分:人们使用的工具。我的链接提供了有关团队用于自动化产品测试的测试工具的信息。

自动化测试工具

在Stackoverflow上检查此搜索:
Questions tagged Automation & Testing

答案 3 :(得分:1)

您可以通过手动测试人员看到的折衷方案是找到一种方法来输出数据结果并在不同版本之间进行比较。

例如传递x组数据,你知道你得到y输出。如果你针对上一个生产版本然后是最新版本执行此操作。并且寻找输出是一样的。


单元测试会为您提供一些您目前可能没有的东西。除了测试仪之外的事情更快,更频繁,更广泛

- 将强制您模块化和解耦代码  例如,如果您的代码混合了GUI和数据层,则必须将其与单元测试分离。但是在你这样做之后,你可以拿出各种各样的东西,并在不同的项目中重复使用它们。

- 可以帮助记录您的应用程序逻辑。我的意思是,如果您的应用程序具有需要一些数据x和输出数据y的代码。您可以在单元测试中编写和记录用例。所以你会知道什么时候x会出现什么y。当新开发人员进入项目时,他们可以查看工作单元测试(即使规范存在也是正确的吗?)

答案 4 :(得分:1)

将单元测试改造为遗留代码(即没有单元测试的代码)非常困难。有一本关于此的书:Working effectively on legacy code。在开发新代码时应该应用单元测试。

如果没有正在测试的产品类型的信息,推荐工具并不容易。您可能必须添加内部接口以便测试工具可以激活产品:要测试基于GUI的应用程序,您可以添加未记录的选项以提供将模拟用户操作的命令文件。

查看手动测试中更繁琐且容易出错的任务,测试人员最常抱怨的是什么。

逐步自动化您的测试步骤,例如,先测试执行,然后在第二阶段进行结果验证(PASS / FAIL标准)。

在开始时保持硬任务手册(例如安装,配置)。

简而言之,应用低挂果策略。

还努力通过自动测试重现代码库中修复的每个问题,这将有助于验证修复并构成自动回归测试。

脚本(bash,Perl,Powershell,无论如何)在处理自动化时肯定是有帮助的。

答案 5 :(得分:1)

在您的方案中,一个好的策略是应用“成本效益”分析。对于例如具有复杂逻辑的代码可能是单元测试的正确候选者,而与外部Web服务或数据库交互的代码不适合进行单元测试。这只是一个例子。您必须进行的调用可以是上下文。

对复杂的逻辑代码段进行单元测试比为非逻辑组件进行集成测试带来更多价值。此外,集成测试是一项涉及单元测试的更复杂的活动。在采用当前趋势时,建议采用以下顺序:

单元测试(自动化) - >集成测试(自动化) - >系统测试(自动化) - >功能测试(手动)

答案 6 :(得分:1)

自动化单元测试 - 几乎所有单元测试都可以自动化,但是在设计和维护测试时需要付出努力。它可以保证低级代码是正确的。

构建验证测试 - 每天在自动构建上运行,让开发人员可以放心,他们的代码很强大。这种类型的测试通常会在周期的早期发现问题。

功能测试 - 在发布之前运行更大批量的自动化测试。一般的经验法则是功能测试的40%到60%之间可以自动化。这也可以分解为自动性能测试,安全测试,可靠性测试等。