年终总结 | 2021 年终总结及规划

个人全局的工作总结分析和以后的工作规划

Posted by Haauleon on January 13, 2022

  此次 2021 年度总结报告邀请到了项目经理、产品经理、UI 同事、前端同事和后端同事,借多个不同岗位同事之手共同探讨关于协助方面的事宜和工作中要注意的点,主动去接纳他们的工作建议。其实也带有一点私心吧,如果将来作为一个管理者,而站在管理层面,如何跟其他协作部门共同去完成一个项目?这个问题同样也值得我去跟大家共同探讨。我们不能只是做一个唯技术论者,生活在这个复杂多样化的人际社会中,眼界和格局很重要。

  此次总结会议分为五大块来进行,分别是:总结复盘、数据分析、工作规划、问题剖析和提问环节。首先,总结复盘是对 2021 年度工作产出的总结和复盘,数据分析是对 2020 和 2021 年度工作的变化分析,工作规划则是对 2022 年工作中要规划进去的大概事项,问题剖析提供了对以后工作中问题的剖析方法和方案,提问环节是针对受邀同事进行的。对此,总结了以下内容。



前言

  转眼间,2021年已经过去了。
  回首过去,在这一年里,接受了很多不同的测试类型、测试难度的工作,加上随之而来的新的工作任务,种种因素都对我的工作发起了新的挑战。与此同时,我见识了很多新的东西,这是工作技能提升最快的一年,更是最浮躁的一年,同时也是我收获颇丰的一年。
  站在2022年的起点,继承和发扬过去工作中存在的优点,汲取经验,摒弃不足,满怀信心,以更清醒的头脑、更旺盛的斗志向新的目标进发!



一、总结复盘

1、年度版本提测数据汇总

2021年度提测项目/任务数 ≈ 22 次


2、年度重大故障回顾

故障:一村一品小程序在用户已登录成功的条件下,出现再次授权,授权登录后用户个人页面的资料数据互窜,部分用户的个人页显示的是其他用户的信息。

影响:该故障导致部分用户无法正常使用课程打卡功能,同时由于个人页显示其他用户信息导致数据隐私安全问题。

分析:前期内部测试时,用户数据量不够,有偶现情况但无法复现,导致问题迟迟得不到正确的解决。

解决:微信 code 过期后获取 openId 有异常,更新 redisSession 。


3、年度测试输出文档

2021年度测试输出文档数 ≈ 29 份

华新项目使用手册
鲲鹏认证劳务系统测试用例文档
鲲鹏认证劳务系统性能测试文档
鲲鹏认证劳务系统兼容性测试文档
鲲鹏认证劳务系统兼容性认证报告 山西线上金融教育基地系统测试计划
山西线上金融教育基地用户操作手册
山西线上金融教育基地系统测试报告 一村一品迭代功能测试报告
一村一品系统用户操作手册 珠海丰收节项目系统测试计划
珠海丰收节项目系统测试报告 信宜供应链金融系统测试计划 信宜跨境电商通关系统测试计划
信宜跨境电商通关系统测试用例
信宜跨境电商通关系统测试报告 信宜跨境数据大屏展示系统测试计划
信宜跨境数据大屏展示系统测试用例
信宜跨境数据大屏展示系统测试报告 信宜跨境学堂教育培训系统测试计划
信宜跨境学堂教育培训系统测试用例
信宜跨境学堂教育培训系统测试报告 信宜跨境B2B、B2C交易平台系统测试计划
信宜跨境B2B、B2C交易平台系统测试用例
信宜跨境B2B、B2C交易平台系统测试报告 信宜综合服务门户系统测试计划
信宜综合服务门户系统测试用例
信宜综合服务门户系统测试报告


4、年度培训分享

2021年度培训分享数 ≈ 2 次

山西金融教育基地的线上培训会议
boss、saas 财务相关业务操作流程培训



二、数据分析

统计项 2020 2021
测试设计 功能测试的设计方面常使用单运行异常值和多运行顺序执行法,基本满足用例设计需求,测试策略方面偏向功能性分析。 在测试基础上,完善需求分析的产品总体测试目标,在测试分析和设计上完善阶段测试策略,同时在测试执行方面增加测试数据和测试脚本。
API 自动化测试 纯 python 代码实现,消化 github 各路大神的项目代码后得以驾驭。耗时长且单人维护压力大。 工具结合代码实现,工具仅提供简单的代码生成功能且伴有部分奇怪的bug,用于维护已足够。
可靠性测试 postman 结合 jmeter 完成,但对测试机资源要求高,使用 jmeter 进行稳定性测试和恢复测试时总是伴有内存消耗太大然后卡死的情况,用不动。 使用 es6 结合 postman 和 k6 完成,在鲲鹏认证性能测试足以体现,在使用持续一整天的突变形态负载进行恢复测试时依然表现良好,无异常。
测试脚本 仅用于辅助进行后期的稳定性 API 测试,不太能写工具。 继承前同事的爬虫项目后,在写工具/脚本添加测试数据、辅助测试执行、测试文档、数据批量上传等等方面均有提升。
如何决定发版? 测试环境的测试用例/用户场景测试完成后禅道无严重 bug,由测试人员决定发版上线。 负责相关功能的测试人员设计可靠性测试场景,组织对业务有一定认知的交叉测试者功能进行交叉测试,完成可用性测试后增加上线信心。



三、工作规划

1、概要工作的落实事项

测试流程优化:依然需要根据业务选取有效的交叉测试者共同完成交叉测试,上线后自动负载测试。

测试策略优化:增强产品的商业目标分析,制定符合商业目标的测试策略,增加产品的用户类型分析,完善多运行顺序执行设计场景。

技术设计更新:依旧需要摆脱单人维护压力大的测试技术,继续发掘和接纳更多简单好用好维护的测试工具和测试技术。

标准规范更新:不同测试阶段的测试策略。


2、测试团队梯队建设和能力建设

(1) 团队能力模型
已有能力沉淀:测试技能
缺失能力建设:测试管理

(2) 团队能力培养
业务培训:saas/boss
技能增强:可靠性测试
能力培养:测试管理能力

(3) 团队日常建设
增加缺陷跟踪、质量跟踪
增加测试团队内的技术分享会



四、问题剖析

重要问题剖析及解决方案:个人亦需进行项目复盘,包括但不限于统计问题影响范围、问题分析和避免方法。

测试工作如何更好的闭环:测试策略的制定很重要,也是成为测试管理者的重要技能之一。

眼界和格局:学历、能力、技能、经验等只是铺垫,眼界和格局决定自己能否从容。

待定:待定 ……



五、提问环节

  提问环节邀请到了项目经理、产品经理、UI 同事、前端同事和后端同事,在协同方面提出了大家提出了以下建议。

  UI 同事。建议能在 UI 测试方面跟测试同事共同研讨和进步。

  后端同事。禅道问题单的提交,除非问题比较单一可省略非必要的描述,复杂业务流的问题单需要描述每一步的详细操作和截图。

  前端同事。前端项目例如像 CMS 内容管理系统,通常很多模块的页面和功能是一致的,因此在提交问题单方面可以优化成:若多个模块的问题是一样的,那么只需要提交一个问题单,然后在此问题单中描述出现此问题的所有相关页面的 url 路径即可。

  产品经理。希望在测试同事在测试分析的时候可以先从大的业务流开始思考整体的项目流程。
  测试同事。希望后端同事的接口文档能够备注接口每一个字段的释义、参数类型、参数值可选项。