Android测试二三事之小里程碑制定

上一篇 / 下一篇  2017-04-17 16:31:33 / 个人分类:工作总结

由于android系统的多样性,分辨率的多样性以及手机的多样性测试增加了一定的难度
    系统的多样性,在我测试的这些时间里面发现各个软件在各种系统里面行为不一的情况较多。由于android的平台太过开放性,网上现在自制的系统非常多。作为软件测试来讲,不可能将所有的系统一一测试过来,但是可以尽量降低软件在各种系统上面出现bug的概率。

    分辨率的多样性,分辨率的测试不单单是检查软件每一个png的像素是不是被拉伸了,显示是不是全了,还要注意一些button的点击范围可能会因为分辨率的不同而造成bug


  手机的多样性,android手机目前应该说是面貌多样。物理键盘,屏幕上软键盘,各种手势滑动操作的机器等等。在任何的软件操作的时候,都能够点击home或者长按home键去切换应用,这类的操作往往容易被遗漏。还有测试一些应用的时候也要关注其兼容性说了这么多Android的多样性,那怎么减少无用功的发生呢?

首先简单介绍下研发测试和适配测试有什么区别?不都是测试吗,为什么会有研发测试和适配测试之分?

研发测试从需求阶段开始参与项目(甚至更早),直到项目或阶段结束,需要了解整个需求,机型只选择主流的厂商和机型。

适配测试在提测阶段参与项目,只了解当前适配点,机型覆盖量大。

里程碑的制定可包含在测试计划中,也可单独形成文档,但是一定要依据测试计划或项目计划。就研发测试而言,小里程碑主要体现在重要功能模块,每次测试的时候优先重点模块,一旦重点模块出现问题就要把测试包打回,等待重新提测。试想一下,如果我们测试的时候是按照用例的模块测试或者checklist测试,等到你测试重要模块时才发现问题,把包打回再提测的时候,前面的工作量都白费了。还要再重新测试一遍,这样不仅浪费的开发的时间,也浪费了测试的时间,甚至有可能影响版本发布的时间。再说适配测试时的里程碑制定,适配测试时的里程碑制定主要针对厂商或SDK某个方面设定,一旦确认测试包或者测试步骤中有问题就要及时确认,换包或修改测试步骤,由于适配测试的机型覆盖量比较大,如果测试后期甚至测试完成才发现问题可想而知浪费了多少人力及时间。提到测试步骤有问题有人可能会有疑问,就如前面所说适配测试只是针对适配点进行测试,而在适配测试时的用例是没有评审过的;相反,研发测试的测试用例是会进行同行评审及组内评审的。

用例的评审主要分为同行评审和组内评审。用例的同行评审是指同项目组外的测试人员(用例编写人员)一起评审用例,主要是发散思维,增加用例的覆盖率;而组内评审一方面增加项目组人员对需求的充分理解,减少分歧,另一方面则是使组内人员对用例达成一致性,最后同样会增加用例的覆盖率。

另附Android测试中常见问题点:

1、网络切换(飞行模式、3G4Gwifi、无网络)

2、时间调整

3、后台或锁屏

4、兼容性(同类软件兼容性、厂商、系统及分辨率兼容性等)

5、多指操作(iOS中更该注意此点)

6、物理返回键和应用返回键

7、结束进程

8、覆盖安装(尤其是数据迁移类)

9、异常测试(来电来信息、断网断电、插拔数据线和耳机、服务器异常、压力测试


TAG: 里程碑 Android

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

日历

« 2017-07-11  
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

数据统计

  • 访问量: 3329
  • 日志数: 19
  • 建立时间: 2010-11-29
  • 更新时间: 2017-04-17

RSS订阅

Open Toolbar