前言
相信所有从事着软件测试或相关工作的同学都会思考一个问题: 如何在持续且部分重复的测试活动中有效的进行测试技术积累？
image
这个有趣的问题我先不予回答，我们先谈谈如何有效保证软件质量。 作为团队中的质量保证者，需要深刻的意识到，验证系统原有功能是否高可用 (回归测试) 往往比验证新功能 要重要得多 ( 当然新功能有问题产品小姐姐也是会捶你的 )。这一点在 敏捷开发中更是尤为重要 (不能因为新功能而忽视旧功能) 。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 --百度百科
关于敏捷开发这里不过多介绍，其中的一个特性我比较看好，那就是 持续交付 。
整个业务市场肯定是持续在变化的，支撑业务的软件如果跟不上市场的节奏，则很有可能导致业务受到影响甚至直接被市场淘汰。 --笔者
持续交付听起来高大上，说白了就是保证软件随时处于一种可上线的状态， 而这个时候，测试自动化就显得格外重要了。
image
举个栗子(比较极端):
一次系统迭代到达了既定的上线日，这时仍然存在着数个不严重 (核心功能可用) 但也会影响部分支线业务的缺陷。
这时测试问开发: "你丫的这几个Bug还能不能修了啊，不修就上了啊" 。
开发回答: "修修修, 我修好这一个Bug你再测一下没问题就上线" 。
当测试验证完开发修的Bug并且花了几个小时手动回测了系统原有功能，刚准备上线时，
开发急急忙忙跑过来说 : "另外一个Bug我也修了, 你再看看没问题就上线吧"
这时，相信测试心里是相当难受的，
先不考虑修复一个Bug导致千千万万个新Bug的情况出现， 光是回测的工程量就不是一般的大。
于是测试幻想着所有测试都交给机器去做，这样就可以带薪发呆了 ......
image
众所周知，机器在某些方面是优于人类的，所以说一些 重复性 的测试工作完全可以交给机器去做，而不应该是堆人数去疯狂的点点点 ( 虽然该点的时候还是要点 )。 这时候你可能会问，那自动化测试能完全代替手工测试吗？ 答案是 : 不能，因为人类特有的创造性和探索性是目前机器难以模拟的。 虽然说完全用自动化测试代替手工测试是不太现实的， 但是将系统稳定且核心的功能实现测试自动化还是非常可行的。
只有稳定的功能才有资格拥有自动化测试。 --笔者
再聊一点题外话，测试人员作为软件质量守卫者，系统每一次细微的改动 （包括改Bug），都应该当成一个 全新的版本 去进行测试。但是当 测试 - > 修复缺陷 -> 验证缺陷 -> 回测 的循环次数逐渐增多时，测试人员的测试热情肯定已经不如第一次测试时那么高昂了，心里也是处于一种得过且过的心态。(只要不爆炸，你就给我上)
image
测试人员对缺陷的容忍度会随着工作时长而增加。 --笔者
每一次迭代到后期，测试人员更应关注核心功能是否高可用(条件允许的话，系统原有核心功能的测试交给自动化，新核心功能测试则根据实际情况部分自动化部分人工)，不然的话项目可能会将无限延期下去。 所以这也就是为什么软件上线后不可避免的会出现一些新问题或者是老问题复现。在每一次迭代中，想要完全实现100%自动化测试那是不太可能的，除非有许多专业且精通业务的测试开发人员，然而我们知道这是不现实的(不仅是公司成本问题，市场上也没那么多人才)。同时，自动化测试的实现也是开发的一个过程，自动化测试本身也可能会有缺陷，开发自动化测试的难度甚至比被测软件开发本身还要高，随着被测软件不断迭代，自动化测试也必然要紧跟着被测软件的脚步进行迭代，测试框架也需要测试人员花精力与时间去维护。 --来自笔者的吐槽
image
然而吐槽过后，该做的还是要做。言归正传, 测试技术积累 无非有几个大方向: 自动化测试、 性能测试、 安全测试，(其实性能、安全测试都可以包括在自动化测试内)。每一项测试对于一个系统来说都十分重要，但是其中偏功能的自动化测试相对来说更直观更易上手。以目前主流的Web项目来说，先不考虑单元测试(基本由开发人员负责) ,测试人员能把接口测试以及UI自动化测试做好的话，软件就基本达到可快速持续交付的标准了， 而接口测试对比UI自动化测试来说环境更 封闭 ，测试覆盖率也比较容易得到保障。所以说大方向上先把接口测试做起来是没有任何毛病的。 (但请注意接口测试全通过了软件也可能存在严重的UI界面上的缺陷，笔者吃过亏，别问都是泪)
image
笔者接口测试学习并实践了一段时间后，觉得一直堆测试代码并不是很优雅，基于这一点，决定自己从零搭建一套 易用轻便(最后估计会变得很臃肿) 的自动化测试平台 。虽然现在测试开源平台多如牛毛，但是俗话说的好，只有自己做出来的东西才是最合适、用起来才是最爽的。 做人如果没梦想，和咸鱼有什么区别 (笔者可是要将人工智能与测试结合的人)。于是说干就干，虽然过程很艰辛 (从零开始摸爬滚打了 小半年)，但勉强算是搭建出了一个简易可用的测试平台。
image
正文将围绕测试技术壁垒以及笔者正在构建的测试平台不断地进行总结与分享，笔者也不是什么大牛，希望能在持续分享中同读者共同成长。
觉得这篇东西有点意思的朋友请点个赞哦~
有任何问题或想法欢迎随时沟通 :)
image
正文
"智能"测试平台初体验
整个测试平台技术架构为: Python-Flask + Vue + MongoDB， 其中整个后端代码由笔者独立完成，前端则借鉴了某开源项目，在此感谢该开源项目提供的灵感。
image
本章将不叙述任何实现思路以及细节，仅仅展示一下平台目前的一个使用流程。
首先我们通过【登录页面】进入【平台首页】并且在【接口测试】下新建一个名为【测试项目】的项目:
image
然后进入【测试项目】并 新增一条 【测试用例】
image
接着进入【测试用例】并 新增一条 【接口测试用例】(笔者的想法是一条测试用例下可对多个接口进行测试):
image
好的这个时候我们进入【修改】页面，填入接口测试用例信息并点击【保存】:
image
现在我们需要先去【Host配置】设置测试的host地址(选取当前本机的平台项目后端作为演示地址):
image
好的现在回到【测试列表】选取测试用例以及测试环境后点击【执行测试】:
image
这个时候页面会自动跳转至【自动化测试报告】页面，我们可以点击【查看详情】查看详细内容:
image
咦？ 怎么飘红了？，喔原来是协议选错了，本机并没有配置CA证书，并不支持HTTPS访问。
image
那么我们这个时候回到接口用例修改页面，将HTTPS换成HTTP:
image
再一次进行测试，这个时候可以看到测试终于通过咯:
image
image
下面我们来演示一下【定时任务】功能，首先先新增一个定时任务:
image
新增完毕后，可自由 编辑/停用/启用 且 立即生效！:
image
image
过一段时间后，我们可以进入【自动化测试报告】查看定时任务是否正常工作,
在下方动图可以看到列表中新增了很多执行方式被标记为【定时执行】的测试报告:
image
有没有觉得测试都是全通过，一点意思都没有，好的那我们去修改一下用例的测试结果校验，让他成为永远都通过不了的测试用例:
image
image
过一段时间后我们回到【自动化测试报告】页面，发现多出了很多通过率为0%的测试报告:
image
同时，系统会向定时任务中设置的告警邮箱发送警告，相关人员收到告警邮件后，进入系统内搜索邮件中的报告编号，即可找到存在失败用例的测试报告:
image
至此，笔者目前构建的 "智能"测试平台 使用主流程就介绍完毕啦，后续将会分享其中一些小细节以及不断的进行功能迭代。
热烈祝贺本次介绍圆满结束 :)
image
觉得这篇东西有点意思的朋友请点个赞哦~
有任何问题或想法欢迎随时沟通 :)
image
网友评论