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

持续坚持原创输出，点击蓝字关注我吧

软件质量保障 ：所寫即所思｜一个阿里质量人对测试的所感所悟。

引言

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

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

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

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

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

项目现状

1.接手“烂摊子”

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

系统比较陈旧僵尸代码多。和同事沟通得知，这个X系统其实是5年前的老项目了（Apache+PHP+MySQL+Redis架构），赶上最近公司扩展新业务才重新拿出来用，所以这个系统之前是没人测试的。
开发不熟悉系统代码。开发同学赶鸭子上架，边熟悉代码边开发新代码的。改动一行代码到底影响有多大开发无法评估，导致测试验证缺陷修复的策略往往回归全量用例。3. 系统前后端不分离，前后端开发同学在同一套代码上进行开发，部署都要等到前后端同时ready才可以，总之非常麻烦。
硬编码的地方比较多。修改配置都要重新发布项目。
缺失接口文档。

2.质量保障策略

2.1 开发比悬殊

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

2.2 项目流程不规范

技术方案频繁更改，开发不写单测，没有冒烟测试，项目发布不规范等****重点说下项目发布不规范，可以概括为： 1.“准出”规则不规范。针对准出规则，我想大家肯定是熟悉的，即只有达到发布标准，才允许项目发布。 2.发布时间不规范。为了保证多个项目的排期，都会规定固定的某天周X为发布日，一般选择周四，这样可以在周五观察一天，看是否有线上缺陷，这样在周五还来得及修复。

2.3 测试文档没标准

测试用例测试小组里每个测试同学基本上按照自己的习惯写测试用例，所以测试用例要素不尽统一，再加上当时测试用例的载体为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: 质量度量****强调一点，缺陷度量不仅仅发生于测试结束后，而是伴随整个测试过程的。那么，测试质量度量指标有哪些呢？ 汇总如下，可以看出我们软件测试度量范围不仅限于测试角色，还包括开发角色。

指标名称	定义	度量范围
测试执行率	（实际执行的测试用例数/测试用例总数）*100%	测试进度
测试通过率	（执行通过的测试用例数/测试用例总数）*100%	开发质量
需求（测试用例）覆盖率	（已设计测试用例的需求数/需求总数）*100%	测试设计质量
需求通过率	（已测试通过的需求数/需求总数）*100%	进度
测试用例命中率	（缺陷总数/测试用例数）*100%	测试用例质量
二次故障率	（Reopen的缺陷/缺陷总数）*100%	开发质量
NG率	（验证不通过的缺陷/缺陷总数）*100%	开发质量
缺陷有效率	（有效的缺陷/缺陷总数）*100%	测试
缺陷修复率	（已解决的缺陷/缺陷总数）*100%	开发
缺陷生存周期	缺陷从提交到关闭的平均时间	开发、测试
缺陷修复的平均时长	缺陷从提交到修复的平均时间	开发
缺陷关闭的平均时长	缺陷从修复到关闭的平均时间	测试
缺陷探测率	（测试发现的缺陷数/（测试发现的缺陷+客户发现的缺陷））*100%	测试质量
缺陷拒绝率	（缺陷拒绝修复数/缺陷总数）*100%	测试质量
缺陷逃逸率	（线上缺陷/（提交缺陷数量+线上缺陷））*100%	测试质量

以缺陷拒绝率为例 ，假如测试提出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排期。这样不管项目大小，其实都给测试留出了一些自主时间可以用于技术提升。 第三阶段：建立接口自动化能力，将业务按主流程划分，全部实现接口自动化覆盖，提升测试效率，可以更快速的测试。 - END -