尧图网站建设 
简介《软件测试培训讲义》是一份系统梳理软件测试基础理论与方法的PPT课件适合软件测试初学者、开发人员在课程教学或企业培训中快速建立测试知识框架。课件从测试的目的与重要性讲起引用历史上因编程错误导致重大事故的案例阐述测试开销大、无法穷举、难度大等核心特点并给出测试的基本原则与从模块测试到安装测试的完整步骤。测试方法部分重点讲解静态分析与动态测试两类手段其中白盒法按语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖等标准逐一展开并结合程序段示例演示测试用例设计过程。资源为1个PPT文件压缩包大小2.76MB已有86人学习适合需要系统夯实软件测试理论并理解测试用例设计方法的读者下载参考。1. 软件测试培训讲义.ppt从翻完课件到真正测出问题软件测试培训讲义.ppt 这个文件名在网盘里流通的版本多到数不过来面试突击的应届生下载过转岗两年的开发看过给组内新人做内训的测试组长也存过。大多数人的学习停在“讲义翻完”这一步撑过面试不难真正上岗后写用例、提缺陷、跑回归、定位问题每一环都和 PPT 上的箭头图隔着一段距离。这份讲义是给想真正上手的人准备的先把测试的认知基线立住再把用例设计、自动化执行、专项测试逐项落到可复现的操作上最后用一组高频面试题验证吸收度。看完不用背照着做一遍它就从课件变成工具。2. 软件测试的认知基线流程、类型与测试计划2.1 从V模型到敏捷测试流程为什么要提前介入第一次正经做测试培训的人几乎都会把 V 模型放前面。左侧是需求分析、概要设计、详细设计、编码右侧是单元测试、集成测试、系统测试、验收测试中间由一条“早准备、晚执行”的线连起来。它最大的贡献不是那张弓形图而是让你记住测试活动应该在设计阶段就启动而不是等代码提交后才开始。缺陷发现得越晚修复成本越高这个成本在 V 模型上体现为大致的指数增长。需求阶段的歧义可能要等系统测试才发现改动涉及多个模块而单元测试阶段发现的逻辑错误通常只影响一个函数。敏捷模式把 V 模型压缩成迭代但原理没变——每个冲刺内需求分解完就写测试用例编码完成前先准备测试数据。提示如果只看一页讲义就开工最常见错误是流程倒挂。冲刺刚开始就闷头写自动化脚本等提测时才回去翻需求文档。我一般建议在需求讨论阶段只带一个核心问题验收标准是什么。答案明确后用例和脚本都从这个标准长出来。2.2 测试金字塔与测试类型图谱7:2:1 的资源分配依据测试金字塔告诉你资源怎么分。底座是单元测试数量最大、跑得最快中间是服务层测试覆盖接口协议和业务逻辑顶部是 UI 端到端测试数量最少。经典配比是 7:2:1。这份讲义真正要劝住的只有一条不要把所有自动化都压在 UI 上——一次页面重构就能让几十条 UI 用例集体失效而接口用例几乎不受影响。类型图谱方面功能测试之外还有一整套非功能测试。银行软件测试里账务准确性再高并发高峰扛不住一样出事故嵌入式软件测试里功能通过内存泄漏也能让设备运行三天后死机。这张表里列的是培训讲义必须讲清的基础类型。测试类型关注点常用工具/手段性能测试响应时间、TPS、资源占用JMeter、Locust、Grafana安全测试越权、注入、敏感信息OWASP ZAP、Burp Suite、代码扫描兼容性测试浏览器、设备、分辨率Selenium Grid、云真机平台可靠性测试长时间运行、故障恢复混沌工程、Monkey、监控告警线上出问题的事件里相当一部分不是功能 bug而是非功能需求没定义清楚。“支持 5000 用户在线”到底是同时在线还是并发操作峰值持续 5 分钟还是 30 分钟这些参数写不清楚性能测试没法做。2.3 测试计划的五个要素范围、排期、准入、准出、风险软件测试流程走到项目层面第一份要写的文档是测试计划。测试计划是顶层文档不止给领导看也用来约束测试自己。五个要素必不可少范围、排期、准入条件、准出条件和风险。要素要回答的问题建议写法范围测什么、不测什么列出被测模块与明确排除项排期多少人、多少天按功能拆分预留缓冲准入条件什么状态的版本可以开始测提测单、冒烟通过率准出条件测到什么程度才能放行用例执行率、缺陷清零标准风险什么会让计划失效依赖的第三方、数据、环境实践上准出条件最容易被人为放宽。用例执行率 100%、致命和严重缺陷清零、遗留缺陷的严重度与数量在阈值内这三条是底线。如果发版节奏很赶至少保留第一和第二条。把退出标准写进计划的价值在于领导来催时你能拿数据而不是感觉说话。3. 软件测试用例设计与缺陷管理把经验变成可复现资产3.1 等价类与边界值用最少用例覆盖最大输入空间用例设计是所有测试技能里最容易被低估的一项。自动化脚本只是放大执行效率策略本身还是靠用例设计。等价类划分的核心是“同一类输入等价”从中选一个代表值测试就能代替一整类数据。以“用户名由 6-20 位字母或数字组成”为例有效等价类是长度 6-20 且只含字母数字的组合无效等价类至少有三类长度小于 6、长度大于 20、含字母数字以外的字符。边界值是和等价类配合使用的方法。大量缺陷集中在边界上所以取边界及边界两侧的值单独设计用例。6-20 位的字段要测 5、6、20、21 四个值再加上空值。别小看空值HTTP 接口里空字符串和字段缺失往往是两种表现。编号输入预期结果EC-01abc1236位字母数字通过EC-02abc3位提示长度不符EC-0321位字母数字提示长度不符EC-04user_name含下划线提示只能包含字母或数字EC-05空值提示用户名不能为空BV-01123455位边界下侧应通过BV-021234566位边界值应通过BV-0320位数字边界值应通过BV-0421位数字边界上侧应拒绝3.2 判定表与场景法把多条件组合讲成一张表单个字段用等价类多个条件组合时用判定表。以电商下单为例三个条件订单金额是否满 300、是否会员、金额是否满 99。动作有减 50、会员 9 折、免运费。把条件的真/假和动作画成判定表能保证组合不遗漏。条件/动作规则1规则2规则3规则4规则5规则6订单满300TTFFFF会员TFTFTF金额≥99--TTFF减50✓✓----会员9折✓-✓-✓-免运费✓✓✓✓--这里规则 1 和 2 中“金额≥99”因为满 300 自动成立写“-”表示不关心。场景法适合流程性功能注册、下单、审批。用“基本流备选流”把主流程和异常分支串起来每个分支对应一到两条用例。设计时先画流程线再套数据比盯着界面想到哪算哪完整得多。3.3 缺陷管理可复现是缺陷的灵魂优先级不等于严重程度缺陷报告写到什么程度直接决定修复效率。标题要能一眼看出模块和现象正文写环境、版本、前置条件、复现步骤、实际结果、期望结果。复现步骤用编号列表每一步包含具体操作和数据尽量不带“可能”“大概”这种词。字段填写要点标题模块现象例如“订单列表-导出Excel时日期列排序错乱”环境/版本操作系统、浏览器、构建号前置条件登录身份、测试数据准备状态复现步骤编号列表每一步可执行实际结果观察到的现象含错误码/截图期望结果需求规定的正确表现严重程度/优先级S1-S4 / P1-P4严重程度和优先级是两个维度严重程度指对系统的影响S1 崩溃、S2 主要功能不可用、S3 一般、S4 建议优先级指修复顺序P1 立即、P2 尽快、P3 正常、P4 低。一个不影响主流程的错别字可能是 S3/P2一个只在特殊配置下触发的致命错误可能是 S1/P2。开发抱怨测试“乱提 bug”大多是把优先级别写对了严重程度却拔高了。提缺陷时顺手附上日志或抓包信息比在群里喊十句“必现”都管用。我一般会把接口请求和响应贴到附件里涉及前端则补一张截图偶现问题记录当时的机器状态、网络、数据规模这些信息能帮开发快速缩小排查范围。4. 软件测试自动化落地从接口用例到UI回归4.1 自动化选型回归密集且链路稳定的场景才划算自动化不是越早越好。刚启动的项目原型天天改UI 自动化脚本改到怀疑人生需求冻结、回归频繁的阶段才是自动化的主战场。单元测试交给开发测试团队重点做接口自动化和关键路径 UI 回归。判断标准很简单这条用例要重复执行多少次每次手工执行是否超过五分钟答案是肯定的才值得写脚本。接口自动化比 UI 自动化性价比高一个量级执行快、环境依赖少、定位废手指。很多软件测试项目实战培训实际上就是用 pytest 把 10 到 20 个接口用例跑通再往上加一层数据断言。场景优先级推荐手段接口回归高pytest requests关键路径 UI 回归中Selenium 显式等待测试数据造数中pytest fixture兼容性冒烟低Selenium Grid / 云真机4.2 pytest与requests最小可运行的接口测试用例入门最小方案是 pytest 加 requests不需要额外框架。先写一个最简单的登录接口用例。# test_login_api.py import requests BASE_URL http://127.0.0.1:8000 def test_login_success(): resp requests.post( f{BASE_URL}/api/login, json{username: tester01, password: Passw0rd!}, ) assert resp.status_code 200 data resp.json() assert data[code] 0 assert data[data][token]逻辑说明第一条断言管 HTTP 状态码看链路通不通第二条断言业务码看业务成不成功第三条断言 token 是否返回。只断言状态码会漏掉大量业务错误。跑这条用例只需要一条命令。pytest test_login_api.py -v参数说明-v输出每条用例的执行结果断言失败时能直接看到是哪个字段没满足。如果环境里还没装依赖先执行pip install pytest requests再跑。4.3 Selenium做UI回归显式等待是唯一的等待方式UI 自动化在测试金字塔顶端数量要少但路径要关键。登录、购物车、支付这类主流程值得写。最容易踩的坑是等待用time.sleep(3)猜加载时间网络一波动就挂。替代方案是显式等待等元素出现再继续。# test_login_ui.py from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def test_login_ui(): driver webdriver.Chrome() try: driver.get(http://127.0.0.1:8000/login) driver.find_element(By.ID, username).send_keys(tester01) driver.find_element(By.ID, password).send_keys(Passw0rd!) driver.find_element(By.ID, submit).click() WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, welcome)) ) assert tester01 in driver.page_source finally: driver.quit()逻辑说明用户名字段用 ID 定位点击提交后用 WebDriverWait 轮询最多 10 秒等待欢迎区域出现轮询间隔默认 500 毫秒出现后断言页面包含用户名。quit()写在finally里用例失败时浏览器也能关掉避免进程残留。要跑通这段代码需要预先装好selenium并保证 Chrome 版本与 ChromeDriver 匹配——UI 自动化最大的成本是环境脚本本身反而是小事。自动化脚本的价值在反复执行。接入持续集成后每天凌晨跑一遍接口用例早上到岗直接看失败列表。GitLab CI 里加一个自动化 stage拉代码后装依赖再执行 pytest报告归档到 runner。这一层不复杂但能逼着团队保持用例干净。5. 软件测试专项实战性能、安全与行业场景5.1 性能测试先想清楚指标并发、TPS与响应时长性能测试开始的信号不是“压一下”而是产品把指标写进需求了。常见的三个指标并发数、TPS、响应时间RT。并发数不是同时在线人数而是同时发起请求的活跃连接。在线用户可能几分钟才操作一次不能直接当并发用。经验上把同时在线数乘以 2%-8% 作为预估并发具体看业务类型但没有万能系数最终还是要做一次摸底压测。TPS 和 RT 互相拖累。系统接近处理上限时RT 会突然变长错误率开始抬头。压测要优先观测 P90 响应时间也就是 90% 的请求低于该值比平均值更能体现大部分用户的真实体感。5.2 JMeter基础压测GUI调脚本命令行跑量JMeter 还是投入产出比最高的压测工具。做法分两步先用 GUI 录制或手写一个线程组脚本加一个聚合报告监听器在本地用小并发调通脚本正式压测换成命令行避免 GUI 占用资源干扰结果。jmeter -n -t login_scenario.jmx -l result.jtl -e -o ./report参数说明-n表示非 GUI 模式-t指定测试计划文件-l输出原始结果文件jtl-e生成 HTML 统计报告-o指定报告输出目录要求目录不存在或为空。结束后打开./report/index.html重点看三个汇总响应时间百分位表、TPS 吞吐量曲线、错误率。指标参考值异常迹象错误率 1%从 0 突然涨到 5% 以上先确认是超时还是断言失败P90 RT对照业务指标随并发线性上涨说明压力传递正常TPS对照硬件与应用类型到峰值后不涨反跌系统已达瓶颈如果错误率超过 1%先查是断言失败还是连接超时两者问题边界完全不同。断言失败多半是业务逻辑或数据问题连接超时则要优先看网络和连接池配置。5.3 行业场景银行与嵌入式的测试差异银行软件测试的难点在业务规则和数据迁移。账务类功能必须对金额精度、幂等性、对账逻辑做专项设计测试数据要覆盖整批迁移后的余额一致同时还有大量报表和权限测试。嵌入式软件测试则要处理交叉编译和硬件依赖内存泄漏、串口日志解码、异常断电恢复比功能本身更值得写用例。这两个方向的共同点是都依赖领域知识但底层能力还是前面几章的用例设计与缺陷管理。全国大学生软件测试大赛这类实战比赛也是用真实系统考察这些基本功。转行者不用被“银行测试”“嵌入式测试”吓到先把手头项目的接口和 UI 用例跑顺再补行业专属维度。6. 软件测试面试与技能自检用八个问题验证讲义吸收度6.1 面试八问先答覆盖度再看深度问题自检要点什么是等价类划分能现场说出有效/无效等价类示例边界值为什么重要能解释缺陷集中分布的原因并举例用例包含哪些要素能写出前置条件、步骤、预期结果严重程度与优先级区别能给出一个“S1/P2”的实例如何保证用例覆盖率会从需求拆分功能点再逐项设计自动化能替代手工吗能说出金字塔比例与不刷覆盖率的理由接口测试断言什么状态码、业务码、业务数据三层发现偶现 bug 怎么办保留现场记录环境与数据扩大观测这八问基本覆盖了入门岗位的面试范围。回答时不用背定义拿自己写过的用例讲一遍当时需求是什么、怎么划分、缺陷在哪一步发现。面试官要听的是解题路径不是教科书原话。那类被调侃为“八股文”的测试理论核心也是这套体系换了个说法而已。6.2 把项目写进简历测试skill的使用要落到具体动作简历上的测试经历常见写法是“熟悉测试流程编写测试用例”这句话没有信息量。测试 skill 的具体使用要落到动作和结果上。用 STAR 结构写环境加数据才有说服力哪个系统的订单模块负责接口与 UI 回归设计了多少条用例自动化覆盖到什么程度累计发现多少有效缺陷。数字不需要多但一定要和业务有关联。提示一个干净的简历条目可以这么写—— 某订单系统测试项目独立完成 60 条接口用例与 12 条核心 UI 用例设计接口自动化覆盖率达 70%执行三轮回归累计提交有效缺陷 37 个其中 P1 缺陷 3 个。学完这份讲义不必急着到处搜面经先把上面的表格逐项过一遍写不出来的地方回到对应章节重做一次。下次再有人发来一份软件测试培训讲义.ppt你翻目录的时间就已经知道它差哪一章了。本文还有配套的精品资源点击获取 软件测试培训讲义：从测试用例设计到自动化与性能实战
简介《软件测试培训讲义》是一份系统梳理软件测试基础理论与方法的PPT课件适合软件测试初学者、开发人员在课程教学或企业培训中快速建立测试知识框架。课件从测试的目的与重要性讲起引用历史上因编程错误导致重大事故的案例阐述测试开销大、无法穷举、难度大等核心特点并给出测试的基本原则与从模块测试到安装测试的完整步骤。测试方法部分重点讲解静态分析与动态测试两类手段其中白盒法按语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖等标准逐一展开并结合程序段示例演示测试用例设计过程。资源为1个PPT文件压缩包大小2.76MB已有86人学习适合需要系统夯实软件测试理论并理解测试用例设计方法的读者下载参考。1. 软件测试培训讲义.ppt从翻完课件到真正测出问题软件测试培训讲义.ppt 这个文件名在网盘里流通的版本多到数不过来面试突击的应届生下载过转岗两年的开发看过给组内新人做内训的测试组长也存过。大多数人的学习停在“讲义翻完”这一步撑过面试不难真正上岗后写用例、提缺陷、跑回归、定位问题每一环都和 PPT 上的箭头图隔着一段距离。这份讲义是给想真正上手的人准备的先把测试的认知基线立住再把用例设计、自动化执行、专项测试逐项落到可复现的操作上最后用一组高频面试题验证吸收度。看完不用背照着做一遍它就从课件变成工具。2. 软件测试的认知基线流程、类型与测试计划2.1 从V模型到敏捷测试流程为什么要提前介入第一次正经做测试培训的人几乎都会把 V 模型放前面。左侧是需求分析、概要设计、详细设计、编码右侧是单元测试、集成测试、系统测试、验收测试中间由一条“早准备、晚执行”的线连起来。它最大的贡献不是那张弓形图而是让你记住测试活动应该在设计阶段就启动而不是等代码提交后才开始。缺陷发现得越晚修复成本越高这个成本在 V 模型上体现为大致的指数增长。需求阶段的歧义可能要等系统测试才发现改动涉及多个模块而单元测试阶段发现的逻辑错误通常只影响一个函数。敏捷模式把 V 模型压缩成迭代但原理没变——每个冲刺内需求分解完就写测试用例编码完成前先准备测试数据。提示如果只看一页讲义就开工最常见错误是流程倒挂。冲刺刚开始就闷头写自动化脚本等提测时才回去翻需求文档。我一般建议在需求讨论阶段只带一个核心问题验收标准是什么。答案明确后用例和脚本都从这个标准长出来。2.2 测试金字塔与测试类型图谱7:2:1 的资源分配依据测试金字塔告诉你资源怎么分。底座是单元测试数量最大、跑得最快中间是服务层测试覆盖接口协议和业务逻辑顶部是 UI 端到端测试数量最少。经典配比是 7:2:1。这份讲义真正要劝住的只有一条不要把所有自动化都压在 UI 上——一次页面重构就能让几十条 UI 用例集体失效而接口用例几乎不受影响。类型图谱方面功能测试之外还有一整套非功能测试。银行软件测试里账务准确性再高并发高峰扛不住一样出事故嵌入式软件测试里功能通过内存泄漏也能让设备运行三天后死机。这张表里列的是培训讲义必须讲清的基础类型。测试类型关注点常用工具/手段性能测试响应时间、TPS、资源占用JMeter、Locust、Grafana安全测试越权、注入、敏感信息OWASP ZAP、Burp Suite、代码扫描兼容性测试浏览器、设备、分辨率Selenium Grid、云真机平台可靠性测试长时间运行、故障恢复混沌工程、Monkey、监控告警线上出问题的事件里相当一部分不是功能 bug而是非功能需求没定义清楚。“支持 5000 用户在线”到底是同时在线还是并发操作峰值持续 5 分钟还是 30 分钟这些参数写不清楚性能测试没法做。2.3 测试计划的五个要素范围、排期、准入、准出、风险软件测试流程走到项目层面第一份要写的文档是测试计划。测试计划是顶层文档不止给领导看也用来约束测试自己。五个要素必不可少范围、排期、准入条件、准出条件和风险。要素要回答的问题建议写法范围测什么、不测什么列出被测模块与明确排除项排期多少人、多少天按功能拆分预留缓冲准入条件什么状态的版本可以开始测提测单、冒烟通过率准出条件测到什么程度才能放行用例执行率、缺陷清零标准风险什么会让计划失效依赖的第三方、数据、环境实践上准出条件最容易被人为放宽。用例执行率 100%、致命和严重缺陷清零、遗留缺陷的严重度与数量在阈值内这三条是底线。如果发版节奏很赶至少保留第一和第二条。把退出标准写进计划的价值在于领导来催时你能拿数据而不是感觉说话。3. 软件测试用例设计与缺陷管理把经验变成可复现资产3.1 等价类与边界值用最少用例覆盖最大输入空间用例设计是所有测试技能里最容易被低估的一项。自动化脚本只是放大执行效率策略本身还是靠用例设计。等价类划分的核心是“同一类输入等价”从中选一个代表值测试就能代替一整类数据。以“用户名由 6-20 位字母或数字组成”为例有效等价类是长度 6-20 且只含字母数字的组合无效等价类至少有三类长度小于 6、长度大于 20、含字母数字以外的字符。边界值是和等价类配合使用的方法。大量缺陷集中在边界上所以取边界及边界两侧的值单独设计用例。6-20 位的字段要测 5、6、20、21 四个值再加上空值。别小看空值HTTP 接口里空字符串和字段缺失往往是两种表现。编号输入预期结果EC-01abc1236位字母数字通过EC-02abc3位提示长度不符EC-0321位字母数字提示长度不符EC-04user_name含下划线提示只能包含字母或数字EC-05空值提示用户名不能为空BV-01123455位边界下侧应通过BV-021234566位边界值应通过BV-0320位数字边界值应通过BV-0421位数字边界上侧应拒绝3.2 判定表与场景法把多条件组合讲成一张表单个字段用等价类多个条件组合时用判定表。以电商下单为例三个条件订单金额是否满 300、是否会员、金额是否满 99。动作有减 50、会员 9 折、免运费。把条件的真/假和动作画成判定表能保证组合不遗漏。条件/动作规则1规则2规则3规则4规则5规则6订单满300TTFFFF会员TFTFTF金额≥99--TTFF减50✓✓----会员9折✓-✓-✓-免运费✓✓✓✓--这里规则 1 和 2 中“金额≥99”因为满 300 自动成立写“-”表示不关心。场景法适合流程性功能注册、下单、审批。用“基本流备选流”把主流程和异常分支串起来每个分支对应一到两条用例。设计时先画流程线再套数据比盯着界面想到哪算哪完整得多。3.3 缺陷管理可复现是缺陷的灵魂优先级不等于严重程度缺陷报告写到什么程度直接决定修复效率。标题要能一眼看出模块和现象正文写环境、版本、前置条件、复现步骤、实际结果、期望结果。复现步骤用编号列表每一步包含具体操作和数据尽量不带“可能”“大概”这种词。字段填写要点标题模块现象例如“订单列表-导出Excel时日期列排序错乱”环境/版本操作系统、浏览器、构建号前置条件登录身份、测试数据准备状态复现步骤编号列表每一步可执行实际结果观察到的现象含错误码/截图期望结果需求规定的正确表现严重程度/优先级S1-S4 / P1-P4严重程度和优先级是两个维度严重程度指对系统的影响S1 崩溃、S2 主要功能不可用、S3 一般、S4 建议优先级指修复顺序P1 立即、P2 尽快、P3 正常、P4 低。一个不影响主流程的错别字可能是 S3/P2一个只在特殊配置下触发的致命错误可能是 S1/P2。开发抱怨测试“乱提 bug”大多是把优先级别写对了严重程度却拔高了。提缺陷时顺手附上日志或抓包信息比在群里喊十句“必现”都管用。我一般会把接口请求和响应贴到附件里涉及前端则补一张截图偶现问题记录当时的机器状态、网络、数据规模这些信息能帮开发快速缩小排查范围。4. 软件测试自动化落地从接口用例到UI回归4.1 自动化选型回归密集且链路稳定的场景才划算自动化不是越早越好。刚启动的项目原型天天改UI 自动化脚本改到怀疑人生需求冻结、回归频繁的阶段才是自动化的主战场。单元测试交给开发测试团队重点做接口自动化和关键路径 UI 回归。判断标准很简单这条用例要重复执行多少次每次手工执行是否超过五分钟答案是肯定的才值得写脚本。接口自动化比 UI 自动化性价比高一个量级执行快、环境依赖少、定位废手指。很多软件测试项目实战培训实际上就是用 pytest 把 10 到 20 个接口用例跑通再往上加一层数据断言。场景优先级推荐手段接口回归高pytest requests关键路径 UI 回归中Selenium 显式等待测试数据造数中pytest fixture兼容性冒烟低Selenium Grid / 云真机4.2 pytest与requests最小可运行的接口测试用例入门最小方案是 pytest 加 requests不需要额外框架。先写一个最简单的登录接口用例。# test_login_api.py import requests BASE_URL http://127.0.0.1:8000 def test_login_success(): resp requests.post( f{BASE_URL}/api/login, json{username: tester01, password: Passw0rd!}, ) assert resp.status_code 200 data resp.json() assert data[code] 0 assert data[data][token]逻辑说明第一条断言管 HTTP 状态码看链路通不通第二条断言业务码看业务成不成功第三条断言 token 是否返回。只断言状态码会漏掉大量业务错误。跑这条用例只需要一条命令。pytest test_login_api.py -v参数说明-v输出每条用例的执行结果断言失败时能直接看到是哪个字段没满足。如果环境里还没装依赖先执行pip install pytest requests再跑。4.3 Selenium做UI回归显式等待是唯一的等待方式UI 自动化在测试金字塔顶端数量要少但路径要关键。登录、购物车、支付这类主流程值得写。最容易踩的坑是等待用time.sleep(3)猜加载时间网络一波动就挂。替代方案是显式等待等元素出现再继续。# test_login_ui.py from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def test_login_ui(): driver webdriver.Chrome() try: driver.get(http://127.0.0.1:8000/login) driver.find_element(By.ID, username).send_keys(tester01) driver.find_element(By.ID, password).send_keys(Passw0rd!) driver.find_element(By.ID, submit).click() WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, welcome)) ) assert tester01 in driver.page_source finally: driver.quit()逻辑说明用户名字段用 ID 定位点击提交后用 WebDriverWait 轮询最多 10 秒等待欢迎区域出现轮询间隔默认 500 毫秒出现后断言页面包含用户名。quit()写在finally里用例失败时浏览器也能关掉避免进程残留。要跑通这段代码需要预先装好selenium并保证 Chrome 版本与 ChromeDriver 匹配——UI 自动化最大的成本是环境脚本本身反而是小事。自动化脚本的价值在反复执行。接入持续集成后每天凌晨跑一遍接口用例早上到岗直接看失败列表。GitLab CI 里加一个自动化 stage拉代码后装依赖再执行 pytest报告归档到 runner。这一层不复杂但能逼着团队保持用例干净。5. 软件测试专项实战性能、安全与行业场景5.1 性能测试先想清楚指标并发、TPS与响应时长性能测试开始的信号不是“压一下”而是产品把指标写进需求了。常见的三个指标并发数、TPS、响应时间RT。并发数不是同时在线人数而是同时发起请求的活跃连接。在线用户可能几分钟才操作一次不能直接当并发用。经验上把同时在线数乘以 2%-8% 作为预估并发具体看业务类型但没有万能系数最终还是要做一次摸底压测。TPS 和 RT 互相拖累。系统接近处理上限时RT 会突然变长错误率开始抬头。压测要优先观测 P90 响应时间也就是 90% 的请求低于该值比平均值更能体现大部分用户的真实体感。5.2 JMeter基础压测GUI调脚本命令行跑量JMeter 还是投入产出比最高的压测工具。做法分两步先用 GUI 录制或手写一个线程组脚本加一个聚合报告监听器在本地用小并发调通脚本正式压测换成命令行避免 GUI 占用资源干扰结果。jmeter -n -t login_scenario.jmx -l result.jtl -e -o ./report参数说明-n表示非 GUI 模式-t指定测试计划文件-l输出原始结果文件jtl-e生成 HTML 统计报告-o指定报告输出目录要求目录不存在或为空。结束后打开./report/index.html重点看三个汇总响应时间百分位表、TPS 吞吐量曲线、错误率。指标参考值异常迹象错误率 1%从 0 突然涨到 5% 以上先确认是超时还是断言失败P90 RT对照业务指标随并发线性上涨说明压力传递正常TPS对照硬件与应用类型到峰值后不涨反跌系统已达瓶颈如果错误率超过 1%先查是断言失败还是连接超时两者问题边界完全不同。断言失败多半是业务逻辑或数据问题连接超时则要优先看网络和连接池配置。5.3 行业场景银行与嵌入式的测试差异银行软件测试的难点在业务规则和数据迁移。账务类功能必须对金额精度、幂等性、对账逻辑做专项设计测试数据要覆盖整批迁移后的余额一致同时还有大量报表和权限测试。嵌入式软件测试则要处理交叉编译和硬件依赖内存泄漏、串口日志解码、异常断电恢复比功能本身更值得写用例。这两个方向的共同点是都依赖领域知识但底层能力还是前面几章的用例设计与缺陷管理。全国大学生软件测试大赛这类实战比赛也是用真实系统考察这些基本功。转行者不用被“银行测试”“嵌入式测试”吓到先把手头项目的接口和 UI 用例跑顺再补行业专属维度。6. 软件测试面试与技能自检用八个问题验证讲义吸收度6.1 面试八问先答覆盖度再看深度问题自检要点什么是等价类划分能现场说出有效/无效等价类示例边界值为什么重要能解释缺陷集中分布的原因并举例用例包含哪些要素能写出前置条件、步骤、预期结果严重程度与优先级区别能给出一个“S1/P2”的实例如何保证用例覆盖率会从需求拆分功能点再逐项设计自动化能替代手工吗能说出金字塔比例与不刷覆盖率的理由接口测试断言什么状态码、业务码、业务数据三层发现偶现 bug 怎么办保留现场记录环境与数据扩大观测这八问基本覆盖了入门岗位的面试范围。回答时不用背定义拿自己写过的用例讲一遍当时需求是什么、怎么划分、缺陷在哪一步发现。面试官要听的是解题路径不是教科书原话。那类被调侃为“八股文”的测试理论核心也是这套体系换了个说法而已。6.2 把项目写进简历测试skill的使用要落到具体动作简历上的测试经历常见写法是“熟悉测试流程编写测试用例”这句话没有信息量。测试 skill 的具体使用要落到动作和结果上。用 STAR 结构写环境加数据才有说服力哪个系统的订单模块负责接口与 UI 回归设计了多少条用例自动化覆盖到什么程度累计发现多少有效缺陷。数字不需要多但一定要和业务有关联。提示一个干净的简历条目可以这么写—— 某订单系统测试项目独立完成 60 条接口用例与 12 条核心 UI 用例设计接口自动化覆盖率达 70%执行三轮回归累计提交有效缺陷 37 个其中 P1 缺陷 3 个。学完这份讲义不必急着到处搜面经先把上面的表格逐项过一遍写不出来的地方回到对应章节重做一次。下次再有人发来一份软件测试培训讲义.ppt你翻目录的时间就已经知道它差哪一章了。本文还有配套的精品资源点击获取