简介这份《银行信贷管理系统测试方案》PDF面向银行软件测试人员、测试管理者以及参与信贷系统质量保障的开发与实施团队用于解决测试范围界定不清、准入与挂起标准模糊、各测试类型缺乏统一执行依据等问题。文档围绕性能测试、功能测试、用户界面测试、兼容性测试、安全性与访问控制测试及回归测试展开逐项说明测试目标、测试范围、所用技术、开始标准与结束标准并给出通过、失败与挂起的判定依据同时介绍等价类划分、边界值分析等方法以及QTP、QC、LoadRunner等工具的技术要求还分析了接口参数测试、低配环境配置测试、可服务性与多系统兼容性验证等要点。资源为1个PDF文件压缩包约416KB篇幅紧凑便于检索与打印。目前已有581人学习下载适合用作测试计划编写模板与用例设计参考也可帮助读者快速建立信贷系统测试的整体框架与验收思路减少遗漏关键测试项的风险。1. 信贷系统测试里先崩的往往不是功能是准入判定接手一套跑在 Delphi 7 SQL Server 2000 上的银行信贷管理系统多数人第一反应是把登录、贷款申请、审批、发放这几条主业务流手工跑一遍跑通就认为可以验收。真正让测试停摆数周的通常不是这几条流程本身而是准入条件没有冻结库里只有几百条模拟数据运维给的操作员账号缺审批权限三台测试机的配置还各不相同。性能测试跑出来的吞吐量没人敢签字回归测试也没法判定“通过”。这份测试方案的核心价值就是把“什么条件下才允许开测”和“什么情况下必须挂起”写成硬约束再往下拆功能、界面、兼容性、安全性各测什么、用什么技术、卡在哪个口径。下面按策略矩阵、接口参数用例、性能与配置基线、安全与访问控制四段展开每段都给出可直接执行的判定口径、参数表和脚本片段适合做测试方案落地的人照着改。2. 六类测试的策略矩阵目标、技术、准入与退出标准的量化测试策略不是把六种测试类型列一遍就完事它解决的是“谁在什么条件下开始、按什么标准收尾”。同一套系统里功能测试的结束标准是 95% 用例通过加最高级缺陷全解性能测试的结束标准却是响应时间和错误率两者不能互相替代。先把六类测试的边界钉死后面写用例、配环境才不会互相打架。2.1 一张表把六类测试的边界钉死测试类型测试目标技术/工具开始标准结束标准性能测试验证并发下的响应时间与吞吐LoadRunner 11g 场景压测环境部署完毕、模块功能完善、数据量同级生产实际结果与用例预期一致功能测试功能正常、异常可处理黑盒测试 QTP 10.0 录制回放用例编写完成并通过评审95% 用例通过且最高级缺陷全解用户界面测试窗口风格、提示、图标与基准版本一致黑盒 QTP 截图比对用例编写完成并通过评审95% 用例通过且最高级缺陷全解兼容性测试不同软硬件组合下运行稳定黑盒多浏览器/OS/分辨率组合项目组移交系统测试各组合下功能均正常实现安全性与访问控制只能操作权限内的功能未授权不可入代码审查 非授权访问模拟项目组移交系统测试各种非法操作无漏洞且系统正常回归测试变更后功能、性能仍满足需求黑盒覆盖全部测试类型被测软件或其环境发生变更95% 用例通过并通过系统测试这张表在实际执行中最容易走样的是“兼容性测试”和“回归测试”两行。兼容性一栏写着“各种组合”落到执行上必须裁剪否则 Windows 2000、XP、Vista、7 加 Linux、Mac、UNIX 再乘分辨率用例数量会失控。常见做法是按业务权重取三档主流环境全功能测边缘环境只跑主干流程淘汰环境只做安装与启动验证。回归测试同理软件或环境每变更一次就全量回归是不现实的通常按变更影响面圈定模块再补一条主干流程走查。提示性能测试的“开始标准”里有一条常被忽略——数据库中必须已具备与日常生产环境同级别的数据量。空库跑出来的响应时间没有任何参考价值。2.2 95% 通过率与“最高级缺陷清零”的统计口径95% 这个数字怎么写都行关键在分母。分母取“全部用例”还是“已执行用例”结论可能差出十几个百分点如果 1000 条用例只执行了 600 条全部通过按全部用例算通过率是 60%按已执行用例算是 100%。方案里同时出现“95% 测试用例通过”和“最高级缺陷全部解决”两个条件时建议把执行率单独作为一道门禁执行率不到 90% 不允许进入收尾评审。用测试管理工具QC 或同类平台导出的执行明细跑一遍统计比人工数表可靠import csv from collections import Counter SEVERE {致命, 严重} # 最高级缺陷的优先级枚举 def gate(path): total run passed 0 open_severe Counter() with open(path, newline, encodingutf-8) as f: for row in csv.DictReader(f): # 字段id,module,priority,status total 1 if row[status] in (通过, 失败): # 仅已执行用例进分母 run 1 passed row[status] 通过 if row[priority] in SEVERE and row[status] ! 通过: open_severe[row[module]] 1 rate passed / run if run else 0 print(f执行率{run/total:.1%} 通过率{rate:.1%} f未通过的最高级缺陷{sum(open_severe.values())}) for mod, n in open_severe.most_common(): print(f 待解模块: {mod} ({n})) return run / total 0.9 and rate 0.95 and not open_severe print(准出判定:, 通过 if gate(qc_cases.csv) else 不通过)status字段建议只保留“通过/失败/未执行/阻塞”四态把“阻塞”单独拎出来因为阻塞用例既不算通过也不算失败它对应的正是挂起条件。priority与缺陷严重级别是两套字段统计“最高级缺陷”时用的是缺陷的严重级别不是用例优先级这里的SEVERE只是示例枚举落到项目里要换成工具中真实的取值。2.3 挂起的四个触发条件与恢复动作挂起不等于停测。方案里列的四个条件——主业务流被某些问题阻断、模块问题导致依赖功能无法测试、人力被抽调、发现程序结构或业务设计不合理——每一条都对应不同的处理动作。前两条属于技术阻塞处理方式是把阻塞点写成缺陷单并标注影响范围同时把不受影响的模块继续往前推第三条属于资源问题需要当天确认归期测试数据准备和用例评审这两类可以离线做的工作优先安排第四条最麻烦程序结构或业务设计不合理往往意味着需求侧的返工这时候继续堆用例是浪费正确的动作是冻结相关模块用例把问题带到需求评审上定结论。恢复测试也有前置条件阻塞缺陷已修复并通过冒烟、被阻塞用例的依赖数据重新准备好、环境回到可复现状态。三者缺一恢复后跑出来的结果不可信。3. 接口参数测试等价类、边界值与用例结构划分信贷系统的接口测试比界面测试更容易漏问题原因是界面上能看见的校验往往只是最后一层真正决定贷款能不能发放的是接口参数和服务端校验。接口测试做扎实回归阶段能省掉大量重复的界面点击。3.1 程序内部环境与外部接口环境要分开搭接口测试环境分两种一种是程序内部的环境比如客户端通过 ADO 直连数据库、调用存储过程另一种是接口所调用的外部环境比如征信查询、核心账务。两者的搭建方式完全不同——内部环境依赖数据库账号、连接串和组件注册外部环境通常需要一个挡板/桩服务把外部返回码按需求可控地造出来。常见做法是给外部接口做一个可切换的挡板正常返回、超时、返回业务错误码三种模式用配置文件切换。挡板不加边界情况的用例根本没法执行因为真实外部系统不会配合你返回一个“账号不存在”的错误。注意内部环境里数据库连接账号必须与生产隔离且不要在测试脚本里硬编码口令用环境变量注入。3.2 参数数据与系统数据必须用不同的数据接口测试数据分两类接口参数数据用例执行所需的系统数据。这两类数据如果复用同一份问题就容易被掩盖——某个客户号上已经挂了一笔未结清贷款新申请的校验逻辑走的是另一条分支用例“通过”了实际业务路径错了。接口参数要按功能逻辑做等价类划分和边界取值别漏边界值和错误点。以贷款申请为例参数合法等价类边界值非法等价类预期返回码贷款金额1 ~ 5000001、500000、0、500001负数、非数字E1001贷款期限1 ~ 360 月1、360、0、361字符串E1002客户号已存在客户首个客户、末位客户不存在、空值E1003操作员具备申请权限权限边界角色无权限角色E1004每一行至少一条合法用例、两条边界用例、一条非法用例。金额的 1 和 500000 是上下界内0 和 500001 是界外这四个点覆盖了绝大多数边界缺陷。3.3 用例结构按功能点粒度划分一个接口功能复杂时把用例按功能点做结构化划分可读性和可维护性都会好一截。划分粒度以“功能点”为准贷款申请接口可以拆成“客户资格校验”“金额期限校验”“重复申请校验”“额度占用”四个功能点同一功能点下再按测试环境和数据不同填充用例。执行动作本身很简单就是调用被测接口重点在预期结果的验证——每个用例都要有验证点但不要在一条用例里重复做相同的验证那只是浪费时间。3.4 可复用的参数化用例实现下面这段用pytest参数化写金额边界接口返回和数据落库两层都断言import pytest, pyodbc, requests BASE http://10.0.0.21:8080/credit/api pytest.fixture(scopemodule) def db(): conn pyodbc.connect( DRIVER{SQL Server};SERVER10.0.0.30;DATABASECREDIT;UIDsa;PWD***, timeout5) yield conn conn.close() pytest.mark.parametrize(amount,code, [ (0, E1001), # 下界外 (1, OK), # 最小合法值 (500000, OK), # 上界内 (500001, E1001), # 上界外 (-1, E1001), # 非法等价类 ]) def test_apply_amount(db, amount, code): r requests.post(f{BASE}/loan/apply, json{ custNo: C20240001, # 每次用独立客户号避免系统数据污染 amount: amount, term: 12, operator: op_apply}, timeout5) body r.json() assert body[code] code if code OK: # 接口通了还要校验落库状态 cur db.cursor() cur.execute(SELECT STATUS FROM LOAN_APPLY WHERE APPLY_NO?, body[applyNo]) assert cur.fetchone()[0] 0 # 0待审批custNo走参数化文件而不是写死是为了保证每次执行用不同的系统数据timeout5是防止内部环境卡屏时用例无限期挂住断言拆成接口返回码和数据库状态两层是因为历史项目里出现过接口返回成功但事务回滚的情况。applyNo由接口返回用它去查库才算闭环验证直接拿客户号查会命中多条历史记录。4. 性能与配置测试LoadRunner 场景、数据量与最低硬件基线性能测试在这套系统上有个特殊约束信贷业务的并发场景和人行、核心系统的交互强耦合压测很容易把上游打挂。场景设计要在“真实”和“可控”之间取平衡同时硬件基线必须写清楚否则一堆“卡屏、蓝屏”的结论无法归因。4.1 性能测试的五个准入前置条件准入不满足就别开压跑出来的数字会被质疑。五个条件逐条确认测试环境部署完毕应用服务器、中间件、数据库、客户端四层都在位测试范围内的模块功能完善主干流程已能跑通测试数据准备完毕运维方提供拥有对应操作权限的操作用户数据库中已具备与日常生产同级别的数据量。最后一条最容易被敷衍。造十万条申请记录和造一千条索引命中路径完全不同前者可能走全表扫描的临界点后者永远走索引。判断数据量是否到位可以比对生产库中主业务表的行数级差量级一致同一数量级即可不必逐行相等。4.2 场景参数与业务检查点脚本场景参数建议一张表定死避免每次压测口径漂移场景并发用户加压方式持续时间目标 TPS响应时间 P90错误率登录50阶梯每 30 秒加 5 用户10 分钟20≤ 2s 0.5%贷款申请100一次性加载15 分钟35≤ 3s 1%贷款审批30阶梯10 分钟10≤ 2s 0.5%脚本里一定要加业务级检查点。只判断 HTTP 200 会把“系统返回了错误页面但状态码正常”的情况算成成功TPS 数据虚高Action() { lr_think_time(3); // 模拟人工操作间隔否则 TPS 失真 web_reg_find(Text登记成功, LAST); // 业务级检查点 lr_start_transaction(loan_apply); web_submit_data(loanApply, Actionhttp://10.0.0.21:8080/credit/loanApply, MethodPOST, ITEMDATA, NamecustNo, Value{custNo}, ENDITEM, Nameamount, Value{amount}, ENDITEM, Nameterm, Value12, ENDITEM, LAST); lr_end_transaction(loan_apply, LR_AUTO); return 0; }参数custNo和amount从参数化文件取取值方式选 Unique Once保证一次压测内不重复提交同一个客户号否则“重复申请”校验会先于业务逻辑返回测到的其实是错误分支。lr_think_time不能省去掉它相当于把每个虚拟用户变成没有停顿的机器人TPS 会明显高于真实用户水平。事务包住的是请求本身检查点放在事务开始前注册失败时事务会被标记为失败并计入错误率。4.3 造出与生产同量级的数据造数脚本要能重复执行且可清理建议表名前缀或独立批次号区分测试数据-- 造与生产同量级的历史申请数据避免在空库上做性能结论 DECLARE i INT 0; WHILE i 100000 BEGIN INSERT INTO LOAN_APPLY (APPLY_NO, CUST_NO, AMOUNT, TERM, STATUS, CREATE_TIME) VALUES (T RIGHT(000000 CAST(i AS VARCHAR), 6), C RIGHT(000000 CAST(i % 50000 AS VARCHAR), 6), 1000 (i % 500) * 100, 12, 1, GETDATE() - (i % 365)); SET i i 1; END UPDATE STATISTICS LOAN_APPLY; -- 造数后刷新统计信息否则执行计划不准 GOCUST_NO取模 50000 是为了让客户维度有重复更接近真实分布STATUS固定为已审批状态保证压测的新申请不会和造出来的数据混淆。造完数据必须更新统计信息否则 SQL Server 2000 的执行计划仍按空表估算压测结论会明显偏差。4.4 配置与依赖测试200M 内存、500MHz 主频与 ADO 组件配置测试要给出明确的下限系统在低于 200M 内存、主频低于 500MHz 的机器上会出现卡屏、蓝屏最低要求 CPU 1.5GHz / 内存 512MB推荐 CPU 2.0GHz / 内存 2GB。这两组数字要写进测试报告作为“在某些终端上不响应”类问题的归因依据否则这类问题会被反复当成缺陷提。环境依赖同样要单独测。这套程序在 Windows 2000、Delphi 7、SQL Server 2000 下编译运行正常在 Windows XP 下正常在 Windows 98 下不能运行——原因是 Windows XP 自带 ADO 库类Windows 98 不带需要自行安装。判断方式很简单看系统目录里有没有msado15.dll这类文件它包含了 ADO 编程所需的接口和常量。上线前给客户端做一次环境预检比事后排查省事得多echo off REM 客户端环境预检ADO 组件与硬件下限 reg query HKCR\ADODB.Connection nul 21 || echo [FAIL] 未注册 ADODB.Connection if exist %SystemRoot%\System32\msado15.dll (echo [OK] msado15.dll) else (echo [FAIL] 缺少 msado15.dll) wmic OS get Caption,TotalVisibleMemorySize /value wmic CPU get MaxClockSpeed /valuereg query判断 ADO 类型是否注册文件存在不代表可用两者一起看才准wmic取内存和主频用来和最低配置要求做对比。脚本输出直接进环境检查记录表部署一台验一台。提示兼容性测试里“不同的网络接入方式”这一项重点是弱网和不同带宽下的超时表现而不是接入方式本身。超时时间配置错了弱网下会出现提交成功但提示失败的重试问题。5. 安全与访问控制测试的验证手法安全测试最怕写成“模拟攻击、检查漏洞”这种没法执行的描述。落到信贷系统上可验证的点其实是有限且明确的权限边界、会话鉴权、数据可恢复性。5.1 权限矩阵逐格验证先把角色和功能的对应关系列成矩阵再逐格验证比随机点菜单有效得多。至少覆盖登录、超级管理员、一般管理员、普通用户四类角色角色贷款申请贷款审批贷款发放计息用户管理普通用户允许拒绝拒绝拒绝拒绝一般管理员允许允许拒绝允许拒绝超级管理员允许允许允许允许允许验证方式是直接调用对应接口而不是只看界面按钮是否隐藏。按钮隐藏只说明前端做了展示控制接口是否鉴权要看服务端返回。重点测三类异常同一用户重复登录是否产生用户冲突权限变更后原会话是否立即失效密码字段在请求和响应中是否可见、是否可复制。权限被收回但旧会话仍能操作是这类系统里最常见的漏洞。5.2 绕过登录路径绝对路径与后退键登录后的链接直接拷贝到新会话中打开能否进入系统——这是绝对路径登录的经典验证。另一个必测项是退出退出后系统是否清除了全部鉴权标记按后退键能否不输入口令回到业务页面。这两项用浏览器直接操作就能验不需要工具。验证时把会话标识Cookie 或服务端 session id在退出前后做一次比对退出后如果该标识仍能换取业务数据即判定未清除。测试结论要落到具体接口和参数上只写“存在会话问题”开发无法定位。5.3 数据库备份恢复是可测的数据库安全可以拆成机密性、完整性、可管理性、独立性、备份与恢复五问其中备份恢复是唯一能用脚本验证的。做法是记录基线快照执行备份与恢复再逐表比对关键字段-- 恢复后一致性核对记录数、金额合计、最大主键 SELECT COUNT(*) AS CNT, SUM(AMOUNT) AS AMT, MAX(APPLY_NO) AS MAXNO FROM LOAN_APPLY WITH (NOLOCK);把这条语句在备份前、恢复后各跑一次三项结果完全一致才算恢复完整。MAX(APPLY_NO)用来确认恢复后没有丢尾部数据只比记录数会漏掉“数量对但内容错”的情况。核对结果连同备份文件大小、恢复耗时一起记入测试记录恢复耗时应与业务可接受的中断时长做比对——这是比“备份是否完整”更实际的判断标准。本文还有配套的精品资源点击获取 银行信贷系统测试方案：准入判定、接口性能与安全验证
简介这份《银行信贷管理系统测试方案》PDF面向银行软件测试人员、测试管理者以及参与信贷系统质量保障的开发与实施团队用于解决测试范围界定不清、准入与挂起标准模糊、各测试类型缺乏统一执行依据等问题。文档围绕性能测试、功能测试、用户界面测试、兼容性测试、安全性与访问控制测试及回归测试展开逐项说明测试目标、测试范围、所用技术、开始标准与结束标准并给出通过、失败与挂起的判定依据同时介绍等价类划分、边界值分析等方法以及QTP、QC、LoadRunner等工具的技术要求还分析了接口参数测试、低配环境配置测试、可服务性与多系统兼容性验证等要点。资源为1个PDF文件压缩包约416KB篇幅紧凑便于检索与打印。目前已有581人学习下载适合用作测试计划编写模板与用例设计参考也可帮助读者快速建立信贷系统测试的整体框架与验收思路减少遗漏关键测试项的风险。1. 信贷系统测试里先崩的往往不是功能是准入判定接手一套跑在 Delphi 7 SQL Server 2000 上的银行信贷管理系统多数人第一反应是把登录、贷款申请、审批、发放这几条主业务流手工跑一遍跑通就认为可以验收。真正让测试停摆数周的通常不是这几条流程本身而是准入条件没有冻结库里只有几百条模拟数据运维给的操作员账号缺审批权限三台测试机的配置还各不相同。性能测试跑出来的吞吐量没人敢签字回归测试也没法判定“通过”。这份测试方案的核心价值就是把“什么条件下才允许开测”和“什么情况下必须挂起”写成硬约束再往下拆功能、界面、兼容性、安全性各测什么、用什么技术、卡在哪个口径。下面按策略矩阵、接口参数用例、性能与配置基线、安全与访问控制四段展开每段都给出可直接执行的判定口径、参数表和脚本片段适合做测试方案落地的人照着改。2. 六类测试的策略矩阵目标、技术、准入与退出标准的量化测试策略不是把六种测试类型列一遍就完事它解决的是“谁在什么条件下开始、按什么标准收尾”。同一套系统里功能测试的结束标准是 95% 用例通过加最高级缺陷全解性能测试的结束标准却是响应时间和错误率两者不能互相替代。先把六类测试的边界钉死后面写用例、配环境才不会互相打架。2.1 一张表把六类测试的边界钉死测试类型测试目标技术/工具开始标准结束标准性能测试验证并发下的响应时间与吞吐LoadRunner 11g 场景压测环境部署完毕、模块功能完善、数据量同级生产实际结果与用例预期一致功能测试功能正常、异常可处理黑盒测试 QTP 10.0 录制回放用例编写完成并通过评审95% 用例通过且最高级缺陷全解用户界面测试窗口风格、提示、图标与基准版本一致黑盒 QTP 截图比对用例编写完成并通过评审95% 用例通过且最高级缺陷全解兼容性测试不同软硬件组合下运行稳定黑盒多浏览器/OS/分辨率组合项目组移交系统测试各组合下功能均正常实现安全性与访问控制只能操作权限内的功能未授权不可入代码审查 非授权访问模拟项目组移交系统测试各种非法操作无漏洞且系统正常回归测试变更后功能、性能仍满足需求黑盒覆盖全部测试类型被测软件或其环境发生变更95% 用例通过并通过系统测试这张表在实际执行中最容易走样的是“兼容性测试”和“回归测试”两行。兼容性一栏写着“各种组合”落到执行上必须裁剪否则 Windows 2000、XP、Vista、7 加 Linux、Mac、UNIX 再乘分辨率用例数量会失控。常见做法是按业务权重取三档主流环境全功能测边缘环境只跑主干流程淘汰环境只做安装与启动验证。回归测试同理软件或环境每变更一次就全量回归是不现实的通常按变更影响面圈定模块再补一条主干流程走查。提示性能测试的“开始标准”里有一条常被忽略——数据库中必须已具备与日常生产环境同级别的数据量。空库跑出来的响应时间没有任何参考价值。2.2 95% 通过率与“最高级缺陷清零”的统计口径95% 这个数字怎么写都行关键在分母。分母取“全部用例”还是“已执行用例”结论可能差出十几个百分点如果 1000 条用例只执行了 600 条全部通过按全部用例算通过率是 60%按已执行用例算是 100%。方案里同时出现“95% 测试用例通过”和“最高级缺陷全部解决”两个条件时建议把执行率单独作为一道门禁执行率不到 90% 不允许进入收尾评审。用测试管理工具QC 或同类平台导出的执行明细跑一遍统计比人工数表可靠import csv from collections import Counter SEVERE {致命, 严重} # 最高级缺陷的优先级枚举 def gate(path): total run passed 0 open_severe Counter() with open(path, newline, encodingutf-8) as f: for row in csv.DictReader(f): # 字段id,module,priority,status total 1 if row[status] in (通过, 失败): # 仅已执行用例进分母 run 1 passed row[status] 通过 if row[priority] in SEVERE and row[status] ! 通过: open_severe[row[module]] 1 rate passed / run if run else 0 print(f执行率{run/total:.1%} 通过率{rate:.1%} f未通过的最高级缺陷{sum(open_severe.values())}) for mod, n in open_severe.most_common(): print(f 待解模块: {mod} ({n})) return run / total 0.9 and rate 0.95 and not open_severe print(准出判定:, 通过 if gate(qc_cases.csv) else 不通过)status字段建议只保留“通过/失败/未执行/阻塞”四态把“阻塞”单独拎出来因为阻塞用例既不算通过也不算失败它对应的正是挂起条件。priority与缺陷严重级别是两套字段统计“最高级缺陷”时用的是缺陷的严重级别不是用例优先级这里的SEVERE只是示例枚举落到项目里要换成工具中真实的取值。2.3 挂起的四个触发条件与恢复动作挂起不等于停测。方案里列的四个条件——主业务流被某些问题阻断、模块问题导致依赖功能无法测试、人力被抽调、发现程序结构或业务设计不合理——每一条都对应不同的处理动作。前两条属于技术阻塞处理方式是把阻塞点写成缺陷单并标注影响范围同时把不受影响的模块继续往前推第三条属于资源问题需要当天确认归期测试数据准备和用例评审这两类可以离线做的工作优先安排第四条最麻烦程序结构或业务设计不合理往往意味着需求侧的返工这时候继续堆用例是浪费正确的动作是冻结相关模块用例把问题带到需求评审上定结论。恢复测试也有前置条件阻塞缺陷已修复并通过冒烟、被阻塞用例的依赖数据重新准备好、环境回到可复现状态。三者缺一恢复后跑出来的结果不可信。3. 接口参数测试等价类、边界值与用例结构划分信贷系统的接口测试比界面测试更容易漏问题原因是界面上能看见的校验往往只是最后一层真正决定贷款能不能发放的是接口参数和服务端校验。接口测试做扎实回归阶段能省掉大量重复的界面点击。3.1 程序内部环境与外部接口环境要分开搭接口测试环境分两种一种是程序内部的环境比如客户端通过 ADO 直连数据库、调用存储过程另一种是接口所调用的外部环境比如征信查询、核心账务。两者的搭建方式完全不同——内部环境依赖数据库账号、连接串和组件注册外部环境通常需要一个挡板/桩服务把外部返回码按需求可控地造出来。常见做法是给外部接口做一个可切换的挡板正常返回、超时、返回业务错误码三种模式用配置文件切换。挡板不加边界情况的用例根本没法执行因为真实外部系统不会配合你返回一个“账号不存在”的错误。注意内部环境里数据库连接账号必须与生产隔离且不要在测试脚本里硬编码口令用环境变量注入。3.2 参数数据与系统数据必须用不同的数据接口测试数据分两类接口参数数据用例执行所需的系统数据。这两类数据如果复用同一份问题就容易被掩盖——某个客户号上已经挂了一笔未结清贷款新申请的校验逻辑走的是另一条分支用例“通过”了实际业务路径错了。接口参数要按功能逻辑做等价类划分和边界取值别漏边界值和错误点。以贷款申请为例参数合法等价类边界值非法等价类预期返回码贷款金额1 ~ 5000001、500000、0、500001负数、非数字E1001贷款期限1 ~ 360 月1、360、0、361字符串E1002客户号已存在客户首个客户、末位客户不存在、空值E1003操作员具备申请权限权限边界角色无权限角色E1004每一行至少一条合法用例、两条边界用例、一条非法用例。金额的 1 和 500000 是上下界内0 和 500001 是界外这四个点覆盖了绝大多数边界缺陷。3.3 用例结构按功能点粒度划分一个接口功能复杂时把用例按功能点做结构化划分可读性和可维护性都会好一截。划分粒度以“功能点”为准贷款申请接口可以拆成“客户资格校验”“金额期限校验”“重复申请校验”“额度占用”四个功能点同一功能点下再按测试环境和数据不同填充用例。执行动作本身很简单就是调用被测接口重点在预期结果的验证——每个用例都要有验证点但不要在一条用例里重复做相同的验证那只是浪费时间。3.4 可复用的参数化用例实现下面这段用pytest参数化写金额边界接口返回和数据落库两层都断言import pytest, pyodbc, requests BASE http://10.0.0.21:8080/credit/api pytest.fixture(scopemodule) def db(): conn pyodbc.connect( DRIVER{SQL Server};SERVER10.0.0.30;DATABASECREDIT;UIDsa;PWD***, timeout5) yield conn conn.close() pytest.mark.parametrize(amount,code, [ (0, E1001), # 下界外 (1, OK), # 最小合法值 (500000, OK), # 上界内 (500001, E1001), # 上界外 (-1, E1001), # 非法等价类 ]) def test_apply_amount(db, amount, code): r requests.post(f{BASE}/loan/apply, json{ custNo: C20240001, # 每次用独立客户号避免系统数据污染 amount: amount, term: 12, operator: op_apply}, timeout5) body r.json() assert body[code] code if code OK: # 接口通了还要校验落库状态 cur db.cursor() cur.execute(SELECT STATUS FROM LOAN_APPLY WHERE APPLY_NO?, body[applyNo]) assert cur.fetchone()[0] 0 # 0待审批custNo走参数化文件而不是写死是为了保证每次执行用不同的系统数据timeout5是防止内部环境卡屏时用例无限期挂住断言拆成接口返回码和数据库状态两层是因为历史项目里出现过接口返回成功但事务回滚的情况。applyNo由接口返回用它去查库才算闭环验证直接拿客户号查会命中多条历史记录。4. 性能与配置测试LoadRunner 场景、数据量与最低硬件基线性能测试在这套系统上有个特殊约束信贷业务的并发场景和人行、核心系统的交互强耦合压测很容易把上游打挂。场景设计要在“真实”和“可控”之间取平衡同时硬件基线必须写清楚否则一堆“卡屏、蓝屏”的结论无法归因。4.1 性能测试的五个准入前置条件准入不满足就别开压跑出来的数字会被质疑。五个条件逐条确认测试环境部署完毕应用服务器、中间件、数据库、客户端四层都在位测试范围内的模块功能完善主干流程已能跑通测试数据准备完毕运维方提供拥有对应操作权限的操作用户数据库中已具备与日常生产同级别的数据量。最后一条最容易被敷衍。造十万条申请记录和造一千条索引命中路径完全不同前者可能走全表扫描的临界点后者永远走索引。判断数据量是否到位可以比对生产库中主业务表的行数级差量级一致同一数量级即可不必逐行相等。4.2 场景参数与业务检查点脚本场景参数建议一张表定死避免每次压测口径漂移场景并发用户加压方式持续时间目标 TPS响应时间 P90错误率登录50阶梯每 30 秒加 5 用户10 分钟20≤ 2s 0.5%贷款申请100一次性加载15 分钟35≤ 3s 1%贷款审批30阶梯10 分钟10≤ 2s 0.5%脚本里一定要加业务级检查点。只判断 HTTP 200 会把“系统返回了错误页面但状态码正常”的情况算成成功TPS 数据虚高Action() { lr_think_time(3); // 模拟人工操作间隔否则 TPS 失真 web_reg_find(Text登记成功, LAST); // 业务级检查点 lr_start_transaction(loan_apply); web_submit_data(loanApply, Actionhttp://10.0.0.21:8080/credit/loanApply, MethodPOST, ITEMDATA, NamecustNo, Value{custNo}, ENDITEM, Nameamount, Value{amount}, ENDITEM, Nameterm, Value12, ENDITEM, LAST); lr_end_transaction(loan_apply, LR_AUTO); return 0; }参数custNo和amount从参数化文件取取值方式选 Unique Once保证一次压测内不重复提交同一个客户号否则“重复申请”校验会先于业务逻辑返回测到的其实是错误分支。lr_think_time不能省去掉它相当于把每个虚拟用户变成没有停顿的机器人TPS 会明显高于真实用户水平。事务包住的是请求本身检查点放在事务开始前注册失败时事务会被标记为失败并计入错误率。4.3 造出与生产同量级的数据造数脚本要能重复执行且可清理建议表名前缀或独立批次号区分测试数据-- 造与生产同量级的历史申请数据避免在空库上做性能结论 DECLARE i INT 0; WHILE i 100000 BEGIN INSERT INTO LOAN_APPLY (APPLY_NO, CUST_NO, AMOUNT, TERM, STATUS, CREATE_TIME) VALUES (T RIGHT(000000 CAST(i AS VARCHAR), 6), C RIGHT(000000 CAST(i % 50000 AS VARCHAR), 6), 1000 (i % 500) * 100, 12, 1, GETDATE() - (i % 365)); SET i i 1; END UPDATE STATISTICS LOAN_APPLY; -- 造数后刷新统计信息否则执行计划不准 GOCUST_NO取模 50000 是为了让客户维度有重复更接近真实分布STATUS固定为已审批状态保证压测的新申请不会和造出来的数据混淆。造完数据必须更新统计信息否则 SQL Server 2000 的执行计划仍按空表估算压测结论会明显偏差。4.4 配置与依赖测试200M 内存、500MHz 主频与 ADO 组件配置测试要给出明确的下限系统在低于 200M 内存、主频低于 500MHz 的机器上会出现卡屏、蓝屏最低要求 CPU 1.5GHz / 内存 512MB推荐 CPU 2.0GHz / 内存 2GB。这两组数字要写进测试报告作为“在某些终端上不响应”类问题的归因依据否则这类问题会被反复当成缺陷提。环境依赖同样要单独测。这套程序在 Windows 2000、Delphi 7、SQL Server 2000 下编译运行正常在 Windows XP 下正常在 Windows 98 下不能运行——原因是 Windows XP 自带 ADO 库类Windows 98 不带需要自行安装。判断方式很简单看系统目录里有没有msado15.dll这类文件它包含了 ADO 编程所需的接口和常量。上线前给客户端做一次环境预检比事后排查省事得多echo off REM 客户端环境预检ADO 组件与硬件下限 reg query HKCR\ADODB.Connection nul 21 || echo [FAIL] 未注册 ADODB.Connection if exist %SystemRoot%\System32\msado15.dll (echo [OK] msado15.dll) else (echo [FAIL] 缺少 msado15.dll) wmic OS get Caption,TotalVisibleMemorySize /value wmic CPU get MaxClockSpeed /valuereg query判断 ADO 类型是否注册文件存在不代表可用两者一起看才准wmic取内存和主频用来和最低配置要求做对比。脚本输出直接进环境检查记录表部署一台验一台。提示兼容性测试里“不同的网络接入方式”这一项重点是弱网和不同带宽下的超时表现而不是接入方式本身。超时时间配置错了弱网下会出现提交成功但提示失败的重试问题。5. 安全与访问控制测试的验证手法安全测试最怕写成“模拟攻击、检查漏洞”这种没法执行的描述。落到信贷系统上可验证的点其实是有限且明确的权限边界、会话鉴权、数据可恢复性。5.1 权限矩阵逐格验证先把角色和功能的对应关系列成矩阵再逐格验证比随机点菜单有效得多。至少覆盖登录、超级管理员、一般管理员、普通用户四类角色角色贷款申请贷款审批贷款发放计息用户管理普通用户允许拒绝拒绝拒绝拒绝一般管理员允许允许拒绝允许拒绝超级管理员允许允许允许允许允许验证方式是直接调用对应接口而不是只看界面按钮是否隐藏。按钮隐藏只说明前端做了展示控制接口是否鉴权要看服务端返回。重点测三类异常同一用户重复登录是否产生用户冲突权限变更后原会话是否立即失效密码字段在请求和响应中是否可见、是否可复制。权限被收回但旧会话仍能操作是这类系统里最常见的漏洞。5.2 绕过登录路径绝对路径与后退键登录后的链接直接拷贝到新会话中打开能否进入系统——这是绝对路径登录的经典验证。另一个必测项是退出退出后系统是否清除了全部鉴权标记按后退键能否不输入口令回到业务页面。这两项用浏览器直接操作就能验不需要工具。验证时把会话标识Cookie 或服务端 session id在退出前后做一次比对退出后如果该标识仍能换取业务数据即判定未清除。测试结论要落到具体接口和参数上只写“存在会话问题”开发无法定位。5.3 数据库备份恢复是可测的数据库安全可以拆成机密性、完整性、可管理性、独立性、备份与恢复五问其中备份恢复是唯一能用脚本验证的。做法是记录基线快照执行备份与恢复再逐表比对关键字段-- 恢复后一致性核对记录数、金额合计、最大主键 SELECT COUNT(*) AS CNT, SUM(AMOUNT) AS AMT, MAX(APPLY_NO) AS MAXNO FROM LOAN_APPLY WITH (NOLOCK);把这条语句在备份前、恢复后各跑一次三项结果完全一致才算恢复完整。MAX(APPLY_NO)用来确认恢复后没有丢尾部数据只比记录数会漏掉“数量对但内容错”的情况。核对结果连同备份文件大小、恢复耗时一起记入测试记录恢复耗时应与业务可接受的中断时长做比对——这是比“备份是否完整”更实际的判断标准。本文还有配套的精品资源点击获取