到底是用手工测试还是自动化测试?
上一篇 / 下一篇 2008-04-28 13:35:23 / 个人分类:讨论
相关阅读:
- 下周开始尝试QA对开发过程的控制 (Lola1123, 2007-3-02)
- TD 7.6 中拒绝对原有defect的修改 (Lola1123, 2007-3-06)
- 用QTP录制时如何识别编辑框?? (Lola1123, 2007-3-15)
- 脚本回放中不能触发Click事件 (Lola1123, 2007-3-16)
TAG: 讨论
- 引用 删除 songwj0806 / 2008-04-28 13:37:18
-
这里还有一篇文章:
该手工测试还是自动测试?
自动测试的概念炙手可热,但它能代表一切吗?微软的一名测试技术领导(Test Technical Lead)Michael问道:“你怎么才能知道你到底是把自动化进行得恰如其分,还是行之过甚了?”
自动化测试的用例非常容易。稍微花点精力,我们就可以以固定频率对代码进行回归测试,而很少或者根本不需要开发人员介入。然而,和大多数技术一样,并不是所有时候它都按照你的计划工作。
自动测试生来就是用脚本写成的,而不是探索性的。即便我们使用的是一个引入了所有可能情况的自动测试组合,我们的测试也只能在它们覆盖的地方游刃有余,但 对于其它没有涵盖到的地方,它们就鞭长莫及了。如果出现了哪些没有预料到的情况,那么它们很可能就挂掉了,而且即使它们能够从这些情况中恢复过来,它们还 是无法停止正在处理的任务并检查没有预料到的情况。另外,别忘了要保持测试运行的维护,但这个过程并不能帮你找到程序中的缺陷。那么,你还有时间使用你的 程序吗?
Michael接着讨论了手工测试优缺点,包括探索式测试的涵盖度和无法在每次构建之后进行完整的测试。
另外一种极端的方式是不对任何东西进行自动测试。在这种情况下,每个测试用例都是由人使用鼠标和键盘手动执行的。这种方式能带来显而易见的回报:每个测试 都会是探索性的。整个产品的方方面面都很可能被完全涵盖。如果出现任何意外问题,很容易就能跟进并处理。我们不需要进行任何维护来保证测试用例与应用程序 的变更保持一致,每个人都在不断使用着应用程序。太美妙了,不是吗?
最后,他提出了一个问题:“对于我来说,很显而易见将所有测试都自动化是不切实际的,反之亦然。目前为止我还没有找到最合适的平衡点。你呢?”
当第一个可测试的版本产生后,测试人员开始对这个版本的系统进行测试,很快第二个版本在第一个版本的技术上产生了,测试人员需要在第二次测试时重复上次的测试工作,还要新增加的功能进行测试,每经过一个迭代测试的工作量会逐步的累加.随着软件开发过程的进展,测试工作变得越来越繁重,如果使用手工测试的方法,将很难保证测试工作的进度和质量.在这种情况下应用良好的自动测试工具将势在必行.通过使用自动化测试工具测试人员只要根据测试需求完成测试过程中的所需的行为,自动化测试工具将自动生成测试脚本,通过对测试脚本的简单修改便可以用于以后相同功能的测试了,而不必手工的重复已经测试过的功能部分.
你的观点呢?
标题搜索
日历
|
|||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
1 | 2 | 3 | 4 | ||||||
5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
26 | 27 | 28 | 29 | 30 |
我的存档
数据统计
- 访问量: 45769
- 日志数: 60
- 书签数: 1
- 建立时间: 2008-01-04
- 更新时间: 2012-02-18