YBsisterchang 2012-04-14
天翼空间【云终端测试平台-CMET】评测报告
用户名:CshBBrain 网络测试环境:电信ADSL 6M带宽
电脑操作系统:Windows XP SP3 测试手机机型:三星I909,三星I809
评测报告主要内容:
1、CMET功能:
网站评测:
1.1首页界面布局感觉不太合理,没有突出系统的重点,我们进来一眼看不出系统到底能为我们提供啥子服务;建议把设备一览表信息放到首页上,我们进来一眼就看到有设备可以使用,点下使用就可以使用设备了,要直观得多,不需要过多的言语,我们都知道可以干啥子。强烈建议运营商参考下我提的这个建议。
1.2网站上直接使用只支持IE浏览器,这个有点遗憾,现在基于Webkit内核的浏览器越来越流行了,建议系统在不久的将来支持基于Webkit内核的浏览器(比如Google的Chrome,苹果的Safari浏览器等)。不过还好有客户端可以使用。
1.3设备一览表进入和按条件查询都很慢,多数情况下我每点击一下,至少要等5秒钟以上,我用的还是电信的ADSL 6M带宽。强烈建议系统提供商对系统的性能做下优化。
1.4网站上根本就没有苹果设备和黑莓设备,查询条件中居然有苹果,黑莓品牌以及他们主导的操作系统,刚开始一看你狂喜,还以为有苹果的手机呢。如果没有先把这些撤掉,有点误导我们开发者。
1.5网上上收藏的设备可以自动同步到客户端上面来,网站上上传的应用可自动同步到客户端,这点还是比较方便。
客户端评测:
1.6客户端上做得非常不错,不管是界面布局,还是颜色搭配都非常好;尤其是手机体验测试的快捷操作功能非常好,因为网络的原因,有时操作非延迟,比如拖动屏幕,滑动屏幕等,不好操作,建议这类操作可以提供快捷按钮进行操作。如果将屏幕解锁功能也添加到这里就更好,还有在手机上输入的时候可以提供输入框功能,通过电脑键盘输入比在手机上按键要快很多,这样可以提高操作的效率。
1.7客户端有录制视频的功能,这个功能比较好,有时候有些bug比较难重现,有了视频的话,可以多次回放视频,通过分析操作步骤来确定缺陷出现的规律还是有些帮助。
1.8 应用上传非常慢,我的安装包才783k,上传就花了我差不多2分钟,这个地方最后能改进下就好了。
1.9用户可以通过远程操作手机发送短信和拨打电话,这对于你们来说也许是个问题,一些别有用心的人可以编写脚本使用你们提供的手机来发送垃圾短信,广告短信,骚扰短信,也可能编写一个脚本使用你们的手机定时给某人打电话搞恶作剧;其实你们应该考虑下这个安全隐患。
1.10上传的应用可以直接在使用手机的时候进行安装这个功能还是非常方便。
1.11录制视频的时候,当录制到3600帧的时候自动停止了视频的录制,觉得这个应该改进下,由用户决定录制好长时间。
2、CMET应用适配测评(注:适配测试使用的应用为本公司为新加坡“联合早报成都频道”的新媒体方案)
2.1.适配的机型:
三星I889:设备无法使用,无法开机
三星I559:通过,可正常安装使用
三星I569:通过,可正常安装使用
三星I579:通过,可正常安装使用
I899:设备无法使用
三星I809:装载应用后无法收到短信
三星I909:通过,可正常安装使用
三星W899:通过浏览器下载不了应用,不知道啥子原因
三星I919:无法装载应用
三星I929:无法装载应用
2.2.适配中发现的问题:
2.2.1.关闭设备使用窗口释放设备的时候遇到一次工具崩溃的情况,截取到3张图片供你们参考:
2.2.2.发现没有手机卡的手机不能装载应用,所以就无法进行后面的适配测试了;最好能做到没有手机卡的手机终端也能装载应用就好了。
2.2.3.发现有的手机无法根据地址从“测试中心”下载到应用,提示找不到文件错误。
2.3.4.发现有的手机有卡,但是收不到短信,所以也无法进行后续安装测试。
2.3.适配测试详情:
2.3.1.三星I889:设备无法使用,无法开机
2.3.2.三星I559:通过,可正常安装使用
2.3.3.三星I569:通过,可正常安装使用
2.3.4.三星I579:通过,可正常安装使用
2.3.5.三星I899:设备无法使用
2.3.6.三星I809:装载应用后无法收到短信
2.3.7.三星I909:通过,可正常安装使用
2.3.8.三星W899:通过浏览器下载不了应用,不知道啥子原因
2.3.9.三星I919:无法装载应用
2.3.10.三星I929:无法装载应用
3、自动化脚本测评及分享(注:脚本编写使用的应用为电脑报平板电脑版,使用的手机终端:192.168.3.75,18080198773)
首先规划一下对应用的测试,分为测试准备工作,测试规划工作,素材采集工作,脚本编写调试工作和脚本回放工作共5大部分。首先先进行测试准备工作和测试规划工作。3.1测试准备工作:
3.1.1.上传应用
3.1.2.安装应用到手机终端上
3.1.3.为了编写脚本方便将应用放到首页第一页上
3.2测试规划工作
3.3素材采集工作
3.3.1.素材采集的主要工作是从录制视频过程中工具所生成的所有图片中截取对编写脚本有用的图片;个人认为这里是非常考技巧的地方,因为工具自动获取的图片太多,人工去选取把眼睛都看花可能效果还不太好,对于一堆图片你怎么知道那张图片是在那个操作之前,那张图片是在某个操作之后,这些图片的先后顺利呢。如果把全部图片都导出去选即费时,效果还不好。
3.3.2.这里说说我所使用的素材采集技巧吧,通过“操作记录”制作脚本素材。点“回放视频”,然后点“生成操作记录”;工具会生成你所操作的所有操作记录,操作记录包括你操作相关的所有画面,每个画面的先后顺序,画面和操作动作之间的关联关系,包括延迟的时间数量都记录的下来了。通过操作记录你会非常方便的获取到你编写脚本所需要的图片资源,我就是通过查看操作记录把画面,操作,状态理顺了的;(操作记录直接用浏览器打开)确定要用某张图片作为资源时,直接点击这张图片另存为你的资源文件图形即可。(顺便说一句,工具已经把操作记录都整得这么详细了,为什么不让工具根据操作记录自动生成脚本,然后测试人员在这个基础上修改生成的脚本,添加一些检查点就可以了呢;非要让我们手工去写这么枯燥的脚本呢)
3.3.3.上几张素材采集相关的图片:
操作记录网页效果:
3.4脚本编写调试工作
3.4.1.脚本的编写其实就是根据测试规划的内容进行脚本的编制,脚本编辑器的好处是将对应用的操作抽象为点击按键和滑动屏幕2大类操作,脚本的操作步骤由动作,检查点,延迟等内容组成。其他我看还有什么分支,循环,子脚本等执行路径控制节点,想法不错;思想是好的。
3.4.2.根据我进行素材采集,脚本编写的过程来看我充分利用了工具本身的“操作记录”功能所生成的“操作记录”,这个操作记录非常有用,将你操作的所有动作,动作的先后顺序,操作动作与画面之间的关联关系,动作延迟等信息都做了详细的记录,并进行了非常合理的整理,其实就差检查点了。呵呵......说道这里我有话不得不说,既然你们的技术实现都已经把“操作记录”做到这么智能的一个程度了,为什么不再进一步呢?这一步是什么呢?就是工具提供一个根据操作日志自动生成测试脚本的功能,测试人员只要用了这个功能,工具将他所有的操作步骤以及相关画面生成测试脚本;测试人员在生成的测试脚本基础之上要么添加步骤,要么减少步骤,要么插入检查点,再进行调试调试就完成了测试脚本的编写,岂不美哉!(这里强烈建议你们参考一下hp的qtp录制脚本的功能是怎么弄的)如果你们实现了像我所想的那样,我们写脚本可以节约80%的时间啦,这个将是一个革命性的东西。
3.4.3.我在调试脚本的时候处理得最多的问题就是超时处理,可能是网络的问题。我希望这个延迟不要在每个步骤里面去设置死,在回放脚本的时候让用户根据自己网络的情况去设置合理的步骤之间的思考时间区间,比如我的网络有点糟糕,我回放时,将思考时间设置为10秒,那么执行时,每个步骤的超时时间就为10秒。我的网络比较好,我将回放思考时间设置我3秒。
3.4.4.工具的稳定性好像不是很好,用一段时间后会出现崩溃的情况。
3.4.5.将我编写的脚本截张图放上来,感兴趣的可下载附件:
3.5脚本回放
3.5.1.回放10次脚本,5次成功,5次失败,失败的原因都是执行超时,不知道啥原因我是独享电信6M带宽。
3.5.2.脚本回放图片:
启动回放:
回放中:
回放完:
4、体验心得及建议:
4.1 系统整体上不错,使用过程中感觉客户端要比网站好用,网站不支持Webkit内核的浏览器是个不小的遗憾,以后最后支持Webkit内核的浏览器(比如Google的Chrome浏览器,苹果的Safari浏览器),毕竟无线互联网还是Webkit内核浏览器的天下。
4.2 网站首页的布局不是太合理,没能很好的突出系统所能提供的服务,需要看了帮助说明才知道,系统的帮助说明倒是写得很详细。
4.3 客户端可以录制测试操作过程并生成视频,这个功能本身比较好,有时候有些bug比较难重现,有了视频的话,可以多次回放视频,通过分析操作步骤来确定缺陷出现的规律还是有些帮助。但美中不足的是视频录制限制到最大只能录制3600帧;超过了3600帧时,客户端自动停止录制,这个如果能处理到不限制帧数将是一个非常好的功能。
4.4 系统的整体性能最后在提升一下,尤其是网站,每次进入设备一览表和查询设备时都非常慢,使用手机进行操作有时也比较卡。
4.5缺少批量测试功能,比如我想知道我的应用是否在所有Android机型上能正常的安装,运行,卸载,我要每种机型都去测试一下,如果能提供一个方案能自动测试在所有机型上是否正常的安装,运行,卸载;自动测试完只需告诉我哪些机型不能正常安装,运行,卸载把出错的画面一并提供给我,这样就可以省去我们很多测试工作量,也可以减少测试成本。
4.6 UI自动适配,需要花费大量时间去测试UI在各种分辨率的终端上是否显示正常,最后能提供一个自动化的解决方案。
4.7 应用的运行时性能测试,我们非常想知道我们的应用在某种机型上正常运行时的CPU占用率,内存使用大小,手机电池消耗指数,网络带宽占用情况等性能指标,便于应用推广宣传时使用,但一直没有一个好的办法检测这些性能参数。
4.8这类系统国内也有几家,但是现在来看还没有一家能达到真正可以商用的程度,CMET目前来看还算做得较好,测试操作起来还算比较流程的。对于像我们这类专注于移动应用开发的公司非常希望有可以真正商用的远程测试服务,因为这可以为我们节省不少购买设备的资金。
4.9脚本编写没有时间去评测了,不知道是否是在某个机型上编写了测试脚本在所有其他机型都可以自动执行并搜集测试报告。
4.10平台上最多是Android手机终端,没有iPhone,iPad,AndroidPad类型的终端,其实对于专业的移动应用开发上来说,只有Android手机终端其实只能满足我们目前测试所需的四分之一的终端需要,我们的应用还需要在iPhone,iPad,AndroidPad类型的终端测试运行,希望在不久的将来能提供iPhone,iPad,AndroidPad类型的终端供测试使用。
4.11 平台对于使用到重力感应类的游戏,基于GPS定位的应用测试可能不太适合。
4.12 脚本编写为回归测试提供更大的支持,思想是非常好的;但目前脚本编写的工作量太大,还不适合引入到企业的回归测试中来。如果工具改进到能自动生成测试脚本,测试人员在生成的脚本基础上修改脚本,添加检查点即可完成脚本的编写实用价值就非常大了。
4.13通过对测试平台的全面体验,个人感觉目前测试平台作为设备资源池开发给开发者进行应用真机测试,适配测试已经差不多了;但要对回归测试(也就是脚本的编写)提供支持,需要对脚本编写的方式进行变革性的改善和提升,提供更加快速,高效的编写方式才具有真真的实用价值。
看完帖子的朋友们,请帮我点击下面的分享,收藏,支持按钮来支持我,谢谢