Web测试 的基本知识,基本都可以平移到 App测试 上。
但相较于 Web测试,App测试 要兼顾的内容更多,场景更复杂,面临的风险就更大。
因此,本篇内容主要整理 App测试 需要了解的基础知识。
App 的测试工具知道哪些?
在测试 App 时,常用的工具,例如:
-
抓包:用到 Charles、Fiddler
-
自动化相关:Appium、公司自研的自动化框架平台、元素定位工具
-
构造数据:数据库相关的工具,Redis相关的工具
Android 四大组件
Android 四大基本组件包括 Activity、BroadcastReceiver 广播接收器、ContentProvider 内容提供者、Service 服务。
Activity(程序与用户的交互窗口):
应用程序中,一个 Activity 就相当于手机屏幕,它是一种可以包含用户界面的组件,主要用于和用户进行交互。一个应用程序可以包含许多活动,比如事件的点击,一般都会触发一个新的 Activity。
BroadcastReceiver(广播接收器,应用程序之间传输信息的机制):
应用可以使用它对外部事件进行过滤,只对感兴趣的外部事件(如当电话呼入时,或者数据网络可用时)进行接收并做出响应,广播接收器没有用户界面。
然而,它们可以启动一个 Activity 或 Serice 来响应它们收到的信息,或者用NotificationManager 来通知用户。通知可以用很多种方式来吸引用户的注意力──闪动背灯、震动、播放声音 等。一般来说是在状态栏上放一个持久的图标,用户可以打开它并获取消息。
ContentProvider (内容提供者,提供数据的统一访问格式):
内容提供者主要用于在不同应用程序之间实现数据共享的功能,它提供了一套完整的机制,允许一个程序访问另一个程序中的数据,同时还能保证被访问数据的安全性。
只有需要在多个应用程序间共享数据时才需要内容提供者。例如:通讯录数据被多个应用程序使用,且必须存储在一个内容提供者中。它的好处:统一数据访问方式。
Service (服务,在程序后台,完成用户的操作):
是 Android 中实现程序后台运行的解决方案,它非常适合去执行那些不需要和用户交互而且还要长期运行的任务(一边打电话,后台挂着 QQ)。
服务 的运行不依赖于任何用户界面,即使程序被切换到后台,或者用户打开了另一个应用程序,服务仍然能够保持正常运行,不过服务并不是运行在一个独立的进程当中,而是依赖于创建服务时所在的应用程序进程。当某个应用程序进程被杀掉后,所有依赖于该进程的服务也会停止运行(正在听音乐,然后把音乐程序退出)。
App 测试和 Web 测试有什么区别?
从流程上来说,Web 测试和 App 测试没有区别,都需要经历测试计划方案,用例设计,测试执行,缺陷管理,测试报告等相关活动。
从技术上来说,Web 测试 和 APP 测试 的测试类型也基本相似,都需要进行功能测试、接口测试、性能测试等。
主要区别在于具体的测试细节和方法上,比如:
性能测试:
在 Web 测试重点关注测试响应时间这个要素,而在 App 测试中还需要考虑流量测试和耗电量测试等。
兼容性测试:
在 Web 端是兼容浏览器,在 App 端兼容的是手机设备。
而且相对应的兼容性测试工具也不相同,Web 因为是测试兼容浏览器,所以需要使用不同的浏览器进行兼容性测试(常见的是兼容chrome,Firefox);
如果是手机端,那么就需要兼容不同品牌,不同分辨率,不同 Android 版本甚至不同操作系统的兼容。(通常是兼容市场占用率前 N 位的手机即可),有时候也可以使用到兼容性测试工具,App 兼容性测试会使用 Testin 这样的商业工具。
安装测试:
Web 测试基本上没有客户端层面的安装测试,而 App 测试 存在客户端层面的安装测试。
还有,App 测试基于手机设备,需要进行手机设备的专项测试。如交叉事件测试,操作类型测试,网络测试(弱网测试,网络切换)
交叉事件测试:
就是在操作某个软件的时候,来电话、来短信,电量不足提示等外部事件。
操作类型测试:
如横屏测试,手势测试
网络测试:
包含弱网和网络切换测试。需要测试弱网所造成的用户体验,重点要考虑回退和刷新是否会造成二次提交。
从系统架构的层面,Web 测试只要更新了服务器端,客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。
但是 APP 端是不能够保证完全一致的,除非用户更新客户端。如果是 APP 修改了服务器端,意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
升级测试:
升级测试的提醒机制,升级取消是否会影响原有功能的使用,升级后用户数据是否被清除了。
剩余内容,请通过下方获取方式购买后跳转阅读~
获取方式
本专栏内容为付费内容,你可以按照实际需求下单购买,谢谢你的支持~