测试开发的一次实践总结

这些年，测开越来越火，火的原因之一就是因为大部分公司都有设测开岗位并有招聘需求。那测试开发到底是做什么，和测试又有什么区别呢？接下来，说说我对测开的理解与实际工作的总结。

01

—

测试开发的理解

• 测试分类
  从市场招聘来看，测试主要分成两大类：

业务测试：业务测试是对当前从事的业务知识非常熟悉，能够挖掘产品的隐式需求，对业务需求非常了解并有自己独特的理解，能够覆盖更多的测试场景，后期是可以往产品发展的。也是大家口中俗称的点点点，属于功能测试，也是最不容易被工具替代的。

技术测试：技术测试就是我们平时接触非常之多的自动化测试(功能+接口)、性能测试、安全测试、渗透测试、大数据测试、白盒测试等等。这些代名词其实就是测开，只是以不同形式存在，如果广而全，那就更接近全栈。

• 测试开发与开发，测试的区别

测试开发岗位到底要做什么？测试开发和测试有什么区别？测试开发是开发吗？测试开发的价值在哪里？很多人认为测试开发=测试，也有人认为测试开发=自动化测试，还有人认为测试开发=测试工具、测试平台的开发。其实，这些都不是准确的。

1. 首先，可以从招聘岗位的名称来区别，先明确一下简称，由于这几个岗位名字看着比较像，很多人都不知道这三者的区别与联系，软件开发工程师(SWE )，测试开发工程师(SWT)，测试工程师(TE)。
2. 其次，从大致三个方面能力上来看区别，我的理解是：从代码能力要求上，软件开发工程师>测试开发工程师>测试工程师；从掌握知识广度要求上，测试开发工程师>软件开发工程师>测试工程师，从工作沟通能力要求上，测试开发工程师>测试工程师>软件开发工程师。
3. 再次，从进阶路线来看，手工测试<自动化测试工程师<性能、安全性能测试工程师<资深白盒测试工程师<测试架构师，看到这里，很多人就迷惑了，为啥没有测试开发，其实，手工测试到测试架构师中间的每个过程的递进，都是测试开发在不同专项领域的一种表现形式。简单来说，测试开发除了代码能力外，在自动化、性能、安全、大数据测试等每个专项领域都是需要的，只不过每一个专项都可以成为一个大的分支。而测试架构师，就倾向全栈。

• 测试开发分类

一类是
基于业务驱动型的测试开发。可以理解为业务测试工程师，只是具备了开发能力和质量改进思维，这类测开人员需要扎进业务中，主动挖掘业务过程中各个环节质量的薄弱点并且想办法去解决，通过流程改进、开发出得心应手的工具，让自己的测试工作能够持续高效。

一类是
基于框架平台型的测试开发。这类型的测试开发，需要站在更高的纬度来看待产品的质量，他们会对整个研发过程或者某个大的专项去开发一些测试平台、框架，并且将这些能力以服务的形态提供给各个业务线使用，以此来保障全局内建质量。

不管是哪一类，测试开发岗位的核心仍然是“测试”，测试始终是保障质量的手段，而测试开发是具备开发能力并以此来辅助测试，发的目的是为了更好的服务测试，测开应该看重的是对测试的理解，以及在这个基础上设计、能开发设计帮助测试人员或者开发、运维人员提高效率并解决实际业务问题的工具。

• 测试开发的本质

我们公司的测试开发就是基于业务驱动型的，作为一名业务驱动型的测试开发工程师，其实工作中主要还是围绕着业务展开，我们所做的一切测试、开发的工作也都是为了测试提效，为了业务的质量保障。

其实我认为测试开发的本质应该是“懂开发的测试”，是为了更好的服务产品的“质量”。由于对于目前测试的工作要求，已经不是传统的测试岗位所能胜任的了，我们除了简单的操作层面的“测试”工作，还需要考虑到从测试设计到数据准备到风险控制以及研发效率提升等各个方面，我们需要将我们的工作上升到价值层面的“质量保障”，所以测试工作只是测试阶段的质量保障手段之一，我们要做的是从产品的需求评审到交付上线整个周期的质量保证，除此之外我们还需要从效能提升、安全生产等各个方面来评估我们的工作质量。大家可能会陷入一个怪圈，作为一名业务型测试开发，其主要工作是放在业务的质量保障上，但是每到制定OKR、谈到绩效、价值等方面时，却又主要用横向的指标来作为测试人员价值的体现，我不理解为什么是这样，直到我看到一篇文章《业务型测试的职业发展和晋升路径思考》，我才发现原来这是所有业务型测试在公司所面临的的一个挑战。

02

—

测试和开发、产品的关系

在平时工作中，我们接触到最多的角色就是开发和产品，那这三者的关系是如何？从一个产品交付流水线来看，可能有的人会简单地认为，产品、开发、测试是一个线性关系，产品评审完需求之后，开发进入开发过程，完成开发工作之后，测试开始进行测试，最后完成整个需求的上线。但是实际上，这三者之间其实是一个三角关系，产品在需求评审阶段、开发在技术评审阶段、测试在TC评审阶段都需要这三者在场，站在自己的角色视角提出相关建议，更高质量地交付产品上线。

03

—

测试开发需要具备的技能

• 业务理解能力

不管是业务测试，还是技术测试，都不能脱离业务，所以一开始进到一个组之后，首先要熟悉的就是业务，业务测试也是在我们工作中占了大比重的，所以我们需要花日积月累的时间来锻炼自己的业务理解能力。

• 测试能力

测试能力的话，我想先从测试的基本职责来讲，测试在执行质量相关的实践活动，其最基本的五个职责应该是：

1. 理解和澄清业务需求
2. 制定策略并设计测试
3. 实现和执行测试
4. 缺陷管理与分析
5. 质量反馈与风险识别

明白职责后，就是实践的能力，大致可以分成这四种：

1. 1. 代码能力：1. 工具开发能力2. 平台开发能力2. 业务测试：1. 功能测试3. 专项测试：1. 自动化测试(ui+api)2. 性能测试3. 安全测试4. 渗透测试5. 大数据测试4. 运维能力：1. linux服务器相关专业知识2. 环境部署能力3. shell脚本编写能力

• 排查问题的能力

当我们发现bug之后，其实第一个要做的就是快速定位问题的原因，这也可以帮助开发更快的定位和解决问题，后面说的测试过程中需要做到什么程度，也讲了排查问题的能力的级别。比如，在发现一个bug后，可以先判断是前端还是后端还是数据还是环境问题，通过接口返回、日志排查、代码查看权限、具体定位到代码debug等各种方式进行问题的定位。

• 测试提效能力

除了手工测试，我们还需要利用自动化的方式提高测试效率，我们可以写一些自动化的脚本来减少测试带来的重复性工作，也可以研发效能平台来为质量保障作为基建支撑，效能工具就像是一把剑，可以带着我们大大提升工作的效率。

• 安全生产的意识

如果把效能平台比做是一把剑，安全生产我觉得就像是一个盾，我们可以通过监控、故障演练、预案、快恢等各种方式来进行我们的业务质量保障工作，保证整个产品不出问题，或者出了问题能够风险最小化。

• 善于搜索的能力

公司内部的知识库如：语雀、钉钉文档，外面的如：GitHub、CSDN、CNBLOGS、知乎等等都给了我们很多可以学习的空间，但是由于知识的庞杂，我们还需要有善于搜索和发现适合自己的知识和工具的能力。

• 主人翁意识

对于自己负责的工作要具备owner意识，其实这需要很强烈的责任心和积极主动的精神，比如作为一个项目owner，需要有把控全局的能力，还要有懂得如何划分和安排任务的能力，还有协调沟通的能力，还要有推动项目进展的能力，还要有预期和拿结果的能力，虽说有点难，但是我觉得这是作为一个测试人也需要锻炼的能力。

04

—

在测试过程中需要做到什么程度

• 级别1：发现问题，提出bug让开发去定位产生问题的原因；
• 级别2：定位问题，知道出现问题的原因是什么，这个需要去查数据库、日志甚至代码来定位问题。在提bug的时候，给开发一些可能的建议，帮助开发定位到问题，这本身是测试价值的一种体现。
• 级别3：解决问题，如果测试能够解决问题，那就没开发什么事了，或者说能够更好的去协助开发去解决bug。
• 级别4：预防问题，解决问题后需要有能够预防此类问题产生的策略，更好的进行质量保障

其实在工作过程中，我们经常是处于级别1和级别2的一个状态，不过定位问题也是考验技术和对系统的熟悉程度的，如果能精准定位到问题原因所在，也能减少开发排查问题的工作量。

05

—

测试需要具备的软技能

• 沟通能力

测试需要和大量的人打交道，需要很强的沟通能力，如果讲不清楚，那么工作就无法进行，而交流过程中，我们首先要组织好语言和逻辑，其次是要客观的反馈事情的真相。如果有点社恐的人来说其实一直是一个比较有挑战性且有趣的工作，其实一个好的人际交往的能力对工作效率也会有很大的提升。

• 细心、耐心

测试是辅助研发定位错误，帮助研发快速完成开发工作，所以我们需要非常细心去发现一些细小的错误。对于有的测试过程可能是反复枯燥的，这个需要很大的耐心。尤其是业务型测试，我们经常同样的操作步骤需要重复很多次，这也是为什么大家想用自动化来解放双手。

• 细心、耐心

遇到问题，测试需要快速分析定位问题，并且能够复现，理清楚逻辑给到研发，尽量减少研发定位bug和反复修改的工作，这其实意味着我们需要对产品有着非常强的熟悉程度，这样才能更快速精准的定位问题所在。

• 快速学习

测试学的东西比较广泛，需要掌握的知识和技能也非常多，所以拥有快速学习的能力是至关重要的，否则就很容易被淘汰，不过好在公司有很多的知识库以及技术味浓的培训与分享，这其实对于一个新人来说，是一个很好的学习机会，不过有时候东西太多，也要慧眼斟酌一下。

• 责任心

测试的工作是要保证产品上线的质量，所以需要很强的责任心，这个我觉得每个岗位的工作者都需要有这样的素质，就不用多说了。

• 团队协助

测试工作会与各个人员打交道，在做好本职工作的同时，应该积极并且有意识的关注项目的进度和组内情况，要有大局观，团队利益至上，要愿意共享个人经验，同时也善于从同事那里进行学习，团队协作能力也是测试需要具备的基本素养。

• 文档编写

优秀的文档沉淀可以给自己也给后人带来福利，好记性不如烂笔头(是我记性不好)，有时候以文字的方式记录下来可以提醒到自己，也可以锻炼自己的总结能力，当别人有需要的时候也可以分享给别人，真是一举三得呀～

06

—

测试工作流程及关注点有哪些

首先我们应该在需求评审阶段就需进行介入，称之为：测试左移。并且在每个工作阶段，测试都需要有相应的关注点和输入输出，接下来来看一下测试工作流程和每个阶段测试需要做的事情吧

1. 需求评审阶段【关注】

• 测试人员需要进行需求分析，熟悉技术实现方案、设计是否涵盖了业务需求、存在的风险，为测试分析和测试用例设计提供输入。
• 主要关注点：架构合理性、风险评估、测试策略(手工测试or自动化测试or其它)。
• 根据需求大小判断是否测试人员测试还是开发自测(可根据情况判断是否提供冒烟测试用例)。

1. 设计测试用例【重点关注】

• 根据prd编写测试用例、冒烟测试。
• 编写冒烟测试用例(看项目大小而定，如果项目改造比较大，或者是新项目，建议编写，用例评审时提供给相关开发人员，冒烟测试用例通过后，正式提测)。
• 项目中测试同学需要给研发同学提供冒烟测试用例，且和前端同学达成一致，冒烟测试用例要求总用例的10%。

1. 测试用例评审【视需求大小而定】

• 时间在原定提测时间前1-2天，根据项目大小和时间决定是否需要该环节。
• 输出：用例评审会议纪要、修改版测试用例、冒烟测试用例(给开发)。

1. 提测申请与冒烟测试(提测预演)【视需求大小而定】
   ps：正常来说是开发人员组织，如果他们忽略掉，测试人员可根据实际情况，要求进行提测申请并进行冒烟，保障提测质量。

• 规范：按照测试用例评审的冒烟测试用例由开发进行预演，若冒烟测试用例均通过，则测试接受测试，否则打回并发邮件说明冒烟测试不通过并预计下次提测时间
• 输出：冒烟测试结果邮件(通过与否都需要发邮件，并给出预计发布时间点、风险)
• 提测后第一时间投入测试，若预演未通过，要告知风险

1. 测试阶段【重点关注】

• 测试阶段需要提前准备好测试环境、测试用例、测试数据等；
• 测试过程中需要及时提交缺陷、跟进缺陷，bug一般采用云效进行管理，缺陷格式最好采用：【需求名称】具体缺陷名称，便于后续搜索和归类；
• 业务相关咨询：PD+业务 ；产品样式相关咨询：产品+UED ；开发相关咨询：前端+后端；

云效缺陷处理规范 :

1.缺陷修复后，开发同学需要fixed bug(研发)
2.缺陷修复后，需进行对应的缺陷修复验证。(测试同学)
3.缺陷验证通过，closed关闭缺陷前需对该缺陷对应的缺陷类型及缺陷原因进行归类。(测试同学)
4.缺陷验证不通过，可将该缺陷reopen后继续提交开发处理。(测试同学)

1. 发布预演【功能验收(可多轮)】

• 测试人员提前预定会议室，发会议邀约给相关人员

• 会议记录：预演过程中，要记录会议摘要，哪些bug需要修复后上线，哪些bug后期再迭代(PD+业务评估)

• 发布计划的编写人员主要是开发和测试；

• 目的：编写测试计划，测试人员明确本次测试的重点和回归重点，开发人员明确发布应用和发布顺利，避免漏发、发布顺序搞错等原因造成线上bug，从而代码回退。

1. 正式发布

• 跟踪发布情况，可要求开发在群里同步发布节奏，发布完成后，第一时间线上验证(发布后，@PD+业务，他们可同时进行线上验收)；
• 不同的业务可能有不同的发布窗口期，需要注意是否在发布窗口期，否则可能需要紧急审批；
• 由于很多线上问题都是由于变更导致的，所以再发布的时候格外注意是否有漏发的情况出现；
• 一般发布过程中有灰度观察期，这个期间可观察线上流量是否有异常出现。

1. 线上验证

• 相关人员需要及时验证线上结果，一般测试进行验证，如果由于业务特点测试无法验证则需要业务同学及时线上验证，比如，我之前的业务都是测试进行线上回归，现在的业务特点由于数据安全等问题，则需要业务自己进行验证。
• 我把它划分了主要包括需求梳理、测试准备、测试过程、测试总结四个部分，每个阶段的输出都可以以文档的方式沉淀下来，可作为后续验收和回归的一个参考。​

以上是我对测试开发以及工作实践的一些理解，看到这篇文章的人有觉得我的理解有误的地方，也欢迎评论和探讨～