测试计划
- 编制单位： 南京构播云网络科技有限公司
- 编制人员： 张坚
- 编制日期： 2025年04月06日
概述
简介
本次测试的主要目标是：验证江苏世纪新城投资控股集团有限公司APP的功能完整性、界面交互合规性及第三方系统集成稳定性。测试范围覆盖C端管理台、移动端APP全功能模块。
本测试计划阅读人员主要有测试人员、研发人员等相关人员；主要描述了项目的测试情况，对该项目的测试内容及测试工作有个全面的了解。
测试提交的文档
测试计划、测试用例、测试报告、用户手册、缺陷跟踪表；
测试方法和范围
测试方法
- 黑盒测试：手工验证核心业务流程（覆盖正常值、边界值、异常值）
- 接口测试：使用Postman或Apifox验证第三方系统集成（支付、OA、腾讯会议等）
- 兼容性测试：覆盖Android 13+ / iOS 14+主流机型及分辨率
- 性能测试：使用JMeter模拟高并发场景（如抢购、直播活动）
- 缺陷管理： 通过JIRA管理缺陷生命周期
测试范围
本测试主要范围如下，包括有功能测试、界面测试、接口测试、兼容性测试、性能测试等等。
测试阶段
测试准备阶段
测试用例的准备
根据需求文档准备测试用例，用例的设计思路从以下几个方面考虑：
- 正常值，边界值，异常值，等以求发现更多的软件缺陷。
- 设计覆盖多模块联动的测试场景（如"领券→酒店预订→支付→积分累计"） 。
- 简单、易懂、可操作性好。
- 考虑从等价类划分、边界值分析、各种覆盖方法等方面来提供。
- 准备特殊字符数据集：
null/\n/超长字符串（如200字符楼盘名称）
测试用例设计原则
- 模块化：按功能板块划分测试集（如"文旅-优惠券系统"）
- 场景化：串联跨模块业务流程（如"领券→酒店预订→支付→积分累计"）
- 数据驱动：准备典型测试数据集（如超长楼盘名称、特殊字符地址等）
测试环境的准备
| 环境类型 |
配置详情 |
| 操作系统 |
Windows 10/11（管理台测试）、macOS Monterey（iOS打包验证） |
| 移动设备 |
华为P50 Pro（HarmonyOS 3.0）、iPhone IOS 14,15,16、小米/荣耀/VIVO/OPPO （Android 13以上） |
| 网络环境 |
5G/4G/弱网（模拟≤100kbps带宽） |
| 数据库 |
MySQL 8.0.28（独立测试实例，每日自动还原基线数据） |
功能测试
功能测试是从验证业务功能和业务流程的实现结果的角度出发，对系统各功能要求进行测试，根据测试用例，逐项测试，检查系统功能是否达到用户的要求。根据监控系统、服务流程测试用例执行测试任务，记录测试结果；对测试过程中存在的软件bug记录到bug管理工具，并进行回归测试；
核心功能
| 模块 |
测试重点 |
| C端管理台 |
组织架构权限分配、统计报表数据准确性、系统配置变更响应 |
| APP首页 |
导航跳转逻辑、动态内容加载性能、新用户领券链路完整性 |
| 文旅板块 |
景点信息匹配精度、优惠券领取/核销时效性、活动套餐库存同步机制 |
| 物业板块 |
报修工单自动派单规则、缴费异常重试机制、人才公寓申请条件校验 |
| 酒店板块 |
房态实时同步验证（APP端与PMS系统）、房内服务响应超时处理、一键导航路径准确性 |
| 地产板块 |
楼盘动态更新推送、房贷计算器公式校验、全民经纪人佣金计算逻辑 |
| 第三方集成 |
支付回调漏单处理、OA审批流程触发业务状态变更、Unicloud数据备份恢复验证 |
边界值测试
| 功能点 |
测试数据 |
预期结果 |
| 缴费金额输入 |
0元、999999.99元、100.000元 |
拦截非法输入并提示 |
| 时间选择器 |
选择1899-01-01、2099-12-31 |
限制可选日期范围（2020-2030） |
| 并发抢购 |
100用户同时抢购"超低价"商品 |
库存扣减与订单一致性验证 |
系统界面测试
|
|
| 测试对象 |
文本框测试 |
| 测试技术及重点 |
1. 输入特殊字符集，如：NULL, \n等； 2. 输入默认值（空白、空格）； 3. 若只允许输入字母，则尝试输入数字；反正，则尝试输入字母； 4. 输入超长的字符（如：文本框最大容纳10个字符，尝试输入11个，检查能否正确处理）； 5. 输入已存在的文件的名称； 6. 输入正常的字母或数字； |
| 完成标准 |
对于非正常的输入，系统能够给出相应的提示框 |
|
|
| 测试对象 |
命令按钮控件的测试 |
| 测试技术及重点 |
1. 点击按钮正常响应操作；如：点击确定，正确执行操作；点击取消，则退出窗口； 2. 对可能造成数据无法恢复的操作，必须给出确认提示，给用户放弃的机会； 3. 对非法的输入或操作给出足够的提示说明； |
| 完成标准 |
能按照要求执行 |
|
|
| 测试对象 |
单选按钮控件的测试 |
| 测试技术及重点 |
1. 一组单选钮不能同时选中，只能选中一个； 2. 逐一执行每个单选按钮的功能。 3. 一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空； |
| 完成标准 |
能按照要求执行 |
|
|
| 测试对象 |
复选框的测试 |
| 测试技术及重点 |
1. 多个复选框可以被同时选中； 2. 多个复选框可以被部分选中； 3. 多个复选框可以都不被选中； 4. 逐一执行每个复选框的功能； |
| 完成标准 |
按照要求实现功能 |
|
|
| 测试对象 |
Up－down控件的测试 |
| 测试技术及重点 |
1. 直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10； 2. 利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用； 3. 直接输入超边界值，系统应该提示重新输入； 4. 输入默认值、空白，进行测试； 5. 输入字符，此时系统应提示输入有误。 |
| 完成标准 |
能按照要求执行 |
|
|
| 测试对象 |
滚动条控件的测试 |
| 测试技术及重点 |
1. 滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比； 2. 拖动滚动条，检查屏幕刷新情况，并查看是否有乱码； 3. 滚动条的上下按钮。 4. 单击滚动条； 5. 用滚轮控制滚动条； |
| 完成标准 |
能按照要求执行 |
|
|
| 测试对象 |
美观与协调性的测试 |
| 测试技术及重点 |
1. 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间； 2. 切忌长宽比例失调、或宽度超过长度。 3. 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。 4. 放置完控件后界面不应有很大的空缺位置。 5. 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。 6. 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。 7. 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。 8. 对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。 9. 通常父窗体支持缩放时，子窗体没有必要缩放。 |
| 完成标准 |
能按照要求执行 |
接口测试
主要是根据接口测试用例，同各个接口负责人执行测试任务，记录测试结果，对存在的问题进行回归测试；验证传输的数据的正确性及文件格式的正确性；
关键接口验证清单
| 接口名称 |
测试方法 |
异常场景覆盖 |
| 海锚易购商品同步 |
模拟商品价格变更后延迟同步 |
价格不一致时APP端展示逻辑 |
| 物业缴费状态查询 |
主动触发银行对账失败 |
前端展示"到账延迟"提示文案 |
| 钉钉登录 |
使用不同组织架构账号登录 |
权限隔离验证（如物业人员无法访问地产） |
| 致远OA审批流 |
触发"工单超时"事件推送OA系统 |
OA生成待办任务并同步至APP消息中心 |
回归测试
在每轮测试结束之后，重新拷贝修改后的最新版本，进行回归测试。
|
|
| 过程要点 |
详细描述 |
| 输入条件 |
在每轮测试中，按照现有的测试用例没有新的缺陷被发现，测试工具中全部的活动缺陷都被解决。 |
| 工作内容 |
1. 验证已解决的问题的正确性，如果正确则关闭bug，不正确则重新打开bug； 2. 验证是否有新问题产生； |
| 退出标准 |
回归测试所运行的用例全部通过，并且没有新的问题产生； |
测试总结报告
在计划的所有测试场景全部执行完毕，所有测试执行周期结束后。测试小组的人员将测试情况进行总结、报告。测试报告的主要内容是汇总在测试执行阶段发现的重要问题及相关重要信息，如果存在没有修复的问题，需要进行问题的移交。测试报告的用户评审结束，标志着系统测试的工作全部完成
测试验收
测试验收工作是在以上工作全部结束后，对测试的过程，效果进行验收，宣布测试结束。
|
|
| 过程要点 |
详细描述 |
| 输入条件 |
测试组完成了平台的测试工作 |
| 工作内容 |
由约定的验收组成员，对本测试进行验收，验收内容包括： 1. 测试效果验收——测试是否达到预期目的 2. 测试文档验收——测试过程文档是否齐全，可信，符合标准 3. 测试评估——从总体对测试的质量进行评估 4. 测试建议——对本次测试工作指出不足，需要在以后工作中改进的地方 5. 宣布测试结束——测试验收组成员签字宣布本次测试结束 |
| 退出标准 |
签发测试验收报告 |
测试管理流程及工具
缺陷分级标准
| 等级 |
定义 |
响应时效 |
| P0 |
核心功能完全失效（如支付失败） |
2小时内处理 |
| P1 |
主要功能异常（优惠券无法核销） |
4小时内处理 |
| P2 |
次要功能问题（地图加载延迟3秒） |
1个工作日内 |
| P3 |
UI轻微偏移/文案错误 |
版本迭代修复 |
缺陷管理流程
|
|
|
| 步骤 |
描述 |
责任人 |
| 第一步：测试人员创建bug |
当缺陷被发现时，测试人员应创建一个新的bug，有如下信息：概述 严重级别、产生的版本、详细描述、提交人、提交时间； |
测试人员 |
| 第二步：审核bug |
测试组长和开发组负责人审核bug的有效性，包括问题的描述是否清晰等，同时审核问题的严重级别，决定此缺陷是否解决 |
测试组长 开发组长 |
| 第三步：指派缺陷修复责任人 |
开发组长将为每个缺陷指定修复责任人 |
开发组长 |
| 第四步：缺陷调查 |
开发小组调查问题原因并进行修复 |
开发组 |
| 第五步：应用测试 |
Bug修复完毕后进行自测试。 |
开发组 |
| 第六步：重新测试 |
将修改后的应用部署到测试环境后，测试人员重新进行测试。 |
测试人员 |
| 第七步：关闭或重新开启 |
如果重新测试后问题已解决，测试人员关闭bug；如果重新测试后仍然未解决，测试人员需要重新开启问题 |
测试人员 |
人员组织及分工
| 角色 |
职责 |
设备权限 |
| 功能测试工程师 |
执行APP全模块功能测试 |
所有测试账号+管理台权限 |
| 接口测试工程师 |
维护第三方系统集成验证 |
服务器日志查看权限 |
| 兼容性测试工程师 |
覆盖Android 13+ / iOS 14+主流机型及分辨率 |
真机云测试平台账号 |
附录：测试风险控制
- 第三方服务不可用：准备备用方案（如切换支付通道）
- 多端同步延迟：设置合理超时阈值（如状态同步≤5秒）