敏捷测试的方法和实践：
有一次，当开发人员完成当前Sprint 任务的代码之后，测试人员、开发人员和产品经理一起来浏览产品、从头到尾走一遍，产品经理发现了问题，认为需要对功能进行比较大的修改。
这时开发人员估计需要两天时间才能完成代码，但测试人员反对这样做，我们本来只有5天测试时间，加上这次新做的功能比较多、开发代码质量不高，验收测试已经很紧张。如果再延迟两天，测试没法完成。产品经理说，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊！
什么是敏捷测试呢？敏捷测试当然不能简单地理解为测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：
?究竟什么是敏捷测试？
?敏捷测试有哪些流程改进？
?测试人员如何面对敏捷测试的挑战？
?在敏捷测试中如何制定相应的自动化测试策略？
什么是敏捷测试
假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，如图1所示。
图1 敏捷测试定义的形象描述
敏捷测试流程的优化
在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的主测试计划书，然后再建立每个功能任务的测试计划书，测试计划书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员（包括测试经理）讨论，最终得到大家的认可和签字才能通过，仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。
在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库（在线管理系统）中。在敏捷测试中，可能不需要测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有
功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如图2所示。
图2 敏捷测试流程简要图
在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：
?测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。
?参与代码复审（Code Review），并适当辅助开发人员进行单元测试。
?在流程中增加一个环节“产品走查（Product Walk-through）”——测试人员和产品经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。
新功能的测试和回归测试策略
测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有：
?不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。
?持续地进行验证，一旦某块新代码完成（Code Drop），就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。
?实施端到端（End-to-End）的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。
?阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。
?基于经验，可以实施更多的探索性测试、组合交互性（Interoperation）测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。
回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：
?通过执行Code Diff 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小。
?基于风险和操作面分析来减少回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。
?持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。
自动化测试策略
由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确的策略来提高自动化测试的效益，如图3所示，并说明如下。
图3 自动化测试的策略
?构建一个灵活的、开放的自动化测试框架，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。
?针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本，而大部分新功能测试采用手工测试
?集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。
?在产品设计、编程时就很好地考虑了自动化测试的需求，使全面的、自动化的底层测试、接口测试成为可能，尽量避免用户界面（UI）的自动化测试。
?良好的IT基础设施，包括自动化构建软件包、自动化版本验证（BVT）、自动化部署、覆盖率自动产生等。
敏捷测试工具
自动化测试依赖于测试工具，所幸的是，目前已有很多敏捷测试工具。由于篇幅所限，这里只是简单地列出一些常用的敏捷测试工具，不再深入讨论了。
?单元测试工具：TestNG、xUnit家族（如JUnit、NUnit）、JMock、BizMock等。
?功能测试自动化：ThoughtWorks Twist。
?Web功能测试（frontend）：Selenium IDE/RC、WatiR、WatiN。
?Web service测试工具（backend）：soapUI。
?性能测试：JMeter+BadBoy。
?验收测试框架：Fitnesse、Tellurium。
?敏捷测试过程管理工具：微软的Visual Studio 2010，包括TFS 2010、Scrum模板（MS VS Scrum 1.0）、Test Manager 2010、Coded UI Test等。
?业务智能（BI）应用的测试框架：Oraylis BI.Quality （+ NUnit）。
?其他一些协作工具等，如TestLink、BugZilla、BugFree、Wiki等。
测试人员在敏捷方法中的价值
在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？
?在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”
角色，强调用户体验，真正体现测试人员和开发人员的互补作用。
?测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。
?测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。
?在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（End-to-End）测试显得更为重要，测试人员在这些测试上能发挥更大的作用。?产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。
?一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。
理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换，如在当前版本开发中担任测试人员角色，在下一个版本开发中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发的效率和质量会有进一步的提高。
总结
根据上面的讨论和我们的实践，最后针对敏捷测试进行一个简单的总结，就是：
?敏捷测试就是持续测试、持续反馈，扮演“用户代表”角色，确保产品满足客户的需求。
?敏捷功能测试= 新特性的手工测试（Use Case验证和探索性测试）+ 原有功能的自动化测试（回归测试）。
?敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。
?敏捷测试流程依据不同的团队特点、不同产品的特点而不同，因地制宜，适合才是最好。
Petshop测试总结报告
目录 1.引言 (3) 1.1编写目的 (3) 1.2项目背景 (3) 1.3术语和缩写词 (3) 1.4参考资料 (3) 2.测试概要 (3) 2.1测试组织 (3) 2.2测试环境 (3) 2.3测试进度 (4) 2.4测试类型 (4) 3.测试结果及缺陷分析 (4) 3.1测试结果 (4) 3.2覆盖分析 (6) 3.2.1测试覆盖分析 (6) 3.2.2需求覆盖分析 (6) 3.3测试用例执行结果 (6) 3.4未决问题 (6) 4.综合评价 (6) 4.1软件能力与缺陷 (6) 4.2建议 (7) 4.3客户问题和建议 (7)
1.引言 1.1编写目的 对Petshop项目中所有的软件测试活动中，包括测试进度、资源、问题、风险以及测试组和其他组间的协调等进行评估，总结测试活动的成功经验与不足，以便今后更好的开展测试工作。 本系统测试总结报告的预期读者是： 开发部经理； 开发组所有人员； 测试组人员； 以及授权调阅本文档的其他人员。 1.2项目背景 Petshop项目主要以B/S架构形式实现在线购买宠物的功能，测试组需要依据需求规格说明书、测试方案、测试记录等及相应的文档进行系统测试，包括功能测试、性能测试、文档审核测试、用户界面测试、安全性测试、安装与反安装测试以及兼容性测试等。 1.3术语和缩写词 无 1.4参考资料 文档名称版本作者评审号/变更控制号备注Petshop需求规格说明书 1.0 YangGang Petshop测试计划 1.0 Test1 Petshop测试方案 1.0 Test1 Petshop测试记录 1.0 Test1 2.测试概要 2.1测试组织 角色（人数）姓名具体职责 测试人员Test1 测试策划：包括测试策略的确定、测试进度、资源的准备等； 测试设计：根据需求规格说明书完善测试方案，设计测试用例等； 测试执行：依据测试用例执行测试、跟踪测试过程，必要时回归 测试； 测试总结：对测试的过程和活动进行缺陷的汇总分析、经验总结 等； 2.2测试环境 机器类 硬件配置操作系统其它应用软件型
电性能测试报告Electronic Performance Test Report 拟制 (Tested by) 黄秋霞 (Qiuxia Huang) 日期 (Date) 2015-10-16 审核 (Approv ed by) Marey 日期 (Date)
目录 1 概述 (3) (Summary) 2 测试地点、时间、人员 (3) (Test place, Time, Personnel) 3 测试引用标准 (3) (Guide) 3.1 技术指标要求 (3) (Technical Norm Requirement) 3.2 测试方法 (3) (Test Criterion) 4 测试设备 (3) (Test Equipment) 5 结论 (3) (Test Result) 6 问题报告 (3) (Problem Report) 7 测试内容和结果 (4) (Test Items and Result) 7.1 常温环境电气性能测试 (4) (Electronic performance Test at Normal Temperature) 7.2 高温环境电气性能测试 (5) (Electronic performance Test at High Temperature) 7.3 低温环境电气性能测试 (6) (Electronic performance Test at Low Temperature) 8 附录 (7) (Appendix) 8.1 输出电流测试值 (7) (Output Current Test Values) 8.2 效率测试数据记录 (7) (Record of Efficiency Test Date) 8.3 电压调整率计算 (8) (Line Voltage Calculation)
报表测试方法总结 1.提高对业务的熟悉程度 和功能测试以及其他测试一样，报表测试也需要熟悉业务，包括业务流程、业务规则以及数据存储，不同点是报表测试要理解每个指标的算法、数据来源以及要明白具体的业务动作和指标之间的关系，例如：要统计保费收入，首先要考虑正常保单，其次要考虑批增、批减以及注销、全单退以及其他特殊批改，这些业务类型都可以对此指标的统计结果产生影响。所以如果不能分析业务动作和指标之间的关系，那就无法验证报表中数据的准确性。 2.数据准备 数据对报表测试来说是非常重要的问题，因为报表的基本功能就是通过各种查询统计分析的方法为用户提供准确的数据，帮助用户进行决策以及分析，所以在报表测试前要保证准备足够多准确、有效的数据。在实际测试的时候一定要覆盖到报表所要求的每个维度,要保证所有的指标都要有对应的数据，不能出现指标为零的情况，当然也不需要过多，只要覆盖了所有的类型就可以了。一下总结了两种数据准备的方法： 1>对测试后期比如冻结测试时产生的数据进行备份，用于报表测试，前提一定要保证 数据的原始性，不允许对任何人对数据进行修改； 2>自己手工对数据进行准备并且精心设计，要分析影响所测指标的各种因素，以及每 个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法，并且要考虑需 要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖,从而 来验证报表是否取到的该取的数据、没有取不该取的数据，并且最后计算出了正确 的结果。最后要将自己准备的数据用excel保存，并对数据的特点进行记录，以提 高测试时的效率，并可以减少回归测试工作量； 3.数据正确性验证 对于客户来说，使用报表就是期望通过报表系统这个平台能够快速简单的查到自己所需要的数据，所以测试报表最主要的内容就是要验证数据的正确性，总结方法如下： 1 > 要弄清楚数据的来源，来源于哪张表、哪个字段； 2 > 时间条件：统计区间具体应该以业务中的什么时间在卡，并且考虑需求中是否包括 统计区间的边界值； 3>要弄清楚所测表以及所测指标的特定条件，比如要统计2009-01-01——2009-01-31 这个月份所有代理业务，那特定条件就是将保单的业务来源要限制在代理业务中； 4>Sql准备，这个过程是将上面三个过程进行总结，也是后续和开发人员进行分析数 据的基础，所以提高自己编写sql的能力。另外当测试时间不充裕的情况下，对一
产品名称Product name 密级Confidentiality level K3 内部公开 产品版本Product version V100R001 Total 5 pages 共5页K3V100R001样机功耗测试报告 Prepared by 拟制 Date 日期 2009-4-22 Reviewed by 评审人Date日期Approved by批准Date日期Authorized by签发Date日期 Huawei Technologies Co., Ltd. 华为技术有限公司 All rights reserved 版权所有侵权必究 （TST05T01 V2.0/ IPD-PTM V2.0 / 仅供内部使用）
Revision record 修订记录 Date 日期Revision Version 修订版 本 CR ID CR号 Section Number 修改章 节 Change Description 修改描述 Author 作者 2009-4-22 1.00 initial 初稿完成
目 录 1.测试目标 (4) 2.功耗测试概述 (4) 2.1测试原理 (4) 2.2测试需求 (4) 3.测试结果 (4)
K3V100R001样机功耗测试报告 1.测试目标 z测试各个常用应用场景的平均电流值，测试数据与产品规格或标杆手机作比对； z为后续K3功耗测试和优化提供参考依据。 2.功耗测试概述 2.1测试原理 本次使用直流稳压电源KEITHLEY 2306提供3.70V电压为手机供电（特殊情况专门说明），每30秒钟积分一次，测试手机在各个常用应用场景的平均电流。 测试过程中SD卡、SIM卡在位，文件存放在SD卡中，其他设置均为出厂默认设置（有特殊要求的除外）。 2.2测试需求 名称型号 直流稳压电源 KEITHLEY 2306 Windows Mobile手机 K3样机 存储卡 2GB的Micro SD卡 SIM卡 中国移动GSM卡 Wireless Access Point D-Link DWL 2100AP 3.测试结果 ROM020NXF1092000135
变更历史记录
目录 [项目名称测试报告（标准版）] 0 [V1.0(版本号)] 0 [2010年9月9日] 0 第1章简介 (3) 1.1目的 (3) 1.2范围 (3) 1.3名词解释 (3) 1.4参考资料 (3) 第2章测试简介 (4) 2.1测试日期 (4) 2.2测试地点 (4) 2.3人员 (4) 2.4测试环境 (4) 2.5数据库 (5) 2.6测试项 (5) 第3章测试结果与分析 (5) 3.1对问题报告进行统计分析 (5) 3.2遗留问题列表 (7) 第4章简要总结测试的结果 (7) 第5章各测试类型测试结论 (8) 5.1功能测试 (8) 5.2用户界面测试 (9) 5.3性能测试 (9) 5.4配置测试 (9) 5.5安全性测试 (9) 5.6数据和数据库完整性测试 (9) 5.7故障转移和恢复测试 (9) 5.8业务周期测试 (10) 5.9可靠性测试 (10) 5.10病毒测试 (10) 5.11文档测试 (10) 第6章软件需求测试结论 (10) 第7章建议的措施 (10) 第8章追踪记录表格 (11) 8.1需求—用例对应表(测试覆盖) (11) 8.2用例—需求对应表(需求覆盖) (11)
第1章简介 测试报告的简介应提供整个文档的概述。它应包括此测试报告的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述等。 1.1 目的 阐明此测试报告的目的。 1.2 范围 简要说明此测试报告的范围：它的相关项目，以及受到此文档影响的任何其他事物。1.3 名词解释 列出本计划中使用的专用术语及其定义 列出本计划中使用的全部缩略语全称及其定义 表1 名词解释表 1.4 参考资料 本小节应完整地列出此测试报告中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和发布组织。列出可从中获取这些引用的来源。这些信息可以通过引用附录或其他文档来提供。
monkey测试方法总结 测试策略：全模块、单模块 测试步骤： 1、测试前准备: 1.PC侧安装adb驱动，使用adb shell命令不报错 2.手机设置:锁屏方式设置为无，屏幕亮度建议设成最低(防止电量消耗过大导致关机) 3.手机为刚刷的新版本或者进行一次恢复出厂设置 备注：或测试前请先删除自行安装的第三方:手机助手、测试工具apk等等 4.休眠设成最长时间或不休眠 5.设置-开发者选项中勾选不锁定屏幕 6.设置手机时间为当前正确时间 7.若要测试上网请连接可用wifi或打开数据业务 8.测试前需开启aplog*#*#201206#*#* 备注：测试前请确保日志功能开启，测试完成后先保存日志 adb root adb remount adb shell rm -rf /data/logs/* 作用就是删除以前的旧log 工具使用前请确定手机版本为debug版本，PC 的adb命令使用正常 附件解压到任意目录，双击InstalllogClient.bat会自动安装logClient客户端并重
启 手机配置: 1. 连接热点360WiFi-6CDC31，连接密码为xdjatest 2. 输入密码后勾选下面的高级选项-》将DHCP选项改为静态-》设置IP地址为11.12.112.196至199之间的IP，设置完IP直接点击连接，连接上热点后即配置完毕 2、测试执行： 先执行命令adb shell 再输入如下的命令: 全模块： monkey--throttle500--ignore-crashes--ignore-timeouts--ignore-security-exc eptions--ignore-native-crashes--monitor-native-crashes-v-v-v180000>/st orage/sdcard0/monkey_log.txt& 单模块： monkey-p.xdja.ncser--throttle500--ignore-crashes--ignore-timeouts--ign ore-security-exceptions--ignore-native-crashes--monitor-native-crashes-v-v-v180000>/storage/sdcard0/monkey_log.txt& 备注： 1、单模块命令加：-p模块包名； 2、测试9小时使用180000，测试18小时使用375000
博乐宝项目 测试总结报告 提交单位：上海科匠信息科技有限公司提交日期：2015 年02 月04 日
目录 第1部分测试概述 (3) 1.1测试目标 (3) 1.2 项目背景 (3) 1.3 测试对象 (3) 1.4 测试范围 (3) 1.5 测试工具 (4) 第2部分测试概要 (4) 2.1 测试机构和人员 (4) 2.2 测试策略 (4) 2.3 测试类型 (5) 第3部分功能测试过程及测试执行情况 (6) 3.1 测试约束 (6) 3.2 Bug数量统计 (6) 3.3 Bug严重程度统计........................................................................ 错误！未定义书签。 3.4 Bug类型统计................................................................................ 错误！未定义书签。第4部分缺陷分析 .. (6) 第5部分测试结论 (7) 5.1结果分析 (7) 5.2总结 (7)
第1部分测试概述 测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。 1.1测试目标 本测试报告为世强项目系统测试报告，目的在于总结测试阶段的测试情况以及分析测试结果，描述系统是否符合用户需求，是否已达到用户预期的功能目标，并对测试质量进行分析。 1.2 项目背景 项目名称：世强App项目 项目简称: 世强 委托单位： 开发单位：蓝色互动 1.3 测试对象 世强项目的pad及pc平台应用程序 1.4 测试范围 各个测试阶段的范围不同，整个测试阶段覆盖了软件系统的所有业务和功能。 1、单元测试（由开发人员执行）和功能测试阶段，测试范围是软件系统的主业务和路径；
电源测试报告 一、功率因数与效率测试 1、使用仪器设备：AC SOURCE(交流电源)、电子负载、万用表、功率表； 2、测试条件：输入电压220Vac,输入频率50Hz/60Hz,输出带最大负载1.7A、常温25℃； 3、测试方法： 1）、依规格设定测试条件；输入电压、输入频率、最大负载； 2）、从功率表中读取Pin and PF值，并读取输出电压计算Pout; 3）、功率因数=Pin/(Vin*Iin),效率=Pout/Pin*100﹪; 4、测试数据 二、能效测试 1、使用仪器设备：AC SOURCE(交流电源)、电子负载、万用表、功率表； 2、测试条件：输入电压220Vac,输入频率50Hz/60Hz,输出负载分别为1.7A，1.275A,0.85A,0.425A; 3、测试方法： 1）、在测试前将产品在标称负载条件下预热1分钟; 2)、按负载大小由大到小分别记录220V ac/50Hz/60Hz输入时的输入功率（Pin），输入电流(Iin),输出电压（Vo1,Vo2）,功率因数（PF）,然后计算各负载下的效率； 3）、在空载时记录输入功率与输入电流。 4、测试数据 三、纹波与噪声测试 1、使用仪器设备：AC SOURCE(交流电源)、电子负载、示波器； 2、测试条件：输入电压220Vac,输入频率50Hz/60Hz，负载分别为1.7A，1.275A,0.85A,0.425A，0A，常温25℃； 3、测试方法：按测试回路接好各测试仪器，设备，及待测品，测电源在各负载下的纹波与噪声； 4、测试数据及最大幅值的波形。 四、上升/下降时间测试 1、使用仪器设备：AC SOURCE(交流电源)、电子负载、示波器； 2、测试条件：输入电压220Vac,输入频率50Hz/60Hz，负载为1.7A；
. 文档编号：CIECC-EP-TP-0B3 [项目名称测试报告（标准版）] [V1.0( 版本号)] 拟制人______________________ 审核人______________________
批准人______________________ [2010 年9 月9 日] 中国国际电子商务中心 China International Electronic Commerce Center
变更历史记录 日期版本说明作者审核批准2010-09-09 1.0 首次建立项目测试报告（标准版）模 文建东 板
目录 [项目名称测试报告（标准版）] 0 [V1.0( 版本号)] 0 [2010 年9 月9 日] (1) 第1 章简介 (5) 1.1 目的 (5) 1.2 范围 (5) 1.3 名词解释 (5) 1.4 参考资料 (5) 第2 章测试简介 (6) 2.1 测试日期 (6) 2.2 测试地点 (6) 2.3 人员 (6) 2.4 测试环境 (6) 2.5 数据库 (7) 2.6 测试项 (7) 第3 章测试结果与分析 (7) 3.1 对问题报告进行统计分析 (7) 3.2 遗留问题列表 (10) 第4 章简要总结测试的结果 (10) 第5 章各测试类型测试结论 (11)
5.1 功能测试 (12) 5.2 用户界面测试 (12) 5.3 性能测试 (12) 5.4 配置测试 (12) 5.5 安全性测试 (12) 5.6 数据和数据库完整性测试 (13) 5.7 故障转移和恢复测试 (13) 5.8 业务周期测试 (13) 5.9 可靠性测试 (13) 5.10 病毒测试 (13) 5.11 文档测试 (13) 第6 章软件需求测试结论 (14) 第7 章建议的措施 (14) 第8 章追踪记录表格 (14) 8.1 需求—用例对应表(测试覆盖) (14) 8.2 用例—需求对应表(需求覆盖) (14)
中国联通鸡西分公司功率测试分析总结报告 2008年1月20日
测试目的：全面掌握现网不同厂家多期设备的输出功率，以及合路器、馈线损耗，为日后的故障定位、网络 优化调整提供理论依据。 测试方法： 在线测试 a)对现网西门子、华为、北电厂家的不同类型的TRX的 输出功率进行测试。 b)对西门子、华为厂家不同型号的合路器损耗进行测试。 c)对不同工期的馈线损耗进行测试。 测试人员：赵佳溪、王加玉、颐龙公司：关雷 测试地点：业务分配成功率低的小区、故障较高的小区。 测试时间：2007年12月－2008年1月 测试设备：Digital Power Meter 数字功率测试仪 型号:BIRD Model 5000-EX 分析总结时间：2008年1月17日－2008年1月20日
●概述 鸡西联通运行维护部无线及网优人员本着主动学习提高自身维护技能的原则，为全面掌握现网设备功率输出及损耗情况，并为今后的故障定位、优化调整提供理论依据，于2007年12月—2008年1月期间对现网业务信道分配成功率低和故障率相对较高的小区进行了在线对比测试。本次测试共涉及鸡密虎地区9期工程的19个站点45个小区功率测试。 附件一：功率W与Dbm换算关系 ●功率测试数据汇总分析 本次测试共计对GSM网络1期、4期、5期、6期、7期、9期、12期、13期、15期合计16个基站以及CDMA网络3个基站进行在线功率测试。 测试过程中发现，瓦数相同的载频输出功率也存在差异。为了查找其原因，无线及网络优化中心人员利用同一个基站同一个合路器带相同瓦数的不同载频进行多次在线测试，通过测试结果发现：即使相同瓦数的不同载频输出功率也存在微小的差异，而同一个载频在不同的时段进行在线功率测试，输出的功率也不相同。 详细的功率测试数据见附件二。 ●功率测试分析总结 通过对本次不同工期设备功率对比测试数据汇总、分析、研讨得出以下结论： 一、G网设备功率测试
精心整理软件测试工作总结编写规范 1. 目的 2. 适用范围 3. 术语和缩略语 4. 规范要求 5. 引用文件 6. 质量记录 1. 目的
精心整理 本文件规定了测试工作总结编写时应考虑的事项，通过测试工作总结来不断地积累测试经验，提高测试工作的整体水平。并对软件产品测试过程中发现的问题进行分析，为开发人员以后的修改、升级提供一个预防问题的依据。 2. 适用范围 本规范适用于软件项目与软件产品的功能测试与系统测试。 3.术语和缩略语 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 4.规范要求 4.1 测 4.2 在 5.引用文件 本程序采用 6. 项目名称（项目编号） （测试种类）测试工作总结
目录 1. 引言 (3) 2. 项目测试结果 (3) 2.1软件产 (3) 2.1.1软件产品名称及综合评价 2.1.2提交项目管理部门物品 3 3. 测试工作评价3 4. 软件问题倾向 4.1问题解决情况总结与分析 4.2 附录二：测试结束检查表
1.引言 说明参加本项目测试的负责人、参加人员、起止时间及实际工作量。 2.项目测试结果 2.1 软件产品 2.1.1 软件产品名称及综合评价：给出该软件产品的产品名称及对该软件产 品的综合评价。 2.1.2 总结测试工作内容并向项目管理部门提交测试结果 内 3.测试工作评价 3.1 3.2 发现问题数量： 3.3 析。 训。 4. 列出本次实际发现问题数量、解决问题数量、残留问题数量。并对残 留问题对系统功能的影响情况进行分析。 4.2 错误类型统计与分析 在对软件产品测试过程中发现的问题进行充分分析、归纳和总结的基 础上，由全体参与测试的人员完成软件问题倾向分析表，对该类型或 该系统软件产品在模块、功能及操作等方面出错倾向及其主要原因进
项目测试经验总结 说明：以下项目测试经验是我在原来公司工作中的实际经验，拿出来和大家一起交流。我相信之前的项目测试工作中有不少可以改进的地方，还希望大家多多交流。 项目测试经验 ——Judy Shen 本文是对我近几年测试工作经验的总结，并以简报的方式在研发中心内进行分享及交流。 1测试团队介绍 在介绍我们之前项目测试工作之前，需要首先介绍一下之前我所在团队的组织架构及测试人员在项目中的工作。 我们的测试团队属于质量改进中心下的测试部，它和研发团队属于两个不同的中心。测试团队有6个人，从图一可以看出来，一个人可以参与多个处于不同阶段的项目测试工作。 图一测试团队组织架构 参与项目的测试人员以测试组的形式进入项目，测试组和需求组、开发组并列。每个测试组有一个测试组长负责项目测试工作。项目经理不直接面对测试组成员，而是通过测试组长进行任务安排、协调、沟通。测试部经理知情测试人员的项目测试工作，项目测试组的工作汇报均需要抄送给测试部经理。如图二所示： 图二项目组织架构（旧） 上面说到的是旧的测试人员工作模式，在去年年底，为了有效利用公司测试人员资源，我们开始了测试外包的尝试。这里的测试外包模式是指，测试组不进入项目，而是由项目组将测试工
作以一个项目的方式分包给测试部，由测试部根据项目组提供的信息，进行计划、执行测试，并按照项目要求提交测试成果给项目组。 这个模式还在探索中，如图三所示，测试部经理直接负责项目的测试工作，测试组的工作情况抄送给项目经理。这种模式需要进行独立核算，包括成本估算、预算、结算等。但是这种模式的整体思路还不是很成熟，从这个组织架构上大家也可以看出来，很多东西还没有理顺，所以一直都处于尝试过程中。后面提到的内容，如果没有特殊说明，都是在旧的模式下进行的。 图三项目组织架构（测试外包方式） 我想不可否认，大家都认为测试人员应该是测试技术上的专家，但是，测试人员是否需要熟悉并擅长一定的业务呢？不管答案是什么都没有关系，但是我认为一个好的测试人员不仅是测试专家，他同时也是业务专家。有一些测试人员，因为系统的业务知识很复杂，就一头扎进去，几乎全力去学习业务知识，测试技术的学习和研究没有跟上，结果不是设计出大量冗余的测试用例，就是很多方面没考虑到，面对客户的不当请求，也没有底气说测试应该怎么做，弄得做起项目来辛苦异常，个个苦不堪言！ 有着样的说法：“软件测试人员要两条腿走路，左腿是测试技术，右腿是业务知识。只有两条腿的健壮差不多，走路才稳当。”出于这种思想的考虑，在原来的测试团队，我们每个人都有两个学习、研究方向，一个是技术方向，一个是业务方向。例如： ●技术方向： ?功能自动化测试 ?性能测试 ?单元测试 ?测试管理 ●业务方向： ?物流业务 ?智能交通 ?知识管理 但这种方式在工作开展上有些困难。如果公司认为测试人员应该绝大部分时间用在项目测试工作上，那么测试团队既要研究测试技术，又要挤出时间学习业务知识，在操作上是比较困难的。在我们以前的测试团队的工作中，有一部分工作时间是用来进行部门建设的，部门建设工作中包括前面说到的技术研究、业务学习，还有就是部门搭建所需要进行的一些工作（如部门制度建设）。当时公司允许我们团队有30%的工作量投入部门建设上。将部门建设工作分开，主要是用于统计部门成本和测试成本用的。 前面说到了测试人员是以测试组身份进入项目开展测试工作的，但不是每个成员上去都从事同样的工作。在进入项目组工作时，每个测试人员所充当的角色是不同的，项目的测试角色划分为以下四种，如表一所示。在实际工作中因为测试人员数量有限，所以经常是一个人担任多个角色。
单位名称：_________________________ 姓 名：_________________________ 日 期： _______年______月______日 测试工作总结报告 ——Summaring Experience, Carrying Over To Go Forward Striving for More Achievement 。
测试工作总结报告 测试工作总结报告 我最初参加测试工作的时候，不知道什么是软件测试，集成测试和系统测试的概念经常混淆，cmm 是什么就更加不知道了。那时候最简单的开关机也是通过直接拔插电源完成，安装系统对我来说简直是有史以来人类的最高技能，对于那些拿着螺丝刀安装机器的人就认为是宇内超级高手，身具杀人于无形之绝世秘技。拿破仑说不想当将军的士兵不是好士兵，我最初的梦想就是想成为软件测试的高手，傲视天下。所以不断偷师，总结经验，自认为掌握了成为高手的几个秘技，这几年混迹“江湖”还算无往而不利。不敢独享，望与吾辈测试人员切磋，早日总结成功密技之大成，助新进人员早日入门，也算不愧对东北活雷锋的称号。 第一招学会利用网络 刚参加工作面对浩瀚的网络世界，当时如刘姥姥进大观园，什么都新奇，什么都想要，从网上下载很多源程序的代码，软件技术文档之类，恨不得把所有的好东西收集到手中，其实有些在他人看起来就是垃圾一堆。当时觉得有了这些“武林秘籍”，成为高手指日可待。最初参加工作由于自己工作努力有幸转为开发，加入项目组后我的习惯还是没有改，反而变本加厉，手中的资源更加多，上网的时间更加频繁。 一次项目经理分配任务，觉得依靠手中的秘籍加上自己的 “聪明才智”很快会完成，不料短短的时间，所有的一切变成了马奇诺防线。解决问题很慢，思路
声场测试报告 一、设计规范及标准 根据舞台的基本使用功能和定位并参照国家相关的标准和规范： 音响扩声系统设计规范 WH/T38-2009《舞台扩声系统跳线柜、综合接线箱、地板接线盒设置规范》WH/T39-2009《专业音频和扩声用扬声器组件实用规范》 WH/T318-2003《演出场所扩声系统的声学特性指标》 JGJ 57-2000/J 67-2001《剧场建筑设计规范》； GB 4959-95 《厅堂扩声特性测量方法》； GBJ 76-84 《厅堂混响时间测量规范》； JGJ 16-2008 《民用建筑电气设计规范》； GB/T 14476-93 《客观评价厅堂语言可懂度的“RASTI”法》； （WH/T25-2007）《剧场等演出场所扩声系统工程导则》 GB/T 14197-93 《声系统设备互连的优选配接值》； ITU-R BT. 601-2 供演播室使用的数字电视编码标准； ITU-R BT. 711 供分量数字演播室使用的同步基准信号； GY/T 156-2000 演播室数字音频参数； GY/T 158-2000 演播室数字音频接口；
AES3 供数字伴音工程线性表示数字伴音数据的串行传输格式； AES11 供数字伴音工程在演播中使用的数字伴音设备的同步规格； GB 3174-1995 PAL-D 制电视广播技术规范； 二、多功能演播厅声场设计说明 根据场景布局、实用面积，结合系统功能现实（文艺活动兼报告型会议、培训等等），我们选择主/辅/超低/返听扩声模式进行声场扩声。 本系统采用了48路扩展性强、处理功能强大、兼容性好、个性化、多场景方便方便每个操作者和每场演出、无线调音功能的数字调音台为核心进行音频系统主控制，无线手持、无线头戴、人声/乐器、合唱、鹅颈电容会议话筒对人声进行拾取，随后将初次拾取到的人声信号（人声信号先进入数字调音台综合管理） 通过专用的传输线缆传输到调音台，接着输出到效果器进行初次音质处理、修正、根据使用环境适当的添加音频效果后输入至调音台进一步的对音质处理（增益、MIC 前置放大器、均衡、单/立体声输出等等），这时通过调音台末端输出到12进12出音频数字矩阵处理器，运用其内置功能进行处理（输入信号进行压限、延时、均衡等操作，此操作有益系统的正常运行、设备安全、声场音质的均匀），最后分频器进行音频信号处理分频，将音频电声信号一分为三进入扩声系统的信号电声放大部分，此部分是通过与扬声器技术参数相匹配的主/辅/超低频功率放大器对电声信号进行电功率放大，让音频可以有足够的功率去推相应的主/辅/超低频扬声器（也是系统的末端），对舞台这场区域，我们选配一对舞台返听扬声器，用均衡器进行音质处理（提升/衰减量程、增益调节、电压调节、信号动态调节等等），为场景提供一个高品质、高享受、高效率的优良声场。除此之外，为了提高系统的安全性与操作的方便性，还选配了一台电源时序器对整套系统电源进行管理，可以通过此设备对电源逐一逐一的进行安全开/关（一键到位）。为了增加文艺活动演出方便还配置了一套舞台演出内部通讯系统。
编码：TCWY-SPI-E-VER-T06 XXXXXXXX科技有限公司 测试总结报告
更改控制页
目录 1项目说明 (3) 2术语定义 (3) 3测试依据 (3) 4人员及进度 (3) 5测试概要 (4) 5.1测试环境 (4) 5.2测试用例 (4) 5.3测试方法 (4) 6覆盖分析 (4) 6.1需求覆盖 (4) 6.2测试覆盖 (5) 7BUG统计 (5) 7.1BUG汇总 (5) 7.2BUG分析 (5) 7.3遗留BUG (5) 8测试结论与建议 (6) 8.1测试结论 (6) 8.2测试建议 (6) 9评审意见 (6)
1 项目说明 天畅普通网络发票离线开具系统采用税务机关与运营商合作模式进行搭建，包含纳税人通过不同运营商，使用开具系统进行发票开具，国税局对网络发票的使用进行管理等功能。主要测试范围：1、发票管理：发票填开、空白发票作废、发票补打、切换开票点、切换发票段；2、查询统计：开具发票查询、开具项目查询；3、信息维护：纳税人信息维护、打印模版设置、客户信息维护、开票项维护、备注信息维护、厂牌型号维护、产地信息维护、车辆类型维护；4、系统工具：数据备份、数据恢复、日志查询、系统升级、升级说明、网络设置、系统选项； 2 术语定义 OS Operation System 操作系统 C/S Client/Server 客户端/服务器 B/S Browser/Server 浏览器/服务器 LR LoadRunner 负载测试工具 Testing environment 测试环境 3 测试依据 《天畅普通网络发票开具离线系统需求规格说明书》 《系统测试计划》 《系统测试用例》 4 人员及进度
软件测试标准规范 1目的 为了确保软件产品质量，使产品能够顺利交付和通过验收，特编写本文档，以作参考 2适用范围 本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 ?项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ?项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护 记录》。 ?测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ?项目负责人组织测试环境的建立。 ?项目经理审核负责控制整个项目的时间和质量。 ?研发人员确认修改测试人员提交的bug。 4工作流程 4.1测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2制订《测试方案》
在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容： ?测试目的； ?所需人员及相应培训要求； ?测试环境、工具和测试软件； ?测试用例、测试数据和预期的结果。 4.3单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。 ?单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； ?单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； ?单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4集成测试 编码开发完成，项目组内部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。
APP常用测试方法总结 一、安全测试 1.软件权限 1）扣费风险：包括短信、拨打电话、连接网络等。 2）隐私泄露风险：包括访问手机信息、访问联系人信息等。 3）对App的输入有效性校验、认证、授权、数据加密等方面进行检测 4）限制/允许使用手机功能接入互联网 5）限制/允许使用手机发送接收信息功能 6）限制或使用本地连接 7）限制/允许使用手机拍照或录音 8）限制/允许使用手机读取用户数据 9）限制/允许使用手机写入用户数据 10）限制/允许应用程序来注册自动启动应用程序 2.安装与卸载安全性 1）应用程序应能正确安装到设备驱动程序上 2）能够在安装设备驱动程序上找到应用程序的相应图标 3）安装路径应能指定 4）没有用户的允许，应用程序不能预先设定自动启动 5）卸载是否安全，其安装进去的文件是否全部卸载 6）卸载用户使用过程中产生的文件是否有提示 7）其修改的配置信息是否复原 8）卸载是否影响其他软件的功能 9）卸载应该移除所有的文件 3.数据安全性 1）当将密码或其它的敏感数据输入到应用程序时，其不会被存储在设备中，同时密码也不会被解码。 2）输入的密码将不以明文形式进行显示。 3）密码、信用卡明细或其他的敏感数据将不被存储在它们预输入的位置上。4）不同的应用程序的个人身份证或密码长度必须至少在4-8个数字长度之间。5）当应用程序处理信用卡明细或其它的敏感数据时，不以明文形式将数据写到其他单独的文件或者临时文件中。以防止应用程序异常终止而又没有删除它的临时文件，文件可能遭受入侵者的袭击，然后读取这些数据信息。 6）党建敏感数据输入到应用程序时，其不会被存储在设备中。 7）应用程序应考虑或者虚拟机器产生的用户提示信息或安全警告
1 引言 1.1编写目的 编写该测试总结报告主要有以下几个目的 1．通过对测试结果的分析，得到对软件质量的评价 2．分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考 3．评估测试测试执行和测试计划是否符合 4. 分析系统存在的缺陷，为修复和预防 bug 提供建议 1.2背景 1.3用户群 主要读者：***项目管理人员 其他读者：*** 项目相关人员。 1.4定义 基本功能点测试：等价类划分法、边界值法、错误推测法、场景法 业务流程测试：根据业务逻辑，构建测试数据，执行业务流程，查看执行结果与预期是否一致 界面易用性测试：根据界面测试规范及日常使用习惯，提出软件的非功能实现问题 回归测试：对已修复的问题，根据测试出该错误的用例，重新执行该用例，验证问题是否真正被修复，以及是否又引起了其它错误 1.5 测试对象 对综合管理系统进行全新测试，主要进行功能测试、系统测试 1.6测试阶段 第一阶段：对主业务逻辑及功能进行测试 第二阶段：对所有业务逻辑及功能进行深入测试 第三阶段：回归测试 1.7测试工具 BugFree缺陷管理工具 1.8参考资料 《***功能描述》 《***数据字典》
《***测试计划》 《***测试用例》 《***项目计划》 2 测试概要 ***系统测试从 2012年7月25日到2012年10月12日基本结束，历时近70个工作日。后续还有一些扫尾的工作，又增加一些工作时日。是一项花费大量人力物力的项目。 ***通过BugFree缺陷管理工具进行缺陷跟踪管理，在bugfree中有详细的测试用例以及用例执行情况记录 2.1 进度回顾 2.2 测试执行 此次测试严格按照项目计划和测试计划执行，按时完成了测试计划规定的测试对象的测试。针对测试计划规定的测试策略，在测试执行中都有体现，在测试执行过程中，依据测试计划和测试用例，对系统进行了完整的测试、 2.3 测试用例
电子与信息工程系模电实验 实验日期： 2016.4.15 班级：2015级应用物理学实验名称：功率放大电路的仿真测试姓名： 实验成绩：学号： 一、实验目的 （1）了解OTL、OCL功率放大器的基本工作原理和参数测试。 （2）对比分析OTL功率放大器和OCL功率放大器的性能差异。 二、原理与说明 功率放大器根据功放管平均导通时间的长短（或集电极电流流通时间的长短或导通角的大小），分为以下4种工作状态。 （1）甲类工作状态：甲类工作状态下，在整个周期内晶体管的发射结都处于正向运用，集电极电流始终是流通的，即导通角A等于180°。 （2）乙类工作状态：乙类工作状态下，晶体管的发射结在输入信号的半周期内正向运用，在另外半个周期内反向运用，晶体管半周期导电半周期截止。集电极电流只在半周期内随信号变化，而在另半个周期截止，即导通角A等于90°。 （3）甲乙类工作状态：它是介于甲类和乙类之间的工作状态，即发射结处于正向运用的时间超过半个周期，但小于一个周期。即导通角A大于90°小于180°。 （4）丙类工作状态：丙类工作状态:丙类工作状态下，晶体管发射结处于正向运用的时间小于半个周期，集电极电流的时间不到半个周期，即导通角A小于90°。
图4.4.2 OCL功率放大器原理图 4.4.3为单电源供电互补推挽功率放大器。 三、实验内容 1.OCL功率放大器测量
1)按照图4.4.2所示输入自 己的OCL实验电路。并测量晶体管的静态工作，判断器件工作状态。 表格1.1.1 开关闭合开关断开 Q1 Q2 Q1 Q2 I B12.012pa 12.012pa 55.511na 1.691na I C1201ma 1.201ma 1.201ma 1.201mna U CE12v 12v 12v 12v 2)调节信号源输出为3V(峰 值)，在开关J1闭合和断开条件下，用双踪示波器观察输入输出波形。 J1断开时： J1闭合时：
成分分析： 成分分析按照分析对象和要求可以分为微量样品分析和痕量成分分析两种类型。 按照分析的目的不同，又分为体相元素成分分析、表面成分分析和微区成分分析等方法。 体相元素成分分析是指体相元素组成及其杂质成分的分析，其方法包括原子吸收、原子发射ICP、质谱以及X 射线荧光与X 射线衍射分析方法；其中前三种分析方法需要对样品进行溶解后再进行测定，因此属于破坏性样品分析方法；而X射线荧光与衍射分析方法可以直接对固体样品进行测定因此又称为非破坏性元素分析方法。 表面与微区成份分析： X射线光电子能谱（X-ray Photoelectron Spectroscopy, XPS）；（10纳米，表面） 俄歇电子能谱（Auger electron spectroscopy，AES）；（6nm，表面） 二次离子质谱（Secondary Ion Mass Spectrometry, SIMS）；（微米，表面） 电子探针分析方法；（0.5微米，体相） 电镜的能谱分析；（1微米，体相） 电镜的电子能量损失谱分析；（0.5nm） 为达此目的，成分分析按照分析手段不同又分为光谱分析、质谱分析和能谱分析。 1.光谱分析：主要包括火焰和电热原子吸收光谱AAS，电感耦合等离子体原子发射光谱 ICP-OES，X-射线荧光光谱XFS 和X-射线衍射光谱分析法XRD； （1）原子吸收光谱（Atomic Absorption Spectrometry, AAS） 又称原子吸收分光光度分析。原子吸收光谱分析是基于试样蒸气相中被测元素的基态原子对由光源发出的该原子的特征性窄频辐射产生共振吸收，其吸光度在一定范围内与蒸气相中被测元素的基态原子浓度成正比，以此测定试样中该元素含量的一种仪器分析方法。 原子吸收分析特点： （a）根据蒸气相中被测元素的基态原子对其原子共振辐射的吸收强度来测定试样中被测元素的含量； （b）适合对纳米材料中痕量金属杂质离子进行定量测定，检测限低，ng/cm3，10-10—10-14g； （c）测量准确度很高，1%（3—5%）； （d）选择性好，不需要进行分离检测； （e）分析元素范围广，70多种； 应该是缺点（不确定）：难熔性元素，稀土元素和非金属元素，不能同时进行多元素分析；（2）电感耦合等离子体原子发射光谱(Inductively coupled plasma atomic emission spectrometry, ICP-AES)