研发流程中的产品测试

1、研发流程中的产品测试 研发流程中的产品测试研发流程中的产品测试 研发流程中的产品测试 本次交流的目的 我们许多技术人员往往将测试简单的理解为 对产品功能性能的验证。 在产品测试中他们简单的对产品需求规格说 明书中所述的产品性能、功能进行分类，并按 照其预想的用户操作步骤通过黑盒测试的方法 来测试产品是否实现设计指标和功能。 这种方法会带来严重的缺陷： 研发流程中的产品测试 本次交流的目的 1、产品需求规格说明书只会对产品外在指标和 功能进行定义，而不会对产品组成的单元/单板、 接口等指标功能进行描述。这样的测试可以肯 定比较难以发现产品内部的设计缺陷。 2、产品需求规格说明书定义的指标、功能可

2、能 列写不充分。根据不充分的需求定义导出的测 试用例不能够覆盖基本（正常）事件的测试， 导致测试有效性的降低。 研发流程中的产品测试 本次交流的目的 3、产品需求规格说明书可能不会对备选事件和 异常事件进行描述，即使是一一对应需求规格 而设计的测试用例也会造成对备选事件和异常 事件的测试遗漏，进一步降低测试有效性。 4、单元测试、集成测试、系统测试所用测试用 例完全一样，忽略了不同产品测试阶段所要关 注的工作重点，使得产品设计缺陷难以在研发 阶段暴露，后续影响量产产品的质量。 研发流程中的产品测试 本次交流的目的就是增强技术 人员对测试工作的理解和认识， 便于后续公司测试工作流程的 持续改进。

3、 研发流程中的产品测试 提纲 测试的目的和原则 测试的分类和方法 测试实施 研发流程中的产品测试 测试的目的和原则 研发流程中的产品测试 测试的目的 为使最终用户对产品满意，就必须保证 产品功能性能达到用户需求。而验证产品功 能性能否达到用户要求的唯一方法就是持续 有效的测试。 一点共识： 研发流程中的产品测试 测试的目的 从用户的角度出发，就是希望通过测试能 充分暴露产品中存在的缺陷，以便决定是否 买单。 从开发者的角度出发，就是希望测试能表 明产品不存缺陷，已经完全正确地实现了用 户需求。 两种角度： 研发流程中的产品测试 测试的目的 从情感角度来看，开发者是不愿意自己设 计的产品被证明存

4、在设计缺陷。 从应用角度来看，开发者往往是认为用户 一定是按照自己设计好的操作模式来对产品 进行操作的。 三个问题： 从实施角度来看，开发者总是对能够验证 产品已经实现了预期功能的测试项目更加感 兴趣。 研发流程中的产品测试 测试的目的 测试不仅仅是为了证明产品能够实现既定 功能，还要尽可能多地发现产品中的错误和 缺陷。 测试只能证明错误的存在，但不能证明错 误不存在。 四条结论： 研发产品质量保证的唯一方法就是尽量大 覆盖范围下的有效测试。 测试的有效性是通过符合实际应用条件下 的测试用例的设计及实施来保证。 研发流程中的产品测试 测试实施原则 由于惯性思维的存在使得难以发现设计缺陷， 因此

5、尽量避免设计人员来测试自己设计的产品， 但是单元测试除外。 确定预期输出结果是测试用例必不可少的一 部分。如果只有测试数据而无预期结果，那么 就不容易判断测试结果是否正确。 彻底检查每个测试结果。如果不仔细检查测 试结果，有些已经测试出来的错误也可能被遗 漏掉。 研发流程中的产品测试 测试实施原则 对非法的和非预期的输入也要像合法的和预 期的输入一样编写测试用例。 检查产品是否做了应做的事仅是成功的一半， 另一半是看产品是否做了不该做的事。 对测试错误结果一定要有一个确认的过程， 一般有A测试出来的错误，一定要有一个B来确 认，严重的错误可以召开评审会进行讨论和分 析。 研发流程中的产品测试

6、测试实施原则 测试后遗留的错误数目往往与已发现的错误 数目成比例。因此当A模块找出错误比B模块多 得多时，很可能A模块遗留的错误仍比B模块遗 留的错误多。 回归测试的关联性一定要引起充分的注意， 修改一个错误而引起更多的错误出现的现象并 不少见。 妥善保存一切测试过程文档，测试的重现性 往往要靠测试文档。 研发流程中的产品测试 测试实施原则 制定严格的测试计划，并把测试时间安排的 尽量宽松，不要希望在极短的时间内完成一个 高水平的测试。 “尽早和不断的测试”应该成为一个合格的开 发者的座右铭。 研发流程中的产品测试 总结一下 对于测试重要性的理解我们都相差不多，唯 一的区别在于对测试所关注问题

7、的不同看法。 我们的核心问题是如何提高测试效率。 测试会占用开发周期，特别是测试覆盖率 要求越高周期就会越长，这与开发进度要求 一定是矛盾的。 开发人员、测试人员较少测试经验，不具 备良好的测试技能和测试工具，使得测试进 度更加不可保证。 研发流程中的产品测试 广义的测试 测试应该贯穿产品开发周期，测试不仅仅是 测试所实现的产品性能与功能，还要测试开发 周期中各种设计文档。 需求阶段、总体（概要）设计阶段、详细设 计阶段所输出的技术文档，包括需求规格说明、 总体（概要）设计、详细设计、源程序（SCH、 PCB）、用户文档等，都是测试的对象。 研发流程中的产品测试 测试的分类 研发流程中的产品测

8、试 测试的分类 按测试方法划分，有静态测试和动态测试。 动态测试：动态测试：使被测试产品或模块有控制地 运行，并从多种角度观察运行时的行为，以 发现其中的错误。 静态测试：静态测试：就是指人工评审设计文档，借 以发现其中的错误。作为研发质量控制的重 要手段，评审经常作为具体实施前的检查手 段，其目的是保证设计的正确性、减小设计 风险、尽早发现设计缺陷。 研发流程中的产品测试 测试的分类 按测试功能划分，有黑盒测试和白盒测试。 白盒测试：白盒测试：对模块内部是不透明的。从模 块/产品的设计、结构上来进行测试，检查模 块/产品中的错误。 黑盒测试：黑盒测试：对内部透明，仅从使用上来检 查功能上是否

9、有错误。 研发流程中的产品测试 黑盒与白盒 黑盒测试是从上到下、从宏观到微观的逐步 验证过程，一般止步于单板/功能模块外部功能 的测试。 白盒测试是从下到上、从微观到宏观的逐步 验证过程，一般涉及单板/功能模块内部性能功 能及单元间接口的测试。 一般采用白盒测试方法来检查产品的基本功 能单元内部错误，而采用黑盒测试方法来验证 由各功能单元组装而成的产品/系统的功能和性 能。 研发流程中的产品测试 黑盒与白盒 黑盒测试也称功能测试或数据驱动测试，它是在对 产品应具功能进行抽象的基础上，将程序划分成功能单 元，然后对每个功能单元设计测试用例进行测试。 优点：优点：黑盒法测试用例是围绕着产品操作方式

10、和实 际应用环境来设计的，每一个测试用例表征着一种产品 实际可能发生的应用场景，测试结果非常直观便于理解。 缺点：缺点：黑盒测试用例的设计不可能做到完全覆盖， 因此难以完全触发产品内部所有执行流程/路径，也就 难以完全发现深藏在产品内部单元/模块及接口的设计 缺限，需要有白盒测试进行补充。 研发流程中的产品测试 黑盒与白盒 白盒测试也称结构测试或逻辑驱动测试，在知道产 品内部工作过程的前提下，按照产品内部的结构，通过 测试来检测产品内部动作是否符合详细设计。 优点：优点：白盒法测试用例是围绕着产品设计实现角度 出发，通过对其内部信号特征、接口功能性能的覆盖性 检查来保证设计的正确性。 缺点：缺

11、点：以详细设计为依据，以覆盖率为最终目标， 因此缺乏宏观把握的能力。 不能查出详细设计本身所存在的问题，即错误的 产品设计。 不可能查出被详细设计所遗漏的功能、性能。 研发流程中的产品测试 灰盒测试 灰盒测试介于黑盒与白盒之间，关注输出对 于输入的正确性，同时也关注内部表现，但这 种关注不象白盒那样详细、完整，只是通过一 些表征性的现象、事件、标志来判断内部的运 行状态。 灰盒法在用例设计中不关心模块内处理过程， 只关心被测对象的输入与输出，这是典型的黑 盒思维模式。 灰盒法在用例设计时基于对模块内部处理的 了解，测试设计可以有针对性的进行，测试过 程评估也是白盒法。 研发流程中的产品测试 模

12、糊测试 模糊测试是黑盒法中的一种，其执行过程为： 向产品有意识地进行无效输入以期望触发错误条 件或引起产品的故障。 模糊测试最为形象的说法是：测试过程要做 的就是站在后面向目标投掷石头，等待玻璃被打 破的声音。就这个意义而言，模糊测试可被归结 为黑盒测试。 若我们对产品内部有所了解，就可以让石头 每次的飞行路线更直接并且更真实。因此，模糊 测试也可以应用在灰盒测试中。 研发流程中的产品测试 测试方法的选择 有一种观点认为： 在单元测试阶段采用白盒法； 在集成测试阶段采用灰盒法； 在系统测试阶段采用黑盒法。 研发流程中的产品测试 测试的分类 按测试步骤划分，有单元测试、集成测试、 系统测试。 单

13、元测试：单元测试：也称模块测试。测试的对象是 设计的最小单位功能模块。单元测试的依 据是详细设计描述，对模块内所有表达功能/ 性能的节点设计测试用例，以便发现模块内 部的错误。单元测试主要发现详细设计阶段 产生的错误。 研发流程中的产品测试 测试的分类 集成测试：集成测试：又称联合测试也称组装测试，它 是对由各模块组装而成的产品进行测试，主要 检查模块间的接口和通信。 系统测试：系统测试：是把软、硬件和环境连在一起全 面的测试，检查系统的功能、性能及其他特征 是否与用户的需求一致，它是以需求规格说明 书作为依据的测试。系统测试又可细分为功能 测试、容量测试、压力测试、使用性测试、安 全性测试、

14、性能测试、可靠性测试、恢复测试、 强度测试、文档测试以及工序测试。 研发流程中的产品测试 测试的分类 划分测试的种类并不重要，重要的是，一定 要把测试看成是产品设计全生命周期持续不断 而不是阶段性的工作。 研发流程中的产品测试 测试覆盖范围 正确性测试：正确性测试：测试用例中的测试点应首先保 证要至少覆盖需求规格说明书中的各项功能。 健壮性测试：健壮性测试：正确信息输入将产生预期输出， 非法信息输入将导致相应提示或错误处理，而 不至于系统/模块崩溃。 容错性测试：容错性测试：测试系统/产品的功能单元、接 口间出现异常的情况下系统的保护性处理，以 及异常结束后系统功能性能的恢复处理。 研发流程中

15、的产品测试 测试覆盖范围 可靠性测试：可靠性测试：测试系统/产品在实际应用环境 下可保证性能功能有效性的能力。 压力测试：压力测试：测试在大信息量处理情况下的系 统/产品正常工作的能力。 回归测试：回归测试：测试上一轮测试所发现缺陷的解 决及对系统的潜在影响。 研发流程中的产品测试 软件测试与硬件测试 软件测试：软件测试：软件不涉及制造加工，因此软件 测试的目的仅仅是验证设计的正确性。 硬件测试：硬件测试：除了验证设计正确性以外，还要 包括制造的准确性，或者一致性测试。 研发流程中的产品测试 软件测试与硬件测试 当我们只考虑验证设计正确性的话： 软件测试：软件测试：发现软件代码语法错误和逻辑

16、错误，衡量软件设计正确性的标准是：软件 在某种输入条件下是否按正确时序完成对硬 件的操作（如写入/读出寄存器数据）。 硬件测试：硬件测试：发现硬件设计的错误，衡量硬 件设计正确性的标准是：硬件系统在某种激 励条件下能否保证线路上的信号完整性，即 “在需要的时间内信号达到所需要的形状”。 研发流程中的产品测试 测试的实施 研发流程中的产品测试 测试实施 制定测试策略。 测试用例设计。 实施测试工作的过程为： 执行测试用例。 缺陷修复过程。 回归测试。 研发流程中的产品测试 测试策略定义 资源需求的详细说明。 进度约束下的人力资源角色和职责。 依据测试项目的特定环境约束而规定的测试 原则、方式、方

17、法的集合，用以描述在测试活 动各阶段所采用的测试方法和测试目标。内容 主要包括： 某测试阶段所使用的测试方法和工具。 某测试阶段所需要执行的测试类型。 测试完成和测试成功所采用的评价标准。 研发流程中的产品测试 测试策略意义 测试策略的制定还可以使得测试过程中的沟 通交流变得更为容易和有效，而它会影响到整 个项目组。 测试策略明确了所有测试阶段、测试技术和 项目所使用的测试工具和测试目标，用以指导 后续测试工作得有效实施。 研发流程中的产品测试 测试用例定义 测试用例(Test Case)是为某个特殊目标而编 制的一组测试输入、执行条件以及预期结果， 以便测试某个功能单元/模块、系统/产品是否

18、满 足某些特定需求。 测试用例指对特定的功能单元/模块、系统/ 产品进行测试任务的描述，体现测试方案、方 法、技术和策略。内容包括测试目标、测试环 境、测试输入、测试步骤、预期结果等，并以 文档的形式予以表达。 研发流程中的产品测试 测试用例要素 用例编号：用例编号：便于测试用例的管理及测试过程 的跟踪。 用例标题：用例标题：清楚表达测试用例的用途。 重要级别：重要级别：定义测试用例的优先级别。 高：确保系统基本功能及主要功能的测试用例 中：确保系统功能的完善方面的测试用例 低：较少使用或辅助功能的测试用例，如提示信息 测试输入：测试输入：定义用例实施中的各种输入条件。 研发流程中的产品测试

19、测试用例要素 操作步骤：操作步骤：对于复杂测试用例，操作时需要 分几个步骤完成，这部分内容在操作步骤中详 细列出。 预期结果：预期结果：提供测试执行的预期结果，预期 结果应该根据产品需求中的输出得出。 基本事件：基本事件：描述该测试用例的基本操作流程， 指每个流程都“正常”运作时所发生的事情。 基本事件用以测试在正确环境及操作下产品所 能实现的性能、功能。 研发流程中的产品测试 测试用例要素 备选事件：备选事件：表示这种行为或流程是可选的或 备选的，并不是总要执行。 异常事件：异常事件：表示在发生某些非正常的事件后 产品所要执行的响应。 正面测试：正面测试：用于验证被测单元能够执行应该 完成的

20、工作。 负面测试：负面测试：用于验证软件不执行其不应该完 成的工作。 研发流程中的产品测试 测试用例设计白盒法 白盒测试是穷举类测试，主要强调的是覆盖 率，即测试用例要覆盖单元内部所有处理流程。 对软件来讲就是代码路径的覆盖率，对于硬 件测试来讲则是检查所有电路节点的响应信号。 受到进度和资源的约束，不可能达到完全覆 盖率，折衷办法就是选取关键重要的部分进行 测试用例的设计。 研发流程中的产品测试 测试用例设计白盒法 语句覆盖语句覆盖：检查到模块中每个语句执行情况。 判定覆盖判定覆盖：检查到模块中每个分支/信号流执行情况。 条件覆盖条件覆盖：使判定中的每个条件获得各种可能的结果。 判定判定/条

21、件覆盖条件覆盖：选择足够的测试用例，使得判定中 每个条件取到各种可能的值，并且每个判定取到各种可 能的结果。 条件组合覆盖条件组合覆盖：执行足够的测试用例，使得每个判 定中条件的各种可能组合都至少出现一次。 覆盖率由低到高覆盖率由低到高 路径覆盖路径覆盖：执行足够的测试用例，使得每条路径至少 被执行一次。 研发流程中的产品测试 测试用例设计白盒法 白盒法实施深度： 白盒法（包括设计文档评审、软件代码检 查）工作量应占到测试总工作量的50。 对测试缺陷进行统计分析，白盒法发现的 缺陷要达到总缺陷数的50以上。 研发流程中的产品测试 测试用例设计黑盒法 黑盒法是测试者完全不考虑功能模块内部 结构和

22、处理过程，而只是根据功能说明来设计 测试用例，检查模块功能是否符合规格说明的 要求。 等价分类法 边缘值分析法 因果图法 错误推测法 研发流程中的产品测试 测试用例设计黑盒法 等价分类法等价分类法：在输入数据中选择一组子集， 每个子集选择一个具有“代表性”的测试用例， 使这个测试用例可以代表一大类的有同样共性 的其他测试用例，这就形成了一个等价类。这 样就可使用少数的等价类测试用例能发现较多 的错误。 等价分类法分为二步： 根据功能说明中的输入条件划分等价类； 1. 按等价类来选择测试用例。 研发流程中的产品测试 测试用例设计黑盒法 边缘值分析法边缘值分析法：与等价分类法的差别主要在 于边缘值

23、分析法是着重检查等价类边界上的情 况。 若某个输入条件说明了值的范围，则可选择恰好 取到边界值的用例；另外再编写一些代表不合理 输入数据的用例，它们的值恰好超过边界。 如果一个输入条件指出了输入数据的个数，则为 最小个数，最大个数，比最小个数少1，比最大 个数多1，分别设计用例。 研发流程中的产品测试 测试用例设计黑盒法 因果图法因果图法：因果图法则着重检查输入条件的 各种组合情况，消除等价分类法和边缘值分析 法没有检查各种输入条件的组合的缺点。 从用自然语言书写的功能说明中找出因（输入条 件）和果（输出或程序状态的修改）； 通过画因果图将功能说明转换成判定表，然后为 判定表的第一列设计测试用

24、例。 因果图法是设计测试用例的一个系统的方法。 研发流程中的产品测试 测试用例设计黑盒法 错误推测法错误推测法：通过经验或直觉推测程序中可 能存在的各种错误，从而有针对性的编写测试 用例，这就是错误推测法。 错误推测法没有确定的步骤，很大程度上是 凭经验进行的。 研发流程中的产品测试 前述概念是随着软件测试的发展而提出并逐 渐完善。 测试用例设计 相对而言，硬件测试并未能够形成一种完善 的理论和实施流程，其主要原因在于硬件的多 样性以及硬件系统难以独立于软件而单独实现。 对于软件测试用例的设计有许多参考文献， 这里不再描述。后续仅对硬件测试谈谈一些理 解和体会。 研发流程中的产品测试 测试目的

25、：验证设计的正确性、制造准确性， 以及查找、排除现场故障； 硬件测试 测试对象：可测量信号的时域频域形状、指 标偏差、容限、极限参数。 测试项目：指标、功能、可靠性、一致性。 测试方法：白盒测试、黑盒测试。 测试阶段：单元测试、集成测试、系统测试。 研发流程中的产品测试 硬件单元测试 单元测试主要是指单板测试，一般采用白盒 及黑盒测试相结合的方法，主要进行性能指标 测试。 白盒测试的目的是保证板上各级信号的完 整性。 黑盒测试的目的是验证板上及板间接口信 号是否符合设计要求。 研发流程中的产品测试 硬件单元测试白盒测试 根据详细设计选取关键/重要信号设计测试用 例，注意用例必须包括对测试结果的

26、预期。 通过测试验证板上关键/重要信号的完整 性，使信号在传输过程中忠实的再现原始波 形，从而保证功能的实现。 单板的EMC性能在很大程度上可以通过信 号完整性来保证。 研发流程中的产品测试 硬件单元测试白盒测试 狭义的信号完整性，是指因数字信号的模拟特 性而产生的任何影响信号传输的现象，严重时信号 传输发生紊乱，整个系统不能正常工作。 广义方面信号完整性可理解为：在需要的时间 内信号达到所需要的形状。 研发流程中的产品测试 板内信号完整性测试： 电源：电压值、纹波、负载能力 硬件单元测试白盒测试 时钟：电平、占空比、抖动、上升/下降沿、 准确度、稳定度； 数字信号：电平、上升/下降沿、过冲；

27、 模拟信号：输出电平范围，变化率、谐波、 失真； 。 研发流程中的产品测试 黑盒测试的重点是是各功能实体接口的性能 指标。具体来说除了板级接口性能以外，单板 内部各功能实体接口性能也需要进行测试。测 试的过程： 一是验证单板/功能模块的输入信号在需 求定义的变化范围内，输出信号是否达到设 计要求。 硬件单元测试黑盒测试 二是验证单板/功能模块的输出信号在符 合设计要求的情况下输入信号的最大允许变 化范围。 研发流程中的产品测试 输入信号不仅仅理解为接口输入信号，应用 环境的变化对单板的影响也应视为一种输入条 件，如温湿度、震动、电磁干扰等。 硬件单元测试黑盒测试 同样输出信号也不应仅仅理解为接

28、口输出信 号，单板/功能模块工作中对外界应用环境造成 的影响也应考虑在内，如EMI。 研发流程中的产品测试 多数情况下，EMC性能会在集成/系统测试 阶段进行，但是前期的信号完整性测试可以基 本反映系统的EMC性能。 硬件单元测试 在硬件不独立的情况下，为了避免软件问题 带来的测试误差，可以针对不同功能运行特定 的测试软件来验证硬件各部分的性能指标，如 串口测试、中断信号的产生及捕获等。 研发流程中的产品测试 集成测试的依据为产品概要设计，是对 由各模块组装而成的产品进行测试，主要检查 模块间的接口和通信。 硬件集成测试 不完善的总体/概要设计，会导致的各功能模块接 口的功能、指标定义有问题，使