在app端它是cs架构,应该分成c端和s端两方面去考虑。
app端
Android APP 功能测试列表,涵盖了安装、卸载、界面、业务功能、特性、兼容性、升级更新等方面的测试。以下是一些针对每个测试项的简要说明:
APP的安装和卸载
1.1 安装
- 不同操作系统版本的安装测试: 确保应用在各个Android版本上都能正常安装。
- 不同品牌手机的安装测试: 确保应用在不同品牌的手机上都能正常安装。
- 不同屏幕分辨率/大小的安装测试: 确保应用在不同分辨率和屏幕大小的手机上都能正常安装,界面显示不变形。
- 第三方平台安装测试: 测试从第三方平台安装应用的情况,确保安装过程正常。
- 取消安装测试: 测试安装过程中是否能够取消,以及取消后的处理是否符合预期。
- 提示信息测试: 确保安装过程中的提示信息清晰,无乱码或代码显示。
- 意外情况处理测试: 测试在意外情况下(如死机、重启、断电)的安装流程是否正常处理。
- SD卡安装测试: 测试应用是否能识别并安装到SD卡,符合需求。
- 空间不足提示测试: 测试在空间不足的情况下是否能够给出相应提示。
- 网络验证测试: 测试在弱网或断网情况下安装是否正常。
- 安装手册测试: 若有安装手册,测试是否按照手册安装是否正常。
- 目录结构和文件测试: 测试安装完成后是否生成多余的文件或目录。
- 首次安装启动测试: 确保首次安装后应用能正常启动。
- 版本覆盖安装测试: 确保版本覆盖安装后应用能正常启动。
1.2 卸载
- 删除安装文件夹卸载测试: 测试直接删除安装文件夹是否能正常卸载,并检查是否有相应提示信息。
- 直接卸载应用程序测试: 测试直接卸载应用程序是否能正常卸载,并检查是否有相应提示信息。
- 意外情况处理测试: 测试在意外情况下的卸载流程是否正常处理。
- 取消卸载测试: 测试是否能取消卸载,并检查取消后应用程序状态是否恢复正常。
- 卸载进度条测试: 测试卸载过程中是否有进度条提示,并检查进度条显示是否正常。
- 删除安装文件夹测试: 确保卸载后能够完全删除所有安装文件夹。
- 第三方卸载测试: 测试从第三方平台卸载应用是否完全删除。
用户界面测试(UI测试)确实是为了评估应用程序的用户界面是否符合设计规范和用户期望。这项测试旨在确保应用程序界面的功能性、可用性和用户友好性。通过评估布局、风格、控件位置、操作便捷性、导航清晰性、文字准确性、命名统一性、页面美观性以及文字和图片组合等方面,UI测试有助于发现并解决界面设计中的问题,提高用户体验和用户满意度
UI测试的内容:包括导航测试、图形测试、内容测试、表格测试、H5界面测试、整体界面测试等
导航测试
-
按钮测试:
- 按钮的可点击条件:测试在什么情况下按钮可点击,例如是否需要填写完整表单、是否需要满足特定条件等。
- 按钮按下的效果:测试按钮按下后的视觉反馈效果,例如颜色变化、阴影效果等。
- 按钮的跳转引导:测试按钮点击后的跳转目标是否符合预期,是否跳转到正确的页面或执行正确的操作。
-
目录测试:
- 布局正确性测试:测试目录在不同分辨率和设备上的布局是否正确,是否能够完整显示。
- 跳转正确性测试:测试点击目录项后是否能够正确跳转到对应的页面或执行对应的操作。
-
菜单测试:
- 菜单配置测试:测试菜单项是否可配置,是否可以根据用户权限或其他条件进行显示或隐藏。
- 显示文字测试:测试菜单项显示的文字长度是否正常,是否能够完整显示在菜单中。
- 跳转正确性测试:测试点击菜单项后是否跳转到正确的页面或执行正确的操作。
-
弹框测试:
- 弹框信息完整性测试:测试弹框中显示的信息是否完整,包括文字内容、图标等。
- 弹框按钮功能测试:测试点击不同按钮后是否执行正确的操作,例如确认、取消等。
- 跳转正确性测试:测试在弹框中点击按钮后是否跳转到正确的页面或执行正确的操作。
-
列表测试:
- 分页显示测试:测试列表在不同分辨率和设备上的分页显示效果是否正常,用户是否能够清晰地知道当前页和总页数。
- 数据重复利用测试:测试列表是否正确地利用了服务端的分页数据,避免重复加载或显示错误的数据。
图形测试
-
图形元素统一性测试:
- 测试各个图形元素(图片、动画、边框、颜色、字体、背景、按钮等)在不同页面或组件中的一致性,确保它们的样式、大小、颜色等方面符合设计规范。
-
自适应界面设计测试:
- 在不同尺寸和分辨率的设备上测试界面布局的自适应性,确保页面元素能够根据窗口大小自动调整位置和大小,以保证用户在不同设备上的良好体验。
-
横屏/竖屏测试:
- 测试在横屏和竖屏模式下页面的显示效果,包括布局的调整、元素的重新排列以及图片、动画等内容的自适应显示。
-
动画效果测试:
- 测试动画效果是否流畅、自然,并且符合设计规范,例如按钮点击后的过渡效果、图片加载时的渐变效果等。
-
收起效果测试:
- 对于可展开或可折叠的图形元素(如折叠菜单、收起按钮等),测试其收起效果是否符合设计要求,包括动画流畅性和元素状态的变化。
-
图片显示效果测试:
- 测试不同来源的图片(用户上传、本地、服务端配置等)在应用端的显示效果,包括清晰度、色彩、尺寸等方面是否符合预期。
-
横向比较测试:
- 对于不同页面或组件的图形元素进行横向比较,检查它们的操作方式、标签风格等是否统一,以确保整体视觉风格的一致性。
内容测试
-
页面显示文案:
- 确保文案清晰明了,易于理解。
- 检查错别字和语法错误。
- 确保没有使用敏感性词汇。
- 文案布局和设计应与整体风格一致。
- 测试在不同屏幕尺寸和分辨率下的显示效果。
-
文本输入框:
- 确认默认文案准确清晰。
- 检查文字长度限制是否符合设计要求。
- 检查敏感性词汇的输入限制。
- 测试输入达到最大长度时的行为。
- 确保删除输入内容后,文案是否恢复到默认状态。
- 确认输入过程中光标显示是否正常。
-
按钮上的文案:
- 确保文案清晰可见,不会被边框遮挡。
- 检查文案颜色是否符合设计规范。
- 测试按钮点击效果下文案的显示效果。
- 确认在不同屏幕尺寸和分辨率下文案显示是否正常。
- 确保文案表达的意思与实际操作相匹配。
-
链接上的文案:
- 确保一般协议文案与链接的协议一致。
- 检查链接文案的颜色是否符合设计规范。
-
图形上的文案:
- 确保文案清晰可见,不会被图形边框遮挡。
- 检查错别字和语法错误。
- 确保没有使用敏感性词汇。
- 文案布局和设计应与整体风格一致。
- 测试在不同屏幕尺寸和分辨率下的显示效果。
-
确认信息文案:
- 确保确认信息文案与用户填写的信息保持一致。
- 检查布局和设计是否一致。
- 测试在不同屏幕尺寸和分辨率下的显示效果。
-
提示信息文案:
- 测试各种提示信息框包含的逻辑是否正确。
- 确保提示信息清晰明了,能够正确引导用户操作。
表格测试
-
标题行:
- 确认是否存在标题行,并检查其显示位置和样式是否符合设计要求。
- 确保标题行中的单元格不可编辑,以确保数据的一致性和完整性。
-
标题列:
- 确认是否存在标题列,并检查其显示位置和样式是否符合设计要求。
- 如果存在标题列,确保其内容居左显示,并检查单元格是否禁止编辑。
-
非标题行/列:
- 确认非标题行/列中的单元格是否允许编辑,并进行适当的测试,确保编辑功能正常。
- 如果允许编辑,参考文本框控件进行测试,确保输入和保存功能正常。
-
数据类型一致性:
- 确认同一行/列中的单元格是否有统一的居左、居中、居右显示方式。
- 对于特定数据类型(如日期型、时间型、货币型、小数型),确保其在整个行/列中的显示格式一致。
-
当前所在的单元格、当前选中的单元格和当前所在行/列:
- 确认是否提供了突出显示功能,并检查其前景/背景色、字体、字号是否正确。
- 在换行、换列时,确保突出显示的单元格、选中的单元格和行/列的显示正确。
-
排序功能:
- 如果表格具有排序功能,例如点击列标题进行排序,确保排序功能的执行效果正确。
-
翻页功能:
- 确认是否有默认的数据条数,每页显示是否正常。
- 检查翻页功能是否正常,是否有复用情况。
-
图片功能:
- 如果表格中包含图片,确保图片显示正常,可点击时跳转是否正确。
-
滑动功能:
- 确保在上下滑动时数据显示正常,并检查是否有遗漏或错位。
- 检查页面底部是否有必要的提示信息。
整体界面测试
整体界面测试是确保应用程序的页面结构设计合理,操作方便,功能键齐全,并且保持统一的风格和样式。以下是对每个测试点的进一步说明:
-
界面设计合理、简洁、美观:
- 确认界面布局是否合理,各功能模块是否清晰分隔,用户操作路径是否直观。
- 检查页面元素的排列是否简洁有序,避免混乱和拥挤的布局。
- 评估整体视觉效果,包括颜色搭配、图标设计等,确保用户体验良好。
-
功能键、数据项信息是否齐全:
- 检查界面上是否存在缺失的功能键或数据项,确保用户能够完成所需操作。
- 确认数据项的命名是否清晰明了,不会引起歧义或混淆。
-
统一性检查:
- 确认系统中同一功能的名称和错误提示信息是否统一,避免用户困惑。
- 检查不同模块中相同字段值的输入方式是否统一,确保用户体验一致性。
-
弹出窗口显示位置统一:
- 检查弹出窗口的位置是否统一,避免在不同情况下窗口位置变化导致用户不便。
-
样式、风格统一:
- 确认查询条件样式和输入风格是否与系统其他模块统一,保持整体风格的一致性。
- 检查页面内所有字段名称的显示风格是否统一,如居中、左对齐、右对齐等,以提升用户体验。
-
保存后界面关闭统一:
- 确认添加/修改保存后,界面是否自动关闭,确保用户不会因为界面未关闭而感到困扰。
- 建议在修改保存后,修改界面自动关闭,以提高用户操作效率和流畅度。
APP的业务功能测试
APP的常规性业务功能测试
-
界面测试:
- 布局合理性:确认界面布局是否合理,元素是否清晰分隔,用户是否可以自定义界面。
- 视觉效果:评估颜色搭配、字体、文字对齐、图片大小与位置等是否符合设计规范。
- 弹出窗口位置:检查弹出窗口位置是否合适,不影响用户操作或遮挡重要内容。
-
数据测试:
- 输入验证:确保应用能够接受正确的数据输入,并对错误输入有适当的提示和容错处理。
- 数据完整性:验证数据在传输和存储过程中是否完整,防止数据丢失或损坏。
-
操作测试:
- 操作习惯:确认用户操作菜单、按钮、链接等是否符合操作习惯,是否有明确的提示。
- 流畅性:检查操作过程中是否流畅,无卡顿或延迟现象,提升用户体验。
-
逻辑测试:
- 步骤提示:针对需要多步操作的功能,确认是否有清晰的提示或向导,帮助用户完成操作。
- 一致性:验证不同入口进入相同功能时,操作路径是否一致,保持系统状态稳定。
-
接口测试:
- 规范性:确认接口是否符合规范,能够与多种硬件或内部/外部接口配合。
- 兼容性与扩充性:检查接口的兼容性和扩充性,确保能够满足未来的需求变化。
APP业务功能测试的特殊性:包括应用的前后台切换、免登录、数据更新、离线浏览、系统权限等 应用的前后台切换测试:
-
APP切换到后台,再打开APP:
- 打开应用,执行一系列操作,将应用切换到后台(可以通过按Home键或切换到其他应用实现)。
- 再次打开应用,检查应用是否停留在上一次的操作界面,功能是否正常,程序是否崩溃,数据是否更新。
-
手机锁屏解锁后进入APP:
- 打开应用,执行一系列操作,然后让手机锁屏。
- 解锁手机后再次进入应用,检查是否停留在上一次的操作界面,功能是否正常,程序是否崩溃,数据是否更新。
-
APP使用过程中被电话中断:
- 打开应用,执行一系列操作,然后模拟接到电话中断应用的情况。
- 结束电话通话后再次回到应用,检查是否停留在上一次的操作界面,功能是否正常,数据是否更新。
-
Kill掉APP后,再打开APP:
- 打开应用,执行一系列操作,然后通过系统任务管理器或其他方式将应用强制关闭(kill)。
- 再次打开应用,检查功能是否正常,数据是否更新,用户登录状态是否正常。
-
存在必须处理的提示框:
- 打开应用,触发需要处理的提示框(如系统权限请求、更新通知等),然后将应用切换到后台。
- 再次切换到前台,检查提示框是否存在,是否能够正常处理。
-
APP使用过程中出现异常情况:
- 打开应用,执行一系列操作,然后模拟断电或意外关机重启等异常情况。
- 再次打开应用,检查是否能够正常启动,功能是否正常。
更新测试
根据应用的业务规则和数据更新量的情况,确定最优的数据更新方案是至关重要的。以下是针对手动更新和自动更新的一些考虑:
手动更新:
- 上拉/下拉/上滑/下滑更新数据: 这种方式可以让用户主动触发数据更新,适用于用户希望手动控制数据刷新的场景。确保在更新过程中提供清晰的加载动画,并在更新完成后及时反馈更新结果。
- 更新过程中的动画效果: 动画效果应符合用户体验设计,既能提供视觉反馈,又不会影响用户操作。可以进行适度的优化,以提高用户的交互愉悦感。
- 数据筛选和复用的问题: 在更新数据之前,需要确保数据的准确性和一致性,特别是在存在头像或数据复用的情况下,需要仔细检查数据更新的逻辑。
自动实时更新:
- 更新频率和数据量: 自动更新的频率和数据量应根据业务需求和用户习惯来确定,以避免频繁更新或更新过大的数据量导致用户流量和性能问题。
- 用户感知: 自动更新时要考虑用户体验,可以选择静默更新或通知更新两种方式。对于重要的数据更新,可以发送通知提醒用户,而对于一般性的更新可以采用静默更新,以减少用户干扰。
- 前后台切换: 在应用切换到后台后,如果有数据更新,可以通过本地通知或应用图标上的标记等方式提醒用户,以确保用户再次打开应用时可以及时获取更新的数据。
自动定时更新:
- 更新时间设定: 自动定时更新的时间间隔应根据业务需求来确定,例如报表或抢购等需要及时更新的场景可以设置较短的时间间隔,而对于一般性的数据更新可以设置较长的时间间隔。
- 数据准确性检查: 在定时更新之前,需要确保数据的准确性和完整性,特别是对于需要及时更新的数据,应进行严格的检查以避免出现错误或不完整的数据。
离线浏览
无网络状态浏览APP的内容,即客户端会缓存一部分数据供用户查看
-
允许查看本地缓存内容: 对于某些应用,如小说类、本地游戏类、学习软件类等,可以允许用户在无网络情况下查看本地缓存的部分内容。这可以提升用户体验,使他们能够在没有网络连接的情况下继续使用应用。
-
切换到后台再切换到前台时正常浏览内容: 应用在后台运行时,应该保留用户最后浏览的状态,以便在再次切换到前台时能够正常浏览已经缓存的内容,包括视频、音乐等。
-
Kill掉APP后再次打开能正常浏览内容: 在应用被完全关闭后,再次打开时应该能够正常浏览已经缓存的内容,这需要应用具备良好的缓存管理机制。
-
手机锁屏解锁后能正常浏览内容: 当用户解锁手机并进入应用时,应用应该能够正常展示已缓存的内容,无需网络连接。
-
给予无网络提示: 当用户尝试浏览需要服务端请求的内容时,应用应该给予明确的无网络提示,以避免用户误解应用的功能或产生困惑。
-
离线提交表单后后台请求成功提示: 对于离线提交的表单,当应用重新连接到网络后,应该能够自动处理后台提交的请求,并给予用户提交成功的提示,以确保用户的操作能够成功完成。
系统权限
-
定位权限关闭:
- 打开应用后,检查与定位相关的功能(如地图显示、附近商家搜索等)是否正常工作。
- 如果应用依赖定位权限提供核心功能,应该在权限关闭时给予用户友好的提示,并说明为何需要定位权限以及如何开启。
-
网络权限关闭:
- 打开应用后,检查与网络请求相关的功能(如加载网页、下载内容等)是否正常工作。
- 应用应该在网络权限关闭时给予用户提示,指导用户如何开启网络权限。
-
相册权限关闭:
- 打开应用后,检查与相册相关的功能(如上传照片、选择相册中的图片等)是否正常工作。
- 当相册权限关闭时,应用应该给予用户提示,并提供开启权限的指引。
-
相机权限关闭:
- 打开应用后,检查与相机相关的功能(如拍摄照片、扫描二维码等)是否正常工作。
- 应用应该在相机权限关闭时提示用户,并引导用户开启相机权限。
-
通知权限关闭:
- 打开应用后,检查与通知相关的功能(如推送通知、提醒功能等)是否正常工作。
- 应用应该在通知权限关闭时提醒用户,并说明关闭通知权限可能会影响到应用的某些功能或用户体验。
APP的交叉事件测试
交叉事件测试(Cross-Event Testing)是一种测试方法,专注于检查在应用程序或系统的正常功能执行过程中,同时发生其他事件或操作时的表现。这些其他事件或操作可能会干扰或影响应用程序的正常运行,因此交叉事件测试旨在验证应用程序在这些情况下的稳定性、鲁棒性和用户体验。
在智能终端应用的服务等级划分中,交叉事件测试可以帮助确定应用在不同服务级别下对于交叉事件的响应情况,以及在实时特性要求下的性能表现。例如,在不同的服务级别下(如基础服务、标准服务、高级服务等),应用程序可能对交叉事件的处理方式有所不同,交叉事件测试可以帮助确认这些区别并评估其影响。
在实际测试中,交叉事件测试可以涉及各种情况,包括但不限于:
- 应用在前台或后台运行状态下,接收来电、短信等通信事件时的响应情况。
- 应用在执行关键任务(如文件下载、视频播放等)时,接收到系统通知或其他应用的通知时的响应情况。
- 应用在执行某些操作(如数据上传、下载等)时,同时进行其他操作(如拍摄照片、录制视频等)时的表现。
-
多个APP同时运行测试:
- 打开目标应用程序并确保它正常运行。
- 同时打开其他应用程序,尽可能模拟用户真实的使用情况。
- 检查目标应用程序是否受到其他应用程序运行的影响,包括性能下降、响应时间延迟等。
-
前/后台切换测试:
- 在目标应用程序中执行一些操作,并将其置于后台。
- 再次将其从后台切换到前台,并确保应用程序能够正确恢复并继续运行之前的操作。
-
电话测试:
- 在目标应用程序运行时,拨打或接听电话。
- 检查电话操作是否会影响应用程序的正常功能使用,如暂停或中断正在进行的任务。
-
信息/邮件测试:
- 在目标应用程序运行时,发送或接收信息/邮件。
- 确保这些操作不会影响应用程序的正常运行,并且应用程序能够正确处理这些事件。
-
网络切换测试:
- 在目标应用程序运行时,切换网络连接,如从4G切换到WiFi或反之。
- 检查网络切换是否会导致应用程序出现异常或失去连接。
-
蓝牙测试:
- 在目标应用程序运行时,使用蓝牙传送或接收数据。
- 确保蓝牙功能不会干扰应用程序的正常运行,并且应用程序能够正确处理蓝牙相关事件。
-
手机自带应用功能测试:
- 在目标应用程序运行时,使用手机自带的应用功能,如相机、计算器等。
- 确保这些操作不会影响应用程序的正常功能使用。
-
音乐功能测试:
- 在目标应用程序运行时,同时使用其他应用程序收听音乐。
- 确保应用程序的声音功能不会受到其他应用程序音乐播放的影响,并且能够正常播放声音。
-
声音调节功能测试:
- 在目标应用程序运行时,测试其声音调节功能,并确保与手机的声音大小调节功能一致。
-
通知栏通知测试:
- 在目标应用程序运行时,通过通知栏通知打开其他应用程序,并再次返回目标应用程序。
- 确保从通知栏打开其他应用程序不会影响目标应用程序的正常功能使用。
APP的兼容性测试
-
版本兼容性测试:
- 确保新版本的服务端逻辑不会影响旧版本客户端的正常运行,可以通过回归测试来验证。
- 在每次发布新版本时,都要确保与历史版本的兼容性,并记录在发布说明中。
-
第三方兼容性测试:
- 对每个第三方接口和SDK进行测试,确保其在不同情况下的正常工作。
- 特别关注不同手机操作系统和品牌之间的兼容性,因为定制和优化可能会导致一些意外的问题。
-
手机操作系统兼容性测试:
- 在不同版本的Android系统上进行测试,覆盖主要版本和一些流行的子版本。
- 在不同品牌和型号的手机上测试,特别关注定制的操作系统对应用的影响。
-
屏幕分辨率兼容性测试:
- 确保应用在不同分辨率的屏幕上都能正确显示,并且UI元素不会出现错位或者变形。
- 可以使用模拟器或者真实设备来测试不同分辨率下的UI表现。
-
网络兼容性测试:
- 在不同网络环境下进行测试,包括WiFi、5G,4G、3G以及弱网环境。
- 确保应用在各种网络情况下都能正常加载和运行,并且能够处理丢包和延迟等网络问题。
APP的升级更新测试
APP的更新分为:强制更新和非强制更新
强制更新
-
检查强制更新提示:
- 验证打开APP后是否立即显示强制更新提示。
- 确保用户能够关闭强制更新提示框,但同时需要记录下用户关闭的行为。
- 确认强制更新提示中是否包含明确的更新说明和操作指引。
- 检查强制更新是否有进度条显示,以便用户了解更新进度。
-
处理更新过程中的意外情况:
- 模拟更新过程中的意外情况,例如设备死机、断电或重启。
- 再次打开APP后,验证是否再次显示强制更新提示,以确保用户不会错过更新。
-
验证老账号数据和功能正常性:
- 强制更新成功后,使用已存在的老账号登录,验证账号相关数据是否完整且正常。
- 确认老账号能否正常使用APP的各项功能,包括但不限于发送消息、查看内容等。
-
验证剁掉/隐藏功能和新增功能:
- 检查强制更新后是否按照业务需求剁掉或隐藏了指定功能。
- 确认新增的功能是否按照业务需求设计流程操作,并且能够正常使用。
-
检查版本号显示:
- 验证强制更新成功后,APP的版本号是否已更新为最新版本。
-
跨操作系统测试:
- 在不同的操作系统(Android、iOS等)上进行测试,确保强制更新可以在各种操作系统下正常更新APP。
非强制更新
-
检查非强制更新提示:
- 确认打开APP后是否有非强制更新提示。
- 验证用户是否可以关闭更新提示,并记录下用户关闭的行为。
- 确认非强制更新提示中是否包含更新说明和操作指引。
-
验证历史版本用户的正常使用:
- 关闭更新提示后,使用历史版本的用户登录,确认用户是否可以正常使用APP的功能,包括但不限于发送消息、查看内容等。
-
验证更新提示频率:
- 关闭了更新提示后,再次打开APP,检查非强制更新提示是否再次弹出,一般可以设置提示的频率,确保不会过于频繁地打扰用户。
-
处理更新过程中的意外情况:
- 模拟更新过程中的意外情况,如设备死机、断电或重启。
- 再次打开APP后,验证是否再次提示更新,同时确认用户能否正常使用APP。
-
验证更新成功后的账号数据和功能正常性:
- 确认更新成功后,使用老账号登录,验证账号相关数据是否完整且正常。
- 确认老账号能否正常使用APP的各项功能。
-
验证剁掉/隐藏功能和新增功能:
- 检查更新成功后是否按照业务需求剁掉或隐藏了指定功能。
- 确认新增的功能是否按照业务需求设计流程操作,并且能够正常使用。
-
检查版本号显示:
- 验证更新成功后,APP的版本号是否已更新为最新版本。
-
验证新旧版本用户的交互:
- 检查新版本用户和老版本用户之间的交互是否正常,例如互发消息、新版本消息通知是否发送到老版本上、新版本注册的用户登录到老版本上是否正常等。
-
跨操作系统测试:
- 在不同的操作系统(Android、iOS等)上进行测试,确保非强制更新可以在各种操作系统下正常更新APP。
APP的消息通知测试
针对声音提示的测试,可以按照以下步骤进行:
-
及时性测试:
- 在发送测试消息时,确保声音提示能够及时触发,即在接收到新消息时立即播放声音。
- 验证声音提示的触发是否与需求设计中的预期一致,例如在接收到新消息时是否立即触发声音,而不是延迟或错过。
-
音效测试:
- 根据需求设计或产品规格,使用预设的音效进行测试,确认声音提示的音效与需求设计一致。
- 如果存在自定义音效的功能,确保自定义的音效能够正确应用并与需求一致。
- 针对不同类型的消息或事件,可能需要不同的声音提示,确保声音提示的选择与消息类型或事件类型相匹配。
-
异常情况测试:
- 模拟网络不稳定或其他异常情况,验证声音提示在这些情况下的表现,例如是否会出现声音丢失或延迟播放的情况。
-
多任务测试:
- 在接收消息的同时进行其他操作,例如打开APP内的其他页面或运行其他应用程序,验证声音提示是否会被正确触发,并且不会受到其他任务的干扰。
-
兼容性测试:
- 在不同的设备上进行测试,包括不同型号和不同版本的设备,确保声音提示在各种设备上都能够正常工作。
Alert:强打断型提醒,在APP应用内,用户必须做出选择,否则强制提醒弹框不会关闭(如比赛邀请,APP版本强制更新等)
针对Alert强打断型提醒的测试,可以按照以下步骤进行:
-
弹框正常弹出及用户选择:
- 在应用内操作或浏览时,模拟触发各种情况下的提醒事件,例如比赛邀请或强制更新,验证Alert提醒弹框是否正常弹出。
- 确认用户在收到弹框后是否被迫做出选择,例如接受或拒绝邀请,或者更新应用程序。
-
切换至后台和前台:
- 在应用程序处于活动状态时,将其切换到后台,并验证是否会影响Alert提醒弹框的正常弹出。
- 将应用程序从后台切换到前台,检查Alert提醒弹框是否会正常弹出,并且是否保持之前的状态。
-
Kill APP后重新打开:
- 关闭应用程序(Kill APP),然后重新打开应用程序,验证Alert提醒弹框是否会重新弹出。
- 确认在重新打开应用程序时,弹框是否保持原先的状态,例如如果用户在关闭之前没有做出选择,重新打开应用程序时是否会重新显示提醒。
-
消息推送对象和时间:
- 确保消息推送的对象与需求一致,例如确保比赛邀请或强制更新通知发送给正确的用户群体。
- 检查消息推送的时间是否与需求一致,例如是否在重要事件发生时发送提醒。
-
切换账号和手机:
- 在同一手机上切换不同账号,或在不同手机上使用同一账号登录应用程序,验证Alert提醒弹框是否会弹出,并且是否根据每个账号的状态进行适当的显示。
标记:一种不紧急的提醒方式,APP应用内的消息标记,部分用户有强迫清零的习惯
-
消息计数的正确性和显示限制:
- 检查消息计数是否准确反映了未读消息的数量。
- 验证消息计数显示的最大数量,确保当未读消息数量超过限制时,显示的合理性,例如显示为"99+"或其他合适的提示。
-
应用内收到新消息:
- 在应用内收到新消息时,检查消息计数的及时性和准确性,确保它们被及时更新并且反映了新消息的到达。
-
应用外收到新消息后重新打开应用:
- 在应用外收到新消息后重新打开应用程序,验证消息计数的准确性和即时性,确保它们能正确反映出新消息的到达。
-
未读消息的明确标识:
- 检查消息列表中已读和未读消息之间是否有明确的标识,例如不同的颜色、图标或其他标记。
-
消息列表的更新机制:
- 确保当有新消息到达时,消息列表能够及时地自动更新,并显示相应的提醒,例如通过红点、提醒图标等方式。
-
已读消息后未读计数的减少:
- 将消息标记为已读,然后检查未读消息计数是否相应地减少,确保系统能够正确地更新未读消息的状态。
-
新增消息类别的处理:
- 添加新的消息类别,并验证未读消息计数是否相应地增加,以确保新的消息类别能够被正确地纳入到未读消息计数中。
-
消息推送对象和时间:
- 检查消息推送的对象是否与需求一致,确保消息推送到达的用户是正确的。
- 验证消息推送的时间是否与需求一致,确保它们在合适的时间到达用户端。
-
切换账号和手机:
- 在同一手机上切换不同账号,或在不同手机上使用同一账号登录应用程序,验证消息计数是否与当前账号相对应。
Toast:纯告知,不需要处理,一般是针对正在操作的反馈(一般显示在页面的顶部)
针对Toast消息的测试可以执行以下步骤:
-
操作完成后的Toast消息及时弹出:
- 执行一个操作,如发送消息或保存设置等,确保在操作完成后,Toast消息能够及时地弹出,向用户提供反馈信息。
-
Toast消息文案的正确性:
- 验证Toast消息显示的文案是否与操作完成的结果相符合,确保文案准确明了,能够清晰地表达操作的结果或状态。
-
Toast消息的自动消失:
- 确保Toast消息在弹出后几秒钟内自动消失,一般来说,Toast消息应该在几秒钟内自动消失,不会长时间占据用户界面。
通知栏:Notification支持文字内容显示、震动、三色灯、铃声等多种提示形式,在默认情况下,Notification仅显示消息标题、消息内容、送达时间这3项内容
-
消息提醒频率的检查:
- 验证消息提醒的频率是否与需求一致,例如在设置的时间间隔内是否收到通知栏消息提醒,确保提醒频率符合设计需求。
-
通知栏消息显示内容的一致性:
- 检查通知栏消息显示的标题、内容和时间是否与需求一致,确保它们能够清晰地传达消息的重要信息,并反映最新的消息状态。
-
点击通知栏消息的跳转目标:
- 点击通知栏消息,验证跳转的目标位置是否与需求一致,确保用户能够正确地跳转到相关的页面或功能模块。
- 同时,验证点击通知栏消息后,相应的消息是否在消息列表中标记为已读,确保用户体验的连贯性。
-
消息推送对象的正确性:
- 检查消息推送的对象是否正确,确保通知栏消息发送到了预期的用户账户或设备上,以避免消息发送错误的情况发生。
-
消息推送时间的一致性:
- 验证消息推送的时间是否与需求一致,确保通知栏消息在预期的时间内送达给用户,以保证及时性和有效性。
-
系统通知权限设置的验证:
- 检查系统通知权限的设置是否与实际情况一致,确保用户已经授予了应用程序所需的通知权限,以确保通知栏消息能够正常显示。
Android的功能键测试
音量键:
-
调节音量功能测试:
- 打开应用,进入声音相关功能。
- 使用设备的物理音量键,分别向上和向下调节音量。
- 验证音量是否随着物理调节键的操作而增大或减小。
-
系统静音模式测试:
- 打开应用,进入声音相关功能。
- 将系统声音设为静音。
- 验证应用内的声音是否也处于静音状态,确保应用内声音设置与系统设置同步。
锁屏键:
-
后台运行功能测试:
- 打开应用,确保其具有后台运行功能,例如音乐播放功能。
- 锁屏设备,验证应用是否能够在后台正常运行,如音乐是否继续播放或其他相关功能是否正常执行。
-
解锁后应用运行测试:
- 解锁设备,验证应用是否能够在解锁后正常继续运行,确保应用的运行状态不受锁屏的影响。
关机键:
-
关机前操作测试:
- 打开应用,进行一些需要持久状态的操作,如付款等。
- 关机设备。
-
开机后应用功能测试:
- 开机设备,等待系统完全启动。
- 打开应用,检查之前进行的操作是否被正确保存,确认应用功能是否正常,特别是与关机前相关的操作是否受影响。
Android的手势测试
-
从屏幕左侧边缘向右滑动:
- 滑动手势从屏幕左侧向右滑动。
- 验证应用是否响应该手势,例如打开侧边栏菜单或者切换页面。
-
在屏幕上向左滑动:
- 在屏幕上进行向左滑动手势操作。
- 验证应用是否响应该手势,例如返回上一页或者关闭当前页面。
-
从屏幕顶部向下滑动:
- 从屏幕顶部向下滑动手势。
- 验证应用是否响应该手势,例如显示下拉菜单或刷新页面。
-
从屏幕底部向上滑动:
- 从屏幕底部向上滑动手势。
- 验证应用是否响应该手势,例如显示底部菜单或者展开详细信息。
-
按住屏幕向下滑动:
- 在屏幕上按住并向下滑动手势。
- 验证应用是否响应该手势,例如实现下拉刷新或者拖动元素。
-
在图片上双击:
- 双击图片。
- 验证应用是否响应该手势,例如放大图片或者进入图片详情页。
-
按住图片下滑:
- 在图片上按住并向下滑动手势。
- 验证应用是否响应该手势,例如拖动图片或者进行其他操作。
-
2根手指头分开和聚拢:
- 使用两根手指头进行分开和聚拢手势。
- 验证应用是否响应该手势,例如放大或缩小元素。
-
2根手指头按住屏幕旋转:
- 使用两根手指头按住屏幕并进行旋转手势。
- 验证应用是否响应该手势,例如旋转元素或者切换屏幕方向。
-
3根手指上滑:
- 使用三根手指头进行上滑手势。
- 验证应用是否响应该手势,例如切换多任务视图或者执行其他操作。
-
4根手指上下/左右滑动:
- 使用四根手指头进行上下或左右滑动手势。
- 验证应用是否响应该手势,例如切换应用或者执行其他操作。
-
5根手指上下左右滑动:
- 使用五根手指头进行上下左右滑动手势。
- 验证应用是否响应该手势,例如执行特殊操作或者进行其他反应。
-
摇动手机:
- 轻轻摇动手机。
- 验证应用是否响应该手势,例如触发撤销操作或者进行其他反应。
-
长按屏幕:
- 长按屏幕一段时间。
- 验证应用是否响应该手势,例如显示上下文菜单或者启动拖动操作。