手机app测试注意点

昨天刚写了一遍我的测试之路,现在我把我在半年app测试过程中遇到的问题和之前把到前辈的一篇文章,做个总结:

我司产品“彩礼多”,已经在iOS、android等多个平台的移动客户端,这两个端也已经相继开发了几个版本,最近开发的2.8版本即将上线,测试了这么久也该总结一下了。

现在我们测试时,开发会先在本地机上打好测试包,自己安装,轮完一轮,开发修改好后,再打一个包。以下是功能测试时需要注意的点:

1、登录

●登录用户名和密码错误时,界面有提示信息

●用户主动退出登录后,下次启动APP时,应该进入登录界面

●对于支持自动登录的APP,数据交换时 ,是否能自动登录成功且数据库操作无误 ●密码更改后,登录时是否做到了有效数据的校验

●对于未登录时一些页面的操作,是否做了控制

●切换账号登录,检验登录的信息是否做到及时更新

●对于多个端都进行操作时,确保数据库操作无误,且每个端可以及时看到数据的更新 ●对于一些软件,支持一个账号只允许登录一台机器,这时,需要检查账号登录多个手机时,是否将原用户剔除,且能够给出提示信息

● APP切换到后台时,再次切换到前台的测试,如登录时,有电话打进来

2、离线

离线是应用程序在本地的客户端会缓存一部分数据以功程序下次调用

●对于一些程序,需要在登录进来后,这时没有网络的情况下可以浏览本地数据

●对于无网络时,刷新获取新数据时,不能获取数据且能给出友好提示

●切换到后台,再次切换到前台时,可以正常查看

●离线后又连上网,这时对数据有更新时,需要从服务器端获取新数据来更新客户端数据,且要更新本地缓存信息

●对于一些界面的数据不提供离线查看,需要给出相应提示且界面更新后无任何数据

3、Sqlite数据库

android和IOS客户端都采用了sqlite数据库,

当APP需要在客户端保存数据时,它们会创建相应的数据库表,最常见的就是对账号的保存,这时的测试点主要有:

●跟一般数据库一样,需要见擦数据的增,删,改,查

●客户端即用即建,当表不存在时,是否会自动创建

●数据表被删除后,新建的表中的数据能否自动从服务器端中获取回来兵保存

●当对数据进行了修改,删除,客户端和服务器端能否有相应的更新

●获取数据,客户端是从直接从客户端获取还是和服务器端的数据进行比较

●对于客户端从服务器端更新的数据,客户端是否有保存于本地。

个人提的bug注意点:

●因为ios系统有不断的更新,所以会出现这样那样兼容性的问题,其实我们软件中有一点,我记得很清楚,就是在送人彩票环节,赠送成功后会弹出一个温馨提示(问用户是,否要提醒用户领取),用户一旦点了【好的】,会跳到一个短信提醒框,此时就会出错,在苹果5上都没事,一旦在4s上运行就有可能付出闪退。

●如果是同一个用户,那么她在android,ios上登录后,记录应该都是一样的。

●一款手机软件在android系统上测试要特别注意,android手机款式多,内存,分辨率不一,所以测试难过也比较大。我们的软件有一个问题一直走不去,就是在小手机上,如果应用开多,占内存大了,就会出现闪退。

●有新的版本要上线前,一定要测旧的版本,不能因为新版本上线了,老版本就不能用了,用老版本的用户还是大有人在。有一次,我用新版本注册的用户去玩老版本,结果就有有错过,当然这样玩的人很少。

●如果一页面里有很多条记录里,要注意上下多滑动,我在测试过程中,好几次在上下滑动中又由于数据出现错误,导致闪退,尤其是android.

●到了某个页面,突然断网了,然后你在不知情的情况下,点击某个按钮想继续往下走,此时,不能出现闪退的情况,而要给出断网提示。

●文本框校验时采用等价类划分法,边界值法,错误推测法与场景法,至少这些方法的概念,自己网上去搜。

●很多手机app在打开后,一般用户都不需要先注册登录,到了合适的地方,弹出合适的提示,很好友的让用户去登录。当然有些页面,而且有时没有判断,未登录去点一些按钮,有可能会闪退。未登录与登录显示的页面是完全不一样的,要仔细测。

●用户登录状态太久,sessionId会过期,会出现“虽然是登录状态,系统会提示用户没有登录。” ●外部软件需要更新导致自家软件闪退。我公司是一款博彩类软件,用户需要通过支付宝或财付通支付,有一次在用支付快捷支付时,提示我支付快捷支付需要更新,我就点了更新,更新完成后,我们的软件就异常退出了。

●输入数据,点某颗按钮,会出现错误提示,有时不管这个提示,继续猛点这个按钮,会出现出人意外的结果哦。

●上线前一定要测一下软件更新,我好几次这里没测,结果挨了批。这真是叫做“晚节不保”。所有功能都测了n遍了,大胆放心的上了,可是没有在测试环境测软件的更新。结果上线后,用户更新了就出大问题了,大大影响用户量。唉,都是累阿。

 

第二篇:手机app测试

对于产品的手机项目(应用软件),主要是进行系统测试。而针对手机应用软件的系统测试,我们通常从如下几个角度开展:功能模块测试,交叉事件测试,压力测试,容量测试,兼容性测试,易用性/用户体验测试等。

1、功能模块测试:首先应分析功能模块的功能项,测试每个功能项是否能够实现对应的功能。一般根据测试用例(Test Case)或软件本身的流程就可以完成基本功能测试(相对简单,故障也较容易发现、解决)。

2、交叉事件测试:又叫事件或冲突测试,是指一个功能正在执行过程中,同时另外一个事件或操作对该过程进行干扰的测试。例如通话过程中接收到短信或闹铃触发,应用软件运行过程中插拔充电器等。执行干扰的冲突事件不能导致应用软件异常、手机死机或花屏等严重问题。另外,还需要注意各交叉事件的优先级别,检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级较低的事件吊死。

交叉事件测试非常重要,一般能发现应用软件中一些潜在的问题。另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题(这个主要针对手机应用软件支持语言自适应功能),这一点通常会被测试人员忽略。

3、压力测试:又叫边界值容错测试或极限负载测试。即测试过程中,已经达到某一软件功能的最大容量、边界值或最大的承载极限,仍然对其进行相关操作。例如连续进行短信的接收和发送,超过收件箱和SIM卡所能存储的最大条数,仍然进行短消息的接收或发送,以此来检测软件在超常态条件下的表现,进而评估用户能否接受。

对手机可以施加的压力测试类型主要有:

? 存储压力:由于手机采用的是栈式存储,所以当一个存储块满了之后,如果程序员不做相应处理或者处理不好的话,很容易造成其他存储区被擦除,从而在UI上出现问题(比如其他功能无法正常使用,出现异常)。

? 边界压力:边界处理一直是程序员最容易忽略的地方。

? 响应能力压力:有时候某个操作可能处理的时间很长,在处理期间如果测试者再不断地进行其他操作的话,很容易出现问题。

? 网络流量压力:执行较大数据流量的功能的同时,再进行其他功能操作,使得网络流量始终处于很高的状态(如视频通话时再进行短信等其他功能操作),验证各功能是否依然能正常工作,是否存在因网络流量瓶颈而引起某功能异常。

压力测试用手工测试可能很繁锁,可以考虑自动化测试。遗憾的是,目前还没有较为大量使用的工具,一般都是由开发人员配合开发出的工具,或者高级的测试人员编写出的脚本。

5、容量测试:即存储空间已满时的测试,包括手机用户可用内存和SIM卡的所有空间被完全使用的测试。此时再对可编辑的模块进行和存储空间有关的任何操作测试,如果软件在极限容量状态下处理不好,有可能导致死机或严重的花屏等问题的出现。

6、兼容性测试:也就是不同品牌、款型的手机(针对目前我们产品来说,主要是针对不同品牌、款型的手机上的测试),不同网络,不同品牌和不同容量大小的SIM卡之间的互相兼容的测试。不同型号的手机支持的图片格式、声音格式、动画格式不一样,需要选择尽可能通用的格式,或者针对不同的型号进行配置选择。以短消息为例:中国电信的小灵通接收到从中国移动或中国联通GSM发来的短消息,需要验证显示和回复功能是否正常等。再比如,应用软件分别在Nokia N80、N93手机上运行,各功能是否均能正常使用,界面是否均显示正常等。

7、易用性/用户体验测试:易用性(Useability)/用户体验是指在指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力,是交互的适应性、功能性和有效性的集中体现。手机操作主要依赖拇指,所以交互过程中不能设计的

职场生存攻略 提高工作效率的8大必备软件 Photoshop word Excel Dreamweaver

太复杂,交互步骤不能太多,应该尽量设计多点快捷方式,易用是对终端软件(推而广之是交互类软件)最基本、最重要的要求。不好用的软件很难吸引用户,更别提提升用户对软件的忠诚度了。易用性体现在:所见即所得、一用便知、一学就会,方便快捷的完成预期功能。易用的软件能让一个新用户快速学习、使用我们的软件,并在使用软件过程中体现我们的贴心服务,超出用户预期的体现是我们追求的目标。

8、暴力测试:断电,重启,断网等意外情况发生时,处理是否正确

安全性测试

(1)安全性测试方法

有许多的测试手段可以进行安全性测试,目前主要安全测试方法有:

①静态的代码安全测试:主要通过对源代码进行安全扫描,根据程序中数据流、控制流、语义等信息与其特有软件安全规则库进行匹对,从中找出代码中潜在的安全漏洞。静态的源

代码安全测试是非常有用的方法,它可以在编码阶段找出所有可能存在安全风险的代码,这样开发人员可以在早期解决潜在的安全问题。而正因为如此,静态代码测试比较适用于早期的代码开发阶段,而不是测试阶段。

②动态的渗透测试:渗透测试也是常用的安全测试方法。是使用自动化工具或者人工的方法模拟黑客的输入,对应用系统进行攻击性测试,从中找出运行时刻所存在的安全漏洞。这种测试的特点就是真实有效,一般找出来的问题都是正确的,也是较为严重的。但渗透测试一个致命的缺点是模拟的测试数据只能到达有限的测试点,覆盖率很低。 ③程序数据扫描。一个有高安全性需求的软件,在运行过程中数据是不能遭到破坏的,否则就会导致缓冲区溢出类型的攻击。数据扫描的手段通常是进行内存测试,内存测试可以发现许多诸如缓冲区溢出之类的漏洞,而这类漏洞使用除此之外的测试手段都难以发现。例如,对软件运行时的内存信息进行扫描,看是否存在一些导致隐患的信息,当然这需要专门的工具来进行验证,手工做是比较困难的。 (2)反向安全性测试过程

大部分软件的安全测试都是依据缺陷空间反向设计原则来进行的,即事先检查哪些地方可能存在安全隐患,然后针对这些可能的隐患进行测试。因此,反向测试过程是从缺陷空间出发,建立缺陷威胁模型,通过威胁模型来寻找入侵点,对入侵点进行已知漏洞的扫描测试。好处是可以对已知的缺陷进行分析,避免软件里存在已知类型的缺陷,但是对未知的攻击手段和方法通常会无能为力。

①建立缺陷威胁模型。建立缺陷威胁模型主要是从已知的安全漏洞入手,检查软件中是否存在已知的漏洞。建立威胁模型时,需要先确定软件牵涉到哪些专业领域,再根据各个专业领域所遇到的攻击手段来进行建模。

②寻找和扫描入侵点。检查威胁模型里的哪些缺陷可能在本软件中发生,再将可能发生的威胁纳入入侵点矩阵进行管理。如果有成熟的漏洞扫描工具,那么直接使用漏洞扫描工具进行扫描,然后将发现的可疑问题纳入入侵点矩阵进行管理。

③入侵矩阵的验证测试。创建好入侵矩阵后,就可以针对入侵矩阵的具体条目设计对应的测试用例,然后进行测试验证。

(3)正向安全性测试过程

为了规避反向设计原则所带来的测试不完备性,需要一种正向的测试方法来对软件进行比较完备的测试,使测试过的软件能够预防未知的攻击手段和方法。

①先标识测试空间。对测试空间的所有的可变数据进行标识,由于进行安全性测试的代价高昂,其中要重点对外部输入层进行标识。例如,需求分析、概要设计、详细设计、编码这

几个阶段都要对测试空间进行标识,并建立测试空间跟踪矩阵。

②精确定义设计空间。重点审查需求中对设计空间是否有明确定义,和需求牵涉到的数据是否都标识出了它的合法取值范围。在这个步骤中,最需要注意的是精确二字,要严格按照安全性原则来对设计空间做精确的定义。

③标识安全隐患。根据找出的测试空间和设计空间以及它们之间的转换规则,标识出哪些测试空间和哪些转换规则可能存在安全隐患。例如,测试空间愈复杂,即测试空间划分越复杂或可变数据组合关系越多也越不安全。还有转换规则愈复杂,则出问题的可能性也愈大,这些都属于安全隐患。

④建立和验证入侵矩阵。安全隐患标识完成后,就可以根据标识出来的安全隐患建立入侵矩阵。列出潜在安全隐患,标识出存在潜在安全隐患的可变数据,和标识出安全隐患的等级。其中对于那些安全隐患等级高的可变数据,必须进行

详尽的测试用例设计。

(4)正向和反向测试的区别

正向测试过程是以测试空间为依据寻找缺陷和漏洞,反向测试过程则是以已知的缺陷空间为依据去寻找软件中是否会发生同样的缺陷和漏洞,两者各有其优缺点。反向测试过程主要的一个优点是成本较低,只要验证已知的可能发生的缺陷即可,但缺点是测试不完善,无法将测试空间覆盖完整,无法发现未知的攻击手段。正向测试过程的优点是测试比较充分,但工作量相对来说较大。因此,对安全性要求较低的软件,一般按反向测试过程来测试即可,对于安全性要求较高的软件,应以正向测试过程为主,反向测试过程为辅。 三、常见的软件安全性缺陷和漏洞

软件的安全有很多方面的内容,主要的安全问题是由软件本身的漏洞造成的,下面介绍常见的软件安全性缺陷和漏洞。

(1)缓冲区溢出

缓冲区溢出已成为软件安全的头号公敌,许多实际中的安全问题都与它有关。造成缓冲区

溢出问题通常有以下两种原因。①设计空间的转换规则的校验问题。即缺乏对可测数据的校验,导致非法数据没有在外部输入层被检查出来并丢弃。非法数据进入接口层和实现层后,由于它超出了接口层和实现层的对应测试空间或设计空间的范围,从而引起溢出。②局部测试空间和设计空间不足。当合法数据进入后,由于程序实现层内对应的测试空间或设计空间不足,导致程序处理时出现溢出。 (2)加密弱点

这几种加密弱点是不安全的:①使用不安全的加密算法。加密算法强度不够,一些加密算法甚至可以用穷举法破解。②加密数据时密码是由伪随机算法产生的,而产生伪随机数的方法存在缺陷,使密码很容易被破解。③身份验证算法存在缺陷。④客户机和服务器时钟未同步,给攻击者足够的时间来破解密码或修改数据。⑤未对加密数据进行签名,导致攻击者可以篡改数据。所以,对于加密进行测试时,必须针对这些可能存在的加密弱点进行测试。

(3)错误处理

一般情况下,错误处理都会返回一些信息给用户,返回的出错信息可能会被恶意用户利用来进行攻击,恶意用户能够通过分析返回的错误信息知道下一步要如何做才能使攻击成功。如果错误处理时调用了一些不该有的功能,那么错误处理的过程将被利用。错误处理属于异常空间内的处理问题,异常空间内的处理要尽量简单,使用这条原则来设计可以避免这个问题。但错误处理往往牵涉到易用性方面的问题,如果错误处理的提示信息过于简单,用户可能会一头雾水,不知道下一步该怎么操作。所以,在考虑错误处理的安全性的同时,需要和易用性一起进行权衡。 (4)权限过大

如果赋予过大的权限,就可能导致只有普通用户权限的恶意用户利用过大的权限做出危害安全的操作。例如没有对能操作的内容做出限制,就可能导致用户可以访问超出规定范围的其他资源。进行安全性测试时必须测试应用程序是否使用了过大的权限,重点要分析在各种情况下应该有的权限,然后检查实际中是否超出了给定的权限。权限过大问题本质上属于设计空间过大问题,所以在设计时要控制好设计空间,避免设计空间过大造成权限过大的问题。

四、做好安全性测试的建议

许多软件安全测试经验告诉我们,做好软件安全性测试的必要条件是:一是充分了解软件安全漏洞,二是评估安全风险,三是拥有高效的软件安全测试技术和工具。 (1)充分了解软件安全漏洞

评估一个软件系统的安全程度,需要从设计、实现和部署三个环节同时着手。我们先看一下Common Criteria是如何评估软件系统安全的。首先要确定软件产品对应的Protection Profile(PP)。一个PP定义了一类软件产品的安全特性模板。例如数据库的PP、防火墙的

PP等。然后,根据PP再提出具体的安全功能需求,如用户的身份认证实现。最后,确定安全对象以及是如何满足对应的安全功能需求的。因此,一个安全软件的三个环节,哪个出问题都不行。 (2)安全性测试的评估

当做完安全性测试后,软件是否能够达到预期的安全程度呢?这是安全性测试人员最关心的问题,因此需要建立对测试后的安全性评估机制。一般从以下两个方面进行评估。①安全性缺陷数据评估。

如果发现软件的安全性缺陷和漏洞越多,可能遗留的缺陷也越多。进行这类评估时,必须建立基线数据作为参照,

否则评估起来没有依据就无法得到正确的结论。②采用漏洞植入法来进行评估。漏洞植入法和可靠性测试里的故障插入测试是同一道理,只不过这里是在软件里插入一些有安全隐患的问题。采用漏洞植入法时,先让不参加安全测试的特定人员在软件中预先植入一定数量的漏洞,最后测试完后看有多少植入的漏洞被发现,以此来评估软件的安全性测试做得是否充分。

(3)采用安全测试技术和工具

可使用专业的具有特定功能的安全扫描软件来寻找潜在的漏洞,将已经发生的缺陷纳入缺陷库,然后通过自动化测试方法来使用自动化缺陷库进行轰炸测试。例如,使用一些能够模拟各种攻击的软件来进行测试。

安全测试是用来验证集成在软件内的保护机制是否能够在实际中保护系统免受非法的侵入。一句通俗的话说:软件系统的安全当然必须能够经受住正面的攻击——但是它也必须能够经受住侧面的和背后的攻击。