按照阶段分解，产出不同的产物
01_计划阶段：测试计划、WBS、评审
02_分析阶段：需求测试、测试设计（测试方案）、测试用例、评审
03_执行阶段：冒烟测试、测试用例执行记录、执行日报
04_评估阶段：测试报告、测试准出条件
05_结项阶段：总结、漏测分析、遗留问题评审
06_支持过程：。。。

当然各个关于 bug 定级标准、测试准入、准出标准等等都应该在里面。

19 年的时候做了同样的事情，实现方式都一样，不过我们当时配合了接口自动化测试做的，相对更便捷一点儿，例如：
1、动态 mock 管理；
2、实现 mock 返回值的动态修改（当然目前很多 mock 可以通过规则匹配实现动态返回）；
3、实现动态增加 mock 接口；
4、通过 jmeter+Java+mock 平台 +Jenkins 实现接口自动化以及测试报告推送微信公众号等功能；
5、集成其他测试小工具：MD5、json 格式化、kafka 消息推送/消费 等等。

数据清理、接口依赖等场景在接口测试中经常碰到，做法可能有多种，满足自己的需求即可：
1、随机生成一些数据，保证每次接口请求参数不一样（适合测试环境）；
2、setup、test、teardown 三段式的方式清理数据，可以每个 testcase 清一次，也可以是 testsuit 清理一次；
3、数据库备份还原方式，通过 sql、dump、或者镜像方式都可以，在每次执行自动化测试之前初始化。

是的，我给的方案，先判断 404、500，如果不是还会判断是否有些关键字，比如 Error、Exception，如果没有就进行相似度对比，相似度达到一定程度，就认为通过。

UFT 或是一个不错的选择。

在上家公司碰到过类似问题，进去之后接手了一个 RTF 框架写的接口测试用例（10000+ 的用例库，一家做 GIS 的还比较不错的公司，涉及到很多瓦片数据），断言方式全部是全量断言，并且字段非常多（没有使用关键字断言），而断言里面有个别字段是变化的，这样就导致每次跑完用例（2 天时间），就会出现 2000 多个失败用例，每跑一次需要人肉花费 3 个工作日去排错（因为有些是因为返回变了，有些确实是有问题，如：404、500），当时给领导提了建议使用 jieba 库去做相似度对比（相似度可以设置一定阈值），但是领导太固执，非要在短时间内搞重构。。实在没办法，只有走人了，走之前把相似度对比的脚本输出给他们了。。

在武汉，这个待遇还可以的~！

貌似待遇不错~！

薪资福利谈不上丰厚，当然技术要求不算高。