简介《软件测试课程设计.zip》面向计算机相关专业学生及软件测试入门者围绕JavaWeb网上书店前台系统提供一套可对照的课程设计材料解决测试用例设计、单元测试实施与性能测试落地等练习需求。压缩包共904个文件、约45.97MB包含jsp与java源码、class和jar编译依赖、xml配置、js/css页面资源以及大量gif、jpg界面截图便于还原系统结构与测试对象。已有2350人学习下载说明其在课程设计与测试练习场景中具有一定参考度。材料覆盖逻辑覆盖与基本路径测试的白盒用例设计等价类、边界值黑盒分析借助JUnit对核心功能开展单元测试并通过手工或自动化方式完成功能验证性能部分使用LoadRunner进行稳定性与逐步加压的压力测试可帮助读者理解最大服务级别判定思路并据此整理测试方案、用例与结果记录。1. 软件测试课程设计包怎么落地Javaweb 工程 MySQL LoadRunner 的一条闭环软件测试课程设计.zip 这类资源最容易被误读成一份报告模板合集真正卡住复现的是 Javaweb 工程、MySQL 数据脚本和 LoadRunner 脚本能不能接上。有人先写用例结果工程导入报错、数据库连不上、脚本回放登录失败后面全在补环境。我的做法相反先把 IDEA 里的工程跑出页面再把 MySQL 测试数据固定下来最后才让 LoadRunner 按事务压。适合正在做软件测试课程设计、手里有 JavawebMySQL 项目、需要交功能测试和压测报告的人。这份资源解决的不是“测试理论缺多少”而是把一条能复现的测试链路串起来。2. 环境与数据先跑通IDEA 导入 Javaweb 工程、MySQL 初始化与冒烟验证课程设计包最容易翻车的地方不是用例写得少而是环境没对齐。同一份包在别人的机器上能跑换一台机器就出现依赖爆红、数据库连不上、页面 404后面写的用例和压测脚本全成了空中楼阁。先把工程、数据库、启动入口三件事固定下来再谈测试设计后面会省掉很多返工。2.1 拆包后先看三处工程结构、数据库脚本、测试说明拆包后不要先打开报告模板。先定位三个入口源码根目录、数据库脚本、LoadRunner 脚本目录。源码根目录决定用哪种方式导入 IDEA数据库脚本决定测试数据怎么造脚本目录决定压测是重新录还是直接改。用一条命令把关键文件列出来比在目录里来回点更快。find . -maxdepth 3 -type f \ \( -name *.sql -o -name pom.xml -o -name build.gradle \ -o -name web.xml -o -name *.c -o -name *.usr \) \ | sort这段命令做的是“入口定位”不涉及编译。-maxdepth 3控制搜索深度避免把依赖目录全扫一遍-name过滤数据库脚本、构建描述、Web 部署描述和 LoadRunner 常用脚本文件sort让输出稳定方便对照说明文档。实际工程如果不用构建工具可能没有pom.xml或build.gradle那就按普通 Web 工程处理重点看WEB-INF/web.xml和页面入口。看到pom.xml或build.gradle时优先按构建工具导入让 IDEA 自己解析依赖。只有普通 Web 目录时才手工配 SDK 和 Servlet 容器。数据库脚本先看建库语句和字符集别急着执行如果脚本里写死了库名后面连接配置要跟它一致。测试说明里通常会给登录账号、页面路径和启动方式这三样先抄到自己的笔记里后面冒烟和脚本参数化都要用。2.2 IDEA 导入与 Javaweb 运行配置先让页面出来IDEA 导入 Javaweb 工程常见做法是“打开根目录而不是打开某个子目录”。如果根目录下有构建描述文件等依赖索引跑完再动运行配置如果没有就在 Project Structure 里确认 SDK、模块依赖和 Web 资源目录。运行配置里选本地 Servlet 容器部署方式用 exploded 或 war 都行关键是上下文路径要和页面里的链接一致。上下文路径不一致登录页能开提交后照样 404。grep -n servlet-name\|url-pattern\|context-param \ src/main/webapp/WEB-INF/web.xml 2/dev/null || true这段命令用来确认 Servlet 映射和上下文参数。grep -n输出行号方便回到文件里改2/dev/null屏蔽文件不存在时的报错|| true防止命令中断后续检查。路径要按实际工程改普通 Web 工程可能是WebContent/WEB-INF/web.xml或web/WEB-INF/web.xml。看到url-pattern后把登录、列表、提交的入口路径记下来后面 curl 和 LoadRunner 都用同一套路径。依赖爆红时先别急着加 jar。Javaweb 工程里javax.servlet相关依赖经常是provided作用域编译时需要、运行由容器提供。IDEA 里如果模块没有挂容器库代码就会整片爆红。处理顺序是先重新导入构建工具再检查依赖作用域最后才手工加库。运行配置里还要确认端口和上下文路径页面能打开但静态资源 404多半是资源目录没打进部署包。提示先跑通一个登录页或列表页再配数据库。页面都出不来时数据库连接池的报错会掩盖真正的部署问题。2.3 MySQL 初始化建库、建表、测试数据一次写清数据库初始化要围绕测试用例造数据不要只导一份“能跑就行”的库。登录需要正常账号、错误密码、禁用账号列表查询需要空结果、边界值、特殊字符新增修改需要重复数据和必填缺失。下面这段 SQL 用两张最小表覆盖这些场景实际表名按工程脚本替换。CREATE DATABASE IF NOT EXISTS course_test DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE course_test; DROP TABLE IF EXISTS test_user; CREATE TABLE test_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; DROP TABLE IF EXISTS test_item; CREATE TABLE test_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, title VARCHAR(128) NOT NULL, amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO test_user (username, password_hash, status) VALUES (test01, 123456, 1), (test02, 123456, 1), (test03, 123456, 0); INSERT INTO test_item (user_id, title, amount) VALUES (1, 边界值-0.01, 0.01), (1, 边界值-0.00, 0.00), (2, 常规记录, 99.99);这段 SQL 先统一库表字符集再建用户表和记录表。utf8mb4用来覆盖中文和特殊字符username加唯一约束方便做重复注册用例status用 0/1 区分禁用和正常amount用DECIMAL避免浮点误差测试数据里放了 0.00、0.01 和常规值直接对应边界值用例。执行前先确认工程自己的 SQL 脚本有没有外键和字段差异别把示例表硬套到业务表上。测试数据要留“可识别前缀”。功能用例用test01这类账号压测账号用lr_前缀压测产生的记录用压测-前缀。后面清理数据时按前缀删不会误伤功能用例。数据库连接串、账号密码写到本地配置里别提交到公开仓库课程设计答辩时只展示配置项名称不展示真实密码。2.4 冒烟验证页面、接口、日志三条线页面能打开只算一半接口能返回数据才算跑通。先用 curl 走一遍登录和列表查询把会话 cookie 保存下来再带 cookie 请求业务接口。这样后面写 LoadRunner 脚本时请求方法、参数名、上下文路径都有据可查。BASEhttp://127.0.0.1:8080/course curl -i -s -c /tmp/cookie.txt \ -d usernametest01password123456 \ $BASE/login curl -i -s -b /tmp/cookie.txt \ $BASE/item/list?page1size10第一条请求模拟表单登录-c把会话写入/tmp/cookie.txt第二条请求用-b带上会话访问列表接口。-i用来查看响应头登录成功常见 200 或 302-s静默输出避免进度条干扰。BASE里的上下文路径必须和 IDEA 运行配置一致不一致就改成实际路径。判断标准是状态码正常、响应体里能看到test01或测试标题、后台日志没有 SQL 异常。三条线要一起看。页面线看登录、列表、新增能不能点通接口线看请求参数和响应结构日志线看 SQL 报错、连接池超时、空指针。冒烟阶段不要追求用例全覆盖先把“能登录、能查询、能新增一条测试数据”跑通。这一步稳了第 3 章的功能用例才有意义第 4 章的 LoadRunner 脚本才不会录出一堆无效请求。3. 功能与接口测试把登录、查询、新增流程拆成可执行用例功能测试最容易写成“页面点一遍截图交差”。课程设计要的是可复现同样的输入换个人也能得到同样的结果失败时能拿出请求、响应、数据快照。把页面流程拆成用例再把关键用例落到接口层校验报告里的证据链才立得住。3.1 从页面流程拆用例登录、列表查询、新增修改先按页面入口划分模块再按输入维度拆等价类和边界值。登录看账号状态、密码正确性、空值和超长列表查询看正常结果、空结果、分页边界、特殊字符新增修改看必填缺失、金额边界、重复标题。下面这张表可以直接改成自己的用例表优先级按答辩展示顺序排。用例编号场景输入预期优先级LOGIN-01正常登录test01 / 正确密码进入首页会话建立高LOGIN-02密码错误test01 / 错误密码提示失败不建会话高LOGIN-03禁用账号test03 / 正确密码拒绝登录提示状态异常高LOGIN-04空用户名空 / 任意密码前端或后端拦截中LIST-01正常查询页码 1每页 10返回测试数据总数正确高LIST-02空结果关键词“不存在-xx”返回空列表不报错中LIST-03分页边界页码 0、负数、超大值回到合法页或明确提示中ADD-01必填缺失标题为空拦截提交提示必填高ADD-02金额边界0.00、0.01、超大值按业务规则接受或拒绝高用例表里不要只写“登录成功”。输入要写到字段级预期要写到页面提示或接口状态。优先级高的是答辩时能现场复现的优先级低的是补充覆盖。列表查询的空结果和分页边界最容易被忽略但这两类用例最能暴露后端参数校验问题。3.2 接口层校验用 curl 固定请求与断言页面用例靠人眼判断接口用例靠响应内容判断。课程设计里不一定有时间搭完整测试框架用 curl 加最小断言就够。把登录后的 cookie 固定下来查询接口返回后直接匹配总数和关键字段失败就输出原因并退出非零状态。BASEhttp://127.0.0.1:8080/course resp$(curl -s -b /tmp/cookie.txt $BASE/item/list?page1size10) echo $resp | grep -q total:3 \ || { echo total 断言失败; exit 1; } echo $resp | grep -q 边界值-0.01 \ || { echo 测试数据断言失败; exit 1; }这段脚本先取列表响应再用grep -q做静默匹配。||后面是失败分支输出具体断言名并退出非零方便放进回归脚本。total和标题字段要按实际响应结构改JSON 字段名不要照抄示例。断言不要太多先保证“总数对、关键数据在、状态码正常”三条后面再补字段类型和排序。接口校验的价值在于定位。页面提示“查询失败”时接口响应可能已经告诉你参数名错了或会话过期。把每次请求的 URL、参数、响应码、响应体片段记下来缺陷记录就不用靠回忆。3.3 缺陷记录让开发能复现的最小信息集缺陷记录不是写作文。标题要含模块、条件和现象比如“列表查询-页码为 0 时返回 500 而非空页”。正文按“复现步骤、期望结果、实际结果、证据”四块写。复现步骤从登录开始编号每一步写清输入和点击位置证据放请求响应片段、后台日志、数据库快照截图只做辅助。字段写法作用缺陷标题模块 条件 现象一眼定位复现步骤1 登录 2 进入列表 3 页码输 0开发能照着走期望结果返回空页或提示页码非法判断标准实际结果500日志报参数越界现象证据证据请求 URL、响应体、日志行号减少来回沟通缺陷描述里不要写“有时候”“偶尔”。说不清复现条件时先固定数据、固定账号、固定请求顺序再试。课程设计答辩现场老师最常问的是“你怎么证明这个问题存在”不是“你写了多少条缺陷”。3.4 回归顺序与数据清理回归顺序按“冒烟、接口、页面、压测”排。先跑登录和列表冒烟确认环境没坏再跑接口断言确认数据没被污染然后走页面用例最后才压测。压测会产生大量记录压完不清理下一轮功能用例的总数断言就会失败。清理脚本按前缀删先子表后主表。DELETE FROM test_item WHERE title LIKE 压测-%; DELETE FROM test_user WHERE username LIKE lr_%;这两条删除语句靠前缀识别压测数据。LIKE 压测-%对应压测脚本里的标题前缀LIKE lr_%对应参数化账号前缀。执行前先用同样的条件SELECT COUNT(*)确认范围别在业务库上直接跑。有外键时先删子表再删主表没有外键也建议按这个顺序迁移到别的库时不容易出错。清理完再跑一遍总数断言确认功能数据回到基线。基线数据要单独留一份 SQL 快照答辩前重新导入避免演示时列表里全是压测垃圾数据。4. LoadRunner 压测脚本录制、参数化、事务和场景设计LoadRunner 在课程设计里最容易变成“录一遍、跑一遍、截个图”。真正影响报告质量的是事务边界、参数化和场景参数。脚本只跑一次就失败多半是会话没关联TPS 看着很高但页面很慢多半是事务拆得太细或没加思考时间。4.1 录制前先定事务边界登录、查询、提交各算一个事务事务边界按用户可感知的操作切不要把整个脚本包成一个大事务。登录算一个事务列表查询算一个事务提交新增算一个事务。这样报告里能看出是登录慢还是查询慢。录制时先走一遍完整流程再回到脚本里删掉静态资源请求和不必要的跳转。Action() { lr_start_transaction(login); web_submit_data(login, Actionhttp://{host}/course/login, MethodPOST, RecContentTypetext/html, Refererhttp://{host}/course/login, Snapshott1.inf, ModeHTML, ITEMDATA, Nameusername, Value{username}, ENDITEM, Namepassword, Value{password}, ENDITEM, LAST); lr_end_transaction(login, LR_AUTO); lr_think_time(2); lr_start_transaction(list); web_url(list, URLhttp://{host}/course/item/list?page1size10, Resource0, RecContentTypetext/html, Refererhttp://{host}/course/item/list, Snapshott2.inf, ModeHTML, LAST); lr_end_transaction(list, LR_AUTO); return 0; }这段脚本把登录和列表拆成两个事务。lr_start_transaction和lr_end_transaction包住业务请求LR_AUTO根据响应状态自动判定事务成功或失败。{host}、{username}、{password}都是参数后面用参数文件替换。lr_think_time(2)放在两个事务之间模拟用户看页面再点下一步如果放在事务里面响应时间会被思考时间污染。录制后先删掉图片、样式、脚本这类静态资源请求。课程设计压的是业务接口静态资源会拉低 TPS、拉高命中率报告里不好解释。事务名用英文短名别用“事务1”“事务2”后面图表对照时看不出含义。4.2 参数化与关联账号、查询词、会话令牌参数化解决“多个虚拟用户抢同一个账号”的问题。登录账号必须唯一查询关键词可以循环。参数文件用 CSV首行写字段名下面每行一组数据。账号用lr_前缀方便压完清理。username,password,keyword lr_01,123456,边界值 lr_02,123456,常规 lr_03,123456,空结果这份参数文件里username和password给登录事务用keyword给查询事务用。参数更新方式按场景选账号建议每次迭代取唯一值避免同一账号反复登录被锁查询词可以每次出现都换制造不同查询条件。参数文件不要放在脚本根目录之外换机器容易丢路径。会话关联是 LoadRunner 回放失败的高频原因。登录后服务端返回会话 cookie 或 token后续请求必须带上。用web_reg_save_param在登录请求前注册提取规则把值存到SESSION后面请求用{SESSION}引用。web_reg_save_param(SESSION, LBJSESSIONID, RB;, SearchHeaders, LAST);这段关联函数要放在登录请求之前。LB和RB是左右边界SearchHeaders表示从响应头里找。实际工程可能用自定义 token边界要按响应内容改找不到时先打印登录响应头别靠猜。关联值提取不到后面请求会跳登录页事务失败但脚本不报语法错这是最隐蔽的一类翻车。4.3 场景设计并发梯度、思考时间、集合点场景不要一上来就 100 并发。先跑 5、10、20 的梯度每档持续几分钟观察响应时间和错误率的变化。并发数按机器配置和课程设计目标定不要拿生产指标套课程项目。思考时间按真实操作填登录后看页面 2 到 5 秒查询后停顿 1 到 3 秒不加思考时间虚拟用户会像机器人一样连点TPS 虚高。场景并发持续时间思考时间集合点目标基线55 分钟2 秒不开确认脚本稳定梯度一105 分钟2 秒不开看响应时间变化梯度二205 分钟2 秒不开找拐点瞬时并发103 分钟1 秒登录前开看峰值承受集合点只放在需要瞬时并发的场景比如登录前统一释放。日常梯度压测不开集合点否则所有用户同时冲一个接口响应时间曲线会很难看。Ramp up 逐步加压别一秒内起全部用户Duration 至少覆盖一轮完整业务太短的数据没有统计意义。4.4 指标判读TPS、平均响应、错误率、命中率报告里不要只贴 TPS 截图。TPS 高但平均响应时间也高可能是事务拆得太细一个页面操作被拆成很多小事务错误率高先看失败请求的响应码401/302 多半是会话失效500 多半是服务端异常命中率异常高检查是不是压了静态资源。数据库连接池打满时响应时间会突然抬升TPS 反而下降这种拐点比单看峰值更有价值。指标看什么异常信号TPS随并发变化的趋势并发增加 TPS 不升反降平均响应时间各事务分别看登录事务远高于查询事务错误率按响应码分类401/302 集中出现命中率是否压到静态资源接近全命中但业务无压力压测结果要和功能用例对得上。功能用例里列表总数是 3压测后总数变成几千说明数据污染了下一轮断言必失败。压测账号和压测数据都带前缀压完先统计再清理报告里写清数据基线。5. 避坑与常见问题排查从导入失败到压测失真的五条血泪记录课程设计包的坑大多不是高深问题而是环境、数据、脚本三处没对齐。下面五条按“现象、原因、解决”记都是我在复现这类包时反复遇到的。排查顺序建议从环境到脚本再到报告别一上来就改脚本。5.1 环境与数据类导入报错、乱码、连接失败现象一IDEA 导入后javax.servlet整片爆红页面类编译不过。原因通常不是 JDK 坏了而是依赖作用域和容器库没配。Javaweb 工程的 Servlet API 往往由容器提供构建工具里标了providedIDEA 模块没挂容器库时就找不到类。解决顺序是先重新导入构建描述让依赖重新解析再打开模块依赖确认 Servlet API 的作用域最后在运行配置里挂本地容器。不要第一反应就手工下载 jar 塞进lib塞进去容易和容器版本冲突运行时报类加载错误。现象二数据库能连上页面查询中文全是问号或乱码。原因一般有三层数据库字符集、连接串字符集、页面编码。先看建库建表是不是utf8mb4再看连接串有没有指定字符集最后看页面和过滤器编码。三层里有一层是utf8或默认字符集中文就可能坏。解决时统一改成utf8mb4建库、建表、连接串、页面编码一起改已经写入的乱码数据要重新导入不要指望改配置后自动恢复。测试数据里放一条中文标题冒烟时就能提前发现。现象三工程启动报连接池初始化失败但用命令行能连数据库。原因多半是配置文件里的地址、端口、库名或账号和实际不一致也可能是驱动依赖没打进部署包。IDEA 里能跑、部署后连不上先看部署产物里有没有数据库驱动再看连接串是不是指向了另一个库。解决时把连接配置集中到一个本地文件启动前打印实际生效的库名和地址别靠记忆。课程设计答辩换机器时这一步能省很多时间。5.2 脚本与压测类回放失败、参数不生效、TPS 虚高现象四LoadRunner 录制脚本回放时登录失败手动登录却正常。最常见原因是会话没关联。录制时工具自动带了 cookie回放时没有服务端把后续请求重定向到登录页。解决是在登录请求前加关联函数把会话值提取出来后续请求引用。另一个原因是参数化账号被锁或密码错误先拿一个账号手工跑一遍再检查参数文件列名和脚本里的{username}是否一致。回放日志里看请求 URL 和响应码302 集中出现基本就是会话问题。现象五压测 TPS 很高但页面打开很慢报告数据对不上。原因通常是脚本把静态资源也算进事务或者事务拆得太细、没加思考时间。静态资源请求快TPS 被拉高业务接口的真实响应被掩盖。解决时删掉图片、样式、脚本请求只保留登录、查询、提交这类业务事务事务内不要放思考时间场景里按真实操作加停顿。压测前先跑 5 并发基线对比手工操作的响应时间差距太大就回头查脚本。5.3 报告与复现类结果对不上、截图不可信现象六报告里的用例结果和压测后的数据对不上总数断言全失败。原因是压测数据没清理或者功能用例和压测共用了同一批账号。解决是给压测数据加固定前缀压完先统计再删除功能用例使用独立账号和独立数据快照每轮回归前重新导入基线 SQL。报告里写清数据基线、清理条件和使用的前缀别人复核时才能复现。排查时先固定变量同一台机器、同一个数据库、同一份脚本、同一组账号。变量没固定就反复改配置最后不知道是哪一步生效。血泪经验是环境问题先看日志和部署产物脚本问题先看请求和响应报告问题先看数据基线。顺序对了大多数坑十分钟内能定位。6. 报告可复现技巧把用例、脚本、压测数据串成证据链报告里最值钱的不是截图数量而是别人能按你的记录复现。用例编号要能对应到接口请求接口请求要能对应到数据库数据压测事务要能对应到场景参数。下面这张表可以直接放进报告的测试实施章节把证据类型和复核方式写在一起。证据类型放在报告哪一节复核方式用例表功能测试设计按编号逐条执行记录实际结果接口请求接口测试执行保留 URL、参数、响应码片段数据库快照测试数据说明导入基线 SQL 后核对总数压测脚本性能测试脚本检查事务名、参数文件、关联函数场景参数性能测试场景对照并发、持续时间、思考时间结果曲线性能测试结果标注拐点和错误率变化复核时先跑两条命令一条数脚本里的事务一条数压测产生的数据。事务数量和报告里的事务列表对不上说明脚本删改后没同步数据量和基线对不上说明清理没做干净。grep -R lr_start_transaction lr_script/ | wc -l mysql -uroot -p course_test \ -e SELECT COUNT(*) FROM test_item WHERE title LIKE 压测-%;第一条按脚本目录统计事务开始标记wc -l输出行数第二条统计带压测前缀的记录数。路径和数据库连接按本地环境改命令里的-p会提示输入密码不要把密码写进脚本。两条结果都记进报告附录答辩时被问“数据哪来的”直接翻到这一页。我后来养成了一个习惯每次交报告前把用例表、接口请求、数据库快照、压测脚本和场景参数按编号对一遍对不上就停下来改不靠记忆补。这个习惯救过好几次现场演示也让我少写了很多“看起来有图、实际复现不了”的段落。这套课程设计包的入口放在文末拿到后先按第 2 章的冒烟顺序跑一遍再动 LoadRunner能少走不少弯路。希望帮到你。本文还有配套的精品资源点击获取 Javaweb+MySQL+LoadRunner软件测试课程设计闭环
简介《软件测试课程设计.zip》面向计算机相关专业学生及软件测试入门者围绕JavaWeb网上书店前台系统提供一套可对照的课程设计材料解决测试用例设计、单元测试实施与性能测试落地等练习需求。压缩包共904个文件、约45.97MB包含jsp与java源码、class和jar编译依赖、xml配置、js/css页面资源以及大量gif、jpg界面截图便于还原系统结构与测试对象。已有2350人学习下载说明其在课程设计与测试练习场景中具有一定参考度。材料覆盖逻辑覆盖与基本路径测试的白盒用例设计等价类、边界值黑盒分析借助JUnit对核心功能开展单元测试并通过手工或自动化方式完成功能验证性能部分使用LoadRunner进行稳定性与逐步加压的压力测试可帮助读者理解最大服务级别判定思路并据此整理测试方案、用例与结果记录。1. 软件测试课程设计包怎么落地Javaweb 工程 MySQL LoadRunner 的一条闭环软件测试课程设计.zip 这类资源最容易被误读成一份报告模板合集真正卡住复现的是 Javaweb 工程、MySQL 数据脚本和 LoadRunner 脚本能不能接上。有人先写用例结果工程导入报错、数据库连不上、脚本回放登录失败后面全在补环境。我的做法相反先把 IDEA 里的工程跑出页面再把 MySQL 测试数据固定下来最后才让 LoadRunner 按事务压。适合正在做软件测试课程设计、手里有 JavawebMySQL 项目、需要交功能测试和压测报告的人。这份资源解决的不是“测试理论缺多少”而是把一条能复现的测试链路串起来。2. 环境与数据先跑通IDEA 导入 Javaweb 工程、MySQL 初始化与冒烟验证课程设计包最容易翻车的地方不是用例写得少而是环境没对齐。同一份包在别人的机器上能跑换一台机器就出现依赖爆红、数据库连不上、页面 404后面写的用例和压测脚本全成了空中楼阁。先把工程、数据库、启动入口三件事固定下来再谈测试设计后面会省掉很多返工。2.1 拆包后先看三处工程结构、数据库脚本、测试说明拆包后不要先打开报告模板。先定位三个入口源码根目录、数据库脚本、LoadRunner 脚本目录。源码根目录决定用哪种方式导入 IDEA数据库脚本决定测试数据怎么造脚本目录决定压测是重新录还是直接改。用一条命令把关键文件列出来比在目录里来回点更快。find . -maxdepth 3 -type f \ \( -name *.sql -o -name pom.xml -o -name build.gradle \ -o -name web.xml -o -name *.c -o -name *.usr \) \ | sort这段命令做的是“入口定位”不涉及编译。-maxdepth 3控制搜索深度避免把依赖目录全扫一遍-name过滤数据库脚本、构建描述、Web 部署描述和 LoadRunner 常用脚本文件sort让输出稳定方便对照说明文档。实际工程如果不用构建工具可能没有pom.xml或build.gradle那就按普通 Web 工程处理重点看WEB-INF/web.xml和页面入口。看到pom.xml或build.gradle时优先按构建工具导入让 IDEA 自己解析依赖。只有普通 Web 目录时才手工配 SDK 和 Servlet 容器。数据库脚本先看建库语句和字符集别急着执行如果脚本里写死了库名后面连接配置要跟它一致。测试说明里通常会给登录账号、页面路径和启动方式这三样先抄到自己的笔记里后面冒烟和脚本参数化都要用。2.2 IDEA 导入与 Javaweb 运行配置先让页面出来IDEA 导入 Javaweb 工程常见做法是“打开根目录而不是打开某个子目录”。如果根目录下有构建描述文件等依赖索引跑完再动运行配置如果没有就在 Project Structure 里确认 SDK、模块依赖和 Web 资源目录。运行配置里选本地 Servlet 容器部署方式用 exploded 或 war 都行关键是上下文路径要和页面里的链接一致。上下文路径不一致登录页能开提交后照样 404。grep -n servlet-name\|url-pattern\|context-param \ src/main/webapp/WEB-INF/web.xml 2/dev/null || true这段命令用来确认 Servlet 映射和上下文参数。grep -n输出行号方便回到文件里改2/dev/null屏蔽文件不存在时的报错|| true防止命令中断后续检查。路径要按实际工程改普通 Web 工程可能是WebContent/WEB-INF/web.xml或web/WEB-INF/web.xml。看到url-pattern后把登录、列表、提交的入口路径记下来后面 curl 和 LoadRunner 都用同一套路径。依赖爆红时先别急着加 jar。Javaweb 工程里javax.servlet相关依赖经常是provided作用域编译时需要、运行由容器提供。IDEA 里如果模块没有挂容器库代码就会整片爆红。处理顺序是先重新导入构建工具再检查依赖作用域最后才手工加库。运行配置里还要确认端口和上下文路径页面能打开但静态资源 404多半是资源目录没打进部署包。提示先跑通一个登录页或列表页再配数据库。页面都出不来时数据库连接池的报错会掩盖真正的部署问题。2.3 MySQL 初始化建库、建表、测试数据一次写清数据库初始化要围绕测试用例造数据不要只导一份“能跑就行”的库。登录需要正常账号、错误密码、禁用账号列表查询需要空结果、边界值、特殊字符新增修改需要重复数据和必填缺失。下面这段 SQL 用两张最小表覆盖这些场景实际表名按工程脚本替换。CREATE DATABASE IF NOT EXISTS course_test DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE course_test; DROP TABLE IF EXISTS test_user; CREATE TABLE test_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; DROP TABLE IF EXISTS test_item; CREATE TABLE test_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, title VARCHAR(128) NOT NULL, amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO test_user (username, password_hash, status) VALUES (test01, 123456, 1), (test02, 123456, 1), (test03, 123456, 0); INSERT INTO test_item (user_id, title, amount) VALUES (1, 边界值-0.01, 0.01), (1, 边界值-0.00, 0.00), (2, 常规记录, 99.99);这段 SQL 先统一库表字符集再建用户表和记录表。utf8mb4用来覆盖中文和特殊字符username加唯一约束方便做重复注册用例status用 0/1 区分禁用和正常amount用DECIMAL避免浮点误差测试数据里放了 0.00、0.01 和常规值直接对应边界值用例。执行前先确认工程自己的 SQL 脚本有没有外键和字段差异别把示例表硬套到业务表上。测试数据要留“可识别前缀”。功能用例用test01这类账号压测账号用lr_前缀压测产生的记录用压测-前缀。后面清理数据时按前缀删不会误伤功能用例。数据库连接串、账号密码写到本地配置里别提交到公开仓库课程设计答辩时只展示配置项名称不展示真实密码。2.4 冒烟验证页面、接口、日志三条线页面能打开只算一半接口能返回数据才算跑通。先用 curl 走一遍登录和列表查询把会话 cookie 保存下来再带 cookie 请求业务接口。这样后面写 LoadRunner 脚本时请求方法、参数名、上下文路径都有据可查。BASEhttp://127.0.0.1:8080/course curl -i -s -c /tmp/cookie.txt \ -d usernametest01password123456 \ $BASE/login curl -i -s -b /tmp/cookie.txt \ $BASE/item/list?page1size10第一条请求模拟表单登录-c把会话写入/tmp/cookie.txt第二条请求用-b带上会话访问列表接口。-i用来查看响应头登录成功常见 200 或 302-s静默输出避免进度条干扰。BASE里的上下文路径必须和 IDEA 运行配置一致不一致就改成实际路径。判断标准是状态码正常、响应体里能看到test01或测试标题、后台日志没有 SQL 异常。三条线要一起看。页面线看登录、列表、新增能不能点通接口线看请求参数和响应结构日志线看 SQL 报错、连接池超时、空指针。冒烟阶段不要追求用例全覆盖先把“能登录、能查询、能新增一条测试数据”跑通。这一步稳了第 3 章的功能用例才有意义第 4 章的 LoadRunner 脚本才不会录出一堆无效请求。3. 功能与接口测试把登录、查询、新增流程拆成可执行用例功能测试最容易写成“页面点一遍截图交差”。课程设计要的是可复现同样的输入换个人也能得到同样的结果失败时能拿出请求、响应、数据快照。把页面流程拆成用例再把关键用例落到接口层校验报告里的证据链才立得住。3.1 从页面流程拆用例登录、列表查询、新增修改先按页面入口划分模块再按输入维度拆等价类和边界值。登录看账号状态、密码正确性、空值和超长列表查询看正常结果、空结果、分页边界、特殊字符新增修改看必填缺失、金额边界、重复标题。下面这张表可以直接改成自己的用例表优先级按答辩展示顺序排。用例编号场景输入预期优先级LOGIN-01正常登录test01 / 正确密码进入首页会话建立高LOGIN-02密码错误test01 / 错误密码提示失败不建会话高LOGIN-03禁用账号test03 / 正确密码拒绝登录提示状态异常高LOGIN-04空用户名空 / 任意密码前端或后端拦截中LIST-01正常查询页码 1每页 10返回测试数据总数正确高LIST-02空结果关键词“不存在-xx”返回空列表不报错中LIST-03分页边界页码 0、负数、超大值回到合法页或明确提示中ADD-01必填缺失标题为空拦截提交提示必填高ADD-02金额边界0.00、0.01、超大值按业务规则接受或拒绝高用例表里不要只写“登录成功”。输入要写到字段级预期要写到页面提示或接口状态。优先级高的是答辩时能现场复现的优先级低的是补充覆盖。列表查询的空结果和分页边界最容易被忽略但这两类用例最能暴露后端参数校验问题。3.2 接口层校验用 curl 固定请求与断言页面用例靠人眼判断接口用例靠响应内容判断。课程设计里不一定有时间搭完整测试框架用 curl 加最小断言就够。把登录后的 cookie 固定下来查询接口返回后直接匹配总数和关键字段失败就输出原因并退出非零状态。BASEhttp://127.0.0.1:8080/course resp$(curl -s -b /tmp/cookie.txt $BASE/item/list?page1size10) echo $resp | grep -q total:3 \ || { echo total 断言失败; exit 1; } echo $resp | grep -q 边界值-0.01 \ || { echo 测试数据断言失败; exit 1; }这段脚本先取列表响应再用grep -q做静默匹配。||后面是失败分支输出具体断言名并退出非零方便放进回归脚本。total和标题字段要按实际响应结构改JSON 字段名不要照抄示例。断言不要太多先保证“总数对、关键数据在、状态码正常”三条后面再补字段类型和排序。接口校验的价值在于定位。页面提示“查询失败”时接口响应可能已经告诉你参数名错了或会话过期。把每次请求的 URL、参数、响应码、响应体片段记下来缺陷记录就不用靠回忆。3.3 缺陷记录让开发能复现的最小信息集缺陷记录不是写作文。标题要含模块、条件和现象比如“列表查询-页码为 0 时返回 500 而非空页”。正文按“复现步骤、期望结果、实际结果、证据”四块写。复现步骤从登录开始编号每一步写清输入和点击位置证据放请求响应片段、后台日志、数据库快照截图只做辅助。字段写法作用缺陷标题模块 条件 现象一眼定位复现步骤1 登录 2 进入列表 3 页码输 0开发能照着走期望结果返回空页或提示页码非法判断标准实际结果500日志报参数越界现象证据证据请求 URL、响应体、日志行号减少来回沟通缺陷描述里不要写“有时候”“偶尔”。说不清复现条件时先固定数据、固定账号、固定请求顺序再试。课程设计答辩现场老师最常问的是“你怎么证明这个问题存在”不是“你写了多少条缺陷”。3.4 回归顺序与数据清理回归顺序按“冒烟、接口、页面、压测”排。先跑登录和列表冒烟确认环境没坏再跑接口断言确认数据没被污染然后走页面用例最后才压测。压测会产生大量记录压完不清理下一轮功能用例的总数断言就会失败。清理脚本按前缀删先子表后主表。DELETE FROM test_item WHERE title LIKE 压测-%; DELETE FROM test_user WHERE username LIKE lr_%;这两条删除语句靠前缀识别压测数据。LIKE 压测-%对应压测脚本里的标题前缀LIKE lr_%对应参数化账号前缀。执行前先用同样的条件SELECT COUNT(*)确认范围别在业务库上直接跑。有外键时先删子表再删主表没有外键也建议按这个顺序迁移到别的库时不容易出错。清理完再跑一遍总数断言确认功能数据回到基线。基线数据要单独留一份 SQL 快照答辩前重新导入避免演示时列表里全是压测垃圾数据。4. LoadRunner 压测脚本录制、参数化、事务和场景设计LoadRunner 在课程设计里最容易变成“录一遍、跑一遍、截个图”。真正影响报告质量的是事务边界、参数化和场景参数。脚本只跑一次就失败多半是会话没关联TPS 看着很高但页面很慢多半是事务拆得太细或没加思考时间。4.1 录制前先定事务边界登录、查询、提交各算一个事务事务边界按用户可感知的操作切不要把整个脚本包成一个大事务。登录算一个事务列表查询算一个事务提交新增算一个事务。这样报告里能看出是登录慢还是查询慢。录制时先走一遍完整流程再回到脚本里删掉静态资源请求和不必要的跳转。Action() { lr_start_transaction(login); web_submit_data(login, Actionhttp://{host}/course/login, MethodPOST, RecContentTypetext/html, Refererhttp://{host}/course/login, Snapshott1.inf, ModeHTML, ITEMDATA, Nameusername, Value{username}, ENDITEM, Namepassword, Value{password}, ENDITEM, LAST); lr_end_transaction(login, LR_AUTO); lr_think_time(2); lr_start_transaction(list); web_url(list, URLhttp://{host}/course/item/list?page1size10, Resource0, RecContentTypetext/html, Refererhttp://{host}/course/item/list, Snapshott2.inf, ModeHTML, LAST); lr_end_transaction(list, LR_AUTO); return 0; }这段脚本把登录和列表拆成两个事务。lr_start_transaction和lr_end_transaction包住业务请求LR_AUTO根据响应状态自动判定事务成功或失败。{host}、{username}、{password}都是参数后面用参数文件替换。lr_think_time(2)放在两个事务之间模拟用户看页面再点下一步如果放在事务里面响应时间会被思考时间污染。录制后先删掉图片、样式、脚本这类静态资源请求。课程设计压的是业务接口静态资源会拉低 TPS、拉高命中率报告里不好解释。事务名用英文短名别用“事务1”“事务2”后面图表对照时看不出含义。4.2 参数化与关联账号、查询词、会话令牌参数化解决“多个虚拟用户抢同一个账号”的问题。登录账号必须唯一查询关键词可以循环。参数文件用 CSV首行写字段名下面每行一组数据。账号用lr_前缀方便压完清理。username,password,keyword lr_01,123456,边界值 lr_02,123456,常规 lr_03,123456,空结果这份参数文件里username和password给登录事务用keyword给查询事务用。参数更新方式按场景选账号建议每次迭代取唯一值避免同一账号反复登录被锁查询词可以每次出现都换制造不同查询条件。参数文件不要放在脚本根目录之外换机器容易丢路径。会话关联是 LoadRunner 回放失败的高频原因。登录后服务端返回会话 cookie 或 token后续请求必须带上。用web_reg_save_param在登录请求前注册提取规则把值存到SESSION后面请求用{SESSION}引用。web_reg_save_param(SESSION, LBJSESSIONID, RB;, SearchHeaders, LAST);这段关联函数要放在登录请求之前。LB和RB是左右边界SearchHeaders表示从响应头里找。实际工程可能用自定义 token边界要按响应内容改找不到时先打印登录响应头别靠猜。关联值提取不到后面请求会跳登录页事务失败但脚本不报语法错这是最隐蔽的一类翻车。4.3 场景设计并发梯度、思考时间、集合点场景不要一上来就 100 并发。先跑 5、10、20 的梯度每档持续几分钟观察响应时间和错误率的变化。并发数按机器配置和课程设计目标定不要拿生产指标套课程项目。思考时间按真实操作填登录后看页面 2 到 5 秒查询后停顿 1 到 3 秒不加思考时间虚拟用户会像机器人一样连点TPS 虚高。场景并发持续时间思考时间集合点目标基线55 分钟2 秒不开确认脚本稳定梯度一105 分钟2 秒不开看响应时间变化梯度二205 分钟2 秒不开找拐点瞬时并发103 分钟1 秒登录前开看峰值承受集合点只放在需要瞬时并发的场景比如登录前统一释放。日常梯度压测不开集合点否则所有用户同时冲一个接口响应时间曲线会很难看。Ramp up 逐步加压别一秒内起全部用户Duration 至少覆盖一轮完整业务太短的数据没有统计意义。4.4 指标判读TPS、平均响应、错误率、命中率报告里不要只贴 TPS 截图。TPS 高但平均响应时间也高可能是事务拆得太细一个页面操作被拆成很多小事务错误率高先看失败请求的响应码401/302 多半是会话失效500 多半是服务端异常命中率异常高检查是不是压了静态资源。数据库连接池打满时响应时间会突然抬升TPS 反而下降这种拐点比单看峰值更有价值。指标看什么异常信号TPS随并发变化的趋势并发增加 TPS 不升反降平均响应时间各事务分别看登录事务远高于查询事务错误率按响应码分类401/302 集中出现命中率是否压到静态资源接近全命中但业务无压力压测结果要和功能用例对得上。功能用例里列表总数是 3压测后总数变成几千说明数据污染了下一轮断言必失败。压测账号和压测数据都带前缀压完先统计再清理报告里写清数据基线。5. 避坑与常见问题排查从导入失败到压测失真的五条血泪记录课程设计包的坑大多不是高深问题而是环境、数据、脚本三处没对齐。下面五条按“现象、原因、解决”记都是我在复现这类包时反复遇到的。排查顺序建议从环境到脚本再到报告别一上来就改脚本。5.1 环境与数据类导入报错、乱码、连接失败现象一IDEA 导入后javax.servlet整片爆红页面类编译不过。原因通常不是 JDK 坏了而是依赖作用域和容器库没配。Javaweb 工程的 Servlet API 往往由容器提供构建工具里标了providedIDEA 模块没挂容器库时就找不到类。解决顺序是先重新导入构建描述让依赖重新解析再打开模块依赖确认 Servlet API 的作用域最后在运行配置里挂本地容器。不要第一反应就手工下载 jar 塞进lib塞进去容易和容器版本冲突运行时报类加载错误。现象二数据库能连上页面查询中文全是问号或乱码。原因一般有三层数据库字符集、连接串字符集、页面编码。先看建库建表是不是utf8mb4再看连接串有没有指定字符集最后看页面和过滤器编码。三层里有一层是utf8或默认字符集中文就可能坏。解决时统一改成utf8mb4建库、建表、连接串、页面编码一起改已经写入的乱码数据要重新导入不要指望改配置后自动恢复。测试数据里放一条中文标题冒烟时就能提前发现。现象三工程启动报连接池初始化失败但用命令行能连数据库。原因多半是配置文件里的地址、端口、库名或账号和实际不一致也可能是驱动依赖没打进部署包。IDEA 里能跑、部署后连不上先看部署产物里有没有数据库驱动再看连接串是不是指向了另一个库。解决时把连接配置集中到一个本地文件启动前打印实际生效的库名和地址别靠记忆。课程设计答辩换机器时这一步能省很多时间。5.2 脚本与压测类回放失败、参数不生效、TPS 虚高现象四LoadRunner 录制脚本回放时登录失败手动登录却正常。最常见原因是会话没关联。录制时工具自动带了 cookie回放时没有服务端把后续请求重定向到登录页。解决是在登录请求前加关联函数把会话值提取出来后续请求引用。另一个原因是参数化账号被锁或密码错误先拿一个账号手工跑一遍再检查参数文件列名和脚本里的{username}是否一致。回放日志里看请求 URL 和响应码302 集中出现基本就是会话问题。现象五压测 TPS 很高但页面打开很慢报告数据对不上。原因通常是脚本把静态资源也算进事务或者事务拆得太细、没加思考时间。静态资源请求快TPS 被拉高业务接口的真实响应被掩盖。解决时删掉图片、样式、脚本请求只保留登录、查询、提交这类业务事务事务内不要放思考时间场景里按真实操作加停顿。压测前先跑 5 并发基线对比手工操作的响应时间差距太大就回头查脚本。5.3 报告与复现类结果对不上、截图不可信现象六报告里的用例结果和压测后的数据对不上总数断言全失败。原因是压测数据没清理或者功能用例和压测共用了同一批账号。解决是给压测数据加固定前缀压完先统计再删除功能用例使用独立账号和独立数据快照每轮回归前重新导入基线 SQL。报告里写清数据基线、清理条件和使用的前缀别人复核时才能复现。排查时先固定变量同一台机器、同一个数据库、同一份脚本、同一组账号。变量没固定就反复改配置最后不知道是哪一步生效。血泪经验是环境问题先看日志和部署产物脚本问题先看请求和响应报告问题先看数据基线。顺序对了大多数坑十分钟内能定位。6. 报告可复现技巧把用例、脚本、压测数据串成证据链报告里最值钱的不是截图数量而是别人能按你的记录复现。用例编号要能对应到接口请求接口请求要能对应到数据库数据压测事务要能对应到场景参数。下面这张表可以直接放进报告的测试实施章节把证据类型和复核方式写在一起。证据类型放在报告哪一节复核方式用例表功能测试设计按编号逐条执行记录实际结果接口请求接口测试执行保留 URL、参数、响应码片段数据库快照测试数据说明导入基线 SQL 后核对总数压测脚本性能测试脚本检查事务名、参数文件、关联函数场景参数性能测试场景对照并发、持续时间、思考时间结果曲线性能测试结果标注拐点和错误率变化复核时先跑两条命令一条数脚本里的事务一条数压测产生的数据。事务数量和报告里的事务列表对不上说明脚本删改后没同步数据量和基线对不上说明清理没做干净。grep -R lr_start_transaction lr_script/ | wc -l mysql -uroot -p course_test \ -e SELECT COUNT(*) FROM test_item WHERE title LIKE 压测-%;第一条按脚本目录统计事务开始标记wc -l输出行数第二条统计带压测前缀的记录数。路径和数据库连接按本地环境改命令里的-p会提示输入密码不要把密码写进脚本。两条结果都记进报告附录答辩时被问“数据哪来的”直接翻到这一页。我后来养成了一个习惯每次交报告前把用例表、接口请求、数据库快照、压测脚本和场景参数按编号对一遍对不上就停下来改不靠记忆补。这个习惯救过好几次现场演示也让我少写了很多“看起来有图、实际复现不了”的段落。这套课程设计包的入口放在文末拿到后先按第 2 章的冒烟顺序跑一遍再动 LoadRunner能少走不少弯路。希望帮到你。本文还有配套的精品资源点击获取