chanong --在公共免费网络环境（如麦当劳、星巴克等），必须输入用户名和密码并通过SSL认证
访问网络需要使用HTTP捕获异常。
2.1.5 人机界面安全
1）返回菜单始终可用
2）命令有优先顺序
3) 声音设置不影响应用程序的功能
4）应用程序必须使用适合目标设备的全屏尺寸来显示上述内容
5）应用程序必须能够处理不可预测的用户操作，例如错误操作和同时按下多个按键
2.2 安装与卸载测试
验证App是否能够正确安装、运行、卸载
2.2.1 安装
1) 该软件运行在不同的操作系统上（Palm OS、Linux、iOS、Black Berry OS 6.0、
电话 ）安装是否正常？
2）软件安装后能否正常运行，安装后的文件夹和文件是否写入指定目录。
3）各种软件安装选项的组合是否符合概要设计说明
4)) 软件安装向导的UI测试
5）软件安装过程是否可以取消？ 点击取消后，写入的文件是否按照概要设计说明进行处理
6）软件安装过程中意外情况的处理是否符合要求（如死机、重启、断电）
7）安装空间不足时是否有相应提示？
8）安装后不产生多余的目录结构和文件
9) 对于需要网络验证的安装，请在网络断开的情况下尝试。
10）安装手册还需要进行测试，看能否按照安装手册顺利安装。
2.2.2 卸载
1）直接删除安装文件夹，检查卸载时是否有提示信息。
2）测试系统直接卸载程序时是否有提示信息。
3) 测试卸载后是否删除所有安装文件夹中的所有文件。
4）测试卸载过程中出现的意外情况（如死机、断电、重启）。
5）卸载是否支持取消功能，点击取消后软件如何卸载。
6）系统直接卸载UI测试，看是否有卸载状态进度条提示。
2.3 用户界面测试
测试用户界面（如菜单、对话框、窗口等常规控件）的布局和风格是否满足客户要求、文字
是否正确、页面是否美观、文字与图片的结合是否完美、操作是否友好等。
UI测试的目标是确保用户界面通过测试对象的功能为用户提供相应的访问或浏览功能。
确保用户界面符合公司或行业标准。 包括用户友好性、人性化、操作便捷性测试。
2.3.1 导航测试
1）按钮、对话框、列表和窗口等； 或者需要在不同连接页面之间导航
2）导航是否容易且直观？
3）您需要搜索引擎吗？
4）导航帮助是否准确、直观？
5）导航与页面结构、菜单、链接页面风格是否一致？
2.3.2 图形测试
1）横向比较。各个控件统一操作
2）自适应界面设计，内容根据窗口大小自适应
3）页面标签风格是否一致？
4）页面漂亮吗？
5）页面中的图片应具有实际意义，结构合理，整体美观。
6）在设计满足要求的情况下，图片质量要高，图片尺寸尽量小。
7）界面整体颜色不宜过多
2.3.3 内容测试
1）输入框描述文字内容是否与系统功能一致
2）文本长度有限制吗？
3）文本内容是否含义不明确
4）有没有错别字？
5）信息是否显示中文
6）是否存在敏感词和关键词？
7) 是否存在敏感图片，例如涉及版权、专利、隐私等的图片。
2.4 功能测试
根据软件描述或用户需求验证App各功能的实现，并使用以下方法实施和评估功能测试
程序：
1）利用时间、地点、对象、行为和背景或业务分析五要素来分析和提炼App的用户使用情况
场景，比较描述或需求，梳理直接相关的内部、外部和非功能需求，构建测试点，并明确
测试标准。 如果用户需求没有明确的标准可遵循，则需要参考行业或相关国际标准或指南。
2）根据被测试的功能点的特点，列出相应类型的测试用例来覆盖，例如：哪里需要输入
考虑测试类型，例如等效、边界、否定、异常或非法、场景回滚和相关性测试来覆盖它们。
3）跟踪测试实施各阶段的测试实施覆盖率和需求输入，及时纠正对业务或需求的误解
错误。
2.4.1 运行
1）App试运行完成后，软件可以正常打开。
2）打开App测试一下是否有加载状态进度提示。
3）测试打开应用程序的速度，看速度是否可观。
4）App页面之间切换是否流畅，逻辑是否正确
5）注册
--与表单编辑页面相同
--用户名和密码长度
--注册后提示页面
--前端注册页面和后端管理页面数据是否一致
--注册后，后台管理中页面提示
6) 登录
--使用合法用户登录系统。
--系统是否允许多次非法登录，是否有次数限制。
--使用已经登录的账号登录系统是否处理正确。
--禁用账号登录系统是否正确处理。
--用户名和密码（）错误或丢失还能登录吗？
--删除或修改用户后，原用户登录。
--不要输入用户密码和用户，重复单击（确定或取消按钮）以允许登录。
--登录后，页面会显示登录信息。
--页面上有一个注销按钮。
--登录超时的处理。
7) 退出
--新模块系统能否正确处理原模块的注销？
--终止注销后用户能否回到原来的模块和用户？
--原用户注销后系统能否正确处理新用户的注销？
--使用错误的账号、密码或未经许可的禁用账号退出
2.4.2 应用程序前后切换
1）将APP切换到后台，然后返回APP，检查是否停留在上次操作界面。
2）将APP切换到后台，然后返回应用程序，检查功能和应用状态是否正常，IOS4和IOS5版本有什么区别？
机制不同。
3）当应用程序切换到后台再返回前台时，请注意程序是否崩溃以及功能状态是否正常，特别是对于以下用户：
当后台切换回前台时，数据会自动更新。
4）手机锁定和解锁后，进入应用程序并注意是否会崩溃以及功能状态是否正常，特别是从后台切换。
当返回前台时数据自动更新。
5）当应用程序被电话中断，然后切换到应用程序时，功能状态是否正常？
6）杀掉app进程再打开app后，app能否正常启动？
7) 出现必须处理的提示框后，切换到后台，然后再切换回来，检查提示框是否还存在。 有时
会存在应用程序自动跳过提示框的错误。
8）对于有数据交换的页面，每个页面都要进行前后切换和锁屏测试。 这种页面最多
容易崩溃。
2.4.3 无需登录
许多应用程序都提供免登录功能。 当应用程序打开时，将自动使用上次登录的用户。
1）当应用具有免登录功能时，需要考虑IOS版本的差异。
2）考虑在没有网络的情况下能否正常进入免登录状态。
3）切换用户登录后，验证用户登录信息和数据内容是否相应更新，确保原用户退出。
4）根据MTOP现有规则，一个账号只能登录一台机器，所以需要检查一个账号多次登录
手机情况。 需要将原来手机上的用户踢出并给出友好提示。
5) 验证切换app到后台再切换回前台
6）切换到后台再切换回前台测试
7) 修改密码后，检查交换数据时是否进行了有效的身份验证。
8) 当支持自动登录的应用程序进行数据交换时，检查系统是否能够自动登录成功以及数据操作是否成功。
错误。
9）检查用户主动注销后，下次启动应用程序时，应停留在登录界面。
2.4.4 数据更新
根据应用的业务规则和数据更新量，确定最优的数据更新方案。
1）需要确定哪里需要手动刷新，哪里需要自动刷新，哪里需要手动+自动。
刷新。
2）确定从后台切换回前台时需要更新哪些数据。
3）根据业务、速度、流量的合理分配，确定哪些内容需要实时更新，哪些内容需要定期更新。
4）确定数据显示部分的处理逻辑，是每次都向服务器请求，还是缓存在本地，这样就可以
相应地进行相应的测试。
5）检查哪里有数据交换，并有相应的异常处理。
2.4.5 离线浏览
很多应用都会支持离线浏览，即一部分数据会缓存在本地客户端，供用户查看。
1）无网络时可以浏览本地数据
2）退出应用重新打开即可正常浏览。
3）切换到后台再切换回前台即可正常浏览。
4) 锁定屏幕后，解锁屏幕并返回应用前台正常浏览。
5）当服务器上的数据有更新时，会给出相应的离线提示。
2.4.6 应用程序更新
1）当客户端有新版本时，会有更新提示。
2）当版本为非强制升级时，用户可以取消更新，旧版本可以正常使用。 下次用户启动应用程序时
，仍然可以出现更新提示。
3）当版本为强制升级版本时，如果强制更新后用户没有更新，则退出客户端。下次开始
使用应用时，仍然出现强制升级提示。
4）当客户端有新版本时，直接更新并检查是否可以正常更新，无需删除本地客户端。
5）当有新版本客户端时，在本地不删除客户端的情况下，检查更新的客户端功能是否可用
新版本。
6）当有新版本客户端时，在本地不删除客户端的情况下，检查是否可以删除与资源同名的文件，例如图片
正常更新到最新版本。 如果以上无法更新成功，也是缺陷。
2.4.7 定位和摄像服务
1）App使用摄像头和定位服务时，需要注意系统版本差异。
2）当使用定位服务和摄像头服务时，需要进行前后端切换测试，检查应用是否正常。
3）当定位服务未开启时，使用定位服务时，会弹出是否允许设置位置的友好提示，确定后
当允许开启定位时，可以自动跳转到定位设置开启定位服务。
4）测试定位和摄像头服务时，需要使用真机进行测试。
2.4.8 时间测试
客户端可以自行设置手机的时区和时间，因此需要验证该设置对app的影响。
--中国是东八区，所以当手机设置的时间不是东八区时，请检查需要显示时间的地方，看时间是否为
显示正确，应用功能正常。时间一般需要根据服务器时间转换为客户端对应的时区。
说明这样的用户体验比较好。比如发布一条微博，服务器记录的时间是10:00。 此时，华盛
时间是22:00。 客户端浏览时，如果设置了华盛顿时间，则显示的发布时间为22:00。
当时间调回东8区时间后，再次查看会显示10:00。
2.4.9 推测试
1）检查推送消息是否按照指定的业务规则发送
2）检查不接受推送消息时，检查用户将不再接收推送消息。
3) 如果用户设置了免打扰时间段，请检查用户在免打扰时间段内是否收不到PUSH。
非免打扰时段，用户可以正常接收推送消息。
4）当推送消息是针对已登录用户时，需要检查接收到的推送是否与用户身份匹配。 不。
错误地推送了别人的消息。 正常情况下，消息只会推送给话机上最后登录的用户。
5）测试推送时，需要使用真机进行测试。
2.5 性能测试
评估应用程序的时间和空间属性：
1）极限测试：验证App在电池、存储、网速等各种边界压力条件下是否能够正确响应。
--内存满时安装App
--运行App时手机处于关机状态
--运行App时断开网络
2）响应性测试：测试App中的各项操作是否满足用户响应时间要求。
--App安装和卸载的响应时间
--App各项功能操作的影响时间
3）压力测试：在重复/长期运行下，系统资源是否被异常占用。
--App反复安装、卸载，检查系统资源是否正常。
-- 重复其他功能的操作，检查系统资源是否正常。
4）性能评估：评估典型用户应用场景下系统资源的使用情况。
5）测试（基线测试）：与竞品的对比测试、产品演进等。
2.6 交叉事件测试
针对智能终端应用的服务级别分类和实时特性提出的一种测试方法。交叉测试也称为事件或
冲突测试是指一个功能正在执行而另一个事件或操作干扰该过程的测试。
例如，测试App在前/后台状态运行时与来电、文件下载、听音乐等关键应用的交互情况。
尝试等待。 跨事件测试非常重要，可以识别许多应用程序中潜在的性能问题。
1）同时运行多个应用会影响正常功能吗？
2）App运行时前后台切换是否影响正常功能？
3) 在应用程序运行时拨打/接听电话
4）App运行时发送/接收信息
5) 在应用程序运行时发送/接收电子邮件
6) App运行时切换网络（2G、3G、wifi）
7) 在应用程序运行时浏览互联网
8) App运行时使用蓝牙发送/接收数据
9）App运行时，使用相机、计算器等手机自带设备
2.7 兼容性测试
主要测试内部和外部兼容性
1）是否兼容本地及主流应用？
2）根据开发环境和生产环境的差异，检查各种网络连接（WiFi、GSM、GPRS、EDGE、WCDMA、
、、HSPDA等），App的数据和应用是否正确
3）是否兼容各种设备。 如果有跨系统支持，需要检查各个系统下的各种行为是否一致。
--不同操作系统的兼容性以及是否兼容
--兼容不同手机屏幕分辨率
--不同手机品牌的兼容性
2.8 回归测试
1）bug修复后、新版本发布后需要进行回归测试。
2) 交付前必须对所有用例进行 bug 修复后的回归测试。
2.9 升级更新测试
新版本发布后，将根据不同的网络环境提供自动更新提示以及下载、安装、更新、启动、运行验证。
测试。
1）测试升级后的功能是否与需求描述相同
2）测试升级模块相关的功能是否符合要求
3）升级安装过程中意外情况的测试（如死机、断电、重启）
4）升级界面UI测试
5）不同操作系统之间的升级测试
2.10 用户体验测试
从普通消费者的主观角度感知产品或服务的舒适性、实用性、易用性、亲切感和亲切感。
不同个体、独立空间、非体验统计复用方法，有效评估产品的体验特性
提高产品的潜在客户满意度。
1）是否有空的数据界面设计来引导用户进行操作？
2）用户指导是否被滥用。
3）是否有无法点击的效果？ 例如，如果你的按钮此时不可用，则必须将其变灰或删除。
去掉按钮，否则会误导用户
4）菜单层次是否太深？
5）交互过程中分支是否过多？
6）相关选项是否遥远？
7) 是否一次性加载过多数据
8）界面中按钮的可点击范围是否合适
9）标签页与内容是否没有从属关系。 当标签切换时，内容也会随之切换。
10）操作要有主次关系
11) 是否定义Back键的逻辑。当涉及到软硬件交互时，需要专门定义Back键
12）有横向模式的设计吗？ 应用程序一般需要支持横向模式，即自适应设计。
2.11 硬件环境测试
2.11.1 手势操作测试
1）手机屏幕解锁对运行应用程序的影响
2）切换网络对运行App的影响
3）正在运行的App前后切换的影响
4）在多个正在运行的应用程序之间切换
5) 在应用程序运行时关闭它
6）App运行时重启系统
7) App运行时充电
8）当App运行时，杀掉进程，然后重新打开
2.11.2 网络环境
手机网络目前主要分为2G、3G和wifi。目前2G网络速度比较慢，所以测试时要特别注意这一点。
块测试。
1）无网络时，执行需要网络的操作并给出友好提示，保证程序不崩溃。
2）在内网测试时，选择外网操作时要注意异常情况的处理。
3）当网络信号较差时，检查功能状态是否正常，确保不会因提交数据失败而崩溃。
4）当网络信号不好时，检查数据是否会一直提交，是否有超时限制。如果有数据
交换失败时应进行提示。
5) 当网络信号不好时，执行操作后，如果回调未完成，请退出本页面或执行其他操作。
运行情况及有无异常情况。 这个问题也常常导致程序崩溃。
2.11.3 服务器宕机或出现404、502等情况时测试
当后台服务涉及DNS和空间服务提供商时，其稳定性会受到影响。 例如，当域名解析失败时，
你对后端API的请求很可能会导致404错误并抛出异常，这时候就需要正确处理异常
否则，程序可能无法正常运行。
2.12 接口测试
服务端一般向客户端提供JSON格式的数据，所以我们需要在服务端进行接口测试以保证
服务端提供的接口以及转换后的JSON内容都是正确的，分支和异常流都有对应的返回值。这个块测试可以
使用框架进行测试。 最方便的方法是使用接口测试。
在进行服务端测试时，需要开发并提供接口文档。
2.13 客户端数据库测试
1）常规的增、删、改、查测试。
2）表不存在时是否可以自动创建，数据库表删除后是否可以重新创建，是否可以自动从中检索数据。
从服务器取回并保存。
3）当业务需要从服务器检索数据并保存到客户端时，客户端是否可以将数据保存在本地。
4）当业务需要从客户端检索数据时，检查当客户端数据存在时，是否可以自动从客户端检索应用数据。
数据，还是还是从服务器获取？检查客户端数据不存在时是否可以自动获取app数据
在服务器端获取并保存到客户端
5）当业务修改或删除数据时，客户端和服务端是否会相应更新？
微信扫一扫打赏
支付宝扫一扫打赏
