目录
摘要................................................................................................................................ II Abstract ............................................................................................................................. III
第1章绪论 (8)
1.1 课题背景 (8)
1.2 与本课题有关的国内外研究状况 (9)
1.2.1 自动化测试的国内外研究现状 (9)
1.2.2 Android相关的自动化测试研究现状 (11)
1.3 本文研究的主要内容 (12)
第2章自动化测试系统的需求分析与关键技术 (14)
2.1 功能性需求 (14)
2.1.1 测试用例开发 (14)
2.1.2 配置文件处理 (15)
2.1.3 自动化控制 (16)
2.1.4 情景模拟 (17)
2.1.5 测试结果 (20)
2.1.6 用户界面显示 (20)
2.2 非功能性需求 (21)
2.3 关键技术 (21)
2.4 本章小结 (22)
第3章自动化测试系统的设计 (23)
3.1 系统总体设计 (23)
3.2 系统详细设计 (27)
3.2.1 测试用例模块的设计 (27)
3.2.2 配置文件模块的设计 (29)
3.2.3 自动化控制模块的设计 (33)
3.2.4 情景模拟的设计 (38)
3.2.5 测试结果模块的设计 (48)
3.2.6 用户界面模块的设计 (53)
3.3 本章小结 (55)
第4章自动化测试系统的实现 (56)
4.1 测试用例功能模块的实现 (56)
4.1.1 AATS对APPCASE的支持 (56)
4.1.2 AATS对NativeCASE的支持 (57)
4.2 配置文件的实现 (59)
4.2.1 基本类配置文件的实现 (59)
4.2.2 A类配置文件 (60)
4.2.3 B类配置文件 (60)
4.2.4 C类配置文件 (61)
4.3 自动化控制模块的实现 (61)
4.3.1 响应开机广播事件的实现 (61)
4.3.2 MainActivity的业务实现 (63)
4.3.3 测试过程控制的实现 (63)
4.3.4 重要工具类的实现 (67)
4.4 情景模拟的实现 (68)
4.4.1 情景模拟基类的实现 (68)
4.4.2 DDR动态调频情景模拟的实现 (68)
4.4.3 音频情景模拟的实现 (69)
4.4.4 飞行模式情景模拟的实现 (70)
4.4.5 蓝牙情景模拟的实现 (71)
4.4.6 电话情景模拟的实现 (72)
4.4.7 WIFI情景模拟的实现 (73)
4.4.8 睡眠唤醒情景模拟的实现 (74)
4.4.9 CPU动态调压调频情景模拟的实现 (75)
4.4.10 设备切换情景模拟的实现 (76)
4.4.11 Modem重启情景模拟的实现 (77)
4.4.12 CPU电压设置情景模拟的实现 (79)
4.5 测试结果模块实现 (81)
4.5.1 建立SQLite数据库 (81)
4.5.2 访问数据库 (81)
4.5.3 日志信息功能一 (82)
4.5.4 日志信息功能二 (82)
4.6 用户界面模块的实现 (83)
4.6.1 主界面的实现 (83)
4.6.2 模块列表界面的实现 (84)
4.6.3 测试计划选择界面的实现 (84)
4.7 本章小结 (85)
第5章系统测试 (86)
5.1 系统测试环境 (86)
5.2 系统功能测试 (86)
5.2.1 测试用例模块 (86)
5.2.2 配置文件模块 (89)
5.2.3 自动化控制模块 (91)
5.2.4 情景模拟模块 (92)
5.2.5 测试结果模块 (95)
5.2.6 用户界面模块 (96)
5.3 非功能测试 (97)
5.4 测试结论 (98)
5.5 本章小结 (98)
结论 (99)
参考文献 (100)
哈尔滨工业大学学位论文原创性声明及使用权限 (103)
致谢 (104)
个人简历 (105)
第1章绪论
1.1 课题背景
展讯通信是一家集成电路芯片设计企业，为国内外移动设备生产商提供移动设备芯片套片及各种元器件的同时，也为客户提供软件参考设计方案。2009年开始，展讯通信的主要业务也从Feature Phone转移到Smart Phone，而Android 系统是展讯通信产品形态最多的智能操作系统，从单核和双核产品到四核和八核产品，从3G的TD、WCDMA到4G的TD-LTE（FDD，TDD）、TD-SWDMA，从Android 2.3.5到AndroidL，从Linux2.6到Linux3.4，从研发分支到量产分支，再到阿尔法客户分支，而这些分支都采用迭代增量式开发，数以百千计的软件版本需要进行测试，从项目成本和项目进度角度考虑，采用手动测试都是不现实的。
Google为SoC（System on Chip）公司提供的自动化工具有CTS，Monkey、MonkeyRunner、UIAutoMator。CTS只能用于测试Android framework提供的API的兼容性；Monkey是随机性测试，需要长时间的测试才能保证版本可靠，缺乏时效性和针对性；MonkeyRunner和UIAutoMator只是针对Android应用层的具体应用进行测试，需要针对每个应用进行开发测试用例。虽然这些工具在QA部门的日常测试中被使用，但是我们平台研发部门缺乏有针对性，时效性和通用性的测试系统。针对性即针对我们平台研发过程中经常出现的问题，如Camera的预览、拍照、录像等，我们需要们开发一些针对这些问题的测试用例，如果我们把Bugzilla上的常见Bug都按照它们出现的路径开发出测试用例，在每个Daily Build版本出来后自动地进行测试，如果发现版本有问题就不需要发布版本，从而节省测试人员的时间。
鉴于以上事实，我们平台研发部提出了开发自己的自动化测试系统的需求，概括的描述这个需求：开发一个自动化测试系统，同时提供公共接口以满足应用层和linux层测试用例的开发，能够通过配置控制执行各种测试用例，在测试完成后能导出测试报表，对于Android的常见功能形成场景测试，从而验证系统的稳定性和各模块的兼容性。
- 8 -