手机、平板与桌面设备 Profile 测试
使用一致的手机、平板与桌面 Profile 规划授权 QA，覆盖显示、输入、媒体、平台身份与部署判断。
BotBrowser Team
要验证手机结账页或平板仪表盘能否完成任务，却不想每次审查都预约设备实验室？BotBrowser 可用一个获批 Profile 重复浏览器可见的显示、输入、媒体和平台条件，但不能证明真实传感器、操作系统对话框或设备性能；验收依赖这些条件时应转到物理硬件。
要点
为一个命名流程使用一个获批 Profile，记录 Profile 与观察结果；当验收依赖浏览器外的设备或操作系统行为时，转到物理硬件验证。
目录
从用户流程开始，而不是从屏幕宽度开始
手机页面不只是缩窄的桌面页面。触摸输入会改变控件的响应方式，屏幕键盘会改变表单周围的可用区域，屏幕方向会影响导航和媒体，平台习惯会影响菜单、上传、权限，以及浏览器把任务交给其他应用的方式。有价值的设备测试会把这些行为放在一起检查。
BotBrowser 使用以 Profile 为基础的设备族来完成这项工作。选定的 Profile 为显示、输入、媒体、平台身份和浏览器族行为提供同一套一致的基础。团队可以在工作站、CI 运行器或托管服务器上重复同一个授权测试，而不必用互不相关的覆盖项重新拼出设备描述。
实际的起点是客户旅程：为手机结账选择手机 Profile，为触控仪表盘选择平板 Profile，为工作站流程选择桌面 Profile。把这个选择与测试用例一起记录，审查者就能重现相同条件，并理解证据所代表的含义。
网页内容可以观察设备和浏览器会话的大致特征。单独看，屏幕布局或输入方式可能很普通；但显示、交互、图形、媒体、语言和网络上下文组合在一起，就可能支持长期关联。Profile 让这些类别保持一致，使授权的隐私审查不会暴露宿主与目标设备行为混杂的情况。一致性也能提高布局审查的质量：在有文档记录的平板 Profile 下出现的失败，比由一堆临时浏览器设置产生的失败更容易重现。
Profile 的一致性不能取代治理。团队应使用已批准的测试账号、授权的目标、受控数据，以及适用于截图和日志的保留策略。设备覆盖应服从书面的 QA 目的，因为一长串 Profile 清单不如一组与真实产品需求相关的精简集合有用。
当审查者把设备 Profile 视为完整的测试条件时，它最有价值。相关的行为类别包括：
- 显示：可用页面区域、视觉密度、屏幕方向、全屏行为和响应式布局。
- 输入：触摸、指针、键盘、焦点、选择、拖动和手势类控件。
- 表单：屏幕键盘的影响、校验消息、自动填充布局、日期和时间控件，以及文件选择。
- 媒体：响应式图片、播放控件、采集权限提示，以及与设备相称的呈现方式。
- 平台身份：作为同一个设备族呈现的浏览器族与操作系统上下文。
- 图形与文字：与所选 Profile 和被审查内容相符的渲染行为。
- 区域上下文：按授权测试计划选择的语言、时区和网络位置。
用这些类别来观察应用本身：控件是否仍然可见，表单能否完成，同意选择是否得到尊重，同一个 Profile 是否产生稳定的结果。
在用例记录中保留 device-profile、journey-id、expected-result 和 evidence-id。键盘几何契约见 VirtualKeyboard API：视口与 inset 边界，其中 profile 策略与 visual viewport 证据分开记录。
选择 Profile，并逐个设备族审查
从贵组织有权使用的使用数据出发。产品分析可能显示手机、平板和桌面会话的大致占比；支持记录可能指出反复给客户造成问题的移动流程；无障碍测试可能同时需要触控优先和键盘优先的条件。这些来源可以确定一组精简且站得住脚的 Profile，其中每个 Profile 都有存在的理由。
不要仅因为某个 Profile 新或热门就选它。合适的集合应反映应用本身、所服务的地区，以及团队做出的支持承诺。定期复查这个集合，淘汰不再对应有效需求的 Profile，并在使用情况或面向客户的变更需要时新增。
请写明每个 Profile 为什么属于这个集合。像“覆盖窄屏结账”或“代表触控优先的仪表盘”这样的简短备注，可以让后来的审查者判断该 Profile 是否仍有存在的价值。如果两个 Profile 总是产生相同的发现，请保留与更多真实使用情况相符的那个，并淘汰另一个。
手机。 手机测试应覆盖完整任务。一张首页截图几乎无法说明客户能否登录、做出同意选择、找回账号、上传文件或完成购买。使用同一个 Profile 从入口走到完成，并特别留意屏幕底部的控件、固定导航、对话框和多步骤表单。只有产品同时支持竖屏和横屏时，才同时审查两者。
触控目标需要足够的间距，但审查也应在产品承诺的范围内确认键盘可访问性。使用手机 Profile 不是忽略焦点顺序、标签、错误恢复或减少动态效果偏好的理由。移动端的隐私审查和无障碍审查常常暴露同一类设计问题：被隐藏的选项、不清晰的状态，或只依赖单一输入方式的控件。
平板。 平板布局常常介于移动端和桌面端的假设之间。网站可能切换为多列布局，而输入仍以触摸为主，紧凑菜单也可能变成常驻侧边栏。仪表盘、库存工具、现场服务应用、教育产品和媒体体验适合使用平板 Profile。请审查分屏视图、大型对话框、拖动交互、虚拟键盘和旋转，并确认增加的宽度不会暴露难以用触摸操作的桌面专用控件。平板测试不是放大的手机测试，应为它准备独立的预期截图和交互说明。
桌面。 即使移动流量更大，桌面 Profile 仍然重要。工作站流程常涉及长表单、多窗口任务、下载、上传、键盘快捷键和密集的信息。请保留一个有文档记录的基线用于比较，因为每次运行都使用随机窗口尺寸，会让截图差异难以解读。桌面审查还能为移动端发现提供对照：如果同意对话框只在手机 Profile 下失败，团队的排查范围就更窄；如果在各设备族中都失败，问题可能出在共享的应用逻辑中。
为每个选定 Profile 记录 profile-rationale、coverage-family、review-date 和 retire-decision。
表单、屏幕键盘与触摸输入
表单值得单独做一轮移动端检查，因为焦点会改变可见的页面区域。请用选定的手机或平板 Profile 测试登录、地址填写、支付、搜索、账号找回以及任何自定义编辑器。获得焦点的字段、它的标签、校验消息和下一步操作都应保持清晰易懂。
不要只凭第一次焦点事件来判断表单。请完整走过焦点、错误和失焦的整个序列，修正一个错误，打开并关闭一个对话框，再回到页面。确认滚动保持可预测，并且键盘关闭后页面会恢复到有用的位置。这些检查既保护真实用户，也能产生另一位审查者可以重现的证据。
布局视口与可视视口之间的差别，解释了为什么键盘行为需要单独检查。MDN 把可视视口描述为页面的可见部分，不包括屏幕键盘以及其他不随页面缩放的屏幕元素。键盘打开时，可见区域可能缩小，而 CSS 和固定定位所依赖的布局保持不变。因此，按布局尺寸确定的固定页脚可能把主要操作留在键盘下方，而能响应可见区域变化的页面则可以让该操作保持可触及。关于涵盖视口状态以及键盘和触控流程的更完整复核模型，请参阅移动浏览器 Profile 质量复核。
请用可观察的方式写出键盘审查的预期结果。以登录表单为例：获得焦点的字段保持在可见区域内，校验消息出现在字段旁边而不是被键盘遮住，无需离开页面就能触及提交操作，失焦后页面回到合理的位置。把这些结果作为简短清单放进测试用例，并使用该用例选定的 Profile 运行，这样另一位审查者就能重复这一序列并比较结果。
对于能感知键盘的移动端行为，请使用文档说明的产品配置，而不是在 Profile 之上再叠加框架的视口设置。整个测试中，设备条件应始终由 Profile 负责，自动化框架只需沿着已批准的旅程操作。
输入审查应关注用户结果：确认点按能触发预期的控件，滚动不会触发相邻操作，拖动手柄仍然可用，菜单可以关闭。如果某个流程支持指针或实体键盘，请把该条件单独测试，并保留各自的证据。关于鼠标、触控和触笔事件的行为，以及如何让每条输入路径都保持无障碍，请参阅指针事件与鼠标、触控和触笔的无障碍输入。
人工审查仍有价值。自动化检查可以确认控件存在、任务能够完成，而审查者可能注意到菜单显得拥挤、权限说明不清晰，或隐私选项在旋转后变得难以触及。设备 Profile 不能取代无障碍测试，后者仍需要语义检查、键盘与屏幕阅读器覆盖、对比度审查、焦点管理，以及合格的测试人员。
为表单序列捕获 focus-target、visualViewport.height、validation-state 和 return-position。
屏幕方向、媒体、权限与区域上下文
只在用户确实会旋转设备的场景下测试方向变化。媒体、文档审阅、地图、图表和部分平板工具往往需要两种方向，而正式只支持竖屏的结账流程则未必。当方向在范围内时，请验证连续性：页面应保留有意义的状态，让当前任务保持可见，不重新打开已关闭的对话框，并保留已输入的表单数据。关于如何把旋转当作布局状态，并在旋转过程中保持任务完整，请参阅Screen Orientation API 与响应式体验。
用同一个 Profile 在变化前后分别采集证据。不要把方向审查与语言、网络区域或账号状态的无关变化混在一起。每次只做一项受控变化，结果更容易理解。
摄像头、麦克风、位置、通知和文件访问既涉及浏览器的呈现，也涉及应用的同意流程。只使用已授权的账号和已批准的测试数据来测试这些路径。应用应说明请求访问的原因，在被拒绝时不让用户陷入困境，并在产品支持时允许之后更改选择。对于媒体，请确认预览、静音状态、取消和错误恢复符合预期。
权限结果可能保存在浏览器数据目录中，因此请制定有意识的测试状态策略。干净状态适合首次运行的同意流程，保留状态则适合回访场景。请为证据加上标签，让其他审查者知道测试的是哪种条件。
设备族只是移动体验的一部分。语言、时区和网络区域会改变内容、格式、同意义务和支持渠道。请根据授权测试计划选择这些值，并使其与场景保持一致。手机 Profile 并不要求特定的网络类型，但线路必须已获批准、有记录，并且足够稳定，使结果可以被审查。请让凭据远离截图和共享日志。
请把区域变化作为独立用例运行。不要随意把语言变化与不同的账号、Profile 和网络线路混在一起。清晰的用例边界让失败更容易重现，也减少不必要的用户数据收集。
把受控输入标记为 orientation-change、permission-state、locale 和 network-route。
证据、发布矩阵与 CI
有用的证据会把设备条件与观察到的应用行为联系起来。请记录 Profile 设备族、浏览器版本、应用版本、测试账号类别、语言区域、屏幕方向，以及所尝试的旅程。只采集足以说明结果的最小截图或录屏，并在分享前对个人数据做脱敏。
日志也应同样克制。应用控制台输出、网络跟踪和浏览器诊断信息可能包含标识符或账号信息。只收集调查所需的内容，按团队的保留策略存放，并限制访问。请清晰命名预期基线，让审查者无需打开另一份表格，就能判断某张截图属于手机结账、平板仪表盘还是桌面支持流程。
能经得起人员变动的用例记录会列出旅程、Profile 设备族、预期的可观察结果、测试数据类别、负责人和下次复查日期。请把记录放在测试本身旁边，而不是单独的文档里，这样截图一旦变化，就总能追溯到背后的责任人和需求。
大型矩阵往往会变慢并被忽视。请把小型发布门禁与范围更广的定期覆盖分开：门禁包含一旦失败就会阻止交付的设备族和旅程，定期运行则覆盖更多布局、语言和低频流程。为每个用例指定负责人，并让隔离保持临时且可见。如果某个设备用例不稳定，请记录原因，保留一个更小的诊断用例，并设定复查日期，而不是默默接受不断变化的截图或反复重试。
CI 运行器需要与已批准基线相同的 Profile、浏览器版本、字体及配套资源和应用状态。请通过组织常规的密钥和制品控制来分发这些输入，除非测试明确覆盖 Profile 轮换，否则不要在每次运行时拉取不同的 Profile。不要让框架的显示设置覆盖由 Profile 提供的设备条件，并为不同的设备身份使用独立的浏览器实例，使存储状态和失败都能归因于预期的 Profile。
容量规划应来自对你自己页面的测量。媒体密集的仪表盘与简单表单在内存、图形和网络上的成本不同。先从少量并发开始，观察完成时间和资源余量，再为该工作负载选定上限。
浏览器、Profile、自动化框架和应用的升级都可能影响设备测试。请尽可能一次只变更一个层面，先运行发布门禁再扩展到定期矩阵，并与同一 Profile 设备族生成的基线比较。升级后请复查同意、权限、账号找回、上传和支付，并仅在政策和工程价值允许的期限内保留旧证据。
每个矩阵行标识 browser-build、profile-revision、app-build 和 matrix-case。
何时仍应使用物理设备
以 Profile 为基础的桌面测试并不会消除对物理设备的需求。当验收标准依赖真实摄像头、无线电、生物识别传感器、操作系统对话框、应用切换、厂商特定的硬件行为，或实际电量和温度条件下的性能时，请使用硬件。当合同或平台政策要求最终认证时，同样适合使用硬件。
一条有用的升级规则很简单：如果预期结果依赖物理设备或浏览器之外的操作系统服务，就在目标设备上确认；如果它涉及浏览器呈现和受支持的 Profile 工作流，桌面或服务器执行就能提供团队所需的可重复证据，并把有限的设备实验室时间用在真正需要硬件的条件上。
BotBrowser 可以运行匹配的 Android 或 WebKit 族移动 Profile，并提供由 Profile 定义的触摸支持。通过文档说明的 --bot-mobile-keyboard 选项，可信的可编辑字段获得焦点时，visualViewport.height 会减小，而布局视口保持不变，因此团队可以在同一个有文档记录的 Profile 条件下重复进行移动表单与键盘审查。桌面 Profile 会忽略该选项。BotBrowser 不能替代物理设备、真实的操作系统键盘、对话框或硬件行为，也不保证每种设备或应用布局的表现都完全一致。
当团队需要在手机、平板和桌面设备族之间进行可重复的浏览器 QA，尤其是在 CI 或托管基础设施中时，请选择以 Profile 为基础的设备测试。当验收依赖真实硬件时，请选择物理设备服务；当任务只是早期布局草稿、设备身份不在范围内时，请选择标准的响应式模拟。扩大部署之前，请确认 Profile 的负责人、已批准的用途、测试数据处理、证据保留、运行器容量和升级路径。这些决定比目录中的设备名称数量更重要。
下载 BotBrowser 以运行批准的设备 Profile，或在部署前查看平台一致性功能。移动端规划可继续阅读 Android 浏览器 Profile 测试。屏幕与窗口一致性介绍响应式显示审查，跨平台浏览器 Profile介绍宿主环境选择。
结论
选择覆盖命名流程的最小获批 Profile 集合，把 Profile 与发布证据放在一起；当验收条件依赖硬件或操作系统服务时，将物理设备作为必要的升级路径。
来源
本文属于指南： Web 平台能力面：一致性复核地图