51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2993|回复: 3
打印 上一主题 下一主题

When Should a Test Be Automated? 01

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-1-10 12:48:14 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
Brian Marick

Testing Foundations
marick@testing.com

I want to automate as many tests as I can. I’m not comfortable running a test only once.What if a programmer then changes the code and introduces a bug? What if I don’t catch that bug because I didn’t rerun the test after the change? Wouldn’t I feel horrible?


Well, yes, but I’m not paid to feel comfortable rather than horrible. I’m paid to be costeffective.It took me a long time, but I finally realized that I was over-automating, that only some of the tests I created should be automated. Some of the tests I was automating not only did not find bugs when they were rerun, they had no significant prospect of doing so. Automating them was not a rational decision.


The question, then, is how to make a rational decision. When I take a job as a contract tester, I typically design a series of tests for some product feature. For each of them, I need to decide whether that particular test should be automated. This paper describes how I think about the tradeoffs.
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2006-2-6 16:41:57 | 只看该作者
我想尽可能的让所有的测试都能自动执行,但我不能舒适的执行,哪怕只有一次。因为程序员若改表代码并且引进bug怎么办?我若因为没有在程序改变后重新测试怎么办?我不会感觉到厌烦吗?就是这样, 但我被要求舒适而不是厌烦,也被要求是有效的。这些花费我很长时间, 但我最终意识到我在过度自动化, 我创建的测试用例中只有一部份应该被自动化测试。 我的这些自动化测试在他们被重新运行时不仅没有查找到bug,而且也没有重大潜在意义要如此做。 自动化测试不是一个合理的决策。然后的问题是怎么做出合理的决策。 当我作为合同测试人员的工作时, 我为产品某些性能设计了一系列典型的测试用例。 对于他们中的每一个, 我需要决定那些特殊测试用例是否应该被自动化执行。 文章描述我怎么考虑平衡。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2006-2-6 16:44:09 | 只看该作者
试着翻译了这一段,感觉不是很好,需要努力阿。
自勉一下!
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2006-2-7 09:07:05 | 只看该作者
+u+u
继续努力:)
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-9-23 18:27 , Processed in 0.064183 second(s), 25 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表