移动App崩溃测试用例设计

移动App测试与传统台式机测试相比有一定的复杂性。这些复杂性可以被分类为:

  环境(大量的设备,各种移动OSs,适应频繁OSs变化) 。

  设备(触摸式和非触摸式设备,有限的内存容量,电池耗电量) 。

  网络(不同的网络和运营商,在不好或无网络的情况下的App行为,离线支持) 。

  可用性(方向,触摸,多触摸,缩放,分页和导航的局限性,各种干扰,如来电,来电短信,闹钟,和低电量警报) 。

移动App崩溃原因【一些崩溃原因(排名不分先后)】:

  为什么移动App经常崩溃?App崩溃有几个原因:从平台或环境到开发问题。

  设备碎片化:由于设备极具多样性,App在不同的设备上可能有表现不同。

  带宽限制:带宽不佳的网络对App所需的快速响应时间可能不够。

  网络的变化:不同网络间的切换可能会影响App的稳定性。

  内存管理:可用内存过低,或非授权的内存位置的使用可能会导致App失败。

  用户过多:连接数量过多可能会导致App崩溃。

  代码错误:没有经过测试的新功能,可能会导致App在生产环境中失败。

  第三方服务:广告或弹出屏幕可能会导致App崩溃。

移动App崩溃的测试用例设计

  测试用例是移动测试最重要部分之一。

  准备和执行预先定义的针对移动App崩溃的测试用例将简化和加速移动App崩溃的测试。

一些通用的触发移动App崩溃的测试场景,如下:

  1 验证在有不同的屏幕分辨率,操作系统和运营商的多个设备上的App行为。

  2 用新发布的操作系统版本验证App的行为。

  3 验证在如隧道,电梯等网络质量突然改变的环境中的App行为。

  4 通过手动网络从蜂窝更改到Wi-Fi ,或反过来,验证App行为。

  5 验证在没有网络的环境中的App行为。

  6 验证来电/短信和设备特定的警报(如警报和通知)时的App行为。

  7 通过改变设备的方向,以不同的视图模式,验证App行为。

  8 验证设备内存不足时的App行为。

  9 通过用测试工具施加载荷验证App行为。

  10 用不同的支持语言验证App行为。

  显然,还会有更多的导致App崩溃的App特定场景。
结论

  在这项研究中,展示了针对移动App崩溃的通用测试案例。

  如果移动测试团队在他们的测试场景中准备并执行这些测试用例,那么早在开发周期就可以找到崩溃相关的Bug。然后,开发团队将阐明崩溃原因,并找出一个解决所有Bug的通用方法。最后,App质量和用户满意度就会增加。

时间: 2024-10-10 03:03:59

移动App崩溃测试用例设计的相关文章

移动App崩溃的测试用例设计

移动App测试与传统台式机测试相比有一定的复杂性.这些复杂性可以被分类为:   环境(大量的设备,各种移动OSs,适应频繁OSs变化) . 设备(触摸式和非触摸式设备,有限的内存容量,电池耗电量) . 网络(不同的网络和运营商,在不好或无网络的情况下的App行为,离线                   支持) .   可用性(方向,触摸,多触摸,缩放,分页和导航的局限性,各种干扰,                       如来电,来电短          信,闹钟,和低电量警报) . 所有

移动APP测试用例设计实践经验(转载)

前言杂谈 在聊移动APP测试用例设计之前,我请大家先思考如下2个问题: 第一,我们为什么要做好测试用例设计?--why? 第二,好的测试用例设计有什么共性? --what? 深入思考这2个问题的答案是一件很有意义的事情,作为移动互联网时代的产品质量守卫军,我们必须提升自己的测试设计能力,必须清楚的知道要测什么,怎么测.但单从我们测试团队现状来看,有很多人都没有做好准备,测试设计方法仍然比较落后,所以我整理此文,旨在总结沉淀移动客户端测试用例设计实践,帮助测试人员时刻审视完善自我测试能力提升. 那

Android软硬整合设计与框架揭秘: HAL&Framework &Native Service &App&HTML5架构设计与实战开发

掌握Android从底层开发到框架整合技术到上层App开发及HTML5的全部技术: 一次彻底的Android架构.思想和实战技术的洗礼: 彻底掌握Andorid HAL.Android Runtime.Android Framework.Android Native Service.Android Binder.Android App.Android Testing.HTML5技术的源泉和精髓等核心技术,不仅仅是技术和代码本身,更重要的是背后的设计思想和商业哲学. 一.课程特色 l  贯通And

服务端测试之接口测试用例设计

小伙伴们大家好,上一次和大家分享了<服务端测试之接口测试初探>,讲了一些接口测试的基本概念和理论知识.在上次的分享中,简单提到了接口测试用例设计包含的几个方面.本期我将在上次分享的基础上,和各位小伙伴一起具体看看这几个方面都是什么,在实际的项目中应该如何使用. 一.功能性用例设计 之前讲过,服务端的接口是和客户端的功能相对应的,对功能的验证,可以参照接口说明文档来进行.概括起来讲,就是我们需要验证接口说明文档中提到的各种情况,保证这些情况下接口的返回和最初设计的是一样的,这样我们就可以认为该接

自动化测试之-测试用例设计方法总结

黑盒.白盒.接口测试一系列用例设计方法. 黑盒测试用例设计方法包括等价类划分法.边界值分析法.错误推测法.因果图法.判定表驱动法.正交试验设计法.功能图法.场景图法等. (一)等价类划分法 定义:等价类划分法是把所有可能输入的数据,即程序的输入域划分策划国内若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.方法是一种重要的.常用的黑盒测试用例设计方法. 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表

15款优秀移动APP产品原型设计工具

一款优秀的移动APP产品原型设计工具应该具备: ①.支持移动端演示(随时随地演示给BOSS,厕所&食堂&电梯-以体现我是那么的敬业--长点工资必备) ②.组件库(高效复用,谁用谁知道) ③.可以快速生成全局流程(程序猿看不懂拆解的,给丫的看这个) ④.在线协作(多个PM狗一起用) ⑤.手势操作.转场动画.交互特效-(这些都不需要,留给专业的交互.视觉,搞那么虚的不如多想想产品流程逻辑做做减法.写写xxRD啥的) 这些年,产品狗们折腾过的原型工具: 1. POP(Prototyping on

SWTBOK测试实践系列(7) -- 测试用例设计的参考输入有哪些?

不管是文档化的测试用例,还是存在于测试人员头脑中的测试想法和思维,针对测试对象的分析和设计都是整个测试过程的重要测试活动之一.在进行测试分析和设计之前,测试人员首先需要确定测试的需求来源,即测试用例设计需要参考哪些测试依据文档? 测试用例设计的输入文档是什么?测试人员头脑中第一个蹦出的参考依据就是需求规格说明.确实,需求文档是我们测试设计的最主要参考文档.但是,由于时间限制.成本限制和个人能力限制等方面的原因,提供完备的需求规格说明几乎是不可能的.现实情况是,需求规格说明常常是不全的.模糊的,甚

测试用例设计白皮书--边界值分析方法

一.方法简介1.定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法.通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界. 2.与等价划分的区别  1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件.  2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况. 3.边界值分析方法的考虑:  长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对

转:性能测试用例设计策略

性能测试在软件质量保证中起着重要的作用,它包括的测试内容丰富多样.同一个系统,不同的测试设计及测试过程会导致不同的结果,也会有不同的解读.合理的测试规划与设计是至关重要的.本文重点介绍如何结合用户实际业务特点制定有效的性能测试用例. 一.系统业务特点和用户行为分析 用户行为反映了用户对系统的使用模式和应用背景,在性能测试之前,我们首先需要分析用户的使用习惯,确定系统的典型业务及发生时间.分析用户行为是设计性能测试用例的第一步. 1.系统使用高峰时段分析 对于很多大型系统,都有业务集中开展使用的情