系统外部描述（目的 技术原理）
2.1 适用的网络拓扑/应用场景（场景范围）
pdo设备在客户端 运营平台在云端
2.2 产品系统适用的网络管理方式
系统服务的设备对象需要可以连接到绿盟云端，需要云端可以访问设备的web界面，并且设备和云端通过A接口连接
2.3 系统硬件关联性
依赖于绿盟云值守运营平台，对硬件平台没有强烈的依赖，后续的日志大数据分析系统对硬件要求较高
3 系统设计
pdo产品运营云端平台 和多个系统之间都有消息交互，具体包括NBOSS 项目管理IT系统 产品反馈支持CASE系统 云端日志分析系统
3.1 系统技术架构
日志分析平台 设备远程运营门户 产品支持企业微信服务平台
3.2 平台软件子系统模块描述
3.3 应用层子系统模块描述
PDO-V1.0R00F00项目测试方案
一简介 二测试范围 三测试策略 四测试资源 五测试策略风险及应对
1.1 编写目的 根据评审通过的需求文档，确定测试范围和测试结束标准
推荐可采用的测试策略 并对这些策略加以说明
确定测试所需的资源和所需投入的时间
预估测试策略可能引入的风险，并对风险应对措施提出建议
如实记录在项目执行中测试方案的变更内容和原因
1.2 背景 pdo的版本开发是在绿盟云运维平台上进行的
1 客户 订单和服务管理：客户信息生成 订单\服务模版管理
2 设备管理 设备信息同步 运营设备管理
3 时间管理：新建事件 设备上线 设备升级 软硬件故障时件 知识库智能关联
4 事件通知：设备上线通知模板管理 设备升级通知 统治策略的更改
5 知识库的管理：知识库的创建和维护 添加 修改 同步 搜索
6 角色和权限管理：权限管理 账号管理
7 微信公众号：事件管理 设备管理 知识库管理完善
8 报表管理 实施报告的生成
2.1 功能测试范围
重要程度 都是（高）（第一个迭代）
测试内容 描述
客户 订单和服务模版管理 从NBOSS中同步客户和项目信息 ，生成客户 订单及
订单服务模版功能验证
设备管理 设备信息的同步（证书 设备生成序列号等），对设备的操作
（上线提醒和上线后的设备实时在线状态提醒，新建运营事件）
功能验证 需要增加设备权限功能的测试（同一账号登录时看到的设 备信息不同）
事件管理 设备上线 升级 软硬件故障告警事件验证（时间的建立 事件处理 业务 流程的正常性），事件相关关键知识和知识库的关联（升级前从知识 库获取升级相关的信息）
事件通知 设备上线 升级 软硬件故障通知模版内容的验证 通知策略功能验证（邮 件和短信）
知识库管理 知识库的同步（用的是同一个接口，需要保证咱们这边提交的知识能同 步到知识库 ），新增 修改 搜索功能验证
权限管理 1 增加东西南北四个区的区域技术接口人的账号权限可以管理该区域内 工程师(增加和删除)，创建事件分配权限
2 一线工程同事只能查看待处理事件的权限
微信公众号门户 事件管理（查看 处理事件：需验证附件下载功能），设备管理（设备列 表和状态，以及设备的详细内容）
报表管理 实施报告正常生成的功能验证
2.2 性能测试 无
2.3 其他测试范围 ：稳定性 安全性 兼容性等测试内容 看文档《需求规格说明书》
2.4 测试环境覆盖
2.4.1 测试拓扑覆盖
测试环境要求
A新值守平台及相关组建环境2套
1一套用于新功能测试 （使用目前的pamc2.0 测试环境）
2一套灰度上线环境（使用目前pamc2.0灰度测试环境）
3另外需单独部署的组件，目前想到的有web api 和redis数据库
测试环境账号说明：（添加主机解析）
访问方法，修改本机hosts文件（eg, Win7：C:\Windows\System32\drivers\etc\hosts），添加：
10.5.0.228 portaL.wq.test.intra.nsfocus.com
10.5.0.228 pamc.wq.test.intra.nsfocus.com
访问https://portaL.wq.test.intra.nsfocus.com 和https://pamc.wq.test.intra.nsfocus.com
测试用户名/密码：test_100 [email protected]#
环境部署升级说明：
1 测试环境根据开发提供的升级包及部署文档，进行测试环境的升级部署。
2 绿盟云每次发布新版本，都会给各个服务接口人发送邮件，告知这次绿盟云新版本涉及到的新功能各 个服务可以根据自己的实际情况决定自己的环境是否也需要同步升级，升级时，平台团队只升级绿盟 云 的相关模块。
测试结束标准
测试结束标准准中，和质量目标相关的度量项，请以绿盟公司《20XX年产品线研发质量目标》中公布的数据和计算方法为准。其中，“质量红线”是指，“不达到标准，不能过点”的质量指标；“重要度量”是指，“是否达到标准不作为过点的必要条件，但是如果没有达到标准，必须要给出后续可行的质量保证措施”的质量指标。
|
质量维度 |
度量指标 |
度量类别 |
TR5-目标值 |
TR6-目标值 |
|
*需求实现 |
需求交付比 |
质量红线 |
100% |
100% |
|
硬件/OS环境适应性 |
质量红线 |
N/A |
100% |
|
|
UI界面问题解决情况 |
质量红线 |
N/A |
>=70% |
|
|
代码交付 |
测试用例首次执行通过率 |
重要度量 |
>=70% |
>=70% |
|
接收测试通过率 |
重要度量 |
>=70% |
>=70% |
|
|
*测试验证 |
测试用例执行率 |
质量红线 |
100% |
100% |
三 测试策略
[ 测试策略提供了推荐用于测试对象的方法，说明如何对各种测试类型进行测试。如果不实施某种测试，则应该加以说明，并陈述这样做的理由。例如，“出于项目提交时间和进度安排上考虑，将不实施该项测试”或“不适用”。
3.1 安装 生产 升级测试（保证安装 镜像生产 升级功能正常 ）
测试目标 验证系统升级功能 及升级环境部署规范性
测试范围 验证系统功能升级的有效性
测试方法 1手动升级及环境部署 2验证开发提供部署文档的正确性
完成标准 支持升级功能，并符合升级过程的规范性，升级功能有效
测试重点和优先级 高
需考虑的特殊事项：有些组件需要单独部署
3.2 功能测试
测试目标 1确定系统满足需求规格的全部目标项
2验证产品设计功能的正确性
3验证功能数据的准确性
测试范围：看2.1功能测试范围
测试方法：1 根据功能模块设计，需求，接口等，涉及具体模块测试策略，设计功能测试用例
2 核心业务测试用例评审需要相关测试参与，应对模块开发，评审后进行验证测试
3 结合实际业务，考虑多种业务场景，对多种不同场景进行模拟或真实数据测试，验证业务 场景的准确性及合理性
4 利用有效数据及无效数据验证各功能实现正确性及异常处理的合理性
5 利用实验环境进行核心业务的功能验证，确保更能符合最终客户要求
完成标准：1 功能满足需求并满足设计
2 评审测试用例已全部执行
3 不跟核心业务已经过实验局的运营数据的验证，符合发布标准
4 所发现的Normal及以上级别BUG已全部处理，遗留的未解决BUG经过评审，不影响产品发布
测试重点和优先级 优先级高
需考虑的特殊事项 1 测试过程中梳理新增核心业务的自动化测试点，测试接口等内容
2 由于本项目涉及多个系统（NBOSS case系统 知识库管理系统）测试过程中会通过接口模拟数据，这样可能和实际环境存在差异；为避免风险建议测试环境过程中有可用是实验局环境进行验证
3.3 性能测试
本节包括但不限于性能指标评测、负载测试、强度测试及容量测试。例如：核实具体的性能需求是否都已满足，如：
1. 设备转发能力；
2. 设备处理新建并发能力；
3. 对各种业务流量的处理性能；
4. 不同拓扑组网下的性能；
5. 各种配置的上限，例如是否允许配置1000条规则。
注：如果涉及到基于背景数据环境的测试，测试中务必要覆盖到该部分。]
3.4 稳定性测试
测试目标 验证已定业务的情况下运行一定时间系统的工作状况
测试范围 平台整体至少7*24小时不间断运行
测试方法 1主体业务完成迭代开发后 ，灰度环境运行系统
2 添加外网实验局测试数据 尽可能模拟后续线上业务容量测试
3 检查过程中各模拟组件CPU 内存 硬盘 数据处理等是否正常
4 检查各关键业务操作是否正常
5 业务监控系统协助稳定性测试
6 业务的事件告警数量统计
完成标准 持续运行过程中，保持业务功能正常运行，系统资源占用及数据处理情况保持合理范围内
测试重点和优先级 高
需要考虑的特殊事项：
3.5安全性测试
3.6 兼容性测试
3.7 UI/UE测试
3.8 文档测试
四 资源测试
4.1 测试人员资源
4.2 测试设备资源
硬件 灰度测试环境一套
功能测试环境一套
另外需要部署的组件
软件资源
4.3 测试时间安排
五 测试策略风险及应对
5.1 测试策略风险
5.2 风险应对措施