[总结]无线测试

本文主要介绍测试在项目的各个阶段应该要做的事情、使用的工具和主要的注意事项。主要用于新人辅导与自我总结，欢迎大家拍砖。

      需要掌握的基本功（只针对android客户端测试）：
      1、android/java的基础语法
      2、代理设置工具与原理
      （代理设置的方法可以参考文章：http://blog.csdn.net/zshq280017423/article/details/8928616 
      fiddle原理可以参考：http://kb.cnblogs.com/page/130367/）
      3、android的activity的生命周期
      （官方文档：http://developer.android.com/guide/components/activities.html#Lifecycle
         文章可以参考： http://blog.csdn.net/liuhe688/article/details/6733407 ）
      4、一般的用例编写方法
      5、打包、android的签名机制等。
      （参考文章：http://blog.csdn.net/absurd/article/details/5002763 ）
      6、android的adb命令。
      （参考文章：http://www.cnblogs.com/playing/archive/2010/09/19/1830799.html）
      7、git命令。（参考文章：http://git-scm.com/book/zh/v1 ）
      这些基本功掌握后对后续的测试是很有帮助的，在知道原理后写用例、实际测试时都会有的放矢

需求阶段：
      在需求评审或者需求评审前，除了全面的了解产品的特性、技术需求、技术方案外，专项测试同事需要做的是根据现有的需求信息分析其中的风险点，并根据这些风险点制定相应的测试项，通过后期的专项测试发现和规避问题。
      需要考虑的点：
      1、网络风险

                断网重连，断点续传逻辑

                是否会产生大流量，流量合理性（流量消耗和发送的文件大小是否近似）

                请求-响应来回次数较多，是否会增加失败率

                协议必须有压缩策略

                有没有缓存机制
           具体的表现：在断网、弱网情况下app的各种表现，例如：在获取数据时断网、超时应如何显示，需要给用户明确友好的提示，同时app还需要做相应的操作防止数据丢失或者错误。
      2、UI风险

               存在IO操作，例如保存，导入，导出，发送，上传，当遇到大数据时是否有加载过程

               元素或动态/可变元素过多过复杂，是否会造成界面卡顿和CPU长期偏高（如LISTVIEW复杂格式或有动态图）

               元素加载时机（如滑动列表时，头像加载的时机）
           具体的表现：文件的上传下载，本地的文件、数据存储。
      3、电量/CPU风险

               地理位置相关逻辑，检测逻辑（如人脸识别、贴耳检测）

               后台服务（如tcp心跳逻辑）

               音视频相关
            具体的表现：在调用系统组件时会对电量CPU有较大的消耗，需要评估是否会影响app的性能。
      4、OOM风险

               缓存策略，加载大数据策略（如拉取查看大图bitmap）

               GC策略
            具体的表现：在图片查看时如果出现OOM会导致crash。
      5、兼容性风险

               较新的系统特性

               通过系统API/系统数据库获取数据

               硬件相关（摄像头，屏幕触碰效果，声音大小，gps）
            具体的表现：在调用硬件、系统api时由于各个手机厂商可能会对系统进行定制，需要进行机型适配，将主要机型进行适配保证主要机型的硬件调用

      

测试分析阶段：
      在测试分析阶段主要注意

• 数据、环境准备，是否需要跨系统、跨BU进行合作，这种合作比较费时需要提前联系
• 客户端的各种操作方式：上下拉动、左右滑动、多次点击、长按、拖动、语音输入、定位等进行考虑
• 用户体验，要对客户端的用户体验有极致的追求
• 系统行为
• 消息推送

      无线用例设计方法可以参考：《本博客无线TC设计》
      主要使用的工具：xmind（对理清思路很有用）
开发阶段：
      可以给开发提供UI自动化case，让开发在代码大致完成后运行检查主干是否正常。
      可以提供静态代码扫描工具，在开发阶段就修复和避免一些空指针问题。
      

功能预演阶段：
      1、在功能预演前UED应对app进行视觉还原。
      2、功能预演由开发发起，测试提供冒烟点，开发根据冒烟点给PD、UED、测试进行演示。记录演示时的问题，修复后开发发邮件通知功能预演通过。

冒烟测试阶段：
      测试在冒烟测试阶段需要对app进行比较细的冒烟，冒烟点应该包含全部主要正常case与大部分异常case，同时在冒烟报告中最好给出UI自动化主干的运行情况，代码静态扫描的结果。
      
      UI自动化：android现在使用robotium

缺陷提交注意点：

      1、包构建号

      2、手机型号

      3、账号密码

      4、重现步骤

功能测试阶段：
      功能测试阶段主要分为两个阶段：第一阶段为功能执行阶段；第二阶段为专项测试阶段。
      功能测试阶段，除了按照用例进行执行外还需要重点注意的是：
      1、每个activity的返回，最好能模拟activity被内存回收时的场景
      2、前后台切换
      3、杀掉进程后再回到app
      4、推送消息在通知栏的显示，应该接收到的推送消息是否能够接收并正确跳转到相应页面
      5、系统行为的设置是否正确生效
      6、图片、视频、音频的查看与播放，文件上传下载。同时检查有SD卡与无SD卡的情况。
      7、断网或者超时时的提示是否友好并明确
      8、登陆的异常提示是否完善
      9、用户操作是否繁琐，一般客户端的操作越简单明了越好
      10、数据检查
      在功能测试中可以使用代理软件进行代理，修改服务器返回让客户端显示的数据展示出各种情况下的数据。
   

专项测试阶段：
      现在专项测试主要针对两方面进行：1、适配；2、性能；3、安全。
      适配测试：
      适配测试主要分为两种
      1、屏幕适配，屏幕适配一般找三种类型的屏幕：超清屏，普通屏幕，低端屏幕。具体划分见下列注解。
      注：ldpi指120dpi，mdpi指160dpi，hdpi指240dpi，xhdpi指320dpi（高清屏），MX4的手机分辨率为1920*1152（dpi就是 1920的平方加1152的平方和开2次方后除以7结果大约是319.8），dpi越高屏幕越清晰。

      2、操作系统版本适配，系统版本适配android现在的主要分为两种
      流程适配，就是说在大部分的操作系统版本上流程必须保证正常。
      现在流程适配我主要使用UI自动化与手工结合的方式进行验证，不可能在所有的操作系统版本上都运行一次主干流程所以我们需要挑选其中用户使用最多的几种操作系统版本来进行适配。再挑选高中低三种android版本进行适配比如说：2.3.6、4.1.2、4.4+。
      控件适配，指在大部分的操作系统上控件要能够保持稳定不出现crash与anr。
      
      
      性能方面主要关注页面响应时间、弱网络、流量、内存占用、耗电量、FPS（动画效果）与cpu占用。
      测试工具：DDMS、命令行（adb shell top |findstr packageName  主要查看cpu、memory开销）
      耗电量：查看方法：1、拔掉USB；2、操作app；3、插上usb，执行adb shell dumpsys batteryinfo packageName;4、监控app wake lock类型、次数以及时间、传感器使用时间、网络流量的开销，各子进程的CPU使用时间；5、加权计算mAh。
      
      crash问题：主要使用摩天轮与宙斯盾提供的适配功能，再就是优化发布策略，使用灰度发布，定期关注WDM数据，及时修复crash问题。
      
       安全测试：主要使用STC的扫描工具，手工执行安全测试case。
    

回归测试阶段：
      1、每日bug review
      2、回归阶段的策略：一般回归进行3天，第一天服务端在测试环境测试一轮；第二天服务端在预发布再测试一轮，在预发布验证对老版本是否有影响；第三天服务端发布到线上，检查对老版本客户端是否有影响，新版本客户端是否正常。可以使用UI自动化来帮助进行回归。如果需求较多可以适当调整。
      3、安全审核，提交到集团安全
      

RC阶段：
      1、进入RC前所有bug必须关闭，并邀请PD、UED等相关人员体验提出意见。所有问题全部修复后再进入RC。
      2、测出来的问题全部录入缺陷系统，每日bugreview这些问题是否需要修复，影响不大的延期修复（PD决定）。
      3、每次RC需要邮件通知出来。
      注：RC（Release　Candidate）Candidate是候选人的意思，用在软件或者操作系统上就是候选版本。Release是发行、发布的意思。Release.Candidate.就是发行候选版本。和Beta版最大的差别在于Beta阶段会一直加入新的功能，但是到了RC版本，几乎就不会加入新的功能了，而主要着重于除错!


发布：ios本地打包发布到APPstore，android进行发布，最好分批发布，观察WDM的数据，有问题则需要出修复版，再进行RC。

发布成功，后续跟进后台数据，跟进用户反馈。