手机软件测试经验总结

手机软件测试总结

沙晶晶

一个合格的手机软件测试工程师要掌握的东西是很多很多的。在我个人理解中,一个合格的高级手机软件测试工程师应该具有最基本的两点知识:软件测试理论知识和一定的开发技能。

1. 软件测试理论知识

这个不用多说,软件测试工程师必须要掌握的,软件测试如何融入整个开发的流程,什么时候介入,什么时候结束,如何搭建测试环境,如何设计测试用例 (包括设计测试用例的方法,如:等价类划分,边界值法等),如何使用测试工具,还有测试领域专用的一些术语等等。

2. 开发技能

合格的高级软件测试工程师,编程技能不可缺少。在手机测试中,比如自动化测试,完全可以开发工具来实现自动化测试。所以掌握一门扎实的编程语言,C或者C++还是非常重要的,能够自己开发测试工具,也是一个高级手机软件测试工程师应该具备的素质。我认为我们不应该只是单纯的发现bug,而应该从更深层次的去探究这个 bug的原因,甚至可以定位bug。

另外从技能上讲,面向不同的技术方向,像操作系统、网络、通信等都要从专业上深入了解。这些是除去工作时间外必须去加强充电的部分。有这些做后盾,做起事来也会事半功倍。

另外手机测试中应该注意的问题

首先是正确性测试,正确性测试又可称为功能性测试,我们首先就是要测试所有功能是否都已实现、正确、是否满足需求规格说明。

正确性测试还要考虑到用户界面,软件产品始终是关注软件使用者——客户的体验,手机屏幕小,界面有限,所以手机软件的用户界面更需有一定的规范和标准:正确性、一致性、直观性、实用性、灵活性、舒适性便是最基本的标准。

正确性一般比较明显,比较容易发现,例如某个窗口没有被完全显示,文字没有对齐,文字拼写错误,密码输入时没有以*的形式自动屏蔽等。

一致性包括软件自身的一致性以及手机操作系统或与其它软件的一致性,具体表现在使用的术语,字体是否一致,界面的各参数风格是否前后一致等。特别也要注意中英

文版本下界面风格是否一致,是否有中英文混合的情况。

直观性要求软件功能特性易懂、清晰,用户界面布局合理,对操作的响应是否在用户的预期中,如用户做了非法操作后,界面是否有错误的提示信息,提示信息是否完整,是否明确,是否能让用户立即明白问题所在。

实用性不是指软件本身是否实用,而仅仅是指具体的某个特性是否实用,是否有助于用户执行该软件的功能,手机软件是安装在手机上的第三方软件,手机不同于PC机,功能没有PC机强大,在手机上实现的功能也不同于在PC机上的功能,所以功能不应复杂,无用的功能只会增加程序的复杂度,产生不必要的软件缺陷。但是个人觉得有些必要的功能还是一定要有的,如:随时可以退出应用程序这个功能还是很必要的,用户进入多层之后,若想退出应用程序,但是又要一层一层返回到最上一层才能退出时,也是一件很烦很头疼的事。

灵活性,按我个人现在的理解,具体表现在,如果多种状态之间的切换,例如界面的不停切换,操作步骤的复杂,增加了编程的难度,可能也会降低软件的可靠性,这时软件的灵活性将会大打折扣。特别是在我们测试触屏手机的时候,界面的切换经常会导致一些界面卡住,乱码,黑屏,死机的情况,所以我们在测带有触屏手机时,一定要注意到灵活性。

舒适性主要强调界面美观,色彩运用恰当,按钮的立体感以及增加动感动画等。例如颜色的搭配,有些背景色跟文字或图片的颜色搭配在模拟器可以较清晰的显示出来,但是到了手机由于其分辨率问题就不那么明显了。颜色搭配要以清晰美观为基础,还要适当考虑用户心理等问题。

除了测试软件的正确功能,及其更需要考虑一些异常的情况,异常的情况也分多种考虑,如下:

1、容错性测试

容错性测试是一种对抗性的测试过程。在这种测试中,把应用程序或系统置于异常条件下,例如输入特殊字符或异常字符,具体可以通过输入超过边界值的字符(这也相当于用例设计方法中的边界值分析法)看后台有没有相应的容错处理。手机客户端界面会给出什么样的提示信息。另外还要测试多个客户端同时发出请求,测试后台的多线程处理能力,看能同时处理多少用户的同时请求,平均响应时间是多少,是否在可接受范围内。

2、测试应用程序中的一个功能正在执行过程中,同时另外一个事件或操作对该过

程进行干扰。

例如:运用程序运行时,切换程序到外部,做一些与运用程序相关的操作,再切换到应用程序中,查看刚刚的操作是否对正在执行的运用程序有影响。另外来电,短信,电量不足等一些事件警告的出现也有可能导致程序出错,也要作出相应的处理。有些网络程序由于设置了数据通讯时不处理来电,这时候最好能在低电量情况下测试,看是否做了恰当的处理。我们需要测试一下这些干扰的冲突事件会不会导致应用程序core,手机死机、花屏等严重的问题出现。

3、我们一定要考虑到对手机存储空间满后的压力测试。

手机的内存空间资源是有限,不像PC机有着巨大的存储空间,我们很容易做到手机存储空间已满,所以我们一定要考虑剩余空间不足或存储空间为零的情况下,应用软件的运行是否正常?我们要在手机没有存储空间或达到最大的承载极限时,对手机软件可编辑修改的模块进行编辑修改,保存之后,并对手机软件进行任何操作测试,如果程序员不做相应的处理或者处理不好的话,很容易造成配置文件读写错误或无法写入,从而导致手机软件系统出现core掉或者手机出现死机、无法退出的情况。虽然手机本身在磁盘空间已满的情况下也会出现不少问题,我们的应用程序也无法避免,但是我们一定要确保我们的程序不会出现core,程序无法退出,手机死机等这些严重情况出现。

4、极限发散性测试

我个人经常喜欢说成是暴力测试或压力测试,我的做法是通过各种操作步骤或途径、异常或非法执行,站在不正常的用户角度,如快速按按钮或快速划屏、对某个功能做大量的重复性的操作等(如在登录过程中,不停的做登录和取消操作,不停地按几十下几百下),不把程序搞崩溃誓不罢休的暴力发散性测试,往往开发会狡辩与理论这是不正常的变态的测试,如果用户做此操作出现了问题由用户自己负责,确实世界上没有十全十美的东西,任何东西都会有瑕疵,软件也不例外,不可能做到零缺陷,我们不求做到最好,我们只求做到更好,试想用户的操作是多种多样的,谁能确保用户不会做到那些异常的非法的操作,我们不仅要确保正常功能实现的准确无误,一定还要做到异常非法的功能也要处理的准确无误,那样才能降低软件的缺陷率。通过我多次实践,发现不少严重致命的bug往往是由此操作导致,个人认为这与开发人员在异常情况下考虑不充分有一定的关系。

5、边界值测试

程序员会容易漏掉对边界值的处理,通过我多个版本的测试经历发现,每个版本都

会出现这种边界值数组越界导致程序core掉的致命bug,曾经测试过手机界面显示N个缩略图片的功能,显示几百张图片功能无误,但是超过某个数字即几千张之后,应用程序会立即出现一些致命的错误;同时在删除列表界面的第一个或者末尾一个图片时,也出现了严重问题。所以我们不仅仅只考虑到能编辑的文本框下边界值的测试,还要考虑到其他一切尽可能输入的情况。

6、性能测试

我们不仅要测试软件功能的正确性,还要测试软件的性能,软件的运行速度,是否有延时,软件的运行时间,长期的运行是否会增加对存储空间的额外占用情况等。在软件运行时,要懂得不定时的查看资源的利用率,查看cpu的占用情况,内存泄露会造成程序随机的莫名其妙core、卡屏、手机死机的情况,而往往由内存泄露导致的问题,重启手机之后,问题不容易重现,并且再次内存泄露时,出现的现象也会不同,对我们测试重现问题来说是一个比较头疼的事,所以不定时的查看内存情况,查看内存是否泄露,出现的不易重现的严重问题是否与内存泄露有关,其实也是一种定位问题的方法。

7、数据请求或传输等需时较多的过程要确保有提示界面,最好有动画显示数据在传输过程中,请用户耐心等待。另外要注意在这个过程中对重复按键予以忽略,因为等待时间过长或响应迟钝时,用户趋向于重复按手机按钮。曾经测试过删除某个文件,文件比较大,删除很慢,界面没有任何反应,无法判断是否在删除文件,迫不及待的重新乱按手机其他键,导致系统出现错误。

 

第二篇:手机软件测试的经验总结

手机软件测试的经验总结

1.在提交高通前务必要检查文档与实际程序的功能表现是否相同,比如说,游戏增加了密

技功能,在文档中就要有相应的说明。

2.在模拟器上图像处理速度较快,所以不会出现游戏中移动的图像变模糊的现象,但是由于手机的分辨率相对低,所以一般在模拟器显示正常的速度,到了手机就应该让开发

人员适当调慢,否则将会出现移动物体变模糊不能清晰辨认的情况。

3.有些游戏使用了很多的图片资源,当在两个界面之间(例如在主菜单界面和帮助界面之间,主界面菜单是由许多图片组成的,帮助界面是一个html文件的浏览显示),连续按若干次使其在两个界面之间连续切换,会出现图像重叠现象,其原因是手机的CPU处理速度跟不上刷新速度,而且主界面的图片资源一直没有释放,导致图像的残留。一般可模

拟Grinder把这些类似的问题测出来。

4.是否正确处理来电。如果没有适当正确的来电处理,有些来电会使游戏画面变乱,有些直接退出,甚至死机。Brew程序员往往会在来电处理后的恢复中忘了对游戏音乐的处理,比如说原先选择了关闭音乐的,来电处理后音乐又自动开始播放了。有时候需要模拟两个或以上的连续的来电以发掘程序深层的逻辑错误,这些错误大多是来电处理后的恢复过程的错误。另外短信,电量不足等一些事件警告的出现也有可能导致程序出错,也要作

出相应的处理。

5.注意确保游戏说明和帮助的完整清晰,检查系统提示信息,确保在游戏中出现的文

字的正确拼写,没有错别字。要尽量用敬称“您”而不用“你”。

6.标题,菜单等的文字显示要尽量用小字体,尽量缩短文字,能用简短文字说明清楚的就不要用长句,例如“按2,4键可以左右移动图片”就可改成“按2,4键左右移动图片”,或者甚至改成“按2,4键移动图片”。因为不同的手机显示屏幕宽度不一样,在一款手机上显示正确不代表在其他款式都能正确显示,然而用小字体,短句子就能适应大多

数手机的屏幕宽度。

7.线程的处理,有些游戏设有多个线程,如果没有处理好线程的调用释放问题的话,就很可能出现线程争用的问题。例如一个宠物游戏,宠物死亡后,会调用一个新的线程循环播放哀吊音乐,有些程序员由于粗心大意忘记了释放这个线程,当重新开始游戏时,就

会出现这个线程播放的音乐与游戏过程的背景音乐交替播放的情况。

8.文件处理。当涉及文件读写操作的时候,要特别注意测试文件操作带来的内存问题。比如说,有些游戏需要用文件记录游戏最高分或分值等,要注意测试第一次运行程序时的退出操作(此时没有最高分记录或其他分值记录),程序是否申请了文件指针或文件资源而没有释放。如果是的话,则会导致退出时的内存错误。另外对于Brew,应用程序的文件包中不得包含零字节的文件,每个文件至少有一个字节,同时还要求不能包含无用的文件

或文件夹,目的是节省手机上有限的存储资源。

9.颜色的搭配,有些背景色跟文字或图片的颜色搭配在模拟器可以较清晰的显示出来,但是到了手机由于其分辨率问题就不那么明显了。颜色搭配要以清晰美观为基础,还要适

当考虑游戏的种类,用户心理等问题。

10.用模拟器模拟网络不通的情况。目的是测试软件的网络连接,网络资源请求,缓冲区存储等模块的性能,看看内存是否有正确释放等。可以通过断开网络连接的方法模拟手机网络不通的情况,具体就是把本地连接的状态设成禁用或者直接拔掉网络连接线。

11.数据请求或传输等需时较多的过程要确保有提示界面,最好有动画显示数据在传输过程中,请用户耐心等待。另外要注意在这个过程中对重复按键予以忽略,因为等待时间

过长或响应迟钝时,用户趋向于重复按手机按钮。

12.不要忽略了对后台数据正确性的测试。输入特殊字符或异常字符,看后台有没有相应的容错处理(当然这些也可由手机端处理)。多个客户端同时发出请求,测试后台的多线程处理能力,看能同时处理多少用户的同时请求,平均响应时间是多少,是否在可接受

范围内。

13.来电,短信,电量不足等一些事件警告的出现也有可能导致程序出错,也要作出相应的处理。有些网络程序由于设置了数据通讯时不处理来电,这时候就要在低电量情况下测试,用电量不足的警告事件来触发程序的suspend和resume处理事件,看是否做了恰当

的处理。

以上经验同样适合开发人员参考,以便尽量避免类似问题的出现。

 

第三篇:软件测试经验总结

软件生命周期(SDLC)的六个阶段

1、问题的定义及规划

此阶段是软件开发方与需求方共同讨论,主要确定软件的开发目标及其可行性。

2、需求分析

在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段,这一阶段做得好,将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。",同样需求也是在整个软件开发过程中不断变化和深入的,因此我们必须制定需求变更计划来应付这种变化,以保护整个项目的顺利进行。

3、软件设计

此阶段主要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计,数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。

4、程序编码

此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一,符合标准的编写规范。以保证程序的可读性,易维护性,提高程序的运行效率。

5、软件测试

在软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随意性。

6、运行维护

软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的要求。要延续软件的使用寿命,就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

2、软件生命周期模型

从概念提出的那一刻开始,软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后,软件将被使用并进入维护阶段,直到最后由于缺少维护费用而逐渐消亡。这样的一个过程,称为"生命周期模型"(Life Cycle Model)。

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。

瀑布模型的特点(文档是主体),很多的问题在最后才会暴露出来。迭代模型比瀑布模型问题暴露的要早;快速原型法比瀑布模型直观。

3.软件测试概念

广义概念:指软件生存周期中所有的检查、评审和确认工作,其中包括了对分析、设计阶段,以及完成开发后维护阶段的各类文档、代码的审查和确认

狭义概念:识别软件缺陷的过程,即实际结果与预期结果的不一致

4.软件测试目的

测试的目的就是发现软件中的各种缺陷

测试只能证明软件存在缺陷,不能证明软件不存在缺陷

测试可以使软件中缺陷降低到一定程度,而不是彻底消灭

以较少的用例、时间和人力找出软件中的各种错误和缺陷,以确保软件的质量

5.软件测试原则

Good-enough: 一种权衡投入/产出比的原则

保证测试的覆盖程度,但穷举测试是不可能的

所有的测试都应追溯到用户需求

越早测试越好,测试过程与开发过程应是相结合的

测试的规模由小而大,从单元测试到系统测试

为了尽可能地发现错误,应该由独立的第三方来测试

不能为了便于测试擅自修改程序

既应该测试软件该做什么也应该测试软件不该做什么

6.软件测试的的重点

测试用例的设计

测试用例的设计是整个软件测试工作的核心

测试用例反映对被测对象的质量要求,决定对测试对象的质量评估

测试工作的管理

尤其是对包含多个子系统的大型软件系统,其测试工作涉及大量人力和物力,有效的测试工作管理是保证有效测试工作的必要前提

测试环境的建立

测试环境应该与实际测试环境一致

7.黑盒测试

什么是黑盒测试

又称功能测试或数据驱动测试,是针对软件的功能需求/实现进行测试,通过测试来检测每个功能是否符合需求,不考虑程序内部的逻辑结构

黑盒测试方法

功能划分

等价类划分

边界值分析

因果图

错误推测等

8.什么是白盒测试

白盒测试也称结构测试或逻辑驱动测试,必须知道软件内部工作过程,通过测试来检测软件内部是否按照需求、设计正常运行

白盒测试的主要方法

对应于程序的一些主要结构:语句、分支、逻辑路径、变量;白盒测试的主要方法是: 语句覆盖方法

分支覆盖方法

逻辑覆盖方法

什么是动态测试

动态测试需要在开发/测试环境或实际运行环境中运行软件,并使用测试用例去查找软件缺陷;动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等

10.什么是静态测试

静态测试不实际运行软件,主要是对软件的编程格式、结构等方面进行评估.静态测试包括代码检查、程序结构分析、代码质量度量等。它可以由人工进行,也可以借助软件工具自动进行

11.手工测试和自动测试

a.手工测试缺点在于测试工作量大,重复多,回归测试难以实现

b.自动测试利用软件测试工具自动实现全部或部分测试工作:管理、设计、执行和报告;节省大量的测试开销,并能够完成一些手工测试无法实现的测试

手工完成测试的全部过程无法保证测试的科学性与严密性:

修改的缺陷越多,回归测试越困难

没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率

反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一

测试花费的时间越长,测试的严格性也就越低

自动测试将测试人员从反复、烦杂的测试执行中解放出来,用更多的时间进行测试设计和结果分析

软件测试不可能完全自动化

不能完成所有手工测试任务

无创造性且灵活性差,不能改进测试的有效性

过程中可能会遇到许多意想不到的问题,特别是当软件不稳定时

测试脚本的维护高

12. 测试流程

单元测试

集成测试

系统测试

用户验收测试

回归测试

确认测试报告

13.单元测试

完成对最小的软件设计单元—模块的验证工作

目标是确保模块被正确地编码

使用过程设计描述作为指南,对重要的控制路径进行测试以发现模块内的错误

通常情况下是面向白盒的

对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试,及早地发现和解决不易显现的错误

单元测试的内容

接口测试

内部数据结构

全局数据结构

边界

语句覆盖,错误路径

14.集成测试

通过测试发现与模块接口有关的问题

目标是把通过了单元测试的模块拿来,构造一个在设计中所描述的程序结构

应当避免一次性的集成(除非软件规模很小),而采用增量集成

集成测试主要内容

API (Application Programming Interface,应用程序编程接口)

API/参数组合

15.系统测试

根据软件需求规范的要求进行系统测试,确认系统满足需求的要求

系统测试人员相当于用户代言人

在需求分析阶段要确定软件的可测性,保证有效完成系统测试工作

系统测试主要内容

所有功能需求得到满足

所有性能需求得到满足

其他需求(例如安全性、容错性、兼容性等)得到满足

16.用户验收/确认测试

Alpha测试

是由用户在开发者的场所来进行的,Alpha测试是在一个受控的环境中进行的

Beta测试

由软件的最终用户在一个或多个用户场所来进行的,开发者通常不在现场,用户记录测试中遇到的问题并报告给开发者

17.压力测试VS性能测试

性能测试的目的不是去找bugs,而是排除系统的瓶颈,以及为以后的回归测试建立一个基准。而性能测试的操作,实际上就是一个非常小心受控的测量分析过程。在理想的情况下,

被测软件在这个时候已经是足够稳定了

性能测试是为了检查系统的反映,运行速度等性能指标,他的前提是要求在一定负载下,如检查一个网站在100人同时在线的情况下的性能指标,每个用户是否都还可以正常的完成操作等。

概括就是:在不同负载下(负载一定)时,通过一些系统参数(如反应时间等)检查系统的运行情况;

压力测试是为了发现系统能支持的最大负载,他的前提是要求系统性能处在可以接受的范围内,比如经常规定的叶面3秒钟内响应;概括就是:在性能可以接受的前提下,测试系统可以支持的最大负载。

举例说明:针对一个网站进行测试,模拟10到50个用户就是在进行常规性能测试,用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作,就包含了强度测试。

18. 主流测试工具的测试流程

========winrunner

1 启动时选择要加载的插件

2 进行一些设置(如录制模式等)

3 识别应用程序的GUI,即创建map(就是学习被测试软件的界面)

4 建立测试脚本(录制及编写)

5 对脚本除错及调试(保证能够运行完)

6 插入各种检查点(图片,文字,控件等)

7 在新版应用程序中执行测试脚本

8 分析结果,回报缺陷

=========quicktestpro========

1 准备录制

打开你要对其进行测试的应用程序,并检查QuickTest中的各项设置是否适合当前的要求。 2 进行录制

打开QuickTest的录制功能,按测试用例中的描述,操作被测试应用程序。

3 编辑测试脚本

通过加入检测点、参数化测试,以及添加分支、循环等控制语句,来增强测试脚本的功能,使将来的回归测试真正能够自动化。

4 调试脚本

调试脚本,检查脚本是否存在错误。

5 在回归测试中运行测试

在对应用程序的回归测试中,通过QuickTest回放对应用程序的操作,检验软件正确性,实现测试的自动化进行。

6 分析结果,报告问题

查看QuickTest记录的运行结果,记录问题,报告测试结果。

====TestDirect============

安装好后,先进入站点管理

1 创建域及工程

2 添加用户

3 编辑licenses及本服务器

4 编辑数据库

--TD

1 选择新建的工程进行定制(列表,用户,组,版本等)

2 在require中增加需求

3 把需求转化为plan

4 在testlab中由计划新建测试具体用例与执行

5 发现bug,在defect中提交bug

(每一部分都可以相对独立地使用)

======loadrunner

1 制定负载测试计划

(分析应用程序, 确定测试目标,计划怎样执行LoadRunner)

2 开发测试脚本

(录制基本的用户脚本,完善测试脚本)

3 创建运行场景

(选择场景类型为Manual Scenario,选择场景类型,理解各种类型,场景的类型转化) 监视场景

5 (MEMORY 相关,PROCESSOR相关,网络吞量以及带宽,磁盘相关,WEB应用程

序 ,IIS5.0,SQL SERVER,NETWORK DELAY等)

6 6 分析测试结果

7 (分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其他有

用的功能)

相关推荐