2022年自动化测试经验分享 .pdf

《2022年自动化测试经验分享 .pdf》由会员分享，可在线阅读，更多相关《2022年自动化测试经验分享 .pdf（3页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、一、测试的困惑以前我时常反思，测试组的工作多吗？我的回答是多。测试小组的工作成果的好坏和工作任务的多少成正比吗？最终的回答却并非成正比。我们的测试工作成果往往并不理想，甚至是差。那么为什么事倍功半？这问题很难找到清晰的答案。参与了外部培训之后，发现了自己在对测试的工作有了新层次的理解。对之前工作成果差的问题思考也有了新的方向。“ 测试的最高境界是找出所有BUG 吗？不是，测试的最高境界是不需要进行测试。为什么不需要进行测试？是因为所有的问题都已经在软件各阶段中介入的测试工作中给预防解决了。由此引申，测试的定位并不是找出BUG ，而是预防 BUG 。” 这是我培训报告中的一部分。如果测试的出发点

2、只为是发现 BUG ，那么测试工作将会如何？辛苦的发现了一个BUG ，之后开发针对性的修正了这个BUG ，再回重新测试的过程，又会有多少人会重新被卷入，又会有多少BUG 因此而产生，又需要花费多少时间，答案可想而知。这就是我们忙又不见成果的主要原因。所以改善这个问题的出发点就是改变对测试工作的认识 测试的目标并不是为了找出BUG ，而是预防BUG 的出现。如何理解正确的测试目标是预防BUG 的出现。首先可以从软件测试 的阶段划分来看。软件测试的阶段划分为需求、设计、编码、测试、验收。但按此划分来定位测试是错误的。假如在编码阶段完成后测试出的 BUG 属于设计问题（这也是我们测试工作中经常遇到的

3、情况），那么我们已经编码完成的产品就要面临着伤筋动骨的修改，这样的修改会带出多少个新的BUG 出现？为这个修改我们又要重复的测试我们的新提交版本多少次？想必都有很深刻及惨痛的答案了。由此可以说明需求设计阶段的测试比编码阶段测试重要的多。在需求上出现的BUG 就很有可能足以推翻整个产品。那么如果在需求设计阶段测试人员就能发现产品设计的BUG ， 那么就可以避免了因此而衍生的产品BUG ， 达到预防 BUG 这种测试理念的目标。那么又如何能做好以预防BUG 为目标的测试工作。“ 测试工作不只是一种技术，也不仅是一种活动。测试工作的成功也不能取决于测试成果，测试的BUG 越多并不能证明测试工作做的好

4、，所以由此引申，测试工作要站在团队的高度来开展，在团队中做好测试，而不是在测试小组中做好测试。” 这是我培训报告中的另一部分。要做好以预防BUG 为目标的测试工作，首先要尽早的参与到项目中，其次就是需要各部门及小组的大力支持，与业务、项目、代码人员共同形成团队，在团队中影响其他小组提高产品质量，更好的完成以预防产品出现BUG 为目标的测试活动。总结来看，我个人觉得拥有这样的测试理念可以解开我们的疑惑，带领我们走出目前的困境。二、自动化测试迷失随着工作、发展、提高等等多方面的需要，我接到了开展自动化测试的研究工作。概念上来说自动化测试是一种测试度量体系。现实点来说，自动化测试可以为我们自动、无误

5、的运作完成大量且需要重复执名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 3 页 - - - - - - - - - 行的 测试用例 。这是多么让人振奋的概念。甚至可以解开我上文所提到的有关测试工作的困惑。我很兴奋的去展开研究目前最流行的自动化测试工具之一QTP。甚至设计出了管理中心的三个重要功能的自动化测试脚本，并且运行无误在自动化测试讨论会上兴奋的向大家演示。之后还用工具按键精灵设计出了前端的A 类测试用于实际的测试。但很让人沮丧的是最终这些脚本全被遗弃在电脑硬盘的角

6、落，再也没派上用场。为什么？因为他们维护起来很困难，因为他们编写它们的时间与实现的价值并没有超过手工测试。这就是自动化测试吗？怎么不可行啊，我有点不太相信这种结局，所以我再一次困惑了。外部培训的老师这样告诉我们：“ 我们并没有理性的看待自动化测试，自动化测试并不是我们看上去的那样美。首先自动化测试能直接的节约成本、让测试人员变轻松的想法是一个误区。因为原本用于手工测试的时间用来编写及维护测试脚本了，而完善的自动化测试脚本编写或维护的时间很可能会超过手工测试的时间。再者自动化测试脚本用例是测试人员所编写，自动化测试只能是沿着该测试人员的“ 足迹 ” 前进。所以用自动代测试来发现更多软件产品问题的

7、想法也是一个误区。其次并不是所有的测试都能自动化，测试的自动化也不一定是解决问题的最佳手段。”听完这些，原本困惑的我又多了份惊讶，一方面惊叹产述的这些状况与我之前的自动化测试的试行失败是相近的。另一方面又猜疑这自动化测试该不会像共产主义社会那般吧！随着培训内容的展开，我终于解开了困惑，何为理性的看待自动化测试。“ 如同不能指望原始社会拥有了汽车就能进入现代社会一样，自动化测试工具永远都不能主导测试实现自动化 ” （出自国信培训文档）。我们错误的把自动化测试看成了一种测试工具或测试手段。自动化测试是一种理念，它要发挥它真正的作用就需要这种理念转变为一种体系 自动化测试体系。“ 引入自动化测试的前

8、提是已经建立了合适的自动化测试体系，如果没有这些，而片面的追求自动化，无异于缘木求鱼。自动化测试体系是指能够适用某种环境的测试工具、过程、人员结构、方法的综合，运用于整个项目团队” 。回到我之前的对QTP 研究失败的原因，首先我开始就觉得因为研发的设计、编码实现并没有考虑到自动化，而导致自动化脚本的编写非常吃力。比如产品页面项目的命名不规范，导致自动化测试工具很难捕捉这些页面对像。其次就是测试脚本的方向迷失，我在研究QTP 的时候就发现了这个问题。随着我一点点的在编写着脚本，我不断的发现自己在的测试脚本的编写方向上出现了迷失。这段脚本我编写的目标本来是功能测试，但随着我的补充却接近于开发级的单

9、元测试。而另一段本属于功能性测试的脚本，因为功能的重点需要，我又补充了部分脚本导致整个测试脚本测试目标变成了完整关联性测试。而做为单元测试的脚本却并没有在开发的角度上来设计，根本做不到函数、类等代码级的测试，根本不能达到要求。做为完整性测试的脚本也无法模拟接口功能中几何倍数级的各种条件输入对应的输出测试。而功能测试脚本算是硕果仅存，但随着开发对产品的代码大规模调整（这些调整当然不会考虑对已经实现的名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 3 页 - - - - -

10、- - - - 脚本的影响）而直接“ 报废” 。如果需要脚本继续工作，那么就要花时间来修改调整它。这些脚本的结局又再一次可想而知了。所以首先我们要理性的看待自动化测试，不要片面的去追求它。 对不同的项目要开展不同自动化策略。参考如下（1） 评审项目中特定的部分作为应用自动化的候选对像。（2） 从项目中高度冗余的任务或场景重点考虑自动化。（3） 将乏味且人工容易出错的工作重点考虑自动化。（4） 将回归测试经常需要“ 照顾” 到的部分重点考虑自动化。（5） 自动化开始时要首先关注开发成熟、理解透彻、相对稳定的且不易变的部分优先考虑自动化其次，自动化所实现的最大价值目标是可不间断的、可重复的自动执行

11、对需求、设计、代码全面覆盖的大量测试用例从而预防bug 的产生的一套质量保障机制。所以自动化测试的重点在于测试自动化作为一个体系，要运用于整个项目团队。项目组要讨论它（策略、时间、成本等）、研发需要参与它（编码方向、自动化支撑、以及代码单元测试自动化的计划和执行等）、测试要引导及推进它（策略、方法、执行、跟进、维护等），各团队共同形成体系，才能让自动化测试工具真正的成为一种质量保证的有力武器。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 3 页 - - - - - - - - -