软件测试需要学什么?

2021-06-11 09:53
由 admin 发表

 

对自动化测试个人见地


 

自动化是一个老生常谈的话题,也是一个软件范畴非常有技术广度和技术深度的活动,特别是在大型软件的生命周期上。

 

个人觉得展开自动化测试的难度不亚于传统意义上的软件开发。

 

从产品角度来看:质量范畴本身恳求从业人员要全面了解产品、有全局风险认识,例如:产品需求/设计阶段能否发现设计缺陷、产品测试阶段能否发现深层次的bug、产品运维阶段能否制定良好的灰度战略、快速发现、定位线上问题,以致如何做好新/老系统线上过渡切换等等,这里面都有自动化测试可发挥的空间。

 

从技术的广度和深度来看:

 

  • 从技术广度来说,不同的技术范畴的质量保证需求运用不同的技术(这些技术范畴都有一些代表性的工具,但不一定能完好满足理论的项目自动化测试需求),例如有做JUnit接口测试的、有做Web/App/桌面客户端 UI测试的、有做性能测试的、有做用户体验测试的、有做AI算法测试的、有做IoT的、有做压测的、有做各种专项(如兼容性、安全、多媒体、网络)测试的等等,真实太多了......。

     

    假设思索到测试工具本身的可用性、系统性,除知道运用工具以外,可能还需求控制一些基础开发技艺,例如:Java/Node/Python后台、React/H5前端、或者Android/iOS客户端;

     

  • 从技术深度来说,想经过开发软件去测试另一个软件能否正常,本身就是一个很具应战的事情,特别是在黑盒的状态下,举个例子,试想你能否开发一款自动化测试工具能够模拟人的认识形态,它能够对当前多如牛毛的App展开自动化测试,很多人此时想起了Monkey、Appium、AirTest或者Applitools,其实这远远不够,由于目前并不具备处置场景构建以致自我发现缺陷的才干,简单来说,还不具备“认知”App的才干。这个想法不是天方夜谭,事实上很多人正在往这个方向努力ing。自动化测试远远不只是在一个已有的工具上开发自己的脚本,抵达所谓的一个经过率或掩盖率,更中心是思索如何在软件生命周期各个阶段提升产品研发效能及稳定性以致用户体验。

 

 

技术新人如何学习自动化测试

 


 

首先简单了解下QA在软件研发迭代过程中的定位

 

传统软件运用较多的是瀑布模型。测试人员的活动区域是有限的,活动的时间区域主要是提测至上线前。
传统瀑布模型中,QA发挥的空间比较有限,质量压力都集中在测试阶段。随着软件规模的扩大、部门职能的划分、敏捷迭代模式的发展,互联网或者大型软件项目绝大部分演变成了DevOps:

 

DevOps是软件文化上的一次飞跃,它强调产品、开发、测试、托付、运维各个环节的沟通协作,将矫捷的方式延伸到整个产品。从QA的角度也有了测试左移和测试右移的概念。

 

测试左移:

 

测试左移的思想是需求阶段、开发架构设计阶段或是未到系统测试或集成测试前就停止测试,目的是降低时间本钱、减少风险,从用户角度描绘产操行为、从技术角度树立好开发与产品需求的衔接,避免产品设计上的雷或缺陷。这有利于减少无效代码的开发、以投入更好的时间在正确的产品上。也能够在代码编写阶段停止单元测试或掩盖率统计。

 

日常工作中,QA都希冀只对修正的代码或受连带影响功用/需求停止测试,从而减少反复回归的工作量,即“精准测试”。但是实践上,常常得到开发同窗的回复要么是“最好全回归或者中心流程全回归”,要么“是没关系的,就回归下A功用就好”(实践可能曾经带雷上线了)。想象假如可以有个工具可以帮我们将需求与相关的代码调用栈联络起来,在相关代码依赖变动时都可以自动评价有效回归范围,可能是“精准测试”完成的一个方向(我置信业界应该曾经有人在做了)。

 

测试右移:

 

测试右移简单来说是指产品上线以后展开的一系列质量活动。事实证明,在快速迭代以及产品复杂化、多样化的今天,简直不可能做到0缺陷上线,当然,对硬件产品或触及资金的产品而言,存在缺陷可能意味着产品召回或是资损,会给公司带来宏大损失,关于某些互联网产品而言,由于产品发布的自然优势,普通具备热修复、热发布才能,因而在时间和产质量量维度,可能会更强调快速上线,比方facebook就倡导灰度快速上线。因此如何监控产品的稳定性、第一时间发现线上用户问题、用户反应并使问题及时得到处理、如何理解更好的用户需求(如AB测试)变成了QA在测试右移活动中的关注点。期间也有大量自动化测试可发挥的空间。

 

由此可见,QA发挥的空间是在整个软件的生命周期的,DevOps的理念也强调流程自动化,我了解的在各个阶段可以替代人工工作、提升测试效率的都能够称之为自动化测试。这也反过来请求QA具备更高的软件产品流程/风险认识以及更强的自动化理念、编码落地理论才能。

 

软件工程&测试理论根底

 

各个公司产品形态悬殊,因而也制定了不同的软件研发流程。大多数大公司都设置有运营、产品、视觉/交互、开发、测试、运维、技术支持、客服等岗位,应当明白各个角色的职责,以及理解整个产品运转的逻辑。至少应该理解所在公司的研发流程以及当前主流的研发流程(如矫捷开发Scrum),并在项目过程中积极考虑,构成本身的软件认识与理念。在校的同窗能够多在网上找找材料,有个大约理解。个人了解,软件工程自身是一个浩荡的工程,也在一日千里不时地向前开展,它需求长期积聚、不时修炼内功,并在实践项目中理论驱动,从业2年、5年、10年、20年都会有不同层次/深度的了解,自动化测试亦是如此。

 

关于测试理论根底这里不赘述了,网上材料一大把,搜白盒/黑盒、等价类、边境值等关键字就能够找到。

 

通用计算机根底(其实就是计算机专业相关的大学课程)

 

倡议至少控制一门编程言语(C/C++/Java/Python,引荐Python,学习本钱相对更简单一些)。相比于特定需求/范畴的开发人员来说,测试人员对编码技术请求相对会弱化一些(当然并不意味着不需求极客肉体、架构思想)。触及到Web、桌面GUI、Android/iOS的能够到详细应用再学习相应的框架。

 

  • 控制根本的数据构造以及在详细程序言语中的应用,例如:list、map。

  • 控制面向对象程序设计的根本思想。

  • 控制一种代码管理工具,如git、svn。

  • 控制Linux的运用及根本命令运用,如:cp、grep、vi/vim等。

  • 控制关系数据库的根本理论和关系数据库(如MySQL)SQL根本运用、NoSQL(如Redis)的根本运用。

  • 控制根底的计算机网络理论,如TCP/UDP协议、IP划分。

 

接下来,我们就需求站在伟人的肩膀上了。这局部能够依据实践需求停止学习,触及的内容真实太多了,我这里主要从App自动化测试的角度给出一些工具运用、方向学习倡议,大家搜关键字应该都能找到一些材料。

 

效劳端:

 

  • 白盒单元测试:Junit(Java)、unittest(Python)、gtest(C++)

  • http接口测试:Postman

  • 抓包工具:Charles、Wireshark

  • 压测:Jmeter,在大厂里面都会有特定的一些写好的工具能够运用。

  • 链路依赖剖析:梳理应用间的依赖关系,提供压测模型,大厂里面也有一些工具能够运用。

  • 监控&日志剖析:应用稳定性监控,如qps、rt,效劳器负载、cpu监控等。日志剖析这块能够做一些基于规则的错误日志监控、以至基于AI的方式(如:机器学习)对日志大数据停止聚类、问题剖析/定位。

 

客户端(Android/iOS/H5):

 

  • UI:Appium、Macaca、Airtest

  • 性能(CPU/内存/帧率):Android Studio、Instruments(iOS)

  • 稳定性:Monkey

  • 兼容性:各种云真机平台

 

事实上,即便十分纯熟控制了以上工具,也无法到达完整释放人力的目的,以至在自动化理论过程中会存在各种各样的问题(例如如何针对详细的场景设计自动化用例、提升掩盖率、如何维护/结构测试数据、如何停止准确校验、如何进步执行稳定性、如何缩短执行时长、如何监控线上问题等等)。

 

这就需求我们愈加深度的去理解产品形态、在已有工具处理不了问题时,怎样去用创新的思想对待各个阶段面临的问题、以至发明工具,这曾经不只仅只是技术自身的问题了,而是如何去发掘、考虑问题、如何去运用技术的问题了。实践上自动化测试能够归结为如下几个阶段,这也是近2年智能化测试的研讨方向:

 

另外,个人觉得目前市面上对自动化测试其实是存在的一些误区的:

 

  • 以为自动化测试无所不能,只需有自动化,人工能够完整释放。关于复杂产品,目前来看,这简直是不可能的。因而,目前市面上并没有相似“统一宇宙理论”的自动化测试工具。

  • 自动化测试没技术含量(测试没开发有出路),假如仅仅是对工具运用,没有发明力,那的确没有什么太高的技术含量。但是假如是在DevOps各个阶段发挥最大价值,个人以为比传统意义的开发岗位难度更高,并且可发挥空间更大。举个例子,能否发明一种工具,可以依据视觉稿或者App UI自动生成测试用例(啊?怎样可能,试想下人是怎样设计用例的,得益于AI技术的开展,这完整有可能,目前也有一些依据视觉稿生成前端代码的工具了)。我不觉得这是一个没技术含量或没有价值的自动化测试。近些年,质量范畴的大会越来越多,大家也能够关注关注。例如QCon、MTSC、TICA、Tid等等。

  • 自动化掩盖率高高在上。这局部常常来自人们对自动化测试过高的希冀,为了提升掩盖率,未思索好ROI,以致于背道而驰,入不敷出。著名的测试金字塔给了最好的解释。

  • 随声附和,泛而不专。相比于开发人员,个人以为QA展开自动化测试需求控制的技术学问可能会更普遍,例如:开发人员可能专注于Android、iOS或者Java后端,亦或是某类AI算法,即对开发人员的请求是对某一技术控制的足够深化,对QA来说,精神有限的状况下,可能又要懂点效劳端、又要懂点客户端、又要懂点算法等等。再加上各种产品、技术形态不一,也衍生出了形形色色的工具和研讨方向,初学者容易遭到误导,手足无措。自动化测试和开发角色一样,也是一个逐渐积聚、理论的过程。

 

关于自动化测试的确有十分多的内容能够交流、学习,篇幅有限,先写到这里啦。以上内容是个人对自动化测一些了解,当然,假如继续往上走,到管理者,需求控制的学问也远不止这些了。

 

Copyright © 2012-2020 赤峰蒙仁信息咨询有限公司 版权所有