00后从事软件测试一年的心路历程

初识软件测试

不知不觉，我做软件测试已经快一年了，入职第一天的场景仿佛还在昨天。入职前，我对测试的认识仅仅停留在一些软件测试和测试方法的理论知识上，最多也是对自己的代码进行一些单元测试。

我之前所理解的测试是与开发分开，测试人员只需要“鼠标点点点”，根据需求寻找bug，不需要写代码、看代码。然而，通过项目实践，我对测试工作有了真正的认识和见解，认识到测试前置的重要性，依据W测试模型，在需求和设计阶段就介入测试，尽早发现缺陷，如需求文档、设计可行性，也需要提前编写接口用例，例如在测试交易链路时，提前设计用例以覆盖链路的每个分支。除此之外，还需要深入代码的设计逻辑才能更好地测试。

项目实践与成长

入职第一周，安装测试常用软件和平台，做好测试前的预备工作：

Xmind：思维导图软件，用于编写测试用例。
SwitchHosts：hosts管理利器，用于管理、快速切换Hosts小工具。
Fidder：抓包工具，将手机的网络设置手动代理，连接电脑端的IP与端口，可以抓取手机访问的URL以及一些参数。注意，要抓取http请求时需要安装Fiddler证书，下载方式“http://电脑IP:端口”。Fidder与SwitchHosts一般配合使用。
Git、SourceTree：在gitlab上下载分支，使用SourceTree切换分支。
IDEA、Maven：使用IDEA配置Maven，导入gitlab上的项目。
Xshell：访问远端的服务器，主要进行一些日志的查看，学会日志查看的相关命令，如tail、grep等。
TestNG：用于单元测试，学会常用注解。例如，@Test、@BeforeTest、@AfterTest、@DataProvider。
TAPD平台：敏捷项目管理平台，用于创建需求、项目跟进、提交bug等。
环境管理平台：用于申请环境、管理机器、管理服务调用关系。
Beetle平台：转转测试部主导研发的CI/CD分支管理平台，集成了code review、code diff、增量代码覆盖率等功能。

实践项目：我主要参与了清结算业务线配置、pop售后维修、退款等项目的测试工作。项目的流程主要分为这几个阶段：

1、熟悉需求：根据PM所出的需求文档提前了解本期项目的背景、需求点。

2、需求评审：主要是PM讲述需求，作为测试人员，要积极参与其中，对一些模糊点或疑问点及时提出并解决，如果开发后再解决成本高。

3、设计评审：主要是技术评审，RD会对自己的库表、开发思路讲解，测试人员需要从中评估是否符合项目的功能性与非功能需求，并评估需求的可测性，提前思考和规划后续的测试方案。

4、用例设计：从需求中提炼出测试点，使用xmind编写用例，设计的用例要注意几点：

页面：是否与原型相符、非法数据前端是否校验、文案内容。
流程：业务流转是否正常。
数据：非法数据是否校验、传参是否正确，数据展示处理，数据库中记录、值是否正确。

做好测试前置工作——编写接口测试用例，接口测试在接口开发完成后就可介入，不需要关注接口的内部实现逻辑，只需构造入参、校验出参。首先需要引入pom依赖查看接口，测试过程要做到几点：

构造数据：初始化测试数据，例如我们要测试申请售后的接口

首先需要构造交易完成的订单数据，其次需要构造申请售后需要的参数，如该接口需要一个Map，把数据通过<key, value>封装到map中即可，注意key值与RD开发时使用的key对应，避免解析后的不一致，value即为构造的数据。

调接口：输入接口参数，调用接口，测试接口能否成功调通。使用原子层Atomic调用接口，传入构造的map参数。
断言：获取接口返回的结果，判断response数据是否符合预期，注意异常数据的测试。

在做白盒测试时，要深入代码逻辑，使测试用例做到语句覆盖、判定覆盖、条件覆盖，提高测试的覆盖率，例如，对于多分支代码，用例需要考虑每个分支的情况，将所有if...else分支覆盖到，对于判定条件中有“||”或者“&&”的代码，设计的用例要覆盖每个条件。

除此之外，在设计用例时还需要使用等价类划分法、边界值法等方法，比如对于钱款相关的测试，边界值是必不可少的。

5、用例评审：“一千个人就有一千个哈姆雷特”，每个人对同一个需求的理解不同，关注点不同，总会存在一些遗漏点，因此需要其他人员评审用例是否存在遗漏，以保证测试用例的覆盖率，并对用例设计过程中存在的疑问点再次与PM确认。

6、开发自测&冒烟：根据测试人员提供的冒烟用例进行自测，自测完成后项目提测，并发送提测邮件，测试人员正式介入测试。

7、测试阶段：测试环境分为动态测试机和稳定机两类，动态环境用来部署本次有改动的服务，稳定环境保持一套与线上一致全量服务并定时同步。测试工作主要是在动态环境上进行，需要在动态测试环境验证和沙箱环境验证。

（1）测试环境：环境平台上的一套多人共享、按需求隔离的环境，连接线下数据库，用于部署web/rpc服务。在测试环境中，首先验证冒烟用例是否通过，然后验证其他用例。在验证过程中，使用TAPD平台提交bug，对bug的复现描述要清晰，提交bug注意以下几点要素：

bug标题：言简意赅，说明是什么bug
bug内容：bug出现的环境、重现步骤、预期结果、实际结果、截图标明bug位置、错误日志截图、logId
bug严重程度：致命、严重、一般、提示
bug 优先级：高、中、低
bug处理人：定位bug的修复人

在测试过程中要注意在Beetle上查看代码的覆盖率，以防用例未完全覆盖修改的部分，用例全部测试完并通过后，才能进入沙箱环境验证。

（2）沙箱环境：一套预上线环境，连接线上数据库。沙箱验证时要谨慎，不能对线上用户造成影响。沙箱验证完成后，即可进入上线阶段。

8、上线阶段：在上线前要求RD梳理一下上线流程以及回滚方法。上线完成后，进行线上测试。

9、项目复盘：回顾项目的各个阶段，对过程中存在的问题进行总结、分析，吸取经验教训，避免出现重复错误。

实践中的成长：

首个测试任务“清结算业务线配置”中，我主要是对web页面进行测试，本次测试中，我熟悉了清结算业务，学会使用Fiddler抓包，以定位错误问题是前端还是后端，能够使用Xshell查看一些错误日志，然而，在测试过程中，我忽略了一些前端校验和样式问题，明白了对于页面来说，肉眼可见的不适均可能为bug。
在“pop售后维修”的测试任务中，我熟悉了售后维修的流程，学会在IDEA编写接口用例、查看离线任务。然而，在测试过程中，我忽略了客服仲裁后操作的链路是否正常，理所当然的认为只要出现过的操作都是对的，归根结底，我认为是缺少对RD设计逻辑的研究，不了解其状态机配置的链路，测试过程中没有将每个订单流程走到终态。针对这一问题，首先需要提前了解RD的设计逻辑，明确状态机的链路、链路的分支，在测试各链路的分支时，一定要从起始状态走到终止状态，从而保证整个流程的正确性。
“pop售后退款”项目是对维修项目的一个升级，与之不同的是，退款涉及钱款交易。我的测试内容是客服仲裁与退款验证，积累了一些经验后，我这次能够更熟练进行测试了，编写接口用例后，不用自己点点点了，一来验证了流程的跳转，二来直接进入到自己的测试点，可以只关注仲裁结果和退款结果了。但是，对没有接触过的测试点，缺少测试前置规划，没有提前深入了解，导致测试过程中的时间浪费。

改进点：

要熟悉自己的业务，将自己融入产品的角色中，脑袋里要形成每个需求点的操作流程、结果，在测试过程中，更要身临其境，身临用户的情景，验证人机交互是否流畅，是否是用户最期望的结果；提高自己的测试效率；为自己规划，每日总结一下测试遇到的坑，“不积跬步，无以至千里”，要想成为一名优秀的测试工程师，必须拥有丰富的测试经验，在每次测试过程中提高自己的怀疑精神和洞察力。

团队氛围

工作的第一天，我就感受到了团队的生机与活力，感受到了大家对工作充满着热情。完全没有电视中的那种勾心斗角，在这个年轻的团队中，同事之间的交流无代沟，互帮互助，小组里的每位同事都为我这个测试小白解答了不少问题，很有耐心。工作之余，大家也很懂得劳逸结合，成功教会我打桌上足球。

总之，感觉大家都是快乐地在工作，这种充满人情味的团队真的很吸引我。

新人预备知识及能力

作为前辈，给新人们一点小小的建议。首先，你需要一些“硬件”知识，我第一周所安装的工具，你也可以提前体验一下。还有，我们QA也是技术人员哦，可以学习一下Java编程、SQL的常用语句、计算机网络等等技术知识。

如果你想学习测试相关知识，建议学习一些软件测试理论，黑盒测试方法、白盒测试方法，自己学会编写测试用例，然后了解一下单元测试、TestNG、接口测试、自动化测试、性能测试等等。如果你想提升自己的测试能力，平时多留意身边的bug，提升发现问题的能力，再多找些QQ群加入，你会有意想不到的收获。

未来规划

在业务测试方面，熟悉自己负责的业务、与自己相关的业务、公司其它业务，学会看RD的代码，了解开发的过程，以便更好地测试；在测试方法方面：我需要了解并学习团队现有的测试方法，并不断探索新的测试方法；在技术方面，多看一些技术型文章，了解测试技术的发展趋势，学习一些新的技术和测试方法。

技术上的一点帮助

最后分享自己整理的【备战资源库】，基本涵盖了软件测试的全部核心技术点：测试理论，Linux 基础，MySQL 基础，Web 测试，接口测试，App 测试，管理工具，Selenium 相关，性能测试，计算机网络，组成原理，数据结构与算法，逻辑题，人力资源，技术脑图等等…质量非常高！！！应对技术面试绰绰有余！【点击文末小卡片免费领取】