按照阶段分解,产出不同的产物
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 库去做相似度对比(相似度可以设置一定阈值),但是领导太固执,非要在短时间内搞重构。。实在没办法,只有走人了,走之前把相似度对比的脚本输出给他们了。。
在武汉,这个待遇还可以的~!
貌似待遇不错~!
薪资福利谈不上丰厚,当然技术要求不算高。