作者|蔺文文
从学习到工作的转换与思考
从自己决定实习，到作为一名测试实习生入职公司，前后只有五天时间。来到北京，一个我完全陌生的城市。初来对寒冷大风天气的不适应，第一次上班体验到的地铁早高峰，入职后坐在工位看着大家在认真工作的新鲜感…这些我第一次经历的事情，到现在都已经过去两个月了。
从学习到工作，听起来好像是跨越了两个维度的事情。在我看来，工作本身也是一个不断学习的过程，不断遇到问题不断解决问题，提高能力，积累经验。在学校学习的时候，测试基本都停留在纸上谈兵阶段，动手操作的经验并不多。通过两个月的实习，对测试有了更深一步的认知，实际参与了完整项目和需求后，知道其实测试一开始就会介入，贯穿整个项目，从需求到开发到上线，越早介入越早发现不合理的地方，了解开发和产品的思路，了解整个需求，测试可以做得更好。对于一些复杂的部分，涉及到很多的数据和流转，需要写测试方案，准备和构造测试数据。学习的时候所有事情都是自己，是较为独立的存在，工作之后好像事情都变得有规章了，流程清晰起来，每个方向都有负责人。如果说大学是从学校向社会过渡的重要节点，那么实习就是正式进入职场前的测试阶段，有充足的时间熟悉业务，熟悉工作流程和工作内容。
实习期间学到了什么
常用软件:
1、IDEA：开发工具
2、MIT Kerberos Ticket Manager：服务器权限管理工具
使用Kerberos登录堡垒机首先需要申请Kerberos账号，修改密码后进行登录；
3、Xshell：服务器日志查看工具
建立会话成功后连接至服务器，进入相应目录查看日志。出现bug时，查看日志。
常用日志分类：
debug：调试时系统运行的状态信息。
info：输出的信息，打印程序正常的状态信息，便于追踪定位系统当前状态。
warn：警告信息，系统发出警告，但是不影响运行。
Error：错误信息，最常用的日志信息，表示系统出现错误，无法运行得到正确的结果，Error属于异常信息的一种，测试过程中要多关注异常信息，有些异常并不直接影响业务流程，但也要关注原因提出必要的改进意见。
4、Charles/Fiddler/Whistle：抓包工具
Charles，Fiddler一般需要安装Switchhost配置hosts 。Whistle是网页版工具，推荐安装proxyOmega插件一起使用，whistle具体安装使用可以阅读开发者的文档http://wproxy.org/whistle/ ；
5、Switchhost：代理切换工具，用于配置hosts，切换路径；
6、Xmind：导图工具
使用Xmind编写用例，用例是后续测试阶段的重要依据；
7、SourceTree：git的GUI工具
使用SourceTree拉取、上传、克隆gitlab上的项目，新建，切换分支；
8、Navicat for MySQL：数据库连接管理工具
查看数据库数据、字段。
常用平台：
1、Beetle：代码分支流程管理平台，git组权限申请；
2、GitLab：git平台;
3、 TAPD：项目管理平台;
4、dashen：搭建的知识共享平台;
5、环境平台系统：申请环境、部署服务;
6、 运维工单系统：Kerberos账号申请、服务器访问权限、VPN权限申请等等。
测试环境IOS使用whistle抓包：
前提手机和电脑在同一wifi环境下
1、申请测试环境
2、 部署服务
3、配置whistle
4、手机设置代理：测试完记得关闭代理，否则不能正常上网：
图1. 设置手机代理
5、对于https请求需要下载安装证书
ios10.3以后，手机下载完成后需要手动信任证书：打开手机设置-通用-关于本机-证书信任设置-信任证书，就可以正常抓包了。
6、要测试转转app的话，需要下载测试包。
项目流程：
图2. 项目流程
QA参与的重要节点：
1、 需求评审
PM对需求进行讲解，QA也需要参与，可以针对可行性、完整性、用户体验等等提出自己的疑问，后续需求和原型发生变化或更新时，PM应及时同步至TAPD；
2、 设计用例
测试用例：为了某个特殊目标编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
（1）如何进行用例设计
根据原型和开发文档，针对功能、数据校验、数据传输展示、页面美观、请求参数和响应数据等等设计测试用例，对输入数据、处理过程以及输出进行用例设计，具体的方法包括等价类、边界值、场景法、错误推测法等。
（2）拆解用例方式
先要熟悉需求，将需求划分为多个测试点，针对测试点拆分，可根据筛选条件，结果列表等进行划分。根据输入、处理、结果三大步骤将具体的操作步骤转化为一条条测试用例。
（3）用例的要素
一条测试用例主要包括输入数据、前提条件、测试步骤、预期结果。用例需要做到清晰易读，执行力高，考虑全面避免遗漏。
3、 用例评审
一般测试工作量较大的需求需要组织会议进行用例评审。用例评审主要由QA对自己的用例进行讲述，避免有疏漏的地方或者理解偏差的地方，保证项目质量，针对主流程选出冒烟用例；
4、测试
开发执行冒烟用例，通过后进行提测，正式进入测试阶段。依据测试用例进行测试，执行用例过程中要及时标记用例，方便查看测试进度和复查。发现bug时提交至tapd，bug要做到简单清晰，直击重点。测试时可以在beetle上check代码覆盖率，检查是否有遗漏的场景。
图3. 一个bug应该包含的内容
图3. Bug的一生
上述都是在测试服务器上，连接的线下数据库进行测试，主要是对系统和项目进行测试，开发者修改bug。在测试环境完成测试后，进入沙箱环境进行测试，预上线，主要是主流程的走查，数据的流转以及校验，连接的是线上数据库，所以要谨慎操作，防止影响线上带来事故。
5、 上线
沙箱测试完成后进行上线。
主要参与项目和需求：
1、 搜索测试工具完善：测试组提供的工具
搜索在服务优化时，需要保证搜索结果的差异在可控范围内，所以提供测试工具验证差异范围。一是主搜接口的新老策略下，召回结果的差异比；二是新旧ES索引下验证商品数据是否一致。通过完善该测试工具，熟悉搜索推荐测试工具编写流程，熟悉了项目各层之间的调用关系和配置文件的配置过程；
2、 基础服务接口：zzLabel一部分接口测试
先修改host，然后初始化服务，实例化对象，最后编写测试用例。通过该需求，熟悉编写简单接口测试用例，构造入参，使用断言判断出参是否正确；
3、 账单3.0：资金与对账管理系统
主要负责了商品对账、售后对账、提现对账三部分的用例编写和测试。根据测试用例，构造测试需要的数据进行测试。通过这个项目，熟悉了大项目的项目流程和测试流程，熟悉web系统功能测试用例编写，学会定位问题。每日进行的站会要对各个方向进度进行汇总，同步进度，测试阶段有阻碍的点及时抛出，优先解决。
实习的一些改进想法
在测试账单3.0时，因为对需求不够熟悉，加上第一次编写较多的测试用例，很多场景没有考虑到，用例覆盖的不够全面。因为前期并没有做好这一点，由于对需求和数据不够熟悉，导致后面测试进度较缓慢，没有明确的测试流程。测试需求时，第一步要熟悉需求，熟悉需求关联的业务，熟悉流程和数据，编写覆盖率高、简洁清晰并且执行力高的用例，测试时按照用例顺序进行测试，避免出现bug重复提交的错误，及时标记，明确测试进度。
发现bug时，最基本的是要定位前端还是后端，后续应该做到结合日志定位到具体代码模块，定位具体错误原因，了解RD和FE的开发规范和思路。
在测试时，也应该提高自己的沟通技巧，尽量简单清晰的描述问题。
end