8年测试经验分享 —— 从0铸造测试技术壁垒

最新推荐文章于 2024-07-25 15:11:55 发布

测试界的吴彦祖

最新推荐文章于 2024-07-25 15:11:55 发布

阅读量141

点赞数

分类专栏：职业规划软件测试自动化测试文章标签：测试工程师测试工具自动化测试软件测试职场和发展

本文链接：https://blog.csdn.net/myh919/article/details/130275008

版权

自动化测试同时被 3 个专栏收录

1388 篇文章 30 订阅

订阅专栏

软件测试

682 篇文章 4 订阅

订阅专栏

职业规划

32 篇文章 1 订阅

订阅专栏

前言

相信所有从事着软件测试或相关工作的同学都会思考一个问题: 如何在持续且部分重复的测试活动中有效的进行测试技术积累？

这个有趣的问题我先不予回答，我们先谈谈如何有效保证软件质量。作为团队中的质量保证者，需要深刻的意识到，验证系统原有功能是否高可用 (回归测试) 往往比验证新功能 要重要得多 ( 当然新功能有问题产品小姐姐也是会捶你的 )。这一点在 敏捷开发中更是尤为重要 (不能因为新功能而忽视旧功能) 。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 --百度百科

关于敏捷开发这里不过多介绍，其中的一个特性我比较看好，那就是 持续交付 。

整个业务市场肯定是持续在变化的，支撑业务的软件如果跟不上市场的节奏，则很有可能导致业务受到影响甚至直接被市场淘汰。 --笔者

持续交付听起来高大上，说白了就是保证软件随时处于一种可上线的状态，而这个时候，测试自动化就显得格外重要了。

举个栗子(比较极端):

一次系统迭代到达了既定的上线日，这时仍然存在着数个不严重 (核心功能可用) 但也会影响部分支线业务的缺陷。

这时测试问开发:  "你丫的这几个Bug还能不能修了啊，不修就上了啊" 。

开发回答: "修修修, 我修好这一个Bug你再测一下没问题就上线" 。

当测试验证完开发修的Bug并且花了几个小时手动回测了系统原有功能，刚准备上线时， 
开发急急忙忙跑过来说 : "另外一个Bug我也修了, 你再看看没问题就上线吧" 

这时，相信测试心里是相当难受的， 
先不考虑修复一个Bug导致千千万万个新Bug的情况出现， 光是回测的工程量就不是一般的大。
于是测试幻想着所有测试都交给机器去做，这样就可以带薪发呆了 ...... 
复制代码

众所周知，机器在某些方面是优于人类的，所以说一些 重复性 的测试工作完全可以交给机器去做，而不应该是堆人数去疯狂的点点点 ( 虽然该点的时候还是要点 )。这时候你可能会问，那自动化测试能完全代替手工测试吗？答案是 : 不能，因为人类特有的创造性和探索性是目前机器难以模拟的。虽然说完全用自动化测试代替手工测试是不太现实的，但是将系统稳定且核心的功能实现测试自动化还是非常可行的。

只有稳定的功能才有资格拥有自动化测试。 --笔者

再聊一点题外话，测试人员作为软件质量守卫者，系统每一次细微的改动 （包括改Bug），都应该当成一个 全新的版本 去进行测试。但是当 测试 - > 修复缺陷 -> 验证缺陷 -> 回测 的循环次数逐渐增多时，测试人员的测试热情肯定已经不如第一次测试时那么高昂了，心里也是处于一种得过且过的心态。(只要不爆炸，你就给我上)

测试人员对缺陷的容忍度会随着工作时长而增加。 --笔者

每一次迭代到后期，测试人员更应关注核心功能是否高可用(条件允许的话，系统原有核心功能的测试交给自动化，新核心功能测试则根据实际情况部分自动化部分人工)，不然的话项目可能会将无限延期下去。所以这也就是为什么软件上线后不可避免的会出现一些新问题或者是老问题复现。在每一次迭代中，想要完全实现100%自动化测试那是不太可能的，除非有许多专业且精通业务的测试开发人员，然而我们知道这是不现实的(不仅是公司成本问题，市场上也没那么多人才)。同时，自动化测试的实现也是开发的一个过程，自动化测试本身也可能会有缺陷，开发自动化测试的难度甚至比被测软件开发本身还要高，随着被测软件不断迭代，自动化测试也必然要紧跟着被测软件的脚步进行迭代，测试框架也需要测试人员花精力与时间去维护。 --来自笔者的吐槽

然而吐槽过后，该做的还是要做。言归正传, 测试技术积累 无非有几个大方向: 自动化测试、 性能测试、 安全测试，(其实性能、安全测试都可以包括在自动化测试内)。每一项测试对于一个系统来说都十分重要，但是其中偏功能的自动化测试相对来说更直观更易上手。以目前主流的Web项目来说，先不考虑单元测试(基本由开发人员负责) ,测试人员能把接口测试以及UI自动化测试做好的话，软件就基本达到可快速持续交付的标准了，而接口测试对比UI自动化测试来说环境更封闭，测试覆盖率也比较容易得到保障。所以说大方向上先把接口测试做起来是没有任何毛病的。 (但请注意接口测试全通过了软件也可能存在严重的UI界面上的缺陷，笔者吃过亏，别问都是泪)

笔者接口测试学习并实践了一段时间后，觉得一直堆测试代码并不是很优雅，基于这一点，决定自己从零搭建一套 易用轻便(最后估计会变得很臃肿) 的自动化测试平台。虽然现在测试开源平台多如牛毛，但是俗话说的好，只有自己做出来的东西才是最合适、用起来才是最爽的。做人如果没梦想，和咸鱼有什么区别 (笔者可是要将人工智能与测试结合的人)。于是说干就干，虽然过程很艰辛 (从零开始摸爬滚打了小半年)，但勉强算是搭建出了一个简易可用的测试平台。