首页 / 资讯中心 / 文章详情

JavaWeb软件测试课程设计实战:功能、接口与LoadRunner性能测试全流程

JavaWeb软件测试课程设计实战:功能、接口与LoadRunner性能测试全流程 ★ FEATURED ARTICLE
简介这份资源是面向高校计算机相关专业学生的软件测试课程设计完整项目包以JavaWeb网上书店前台系统为被测对象在IDEA中构建适合正在完成软件测试课程设计或需要练习测试用例设计的学习者。压缩包共904个文件约45.97MB包含jsp页面、java源码、class编译文件、xml配置、jar依赖以及大量gif、jpg、png界面素材完整保留了可运行的项目结构与测试环境。资源围绕白盒与黑盒两条主线展开白盒部分采用逻辑覆盖和基本路径覆盖设计用例对核心函数做单元测试黑盒部分运用等价类与边界值分析同时结合JUnit完成单元测试并借助LoadRunner对系统进行稳定性与压力测试逐步加压以确定性能失效临界点。已有2349人学习下载读者可据此获得一套可直接参考的测试方案、用例设计思路与性能测试流程便于对照完成课程设计报告与实验验证。1. 从一份课程设计压缩包说起JavaWeb 项目怎么做软件测试很多同学做软件测试课程设计时第一反应是打开 IDEA 写几个 JUnit 用例就交差结果答辩时被问「性能测试做了吗」「测试用例覆盖率多少」直接卡壳。我手上这份「软件测试课程设计.zip」就是冲着这个痛点来的——它围绕一个 JavaWeb MySQL 的信息管理系统把功能测试、接口测试、性能测试串成一条完整链路配套 LoadRunner 脚本和测试文档模板。适合正在赶课程设计、需要一套能跑通的测试流程参考的在校生也适合想补测试环节的 JavaWeb 开发者。它解决的不是「教你什么是黑盒白盒」而是「给你一个真实项目告诉你每一步测什么、怎么测、结果怎么记录」。2. 环境搭建与项目结构IDEA MySQL LoadRunner 三件套怎么配拿到压缩包别急着双击运行先把环境理顺。这份资源的核心是一个 JavaWeb 应用加一套测试资产环境不对后面全是玄学问题。2.1 先看清压缩包里有什么解压后大致是这么几块我按用途列一下方便你对号入座目录/文件用途备注src/JavaWeb 源码Servlet JSP JDBCMaven 结构sql/数据库脚本建库建表 初始数据test-case/测试用例文档Excel 格式含功能/接口用例loadrunner/性能测试脚本.usr脚本 参数化文件report/测试报告模板Word 模板含缺陷记录表lib/依赖 jar 包老项目可能没用 Maven看实际情况先确认项目是 Maven 还是普通 Web 项目。如果是 Maven直接pom.xml导入如果是普通项目需要手动配WEB-INF/lib。这一步判断错了后面编译报错能让你找半天。2.2 IDEA 导入与 Tomcat 配置用 IDEA 打开项目后第一件事是配 JDK 和 Tomcat。这份资源大概率是 JDK 8 Tomcat 8/9 的组合别上来就用 JDK 17Servlet 的javax和jakarta包名一变满屏红。# 先确认本机 JDK 版本课程设计项目建议 JDK 8 java -version # 检查 MySQL 是否在跑端口默认 3306 mysql -u root -p -e SELECT VERSION();IDEA 里的关键配置File → Project Structure → Modules确认 SDK 是 1.8Run → Edit Configurations新建 Tomcat ServerDeployment 里加上war exploded工件。这里有个高频翻车点——Application context如果设成/访问路径就是http://localhost:8080/设成/test就是http://localhost:8080/test/。测试用例里的 URL 要跟这个对上否则接口测试全 404。2.3 数据库导入与连接串修改数据库这步最容易被忽略。压缩包里的sql/脚本要先执行再改代码里的连接配置。-- 建库字符集用 utf8mb4避免中文乱码 CREATE DATABASE test_course DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 导入表结构和初始数据在命令行执行 -- mysql -u root -p test_course sql/init.sql导入完去源码里找 JDBC 配置通常在db.properties或某个DBUtil.java里。把url、username、password改成你本机的。常见做法是把url写成jdbc:mysql://localhost:3306/test_course?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8。serverTimezone不写MySQL 8 会报时区错误useSSLfalse不写控制台一堆警告。改完启动 Tomcat能打开登录页环境就算通了。提示如果启动报ClassNotFoundException: com.mysql.cj.jdbc.Driver说明驱动包版本和连接串不匹配。MySQL 8 用com.mysql.cj.jdbc.DriverMySQL 5 用com.mysql.jdbc.Driver别混用。3. 功能测试与接口测试从测试用例设计到 Postman 实操环境通了进入正题。这份资源的测试用例文档不是摆设它按模块拆了登录、增删改查、权限校验几块你要做的是理解设计思路然后自己跑一遍验证。3.1 测试用例怎么读、怎么补打开test-case/里的 Excel一般有这几列用例编号、模块、前置条件、操作步骤、预期结果、实际结果、是否通过。新手常犯的错是只照着跑不思考为什么这么设计。比如登录模块好的用例会覆盖正确账号密码、错误密码、空用户名、SQL 注入尝试、多次失败锁定。这几条背后对应的是等价类划分和边界值分析。我一般会做一件事拿用例覆盖的功能点回头对一遍源码里的分支。比如LoginServlet里如果有if (user null)和if (!pwd.equals(dbPwd))两个分支那用例里就必须有能分别命中这两条的数据。覆盖不到的自己补。这一步做完你对「测试用例覆盖率」这个问题就有底气了。3.2 用 Postman 做接口测试JavaWeb 项目的接口测试Postman 是最顺手的。先抓一个登录接口的请求格式通常是 POST 表单参数。// Postman 的 Tests 脚本用来断言响应 pm.test(状态码为 200, function () { pm.response.to.have.status(200); }); pm.test(返回体包含 success 标识, function () { var jsonData pm.response.json(); pm.expect(jsonData.success).to.eql(true); }); // 把登录后的 token 存到环境变量供后续接口用 var token pm.response.json().token; pm.environment.set(auth_token, token);这段脚本的逻辑第一个断言查 HTTP 状态码第二个查业务返回体第三个把 token 提取出来存进环境变量。参数说明——pm.response.json()要求响应是 JSON 格式如果后端返回的是 HTML 或纯文本这里会抛异常得先确认Content-Type。后续的增删改查接口在 Header 里带上Authorization: {{auth_token}}就能复用登录态。接口测试最容易踩的坑是参数格式。表单提交用x-www-form-urlencodedJSON 提交用raw application/json选错了后端收不到参数返回 400 或 null。我建议每个接口先用浏览器 F12 抓一次真实请求照着抄格式比猜快得多。3.3 测试结果怎么记录才有说服力跑完用例结果要落到report/的模板里。别只写「通过/不通过」要带证据请求截图、响应截图、数据库前后对比。缺陷记录表里严重程度要分级——导致系统崩溃的是致命功能不可用的是严重界面错位的是轻微。答辩老师看的就是你有没有这套记录意识而不是你测了多少条。4. LoadRunner 性能测试脚本录制、参数化与场景设计功能测试证明「能用」性能测试证明「扛得住」。这份资源带 LoadRunner 脚本说明课程设计对性能有要求。LoadRunner 是老牌商业工具界面劝退但流程是固定的录制 → 增强 → 场景 → 分析。4.1 脚本录制与关联打开 LoadRunner 的 VuGen新建 Web HTTP/HTML 协议脚本点录制浏览器走一遍登录和查询操作停止后生成脚本。录完第一件事是回放大概率失败因为脚本里写死了 session id 或 token这叫「关联」问题。// LoadRunner 脚本里常见的关联函数写法 web_reg_save_param(SessionID, LBname\sessionid\ value\, RB\, SearchBody, LAST); // 后续请求里用 {SessionID} 引用 web_submit_data(login, Actionhttp://localhost:8080/test/login, MethodPOST, RecContentTypetext/html, ITEMDATA, Nameusername, Value{username}, ENDITEM, Namepassword, Value{password}, ENDITEM, LAST);web_reg_save_param是关联函数LB和RB是左右边界用来从响应里截取动态值。SearchBody表示在响应体里找。截出来的值存进SessionID后面用{SessionID}引用。参数说明——边界写错是最常见的失败原因建议先在响应原文里搜到目标值把前后几个字符原样抄进LB/RB。4.2 参数化让虚拟用户用不同数据性能测试要模拟多用户不能所有人用同一个账号。把用户名密码做成参数文件在脚本里替换。参数名数据源更新方式说明usernameusers.datEach iteration每次迭代换一行passwordusers.datEach iteration与用户名同列对应searchKeykeywords.datEach occurrence每次出现换一个users.dat里一行一个账号用逗号或制表符分隔。更新方式选Each iteration表示每次循环换一组选Once表示整个测试只用第一组。选错了要么所有虚拟用户撞同一个账号要么数据没被充分利用。4.3 场景设计与结果分析脚本调通后进 Controller 设计场景。课程设计常用的场景是逐步加压比如 10、20、50 个并发用户每档跑 5 分钟。设置 Ramp up 让用户逐渐上线别一秒全上否则测的是瞬时冲击不是稳态性能。跑完看 Analysis重点盯三个指标平均响应时间、TPS每秒事务数、错误率。响应时间随并发上升而陡增的那个点就是系统瓶颈。常见瓶颈在数据库连接池——默认池子太小并发一高就排队。这时候去改db.properties里的maxPoolSize再跑一遍对比报告里就有了「优化前后对比」这个加分项。注意LoadRunner 对机器资源占用高本机跑 Controller 和被测应用会互相抢资源测出来的数据不准。条件允许的话把压力机和应用分开部署。5. 避坑与排查那些让课程设计卡壳的常见问题这一章是我踩过的坑合集按「现象 → 原因 → 解决」写你对照着排查能省不少时间。现象一Tomcat 启动报端口被占用。原因通常是 8080 被别的进程占了或者上一次 Tomcat 没退干净。解决命令行netstat -ano | findstr 8080找到 PID任务管理器结束或者改 Tomcat 的server.xml换个端口。现象二页面中文乱码。原因分三种——数据库字符集不是 utf8mb4、JDBC 连接串没加characterEncodingutf8、JSP 页面没声明pageEncoding。解决三处一起查缺一处都可能乱。我一般先看数据库再看连接串最后看页面。现象三LoadRunner 回放报「找不到关联值」。原因是边界字符串写错或者响应内容跟录制时不一样。解决打开回放日志找到实际响应把LB/RB按实际内容重写。别凭记忆写边界一定要复制。现象四接口测试返回 401 但登录明明成功了。原因是 token 没正确传递或者 token 过期了。解决在 Postman 的 Authorization 里确认变量名跟环境变量一致再检查后端 token 有效期设置。有些项目 token 存 session重启 Tomcat 就失效得重新登录。现象五性能测试错误率突然飙升。原因可能是参数化数据用完了虚拟用户在重复用同一批数据导致冲突也可能是应用连接池耗尽。解决先看错误类型如果是业务错误查数据如果是超时错误查连接池和线程数。6. 进阶技巧把测试数据做成可复用的资产课程设计做完就扔是最大的浪费。我习惯把这次测试里沉淀的东西整理成可复用资产下次换项目直接改改就能用。第一个技巧是测试数据生成脚本。手工造 100 条用户数据太慢用 Python 生成。import random import string # 生成测试用户数据写入 users.dat 供 LoadRunner 参数化 def gen_users(n): with open(users.dat, w, encodingutf-8) as f: for i in range(n): # 用户名用固定前缀加序号避免重复 username ftestuser{i:04d} # 密码用随机字符串长度 8 password .join(random.choices(string.ascii_letters string.digits, k8)) f.write(f{username},{password}\n) gen_users(200)这段脚本生成 200 组账号密码格式是用户名,密码正好对上 LoadRunner 的参数文件格式。f{i:04d}保证序号补零对齐方便排查。生成完记得把数据也插进数据库否则登录全失败。第二个技巧是测试报告的模板化。把report/里的 Word 模板拆成固定章节测试环境、测试范围、用例执行统计、缺陷汇总、性能指标、结论。每次只改数据不改结构半小时能出一份像样的报告。第三个技巧是回归测试清单。把核心用例挑出来做成一个精简清单改完代码先跑这遍确认没破坏主流程再跑全量。这个习惯能帮你在答辩前快速验证系统状态。从那以后我每次拿到新的课程设计项目都强制先跑一遍环境检查清单——JDK 版本、数据库连接、Tomcat 端口、依赖包——确认全绿再动手写测试。这套流程帮我省下了大量返工时间。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?
咨询建站