- 📢专注于分享软件测试干货内容,欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正!
- 📢交流讨论:欢迎加入我们一起学习!
- 📢资源分享:耗时200+小时精选的「软件测试」资料包
- 📢 最困难的时候,也就是我们离成功不远的时候!
1、极狐 GitLab 持续测试最佳实践
图 6 主要表达的思想是要把软件测试融入到整个软件开发的工作流当中,具体分成两个重要的部分:第一个就是要通过极狐 GitLab 的 CI/CD(或者其他平台也可以)把自动化测试工具集成起来。将 CI/CD 和自动化测试工具集成的目的是要实现的是全面的自动化。这样开发人员代码提交或者测试脚本更新之后,就可以通过 CI/CD 立刻触发一次全面的测试,才能彻底解决效率问题。CI/CD 集成自动化测试工具,这一点类似于我们所说的空间站的概念,极狐 GitLab 或者各公司采用的 DevOps 平台,本质上就是一个核心仓,测试工具可以通过模块化的方式与其进行对接,最后拼接成一个完整的空间站。
第二个重要的内容就是测试左移、测试右移和质量门禁,测试左移就是测试前置,测试人员参与到需求的评审环节中,解决大家对于需求的理解问题。而测试右移就是在程序发布到线上之后,需要 Ops 监控,遇到问题之后发出报警。这两部分很重要,但都没有中间代码评审部分那么重要,因为很多公司都在创建所谓的质量门禁。这里会遇到两种问题:第一个问题就是如何管理这么多测试工具的报告,很多团队直接把报告发到邮件或者聊天工具中,但是这样代码、版本怎么跟报告匹配呢?另一个问题就是时机问题,就是怎么关联测试跟代码的评审,如果评审通过了,代码也合到主干分支中了,但是测试报告不通过,也是不行的,这相当于测试跟代码评审没有形成关联。测试门禁就失去了它的意义和价值。
2、极狐 GitLab 软件测试基座
对于 极狐GitLab 来说,我们要解决的问题,就是将测试跟代码的评审结合起来,传统的测试报告都是离散的,现在需要对这些数据进行整理,将所有测试工具的报告集成到代码评审的页面中,这样在评审的时候就能够第一时间清晰地看到这些报告,并且确保是跟这一次提到的代码关联的报告。代码评审人员参考这些报告后,只需要签字即可。
对于极狐 GitLab 来说,我们一直认为一定是要把这些数据统一地汇总起来去做代码审核,这对落实代码门禁和代码质量是非常重要的。
3、准备工作
接下来将介绍企业内部,尤其是初创性企业,如何在什么都没有的情况下开展测试工作?如图 7 所示,首先是关于前置条件,这里我列了三点,最主要的就是你先得有版本控制,意味着有代码管理的平台,这是测试的前提。然后就是 CI/CD,它主要解决效率的问题,并且它可以作为刚才所说的集成平台,也就是核心舱,跟测试工具来做对接。第三点就是,在企业内部没有专业的测试人员或者规模还没完成的情况下,如果我们仍想做一些基本的测试(简单的测试大多数也是以手动为主),那么可以采用代码的扫描工具,比如代码质量的扫描、代码安全的扫描来一定程度地弥补手工测试的不足,比如变量名称命名、注释不全这类的问题。
在满足这些条件之后,如果有能力开展自动化测试,结合刚才所说的测试金字塔理论,一般认为最底下的最重要,正常来说应该是单元测试最重要,但实际上这里我把单元测试排在第二位了,把接口测试放到了前面。这是因为对于国内的企业和开发人员来说,大家普遍没有做单元测试的文化,大部分开发人员都是处于工作饱和的状态,此时如果再去写单元测试,会引起更大的抵触情绪。而做接口测试的话,可以使用到一些可视化工具,这些工具不需要编程能力,就可以去实现接口的自动化测试。
4、接口测试
图 8 展示了接口测试的优势,最主要的是第 4 点和第 5 点,第 4 点是说,接口测试可以通过可视化工具来进行,此时门槛是比较低的,测试人员比较容易掌握,不需要增加太多的负担。第 5 点说的是,接口相对来说会比 UI 层面更稳定一些,那么你自动化后他的价值是可以更多的体现出来。流程上来说,一般是测试人员利用这些可视化工具编写测试用例,然后导出为测试脚本,再用这些工具的无 UI 的实现(如 Docker 容器)把脚本加载进去,就可以实现自动化接口测试。这两点在实操层面(落地层面)是比较容易实施的,所以说接口测试对初创性的企业来说,是应该最早被推行的。
对于怎么做接口测试,这里没有讲得那么具体,我在图的下方简单概括了一下,接口测试涉及的工具很多,比如接口文档的管理、接口测试的工具、mock 工具、性能测试工具等,对于初创性企业来说,我推荐大家用一体化工具,其实国内现在有很多一体化工具,它可以去帮我们管理接口文档,也可以做接口测试,甚至可以做性能测试等。对于初创企业来说简化了工作,进而提升了效率。
5、性能测试
接下来就可以开展性能测试,因为大部分的性能测试几乎都是基于接口的,所以在做完接口测试之后,可以顺带进行性能测试。性能测试的类型如图 9 所示,比如负载、压力、浸泡、冲击测试等了。在开展性能测试之前,一定要明确到底要做什么类型的性能测试。性能测试不是强需求,而是非功能性的需求,不同类型决定了目的不同,所以要带着明确的目的去做。图9 中间是微软给出的性能测试的核心流程,可以参考它去做。
6、单元测试
下面就可以做单元测试了,其实也可以把它提前到第一个阶段去做,我没把它放到最前面是因为,国内关于单元测试分成两派,有的人支持,有的人反对,对于企业来说,只要重视产品的质量,并且人员的能力是满足的,就可以先尝试去做。可以从三个方面考虑,如图 10 所示,就是“谁做、咋测、效果”。
“谁做”这一点毋庸置疑,单元测试不是测试人员去做,一定是开发人员自己来做,国外开展敏捷测试,比如极限编程中提到的结对编程、结对开发,是大家相互做单元测试,但是在国内较难推行。“咋测”就是要验证单个程序、单个函数方法的变量、条件、路径、资源是否正确。实际上在正常的开发过程中,开发人员都会做自测,这个自测可能是开发人员自己打好包,从 API 层面或者 UI 层面调用到所写的程序方法的步骤(从外侧调用到内侧),查看是否正确,这样效率比较低。也可能是开发人员写一些马甲程序来实现函数正确性的验证。从某种意义上来说,这是在做单元测试的工作,只是不够专业,不妨将其按照单元测试的正规流程来写。“效果”主要包含两个方面,直接指标包括单元测试的通过率、覆盖率、用例的情况,间接指标是单元测试之后 bug 的总体趋势,以及 bug 率是否降低。国内企业非常看重指标,甚至到了一种畸形的地步,特别申明一下。如果要做单元测试,千万不要把单元测试的覆盖率当作最重要的指标,或者要求单元测试的覆盖率一定要达到 80% 或者90%,这绝对不行。这么做单元测试就成了一个走流程、走形式的过场了。另外单元测试目的是验证功能模块的正确性。尤其是对于复杂功能验证,特别简单的功能没有必要去覆盖,所以不要去追求高覆盖率。
7、UI 测试
最后是 UI 测试,它分为如图 11 所示的几个平台,从平台上来说,分为 App 平台、web(比如 BS 架构的 web 平台)、桌面平台(不光包括 PC 机,硬件终端、上位机其实都属于桌面端)。另外的,UI 测试在类别上主要分为两类,一类是逻辑,指的就是界面上的操作流程顺序和功能是否正确。这一类建议大家一定要自动化大于手动,因为很多传统企业在没有开展自动化测试工具的时候都是靠手工,那么自动化就可以发挥它的优势,代替大量的重复操作。另一个类别就是视觉,很多企业在验证这类 UI 的时候会去看字体、字号、文案、效果等,我反而觉得这部分最好手动,不用大张旗鼓地自动化,因为自动化的成本较大,收益比较低。我认为完全没必要做 OCR 、抠文字、识别、判断文案,扫一眼即可。把 UI 测试放在最后也是因为它的条件,这里我列举了十个条件,这也是业内广泛认可的条件,在这十个条件满足的情况下,就可以开展 UI 测试,如果这十个条件不是特别满足,就没有必要做了。
从这个流程上来说,UI 测试跟其他的测试其实没有大的区别,运行的时候会有两种模式:第一种是以 GUI 模式运行,就是带 UI 的模式去做自动化测试。这种情况要专机专用,比如有一个上位机,将这个上位机带着硬件一起搬过来作为测试的专用机,然后自动化测试脚本在这台专用的机器上运行,这样运行的时候就不可以做其他的操作,因为 GUI 独占了。大部分 app 和桌面平台的自动化UI 测试可能都是采用这样的方式。
另一种模式就是 headless,headless 是通过无 UI 的模式运行软件的测试,它主要是在 web 的 UI 测试中使用,比如基于 Chrome 浏览器的能力。像 selenium,它可以实现 headless 的无 UI 的模式,在容器运行,优点是可以并发,并且效率、性能都比专机专用要高得多。UI 测试的流程方式与刚才提到的接口测试、性能测试都差不多。
行动吧,在路上总比一直观望的要好,未来的你肯定会感谢现在拼搏的自己!如果想学习提升找不到资料,没人答疑解惑时,请及时加入群,里面有各种测试开发资料和技术可以一起交流哦。
最后: 下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取 【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。