文章目录
- 简介
- 测试前
- 测试理论
- Showcase 或者冒烟 case
- 配置变更提醒
- 业务知识
- 测试环境维护
- bug 管理平台
- 资损防控
- 测试中
- 测试工具能力
- 接口自动化
- WebUI 自动化
- APPUI 自动化
- Monkey 测试
- 压力测试
- 流量录制回放
- 代码覆盖率检测
- 精准化测试
- 单元测试
- 安全测试
- 测试后
- 静态代码扫描
- CR
- CI/CD
- 监控告警
- 度量平台建设
- 质量度量和运营
- 质量报告
- 线上问题跟进
- 事故定级标准制定
简介
测开所需要的能力范畴
更新中…
测试前
测试理论
各种测试专业名次：集成测试，系统测试，灰度，白盒黑盒等，以及各个阶段流程该做什么，可能会有什么样的风险
Showcase 或者冒烟 case
组织发起，需要让研发进行冒烟执行或者通过 showcase 会议的形式
这个常常和测试准入准出规定相联系，可能不同部门会制定提测准入和准出的标准如何
配置变更提醒
配置变更就会带来风险，配置变更可以做些规范或者自动触发审批人的机制
业务知识
业务知识，知道业务整体流程，以及每个环节的痛点难点以及容易出错的地方
不同的业务方向，内容差别较大，但是不同业务方向也有会较为相似的通用知识
测试环境维护
环境染色，知道测试环境如何部署，有哪几种测试环境，测试环境，预生产环境，生产环境
了解测试环境的是如何部署的，如果构建
bug 管理平台
免费的有 jira/禅道，各个公司可能有自研，但是使用方式大同小异
资损防控
测试中
测试工具能力
自动化框架：selenium/appium/httpclient/requests/rest-assured等
抓包工具：charles/fiddler/wireshark
接口工具：jmeter/postman/loadrunner
开发框架：vue/react，springboot/gin/django
用例工具：xmind/excel
管理平台：jira/禅道
语言：主流 java/python/shell，次主流
版本管理：git/svn
js/golang/kotlin/c#
运维工具：grafana
cicd：jenkins/docker/k8s
研发组件：mq：kafka/rocketmq/rabbitmq，db：mysql/mongodb/clickhouse/redis/hive，微服务：springcloud/thift/protobuf
其他一些技术基本原理
接口自动化
java 的有 httpclient 库 + testng/junit，可能也有很多公司在用一些开源的其他各种框架，种类较多，也有可能在自研一些框架。也有一些公司用 postman 或者 jmeter 来做了，这些都是免费的
python 的话有 requests 库
WebUI 自动化
基本 selenium + testng/junit 是业内最常见的，必掌握
APPUI 自动化
基本 appium + testng/junit 是业内最常见的，必掌握
Monkey 测试
压力测试
常见的工具有 jmeter，大公司会有自研的压测平台
流量录制回放
较大的公司会自研这样的平台服务，供公司使用
代码覆盖率检测
精准化测试
单元测试
一般都应该由 rd 来开展以及进行，有的公司 qa 会参与进去，是可以的，但是难点是 qa 没有 rd 熟悉，但是可以做些组织协调目标制定等，更多可能是协助作用
安全测试
测试后
静态代码扫描
中小公司可能没有这项能力，也可能借用开源工具，大公司可能有自己的自研产品
CR
和 rd 一起安排 cr 时间，qa 可以参与进去
CI/CD
流水线上线，小公司可能有运维团队支持，qa 最好也参与进去，大公司有相应的流水线开发，qa 参与进去
监控告警
rd 为主进行监控观测，qa 为辅协助
监控告警平台的搭建一般由 rd 或者相应运维支持，qa 可以考虑参与建设
度量平台建设
度量平台，qa 如果有能力以及在小公司可能是 rd 或者测开做，大公司有专门研发开发
质量度量和运营
质量度量和运营往往要借助度量平台的数据，来进行一定时期的总结分析，然后总结规律得出结论，知道哪里薄弱，需要加强哪里，从而加强后续流程
质量报告
质量报告一般在一个项目结束之后产出，给群组哪人员阅览，观察项目整体质量情况
月度或者双月总结的时候也会有一些质量报告产出
质量报告中往往含有对过去的分析（可能包含多种视图分析）以及得出结论，对未来建设的规划
线上问题跟进
线上问题，研发最容易先定位，qa 同学协助参与
小型公司可能有开发 + 运维为主，qa 为协助
大公司可能运维流程很完善，业务的内容研发为主，qa 为协助
事故定级标准制定
事故定级，一般小公司可能由产品 + 研发 + qa 的各个领导一起来规划制定，大公司可能会设置有专门的风控部门来专门整理这块
因为本质来说交给产品/研发/qa来制定都不合适，因为事故会影响三方的利益，所以各方制定时候可能存在私心，所以建议由另一方风险控制部门专门管理控制，保证各方标准能够统一以及公正
