APP测试相关-CSDN博客

本文链接：https://blog.csdn.net/fenqi1989/article/details/136886203

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 修改了服务器端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

升级测试：