软件测试质量保证进阶之路

一说起质量保证，一般情况下，第一时间被cue到的肯定是测试同学，然后紧接着就会有很多质量相关的问题抛来。比如项目时间很紧，卡时间点上线，质量能有效保证吗？能不能做一些自动化测试来提升测试效率？能不能快点测完上线？……等等。对于产品经理来说，最好是开发同学完成开发提测后，分分钟就能上线。我想这是测试开发岗位衍生的重要催化剂吧，当然这也是所有测试同学梦寐以求的事情！

这次主要分享下工作中遇到类似问题的感悟，抛砖引玉。

01 测试时间不够时的质量保证

作为测试同学，我们经常会遇到：哎，这次测试时间又不够了，咋办呢？心里默默地念了几遍，跟好朋友吐槽下，抱怨这个，埋怨那个，然后再无可奈何地加班来搞定测试任务。

但其实我们可以捋一下我们抱怨的事情，捋顺，然后一一解决掉。只是我们在抱怨的当时没有意识到：这些抱怨其实都是可以解决，让工作变得愉悦。在尝试解决或改进这个问题之前，不妨先来看看经常会遇到的时间不够的表现：

• 项目赶进度，留给测试的时间根本不够；

• 没有按时提测，根本来不及测；

• 突然加了需求，测试是最后被告知，导致根本没有预估这部分内容的工作量；

• 提交测试的内容远超出了需求评审时的内容；

• 突然接到测试需求，没有余量的测试时间可以安排。

我们在谈论测试时间不够时，有个隐含约束条件：对应需求的上线时间无法更改。若是上线时间可以随意调整的话，就不存在测试时间不够的问题了。

那么我们可以先思考下：

当我们已经使用科学的方法评估出来预留给测试的时间不够时，我们是否在第一时间同项目组以及测试组织内部反馈了这个问题。也许有同学会碎碎念，反馈有啥用呀，我都已经说了很多次了。这里所说反馈是指——有效反馈，而不是无效的抱怨。比如说，客观地陈述现在遇到了什么问题，尝试了哪些方法，都不起作用，期望能得到什么帮助或者资源。

1.1 测试时间不够之入门级

举个例子，之前遇到过这样的场景：

测试参加需求评审后，根据以往经验，本次的需求内容在预计时间内无法按时上线，或者即使按时上线了，但肯定存在质量风险。

我们的做法是：

首先我们做了测试组内的

需求review

输出需求bug，输出已确定需求的测试用例编写、测试执行的工作量，同时说明存在需求bug的内容工作量暂时无法评估。

接着产品、QA、开发根据测试输出的需求bug再次进行一次

需求沟通会议

明确这些需求bug的处理，并再次确认本次需要上线的需求内容和上线时间点。

经过本次的需求bug沟通会议后，我们“惊喜”地发现，在QA输出的需求bug中，很多细节其实产品并没有梳理清楚，经过新一轮的沟通确认后，去掉了这部分内容，但如果存在这些内容的话，测试的工作量会大幅度增加，而如果没有这些内容，在产品方预期时间上线则完全没有问题。于是顺利解决了这次的“测试时间不够”的问题。

这是比较理想地解决“测试时间不够”问题的场景，而作为测试人，经常遇到下面这种常见场景。

1.2 测试时间不够之通用级

经过再次的多职能需求沟通确认后，原定的所有内容都需要实现，并且仍然需要在原定时间上线。我们尝试的做法是：

测试组内对产品修复的需求bug，再次进行需求review并进行对应的

工作量评估

这时工作量评估的目的是：明确本次需求内容需要的总的测试工作量。

明确测试组内在开发提交测试之前的各项工作内容和对应的

排期

明确每个事项的输入输出，对应的时间节点(确认点)和负责人。

同时，需要跟产品和开发密切沟通，对提交测试内容提早进行

合理拆分

保证分批提交测试而不是留到最后一次性提交测试，减少开发和测试的空闲等待时间。

测试组织输出高质量的

冒烟测试用例

给开发进行自测。这些用例可能会带来意外的收获，开发可能会在开发过程中有意识地避免相关(卡流程)的bug。

目前，一般都可以使用上述场景也能顺利解决“项目赶进度，测试时间不够”的问题。

1.3 测试时间不够之提高级

有些时候，我们会遇到测试准备工作完成和开发提交测试之间有一定的空闲等待时间。这时平时储备的自动化技术就在这时可以用上，为测试后续的高效回归做充足的准备。

当然很容易遇到个人的自动化技术储备不够，或者测试同学自身无法识别 自动化的需求时，需要测试同学要建立起向组织求助的意识。

上述做法能顺利解决“测试时间不够”问题的关键是：

测试进行有效的测试需求分析，并进行有效的输出和测试安排。

测试和其他职能进行充分且有效的沟通，并达成可行且有效的“协议”。

测试需要对确认的各个事项在约定的时间点做有效确认，并且及时识别并提出可能存在的影响上线时间的风险。

当我们向组织申请资源的时候，很有可能组织当前是缺乏这样的资源，但不代表以后不会有这样的资源。如果我们不进行有效沟通，那么组织就很可能一直都不会有这样的资源。事实上，上面的3个关键点对我们测试同学的软硬实力提升也有一定的指导意义。

遇到提交测试内容远超需求评审时约定的内容时，我们可以先快速地跟产品负责人进行沟通，明确目前提交测试的超出需求的内容是否需要在当前版本上线。

大部分时候超出本次需求范畴的内容都不需要在当前版本完成。那么我们会执行：

要求开发去掉超出需求范畴的内容。

当开发再次提交测试后，需要同开发确认去掉超出本次需求范畴内容的方式。

检查最新的提交测试内容是否符合本次的需求内容。

但并不是每一次降临的都是幸运女神，偶尔也会出现因为各种各样的原因，临时增加测试需求。实践中有效的处理方式是：

接受产品团队偶尔出现的临时需求，并且快速响应处理。

在接受的同时，严肃且明确告知产品团队，在开发进行额外需求开发的同时，必须同时将额外需求的内容同步给测试。否则测试有权拒绝临时需求，拒绝是为了质量保证。

临时增加的额外需求测试也同样遵守相关测试流程和测试规范。

而没有按时提测的场景就更普遍了。临近提测节点，测试同学总是战战兢兢地关注推送消息，默默祈祷按时提测，但经常事与愿违。

那为什么没能按时提交测试呢？

测试是否能更早地知道对应的需求内容无法按时提测？如果能尽可能早地得到提交测试延迟的信息，对于质量保障是有益处的。或者我们可以将按时提交测试作为提交测试后质量标准的一部分，以此来解决提交测试延迟的问题。

另外在项目沟通初期，测试是否可以依据自身的项目经验、测试组织的经验以及对开发团队的了解，尽早地考虑、识别到这个风险，并且有意识地管理这个潜在风险？如果有，那么当这个风险出现前，我们必将有很多办法来消除这个风险，而不是等到它出现后，手忙脚乱。关于风险的管理，项目管理相关课程有更精彩的内容，可以适当地学习下。

质量保证过程中另一个不可忽略的场景，产品或者开发同学，总是会抱怨测试时间太长了，能不能再快点。那么如何能缩短下测试时间呢？

之前遇到这个情况后，我们通过调查，发现测试同学经常抱怨测试环境不可用，从而导致测试时间的延长。可是并不能说清楚测试环境到底有多不可用。

于是，我们请开发同学做了个测试环境服务使用的监控，发现测试环境在工作日的使用率大概只有50%左右。而主要原因是：测试环境的服务挂了，没人管！

接着，我们明确测试环境部署的责任人，明确部署规则：只能在午饭和晚饭时间部署，并且部署前需要告知相关干系人，部署后对应的开发需要检查自己刚刚部署上去的内容是否OK。确定执行这个规则之前，当然也需要跟整个团队，特别是团队的相关负责人进行有效沟通。

经过一段时间的实践后，测试环境的可用度有明显提升，最明显的表现是，测试同学对于这方面的抱怨明显减少了，但还是会有一些抱怨，比如新的环境部署后，有一些重要流程会跑不通。经过再次调研，我们发现，并不是所有的开发同学部署环境后，都会去主动去检查自己部署的内容是否OK。

于是，我们又想了个办法，测试环境自动化部署后，进行核心功能以及重要功能的自动化测试，如若存在无法跑通的问题，则同步发送消息给对应开发。但其实，私聊的效果并不是那么明显，发到项目组大群的效果会更好。

通过使用上图的工具，经过一系列测试环境治理后，测试环境不稳定带来的测试时间延长被有效地遏制了。不过偶尔还会出现测试环境异常的情况。还有几个feature可以使用。

增加测试环境不按规范部署的监控，当测试环境一定时间内仍然不可用时，在项目团队群里发送报警信息，同时@团队相关人员。

测试环境服务一段时间内不可用，并且无人响应该问题时，自动重启的相关服务，如果服务器重启后，测试环境仍然有问题，那么就自动回滚到上个版本，直到测试环境可用。

02 提交质量不高时的质量保证

除了测试环境的问题，还有另外一个经常遇到的卡测试进度的问题：开发提交测试质量不高。

在刚提交测试的半天里，会出现很多主流程都走不通；或者是提交测试内容不完整，不符合预期的提交测试内容，导致测试同学总是在等待，或者跟着开发一起联调。但是呢，这段时间，已经习惯性地被认为是测试时间了。因为：提交测试了！于是给产品和开发印象就是：测试时间好长……

2.1 约定提测标准

我们首先做的是：跟团队制定明确提交测试标准。

• 按时提交在需求分析阶段各个职能约定好的内容，若无法按时提交测试，需要在产品团队群里进行告知。
• 取得产品团队同意，开发在提交测试前必须进行一定程度的自测。
• 开发提测时，同时需要明确告知自测的结果，比如自测是否通过。

一开始，我们按照这样的提交测试标准进行执行后，会经常遇到，离截止时间还有一两个小时时，团队群里会出现好几条预期提交测试内容延迟提交测试的消息，或者是，确实按时提交测试了，但提交测试内容的核心功能无法进行有效测试。我们进行一定的调研后，发现对于一些经验不足的开发：

他们并没有意识到延迟提交测试会带来什么后果，他们会认为我们遵守了约定的提交测试标准规范；

开发们往往不清楚需要进行哪些功能点的自测；

或者是他们觉得自测OK了，但是实际提交测试后，测试同学会发现还是存在影响测试进度的bug。

于是跟产品团队沟通后，我们将提交测试标准1调整成：

按时提交在需求分析阶段各职能约定好的内容，若无法按时提交约定好的内容，开发需要提早1天在产品团队群里@所有成员进行告知。

提交测试标准2调整成：

开发提交测试前必须完成由测试同学提供的冒烟测试用例执行，提交测试的内容不存在卡主流程的bug。

2.2 调整提测标准

两个提交测试标准调整后，又经过一段时间的实践，测试同学发现还是有些模块存在比较严重的卡测试进度的bug。此时我们去检查开发提测时输出的自测结果：

发现自测结果中并没有按照“测试想象的那样”输出内容，而且当提交测试内容较多时，并不是每一条提交测试内容都有明确的干系人去核对所有的开发自测输出。

接着，我们去访谈了相关未遵守自测标准的开发同学，他们认为需要自测的内容太多了，太占用他们的开发时间，对于后端开发来说，前端的自测内容对于他们来说是个门槛，而且有一定的学习成本。

整理提交测试标准执行结果和开发的反馈后，我们明确了每个提交测试内容的确认的责任人。

针对开发自测痛点，调整了冒烟测试用例：

将开发自测的冒烟用例拆分成：前端开发自测用例，后端开发自测用例。即对应开发只需要完成各自的冒烟用例自测，输出对应的测试结果即可。

测试同学尽可能将开发自测的冒烟用例执行时间控制在30分钟内。若执行时间超过30分钟，尽早同开发进行沟通，保证对应的自测的冒烟用例能被有效执行。

同时，我们更加明确提交测试标准中开发自测后需要输出的内容：

测试提供的所有冒烟测试用例执行结果，比如所有用例是否都被执行，以及是否测试通过；

输出测试未通过的说明，未通过的用例对应的功能点预期提测时间，以及相关问题是否影响主流程等。

至此，通过提交测试标准的有效实施落地，明显改变了“产品和开发眼中，测试时间好长”的观点，而且让团队养成了在预期提交测试的前一两天，总会有相关干系人在项目群里主动同开发确认，是否能按时提交测试的好习惯！

这里还有个小遗憾，测试输出冒烟测试用例给开发，开发提测时输出自测结果等这些内容，都是通过文档或者邮件往来进行输出确认，对于项目的整体效率打了一定的折扣。未来如果有机会，一定来弥补这个遗憾。

而另外一种提交测试质量不高的情况，虽然出现频率不高，但也经常打扰测试：开发修复bug的质量不高。

最常见的表现是：修复了一个bug，但冒出来好几个其他bug，于是bug数量无法收敛，客观地延长了测试执行的时间。

对于测试新手来说，这真的很烦恼，一方面是无法延迟的上线时间，另一方面是比较弱的bug修复质量。让测试新手无所适从。此时可以适当引用历史经验：

在测试日常输出的测试小结中明确提出这个情况，引起团队干系人注意，尽可能早地处理掉这个风险。

测试可以建议相关开发同学进行代码review干预。

那么经过以上有效的测试环境治理，开发提交测试标准制定实施，我们在测试执行阶段在遏制测试时间“被莫名”延长，同时已经默默地推动了开发必须完成一定程度自测才能进入提交测试的流程。通过一定的风险管理，推动了开发切分feature提测，而不是憋大招，一下子提交了一大堆待测试的内容。而这些当然可以有效地缩短一部分真正的测试时长。

而以上都需要基于：测试有明确的测试计划，并且需要让所有的干系人，也就是项目组所有成员都有明确的预期；测试要依据相关的风险进行测试，最大的风险得到最高效地测试，科学地分配时间，缩短bug反馈的时间弧；进行严格的bug管理，所有重要的bug都及时修复。更加重要的是，需要要有良好的沟通和汇报机制，每天都让团队成员清晰地知道，距离版本目标还有多远。

03 自身能力提升的质量保证

我们除了优雅地处理好影响质量保证的外部因素外，作为质量保证的主体，测试人员自身的素养则更加需要重视。

3.1 挑战

曾经遇到这样的挑战：每次产品上线后，必出线上bug，也就是线上质量堪忧。

我们发现线上bug的表现是这样的：

必须显示的内容，有时候显示正常，有时候显示NULL；

必须显示的内容，有时候显示正常，有时候会显示空；

必须显示的内容，居然没有在预计的时间点被正确显示；

显示的内容存在明显的逻辑问题。

3.2 尝试解决

很明显，问题1和问题2应该是非常容易解决的，深入了解后，我们发现问题1和问题2，是由于后端数据类型不稳定，导致的前端显示异常。于是一方面推动了后端传输的数据类型进行约束，比如有默认的使用类型，异常情况时统一使用另外的一种类型，那么前端只需对约定好的两种情况进行对应的显示处理。

那么按常规来看，应该不会再出现问题1和2了，但遗憾的是，后端更换开发同学了，新的开发同学并不清楚这之前的后端和前端同学的约定，于是再一次掉坑。

比较幸运的是，这次是在测试环境先发现了这2个问题。测试同学意识到了这里的问题，立即整理更新了测试用例以及回归用例，以避免类似问题再次出现。

落地数据类型对接规范，同时增加对应的测试用例到用例列表后，问题1和问题2已经顺利解决。

而问题3是这个产品的特性，也是最大的困难点。我们复盘了下，主要原因有：

测试环境的数据有限，导致无法在测试环境暴露该问题。

测试环境mock该内容时，并没有跟线上环境产生该内容的方式一样，因此无法在测试环境暴露该问题。

不同的开发对于该项内容理解不同，实现的逻辑不一样，导致线上出现的问题原因五花八门。

定时任务报错，导致该问题无法在测试环境暴露。

复盘罗列了问题3的原因后，忽然松了口气，感觉脑海里已经飘过无数的解决方案，只要一落地，就能同问题1，2那样，迅速顺利解决。但当我们再深入了解产品的情况后，被无情的现实打醒，测试环境的测试数据“根本无法”mock到满足预期的数据量。于是我们暂时先搁置了原因1。

接着，我们去了解测试环境上产生的内容，是否可以和正式环境一致。和开发沟通后，发现之前我们在测试环境执行测试时，这些内容都是直接查询数据库表，然后在页面上显示出来，而数据库中的内容，开发是手动填入的。

当了解到这个情况后，我们其实有点崩溃，但更多的是庆幸！接下来，我们很顺利地跟开发确认，后续所有逻辑相关的内容，都必须经过对应的代码逻辑处理，然后由代码写入数据库。同时，我们立即整理了这项测试内容与开发之间的约定，作为回归测试的确认内容。

这个mock方式的调整，让问题4也有一定的受益。我们对显示内容的逻辑测试，变得有效。

最后，我们跟产品方的相关同学沟通后，提出每次上线前，必须进行核心逻辑的代码review，避免因不同的开发理解不同，实现方式不同，而导致的线上问题。当然，测试也把这项约定整理记录，作为回归测试的确认内容。此时，我们灵机一动，定时任务失败是否也可以通过增加相关review来避免该问题。和相关开发深入沟通后，得到了肯定的答复：可以的！于是，4个原因导致的页面内容显示问题顺利得到解决了。而我们也产出了初版的项目上线前的checklist。

经过几次产品上线的考验后，我们发现这份checklist是非常有效的，线上bug次数明显降低了，不再是每次上线必出线上bug了。但我们仍然需要面对：时不时会出个线上bug的问题。之前被搁置的“测试环境的数据有限，导致无法在测试环境暴露该问题”原因再次回到我们的视野，亟需解决，不能搁置了。幸运的是，此时刚好遇到开发正在推动各个项目日志标准化，借着这个契机，我们提出了开发从相关产品导一份符合预期内容和数量级的测试数据到当前的测试环境，便于测试在测试环境进行完备地测试验证，避免再出现部分内容的表现只能上线后听天由命的情况。

果然，在我们这个行当里，只有想不到，没有做不到。虽然麻烦了一点，但测试环境的测试数据终于得到了有效保证，最终实现了测试环境的数据测试自由。我们的初版checklist又增加一条check内容，确认测试环境的测试数据是否准备齐全。

我们整理分类了checklist的内容，一部分由测试进行确认，一部分由开发或者开发负责人进行确认，并且明确每条checklist确认的时间点，同时在checklist中附上有借鉴意义的历史线上bug列表。

3.3 及时改进提优

Checklist落地执行一段时间后，确实有效，正当我们暗自庆幸线上bug再次大幅减少时，又出现了新的问题。某次上线过程中，开发完成checklist后检查确认后，默默地直接上线了！更不幸的是，刚好有严重的线上bug！除了立刻处理线上bug外，我们梳理复盘该问题后发现：

如果开发进行上线操作前，将该信息同步给测试，在测试环境回归确认后再上线，可以避免该问题。

我们的checklist确认后的上线流程存在明显问题，当开发缺乏主动同步上线操作意识的时候，这个问题就暴露出来了。

需要给测试预留一定的线上环境的相关功能和内容验证的时间。

制定流程规范的时候需要将各个职能同学都默认为盲盒，而不是侥幸存有“我觉得应该懂得”的想法，从而出现流程或者规范不够完整。

那么我们对于checklist内容改进，增加上线前和上线后的分类：

我们和开发负责人以及每次做具体执行的开发进行强约定，任何内容的上线操作都必须在项目群里@所有人，待相关责任人确认后，才可以进行对应的上线操作。

上线操作完成后，需要第一时间在项目群里@所有人，相关责任人进行线上确认。

制定流程或规范后，需要每个干系人进行review确认，俗称按手印。

最后测试以线上质量保证为“条件”，成功得到了线上验证的预留时间，虽然很短，但足够了！

3.4 checklist系统化

新版的checklist又经过一段时间的实践后，我们发现只要整套checklist被有效执行，几乎不会再出现线上bug了。本该是值得高兴的事情，但随着产品上线次数越多，测试同学的不满也越来越多：

每次产品上线其他职能的checklist确认总是要一遍一遍地催，感觉自己像个保姆；

其他职能确认checklist的内容后，已经确认的内容和未确认的内容，无法高效地输出，测试在这件事情的沟通上耗费了较多的无效人力。

其他职能已经默默地养成“反正测试会来催，不主动去确认checklist内容”的坏习惯，最后出现产品上线只有测试最着急，其他职能似乎都不在乎或者不关心约定的上线时间的情况。

经过几轮争论后，我们决定借鉴以往的上线流程任务化的经验，将checklist系统化，用强流程来约束各个职能的行为，保证checklist可以高效、透明地执行。我们请工具组的开发人员，帮忙实现了QA流程管理系统。随着该系统的实现，测试的工作流程做出相应的调整：

在产品立项后，测试人员不再第一时间输出checklist，而是最先输出项目流程中各个关键节点的输出时间，这个内容就少很多了，需要确认的内容简洁明了。

各责任人确认完毕关键节点的输出时间后，测试人员输出checklist，并在系统上创建checklist，粒度细化到每条checklist对应一个责任人，同时设置该条checklist的开始和结束时间，即增加了checklist的有效期，可以在产品的不同阶段设置不同的确认消息提醒频率。

最后加上必须所有checklist都确认完成后，产品方可上线的约束。

有了上述的自动提醒和流程约束机制，我们终于优雅地解决无效的测试等待时间，从侧面提升了测试效率。从必出线上问题到基本不再出现线上问题，我们反复使用PDCA方法，对问题抽丝剥茧，在日常的工作中注意积累，同时积极关注业界技术的动态，利用一切可利用的资源，最终实现产品的线上质量大幅提升的目标。

在整个流程优化改进后，还留了个小尾巴：产品执行过程中，整个项目组并不能高效地获取本次checklist的进度和状态。如果测试没有及时在群里同步该信息，那么本次checklist情况对于项目群里所有人都是黑盒的。我们有想法来解决这个问题：使用小泡机器人定时向特定的群自动发送当前的checklist情况。但当时受限于自身的见识和技术能力，并没有实现这个feature。

因产品的特殊性，在提升产品的线上质量方面，我们还做了测试右移。每一次产品上线，测试都必须输出对应的监控。一方面用来保证线上的运行的产品都质量可靠；另一方面需要及时发现产品运行期间可能出现的异常情况。从编写测试脚本，搭建运行环境，到使用工具配置定时任务，使得监控健康运行。在整个质量保证周期中，监控立下了汗马功劳。可以说绝大部分的线上异常情况，都是监控报警出来发现的。比如：

长期正常运行的服务突然不可用；

长期正常运行的服务执行突然慢了下来，影响显示内容的正确性；

长期正常运行的服务，突然缺失或增加了一部分内容。

还有个额外的收益：开发默默地调整了一些内容没有告知测试，也会被监控到！基于这个额外收益，我们在自动化接口测试框架上增加了：

根据项目的特殊性，自动生成基础的接口测试脚本，便于进行基础的接口测试，同时提升测试人员编写接口测试脚本的效率。

自动检查当前是否有新的测试对象，并将检查结果发送给对应的负责人，进行后续处理。

自动收集检查线上运营产品的报错情况，并将检查结果发送给对应负责人，能第一时间进行相关处置。

一键提交当日各产品的测试结果，让测试结果在测试团队内透明，信息共享。

3.5 初版质量测试可视化系统

一发不可收拾，我们输出越来越多的脚本，或提升测试效率，或是提升我们的工作效率。团队成员在脚本方面的技能肉眼可见的提升。于是质量测试可视化平台应运而生。我们期望这个平台能够承载：

通过平台可以透彻了解团队成员所有的工作内容。

通过平台可以清晰地了解团队成员产出脚本的执行情况。

通过平台可以高效展示日常接口测试的执行接口。

通过对平台数据的统计分析，反推测试工作的改进以及测试效率的提升。

目前这个平台的初级版本日常运行，可以说我们现在的日常工作已经离不开它。之前有一段，线上产品的监控报警特别多。但我们无法统计出各个产品具体的报警次数，那么想要对监控进行优化，甚至实现精准监控，要花费大量的人力从POPO消息历史中去翻找消息，并且需要人肉统计。不仅慢，而且太容易出错了。

有了这个平台，我们把所有监控的报警消息经过脱敏处理后，同步传到这个平台，平台拥有的筛选、统计、显示功能，可以非常高效地帮助我们复盘到监控脚本的执行情况，分析出相关的优化点，减少无效报警。再抽象出可复制的有效方法论。

经过上面反复的PDCA，测试团队整体的发现问题，分析问题，解决问题的能力明显提升。整体的测试开发能力实现了从无到有的跨越。

通过这个平台，我们除了让测试质量可见，还可以把测试质量管理起来，这对团队owner来说更加有意义。通过使用定制的平台，定期进行质量复盘，为团队及个人制定可持续发展的目标。

以上是我对质量保证的一些感悟。通过使用PDCA工具，在日常工作中不断地发现问题，分析问题，解决问题，不断地改进优化解决问题方案，沉淀形成体系化的输出让项目组收益，既实现了有效的质量保证，又提升测试人员自身的各项能力。

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！