1. 项目概述从“台词网”到一份完整的毕业设计测试文档最近在辅导一些专升本同学的毕业设计发现一个挺普遍的现象大家花了很多精力在功能开发上但到了测试环节往往就有点“抓瞎”。要么是测试方案写得像流水账要么是测试用例东一榔头西一棒槌性能测试更是直接拿JMeter跑个并发数就完事。正好手头有一个典型的毕业设计项目——“33台词网系统”它的测试文档要求非常全面涵盖了从方案到报告的全套内容。今天我就以这个项目为蓝本结合我这些年带项目、做评审的经验拆解一下如何系统性地完成一份高质量的软件测试毕业设计文档。这不仅仅是交差更是你向未来雇主展示你工程化思维和严谨态度的绝佳机会。“33台词网”听起来像是一个影视台词相关的网站可能包含台词搜索、分类、收藏、用户社区等功能。对于毕业设计而言它通常是一个B/S架构的Web应用。我们的目标不仅仅是“测完”而是要通过一系列规范的文档证明我们理解了软件测试的生命周期并能运用恰当的测试技术来保障质量。你需要交付的将是一套完整的测试资产包包括测试方案指明方向、测试用例作战地图、测试报告成果总结以及体现技术深度的自动化测试脚本和性能测试实施过程最后还有记录问题的缺陷报告。2. 测试方案设计为整个测试活动定下基调测试方案是测试活动的总纲领它回答的是“测什么、怎么测、用什么测、谁来测、何时测”的问题。很多同学把它写成项目简介的扩写版这是大忌。一份好的方案应该能让一个陌生的测试人员快速理解测试范围和策略。2.1 核心需求与测试范围分析首先我们必须基于“33台词网”的需求规格说明书假设你已有一份来界定测试边界。不要想当然要逐条分析。功能测试范围核心业务流用户注册/登录 - 台词搜索支持关键词、影片名、演员名- 查看台词详情 - 收藏/分享台词。这是必须100%覆盖的路径。后台管理功能管理员登录 - 台词库管理增删改查- 用户管理 - 数据统计查看。这部分往往容易被学生忽略但它同样是系统的重要组成部分。非功能性需求这是拉开文档档次的关键。你需要明确性能需求在毕业设计场景下可以设定为“系统在50个并发用户进行搜索操作时平均响应时间应低于2秒服务器CPU使用率低于70%”。这个数字要合理不能拍脑袋可以基于“预计用户量不大”来推导。兼容性需求支持Chrome、Firefox最新版移动端适配主流浏览器。不必追求全覆盖但要有代表性。安全性需求用户密码是否加密存储是否存在SQL注入风险搜索框是重灾区是否有基础的XSS防护测试类型策略功能测试以手动测试为主确保核心业务流程畅通。自动化测试针对核心、稳定的功能如登录、搜索实施UI自动化用于回归测试。这是展示你技术能力的亮点。性能测试使用JMeter对搜索接口和首页加载进行压力测试。这里有个关键点性能测试的目的不是把系统压垮而是验证其是否满足既定的性能需求并寻找瓶颈。接口测试如果系统前后端分离那么对后端API进行接口测试是必须的。使用Postman或PythonRequests库编写自动化脚本。2.2 测试资源与环境规划这部分要具体不能写“一台电脑”。测试环境硬件本地开发机或学校提供的虚拟机。软件明确操作系统Windows 10/11或Ubuntu、数据库版本MySQL 8.0、Web服务器Tomcat 9或Nginx、JDK版本等。环境要与开发环境尽量一致避免环境差异导致的问题。网络局域网环境。性能测试时需确保网络稳定排除网络波动对测试结果的干扰。测试工具选型及理由功能测试管理Excel或TestLink。我推荐使用TestLink虽然需要一点部署成本但它能让你体验真实的测试用例管理流程写在简历上是加分项。自动化测试Selenium WebDriver Python/Java。Python语法简洁上手快适合毕业设计周期。可以配合Pytest测试框架和Allure报告框架让自动化测试显得更专业。性能测试Apache JMeter。开源、强大、社区资源丰富是行业标准工具之一。绝对够用。缺陷管理Jira或禅道。如果条件有限用Excel表格严格记录也可以但必须包含缺陷ID、标题、严重等级、复现步骤、预期/实际结果、提交人、状态等字段。人员与进度明确你的角色测试分析、设计、执行、报告撰写。制定一个甘特图或简单的日程表例如第一周完成方案与用例设计第二周执行功能测试与缺陷提交第三周开展自动化与性能测试第四周整理报告。注意在方案中一定要进行风险评估。例如“项目周期短性能测试可能无法进行多轮调优”、“本人对Selenium自动化测试框架不熟可能需要额外学习时间”。这体现了你的全局观和计划性。3. 测试用例设计把测试思路转化为可执行的步骤测试用例是测试方案的具体化是测试人员执行的“剧本”。设计测试用例的核心方法是等价类划分、边界值分析、场景法和错误推测法。3.1 功能测试用例设计实战以“台词搜索”功能为例我们设计一组测试用例用例ID测试模块测试点前置条件测试步骤预期结果实际结果状态TC-SEARCH-001台词搜索正常关键词搜索1. 用户已登录2. 数据库中存在包含“爱情”的台词1. 在搜索框输入“爱情”2. 点击“搜索”按钮1. 页面显示包含“爱情”的台词列表2. 列表条目数正确3. 高亮显示关键词TC-SEARCH-002台词搜索边界值超长关键词搜索用户已登录1. 输入300个字符的字符串2. 点击搜索1. 系统正常处理可能提示过长或截断2. 页面不崩溃TC-SEARCH-003台词搜索异常输入SQL注入字符用户已登录1. 输入‘ or ‘1’’12. 点击搜索1. 系统应拦截该请求返回友好错误提示而非执行SQL语句或暴露数据库错误信息TC-SEARCH-004台词搜索场景组合搜索影片演员数据库中存在对应数据1. 选择影片“泰坦尼克号”2. 在关键词框输入“Jack”3. 点击搜索显示《泰坦尼克号》中Jack的台词设计要点用例ID要清晰按模块编号便于追踪。步骤要原子化一个步骤只做一个操作描述清晰无歧义。预期结果要可验证不能是“搜索成功”而要是“显示结果列表且第一条结果为XXX”。覆盖正面和负面场景不仅要测“应该怎么用”更要测“不该怎么用”和“乱用会怎样”。3.2 非功能测试用例设计性能测试用例用例1单用户搜索“hello”响应时间基准测试。用例250个并发用户同时执行搜索操作持续5分钟监控平均响应时间、错误率、服务器资源CPU、内存、磁盘I/O、网络带宽。用例3负载测试逐步增加并发用户数10, 20, 30...直到响应时间超过阈值或错误率上升找到系统性能拐点。兼容性测试用例在Chrome 120, Firefox 121, Edge 120上分别执行核心业务流程登录、搜索、查看详情检查页面布局、功能是否正常。安全性测试用例手动测试搜索框的SQL注入和XSS输入scriptalert(xss)/script看是否弹窗。实操心得不要追求用例数量要追求用例质量。一个精心设计的、覆盖了边界和异常情况的用例胜过十个简单的“Happy Path”用例。在设计时多问自己“如果用户这样操作系统会怎样”4. 自动化测试实施让机器代替重复劳动对于毕业设计自动化测试不需要追求全流程覆盖而是要选择最稳定、最高频的功能点做出一个漂亮的“样板工程”。4.1 框架搭建与脚本编写我推荐Python Selenium Pytest Allure这套组合拳技术栈主流效果出众。环境搭建# 安装必要的Python库 pip install selenium pytest pytest-html allure-pytest # 下载对应浏览器版本的WebDriver如ChromeDriver放到系统PATH或项目目录下。目录结构设计autotest_33tai/ ├── conftest.py # Pytest fixture配置如初始化浏览器 ├── page_objects/ # 页面对象模型Page Object │ ├── __init__.py │ ├── login_page.py # 封装登录页面元素和操作 │ └── search_page.py # 封装搜索页面元素和操作 ├── test_cases/ # 测试用例 │ ├── __init__.py │ ├── test_login.py │ └── test_search.py ├── test_data/ # 测试数据 │ └── data.json ├── reports/ # 测试报告 └── utils/ # 工具类 └── common.py编写页面对象Page Object这是关键能让你的脚本可读、可维护。# page_objects/search_page.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC class SearchPage: def __init__(self, driver): self.driver driver self.wait WebDriverWait(driver, 10) # 定位器 SEARCH_INPUT (By.ID, search-input) # 假设搜索框的ID SEARCH_BUTTON (By.ID, search-btn) RESULT_LIST (By.CLASS_NAME, result-item) def enter_keyword(self, keyword): 输入搜索关键词 input_box self.wait.until(EC.presence_of_element_located(self.SEARCH_INPUT)) input_box.clear() input_box.send_keys(keyword) def click_search(self): 点击搜索按钮 self.wait.until(EC.element_to_be_clickable(self.SEARCH_BUTTON)).click() def get_result_count(self): 获取搜索结果数量 results self.wait.until(EC.presence_of_all_elements_located(self.RESULT_LIST)) return len(results)编写测试用例# test_cases/test_search.py import pytest from page_objects.search_page import SearchPage class TestSearch: pytest.fixture(autouseTrue) def setup(self, browser): # browser是conftest.py中定义的fixture返回driver实例 self.driver browser self.search_page SearchPage(self.driver) self.driver.get(http://localhost:8080/33tai) # 你的网站地址 yield # 每个用例执行后可选的清理工作 def test_normal_search(self): 测试正常搜索功能 self.search_page.enter_keyword(经典台词) self.search_page.click_search() result_count self.search_page.get_result_count() assert result_count 0, 搜索未返回任何结果 def test_empty_search(self): 测试输入空字符串搜索 self.search_page.enter_keyword() self.search_page.click_search() # 这里可以断言页面是否有相应提示或者结果列表为空 # 具体逻辑根据你的网站实际行为来定4.2 测试报告生成使用Allure生成美观的测试报告是点睛之笔。运行测试并生成Allure原始数据pytest test_cases/ --alluredir./reports/allure_raw生成并打开HTML报告allure generate ./reports/allure_raw -o ./reports/allure_html --clean allure open ./reports/allure_html最终你的自动化测试部分将包含清晰的代码结构、采用Page Object模式的脚本、以及一份专业的Allure测试报告截图。这足以证明你掌握了现代自动化测试的基本方法论。5. 性能测试执行与瓶颈分析性能测试是很多同学的薄弱环节容易停留在“用JMeter发了请求”的层面。我们要做的是有目标、有分析、有结论的性能测试。5.1 JMeter测试计划设计线程组设计模拟用户并发。线程数用户数根据你的需求来比如50。Ramp-Up Period设置为10秒意思是10秒内启动所有50个用户模拟用户逐渐进入的场景。循环次数勾选“永远”然后通过调度器来控制持续时间例如300秒即5分钟。HTTP请求采样器配置你的搜索请求。协议、服务器名称/IP、端口、路径如/search。方法GET或POST。参数添加一个参数keyword值可以设为${__RandomString(5,abcdefghijklmnopqrstuvwxyz,)}来模拟随机搜索。监听器添加以下关键监听器来收集数据查看结果树调试用正式压测时最好禁用消耗资源。聚合报告最重要的报告之一看平均值、中位数、90%百分位、吞吐量TPS、错误率。响应时间图观察响应时间随时间的变化趋势。每秒事务数观察系统处理能力TPS是否平稳。断言添加响应断言检查返回的HTTP状态码是否为200或者响应数据中是否包含特定文本如“搜索结果”确保请求是真正成功的。5.2 服务器监控与瓶颈定位只压测不监控等于“盲人摸象”。你需要在压测的同时监控服务器的资源使用情况。Windows系统使用性能监视器perfmon添加计数器% Processor Time,Available MBytes,Disk Read/Write Bytes/sec,Network Interface\Bytes Total/sec。Linux系统使用top,vmstat,iostat,netstat命令或者更直观的工具如htop,nmon。数据库监控MySQL的慢查询日志使用SHOW PROCESSLIST;查看当前连接和查询状态。性能瓶颈分析思路看错误率如果错误率聚合报告中的Error %飙升说明系统已经无法处理请求。结合服务器监控看是CPU爆了接近100%还是内存耗尽可用内存极低或者是数据库连接池满了。看响应时间随着并发数增加响应时间是否线性增长如果出现陡增的“拐点”那个点对应的并发数可能就是系统的最大承载点。看TPSTPS是否随着并发数增加而增加达到一个峰值后是否开始下降或波动峰值TPS就是系统的处理能力上限。关联分析当响应时间变长时服务器的CPU、内存、磁盘I/O、网络带宽哪一项先达到瓶颈数据库的CPU和慢查询是否同步增加在你的测试报告中需要附上关键截图JMeter聚合报告结果。响应时间图和TPS图。服务器资源监控图如CPU使用率曲线。如果发现了瓶颈例如CPU在30个并发时就达到95%要分析可能的原因代码效率低数据库查询没加索引并提出简单的优化建议如为keyword字段添加索引。踩坑记录JMeter在Windows上运行本身会消耗大量资源可能成为瓶颈。建议在配置稍好的机器上运行或者使用命令行模式jmeter -n -t testplan.jmx -l result.jtl进行压测以减少GUI开销。压测机和被测服务器一定要分开6. 缺陷报告撰写与测试报告总结6.1 缺陷报告清晰、准确、可复现缺陷报告是开发人员修复问题的依据。一份糟糕的缺陷报告会浪费大量沟通成本。缺陷报告核心要素缺陷ID唯一编号如BUG-001。标题一句话概括问题本质。例如“【搜索功能】输入超长字符串1000字符点击搜索页面崩溃返回500错误”而不是“搜索功能有问题”。严重程度Blocker阻塞、Critical严重、Major主要、Minor次要、Trivial轻微。通常导致核心功能失效、系统崩溃的为Critical或Blocker。优先级P0最高、P1、P2、P3。由项目经理或测试负责人定但你可以建议。通常严重程度高的优先级也高。环境操作系统、浏览器版本、被测软件版本。前置条件测试发生前系统的状态。复现步骤一步一步描述让开发人员能按照步骤100%复现问题。这是最重要的部分预期结果根据需求应该发生什么。实际结果实际发生了什么附上错误截图或日志。附件错误日志、截图、录屏。6.2 测试报告成果的最终呈现测试报告是对整个测试活动的总结是向“客户”你的导师交付的最终成果。它不应是测试结果的简单罗列而应有分析、有结论、有建议。测试报告结构报告概述项目简介、测试目标、测试范围、参考资料。测试环境与工具再次明确。测试执行情况用例执行统计总用例数、通过数、失败数、阻塞数、通过率。缺陷统计缺陷总数、按严重程度分布、按模块分布、当前状态已解决/未解决。用图表展示一目了然。测试结果分析功能测试核心业务流程是否全部通过哪些模块质量较好/较差自动化测试自动化覆盖率、执行效率、稳定性如何性能测试这是重点章节。详细列出性能测试场景、并发用户数、平均响应时间、TPS、错误率、服务器资源峰值。得出结论系统是否满足性能需求瓶颈在哪里例如“在50并发用户下搜索接口平均响应时间为1.8秒满足2秒的需求。但当并发达到70时CPU使用率持续高于90%响应时间超过5秒系统瓶颈在于应用服务器CPU处理能力。”风险评估与建议遗留缺陷的风险是否有未修复的高优先级缺陷对系统上线有何影响测试局限性哪些地方因为时间或环境限制没有测到改进建议给开发团队的建议如优化某SQL查询给未来测试的建议如补充安全测试。最终结论给出明确的结论。例如“本次测试执行了计划内的所有测试类型共发现XX个缺陷已修复XX个。核心功能均通过验证性能指标达到预期。综合评估33台词网系统V1.0版本达到毕业设计要求的质量标准建议通过测试。”最后将所有产出物——测试方案、测试用例Excel或TestLink导出、自动化测试脚本、性能测试JMeter脚本和结果、缺陷报告列表、完整的测试报告——整理成一个清晰的文件夹结构提交给你的导师。这份完整、规范、有深度的测试文档就是你专业能力的最好证明。
1. 项目概述从“台词网”到一份完整的毕业设计测试文档最近在辅导一些专升本同学的毕业设计发现一个挺普遍的现象大家花了很多精力在功能开发上但到了测试环节往往就有点“抓瞎”。要么是测试方案写得像流水账要么是测试用例东一榔头西一棒槌性能测试更是直接拿JMeter跑个并发数就完事。正好手头有一个典型的毕业设计项目——“33台词网系统”它的测试文档要求非常全面涵盖了从方案到报告的全套内容。今天我就以这个项目为蓝本结合我这些年带项目、做评审的经验拆解一下如何系统性地完成一份高质量的软件测试毕业设计文档。这不仅仅是交差更是你向未来雇主展示你工程化思维和严谨态度的绝佳机会。“33台词网”听起来像是一个影视台词相关的网站可能包含台词搜索、分类、收藏、用户社区等功能。对于毕业设计而言它通常是一个B/S架构的Web应用。我们的目标不仅仅是“测完”而是要通过一系列规范的文档证明我们理解了软件测试的生命周期并能运用恰当的测试技术来保障质量。你需要交付的将是一套完整的测试资产包包括测试方案指明方向、测试用例作战地图、测试报告成果总结以及体现技术深度的自动化测试脚本和性能测试实施过程最后还有记录问题的缺陷报告。2. 测试方案设计为整个测试活动定下基调测试方案是测试活动的总纲领它回答的是“测什么、怎么测、用什么测、谁来测、何时测”的问题。很多同学把它写成项目简介的扩写版这是大忌。一份好的方案应该能让一个陌生的测试人员快速理解测试范围和策略。2.1 核心需求与测试范围分析首先我们必须基于“33台词网”的需求规格说明书假设你已有一份来界定测试边界。不要想当然要逐条分析。功能测试范围核心业务流用户注册/登录 - 台词搜索支持关键词、影片名、演员名- 查看台词详情 - 收藏/分享台词。这是必须100%覆盖的路径。后台管理功能管理员登录 - 台词库管理增删改查- 用户管理 - 数据统计查看。这部分往往容易被学生忽略但它同样是系统的重要组成部分。非功能性需求这是拉开文档档次的关键。你需要明确性能需求在毕业设计场景下可以设定为“系统在50个并发用户进行搜索操作时平均响应时间应低于2秒服务器CPU使用率低于70%”。这个数字要合理不能拍脑袋可以基于“预计用户量不大”来推导。兼容性需求支持Chrome、Firefox最新版移动端适配主流浏览器。不必追求全覆盖但要有代表性。安全性需求用户密码是否加密存储是否存在SQL注入风险搜索框是重灾区是否有基础的XSS防护测试类型策略功能测试以手动测试为主确保核心业务流程畅通。自动化测试针对核心、稳定的功能如登录、搜索实施UI自动化用于回归测试。这是展示你技术能力的亮点。性能测试使用JMeter对搜索接口和首页加载进行压力测试。这里有个关键点性能测试的目的不是把系统压垮而是验证其是否满足既定的性能需求并寻找瓶颈。接口测试如果系统前后端分离那么对后端API进行接口测试是必须的。使用Postman或PythonRequests库编写自动化脚本。2.2 测试资源与环境规划这部分要具体不能写“一台电脑”。测试环境硬件本地开发机或学校提供的虚拟机。软件明确操作系统Windows 10/11或Ubuntu、数据库版本MySQL 8.0、Web服务器Tomcat 9或Nginx、JDK版本等。环境要与开发环境尽量一致避免环境差异导致的问题。网络局域网环境。性能测试时需确保网络稳定排除网络波动对测试结果的干扰。测试工具选型及理由功能测试管理Excel或TestLink。我推荐使用TestLink虽然需要一点部署成本但它能让你体验真实的测试用例管理流程写在简历上是加分项。自动化测试Selenium WebDriver Python/Java。Python语法简洁上手快适合毕业设计周期。可以配合Pytest测试框架和Allure报告框架让自动化测试显得更专业。性能测试Apache JMeter。开源、强大、社区资源丰富是行业标准工具之一。绝对够用。缺陷管理Jira或禅道。如果条件有限用Excel表格严格记录也可以但必须包含缺陷ID、标题、严重等级、复现步骤、预期/实际结果、提交人、状态等字段。人员与进度明确你的角色测试分析、设计、执行、报告撰写。制定一个甘特图或简单的日程表例如第一周完成方案与用例设计第二周执行功能测试与缺陷提交第三周开展自动化与性能测试第四周整理报告。注意在方案中一定要进行风险评估。例如“项目周期短性能测试可能无法进行多轮调优”、“本人对Selenium自动化测试框架不熟可能需要额外学习时间”。这体现了你的全局观和计划性。3. 测试用例设计把测试思路转化为可执行的步骤测试用例是测试方案的具体化是测试人员执行的“剧本”。设计测试用例的核心方法是等价类划分、边界值分析、场景法和错误推测法。3.1 功能测试用例设计实战以“台词搜索”功能为例我们设计一组测试用例用例ID测试模块测试点前置条件测试步骤预期结果实际结果状态TC-SEARCH-001台词搜索正常关键词搜索1. 用户已登录2. 数据库中存在包含“爱情”的台词1. 在搜索框输入“爱情”2. 点击“搜索”按钮1. 页面显示包含“爱情”的台词列表2. 列表条目数正确3. 高亮显示关键词TC-SEARCH-002台词搜索边界值超长关键词搜索用户已登录1. 输入300个字符的字符串2. 点击搜索1. 系统正常处理可能提示过长或截断2. 页面不崩溃TC-SEARCH-003台词搜索异常输入SQL注入字符用户已登录1. 输入‘ or ‘1’’12. 点击搜索1. 系统应拦截该请求返回友好错误提示而非执行SQL语句或暴露数据库错误信息TC-SEARCH-004台词搜索场景组合搜索影片演员数据库中存在对应数据1. 选择影片“泰坦尼克号”2. 在关键词框输入“Jack”3. 点击搜索显示《泰坦尼克号》中Jack的台词设计要点用例ID要清晰按模块编号便于追踪。步骤要原子化一个步骤只做一个操作描述清晰无歧义。预期结果要可验证不能是“搜索成功”而要是“显示结果列表且第一条结果为XXX”。覆盖正面和负面场景不仅要测“应该怎么用”更要测“不该怎么用”和“乱用会怎样”。3.2 非功能测试用例设计性能测试用例用例1单用户搜索“hello”响应时间基准测试。用例250个并发用户同时执行搜索操作持续5分钟监控平均响应时间、错误率、服务器资源CPU、内存、磁盘I/O、网络带宽。用例3负载测试逐步增加并发用户数10, 20, 30...直到响应时间超过阈值或错误率上升找到系统性能拐点。兼容性测试用例在Chrome 120, Firefox 121, Edge 120上分别执行核心业务流程登录、搜索、查看详情检查页面布局、功能是否正常。安全性测试用例手动测试搜索框的SQL注入和XSS输入scriptalert(xss)/script看是否弹窗。实操心得不要追求用例数量要追求用例质量。一个精心设计的、覆盖了边界和异常情况的用例胜过十个简单的“Happy Path”用例。在设计时多问自己“如果用户这样操作系统会怎样”4. 自动化测试实施让机器代替重复劳动对于毕业设计自动化测试不需要追求全流程覆盖而是要选择最稳定、最高频的功能点做出一个漂亮的“样板工程”。4.1 框架搭建与脚本编写我推荐Python Selenium Pytest Allure这套组合拳技术栈主流效果出众。环境搭建# 安装必要的Python库 pip install selenium pytest pytest-html allure-pytest # 下载对应浏览器版本的WebDriver如ChromeDriver放到系统PATH或项目目录下。目录结构设计autotest_33tai/ ├── conftest.py # Pytest fixture配置如初始化浏览器 ├── page_objects/ # 页面对象模型Page Object │ ├── __init__.py │ ├── login_page.py # 封装登录页面元素和操作 │ └── search_page.py # 封装搜索页面元素和操作 ├── test_cases/ # 测试用例 │ ├── __init__.py │ ├── test_login.py │ └── test_search.py ├── test_data/ # 测试数据 │ └── data.json ├── reports/ # 测试报告 └── utils/ # 工具类 └── common.py编写页面对象Page Object这是关键能让你的脚本可读、可维护。# page_objects/search_page.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC class SearchPage: def __init__(self, driver): self.driver driver self.wait WebDriverWait(driver, 10) # 定位器 SEARCH_INPUT (By.ID, search-input) # 假设搜索框的ID SEARCH_BUTTON (By.ID, search-btn) RESULT_LIST (By.CLASS_NAME, result-item) def enter_keyword(self, keyword): 输入搜索关键词 input_box self.wait.until(EC.presence_of_element_located(self.SEARCH_INPUT)) input_box.clear() input_box.send_keys(keyword) def click_search(self): 点击搜索按钮 self.wait.until(EC.element_to_be_clickable(self.SEARCH_BUTTON)).click() def get_result_count(self): 获取搜索结果数量 results self.wait.until(EC.presence_of_all_elements_located(self.RESULT_LIST)) return len(results)编写测试用例# test_cases/test_search.py import pytest from page_objects.search_page import SearchPage class TestSearch: pytest.fixture(autouseTrue) def setup(self, browser): # browser是conftest.py中定义的fixture返回driver实例 self.driver browser self.search_page SearchPage(self.driver) self.driver.get(http://localhost:8080/33tai) # 你的网站地址 yield # 每个用例执行后可选的清理工作 def test_normal_search(self): 测试正常搜索功能 self.search_page.enter_keyword(经典台词) self.search_page.click_search() result_count self.search_page.get_result_count() assert result_count 0, 搜索未返回任何结果 def test_empty_search(self): 测试输入空字符串搜索 self.search_page.enter_keyword() self.search_page.click_search() # 这里可以断言页面是否有相应提示或者结果列表为空 # 具体逻辑根据你的网站实际行为来定4.2 测试报告生成使用Allure生成美观的测试报告是点睛之笔。运行测试并生成Allure原始数据pytest test_cases/ --alluredir./reports/allure_raw生成并打开HTML报告allure generate ./reports/allure_raw -o ./reports/allure_html --clean allure open ./reports/allure_html最终你的自动化测试部分将包含清晰的代码结构、采用Page Object模式的脚本、以及一份专业的Allure测试报告截图。这足以证明你掌握了现代自动化测试的基本方法论。5. 性能测试执行与瓶颈分析性能测试是很多同学的薄弱环节容易停留在“用JMeter发了请求”的层面。我们要做的是有目标、有分析、有结论的性能测试。5.1 JMeter测试计划设计线程组设计模拟用户并发。线程数用户数根据你的需求来比如50。Ramp-Up Period设置为10秒意思是10秒内启动所有50个用户模拟用户逐渐进入的场景。循环次数勾选“永远”然后通过调度器来控制持续时间例如300秒即5分钟。HTTP请求采样器配置你的搜索请求。协议、服务器名称/IP、端口、路径如/search。方法GET或POST。参数添加一个参数keyword值可以设为${__RandomString(5,abcdefghijklmnopqrstuvwxyz,)}来模拟随机搜索。监听器添加以下关键监听器来收集数据查看结果树调试用正式压测时最好禁用消耗资源。聚合报告最重要的报告之一看平均值、中位数、90%百分位、吞吐量TPS、错误率。响应时间图观察响应时间随时间的变化趋势。每秒事务数观察系统处理能力TPS是否平稳。断言添加响应断言检查返回的HTTP状态码是否为200或者响应数据中是否包含特定文本如“搜索结果”确保请求是真正成功的。5.2 服务器监控与瓶颈定位只压测不监控等于“盲人摸象”。你需要在压测的同时监控服务器的资源使用情况。Windows系统使用性能监视器perfmon添加计数器% Processor Time,Available MBytes,Disk Read/Write Bytes/sec,Network Interface\Bytes Total/sec。Linux系统使用top,vmstat,iostat,netstat命令或者更直观的工具如htop,nmon。数据库监控MySQL的慢查询日志使用SHOW PROCESSLIST;查看当前连接和查询状态。性能瓶颈分析思路看错误率如果错误率聚合报告中的Error %飙升说明系统已经无法处理请求。结合服务器监控看是CPU爆了接近100%还是内存耗尽可用内存极低或者是数据库连接池满了。看响应时间随着并发数增加响应时间是否线性增长如果出现陡增的“拐点”那个点对应的并发数可能就是系统的最大承载点。看TPSTPS是否随着并发数增加而增加达到一个峰值后是否开始下降或波动峰值TPS就是系统的处理能力上限。关联分析当响应时间变长时服务器的CPU、内存、磁盘I/O、网络带宽哪一项先达到瓶颈数据库的CPU和慢查询是否同步增加在你的测试报告中需要附上关键截图JMeter聚合报告结果。响应时间图和TPS图。服务器资源监控图如CPU使用率曲线。如果发现了瓶颈例如CPU在30个并发时就达到95%要分析可能的原因代码效率低数据库查询没加索引并提出简单的优化建议如为keyword字段添加索引。踩坑记录JMeter在Windows上运行本身会消耗大量资源可能成为瓶颈。建议在配置稍好的机器上运行或者使用命令行模式jmeter -n -t testplan.jmx -l result.jtl进行压测以减少GUI开销。压测机和被测服务器一定要分开6. 缺陷报告撰写与测试报告总结6.1 缺陷报告清晰、准确、可复现缺陷报告是开发人员修复问题的依据。一份糟糕的缺陷报告会浪费大量沟通成本。缺陷报告核心要素缺陷ID唯一编号如BUG-001。标题一句话概括问题本质。例如“【搜索功能】输入超长字符串1000字符点击搜索页面崩溃返回500错误”而不是“搜索功能有问题”。严重程度Blocker阻塞、Critical严重、Major主要、Minor次要、Trivial轻微。通常导致核心功能失效、系统崩溃的为Critical或Blocker。优先级P0最高、P1、P2、P3。由项目经理或测试负责人定但你可以建议。通常严重程度高的优先级也高。环境操作系统、浏览器版本、被测软件版本。前置条件测试发生前系统的状态。复现步骤一步一步描述让开发人员能按照步骤100%复现问题。这是最重要的部分预期结果根据需求应该发生什么。实际结果实际发生了什么附上错误截图或日志。附件错误日志、截图、录屏。6.2 测试报告成果的最终呈现测试报告是对整个测试活动的总结是向“客户”你的导师交付的最终成果。它不应是测试结果的简单罗列而应有分析、有结论、有建议。测试报告结构报告概述项目简介、测试目标、测试范围、参考资料。测试环境与工具再次明确。测试执行情况用例执行统计总用例数、通过数、失败数、阻塞数、通过率。缺陷统计缺陷总数、按严重程度分布、按模块分布、当前状态已解决/未解决。用图表展示一目了然。测试结果分析功能测试核心业务流程是否全部通过哪些模块质量较好/较差自动化测试自动化覆盖率、执行效率、稳定性如何性能测试这是重点章节。详细列出性能测试场景、并发用户数、平均响应时间、TPS、错误率、服务器资源峰值。得出结论系统是否满足性能需求瓶颈在哪里例如“在50并发用户下搜索接口平均响应时间为1.8秒满足2秒的需求。但当并发达到70时CPU使用率持续高于90%响应时间超过5秒系统瓶颈在于应用服务器CPU处理能力。”风险评估与建议遗留缺陷的风险是否有未修复的高优先级缺陷对系统上线有何影响测试局限性哪些地方因为时间或环境限制没有测到改进建议给开发团队的建议如优化某SQL查询给未来测试的建议如补充安全测试。最终结论给出明确的结论。例如“本次测试执行了计划内的所有测试类型共发现XX个缺陷已修复XX个。核心功能均通过验证性能指标达到预期。综合评估33台词网系统V1.0版本达到毕业设计要求的质量标准建议通过测试。”最后将所有产出物——测试方案、测试用例Excel或TestLink导出、自动化测试脚本、性能测试JMeter脚本和结果、缺陷报告列表、完整的测试报告——整理成一个清晰的文件夹结构提交给你的导师。这份完整、规范、有深度的测试文档就是你专业能力的最好证明。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
