手机硬件RF和电性能测试报告
手机硬件RF和电性能测试报告
Add: Prayvtech Communications Technology
Co.，Ltd
Tel:86677066-875
Fax:86677011-801
E-mail:pengguiqiong200154＠https://www.360docs.net/doc/cf9674393.html,
Parametric Test Report
(Revision:A0)
Model:
Description: PR1硬件测试报告
Amount:2PC
Date:xxxx-xx-xx
Test Conditions
1. PCB：
2.S/W:
3.Test Equipments：CMU200/ Agilent 8960/Keithley2306/ Agilent6631系列Standard Test Condition
1. Temperature 15—35℃
2. Relative humidity 50%—70%
3. Test voltage 3.8V
Conclusion:
□FALL ■PASS
Approved:
1 简介
1.1 目的
1.2 适用范围
1.3 责任
2.0 程序内容
3.0 测试数据及测试结果
1 简介
1.1 序言
目前国家对手机的质量问题越来越重视，公司对于手机质量的客户满意度和返修率也一致关注。其中，GSM手机的射频问题仍然是一个影响手机质量、开发进度和生产效率的重要因素。为了保证产品的品质和性能符合 GSM 规范和国家标准，需要在手机测试方面建立一套完整、科学的测试体系。为此我们参
照 GSM 规范欧洲标准、国家邮电部移动通信技术规范、国家信息产业部通信行业标准以及日常积累的
测试经验编写了这份射频测试标准、测试的目的以及硬件相关的测试表格。本程序书定义了GSM 900MHz 和DCS 1800MHz 移动电话中试过程中的电性能测试标准。
1.2 目的
本规范的目的是针对研发阶段的GSM手机提供较全面测试指标依据尽量保证研发阶段GSM手机的点测指标满足FTA、CTA与批量生产点测指标要求，使手机的射频问题尽可能在研发阶段暴露出来并在量产前
解决。
1.3 适用范围
适用于各中试过程中无特殊要求的所有GSM850MHz、GSM 900MHz 、DCS 1800MHz和PCS1900移动电话。
1.4 责任
硬件测试工程师
2.0 程序内容
?所测试RF项目的定义及其测试的目的。
? RF测试数据
?硬件电流测试数据。
3.0测试环境及测试设备
温度：15 -35℃
相对湿度：25 -75％
正常测试电压应为设备的标称工作电压，其频率(测试电源)应为标称频率 lHz 范围内）。
综合测试仪 R&S CMU200 或 Agilent 8960
直流电源 Keithley / Agilent6631系列
电流表 Keithley
屏蔽箱、RF衰减器、耦合天线、射频连接线等（条件：采用相同标准的射频线和转接头，要求包括
转接头在内 GSM 频段各信道间的损耗值小于 0.5dB, 损耗值差异小于 0.2dB； DCS 频段各信道间的损耗值小于 1dB, 损耗值差异小于 0.3dB, 特性阻抗含转接头应在 50/+- 5 欧姆内）。
4．0 附件
附件1:所测试RF项目的定义及目的。
附件2: 硬件电流测试标准（根据不同机型其电流也有所不同，只供参考）
附件3：GSM900连接状态射频测试数据值5~6页。
附件4: DS1800连接状态射频测试数据值7~8页。
附件5：GSM900耦合状态射频测试数据值9~10页。
附件6: DCS1800耦合状态射频测试数据值11~12页。
附件7：GSM850连接状态射频测试数据值13~14页。
附件8: PS1900连接状态射频测试数据值15~16页。
附件10: PCS1900耦合状态射频测试数据值19~20页。
附件11: 硬件电流测数据21页。
附件1；所测试RF项目的定义及目的。
1．接收参数：
1.1 接收灵敏度（Rx sensitivity）
定义：接收灵敏度是指收信机在满足一定的误码率性能条件下收信机输入端需输入的最小信号电平。衡量收信机误码性能主要有帧删除率(FER)、残余误比特率(RBER)和误比特率(BER)三个参数。帧删除率(FER)的定义为被删除的帧数占接收总数据之比。
残余误比特率(RBER)的定义为在那些没有被声明为被删除帧中的误比特率，即在那些检测为好的帧中错误比特的数目与好帧中传输的总比特数之比。
误比特率(BER)的定义为接收到的错误比特与所有发送的数据比特之比。
目的:测量接收机的接收灵敏度是为了检验接收机的射频电路、中频电路及解调电路的性能。提高接收灵敏度，也就是从本质上提高手机接收信号能力,从而提高手机的通话质量．
1．2 接收信号指示电平（RX LEVEL）
定义：接收报告电平指手机在业务信道（TCH）上不同功率级别时接收信号的强度。
目的：检测手机的接收性能．即基站将利用手机的RX LEVEL报告了解手机接收信号强度（过低的RX LEVEL值将产生不必要的越区切换，而过高的RX LEVEL值则会推迟越区切换的时间，造成通话中断）。
1．3接收信号指示质量（RX Quality）
定义：接收报告质量指手机在业务信道（TCH）上不同功率级别时接收信号的强度它是由移动台产生的对接收信号质量的评价，在移动通信中作为射频功率控制和切换。
目的：检验手机的接收性能。如果手机汇报的RXLEV 和RXQUAL 不准确，则网络有可能会对手机发出一些错误的指令。过低的RXLEV 值将产生不必要的越区切换，而过高的RXLEV 值则会推迟越区切换的时间，造成通话中断。
2．发射参数：
2．1 发射载波峰值功率(Peak burst power)
定义：指发射机载波功率在一个突发脉冲的有用信息比特时间上的平均值。
目的：验证被测设备的发射机载频峰值功率符合GSM规范指标。如果发射功率在相应的级别达不到指标要求，会造成很难打出电话，即离基站近时容易打出而离基站远时不易打出困难。如果发射功率在相应的级别超出指标的要求，一方面可以客服空中损耗，降低对接收机接收灵敏度的要求，但则会造成电池损耗大，待机时间短；另外扩大小区覆盖范围，引入邻道干扰。
2．2 发射载频包络(Power time template）
定义：发信载频包络是指发信载频功率相对于时间的关系。（Power RAMP）
目的：验证发射机发射的载频包络在一个时隙期间是否严格满足 GSM 规定的TDMA 时隙幅度的上升沿、下降沿及幅度平坦部分与模块的吻合程度。手机发射突发信号的上升与下降部分应在＋4dB－-30dB，模块范围之内，顶部起伏部分应在 1dB 模板范围之内。若突发信号超出模板范围，将会对临近时隙的用户产生干扰。
2．3 调制频谱（Spectrum Due to Modulation）
定义：调制频谱指数字比特流信息经 GMSK 调制后在临近频带上所产生的频谱。
目的：防止带外频谱辐射，以免引起邻到干扰（指本频道对邻频道产生的的干扰）。在时间上，连续调制频谱和功率切换频谱不是同时发生的，因而输出射频频谱可分为连续调制频谱和切换瞬态频谱。连续调制频谱是由 GSM 调制而产生的在其载频的不同频偏处（主要是在相邻频道）的射频功
定义:指由于功率切换而在标称载频的临近频带上产生的射频频谱。即由于调制突发的上升和下降沿而产生的在其标称载频的不同频偏处（主要是在相邻频道）的射频功率。
目的：防止频段切换时的开关脉冲对邻频道产生干扰（指本频道对邻频道产生的干扰）。
2.5 频率误差（Frequency Error）
定义:频率误差定义为考虑了调制和相位误差的影响以后，发射信号的频率与该绝对射频频道号对应的标称频率之间的差。
目的：检验发射机调制信号的质量和频率稳定度。频率误差小，则表示频率合成器能很快切换频率，并且产生出来的信号足够稳定。只有信号频率稳定，手机才能与基站保持同步。若频率稳定达不到要求（ 0.1ppm），手机将出现信号弱甚至无信号的故障，若基准频率调节范围不够，还会出现在某一地方可以通话但在另一地方不能正常通话的故障。
2.6 相位误差（Phase Error）
定义：发射信号的相位误差定义为发信机发射信号的相位与理论上最好信号（即理论上按GMSK 调制出来的信号）之间的相位之差。理论上的相位轨迹可根据一个已知的伪随机比特流通过 0.3GMSK 脉冲成形滤波器得到。
目的：通过测试相位误差了解手机发射通路的信号调制准确度及其噪声特性。可以看出调制器是否正常工作，功率放大器是否产生失真，相位误差的大小显示了 I、Q数位类比转换器和高斯滤波器性能的好坏。发射机的调制信号质量必须保持一定的指标，才能当存在着各种外界干扰源时保持无线链路上的低误码率。
2．7 发射峰值电流和平均电流
定义:发射峰值电流：是指打开发射通道时发射机的瞬时峰值电流。
发射平均电流：是指打开发射通道，发射功率稳定后的电流值。
目的：检测发射峰值电流是否符合手机工作电流范围之内，是否符合电池承受能力等。
附件2:基本电性能指标(注：此电流指标根据不同平台及机型相应的值也有所不同，此标准只供参考)
附件3: GSM900 连接状态射频测试数据 Test Result GSM900 Cable Loss ： 0.5dB
(注：调制频谱值和开关频谱值若在中心值可省去记录数据可直接在结果拦中用OK) GSM900 连接状态射频测试数据
附件4: DCS1800 连接状态射频测试数据 Test Result DCS1800 Cable Loss ：0.8dB
(注：调制频谱值和开关频谱值若在中心值可省去记录数据可直接在结果拦中用OK)
DCS1800 连接状态射频测试数据
附件5: GSM900耦合状态射频测试数据 Test Result GSM900 Cable Loss ： 8.0dB
(注：调制频谱值和开关频谱值若在中心值可省去记录数据可直接在结果拦中用OK)
GSM900耦合状态射频测试数据
附件6: DCS1800耦合状态射频测试数据 Test Result DCS1800 Cable Loss ： 12dB
DCS1800耦合状态射频测试数据
附件7: GSM850 连接状态射频测试数据 Test Result GSM850 Cable Loss ： 0.5dB
(注：调制频谱值和开关频谱值若在中心值可省去记录数据可直接在结果拦中用OK)
GSM850 连接状态射频测试数据
附件8: PCS1900连接状态射频测试数据 Test Result PCS1900 Cable Loss ：0.8dB
PCS1900 连接状态射频测试数据
附件9: GSM850耦合状态射频测试数据 Test Result GSM850 Cable Loss ： 8.0dB
(注：调制频谱值和开关频谱值若在中心值可省去记录数据可直接在结果拦中用OK)
GSM850耦合状态射频测试数据
附件10: PCS1900耦合状态射频测试数据 Test Result PCS1900 Cable Loss ： 12dB
PCS1900耦合状态射频测试数据
手机APP测试报告模板
手机APP测试总结报告
目录 1.测试概述 (1) 1.1. 编写目的 (1) 1.2. 测试范围 (1) 2. 测试计划执行情况 (1) 2.1. 测试类型 (1) 2.2. 测试环境与配置 (3) 2.3. 测试人员 (3) 2.4. 测试问题总结 (3) 3. 测试总结 (4) 3.0.程序流程 图 (3) 3.1.测试用例执行结果 (4) 3.2. 安全测试 (6) 3.2.1. 软件权限 (7) 3.2.2. 安装与卸载安全性 (7) 3.2.2. 数据安全性 (8) 3.2.3. 通讯安全性 (9) 3.2.4. 人机接口安全性 (10) 3.3. 安装、卸载测试 (11) 3.3.1. 安装 (11)
3.3.2. 卸载 (11) 3.4. UI测试 (12) 3.4.1. 导航测试 (12) 3.4.2. 图形测试 (12) 3.4.3. 内容测试 (13) 3.5. 功能测试 (13) 3.5.1. 运行 (13) 3.5.2. 注册 (13) 3.5.3. 登录 (14) 3.5.4. 注销 (14) 3.5.5. 应用的前后台切换 (15) 3.5.6. 免登入 (15) 3.5.7. 数据更新 (16) 3.5.8. 离线浏览 (16) 3.5.9. APP更新 (17) 3.5.10. 时间测试 (17) 3.5.11. 性能测试 (17) 3.5.12. 交叉性事件测试 (17) 3.6. 兼容测试 (18) 3.7. 用户体验测试 (19) 4. 测试结果 (19) 软件缺
陷 (15)
1.测试概述 1.1.编写目的 本测试报告为招标手机APP的测试报告，目的在于总结测试阶段的测试情况以及分析测试结果，描述系统是否符合用户需求，是否已达到用户预期的功能目标，并对测试质量进行分析。 测试报告参考文档提供给用户、测试人员、开发人员、项目管理者、其他管理人员和需要阅读本报告的高层经理阅读。 1.2.测试范围 测试主要根据用户需求说明书和软件需求规格说明书以及相应的文档进行系统测试，包括功能测试、性能测试、安全性和访问控制测试、用户界面测试以及兼容性测试等，而单元测试和集成测试由开发人员来执行。 主要功能包括：用户登录、我的项目、推荐项目订阅、软件设置、我的收藏、消息中心，借阅同步等。 2.测试计划执行情况 2.1.测试类型
手机APP测试报告模板【完整版】
招标手机APP测试总结报告
目录 1.测试概述 (1) 1.1.编写目的 (1) 1.2.测试范围 (1) 2.测试计划执行情况 (1) 2.1.测试类型 (1) 2.2.测试环境与配置 (2) 2.3.测试人员 (3) 2.4.测试问题总结 (3) 3.测试总结 (3) 3.1.测试用例执行结果 (3) 3.2. 安全测试 (6) 3.2.1. 软件权限 (6) 3.2.2. 安装与卸载安全性 (7) 3.2.2. 数据安全性 (7) 3.2.3. 通讯安全性 (9) 3.2.4. 人机接口安全性 (9) 3.3. 安装、卸载测试 (10) 3.3.1. 安装 (10) 3.3.2. 卸载 (10) 3.4. UI测试 (11) 3.4.1. 导航测试 (11) 3.4.2. 图形测试 (11) 3.4.3. 内容测试 (12)
3.5. 功能测试 (12) 3.5.1. 运行 (12) 3.5.2. 注册 (12) 3.5.3. 登录 (13) 3.5.4. 注销 (13) 3.5.5. 应用的前后台切换 (14) 3.5.6. 免登入 (14) 3.5.7. 数据更新 (15) 3.5.8. 离线浏览 (15) 3.5.9. APP更新 (16) 3.5.10. 时间测试 (16) 3.5.11. 性能测试 (16) 3.5.12. 交叉性事件测试 (16) 3.6. 兼容测试 (17) 3.7. 用户体验测试 (18) 4.测试结果 (18)
1.测试概述 1.1.编写目的 本测试报告为招标手机APP的测试报告，目的在于总结测试阶段的测试情况以及分析测试结果，描述系统是否符合用户需求，是否已达到用户预期的功能目标，并对测试质量进行分析。 测试报告参考文档提供给用户、测试人员、开发人员、项目管理者、其他管理人员和需要阅读本报告的高层经理阅读。 1.2.测试范围 测试主要根据用户需求说明书和软件需求规格说明书以及相应的文档进行系统测试，包括功能测试、性能测试、安全性和访问控制测试、用户界面测试以及兼容性测试等，而单元测试和集成测试由开发人员来执行。 主要功能包括：用户登录、我的项目、推荐项目订阅、行业资讯、我的收藏、意见反馈、我的CA锁。 2.测试计划执行情况 2.1.测试类型
手机软件测试报告(模板)资料
技术文件 技术文件名称：XXX手机软件测试报告技术文件编号： 版本： 共页 (包括封面) 拟制 审核 会签 标准化 批准
目录 1概述...................................................错误！未定义书签。 1.1 编写目的................................................................................. 错误！未定义书签。 1.2 术语和缩略语......................................................................... 错误！未定义书签。 1.2.1 术语、定义：................................................................. 错误！未定义书签。 1.2.2 缩略语：......................................................................... 错误！未定义书签。 1.3 参考文献................................................................................. 错误！未定义书签。2测试任务说明 .. (2) 2.1 测试活动类别 (2) 2.2 测试级别 (2) 2.3 版本变更情况......................................................................... 错误！未定义书签。 2.4 测试任务列表 (2) 3测试环境描述 (2) 3.1 测试环境描述 (2) 3.1.1 硬件环境描述 (2) 3.1.2 软件环境描述 (3) 3.2 测试环境比较 (3) 3.3 其它说明 (3) 4测试故障描述 (3) 4.1 ××××测试模块 (3) 4.2 ××××测试模块 (3) 5测试结果分析 (4) 5.1 ××××模块测试结果分析 (4) 5.2 ××××模块测试结果分析 (4) 5.3 总体测试结果分析 (4) <2.按实现结果统计：> (4) 6测试结论 (5) 7测试总结和评价 (5) 7.1 测试评估 (5) 7.2 测试总结和改进建议 (5) 8遗留问题报告 (5) 8.1 遗留问题统计 (5) 8.2 遗留问题详细列表 (6) 附录1：测试现场记录 (7)
性能测试报告模版
目录 第1章概述 (1) 第2章测试需求分析 (1) 第3章测试场景设计 (4) 第1章概述 1.1目的 说明为什么要进行此测试；参与人有哪些；测试时间是什么时候；项目背景等。 编写此测试方案的目的是通过测试确认软件是否满足产品的性能需求，同时发现系统中存在的性能瓶颈，起到优化系统的目的。测试的依据是产品的需求规格说明书；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。此模板使用于性能测试的方案设计和测试报告记录。 1.2名词解释 此方案中涉及的业务和技术方面的专业名词。 1.3参考资料 此方案参考和依据的所有文档。 第2章测试需求分析 2.1测试目的
说明此测试的目的。例如： 1、IAGW增加了短信过滤功能和鉴权功能，需要执行性能测试，得出系统的性能指标； 2、持续进行大压力测试，对系统进行稳定性测试。 2.2测试对象 说明被测试产品的名称，版本，特性说明。 比如： Product Name: IAGW License Version: v1.1 Build Date: 20060715 2.3系统结构 简要描述被测系统的结构。 2.4测试范围 2.4.1测试范围 如：XXXX系统各项性能指标，软件响应时间的性能测试、CPU、Memory的性能测试、负载的性能测试（压力测试） 2.4.2主要检测内容 如： 1. 典型应用的响应时间 2. 客户端、服务器的CPU、Memory使用情况 3. 服务器的响应速度 4. 系统支持的最优负载数量 5. 网络指标 6. 系统可靠性测试 2.5系统环境
说明测试所需要的软硬件环境。 2.5.1硬件环境 2.5.2软件环境 2.5.2.1测试软件产品 主要说明被测试的软件产品模块名称和各模块分布情况。 2.5.2.2测试工具 说明所使用的测试工具。 第3章测试场景设计 3.1场景1 说明测试执行时的业务操作情况。相当于Use Case。不同场景下，将得到不同的测试结果。因此性能测试的结果必须与场景关联。例如： 测试IAGW在不与其他Server通讯的情况下，多用户并发访问交易响应时间<3秒的限制下，系统每秒钟处理的最大短信条数。 3.1.1测试目的 说明此场景测试的目的。例如： IAGW每秒钟处理最大短信条数。 3.1.2测试配置 说明该测试所使用的配置
手机app测试方法
1 APP测试基本流程 1.1流程图 仍然为测试环境
1.2测试周期 测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周（即15个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.3测试资源 测试任务开始前，检查各项测试资源。 --产品功能需求文档； --产品原型图； --产品效果图； --行为统计分析定义文档； --测试设备（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）； --其他。 1.4日报及产品上线报告 1）测试人员每天需对所测项目发送测试日报。 2）测试日报所包含的内容为： --对当前测试版本质量进行分级； --对较严重的问题进行例举，提示开发人员优先修改； --对版本的整体情况进行评估。 3）产品上线前，测试人员发送产品上线报告。 4）上线报告所包含的内容为： ---对当前版本质量进行分级； ---附上测试报告（功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果）； --总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。 2 App测试点 2.1安全测试 2.1.1软件权限 1）扣费风险：包括发送短信、拨打电话、连接网络等
2）隐私泄露风险：包括访问手机信息、访问联系人信息等 3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测 4）限制/允许使用手机功能接人互联网 5）限制/允许使用手机发送接受信息功能 6）限制/允许应用程序来注册自动启动应用程序 7）限制或使用本地连接 8）限制/允许使用手机拍照或录音 9）限制/允许使用手机读取用户数据 10) 限制/允许使用手机写人用户数据 11) 检测App的用户授权级别、数据泄漏、非法授权访问等 2.1.2安装与卸载安全性 1）应用程序应能正确安装到设备驱动程序上 2）能够在安装设备驱动程序上找到应用程序的相应图标 3）是否包含数字签名信息 4）JAD文件和JAR包中包含的所有托管属性及其值必需是正确的 5）JAD文件显示的资料内容与应用程序显示的资料内容应一致 6）安装路径应能指定 7）没有用户的允许，应用程序不能预先设定自动启动 8）卸载是否安全，其安装进去的文件是否全部卸载 9）卸载用户使用过程中产生的文件是否有提示 10）其修改的配置信息是否复原 11）卸载是否影响其他软件的功能 12）卸载应该移除所有的文件 2.1.3数据安全性 1）当将密码或其他的敏感数据输人到应用程序时，其不会被储存在设备中，同时密码也不会被解码 2）输人的密码将不以明文形式进行显示 3）密码，信用卡明细，或其他的敏感数据将不被储存在它们预输人的位置上 4）不同的应用程序的个人身份证或密码长度必需至少在4一8个数字长度之间 5）当应用程序处理信用卡明细，或其他的敏感数据时，不以明文形式将数据写到其它单独的文件或者临时文件中。以防止应用程序异常终止而又没有侧除它的临时文件，文件可能遭受人侵者的袭击，然后读取这些数据信息。 6）当将敏感数据输人到应用程序时，其不会被储存在设备中 7）备份应该加密，恢复数据应考虑恢复过程的异常通讯中断等，数据恢复后再使用前应该经过校验 8）应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告 9）应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告，更不能在安全警
手机整机测试标准
目录 1 简介 (2) 1.1目的 (2) 1.2适用范围 (2) 1.3责任 (2) 2手册内容 (2) 2.1测试项目 (2) 2.1.1电性能测试 (2) 2.1.2ESD测试 (2) 2.1.3软件功能测试 (2) 2.1.4用户试用 (2) 2.1.5场地测试 (2) 2.1.6环境测试 (3) 2.1.7寿命测试 (3) 2.1.8机械强度测试 (3) 2.1.9包装成品测验 (3) 2.1.10其它测试 (3) 2.1.11附件（旅充、座充、电池、耳机）测试 (3) 3测试标准 (4) 3.1电性能测试标准 (4) 3.2功能/软件测试 (4) 3.3用户试用 (4) 3.4场地测试 (4) 3.5ESD静电测试 (4) 3.6环境测试 (5) 3.7寿命测试 (6) 3.8机械强度测试 (7) 3.9其它测试 (7) 3.10包装成品测试 (8)
1 简介 1.1 目的 制定整机中试过程中的测试标准。 1.2 适用范围 本手册适用于中试过程中的整机。 1.3 责任 中试工程师、品质工程师。 2 手册内容 2.1测试项目 2.1.1电性能测试 按照GSM规范和移动电话相关标准，测试手机的各项重要电性能指标； 2.1.2ESD测试 测试手机在静电环境中的性能； 2.1.3软件功能测试 测试用户手册规定的各项功能，以及模拟软件的极端使用条件，测试软件的性能； 2.1.4 用户试用 验证移动电话在移动网络上能否正常使用，互联互通，功能设计、人机界面等是否达到设计和用户使用的要求，分为普通用户试用和专业用户试用； 2.1.5 场地测试 在各地网络环境，实地测试手机的功能及网络兼容性；
手机性能测试报告
手机性能测试报告 系：信息 班级：041 指导教师：李国力 本报告是我同肖钢同学一起合作完成的。由于条件限制，我们只是通过测试相同的项目来对比两个版本的性能差异，实验项目有基本功能、游戏流畅性、响应时间、CPU 负载、内存使用等。我们所做的实验测试，只对存在差异性的项目进行报告结果，对其它有相同结果的项目没有列到本报告中。在实验中分别是对安卓和苹果二种手机进行了测试。 第一个成果：测试项及测试结果： 第二个成果是：使用超级兔子系统评测的结果： 序号 测试项 功能名称 RAM256版 RAM512升级版 差值\优势机 1 基本功能 通话，短信，浏 览器 正常 正常 相同 2 安装20个软件用时 第三方软件 1000秒 300秒 700秒/RAM512 升级版 3 启动游戏 Angry bird 20秒 12秒 8秒/RAM512升级版 4 游戏后台 Angry bird 不能后台（内存不足引起） 能后台 RAM512升级版 5 5小时并发测试 音乐、QQ ，Angry bird Angry bird 出现2次错 误 正常 RAM512升级版 6 运行游戏 的流畅性 Angry bird ， NFS Shift ，水果 忍者 RAM512升级版 测试项 RAM256版 RAM512升级版 差值/优势机 1 RAM 性能 88 98 10/RAM51 2 2 CPU 整数性能 179 199 20/RAM512 3 CPU 浮点性能 15 16 1 4 2D 绘图性能 234 23 5 1 5 3D 绘图性能 395 454 60/RAM512 6 数据库IQ 性能 120 140 20/RAM512 7 SD 卡写入速度 55 55 0 8 SD 卡读取速度 161 161
XX系统性能测试报告
XXXX系统性能测试报告
1 项目背景 为了了解XXXX系统的性能，特此对该网站进行了压力测试2 编写目的 描述该网站在大数据量的环境下，系统的执行效率和稳定性3 参考文档 4 参与测试人员 5 测试说明 5.1 测试对象 XXXX系统
5.2 测试环境结构图 5.3 软硬件环境 XXXXX 6 测试流程 1、搭建模拟用户真实运行环境 2、安装HP-LoadRunner11.00（以下简称LR） 3、使用LR中VuGen录制并调试测试脚本 4、对录制的脚本进行参数化 5、使用LR中Controller创建场景并执行 6、使用LR中Analysis组件分析测试结果 7、整理并分析测试结果，写测试总结报告 7 测试方法 使用HP公司的性能测试软件LoadRunner11.00，对本系统业务进行脚本录制，测试回放，逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调用各前台测试，发起 各种组合业务请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。录制登陆业务模块，并模拟30、50、80、100 个虚拟用户并发登陆、添加和提交操作，进行多次连续测试，完成测试目标。 测试评估及数据统计 此次测试通过同一台客户机模拟多个并发用户在因特网环境进行，未考虑因特网的稳定 性的问题。此次测试用户操作流程相对简单，只录制了三个事务，即：用户登录、添加和信息提交，从测试的数据来分析，各项性能指标基本在可控的范围之内。但在测试过程中也发 现一些不容忽视的问题，应予以重视。 1 、模拟80 个用户并发操作时，出现1 个未通过的事务，具体原因需结合程序、网络和服务器综合分析，系统的稳定性并非无可挑剔。 2 、用户登陆事务的平均响应时间与其他两个事务相比等待的时间要长，且波动也较大， 在网速变慢、用户数增加的外部条件下，有可能会影响到系统的稳定性。建议优化系统登录页面程序，提高系统的稳定性。
测试手机APP流程规范标准[详]
关于手机APP 测试流程规范 1、流程图 不符
仍然为测试环境进入正式环境
测试周期 测试周期一般为两周（10个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.1测试资源 测试任务开始前，检查各项测试资源。 1.产品功能需求文档 2.产品原型图 3.产品效果图 4.行为统计分析定义文档 5.测试设备（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1 及以上；Symbian v3/v5/Nokia Belle等） 6.其他（例如有秒杀专题的项目，需要规划秒杀时间表；有优惠券使用的 项目，需要申请添加优惠券数据；支付宝/银联支付功能的项目，需要提前申请支付宝/银联账户等等） 1.2测试要点 1.接收版本 A）接收测试版本的同时，需要查看程序填写的《App测试版本提交质量规范》，若符合则开始测试任务，若不符合规范，可拒绝测试。 B）日常接收版本时需要注意测试版本规范，如不符合，请开发人员重新修
改合适的版本号后再次提交测试。 2.UI测试 A）确保手头的原型图与效果图为当前最新版本。 B）确保产品UI符合产品经理制定的原型图与效果图。 C）一切界面问题以效果图为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。 D）由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型 3.功能测试 A）确保手头的功能需求文档为当前最新版本。 B）确保所有的软件功能都已实现且逻辑正常。 C）一切功能问题以需求文档为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。 D）若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现，必须得到产品经理的确认，而不是单单只听开发人员的 技术解释。 E）PMS上所有的“外部原因”问题，都需要尽早地督促开发人员与客户服务端人员联系协调解决。 F）PMS上所有的“设计如此”、“延期处理”问题，都需要和产品经理确认后再进行验证。 G）测试下单时，所有测试人员必须严格遵守《测试单下单规范》标准。 注册的测试账号必须符合公司规范；收货地址必须包含“测试”关键
版本发布测试总结报告 特
测试总结报告 _SMAIL1.2.2.001_CPORTAL 卓望数码技术（深圳）有限公司版权所有 内部资料注意保密
修订记录：
目录 1 概述 (4) 1.1 上次报告的遗留问题 (4) 1.2 本次报告的范围 (4) 1.3 参考资料 (7) 2 测试记录 (8) 2.1 活动简述 (8) 2.2 测试环境 (8) 2.3 案例执行记录 (9) 2.4 缺陷记录 (10) 3 测试分析 (11) 3.1 测试覆盖情况分析 (11) 3.1.1.1 测试场景一：注册 (11) 3.1.1.2 测试场景二：登录综合请求 (11) 3.1.1.3 测试场景三：综合业务请求 (11) 3.1.1.4 测试场景四：登录适配下载请求 (12) 3.1.1.5 测试场景五：登录上传请求 (12) 3.1.1.6 测试场景六：登录升级请求 (12) 3.2 缺陷分析 (13) 3.2.1 缺陷收敛点分析 (13) 3.2.2 修复但没有验证缺陷分析 (13) 3.2.3 未修复缺陷 (13) 3.3 其它角色意见 (15) 3.3.1 项目组对遗留问题的意见 (15) 3.3.2 系统集成对遗留问题的意见 (15) 3.3.3 其它人员对遗留问题的意见 (15) 4 总结 (15) 4.1 后续活动和建议 (15) 4.2 结论 (16)
1概述 超级邮箱是集成手机网盘、通信、超市为一体的手机客户端软件. 其基本组成包括： 内部网元：CPPS/CPORTAL/MGROUP/手机客户端(KJA V A版和S60版) 等 外部网元：内容适配平台/网盘服务器/UC服务器/点卡服务器/彩铃平台等 本报告主要针对于手机客户端后台cportal。 1.1上次报告的遗留问题 无 1.2本次报告的范围 本次测试的版本号 本次测试版本为： SMAIL1.2.2.0_CPORTAL SMAIL1.2.2.001_CPORTAL（包含SMAIL1.2.2.0的所有功能）本次测试： CPORTAL（1.2.2.0）包括如下Build的测试： SMAIL1.2.2.0_CPORTAL_SSYT_1__20080602_16.33.58 SMAIL1.2.2.0_CPORTAL_SSYT_2__20080604_13.49.18 SMAIL1.2.2.0_CPORTAL_SSYT_3__20080610_17.34.20 SMAIL1.2.2.0_CPORTAL_SSYT_4__20080612_17.29.06 SMAIL1.2.2.0_CPORTAL_SSYT_5__20080623_17.55.49 SMAIL1.2.2.0_CPORTAL_SSYT_6__20080627_17.23.12 SMAIL1.2.2.0_CPORTAL_SSYT_7__20080708_14.33.51 SMAIL1.2.2.0_CPORTAL_SSYT_8__20080710_18.46.17 SMAIL1.2.2.0_CPORTAL_SSYT_9__20080717_18.42.06 CPORTAL（1.2.2.001）包括如下Build的测试： SMAIL1.2.2.001_CPORTAL_SSYT_1__20080714_18.36.16 SMAIL1.2.2.001_CPORTAL_SSYT_2__20080717_18.45.48 SMAIL1.2.2.001_CPORTAL_SSYT_3__20080723_11.29.20
手机app测试经验总结
手机上a p p测试总结 / / 上的app分为基于HTML5的app（类似于pc上的b/S应用）和本地app（类似于 C/S结构）。 所以上我们也可以充分吸收的b/s和c/s测试经验。但是不同于pc上的应用测试，手机上的测试有其独特性 测试前的思考：我们这个产品主要是做什么的为什么我要做这个产品市场上有那 些同类型的产品 测试前的准备：1.使用同类型的产品，不仅仅是使用，应该是测试同类型的产品。2.熟悉我们产品的spec文档，积极和pm交流。3，写，没有时间至少要有一个checklist。 1.功能 a.基本功能，主要指app是否完成了设计的所有功能。分清模块，写一份checklist，避免漏测。考虑横竖屏切换，不过很多app现在只支持竖屏。 b.系统交互:电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等， 2.性能:稳定性，兼用型（android碎片化是个难题，bug也多，ios相对bug少），app运行的内存消耗和cpu消耗，app后台长时间运行的耗流量，耗电量。 推荐testin这个第三方平台，对android兼用性测试比较有帮助。 3.易用性：面是否吸引人、容易理解。界面整洁、简单。无错别字。点击范围确 定等。这部分测试中，如果测试认为有不合理的地方通常会提交需求bug。 4.外场：网络切换，网络信号强，弱下的app运行情况。
对自动化的一些看法： 目前我们可以接触到手机方面的自动化工具：robotium，monkey，monkeyrunner，androidjunit。但是由于ui变化快，往往不方便维护。前三个不需要源码支持，但是功能有限，androidjunit很强大，对代码能力要求高，同时需要源码支持。app的开发周期一般都很短，ui变化大，用自动化要考虑投入成本，大多数的公司估计都不适用。不过测接口之类的通过自动化是个不错的选择。 转，说得多有道理的。 1.移动开发节奏很快，版本快速迭代，如何让测试起来？ Monkey：我建议放弃完全得 Case。全部用feature list或者测试思维导图或者功能点划分表来进行引导得测试。主要目的不会漏掉功能点以及防止regression 得bug。其次要敏捷必须要有自动化得支持。关于这点就是根据不同得app进行定义了。首先UT无论如何就要做起来。其次是api和regression test得自动化要做起来。当然CI也一定要搭建的。 2.移动应用测试，如何更全面的保证产品质量如何让用户参与到测试中来？Monkey：更全面得保证产品质量。如果要说到全面，那么必须就是功能，压力，性能，安全，用户体验面面具到了。其实还是和我第一个问题说得一样。将app 结合os得特性分层进行逐个得测试或者自动化测试。关于让用户参与到测试中来的话。我建议可以将不同的用户集合起来，qq或者weixin保持联系。然后android 可以定期发布内测版本，ios可以发布testflight版本。 3.用户反馈问题建议非常多，如何做好有效管理、分析和反馈？
手机游戏测试总结
手机测试的经验总结 查看( 35 ) / 评论( 0 ) / 评分( 0 / 0 ) 1．在提交高通前务必要检查文档与实际程序的功能表现是否相同，比如说，游戏增加了密技功能，在文档中就要有相应的说明。 2．在模拟器上图像处理速度较快，所以不会出现游戏中移动的图像变模糊的现象，但是由于手机的分辨率相对低，所以一般在模拟器显示正常的速度，到了手机就应该让开发人员适当调慢，否则将会出现移动物体变模糊不能清晰辨认的情况。 3．有些游戏使用了很多的图片资源，当在两个界面之间（例如在主菜单界面和帮助界面之间，主界面菜单是由许多图片组成的，帮助界面是一个html文件的浏览显示），连续按若干次使其在两个界面之间连续切换，会出现图像重叠现象，其原因是手机的CPU处理速度跟不上刷新速度，而且主界面的图片资源一直没有释放，导致图像的残留。一般可模拟Grinder把这些类似的问题测出来。 4．是否正确处理来电。如果没有适当正确的来电处理，有些来电会使游戏画面变乱，有些直接退出，甚至死机。Brew程序员往往会在来电处理后的恢复中忘了对游戏音乐的处理，比如说原先选择了关闭音乐的，来电处理后音乐又自动开始播放了。有时候需要模拟两个或以上的连续的来电以发掘程序深层的逻辑错误，这些错误大多是来电处理后的恢复过程的错误。另外短信，电量不足等一些事件警告的出现也有可能导致程序出错，也要作出相应的处理。 5．注意确保游戏说明和帮助的完整清晰，检查系统提示信息，确保在游戏中出现的文字的正确拼写，没有错别字。要尽量用敬称“您”而不用“你”。 6．标题，菜单等的文字显示要尽量用小字体，尽量缩短文字，能用简短文字说明清楚的就不要用长句，例如“按2，4键可以左右移动图片”就可改成“按2，4键左右移动图片”，或者甚至改成“按2，4键移动图片”。因为不同的手机显示屏幕宽度不一样，在一款手机上显示正确不代表在其他款式都能正确显示，然而用小字体，短句子就能适应大多数手机的屏幕宽度。 7．线程的处理，有些游戏设有多个线程，如果没有处理好线程的调用释放问题的话，就很可能出现线程争用的问题。例如一个宠物游戏，宠物死亡后，会调用一个新的线程循环播放哀吊音乐，有些程序员由于粗心大意忘记了释放这个线程，当重新开始游戏时，就会出现这个线程播放的音乐与游戏过程的背景音乐交替播放的情况。 8．文件处理。当涉及文件读写操作的时候，要特别注意测试文件操作带来的内存问题。比如说，有些游戏需要用文件记录游戏最高分或分值等，要注意测试第一次运行程序时的退出操作（此时没有最高分记录或其他分值记录），程序是否申请了文件指针或文件资源而没有释放。如果是的话，则会导致退出时的内存错误。另外对于Brew，应用程序的文件包中不得包含零字节的文件，每个文件至少有一个字节，同时还要求不能包含无用的文件或文件夹，目的是节省手机上有限的存储资源。
手机测试人员个人工作总结
手机测试人员个人工作总结 总结是对取得的成绩、存在的问题及得到的经验和教训等方面情况进行评价与描述的一种书面材料，它可以明确下一步的工作方向，少走弯路，少犯错误，提高工作效益，快快来写一份总结吧。总结怎么写才能发挥它的作用呢？以下是帮大家的手机测试人员个人工作总结，欢迎大家分享。 1.培养个人素质： A）对工作一丝不苟的谨慎态度和一如既往的高昂热情。 B）探索精神，打破沙锅问到底。 C）追求完美，创造性思维，想出富有创意甚至超常的手段来寻找缺陷。 D）善于表达观点，并组织好语言，描述操作过程应做到通俗易懂。 2.认识职责所在：
A）测试用例、测试计划的编写，测试资源、测试质量的协调保证。 B）测试执行，部分自动化测试、性能测试。 C）国外、国内，外场测试的支持。 测试的目的是为了发现尽可能多的缺陷，这个观念很容易让人接受，但是却很难落实到实际工作中，因为测试的目的常常被定位为“证明软件没有问题”。软件质量是否优良在投产后才能有所体现。 正确理解测试的目的十分重要。如果认为测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地设计很多不易暴露错误的测试示例，这些测试用例恰恰证明软件实现了预期功能，这样的测试是不真实的。成功的测试在于发现了迄今尚未发现的缺陷。 1.项目需求评审： A）评审原则：检查需求的正确性，无歧义性，完整性，一致性，可执行性，可验证性，可修复性，可追溯性。不要只检查文档的.表
面文字和界面，要深入思考，该功能是否符合逻辑，敢于提出问题。 B）评审要点：是否描述可输入/输出值的属性，如边界值，度量单位，时序要求等。是否描述清楚软件模块与模块间衔接处的处理情况及返回值。专用名词是否一致性等等。 2.制定测试计划 A.对测试项目进行划分进程，明晰在某个时间应该完成某个测试任务。尽量细分测试阶段及人员分配。 B.了解、收集并测试所需的资源。 C.制定可用度量指标定义的测试成功条件。 3.设计测试用例： A）基本要素：测试目的、前提条件、输入数据或操作过程、期望的响应。 B）不同的测试例其用途应当不同，不要冗余。
app测试报告范文(20200505190910)
app测试报告范文 app测试报告范文【1】 一、引言 手机软件的自动化测试一直困扰着手机软件测试从业人员，本文将最近的一些研究新发现及具体思路作详尽阐述，希望能给予大家更多的参考萌发新的思路。 通过长期的手工测试得出如下可以以自动化测试来解决的问 题： 1. 压力测试：一些连续不断的操作，比如反复切换歌曲播放 及联网操作等； 2. 极限临界测试：一些极限条件的构造（创建多个列表）及 输入字符个数等； 3. 兼容及中断：比如在播放或下载歌曲的时候来电话或者信息； 4. 基本功能回归测试：这样大大的节约了时间和人力成本。 对于以上的测试很多也是可以通过手工来完成，但部分测试采用手工测试是不可靠的，比如最近发现一个Bug（在联网的一瞬间如果来一个信息等中断操作出现死机），类似这种Bug出现条件非常苛刻和临界的情况在手工测试中是很难发现和构造这种测试环境的，即使发现了在很大程度上也属于一种偶然，同时给开发人员定位这个问题也带来了很大的困难。 面对诸多因素，我们不得不重视手机软件的自动化测试研究。
其实如果掌握了一些自动化测试要领，从简单入手，逐步实现和突破，相信一定能够解决手机软件自动化测试的难题。 二、自动化测试原理 1. Test Agent Test Agent为嵌入在手机软件系统中的一个测试代理模块， 解决PC端与手机端交互处理及互联消息通讯问题，这是区别于其他 桌面软件自动化测试的关键点，也是嵌入式软件自动化测试的主要特征之一。通过串口或蓝牙设备与PC端中的Test Tool建立通讯，其具备的主要功能如下： 1) 接收Test Tool发送的消息并向手机端软件系统分发消息及任务 2) 监控手机端软件运行情况并根据相应的约束反馈给PC端的Test Tool 3) 被测软件的功能（接口）封装及消息响应 2. Test Tool Test Tool自动化测试工具在PC端用于测试控制及测试操作实体，与Test Agent对应，该工具与常规的自动化测试软件一样， 其具备的主要功能如下： 1) 向手机端Test Agent发送可识别的消息及任务 2) 接收来自手机端Test Agent的反馈结果 3) 对来自手机端Test Agent的反馈进行测试业务的处理 4) 将测试业务的处理结果呈现给测试人员
Iphone性能比拼测试总结
2011-10-21
Security Level:
iPhone测试总结 iPhone测试总结
https://www.360docs.net/doc/cf9674393.html,
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
内
容
测试情况介绍 测试情况介绍 情况介 接收性能 系统间切换及重选 统间切 及重选 接通和掉话 接通和掉话 数据业务测试 数据业务测试
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 2
主要进行的测试项目
接收信号强度和质量对比 RSCP对比测试 Ec/Io对比测试 2/3G切换重选对比 切换重选对比 2-3重选时间对比测试 3-2切换时间点对比测试 iPhone4 语音业务对比测试 数据业务性能对比 数据业务速率测试（speedtext） iPhone性能专题分析 性能专题分析
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
Page 3
参与测试的3G商用终端
Sumsung-SGH-F480
iphone-3G(S)
HTC-P3600
索爱K800i 索爱
ZTE-T6
Sumsung-SGH-F408 iphone-4
HTC-Diamond2
Nokia-N97 Nokia-6500s Nokia-5800 Nokia-N95 HW-U3300
Page 4
HW-U120E
HUAWEI TECHNOLOGIES CO., LTD.
Huawei Confidential
手机软件测试实习报告
河北工业大学 毕业实习报告 姓名： XXX 学号： 093532 专业班级： XXXXXXXXXX 实习单位：北京北阳电子技术有限公司 实习时间：2011年2月14日—2O11年4月1日 指导教师： XXX
一．实习目的：理论联系实际，通过把所学软件测试知识与实际操作相结合，熟练软件测试操作流程，根据实际操作总结学习中的错误认识，拓 展思维方法并学习实际业务流程中的相关技巧和同事之间的相处 问题。 二．实习时间：2011年2月23日——2011年4月1日 三．实习地点：北京海淀区上地三街中黎科技园1号楼5层 四．实习单位：北京北阳电子技术有限公司 五．实习内容： 1.公司背景 北京北阳电子技术有限公司成立于1997年，地处属国家级高科技园区的北京上地信息产业基地，系高新技术企业，已先后经北京市科委评审被认定为软件企业和集成电路企业。 作为台湾凌阳科技股份有限公司在中国大陆的合作伙伴，北阳电子带着“科技落实生活”的愿景，致力于微控制器、数字信号处理器（DSP）应用与开发，以及系统工具软件、消费类娱乐产品和家庭网络产品的开发和研制，并实现通讯及多媒体技术的商品化，使人们能够享受到高科技带来的舒适、便利与欢乐，从而提升人们的生活品质。 2.平台构建 围绕经营理念的实现，北阳电子在主营高新技术原动力驱动下，打造出与之相适应的系列平台，诸如技术研发、知识管理、品质管理、智权产出、技术推广以及企业管理等平台。 在这些平台上伴随着资源的有效管理和知识、智慧的混合运作，高速、高效的载着源源不断的富创意、优品质的技术研发和推广的成果，为给客户一流的产品开发方案和满意的技术服务提供了保证，亦为北阳无可替代的优势打下坚实的基础。 3.团队建设 多年来北阳公司一直致力于团队的基础建设，从创业伊始的三、五十人发展至今已建成一个具有相当规模的研发、品保、知识产权、技术推广以及技资管理等团队的正规专业型企业。每一团队，都在公司有着举足轻重的位置，其作用一环扣一环，缺一不可。团队之间的通畅协作，不仅增强团队本身战斗力，而且亦增
手机黑盒测试测试方案与测试报告
手机黑盒测试测试方案与测试报告 1
学号: 08202138 班级:B7082021 专业:软件工程 姓名:申金萍 2
手机黑盒测试测试方案和测试报告 1、简介 手机作为专用的消费类电子产品需要进行以下测试:可靠性测试(对于硬件则是RQT;对于软件则是field trial);标准符合性测试(FTA);互操作性测试(IOT);安全性测试(安规测试);强度测试等。 1.1编写目的 1.由于现在软件的规模越来越大,一个人或者少数几个人已经不可能在一定的时间内完 成一个软件,因此软件开发的过程越来越复杂,层次越来越深。这就导致开发人员之 间的沟通有了一定的隔阂。因此,软件测试越来越有单立出来的必要和重要性。 3
2. 由于软件开发的过程的复杂性,软件必然存在着无数的Bug。而 且大多数是在软件上 市前必须解决的,而开发者有不定能发现这些问题,故而测试就显得非常必要。测试 是开发成功的必要保障。 3. 由于软件开发的层次性,因此开发的结果很可能与初衷不一样,这就需要测试者去发 现这些差异。因此,测试是软件成功的重要保证。 4. 软件不但要实现一些功能,更要完善它的性能。这就需要测试人员对软件进行评测, 从而不断地完善软件的性能。 1.2项目背景 在计划制定好之后,在执行之前,必须将测试所需的人力资源,硬件资源,软件资源,文 档资源以及环境和人文资源准备充分。 1.3术语 时间相关的性能测试可分为长时间保持测试和限定时间反应测试。 次数相关的性能测试是测试终端重复稳定地进行某项功能的能 力。 4
并发测试主要是测试终端同时进行多项业务时表现出的处理能力。 负载测试主要是验证系统的负载工作能力。 2、测试概要 2.1测试用例设计 5
新版手机性能测试-新版.pdf
android手机性能测试 测试工具DDMS（Dalvik Debug Monitor Service） 安装与配置 1、首先安装JDK，1.5以上的版本（目前java vuser不支持JDK1.7） 2、在安装完JDK 后，就需要下载及安装Android SDK，即： android-sdk-windows，压缩 包大约有551M左右 3、解压缩android-sdk-windows，放在C盘的根目录下，配置系统变量path 的值为：C: \android-sdk-windows\tools 启动DDMS 1、可以在开始--运行中进入DDMS 2、也可以在C: \android-sdk-windows\tools目录下启动ddms.bat 连接DDMS 1、使用数据线连接安卓系统的手机，确认手机是处于“USB调试”模式。 a)在手机上按下“Menu”键，在弹出的菜单中选择“Setting（设置）”； b)选择“应用程序”； c)在此界面勾选“未知来源”，然后选择“开发”； d)勾选“USB调试”，“保持唤醒状态”； 2、在ddms的左边框中会显示手机已经打开的应用程序(APP)进程，如果不显示，可以多连 接几次，或者换个手机试
操作DDMS 1、点击选中想要监测的进程，比如system_process进程； 2、点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标； 3、点击Heap视图中的“Cause GC”按钮； 4、此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况。 分析DDMS 如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的 对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断： 1、不断的操作当前应用，同时注意观察data object的Total Size值； 2、正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代 码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成 很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会 会落到一个稳定的水平； 3、反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每 次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大，直到到达一个上限后导致进程被kill掉。 4、此处已system_process进程为例，在我的测试环境中system_process进程所占用的内 存的data object的Total Size正常情况下会稳定在 2.2~2.8之间，而当其值超过 3. 55后进程就会被kill掉