聊一聊在字节跳动做项目质量改进的经验

引言

那一年，我刚毕业一年多，在第一家公司依然到了成长瓶颈期，一是不愿意频繁出差（做乙方的无奈）；二是疲于每天重复的手工测试（团队缺乏技术氛围），技术上难有突破的机会。身边的同事基本上是安于现状的，而我作为新人则精力充沛，感觉自己每天除了学习真不知道干什么了，时常学习到半夜。此时我觉得趁着年轻是换个环境的时候了，开始投递心仪的公司。优先考虑上海的公司，原因是经常来这儿出差，比较喜欢上海这个城市，最后全部拿到了投递公司的offer，最终选择了字节跳动测试工程师（偏功能测试）岗位，顺利来到上海。

而如今，离开前东家已经2年多了，回首职业生涯，我觉得在前东家做项目那一年多的时间是我成长最快的时光。诚然，那段时光的成长离不开天时地利人和。就像出名要趁早一样，成长也是一样的道理。天时是当时刚毕业，年轻人的奋斗劲十足；地利是选择了字节跳动创新业务部门（我认为创新业务更多的是开疆拓土，面临的挑战比较多；而成熟部门做的更多的是“守成”，一般“卷”的也比较厉害）给我机会施展“才华”；人和就是遇到了一个非常nice的老板带我成长。

来到字节跳动，做项目并非一帆风顺，可能是部门刚成立的缘故，接手过来的项目是一个多年的老项目，没有测试沉淀，对于我来说完全就是黑盒中的黑盒。一切都要从0到1开始，包括业务熟悉、测试团队建设、开发测试关系培养、测试流程完善。

正如“破蛋说”一样，工作亦如此,从外面打破是压力,从内打破是成长。成长往往伴随痛苦，痛苦是多个项目并行，痛苦是经常加班到凌晨甚至通宵，痛苦是漏测导致了线上缺陷，痛苦是…。而透过痛苦，蓦然回首你会发现这才是财富（哈哈这句真的是老PUA了）。

本文就从质量改进的角度，给大家分享下笔者从0到1对老项目做质量改进的历程。

项目现状

1.接手“烂摊子”

在字节面试通过后，我通过微信向老板咨询将来负责什么业务，老板说会让我单独负责X系统，算是一个内部使用的平台型系统，对于性能要求不高，但是对稳定性要求比较高。入职字节后，这个系统还是我同事在兼着负责，来之后让我先跟着同事做一两个迭代，然后等业务熟悉后会完全交给我负责。大概熟悉一周业务之后，我就参与了第一个迭代。参与后，对于这个系统最大的体感就是“乱”。可以概括以下几点：

1. 系统比较陈旧僵尸代码多。和同事沟通得知，这个X系统其实是5年前的老项目了（Apache+PHP+MySQL+Redis架构），赶上最近公司扩展新业务才重新拿出来用，所以这个系统之前是没人测试的。

2. 开发不熟悉系统代码。开发同学赶鸭子上架，边熟悉代码边开发新代码的。改动一行代码到底影响有多大开发无法评估，导致测试验证缺陷修复的策略往往回归全量用例。3. 系统前后端不分离，前后端开发同学在同一套代码上进行开发，部署都要等到前后端同时ready才可以，总之非常麻烦。

3. 硬编码的地方比较多。修改配置都要重新发布项目。

4. 缺失接口文档。

2.质量保障策略

2.1 开发比悬殊

当时后端3个，前端2个，全职开发人力5个，而测试只有我一个人（后面又招进来一个外包），真的是单打独斗的节奏。

2.2 项目流程不规范

技术方案频繁更改，开发不写单测，没有冒烟测试，项目发布不规范等

重点说下项目发布不规范，可以概括为：

1.“准出”规则不规范。针对准出规则，我想大家肯定是熟悉的，即只有达到发布标准，才允许项目发布。

2.发布时间不规范。为了保证多个项目的排期，都会规定固定的某天周X为发布日，一般选择周四，这样可以在周五观察一天，看是否有线上缺陷，这样在周五还来得及修复。

2.3 测试文档没标准

1. 测试用例

测试小组里每个测试同学基本上按照自己的习惯写测试用例，所以测试用例要素不尽统一，再加上当时测试用例的载体为Excel，导致测试用例复用率较低，维护也比较麻烦，无形之中耗费测试同学很多宝贵时间。

2. 测试方案

没有统一的模版，每个人自成一体。

3. 测试报告

测试方案和测试报告也是类似的问题，没有统一的标准，会让老板觉得比较乱。

2.4 缺陷管理不规范

没有缺陷的程序是不存在的。从缺陷发现、缺陷修复，直到缺陷解决、经验证、关闭缺陷为止，在缺陷管理的整个生命周期中记录了大量数据，它们是进行缺陷分析、提高产品质量所需要的宝贵信息。度量这些缺陷的发现成本、修改效益，对缺陷管理及其改进是非常有帮助的。

1. 缺陷描述五花八门

没有统一的缺陷描述格式，对于统计缺陷分析缺陷影响很大，不利于统计结果精准统计。

2. 缺陷等级边界不明

这个问题可以分为两部分来说明：

1）测试过程给开发提缺陷。由于缺陷级别不明确，一个中等的缺陷可能会被测试认作重大缺陷，这会让开发同学十分憋屈，对测试的专业度认可大打折扣，影响测试开发关系；

2）项目上线后发现缺陷。因为负责的系统服务于公司内部使用，所以缺陷定级也不是很清晰，在线上发现缺陷时候，由于标准不明确，责任人往往会压低缺陷级别，这样的后果就是会让大家不重视测试质量。

3. 缺陷生命周期

测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。我们当时使用的缺陷管理工具是Jira，Jira支持配置BUG状态转换图，这样可以确保所有缺陷的最终态是end。

4.开发修复缺陷漫不经心

有的开发同学对于缺陷修复不积极（可能是并发任务多？），早上提的缺陷，到了晚上开发还没修复，如果是一般的缺陷不影响主流程还好，但是要是严重缺陷，这样下来一天都执行不了多少用例，所以有时候会经常搞到深夜去验证开发修复的缺陷。

5.开发修复缺陷质量低

这个问题是有些开发同学修复缺陷时候考虑不周，往往是修复缺陷后引入新缺陷，导致频繁发布，带来的后果就是测试频繁的回归，“劳民伤财”，整的测试同学身心俱疲。这个问题和问题4属于两个极端。

2.5 质量手段单一

当时刚接手这个系统，完全是一穷二白的境地，没有前人的测试积累可以参考，完全是从0到1开搞。刚接手的前半年基本是依赖手工做黑盒测试。仅靠手工测试的缺点也日益显露，随着项目的需求越做越大，回归成本日益增高，所以做的越来越心累。

3.测试成本高，用例质量低

1.开发代码质量低

因为没有自动化测试用例沉淀，刚接手项目的时候迭代较多（小步快跑，一周小迭代，两周大迭代），几乎没有时间停下来测试接口写自动化用例，完全是纯手工测试业务。而我们的项目只有两个环境，dev环境和线上环境，没有测试环境，与开发共用dev环境，所以起初dev环境的代码很不稳定，因为开发没有规范（技术方案设计质量低、代码不规范等），导致开发质量较低，缺陷密度高，回归频繁，成本较高。

2.外包不重视测试分析，测试质量低

我带的一个外包同学，测试分析几乎是把开发的技术方案copy一份，而是在编写测试用例的时候去分析功能需求。使用Excel编写测试用例，设计用例时间长，导致测试用例质量较低。

质量改进

修炼内功

1.项目流程规范化

根据项目迭代情况制定规范化的项目流程，经过半年多的项目迭代发现，可以将项目归类为3大类：

1）hotfix项目，整体时间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

质量度量

想必大家都有这样被老板灵魂发问的经历吧。

1. 当你负责的项目按时交付发布后，你老板问项目的测试质量怎么样啊？

2. 当你测试的项目上线后有用户曝出使用缺陷，你老板问你这个缺陷怎么没有测试出来呢？

如果测试工程师将测试工作理解为测试用例设计、测试执行，那么你大概率回答不好老板的提问，给不到老板想要的答案。

测试工程师作为项目质量把关者， 是产品质量保障至关重要的一环，测试设计和执行只是其职责的一部分，殊不知，测试质量度量也是测试工作尤为重要的一环。测试质量度量的范围不仅限于测试角色，也包括开发角色，甚至是产品角色。因为产品质量不是测出来的，而是产研测三方共同努力“测试”的结果。

度量是一种工具，就像一把尺子，衡量项目测试质量的好坏，哪些地方做的好，哪些地方还需要改进。

下面就分享下测试工程师如何度量软件测试质量，我将其分为三个过程：

1. 缺陷规范

2. 缺陷管理

3. 质量度量

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）验证缺陷

5）Reopen/关闭缺陷

6）统计缺陷

Step3: 质量度量

强调一点，缺陷度量不仅仅发生于测试结束后，而是伴随整个测试过程的。那么，测试质量度量指标有哪些呢？

汇总如下，可以看出我们软件测试度量范围不仅限于测试角色，还包括开发角色。

以缺陷拒绝率为例，假如测试提出84个缺陷，开发测试双方认定其中20个不属于缺陷，你可以计算出缺陷拒绝率是20/84=0.238（23.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的，那么为什么线上仍会有此缺陷呢？

和负责的测试同学沟通后，发现有以下几个情况：

1. 业务流程不熟悉

2. 第一轮测试，A场景用例通过，B场景用例发现缺陷。开发修复后，测试同学对B场景进行回归验证，因为他觉得A场景和B关联性不大，所以没做回归，但是恰恰感觉关联性不大的地方实则有一定关联，导致漏测。

3. 执行用例的同学觉得针对功能模块A设计相关的几个测试用例属于等价类，所以在执行其中一个用例通过后，其他用例完全没执行就进行了Pass标记。但是实际用例之间并不等价，导致漏测。

4. 我们测试流程是DEV环境全量用例测试，线上环境仅执行主流程用例。正由于线上回归不是全量回归，而又缺乏自动化回归能力，我们也踩了一些环境配置导致的漏测的坑。

改进建议：这个问题也侧面反应两个点，1.频繁的手工测试让人倦怠，测试同学很容易眼高手低。2.没有自动化回归，测试同学的经验如果不可靠，往往付出血的代价。

为了解决这个问题，我们小组采取交叉回归策略。例如一个迭代有A、B两个同学参与测试，在一轮测试完毕后，A\B两个测试同学相互交叉测试彼此负责的模块，这样能解决一部分测试人员因工作粗心导致的漏测。

此外，我们团队开始着手接口自动化能力的建设，重点在测试环境自动化回归。3.建立项目文档知识库，缺陷复盘存档。

3.项目初期 发现bug数量多，修复率低，上线频频延期

团队初期由于项目节奏比较快，项目组成员不是在评审，就是在评审的路上，几乎每天都有各种项目相关的会议，大家都在赶项目上，而忽略了项目过程遇到的流程不健全的问题，最大的问题就是对开发的“宽容”（现在想想，真的是对开发的宽容就是对自己的残忍），具体点就是没有要求开发冒烟测试，开发自测完事后走一遍流程就提测了，而测试过程发现缺陷比较多，而且reopen的缺陷比较多。

当然，针对缺陷比较多的问题，我们自身也进行了缺陷分析原因和归类，大致有以下几类：

1. 需求问题产生的bug，需求设计不合理，而直到测试阶段才发现问题

2. 开发实现和需求不一致产生的bug

3. 开发自测打马虎眼，对bug睁一只眼闭一只眼

4. 开发新人对产品功能不熟悉

5. 环境问题导致的bug

下面分析一下第3点，如果开发对自己开发代码多些责任心，自测质量高一些，会大大降低缺陷逃逸到测试阶段以及reopen的次数。而项目质量的提升，不能完全只靠“测”，离不开测研协作，推动开发高质量自测就显得非常重要。

而鉴于此问题的严重性，我们和开发同学沟通制定了三板斧策略：

1. 推动开发高质量自测，不管是缺陷修复还是功能开发阶段。

2. 设置项目提测门禁，冒烟测试用例100%通过方可提测。

3. 给开发打质量分，初期我们给开发打质量分的指标也比较简单，主要针对缺陷统计侧面评估开发质量，当然每个项目的开发质量分会和开发leader反映问题所在，目的在于提升开发质量。

4.测试过程发现了需求之外的缺陷，即如何处理历史缺陷？

随着业务压力越来越大，老板也给我们很对外包招聘名额，后续团队陆陆续续增加到7人，其中6个外包，当然并不是每个项目都是6个人一起上，而是将其划分了3、2、1的模式，其中3个人cover一个较大的项目，2个人cover较小的项目，1个人是自由人，主要承担线上反馈问题处理以及随时补位。较大项目一般2周发布，小项目一周一发。由于两条项目线并行的问题，这样就出现了A项目的测试同学负责的项目发现B项目测试同学负责过的版本存在遗漏的缺陷，而对这种问题，我们分情况处理：

1. 如果测试过程发现历史缺陷，产研测会将此问题抛出来，评估严重程度以及修复成本。(1).严重程度决定是否修复; (2).修复成本用于评估额外的项目成本是否对项目整体造成延期的风险。如果缺陷比较严重，修复成本比较高，则会延期修复。如果缺陷不严重，则根据开发测试意愿自己决定是否修复。

2. 如果A小组负责项目上线后，发现了B小组测试的项目版本出现缺陷，则缺陷责任人属于B小组测试人员。

5.开发过程需求经常变更

你是否也遇到过类似问题，开发实现的产品和交互设计的不一致？问了开发原因才晓得是产品单独找开发更改需求了。。。

当然并不是说 需求不能变更，需求问题在任何公司，我想都是不可避免的。因为随着系统复杂度的不断提高等原因，产品同学确实不太容易考虑完全。

该问题也比较常见，对项目的影响：

1. 提测前需求变更，导致开发过程不流畅，且会存在设计变更的风险，缩短开发时间，影响开发进度及项目质量。

2. 提测后需求变更，影响开发新版本的流程及开发修复bug时间，影响QA的测试进度。且需求变更容易引出新的问题致使项目质量不可控。

需求变更直接影响是，增加项目不确定性风险。

解决方案：

针对需求问题，我们通过以下措施去推动解决：

1. 硬性要求，需求变更必须通知到研测，三方共同拍板，并重新评估项目排期。

2. 测试角度，产品同学提前发需求文档，鼓励测试同学在需求评审的过程参与需求测试，多思考异常场景。

3. 产品角度，避免需求文档中出现不确定、同上等模糊不清的说辞。如变更需求，PRD应及时更新要有变更记录，避免口头变更。

4. 开发角度，避免盲从产品变更需求，应三方确认后，重新更新技术方案，如有必要可以重新技术评审。如未告知测试进行需求变更，测试有理由拒绝测试。

6.线上故障应急效率低以及改进策略

第一阶段：刚接手项目后，就被拉进了很多飞书应急群。要说整个项目过程什么时候是最紧张的，那肯定是项目上线后的第2天早上，因为新需求上线后，可能会有未知的缺陷暴露，所以规定发布后的第2天一大早就要去公司候着，以随时应对线上反馈的问题。对这是团队最早的应急方式-应急群被动接线上问题，完全属于人肉应急。

除了应急效率低的问题，还经常报一些非代码缺陷的情况，例如网络原因导致的响应延迟问题、用户对新需求不熟悉的问题。当时我们也采取了一些手段来提升应急效率，针对用户对需求不熟悉的问题，让产品同学及时和CQC同学沟通新需求内容；和一线的用户沟通，最好在多个用户能同时复现再反馈到应急群。此外，针对网络等因素的问题，我们还给用户培训如何辨别问题的原因，例如利用Chrome的开发者工具查看接口报错等。再者就是建立缺陷知识库，给缺陷归类并标记tag，让一线用户可以自助找解决方案。

第二阶段：这阶段半自动应急阶段，何为半自动？其实就是给问题自动分配应急人，并通过机器人自动化记录问题，用于每个月的项目质量打分，可以理解为问题自动化存档。

第三阶段：接入字节跳动兄弟团队研发的应急机器人，可以基于知识库给用户自动化推荐相似问题的解法。可以有效排除一些反馈的无效问题，节省应急人的时间。

7.开发只改了一点点，为什么测试需要耗费那么多时间？关于测试开发时间的合理性评估

也许你也遇到过经常被开发/产品挑战“只改了一点点，为什么测试需要耗费那么多时间啊？”

这个问题在我经历过的几家公司都被开发产品挑战过。这个问题的本质是测试依赖手工测试的局限性。没有完备的自动化回归能力，缺乏有效的精准测试能力，仅人肉回归必定增加无效的测试。也属于测试有效性需要解决的问题。

下面说下我们测试组对测试开发时间比的“争论”以及最终的“妥协”。

第一阶段：没有什么测试开发时间比，因为当时项目多，测试人员少，往往一个测试全包全揽，所以测试时间根据功能测试范围由测试评估，当然测试时间的长短由测试经验评估的测试范围准确性决定。而缺乏有效的评估工具和精准测试工具，有时候经验也不准备，所以有时候项目比较赶有时候比较松。接着我们想到根据用例数评估测试时间，就按每天200个测试用例的执行数，评估一轮测试时间，再加+1人日回归时间，这样作为测试工时。例如600个测试用例一轮测试3人日，加1人日回归，总共4人日测试时间。

第二阶段：后来随着项目的任务量减小，经过高强度项目长时间的浴血奋战，老板发现测试同学手工测试略显疲态，为了缓解这种长时间手工带来的问题，和开发老板一起沟通决定测试开发时间比按1:3排期。这样不管项目大小，其实都给测试留出了一些自主时间可以用于技术提升。

第三阶段：建立接口自动化能力，将业务按主流程划分，全部实现接口自动化覆盖，提升测试效率，可以更快速的测试。

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取 【保证100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!