谈谈我的第三次测试经历及总结

从17年到22年，中间经历过两家公司，第一家也就一年的样子，更多的成长以及感触还是第二家，之前一直拖着没写，这次总结下。

从零开始阶段

适应期

我是作为项目第一个专业的测试进入的，虽然有一个前端开发转的测试，这时候项目开发团队也就十来个人，项目也是初始孵化，仅小范围的试运行。
快速熟悉项目后，就准备上手了，虽然需求变动频繁，也额外有其他项目的测试需求，好在业务逻辑也简单，测试设计仿佛也变得没那么重要。

这个时期主要的思考是：

1. 如何快速的融入团队，熟悉业务？
2. 没有相关的规范下，思考如何开展测试活动？
3. 没有相关的文档下，手动摸索业务功能及逻辑流转。

规范尝试期

初步完成几版需求过后，针对目前的一些团队问题，就开始准备一些规范避免，包括测试计划、测试用例、测试上线报告等等，但大部分还是以效率为准，也是老大要求的。
测试执行阶段，有问题扯着嗓子吼一声，bug找的快改得也快，大概是开发不愿被二次提名吧，毕竟大家工位就两三排，心知肚明。

这个时期会面临一些问题：

1. Bug逃逸率较大，也就是质量不高。
2. 没有沉淀相关的文档，问题的溯源毕竟麻烦。
3. 技术基础建设薄弱，技术价值体现单一。
4. 临时需求交互，大家回切换精力较大。

零到一阶段

 项目变动期

大概过了3个月，上层决定把项目迁至杭州作为独立产品运营，于是伴随着项目人员变动，第一批过去了部分开发，导致测试沟通成本加大。

杭州初建的团队也开始融入，包括新技术leader、新的测试及开发人员，带来新的规范开始融合，比如重要的测试报告。我是第二批过去的，这时杭州团队已经出具雏形。

这个时期的主要工作：

1. 项目调动带来的思考
2. 测试规范学习期，主要是来自新技术Leader的建议
3. 新入职测试人员的任务安排与分配

产品基础建设尝试期

在我没去杭州时，已经跟杭州的团队交流协作过了，来到杭州后，测试活动也照常进行，仅是大部分陌生的脸。这时主要是基础架构升级，从之前的php开发转为java开发，于是新的测试需求出现了，系统剥离与重构，此外产品也迎来了2.0时刻，虽然产品设计依旧在蒙头乱撞。

最主要的感受就加班的日子越来越多了，但是当时氛围很好，并不觉得累。而且作为公司老人，自然而然担负起了测试组长的角色。

这个时期的主要工作：

1. 业务测试的比重占80%。
2. 测试团队的扩招，准备相关的面试资料。
3. 新人的带领培训，包括考核的制定。
4. 测试团队的磨合，讨论并整合相关测试规范。
5. 技术部leader的指导，落地行业内相关的解决方案，比如静态代码检查、线上问题收集工具等。
6. 跨部门的协作，相关会议明显增多，产品及需求越来越复杂。

开始积极团队建设，相关的建设如下：

产品基础建设变动期

 就这样大概忙碌到年底的时候，部门leader决定后端团队由java转为go开发，其中有很多原因：一是java后端没有好的架构师角色，欠下很多技术债；二是本身技术栈也是go，也考虑到未来的行业规划等等，不过java整体还没稳定，又提出转型，这注定是个痛苦且艰难的过程。

而我们质量团队也得为这个决定付出巨大的努力，一直持续到第二年年底，整个java后端才逐渐更替完成，而原有java服务改造工作还没开始，庆幸是我们的大前端团队比较稳也很给力，不然质量团队真的入不敷出了。

这个时期的主要问题：

1. 测试业务的比重占70%，虽然大Leader总是强调作为TeamLender不要陷于具体的业务。
2. 后端语言的更换导致的人员变动，需求断层。
3. 团队氛围比较低迷，工作感受很累。
4. 测试的基础建设实施基本没有增长。

 团队建设缓慢，如下：

产品基础建设稳定期

在后端go语言替换java接近尾声时，也是我来杭州的第三年，这时，团队成员也趋近稳定了，产品的业务方向也比较明确了，部门协作规范也清晰了，大家都鼓劲一起冲，团队建设也有比较明显的提升，测试团队被定位为效能提升角色，年度目标是技术能力对标杭州第二梯队公司，而我们测试组也开始提升整体实力，包括组内知识库的沉淀，组织组内python学习，也包括接口自动化与UI自动化的推动。

后面经过双十一的事故，性能的基础建设也提上了日程，不过由于很多原因，3年的职业生涯也到此结束。

这个时期的主要成果：

1. 测试规范更清晰更明确
2. 测试知识库的沉淀
3. 测试人员的开发能力提升
4. 专项测试的落地
5. 效能思想的转变，并产出了多个效能提升项目

团队建设稍有起步，如下：

------------------------------------------------------------ 三年总结 ------------------------------------------------------------

再总结之前，我们先提一个问题：面对软件日益复杂的情况下，如何能更好的保障质量？

你可能会说：测试左移？测试右移？TDD？回归测试？自动化测试？敏捷测试？混沌测试？AI测试？

相信大家很熟悉这些词，这些手段或者过程也或多或少经历过，虽然看起来简单，但每块展开来就东西多了。按照目前的经历，要知道公司发展的每个阶段都会有对应阶段的问题，有能解决的，也有解决不了的，能解决的问题也不一定当下会解决。

还记得临走前与领导吃饭，他提了一个关键词优先级：效率>质量>体验。他还说最看重一个人解决问题的能力，是啊！解决问题的能力细化下来太多太多了。

啰嗦了这么多，我给到的回答包括三部分：

• 一是测试的全流程建设，从提出需求到被实现，到最后运营的每个阶段都要做质量保障的手段，这可以根据公司与业务的实际情况做调整，大厂的质量体系、保障大盘看看就好。
• 二是定位好团队角色，是效能提升还是质量保证为主，我知道基本大部分的测试资源都很紧张，或者说整个技术团队的资源都比较紧张，但业务方就是要快。这时就是效率>质量，就要分析测试重心，找到质量的平衡点，减少不必要工作；如果是质量>效率，就要尝试各种手段，围绕如何找到更多的问题，多做一些探索性的工作。
• 三是要深入业务，这是老生常谈的问题，也是最容易忽视的问题，一句话做技术是为业务服务的，业务做不好，一切都不免谈。

这是我多年工作来的感受，也欢迎大家拍砖，也许后面会有新的认识，坚守测试，一起为测试行业的发展努力吧。

很喜欢下面一句话：

软件测试的真正价值并不体现在从代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限，思路中的狭隘和技能方面的不足。——快排算法托尼·霍尔