• [技术交流] 单元测试
     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软件工具的认证测试工程管理
  • [数据库] MySQL-单元测试介绍
    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 D系列产品】【分类网络功能】单元测试 和 集成运行时输出结果不一致
    在SDC D2150上训练好的分类网络:单元测试结果  和 集成测试结果不一致集成测试: 通过灌流 通过“分类网络”(使用nnie)计算后,得到每一个图片和分类得到的分数。单元测试:将集成测试得到的所有图片,每次一张图片的进行“分类网络”计算后,得到分类的分数。【测试结果】1. 集成测试 和 单元测试 结果不一致,差异很大;2. 单元测试结果(计算得到的分数)是正确的(或正常的);3. 集成测试结果中,有部分结果异常(应该低分的得到高分,应该高分的得到低分);【请问】1. 可能什么原因导致以上的结果?2. 在 图片数据 传给sdc  nnie时,如何确定nnie接收到的数据是传入进去的?如何确保nnie完整的接收输入数据?2. 如何将传入sdc nnie的图片数据,从sdc  nnie读取出来并保存?【追加问题 20210918】1、使用nnie是否有调用频率的限制?(比如不能调用太频繁太快了,不然会导致结果异常)     在使用过程中,发现调用频率太高,会出现输入数据是对的,但调用nnie结束后,输入数据被篡改了(这里没有写错,是输入数据被篡改,不是输出数据)
  • [执行问题] 【AKG】910平台AKG单元测试出现undefined symbol的错误
    【功能模块】910平台AKG单元测试【操作步骤&问题现象】1、910平台AKG在单元测试时出现OSError: libakg.so:  undefined symbol:_ZN6Msprof6Engine21MsprofCallbackHandler10reporters_E2、这个函数应该来源于名为libmsprofiler_fwkacl.a的静态库, 使用nm命令可以在libakg.so中找到这个函数, 但是运行时却会报错, 原因在哪?【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [技术干货] 上手 Jest 测试框架
      当我第一次听说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方法。      以上。————————————————
  • [问题求助] 初学算子,执行文件代码单元测试用例跑不通,提示“RuntimeError: Expect out tensor is None.
    初学算子开发,用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)【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [技术干货] SpringBootTest测试时不启动程序
    开发spring boot 程序过程,如果要针对某个方法做单元测试。一般使用开发工具新建项目都会自动生成单元测试单元。但是默认情况下的配置在测试中会启动程序,如果不想要启动可以修改如下代码@RunWith(SpringRunner.class) @SpringBootTest public class ests {}上面代码意思是针对所有class进行扫描,添加(classes=Tests.class)属性可以针对某些类做单元测试。
  • [技术干货] eggjs框架学习心得
                    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] 一键式运维数据收集工具
    一、工具介绍一键式信息收集工具用于快速收集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文件。
  • [技术干货] 单元测试/集成测试自动化工具--WinAMS
    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 未支持) 
  • [技术干货] python中的测试框架
    一、测试常用规则一个测试单元必须关注一个很小的功能函数,证明它是正确的;每个测试单元必须是完全独立的,必须能单独运行。这样意味着每一个测试方法必须重新加载数据,执行完毕后做一些清理工作。通常通过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/
  • [AI人工智能全栈成长...] 【问答官】深度学习代码如何进行单元测试
    深度学习代码如何进行单元测试
  • [分享交流] Wings企业级单元测试自动编码引擎白皮书
    第一章Wings企业级单元测试自动编码引擎诞生的背景 (附Wings讲解视频和白皮书pdf下载)随着科技的飞速发展,软件系统越来越复杂,在系统测试阶段不断遇到的瓶颈,迫使行业逐步追根溯源到了单元测试阶段。软件缺陷发现得越晚,其处理费用就越呈几何激增,因此测试左移概念已经成为趋势。单元测试面临的最大问题是单元测试用例编写工作量巨大,极端情况下与开发工作量比达到1:1,甚至更高,这使大部分开发团队要么主动忽视单元测试,要么象征性的走个流程。如果可以让计算机先对被测试程序进行全局分析和深度理解,再由计算机进行全自动的完成单元测试编码,同时还能确保自动编写的代码无语法、语义错误的直接运行起来,这种用计算机智能算法全自动产生的测试编码去验证开发人员编写的源代码逻辑输入输出对错的高端测试模式,无疑是未来软件测试领域最为璀璨的“明珠”技术。国外软件诸如c++ test完成了这个领域的初步技术探索,星云测试研发的Wings(目前商用产品支持c/c++程序)产品,则大踏步完成了整体技术跨越和多方商用落地验证。Wings可以对程序参数进行深度解析,比如c++类、模板类、数组、结构体、指针、链表以及任意复杂结构的层级嵌套,同时对于面向对象的程序特性以及常用的容器库,能够完美识别和支持。对于一些void*、函数指针、模板类等无法直接静态分析进行类型确定的特殊情况,均有基于人工智能的程序分析辅助进行类型确定。Wings在基于深度参数解析的基础上,对于全局范围的程序进行理解分析后,第一步 按照内置规则,自动化构建被测程序的输入用例代码;第二步 构建测试代码用于调用被测程序的源代码;第三步 构建被测程序输出断言,完成调用被测试程序单元的全部环境准备。这个构建速度非常快,可以达到每分钟100万行左右的生成速度,编写的代码比程序开发人员手工编写的规范度高出一截,并确保100% 的语法语义正确,免去大量的调试时间。在驱动数据上,Wings实现了驱动代码和数据的分离。Wings基于深度参数解析基础上,可以根据参数的结构自动生成层级嵌套的测试数据结构,用图形界面可视化的展示给用户。用户只需要根据Wings提供的界面向导对测试数据进行填充即可,驱动程序会自动识别并读取这些数据,完成对被测试程序的调用。Wings还可以全自动生成参数捕获程序,并自动插装在被测试程序中。当被测试程序运行后,可以通过专用软件捕获程序中每个函数模块运行的具体参数值。Wings的测试代码驱动自动生成和参数捕获,相当于完成了一种全智能的闭环测试验证体系。Wings使测试数据不需要人工准备,只需要在前序轮次中通过参数捕获自动存储。若前序测试用例运行正常,那么这些数据都可以作为后续测试输入和进行校验的基础数据。第二章 单元测试自动生成技术2.1 测试左移后单元测试面临的问题测试左移后,传统的单元测试一般面临很多问题,主要如下:(1) 传统程序级测试用例的编写会耗费开发人员大量的工时,比如TDD测试驱动开发里面的单元测试无法有效实施,导致所有测试几乎全部依赖于系统级黑盒测试。程序级测试用例的开发成本是功能实现代码本身时间至少为1:1,绝大部分企业选择放弃开发程序级测试,而采用系统级测试方法。(2)     需求发生变化导致程序实现发生变化后,程序集用例也需要发生变化,和自动化面临的问题一样,单元测试本身的可维护性问题导致投入是持续的而不是一次性的,会打消其企业应用的热情。(3)     很多单元在未组装成系统的时候切入,如果需要进行测试需要进行大量的mock操作或者桩模拟,这个过程会造成单元测试的不精确性。(4)     程序集测试数据量很大,全部需要用户来进行准备无法全自动从前序系统测试过程中获取。      针对以上问题,很多业内人士提出了很多办法,例如自动生成测试用例、自动构建测试驱动、模糊测试方法等诸多方式,但是实际开发中程序输入参数十分复杂,简单的输入已经不能满足,如何能够构建复杂的参数输入,是要解决的重要问题。因此,星云测试研发了Wings产品--单元级的自动编码引擎,它不仅能够自动构建测试驱动,还能处理十分复杂的大型程序参数,帮助企业能够更好的进行单元测试。2.2 完成单元测试要素构成单元测试的要素如下:a.        测试数据b.        测试驱动代码例如针对以下程序,需要准备的测试输入以及测试代码① 全局变量:c② 参数:a、b③ 预期输出:320 30 int c = 100; int sum(int a, int b) {      return a + b + c; } int driver_sum() {      int a = 100, b = 20;      c = 200;      return sum(a, b); }                                                                                TEST(test, driver_sum) {      EXPECT_EQ(320, driver_sum);      EXPECT_EQ(30, driver_sum); }2.3构建测试数据和测试代码遇到的技术瓶颈编写测试代码比较繁琐开发编写驱动不难,但是浪费大量的时间,并且没有创造性。编写代码是否有良好的代码规范单元测试也需要一些规范支持,例如代码规范,注释规范等,有了这些规范能够为测试人员提供很好的功能测试用例设计的逻辑思考,也为其他开发熟悉代码提供极大的便利。数据类型比较复杂通常情况下,输入参数比较复杂,嵌套层析结构比较深入,例如类包含其他类等。能否支持多组测试数据一般代码中每个循环、分支判断以及输入输出都有可能产生缺陷。因此单元测试需要很多用例,满足不同的条件分支,达到满足覆盖率。第三章 Wings的基本架构介绍3.1 Wings测试用例驱动自动生成技术的特性l  Wings是智能的全自动测试用例驱动构建系统,能够在很短时间内完成对大型复杂程序的自动解析、构建。每分钟达到100万行代码的生成速率。l  可以将任意复杂类型逐步分解为基本数据类型,例如结构体嵌套,复杂类对象,c++标准容器,自定义模板类等。l  支持多层次的可视化的数据表格来对变量类型进行赋值,无需关注驱动程序本身。数据表格可以表达任意深度和多层次的数据关系,用户只需要关注表格数据,完成对输入数据的校对。l  能够区分系统数据类型和用户自定义类型,对于复杂的约定俗成系统类型可由用户自定义扁平式赋值模板,例如std::vector类型等,内部集成常用系统类型的模板。3.2 Wings的技术架构介绍Wings的技术架构:首先Wings利用代码静态分析技术,提取被测程序的主干信息并保存到Program Structure Description(PSD)结构中,PSD结构中主要存储函数的参数、全局变量以及返回值的信息,类的成员变量,成员函数,以及访问权限等信息。利用存储的信息,依据一定的编写规则,自动构建测试驱动、googletest 期望断言、测试输入、参数捕获等代码和值。                                             图 3.2 Wings总体架构图上述Wings的总体架构图,说明了Wings构建代码与测试输入的具体过程,整个核心技术是通过编译底层技术获取程序的信息,然后按照一定的规则构建需要的数据。第四章 程序结构信息描述程序结构信息(Program Structure Description)是指对源程序进行提取后的描述信息,主要包括类名、命名空间、类的成员变量信息、类的函数信息,以及各种类型信息等(程序结构信息,下文简称“PSD”)。描述信息的保存C语言是以一个文件为单元存储,C++提取所有的类信息存储在一个文件中。Wings的主要特性是能够对复杂的类型(结构体、类、模板类等)进行逐层展开分解到最基本数据类型(char、int、string等)。PSD结构存储在XML文件中,不同的XML文件存储不同的描述信息。Wings提取的程序结果都存储在Wingsprojects文件下的funxml与globalxml文件夹中,其中funxml文件中主要存储的文件以及作用如下:RecordDecl.xml: 结构体,联合体与类描述信息。ClassTemplateDecl.xml:模板类描述信息EnumDecl.xml:枚举描述信息funcPoint.txt: 存储函数参数为函数指针的分析结果。funcCount.txt: 存储分析到的全部函数,参数个数,参数类型信息。void.txt: 存储函数参数为void*的分析结果。filename.xml:存储c语言文件的信息。注:具体文件的描述信息,参看附录A。针对复杂类型,例如结构体类型location_s,成员变量中除了基本数据类型之外,还存在包含结构体类型的情况,如下所示的代码中,location_s中包含coordinate_s结构体,以及FILE等类型的信息,针对不同的类型进行标记区分。 源代码如下:typedef struct coordinate_s{     void(*setx)(double, int);     int mInt;     char *mPoi;     int mArr[2][3];     void *vo; } coordinate;   typedef struct location_s {     int **mPoi;     coordinate *coor;     FILE *pf;     struct location_s *next; }location;   coordinate *coordinate_create(void); int coordinate_destroy(location *loc,size_t length,char *ch); void func_point(double param1, int param2); 生成对应的PSD结构信息如下图4:图4:PSD描述信息C++的主要表示类型是类,因此测试是C++以一个类为单元做测试,类主要包括类的成员变量名以及类型信息,成员变量的访问权限信息。类的成员函数分为构造函数、内联函数、虚函数等,成员函数的参数信息以及类型信息等。具体描述信息可以登陆www.codeWings.net下载Wings试用版本进行学习。第五章 Wings构建程序描述Wings通过获取到的存储信息,依据一定的编码规则,构建不同的代码程序,如驱动程序、期望断言程序、参数捕获程序等。5.1 驱动程序构建驱动程序指单元测试代码,Wings针对函数参数的类型,自动完成单元测试代码的编写。为了更详细的说明驱动程序,以一个C++类作为具体的例子说明。 类的声明如下:class BlockBuilder { public:     explicit BlockBuilder(const Options* options);     BlockBuilder(const BlockBuilder&) = delete;     BlockBuilder& operator=(const BlockBuilder&) = delete;     void Reset();     void Add(const Slice& key, std::string & value);     Slice Finish();     size_t CurrentSizeEstimate() const; private:     const Options* options_;     std::string buffer_;     int counter_;     bool finished_; };针对如上BlockBuilder 类,构建一个对应的驱动类DriverBlockBuilder,驱动类中主要包含构造函数、析构函数、每个成员函数的驱动函数以及返回值函数。为了避免类中重名函数,对写入PSD需要对应生成驱动的函数进行顺序编号。驱动类声明:class DriverBlockBuilder { public:     DriverBlockBuilder(Json::Value Root, int times);     ~DriverBlockBuilder();     int DriverBlockBuilderReset1(int times);     int Reset1Times;     int DriverBlockBuilderAdd2(int times);     int Add2Times;     int DriverBlockBuilderFinish3(int times);     void ReturnDriver_Finish3(class Wings::Slice returnType);     int Finish3Times;     int DriverBlockBuilderCurrentSizeEstimate4(int times);     void ReturnDriver_CurrentSizeEstimate4(size_t returnType);     int CurrentSizeEstimate4Times; private:     Wings::BlockBuilder* _BlockBuilder; };在上述驱动类中,构造函数的作用是构造BlockBuilder的对象,用构造的对象,调用测试BlockBuilder中的成员函数。析构函数的作用是释放构建的对象。 构造函数与析构函数:DriverBlockBuilder::DriverBlockBuilder(Json::Value Root, int times){   Json::Value _BlockBuilder_Root = Root["BlockBuilder" + std::to_string(times)];   /* options_ */   Json::Value _options__Root = _BlockBuilder_Root["options_"];   int _options__len = _options__Root.size();   Wings::Options* _options_ = DriverstructOptionsPoint(_options__Root, _options__len);   /* buffer_ */   std::string _buffer_= _BlockBuilder_Root["buffer_"].asString();   /* counter_ */   int _counter_ = _BlockBuilder_Root["counter_"].asInt();   /* finished_ */   bool _finished_;   int _finished__value_ = _BlockBuilder_Root["finished_"].asInt();   if (_finished__value_ == 0) {     _finished_ = true;    }   else {     _finished_ = false;   }   _BlockBuilder = new Wings::BlockBuilder(_options_, _buffer_, _counter_, _finished_, false); } DriverBlockBuilder::~DriverBlockBuilder() {     if (_BlockBuilder != nullptr) {         delete _BlockBuilder; } }每个成员函数对应生成自己的驱动函数。类中的Add函数对应的驱动函数如下。Add驱动函数:int DriverBlockBuilder::DriverBlockBuilderAdd2(int times) {     Add2Times = times;     const char* jsonFilePath = "drivervalue/BlockBuilder/Add2.json";     Json::Value Root;     Json::Reader _reader;     std::ifstream _ifs(jsonFilePath);     _reader.parse(_ifs, Root);     Json::Value _Add2_Root = Root["Add2" + std::to_string(times)];     /*It is the 1 global variable: count    Add */     int _count = _Add2_Root["count"].asInt();     count = _count;     /*It is the 1 parameter: key Add2      * Parameters of the prototype:const Wings::Slice &key */     Json::Value _keykey_Root = _Add2_Root["key"];     /* data_ */     char* _keydata_;     {         std::string _keydata__str = _keykey_Root["data_"].asString();         _keydata_ = new char[_keydata__str.size()];         memcpy(_keydata_, _keydata__str.c_str(), _keydata__str.size());     }     /* size_ */     unsigned int _keysize_ = _keykey_Root["size_"].asUInt();     Wings::Slice _key(_keydata_, _keysize_, false);     /*It is the 2 parameter: value    Add2      * Parameters of the prototype:const std::string &value  */     string _value = _Add2_Root["value"].asString();       //The Function of Class    Call     _BlockBuilder->Add(_key, _value);     return 0; }构成以上驱动函数的主要包括全局变量、参数、调用被测函数的构建。以上是针对BlockBuilder类的驱动类的主要信息,而构建的程序遵守google的编码规范。一些命名规则如下:Wings生成的驱动代码,存储在drivercode文件夹中。(1)driver.cc与driver.h,针对程序中使用到的一些公共函数以及头文件。(2)同一个结构体或者联合体,可能会作为多个函数的参数使用,为了避免代码的重复,Wings针对所有的结构体和联合体的不同类型,封装成不同的驱动函数或者参数捕获函数。driver_structorunion.cc 存储结构体驱动函数的代driver_structorunion.h 对应的头文件。结构体实现函数的命名规则为:DriverStruct+结构体名字+类型,其中Point代表一级指针或者一维数组,PointPoint代表二级指针或者二维数组使用。源文件的命名规则为:driver_+源文件名/类名+.cc例如:driver_nginx.cc 或 driverBlockBuilder.cc驱动函数的命名规则:Driver_+函数名+(编号)例如:Driver_ngx_show_version_info(void);DriverBlockBuilderAdd2(int times)    (3)返回值的打印输出返回值的打印输出函数命名规则:Driver+Return+Print_+函数名。例如:DriverReturnPrint_ngx_show_version_info();(4)用户源代码中的main函数自动进行注释,重新生成一个main函数文件,来进行测试。Wings会生成驱动main的主函数文件为:gtest_auto_main.ccWings主要针对参数进行逐层展开,解析到最底层为基本类型进行处理。驱动的赋值部分,主要就是针对基本类型进行处理。(注:特殊类型,比如FILE等,后面会详细讲解如何赋值)以int类型举例,一般程序构成int的主要组成大概包括以下情况:int p; int *p; int **p; int ***p;int p[1]; int p[2][3]; int p[1][2][3];int(*p)[]; int(*p)[][3]; int *(*p)[]; int (**p)[];int *a[]; int **a[]; int *a[][3]; int (*a[])[];Wings会针对基本类型的以上15种类型,进行不同的赋值。构建完驱动程序之后,要对驱动程序进行运行,Wings构建googletest的框架,来进行测试。下面我们将针对期望断言的googletest程序进行构建。5.2 googletest程序的构建在构建完单元测试驱动程序之后,Wings将调用googletest的框架,完成对返回值的期望值验证代码,并且输出测试结果。Wings运行单元测试过程中,会构建返回值的保存代码,将程序的返回值结果进行存储,然后读取用户输入的预期值,进行结果对比,判断是否通过。针对具体的类,对应生成gtest类,每个gtest类中对每个函数构建期望代码。例如针对BlockBuilder类,生成的gtest类为 GtestBlockBuilder。GtestBlockBuilder类的声明:class GtestBlockBuilder : public testing::Test { protected:     virtual void SetUp()     {         const char* jsonFilePath = "../drivervalue/RecordDecl.json";         Json::Value Root;         Json::Reader _reader;         std::ifstream _ifs(jsonFilePath);         _reader.parse(_ifs, Root);         driverBlockBuilder = new DriverBlockBuilder(Root, 0);     }     virtual void TearDown()     {         delete driverBlockBuilder;     }       DriverBlockBuilder* driverBlockBuilder; }; BlockBuilder类中的每个函数对应一个gtest函数,每个函数负责调用DriverBlockBuilder编写的驱动函数,对于包含返回值信息的函数,则对应生成具体的期望值对比。 期望对比函数CurrentSizeEstimate:TEST_F(GtestBlockBuilder, DriverBlockBuilderCurrentSizeEstimate4) {     const char* jsonFilePath = "drivervalue/BlockBuilder/CurrentSizeEstimate4.json";     Json::Value Root;     Json::Reader _reader;     std::ifstream _ifs(jsonFilePath);     _reader.parse(_ifs, Root);     for (int i = 0; i < BLOCKBUILDER_CURRENTSIZEESTIMATE4_TIMES; i++) {         driverBlockBuilder->DriverBlockBuilderCurrentSizeEstimate4(i);         Json::Value _CurrentSizeEstimate4_Root = Root["CurrentSizeEstimate4" + std::to_string(i)];         /* return */         unsigned int _return_actual = _CurrentSizeEstimate4_Root["return"].asUInt();         /* return */         unsigned int _return_expected = _CurrentSizeEstimate4_Root["return"].asUInt();         /* return_expected */         EXPECT_EQ(_return_expected, _return_actual);     } }最后调用自动构建的main函数运行整个单元测试过程。5.3 参数捕获程序构建参数捕获是指在程序运行过程中获取程序的变量信息,主要包括函数的参数、全局变量、返回值等。Wings自动构建获取参数的程序,利用插装技术,将构建的捕获函数插入源代码中对应的位置,将获取的具体信息,写入值文件,可以将获取的数据作为单元测试的输入,在代码发生变更后,利用相同的输入判断是否得到相同的输出,进行回归测试。Wings的参数捕获代码存储在paramcaputrecode文件夹中。其中命名规则同驱动格式一样,将所有的driver替换为param即可。Wings针对每个类生成一个对应的参数捕获类,而参数捕获类中针对每个函数生成对应的捕获参数、全局变量以及返回值的函数。c++ 中类的成员变量是私有,无法从外部获取,Wings利用插桩技术,对每个类插入一个捕获函数,来获取类的私有成员变量。参数捕获类ParamCaptureBlockBuilder:class ParamCaptureBlockBuilder { public:   ParamCaptureBlockBuilder();   ~ParamCaptureBlockBuilder();   void ParamCapture_Reset1();   void GlobalCapture_Reset1();   void ReturnCapture_Reset1();   void ParamCapture_Add2(const Wings::Slice &key, const std::string &value);   void GlobalCapture_Add2();   void ReturnCapture_Add2();   void ParamCapture_Finish3();   void GlobalCapture_Finish3();   void ReturnCapture_Finish3(class Wings::Slice returnType);   void ParamCapture_CurrentSizeEstimate4();   void GlobalCapture_CurrentSizeEstimate4();   void ReturnCapture_CurrentSizeEstimate4(size_t returnType); };具体的捕获函数不再详细说明,具体信息可以在Wings官网下载试用版本查看。第六章 Wings类型以及面向对象语法特性的支持Wings能够支持任意的类型以及面向对象的语法特性。类型支持:l  基本类型,int、double、float、std::string等l  任意复杂的结构类型,结构体、联合体、枚举、链表、多级指针、数组、树、图等l  任意复杂的类对象,标准库容器、自定义模板类特殊模板:n  区分用户自定义的类型与系统变量类型(标准库头文件中包含的类型)n  类的运算符重载函数n  void *与函数指针n  识别类中包含delete与default关键字的函数进行特殊处理语法支持:u  处理static函数、保护和私有函数u  类中定义私有结构体u  类中包含delete与default关键字的函数进行特殊处理u  多态与复杂的类继承6.1链表针对链表类型,采用比较灵活的赋值方式,考虑到实际应用中的一些因素,针对链表类型,默认赋值两层结构,在实际测试过程中,用户可依据需要自动添加节点。6.2 标准库容器Wings能够支持c++的标准库容器,能够对容器进行逐层展开,利用不同容器的标准赋值函数进行赋值以取值。其他类似的容器例如QT中的容器以及boost库中的相关容器,我们在继续支持。6.3 自定义模板类一些用户自定义的模板类类型,Wings能够识别是用户自定义的模板类,Wings依据实际程序中的赋值类型,进行处理。6.4  void*与函数指针Void*与函数指针在实际程序中可以作为函数参数或者结构体与类的成员变量,针对不确定的赋值类型,Wings提供了具体的解决办法:① 利用编译底层技术,对源程序静态分析,获取真实类型,对真实类型进行赋值② 由用户在数据表格界面配置实际类型6.5 特殊模板在实际的代码程序中,会存在一些类型无法使用通用的模式全部展开,如一些系统变量(FILE、iostream)、第三方库以及一些用户需要特殊赋值。Wings是如何针对以上特殊类型进行赋值,举例如下:struct sockaddr_in {         short   sin_family;         u_short sin_port;         struct  in_addr sin_addr;         char    sin_zero[8]; };步骤如下:a.        识别sockaddr_in为系统变量类型,特殊标记b.        检测程序中的所有系统变量类型,显示在模板界面c.         用户配置特殊变量,如sin_familyd.        构建sockaddr_in对象e.        调用模板,生成驱动模板配置如下:图:6.5模板配置  第七章 数据表格Wings目前测试用例数据采用随机生成的方式,支持int、char、double、float、bool、char*类型。数据表格可以任意编辑以上类型的数值。(1)Wings数据表格将会针对参数进行展开,假如参数类型为结构类型,数据表格将分层展开结构的类型,到基本类型。(2) 针对基本类型的指针类型,例如int *p;Wings处理为不定长度的一维数组类型,int **p;处理为不定长度的二维数组类型,默认长度为3,数据表格界面可以点击进行添加和删除数据。(3) 针对不定长度的数组作为函数参数,例如int p[];Wings默认长度为1,用户依据需求,在数据表格界面进行任意添加和修改即可。图 7-1数据表格展示 附录A表一:type属性ZOA_CHAR_S/ZOA_UCHAR/ZOA_INT/ZOA_UINT/ZOA_LONG/ZOA_ULONG/ZOA_FLOAT/ZOA_UFLOAT/ZOA_SHOTR/ZOA_USHORT/ZOA_DOUBLE/ZOA_UDOUBLE基本类型StructureOrClassType结构体类型ZOA_FUNC函数指针类型ZOA_UNION联合体类型ZOA_ENUM枚举类型ClassType类类型  表二:basetype属性BuiltinType基本类型ArrayType数组类型PointerType指针类型StructureOrClassType结构体类型UnionType联合体类型EnumType枚举类型FunctionPointType函数指针类型 表三:其他属性Name代表结构体、类、联合体名字NodeType代表链表类型parmType代表函数参数类型parNum代表函数参数个数SystemVar代表此类型为系统头文件类型value代表枚举类型的值bitfield代表位域类型所占字节returnType代表返回值类型Field类成员变量Method类构造函数paramName类构造函数参数名paramType类构造函数参数类型TemplateArgumentTypeSTL结构参数类型WingsTemplateArgumentSTL结构嵌套参数名字TemplateArgumentValueSTL结构中参数为具体值FunctionModifiers函数访问权限FunctionAttribute函数是extern或者static函数FuncClassName函数所属类OperatorFundecl重载运算符函数Operator重载运算符类型
总条数:21 到第
上滑加载中