wordpress企业站教程,企业邮箱域名怎么设置,做会员卡的网站在线制作,有没有专门做宝宝用品的网站引言
那一年#xff0c;我刚毕业一年多#xff0c;在第一家公司依然到了成长瓶颈期#xff0c;一是不愿意频繁出差#xff08;做乙方的无奈#xff09;#xff1b;二是疲于每天重复的手工测试#xff08;团队缺乏技术氛围#xff09;#xff0c;技术上难有突破的机会…引言
那一年我刚毕业一年多在第一家公司依然到了成长瓶颈期一是不愿意频繁出差做乙方的无奈二是疲于每天重复的手工测试团队缺乏技术氛围技术上难有突破的机会。身边的同事基本上是安于现状的而我作为新人则精力充沛感觉自己每天除了学习真不知道干什么了时常学习到半夜。此时我觉得趁着年轻是换个环境的时候了开始投递心仪的公司。优先考虑上海的公司原因是经常来这儿出差比较喜欢上海这个城市最后全部拿到了投递公司的offer最终选择了字节跳动测试工程师偏功能测试岗位顺利来到上海。
而如今离开前东家已经2年多了回首职业生涯我觉得在前东家做项目那一年多的时间是我成长最快的时光。诚然那段时光的成长离不开天时地利人和。就像出名要趁早一样成长也是一样的道理。天时是当时刚毕业年轻人的奋斗劲十足地利是选择了字节跳动创新业务部门我认为创新业务更多的是开疆拓土面临的挑战比较多而成熟部门做的更多的是“守成”一般“卷”的也比较厉害给我机会施展“才华”人和就是遇到了一个非常nice的老板带我成长。
来到字节跳动做项目并非一帆风顺可能是部门刚成立的缘故接手过来的项目是一个多年的老项目没有测试沉淀对于我来说完全就是黑盒中的黑盒。一切都要从0到1开始包括业务熟悉、测试团队建设、开发测试关系培养、测试流程完善。
正如“破蛋说”一样工作亦如此,从外面打破是压力,从内打破是成长。成长往往伴随痛苦痛苦是多个项目并行痛苦是经常加班到凌晨甚至通宵痛苦是漏测导致了线上缺陷痛苦是…。而透过痛苦蓦然回首你会发现这才是财富哈哈这句真的是老PUA了。
本文就从质量改进的角度给大家分享下笔者从0到1对老项目做质量改进的历程。 项目现状
1.接手“烂摊子”
在字节面试通过后我通过微信向老板咨询将来负责什么业务老板说会让我单独负责X系统算是一个内部使用的平台型系统对于性能要求不高但是对稳定性要求比较高。入职字节后这个系统还是我同事在兼着负责来之后让我先跟着同事做一两个迭代然后等业务熟悉后会完全交给我负责。大概熟悉一周业务之后我就参与了第一个迭代。参与后对于这个系统最大的体感就是“乱”。可以概括以下几点 系统比较陈旧僵尸代码多。和同事沟通得知这个X系统其实是5年前的老项目了ApachePHPMySQLRedis架构赶上最近公司扩展新业务才重新拿出来用所以这个系统之前是没人测试的。 开发不熟悉系统代码。开发同学赶鸭子上架边熟悉代码边开发新代码的。改动一行代码到底影响有多大开发无法评估导致测试验证缺陷修复的策略往往回归全量用例。3. 系统前后端不分离前后端开发同学在同一套代码上进行开发部署都要等到前后端同时ready才可以总之非常麻烦。 硬编码的地方比较多。修改配置都要重新发布项目。 缺失接口文档。
2.质量保障策略
2.1 开发比悬殊
当时后端3个前端2个全职开发人力5个而测试只有我一个人后面又招进来一个外包真的是单打独斗的节奏。
2.2 项目流程不规范
技术方案频繁更改开发不写单测没有冒烟测试项目发布不规范等
重点说下项目发布不规范可以概括为
1.“准出”规则不规范。针对准出规则我想大家肯定是熟悉的即只有达到发布标准才允许项目发布。
2.发布时间不规范。为了保证多个项目的排期都会规定固定的某天周X为发布日一般选择周四这样可以在周五观察一天看是否有线上缺陷这样在周五还来得及修复。
2.3 测试文档没标准
测试用例
测试小组里每个测试同学基本上按照自己的习惯写测试用例所以测试用例要素不尽统一再加上当时测试用例的载体为Excel导致测试用例复用率较低维护也比较麻烦无形之中耗费测试同学很多宝贵时间。
测试方案
没有统一的模版每个人自成一体。
测试报告
测试方案和测试报告也是类似的问题没有统一的标准会让老板觉得比较乱。
2.4 缺陷管理不规范
没有缺陷的程序是不存在的。从缺陷发现、缺陷修复直到缺陷解决、经验证、关闭缺陷为止在缺陷管理的整个生命周期中记录了大量数据它们是进行缺陷分析、提高产品质量所需要的宝贵信息。度量这些缺陷的发现成本、修改效益对缺陷管理及其改进是非常有帮助的。
缺陷描述五花八门
没有统一的缺陷描述格式对于统计缺陷分析缺陷影响很大不利于统计结果精准统计。
缺陷等级边界不明
这个问题可以分为两部分来说明
1测试过程给开发提缺陷。由于缺陷级别不明确一个中等的缺陷可能会被测试认作重大缺陷这会让开发同学十分憋屈对测试的专业度认可大打折扣影响测试开发关系
2项目上线后发现缺陷。因为负责的系统服务于公司内部使用所以缺陷定级也不是很清晰在线上发现缺陷时候由于标准不明确责任人往往会压低缺陷级别这样的后果就是会让大家不重视测试质量。
缺陷生命周期
测试人员应该跟踪一个Bug的整个生命周期从Open到Closed的所有状态。我们当时使用的缺陷管理工具是JiraJira支持配置BUG状态转换图这样可以确保所有缺陷的最终态是end。 4.开发修复缺陷漫不经心
有的开发同学对于缺陷修复不积极可能是并发任务多早上提的缺陷到了晚上开发还没修复如果是一般的缺陷不影响主流程还好但是要是严重缺陷这样下来一天都执行不了多少用例所以有时候会经常搞到深夜去验证开发修复的缺陷。
5.开发修复缺陷质量低
这个问题是有些开发同学修复缺陷时候考虑不周往往是修复缺陷后引入新缺陷导致频繁发布带来的后果就是测试频繁的回归“劳民伤财”整的测试同学身心俱疲。这个问题和问题4属于两个极端。
2.5 质量手段单一
当时刚接手这个系统完全是一穷二白的境地没有前人的测试积累可以参考完全是从0到1开搞。刚接手的前半年基本是依赖手工做黑盒测试。仅靠手工测试的缺点也日益显露随着项目的需求越做越大回归成本日益增高所以做的越来越心累。
3.测试成本高用例质量低
1.开发代码质量低
因为没有自动化测试用例沉淀刚接手项目的时候迭代较多小步快跑一周小迭代两周大迭代几乎没有时间停下来测试接口写自动化用例完全是纯手工测试业务。而我们的项目只有两个环境dev环境和线上环境没有测试环境与开发共用dev环境所以起初dev环境的代码很不稳定因为开发没有规范技术方案设计质量低、代码不规范等导致开发质量较低缺陷密度高回归频繁成本较高。
2.外包不重视测试分析测试质量低
我带的一个外包同学测试分析几乎是把开发的技术方案copy一份而是在编写测试用例的时候去分析功能需求。使用Excel编写测试用例设计用例时间长导致测试用例质量较低。
质量改进
修炼内功
1.项目流程规范化
根据项目迭代情况制定规范化的项目流程经过半年多的项目迭代发现可以将项目归类为3大类
1hotfix项目整体时间2-3天
2小迭代整体时间1周
3大迭代整体时间2-4周
不同的迭代对应不同的发布流程。
2.测试标准化
1文档规范化
制定测试分析文档模版
测试报告模版统一
每日测试进度模版统一
2缺陷管理标准
缺陷要素标准化
缺陷定级规范化
缺陷流程规范化
缺陷修复规范要求开发当日缺陷当日修复并回归
3简化用例设计提升用例质量
测试用例重点在于“分析”测分做的全面用例完全可以不用再重复写。因此我们为提升测试设计效率把更多时间放在了测试分析上对测试用例的6要素进行了统一测试用例的编写放弃传统的Excel全面拥抱xmind测试评审也采用xmind模式。
a) 测试标题
b) 重要级别
c) 预置条件
d) 输入参数
e) 操作步骤
f) 预期输出
当然xmind也有缺点就是用例不易存档复用率较低虽说传统的Excel设计用例效率低但是易于存档也是其一个优点为了解决这个问题存档难、复用率低的问题我们又开发了一个工具支持将测试用例从xmind上解析出来生成Excel然后基于项目迭代将每次迭代的用例进行存档。
3.测试提效
mock平台
因为所在的项目是内容生产系统其中有用到算法服务可以理解为微服务在业务还没发展壮大的时候 算法服务支持的系统只有我们平台所以契约比较固定算法迭代都是涉及算法效果的提升。但是后面随着公司对E部门投资力度的加大此前和E部门有类似业务形态且相互独立的部门开始整合成新的部门 而我们部门又是提供内容生产的部门随后就提出中台化概念整合部门基础技术能力给兄弟部门提供技术支持。此时成立了很多中台对外提供基础支持能力算法也不例外所以这也是mock平台产生的直接因素。
E部门中台化概念引出之前算法还没有所谓的微服务概念当时算法算只是中台接口所以随着业务量的增大算法团队为了支持更多业务线就对其算法契约接口参数约定做了升级但是算法同学缺乏后端开发承接业务的思维所以把对接各业务线的契约维护的一塌糊涂经常因为契约问题出现缺陷入参/出参经常不一致。刚开始鉴于算法只针对我们自己的系统提供服务所以契约比较稳定测试同学也没有将算法与我们系统作为联调对象也不会有什么问题。后面算法承接业务多了问题就来了。连续发现了两三次算法接口契约变动导致的缺陷后面测试团队在每次项目迭代时也就将与算法联调作为测试点。最开始的做法就是让后端开发本地起个算法服务的mock但是对于测试来说mock服务的质量不能保障如果mock服务的契约不是最新的那么是发现不了问题的最终还是会逃逸到测试阶段进而增加与算法同学的撕逼成本然后我们就提出mock平台的概念mock平台提供的基础能力就是可以根据接口文档获取最新的契约自动创建mock服务不必担心mock服务质量低的问题所以就保障了mock服务质量。
但是仍然还有可以提升的地方例如后端开发使用mock的服务仍然需要手动替换域名这点颇为繁琐。而来到阿里这边发现这个问题也有解法可以为mock平台的服务增加mock开关当开关打开在后端服务对xx服务进行调用的时候可以先mock consult如果咨询结果true就走mock链路反之走真实链路。
小工具平台
我们团队内部有很多小组每个小组leader各自负责不同的业务而不同的业务间又是相互调用的难免会找对应业务的测试同学帮忙造些数据什么而我负责的服务又是最底层的内容生产是其他业务进行的第一步经常接到产研测的造数据等需求在频繁的需求中我们就整理外部需求在项目演进的过程沉淀很多基于业务的小工具。小工具平台的目的就是整合各小组各业务系统的提效工具允许不同业务间相互调用各业务具备的工具减轻小组同学对外协作的压力将更多时间放在负责的业务上。此外小工具平台提供数据统计能力统计平台内小工具使用流量/频次。
每个小工具提供help入口可以备注问题但是当时还没有客服体系不能做到实时响应。
而我针对小工具平台也做了2次分享鼓励大家开发工具当时使用的技术也比较简单也为更多是内部工具部署也是在团队内部一个工具分前端和后端鼓励前后端使用python栈我的观点是Python上手简单很多提效工具都是python开发的python还提供web开发框架如flask、Django等在当时完全够用。
而来到阿里这边这边也有类似的平台。但是更多也是基于团队内各小组的我所在团队是这样的。只不过大家都是使用Java开发。
当然小工具平台的缺点也有如前端页面不好搭flask并不是都能使用的游刃有余前端页面样式不统一等。其实这点突出了大家前端开发能力的欠缺。虽然脚本大家都会但是前端并不是人人都会。而针对这个问题的解法可以考虑将前后端分离前端使用搭投框架作为小工具平台的基础架子允许大家基于自己的idea搭建各种样式统一的工具前端页面后端服务随你使用什么语言只要能开发出一个API就行直接对接前端。这样就解决了大家前端开发能力弱的问题而且还不拘泥提效工具后端逻辑使用的语言形式更利于平台的建设。
此外不同业务组的工具的帮助文档不完善。例如写出这个脚本的目的、如何使用这个脚本它期望接收的数据以及返回的数据以及一些前置条件和后置条件。一些额外的信息也很有用如在一些可能的错误条件下会发生什么。这些信息应该可以很容易地搜索到。事实上将这些信息收集起来就可以作为测试件的文档而且通常可以很直接地将这些信息收集起来并将其分类到单独的文档或者集中进行管理。
造数据工具
一般来说造数据占了测试工作内容的1/3。测试同学在设计测试用例的时候最重要的一个步骤就是预置数据的定义。测试数据的方式有手工定义、脚本生成、甚至有涉及到数据库存储过程等。
造数据工具其实属于小工具平台的一个工具而已为什么要拎出来重点讲解呢当然是造数据很重要特别是对于那些链路比较长而且“分叉”比较多的业务。我负责的业务形态就属于这种因为是内容生产系统如果你去过生产流水线会更有体感同样内容的生产也是经历了6/7道工具而且不同结构的内容实用的工序生产流程还不一样。就拿一道题目而言。你可以对其特征进行发散。例如学科、年级、题目类型填空、判断、解答、选择。
不同类型的题目它的结构也不一样 所以它的生产工序也是不一样的不一样的生产工序就有不一样的数据流。不同的数据流就要求在接口调用的时候要传不同的参数或者调用不同的接口。本小节主要讲述一下我们团队的全链路造数工具的发展历程。可以简单概括为四个阶段
第一个阶段就是纯手工造数的阶段
第二个阶段是利用接口自动化测试工具JMeter进行串联链路接口进行造数
第三个阶段是利用团队内部自研的接口自动化框架造数 利用框架开发全链路自动化用例通过Jenkins调度自动化用例发起一键造数。
第四个阶段【规划阶段】就是基于接口自动化平台进行一键造数其实本质和Jenkins的造数任务是一样的只不过利用平台化可以提高造数效率和数据丰富度。
第一阶段第一阶段也是接手项目刚起步的时候这个时候组内的自动化能力还很不健全所以我们接到产品或一些其他同学的造数需求的时候基本上都是抽空 帮他们造数据大概是我们测试对平台操作比较熟悉的缘故吧 抑或是他们觉得这就是测试要干的活现在想 当时为什么不知道拒绝呢当然这是后话。这个阶段没有自动化工具所以是最费时间而且重复极高。也占据了我们不少时间。
第二阶段因为我有JMeter工具的使用经验所以当时我就利用这个工具串联了我们业务的核心流程接口然后就可以进行一键造数据。当然因为产品他们基本上不会使用这些设施工具所以还是我们帮他们使用工具帮他们造数据。嗯严格来说是节省我们一部分时间了。
第三阶段这个阶段我们已经有了接口自动化测试框架然后我们就将全链路接口自动化用例部署的Jenkins上通过任务调度的方式去执行一键造数造数成功后可以lark通知执行者。
第四阶段有了接口自动化测试框架然后老板就想让我们再搞一个前端页面这样在操作上更简便而且方便做数据统计也降低了产品同学的使用门槛。
推动测试左移
1静态代码扫描
2推动开发自测
3推动开发CR
4鼓励测试参与CR
质量度量
想必大家都有这样被老板灵魂发问的经历吧。 当你负责的项目按时交付发布后你老板问项目的测试质量怎么样啊 当你测试的项目上线后有用户曝出使用缺陷你老板问你这个缺陷怎么没有测试出来呢
如果测试工程师将测试工作理解为测试用例设计、测试执行那么你大概率回答不好老板的提问给不到老板想要的答案。
测试工程师作为项目质量把关者 是产品质量保障至关重要的一环测试设计和执行只是其职责的一部分殊不知测试质量度量也是测试工作尤为重要的一环。测试质量度量的范围不仅限于测试角色也包括开发角色甚至是产品角色。因为产品质量不是测出来的而是产研测三方共同努力“测试”的结果。
度量是一种工具就像一把尺子衡量项目测试质量的好坏哪些地方做的好哪些地方还需要改进。
下面就分享下测试工程师如何度量软件测试质量我将其分为三个过程 缺陷规范 缺陷管理 质量度量
Step1: 缺陷规范
软件缺陷可以是编码中的缺陷也可以是软件需求设计中的缺陷最终都会导致软件程序运行不符合用户预期需求 的结果。有过测试经验的小伙伴大都接触过比较流行的缺陷管理工具Jira用于记录测试过程发现的缺陷。想要做好质量度量就一定要有被度量的元数据缺陷数据而缺陷自身被给予的特征维度越多则越能将度量工作做的更细致也能度量出更多的结果。而缺陷规范可以简单理解为给缺陷 贴不同维度标签要素。
如上所述理论上缺陷要素越多则度量的结果越精确但通常会包含以下基本内容如描述、发现缺陷的日期、发现缺陷的测试人员的名字、修复缺陷的开发人员的名字等。
缺陷ID唯一的缺陷ID可以根据该ID追踪缺陷
缺陷状态一般情况下缺陷状态有“打开/重新打开”、“待解决”、“不解决拒绝”、“已解决”、“已修复”、“延期修复”、“关闭”等。英文描述Open/Reopen、un-solved、Won’t Fix、Resolved、Fixed、Deferred、Close。
缺陷标题描述缺陷的标题
缺陷标签用于给缺陷归类
缺陷的详细描述对缺陷的详细描述缺陷如何复现的步骤等等之所以把这项单独列出来是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改描述应该尽可能详细。
缺陷的严重程度描述缺陷的严重程度一般分为“致命Critical”、“严重Major”、“一般Minior”、“轻微Trival”和“建议修改Suggestion”等五种。缺陷的紧急程度描述缺陷的紧急程度用P0-4级来定义4是优先级最低的等级0级是优先级最高的等级。缺陷的紧急程度与严重程度虽然是不一样的但两者密切相关往往的越是严重就越是紧急但是也存在一些情况虽然严重等级不高但是需要紧急修复。
缺陷提交人缺陷提交人的名字
缺陷所属项目/模块缺陷所属的项目和模块最好能较精确的定位至模块缺陷解决人最终解决缺陷的人
缺陷处理结果描述对处理结果的描述如果对代码进行了修改要求在此处体现出修改
必要的附件对于某些文字很难表达清楚的缺陷使用图片等附件是必要的
Step2: 缺陷管理
缺陷管理是一个缺陷从被发现到缺陷修复的系统过程也叫缺陷生命周期管理。缺陷管理周期包含以下阶段
1发现缺陷
2记录缺陷
3修复缺陷
4验证缺陷
5Reopen/关闭缺陷
6统计缺陷 Step3: 质量度量
强调一点缺陷度量不仅仅发生于测试结束后而是伴随整个测试过程的。那么测试质量度量指标有哪些呢
汇总如下可以看出我们软件测试度量范围不仅限于测试角色还包括开发角色。 以缺陷拒绝率为例假如测试提出84个缺陷开发测试双方认定其中20个不属于缺陷你可以计算出缺陷拒绝率是20/840.23823.8 %。通常来说缺陷拒绝率值越小测试的质量就越高。
我们通过上述指标可以窥探测试/开发存在的问题效率问题、质量问题等用于提出解决方案并最终提升项目效率和质量。
最后试想一下每个项目测试完毕上线之后如果你的老板再问你文章开头的问题你是否就不慌了呢这就是 心里有“数”就不慌。
典型问题鞭尸
1.开发经常私自发布代码
先介绍下当时团队的开发模式我们总共有2套环境dev环境和线上环境。新需求开发流程是将master代码merge到dev分支开发在各自的研发分支开发feature然后merge到dev分支提测后测试在dev环境测试新功能测试通过后会让开发给当前测试通过的代码打版本tag然后将此代码merge到master分支再进行线上环境的回归测试。 对于质量体系建立还不够不完善的团队这个问题是比较常见的。和开发同学打交道这么多年还是比较了解开发私自改代码的动机的。我说几种常见的情况
1提测后开发发现自己的代码有缺陷A就偷偷修改代码并随测试同学提交的缺陷的修复代码一起commit到dev分支。说实话这个还是比较隐蔽的如果他们修复缺陷A的代码不会引出新缺陷测试很难发现这个问题的。
2开发同学发现自己犯了比较低级的配置问题时候碍于情面就悄咪咪修改并commit。 改进建议
1记录开发“犯错”的次数以及引发的问题用于约束开发不要私自修改代码话说再一再二不再三人都是要面子的次数多了他们也不敢再乱来如果还是私自改说明他们态度真的有问题。
2采用技术手段监控开发提交的代码-gitlab/github上都可以配置提交/merge代码的webhook用于监控开发提交的代码并在群里消息提醒。
2.项目漏测频出
缺陷来源分析
我们在进行项目复盘的时候发现一些漏侧的缺陷明明是测试评审用例中有覆盖到此场景的而在测试同学执行的用例记录中漏侧的场景用例也是Pass的那么为什么线上仍会有此缺陷呢
和负责的测试同学沟通后发现有以下几个情况 业务流程不熟悉 第一轮测试A场景用例通过B场景用例发现缺陷。开发修复后测试同学对B场景进行回归验证因为他觉得A场景和B关联性不大所以没做回归但是恰恰感觉关联性不大的地方实则有一定关联导致漏测。 执行用例的同学觉得针对功能模块A设计相关的几个测试用例属于等价类所以在执行其中一个用例通过后其他用例完全没执行就进行了Pass标记。但是实际用例之间并不等价导致漏测。 我们测试流程是DEV环境全量用例测试线上环境仅执行主流程用例。正由于线上回归不是全量回归而又缺乏自动化回归能力我们也踩了一些环境配置导致的漏测的坑。
改进建议这个问题也侧面反应两个点1.频繁的手工测试让人倦怠测试同学很容易眼高手低。2.没有自动化回归测试同学的经验如果不可靠往往付出血的代价。
为了解决这个问题我们小组采取交叉回归策略。例如一个迭代有A、B两个同学参与测试在一轮测试完毕后A\B两个测试同学相互交叉测试彼此负责的模块这样能解决一部分测试人员因工作粗心导致的漏测。
此外我们团队开始着手接口自动化能力的建设重点在测试环境自动化回归。3.建立项目文档知识库缺陷复盘存档。
3.项目初期 发现bug数量多修复率低上线频频延期
团队初期由于项目节奏比较快项目组成员不是在评审就是在评审的路上几乎每天都有各种项目相关的会议大家都在赶项目上而忽略了项目过程遇到的流程不健全的问题最大的问题就是对开发的“宽容”现在想想真的是对开发的宽容就是对自己的残忍具体点就是没有要求开发冒烟测试开发自测完事后走一遍流程就提测了而测试过程发现缺陷比较多而且reopen的缺陷比较多。
当然针对缺陷比较多的问题我们自身也进行了缺陷分析原因和归类大致有以下几类 需求问题产生的bug需求设计不合理而直到测试阶段才发现问题 开发实现和需求不一致产生的bug 开发自测打马虎眼对bug睁一只眼闭一只眼 开发新人对产品功能不熟悉 环境问题导致的bug
下面分析一下第3点如果开发对自己开发代码多些责任心自测质量高一些会大大降低缺陷逃逸到测试阶段以及reopen的次数。而项目质量的提升不能完全只靠“测”离不开测研协作推动开发高质量自测就显得非常重要。
而鉴于此问题的严重性我们和开发同学沟通制定了三板斧策略 推动开发高质量自测不管是缺陷修复还是功能开发阶段。 设置项目提测门禁冒烟测试用例100%通过方可提测。 给开发打质量分初期我们给开发打质量分的指标也比较简单主要针对缺陷统计侧面评估开发质量当然每个项目的开发质量分会和开发leader反映问题所在目的在于提升开发质量。
4.测试过程发现了需求之外的缺陷即如何处理历史缺陷
随着业务压力越来越大老板也给我们很对外包招聘名额后续团队陆陆续续增加到7人其中6个外包当然并不是每个项目都是6个人一起上而是将其划分了3、2、1的模式其中3个人cover一个较大的项目2个人cover较小的项目1个人是自由人主要承担线上反馈问题处理以及随时补位。较大项目一般2周发布小项目一周一发。由于两条项目线并行的问题这样就出现了A项目的测试同学负责的项目发现B项目测试同学负责过的版本存在遗漏的缺陷而对这种问题我们分情况处理 如果测试过程发现历史缺陷产研测会将此问题抛出来评估严重程度以及修复成本。(1).严重程度决定是否修复; (2).修复成本用于评估额外的项目成本是否对项目整体造成延期的风险。如果缺陷比较严重修复成本比较高则会延期修复。如果缺陷不严重则根据开发测试意愿自己决定是否修复。 如果A小组负责项目上线后发现了B小组测试的项目版本出现缺陷则缺陷责任人属于B小组测试人员。
5.开发过程需求经常变更
你是否也遇到过类似问题开发实现的产品和交互设计的不一致问了开发原因才晓得是产品单独找开发更改需求了。。。
当然并不是说 需求不能变更需求问题在任何公司我想都是不可避免的。因为随着系统复杂度的不断提高等原因产品同学确实不太容易考虑完全。
该问题也比较常见对项目的影响 提测前需求变更导致开发过程不流畅且会存在设计变更的风险缩短开发时间影响开发进度及项目质量。 提测后需求变更影响开发新版本的流程及开发修复bug时间影响QA的测试进度。且需求变更容易引出新的问题致使项目质量不可控。
需求变更直接影响是增加项目不确定性风险。
解决方案
针对需求问题我们通过以下措施去推动解决 硬性要求需求变更必须通知到研测三方共同拍板并重新评估项目排期。 测试角度产品同学提前发需求文档鼓励测试同学在需求评审的过程参与需求测试多思考异常场景。 产品角度避免需求文档中出现不确定、同上等模糊不清的说辞。如变更需求PRD应及时更新要有变更记录避免口头变更。 开发角度避免盲从产品变更需求应三方确认后重新更新技术方案如有必要可以重新技术评审。如未告知测试进行需求变更测试有理由拒绝测试。
6.线上故障应急效率低以及改进策略
第一阶段刚接手项目后就被拉进了很多飞书应急群。要说整个项目过程什么时候是最紧张的那肯定是项目上线后的第2天早上因为新需求上线后可能会有未知的缺陷暴露所以规定发布后的第2天一大早就要去公司候着以随时应对线上反馈的问题。对这是团队最早的应急方式-应急群被动接线上问题完全属于人肉应急。
除了应急效率低的问题还经常报一些非代码缺陷的情况例如网络原因导致的响应延迟问题、用户对新需求不熟悉的问题。当时我们也采取了一些手段来提升应急效率针对用户对需求不熟悉的问题让产品同学及时和CQC同学沟通新需求内容和一线的用户沟通最好在多个用户能同时复现再反馈到应急群。此外针对网络等因素的问题我们还给用户培训如何辨别问题的原因例如利用Chrome的开发者工具查看接口报错等。再者就是建立缺陷知识库给缺陷归类并标记tag让一线用户可以自助找解决方案。
第二阶段这阶段半自动应急阶段何为半自动其实就是给问题自动分配应急人并通过机器人自动化记录问题用于每个月的项目质量打分可以理解为问题自动化存档。
第三阶段接入字节跳动兄弟团队研发的应急机器人可以基于知识库给用户自动化推荐相似问题的解法。可以有效排除一些反馈的无效问题节省应急人的时间。
7.开发只改了一点点为什么测试需要耗费那么多时间关于测试开发时间的合理性评估
也许你也遇到过经常被开发/产品挑战“只改了一点点为什么测试需要耗费那么多时间啊”
这个问题在我经历过的几家公司都被开发产品挑战过。这个问题的本质是测试依赖手工测试的局限性。没有完备的自动化回归能力缺乏有效的精准测试能力仅人肉回归必定增加无效的测试。也属于测试有效性需要解决的问题。
下面说下我们测试组对测试开发时间比的“争论”以及最终的“妥协”。
第一阶段没有什么测试开发时间比因为当时项目多测试人员少往往一个测试全包全揽所以测试时间根据功能测试范围由测试评估当然测试时间的长短由测试经验评估的测试范围准确性决定。而缺乏有效的评估工具和精准测试工具有时候经验也不准备所以有时候项目比较赶有时候比较松。接着我们想到根据用例数评估测试时间就按每天200个测试用例的执行数评估一轮测试时间再加1人日回归时间这样作为测试工时。例如600个测试用例一轮测试3人日加1人日回归总共4人日测试时间。
第二阶段后来随着项目的任务量减小经过高强度项目长时间的浴血奋战老板发现测试同学手工测试略显疲态为了缓解这种长时间手工带来的问题和开发老板一起沟通决定测试开发时间比按1:3排期。这样不管项目大小其实都给测试留出了一些自主时间可以用于技术提升。
第三阶段建立接口自动化能力将业务按主流程划分全部实现接口自动化覆盖提升测试效率可以更快速的测试。 感谢每一个认真阅读我文章的人
作为一位过来人也是希望大家少走一些弯路如果你不想再体验一次学习时找不到资料没人解答问题坚持几天便放弃的感受的话在这里我给大家分享一些自动化测试的学习资源希望能给你前进的路上带来帮助。 软件测试面试文档
我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。 视频文档获取方式 这份文档和视频资料对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你以上均可以分享点下方小卡片即可自行领取。
