【转载】移动端的功能测试范畴

 

要总结的是都很简单,但是很重要的功能测试

定义功能测试:Functional testing is a quality assurance (QA) process and a type of black-box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered (not like inwhite-box testing).Functional testing usually describes what the system does.

简单的说就是功能测试时检验系统能够做什么的测试。对于移动端来说,这是一款什么样的app, 它可以做什么。但是相对于pc 端的系统来说,由于使用环境的多元化,使用的用户差异化,使用习惯的不同让一款app 测试起来颇为费劲,首先了解下功能测试要测试那些方面。

一、 验证App是否能正确安装、运行、卸载,升级以及操作过程和操作前后对系统文件的影响,主要包括:

1)检测软件是否能正确安装、运行、卸载; 
   2)安装、卸载、更新错误报告; 
   3)其他辅助信息:  
      -安装文件的位置和文件夹是否合理;   
      -组件是否正确注册或删除;
      -系统缓存文件, 尤其是图片,语音保存位置,是否会影响系统层面的文件
     问题3的第一个问题,主要指Android,实话这块检查的比较少,要求了解android APK应用安装过程以及默认安装路径,自行百度;后两个问题是经常会遗漏的,这是个巨坑,说多了都是泪呀!
   4)升级!!其实在测试的过程中一般都会在不知觉中进行了覆盖性测试,但是你试过应用内下载测试么,这是经常忘记呀, 而且测试用例里面在第一版里面会有,之后就不会再写,成了大家一个不说的测试用例,但是就是会忘!!建议,针对上线写一个check list,包括这一项。
   5) 从服务器下载的apk名字,尤其是通过浏览器下载的,用户会看不懂应用的名字从而造成错觉

二、 权限测试,权限测试这个是很简单的一个东西,也没找到有啥针对移动端的权限测试方面的介绍,就简单的列下在工作中遇到的一些问题。

1)软件权限  
  -扣费风险:包括发送短信、拨打电话、连接网络等    
  -隐私泄露风险:包括访问手机信息、访问联系人信息等 
  -增风险项 ,获取应用内不需要的权限,尤其是Andorid 版本,这一块可以在设置中查看该应用获取了那些权限, 安装页面一般也会提示该应用需要获取的权限 
  2)开发者官方权限列表信息比对分析 (尤其是ios的审核,一定要检查),而且在使用应用过程中,ios 都会提示用户应用要获取系统权限,这个在测试的过程中需要注意。

三、 需求文档或产品说明书中 内容检查--app 功能的主体功能,这部分一般都是由测试用例来表现, 所以测试用例的编写就很重要了。

测试用例的定义:A test case is a document, which has a set of test data, preconditions, expected results and postconditions, developed for a particular test scenario in order to verify compliance against a specific requirement.

这个说的测试用例是描述一个输入,经过系统的操作产生一个结果的的指导文档。在实际的过程中,实际的这样的一个操作会有很多前提条件,就会导致一个在不同的页面都会存在这样的一个测试用例,导致了测试用例的重复。当然这里我就把测试用例定义为一个操作。 在不同的测试对象中,测试用例,具体指一个功能功能还是一个操作,还是一个场景,这个问题在这里就不多做阐述了。测试用例只是工具,工具如何用要看个人,只要达到目的就行。

测试用例编写这部分,本想就这次一起总结算了,一个小时,还是没一个具体的方向,还是觉得测试用例编写不简单,再重看之前写的测试用例,觉得写的稀烂,但是真上手重新写, 还是觉得差点啥, 所以下次写出一版比较满意的测试用例之后,再进行总结,补上这部分的吧!

时间: 2024-08-12 05:08:07

【转载】移动端的功能测试范畴的相关文章

转载 移动端前端开发调试

以下内容转载自:http://yujiangshui.com/multidevice-frontend-debug/ 本文更新说明:第一版是在 2014-06-16 编写的,现在来看,内容不够分明,思路不够清晰,方法不够完全.故再次更新.补充.修改,力求可以作为移动端前端开发测试的基本参考文档.后续还会随着技术的进步不断调整和修改. ———————————————————— 通过移动端使用 Web 服务的比率越来越大,例如淘宝今年双十一,移动端交易份额就达到 42.6%.由此可见,掌握移动端的前

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

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

海量用户-高并发SAAS产品测试上线流程

海量用户高并发SAAS产品测试上线流程 SAAS产品测试上线流程-以Web插件产品为例子 1   概述 在互联网产品中,IT公司之间更加注重产品功能之间的协作,SAAS形态的产品扮演着越来越重要的作用. 一个典型的完全由宿主代理的SAAS服务的通讯流程如下图: 这样的产品一般具有如下特点: 一般由第三方提供专门的服务 通常以网络为媒介来提供服务 具备嵌入的客户端功能 具备第三方服务端功能 一般不以独立的产品形式直接面向客户 一般需要集成“寄生”在宿主产品中来面向客户 SAAS形态的主要产品有:

关于大型网站技术演进的思考(十九)--网站静态化处理—web前端优化—上(11)

网站静态化处理这个系列马上就要结束了,今天我要讲讲本系列最后一个重要的主题web前端优化.在开始谈论本主题之前,我想问大家一个问题,网站静态化处理技术到底是应该归属于web服务端的技术范畴还是应该归属于web前端的技术范畴,要回答清楚这个问题我们要明确下网站应用的本质到底是什么?网站的本质其实就是BS,这里的BS我没有带上架构二字,而就是指Browser和Server即浏览器和服务器,而网站静态化技术的作用目标就是让客户端即浏览器的用户体验更好,但是如果我们想让网站在浏览器上运行的更快,在更快的

OpenStack Summit Paris 会议纪要 - 11-06-2014

Ops/Design Summit - 2014-11-06 Record 1. Neutron Kilo Lighting Talks 1. MPLS VPN (1)Brocade提出的一个数据中心互联方案 (2)单个租户网络可以扩展到多区域的数据中心 (3)无缝迁移VM的负载 (4)提出一个MPLS VPN Service的API Ext和对应的Model: Attachment Circuit:租户网络内部的一个逻辑接口 MPLS LSP Tunnels:在多个MPLS VPN服务间共享

APP自动化框架LazyAndroid使用手册(1)--框架简介

作者:cryanimal  QQ:164166060 APP自动化简介 APP自动化,即通过自动化的方式,对APP施行一系列的仿按键输入.触摸屏输入.手势输入等操作,以达到对APP的功能进行自动化测试的目的. 其一般过程如下图所示: APP自动化常用工具简介 Monkey Monkey 是Android SDK 自带的自动化测试工具,可以运行在模拟器里或实际设备中,它向系统发送随机的用户事件流,如按键输入.触摸屏输入.手势输入.Sensor 事件等, 实现对正在开发的应用程序进行表现或者压力测试

如何提升工作效率?

请你告诉我,我该走哪条路?”爱丽丝说. “那要看你想去哪里?”猫说. “去哪儿无所谓.”爱丽丝说. “那么走哪条路也就无所谓了.”猫说. 引入一个经典的例子,是想告诉大家也是小编自勉,工作首先需要有目标,如果自己都不知道干什么,别人是无法帮助你的.在工作中,如果没有目标,往往是被动的完成一些工作上的事情,可能存在的问题是,工作2~3年,依旧是原地踏步.有了目标也就有了工作道路上的灯塔,知道了该选择哪条路了,即使道路崎岖和遇阻,也不会轻言放弃,因为在灯塔的指引下,有了向前冲的激情和动力. 如何制定

浅谈单片机、ARM和DSP的异同

犹记得当年读书的时候,老师说单片机.ARM.DSP有互通之处,都是CPU,但听老师讲都听不懂. 我该如何理解他们,并找出他们的异同呢?我们来看看行内人的看法: ICer,从事ARM CPU的SOC设计 按我的理解说几句吧,希望能说薄一点. 首先,说CPU,中央处理器,本质就是一个集成电路,实现的功能就是从一个地方(如rom)读出一个指令,从一个地方(如ram)读出数据,然后根据指令的不同对数据做不同的处理(如相加),然后把结果存回某个地方(如ram).不同架构的cpu会有不同的指令,不同的存取方

重读《从菜鸟到测试架构师》-- 对黑盒子的全方位照明

上回说到,小艾学会了分而治之的方式来将模块细化做功能测试,这样的好处是更容易找到bug,但尽管容易找bug,并不表示bug就能完全被找到,而不被交付到客户手里.也出于对客户发现的bug进行分析,组长告诉小艾,不仅仅需要分而治之,也需要合而治之. 上一章我们也提到一个名词:跨模块/解决方案的功能测试,即功能集成测试,其实这就是为了确保所有的功能特征,或者User Story在一个产品或应用的开发过程中能够被彻底测试,而对产品的各个模块或者解决方案,按照用户的使用方式,根据模块/解决方案间的逻辑关系