从零铸造测试技术壁垒

前言

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

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

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

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

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

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

举个栗子(比较极端):

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

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

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

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

这时，相信测试内心是至关难受的， 
先不考虑修复一个Bug致使千千万万个新Bug的状况出现， 光是回测的工程量就不是通常的大。
因而测试幻想着全部测试都交给机器去作，这样就能够带薪发呆了 ...... 
复制代码

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

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

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

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

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

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

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

正文将围绕测试技术壁垒以及笔者正在构建的测试平台不断地进行总结与分享，笔者也不是什么大牛，但愿能在持续分享中同读者共同成长。

以为这篇东西有点意思的朋友请点个赞哦~

有任何问题或想法欢迎随时沟通 :)

--2019-5-7
复制代码

正文

"智能"测试平台初体验

---

整个测试平台技术架构为: Python-Flask + Vue + MongoDB， 其中整个后端代码由笔者独立完成，前端则借鉴了某开源项目，在此感谢该开源项目提供的灵感。

本章将不叙述任何实现思路以及细节，仅仅展现一下平台目前的一个使用流程。

---

首先咱们经过【登陆页面】进入【平台首页】而且在【接口测试】下新建一个名为【测试项目】的项目:

而后进入【测试项目】并 新增一条 【测试用例】

接着进入【测试用例】并 新增一条 【接口测试用例】(笔者的想法是一条测试用例下可对多个接口进行测试):

好的这个时候咱们进入【修改】页面，填入接口测试用例信息并点击【保存】:

如今咱们须要先去【Host配置】设置测试的host地址(选取当前本机的平台项目后端做为演示地址):

好的如今回到【测试列表】选取测试用例以及测试环境后点击【执行测试】:

这个时候页面会自动跳转至【自动化测试报告】页面，咱们能够点击【查看详情】查看详细内容:

咦？ 怎么飘红了？，喔原来是协议选错了，本机并无配置CA证书，并不支持HTTPS访问。

那么咱们这个时候回到接口用例修改页面，将HTTPS换成HTTP:

再一次进行测试，这个时候能够看到测试终于经过咯:

下面咱们来演示一下【定时任务】功能，首先先新增一个定时任务:

新增完毕后，可自由 编辑/停用/启用 且 当即生效！:

过一段时间后，咱们能够进入【自动化测试报告】查看定时任务是否正常工做,

在下方动图能够看到列表中新增了不少执行方式被标记为【定时执行】的测试报告:

有没有以为测试都是全经过，一点意思都没有，好的那咱们去修改一下用例的测试结果校验，让他成为永远都经过不了的测试用例:

过一段时间后咱们回到【自动化测试报告】页面，发现多出了不少经过率为0%的测试报告:

同时，系统会向定时任务中设置的告警邮箱发送警告，相关人员收到告警邮件后，进入系统内搜索邮件中的报告编号，便可找到存在失败用例的测试报告:

至此，笔者目前构建的 "智能"测试平台 使用主流程就介绍完毕啦，后续将会分享其中一些小细节以及不断的进行功能迭代。

热烈祝贺本次介绍圆满结束 :)

欢迎你们扫码关注个人公众号「智能测试开发」，

回复：优质教程， 便可免费得到 泰斯特平台完整使用教程

回复：测试进阶教程，便可免费得到 进阶教程 ~