大会——移动互联网金字塔.pptxVIP

自我介绍陈晔曾担任多家创业公司首任测试主管移动互联网应用测试布道师正测试三观的人上海各个高校测试推广到处刷脸编写《大话移动测试——Android与iOS应用测试指南》（清华大学出版社）目前负责支付宝商户版移动应用的自动化技术回顾下移动互联网测试的历史我们的项目流程和现状移动互联网项目特点迭代快迭代周期：两个月？一个月？半个月？还有更甚？？变化快第N次迭代产品的样子第N＋1次迭代产品的样子烧钱快见效快 用户至上 移动互联网测试特点测试行业特点各个大会理论忽悠多，落地技术少行业组成人员鱼龙混杂抱怨多，静下心来学习少大部分人都是“拿来主义”大部分人自己看不起自己和测试大部分人也不知道测试到底做啥问题：移动互联网给我们带来了什么？在这样的前提下，大部分测试的愿望是什么？可是事实是大家有什么问题吗？移动互联网的应用业务测试应该怎么去做？应该关注什么？仅仅关注app，你绝对不是一个合格的测试人员软件分层是测试的精髓移动互联网也是一样问题：你觉得UI层要关注哪些？最重要的是设计比如除了精美的设计以外，还需要遵守规则测试提升设计敏感度阅读开源设计和交互文档多使用国外的应用多使用竞品多与真正的用户交流，而不是老板真正在生活中使用产品什么？你认为测试根本不需要关心用户体验？项目团队中使用产品最多的角色就是测试，他不关心谁关心？至少我是这样认为的UI测试毋庸置疑，移动互联网应用最多的测试还是手动功能测试全部自动化是银弹？非也，那是扯淡试问，如果资金类产品都是自动化测试，你们还敢用吗？UI关注点大部分企业做UI自动化。什么是UI自动化呢？就是将业务的手动功能测试转换成自动化执行吗？请切勿对号入座！关注点一控件是否存在关注点二控件位置关注点三控件显示内容和状态按钮上的文字文本上的文字单选的按钮是否被选中等关注点四全屏截屏对比MonkeyRunner自带API全屏截屏对比其他第三方对比库关注点五混合应用中的webviewAppium示例行业其他常用工具Robotium对Android原生测试框架Instrumentation做了简单明了的封装Solo API使用方便兼容Native和Webview缺点：不能跨应用进行相关操作BDD—Calabash场景即是用例，用例即是场景场景中步骤的封装舒服的日志Calabash同样支持iOSiOS UI测试工具Instruments大家有什么问题吗？App Inner测试Inner Service测试并非Server端的服务可测试Service的生命周期可测试Service相关的监听方法是否生效可Mock相关Context对Service进行隔离测试Inner测试一般分成这样几类：Native 方法测试与Server交互的方法测试与业务强绑定的方法测试Android举例Native方法测试使用Android Junit Test并非是Unit test，更多的当作一个API测试比如Aactivity中intent.putExtra()，Bactivity中intent.getStringExtra()；大部分公司的服务器接口自动化已经很完善，但这样就足够了吗？移动互联网应用的UI自动化投入产出比大多不高Android案例二与Server交互的方法测试使用Android Junit Test模拟所有和服务器交互的方法，从而在保证服务器接口正确的情况下，也保证了客户端对于数据的传输和解析也是正确的Android案例三与业务强绑定的方法测试很多功能和业务的自动化不是只有从UI切入一种方法，更多的可以从UI这层皮下面的核心方法入手比如联系人搜索功能你可以从UI入手，请问你要准备多少数据，要输入多少次？头大不大但你也可以选择直接启动这个activity，测试搜索的核心算法方法。是不是感觉很爽？是不是发现很多控件很难找到？很多操作很难实现？这就对了当你将这些很难实现的操作，从App inner为切入点去看的时候，一切就迎刃而解了UT测试这有啥好说的？从代码层面来讲，就是java和object－c的单元测试呗框架推荐Robolectric语法更接近于robotium，但却是shadow了Activity的一种UT这些思想和技术给我们能带来什么？提升测试效率将测试提前能够轻松的进行各种我们想进行的测试比如应用启动性能测试你可以使用adb logcat也可以写在android junit test中也可以在代码中插桩Android junit test代码插桩然后可以使用logcat过滤tag，脚本分析文件就可以了比如Android app性能测试应用消耗流量，编写service可做监控Android app电量编写service可监控电量性能全自动化插桩，然后logcat过滤保存到文本Top或者dumpsys过滤保存到文本过滤GC到