我从事了11年的软件测试工作

一篇工作汇总，关于团队融入、需求业务、测试用例、执行结果、沟通过程、经验总结、上线最容易出现问题的总结 、工具使用（charles、jmeter、postman、开发工具、Python）

团队融入

1. 熟悉相关项目人员、项目内容
2. 熟悉业务、进行测试及相关分享、历史资料阅读和总结
3. 分析和总结业务及问题
4. 建立环境&数据信息&测试总结（小程序、web、及数据库、跳板机、VPN、工具包）
5. 团队的协作过程，寻找相关人员，沟通表达来意

需求业务

1. 快速熟悉业务–会对业务讲解进行录屏
2. 沟通业务问题，确认问题（讲解业务过程中及会议结束后抛出疑问）
3. 推动问题、跟进问题（疑问的抛出，追问及解决）

测试用例

1. 根据业务需求写测试用例（SIT测试用例、UAT测试用例）
2. 提炼通用性测试用例（通用）
3. 写测试用例的方法与总计
4. 使用场景法：整个业务的连接性，以及非测试人员（如产品、运营、客户）也能看懂并且能上手执行的测试用例
5. 测试点输出法：上面先将场景写出来以后，按照每个模块，每个页面，每个细节节点进行扩展与补充；如模块分为ABC，ABC模块分为A1/A2/A3页面，再按照页面的前后左右来写测试点，按照等价类、边界值、异常、兼容性、设计稿还原度等进行输出测试用例
6. AI辅助–根据需求生成测试用例，核对测试用例+修改，效率提升50%

🔵测试用例生成 / 优化（最常用）prompt

执行结果

1. 确认测试环境，确认开发版本，确认提测时间
2. 执行测试用例，记录执行过程（提缺陷记录：bug、需求、优化、建议、历史问题）
3. 关闭缺陷、跟踪问题，推进问题到闭环
4. UAT确认提交、确认范围
5. 闭环输出测试结果

沟通过程

PM

1. 与PM沟通工时，提测时间，任务安排
2. 闭环同步，日报同步

沟通模板：🔵PM关心的测试价值

需求

1. 与需求沟通业务系统、涉及的业务、及需求中的业务细节，如文案提示、异常处理、字体长度、流程等
2. 跟进和推送需求确认

沟通模板：🔵BA需求分析师关心的测试价值

开发

1. 与开发沟通业务功能、测试范围影响范围、测试点、工具+环境
2. 缺陷的确认：bug、优化、建议、需求
3. 缺陷的描述：标题+复现步骤+截图+接口cURLbase
4. 推送开发解决问题-闭环问题

沟通模板：🔵开发关心的测试价值

经验总结

1. 业务及测试经验文档输出总结(根据业务来输出)
2. 记录数据库sql执行及使用情况（专用sql记录）
3. 删除账号等脚本（操作步骤）
4. 上传本次测试文件及相关业务内容
5. 测试经验库，问题记录（最容易出现兼容性问题的机型、UI看重问题、UI最容易出现的问题、）
6. 影响测试质量库，问题记录（需求未考虑、需求不清晰、开发问题（未开发、需求未确认等待测试来确认）、提测延期、提测主流程不通过、开发未自测、等）
7. 线上缺陷分析库,问题记录（问题描述、问题原因、分析、根因、解决方法、品牌影响）

工具使用（chals、jmeter、postman、开发工具、Python）

1. 工作中熟练使用chals抓包工具（安装到手机上、IOS手机不支持就先把证书在微信中存储，再进行安装），对接口 进行抓包分析，request请求，response请求，抓包请求和响应的断点拦截，修改参数等
2. 工作中熟练使用jmeter工具（安装jmeter工具到电脑中，进行压测）
3. jmeter方案梳理—通用用模板
4. 压测方案—跟PM，开发，业务对齐（混合场景量和单接口场景的占比）
5. 压测脚本输出
6. 压测报告输出—通用模板
7. 压测汇总总结

3、postman，CURL的接口调用和测试

1. 测试接口的业务流程（按照业务流程来传递参数、token的公用）
2. 单接口的测试（等价类、边界值、异常和正常的状态码）

4、各种小程序的工具包运行，检测设计稿还原度（字体、字号、上下左右边距、色号、像素值）

开发者工具：小红书、Baidu、抖音、jd、微信开发工具

5、使用Python开发代码，部署服务器中搭建接口测试平台

1. Python+pytest，搭建公司的测试平台快速部署
2. 业务的接口自动化验证测试，定时任务接入企业微信，每天自动跑脚本
3. UI自动化，微信小程序的云测平台，云测平台生成多条主流程测试用例，定时任务接入企业微信，每天自动跑脚本
4. 在平台中如（Meterspace），搭建公司的测试接口自动化
5. 业务的接口自动化验证测试，定时任务接入企业微信，每天自动跑脚本
6. 熟悉业务场景，API接口之间的传参、公共属性、公共token、公共环境变量、公共文件

手搓python实用小工具

1. 针对库存查询工具（web页面，部署在公司服务器中，定时任务企业微信）
2. 性能计算工具（web页面，部署在公司服务器中）
3. 图片对比工具（web页面，部署在公司服务器中）
4. 文字生成统计工具（web页面，部署在公司服务器中）
5. ai手工用例工具（根据需求+测试用例知识库，生成测试用例）
6. ai测试用例知识库生成测试用例
7. 使用Python脚本抓取线上缺陷任务看板的内容

上线最容易出现问题的总结

1. 体验版老版本本线上版本，连最新的生产后台
2. → 问题：体验版与生产后台版本不一致，使用了未同步更新的旧版本体验版直接上线，导致与最新生产后台逻辑不兼容，出现功能异常。
3. 体验版老版本不升级，业务的影响范围
4. → 问题：体验版长期停留在旧版本未升级，未充分评估其对全链路业务的影响范围，导致上线后出现连锁业务故障。
5. 配置开关、开启和关闭的业务影响范围
6. → 问题：对配置开关的开启/关闭逻辑、业务影响范围和边界条件测试不充分，上线后开关切换导致业务流程异常。
7. 漏测及没想到的点
8. → 问题：测试用例设计不完整，遗漏了关键业务场景、边界条件或异常分支，导致上线后出现未被覆盖的问题。
9. 偷懒未测的点
10. → 问题：因主观懈怠或时间压力，主动跳过了部分必要的测试环节（如回归、性能、兼容性），导致风险未被提前发现。
11. 粗心未测试的点
12. → 问题：因疏忽或流程不严谨，未执行已规划的测试用例，导致本应发现的问题被遗漏。
13. 测试环境与生产环境不一致：配置、依赖服务版本、数据量、网络策略等差异，导致测试通过但上线后异常。
14. 数据迁移/历史数据兼容性问题：新功能上线时，数据迁移脚本、历史数据格式兼容、脏数据处理未充分测试。
15. 依赖服务/第三方接口未同步变更：上下游服务、第三方接口（支付、物流等）变更未同步，测试未覆盖新逻辑。
16. 回归测试不充分：只聚焦新功能，忽略对老功能、核心链路（如订单、支付）的影响，导致老功能异常。
17. 性能/容量测试缺失：大促、高并发场景下的性能瓶颈、数据库锁、接口超时等问题，未做压测或压测不达标。
18. 兼容性测试不足：不同浏览器、设备、操作系统、APP版本的兼容性问题（尤其前端渲染、交互）。
19. 灰度发布/回滚方案未验证：灰度策略、回滚脚本、降级预案未测试，出问题时无法快速恢复。
20. 监控与告警缺失：关键业务指标（成功率、耗时、错误率）、日志监控未配置或不生效，上线后无法及时发现问题。
21. 权限与安全测试遗漏：数据权限、接口防刷、SQL注入、XSS等安全风险未覆盖，导致数据泄露或被攻击。
22. 跨团队协作依赖未对齐：其他团队（如运营、运维）的配置、规则变更未同步，测试未覆盖联动场景。
23. 上线文档/配置项错误：部署文档、环境配置、开关配置等存在错误，导致部署失败或功能异常。
24. 极端/异常场景未测试：网络超时、数据库宕机、服务雪崩等极端场景下的降级、熔断、重试逻辑未验证。