测试已死,我看未必

"测试已死”的观点在业内仍然存在着争议,很多公司缩减了测试人员,开发测试比屡创新高。本文旨在通过介绍软件测试的新趋势和新技术来展示软件测试行业面临的机遇与挑战,为软件测试工程师的职业规划提供参考。

安全测试

从孟加拉国银行 8100 万美元被黑客成功盗取到美国民主党邮件泄露事件可以看出,网络安全事件已经被推到了风口浪尖。随着物联网逐步普及,智能家居、汽车电子等设备的网络化水平大幅提升。但物联网的安全却不容乐观,很多中小企业往往忽视安全防护。开源软件的源代码公开,黑客可以通过阅读源代码更容易的分析出软件的安全漏洞,使得网络安全迎来了新的挑战。当开源社区中发布出 cve 漏洞时,需要厂商及时的合入补丁,否则将给黑客入侵敞开大门。

新的编程语言的出现在提高了编码效率的同时,也为软件产品增添了安全挑战,需要安全厂商尽快推出相应的安全工具和安全加固方案。随着 SaaS 的普及,相信会有更多的安全工具问世。渗透测试需要测试工程师阅读源码来找出漏洞,与安全合规测试相比,需要更高的技术水平。在未来相当长的一段时间内渗透测试工程师将有很大的缺口。

人工智能测试

近年来,人工智能(AI)被越来越多的应用在 IT 行业,如智能汽车、智能家居和机器人等。尤其是 2016 年 AlphaGo 在围棋领域掀起一股热潮之后,AI 更多地成为人们热议的焦点。人工智能是一个新的领域,对于人工智能本身的测试方案和测试工具还有待完善。

对于人工智能在软件测试领域的应用,即利用人工智能来优化其他软件的测试,目前已经取得了一定的进展。人工神经网络是软件测试领域使用相对广泛的 AI 技术之一。神经网络是基于生物学中神经网络的基本原理,在理解和抽象了人脑结构和外界刺激响应机制后,以网络拓扑知识为理论基础,模拟人脑的神经系统对复杂信息的处理机制的一种数学模型。目前在 OCR,语音识别,医学诊断等方面已经取得了很大的成功。在软件测试中,它非常适合 GUI 测试、内存使用测试及分布式系统功能验证等场景。

遗传算法是另一个软件测试中用到的 AI 技术。它是模仿生物遗传和进化机制的一种最优化方法,它把类似于遗传基因的一些行为,如交叉重组、变异、选择和淘汰等引入到算法求解的改进过程中。遗传算法的特点之一是,它同时保留着若干局部最优解,通过交叉重组或者解的变异来寻求更好的解。在软件单元测试中,已知输入的参数的范围,求解哪些参数的组合能够达到最大的代码覆盖率(也有些研究是能达到最大的路径覆盖 / 分支覆盖)。因此,遗传算法可以用于选择最优的单元测试用例,也就是单元测试的最优输入集。同时利用人工智能还可以优化测试工具,将软件测试的上下文与测试用例结合起来,选择最优的测试用例集进行测试。

静态分析与符号执行

软件可靠性是对软件在设计、开发以及所预定的环境下既有能力的置信度的一个度量,是衡量软件质量的主要参数之一。而软件测试则是保证软件质量、提高软件可靠性的最重要手段。静态分析工具可以直接对源码进行扫描,但其误报率的问题有待改善。

大量可靠性问题隐藏在未知场景和不熟悉的开源代码中,有必要通过程序行为分析工具来遍历各种异常分支、代码的所有路径。符号执行技术是精确的路径遍历,是随机测试、FUZZ 测试的有益补充。

符号执行代表工具 KLEE,在第一次学术使用(2008)便发现了 unix 系统中最常用的程序的多个问题,有的问题已经存在超过 15 年。符号执行技术在之前没有得到大规模应用,主要原因是技术本身需要大量的计算资源(路径爆炸)。随着软硬件技术的发展,平均计算成本比之前降低了很多,为符号执行的发展和推广提供了有利的客观条件。目前符号执行技术已应用在许多公司的产品测试当中,如 HP、微软等公司都已经有 10 年以上的符号执行探索经验。当前基于 KLEE 的二次开发工具已经大量应用在软件可靠性测试中,如 Mayhem 已发现了 DebianOS 的上千个 crash 问题,以及 Linux 和 Windows 系统的几十个可利用漏洞。

精准测试

在当前敏捷测试的时代,版本发布日趋频繁,快速发布高质量的软件是很多企业的目标。对于急于发布的软件版本,全量运行所有的用例往往需要花费较长的时间,已经不能满足产品发布的节奏。如何避免过度测试并在时间、质量、成本中找到最佳的平衡?

精准测试可让软件测试过程可量化衡量、可追溯,清楚的展示出测试用例运行的路径,并可以实现测试用例与代码的双向追踪。对于代码量较大的系统的软件,通过精准测试可以获取到曾经执行过某段代码的测试用例,当这部分代码进行修改后,只需执行对应的用例即可,大大缩短了测试的时间,加快了产品上线速度。因此精准测试成为了近期软件测试技术的新方向之一。精准测试的实施对测试人员的代码开发、测试设计、需求理解、架构理解、自动化测试能力均有较高的要求。

云测试

云计算是一种按需提供计算资源的技术,它可以减少用户基础设施投入并降低管理成本。然而,云平台在近年来不断出现大面积宕机的情况,这为云计算测试技术提出了新的挑战。需要测试人员深入理解云平台底层、中间层和上层技术,构建符合云平台质量要求的测试工程能力和质量保障方案。

很多测试服务提供商已经将测试服务部署到云上,这种方式有很多的优势。首先,它可以按需提供服务,用户可以根据需求灵活的占用云端资源,避免了传统测试中的资源浪费。例如手机应用提供商可以把应用程序通过云平台进行主流手机的兼容性测试,而不必直接购买各品牌的手机。其次,云平台可以提供较为全面的测试环境和测试工具,免去了部署环境和工具的时间,使测试工程师可以将更多的精力投入到业务中。再次,当云平台和容器技术结合起来时,可以快速构建可扩展可伸缩的测试环境,并行执行测试用例,从而减少测试执行时间。

物联网测试

IoT 是一个包含大量网络设备、传感器和计算基础设施的庞大系统。IoT 的应用覆盖了军事、家庭、医疗、零售等多个领域。其使用场景复杂,解决方案多元化,使得 IoT 设备以及解决方案的测试面临很大的挑战。下面笔者提出了一些观点和思路供大家参考。

仿真

基于效率和成本的考虑,测试人员无法针对所有的 IoT 设备、连接协议以及服务节点进行全面覆盖。依靠 IoT 场景仿真能力,测试人员可以在少量可用的物理设备上创建各类虚拟设备并建立不同协议的虚拟连接,从而模拟出真实应用场景,达到全面测试覆盖的目的。不仅能够节约时间和成本,还具有更好的灵活性和扩展性。

安全

当前 IoT 发展的重点是技术的创新、推广和应用,安全问题没有受到足够的重视。相对传统移动互联网,IoT 的规模、应用和服务都更加庞大复杂,安全问题无疑具有极大的挑战性。

自动化

在 IoT 领域,目前自动化测试工具和系统的发展还处于比较初级的阶段。在测试执行、场景构建、性能度量及状态监控等各个方面都需要有强有力的工具、框架和规范的出现,来支撑复杂的 IoT 自动化测试。

开源测试

开源软件本着“不要重复造轮子”的原则,与商业软件相比,拥有使用成本低、可定制性高等特点。目前开源测试工具种类繁多,涵盖测试管理、缺陷管理、持续集成、功能测试、性能测试、测试框架、测试设计、安全测试等类别。下面列举了这些分类中一些典型的测试工具。而针对我们自身的业务需求,可以通过修改源代码来适配自己的业务,从而实现工具定制化。

  • 测试管理: TestLink、Testopia
  • 缺陷管理:Redmine、Bugzilla、Mantis
  • 持续集成:Jenkins、Buildbot
  • 功能测试:Selenium、LTP
  • 性能测试:lmbench、Sysbench、Iperf、Fio
  • 测试框架:JUnit、Autotest
  • 测试设计:Xmind、StarUML、UML Designer
  • 安全测试:Metasploit、Nessus、AppScan

为了减少研发成本,很多公司都制定了基于开源软件进行二次开发的策略。在重点测试自研特性的同时,面对大量的开源代码,测试工程师需要与开源社区互动,及时将发现的问题提交给社区并同步社区的问题单和 cve 补丁。

然而,当前很多开源社区中的测试并不到位,很多特性在发布之后长时间没有对应的文档和测试用例。以 kernel 社区的 user namespace 内核特性为例,其是在 2013 年 2 月 18 日随内核 3.8 版本正式发布的,然而直到 2015 年 5 月 21 日,社区才拥有第一个该特性的测试用例。二者时间间隔在两年以上,版本的质量保证令人堪忧。对于这部分特性,需要测试工程师根据业务需要自行补充测试。测试工程师同时还要注意构建社区影响力,以保证与自己平台相关的测试用例能够顺利的被社区接收,从而减少测试代码维护成本。感兴趣的读者可以阅读 《让我们成为开源软件测试者》。

容器化 /Devops/ 微服务

容器为开发、测试、运维三个团队提供一致的环境,避免因为环境不统一产生的缺陷误报。同时使开发人员可以很容易的通过容器镜像复现测试人员和客户报来的缺陷。利用容器还可以避免环境污染和批量快速的启动多个测试环境并行测试来提高测试效率。微服务将软件细分为多个子模块,各模块间相对独立,便于测试进行迁移以便及早的发现缺陷。Devops 通过成熟的自动化解决方案,同时配合容器、微服务技术,打通了开发、测试、运维团队的壁垒。随着容器、微服务时代的到来,配置基于 CI/CD 的 Devops 流程成为了测试人员必备的技能。感兴趣的读者可以阅读 《Docker 引领测试革新》。

敏捷测试

传统的软件测试方法将开发和测试视作两个团队的两种不同的工作模式,团队之间沟通比较有限,团队壁垒较为明显。在这种开发模式下,软件缺陷通常在项目后期才逐步被发现。近年来,在客户需求频繁变化、高强度的外部竞争压力和软件交付迭代频繁的大环境下,传统的软件测试方式已经不能满足需求。

敏捷测试强调从客户的角度进行测试,重点关注持续迭代地测试新开发的功能,而不再强调传统测试过程中严格的测试阶段,同时提倡尽早开始测试。它强调开发和测试团队在合作、透明、灵活的环境下协同工作,以测试前移、持续集成、自动化等方式为优化手段,可以很好的适应快速、需求变更频繁的软件交付。

目前敏捷测试已经受到了行业内的认可,相信会有更多的公司将会进行敏捷转型,敏捷教练的薪水也会水涨船高。

大数据测试

当前全球信息数据量增长迅猛,据市场调研机构 IDC 预测,到 2020 年,全球数据总量将达到 40ZB,相当于每人拥有一千张 DVD 光盘以上的信息量。如此大量的数据为测试数据的备份和管理带来了挑战,测试人员需要确认数据完整性,保证数据质量。面对大量而动态变化的数据和有限的测试时间,需要制定出行之有效的测试策略,开发出适用的测试工具,并完善自动化测试。

随着大数据应用的快速增长,我们需要更快速的完成数据处理。大数据挖掘的目的是找出数据与数据的关联关系,与传统软件相比,很多大数据场景中的输出是无法直接确定的,同时数据又具有多样性,需要测试人员具备更多的发散思维;面对爆炸式的数据服务,测试时需要搭建可扩展伸缩的测试平台模拟大量的测试客户端。而面对大数据中很多场景下程序输出的不确定性、大数据结构多样化、定位数据因果关系困难等问题为测试工程师带来了新的挑战。

自动化测试

传统的自动化测试需要测试工程师直接编写测试程序,而这样的程序往往可维护性不强,当开发代码变更时往往需要重新适配自动化测试程序。测试驱动开发是软件工程中的一个里程碑,即开发在提交开发代码修改时同时要提交测试代码,但这种方式仍然需要较多的人力投入到测试代码的编写中。而一些程序可以通过录制或符号执行等方法自动生成自动化代码,免去了手工编写的不便。另外通过埋点、mock 等技术还可以辅助自动化测试。随着测试业务日趋多样化,需要不断开发新的自动化测试框架、测试平台来满足业务需求。当自动化测试与云平台相结合时,可以方便的进行任务迁移、回滚、故障自动修复等功能。

移动互联网测试

随着智能移动设备的普及,测试范畴也从智能手机、智能平板扩展延伸至包含了运动手环、车载联网应用、共享单车、无人机等事物。移动平台也呈现多样化趋势,而每个平台的版本升级速度非常快。移动应用种类繁多,从社交到游戏、教育、办公、旅行、工具等类别。为满足用户需求,热门应用的迭代更新非常频繁。面对众多的移动设备硬件型号、多个终端平台版本、繁多的移动应用、各应用的不同版本号,测试人员不得不制定新的测试策略和方案来应对业务。即使应用没有新的特性引入,但自动化测试不得不根据新的平台进行适配工作。而多种组合的测试为测试人员、测试工程能力、自动化测试提出了更高的要求。

目前已经出现了针对移动测试的自动化设备和 SAAS 平台。测试设备可以模拟出用户真实的终端操作的方式。在 SAAS 平台中,使用者可以将应用提交到平台中进行全量的自动化测试,来确保应用的多个版本可以适配到不同的平台和硬件中。此外,领域中的专项测试,如性能测试、功耗测试、安全测试、兼容性测试、跨地域跨时区测试、老化测试,也将产生很大的测试需求。

写在最后

当前很多公司已经将基本的功能测试任务交由开发团队负责,测试人员主要专注于自动化测试开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项测试中。这部分测试任务能够很好的体现测试人员的价值。虽然“测试已死”的争论还在继续,但只要把握好软件测试发展的趋势并凭借自身的努力,相信测试人员是能够在行业中受到认可的。

作者简介

孙远,华为中央软件院资深工程师,个人网站:www.enjoytesting.cn

孟宪伟,华为中央软件院资深工程师,硕士毕业,软件行业 10 年以上从业经验。目前从事华为云计算产品虚拟化平台的测试以及相关测试工具的开发工作。加入华为前供职于 IBM,Thomson Reuters 以及 VMware 等多家公司,期间曾从事软件开发,项目管理,软件测试等各类工作。

文章来源:InfoQ

时间: 2024-10-06 00:26:45

测试已死,我看未必的相关文章

谁说门户已死?从世界杯看新浪的四大优势

巴西世界杯即将尘埃落定,四大门户的世界杯报道大战也进入最后的"角逐"阶段.根据过去的案例分析,谁的资源整合能力强,谁就能成为世界杯报道的赢家.目前巴西世界杯赛程已接近尾声,这场门户之间的报道大战也将很快见分晓. 今天笔者先分析下新浪. 四大门户之中,新浪在重大事件报道方面应该是最有发言权的,不仅仅因为新浪在内容方面多年来的积累,更重要的是,新浪旗下有诸多产品资源和平台资源.从今年世界杯期间的表现来看,新浪在内容.移动.社交.营销四个方面都表现出明显的优势. 内容:老牌门户的积淀+微博新

centos6.5安装MYSQL“mysqld已死,但是subsys被锁”的解决方案

今天安装好了centos 6.5  32位系统,远程安装好了MySQL,进入mysql后,有事忘了退出来,当我想起来之后,远程已经断开连接,重新连接ssh,登录MySQL,输入密码提示错误,检查服务:service mysqld status [[email protected] ~]# service mysqld status mysqld 已死,但是 subsys 被锁 [[email protected] ~]# 然后查询下资料,按照以下步骤: [[email protected] ~]

小程序已死?我们拭目以待吧

微信小程序于1于9日正式上线,上线的时候我写了一篇文章<微信小程序刷爆朋友圈的秘密>,当然那几天也是吵得最热闹的几天.从我的文章中,我对小程序是看好的. 当然那几天各路媒体也都悉数发表各种新闻评论,一时之间小程序似乎有翻云覆雨.一统江湖的趋势. 然而,两个月过去了,世界依然如此.APP和小程序也都安静地存在.而那些吹捧者.投机者却开始宣扬小程序衰落.小程序已死的言论了.或许只是因为它们并没能如愿收获千万流量.一夜屌丝逆袭,就立马开始看衰了. 任何事物的暴发或许都不是事先预料好的,正如微信公众号

JVM学习记录-对象已死吗

前言 先来回顾一下,在jvm运行时数据区,分为两部分,一个部分是线程共享区,主要包括堆和方法区,另一部是线程私有区分包括本地方法栈,虚拟机栈和程序计数器.在线程私有部分的三个区域是随着线程生和灭的.栈中的栈帧随着方法的进入和退出而执行着出栈和入栈操作.每一个栈帧所用内存大小在类结构确定下来时就已知了.因此这线程私有区的内存分配和回收都具备确定性,简单概括的说:这部分内存在类加载时分配,在线程结束时回收.(个人理解) 而线程共享区(堆和方法区)则不一样,一个方法中的多个分支需要的内存可能不一样,只

SNMP 已死 - Streaming Telemetry 流遥测技术

路人甲:姜汁哥,听说你专栏卖得很火? 还行吧,感谢大家的认可. 路人甲:你这赚了点小钱,就跑路了?上次见你发文章,转眼已是n年. 没跑路,没跑路,我现在夜以继日的在为<网工2.0晋级攻略 - 零基础入门Ansible/Python>赶稿子呢. 路人甲:真会装.... 琢磨了半天,才想出来这么个用2B铅笔写的,广告成分极大开场白,最近一忙专栏,就没空更新博客,对不住我的朋友们了. 今天我想和大家聊一个关乎于多年江湖恩怨的话题. SNMP已死! 喔喔喔,等下,先别急着扔斧头,大哥,这话不是我说的,

JVM的判断对象是否已死和四种垃圾回收算法总结

面试题一:判断对象是否已死 判断对象是否已死就是找出哪些对象是已经死掉的,以后不会再用到的,就像地上有废纸.饮料瓶和百元大钞,扫地前要先判断出地上废纸和饮料瓶是垃圾,百元大钞不是垃圾.判断对象是否已死有引用计数算法和可达性分析算法. 1.引用计数算法 给每一个对象添加一个引用计数器,每当有一个地方引用它时,计数器值加 1:每当有一个地方不再引用它时,计数器值减 1,这样只要计数器的值不为 0,就说明还有地方引用它,它就不是无用的对象.如下图,对象 2 有 1 个引用,它的引用计数器值为 1,对象

ServiceMix--JBI已死-Camel代替

本文目的: 一开始接触ESB的时候,对mule,servicemix等进行选型,当时考虑到sm对jbi有支持,mule的社区版本砍掉的功能较多等原因, 选择了sm.在进行sm用做web service代理时,看到网上只有一个sm3.0时代的文章: 名称:使?用?S?e?r?v?i?c?e?m?i?x?(?E?S?B?)?发?布?一?个?外?部?的?W?e?b?S?e?r?v?i?c?e 地址:http://wenku.baidu.com/link?url=A9Ava_nYaGHDFBO0mAgy

为什么说传统电视已死?

前些日子,"互联网女皇"玛丽·米克尔(Mary Meeker)发布2014年年度互联网趋势报告,并且在这份报告中指出"重新定义遥控器"的概念.在玛丽·米克尔看来,随着互联网的应用和普及,未来互联网和智能终端设备的发展,无疑将促使多屏一体成为新的潮流和技术趋势,同时改写全新的互联网和新的商业生态. 除此之外,玛丽·米克尔还在这份报告中额外指出,智能电视将蚕食功能电视市场.并且改变互联网的屏幕,特别是以APP为方式的智能电视,未来将成家庭娱乐中心. 玛丽·米克尔的这种观

第三方推送已死

国内第三方推送的起源 2010 年左右,Android 手机在国内迅速发展,Google 的原生推送(C2DM,现在的 GCM)由于种种原因不能正常使用,当时的 Android 开发者使用各种办法来解决这个问题,其中就包括 Android 手机厂商开发出自己的推送方案. 对于大部分开发者来说,除了做一个 App,还要独立开发一套推送系统是件异常困难的事情.哪怕是用户数量很大的 App ,这也不是一件容易的事情.于是在 2011 年底,我产生了做独立第三方推送服务的想法,也就有了后来的极光推送.