完善的计划和执行的质量保证流程不仅可以确保产品的质量,还可以确保产品的成功和平稳的业务运营。 获得高质量产品的方法是制定有效的质量保证流程。以下是一些实践,它们将有助于团队质量保证中获得期望的结果。 外包质量检查的一些好处: 节省时间,金钱和精力来维持内部质量检查团队。 少一件事情担心,因为这项工作将由质量检查专业人员来照顾。 外包可以让内部质量团队更专注于核心业务流程。 更多整合 质量保障团队需要找到新的技术和工具,并将其带入团队,以增加质量保证部门的开发流程。 应该让测试人员在SDLC或测试生命周期的不同阶段进行严格质量检查,这将以更快的速度获得关键的信息反馈。 高度重视质量检查 为了从质量检查中获得更多收益,将质量保证作为重中之重很重要。 通过不同的手段保证软件质量,如代码审查如何保证软件质量、软件测试中质量优于数量、5种促进业务增长的软件测试策略。
这个词既可以是个动词,也可以是个名词,初入这个行业,这个词在工作中更多体现的是动词,也就是执行测试,但是工作越久就越有一种感觉,作为一名测试工程师,工作中应该更多地去思考和落地“测试”这个词背后的名词词性——质量保障 首先,我们应该明白一个项目的质量并不是由测试这个环节决定的,而是由整个项目周期中所有环节共同决定的。 作为测试工程师,想要保障好整个项目的质量,就不能局限在测试环节,而是要逐步熟悉整个项目的所有环节,并逐步去把控每个环节中质量。 第二点是测试后置后研发提测质量会有一定的提升,如果研发人员提测质量太低直接会被产品验收打回,这样测试人员不会在提测阶段因为提测质量过低浪费太多精力,测试人员可以有更多的精力去保障整个项目的质量。 作者简介:Chaofan,爱测角成员之一,专注探索和分享软件质量保障。文章首发于微信公众号爱测角转载请注明文章来源公众号:爱测角并附原文链接
因此,“高质量”是最基本要求,这是保证分析效果准确性的基石。那么,常见的质量问题有哪些呢? 事件重复&丢失。 二、保障机制 针对埋点质量问题,我们尝试以下的保障机制,去解决。从业务开发的过程出发,在不同阶段提供服务支持,形成一个解决问题的闭环,保障日志处于高质量状态。 ? 三、现状&规划 在以上介绍的一整套体系化的质量保障工作下,有赞的埋点质量有了大幅度提升。 我们的质量保障工作已经取得不错的成果,并形成良性的循环。 推动业务方主动关心和优化质量问题,让前文提到的闭环,顺畅运行 通过这些方向的努力,相信有赞的埋点质量会持续保持高质量状态,更有力地为业务分析保驾护航。
方法 传统的质量保证通常需要在进行任何测试之前进行大量的准备工作和脚本编写。这导致在接近deadline日期时发现软件中的更多错误。从敏捷测试开始,更多的质量保证涉及自动化测试和持续集成。 最佳实践 质量保证方法可以使我们在一个本已负重不堪的开发和测试环境中脱颖而出,下面分享一些在实际工作中被证明过的质量保证的最佳实践。 测试覆盖率和代码覆盖率 许多质量检查工程师都在谈论关于测试覆盖率,这为应用程序的质量提供了良好的总体印象。但是,要获得真正的质量,必须同时考虑测试用例和代码覆盖率分析。 但是,为了在敏捷方法论中获得最佳质量,QA团队需要转移重点,并从项目开始就立即开始介入和测试。 无论手动测试质量多高,人为错误始终是一个重要因素,这就是为什么使所有可能的测试自动化是确保结果达到并超过期望达到的质量标准的最佳方法的原因。
8月13日应邀在天津做了一场质量保障相关的分享,主题是《看长远 顾眼前——测试活动的理想与现实》,其中关于测试质量的保障因素,自己做了个简单的总结,形成了如下图所示的公式,本文做个详细的梳理,欢迎探讨。 01 质量意识 首先,所有的测试活动都是由人开展的,人的因素应该第一时间被重视。 测试人员对自己的定位,每个人自己的质量意识是非常重要的,如果你没有很好的质量意识,那么在遇到问题时,可能就轻易放过,或者浮于表面现象。 在这种环境下,你很难去做质量保障的事。 如果测试员有以下认知:从自己手中出去的产品,要有最低的质量保证。那么出现问题后,能够及时反思,寻找解决办法,总结经验教训,努力提升自己。 真正把测试当做职业来对待,想到办法解决或者规避同类问题的再次发生,或者通过更好的实践方式,提前预防问题的发生,那么质量保障就会得到很好的实践。
前言 开发提测是正式开始测试的重要关卡,提测质量的好坏会直接影响测试阶段的效率,进而影响项目进度。较好的提测质量,对提高测试效率和优化项目进度有着事半功倍的作用。如何更好的推进开发提高提测质量呢? 开发验证自测case通过提测后,测试验证自测case不通过; 各端开发配合需求中,开发在实际联调成功前回复自测case; 开发与产品两方沟通调整需求,未同步给测试; …… 开发自测case 推进提测质量的提高 在正式提测前开发实现中,可以通过方案讲解会、code review来提高实现质量及预期结果;正式提测阶段,可以通过自测case、交互走查、视觉走查等方式把关质量;提测后,可以有产品验收等方式。 总结 我们在实际项目测试过程中,不可避免的会遇到配合、效率、质量的问题,不同的项目组会有不同的解决方式,流程规范只是其中一种有效手段,小伙伴们可以根据实际项目情况选择最适合自己的解决方式。
前言 从事软件测试相关工作七年,做过功能测试、自动化测试、测试开发、性能测试、专项测试,也干过一段时间技术管理,近几年随着行业成熟度的发展,对软件测试也有了更高的要求,很多测试团队开始转变为质量保障团队 如何从质量保障的维度去更好的为业务提供支持,是我一直在思考的事情。整理了自己的很多笔记,结合我在工作中遇到的种种场景,我梳理出了下面这张质量保障体系思维导图,供大家参考。 在软件质量保障领域,所谓的愿景概括来说就四个字:保质提效。 保质,就是在日常交付中保障软件质量,并且在长期发展过程中,不断提高软件的质量。 对于质量保障团队来说,测试环境及内部自建技术平台涉及的云端资产,都需要通过一定的手段管理起来。当然一般这种事在运维团队,有CMDB体系来进行管理,可进行参考。 问题管理 测试过程中遇到的BUG,分门别类,阶段性的总结梳理,输出质量保障参考手册/SOP; 版本管理 版本管理主要涵盖每个版本的服务发版次数、冒烟通过率、bug的reopen率、上线质量等因素。
典型的COS视频质量自动化保障流程: Step1、用户将视频上传到COS后即可开始使用视频质量评分,通过质量评分将素材进行质量分级。 Step2、为每个质量分级的素材进行其质量级别适配的处理方式。 同时我们在保障过程中以提升用户体验为目标,不断反向推进视频处理的效果优化。 数据万象视频质量评分接口请参考:https://cloud.tencent.com/document/product/460/76906 整个质量保障过程均为自动化流程,无需人工介入,以提升用户体验为目标 下面列出了标准中的部分细则: 执行严格的视频标注&验收流程 在标注过程中,我们聘请了内部上百人的专业打分团队进行质量标注,并在标注全流程的各个环节预埋了打分可靠性保障机制,确保最终获得的标注分数可靠性高 经典案例:腾讯某自有产品视频质量提升 腾讯某自有业务使用质量评估能力来对业务链路进行监控,找到质量瓶颈点,并针对问题设计了视频质量改进方案。
但是如果运营活的质量很差,被骂的声音也会更响亮了! 属实的又爱又恨,运营活动因而成为了质量人最甜蜜的负担~而通过项目的积累、与其他业务的讨论共创,我们也积累了一批对运营活动类项目的测试点和对应的测试方案。 并设定截止的时间限制,观察用户对产品的浏览值和下单量,如果在活动期间用户表现的不温不火,那多半是哪里出了问题,我们的运营互动的目标一定是提升品牌知名度,提高新用户的转化率和老用户的活跃度,因此运营活动的质量保障 参考运营活动类项目测试方案,测试在相关项目中也更充分地可以参与到各个环节,为提升项目收益、保证项目质量、提升测试效率贡献自己的力量。
除了 P99分位数,常用的耗时分位数还包括 P99.9、P95、P90、P50分位数,可以根据应用接口的重要性和服务质量承诺(SLA)选择适当的分位数进行监控和预警。
这一举措旨在优化资源配置,确保关键领域(如用户交互、界面展示、业务流程等)的测试覆盖与质量把控得到充分保障。 对于这类需求,我们鼓励并支持研发团队或产品团队自行构建质量保障体系。 总体流程及保障方案 新创建的小程序必经详尽配置以奠定坚实基础,而迭代优化的小程序则可根据变更灵活调整配置,无需全面重新配置。 总结 小程序质量保障需全面覆盖需求分析、技术选型、开发过程、测试验证及上线运营各阶段。需求分析需精准对接用户期望,技术选型应匹配业务场景,开发过程需遵循规范确保代码质量。 通过这一系列措施,可以有效提升小程序的质量和用户满意度。
媒体服务质量保障与QoE 近年来随着媒体内容处理、传输能力的提升以及内容呈现形式、形态等的不断变化,用户对于多媒体服务、内容质量的期待也越来越高,面对不同业务场景下的需求特性,通过丰富的数据监控与收集, 本专题将从图像质量评估、端到端体验优化、主观人眼感知等不同维度来一同探讨如何保障和优化提升QoS与QoE。 端上网络轻量化加速 ---- Topic2 vivo互联网视频播放体验优化的探索与实践 随着vivo互联网在视频业务领域的不断扩展,在多样化的业务场景下,如何提升每个用户的视频播放体验,保障最优的播放流畅度和清晰度 介绍视频质量评测的必要性以及实践中进行质量评测时面对的难题和困境; 2. ---- Topic4 Hotstar基于大数据平台计算用户观看VMAF质量的实践 在评价用户视频观看质量中,以往通常使用平均观看码率这一指标来衡量。
对于支撑如此海量大数据处理的核心分布式计算平台,质量保障面临非常大的挑战: 开源Hadoop框架在8000+集群规模下,是否能稳定运行,业界没有先例。 所以,我们也采取了相应的规避保障措施: 权限隔离:为测试业务流单独创建权限,可严格保证测试操作对现网用户数据不造成破坏;同时测试权限分配相应的测试资源,对现网同等优先级业务不造成资源竞争影响。
在本文之前,笔者曾分享过一篇关于质量保障流程的文章《漫谈项目质量保障——协作流程》,文章简述了笔者参与的项目协作流程,同时对流程中一些不同寻常的协作节点进行阐述。 由于多种原因限制,之前分享的流程存在一定的不完整性,所以本文将继续分享《漫谈项目质量保障——协作流程》优化后的版本。 如果没有这个环节,没有提测不通过数据的数据支撑,项目延期和项目质量的风险只会是测试人员独自承担,所以需要这个环节来暴露开发的的质量风险并进行约束。 总结来说,项目协作已经是一个比较复杂的过程,而项目协作管理只是项目质量管控中的一小部分。 因此,对于测试工程师或者QA来说,想要把控好软件项目的质量,不仅要关注眼前有形的bug,还需要关注项目流程中无形的bug……作者简介:Chaofan,爱测角成员之一,专注探索和分享软件质量保障。
引言 又到周末了,思前想后不知道写点什么,那就从以前经历的一个线上缺陷说起,聊一下软件质量保障的巡检技术。 我认为质量保障的手段有主动发现与被动发现之分。 主动和被动手段没有哪种更好之分,都是质量保障的一部分,二者结合方可提升业务测试质量。 大家都知道,软件测试是无法穷举测试的,即测试只能证明软件存在缺陷,不能证明软件没有缺陷。 主动手段不能保障产品发布后就不会有缺陷产生,因而可以使用被动手段弥补,监控风险较高的功能or服务。
上线这一整个链路中,参与的角色非常多,涉及到 业务、PM,数据PM,分析师,开发(客户端、服务端,数据); 有4个端的埋点需要全量回归(移动端,h5,桌面端,web端),多端埋点,开发不同,埋点的正确性和一致性难以保障 埋点的核心目的是要采集用户行为数据,并对数据结果进行分析,进一步优化产品或指导产品运营工作,那么如何体系化的去保障埋点数据质量呢?
所以搜索的质量工作一直被如下问题所困扰: 搜索对外提供了 171 个检索条件,不同条件的组合,会流转到不同代码分支。一旦改动公共层代码,不确定回归场景是否全面? 基于上述问题,实践了一套基于流量的质量保障方案。 二 搜索质量保障方案 2.1 整体保障方案 目标:借助流量区分活跃和非活跃代码,针对活跃代码,使用场景计算,自动识别和构建场景用例。 接下来分别介绍:活跃代码保障策略,非活跃代码保障策略,自动回归策略。 2.3 非活跃代码保障 2.3.1 保障策略 流量覆盖不到的代码是非活跃代码,保障策略采用人工覆盖。搜索的非活跃代码主要有:1)开关;2)异常场景;3)未使用的方法。 质量保障的挑战 全场景覆盖,人工回归成本高。 服务重构前后,同一搜索条件,返回结果和结果顺序必须强一致,采用人工对比既痛苦又容易漏测。
在此,将有赞的前端质量保障体系进行总结,希望和大家一起交流。 先来全局看下有赞前端的技术架构和针对每个不同的层次,主要做了哪些保障质量的事情: ? ? 对于每个不同的层,我们都做了一些事情来保障质量,包括: 针对整个业务层的 UI 自动化、核心接口|页面拨测; 针对 client 层的 sentry 报警; 针对 server 层的接口测试、业务报警; 下面就来分别讲一下这几个维度的质量保障工作。 一、UI 自动化 很多人会认为,UI 自动化维护成本高、性价比低,但是为什么在有赞的前端质量保证体系中放在了最前面呢? 这个时候单单靠服务化接口的自动化已经不能保障对上层接口的全覆盖,所以我们针对 Node 接口也进行自动化测试。 为了使用测试内部统一的测试框架,我们通过 java 去请求 Node 提供的 http 接口,那么当用例都写好之后,该如何评判接口测试的质量?是否完全覆盖了全部业务逻辑呢?
第一章讲了保障项目质量的前6点,是关于比较基础的,接下来是比较虚的知识点,也就是是意识上的东西,对于测试人员和管理层会有比较大的提点,话不多说,续上: 7.数据量化分析,如项目质量DDP,O-DDP 通过数据来分析存在问题的问题以及量化各合作部门的工作情况,如需求探索率,千行代码Bug率等,通过定义好一个指标,让大家都遵守,形成输入-标准-输出的准则; 8.测试之心,测试人员要具备专心,细心,耐心,用心,信心,责任心,拥有了他们就拥有强大的内心,那质量就不用说了 12.最重要的一点,也就是PDCA,简称戴明环,周而复始的发现,解决,检查,总结,计划的做,形成一个系统化的思维,不断的优化改善,但记得这是一个“度”的衡量,适合自己才是最重要的; 最终全方面的保证项目质量秘籍就是 “测试流程化,质量标准化,流程规范化,培训系统化,管理精细化”这二十个字;这也是测试团队管理的最终目标;以上是个人对于如何保障全方面保证项目质量及团队管理的最终目标;
然而由于内存泄漏导致的OOM、空指针正是导致应用崩溃的两大原因,因此尽早的发现并且解决掉这类问题对于应用质量来说至关重要。 用单元测试尽量覆盖程序中的每一项功能的正确性,这样就算是开发后期,也可以有保障地增加功能或者更改程序结构,而不用担心这个过程中会破坏原来的功能,因为单元测试为代码的重构提供了保障。 通过不断的完善自动化平台,以机器替代部分的人工测试,我们的应用质量将会得到很大程度的保障。 即使只有单元测试、压力测试、LeakCanary内存检测、云平台的兼容性测试,我们的应用也能够经受住创业公司快速迭代带来的质量考验。 我们的目标是提高应用的质量,而不是增加测试的数量。 以上就是我这阵子的实践与总结,也希望更多的人将自己的实践、所思所得分享出来,让我们在开发过程中少走弯路!