## 测试资源及准备 1. 产品需求文档、产品原型图、接口说明文档以及设计说明文档等 2. 测试设备及工具：IOS和andriod不同版本的真机，以及相关测试工具（如：抓包工具、VPN等） 3. 确定被测试的APP的版本号和操作系统类型 ## 设计测试用例： 1. 根据产品需求文档、产品原型图、接口说明文档以及设计说明文档等编写功能测试用例。 2. 用例评审、修改、完善，评审通过后，根据测试用例进行测试 ## 测试阶段：UI测试、功能测试、性能压力测试、异常测试等 ## 移动测试测试常见的测试点 ## UI测试（User Interface 用户界面） 1. UE（User Experience）用户体验 - 布局与交互图保持一致，风格是否满足用户需求，若有用户体验方面的建议，可以先与产品经理确认，确认通过后，可以正式向开发提出用户体验方面的问题； - 真机效果与UE图没有视觉上的严重偏差，如字号，字体大小，加粗，字体颜色，行高，行间距，按钮摆放位置，间隔，尺寸等； - 资源图正确使用，没有不必要的拉伸，压缩或其他效果； - 各种提示，文字通顺不产生歧义，展示符合用户使用习惯； - 动画效果不卡顿，正常展现； - 由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。 2. 页面操作 - 是否有防重复点击，即连续快速点击不会出现多个页面或弹窗 - 单指滑动，单指单击，单指双击，单指长按，单指缩放，多指点击 - 摇一摇，横竖屏切换，前后台切换 - 长时间使用，长时间放在后台 3. 不同场景下的页面操作 - 不同网络，弱网下的页面跳转，点击响应的展现效果 - 修改本地参数后的页面操作展现效果，如修改日期，时间，时区，语言，键盘等 - 修改系统权限后的页面操作展现效果，如打开关闭定位，摄像，照片，通讯录等的授权等 - 页面操作过程中有系统打断，如来电，短信，闹钟提醒，日历提醒，蓝牙提醒，插拔数据线，插拔耳机，待机，锁屏，低电量提醒等 - 页面操作过程中进行前后台切换，如当页面数据交换时，有弹窗，提示框的时机进行切换容易发现问题。 - 针对非主线程调用的接口，前端要对异常及无网络情况做异步处理，不提示异常且不影响主线程操作。 4. 页面数据获取和展现 - 页面是否有缓存，缓存机制是怎样的，缓存的内容有哪些 - 在提交页面数据失败后是否有重试机制，重试的接口参数是否保持不变 - 在页面操作过程中，异步接口返回的内容，是否对用户透明（客户端兼容忽略请求返回msg） - 在页面操作过程中，对于接口返回的异常数据，客户端需兼容，保证程序不崩 # 功能测试 1. 功能测试时主要依据编写的功能测试用例进行软件功能的遍历； 2. 涉及的测试主要包括基本功能测试，安装、卸载、运行测试，异常处理（包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理）测试。 3. 业务逻辑测试：主要测试客户端业务能否正常完成。 4. 功能点测试：主要测试客户端功能点是否正常使用 5. 关联性测试：主要测试客户端与pc端的交互，客户端处理完后，pc端与客户端数据一致 ## 安装、卸载测试： 1. 生成apk文件在真机上可以安装及卸载； 2. Android手机端通用安装工具。如：豌豆荚 3. 应用程序应能正确安装到设备驱动程序上 4. 能够在安装设备驱动程序上找到应用程序的相应图标 5. 是否包含数字签名信息 6. JAD文件和 JAR包中包含的所有托管属性及其值必需是正确的 7. JAD文件显示的资料内容与应用程序显示的资料内容应一致 8. 安装路径应能指定 9. 没有用户的允许,应用程序不能预先设定自动启动 10. 卸载是否安全,其安装进去的文件是否全部卸载 11. 卸载用户使用过程中产生的文件是否有提示 12. 其修改的配置信息是否复原 13. 卸载是否影响其他软件的功能 14. 卸载应该移除所有的文件 ## 运行测试 1. App安装完成后的试运行，可正常打开软件。 2. App打开测试，是否有加载状态进度提示。 3. App打开速度测试，速度是否可观。 4. App页面间的切换是否流畅，逻辑是否正确 ## 注册 1. 同表单编辑页面 2. 用户名密码长度 3. 注册后的提示页面 4. 前台注册页面和后台的管理页面数据是否一致 5. 注册后，在后台管理中页面提示 ## 登录 1. 使用合法的用户登录系统。 2. 系统是否允许多次非法的登陆，是否有次数限制。 3. 使用已经登陆的账号登陆系统是否正确处理。 4. 使用禁用的账号登陆系统是否正确处理。 5. 用户名、口令（密码）错误或漏填时能否登陆。 6. 删除或修改后的用户，原用户登陆。 7. 不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。 8. 登陆后，页面中登陆信息。 9. 页面中有注销按钮。 10. 登陆超时的处理 ## 注销 1. 注销原模块，新的模块系统能否正确处理。 2. 终止注销能否返回原模块，原用户。 3. 注销原用户，新用户系统能否正确处理。 4. 使用错误的账号、口令、无权限的被禁用的账号进行注销 ## 软件权限 1. 扣费风险：包括发送短信、拨打电话、连接网络等 2. 隐私泄露风险：包括访问手机信息、访问联系人信息等 3. 对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测 4. 限制/允许使用手机功能接人互联网 5. 限制/允许使用手机发送接受信息功能 6. 限制/允许应用程序来注册自动启动应用程序 7. 限制或使用本地连接 8. 限制/允许使用手机拍照或录音 9. 限制/允许使用手机读取用户数据 10. 限制/允许使用手机写人用户数据 11. 检测App的用户授权级别、数据泄漏、非法授权访问等 ## 中断测试 1. APP切换到后台，再回到 App，检查是否停留在上一次操作界面。 2. APP切换到后台，再回到 App，检查功能及应用状态是否正常，IOS4和IOS5的版本的处理机制有的不一样。 3. App切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。 4. 手机锁屏解屏后进入App注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。 5. 当 App使用过程中有电话进来中断后再切换到App，功能状态是否正常 6. 当杀掉 App进程后，再开启 App，App能否正常启动。 7. 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。 8. 对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃 ## 免登录 很多应用提供免登录功能，当应用开启时自动以上一次登录的用户身份来使用 App。 1. App有免登录功能时，需要考虑IOS版本差异。 2. 考虑无网络情况时能否正常进入免登录状态。 3. 切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出。 4. 根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示。 5. app切换到后台，再切回前台的校验 6. 切换到后台，再切换回前台的测试 7. 密码更换后，检查有数据交换时是否进行了有效身份的校验 8. 支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误。 9. 检查用户主动退出登录后，下次启动app，应停留在登录界面 ## 数据更新 根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。 1. 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新。 2. 确定哪些地方从后台切换回前台时需要进行数据更新。 3. 根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新。 4. 确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试。 5. 检查有数据交换的地方，均有相应的异常处理。 ## 离线浏览 很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。 1. 在无网络情况可以浏览本地数据 2. 退出 App再开启 App时能正常浏览 3. 切换到后台再切回前台可以正常浏览 4. 锁屏后再解屏回到应用前台可以正常浏览 5. 在对服务端的数据有更新时会给予离线的相应提示 ## App更新 1. 当客户端有新版本时，有更新提示。 2. 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动App时，仍能出现更新提示。 3. 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。 4. 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。 5. 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。 6. 当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。 ## 定位、照相机服务 1. App有用到相机，定位服务时，需要注意系统版本差异 2. 有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。 3. 当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务。 4. 测试定位、照相机服务时，需要采用真机进行测试。 ## 时间测试 1. 客户端可以自行设置手机的时区、时间，因此需要校验该设置对 app的影响。 2. 中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东 8区时间时，再查看则显示为10：00。 ## 兼容性及适配测试 1. 硬件的适配：不同手机厂商(华为、OPPO、锤子等)、硬件性能，不同屏幕大小的适配（3.5到5.0屏幕在UI显示有区别，要支持最大到最小）； 2. OS版本的兼容：IOS6-9；Andriod3以上等，如果用了一些新的API在老的系统上不支持会导致crash； 3. 不同分辨率屏幕的适配：移动设备的分辨率多种多样，如果APP没有做比较合适的处理就可能会显示不好，甚至影响功能的操作。 4. 兼容性测试必须在一定数量的真机上进行，由于真机类型过多，尤其Android在做兼容性测试时，可以选取典型的几种运用较多的真机，进行兼容性测试； 5. 另外可以借助开源测试testin云测，进行更多机型的兼容性测试，testin云测提供基本的运行情况和一些截图，以及简单的测试报告，有助于扩大测试的范围。 6. 网络的兼容性：2G\\3G\\4G\\WIFI,弱网下、断网时 7. app跨版本的兼容性 ## 稳定性测试 1. 安卓APP的稳定性常常使用monkey命令进行测试，通过随机事件流模拟人的操作，对检查程序的内存溢出、空指针有很大的作用。 2. Monkey主要用来检测系统ANR及Crash等问题 ## 数据安全性 1. 当将密码或其他的敏感数据输人到应用程序时，其不会被储存在设备中，同时密码也不会被解码 2. 输人的密码将不以明文形式进行显示 3. 密码，信用卡明细，或其他的敏感数据将不被储存在它们预输人的位置上 4. 不同的应用程序的个人身份证或密码长度必需至少在4一8个数字长度之间 5. 当应用程序处理信用卡明细，或其他的敏感数据时，不以明文形式将数据写到其它单独的文件或者临时文件中。以防止应用程序异常终止而又没有删除它的临时文件，文件可能遭受人侵者的袭击，然后读取这些数据信息。 6. 当将敏感数据输人到应用程序时，其不会被储存在设备中 7. 备份应该加密，恢复数据应考虑恢复过程的异常通讯中断等，数据恢复后再使用前应该经过校验 8. 应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告 9. 应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告，更不能在安全警告显示前,，利用显示误导信息欺骗用户，应用程序不应该模拟进行安全警告误导用户 10. 在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作 11. “取消”命令操作能够按照设计要求实现其功能 12. 应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况 13. 当进行读或写用户信息操作时，应用程序将会向用户发送一个操作错误的提示信息 14. 在没有用户明确许可的前提下不损坏删除个人信息管理应用程序中的任何内容 15. 应用程序读和写数据正确。 16. 应用程序应当有异常保护。 17. 如果数据库中重要的数据正要被重写，应及时告知用户 18. 能合理地处理出现的错误 19. 意外情况下应提示用户 ## 通讯安全性 1. 在运行其软件过程中，如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时，是否能暂停程序，优先处理通信，并在处理完毕后能正常恢复软件，继续其原来的功能 2. 当创立连接时，应用程序能够处理因为网络连接中断，进而告诉用户连接中断的情况 3. 应能处理通讯延时或中断 4. 应用程序将保持工作到通讯超时，进而发送给用户一个错误信息指示有连接错误 5. 应能处理网络异常和及时将异常情况通报用户 6. 应用程序关闭或网络连接不再使用时应及时关闭或断开 7. HTTP、HTTPS覆盖测试 –App和后台服务一般都是通过HTTP来交互的，验证HTTP环境下是否正常； –公共免费网络环境中（如：麦当劳、星巴克等）都要输入用户名和密码，通过SSL认证来访问网络，需要对使用HTTPClient的library异常作捕获处理。 ## 人机接口安全性 1. 返回菜单总保持可用 2. 命令有优先权顺序 3. 声音的设置不影响应用程序的功能 4. 应用程序必需利用目标设备适用的全屏尺寸来显示上述内容 5. 应用程序必需能够处理不可预知的用户操作，例如错误的操作和同时按下多个键 ## PUSH测试 1. 检查push消息是否按照指定的业务规则发送 2. 检查不接受推送消息时，检查用户不会再接收到push. 3. 如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH。 在非免打扰时间段，用户能正常收到push。 4. 当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。 5. 测试push时，需要采用真机进行测试 ## 交叉事件测试 针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。如；App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。交叉事件测试非常重要，能发现很多应用中潜在的性能问题。 1. 多个App同时运行是否影响正常功能 2. App运行时前/后台切换是否影响正常功能 3. App运行时拨打/接听电话 4. App运行时发送/接收信息 5. App运行时发送/收取邮件 6. App运行时切换网络（2G、3G、wifi） 7. App运行时浏览网络 8. App运行时使用蓝牙传送/接收数据 9. App运行时使用相机、计算器等手机自带设备 ## 图形测试 1. 横向比较。各控件操作方式统一 2. 自适应界面设计，内容根据窗口大小自适应 3. 页面标签风格是否统一 4. 页面是否美观 5. 页面的图片应有其实际意义而要求整体有序美观 6. 图片质量要高且图片尺寸在设计符合要求的情况下应尽量小 7. 界面整体使用的颜色不宜过多 ## 支付测试 1. 支付结果的确认，数据库查询 2. 请求报文是否加密 3. 不同场景的支付:金额足够、金额不足、重复支付、无网支付、弱网支付、同账号多平台一起支付、余额宝微信信用卡等多种支付方式、不同支付方式的组合、密码正确/错误、支付上限等情况 4. 选择付款方式为‘支付宝’，测试是否提示“允许打开支付宝” 5. 测试支付宝没有安装的情况下，APP是否有正确提示（未安装支付宝） 6. 测试支付宝正确安装的情况下，未登录支付宝，是否提示登录页面 7. 测试支付宝正确安装的情况下，已登录支付宝，是否提示支付页面 ## 性能测试 1. 客户端性能测试重点关注：安装卸载时间、启动时间、页面加载时间、主要功能占用的CPU、内存、流量、耗电量等，以及与同类产品相比较是否有优势； 2. 其中页面加载时间可以利用Android调试工具DDMS获取到，在DDMS里面搜索Displayed关键字就可以看到页面加载时间； 3. 运行过程中主要功能占用的CPU、内存、流量等可以借助开源工具emmagee（适用于Android）获取到； 4. 至于服务器端的性能，主要利用接口对服务器施加压力，重点关注响应时间、吞吐量、并发数、事物通过率等，可以视同工具loadrunner、jmeter进行测试。 ## 回归测试 bug修复后的回归测试，上线交付前进行全部的回归，验证 ## 移动端程序的开发流程  **版本流程详解：** 版本流程共分为5大部分，分别为需求、开发、测试、发布、反馈收集。 ### 需求部分 1、需求池：产品会将各组需求进行优先级排序，跟进技术资源的数量来安排当前版本可以做哪些需求。 2、立项：需求较大，涉及较多不同开发组、或部门的需求需要立项，项目进度与资源有独立的项目经理跟进。 3、需求评审：其中包含需求预审，需求预审是各组老大对该版本的需求进行一次预审与工作量初步评估。确定版本需求后产品经理会在规定的时间节点内召集开发、测试进行需求评审。 ### 开发部分 4、设计评审：服务端开发接口设计完成后进行设计评审，与android、iOS开发沟通清楚接口设计。确保信息一致性。 5、开发编码：开发各自根据需求进行开发。 ### 测试部分 6、用例设计、用例评审：在开发编码过程中进行用例设计，用设计完成后召集产品、相关开发、相关测试进行TC评审 7、功能预演：在开发提测时进行功能预演，最好能邀请产品参加，产品提前介入能够提前发现需求、交互与产品预想中的差异。降低修改成本 8、冒烟测试：功能预演通过后进行冒烟测试，冒烟测试如果遇到主干流程不通可以直接打回。冒烟测试过程中需要保证主要功能正常，不影响后续测试。 9、功能测试：根据项目复杂度确定功能测试轮数 10、适配测试：手工适配，挑选用户量占比较多的手机进行适配测试，保证不同分辨率，不同操作系统的手机都能正常使用。自动化适配，使用自动化工具在机房进行monkey测试，测试APP在不同操作系统、机型上的安装、卸载、启动、跟稳定性。 11、服务端性能测试：根据需求、预估线上用户量，是否需要提交申请性能测试。需要在上线前完成性能测试与性能调优。 12、客户端性能测试：理论上来说新增的功能都需要进行性能测试。需要用工具检查APP的内存占用、CPU占用、FPS、流量、电量等指标是否符合预期。 13、bugbash：在完成功能测试后进行bugbash，需要邀请产品、交互、视觉、开发、测试参与，将bugbash中发现的问题汇总修改完成后可以进入发布流程。 ### 发布部分 14、发布计划制定：发布计划分为两部分，一为服务端发布，二为客户端发布。 服务端发布根据项目涉及到的应用，制定发布顺序，一些独立工程或者独立项目可以以项目上线流程提前上线。剩余应用排定顺序后在发布日按顺序发布。 客户端根据需求制定需要灰度的时间，策略，渠道等。灰度完成后再正式发布到市场。 15、发布执行，在服务端发布日当天如果涉及应用较多可以进行集中发布，将PE、开发负责人、测试负责人集中到一起进行发布。具体发布细节可以参考发布流程。 16、客户端发布：服务端发布完成后客户端打渠道包进行渠道灰度，一般2~3天左右，根据收集的问题修复后，测试进行客户端大回归，大回归通过后，发布到各个应用市场 ### 反馈收集 17、发布完成后分析crash日志，收集用户反馈将收集的问题加入到需求池。 ## 常见的移动端测试流程