从TestDirector到LoadRunner：代理商管理系统验收测试全流程解析

简介《代理商管理系统测试报告》是一份面向软件测试人员、项目经理及软件测试学习者的完整测试过程文档围绕代理商信息管理、佣金结算、评估、营销资源分配、接口数据查询、日志信息查询和系统信息设置等功能模块展开验证。测试采用 TestDirector 管理测试计划、执行与缺陷跟踪并使用 LoadRunner 执行负载测试和疲劳测试覆盖功能测试、负载测试、疲劳测试三类方式测试用例按等价类划分、边界值分析和错误推测法设计利用用例场景法覆盖详细设计文档全部功能具备代表性、可判定性和可再现性。文档以 1 个 doc 文件打包大小 35KB内容包含测试环境、测试工具简介、测试方法及模块测试结果表所有被测模块均通过。目前已有 101 人学习适合需要参考系统测试报告结构、了解测试工具应用和测试用例设计思路的读者。1. 从一份测试报告看代理商管理系统的验收逻辑代理商管理系统这种企业内部业务系统通常不会出现在技术社区的热门讨论里但它的测试报告却很有代表性系统涵盖代理商信息维护、佣金结算、评估、营销资源分配、接口数据查询、日志查询和系统设置七个模块既有基础 CRUD又有对接 97 系统与计费系统的数据结算逻辑还牵扯多角色权限分配。这份测试报告的特别之处在于它完整走了一遍 Mercury 工具链——用 TestDirector 管理从用例设计到缺陷跟踪的全流程用 LoadRunner 做并发和疲劳验证而不是只停留在手工点功能。对正在做 B 端管理系统验收的测试工程师来说这套打法可以直接映射到自己的项目里管理类系统怎么设计用例覆盖面、性能测试做到什么程度算够、测试环境怎么搭才能支撑结论。下面的内容会按工具链、用例设计、执行参数、环境与结果复盘四个层面拆开讲中间会给出可以照抄的用例组织方式和性能场景参数。2. TestDirector 与 LoadRunner 的测试链从用例管理到并发压力测试工具的选择决定了测试过程的规范程度。这份报告采用 Mercury 公司的 TestDirector 8.0 做测试管理、LoadRunner 8.1 做性能验证两个工具在当时的企业级测试体系中是标准搭配。TestDirector 的核心价值在于把测试生命周期里的五个环节——测试需求管理、测试计划、测试日程安排、测试执行、缺陷跟踪——统一到一个基于浏览器的平台上开发、测试、管理人员看到的都是同一份进度和同一批缺陷记录。LoadRunner 则负责另外一件事模拟大量用户并发访问系统用来回答系统上线后能不能扛住真实业务压力这个问题。两者叠加恰好覆盖了功能正确性和性能稳定性两个维度。2.1 TestDirector 管理流程的落地方式用 TestDirector 管理测试项目常规做法是先建需求树把详细设计文档里的功能点逐条映射成测试需求再基于需求编写测试计划最后才进入执行和缺陷跟踪。这套流程对应到代理商管理系统需要先梳理出七个模块的业务边界。2.1.1 需求覆盖的映射策略把详细设计文档中的功能点拆成可验证的测试需求是 TestDirector 里最基础也最容易偷懒的一步。以代理商佣金结算模块为例需求树可以这样拆按结算周期查询代理商佣金根据 97 系统与计费系统的数据生成佣金明细佣金计算结果导出与人工复核结算异常的标记与处理每个需求节点都要关联预期结果和优先级。TestDirector 的一大优势是需求和缺陷可以双向追溯——执行用例时发现的缺陷能直接关联到对应的需求节点后期统计哪些需求测过、哪些需求有未关闭缺陷就非常直观。在测试报告里七个模块全部标注是说明这个追溯链条是完整走通的。2.2 LoadRunner 在管理系统性能验证中的角色LoadRunner 的价值体现在 LoadRunner 虚拟用户机制上。LoadRunner 通过录制脚本生成虚拟用户Vuser操作再用 Controller 组件控制虚拟用户的数量、加载方式和运行时长最终由 Analysis 组件汇总响应时间、吞吐量、错误率等指标。对于代理商管理系统这类基于 B/S 架构的内部系统LoadRunner 通常关注三类场景并发登录与基础操作、佣金结算这类数据密集型操作的并发响应、长时间运行的内存与连接稳定性。2.2.1 性能测试脚本的组织方式LoadRunner 脚本一般有 vuser_init、Action、vuser_end 三段结构vuser_init 放登录和初始化操作Action 放被测业务vuser_end 做退出清理。以下是常见做法中登录后查询佣金结算数据的脚本骨架// vuser_init: 登录系统 web_url(login_page, URLhttp://192.168.1.10:8080/agent/login.jsp, LAST); web_submit_form(login, Nameusername, Value{param_username}, ENDITEM, Namepassword, Value{param_password}, ENDITEM, LAST);// Action: 查询佣金结算数据 lr_start_transaction(query_commission); web_submit_data(commission_query, Actionhttp://192.168.1.10:8080/agent/commission/query, MethodPOST, Namesettle_date, Value{param_date}, ENDITEM, Nameagent_id, Value{param_agentid}, ENDITEM, LAST); lr_end_transaction(query_commission, LR_AUTO);// vuser_end: 退出系统 web_url(logout, URLhttp://192.168.1.10:8080/agent/logout, LAST);说明lr_start_transaction 和 lr_end_transaction 是 LoadRunner 脚本中标记事务开始和结束的关键函数被标记的代码块会在 Analysis 报告中单独统计平均响应时间和事务成功率。参数化使用{param_username}、{param_date}这类占位符是为了让不同虚拟用户使用不同账号和数据避免所有并发请求命中同一份数据造成缓存干扰。在实际项目里参数数据通常从数本文还有配套的精品资源点击获取