一、测试的困惑

以前我时常反思，测试组的工作多吗？我的回答是多。测试小组的工作成果的好坏和工作任务的多少成正比吗？最终的回答却并非成正比。我们的测试工作成果往往并不理想，甚至是差。那么为什么事倍功半？这问题很难找到清晰的答案。

参与了外部培训之后，发现了自己在对测试的工作有了新层次的理解。对之前工作成果差的问题思考也有了新的方向。“测试的最高境界是找出所有BUG吗？不是，测试的最高境界是不需要进行测试。为什么不需要进行测试？是因为所有的问题都已经在软件各阶段中介入的测试工作中给预防解决了。由此引申，测试的定位并不是找出BUG，而是预防BUG。” 这是我培训报告中的一部分。如果测试的出发点只为是发现BUG，那么测试工作将会如何？辛苦的发现了一个BUG，之后开发针对性的修正了这个BUG，再回重新测试的过程，又会有多少人会重新被卷入，又会有多少BUG因此而产生，又需要花费多少时间，答案可想而知。这就是我们忙又不见成果的主要原因。所以改善这个问题的出发点就是改变对测试工作的认识——测试的目标并不是为了找出BUG，而是预防BUG的出现。

如何理解正确的测试目标是预防BUG的出现。首先可以从软件测试的阶段划分来看。软件测试的阶段划分为需求、设计、编码、测试、验收。但按此划分来定位测试是错误的。假如在编码阶段完成后测试出的BUG属于设计问题（这也是我们测试工作中经常遇到的情况），那么我们已经编码完成的产品就要面临着伤筋动骨的修改，这样的修改会带出多少个新的BUG出现？为这个修改我们又要重复的测试我们的新提交版本多少次？想必都有很深刻及惨痛的答案了。由此可以说明需求设计阶段的测试比编码阶段测试重要的多。在需求上出现的BUG就很有可能足以推翻整个产品。那么如果在需求设计阶段测试人员就能发现产品设计的BUG，那么就可以避免了因此而衍生的产品BUG，达到预防BUG这种测试理念的目标。 那么又如何能做好以预防BUG为目标的测试工作。“测试工作不只是一种技术，也不仅是一种活动。测试工作的成功也不能取决于测试成果，测试的BUG越多并不能证明测试工作做的好，所以由此引申，测试工作要站在团队的高度来开展，在团队中做好测试，而不是在测试小组中做好测试。”这是我培训报告中的另一部分。要做好以预防BUG为目标的测试工作，首先要尽早的参与到项目中，其次就是需要各部门及小组的大力支持，与业务、项目、代码人员共同形成团队，在团队中影响其他小组提高产品质量，更好的完成以预防产品出现BUG为目标的测试活动。

总结来看，我个人觉得拥有这样的测试理念可以解开我们的疑惑，带领我们走出目前的困境。

二、自动化测试迷失

随着工作、发展、提高等等多方面的需要，我接到了开展自动化测试的研究工作。概念上来说自动化测试是一种测试度量体系。现实点来说，自动化测试可以为我们自动、无误的运作完成大量且需要重复执

行的测试用例。这是多么让人振奋的概念。甚至可以解开我上文所提到的有关测试工作的困惑。我很兴奋的去展开研究目前最流行的自动化测试工具之一QTP。甚至设计出了管理中心的三个重要功能的自动化测试脚本，并且运行无误在自动化测试讨论会上兴奋的向大家演示。之后还用工具按键精灵设计出了前端的A类测试用于实际的测试。但很让人沮丧的是最终这些脚本全被遗弃在电脑硬盘的角落，再也没派上用场。为什么？因为他们维护起来很困难，因为他们编写它们的时间与实现的价值并没有超过手工测试。这就是自动化测试吗？怎么不可行啊，我有点不太相信这种结局，所以我再一次困惑了。

外部培训的老师这样告诉我们：“我们并没有理性的看待自动化测试，自动化测试并不是我们看上去的那样美。首先自动化测试能直接的节约成本、让测试人员变轻松的想法是一个误区。因为原本用于手工测试的时间用来编写及维护测试脚本了，而完善的自动化测试脚本编写或维护的时间很可能会超过手工测试的时间。再者自动化测试脚本用例是测试人员所编写，自动化测试只能是沿着该测试人员的“足迹”前进。所以用自动代测试来发现更多软件产品问题的想法也是一个误区。其次并不是所有的测试都能自动化，测试的自动化也不一定是解决问题的最佳手段。”

听完这些，原本困惑的我又多了份惊讶，一方面惊叹产述的这些状况与我之前的自动化测试的试行失败是相近的。另一方面又猜疑这自动化测试该不会像共产主义社会那般吧！随着培训内容的展开，我终于解开了困惑，何为理性的看待自动化测试。

“如同不能指望原始社会拥有了汽车就能进入现代社会一样，自动化测试工具永远都不能主导测试实现自动化”（出自国信培训文档）。我们错误的把自动化测试看成了一种测试工具或测试手段。自动化测试是一种理念，它要发挥它真正的作用就需要这种理念转变为一种体系——自动化测试体系。

“引入自动化测试的前提是已经建立了合适的自动化测试体系，如果没有这些，而片面的追求自动化，无异于缘木求鱼。自动化测试体系是指能够适用某种环境的测试工具、过程、人员结构、方法的综合，运用于整个项目团队” 。回到我之前的对QTP研究失败的原因，首先我开始就觉得因为研发的设计、编码实现并没有考虑到自动化，而导致自动化脚本的编写非常吃力。比如产品页面项目的命名不规范，导致自动化测试工具很难捕捉这些页面对像。其次就是测试脚本的方向迷失，我在研究QTP的时候就发现了这个问题。随着我一点点的在编写着脚本，我不断的发现自己在的测试脚本的编写方向上出现了迷失。这段脚本我编写的目标本来是功能测试，但随着我的补充却接近于开发级的单元测试。而另一段本属于功能性测试的脚本，因为功能的重点需要，我又补充了部分脚本导致整个测试脚本测试目标变成了完整关联性测试。而做为单元测试的脚本却并没有在开发的角度上来设计，根本做不到函数、类等代码级的测试，根本不能达到要求。做为完整性测试的脚本也无法模拟接口功能中几何倍数级的各种条件输入对应的输出测试。而功能测试脚本算是硕果仅存，但随着开发对产品的代码大规模调整（这些调整当然不会考虑对已经实现的

脚本的影响）而直接“报废”。如果需要脚本继续工作，那么就要花时间来修改调整它。这些脚本的结局又再一次可想而知了。

所以首先我们要理性的看待自动化测试，不要片面的去追求它。对不同的项目要开展不同自动化策略。参考如下

（1） 评审项目中特定的部分作为应用自动化的候选对像。

（2） 从项目中高度冗余的任务或场景重点考虑自动化。

（3） 将乏味且人工容易出错的工作重点考虑自动化。

（4） 将回归测试经常需要“照顾”到的部分重点考虑自动化。

（5） 自动化开始时要首先关注开发成熟、理解透彻、相对稳定的且不易变的部分优先考虑自动化 其次，自动化所实现的最大价值目标是可不间断的、可重复的自动执行对需求、设计、代码全面覆盖的大量测试用例从而预防bug的产生的一套质量保障机制。所以自动化测试的重点在于测试自动化作为一个体系，要运用于整个项目团队。项目组要讨论它（策略、时间、成本等）、研发需要参与它（编码方向、自动化支撑、以及代码单元测试自动化的计划和执行等）、测试要引导及推进它（策略、方法、执行、跟进、维护等），各团队共同形成体系，才能让自动化测试工具真正的成为一种质量保证的有力武器。

第二篇：自动化测试实施策略(自动化测试经验分享)

自动化测试实施策略（自动化测试经验分享） 以下内容来自《软件测试精要》一书20xx年电子工业出版社出版

自动化测试实施策略

我们在制定自动化测试实施策略时，首先应该考虑其中可能存在的风险。 1．自动化测试时间不充足

2．对自动化测试期望过高

3．缺乏自动化测试实施的经验

4．自动化测试工具更新过于频繁

5．自动化测试工具对软件测试本身没有起到帮助作用

6． 当我们有了针对自动化测试实施风险的准备后，就可以开始考虑： 6.1 需要在什么阶段开始启动自动化测试？

在何时启动自动化测试，每个公司的情况都不同。有的公司是在

测试用例都手工执行过并且测试用例不再修改时，再开发相应的

自动化测试脚本；而有的公司则是在开发测试用例的同时，就进

行脚本的开发。如果团队中测试用例的设计者是一个有着丰富测

试用例设计经验的工程师，他所开发的测试用例是高效的，未来

改动较少，则可以考虑在开发测试用例的同时，同步开发自动化

测试脚本。如果团队中测试用例的设计者是一个测试用例设计经

验不丰富或是设计的测试用例质量不高效的人，其开发的测试用

例需要在后期经常进行许多的改动，则还是考虑等到测试用例本

身稳定后，再开始脚本开发。

6.2 自动化测试的人力投入方式如何？

大部分公司是由专人进行自动化测试脚本开发的，少部分大公司则是全民开发自动化测试脚本。这两种方式都各有利弊：专人进行脚本开发，优点是开发脚本的专业技能可以不断地得到强化，开发效率大大提高；缺点是由于对开发模块的测试用例了解并不深入，有可能开发出的自动化测试脚本只是“翻译”测试用例，发现bug的概率较小。而有的大公司，由于员工的整体素质较高，通常都具备一定的开发能力，则由每个模块的手工测试者自行开发自动化测试脚本。虽然，手工测试者脚本开发的熟练程度没有专门的脚本开发者熟练，但是由于手工测试者是最了解测试用例真谛的人，因此他开发出的测试脚本就不

仅仅是“翻译”，而可能是对测试用例的“升华”，其测试脚本发现bug的概率会更大。

如何执行测试脚本才更高效？ （1）N个测试环境同步并行执行测试脚本，可以将自动化测试脚本执行的总时间成本降低为1/N。

（2）由专门的自动化测试执行工程师来执行批量的自动化测试脚本。自动化测试脚本运行失败的前3大因素大致为：

?测试环境问题

?脚本错误

?被测目标出现bug

由于专门的自动化测试执行工程师对大量失败的脚本分析经验的积累，通常可以非常高效地定位脚本失败的原因，提高自动化测试脚本执行的效率。 （3）独立的自动化测试环境供脚本执行团队使用。如前所述，测试环境问题是测试脚本失败的原因。而测试环境影响测试脚本执行的两大杀手：一个是测试环境被前一个失败脚本破坏而未还原；另一个则是测试环境被其他项目的同事给破坏了。对于第一种情况，我们可以在测试脚本的代码结构中加入足够的系统恢复代码来解决；对于第二种情况，则只有依赖于公司领导的政策支持，是否愿意腾出足够的测试环境给自动化测试执行小组专用。

（4）在测试脚本中加入丰富的脚本失败的定位信息。自动化测试脚本一旦失败，我们就只有依靠脚本自身打印的信息进行定位了，定位问题的速度快慢除了依赖脚本执行人员自身的经验外，更依赖脚本中是否有着丰富的脚本打印信息。

（5）使用自动化测试基线软件版本。当出现大批量测试脚本失败的情况时，可以在排除了测试环境问题后，直接把这些失败的测试脚本在基线软件版本中运行。如果在基线版本中运行全通过了，则证明脚本失败原因是产品新bug引起的，而不用逐个地去阅读这些失败测试脚本的源代码来分析脚本自身原因。