入行测试已五年有余，前三年干的是测试用例翻译为自动化用例脚本，分析失败用例找BUG。之后至今做的手工测试，空闲之余自己研究搭建接口测试框架。接下来聊聊每段经历自己的一些体验。
初入自动化测试
要说为何最初选择了自动化测试，因为当时毕业对自己编程能力不够自信，没选择干开发，就选择了测试。再来看要用到语言写脚本，也不算荒废编程（现在看来，是荒废了），所以就这么入坑了。
说一下项目背景，是通信行业的基站系统，有硬件和软件测试，我做的是外包出来的软件自动化测试。项目的自动化测试框架都是现成的，用的TCL语言（不通用），要做的也就是不断的往里面加用例脚本。出现公共的可复用的业务提取出来实现公共函数用于单个用例中去调用。基础配置文件，数据文件，业务代码是分类规划的。
一个用例的流程：登录--->实现业务预置条件--->业务流程执行及检查点设置--->恢复环境（增加的要删除，恢复初始设置）--->退出登录。
完成的用例会将用例编号写入文件，再由工具来调用执行，都是晚上跑，白天分析执行结果。任务的调起还有专职人员来做。
工作的绩效考核主要看脚本数量，提BUG数量。每天疲于应对KPI，每天都处于一种忙碌的状态，而这样工作的意义在哪里，没有仔细思考过。后来经历了一次裁人风波，我因为工作时间久点，业务知识熟悉，而留了下来。
之后有了个新项目，是用python语言实现的测试框架，同样也是框架现成，只需要会使用。学习了一下python的基础语法，就开始上手了。现在想来遗憾的是，当时没有意识到应该好好研究一下这个框架底层的东西（这个项目不像TCL语言的那个底层代码不可见）。
接口测试
做了三年的用例翻译后，因个人原因离开了这份工作，换了个城市，也换了测试的行业方向。测过了WEB网站、APP、H5页面、小程序，这期间也接触了接口测试。
最初了解的接口测试是报错时浏览器上按F12，查看是否是接口返回的报错，来判断是前端还是后端的问题。使用抓包工具抓取消息后，修改请求参数后发送。
公司业务提供三方接口（支持JAVA、PHP）供客户使用，所以接触了在IDEA（java编程语言开发的集成环境）中配置SDK包，在开发提供的测试DEMO中去测试接口。为什么不使用PostMan或Jemter测试工具呢，是因为它复杂的签名验证算法，在接口测试工具中难得搞。之后因为签名难，校验难，新功能客户要手动更新SDK包等问题，开发了新的接口，可以直接用http发起请求，易于自行实现签名校验和接口跨平台化。签名简化后就使用了接口测试工具来测试。
在本地部署（不想数据保存在公司方的服务器上，就把项目部署到客户方的服务器上）项目中因为签名验证算法简单，所以有使用PostMan或Jemter来测试。
在使用工具来做接口测试的过程中，有感觉到重复劳动，所以萌生了做成自动化的接口测试。在网上搜索了一番后，我决定用python+requests+unittest来做。
简要介绍一下目录结构，之后另写一篇来详细介绍具体实现。
Common---放可以提取出来共用的
Config---配置文件
Data---构造测试数据的文件
Report---调哪些测试用例执行，生成测试报告
Testcase---测试用例，按模块划分
生成的测试报告展示：
报告内容展示：
