app测试报告范文Word文档格式.docx
- 文档编号:19421418
- 上传时间:2023-01-06
- 格式:DOCX
- 页数:9
- 大小:20.65KB
app测试报告范文Word文档格式.docx
《app测试报告范文Word文档格式.docx》由会员分享,可在线阅读,更多相关《app测试报告范文Word文档格式.docx(9页珍藏版)》请在冰豆网上搜索。
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
=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)
sprintf(buffer,“HelloStop”);
printf(“%s“,“HelloStop”);
else
/*uecognizedcommand*/
“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测试报告范文]
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- app 测试报告 范文