研发流程中的产品测试

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

2、交流的目的3、产品需求规格说明书可能不会对备选事件和异常事件进行描述，即使是一一对应需求规格而设计的测试用例也会造成对备选事件和异常事件的测试遗漏，进一步降低测试有效性。4、单元测试、集成测试、系统测试所用测试用例完全一样，忽略了不同产品测试阶段所要关注的工作重点，使得产品设计缺陷难以在研发阶段暴露，后续影响量产产品的质量。本次交流的目的就是增强技术人员对测试工作的理解和认识，便于后续公司测试工作流程的持续改进。提纲 测试的目的和原则 测试的分类和方法 测试实施测试的目的和原则测试的目的 为使最终用户对产品满意，就必须保证产品功能性能达到用户需求。而验证产品功能性能否达到用户要求的唯一方法就是

3、持续有效的测试。 一点共识：测试的目的 从用户的角度出发，就是希望通过测试能充分暴露产品中存在的缺陷，以便决定是否买单。 从开发者的角度出发，就是希望测试能表明产品不存缺陷，已经完全正确地实现了用户需求。 两种角度：测试的目的 从情感角度来看，开发者是不愿意自己设计的产品被证明存在设计缺陷。 从应用角度来看，开发者往往是认为用户一定是按照自己设计好的操作模式来对产品进行操作的。 三个问题： 从实施角度来看，开发者总是对能够验证产品已经实现了预期功能的测试项目更加感兴趣。测试的目的 测试不仅仅是为了证明产品能够实现既定功能，还要尽可能多地发现产品中的错误和缺陷。 测试只能证明错误的存在，但不能证

4、明错误不存在。 四条结论： 研发产品质量保证的唯一方法就是尽量大覆盖范围下的有效测试。 测试的有效性是通过符合实际应用条件下的测试用例的设计及实施来保证。测试实施原则 由于惯性思维的存在使得难以发现设计缺陷，因此尽量避免设计人员来测试自己设计的产品，但是单元测试除外。 确定预期输出结果是测试用例必不可少的一部分。如果只有测试数据而无预期结果，那么就不容易判断测试结果是否正确。 彻底检查每个测试结果。如果不仔细检查测试结果，有些已经测试出来的错误也可能被遗漏掉。测试实施原则 对非法的和非预期的输入也要像合法的和预期的输入一样编写测试用例。 检查产品是否做了应做的事仅是成功的一半，另一半是看产品是

5、否做了不该做的事。 对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。测试实施原则 测试后遗留的错误数目往往与已发现的错误数目成比例。因此当A模块找出错误比B模块多得多时，很可能A模块遗留的错误仍比B模块遗留的错误多。 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。 妥善保存一切测试过程文档，测试的重现性往往要靠测试文档。测试实施原则 制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。 “尽早和不断的测试”应该成为一个合格的开发者的座右铭。

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

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

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

9、试用例的设计不可能做到完全覆盖，因此难以完全触发产品内部所有执行流程/路径，也就难以完全发现深藏在产品内部单元/模块及接口的设计缺限，需要有白盒测试进行补充。黑盒与白盒 白盒测试也称结构测试或逻辑驱动测试，在知道产品内部工作过程的前提下，按照产品内部的结构，通过测试来检测产品内部动作是否符合详细设计。 优点：优点：白盒法测试用例是围绕着产品设计实现角度出发，通过对其内部信号特征、接口功能性能的覆盖性检查来保证设计的正确性。 缺点：缺点：以详细设计为依据，以覆盖率为最终目标，因此缺乏宏观把握的能力。不能查出详细设计本身所存在的问题，即错误的产品设计。不可能查出被详细设计所遗漏的功能、性能。灰盒测

10、试 灰盒测试介于黑盒与白盒之间，关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。 灰盒法在用例设计中不关心模块内处理过程，只关心被测对象的输入与输出，这是典型的黑盒思维模式。 灰盒法在用例设计时基于对模块内部处理的了解，测试设计可以有针对性的进行，测试过程评估也是白盒法。模糊测试 模糊测试是黑盒法中的一种，其执行过程为：向产品有意识地进行无效输入以期望触发错误条件或引起产品的故障。 模糊测试最为形象的说法是：测试过程要做的就是站在后面向目标投掷石头，等待玻璃被打破的声音。就这个意义而言，模糊测试可被归结为

11、黑盒测试。 若我们对产品内部有所了解，就可以让石头每次的飞行路线更直接并且更真实。因此，模糊测试也可以应用在灰盒测试中。测试方法的选择 有一种观点认为： 在单元测试阶段采用白盒法； 在集成测试阶段采用灰盒法； 在系统测试阶段采用黑盒法。测试的分类 按测试步骤划分，有单元测试、集成测试、系统测试。 单元测试：单元测试：也称模块测试。测试的对象是设计的最小单位功能模块。单元测试的依据是详细设计描述，对模块内所有表达功能/性能的节点设计测试用例，以便发现模块内部的错误。单元测试主要发现详细设计阶段产生的错误。测试的分类 集成测试：集成测试：又称联合测试也称组装测试，它是对由各模块组装而成的产品进行测

12、试，主要检查模块间的接口和通信。 系统测试：系统测试：是把软、硬件和环境连在一起全面的测试，检查系统的功能、性能及其他特征是否与用户的需求一致，它是以需求规格说明书作为依据的测试。系统测试又可细分为功能测试、容量测试、压力测试、使用性测试、安全性测试、性能测试、可靠性测试、恢复测试、强度测试、文档测试以及工序测试。测试的分类 划分测试的种类并不重要，重要的是，一定要把测试看成是产品设计全生命周期持续不断而不是阶段性的工作。测试覆盖范围 正确性测试：正确性测试：测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能。 健壮性测试：健壮性测试：正确信息输入将产生预期输出， 非法信息输入将

13、导致相应提示或错误处理，而不至于系统/模块崩溃。 容错性测试：容错性测试：测试系统/产品的功能单元、接口间出现异常的情况下系统的保护性处理，以及异常结束后系统功能性能的恢复处理。测试覆盖范围 可靠性测试：可靠性测试：测试系统/产品在实际应用环境下可保证性能功能有效性的能力。 压力测试：压力测试：测试在大信息量处理情况下的系统/产品正常工作的能力。 回归测试：回归测试：测试上一轮测试所发现缺陷的解决及对系统的潜在影响。软件测试与硬件测试 软件测试：软件测试：软件不涉及制造加工，因此软件测试的目的仅仅是验证设计的正确性。 硬件测试：硬件测试：除了验证设计正确性以外，还要包括制造的准确性，或者一致性

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

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

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

17、。 预期结果：预期结果：提供测试执行的预期结果，预期结果应该根据产品需求中的输出得出。 基本事件：基本事件：描述该测试用例的基本操作流程，指每个流程都“正常”运作时所发生的事情。基本事件用以测试在正确环境及操作下产品所能实现的性能、功能。测试用例要素 备选事件：备选事件：表示这种行为或流程是可选的或备选的，并不是总要执行。 异常事件：异常事件：表示在发生某些非正常的事件后产品所要执行的响应。 正面测试：正面测试：用于验证被测单元能够执行应该完成的工作。 负面测试：负面测试：用于验证软件不执行其不应该完成的工作。测试用例设计白盒法 白盒测试是穷举类测试，主要强调的是覆盖率，即测试用例要覆盖单元内

18、部所有处理流程。 对软件来讲就是代码路径的覆盖率，对于硬件测试来讲则是检查所有电路节点的响应信号。 受到进度和资源的约束，不可能达到完全覆盖率，折衷办法就是选取关键重要的部分进行测试用例的设计。测试用例设计白盒法 语句覆盖语句覆盖：检查到模块中每个语句执行情况。 判定覆盖判定覆盖：检查到模块中每个分支/信号流执行情况。 条件覆盖条件覆盖：使判定中的每个条件获得各种可能的结果。 判定判定/条件覆盖条件覆盖：选择足够的测试用例，使得判定中每个条件取到各种可能的值，并且每个判定取到各种可能的结果。 条件组合覆盖条件组合覆盖：执行足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。覆盖率由

19、低到高覆盖率由低到高 路径覆盖路径覆盖：执行足够的测试用例，使得每条路径至少被执行一次。测试用例设计白盒法 白盒法实施深度： 白盒法（包括设计文档评审、软件代码检查）工作量应占到测试总工作量的50。 对测试缺陷进行统计分析，白盒法发现的缺陷要达到总缺陷数的50以上。测试用例设计黑盒法 黑盒法是测试者完全不考虑功能模块内部结构和处理过程，而只是根据功能说明来设计测试用例，检查模块功能是否符合规格说明的要求。 等价分类法 边缘值分析法 因果图法 错误推测法测试用例设计黑盒法 等价分类法等价分类法：在输入数据中选择一组子集，每个子集选择一个具有“代表性”的测试用例，使这个测试用例可以代表一大类的有同

20、样共性的其他测试用例，这就形成了一个等价类。这样就可使用少数的等价类测试用例能发现较多的错误。 等价分类法分为二步：1. 根据功能说明中的输入条件划分等价类；2. 按等价类来选择测试用例。测试用例设计黑盒法 边缘值分析法边缘值分析法：与等价分类法的差别主要在于边缘值分析法是着重检查等价类边界上的情况。 若某个输入条件说明了值的范围，则可选择恰好取到边界值的用例；另外再编写一些代表不合理输入数据的用例，它们的值恰好超过边界。 如果一个输入条件指出了输入数据的个数，则为最小个数，最大个数，比最小个数少1，比最大个数多1，分别设计用例。测试用例设计黑盒法 因果图法因果图法：因果图法则着重检查输入条件

21、的各种组合情况，消除等价分类法和边缘值分析法没有检查各种输入条件的组合的缺点。 从用自然语言书写的功能说明中找出因（输入条件）和果（输出或程序状态的修改）； 通过画因果图将功能说明转换成判定表，然后为判定表的第一列设计测试用例。 因果图法是设计测试用例的一个系统的方法。测试用例设计黑盒法 错误推测法错误推测法：通过经验或直觉推测程序中可能存在的各种错误，从而有针对性的编写测试用例，这就是错误推测法。 错误推测法没有确定的步骤，很大程度上是凭经验进行的。 前述概念是随着软件测试的发展而提出并逐渐完善。测试用例设计 相对而言，硬件测试并未能够形成一种完善的理论和实施流程，其主要原因在于硬件的多样性

22、以及硬件系统难以独立于软件而单独实现。 对于软件测试用例的设计有许多参考文献，这里不再描述。后续仅对硬件测试谈谈一些理解和体会。 测试目的：验证设计的正确性、制造准确性，以及查找、排除现场故障；硬件测试 测试对象：可测量信号的时域频域形状、指标偏差、容限、极限参数。 测试项目：指标、功能、可靠性、一致性。 测试方法：白盒测试、黑盒测试。 测试阶段：单元测试、集成测试、系统测试。硬件单元测试 单元测试主要是指单板测试，一般采用白盒及黑盒测试相结合的方法，主要进行性能指标测试。 白盒测试的目的是保证板上各级信号的完整性。 黑盒测试的目的是验证板上及板间接口信号是否符合设计要求。硬件单元测试白盒测试

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

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

25、也应考虑在内，如EMI。 多数情况下，EMC性能会在集成/系统测试阶段进行，但是前期的信号完整性测试可以基本反映系统的EMC性能。硬件单元测试 在硬件不独立的情况下，为了避免软件问题带来的测试误差，可以针对不同功能运行特定的测试软件来验证硬件各部分的性能指标，如串口测试、中断信号的产生及捕获等。 集成测试的依据为产品概要设计，是对由各模块组装而成的产品进行测试，主要检查模块间的接口和通信。硬件集成测试 不完善的总体/概要设计，会导致的各功能模块接口的功能、指标定义有问题，使得模块间通信不正常。这样的问题在单元测试中是无法检验的。 产品结构限制各功能模块在空间上不能完全隔离，使得组装后的产品各功能模块间可能产生相互干扰，导致产品性能的下降，严重的会导致产品无法工作。 单元测试有效性不可能达到100，导致部分指标没有被测试到或者测试结果的不正确。 集成测