到底是用手工测试还是自动化测试？

songwj0806 · 发表于 2008-4-28 13:31:26

我是一名刚工作不久的测试员，今天看着流程图时突然脑海里冒出一个念头：到底是用手工测试还是自动化测试的好？测试工作无论是手工测试还是自动化测试都是软件质量保障的一个途径。如何更好的使两者相互结合也是我们现在所要讨论的话题。我们何时应用手工测试又何时应用自动化测试呢？我在网上搜索了一下，看了一些资料，觉得对于一些基本的、逻辑性不强的操作，可以使用自动化测试工具。应该说，现在在性能测试、压力测试等方面，自动化测试有其不可替代的优势。它可以用简单的脚本，实现大量的重复的操作。从而通过对测试结果的分析，得出结论，这样不仅节省了大量的人力和物力，而且使测试的结果更准确。对于一些逻辑性很强的操作，如果自动化测试不是很健全的话，不建议使用。因为这需要比较复杂的脚本语言，不可避免的增加了由于测试脚本的缺陷所造成测试结果错误的误差。这时就需要手动测试了。手工测试也存在这一些缺陷，手工测试者最常做的就是重复的手工回归测试，不但代价昂贵，而且容易出错。自动化测试可以减少但不能消除这种工作的工作量。测试者可以有更多的时间去从事更有趣的测试,例如在应用程序在复杂的场景下的不同处理等，尽管测试就是要花费更长的时间找到错误，但比不意味着因此而要付出更高的代价。所以选择正确的测试方法是尤为重要的。具体叙述如下：
1、自动化测试对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
2、可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。
3、可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
4、更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
5、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。
6、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
7、增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。
但是我也要在这里说明一下自动化测试的缺点：
1、不能取代手工测试；
2、往往手工测试比自动测试发现的缺陷更多；
3、对测试质量的依赖性极大；
4、测试自动化不能提高有效性；
5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发；
6、工具本身并无想像力。
综上所述，可以归结自动化完成不了的，手工测试都能弥补，两者有效的结合是测试质量保证的关键。但这个度就需要你来把握了，不知各位高手是否愿意说下：你是怎么把握这个临界点的？

songwj0806 · 发表于 2008-4-28 13:36:40

这里还有一篇文章：
该手工测试还是自动测试？
自动测试的概念炙手可热，但它能代表一切吗？微软的一名测试技术领导（Test Technical Lead）Michael问道：“你怎么才能知道你到底是把自动化进行得恰如其分，还是行之过甚了？”
自动化测试的用例非常容易。稍微花点精力，我们就可以以固定频率对代码进行回归测试，而很少或者根本不需要开发人员介入。然而，和大多数技术一样，并不是所有时候它都按照你的计划工作。
自动测试生来就是用脚本写成的，而不是探索性的。即便我们使用的是一个引入了所有可能情况的自动测试组合，我们的测试也只能在它们覆盖的地方游刃有余，但对于其它没有涵盖到的地方，它们就鞭长莫及了。如果出现了哪些没有预料到的情况，那么它们很可能就挂掉了，而且即使它们能够从这些情况中恢复过来，它们还是无法停止正在处理的任务并检查没有预料到的情况。另外，别忘了要保持测试运行的维护，但这个过程并不能帮你找到程序中的缺陷。那么，你还有时间使用你的程序吗？
Michael接着讨论了手工测试优缺点，包括探索式测试的涵盖度和无法在每次构建之后进行完整的测试。
另外一种极端的方式是不对任何东西进行自动测试。在这种情况下，每个测试用例都是由人使用鼠标和键盘手动执行的。这种方式能带来显而易见的回报：每个测试都会是探索性的。整个产品的方方面面都很可能被完全涵盖。如果出现任何意外问题，很容易就能跟进并处理。我们不需要进行任何维护来保证测试用例与应用程序的变更保持一致，每个人都在不断使用着应用程序。太美妙了，不是吗？
最后，他提出了一个问题：“对于我来说，很显而易见将所有测试都自动化是不切实际的，反之亦然。目前为止我还没有找到最合适的平衡点。你呢？”
当第一个可测试的版本产生后,测试人员开始对这个版本的系统进行测试,很快第二个版本在第一个版本的技术上产生了,测试人员需要在第二次测试时重复上次的测试工作,还要新增加的功能进行测试,每经过一个迭代测试的工作量会逐步的累加.随着软件开发过程的进展,测试工作变得越来越繁重,如果使用手工测试的方法,将很难保证测试工作的进度和质量.在这种情况下应用良好的自动测试工具将势在必行.通过使用自动化测试工具测试人员只要根据测试需求完成测试过程中的所需的行为,自动化测试工具将自动生成测试脚本,通过对测试脚本的简单修改便可以用于以后相同功能的测试了,而不必手工的重复已经测试过的功能部分.

你的观点呢？

wangting423 · 发表于 2008-5-4 21:17:26

如果测试脚本经常维护的话，人手又不足的话，建议还是人工测试。

chech28 · 发表于 2008-5-5 10:10:12

偶感觉这个话题将来将成为测试届的月经贴。。。

cityyard · 发表于 2008-5-6 20:51:05

“自动化测试的用例非常容易。稍微花点精力，我们就可以以固定频率对代码进行回归测试，而很少或者根本不需要开发人员介入。然而，和大多数技术一样，并不是所有时候它都按照你的计划工作。
自动测试生来就是用脚本写成的，而不是探索性的。即便我们使用的是一个引入了所有可能情况的自动测试组合，我们的测试也只能在它们覆盖的地方游刃有余，但对于其它没有涵盖到的地方，它们就鞭长莫及了。如果出现了哪些没有预料到的情况，那么它们很可能就挂掉了，而且即使它们能够从这些情况中恢复过来，它们还是无法停止正在处理的任务并检查没有预料到的情况。另外，别忘了要保持测试运行的维护，但这个过程并不能帮你找到程序中的缺陷。那么，你还有时间使用你的程序吗？”

上面这段不是完全赞同