简介Openstack云平台项目测试报告面向云平台运维、测试工程师及项目验收人员用于验证生产集群云平台的功能可用性与运行可靠性。报告模拟云平台运营中的全部功能性操作并通过模拟服务进程崩溃、硬件故障等方式考察系统稳定性适合作为云平台测试方案设计与验收参考。资源包内含1个docx文档压缩包约299KB结构完整、目录清晰。文档从测试目的、测试环境说明入手详列控制台、计算存储融合节点等硬件配置及CentOS 7、QEMU-KVM等软件版本并给出测试环境要求与过程控制方法。核心章节覆盖控制台、运营平台、计费平台、工单平台及监控功能测试逐项列出测试标准与结果最后附测试总结与结论分析。目前已有471人学习下载可帮助读者掌握云平台各功能模块的验证要点、故障模拟思路与测试报告撰写框架。1. 从一份 70 页的 OpenStack 测试报告说起它到底能帮你避开哪些坑如果你正在交付一套 OpenStack 私有云或者刚接手一个已经上线、但没人说得清“到底测过什么”的生产集群这份《Openstack 云平台项目测试报告.docx》值得你逐页翻一遍。它不是那种只写“功能正常、测试通过”的走过场文档而是把控制台、运营平台、计费平台、工单平台、监控五个模块的测试项一条条列出来连“锁定云主机后 admin 角色不受 lock 影响”这种边界行为都写进了测试标准里。换句话说它是一份可以直接拿来当验收清单用的实测记录。这份报告对应的环境是实施软件版本 4.0底层 CentOS 7 1611、内核 3.10.0-514.26、QEMU-KVM 2.6.0、Libvirt 2.0.0-10硬件上是控制网络融合节点加计算存储融合节点的组合。测试目的很明确验证生产集群云平台的功能可用性并且通过模拟服务进程崩溃和硬件故障来检验可靠性。适合谁看一是正在做 OpenStack 交付、需要一份可参照的测试用例基线的工程师二是运维团队想拿它当日常巡检和故障演练的对照表三是刚接触 OpenStack 云平台搭建、想搞清楚“一个合格的私有云到底要测哪些东西”的新手。下面我按“这份报告怎么用、每个模块测什么、参数怎么对、坑在哪”的顺序拆开讲。2. 测试环境与过程控制先把硬件清单和入口条件对齐2.1 硬件与软件版本核对报告里的硬件环境写得比较简略只给了设备类型和用途没有具体型号和数量。表 2-1 列了“服务器控制网络融合节点”和“服务器计算存储融合节点”两类但数量栏是空的。这在实际交付里是个常见问题——测试报告往往只写架构角色不写具体配置。我一般会补一张自己的核对表把每台机器的 CPU、内存、磁盘、网卡和角色对应上否则后面做故障模拟时根本不知道哪台挂了会影响什么。软件版本这块信息是完整的直接抄下来对版本组件版本实施软件版本4.0操作系统CentOS 7 1611内核版本3.10.0-514.26QEMU-KVM2.6.0Libvirt2.0.0-10这几个版本号要重点看。CentOS 7 1611 对应的是 3.10.0-514 系列内核QEMU-KVM 2.6.0 和 Libvirt 2.0.0-10 是配套的。如果你现在用的是更新的版本比如 QEMU 4.x 以上报告里某些测试项的行为可能不一样尤其是云主机搁置、救援、重建这几个涉及镜像和快照的操作。常见做法是先在测试环境把版本对齐再跑一遍报告里的用例确认行为一致后再上生产。2.2 测试环境要求与入口条件报告里对物理环境的要求写得很具体室温 15~35℃相对湿度 30%~70%电源 220V±10%还要有满足用电和网络通讯的设施。这些不是凑字数是实打实会影响测试结果的。我遇到过机房空调故障导致某台计算节点温度过高、CPU 降频结果云主机创建时间从 20 秒变成 50 秒差点误判为性能不达标。所以测试前先确认环境条件别让物理因素背锅。测试入口条件有两条一是测试环境以及人员、设备等资源到位二是测试用例基线化。第二条容易被忽略。“用例基线化”意味着你手里得有一份冻结的测试用例版本不能测到一半临时加需求。我一般会把报告里的测试项导出成表格每条标注“通过/不通过/阻塞”阻塞的必须写清楚原因比如“依赖的公网 IP 池未配置”。2.3 受测设备状态检查正式测试前要检查硬件集成情况、网络配置情况、应用系统部署情况还要确认测试文件和人员到位。这一步我习惯用一段脚本来做快速巡检比人工翻界面靠谱# OpenStack 测试前环境巡检脚本 # 检查各节点服务状态和基础资源 # 1. 检查控制节点核心服务 for svc in nova-api nova-scheduler nova-conductor neutron-server keystone cinder-api glance-api; do systemctl is-active $svc /dev/null 21 echo $svc: OK || echo $svc: FAIL done # 2. 检查计算节点 libvirt 和 nova-compute for host in $(openstack compute service list -f value -c Host); do ssh $host systemctl is-active libvirtd systemctl is-active nova-compute \ echo $host: OK || echo $host: FAIL done # 3. 检查存储后端 openstack volume service list -f value -c Binary -c State # 4. 检查网络代理 for host in $(openstack network agent list -f value -c Host); do echo $host openstack network agent list --host $host -f value -c Alive -c State done这段脚本的逻辑是先确认控制节点上 nova、neutron、keystone、cinder、glance 的核心服务都在跑再逐台计算节点检查 libvirtd 和 nova-compute然后看 cinder 卷服务和 neutron 网络代理的状态。参数上systemctl is-active返回 active 才算正常openstack compute service list里的 State 列要是 upopenstack network agent list里的 Alive 列要是 True。如果哪一步 FAIL先别急着往下测把服务拉起来再说。报告里说的“受测设备状态需要在系统测试开始前部署并调试就绪”落到操作上就是这套检查。3. 控制台功能性测试云主机全生命周期怎么逐项验证3.1 创建、登录与状态操作控制台测试是整份报告里篇幅最大的部分从创建云主机一直测到删除基本覆盖了云主机的完整生命周期。创建这块分单台和批量单台要测密码登录和密钥登录两种方式批量要一次创建 10 台并且单台创建时间小于 30 秒。这个 30 秒是个硬指标我建议在测试时用time命令卡一下# 测试单台云主机创建耗时 time openstack server create \ --flavor m1.medium \ --image centos7-1611 \ --nic net-id网络ID \ --security-group default \ test-vm-01 # 批量创建 10 台并记录总耗时 time for i in $(seq 1 10); do openstack server create \ --flavor m1.medium \ --image centos7-1611 \ --nic net-id网络ID \ --security-group default \ test-vm-batch-$i done wait参数说明--flavor指定规格--image指定镜像--nic指定网络--security-group指定安全组。批量创建时用放到后台并行执行wait等全部完成。如果单台超过 30 秒先看镜像是不是太大、存储后端是不是满了、调度器有没有报错。常见原因是镜像放在慢速存储上或者计算节点资源不足导致调度排队。状态操作这块报告列得很细关机、开机、重启、暂停、取消暂停、挂起、恢复、锁定、解锁、救援、恢复救援、搁置、取消搁置、重建。每个操作都有明确的预期状态。我挑几个容易出问题的说。锁定云主机这条报告特别注明“只限于普通用户admin 角色的用户不受 lock 的影响并且无论加锁与否都可以正常执行操作”。这个行为在测试时一定要用普通用户验证别用 admin 测完就以为通过了。我见过有人用 admin 账号测锁定发现还能重启以为功能有 bug其实是权限模型设计如此。搁置云主机这条报告提到“在此过程中会创建一个名称以 shelved 结尾的主机快照”。这个快照是搁置机制自动生成的不是用户手动创建的快照。测试时要确认快照确实存在并且取消搁置后云主机能正常恢复。如果搁置失败先看 nova 的 shelve 相关日志常见原因是镜像服务连不上或者快照存储空间不足。3.2 网络、安全组与密钥对网络操作包括绑定公网 IP、解除公网 IP、加入网络、修改安全组。绑定公网 IP 分两种情况选择已有公网 IP 和创建新公网 IP。测试标准里写“绑定后公网 IP 地址生效云主机可通过公网访问”验证时不能只看界面显示要实际从外部 ping 或者 ssh 一下。加入网络这块报告测了四种路径顶部“更多”菜单选子网、顶部“更多”菜单选网卡、详细信息页选子网、详细信息页选网卡。这四种路径最终效果一样但界面入口不同测试时要都走一遍确认没有哪个入口漏了参数。另外还测了“云主机加入多个网络创建两个子网一台虚拟机选择两个子网虚拟机网络可达两个网络的网关可绑定弹性 IP正常访问外网”。这个场景在多网络环境中很常见验证时要确认路由表和安全组规则都正确。安全组测试分创建、修改名称、详细信息、修改规则、删除。修改规则又分上行和下行每条都要测添加和删除。报告里有一条很关键“选择 1 个已绑定到网卡的安全组执行删除操作安全组删除操作不成功界面显示正常操作过程中无报错。”这是预期行为——安全组被网卡引用时不能删。测试时如果发现能删掉反而是 bug。密钥对测试包括创建选择“创建密钥”和“导入密钥”两种、使用密钥对创建 Linux 云主机、删除单个和批量删除。导入密钥时要注意公钥格式常见做法是用ssh-keygen -t rsa -b 2048生成然后把~/.ssh/id_rsa.pub的内容粘贴进去。如果导入后创建云主机登录不了先检查公钥有没有换行符或者多余空格。3.3 云硬盘与快照操作云硬盘分容量型和性能型测试项基本对称创建、创建快照、挂载、卸载、扩容、设置只读、设置读写、详细信息、创建转让、接收转让、删除。扩容这块有个细节报告测了三种情况——新创建未使用的、挂载后安全卸载的、使用中的。前两种扩容成功第三种扩容不成功。这是符合预期的使用中的云硬盘不能直接扩容必须先卸载。测试时如果发现使用中也能扩容要确认是不是底层存储支持在线扩容否则可能是 bug。创建快照分顶部菜单和详细信息页两个入口每个入口又分未使用和使用中两种状态。四个组合都要测。快照创建后要验证数据一致性报告里写“快照中的数据与原虚拟机保持一致”。我一般会在云主机里创建一个带时间戳的文件打快照后用快照创建新云主机登录进去看文件在不在。删除云硬盘也有边界未使用的可以删使用中的删不掉。这个和删除安全组的逻辑类似都是引用保护。测试时确认界面有明确提示而不是静默失败。4. 运营、计费、工单与监控四个平台的测试要点4.1 运营平台与计费平台运营平台功能性测试在报告里从第 38 页开始计费平台从第 62 页开始。运营平台主要测云主机管理、存储管理、网络管理这些运营侧功能计费平台测计费规则管理和计费记录管理。这两个平台的测试有一个共同点它们依赖控制台已经创建好的资源。所以测试顺序不能乱必须先跑完控制台测试确保云主机、云硬盘、网络都正常再测运营和计费。计费平台的测试要特别注意计费规则的生效时间。常见做法是创建一个按小时计费的规则然后开一台云主机等一个计费周期后看账单有没有生成。如果账单没出来先检查计费服务有没有定时任务在跑再看云主机的计量数据有没有上报。报告里没有展开计费的具体规则但测试标准写的是“计费记录管理”说明至少覆盖了记录的生成和查询。4.2 工单平台与监控功能工单平台从第 63 页开始测工单管理和任务管理。工单系统的测试重点是状态流转创建工单、派单、处理、关闭每个状态变更都要确认通知和权限正确。监控功能测试从第 68 页开始测资源监控和性能监控。报告里提到“通过模拟服务进程崩溃和硬件故障等方式”来测试这是监控测试的关键——不能只看监控界面有没有数据要真的制造故障看能不能告警。我一般会做两个故障模拟一是手动停掉某台计算节点的 nova-compute 服务看监控平台多久发出告警二是拔掉一台节点的网线或者关掉网卡看网络监控能不能检测到。告警延迟和准确性是重点。如果停服务后 5 分钟还没告警检查监控 agent 的心跳间隔和告警规则阈值。4.3 测试过程控制中的故障模拟报告在第 3 章“测试过程控制”里提到测试目的包括“通过模拟服务进程崩溃和硬件故障等方式”验证可靠性。虽然正文没有展开具体怎么模拟但结合 OpenStack 的常见做法我一般会做这几类# 故障模拟 1停掉计算节点 nova-compute ssh 计算节点 systemctl stop nova-compute # 预期控制台该节点状态变为 down已有云主机不受影响新调度不落到该节点 # 故障模拟 2停掉控制节点 nova-api ssh 控制节点 systemctl stop nova-api # 预期控制台 API 不可用但已运行的云主机不受影响 # 故障模拟 3模拟存储后端故障 # 如果是 Ceph可以临时屏蔽某个 OSD ceph osd out osd-id # 预期卷读写可能降级但不应丢失数据这些模拟的目的是验证云平台在部分组件故障时还能不能维持核心功能。测试标准里没有写具体的恢复时间要求但实际交付时一般要求控制服务故障后 5 分钟内恢复计算节点故障后云主机 10 分钟内恢复。如果达不到就要看高可用配置和集群仲裁参数。5. 避坑与常见问题测试报告里没写但一定会遇到的五件事5.1 云主机创建成功但 VNC 黑屏现象云主机状态是 active但 VNC 打开后黑屏看不到登录界面。原因通常是镜像里没有安装正确的显示驱动或者 QEMU-KVM 版本和镜像不兼容。报告里测的是 CentOS 7 1611 和 Windows 镜像如果你用的镜像版本不同先确认镜像里有没有 virtio 驱动。解决方法是重新制作镜像把 virtio-gpu 和 virtio-input 驱动打进去或者换用报告里验证过的镜像版本。5.2 安全组规则改了但不生效现象在控制台修改了安全组规则添加了允许 22 端口的入站规则但 ssh 还是连不上。原因可能是规则没有应用到正确的网卡上或者安全组绑定了多个网卡但只改了其中一个。解决方法是先确认云主机的网络端口绑定了哪些安全组然后逐条检查规则的方向和协议。报告里测了“修改安全组换其他安全组”“添加安全组”“减少安全组”三种操作每种都要确认规则实际生效不能只看界面。5.3 云硬盘扩容后文件系统没变大现象在控制台把云硬盘从 100G 扩到 200G挂载到云主机后df -h还是显示 100G。原因是控制台扩容的是块设备容量文件系统还需要手动扩展。解决方法是登录云主机用growpart扩展分区再用resize2fs或xfs_growfs扩展文件系统# 扩展分区 growpart /dev/vda 1 # 扩展 ext4 文件系统 resize2fs /dev/vda1 # 如果是 xfs xfs_growfs /报告里测了“挂载到云主机云硬盘容量增加原有分区及数据无影响”但没写文件系统扩展这一步。实际交付时这一步必须做否则用户会以为扩容失败。5.4 搁置云主机后快照删不掉现象云主机搁置后自动生成了 shelved 快照取消搁置后想删这个快照发现删不掉。原因是快照还被搁置的云主机引用或者删除顺序不对。解决方法是先确认云主机已经完全恢复状态 active再删快照。如果还是删不掉检查 glance 服务状态和快照的 owner 权限。报告里提到搁置会创建快照但没写快照的生命周期管理这是实际运维中容易踩的坑。5.5 批量删除云主机时部分失败现象选了 5 台以上云主机执行批量删除结果有几台删不掉界面报错但不明显。原因可能是某台云主机还有挂载的云硬盘没卸载或者有未删除的快照。解决方法是先逐台检查云主机的依赖资源把云硬盘卸载、快照删除后再批量删。报告里测的是“选择 5 台以上云主机执行删除操作成功”但没写依赖检查。我一般会在批量删除前跑一遍依赖扫描# 检查云主机的挂载卷和快照 for vm in $(openstack server list -f value -c ID); do echo $vm openstack server show $vm -f value -c volumes_attached openstack volume list --server $vm -f value -c ID -c Status done6. 把测试报告变成可复用的验收脚本我的三个进阶习惯这份报告最大的价值不是它测了什么而是它给出了一套可复用的测试标准。我把它落地成三个习惯每次交付新集群都走一遍。第一个习惯是把报告里的测试项转成自动化脚本。控制台的功能测试大部分可以通过 OpenStack CLI 完成比如创建、状态操作、网络绑定、安全组修改。我写了一个 Python 脚本用openstack命令和requests库调 API把报告里的“通过/不通过”变成脚本的 exit code。这样每次环境变更后跑一遍几分钟就能知道有没有回归。# 简化的验收脚本框架 import subprocess def check(cmd, expect_keywordNone): 执行命令并检查输出 result subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue) if result.returncode ! 0: return False, result.stderr if expect_keyword and expect_keyword not in result.stdout: return False, f未找到关键字: {expect_keyword} return True, result.stdout # 测试项创建云主机 ok, msg check( openstack server create --flavor m1.medium --image centos7 --nic net-idxxx --wait test-vm, ACTIVE ) print(f创建云主机: {通过 if ok else 失败 - msg}) # 测试项锁定云主机 ok, msg check(openstack server lock test-vm) print(f锁定云主机: {通过 if ok else 失败}) # 测试项删除云主机 ok, msg check(openstack server delete --wait test-vm) print(f删除云主机: {通过 if ok else 失败})这个框架的关键是--wait参数它会阻塞到操作完成避免脚本跑完了资源还没就绪。参数上--flavor、--image、--nic要换成你环境里的实际值。如果某一步失败脚本会打印错误信息方便定位。第二个习惯是记录每次测试的版本基线。报告里写的是实施软件版本 4.0但 OpenStack 的每个组件都有自己的版本号。我一般会在测试报告开头加一张版本快照表把nova-manage version、neutron --version、cinder-manage version这些命令的输出都记下来。这样下次环境升级后能快速对比哪些组件变了、哪些测试项可能受影响。第三个习惯是把故障模拟常态化。报告里提到模拟服务进程崩溃和硬件故障但很多团队只在验收时做一次。我建议把故障模拟做成定期演练比如每月停一次某个计算节点的服务看监控告警和自动恢复是否正常。从那以后我每次交付新集群都强制走一遍“停服务-看告警-恢复服务-确认状态”的流程不跳过。希望帮到你。本文还有配套的精品资源点击获取
OpenStack云平台测试报告深度解读：从测试用例到验收脚本的工程实践
简介Openstack云平台项目测试报告面向云平台运维、测试工程师及项目验收人员用于验证生产集群云平台的功能可用性与运行可靠性。报告模拟云平台运营中的全部功能性操作并通过模拟服务进程崩溃、硬件故障等方式考察系统稳定性适合作为云平台测试方案设计与验收参考。资源包内含1个docx文档压缩包约299KB结构完整、目录清晰。文档从测试目的、测试环境说明入手详列控制台、计算存储融合节点等硬件配置及CentOS 7、QEMU-KVM等软件版本并给出测试环境要求与过程控制方法。核心章节覆盖控制台、运营平台、计费平台、工单平台及监控功能测试逐项列出测试标准与结果最后附测试总结与结论分析。目前已有471人学习下载可帮助读者掌握云平台各功能模块的验证要点、故障模拟思路与测试报告撰写框架。1. 从一份 70 页的 OpenStack 测试报告说起它到底能帮你避开哪些坑如果你正在交付一套 OpenStack 私有云或者刚接手一个已经上线、但没人说得清“到底测过什么”的生产集群这份《Openstack 云平台项目测试报告.docx》值得你逐页翻一遍。它不是那种只写“功能正常、测试通过”的走过场文档而是把控制台、运营平台、计费平台、工单平台、监控五个模块的测试项一条条列出来连“锁定云主机后 admin 角色不受 lock 影响”这种边界行为都写进了测试标准里。换句话说它是一份可以直接拿来当验收清单用的实测记录。这份报告对应的环境是实施软件版本 4.0底层 CentOS 7 1611、内核 3.10.0-514.26、QEMU-KVM 2.6.0、Libvirt 2.0.0-10硬件上是控制网络融合节点加计算存储融合节点的组合。测试目的很明确验证生产集群云平台的功能可用性并且通过模拟服务进程崩溃和硬件故障来检验可靠性。适合谁看一是正在做 OpenStack 交付、需要一份可参照的测试用例基线的工程师二是运维团队想拿它当日常巡检和故障演练的对照表三是刚接触 OpenStack 云平台搭建、想搞清楚“一个合格的私有云到底要测哪些东西”的新手。下面我按“这份报告怎么用、每个模块测什么、参数怎么对、坑在哪”的顺序拆开讲。2. 测试环境与过程控制先把硬件清单和入口条件对齐2.1 硬件与软件版本核对报告里的硬件环境写得比较简略只给了设备类型和用途没有具体型号和数量。表 2-1 列了“服务器控制网络融合节点”和“服务器计算存储融合节点”两类但数量栏是空的。这在实际交付里是个常见问题——测试报告往往只写架构角色不写具体配置。我一般会补一张自己的核对表把每台机器的 CPU、内存、磁盘、网卡和角色对应上否则后面做故障模拟时根本不知道哪台挂了会影响什么。软件版本这块信息是完整的直接抄下来对版本组件版本实施软件版本4.0操作系统CentOS 7 1611内核版本3.10.0-514.26QEMU-KVM2.6.0Libvirt2.0.0-10这几个版本号要重点看。CentOS 7 1611 对应的是 3.10.0-514 系列内核QEMU-KVM 2.6.0 和 Libvirt 2.0.0-10 是配套的。如果你现在用的是更新的版本比如 QEMU 4.x 以上报告里某些测试项的行为可能不一样尤其是云主机搁置、救援、重建这几个涉及镜像和快照的操作。常见做法是先在测试环境把版本对齐再跑一遍报告里的用例确认行为一致后再上生产。2.2 测试环境要求与入口条件报告里对物理环境的要求写得很具体室温 15~35℃相对湿度 30%~70%电源 220V±10%还要有满足用电和网络通讯的设施。这些不是凑字数是实打实会影响测试结果的。我遇到过机房空调故障导致某台计算节点温度过高、CPU 降频结果云主机创建时间从 20 秒变成 50 秒差点误判为性能不达标。所以测试前先确认环境条件别让物理因素背锅。测试入口条件有两条一是测试环境以及人员、设备等资源到位二是测试用例基线化。第二条容易被忽略。“用例基线化”意味着你手里得有一份冻结的测试用例版本不能测到一半临时加需求。我一般会把报告里的测试项导出成表格每条标注“通过/不通过/阻塞”阻塞的必须写清楚原因比如“依赖的公网 IP 池未配置”。2.3 受测设备状态检查正式测试前要检查硬件集成情况、网络配置情况、应用系统部署情况还要确认测试文件和人员到位。这一步我习惯用一段脚本来做快速巡检比人工翻界面靠谱# OpenStack 测试前环境巡检脚本 # 检查各节点服务状态和基础资源 # 1. 检查控制节点核心服务 for svc in nova-api nova-scheduler nova-conductor neutron-server keystone cinder-api glance-api; do systemctl is-active $svc /dev/null 21 echo $svc: OK || echo $svc: FAIL done # 2. 检查计算节点 libvirt 和 nova-compute for host in $(openstack compute service list -f value -c Host); do ssh $host systemctl is-active libvirtd systemctl is-active nova-compute \ echo $host: OK || echo $host: FAIL done # 3. 检查存储后端 openstack volume service list -f value -c Binary -c State # 4. 检查网络代理 for host in $(openstack network agent list -f value -c Host); do echo $host openstack network agent list --host $host -f value -c Alive -c State done这段脚本的逻辑是先确认控制节点上 nova、neutron、keystone、cinder、glance 的核心服务都在跑再逐台计算节点检查 libvirtd 和 nova-compute然后看 cinder 卷服务和 neutron 网络代理的状态。参数上systemctl is-active返回 active 才算正常openstack compute service list里的 State 列要是 upopenstack network agent list里的 Alive 列要是 True。如果哪一步 FAIL先别急着往下测把服务拉起来再说。报告里说的“受测设备状态需要在系统测试开始前部署并调试就绪”落到操作上就是这套检查。3. 控制台功能性测试云主机全生命周期怎么逐项验证3.1 创建、登录与状态操作控制台测试是整份报告里篇幅最大的部分从创建云主机一直测到删除基本覆盖了云主机的完整生命周期。创建这块分单台和批量单台要测密码登录和密钥登录两种方式批量要一次创建 10 台并且单台创建时间小于 30 秒。这个 30 秒是个硬指标我建议在测试时用time命令卡一下# 测试单台云主机创建耗时 time openstack server create \ --flavor m1.medium \ --image centos7-1611 \ --nic net-id网络ID \ --security-group default \ test-vm-01 # 批量创建 10 台并记录总耗时 time for i in $(seq 1 10); do openstack server create \ --flavor m1.medium \ --image centos7-1611 \ --nic net-id网络ID \ --security-group default \ test-vm-batch-$i done wait参数说明--flavor指定规格--image指定镜像--nic指定网络--security-group指定安全组。批量创建时用放到后台并行执行wait等全部完成。如果单台超过 30 秒先看镜像是不是太大、存储后端是不是满了、调度器有没有报错。常见原因是镜像放在慢速存储上或者计算节点资源不足导致调度排队。状态操作这块报告列得很细关机、开机、重启、暂停、取消暂停、挂起、恢复、锁定、解锁、救援、恢复救援、搁置、取消搁置、重建。每个操作都有明确的预期状态。我挑几个容易出问题的说。锁定云主机这条报告特别注明“只限于普通用户admin 角色的用户不受 lock 的影响并且无论加锁与否都可以正常执行操作”。这个行为在测试时一定要用普通用户验证别用 admin 测完就以为通过了。我见过有人用 admin 账号测锁定发现还能重启以为功能有 bug其实是权限模型设计如此。搁置云主机这条报告提到“在此过程中会创建一个名称以 shelved 结尾的主机快照”。这个快照是搁置机制自动生成的不是用户手动创建的快照。测试时要确认快照确实存在并且取消搁置后云主机能正常恢复。如果搁置失败先看 nova 的 shelve 相关日志常见原因是镜像服务连不上或者快照存储空间不足。3.2 网络、安全组与密钥对网络操作包括绑定公网 IP、解除公网 IP、加入网络、修改安全组。绑定公网 IP 分两种情况选择已有公网 IP 和创建新公网 IP。测试标准里写“绑定后公网 IP 地址生效云主机可通过公网访问”验证时不能只看界面显示要实际从外部 ping 或者 ssh 一下。加入网络这块报告测了四种路径顶部“更多”菜单选子网、顶部“更多”菜单选网卡、详细信息页选子网、详细信息页选网卡。这四种路径最终效果一样但界面入口不同测试时要都走一遍确认没有哪个入口漏了参数。另外还测了“云主机加入多个网络创建两个子网一台虚拟机选择两个子网虚拟机网络可达两个网络的网关可绑定弹性 IP正常访问外网”。这个场景在多网络环境中很常见验证时要确认路由表和安全组规则都正确。安全组测试分创建、修改名称、详细信息、修改规则、删除。修改规则又分上行和下行每条都要测添加和删除。报告里有一条很关键“选择 1 个已绑定到网卡的安全组执行删除操作安全组删除操作不成功界面显示正常操作过程中无报错。”这是预期行为——安全组被网卡引用时不能删。测试时如果发现能删掉反而是 bug。密钥对测试包括创建选择“创建密钥”和“导入密钥”两种、使用密钥对创建 Linux 云主机、删除单个和批量删除。导入密钥时要注意公钥格式常见做法是用ssh-keygen -t rsa -b 2048生成然后把~/.ssh/id_rsa.pub的内容粘贴进去。如果导入后创建云主机登录不了先检查公钥有没有换行符或者多余空格。3.3 云硬盘与快照操作云硬盘分容量型和性能型测试项基本对称创建、创建快照、挂载、卸载、扩容、设置只读、设置读写、详细信息、创建转让、接收转让、删除。扩容这块有个细节报告测了三种情况——新创建未使用的、挂载后安全卸载的、使用中的。前两种扩容成功第三种扩容不成功。这是符合预期的使用中的云硬盘不能直接扩容必须先卸载。测试时如果发现使用中也能扩容要确认是不是底层存储支持在线扩容否则可能是 bug。创建快照分顶部菜单和详细信息页两个入口每个入口又分未使用和使用中两种状态。四个组合都要测。快照创建后要验证数据一致性报告里写“快照中的数据与原虚拟机保持一致”。我一般会在云主机里创建一个带时间戳的文件打快照后用快照创建新云主机登录进去看文件在不在。删除云硬盘也有边界未使用的可以删使用中的删不掉。这个和删除安全组的逻辑类似都是引用保护。测试时确认界面有明确提示而不是静默失败。4. 运营、计费、工单与监控四个平台的测试要点4.1 运营平台与计费平台运营平台功能性测试在报告里从第 38 页开始计费平台从第 62 页开始。运营平台主要测云主机管理、存储管理、网络管理这些运营侧功能计费平台测计费规则管理和计费记录管理。这两个平台的测试有一个共同点它们依赖控制台已经创建好的资源。所以测试顺序不能乱必须先跑完控制台测试确保云主机、云硬盘、网络都正常再测运营和计费。计费平台的测试要特别注意计费规则的生效时间。常见做法是创建一个按小时计费的规则然后开一台云主机等一个计费周期后看账单有没有生成。如果账单没出来先检查计费服务有没有定时任务在跑再看云主机的计量数据有没有上报。报告里没有展开计费的具体规则但测试标准写的是“计费记录管理”说明至少覆盖了记录的生成和查询。4.2 工单平台与监控功能工单平台从第 63 页开始测工单管理和任务管理。工单系统的测试重点是状态流转创建工单、派单、处理、关闭每个状态变更都要确认通知和权限正确。监控功能测试从第 68 页开始测资源监控和性能监控。报告里提到“通过模拟服务进程崩溃和硬件故障等方式”来测试这是监控测试的关键——不能只看监控界面有没有数据要真的制造故障看能不能告警。我一般会做两个故障模拟一是手动停掉某台计算节点的 nova-compute 服务看监控平台多久发出告警二是拔掉一台节点的网线或者关掉网卡看网络监控能不能检测到。告警延迟和准确性是重点。如果停服务后 5 分钟还没告警检查监控 agent 的心跳间隔和告警规则阈值。4.3 测试过程控制中的故障模拟报告在第 3 章“测试过程控制”里提到测试目的包括“通过模拟服务进程崩溃和硬件故障等方式”验证可靠性。虽然正文没有展开具体怎么模拟但结合 OpenStack 的常见做法我一般会做这几类# 故障模拟 1停掉计算节点 nova-compute ssh 计算节点 systemctl stop nova-compute # 预期控制台该节点状态变为 down已有云主机不受影响新调度不落到该节点 # 故障模拟 2停掉控制节点 nova-api ssh 控制节点 systemctl stop nova-api # 预期控制台 API 不可用但已运行的云主机不受影响 # 故障模拟 3模拟存储后端故障 # 如果是 Ceph可以临时屏蔽某个 OSD ceph osd out osd-id # 预期卷读写可能降级但不应丢失数据这些模拟的目的是验证云平台在部分组件故障时还能不能维持核心功能。测试标准里没有写具体的恢复时间要求但实际交付时一般要求控制服务故障后 5 分钟内恢复计算节点故障后云主机 10 分钟内恢复。如果达不到就要看高可用配置和集群仲裁参数。5. 避坑与常见问题测试报告里没写但一定会遇到的五件事5.1 云主机创建成功但 VNC 黑屏现象云主机状态是 active但 VNC 打开后黑屏看不到登录界面。原因通常是镜像里没有安装正确的显示驱动或者 QEMU-KVM 版本和镜像不兼容。报告里测的是 CentOS 7 1611 和 Windows 镜像如果你用的镜像版本不同先确认镜像里有没有 virtio 驱动。解决方法是重新制作镜像把 virtio-gpu 和 virtio-input 驱动打进去或者换用报告里验证过的镜像版本。5.2 安全组规则改了但不生效现象在控制台修改了安全组规则添加了允许 22 端口的入站规则但 ssh 还是连不上。原因可能是规则没有应用到正确的网卡上或者安全组绑定了多个网卡但只改了其中一个。解决方法是先确认云主机的网络端口绑定了哪些安全组然后逐条检查规则的方向和协议。报告里测了“修改安全组换其他安全组”“添加安全组”“减少安全组”三种操作每种都要确认规则实际生效不能只看界面。5.3 云硬盘扩容后文件系统没变大现象在控制台把云硬盘从 100G 扩到 200G挂载到云主机后df -h还是显示 100G。原因是控制台扩容的是块设备容量文件系统还需要手动扩展。解决方法是登录云主机用growpart扩展分区再用resize2fs或xfs_growfs扩展文件系统# 扩展分区 growpart /dev/vda 1 # 扩展 ext4 文件系统 resize2fs /dev/vda1 # 如果是 xfs xfs_growfs /报告里测了“挂载到云主机云硬盘容量增加原有分区及数据无影响”但没写文件系统扩展这一步。实际交付时这一步必须做否则用户会以为扩容失败。5.4 搁置云主机后快照删不掉现象云主机搁置后自动生成了 shelved 快照取消搁置后想删这个快照发现删不掉。原因是快照还被搁置的云主机引用或者删除顺序不对。解决方法是先确认云主机已经完全恢复状态 active再删快照。如果还是删不掉检查 glance 服务状态和快照的 owner 权限。报告里提到搁置会创建快照但没写快照的生命周期管理这是实际运维中容易踩的坑。5.5 批量删除云主机时部分失败现象选了 5 台以上云主机执行批量删除结果有几台删不掉界面报错但不明显。原因可能是某台云主机还有挂载的云硬盘没卸载或者有未删除的快照。解决方法是先逐台检查云主机的依赖资源把云硬盘卸载、快照删除后再批量删。报告里测的是“选择 5 台以上云主机执行删除操作成功”但没写依赖检查。我一般会在批量删除前跑一遍依赖扫描# 检查云主机的挂载卷和快照 for vm in $(openstack server list -f value -c ID); do echo $vm openstack server show $vm -f value -c volumes_attached openstack volume list --server $vm -f value -c ID -c Status done6. 把测试报告变成可复用的验收脚本我的三个进阶习惯这份报告最大的价值不是它测了什么而是它给出了一套可复用的测试标准。我把它落地成三个习惯每次交付新集群都走一遍。第一个习惯是把报告里的测试项转成自动化脚本。控制台的功能测试大部分可以通过 OpenStack CLI 完成比如创建、状态操作、网络绑定、安全组修改。我写了一个 Python 脚本用openstack命令和requests库调 API把报告里的“通过/不通过”变成脚本的 exit code。这样每次环境变更后跑一遍几分钟就能知道有没有回归。# 简化的验收脚本框架 import subprocess def check(cmd, expect_keywordNone): 执行命令并检查输出 result subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue) if result.returncode ! 0: return False, result.stderr if expect_keyword and expect_keyword not in result.stdout: return False, f未找到关键字: {expect_keyword} return True, result.stdout # 测试项创建云主机 ok, msg check( openstack server create --flavor m1.medium --image centos7 --nic net-idxxx --wait test-vm, ACTIVE ) print(f创建云主机: {通过 if ok else 失败 - msg}) # 测试项锁定云主机 ok, msg check(openstack server lock test-vm) print(f锁定云主机: {通过 if ok else 失败}) # 测试项删除云主机 ok, msg check(openstack server delete --wait test-vm) print(f删除云主机: {通过 if ok else 失败})这个框架的关键是--wait参数它会阻塞到操作完成避免脚本跑完了资源还没就绪。参数上--flavor、--image、--nic要换成你环境里的实际值。如果某一步失败脚本会打印错误信息方便定位。第二个习惯是记录每次测试的版本基线。报告里写的是实施软件版本 4.0但 OpenStack 的每个组件都有自己的版本号。我一般会在测试报告开头加一张版本快照表把nova-manage version、neutron --version、cinder-manage version这些命令的输出都记下来。这样下次环境升级后能快速对比哪些组件变了、哪些测试项可能受影响。第三个习惯是把故障模拟常态化。报告里提到模拟服务进程崩溃和硬件故障但很多团队只在验收时做一次。我建议把故障模拟做成定期演练比如每月停一次某个计算节点的服务看监控告警和自动恢复是否正常。从那以后我每次交付新集群都强制走一遍“停服务-看告警-恢复服务-确认状态”的流程不跳过。希望帮到你。本文还有配套的精品资源点击获取
