测试开发的一次实践总结

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

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

—

测试开发的理解

测试分类

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

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

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

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

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

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

测试开发分类

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

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

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

测试开发的本质

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

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

—

测试和开发、产品的关系

—

测试开发需要具备的技能

业务理解能力

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

测试能力

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

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

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

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

排查问题的能力

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

测试提效能力

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

安全生产的意识

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

善于搜索的能力

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

主人翁意识

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

—

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

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

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

—

测试需要具备的软技能

沟通能力

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

细心、耐心

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

细心、耐心

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

快速学习

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

责任心

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

团队协助

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

文档编写

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

—

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

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

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

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

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

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

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

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

4. 提测申请与冒烟测试(提测预演)【视需求大小而定】

ps正常来说是开发人员组织如果他们忽略掉测试人员可根据实际情况要求进行提测申请并进行冒烟保障提测质量。

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

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

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

云效缺陷处理规范 :

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

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

测试人员提前预定会议室发会议邀约给相关人员
会议记录预演过程中要记录会议摘要哪些bug需要修复后上线哪些bug后期再迭代(PD+业务评估)

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

8. 正式发布

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

9. 线上验证

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