发布时间: 2013-2-06 11:26 作者: 曾月天 译 来源: 51Testing软件测试网采编
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推荐标签：
软件测试 手动测试
自动化测试
几个星期以前我遇到我们团队中的自动测试专家，从他们那里得到了一些什么时候适宜进行自动测试什么时候适合进行手动测试的信息。其实掰掰手指头都能想到，必须使用常识来决定。如果你只需要运行测试一两次，或者做自动测试非常昂贵，那最好采用手动测试。不过，在使用常识之前，你必须拿出确定的一些关于何时开始自动化测试的指导方针。
自动测试的好处：
如果你需要反复运行一组测试，那么自动测试将会对你非常有用。
（回归测试，build测试，压力测试，负载测试，性能测试，安全测试，缺陷追踪测试等等这些测试场景相同，需要多次执行的，就适合自动化测试）
自动测试使你能够应对频繁改变的代码从而跟上周期性回归测试的脚步。（不错，所以自动化测试特别适合回归测试）
自动测试可以使你能够自动运行主流业务场景从而跟上周期性回归测试的脚步。（原文：It gives you the ability to run automation in main stream scenarios to catch regressions in a timely manner）（自动化测试的好处就是在测试框架搭建好后，新的需求变更引起的业务场景的变更，比手工测试的update效率更高，成本更低）
自动测试可以帮助你测试大量测试矩阵（在不同
操作系统上的不同语言）。自动测试可以使你的测试同时运行在不同的机器上，而手动测试必须不断地继续执行。
（自动化测试的可以用一套脚本进行版本测试和分布式测试，对于web gui的测试，效果是倍增的。）
自动测试的限制：
花费大。编写
测试用例，编写和配置自动化测试框架将会在测试开始时花费比手动测试更多的费用。
（其实自动化测试的成本在任何时刻都是比手工测试高的，并不是自动化测试的速度比手工测试的速度快，就武断的认为自动化测试的成本低。自动化的成本唯一的好处是对一个成型的产品，能够减少回归测试的成本，但是必须是长生命周期的项目，一般2年左右的才有必要去大规模自动化覆盖，对于6个月以内的产品，除非是同架构的产品，否则很难套用原有的测试框架，往往得不偿失）
无法自动测试一些可视的场景。例如，如果你无法通过代码告诉自动测试工具字体颜色，那么只好使用手动测试。
（自动化测试的测试用例，首先就要和手工测试用有所区别，两者的scope是有迭代，但是也有各自的独立范畴，如何挑选测测试用例进行自动化转换，是一个技术活，例如，字体的颜色，其实是可以进行自动化验证的，比如固定的模板色的话，或者使用同一CSS文件的情况下）
手动测试的好处：
如果一个测试用例在编码阶段只运行两次，那最好使用手动测试，它将比自动测试花费少得多的费用。
（其实现在很多自动化工具并非是针对case进行转制的，比如cucumber，是基于正则表达式的，往往只需要1周时间，对100多条正则表达式与自动化脚本进行匹配，就能实现全面自动化，所以现在以执行频度去考虑是否进行自动话，实际上已经过时了）
手动测试允许测试员进行更多的随机测试。以我的经验来看，更多的bug将会由随机测试发现，而不是自动测试。并且，一个测试员花费越多的时间进行随机测试，发现真正的用户bug的几率就越大。
（随机测试的实现，自动化工具更加有效率，之所以随机测试发现更多的bug，就在于自动化转制时，选择的手工测试用例的覆盖率偏低，overlap的场景太少，业务逻辑和workflow只考虑了正向等等愿意，很多公司在转制自动化时，是使用录制的方式，依据现有的手工测试用例，其实这时，基本上能够录制成功的话，已经很难发现miss的bug，最多只能在后续的版本中发现一些regression bug，所以很多自动化之后，发现没有比手工测试发现更多的bug，就认为自动化测试的效果不佳，是错误的。根源除了以上之外，还是对自动化脚本的target没有过的考虑，从出发点上就是模糊的）
手动测试的限制：
手动进行测试将花费大量的时间。
（手工测试未必就比自动化测试花费的时间更多，有很多操作，自动化因为缺少上下文，所以很多pre-condition需要准备，而手工测试反而可以直接忽略了这些pre-condition）
每次有了新的build，测试员必须重新运行测试-经过一段时间以后将会非常繁琐和疲惫。
（其实手工测试的plan和method设置的很好的话，手工测试也很轻松，原来好多公司都经常在一个新版本上进行所有测试用例的回归测试，带来的是麻木和大量的缺失。其实通过引入case的severity和priority，以及bug的分析等因素，完全可以设定选取测试用例的范围，未必要都测试）
其他的因素：
你将哪些部分进行自动测试也由你使用的工具决定。如果该工具有很多限制，那么这些部分还是手动测试吧。
（究竟是根据需求选择测试工具，还是根据测试工具选择测试范围，这是个难题。所以，解决之道还是你想使用自动化测试达到什么效果，你的目标是什么，才能去选择工具和划定范畴，为了纯粹自动化而自动化，是很多公司的现状，完全没有人去考虑我究竟为什么自动化，就为了说我们是自动化测试的？自动化很流行，所以我们也要自动化？自动化的测试工程师才是最好的测试工程师？）
是否投资的回报值得运行自动测试？是否你自动化测试的产出值得建立和支持测试用例，自动框架和运行测试用例的系统？
（恩，自动化的过程很复杂，有些公司是为了降低成本，有些公司为了提高竞争力，有些公司是为了锻炼技术，总之，自动化的目的太多了，完全要依据你自己的需求）
自动测试的标准
有两个问题可以用来判断是否应该为你的测试用例进行自动化。
Q1：是否测试场景可以自动化？ （
A1：是的，并且花费很少。
A2：是的，但是花费很多。
A3：不，不可能进行自动化。
Q2：该测试场景有多么重要？
A1：我必须在任何可能的时候都对其进行测试。
A2：我需要有规律地对该场景进行测试。
A3：我只需要测试该场景一次。
如果这两个问题你的答案都是#1，那么你肯定需要自动化该测试。
（还是上面说的，自动化的目的是什么才能决定是否自动化，上面两个问题，更像是在自动化过程中，如果进行优先级的安排的问题，那些先自动化，那些后自动化）
如果这两个问题你的答案是一个#1和一个#2，那么你最好自动化该测试。
如果这两个问题你的答案都是#2，那么你应该好好考虑一下是否你值得为自动化测试投资。
如果你无法自动测试，会有什么结果
让我们假设如果你有一个测试必须在任何可能的时间运行，但是却无法自动化它，你的选择是：
再评估 – 是否我真的需要如此频繁地运行它？
如果手动测试它会有多大的花费？
寻找新的测试工具。
（没有一种测试工具是万能的，自动化的本质还是个工具，能否成功的进行自动化，还是取决于你测试的基本素质，手工测试能够组织的优秀的团队，进行自动化就是一个游戏的过程）
