简介本资源是一份完整的CRM客户关系管理系统测试计划报告面向软件测试工程师、质量保障人员及高校计算机专业学生用于指导中大型业务系统功能测试方案设计与落地。报告覆盖客户管理、商品管理、预定管理三大核心模块的测试范围、优先级划分、分阶段执行计划含一期单元测试与二期集成测试、详细测试资源禅道9.1、QTP11.5、LoadRunner Professional、环境配置要求及缺陷分级标准具备强实操性与工程参考价值。压缩包为单个32KB的Word文档.docx内容结构规范含12页完整测试计划正文、修订记录、测试进度甘特表、人力资源分工及UI/功能测试策略等关键章节。目前已有655人学习下载读者可直接复用该模板开展同类B/S架构CRM系统的测试规划快速掌握测试范围界定、用例设计依据、Bug清单归档及系统测试报告编制要点。1. 这份 CRM 客户关系管理系统测试计划报告不是模板套用文档而是交付前必须对齐业务逻辑、数据流向与权限边界的实操清单很多团队把“CRM 测试计划”当成 Word 文档交差环节填完测试范围、人员分工、进度表就上传归档。但真实项目里一份合格的 CRM 测试计划报告本质是一份可执行、可追溯、可反推缺陷根因的技术契约——它要能回答销售线索从微信公众号进来的那一刻是否触发了自动分配规则客户等级变更后服务响应 SLA 是否同步刷新财务回款数据更新后销售业绩看板延迟超过 3 秒算不算缺陷这份.docx报告不是终点而是测试活动启动前开发、测试、产品三方对齐“系统到底要做什么、不做什么、怎么验证”的唯一基准。它特别适合正在落地私有化部署 CRM如基于 Ruoyi-Office 扩展的定制系统、或需向甲方交付完整质量证据链的中大型项目团队。如果你的 CRM 已接入企微/钉钉审批流、对接了 ERP 的客户主数据、或启用了动态字段自定义工作流那么这份计划里必须显式声明这些集成点的测试策略否则上线后第一起客诉往往就卡在“客户状态已更新但合同模块没收到通知”。2. 用结构化框架拆解 CRM 测试范围从核心实体生命周期到跨系统集成边界CRM 系统的测试范围极易失焦。泛泛写“测试客户管理模块”毫无意义必须下沉到实体行为与数据契约。我们采用“三层覆盖法”基础实体操作层 → 业务流程闭环层 → 系统集成契约层。每一层都对应可验证的检查项且全部映射到.docx报告中的表格字段。2.1 基础实体操作层锁定客户、联系人、商机、跟进记录四大核心对象这是所有 CRM 的根基。测试计划必须明确每个实体的 CRUD 操作约束而非仅罗列功能点。例如客户Customer创建必填字段校验企业名称非空长度≤50、统一社会信用代码正则校验^[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{6}$、行业分类下拉树选中叶子节点唯一性约束同一租户下手机号邮箱组合不可重复需在测试用例中设计冲突数据默认值逻辑客户等级自动设为“潜在客户”创建时间由服务端生成禁止前端传入。联系人Contact关联逻辑删除客户时其名下联系人是否转为“未归属”而非级联删除联系人手机号修改后是否触发客户主数据同步若启用主数据管理。提示.docx报告中需用表格列出每个实体的“关键字段约束”“状态迁移图”“关联删除策略”避免用“按需求文档执行”模糊表述。字段约束必须引用实际数据库字段名如cust_level_code而非 UI 上的中文标签。2.2 业务流程闭环层聚焦销售漏斗、服务工单、营销活动三条主线CRM 的价值不在单点功能而在流程贯通。测试计划必须定义每条主线的端到端验证路径和断点容错机制销售漏斗Lead → Customer → Opportunity → Contract关键验证点当销售将“线索”转为“客户”时系统是否自动创建一条初始跟进记录并分配给该销售断点测试在“商机阶段”为“方案报价”时强制中断网络再恢复后商机状态是否仍为“方案报价”历史报价附件是否完整服务工单Service TicketSLA 触发逻辑客户等级为“VIP”时工单创建后 2 小时内未分配是否自动升级至主管邮箱状态闭环工单解决后客户满意度评价链接是否通过短信发送评价提交后是否更新客户档案中的last_satisfaction_score字段营销活动Campaign发送控制同一客户 24 小时内不得接收重复活动短信需验证去重逻辑而非仅查发送日志。2.2.1 流程验证的最小可执行命令用 curl 模拟关键状态流转# 模拟将线索转为客户假设 API 接口为 /api/v1/leads/{id}/convert curl -X POST https://crm-api.example.com/api/v1/leads/12345/convert \ -H Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... \ -H Content-Type: application/json \ -d { assign_to: sales_zhang, customer_name: 北京某某科技有限公司, contact_phone: 13800138000 } \ -w \nHTTP Status: %{http_code}\n \ -o /dev/null -s参数说明assign_to必须是系统内有效销售账号contact_phone需符合国家手机号正则^1[3-9]\d{9}$-w参数用于捕获 HTTP 状态码成功应返回201 Created-o /dev/null -s静默输出响应体聚焦状态验证。验证逻辑执行后立即调用查询接口GET /api/v1/customers?phone13800138000确认返回客户 ID、默认等级、以及关联的跟进记录 ID 是否存在。2.3 系统集成契约层明确定义与 ERP、IM、短信平台的数据交换规则CRM 很少孤立运行。测试计划必须将集成点作为独立测试域定义数据格式、时序要求、失败重试策略集成系统数据流向校验要点失败处理ERPSAPERP 同步客户主数据 → CRM字段映射ERP 的KUNNR→ CRM 的erp_customer_idNAME1→company_name长度超限时截断并记录警告日志重试 3 次间隔 30 秒第 4 次失败后进入人工干预队列企业微信客户添加事件 → CRM事件类型change_external_contact中add_way为1扫码添加时是否自动打上“线下展会”标签事件丢失后通过GET /cgi-bin/externalcontact/get_external_contact拉取最新客户列表补偿短信平台阿里云CRM 发送营销短信 → 短信平台请求体中sign_name必须为白名单签名template_code必须匹配已审核模板template_paramJSON 结构需严格匹配模板变量返回429 Too Many Requests时退避 60 秒后重发注意.docx报告中需附上各集成点的原始协议截图如 SAP IDoc 结构图、企微事件推送 JSON 示例而非仅写“按接口文档”。协议截图应标注关键字段与校验逻辑。3. 测试环境与数据构造用 Docker 快速拉起隔离的 CRM 测试实例测试环境混乱是 CRM 测试失败的首要原因。生产库直连、测试数据被多人污染、依赖服务版本不一致——这些问题必须在测试计划中固化解决方案。我们推荐用 Docker Compose 构建轻量、可复现的本地测试环境。3.1 用 docker-compose.yml 定义最小可行环境# docker-compose.test.yml version: 3.8 services: crm-app: image: registry.example.com/crm/backend:v2.4.1 ports: - 8080:8080 environment: - SPRING_PROFILES_ACTIVEtest - DB_URLjdbc:mysql://mysql:3306/crm_test?useSSLfalseserverTimezoneAsia/Shanghai - REDIS_HOSTredis depends_on: - mysql - redis - mock-erp mysql: image: mysql:8.0.33 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: crm_test volumes: - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql redis: image: redis:7.0-alpine command: redis-server --appendonly yes mock-erp: image: python:3.9-slim volumes: - ./mock_erp:/app working_dir: /app command: python -m http.server 8000 ports: - 8000:8000关键配置说明SPRING_PROFILES_ACTIVEtest强制加载测试配置关闭邮件发送、启用内存缓存DB_URL指向容器内 MySQL 地址mysql是服务名Docker DNS 自动解析volumes挂载init.sql初始化脚本确保每次docker-compose up都重建干净数据库mock-erp用 Python 内置服务器模拟 ERP 接口返回预设 JSON避免依赖真实 ERP。3.2 用 Python 脚本批量构造分层测试数据CRM 测试数据需覆盖“正常流、边界值、异常组合”。手动录入效率低且不可复现。以下脚本生成 500 条客户数据按等级、行业、地域分层# generate_test_data.py import random import json from datetime import datetime, timedelta industries [信息技术, 金融, 制造业, 教育, 医疗] levels [潜在客户, 普通客户, VIP客户, 战略客户] regions [华东, 华北, 华南, 西南] def gen_phone(): prefix random.choice([138, 159, 186]) return prefix .join(random.choices(0123456789, k8)) def gen_customer(i): return { id: fCUST{i:05d}, company_name: f测试公司-{i}, industry: random.choice(industries), level: random.choices(levels, weights[40,30,20,10])[0], # 按权重分布 region: random.choice(regions), phone: gen_phone(), created_time: (datetime.now() - timedelta(daysrandom.randint(0, 365))).isoformat() } customers [gen_customer(i) for i in range(1, 501)] with open(test_customers.json, w, encodingutf-8) as f: json.dump(customers, f, ensure_asciiFalse, indent2)执行与验证# 生成数据 python generate_test_data.py # 导入到测试库假设 CRM 提供批量导入 API curl -X POST http://localhost:8080/api/v1/customers/batch \ -H Content-Type: application/json \ -d test_customers.json \ -w \nImported: %{size_upload} records\n -s参数说明weights[40,30,20,10]确保 VIP 客户占比 20%符合真实业务分布created_time随机分布在近一年验证时间相关查询如“近30天新增客户”。3.3 环境一致性检查表确保测试结论可信在.docx报告的“环境说明”章节必须包含此检查表由测试负责人逐项勾选检查项检查方法通过标准勾选数据库字符集SELECT DEFAULT_CHARACTER_SET_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAMEcrm_test;utf8mb4☐Redis 连接池大小查看application-test.yml中spring.redis.lettuce.pool.max-active≥ 20☐Mock ERP 响应延迟curl -w time_total: %{time_total}s\n -o /dev/null -s http://localhost:8000/mock/customer/123≤ 100ms☐时区设置docker exec -it crm-app-app date输出CST或Asia/Shanghai☐提示所有检查命令需直接写入.docx报告测试执行时复制粘贴即可验证。避免写“确认环境已配置正确”等无效描述。4. 缺陷分级与回归策略用 Jira Query LanguageJQL精准定位 CRM 类缺陷CRM 系统缺陷影响面广同一问题可能同时涉及数据、流程、权限。测试计划必须定义清晰的缺陷分级标准并配套自动化回归手段否则上线前回归测试将陷入无休止的手工点击。4.1 CRM 特色缺陷分级标准超越严重/一般/轻微的三层模型传统分级无法体现 CRM 业务特性。我们采用“影响维度 × 业务权重”矩阵影响维度业务权重典型场景升级规则数据一致性高10分客户等级变更后销售业绩看板未更新线索转客户时ERP 主数据未同步2小时内必须响应4小时给出临时修复方案流程阻断中7分销售无法提交商机报价单按钮灰显服务工单无法指派给指定客服下一个迭代必须修复否则阻塞发布体验降级低3分客户列表页搜索框输入中文后首字母排序失效跟进记录编辑框光标跳动可延后至下个次要版本判定逻辑缺陷必须同时满足“影响维度”和“业务权重”才定级。例如“短信模板变量缺失导致发送失败”属于数据一致性 × 高权重影响所有营销活动而非“体验降级”。4.2 用 JQL 实现 CRM 缺陷的精准回归筛选手工回归效率低下。在.docx报告的“回归测试策略”章节必须嵌入可执行的 Jira 查询语句# 回归所有“数据一致性”类缺陷含已关闭 project CRM AND issuetype Bug AND 影响维度 数据一致性 AND status IN (Done, Closed) # 回归“流程阻断”且影响销售漏斗的缺陷 project CRM AND issuetype Bug AND 影响维度 流程阻断 AND text ~ 商机|报价|合同|漏斗 AND status IN (Done, Closed) # 回归最近3个版本中与“客户等级”相关的所有缺陷 project CRM AND issuetype Bug AND text ~ 客户等级|cust_level|VIP AND updated startOfMonth(-3)执行说明将上述 JQL 粘贴至 Jira 搜索栏点击“保存为筛选器”命名为CRM-Regression-DataConsistency。回归测试时直接打开该筛选器批量执行“重新打开”操作触发自动化测试流水线如 Jenkins Job。参数说明text ~ 商机|报价|合同|漏斗使用 Jira 全文检索语法匹配缺陷描述、评论、标题中任意关键词updated startOfMonth(-3)确保只回归近期活跃缺陷避免历史陈旧问题干扰。4.3 自动化回归的最小可行脚本验证客户等级变更的数据链路# regression_customer_level.py import requests import time def test_level_sync(): # Step 1: 更新客户等级为 VIP update_resp requests.post( http://localhost:8080/api/v1/customers/CUST00001/level, json{new_level: VIP客户}, headers{Authorization: Bearer test-token} ) # Step 2: 等待异步任务CRM 通常用 MQ 同步 ERP time.sleep(2) # Step 3: 查询 ERP Mock 接口确认等级已更新 erp_resp requests.get(http://localhost:8000/mock/customer/CUST00001) assert update_resp.status_code 200, CRM 等级更新失败 assert erp_resp.json().get(level) VIP客户, ERP 未同步等级 print(✅ 客户等级变更数据链路验证通过) if __name__ __main__: test_level_sync()执行方式# 在 CI 流水线中运行如 Jenkinsfile stage(CRM Regression) { steps { script { sh python regression_customer_level.py } } }设计逻辑脚本不验证 UI直击数据链路核心——CRM 接口调用 → 异步任务触发 → ERP Mock 接口返回。time.sleep(2)模拟典型 MQ 延迟比轮询更贴近真实场景。5. 测试报告交付物检查确保 .docx 文件本身通过技术合规性扫描.docx报告不仅是文字载体更是交付物。许多甲方会用工具扫描文档元数据、宏、外部链接。测试计划必须包含对.docx文件本身的合规性检查否则可能因文档问题被拒收。5.1 用 python-docx 库自动化检查文档安全属性# check_docx_security.py from docx import Document from docx.oxml.ns import qn from docx.oxml import OxmlElement def check_docx_security(file_path): doc Document(file_path) # 检查是否启用宏禁止 if doc.core_properties.keywords and macro in doc.core_properties.keywords.lower(): raise ValueError(文档包含宏关键词禁止使用宏) # 检查是否嵌入外部链接CRM 测试计划不应有 for rel in doc.part.rels.values(): if http in rel.target_ref: raise ValueError(f文档嵌入外部链接{rel.target_ref}) # 检查作者信息是否为项目组非个人 author doc.core_properties.author if not any(team in author for team in [CRM测试组, XX项目QA]): raise ValueError(f作者信息不规范{author}应为项目组名称) print(✅ .docx 文档安全属性检查通过) if __name__ __main__: check_docx_security(CRM测试计划报告.docx)执行时机该脚本应集成到 CI 流水线在生成.docx后自动执行。参数说明doc.core_properties.author读取 Word 文档属性中的作者字段rel.target_ref遍历所有关系包括图片、超链接、嵌入对象确保无http协议外链。5.2 WPS/Office 兼容性强制规范规避“wps 不能默认新建docx”类问题网络热词中频繁出现 WPS 兼容问题。测试计划必须规定.docx的生成方式杜绝手动另存为项目规范要求违规示例检查方法文件格式必须用python-docx库生成目标兼容 Office 2016用 WPS 手动编辑后“另存为 .docx”用file CRM测试计划报告.docx命令查看 MIME 类型应为application/vnd.openxmlformats-officedocument.wordprocessingml.document字体嵌入正文字体仅限微软雅黑、宋体、Arial使用汉仪旗黑等非系统字体在 Word 中打开 → “文件” → “选项” → “保存” → 检查“在文件中嵌入字体”是否关闭样式定义所有标题用内置样式标题1/标题2禁用直接设置字号手动将标题设为“16号加粗”用docx2python库解析检查paragraph.style.name是否为Heading 1提示.docx报告末尾需添加“技术合规性声明”小节明确列出以上三项并附上file命令输出截图及python-docx生成代码片段证明非手工编辑。5.3 交付前最终检查清单签字前必须完成的 5 项硬性动作在.docx报告封底必须嵌入此清单由测试经理、开发负责人、产品经理三方签字序号检查项执行人日期签字1所有测试用例 ID 已在 TestLink/Jira 中创建并关联需求QA2环境检查表3.3节全部勾选通过DevOps3JQL 回归筛选器已保存并验证返回结果准确QA4.docx安全检查脚本5.1节执行通过QA5文档字体、样式、格式符合 5.2 节规范附file命令输出QA执行逻辑任一检查项未完成报告不得进入评审流程。签字即代表对测试范围、数据、环境、交付物的全责承诺。技术依据该清单直接对应 ISO/IEC/IEEE 29119-3 标准中“测试计划批准条件”确保交付物具备审计追溯性。本文还有配套的精品资源点击获取 CRM测试计划实操指南：实体生命周期与跨系统集成验证
简介本资源是一份完整的CRM客户关系管理系统测试计划报告面向软件测试工程师、质量保障人员及高校计算机专业学生用于指导中大型业务系统功能测试方案设计与落地。报告覆盖客户管理、商品管理、预定管理三大核心模块的测试范围、优先级划分、分阶段执行计划含一期单元测试与二期集成测试、详细测试资源禅道9.1、QTP11.5、LoadRunner Professional、环境配置要求及缺陷分级标准具备强实操性与工程参考价值。压缩包为单个32KB的Word文档.docx内容结构规范含12页完整测试计划正文、修订记录、测试进度甘特表、人力资源分工及UI/功能测试策略等关键章节。目前已有655人学习下载读者可直接复用该模板开展同类B/S架构CRM系统的测试规划快速掌握测试范围界定、用例设计依据、Bug清单归档及系统测试报告编制要点。1. 这份 CRM 客户关系管理系统测试计划报告不是模板套用文档而是交付前必须对齐业务逻辑、数据流向与权限边界的实操清单很多团队把“CRM 测试计划”当成 Word 文档交差环节填完测试范围、人员分工、进度表就上传归档。但真实项目里一份合格的 CRM 测试计划报告本质是一份可执行、可追溯、可反推缺陷根因的技术契约——它要能回答销售线索从微信公众号进来的那一刻是否触发了自动分配规则客户等级变更后服务响应 SLA 是否同步刷新财务回款数据更新后销售业绩看板延迟超过 3 秒算不算缺陷这份.docx报告不是终点而是测试活动启动前开发、测试、产品三方对齐“系统到底要做什么、不做什么、怎么验证”的唯一基准。它特别适合正在落地私有化部署 CRM如基于 Ruoyi-Office 扩展的定制系统、或需向甲方交付完整质量证据链的中大型项目团队。如果你的 CRM 已接入企微/钉钉审批流、对接了 ERP 的客户主数据、或启用了动态字段自定义工作流那么这份计划里必须显式声明这些集成点的测试策略否则上线后第一起客诉往往就卡在“客户状态已更新但合同模块没收到通知”。2. 用结构化框架拆解 CRM 测试范围从核心实体生命周期到跨系统集成边界CRM 系统的测试范围极易失焦。泛泛写“测试客户管理模块”毫无意义必须下沉到实体行为与数据契约。我们采用“三层覆盖法”基础实体操作层 → 业务流程闭环层 → 系统集成契约层。每一层都对应可验证的检查项且全部映射到.docx报告中的表格字段。2.1 基础实体操作层锁定客户、联系人、商机、跟进记录四大核心对象这是所有 CRM 的根基。测试计划必须明确每个实体的 CRUD 操作约束而非仅罗列功能点。例如客户Customer创建必填字段校验企业名称非空长度≤50、统一社会信用代码正则校验^[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{2}[0-9A-HJ-NPQRTUWXY]{6}$、行业分类下拉树选中叶子节点唯一性约束同一租户下手机号邮箱组合不可重复需在测试用例中设计冲突数据默认值逻辑客户等级自动设为“潜在客户”创建时间由服务端生成禁止前端传入。联系人Contact关联逻辑删除客户时其名下联系人是否转为“未归属”而非级联删除联系人手机号修改后是否触发客户主数据同步若启用主数据管理。提示.docx报告中需用表格列出每个实体的“关键字段约束”“状态迁移图”“关联删除策略”避免用“按需求文档执行”模糊表述。字段约束必须引用实际数据库字段名如cust_level_code而非 UI 上的中文标签。2.2 业务流程闭环层聚焦销售漏斗、服务工单、营销活动三条主线CRM 的价值不在单点功能而在流程贯通。测试计划必须定义每条主线的端到端验证路径和断点容错机制销售漏斗Lead → Customer → Opportunity → Contract关键验证点当销售将“线索”转为“客户”时系统是否自动创建一条初始跟进记录并分配给该销售断点测试在“商机阶段”为“方案报价”时强制中断网络再恢复后商机状态是否仍为“方案报价”历史报价附件是否完整服务工单Service TicketSLA 触发逻辑客户等级为“VIP”时工单创建后 2 小时内未分配是否自动升级至主管邮箱状态闭环工单解决后客户满意度评价链接是否通过短信发送评价提交后是否更新客户档案中的last_satisfaction_score字段营销活动Campaign发送控制同一客户 24 小时内不得接收重复活动短信需验证去重逻辑而非仅查发送日志。2.2.1 流程验证的最小可执行命令用 curl 模拟关键状态流转# 模拟将线索转为客户假设 API 接口为 /api/v1/leads/{id}/convert curl -X POST https://crm-api.example.com/api/v1/leads/12345/convert \ -H Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... \ -H Content-Type: application/json \ -d { assign_to: sales_zhang, customer_name: 北京某某科技有限公司, contact_phone: 13800138000 } \ -w \nHTTP Status: %{http_code}\n \ -o /dev/null -s参数说明assign_to必须是系统内有效销售账号contact_phone需符合国家手机号正则^1[3-9]\d{9}$-w参数用于捕获 HTTP 状态码成功应返回201 Created-o /dev/null -s静默输出响应体聚焦状态验证。验证逻辑执行后立即调用查询接口GET /api/v1/customers?phone13800138000确认返回客户 ID、默认等级、以及关联的跟进记录 ID 是否存在。2.3 系统集成契约层明确定义与 ERP、IM、短信平台的数据交换规则CRM 很少孤立运行。测试计划必须将集成点作为独立测试域定义数据格式、时序要求、失败重试策略集成系统数据流向校验要点失败处理ERPSAPERP 同步客户主数据 → CRM字段映射ERP 的KUNNR→ CRM 的erp_customer_idNAME1→company_name长度超限时截断并记录警告日志重试 3 次间隔 30 秒第 4 次失败后进入人工干预队列企业微信客户添加事件 → CRM事件类型change_external_contact中add_way为1扫码添加时是否自动打上“线下展会”标签事件丢失后通过GET /cgi-bin/externalcontact/get_external_contact拉取最新客户列表补偿短信平台阿里云CRM 发送营销短信 → 短信平台请求体中sign_name必须为白名单签名template_code必须匹配已审核模板template_paramJSON 结构需严格匹配模板变量返回429 Too Many Requests时退避 60 秒后重发注意.docx报告中需附上各集成点的原始协议截图如 SAP IDoc 结构图、企微事件推送 JSON 示例而非仅写“按接口文档”。协议截图应标注关键字段与校验逻辑。3. 测试环境与数据构造用 Docker 快速拉起隔离的 CRM 测试实例测试环境混乱是 CRM 测试失败的首要原因。生产库直连、测试数据被多人污染、依赖服务版本不一致——这些问题必须在测试计划中固化解决方案。我们推荐用 Docker Compose 构建轻量、可复现的本地测试环境。3.1 用 docker-compose.yml 定义最小可行环境# docker-compose.test.yml version: 3.8 services: crm-app: image: registry.example.com/crm/backend:v2.4.1 ports: - 8080:8080 environment: - SPRING_PROFILES_ACTIVEtest - DB_URLjdbc:mysql://mysql:3306/crm_test?useSSLfalseserverTimezoneAsia/Shanghai - REDIS_HOSTredis depends_on: - mysql - redis - mock-erp mysql: image: mysql:8.0.33 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: crm_test volumes: - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql redis: image: redis:7.0-alpine command: redis-server --appendonly yes mock-erp: image: python:3.9-slim volumes: - ./mock_erp:/app working_dir: /app command: python -m http.server 8000 ports: - 8000:8000关键配置说明SPRING_PROFILES_ACTIVEtest强制加载测试配置关闭邮件发送、启用内存缓存DB_URL指向容器内 MySQL 地址mysql是服务名Docker DNS 自动解析volumes挂载init.sql初始化脚本确保每次docker-compose up都重建干净数据库mock-erp用 Python 内置服务器模拟 ERP 接口返回预设 JSON避免依赖真实 ERP。3.2 用 Python 脚本批量构造分层测试数据CRM 测试数据需覆盖“正常流、边界值、异常组合”。手动录入效率低且不可复现。以下脚本生成 500 条客户数据按等级、行业、地域分层# generate_test_data.py import random import json from datetime import datetime, timedelta industries [信息技术, 金融, 制造业, 教育, 医疗] levels [潜在客户, 普通客户, VIP客户, 战略客户] regions [华东, 华北, 华南, 西南] def gen_phone(): prefix random.choice([138, 159, 186]) return prefix .join(random.choices(0123456789, k8)) def gen_customer(i): return { id: fCUST{i:05d}, company_name: f测试公司-{i}, industry: random.choice(industries), level: random.choices(levels, weights[40,30,20,10])[0], # 按权重分布 region: random.choice(regions), phone: gen_phone(), created_time: (datetime.now() - timedelta(daysrandom.randint(0, 365))).isoformat() } customers [gen_customer(i) for i in range(1, 501)] with open(test_customers.json, w, encodingutf-8) as f: json.dump(customers, f, ensure_asciiFalse, indent2)执行与验证# 生成数据 python generate_test_data.py # 导入到测试库假设 CRM 提供批量导入 API curl -X POST http://localhost:8080/api/v1/customers/batch \ -H Content-Type: application/json \ -d test_customers.json \ -w \nImported: %{size_upload} records\n -s参数说明weights[40,30,20,10]确保 VIP 客户占比 20%符合真实业务分布created_time随机分布在近一年验证时间相关查询如“近30天新增客户”。3.3 环境一致性检查表确保测试结论可信在.docx报告的“环境说明”章节必须包含此检查表由测试负责人逐项勾选检查项检查方法通过标准勾选数据库字符集SELECT DEFAULT_CHARACTER_SET_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAMEcrm_test;utf8mb4☐Redis 连接池大小查看application-test.yml中spring.redis.lettuce.pool.max-active≥ 20☐Mock ERP 响应延迟curl -w time_total: %{time_total}s\n -o /dev/null -s http://localhost:8000/mock/customer/123≤ 100ms☐时区设置docker exec -it crm-app-app date输出CST或Asia/Shanghai☐提示所有检查命令需直接写入.docx报告测试执行时复制粘贴即可验证。避免写“确认环境已配置正确”等无效描述。4. 缺陷分级与回归策略用 Jira Query LanguageJQL精准定位 CRM 类缺陷CRM 系统缺陷影响面广同一问题可能同时涉及数据、流程、权限。测试计划必须定义清晰的缺陷分级标准并配套自动化回归手段否则上线前回归测试将陷入无休止的手工点击。4.1 CRM 特色缺陷分级标准超越严重/一般/轻微的三层模型传统分级无法体现 CRM 业务特性。我们采用“影响维度 × 业务权重”矩阵影响维度业务权重典型场景升级规则数据一致性高10分客户等级变更后销售业绩看板未更新线索转客户时ERP 主数据未同步2小时内必须响应4小时给出临时修复方案流程阻断中7分销售无法提交商机报价单按钮灰显服务工单无法指派给指定客服下一个迭代必须修复否则阻塞发布体验降级低3分客户列表页搜索框输入中文后首字母排序失效跟进记录编辑框光标跳动可延后至下个次要版本判定逻辑缺陷必须同时满足“影响维度”和“业务权重”才定级。例如“短信模板变量缺失导致发送失败”属于数据一致性 × 高权重影响所有营销活动而非“体验降级”。4.2 用 JQL 实现 CRM 缺陷的精准回归筛选手工回归效率低下。在.docx报告的“回归测试策略”章节必须嵌入可执行的 Jira 查询语句# 回归所有“数据一致性”类缺陷含已关闭 project CRM AND issuetype Bug AND 影响维度 数据一致性 AND status IN (Done, Closed) # 回归“流程阻断”且影响销售漏斗的缺陷 project CRM AND issuetype Bug AND 影响维度 流程阻断 AND text ~ 商机|报价|合同|漏斗 AND status IN (Done, Closed) # 回归最近3个版本中与“客户等级”相关的所有缺陷 project CRM AND issuetype Bug AND text ~ 客户等级|cust_level|VIP AND updated startOfMonth(-3)执行说明将上述 JQL 粘贴至 Jira 搜索栏点击“保存为筛选器”命名为CRM-Regression-DataConsistency。回归测试时直接打开该筛选器批量执行“重新打开”操作触发自动化测试流水线如 Jenkins Job。参数说明text ~ 商机|报价|合同|漏斗使用 Jira 全文检索语法匹配缺陷描述、评论、标题中任意关键词updated startOfMonth(-3)确保只回归近期活跃缺陷避免历史陈旧问题干扰。4.3 自动化回归的最小可行脚本验证客户等级变更的数据链路# regression_customer_level.py import requests import time def test_level_sync(): # Step 1: 更新客户等级为 VIP update_resp requests.post( http://localhost:8080/api/v1/customers/CUST00001/level, json{new_level: VIP客户}, headers{Authorization: Bearer test-token} ) # Step 2: 等待异步任务CRM 通常用 MQ 同步 ERP time.sleep(2) # Step 3: 查询 ERP Mock 接口确认等级已更新 erp_resp requests.get(http://localhost:8000/mock/customer/CUST00001) assert update_resp.status_code 200, CRM 等级更新失败 assert erp_resp.json().get(level) VIP客户, ERP 未同步等级 print(✅ 客户等级变更数据链路验证通过) if __name__ __main__: test_level_sync()执行方式# 在 CI 流水线中运行如 Jenkinsfile stage(CRM Regression) { steps { script { sh python regression_customer_level.py } } }设计逻辑脚本不验证 UI直击数据链路核心——CRM 接口调用 → 异步任务触发 → ERP Mock 接口返回。time.sleep(2)模拟典型 MQ 延迟比轮询更贴近真实场景。5. 测试报告交付物检查确保 .docx 文件本身通过技术合规性扫描.docx报告不仅是文字载体更是交付物。许多甲方会用工具扫描文档元数据、宏、外部链接。测试计划必须包含对.docx文件本身的合规性检查否则可能因文档问题被拒收。5.1 用 python-docx 库自动化检查文档安全属性# check_docx_security.py from docx import Document from docx.oxml.ns import qn from docx.oxml import OxmlElement def check_docx_security(file_path): doc Document(file_path) # 检查是否启用宏禁止 if doc.core_properties.keywords and macro in doc.core_properties.keywords.lower(): raise ValueError(文档包含宏关键词禁止使用宏) # 检查是否嵌入外部链接CRM 测试计划不应有 for rel in doc.part.rels.values(): if http in rel.target_ref: raise ValueError(f文档嵌入外部链接{rel.target_ref}) # 检查作者信息是否为项目组非个人 author doc.core_properties.author if not any(team in author for team in [CRM测试组, XX项目QA]): raise ValueError(f作者信息不规范{author}应为项目组名称) print(✅ .docx 文档安全属性检查通过) if __name__ __main__: check_docx_security(CRM测试计划报告.docx)执行时机该脚本应集成到 CI 流水线在生成.docx后自动执行。参数说明doc.core_properties.author读取 Word 文档属性中的作者字段rel.target_ref遍历所有关系包括图片、超链接、嵌入对象确保无http协议外链。5.2 WPS/Office 兼容性强制规范规避“wps 不能默认新建docx”类问题网络热词中频繁出现 WPS 兼容问题。测试计划必须规定.docx的生成方式杜绝手动另存为项目规范要求违规示例检查方法文件格式必须用python-docx库生成目标兼容 Office 2016用 WPS 手动编辑后“另存为 .docx”用file CRM测试计划报告.docx命令查看 MIME 类型应为application/vnd.openxmlformats-officedocument.wordprocessingml.document字体嵌入正文字体仅限微软雅黑、宋体、Arial使用汉仪旗黑等非系统字体在 Word 中打开 → “文件” → “选项” → “保存” → 检查“在文件中嵌入字体”是否关闭样式定义所有标题用内置样式标题1/标题2禁用直接设置字号手动将标题设为“16号加粗”用docx2python库解析检查paragraph.style.name是否为Heading 1提示.docx报告末尾需添加“技术合规性声明”小节明确列出以上三项并附上file命令输出截图及python-docx生成代码片段证明非手工编辑。5.3 交付前最终检查清单签字前必须完成的 5 项硬性动作在.docx报告封底必须嵌入此清单由测试经理、开发负责人、产品经理三方签字序号检查项执行人日期签字1所有测试用例 ID 已在 TestLink/Jira 中创建并关联需求QA2环境检查表3.3节全部勾选通过DevOps3JQL 回归筛选器已保存并验证返回结果准确QA4.docx安全检查脚本5.1节执行通过QA5文档字体、样式、格式符合 5.2 节规范附file命令输出QA执行逻辑任一检查项未完成报告不得进入评审流程。签字即代表对测试范围、数据、环境、交付物的全责承诺。技术依据该清单直接对应 ISO/IEC/IEEE 29119-3 标准中“测试计划批准条件”确保交付物具备审计追溯性。本文还有配套的精品资源点击获取