Web端测试和移动端APP测试之操作特性区分

本文详细介绍移动应用测试的关键方面,包括bug记录、测试环境搭建、兼容性验证、移动端特性考量等,帮助测试人员全面掌握移动应用测试流程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


 

之前有简单写过,这次详细说说两者的特性

 

记录bug

  

在Web端可以通过系统自带的截图和QQ截图等方式来截取bug的图片,对于错误的地方可以用工具自带的标识来重点标记。

  

对于移动端设备可以用手机自带的截图工具来截图然后传到电脑上,个人一般习惯安装微信的windows版本,通过文件传输助手发送到PC端。还有一种比较便捷的方式,将手机用数据线连接到电脑,本地配置Android的运行环境,下载asm.jar,在cmd运行Java -jar asm.jar,即可实时同步手机端画面,对有bug的页面直接使用PC端的截图工具进行截图。IOS可以在PC安装itools,要额可以同步画面。

  

对于记录bug建议:

  

bug主题尽量的言简意骇,在bug描述中可以详细描述,对于操作步骤比较复杂的bug要详细的写上操作步骤。必要时附带上相关的log,记录上测试的环境,手机版本等等。对于必现喝非必现的bug也要详细说明,减少不必要的沟通成本。

 

测试环境

  

Web端的测试环境很多时候是通过hosts进行切换,switchhosts工具可以方便的切换需要的host,但是移动端设置起来比较复杂,比较简单的方式是电脑端设置代理,手机端直接连接代理。注意,手机和电脑必须连接同一个网络。

 

兼容性

  

web端的测试一般都是主要使用一种浏览器,待系统基本稳定的时候,再去专门测试浏览器的兼容性。

  

但是,对移动端来说,这样的方式是行不通的,因为移动端主要分为安卓和IOS,而这两端出现的问题一般是不一致的,一致的问题主要是数据问题,这时候是需要后台处理的,所以我们测试的时候需要两端都重点测试,而不会出现先着重测试某一端的问题。

 

移动端的特性

  

移动端与web端相比较来说,移动端有很多自己的特性:

 

网络种类多:移动端有多种网络:无线网络、2G、3G、4G等,断网、网速较差及网络之间的切换时页面的显示等,这些对于移动端来说很重要。此外,在非wifi下,还需要注意网络使用量问题。

 

间断问题:移动端APP测试有一个很重要的问题,一般情况下在使用软件的过程并不是长久的,这中间可能发生很多中断,如电话、短信、通知、断电等等,软件需要特殊处理这些特殊情况,即中断测试

 

屏幕的限制:图片及文字的显示;上传不同的图片尺寸显示是否正常;图片和文字一起显示时,效果如何。

  

操作区域:web端的应用,一般不会受到屏幕的限制,而且通过鼠标操作更加准确。但是移动端由于屏幕较小,页面及按钮会受到屏幕大小的限制,再加上用户都是通过手指进行操作,一些按钮、选择框等是否容易点击,多个可点区域位置较近时,点击部位稍微偏移,也许就会造成不同的结果,这种情况下是否可以达到预先的效果。

 

软件启动运行:移动端APP启动、卸载、升级几个特性,这是比较常见、也很重要的,比如升级时用户的数据怎么办,卸载后用户的数据怎么处理,卸载再安装用户登录数据的显示等。

 

手势:移动端还有一大特性,就是移动端有自己比较简单的手势,用户可以通过手势进行一个操作,比如左滑删除、右滑返回上一个页面、左右滑动图片等,软件需要对这个手势进行适配。

 

分享:移动端一般会装有很多APP,用户下单或者产品有活动时,用户都会进行分享,但是分享时的权限、软件是否存在等问题,需要特殊处理测试。一般的APP,都会开放一部分页面,允许用户不登录时即可访问,而有些页面是必须要求用户登录的,主要针对这两种权限不同的页面做分享,然后通过分享进入本页面,查看权限的控制是否正常。分享只是简单的功能,对于一款APP,功能众多,APP功能测试就尤为重要。

 

web和移动端的同步:用户在web端的操作,在移动端是否可以正常的进行同步、显示;在移动端的操作,用户登录web账号,信息是否同步等。

### OAuth2 在移动端Web 的差异 OAuth2 是一种授权框架,主要用于允许第三方应用程序访问用户的资源而无需暴露用户密码。然而,在移动设备上使用 OAuth2 Web 应用程序中的实现存在显著区别。 #### 差异分析 1. **重定向机制的不同** - Web 环境下的 OAuth2 协议依赖于浏览器的重定向功能来完成认证过程。而在移动端环境中,由于缺乏统一的标准浏览器行为以及安全性的考虑,传统的基于重定向 URI 的方法可能无法正常工作[^1]。 2. **安全性考量** - 移动端应用通常运行在一个独立的安全沙箱中,这使得通过 URL Scheme 或者 Custom Tabs 来接收回调变得复杂化。因此,为了提高安全性并减少中间人的攻击风险,建议采用 PKCE (Proof Key for Code Exchange) 扩展标准[^4]。 3. **用户体验优化** - 对于移动端来说,提供更好的用户体验尤为重要。这意味着应该尽量避免让用户离开原生应用去打开外部网页进行身份验证。为此可以利用系统内置浏览器组件如 Android 上的 Chrome Custom Tab 或 iOS 中 SFSafariViewController 实现无缝切换[^3]。 #### 实现方式对比 ##### Web 实现流程 - 用户击链接跳转到授权服务器页面; - 授权服务器显示登录界面供用户输入凭证; - 成功后返回带有 code 参数的重定向地址给客户网站; - 客户再拿此 code 请求实际 token; 示例代码片段展示如何配置 Spring Security 进行 OAuth 登录过滤器设置: ```java @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests((authz) -> authz.anyRequest().authenticated()) .oauth2Login(withDefaults()); return http.build(); } ``` 上述 Java 配置文件定义了一个基本的安全链路,并启用了默认的 `OAuth2LoginAuthenticationFilter` 处理程序[^2]。 ##### 移动端实现流程 考虑到之前提到的各种因素,以下是推荐的一个典型步骤概述: - 使用官方 SDK 如果可用的话; - 否则构建自定义解决方案时需特别注意保护敏感数据比如 client secret 不应存储在任何地方容易被反编译的地方; - 当发起授权请求时加入额外参数证明密钥交换以增强防护措施; Django REST framework 路由例子展示了服务需要准备哪些 API 支持前调用获取必要信息及后续操作后的反馈处理: ```python from django.urls import path from rest_framework import routers from account import views app_name = "account" urlpatterns = [ path('OAuthID/', views.OAuthIDAPIView.as_view()), # 获取第三方客户ID path('OAuthCallback/', views.OAuthCallbackAPIView.as_view()) # 第三方登录后回调 ] router = routers.DefaultRouter() urlpatterns += router.urls ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值