手机测试基本知识

手机测试介绍
课程内容
¾第一部分 ¾第二部分 ¾讨论
测试概论 手机测试
第一部分 测试概论
¾ 几个概念 ¾ 测试的目的和原则 ¾ 测试的分类 ¾ 测试阶段的划分 ¾ 测试策略 ¾ 测试计划 ¾ 测试文档 ¾ 测试度量
几个概念
¾ 测试
–由人工或自动方法来执行或评价系统或系统部件的过 程，以验证它是否满足规定的需求；或识别出期望的 结果和实际结果之间有无差别。
– 单元测试：由开发人员自行计划与完成的，针对单 个或相关联的一组程序单元的测试。
– 集成测试：计划于设计阶段，由开发人员与测试人 员合作完成的，针对结合起来的不同单元以及它们 的接口的测试。
– 系统测试：测试整个系统，以证实它满足要求所规 定的功能、质量和性能等方面的特性。
– 验收测试：由市场人员或最终客户在实际应用环境 中，按照用户手册对产品手机进行使用测试
¾ 测试策略包括：
– 要使用的测试技术和工具； – 测试完成标准； – 影响资源分配的特殊考虑例如测试与外部接口或者
模拟物理损坏、安全性威胁。
测试计划
– 测试计划独立于项目计划之外，用于明确测试思路 ，指导测试活动，是成功执行和管理测试项目的保 证，通过测试计划可以提高可交流性，避免测试的 随意性。测试过程一定要按测试计划来进行。
– 测试一个大的项目时，应该将进度表分为若干个里程碑。一 个里程碑之内的多个任务可以同步进行。
– 制定的计划应明确、可及、可度量、可追踪。 – 计划表中必须留有缓冲时间，并将缓冲时间用到不确定的事
情上。 – 由于内外部因素可能需要对测试计划进行调整，这时需要及
时对测试计划进行变更和维护。
测试风险
¾ 测试风险可分为外部风险和内部风险
– 交流错误或者没有进行交流（需求不明确） – 系统复杂性 – 设计、编程错误 – 需求改变 – 时间压力 – 自负 – 文档质量差 – 开发工具
测试的目的
¾ 从用户的角度出发
– 希望通过测试暴露出产品中隐藏的错误和缺陷，以 考虑是否可接受该产品。
– 找出关键性的错误，这些错误可能影响用户对产品 的使用和评价。
– 兼容性测试：测试在特殊的硬件/软件/操作系统/网络环境
下的软件表现。
– 文档、帮助测试：主要检查文档的正确性、完备性和可理
解性
测试的分类
¾ 按技术划分
– 白盒测试：是一种基于代码或设计的测试，就是已 知产品的内部活动方式，测试它的内部活动是否符 合设计要求
– 黑盒测试：是一种基于需求的测试，就是已知产品 的功能指标，测试它的每一个功能指标都是否达到 了预期的设计要求。
– 测试计划的内容应该包含以下几大部分：测试范围 、方法、测试配置和环境、通过准则、暂停和再启 动标准、进度、人力资源、风险和应对等
制定测试计划应遵循的原则
– 制定计划的人应该是最了解项目和测试资源的人。测试计划 要经过项目组的评审，避免出现不合理的计划。
– 计划安排要结合需求，执行优先级要体现需求的优先级。在 同等优先级的情况下，要先安排技术难度高的测试项，增加 计划的可调控性。
¾ 从开发者的角度出发
– 希望测试成为表明产品中不存在错误的过程，验证 该产品已正确地实现了用户的要求，确立人们对产 品质量的信心。
测试的角色
¾ 测试人员扮演的是破坏者的角色，试图通过设计和执 行测试用例来“摧毁”已开发人员已建立的系统。“摧毁” 的目的是为了摧毁潜伏在产品中的错误，从而达到保 证质量的目的。
测试的原则
¾ 测试是有风险的
– 不能穷举测试，但不测试又会漏掉软件错误或缺陷 。测试人员要学会的一个主要原则是如何把无边无 际的可能减少到可以控制的范围，以及如何针对风 险做出明智抉择，去粗存精。
测试的粒度
“纯” 结构化 （白盒）
测试
“纯” 行为化 （黑盒）
测试
“纯” 现场测试
测试的分类
¾ 按阶段划分
测试度量内容
¾ 规模度量
– 被测对象的规模（功能点、代码行（有效代码行， 注释行）等）
– 测试需求数目 – 测试用例数目（总用例数、计划执行数、实际执行
数）
¾ 测试质量度量
– 测试覆盖率（需求覆盖率、测试用例覆盖率、测试 用例执行率、测试用例通过率）
– 缺陷检测率
测试度量和分析
¾ 产品质量度量
– 版本发布前缺陷数 – 版本发布后缺陷数 – 评审发现的缺陷数 – 缺陷修正率：缺陷修正率＝发布前已修正的缺陷数/
系统连接器
– 计划的测试开始、结束时间/实际的测试开始、结束 时间/执行测试用例的时间。
¾ 成本度量
– 计划投入测试的工作量(人时)/实际投入测试的工作 量(人时)
– 计划投入测试的资金/实际投入测试的资金 – 评审投入的工作量（人时） – 缺陷修正成本（提交缺陷、研究缺陷、改正缺陷、
验证等所需时间） – 累积测试时间。
¾ 尽早地制定测试计划
– 测试计划可以在需求定义一完成就开始，详细的测 试用例定义可以在系统方案被确定后立即开始。
– 严格执行测试计划，排除测试的随意性
¾ 所有的测试都应可追溯到客户需求
– 测试的目标在于发现错误，而最严重的错误是那些 导致产品无法满足用户需求的错误
测试的原则
¾ 穷举测试是不可能的
¾ “如果您没有使人们心烦，那您就没有做好工作.” ¾ 测试人员应具有以下的素质：
– 技术能力、沟通能力、自信心、耐心、怀疑精神、 洞察力、细心、责任心
– 具有保守而又灵活、好奇而又不带成见、注意力高 度集中的能力
两个观点
¾ 测试是保证产品质量的重要手段。
– 通过测试可以验证产品的功能、性能、可靠性等指 标是否满足规定的要求。但测试不能表明产品中不 存在错误，它只能说明存在错误，通过系统的、严 密的测试能够最大限度的发现产品中的错误，从而 减少产品中遗留的错误。
¾ 测试不是灵丹妙药。因为：
– 完全的测试是不现实的 – 测试不能保证发现其中所有的错误 – 测试不能取代其它质量保证手段 – 测试是巨大的效益和艰苦的工作并存，需要平衡考
虑。
测试的原则
¾ 测试的目的在于发现错误：
– Βιβλιοθήκη Baidu个好的测试用例是能够发现至今尚未察觉的错误 – 一个成功的测试是发现至今尚未察觉的错误的测试
测试文档
¾ 测试相关的文档
– 测试计划：描述了对于预定的测试活动将要采 取的途径的文件。包括标识要测试的项 目、要 完成的测试、测试进度表、人力资源要求、报 告要求、评价准则等。
– 测试方案：规定产品的测试条件、测试思想和 要求、及测试的内容和计划等内容的文件。
– 测试规程：对给定的测试，就其建立、运行和 结果估计所作的详细说明。常常把一组有关的 过程组合起来形成测试过程文件。
– 测试报告：一个描述对系统或系统部件进行的 测试行为及结果的文件。
测试度量和分析
¾ 测试度量的目的：
– 了解目前测试活动的现况，判断测试的有效性，判 断测试的完整性，判断工作产品的质量；
– 客观的根据度量数据来跟踪测试计划的完成情况和 管理测试活动。
– 分析和改进测试过程。
测试度量内容
¾ 进度度量
测试周期与开发周期的关系
开发周期 需求分析 测试周期 测试计划
总体设计
详细设计
测试设计
测试开发
缺陷跟踪
维护 修改
测试执行 评估
测试计划阶段
¾ 测试计划阶段：
– 测试计划阶段确定各测试阶段的目标和策略。这个 过程将输出测试计划，明确要完成的测试活动，评 估完成活动所需要的时间和资源，设计测试组织和 岗位职责，进行活动安排和资源分配，安排跟踪和 控制测试过程的活动。
– 现场测试：是一种基于实际工作环境的测试。现场 测试可以由客户、专家、开发人员、最终用户进行 。
测试阶段的划分
测试计划可分为如下四个阶段：
– 测试计划（定义测试需求、考虑测试内容） – 测试设计（定制测试过程、选择测试用例、方法
） – 测试开发（编程、开发） – 测试执行和评估（执行、检查、评估）
– 在测试执行和评估阶段的最后，对以前各阶段所积 累的测试数据进行合理的统计分析，形成系统测试 报告并提交，使项目管理者全面了解产品开发的质 量，为决策管理提供支持。
测试策略
¾ 制定测试策略的目的
– 测试策略用于说明某项特定测试工作的总体方法和 目标。
– 在测试计划阶段制定和选择好的测试策略可以极大 地提高测试的效率和质量。
发布前已知的缺陷总数。 – 缺陷密度：千行代码缺陷率＝测试和评审中发现的
缺陷数/被测目标的代码的规模（KL） – 代码质量：编码规范
第二部分 手机测试介绍
¾硬件测试介绍 ¾软件测试介绍 ¾结构测试介绍 ¾可靠性测试介绍
手机硬件组成
音频和 振动部分 存储器
LCD模块
键盘板
电池
数字 基带 芯片
模拟基带 芯片
¾ 调试
– 查找、分析和纠正错误的过程。
¾ 验证
– 通过检查并收集客观的证据来确定特定的需求得到满 足。
几个概念
¾确认
– 通过检查并收集客观的证据来确定针对某种特定的 预期使用的特殊需求得到了满足。
¾ 错误
– 计算、观察、测量的值或条件与实际的、规定的 或理论上的值或条件不符合。
¾ 缺陷:
– 系统功能部件不能执行所要求的功能。 – 可能引起失效的错误。
测试设计阶段
¾ 测试设计阶段
– 要完成的主要活动包括设计系统测试方案、设计系 统测试规范。
– 如果被测试系统需要自己研制软硬件测试工具，测 试工具的方案设计也应该在本阶段完成。
– 测试设计阶段的结束标志是，系统测试方案、系统 测试规范通过设计评审。
测试开发阶段
¾ 测试开发阶段
– 要根据测试方案和测试规范，参考详细设计说明、 使用说明等文档，对系统测试用例进行详细设计， 使得测试用例可以在测试执行和评估阶段顺利实施 。对于需要采用自动化测试工具的系统测试部分， 应该设计自动化测试用例的脚本，并准备测试数据 。
测试的分类
¾ 按目的划分
– 性能测试：性能测试是要检查系统是否满足在需求说明书
中规定的性能，如响应时间、处理精度等。
– 功能测试：功能测试是在规定的一段时间内运行系统的所
有功能，以验证这个系统有无错误。功能测试通常采用黑盒 测试方法。
– 安全性测试：测试系统在应付非授权的内部/外部访问、故
意的损坏时的防护情况。
– 外部风险就是导致测试实际情况和计划不一致的外部因素。 包括：需求项变更，项目进度调整，提交测试工作产品的质 量不符合要求等。
– 内部风险就是测试团队内的一些不确定因素。包括测试进度 延误，测试工程师流失，测试工具不到位等。
¾ 测试阶段常见的风险
– 各阶段测试任务不能按期完成； – 开发组没能按计划提交相应的测试工作产品； – 测试计划要求的硬件和软件设备或资源未能满足； – 测试工具的应用没能达到预期深度； – 测试人员的流失、出差或休假； – 过多的临时任务； – 重要测试数据丢失等
– 测试开发阶段，还需要对自己研制的软硬件测试工 具进行开发。
测试执行和评估阶段
¾ 测试执行和评估
– 根据测试类型和指定的测试范围和要求，对功能、 性能、稳定性等测试项进行测试，将获得的运行结 果与预期结果进行比较和分析，记录、跟踪和管理 软件缺陷。
– 对测试结果进行监视，如果没有实现预定的结果， 则应进行适当的调整或纠正。
哪些叫错误、缺陷？
¾ 如果一个产品存在下列现象，我们称之为错误 或缺陷：
– 产品未达到设计规范表明的功能指标； – 产品出现了设计规范指明不会出现的错误； – 产品功能超出了设计规范指明的范围； – 产品未达到设计规范虽未指出但应达到的目标； – 最终用户认为不好使用。
为何会出错？
¾ 出现错误和缺陷的原因：
– Good_Enough原则 这是一种权衡投入／产出比的 原则，测试既不要不充分，也不要过分。不充分和 过分都是一种不负责任的表现。
– 80/20原则 一般情况下，在分析、设计、实验阶 段的复审和测试工作能够发现和避免８０％的bug ，而系统的软件测试能够找出其余bug中的８０％ 。最后约5%的bug只有在用户大范围、长时间的使 用后才会暴露出来。因此测试只能保证尽可能多地 发现错误，不能保证发现所有的错误。
– 测试计划可以分为系统测试总体计划和系统测试详 细计划两部分。
测试计划阶段
– 在需求分析阶段，要完成系统测试总体计划。总体 测试计划应该包括测试设计和开发阶段、测试执行 和评估阶段的进度和资源计划以及每一个阶段要完 成的测试活动。
– 在总体设计阶段，要完成系统测试详细计划。系统 测试详细计划包括了系统测试在每一个阶段的详细 测试活动安排，是系统测试总体计划的具体落实。