初识测试
不知不觉，我在测试部的实习已经快三个月了，入职第一天的场景仿佛还在昨天。在实习之前，我对测试的认识仅仅停留在一些软件测试和测试方法的理论知识上，在学生阶段项目中的测试，最多也是对自己的代码进行一些单元测试。
我之前所理解的测试是与开发分开，测试人员只需要“鼠标点点点”，根据需求寻找bug，不需要写代码、看代码。然而，通过项目实践，我对测试工作有了真正的认识和见解，认识到测试前置的重要性，依据W测试模型，在需求和设计阶段就介入测试，尽早发现缺陷，如需求文档、设计可行性，也需要提前编写接口用例，例如在测试交易链路时，提前设计用例以覆盖链路的每个分支。除此之外，还需要深入代码的设计逻辑才能更好地测试。
项目实践与成长
实习第一周，安装测试常用软件和平台，做好测试前的预备工作：
- Xmind：思维导图软件，用于编写测试用例。
- SwitchHosts：hosts管理利器，用于管理、快速切换Hosts小工具。
- Fidder：抓包工具，将手机的网络设置手动代理，连接电脑端的IP与端口，可以抓取手机访问的URL以及一些参数。注意，要抓取https请求时需要安装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，把数据通过
⑤调接口：输入接口参数，调用接口，测试接口能否成功调通。使用原子层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的设计逻辑，明确状态机的链路、链路的分支，在测试各链路的分支时，一定要从起始状态走到终止状态，从而保证整个流程的正确性。