研发流程中的产品测试PPT课件

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

模糊测试
➢ 模糊测试是黑盒法中的一种,其执行过程为: 向产品有意识地进行无效输入以期望触发错误条 件或引起产品的故障。
➢ 模糊测试最为形象的说法是:测试过程要做 的就是站在后面向目标投掷石头,等待玻璃被打 破的声音。就这个意义而言,模糊测试可被归结 为黑盒测试。
➢ 若我们对产品内部有所了解,就可以让石头 每次的飞行路线更直接并且更真实。因此,模糊 测试也可以应用在灰盒测试中。
➢ 重要级别:定义测试用例的优先级别。
➢高:确保系统基本功能及主要功能的测试用例 ➢中:确保系统功能的完善方面的测试用例 ➢低:较少使用或辅助功能的测试用例,如提示信息
➢ 测试输入:定义用例实施中的各种输入条件。
测试用例-要素
➢ 操作步骤:对于复杂测试用例,操作时需要 分几个步骤完成,这部分内容在操作步骤中详 细列出。
测试的目的
➢ 两种角度:
➢ 从用户的角度出发,就是希望通过测试能 充分暴露产品中存在的缺陷,以便决定是否 买单。
➢ 从开发者的角度出发,就是希望测试能表 明产品不存缺陷,已经完全正确地实现了用 户需求。
测试的目的
➢ 三个问题:
➢ 从情感角度来看,开发者是不愿意自己设 计的产品被证明存在设计缺陷。
1、产品需求规格说明书只会对产品外在指标和 功能进行定义,而不会对产品组成的单元/单板、 接口等指标功能进行描述。这样的测试可以肯 定比较难以发现产品内部的设计缺陷。
2、产品需求规格说明书定义的指标、功能可能 列写不充分。根据不充分的需求定义导出的测 试用例不能够覆盖基本(正常)事件的测试, 导致测试有效性的降低。
➢ 静态测试:就是指人工评审设计文档,借 以发现其中的错误。作为研发质量控制的重 要手段,评审经常作为具体实施前的检查手 段,其目的是保证设计的正确性、减小设计 风险、尽早发现设计缺陷。
测试的白盒测试:对模块内部是不透明的。从模 块/产品的设计、结构上来进行测试,检查模 块/产品中的错误。 ➢ 黑盒测试:对内部透明,仅从使用上来检 查功能上是否有错误。
➢ 容错性测试:测试系统/产品的功能单元、接 口间出现异常的情况下系统的保护性处理,以 及异常结束后系统功能性能的恢复处理。
测试覆盖范围
➢ 可靠性测试:测试系统/产品在实际应用环境 下可保证性能功能有效性的能力。
➢ 压力测试:测试在大信息量处理情况下的系 统/产品正常工作的能力。
➢ 回归测试:测试上一轮测试所发现缺陷的解 决及对系统的潜在影响。
➢ 测试的有效性是通过符合实际应用条件下 的测试用例的设计及实施来保证。
测试实施原则
➢ 由于惯性思维的存在使得难以发现设计缺陷, 因此尽量避免设计人员来测试自己设计的产品, 但是单元测试除外。
➢ 确定预期输出结果是测试用例必不可少的一 部分。如果只有测试数据而无预期结果,那么 就不容易判断测试结果是否正确。
黑盒与白盒
➢ 黑盒测试是从上到下、从宏观到微观的逐步 验证过程,一般止步于单板/功能模块外部功能 的测试。 ➢ 白盒测试是从下到上、从微观到宏观的逐步 验证过程,一般涉及单板/功能模块内部性能功 能及单元间接口的测试。
➢ 一般采用白盒测试方法来检查产品的基本功 能单元内部错误,而采用黑盒测试方法来验证 由各功能单元组装而成的产品/系统的功能和性 能。
➢ 优点:白盒法测试用例是围绕着产品设计实现角度 出发,通过对其内部信号特征、接口功能性能的覆盖性 检查来保证设计的正确性。
➢ 缺点:以详细设计为依据,以覆盖率为最终目标, 因此缺乏宏观把握的能力。
➢不能查出详细设计本身所存在的问题,即错误的 产品设计。
➢不可能查出被详细设计所遗漏的功能、性能。
灰盒测试
➢ 测试用例指对特定的功能单元/模块、系统/ 产品进行测试任务的描述,体现测试方案、方 法、技术和策略。内容包括测试目标、测试环 境、测试输入、测试步骤、预期结果等,并以 文档的形式予以表达。
测试用例-要素
➢ 用例编号:便于测试用例的管理及测试过程 的跟踪。 ➢ 用例标题:清楚表达测试用例的用途。
测试策略-定义
➢ 依据测试项目的特定环境约束而规定的测试 原则、方式、方法的集合,用以描述在测试活 动各阶段所采用的测试方法和测试目标。内容 主要包括:
➢ 资源需求的详细说明。 ➢ 进度约束下的人力资源角色和职责。 ➢ 某测试阶段所使用的测试方法和工具。 ➢ 某测试阶段所需要执行的测试类型。 ➢ 测试完成和测试成功所采用的评价标准。
测试实施原则
➢ 测试后遗留的错误数目往往与已发现的错误 数目成比例。因此当A模块找出错误比B模块多 得多时,很可能A模块遗留的错误仍比B模块遗 留的错误多。
➢ 回归测试的关联性一定要引起充分的注意, 修改一个错误而引起更多的错误出现的现象并 不少见。
➢ 妥善保存一切测试过程文档,测试的重现性 往往要靠测试文档。
软件测试与硬件测试
➢ 软件测试:软件不涉及制造加工,因此软件 测试的目的仅仅是验证设计的正确性。
➢ 硬件测试:除了验证设计正确性以外,还要 包括制造的准确性,或者一致性测试。
软件测试与硬件测试
➢ 当我们只考虑验证设计正确性的话:
➢ 软件测试:发现软件代码语法错误和逻辑 错误,衡量软件设计正确性的标准是:软件 在某种输入条件下是否按正确时序完成对硬 件的操作(如写入/读出寄存器数据)。
测试实施原则
➢ 制定严格的测试计划,并把测试时间安排的 尽量宽松,不要希望在极短的时间内完成一个 高水平的测试。
➢ “尽早和不断的测试”应该成为一个合格的开 发者的座右铭。
总结一下
➢ 对于测试重要性的理解我们都相差不多,唯 一的区别在于对测试所关注问题的不同看法。
➢ 我们的核心问题是如何提高测试效率。
测试的分类
➢ 集成测试:又称联合测试也称组装测试,它 是对由各模块组装而成的产品进行测试,主要 检查模块间的接口和通信。
➢ 系统测试:是把软、硬件和环境连在一起全 面的测试,检查系统的功能、性能及其他特征 是否与用户的需求一致,它是以需求规格说明 书作为依据的测试。系统测试又可细分为功能 测试、容量测试、压力测试、使用性测试、安 全性测试、性能测试、可靠性测试、恢复测试、 强度测试、文档测试以及工序测试。
➢ 缺点:黑盒测试用例的设计不可能做到完全覆盖, 因此难以完全触发产品内部所有执行流程/路径,也就 难以完全发现深藏在产品内部单元/模块及接口的设计 缺限,需要有白盒测试进行补充。
黑盒与白盒
➢ 白盒测试也称结构测试或逻辑驱动测试,在知道产 品内部工作过程的前提下,按照产品内部的结构,通过 测试来检测产品内部动作是否符合详细设计。
测试的分类
➢ 划分测试的种类并不重要,重要的是,一定 要把测试看成是产品设计全生命周期持续不断 而不是阶段性的工作。
测试覆盖范围
➢ 正确性测试:测试用例中的测试点应首先保 证要至少覆盖需求规格说明书中的各项功能。
➢ 健壮性测试:正确信息输入将产生预期输出, 非法信息输入将导致相应提示或错误处理,而 不至于系统/模块崩溃。
测试方法的选择
➢ 有一种观点认为: ➢ 在单元测试阶段采用白盒法; ➢ 在集成测试阶段采用灰盒法; ➢ 在系统测试阶段采用黑盒法。
测试的分类
➢ 按测试步骤划分,有单元测试、集成测试、 系统测试。
➢ 单元测试:也称模块测试。测试的对象是 设计的最小单位-功能模块。单元测试的依 据是详细设计描述,对模块内所有表达功能/ 性能的节点设计测试用例,以便发现模块内 部的错误。单元测试主要发现详细设计阶段 产生的错误。
➢ 需求阶段、总体(概要)设计阶段、详细设 计阶段所输出的技术文档,包括需求规格说明、 总体(概要)设计、详细设计、源程序(SCH、 PCB)、用户文档等,都是测试的对象。
测试的分类
测试的分类
➢ 按测试方法划分,有静态测试和动态测试。
➢ 动态测试:使被测试产品或模块有控制地 运行,并从多种角度观察运行时的行为,以 发现其中的错误。
测试策略-意义
➢ 测试策略明确了所有测试阶段、测试技术和 项目所使用的测试工具和测试目标,用以指导 后续测试工作得有效实施。
➢ 测试策略的制定还可以使得测试过程中的沟 通交流变得更为容易和有效,而它会影响到整 个项目组。
测试用例-定义
➢ 测试用例(Test Case)是为某个特殊目标而编 制的一组测试输入、执行条件以及预期结果, 以便测试某个功能单元/模块、系统/产品是否满 足某些特定需求。
➢ 从应用角度来看,开发者往往是认为用户 一定是按照自己设计好的操作模式来对产品 进行操作的。
➢ 从实施角度来看,开发者总是对能够验证 产品已经实现了预期功能的测试项目更加感 兴趣。
测试的目的
➢ 四条结论:
➢ 测试不仅仅是为了证明产品能够实现既定 功能,还要尽可能多地发现产品中的错误和 缺陷。 ➢ 测试只能证明错误的存在,但不能证明错 误不存在。 ➢ 研发产品质量保证的唯一方法就是尽量大 覆盖范围下的有效测试。
黑盒与白盒
➢ 黑盒测试也称功能测试或数据驱动测试,它是在对 产品应具功能进行抽象的基础上,将程序划分成功能单 元,然后对每个功能单元设计测试用例进行测试。
➢ 优点:黑盒法测试用例是围绕着产品操作方式和实 际应用环境来设计的,每一个测试用例表征着一种产品 实际可能发生的应用场景,测试结果非常直观便于理解。
➢ 测试会占用开发周期,特别是测试覆盖率 要求越高周期就会越长,这与开发进度要求 一定是矛盾的。
➢ 开发人员、测试人员较少测试经验,不具 备良好的测试技能和测试工具,使得测试进 度更加不可保证。
广义的测试
➢ 测试应该贯穿产品开发周期,测试不仅仅是 测试所实现的产品性能与功能,还要测试开发 周期中各种设计文档。
➢ 灰盒测试介于黑盒与白盒之间,关注输出对 于输入的正确性,同时也关注内部表现,但这 种关注不象白盒那样详细、完整,只是通过一 些表征性的现象、事件、标志来判断内部的运 行状态。
➢ 灰盒法在用例设计中不关心模块内处理过程, 只关心被测对象的输入与输出,这是典型的黑 盒思维模式。
➢ 灰盒法在用例设计时基于对模块内部处理的 了解,测试设计可以有针对性的进行,测试过 程评估也是白盒法。
本次交流的目的就是增强技术 人员对测试工作的理解和认识, 便于后续公司测试工作流程的
持续改进。
提纲
➢ 测试的目的和原则 ➢ 测试的分类和方法 ➢ 测试实施
测试的目的和原则
测试的目的
➢ 一点共识:
➢ 为使最终用户对产品满意,就必须保证 产品功能性能达到用户需求。而验证产品功 能性能否达到用户要求的唯一方法就是持续 有效的测试。
➢ 彻底检查每个测试结果。如果不仔细检查测 试结果,有些已经测试出来的错误也可能被遗 漏掉。
测试实施原则
➢ 对非法的和非预期的输入也要像合法的和预 期的输入一样编写测试用例。
➢ 检查产品是否做了应做的事仅是成功的一半, 另一半是看产品是否做了不该做的事。
➢ 对测试错误结果一定要有一个确认的过程, 一般有A测试出来的错误,一定要有一个B来确 认,严重的错误可以召开评审会进行讨论和分 析。
本次交流的目的
3、产品需求规格说明书可能不会对备选事件和 异常事件进行描述,即使是一一对应需求规格 而设计的测试用例也会造成对备选事件和异常 事件的测试遗漏,进一步降低测试有效性。
4、单元测试、集成测试、系统测试所用测试用 例完全一样,忽略了不同产品测试阶段所要关 注的工作重点,使得产品设计缺陷难以在研发 阶段暴露,后续影响量产产品的质量。
➢ 硬件测试:发现硬件设计的错误,衡量硬 件设计正确性的标准是:硬件系统在某种激 励条件下能否保证线路上的信号完整性,即 “在需要的时间内信号达到所需要的形状”。
测试的实施
测试实施
➢ 实施测试工作的过程为: ➢ 制定测试策略。 ➢ 测试用例设计。 ➢ 执行测试用例。 ➢ 缺陷修复过程。 ➢ 回归测试。
研发流程中的产品测试
本次交流的目的
➢ 我们许多技术人员往往将测试简单的理解为 对产品功能性能的验证。
➢ 在产品测试中他们简单的对产品需求规格说 明书中所述的产品性能、功能进行分类,并按 照其预想的用户操作步骤通过黑盒测试的方法 来测试产品是否实现设计指标和功能。
➢ 这种方法会带来严重的缺陷:
本次交流的目的
相关文档
最新文档