Leo-Fighting的博客

工具篇涉及到的内容，已经一并打包。

平时进行测试时，要对自己的测试速度有大致的评估，例如平均每天可完成100个测试用例，若效率高可完成120个测试用例。在测试进行的过程中，如果发现时间不够，提前向上级反馈，可适当增加测试时间或者增加测试人手。如果发现评估的时间多了，可以自己花点时间做发散性测试，或者提前结束。前面分享过一篇测试工时评估的文章，根据开发时间、验收时间来做评估。梳理的时候，用思维导入逐个模块，拆开来评估，最后做汇总，如下图所示。在评估测试工时的时候，大致判断需求的每个模块，会有多少条用例？今天分享到这里，有疑问的可以告诉我~

在提bug时，如果能提供截图，或者录屏，会更方便开发复现，从而提高修复的效率。

关于抓包工具，分以下3类情况介绍。

相比于 Xshell，MobaXterm 的界面与整体交互会好一个档次。可惜的是，只支持 Windows 系统。今天分享到这里，有疑问的可以告诉我~关于 终端管理工具，推荐使用。也准备了文档及视频教程。

查验 Redis 数据，或者构造数据，推荐的可视化工具–Another Redis Desktop Manager。例如，对于金币、钻石等奖励的发放，会选择使用 Redis 来进行存储。有些场景，涉及到缓存数据（使用 Redis 来进行存储）。今天分享到这里，有疑问的可以告诉我~

关于DBeaver 的安装使用，以下这篇文档整理得挺好的，我就不重复造轮子了。目前，MySQL 最好的可视化工具，应该是 Navicat。但由于是付费工具，一般公司都没有去买。今天分享到这里，有疑问的可以告诉我~在公司的电脑安装破解版，又有风险。

出现了线上问题，也不要怕，不要逃避，自己总结反思，避免以后再犯同样的问题。涉及到公司金额损失的，责任人需要承担一定比例的损失，从工资中扣。优先要跟进用户，配合开发复现场景，这样才能高效修复问题。如果阻塞流程，影响的人员越多，处理的优先级越高。所以，负责的业务，离钱越近，测试时，越要谨慎。用户反馈线上问题时，作为测试，要及时响应。直至验证通过，再重新发布到正式环境。今天分享到这里，有疑问的可以告诉我~如果存在漏测，漏测的原因是什么？那出现线上问题有什么影响？线上问题是难以避免的。问题的场景是怎样的？

例如，应该要有结果，但是没有；特别是涉及数额的时候，后端会返回很多内容，前端不够细心的话，就容易回填一个错误的参数值。等开发修复好，再去做回归验证，保证这个 bug，以及可能关联的场景，都验证下。，优化SQL、异步处理等，其次可以从前端加载的方式上进行优化。因此，在提bug前，可跟开发确认下，避免提无效的 bug。如果你发现传参没有任何问题，但返回结果与预期的不符，前端的 bug，通常是页面样式，页面交互的问题……还有一种常见的前端bug，是取了错误的值，，你提的 bug，是否有效？

用例评审的时间，建议安排在产品验收的中后期。一方面，产品验收阶段，可根据实际情况，给你一些优化调整用例的建议和思考方向；另一方面，开发能跟上你的思路，更新一些需求以外的内容，例如功能实现做了调整，会影响到其他模块功能，哪些场景可能存在性能风险等。

测试的工时评估，可以参考2个时间：产品经理的验收时间开发时间通常情况下，是 验收时间 < 测试时间 < 开发时间。

产品会在需求评审前，会把需求文档发出来，给开发、测试看。

用例的模板文件需要不断更新。随着测试的深入，会逐渐发现更多重复、有规律的用例。或者是线上环境暴露了新的bug，要提醒自己下回注意。这些都促使你去更新迭代用例模板。

无论使用 Excel表格，还是 思维导图，都建议积累形成一份，适合你的测试用例模板。测试用例模板的作用，有2点：提高编写测试用例的效率减少漏测的风险第1点很好理解了，重点说说第2点。很多人都是直接按照需求文档来写用例的，这没错。但还不够。出问题的时候，可以反驳，需求文档没有写。可上级会认为，你考虑不够全面，到最后，会影响个人绩效。那么，用例模板如何制作？分2部分。

没有导入平台的要求，公司也没要求使用表格编写用例，使用思维导图是效率最高的。测试的时候，对的场景就打钩，错的打叉，再写个备注，方便自己进行回归验证。所以，如果要导入平台的话，直接用 Excel表格编写用例。按照需求文档，逐个点去拆解场景，有关联的，用箭头串联起来。将需求内容分成一个一个模块，通常是从上到下，从左到右，将页面上的每个版块，每个功能按钮，逐个排查。这一篇分享使用思维导图，来编写测试用例。很复杂吧，完全失去了思维导图的意义。今天分享到这里，有疑问的可以告诉我~而且有利于发散思维。

我司的测试平台，是在 MeterSphere 的基础上做了二次开发，想了解的可以跳转至。万一哪一天，公司引入 MeterSphere，需要在平台上维护用例，而你已经适应了按照这个模板填写，到时候转换过来，也不会有什么困难。我的模板文件是在 MeterSphere 上导出的，如果公司还没有形成规范的模板文件，那可以参考我的。看看别人是怎么写的，先模仿着写，基本不会出错。如果公司已经有了规范的模板，直接用就好，今天分享到这里，有疑问的可以告诉我~使用这个模板文件的好处也是有的。先来说说 Excel表格。

自学的时候，我觉得编写测试用例挺简单的，根据需求文档，逐句逐点去拆分，正向流程、逆向流程、有什么逻辑限制、什么状态允许执行……看起来都不难是吧？但到了实际工作，发现是我低估了写用例这件事的难度。

考虑到你对项目组业务不熟悉，一般不会马上安排测试任务。这段时间，多观察，多记录，有疑惑的地方，先思考，再统一问。

因为这会阻碍你当前工作，别人以为你已经申请权限获得某些文档资料，并且看完了，但实际一直卡在权限申请上，没有进展，这会给别人留下糟糕的第一印象。团队成员比较少，Leader会将你介绍给工作中会接触到的同事，包括项目经理、产品、同组的测试成员、开发、运维。有不懂的自己先总结整理，集中时间去问，而不是有一个问题就问一次，这会打断别人的测试思路。例如，第一天上班，有些权限申请，按照别人提供的资料，半个小时还处理不了，就及时求助吧。多阅读同事给你分享的文档，熟悉工作流程，业务需求等。而产品，则有利于你熟悉业务需求。

第二类：对于互联网企业，中等规模以上、存在竞品对手的项目，入职流程相对严谨，复杂。除了劳动合同，还有保密协议，入职后权限/账号等的申请及开通，租房补贴等的申请……第一类：传统行业的IT部门、小规模的互联网企业，入职流程跟常规的差不多。HR会将当天的入职人员组织到一起，通过培训的方式来指导入职。另外，离职证明放在中间，HR就不会把注意力放在离职证明上，整体流程方面，根据行业，公司的规模，及产品线有所不同。相比转行时入职，这一次跳槽后的入职，相对放松了。而不是缺这缺那的，反复检查，调取你的资料。

转行的第一喜事，当然是收到Offer啦～拿到Offer的那一天，我松了一口气，算是实现了一个小目标。但我又意识到，接下来，游戏要升级了，即将要面临试用期的考验。前面的文章，分享过如何度过试用期。在试用期这段时间里，你只要不犯原则上的错误，大概率是可以留下来的。毕竟企业重新招人，培训，直到能够熟悉业务独立测试，一切都需要成本。转正这一段路，你带着如履薄冰的心态去面对，不是件坏事。只有这样，你才不会懈怠，仅仅满足于入行，知不足才会不断去提升自己。在这里，我想陪你走过转正这一段路。通过对比前后两份工作