app测试报告范文.docx

上传人:b****6 文档编号:12877641 上传时间:2023-06-08 格式:DOCX 页数:11 大小:20.59KB
下载 相关 举报
app测试报告范文.docx_第1页
第1页 / 共11页
app测试报告范文.docx_第2页
第2页 / 共11页
app测试报告范文.docx_第3页
第3页 / 共11页
app测试报告范文.docx_第4页
第4页 / 共11页
app测试报告范文.docx_第5页
第5页 / 共11页
app测试报告范文.docx_第6页
第6页 / 共11页
app测试报告范文.docx_第7页
第7页 / 共11页
app测试报告范文.docx_第8页
第8页 / 共11页
app测试报告范文.docx_第9页
第9页 / 共11页
app测试报告范文.docx_第10页
第10页 / 共11页
app测试报告范文.docx_第11页
第11页 / 共11页
亲,该文档总共11页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

app测试报告范文.docx

《app测试报告范文.docx》由会员分享,可在线阅读,更多相关《app测试报告范文.docx(11页珍藏版)》请在冰点文库上搜索。

app测试报告范文.docx

app测试报告范文

app测试报告范文

app测试报告范文【1】

一、引言

手机软件的自动化测试一直困扰着手机软件测试从业人员,本文将最近的一些研究新发现及具体思路作详尽阐述,希望能给予大家更多的参考萌发新的思路。

通过长期的手工测试得出如下可以以自动化测试来解决的问题,

1.压力测试,一些连续不断的操作,比如反复切换歌曲播放及联网操作等,

2.极限临界测试,一些极限条件的构造,创建多个列表,及输入字符个数等,

3.兼容及中断,比如在播放或下载歌曲的时候来电话或者信息,

4.基本功能回归测试,这样大大的节约了时间和人力成本。

对于以上的测试很多也是可以通过手工来完成,但部分测试采用手工测试是不可靠的,比如最近发现一个Bug,在联网的一瞬间如果来一个信息等中断操作出现死机,,类似这种Bug出现条件非常苛刻和临界的情况在手工测试中是很难发现和构造这种测试环境的,即使发现了在很大程度上也属于一种偶然,同时给开发人员定位这个问题也带来了很大的困难。

面对诸多因素,我们不得不重视手机软件的自动化测试研究。

其实如果掌握了一些自动化测试要领,从简单入手,逐步实现和突破,相信一定能够解决手机软件自动化测试的难题。

二、自动化测试原理

1.TestAgent

TestAgent为嵌入在手机软件系统中的一个测试代理模块,解决PC端与手机端交互处理及互联消息通讯问题,这是区别于其他桌面软件自动化测试的关键点,也是嵌入式软件自动化测试的主要特征之一。

通过串口或蓝牙设备与PC端中的TestTool建立通讯,其具备的主要功能如下,

1)接收TestTool发送的消息并向手机端软件系统分发消息及任务

2)监控手机端软件运行情况并根据相应的约束反馈给PC端的TestTool

3)被测软件的功能,接口,封装及消息响应

2.TestTool

TestTool自动化测试工具在PC端用于测试控制及测试操作实体,与TestAgent对应,该工具与常规的自动化测试软件一样,其具备的主要功能如下,

1)向手机端TestAgent发送可识别的消息及任务

2)接收来自手机端TestAgent的反馈结果

3)对来自手机端TestAgent的反馈进行测试业务的处理

4)将测试业务的处理结果呈现给测试人员

三、测试业务

1.主动式测试

TestTool主动式测试是根据我们的测试需求比如,压力、性能、极限,在TestTool中编写测试脚本控制手机端软件进行测试,或者构造一些手工很难实现的测试场景,通过运行脚本向TestAgent发送消息及任务,TestAgent再向被测软件分发消息及任务,并将结果原路返回给TestTool,TestTool再通过数据处理分析得出测试结果。

关键点,发送和分发消息、接收及处理反馈结果,结果判断,。

2.回归式测试

基本功能的回归测试最为简单的方法就是录制和回放机制,通过运行录制的测试脚本达到按照先前的操作顺序、步骤、输入数据等再次测试被测软件以此达到回归测试的目的。

1)录制,就是在执行手工测试时将手工测试的任何操作及返回结果,预期正确的结果,通过TestAgent在TestTool中保存下来,并进行分析处理形成一个可执行的脚本。

录制的关键点,按键或触屏消息、坐标、响应结果,GUI界面,。

2)回放,与录制相对应,运行录制时产生的脚本,与主动式测试方式不同的是回归式测试是事先

要录制脚本,通过录制脚本来代替人工编写脚本。

回放关键点,发送和分发消息、接收及处理反馈结果,结果判断,。

四、关键技术

1.消息传送机制

利用手机Modem中提供的ATCommand通过串口向手机端

建立命令消息通讯,目前手机厂商提供了常用的ATCommand,基

本满足普通的自动化测试需求,另外厂商还提供了用户自定义AT

Command的功能,当标准的ATCommand不能满足自动化测试需

求时,我们可以利用自定义ATCommand来实现我们自动化测试中

所需要的消息通讯。

如下为MTK平台上实现自定义ATCommand

的关键样例代码,

viewplaincopytoclipboardprint

//customer_at_command.c

#include“kal_non_sp***customercommand

****************************************************************************

*/#definePLAY“play”

#defineSTOP“stop”

kal_uint8custom_get_atcmd_symbol(void);

voidcustom_command_hdlr(char*full_cmd_string);

externvoidrmmi_write_to_uart(kal_uint8*buffer,kal_uint16length,kal_boolstuff);

/***************************************************************************

***FUNCTION

*custom_command_hdlr()

*DESCRIPTION

*ThisfunctionshouldparsethecustomATcommandanddocorrespondentaction.

*Customershouldmaintainandmodifythecode.

*PARAMETERS

*kal_uint8*cmd_string

*RETURNS

*none

****************************************************************************

*/voidcustom_command_hdlr(char*full_cmd_string)

charbuffer[MAX_UART_LEN];

charcmd_name[15];

kal_uint8index=3;//westartparsingindexaftertheCUSTOM_SYMBOL

kal_uint8tmp_idx=0;

while((full_cmd_string[index]!

==)&&//mightbeTESTcommandorEXEcommand

(full_cmd_string[index]!

=)&&//mightbeREADcommand

(full_cmd_string[index]!

=13))//carriagereturn

{

cmd_name[tmp_idx]=full_cmd_string[index];

tmp_idx++;

index++;

}

cmd_name[tmp_idx]=;

/*justaverybasicexample:

customercanimplementtheir

own*/

if(strcmp(cmd_name,PLAY)==0)

{

/*BEGIN:

dothefollowingparsingandcorrespondent

action*/

/**/

/**/

/**/

/*END:

dothefollowingparsingandcorrespondentaction

*/

/*generatefinalresultcode:

“OK”*/

//Todo实现消息分发或功能调用

sprintf(buffer,“HelloPlay”);

printf(“%s“,“HelloPlay”);

rmmi_write_to_uart((kal_uint8*)buffer,(kal_uint16)strlen(buffer),KAL_TRUE);

}

elseif(strcmp(cmd_name,STOP)==0)

{

/*BEGIN:

dothefollowingparsingandcorrespondent

action*/

/**/

/**/

/**/

/*END:

dothefollowingparsingandcorrespondentaction

*/

/*generatefinalresultcode:

“OK”*/

//Todo实现消息分发或功能调用

sprintf(buffer,“HelloStop”);

printf(“%s“,“HelloStop”);

rmmi_write_to_uart((kal_uint8*)buffer,(kal_uint16)strlen(buffer),KAL_TRUE);

}

else

/*uecognizedcommand*/

/*generatefinalresultcode:

“ERROR”*/

sprintf(buffer,“ERROR”);

printf(“%s“,“ERROR”);

rmmi_write_to_uart((kal_uint8*)buffer,

(kal_uint16)strlen(buffer),KAL_TRUE);

}

return;

}

kal_uint8custom_get_atcmd_symbol(void)

{

return(CUSTOM_SYMBOL);

}

2.图像识别

图像识别主要通过抓取LCD屏幕显示图像进行智能识别来模拟测试工程师的双眼辨识文字或图像信息,以此判断测试结果。

主要涉及图像的获取和对比分析,智能识别是一个比较专业的研究领域,更进一步的研究需要进行调研,目前我们可以考虑是否能够通过第三方工具来实现,比如借助目前已经成熟的测试工具QTP等。

对于图像获取在手机平台上应该具备这样的接口,或者自行开发这个接口。

3.录制回放

录制的信息及相应的实现方式如下,

1)按键消息,由TestAgent捕获该消息并同步给PC端的TestTool

2)笔点消息,由TestAgent捕获该消息并同步给PC端的TestTool

3)坐标,由TestAgent捕获该坐标信息并同步给PC端的TestTool

4)响应结果,GUI界面回放的预期结果,,通过图像抓取接口抓取图像并同步给PC端的TestTool,如果做到极致的话在PC端所呈现的GUI界面与实际手机GUI界面同步一致,等同于PC机上的显示为手机GUI的一个镜像,

5)时钟同步,操作步骤的时间点、操作的先后顺序、输出结果响应时间

6)录制脚本组装,TestTool将所有的录制信息进行处理并组装成一套可运行的测试脚本,要求运行该脚本后能够与录制时的操作完全一样,并能将回放时的实际结果与预期结果进行比较从而得出执行结果。

7)回放,主要是运行组装好的测试脚本,将回放时的实际结果与预期结果进行比较从而得出执行

app测试报告范文【2】

测试前的准备,

1.使用同类型的产品,不仅仅是使用,应该是测试同类型的产品。

2.熟悉我们产品的spec文档,积极和pm交流。

3,写测试用例,没有时间至少要有一个checklist。

1.功能

a.基本功能,主要指app是否完成了设计的所有功能。

分清

模块,写一份checklist,避免漏测。

考虑横竖屏切换,不过很多app现在只支持竖屏。

b.系统交互:

电话短信干扰,低电量提醒,push提醒,usb数据线插拔提醒,充电提醒等,

2.性能:

稳定性,兼用型,android碎片化是个难题,bug也多,ios相对bug少,,app运行的内存消耗和cpu消耗,app后台长时间运行的耗流量,耗电量。

推荐testin这个第三方平台,对android兼用性测试比较有帮助。

3.易用性,面是否吸引人、容易理解。

界面整洁、简单。

无错别字。

点击范围确定等。

这部分测试中,如果测试认为有不合理的地方通常会提交需求bug。

4.外场,网络切换,网络信号强,弱下的app运行情况。

对自动化的一些看法,

目前我们可以接触到手机方面的自动化工具,robotium,monkey,monkeyrunner,androidjunit。

但是由于ui变化快,自动化测试往往不方便维护。

前三个不需要源码支持,但是功能有限,androidjunit很强大,对代码能力要求高,同时需要源码支持。

app的开发周期一般都很短,ui变化大,用自动化要考虑投入成本,大多数的公司估计都不适用。

不过测接口之类的通过自动化是个不错的选择。

转,说得多有道理的。

1.移动互联网开发节奏很快,版本快速迭代,如何让测试敏捷起来,

Monkey,我建议放弃完全得TestCase。

全部用featurelist

或者测试思维导图或者功能点划分表来进行引导得测试。

主要目的不会漏掉功能点以及防止regression得bug。

其次要敏捷必须要有自动化得支持。

关于这点就是根据不同得app进行定义了。

首先UT无论如何就要做起来。

其次是api和regressiontest得自动化要做起来。

当然CI也一定要搭建的。

2.移动应用测试,如何更全面的保证产品质量,如何让用户参与到测试中来,

Monkey,更全面得保证产品质量。

如果要说到全面,那么必须就是功能,压力,性能,安全,用户体验面面具到了。

其实还是和我第一个问题说得一样。

将app结合os得特性分层进行逐个得测试或者自动化测试。

关于让用户参与到测试中来的话。

我建议可以将不同的用户集合起来,qq或者weixin保持联系。

然后android可以定期发布内测版本,ios可以发布testflight版本。

3.用户反馈问题建议非常多,如何做好有效管理、分析和反馈,

Monkey,这个我相信无论哪家公司都会碰见。

用户的反馈不一定都是有效的。

管理的话,我建议还是需要安排一个专门的人进行记录。

将反馈全部作为bug的一种,随后填入bug系统方便跟踪。

其次关于crash或者无法重现的问题。

就需要自己在软件中增加自动

反馈crashlog的机制。

包括用第三方的友盟等也可以。

随后再定期的进行log的分析。

这些其实都不难,主要就是需要坚持,一直去做。

4.竞争产品很多,测试如何做竞品分析,

Monkey,这个其实我并不是很在行。

不过我觉得分析的话。

主要有几点。

其一,核心功能的体验。

也就是说核心功能路径长短。

比如A用了3步完成B用了4步完成的功能,那么A明显有优势。

其二,核心功能的交互,包括用户的学习成本。

其三,场景分析,比如我们可以设计N个场景,在这N个场景中我们自己的产品和竞争对手的产品,用户会做什么选择。

其实往往我们一设计之后就发现,有些功能用户根本无法理解,或者根本不用去做。

自然也就没有意义。

当然分析还有很多,包括下载量,点击数,评论等等。

都可以观察。

app的测试方式我在我自己的书中会有写。

这里我简单介绍以下。

不过首先需要肯定是不是拿到手就可以测的。

更多的是需要了解

a。

产品功能featurelist需要熟悉

b。

需要产品所在的系统的架构

c。

需要熟悉产品本身的结构,本身的逻辑,包括cs结构,生命周期,api等

d。

根据abc来设计测试点,测试点可以是思维导图或者别的。

但是并不需要去编写很详细的测试用例。

app测试报告范文【3】

1、安装、卸载测试

在真机上的以及通过91等第三方的安装与卸载

安装在手机上还是sd卡上

2、启动app测试

3、升级测试

数字签名、升级覆盖安装、下载后手动覆盖安装、跨版本升级、升级后可以正常使用。

覆盖安装要确保数据库有字段更新的话,能正常更新,否则就容易导致app异常。

4、功能测试

包括功能点、业务逻辑、关联性,主要测试客户端与PC端的交互,客户端处理完后,PC端与客户端数据一致,、

服务端接口测试,主要通过访问服务端接口来验证服务端业务逻辑功能点是否正确,

5、数据对比测试

可在模拟器或真机上进行,同时与数据库中实际的插入记录做对比。

还要对比主站的相同流程

6、性能

7、安全

8、android特性测试,横竖屏,home键,音量键,power键等,

9、各种网络状态下进行的测试,包括飞行模式,

3G上网,td-cdma、cdma2000、wcdma能否正常使用。

edge、gprs能否正常使用,主要测试是否支持net接入点和wap接入点,

10、中断性测试

如突然来电

短信弹出

低电量等时app能否正常使用

11、app切换测试,最小化、多个app切换,

12、关机、待机后app能否正常使用

13、兼容性测试

android各种版本

各种分辨率QVGA、WVGA、HWVGA等

与其他第三方app的兼容

14、app在清空数据或强制退出后还能正常运行否

15、api,包括在app内跳转到另一个界面,在返回来,以及跳转到系统api

16、app对资源的占用,cpu、内存、耗电、流量等,

17、app本身涉及的权限

18、长时间开机且开app,看是否会出现异常情况

19、互动分享,如果程序里面包括分享功能,那么检测点击分享的时候是否会正常给出分享提示,点击分享后所填写的分享内容是否正确

[app测试报告范文]

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 求职职场 > 简历

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2