单元测试/集成测试自动化工具--WinAMSCoverageMaster winAMS : 适用于嵌入式目标机代码的单元测试/集成测试工具全面支持嵌入式微机！验证嵌入式C/C++软件 实施以模块为单位的自动化单元测试工具不需要HookCode 直接使用目标机代码进行单元测试联合静态解析工具[CasePlayer2]，提供C0（语句）,C1（判定）,MC/DC覆盖率报告，优化测试用例制作已取得第三方认证机构TUVSUD对适用于汽车机能安全ISO26262软件工具的认证产品概要[Coverage master winAMS]是以嵌入式软件的函数为单位，实施模块单元测试以及C0/C1/MCDC覆盖率测试（coverage test）的嵌入式软件自动化单元测试工具。目标机源代码通过交叉编译器生成目标机执行代码，通过跟实际处理器同样的模拟处理器环境进行单元测试，不需要对执行代码做任何变动，使高信赖性的模块测试成为可能。在汽车控制软件这样的对安全性要求极高的领域，单元测试已经成为不可缺少的一部分。使用目标机代码进行单元测试也是为了符合汽车行业中ISO26262功能安全认证标准。产品特长全面支持嵌入式微机！验证嵌入式C/C++软件 实施以模块为单位的自动化单元测试工具作为能够检验出仅凭系统测试以及整体测试无法发现的[潜在错误]的检测方法，[单元测试]在嵌入式开发领域受到广泛重视。同时，单元测试也是汽车用软件功能安全（ISO26262）领域中要求实施的认证项目之一。[Coverage master winAMS]直接使用通过交叉编译生成的目标机代码，在模拟处理器环境下进行单元测试。既能实现C语言程序的逻辑上的单元验证，又能够对嵌入式微机组装为产品后可能发生的问题等进行具有高信赖度的白盒（white box）测试。不需要HookCode 使直接使用目标机代码进行单元测试成为可能的业界唯一的工具有些公司的单元测试工具往往采用在被测试对象的源代码中追加测试用代码或者测试用驱动器的方法，导致测试时所用的代码与组装为产品后的目标机用代码不同。虽然[理论上运行功能应该是相同的]，但是从嵌入式开发的角度考虑，这样就如同对交叉编译所生成的经过优化处理的代码进行了加工，无法确保最终产品的质量。Coverage master winAMS是业界唯一的，具有[不需要对被测试对象做任何加工]实施单元测试功能的工具，特别是在安全性要求高的领域中得到很高的评价。不需建立单元测试专用的环境，可以在开发用交叉编译环境进行单元测试Coverage master winAMS不需要追加任何测试用驱动器或测试用代码，可以直接使用将组装成产品的目标代码进行单元测试。单元测试能够与软件开发使用共同的交叉编译环境，不再需要对测试资源进行专门管理，也不再需要建立其他专用环境。因此，既方便程序资源管理，又能够缩短准备测试环境所需的时间。符合汽车功能安全标准（ISO26262）[不做加工直接使用目标机代码实施单元测试]这一要求的最佳工具ISO26262是从IEC61508衍生出来的适用于汽车制造领域的功能安全标准。其中的Part.6-9[软件程序单元测试]包括了关于软件程序的构造覆盖率测试以及有关的规定项目。根据汽车安全标准（ASIL），提出了测试语句覆盖率（statement coverage），分支覆盖率（branch coverage），MC/DC覆盖率的推荐性事项。其中的另一个推荐性事项是[尽可能使单元测试的环境与目标环境相同]的规定。如果在与目标环境不同的环境下进行单元测试，必须表明源代码与目标代码的差别，以及目标环境和测试环境的差别。因此，对于那些使用与目标微机不同的电脑进行编译和单元测试的其他公司的工具而言，这个要求很难满足。 还有些公司的单元测试工具虽然包括交叉编译环境及编译功能，而且也能够在与目标环境相同的环境下进行测试，但是所有的测试都需要插入测试用代码，进行再次编译，因此测试也只能在与目标环境不同的环境下实施。GAIO提供的单元测试工具Coverage master winAMS具有●采用全面支持嵌入式微机的微机化功能测试平台环境●不需要插入测试用代码直接使用目标机代码进行测试的特征，提供符合ISO26262标准要求的必须功能。GAIO提供的Coverage master winAMS是符合ISO26262标准[直接使用整装用代码实施单元测试]这一要求的业界唯一的工具。关于汽车机能安全ISO26262的对应以及认证的获得已取得第三方认证机构TUVSUD对适用于汽车机能安全ISO26262软件工具的认证2012年6月28日，「Coverage master winAMS / General」测试工具获得由德国TUVSUD第三方认证机构，在汽车机能安全规格的ISO26262软件工具方面的认证，包括日本在内亚洲地区首次获得该项认证。通过此项认证，说明本公司的单元测试工具「Coverage master winAMS / General」，以及程序分析工具「CasePlayer2」，在静态分析和单元测试领域，是符合所有安全度水准的工具，并由TUVSUD认证机构得到了保障。ISO 26262对于不同的开发用软件工具在工具置信水平（TCL），都需要开发者提供开发软件工具的认证书。此项认证适用于在工具认证当中，最为复杂的TCL3工具认证标准。因此，导入本公司的单元测试工具之后，不需要对TCL的部分进行认证，进而可以缩减手续跟时间。主要的单元测试功能采用SSTManager管理单元测试projectSSTManager是Coverage master winAMS的应用功能，用于管理单元测试project，制作测试数据（test data）。从设定测试环境开始，到报告测试结果为止，均由微机化功能测试平台（ISS）实施综合管理。采用通用便利的CSV文件管理测试数据的输入输出Coverage master winAMS不需要插入测试用代码，直接使用目标机代码进行单元测试。采用通用便利的CSV文件管理函数测试时使用的输入输出数据。测试结束后，输出的测试结果和输出的期待值也将以相同的格式显示在CSV文件之中。C0/C1覆盖率报告的自动化制作功能（标准功能）根据测试的输入输出数据自动报告相应源代码的C0/C1测试覆盖率结果。包括通过图形（viewer）显示测试数据，以及与其相应的被测试的源代码路径的功能，用于分析测试结果。作为选项功能也包括MC/DC覆盖率测试功能。MC/DC覆盖率的自动化测试功能（选项功能）作为选项功能提供MC/DC覆盖率测试功能。C0/C1覆盖率测试不需要加工即可直接使用目标机代码。然而，MC/DC覆盖率测试对于复合式的条件式，需要自动插入HookCode将复合式的条件式分解，才能对各条件式进行测试。这样就有可能导致测试用代码与目标机用代码的不同。为了验证HookCode的妥当性，在MC/DC覆盖率测试的同时，运行目标机代码，确认运行结果与期待值的一致性。注:右图举例显示，第2个if句的复合条件式中，[gbc>30]为false时的分支没有被测试到。以C1覆盖率测试来说，它的测试结果是OK；而对于MC/DC覆盖率测试来说，它的结果是NG。注: MC/DC覆盖率测试功能不支持C++程序。单元测试的效率化功能联合程序解析工具CasePlayer2，实现代码参照解析作业的效率化利用CasePlayer2生成的流程图表以及模块构造图（调用函数的构造图）与源代码的连接（link）功能，使单元测试用源代码的解析工作效率化。能够自动检索被测试函数的外部变量，使测试条件设定效率化联合程序解析工具CasePlayer2，自动检索被测试函数所使用的外部变量。缩短了以往必须对源代码进行搜索找出输入条件的变量所需的工作。而且，能够防止人工操作导致的类似变量指定遗漏的的错误。根据代码解析自动化制作C0，C1，MC/DC 覆盖率测试计划联合程序解析工具CasePlayer2，自动化制作符合覆盖率测试要求的条件分支if,switch,for,while等的测试数据。可以将被测试函数中含有的条件式（if以及switch等）在数据制成图形(Viewer)上列表显示。点击其中的条件，工具将自动开始检索与之相关的变量，进而从所设置的条件的境界值中自动生成覆盖率测试所需要的数据。为了达到C1/MCDC覆盖率，测试时需要对各函数的数据进行组合。利用CasePlayer2提供的解析结果，分析条件式的net构造，在重复性限制在最小限度下生成C1/MCDC覆盖率测试用数据。支持MPU　CoverageMaster winAMS Supported Processor List(English)动作环境・操作PC/OS・IBM PC/AT 兼容机・Pentium(相当) 2GHz 以上的CPU・存储器 512MB 以上（推荐值）・显示器分辨率 XGA(1024*768)以上（推荐值）・Windows XP, Windows Vista, Windows 7（32bit/64bit）（※Windows 95/98/Me/NT/2000 未支持）

 1         单元测试的重要性1.1      一些错误的认识在实际的单元测试过程中总会有一些错误的认识左右着我们，使之成为单元测试最大的障碍，在此将其一一分析如下：它太浪费时间了，现在要赶进度，时间上根本不允许，或者随便做做应付领导。我是一个很棒的程序员，我写的代码肯定是没有问题的。做单元测试太烦了，直接集成，到时有问题在集成测试时肯定能发现的，实在不行在系统测试总该能发现吧。它仅仅是证明这些代码做了什么。对于以上错误认识的产生归根结底还是由于对单元测试的理解还是不够，没有真正认识到单元测试的重要性。1.2      测试的重要性单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。从如下几个方面就可以看出单元测试的重要性在何处。时间方面：如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。 测试效果：根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。测试成本：在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时，则在集成测试时发现该问题需要2个小时，在系统测试时发现则需要3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。 产品质量：单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。    综上所述，单元测试是构筑产品质量的基石，我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间，我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来！1.3      具有的优点1. 它是一种验证行为。程序中的每一项功能都是测试来验证它的正确性，为以后的开发提供支缓。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障，这样，我们就可以更自由的对程序进行改进。2.它是一种设计行为。编写单元测试将使我们从调用者观察、思考，特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。另外还可以使编码人员在编码时产生预测试，将程序的缺陷降低到最小。3.它是一种编写文档的行为。单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。4.它具有回归性。自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。 2         单元测试的基本理论2.1      基本概念1. 单元测试：单元测试又称模块测试，属于白盒测试，是最小单位的测试。模块分为程序模块和功能模块。功能模块指实现了一个完整功能的模块（单元），一个完整的程序单元具备输入、加工和输出三个环节。而且每个程序单元都应该有正规的规格说明，使之对其输入、加工和输出的关系做出名明确的描述。2.测试驱动：驱动被测试模块正常运行起来的实体3.测试桩：代替被测模块调用的子模块的实体，该实体一般为桩函数。4. 测试覆盖：评测测试过程中已经执行的代码的多少。5.覆盖率：代码的覆盖程度，一种度量方式。针对代码的测试覆盖率有许多种度量方式，定义如下： 语句覆盖（StatementCoverage）：也称为行覆盖（linEC）,段覆盖（segmentcoverage）和基本块覆盖（bAS）。它度量每一个可执行语句是否被执行到了。icblockcoverageoverage判定覆盖（DecisionCoverage）：也被称为分支覆盖（branchcoverage），所有边界覆盖（all-edgescoverage），基本路径覆盖（basispathcoverage），判定路径覆盖（decision-decision-path或DDPtesting）。它度量是否每个BOO型的表达式取值true和false在控制结构中都被测试到了。L 条件覆盖（ConDI）：它独立的度量每一个子表达式，报告每一个子表达式的结果的true或false。这个度量和判定覆盖（decisioncoverage）相似，但是对控制流更敏感。不过，完全的条件覆盖并不能保证完全的判定覆盖。tionCoverage 路径覆盖（PathCoverage）：也称为断言覆盖（prEDI），它度量了是否函数的每一个可能的分支都被执行了。路径覆盖的一个好处是：需要彻底的测试。但有两个缺点：一是，路径是以分支的指数级别增加的，例如：一个函数包含10个IF语句，就有1024个路径要测试。如果加入一个IF语句，路径数就达到2048；二是，许多路径不可能与执行的数据无关。catecoverage循环覆盖（LOOP）：这个度量报告你是否执行了每个循环体零次、只有一次还是多余一次（连续地）。对于do-while循环，循环覆盖报告你是否执行了每个循环体只有一次还是多余一次（连续地）。这个度量的有价值的方面是确定是否对于while循环和for循环执行了多于一次，这个信息在其它的覆盖率报告中是没有的。 2.2      测试的内容单元测试的对象是软件设计的最小单位——模块或函数，单元测试的依据是详细设描述。测试者要根据详细设计说明书和源程序清单，了解模块的I/O条件和模块的逻辑结构。主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理和不合理的输入都能鉴别和响应。要求对所有的局部和全局的数据结构、外部接口和程序代码的关键部分进行桌面检查和代码审查。在单元测试中，需要对下面5个方面的内容进行测试，也是构造测试用例的基础。1)   模块接口：测试模块的数据流。如果数据不能正确地输入和输出，就谈不上进行其他测试。因此，对于模块接口需要如下的测试项目：调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；所测模块调用子模块时，它输入个子模块的参数与子模块的形式参数在个数、属性、顺序上是否匹配；是否修改了只做输入用的形式参数；输出给标准函数的参数在个数、属性、顺序上是否匹配；全局变量的定义在各模块中是否一致； 限制是否通过形式参数来传送。2)  局部数据结构测试：模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误： 检查不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量； 错误的初始值或错误的默认值；变量名拼写错误或书写错误； 不一致的数据类型。3)路径测试：对基本执行路径和循环进行测试会发现大量的错误。根据白盒测试和黑盒测试用例设计方法设计测试用例。设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。常见的不正确的计算有：Ø         运算的优先次序不正确或误解了运算的优先次序；Ø         运算的方式错误（运算的对象彼此在类型上不相容）；Ø         算法错误；Ø         初始化不正确；Ø         运算精度不够；Ø         表达式的符号表示不正确等。 常见的比较和控制流错误有：Ø         不同数据类型的比较；Ø         不正确的逻辑运算符或优先次序；Ø         因浮点运算精度问题而造成的两值比较不等；Ø         关系表达式中不正确的变量和比较符；Ø         “差1错”，即不正确地多循环或少循环一次；Ø         错误的或不可能的循环终止条件；Ø         当遇到发散的迭代时不能终止循环；Ø         不适当地修改了循环变量等。4) 错误处理测试：比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理对策，以便在程序出错时，能对出错程序重新做安排，保证其逻辑上的正确性。这种出错处理也是模块功能的一部分。表明出错处理模块有错误或缺陷的情况有：出错的描述难以理解；出错的描述不足以对错误定位和确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预； 如果出错情况不予考虑，那么检查恢复正常后模块可否正常工作。5) 边界测试：边界上出现错误上常见的。设计测试用例检查： 在n次循环的第0次、1次、n次是否有错误；运算或判断中取最大最小值时是否有错误；数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。 2.3      测试的环境构成何时进行单元测试？单元测试在编码阶段进行。在源程序代码编制完成、经过评审和验证、确认没有语法错误之后，就可以开始进行单元测试的测试用例设计。要利用软件设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应该有预期的正确结果。在单元测试时，如果模块不是独立的程序，需要辅助测试模块，有两种辅助模块：驱动模块（Driver）：所测模块的主程序。它接收测试数据，把这些数据传递给所测试模块，最后再输出测试结果。当被测试模块能完成一定功能时，也可以不要驱动模块。 桩模块（Stub）：用来代替所测模块调用的子模块。      被测试模块、驱动模块和桩模块共同构成了一个测试环境，如下图所示：3         测试方法与过程3.1      用例设计1.测试用例的组成（在单元测试中测试用例基本上由测试脚本组成）用例运行前置条件被测模块/单元所需环境（全局变量赋值或初始化实体）启动测试驱动设置桩调用被测模块设置预期输出条件判断2.测试用例的设计原则一个好的测试用例在于能够发现至今没有发现的错误；测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；在测试用例设计时，应当包含合理的输入条件和不合理的输入条件；为系统运行起来而设计测试用例；为正向测试而设计测试用例；为逆向测试而设计测试用例；为满足特殊需求而设计测试用例；为代码覆盖而设计测试用例；3.用例设计方法1)        规范（规格）导出发2)        等价类划分法3)        边界值分析法4)        状态转移测试法5)        分支测试法6)        条件测试法7)        数据定义－使用测试法（又名数据流测试法）8)        内部边界值测试法9)        错误猜测法4. 特定的用例测试设计1)声明测试：检查模块中的所有变量是否被声明。经验表明，大量重要的错误都是由于变量没有被声明或没有被正确的声明而引起的。2)路径测试：要求模块中所有可能的路径都被执行一遍，属逻辑覆盖测试。基本路径测试：由于实际中，一个模块中的路径可能非常多，由于时间和资源有限，不可能一一测试到。这就需要把测试所有可能路径的目标减少到测试足够多的路径，以获得对模块的信心。要测试的最小路径集就是基本测试路径集。基本测试路径集要保证：每个确定语句的每一个方向要测试到；每条语句最少执行一次。3)循环测试：重点检查循环的条件－判断部分以及边界条件。测试循环是一种特殊的路径测试，因为循环比其他语句都复杂一些。循环中错误的发生机会比其他代码构成部分多。因此，对于任何给定的循环测试应该包括测试下面每一条件的测试用例： 循环不执行； 执行一次循环；执行两次循环；反映执行典型的循环的执行次数；如果有最大循环次数，最大循环次数减1；最大循环次数；大于最大循环次数。对于增量和减量不是1的FOR语句，要特别注意，因为程序员习惯于增量1。4) 循环嵌套：循环嵌套使逻辑的次数呈几何级数增长，设计测试嵌套循环的测试用例应该包括的测试条件有：把外循环设置为最小值，并运行内循环所有可能的情况；把内循环设置为最小值，并运行外循环所有可能的情况；把所有的循环变量都设置为最小值运行；把所有的循环变量都设置为最大值运行； 把外循环设置为最大值，并运行内循环所有可能的情况；把内循环设置为最大值，并运行外循环所有可能的情况；5) 边界值测试：指程序内部边界测试。检查确定代码在任何边界情况下都不会出差错。重点检查小于、等于和大于边界条件的情况。边界值测试是指专门设计用来测试当条件语句中引用的值处在边界或边界附近时系统反映的测试。被测试语句的最好的例子就是“IF-THEN…ELSE-ENDIF”部分。这样语句的例子如：IF a <= 123 THENb = 1ELSE IF a >= 123 THENb = 2ELSE b = 3END IF           上面例子中的边界值测试用例应该至少包括a的以下值：122，123，124。当a=123时，b=1还是2。（找出逻辑判断的矛盾）6)接口测试：检查模块的数据流（输入、输出）是否正确。检查输入的参数和声明的自变量的个数，数据类型和输入顺序是否一致。检查全局变量是否被正确的定义和使用等。7)确认测试：是否接受有效输入数据（操作），拒绝无效数据（操作）。8)事务测试：输入－>输出，错误处理。3.2      用例执行一般来说，做单元测试均采用的是商用的测试工具或自行开发的测试工具，用例的编写都是在测试工具上完成，测试用例都是一些测试脚本，都以文件的方式来保存，故其用例的执行过程主要是由测试工具根据所编写的具体的测试用例脚本来完成，这样对于用例的管理和执行也非常灵活。在特定场合，比如某种压力测试或极限测试，对于测试执行过程时间很长时（几个小时以上），一般都预先编写好用例（确保用例无误），使用空闲机或非工作时间执行测试用例，这样操作起来较节约时间。在用例的执行过程中务必注意如下事项： 程序的执行过程―――便于构造发散用例不要放过任何细节―――这种细节可能就是问题 3.3      测试优化和策略在测试的过程中为了提高测试效率和效果，不断的减少冗余劳动，也为后期的回归测试和测试管理带来很大的方便，不至于感到测试很混乱无序。因此我们要对测试用例和测试执行进行不断的优化，以测试策略为指导方针进行测试。1、测试用例的优化    测试用例的优化主要是指用例的合并、修改和删除，减少冗余的无价值的测试，其优化依据来源于测试后的测试数据分析和评估，其中测试覆盖也是用例优化的主要参考。2、测试执行的优化        测试执行的优化主要是指测试步骤的优化，减少测试人员的手工操作，因为太多的手工操作会导致测试人员很厌倦，直接影响测试效果，优化依据来源于测试总结。3、测试策略    在测试过程中由于时间或资源的原因可能会使测试处于紧张的局面，在此情况下我们要采取一定的策略来解决此局面。策略来源于测试数据的分析，主要的方法是：为各模块制定测试优先级，其优先级的划分依据如下：哪些是重点模块？ 哪些程序是最复杂、最容易出错的？ 哪些程序是相对独立，应当提前测试的？ 哪些程序最容易扩散错误？哪些程序是开发者最没有信心的？ 80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错，这种应该列入测试重点。 3.4      测试评估   单元测试完成以后，需要对单元测试的执行效果进行评估，主要从以下几方面进行：1)测试完备性评估，主要检查测试过程中是否已经执行了所有的测试用例，对新增的测试用例是否已及时更新测试方案等。2)代码覆盖率评估，主要是根据代码覆盖率工具提供的语句覆盖情况报告，检查是否达到方案中的要求，公司要求语句覆盖达到100％。但很多情况下，第一轮测试用例执行完后是很难达到的，这时在评估过程中要对覆盖率进行分析，主要从以下方面来考虑：不可能的路径或条件不可达的或冗余的代码不充分的测试用例3) 从覆盖的角度看，测试应该覆盖： 功能覆盖 输入域覆盖输出域覆盖函数交互覆盖代码执行覆盖   大多数有效的测试用例都来自于分析，而不是仅仅为了达到测试覆盖率目标而草率设计测试用例。千万不要误解测试覆盖，测试覆盖并不是我们最求的目的，它只是评价测试的一种方式，为测试提供指导和依据。3.5      测试过程1.测试过程中各种人员的作用系统分析设计人员     进行需求跟踪，确保系统需求的实现和更新。进行软件单元可测性分析，确定单元测试的对象、范围和方法。软件开发人员     负责编码和单元测试过程，完成单元测试计划、方案和报告。软件测试人员     参与单元测试计划、方案和报告的评审，对单元测试的计划、设计和执行质量进行监控。根据实际情况，可选择参与由开发人员负责的代码检视、单元测试等活动。 配置管理人员    对代码及单元测试文档进行配置管理。质量保证（QA）人员     参与编码与单元测试评审，对编码和单元测试过程进行审计。2.  单元测试输入《软件需求规格说明书》《软件详细设计说明书》《软件编码与单元测试工作任务书》《软件集成测试计划》《软件集成测试方案》用户文档3.单元测试的输出《单元测试计划》《单元测试方案》《需求跟踪说明书》或需求跟踪记录 代码静态检查记录《正规检视报告》 问题记录 问题跟踪和解决记录软件代码开发版本《单元测试报告》《软件编码与单元测试任务总结报告》3.6      测试实施1.  单元测试实施步骤1)        制定测试计划和测试方案（包括测试工具的选择）2)        根据计划和方案及相关输入文档编写测试用例3)        搭建测试环境4)        执行测试5)        记录和跟踪问题6)        编写测试报告和总结报告2.  单元测试实施遵循的原则 精心制定测试计划 严格评审测试计划 严格执行测试计划系统分析测试结果并提交报告4         常用测试工具介绍常用的C语言单元测试工具介绍如下： winAMS、CasePlayer21)        简介GAIO公司的覆盖率专家winAMS获得机能安全标百准ISO26262/IEC61508工具认证，是日本工业制造度领域普遍使用的针对C/C++的单元/集成测试工具。winAMS将通过交叉编译生成的原始代码作为评价代码，具有使用芯片仿真器进行仿真功能的测试工具。不仅可以对C/C++语言编写的程序进行逻辑水平的测试，还可以对嵌入式软件特有的依存于芯片的问题点进行确认。2)        功能特性尽可能使单元测试的环境与目标环境相同采用全面支持嵌入式微机的微机化功能测试平台环境不需要插入测试用代码直接使用目标机代码进行测试取得第三方认证机构TUVSUD对适用于汽车机能安全ISO26262软件工具的认证测试工程管理

1.1 MySQL单元测试介绍 MySQL有两套单元测试工具，一个是tap，一个是gtest，现在用gtest。 tap：#include "unittest/mytap/tap.h" gtest： 1.2 目录结构单元测试主目录：unittest examples：tap参考用例目录gunit:gtest用例目录mytap：tap工具目录 gunit目录： 1.3 编译编译时要加上这个参数：-DENABLE_DOWNLOADS=1会自动下载gtest工具。 如果无法自动下载，自己下载googletest-release-1.8.1.zip放到source_downloads目录下，无需解压。 修改了原代码可能会导致编译不通过，需要修改单元测试的CMakeLists.txt或代码。 如何判断编译是否成功，进入unittest目录执行ctest命令1.4 测试方法单元测试要在build目录下执行，不能在install目录下执行。1.4.1 全量测试build主目录下执行ctest 1.4.2 执行gtest用例unittest/gunit下执行ctest 或 make test 1.4.3 执行单个测试集或单个用例文件runtime_output_directory1.4.4 执行单个用例 -h 查看帮助信息1.5 添加单元测试用例文件名要加-t ，没有加-t的文件编译成库文件供用例链接。  1.6 用例编写1.6.1 gtest使用略过 1.6.2 gmock使用包含头文件 使用步骤：定义一个Mock类： 创建一个Mock对象 定义Mock对象的行为EXPECT_CALL 执行测试代码 

在SDC D2150上训练好的分类网络：单元测试结果  和 集成测试结果不一致集成测试： 通过灌流 通过“分类网络”（使用nnie）计算后，得到每一个图片和分类得到的分数。单元测试：将集成测试得到的所有图片，每次一张图片的进行“分类网络”计算后，得到分类的分数。【测试结果】1. 集成测试 和 单元测试 结果不一致，差异很大；2. 单元测试结果（计算得到的分数）是正确的（或正常的）；3. 集成测试结果中，有部分结果异常（应该低分的得到高分，应该高分的得到低分）；【请问】1. 可能什么原因导致以上的结果？2. 在 图片数据 传给sdc  nnie时，如何确定nnie接收到的数据是传入进去的？如何确保nnie完整的接收输入数据？2. 如何将传入sdc nnie的图片数据，从sdc  nnie读取出来并保存？【追加问题 20210918】1、使用nnie是否有调用频率的限制？（比如不能调用太频繁太快了，不然会导致结果异常）     在使用过程中，发现调用频率太高，会出现输入数据是对的，但调用nnie结束后，输入数据被篡改了（这里没有写错，是输入数据被篡改，不是输出数据）

【功能模块】910平台AKG单元测试【操作步骤&问题现象】1、910平台AKG在单元测试时出现OSError: libakg.so:  undefined symbol:_ZN6Msprof6Engine21MsprofCallbackHandler10reporters_E2、这个函数应该来源于名为libmsprofiler_fwkacl.a的静态库, 使用nm命令可以在libakg.so中找到这个函数, 但是运行时却会报错, 原因在哪?【截图信息】【日志信息】（可选，上传日志内容或者附件）

　　当我第一次听说TDD(Test-Driven Develop, 测试驱动开发)的时候，我首先想到的是测试小姐姐们想搞事情？后面发现这个玩意儿是想干掉测试，那好，下面开始让我们干掉这群整天给我们找bug…下面开始从简单的单元测试上手Jest测试框架。我们能学到什么Jest怎么4行代码完成一个测试用例Jest怎么让测试用例覆盖率100%Jest怎么和Typescript完美结合（填坑实录）Jest最锋利的功能 Mock Functions项目初始化创建工程# 注意powershell中'&&'替换为';'mkdir jest-just-go && cd jest-just-go初始化npm init -y安装依赖npm i jest --save-dev1.Jest怎么4行代码完成一个测试用例初始化Jest默认配置npx jest --init初始化时会出现提示信息，按y或enter即可。编写功能代码　　现在让我们正式开始，茶和图雀社区精心准备的甜品更搭哦。　　在项目根目录下新建src目录，存放我们的功能代码。然后创建src/dessert.js。const dessert = function (name) { this.name = name; } dessert.prototype = { enjoy: function () { return "Enjoy the " + this.name; } }module.exports = dessert;　　我们已经编写了一个甜品类型，它有一个提供品尝的方法enjoy编写测试用例　　下面开始编码，实现对上面甜品功能的单元测试。　　在项目根目录下新建__tests__目录，存放我们的测试用例。然后创建__tests__/dessert.test.js。const dessert = require("../src/dessert"); describe("test dessert feature", () => { test("enjoy the cake", () => { const cake = new dessert('cake'); expect(cake.enjoy()).toBe("Enjoy the cake"); } }　　简单的四行代码，我们的第一个测试用例就已经大功告成。这里我们只需要注意 describe、test、expect 这3个 Jest 关键字就行了：describe：组合同一类的 test 用例，可以添加 beforeEach \ afterEach、beforeAll \ afterAll （这里由于篇幅，这一类进阶特性将放在后续的教程中）为其下所有 test 进行统一描述和处理。test：描述具体的测试用例，是单元测试的最小单元。expect： Jest 最终落在了每一个对测试结果的 期望 上，通过 expect 中的返回值或是函数执行结果来和期望值进行对比。执行测试　　回到控制台，输入:npm test　　无需更多配置，测试结果显示如下：　　其中：%Stmts 是语句覆盖率（statement coverage）：是不是每个语句都执行了？%Branch 分支覆盖率（branch coverage）：是不是每个if代码块都执行了？%Funcs 函数覆盖率（function coverage）：是不是每个函数都调用了？%Lines 行覆盖率（line coverage）：是不是每一行都执行了？　　%Stmts 和 %Lines 的区别是：行覆盖率的颗粒度是大于语句覆盖率的，因为可能允许一行中有多条语句（js开发中尤为常见）。　　我们更改__tests__/dessert.test.js：expect(cake.enjoy()).toBe("Enjoy the cake");　　改为expect(cake.enjoy()).toBe("enjoy the cake");　　执行测试命令查看测试不通过的情形：2.Jest怎么让测试用例覆盖率达到100%　　当我们的功能场景逐渐变得复杂，我们的测试就必须确保测试用例的覆盖率达到一个标准。最佳当然是100%啦，这样才能保证测试小改改们找不到我们的茬，闲的没事就会主动找我们拉话话啦，美好生活从测试用例覆盖率100%开始。编写功能代码　　甜点不够怎么办？要不我们开家店吧！先让红豆烧和提拉米苏够吃先~const dessert = require("./dessert"); const dessertFactory = function () { } dessertFactory.produce = function (type) { switch (type) { case 'Red bean burning': return new dessert('Red bean burning'); // 红豆烧 case 'Tiramisu': return new dessert('Tiramisu'); // 提拉米苏 default: throw new Error("please choose a dessert type"); } }module.exports = dessertFactory;　　现在想吃什么通过dessertFactory.produce(...)order就fine啦~编写测试用例　　不过，要保证我们想吃的时候就必须能吃到（这个很重要），我们先验收先：　　__tests__/dessertFactory.test.jsconst dessertFactoty = require("../src/dessertFactoty"); describe("test dessertFactoty feature", () => { test("produce all dessert", () => { const dessertType = ['Red bean burning', 'Tiramisu']; expect(dessertFactoty.produce(dessertType[0]).enjoy()).toBe("Enjoy the Red bean burning"); } }　　–“我不要你觉得，我要我觉得“，我要上档次的“验收报告“！　　–行，网页展示出来怎么样配置jest.config.js保存测试用例覆盖率执行报告　　我们在执初始化Jest默认配置的时候，会生成在项目根目录下生成jest.config.js，里面列出了所有的配置项，未设置的已经被注释掉了。我们要将每次执行测试后生成的覆盖率报告保存下来需要找到下面这项配置属性并更改：// Indicates whether the coverage information should be collected while executing the test collectCoverage: true,　　然后我们可以再次执行测试命令并用浏览器打开_/coverage/lcov-report/index.html_查看测试用例覆盖率报告。修改测试用例使覆盖率达到100%　　__tests__/dessertFactory.test.jsconst dessertFactoty = require("../src/dessertFactoty"); describe("test dessertFactoty feature", () => { test("produce all dessert", () => { const dessertType = ['Red bean burning', 'Tiramisu']; expect(dessertFactoty.produce(dessertType[0]).enjoy()).toBe("Enjoy the Red bean burning"); expect(dessertFactoty.produce(dessertType[1]).enjoy()).toBe("Enjoy the Tiramisu"); expect(() => { dessertFactoty.produce('Luckin Coffee') }).toThrow("please choose a dessert type"); } }　　再测试并查看覆盖率报告：　　这里 Functions列 为什么不是100%，大家可以点击 dessertFactory.js 根据详细说明分析推测。3.Jest怎么和Typescript完美结合（填坑实录）　　搜索引擎上现有的 Jest + Typescript 的样例比较少，并且存在了一定的问题没有解决，这一部分我已经填平了坑，可以作为配置参考。增加依赖npm i ts-jest @types/jest typescript @types/node --save-dev　　其中 ts-jest 为 Jest + Typescript 环境下进行测试提供了类型检查支持和预处理。ts初始化　　在根目录下创建配置文件tsconfig.json：{ "compilerOptions": { "target": "es5", "module": "commonjs", "lib": [ "es2015" ], "strict": true, "declaration": true, "outDir": "build", "sourceMap": true }, "include": [ "src/**/*" ], "exclude": [ "node_modules", "__test__/**/*" ] }修改jest.config.js配置　　添加如下配置项：// An array of file extensions your modules use moduleFileExtensions: [ "js", "json", "jsx", "ts", "tsx", "node" ], // A preset that is used as a base for Jest's configuration preset: "ts-jest",修改功能代码　　src/dessert.js => src/dessert.tsexport default class dessert { name: string; constructor(name: string) { this.name = name; } enjoy() { return "Enjoy the " + this.name; } }　　src/dessertFactory.js => src/dessertFactory.tsimport dessert from "./dessert"; export default class dessertFactory { static produce(type: string) { switch (type) { case 'Red bean burning': return new dessert('Red bean burning'); // 红豆烧 case 'Tiramisu': return new dessert('Tiramisu'); // 提拉米苏 default: throw new Error("please choose a dessert type"); } } }修改测试用例　　__tests__/dessert.js => __tests__/dessert.tsimport dessert from "../src/dessert"; describe("test dessert feature", () => { test("enjoy the cake", () => { const cake = new dessert('cake'); expect(cake.enjoy()).toBe("Enjoy the cake"); } }　　__tests__/dessertFactory.js => __tests__/dessertFactory.tsimport dessertFactoty from "../src/dessertFactoty"; describe("test dessertFactoty feature", () => { test("produce all dessert", () => { const dessertType = ['Red bean burning', 'Tiramisu']; expect(dessertFactoty.produce(dessertType[0]).enjoy()).toBe("Enjoy the Red bean burning"); expect(dessertFactoty.produce(dessertType[1]).enjoy()).toBe("Enjoy the Tiramisu"); expect(() => { dessertFactoty.produce('Luckin Coffee') }).toThrow("please choose a dessert type"); } }　　如同代码重构后我们通过测试用例可以快速检查是否改动出现差错一样，我们这次变更可以执行 Jest 测试命令，检查是否对功能无影响。4.Jest最锋利的功能 Mock Functions　　关于 Jest 测试框架中的Mock功能，我们主要关注两点：mock function: 对函数进行mock.mock return value: 对返回值进行mock.　　从以上两点可以衍生出 Jest 对于代码单元测试中两项常用的锋利功能：对功能中业务逻辑简化后的重新实现，方便有指向性的进行测试（比如忽略实际场景中的跨服务调用功能等，仅需将原有功能中对应的调用逻辑改为定义的测试数据即可）。对功能返回值的直接模拟。　　为甜点增加了评论功能：export default class dessert { name: string; static comment: string[] = []; constructor(name: string) { this.name = name; } enjoy() { return "Enjoy the " + this.name; } static comments(message: string) { dessert.comment.push(message); } }　　专门建立一个互动区进行甜点的讨论。创建src/dessertCommentModule.ts:import dessert from "./dessert"; module dessertCommentModule { export function comments(message: string) { dessert.comments(message); return dessert.comment; } }export default dessertCommentModule;　　下面开始test dessert feature with mock~这一部分均已通过测试，建议深入研读代码，感受 Jest mock 每一处的奥妙。如果下面各处期望的结果都如你所料，那么你就是图雀社区最靓的仔：import dessert from "../src/dessert"; import dessertCommentModule from "../src/dessertCommentModule"; jest.mock("../src/dessertCommentModule"); describe("test dessert feature", () => { test("enjoy the cake", () => { const cake = new dessert('cake'); expect(cake.enjoy()).toBe("Enjoy the cake"); } } describe("test dessert feature with mock", () => { test("enjoy the cake with mock function", () => { const dessertFactoryMock = jest.fn(name => new dessert(name)); const cake = dessertFactoryMock('cake'); expect(cake.enjoy()).toBe("Enjoy the cake"); expect(dessertFactoryMock.mock.results[0].value.enjoy()).toBe("Enjoy the cake"); console.log(dessertFactoryMock.mock); } test("enjoy the cake with mock return value", () => { const dessertFactoryMock = jest.fn(name => new dessert(name)); const cake = new dessert('cake'); dessertFactoryMock.mockReturnValue(cake); const tiramisu = dessertFactoryMock('tiramisu'); expect(tiramisu.enjoy()).toBe("Enjoy the cake"); expect(tiramisu).toEqual(cake); expect(dessertFactoryMock.mock.results[0].value).toEqual(cake); } test("comment the dessert with mock module", () => { const mockedDessert = dessertCommentModule as jest.Mocked<typeof dessertCommentModule>; mockedDessert.comments.mockReturnValue(['not bad']); expect(mockedDessert.comments("cake is so good")).toEqual(['not bad']); expect(dessert.comment).toEqual([]); } test("comment the dessert with mock implementations", () => { const mockedDessert = dessertCommentModule as jest.Mocked<typeof dessertCommentModule>; mockedDessert.comments.mockImplementation((message: string) => { dessert.comments(message); return ['not bad']; } expect(mockedDessert.comments("cake is so good")).toEqual(['not bad']); expect(dessert.comment).toEqual(['cake is so good']); } } mock function注意：我们可以更改test为test.only仅对test.only的测试用例执行测试，降低测试时间并关注特定测试点。test.only("enjoy the cake with mock function", () => { ...　　这里我们通过 jest.fn 进行 了 mock function 功能的展示，通过执行 npm test 看到 .mock 的结构信息：.mock的中将会记录mock function调用后的相关信息。mock return value test("enjoy the cake with mock return value", () => { ....这里我们通过 .mockReturnValu 可以将 function mock 的操作略过，直接会返回 .mockReturnValue 中填充的返回值。通过执行 npm test 验证。mock module import dessertCommentModule from "../src/dessertCommentModule"; jest.mock("../src/dessertCommentModule"); test.only("comment the dessert with mock module", () => { ...通过 jest.mock ，我们 mock 了甜点评论区，这项操作可以使我们对dessertCommentModule中的所有功能进行我们的测试定制。这里我们通过对评论功能进行 mock return value ，通过执行 npm test 看到：并没有进入dessertCommentModule中的comments方法，直接返回了我们预置的返回值。mock implementations test.only("comment the dessert with mock implementations", () => { ...我们通过对评论功能进行 mock implementations ，通过执行 npm test 看到：　　进入了 mockImplementation 中的测试定制功能，并且调用了dessert中的comments方法。　　　　　　以上。————————————————

初学算子开发，用MindStudio2的生成框架学着改写了一个算子的测试用例，就几行代码，总是跑不通，提示“RuntimeError: Expect out tensor is None.算子执行代码文件、单元测试用例文件请见附件。请各位学长帮着诊断、指导一下，先谢谢啦【单元测试用例代码】# # -*- coding:utf-8 -*-import sysfrom op_test_frame.ut import OpUTfrom impl.h_swish import h_swishut_case = OpUT("h_swish")# [TODO] coding expect function heredef calc_expect_func(input_x, output_y):    res = h_swish(input_x, output_y)    return [res, ]# [TODO] coding cases hereut_case.add_precision_case(case={    "params": [        {            "shape": (32, 64),            "ori_shape": (32, 64),            "format": "ND",            "ori_format": "ND",            "dtype": "float16",            "param_type": "input",            "value_range": [2.0, 3.0]        },        {            "shape": (32, 64),            "ori_shape": (32, 64),            "format": "ND",            "ori_format": "ND",            "dtype": "float16",            "param_type": "output"        }    ],    "calc_expect_func": calc_expect_func})if __name__ == '__main__':    ut_case.run("Ascend910", None, "ca", None)【截图信息】【日志信息】（可选，上传日志内容或者附件）

开发spring boot 程序过程，如果要针对某个方法做单元测试。一般使用开发工具新建项目都会自动生成单元测试单元。但是默认情况下的配置在测试中会启动程序，如果不想要启动可以修改如下代码@RunWith(SpringRunner.class) @SpringBootTest public class ests {}上面代码意思是针对所有class进行扫描，添加(classes=Tests.class)属性可以针对某些类做单元测试。

                egg-project├── .autod.conf.js【eggjs调用的配置文件】├── .travis.yml 【travis配置文件】├── appveyor.yml【appveyor配置文件】├── .eslintignore 【忽略代码格式化配置文件】├── .eslintrc 【代码格式化配置文件】├── package.json【相关依赖模板、版本信息、启动命令配置文件】├── package_lock.json【node_modules目录下所有模块的具体来源和版本号以及其他的信息】├── jsconfig.json【VSCODE指定根文件和JavaScript语言服务提供的功能选项】├── app.js (可选) 【自定义启动时的初始化工作】├── agent.js (可选) 【自定义agent启动时的初始化工作】├── logs 【日志目录】├── node_modules【node模块目录】├── run【运行时生成的配置文件目录】├── typings 【智能提示控件】├── app 【应用层目录】|   ├── router.js 【配置 URL 路由规则文件】│   ├── controller 【控制器目录】│   |   └── home.js 【用于解析用户的输入，处理后返回相应的结果的文件】│   ├── service (可选)【服务层目录】│   |   └── user.js 【编写业务逻辑层文件】│   ├── middleware (可选) 【中间件目录】│   |   └── response_time.js 【中间件文件】│   ├── schedule (可选)【定时任务目录】│   |   └── my_task.js 【定时任务文件】│   ├── public (可选) 【静态资源文件】│   |   └── reset.css 【一个css文件】│   ├── view (可选) 【模板文件目录】│   |   └── home.tpl 【模板文件】│   └── extend (可选) 【框架的扩展目录】│       ├── helper.js (可选)【扩展helper对象文件】│       ├── request.js (可选)【扩展request对象文件】│       ├── response.js (可选)【扩展response对象文件】│       ├── context.js (可选) 【扩展ctx对象文件】│       ├── application.js (可选) 【扩展app对象文件】│       └── agent.js (可选)【扩展agent对象文件】├── config 【配置文件目录】|   ├── plugin.js 【插件的配置文件】|   ├── config.default.js 【默认的配置文件】│   ├── config.prod.js 【prod环境加载的配置文件】|   ├── config.test.js (可选)【test环境加载的配置文件】|   ├── config.local.js (可选)【local环境加载的配置文件】|   └── config.unittest.js (可选)【unittest环境加载的配置文件】└── test 【单元测试目录】    ├── middleware 【中间件单元测试目录】    |   └── response_time.test.js 【单元测试文件】    └── controller 【控制器单元测试目录】        └── home.test.js  【单元测试文件】      

1.jtest java语言的单元测试框架2.JUnit 验证java的工具3.cppunit 跨平台的c++单元测试框架4.gtest 跨平台的c++单元测试框架5.BoundsChecker C++,Delphi API和OLE错误检查、指针和泄露错误检查、内存错误检查6.TrueTime C++,Java,Visual Basic 代码运行效率检查、组件性能的分析

1，jtest java语言的单元测试框架2，JUnit 验证java的工具3，cppunit 跨平台的c++单元测试框架4，gtest 跨平台的c++单元测试框架5，PhpUnit Php6，BoundsChecker C++,Delphi API和OLE错误检查、指针和泄露错误检查、内存错误检查7，TrueTime C++,Java,Visual Basic 代码运行效率检查、组件性能的分析

一、工具介绍一键式信息收集工具用于快速收集MindX SDK问题，定位所依赖的相关信息。主要包括芯片信息（版本和日志）、操作系统版本信息、环境变量、网络信息以及MindXSDK信息（版本、配置文件、日志、第三方库版本）等。 避免让客户反复收集日志，反复确认信息。该工具由sdk_info_collector.sh和sdk_info_collector.py两个文件组成，其中在sdk_info_collector.sh文件中调用了sdk_info_collector.py文件。此外，用户可以根据自己的需求在已有的信息收集工具上扩展新功能。一键式信息收集工具为芯片日志和MindX SDK日志的信息收集提供了可配置的参数，请参见下表，其他的信息都默认收集。二、工具使用步骤1 跳转到信息收集工具所在的目录。cd ${MX_SDK_HOME}/bin注意：请确保MX_SDK_HOME为有效的环境变量。步骤2 执行sdk_info_collector.sh。以下为三种一键式信息采集的方式，用户可以根据自己的实际情况来使用。采用默认参数。bash sdk_info_collector.sh -p logs_path采用默认参数收集信息，默认收集MindX SDK所有日志信息，不收集芯片日志。指定参数收集。命令示例：bash sdk_info_collector.sh -p logs_path -r 3d -t w -x 6命令解释如下表所示。命令示例：bash sdk_info_collector.sh -p logs_path -r 3d -t w -x 0,2,5全量收集。bash sdk_info_collector.sh -p logs_path -r full -t full -x -1步骤3 获取结果。运行一键式信息收集工具的结果存放在“MX_SDK_HOME/bin”目录下的mindx_sdk_info_年月日_时分秒.tar.gz文件。

CoverageMaster winAMS : 适用于嵌入式目标机代码的单元测试/集成测试工具全面支持嵌入式微机！验证嵌入式C/C++软件 实施以模块为单位的自动化单元测试工具不需要HookCode 直接使用目标机代码进行单元测试联合静态解析工具[CasePlayer2]，提供C0（语句）,C1（判定）,MC/DC覆盖率报告，优化测试用例制作已取得第三方认证机构TUVSUD对适用于汽车机能安全ISO26262软件工具的认证产品概要[Coverage master winAMS]是以嵌入式软件的函数为单位，实施模块单元测试以及C0/C1/MCDC覆盖率测试（coverage test）的嵌入式软件自动化单元测试工具。目标机源代码通过交叉编译器生成目标机执行代码，通过跟实际处理器同样的模拟处理器环境进行单元测试，不需要对执行代码做任何变动，使高信赖性的模块测试成为可能。在汽车控制软件这样的对安全性要求极高的领域，单元测试已经成为不可缺少的一部分。使用目标机代码进行单元测试也是为了符合汽车行业中ISO26262功能安全认证标准。产品特长全面支持嵌入式微机！验证嵌入式C/C++软件 实施以模块为单位的自动化单元测试工具作为能够检验出仅凭系统测试以及整体测试无法发现的[潜在错误]的检测方法，[单元测试]在嵌入式开发领域受到广泛重视。同时，单元测试也是汽车用软件功能安全（ISO26262）领域中要求实施的认证项目之一。[Coverage master winAMS]直接使用通过交叉编译生成的目标机代码，在模拟处理器环境下进行单元测试。既能实现C语言程序的逻辑上的单元验证，又能够对嵌入式微机组装为产品后可能发生的问题等进行具有高信赖度的白盒（white box）测试。不需要HookCode 使直接使用目标机代码进行单元测试成为可能的业界唯一的工具有些公司的单元测试工具往往采用在被测试对象的源代码中追加测试用代码或者测试用驱动器的方法，导致测试时所用的代码与组装为产品后的目标机用代码不同。虽然[理论上运行功能应该是相同的]，但是从嵌入式开发的角度考虑，这样就如同对交叉编译所生成的经过优化处理的代码进行了加工，无法确保最终产品的质量。Coverage master winAMS是业界唯一的，具有[不需要对被测试对象做任何加工]实施单元测试功能的工具，特别是在安全性要求高的领域中得到很高的评价。不需建立单元测试专用的环境，可以在开发用交叉编译环境进行单元测试Coverage master winAMS不需要追加任何测试用驱动器或测试用代码，可以直接使用将组装成产品的目标代码进行单元测试。单元测试能够与软件开发使用共同的交叉编译环境，不再需要对测试资源进行专门管理，也不再需要建立其他专用环境。因此，既方便程序资源管理，又能够缩短准备测试环境所需的时间。符合汽车功能安全标准（ISO26262）[不做加工直接使用目标机代码实施单元测试]这一要求的最佳工具ISO26262是从IEC61508衍生出来的适用于汽车制造领域的功能安全标准。其中的Part.6-9[软件程序单元测试]包括了关于软件程序的构造覆盖率测试以及有关的规定项目。根据汽车安全标准（ASIL），提出了测试语句覆盖率（statement coverage），分支覆盖率（branch coverage），MC/DC覆盖率的推荐性事项。其中的另一个推荐性事项是[尽可能使单元测试的环境与目标环境相同]的规定。如果在与目标环境不同的环境下进行单元测试，必须表明源代码与目标代码的差别，以及目标环境和测试环境的差别。因此，对于那些使用与目标微机不同的电脑进行编译和单元测试的其他公司的工具而言，这个要求很难满足。 还有些公司的单元测试工具虽然包括交叉编译环境及编译功能，而且也能够在与目标环境相同的环境下进行测试，但是所有的测试都需要插入测试用代码，进行再次编译，因此测试也只能在与目标环境不同的环境下实施。GAIO提供的单元测试工具Coverage master winAMS具有●采用全面支持嵌入式微机的微机化功能测试平台环境●不需要插入测试用代码直接使用目标机代码进行测试的特征，提供符合ISO26262标准要求的必须功能。GAIO提供的Coverage master winAMS是符合ISO26262标准[直接使用整装用代码实施单元测试]这一要求的业界唯一的工具。关于汽车机能安全ISO26262的对应以及认证的获得已取得第三方认证机构TUVSUD对适用于汽车机能安全ISO26262软件工具的认证2012年6月28日，「Coverage master winAMS / General」测试工具获得由德国TUVSUD第三方认证机构，在汽车机能安全规格的ISO26262软件工具方面的认证，包括日本在内亚洲地区首次获得该项认证。通过此项认证，说明本公司的单元测试工具「Coverage master winAMS / General」，以及程序分析工具「CasePlayer2」，在静态分析和单元测试领域，是符合所有安全度水准的工具，并由TUVSUD认证机构得到了保障。ISO 26262对于不同的开发用软件工具在工具置信水平（TCL），都需要开发者提供开发软件工具的认证书。此项认证适用于在工具认证当中，最为复杂的TCL3工具认证标准。因此，导入本公司的单元测试工具之后，不需要对TCL的部分进行认证，进而可以缩减手续跟时间。主要的单元测试功能采用SSTManager管理单元测试projectSSTManager是Coverage master winAMS的应用功能，用于管理单元测试project，制作测试数据（test data）。从设定测试环境开始，到报告测试结果为止，均由微机化功能测试平台（ISS）实施综合管理。采用通用便利的CSV文件管理测试数据的输入输出Coverage master winAMS不需要插入测试用代码，直接使用目标机代码进行单元测试。采用通用便利的CSV文件管理函数测试时使用的输入输出数据。测试结束后，输出的测试结果和输出的期待值也将以相同的格式显示在CSV文件之中。C0/C1覆盖率报告的自动化制作功能（标准功能）根据测试的输入输出数据自动报告相应源代码的C0/C1测试覆盖率结果。包括通过图形（viewer）显示测试数据，以及与其相应的被测试的源代码路径的功能，用于分析测试结果。作为选项功能也包括MC/DC覆盖率测试功能。MC/DC覆盖率的自动化测试功能（选项功能）作为选项功能提供MC/DC覆盖率测试功能。C0/C1覆盖率测试不需要加工即可直接使用目标机代码。然而，MC/DC覆盖率测试对于复合式的条件式，需要自动插入HookCode将复合式的条件式分解，才能对各条件式进行测试。这样就有可能导致测试用代码与目标机用代码的不同。为了验证HookCode的妥当性，在MC/DC覆盖率测试的同时，运行目标机代码，确认运行结果与期待值的一致性。注:右图举例显示，第2个if句的复合条件式中，[gbc>30]为false时的分支没有被测试到。以C1覆盖率测试来说，它的测试结果是OK；而对于MC/DC覆盖率测试来说，它的结果是NG。注: MC/DC覆盖率测试功能不支持C++程序。单元测试的效率化功能联合程序解析工具CasePlayer2，实现代码参照解析作业的效率化利用CasePlayer2生成的流程图表以及模块构造图（调用函数的构造图）与源代码的连接（link）功能，使单元测试用源代码的解析工作效率化。能够自动检索被测试函数的外部变量，使测试条件设定效率化联合程序解析工具CasePlayer2，自动检索被测试函数所使用的外部变量。缩短了以往必须对源代码进行搜索找出输入条件的变量所需的工作。而且，能够防止人工操作导致的类似变量指定遗漏的的错误。 根据代码解析自动化制作C0，C1，MC/DC 覆盖率测试计划联合程序解析工具CasePlayer2，自动化制作符合覆盖率测试要求的条件分支if,switch,for,while等的测试数据。可以将被测试函数中含有的条件式（if以及switch等）在数据制成图形(Viewer)上列表显示。点击其中的条件，工具将自动开始检索与之相关的变量，进而从所设置的条件的境界值中自动生成覆盖率测试所需要的数据。为了达到C1/MCDC覆盖率，测试时需要对各函数的数据进行组合。利用CasePlayer2提供的解析结果，分析条件式的net构造，在重复性限制在最小限度下生成C1/MCDC覆盖率测试用数据。支持MPU　CoverageMaster winAMS Supported Processor List(English)动作环境・操作PC/OS・IBM PC/AT 兼容机・Pentium(相当) 2GHz 以上的CPU・存储器 512MB 以上（推荐值）・显示器分辨率 XGA(1024*768)以上（推荐值）・Windows XP, Windows Vista, Windows 7（32bit/64bit）（※Windows 95/98/Me/NT/2000 未支持） 

一、测试常用规则一个测试单元必须关注一个很小的功能函数，证明它是正确的；每个测试单元必须是完全独立的，必须能单独运行。这样意味着每一个测试方法必须重新加载数据，执行完毕后做一些清理工作。通常通过setUp()和setDown()方法处理；编写执行快速的测试代码。在某些情况下，测试需要加载复杂的数据结构，而且每次执行的时候都要重新加载，这个时候测试执行会很慢。因此，在这种情况下，可以将这种测试放置一个后台的任务中。在编写代码前执行完整的测试，而且在编写代码后再重新执行一次。这样能保证你后来编写的代码不会破坏任何事情；在提交代码前执行完整的测试；如果在开发期间被打断了工作，写一个打断的单元测试，关于你下一步将要开发的。当你回来工作时，你能知道上一步开发到的指针；单元测试函数使用长的而且具有描述性的名字。在正式执行代码中，可能使用square()或sqr()取名，但是在测试函数中，你必须取像test_square_of_number_2()、test_square_negativer_number()这些名字，这些名字描述更加清楚；测试代码必须具有可读性；单元测试对新进的开发人员来说是工作指南。二、python常用的测试框架1. unittestunittest是Python内置的标准类库unittest 和 JUnit类似，可以说是python的标准单元测试框架，所以有时也被人称为 PyUnit。它使用起来和xUnit 家族其他成员类似。 用的人也比较多。兼容 python2 以及python3 。2、unittest2unittest2 可以说是一个针对 unittest测试框架新特性的补丁。它很大程度上和unittest都类似。然后还添加了一些unittest没有的方法。3、pytestpy.test是unittest的替代工具。尽管它是一个功能丰富、灵活的测试框架，但是它的语法很简单。创建一个单元测试就像编写一个模块一样。相比unittest，实现相同的测试功能，py.test做的事情更少。pytest 直接可以通过 @pytest.mark.parametrize 进行参数化，而unittest 则需要借助DDT。4、noseNose是对unittest的扩展，使得python的测试更加简单。nose自动发现测试代码并执行，nose提供了大量的插件，比如测试输出的xUnitcompatible，覆盖报表等等。基于Python的测试驱动开发实战 也有nose的用法： http://python.jobbole.com/81305/还有一个特定就是，nose可以采用 @with_setup() 来定义方法的setup和teardown。5、doctestdoctest模块会搜索那些看起来像交互式会话的 Python 代码片段，然后尝试执行并验证结果。6、tox最大的特色，是自动最测试环境的管理以及使用多个解析器配置进行测试。tox的详细文档： http://testrun.org/tox/latest/7、mockunittest.mock是用来测试python的库。在python3.3版本以后，这个是一个标准库。 对老版本来说，使用pip install mock 进行安装。mock的精髓在于，你可以使用模拟的对象来替代你的系统的一部分，然后验证后续的执行是否正确。mock的详细文档：http://www.voidspace.org.uk/python/mock/

深度学习代码如何进行单元测试