星云测试
探索云世界
星云测试
专注于软件测试
随着国内大数据、云计算、人工智能等新技术的发展，银行业的前中后台正面临着全面改造，金融科技是业务转型发展的一个核心发力点。金融行业信息系统集中度高、规模庞大、多系统之间关联性强、业务复杂、需求变化快，另外各种新旧系统错综交互，软件质量控制难度异常复杂。通过技术手段精准地追溯每一个数据路线，有效实现信息系统的高可靠性和易维护性，是金融业界共同的目标。 一、传统测试的局限 目前，在大部分金融机构中，主流的功能测试方法是黑盒测试辅之以一定量的自动化测试。由于自动化测试用例的维护问题较多，黑盒手工（功能）测试依然是主流。它有很多经典方法，如等价类、正交用例设计法以及近些年流行的探索性测试等。因黑盒测试方法总体依赖于业务经验，以及一定的测试“灵感”和临场发挥的“算力”，随着金融软件复杂性和迭代速度的不断加快、软件系统组合路径膨胀等问题，人脑的推算力显然远远跟不上了。即使很优秀的测试人员，也会因为状态问题而导致测试用例设计水准出现波动。后续测试覆盖不充分性日益凸显，剩余至少30%以上的漏测点。而白盒测试工具，因为技术没有跟上敏捷迭代的开发场景，目前在金融企业几乎很少在实际中应用。 二、精准测试概念的提出 如何快速定位金融大型信息系统的测试死角，用“可量化”和“可视化”的分析与测试手段，有效地发现程序深层隐藏的缺陷、提高信息系统投产质量、降低投产风险、增强投产信心，金融业甚至软件业均在寻求最佳解决方案。 精准测试方法体系，是近年来业界颇为关注的新测试技术体系。它立足于“系统级”测试，建立了业务功能与代码之间的映射与追溯关系，在代码优化、快速定位代码缺陷、确保关键代码的测试覆盖、精准回归等方面表现突出。为金融信息系统实施高效管理，提供了质量抓手。 三、 精准测试的关键技术 1. 精准测试的核心技术 精准测试最底层的核心技术：“一种基于用例与源码双向追溯的测试装置及方法”，用一个量子纠缠的形象类比：如常见的金融转账、手机拍照、机器人控制等指令，每个操作都有与之对应的代码，他们之间如同两个纠缠在一起的粒子，具备强关联性。一个发生变化，另一个必定发生相应变化。星云精准测试将功能用例和对应的代码之间实现了精准无误的追溯路线可视化，彻底解决了“黑盒”的难题。在此核心技术基础上，诸如：“回归测试用例的自动选取”、“覆盖率可视化”、“智能缺陷定位”、“聚类分析”等精准测试的高级功能得以充分实现。 图 双向追溯(正向)-测试用例追溯到代码 由于优秀的内核设计，星云精准测试可以轻松应用在数亿行的超大型复杂应用上，在建立测试用例、代码、模块之间精准可视追溯机制的同时，瞬间可将海量数据实时采集并存储起来，用于后续测试大数据的分析和运算上。整体过程对原有系统性能，不产生干扰。 2. 高度智能化的静默式落地方案 星云精准测试并不改变现有的测试流程和团队组成，它巧妙地使黑盒测试无缝对接到精准测试体系，快速实现提升测试效能比的刚需。测试工程师打开测试用例的Excel表格、执行点击用例，即可通过VBA技术，直接调用星云精准测试的后台接口，再附加一整套深入应用后台执行线程的用户标签技术，就可以将用例和代码关联和分离出来（分离是指类似J2EE服务端后台应用）。在对外提供多用户并发访问的情况下，可分离出每个用户执行的用例所对应的代码。测试者在整个过程中，几乎不需要增加额外工作量。 3. 精准可信的测试数据记录过程 传统测试有点像挖矿藏，主要依赖测试用例执行数、时长、bug的数量等外在维度进行衡量，缺陷是未知数，结果不那么具备公信力。精准测试是传统测试走向可信测试的一个最好的技术手段。它的所有测试数据均是在测试执行过程中，由软件自动分析并录入的底层代码运行原生数据。由于用例和执行代码之间信息被完整跟踪，并且细分到测试用例级别，因此整个测试数据都可以在代码层面可视化出来，人工无法介入修改。它真实再现测试现场情况，结果可直接用于测试的过程管理和实效分析。从技术上确保所有数据精准无篡改。这一举措，使测试的衡量点回归到计算机程序的本质-“代码”上来。 四、精准测试的应用实践 精准测试的用例与执行代码的强追溯性，为采集到的海量测试数据实现精准度量以及全面、多维度的测试分析，打下了坚实基础。测试管理从相对单一的覆盖率考量视角，扩展到多剖面的智能分析。由于篇幅限制，本文选择两个主要功能点做一介绍： 1、企业级覆盖率方面的创新 测试覆盖率是测试界公认的测试结项可用量化指标。在敏捷迭代场景下，由于新版本快速发布，代码变更频繁，本应在一个版本上分析的覆盖数据，分布到了数个代码结构不一样的程序版本上，因此传统白盒覆盖率的统计方法和参考意义基本上都失效了。星云精准测试通过软件示波器在系统测试阶段取采集多种代码覆盖率（最高支持航天航空标准MC/DC的100%覆盖率要求），提供实时覆盖率增长趋势图及各类分析报表，管理者可清晰的观察整个测试进度情况、效率等。 覆盖率智能合并。精准测试可以按照敏捷的模式，将多个版本的覆盖率以最新程序代码版本为投影进行合并，在控制流上直接累加，无需在每个版本上跑全量用例。它在不同的版本上执行不同功能范围的用例，然后合并一个测试周期的覆盖率信息，看总体的覆盖情况。覆盖率合并算法将全自动分析每个版本序列上程序函数变更的情况，以最新版本往前合并，直到某个模块的代码发生变化，在此之间的覆盖率均可合并。 增量覆盖率分析。版本发布后，精准测试可以对增量代码覆盖专门有一个统计维度，这样也是对于覆盖率目标的一种工业应用新思路，不用去关注总体覆盖，而在迭代中关注调整代码的覆盖，尤其是新增代码的覆盖情况。 覆盖率可视化。在星云精准测试中，用户在选择分析的覆盖率维度后，系统就会将被测试程序的相关结构展示出来，并且用颜色表达覆盖情况：绿色代表覆盖，深蓝色代表未覆盖。同时告知覆盖率的分子和分母都是哪些，非常清晰的展示覆盖率可视化结果。 相关覆盖率。可将某个功能用例所触及的函数范围中，所有代码分支作为覆盖率的分母，真正运行到的分支作为分子，这样取得的相关覆盖率非常具有实际指导意义。使用者在有权限的情况下，随时可以看到：因此即使测试的是一个小功能范围的用例集，其覆盖结果也可以近似等价为这个功能范围相关代码的覆盖率情况，亦可以用于分析某个功能范围的测试是否充分。 2、回归测试用例的推荐和选取： 对于测试效率的提升，一般会提到狭义的自动化测试，这也是行业内通常解决回归测试的办法。它是一种应对全局回归的方法，在无法有效确定回归范围的情况下，就通过技术手段全量回归以确保系统的修改没有引入新的问题。真正实施过全量自动化回归的团队，会对此项工作的难度和成本深有体会。 星云精准测试回归用例自动选取是属于一种机器智能计算下安全的局部回归。它根据历史测试用例执行的路径信息以及新版本的代码变更信息，自动推荐和选取回归测试用例集，并给出回归优先级和影响度。用户在测试人力有限的条件下，可以根据算法给出的优先级安排测试执行，以最有效的方法发现代码调整引入的缺陷。这种基于海量的程序运行路径计算的数据，精确而完整，不会因团队工作状态问题，而出现大量遗漏的现象。 五、小结 精准测试将大幅度提升测试数据的价值，也将产出大量对研发极有意义的分析数据。它必将推动软件行业的数字化改革，为传统金融业务及金融创新（Fintech），提供更智能、有效的软件高端质量保障思路与方法。
星云测试Horn插装采用脚本配置方式自动对语法进行扫描和插装，在整个插装过程中需要用到星云提供的插件工具。通过与CI集成，在CI编译前通过jenkins调用星云插装插件模块进行必要的数据填充，生成对应的项目插装脚本，即可以通过星云插装插件进行项目插装与编译。 通过星云插件脚本自动创建工程和代码插装 1.解压星云提供的插件包 星云测试在windows环境下提供的插装工具为javaForWindows工具包；将javaForWindows放到合适目录下并解压即可。（LINUX使用LINUX插件包）。（登录星云网站www.teststars.cc 离线企业测试中心即可免费试用） 2.修改脚本配置 星云测试整个编译通过脚本ComplierPath.xml配置文件进行，在ComplierPath.xml中用户需要配置TTserver的服务器地址、用户名、项目名、版本名、以及代码路径等，如果需要过滤不需要插装的代码，也可以通过该配置进行过滤。通过jenkins对通用模板进行数据填充，生成本次插装编译项目所需要的对应脚本。 配置参数说明： <server_ip>127.0.0.1</server_ip><!--服务端ip，按照实际配置--> <user_name>user</user_name><!--编译账户用户名-->使用该用户名前，建议该用户名没有其它登录客户端操作 <password>user</password><!--编译账户用户密码--> <is_append>0</is_append><!--是否追加编译0不追加 1 追加-->一般默认 <is_Regression>0</is_Regression><!--是否选择回归0不回归 1 回归-->一般默认 <is_AddCompile>0</is_AddCompile><!--是否增量编译0否 1 是 增量编译是文件级别的去重编译，此时会忽略同模块名级别去重-->一般默认 <is_classCompileOnly>0</is_classCompileOnly><!--是否追加class编译0不追加 1 追加-->（注意：project_path 和 class_path 路径不能为空）一般默认 <compile_mode>1</compile_mode><!--编译模式0 旧编译模式（通过客户端登录方式） 1新编译方式-->一般默认 <is_Parallel_compile_mode>0</is_Parallel_compile_mode><!--是否支持并行编译0 否 1是-->一般默认 <tool> <project_name>j2eeproj</project_name> <!--项目名称，追加编译时候必须填写，普通编译可以置空，建议按实际项目填写--> <baseversion_name>asdasdada_RR</baseversion_name> <!--基础拷贝版本名称，以为空默认查找当前项目下最新的版本作为基础版本-->一般为空 <version_name>Ver2</version_name> <!--版本名称，可以为空，默认按照当前时间创建： 例如：Ver_2019_02-02-18_0_0 ，该新建版本可以再客户端菜单：文件/刷新工程导航树 刷新出来--> <submodule> <proName>TTPro1</proName> <!--当前模块名称，如果配置为追加编译且不是增量编译会按照同名模块去重，建议起初就进行配置--> <Path> <project_path>J:\sushe\src</project_path> <!--src项目路径--> <class_path>J:\sushe\build\classes</class_path> <!--class文件目录--> <encode>GBK</encode> <!--编码格式Automatic_encoding 有系统自动识别或者配置实际编码格式-->一般默认 <filterPath>D:\moxi\target\classes</filterPath> <!--过滤不插装的路径-->（注意：想要不插装多个路径，就写多个filterPath）一般不填写 </Path> </submodule> </tool> 3.插件运行进行代码分析与插装 TT插装插件可以通过Jenkins命令进行启动，如：Windows通过cmd命令选择到插件所在的根目录下，运行autoCompiler.jar进行编译（记得编译得时候在javaForWindows目录下进行编译）命令: jrebinjava.exe -jar autoCompile.jar -c D:J2EEjavaForWindows **注：**-c后面的参数为ComplierPath.xml文件的目录 命令生效后自动进行代码分析与插装并在cmd窗口中进行打印。  注意：0若是选择为1的启动方式：.jrebinjava.exe -jar autpCompile.jar -c 插件路径 ComplierPath.xml绝对路径 4.项目静态数据加载 插装成功后，通过登录客户端选中我们插装的项目进行版本静态数据的加载，加载成功后即可看到分析的生成的静态数据 5.源码路径替换，采用星云插装代码 由于测试的时候需要运行星云插装过后的代码应用生成采集数据，所以需要对编译的源码路径进行相应修改，通过Jenkins脚本对目录进行更替，星云插装过后的代码会在脚本配置的代码路径的目录同层下生成src-instru目录，src-instru目录即为编译插装后的源码）;具体操作：先将源码目录下未插装的java目录重命名为pre_java，再将编译插装生成的src-instru目录命名为java。 6.项目添加星云依赖库进行并编译 Maven项目pom.xml修改加入依赖库 因采用星云插装过后的代码，即在编译过程中需要引入星云提供的2个依赖库，Maven项目可以通过修改pom.xml进行引入通过jenkins自动修改项目的pom.xml文件来引入TT的依赖库：方法加入到两个之间，加入的代码如下： systemPath需要按JavaParser-j2ee.jar和jeromq-0.3.0-SNAPSHOT.jar的绝对路径填写 <dependency> <groupId>com.zoa</groupId> <artifactId>JavaParser-MQ</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/JavaParser-J2EE.jar</systemPath> </dependency> <dependency> <groupId>com.zoa</groupId> <artifactId>jeromq</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/jeromq-0.3.0-SNAPSHOT.jar</systemPath></dependency> 在pom文件修改完成后即可打包发布在被测程序目录下执行mvn clean package 命令 传统J2EE项目或安卓项目 通过jenkins在编译项目中引入JavaParser-j2ee.jar和jeromq-0.3.0-SNAPSHOT.jar进行编译，注这里需要群J2EE和安卓项目，如安卓项目需要把2个依赖包最终打入到APK中，如果是J2EE项目，请在最后生成的war包或jar包中取出该依赖包，因J2EE项目最终会搭配agent使用，agent中会自带该依赖。打包完成，为使函数覆盖率可视视图代码部分显示正常，需要手动修改源码路径：右键版本，点击修改源码路径，选择到pre_java目录即可。
现代的专业软件测试中心，随着项目的迭代，通常针对每个系统构建了大量的自动化测试用例集，而启动一次全量的自动化测试以CI级触发，使之大比率通过，非常困难。测试工程师们常常需要投入很高的成本，把大量精力花在自动化用例失败排查上面，然而发现有效BUG的概率很低。在反复排查无果、心神俱疲的情况下，几乎对自动化产生绝望之心，视之为鸡肋，用之无用，弃之可惜，让测试中心极为头疼。 如何让自动化用例发挥它们应有的效用，让QA工作不那么沉重呢？星云测试针对这一难题，进行了精准测试与自动化测试无缝对接的技术方案研发。经过大量企业实施与验证，精准测试的数据流最终可以“无感”对接到自动化测试中，极大扩展了自动化测试的优势，彻底改进了自动化测试变更管理难的短板。 这一技术方案的推出，就像给自动化测试装上“精准测试”的眼睛和翅膀，瞬间就具备了多种飞跃功能。比如： 1) 自动化测试用例与源码自动建立关联 2) 同步进行智能回归用例选取 3) 有效缩小自动化测试执行范围 4) 即时分析需要进行维护的测试用例集合 5) 全自动追踪每个测试用例的执行代码路径 6) 当自动化执行结束后可辅助直接定位自动化用例的代码出错点 7) 对自动化测试用例集进行分析，例如聚类分析，以及最小用例集合分析等 8) 对测试用例集的优化给出指导意见 9) 给出测试用例集运行的总体覆盖率信息 10) 协助有效的对用例集进行增补 11) 增量代码覆盖率分析等等。 本文重点以星云精准测试产品与单元测试框架JUnit为例进行说明。 单元测试一般通过写测试用例来测试：核心类方法，异常处理，业务逻辑等。实现Junit单元测试与精准测试的无缝对接后，基本可以确保真正的测试充分性。因为在运行单元测试用例的时候，精准测试系统中将自动生成相应测试用例，并将每个单元测试的代码覆盖情况详细的记录到精准测试系统中，由于精准测试自带测试用例与代码相互追溯以及覆盖率可视化的特性，你可以对当前所写的单元测试是否充分，一览无余。 下图是精准测试与Junit单元测试无缝对接实现自动化测试的架构示意图。 该方案主要特点是：充分利用了JUnit框架的继承特性，所有精准测试必要的通信和控制逻辑可以全部通过基类实现。也就是说，对于原来所有自动化测试用例集，只需要增加一个对于封装的ParentTest的继承。即：不需要对原有测试用例的实现代码做任何改动，就可以实现与星云精准测试平台的对接。对接完成后，JUnit测试的运行过程中，测试用例会自动的在星云精准测试系统中创建，并且全自动记录每个自动化测试用例的代码覆盖信息。 下面是对ParentTest扩展基类主要方法的描述，该解决方案主要针对Junit框架自身的注解方法进行扩展：@Before：初始化方法对于每一个测试方法都要执行一次，在每个测试方法之前执行，@After：释放资源，在每个测试方法之后执行，@BeforeClass：在当前类的所有测试方法之前执行，@AfterClass：在当前类中的所有测试方法之后执行。一个JUnit4的单元测试用例执行顺序为： @BeforeClass -> @Before -> @Test -> @After -> @AfterClass; 因此可针对这个特性在不同注解代码中进行定制，定制一个公共的类，当其他的单元测试都继承自该类时，也运行相同的方法。通过在不同注解中添加登录版本，创建测试用例并开始，结束测试用例以及登出版本命令，并发送至TTFront组件实现与TT的交互，并不影响单元测试本身的测试程序和测试结果。 TTfront在接受到命令后，登录对应版本并记录用户名，创建完成测试用例后当测试用例运行时刻通过软件示波器实时采集该测试用例对应的覆盖率数据，将该部分数据通过用户名匹配到该测试用例。在TT客户端可以看到测试用例以及该单元测试对应的函数覆盖情况以及代码覆盖情况。 只需要在创建单元测试的时候类继承自已经封装好的ParentTest类，即可与TT无缝对接实现自动化测试。 Junit单元测试与TT对接的实施案例以及效果图： 1、创建测试用例时继承自ParentTest类 2、修改ParentTest中的项目，版本，用户密码以及TT服务端IP 3、对应修改引入的包(以mvn项目为例)，JavaPaser包主要包含了插装代码以及ParentTest类必须要的TT处理逻辑需要的库的引用。 对被测试代码通过TT进行插装打包，注意Junit自动化测试用例代码不需要插装，只需要插装Junit测试的业务逻辑代码即可。 4、开始单元测试，在测试用例执行过程中，打开TT客户端示波器组件，显示实时采集的覆盖率波形，看到测试用例在TT系统中自动建立。TT客户端效果图（生成对应测试用例以及该测试用例的覆盖情况） 以上讲述了精准测试系统如何无缝与现有自动化测试框架的对接。除了Junit，其他自动化测试框架，均可以参照此思路进行实现（登录星云网站www.teststars.cc 离线企业测试中心即可免费试用）。精准测试系统与自动化进行对接后，可以使无法看清的黑盒状态中的自动化测试执行，变得有迹可循。基于精准测试强大的测试分析系统，可以对自动化测试执行和规划进程进行持续的优化，这一方案，可以有效解决自动化测试的投入产出比居高不下的业界难题。
导读：本文根据实际使用情况，简要分析了精准测试和类Jacoco等传统白盒工具在设计理念、功能和应用场景的异同点，并阐述了覆盖率技术如何在新型企业开发体系中，发挥应有的重要作用。 覆盖率技术可以说是测试理论中最基本的技术体系，但由于传统覆盖率并没有很好的适应新型软件开发模型，导致应用场景越来越窄。比如：Jacoco等同类工具，仍停留在传统白盒覆盖技术的技术演化层面，目前基本仅适用在瀑布模式的开发体系下。最新的测试黑马技术—“精准测试”覆盖率功能是企业级、面向敏捷迭代场景、全新的覆盖率技术。它明确提出了用例层级覆盖率的概念，并将用例层级覆盖率技术广泛应用于智能的测试分析算法。 精准测试的专利技术之一：测试用例与代码的双向追溯，可以简单理解为：所有分析和计算依赖于测试用例维度的覆盖信息。它创新性的将覆盖率统计维度从全局维度显示，降维到了测试用例这一细节，使覆盖率的放大作用远超出原有能力。它如同放大镜一样，使测试分析、测试算法以及测试数据真正做到一览无余，不错过任何重要细节。 Jacoco是传统的白盒覆盖率工具，不具备将覆盖率与用例关联的功能，很遗憾的不具备精准测试的所有高级特性。下面仅就“覆盖率”这一功能，将精准测试与Jacoco为代表的传统白盒覆盖工具进行一个简单比对： 1 覆盖率分析能力PK Jacoco：作为传统白盒功能的代表，它的应用模式是部署在后台，采集所有执行代码的覆盖率，所有用户请求和功能的覆盖数据为混合统计，范围仅围绕在看覆盖率上。但这种覆盖信息的弊端是：它从全系统维度来统计，导致颗粒度太大，无法详细定位和深度分析覆盖率的真正问题。 精准测试：可以像调焦距一样，在并发访问的后台服务中，将某个测试用例的执行路径分离出来，进行各种细致分析。它用例级的双向追溯的覆盖信息，带有执行时序，可以很快定位缺陷发生时刻代码的执行路径（类似于重现单步调试场景），与此同时，还可以对测试人员的用例执行情况，进行非常精确的代码级跟踪。 2 对于敏捷测试的响应能力PK Jacoco：不适应于敏捷迭代过程对于覆盖率的企业级需求。当代码发生变更后，Jacoco将重新采集覆盖率，各个发布版本采集的结果孤立存在。现代企业通常每天会发布多个版本，孤岛式无对比分析的覆盖率结果，价值不大。因为每组测试执行通常是在每个版本上跑一部分用例，而不是瀑布模型下在一个版本上进行所有用例的测试。 精准测试：在覆盖率计算和应用上有累积覆盖率、增量覆盖率、相关覆盖率、高风险覆盖分析、可变分母覆盖等诸多创新办法，随时响应敏捷迭代需求。1）累积覆盖率：精准测试可以将多个测试覆盖进行累计和投影，这样就无所谓中间发布多少个版本、每个版本上跑多少个用例，可以自由选择看一个阶段的总体覆盖率。 2）增量覆盖率：由于企业软件体量庞大，因此无论如何测试都很难满足100%覆盖率的要求。所以通常企业更关注的是增量覆盖率，即新发布版本相比上一个测试版本修改后的代码覆盖情况。精准测试由于每个版本发布的时候都有详细的代码静态分析数据支持，因此它可以智能标识版本差异，并将版本差异的代码覆盖进行高亮显示，帮助企业关注新增/调整代码部分的覆盖率。 3）相关覆盖率：精准测试创新性提出了相关覆盖率技术，即把一个功能模块相关的代码作为计算的分母计算覆盖率。这样非常有利于在敏捷迭代场景下，只测试部分功能的覆盖率分析。相关覆盖率可用于支持功能模块（用例分类）级别的覆盖率，从业务角度统计某一个功能模块相关代码范围的覆盖率，明确指出某一个功能范围的测试覆盖充分度，而不是传统的全局代码覆盖率。 4）高风险覆盖分析：精准测试支持基于静态数据和动态数据高风险的模块检出，引导用户把精力投入到最高风险的模块覆盖逻辑补充上。 5）可变分母覆盖：精准测试支持多种系列的企业级覆盖计算要求，例如通过界面设置，将某些确定不需要或者无法覆盖的代码（例如暂时保留的无效代码）从覆盖率计算结果中排出，整体重新进行覆盖率的计算。支持某一个代码路径下（某一程度模块）范围内的代码覆盖等高级特性。 3 覆盖率可视化能力 PK Jacoco：基于字节码插装，没有全面的程序静态分析过程，因此无法将覆盖率通过静态分析得到的可视化图形结合清晰展示覆盖率信息。另外，Jacoco必须提供源码才能看懂覆盖率。 精准测试：具有多种函数调用图，控制流程图上展示覆盖率信息，可以在没有源码的情况下，基于精准分析结果，结合动态覆盖率视图，清晰展示程序的覆盖和执行路径信息。 4 覆盖率统计能力 PK Jacoco：以行覆盖和分支覆盖为主。Jacoco是传统行覆盖，基本上每行都需要进行插装。在结合代码展示覆盖的视图方面，无法取得程序的深入静态信息，因此一般只能再代码视图上以颜色表达是否覆盖。 精准测试：支持覆盖率计算可视化、多覆盖率算法标准及深度的数据分析。1）支持覆盖率计算可视化，覆盖率是如何计算的都表达的非常清晰（贡献覆盖率的分子分母对应的程序元素、数量），方便用户去深入理解覆盖率的含义和信息。 2）精准测试支持更加深度的条件以及条件组合级别以及航天级MC/DC的覆盖率标准。精准测试提供的语句覆盖是基本块覆盖，一个顺序的代码段因为有静态分析结果的支撑，只需要一个插装点。 3）精准测试对程序的静态结构有深度的分析数据，因此它的代码展示视图很清晰，程序结构都可以绘制出来，代码覆盖率视图看起来非常清晰。例如中间没有跳转的基本块会在展示效果上绘制为一个整体，并有是否覆盖标识，而不是每行都要进行标识。 5 高度产品化特性 PK Jacoco：属于开源范畴，采用字节码插装（指令层级），插装后的代码不可见不可维护，出现问题后很难排查原因，很难定位和修复，商用使用风险较高。每次获取一次覆盖数据都需要访问一个网页地址显示的重新生成。Jacoco的应用模式是部署在后台采集，无前端显示。出现异常时，测试人员无法知晓自己执行的测试用例是否有效。 精准测试：由星云测试（www.teststars.cc） 主导研发，自主可控。在产品化特性有不可比拟的优越性：1）基于源码插装，插装代码可见且开放，非常利于企业应用排查问题和进行流程整合等。万一出现特殊语法问题引起插装问题，用户可以随时查看并自行处理，不会因为极个别情况影响产品应用。 2）覆盖率信息是实时汇总的，通过客户端可以由多个有查看权限的用户（包括开发、测试以及管理人员）实时查阅。 3）软件示波器可实时传输测试过程中的数据，对于传输过程中测试执行覆盖率采集是否有效，可进行可视化的故障排查。
简介：本文主要目的是把现今主流的Dubbo框架项目和精准测试进行对接，通过精准测试的数据穿透、数据采集、测试用例与代码的双向追溯、数据分析等一系列精准测试的特有功能达到对项目质量的保证。 本次环境搭建分为基础环境准备、Dubbo环境搭建、精准测试环境搭建、精准测试与Dubbo环境对接等一整套完整的配置过程，用户可以通过下图中的流程图确认自己所部署过程中进行到的阶段点，从而排查部署中可能遇见的问题。 一 dubbo的工具配置流程 1，使用工具 1， Eclipse Java Photon2， JDK 1.83， MySQL 5.74， Navicat for MySQL5， Nodejs6， apache-maven-3.5.47， zoa-agent-1.6.28， apache-tomcat-8.0.479， J2EE_Enterprise_key_64bit061410， 项目：dubbo11， 服务：zookeeper项目和微服务下载地址：https://pan.baidu.com/s/1JBKJBVhm0XQT0VmWacD3wQ 提取码: nr9t 2 ，配置所需的安装 2.1，安装Eclipse、JDK，tomcat,MySQL、Nodejs 正常安装Eclipse，jdk和tomcat，比且需要在tomcat中配置agent，具体的配置是：找到tomcat的G:apache-tomcat-8.0.47bin目录catalina.bat文件打开以后将agent的安装目录和解密库的目录放在catalina.bat文件里面 脚本安装mysql和nodejs（一键安装）1、 打开TT_Soft文件夹2、以管理员身份运行TeststarsSoftInstall.exe3、等待自动安装完成，关闭窗口4、使用net start mysql 命令启动MySQL服务5、使用node –v查看node版本 2.2, 安装Maven Eclipse本身会带Maven，但是不如自己安装的灵活，解压apache-maven-3.5.4.zip（例如：E:apache-maven-3.5.4），配置系统变量添加变量名：MAVEN_HOME变量值= E:apache-maven-3.5.4，Path添加变量值= %MAVEN_HOME%bin，cmd测试用mvn -v如下即安装成功。 2.2.1，Eclipse替换自带为本地Maven Windows-Preferences-Maven-Installations-Add，路径指向E:apache-maven-3.5.4，加载完成后勾选新的apache-maven-3.5.4，Apply。 2.2.2，定义本地Maven依赖库 修改E:apache-maven-3.5.4confsettings.xml，添加如下一行代码定义，例如：C:Usersluxper.m2repository，C:Usersluxper.m2repository是我的本地maven仓库地址。Eclipse：Windows-Preferences-Maven-User Settings-Global Settings，Browse= E:apache-maven-3.5.4confsettings.xml，Apply。 2， 项目部署 将Dubbo下载好以后直接放在指定目录下 将下载好的dubbo的项目导入到eclipse中 edu-common-parent:提供edu-facade-user:公共接口edu-service-user:服务端（生产者）edu-web-boss:客户端（消费者）将下载好的sql文件正确的导入到数据库中 二 测试项目 1，下载工具及工具配置 1.1，从官网上下载星云测试工具：http://www.teststars.cc/ 下载以后进行配置： 1.2，星云测试服务端的配置 TTLangage.config配置项说明：1、 运行下的星云测试server目录中ThreadingTestServer.exe，在右下的图表中点注册信息，查看其时间，星云测试有两个月的体验，若是超过两个月，发生KEY过期，请联系星云测试的工作人员，并提交服务端中的序列码 2、联系星云工作人员获取当前服务器的key.key文件，替换到星云的server目录下；3、启动server目录下的ThreadingTestServer.exe后会自动打开同级目录下的ThreadingTestServerFront.exe，看到自动弹出下面窗口后，表示连接正常。 1.3，星云测试客户端的配置 注：星云测试在线客户端的连接需要访问端口17262/17263.登陆之前需要保证网络连接不存在限制。打开客户端之前需要修改TTClient文件夹下的Server.cfg文件，配置localIP项为可以与服务端正常数据通信的本机IP地址。配置这个localIP的原因是，在客户端需要接收来自服务端传来的动态数据，配置本地的IP地址服务端才能把数据传到客户端中来。配置IP地址完成后双击运行TTClient/TT.exe文件进入星云测试客户端。选择文件->登录，输入星云测试服务端的IP地址以及自己的用户名和密码即可登录。如下图所示。 1.4，星云测试云报表平台服务启动 1、 运行星云测试TTWeb目录下的binredis-2.4.5-win32-win6432bit中的redis-server.exe2、运行星云测试TTWeb目录下的startTTwebserver.bat访问网页报表网页IP地址:3000 2，创建工程和版本并编译 1， 登录客户端2， 选中待插装的空版本，版本处于解锁状态（解锁状态：右键-解锁状态）3， javaForWindows目录下的Server.cfg配置文件，[SERVER] ip填写实际ip地址，修改[PROPERTY]字段，与客户端目录下的Server.cfg同步 4、修改javaForWindows目录下的ComplierPath.xml配置文件同一个版本下可添加多个子模块即proname，proname不能重复，一个子模块下可以配置多个工程路径ProName：子模块名称Project_path：测试程序源码文件路径Class_path：测试程序class文件路径注意：在进行编译插装的时候，编译插装的项目是edu-service-user，edu-web-boss这两个项目5、修改javaForWindows目录下tt_windows文件夹下Server.ini配置文件Ip设置为客户端的ip地址。6、在命令行运行autoCompiler.jar进行编译 jre\bin\java.exe -jar autoCompile.jar -e D:\J2EE_Enterprise_key_64bit0803\CompileToolsPkg\javaForWindows 注：-e后面的参数为ComplierPath.xml文件的目录7、在客户端查看数据,记得必须点击重新加载文件由于测试的时候需要运行我们插装后的代码（编译完成后会在java目录同层生成src-instru目录，src-instru目录即为编译插装后的源码）;具体操作：先将源码目录下未插装的java目录重命名为pre_java，再将编译插装生成的src-instru目录命名为java。并且插桩代码的运行需要我们的jar包，因此需要修改客户的pom.xml文件来引入我们的jar服务，加入到两个之间，加入的代码如下：systemPath需要按JavaParser-j2ee.jar和jeromq-0.3.0-SNAPSHOT.jar的绝对路径填写 <dependency> <groupId>com.zoa</groupId> <artifactId>JavaParser-ZMQ</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/JavaParser-J2EE.jar</systemPath> </dependency> <dependency> <groupId>com.zoa</groupId> <artifactId>jeromq</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/jeromq-0.3.0-SNAPSHOT.jar</systemPath></dependency> 在pom文件修改完成后即可打包发布 3，打包dubbo的工程例子 1 zookeeper环境搭建zk解压到指定目录下，解压后,将con文件夹下的zoo_sample.cfg拷贝一份,重命名为zoo.cfg，注意修改cfg的内容如下，根据自己的目录来修改：windows系统下会使用zkServer.cmd开启,所以在bin目录下找到zkServer.cmd,双击开启,这个是启动后的成功的图 打开以后就可以进行打包了，在eclipse打然后打包生产者和消费者(打包出来的是war包)，将打包好的war包分别放在不同端口的tomcat中。 生产者启动tomcat： 生产者在启动tomcat时，向注册中心注册自己提供的服务消费者启动tomcat： 消费者在启动时，向注册中心订阅自己所需的服务，注册中心返回生产者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。消费者将设置的标识通过一系列返回给生产者打包完成，为使函数覆盖率可视视图代码部分显示正常，需要手动修改源码路径：右键版本，点击修改源码路径，选择到pre_src目录即可。 4，编写测试用例 点击添加：启动测试用例 5，项目测试 1，设置标识 1,项目URL后面加teststars.jsp，访问teststars.jsp页面进行标识设置2,点击set标识进行设置，设置成功页面如下：注：为了区分测试，我们在设置的用户姓名与星云客户端当前登录用户一致，设置完成后页面显示是 消费者通过web页面设置标识 生产者：通过穿透将消费者设置的标识值穿透到生产者中页面点击登陆进就会有相应的测试数据传输过来（具体的展示见后面测试结果的第一个标题：示波器的展示），数据接收完以后点击停止，本条用例测试完毕 3， 生产者和消费者再客户端的覆盖率展示：消费者在客户端的展示： 生产者在客户端的展示： 三 测试结果 1，示波器波形展示 先选中测试用例，再点击开始后就可以进行相应的测试工作了，测试的时候示波器可以收到动态数据并以波形图的方式展示出来。注：采集的动态数据保存在服务端目录下的VersionData文件夹下 2，缺陷管理 为了让测式人员更好的对缺陷进行管理，采用测试用例、代码、BUG相关联方式，精准测试云平台使用了历史BUG追查功能，这使得在版本迭代过程中，同一个测试用例所有的BUG情况一目了然，避免了因人员变动或版本变动导致的相同的BUG的排查时间，以及重复提交未被解决的BUG。 图表 缺陷提交与管理 图表 bug信息一目了然 3，覆盖率 覆盖率可视化针对函数sc0、True、false 、both、Branch、C/DC 、MC/DC 7种覆盖率给出可视化展示下面针对每一种覆盖率展示界面给出说明：（以sc0为例）sc0为语句块覆盖，其颜色区分对象为基本语句块（包括隐含不可见语句块）其中绿色标示被覆盖的语句块。蓝色是未覆盖到的语句块。计算方法为：覆盖到块/应统计块 用红色的标出来的表示sc0覆盖率，函数列表右方为覆盖率的展示： 4，双向追溯 双向追溯是指通过运行测试用例，实现测试用例与被测源码间相互追溯。根据测试用、查看相关被测源码为正向追溯，根据被测源码查看相关测试用例为逆向追溯。在测试用例列表中选择测试用例，可以追溯到该测试用例的内容描述信息，在模块调用图中显示被测试到的函数；也可以在模块调用图中，点击相关的函数，也可以追溯到相关的测试用例。该追溯技术方便了用户查看和设计测试用例。 双向追溯功能可以运行的前提是，测试用例已经被运行过，并且示波器收到了波形采集到了动态数据。 1，正向追溯 正向追溯是指：将测试用例和海量的代码执行信息自动关联，可精确到函数级别及代码块级别；通过正向追溯可直接在代码级定位测试现场故障和缺陷逻辑，并提供最后运行的时序数据；通过正向追溯自动记录产生功能对应的详细设计实现，辅助软件解耦和架构分析。正向追溯的优势是：迅速定位缺陷对应的代码执行逻辑，帮助开发快速修复缺陷，可追踪难复现缺陷；精确、详尽的记录测试用例运行的情况，为精准软件测试提供大量原生分析性数据；可以进行事后的缺陷分析、追踪，辅助开发进行功能实现确认。生产者的正向追溯： 消费者的正向追溯：如图：点击测试用例追溯到这个用例运行过得函数，选中一个函数，追溯到这个函数运行过得控制流程图的逻辑分支 以下是正向追溯到代码和函数调用图： 2，反向追溯 反向追溯是指：分析代码关联的功能，为研发分析系统和进行一致性修改以及回归测试分析提供精确数据。反向追溯过程：点击需要查看的函数或函数中的某行代码，自动列出可以测试到该函数或者程序分支的测试用例生产者的反向追溯： 消费者的反向追溯： 选择函数追溯到运行过该函数的测试用例，查看该函数的控制流程图和代码点击代码，追溯到运行过该代码的测试用例 5，简易流程图的展示 前置条件：版本有数据，关联源码可在代码视图有显示源码，并且在简易控制流 程图的分支块有具体语句显示，有覆盖率数据，可在简易控制流程图显示当前覆盖到的块信息简易控制流程图功能，以语句块的形式清晰的展示函数内部的控制逻辑，界面上可以直观的看出控制流各节点的测试覆盖情况，在展示中，简易控制流程图还可以通过颜色对每个程序块进行覆盖率标识，在缩略图中整个模块的覆盖率非常直观。（背景色为绿色表示有测试用例覆盖到该块：以SC0覆盖为参考标准） 6，报表的展示 选择客户端所编译的项目和版本：显示所选取编译项目的一些基本信息，包括:项目指标信息、项目信息、版本信息、测试汇总信息、测试过程监控趋势图、测试设备组成和分布图、版本覆盖率汇总图、复杂度统计图项目汇总： 包含项目信息：项目的详情信息 版本信息：版本的详情信息 测试汇总信息：测试用例通过率：无BUG的测试用例 BUG累计：测试用例运行完毕后提交的BUG数 当前版本覆盖率(SC0)：(执行过可见段数/可见段数)*100%的比例 覆盖率增长：相比前一天的SC0增长差值 高复杂度预警函数个数：高复杂度的函数个数 测试用例列表：显示制作的测试用例的详细信息，包括测试用例的名称、创建时间、执行时间、关联函数、覆盖率占比、运行状态、测试人员等覆盖率按日增长曲线图： 覆盖率按日增长曲线图,让管理者更好的把握测试过程 测试漏洞列表： 在一个程序中，往往有成百上千的函数，这些函数有的是关联整个程序核心、有的则是开发人员弃而不用，但一直保留迟迟不肯删除的，针对这些大量的函数，“精准测试”采用通过静态、动态指标的综合分析，在大量的程序函数中，通过计算直接筛选潜在的高危的测试漏洞，通过报表给予展示。 通过复杂度和覆盖率进行计算 通过函数调用上下文和覆盖率进行计算
提交了问题
2018-12-04
简介：本文主要目的是把现今主流的Dubbo框架项目和精准测试进行对接，通过精准测试的数据穿透、数据采集、测试用例与代码的双向追溯、数据分析等一系列精准测试的特有功能达到对项目质量的保证。 本次环境搭建分为基础环境准备、Dubbo环境搭建、精准测试环境搭建、精准测试与Dubbo环境对接等一整套完整的配置过程，用户可以通过下图中的流程图确认自己所部署过程中进行到的阶段点，从而排查部署中可能遇见的问题。 一 dubbo的工具配置流程 1，使用工具 1， Eclipse Java Photon2， JDK 1.83， MySQL 5.74， Navicat for MySQL5， Nodejs6， apache-maven-3.5.47， zoa-agent-1.6.28， apache-tomcat-8.0.479， J2EE_Enterprise_key_64bit061410， 项目：dubbo11， 服务：zookeeper项目和微服务下载地址：https://pan.baidu.com/s/1JBKJBVhm0XQT0VmWacD3wQ 提取码: nr9t 2 ，配置所需的安装 2.1，安装Eclipse、JDK，tomcat,MySQL、Nodejs 正常安装Eclipse，jdk和tomcat，比且需要在tomcat中配置agent，具体的配置是：找到tomcat的G:apache-tomcat-8.0.47bin目录catalina.bat文件打开以后将agent的安装目录和解密库的目录放在catalina.bat文件里面 脚本安装mysql和nodejs（一键安装）1、 打开TT_Soft文件夹2、以管理员身份运行TeststarsSoftInstall.exe3、等待自动安装完成，关闭窗口4、使用net start mysql 命令启动MySQL服务5、使用node –v查看node版本 2.2, 安装Maven Eclipse本身会带Maven，但是不如自己安装的灵活，解压apache-maven-3.5.4.zip（例如：E:apache-maven-3.5.4），配置系统变量添加变量名：MAVEN_HOME变量值= E:apache-maven-3.5.4，Path添加变量值= %MAVEN_HOME%bin，cmd测试用mvn -v如下即安装成功。 2.2.1，Eclipse替换自带为本地Maven Windows-Preferences-Maven-Installations-Add，路径指向E:apache-maven-3.5.4，加载完成后勾选新的apache-maven-3.5.4，Apply。 2.2.2，定义本地Maven依赖库 修改E:apache-maven-3.5.4confsettings.xml，添加如下一行代码定义，例如：C:Usersluxper.m2repository，C:Usersluxper.m2repository是我的本地maven仓库地址。Eclipse：Windows-Preferences-Maven-User Settings-Global Settings，Browse= E:apache-maven-3.5.4confsettings.xml，Apply。 2， 项目部署 将Dubbo下载好以后直接放在指定目录下 将下载好的dubbo的项目导入到eclipse中 edu-common-parent:提供edu-facade-user:公共接口edu-service-user:服务端（生产者）edu-web-boss:客户端（消费者）将下载好的sql文件正确的导入到数据库中 二 测试项目 1，下载工具及工具配置 1.1，从官网上下载星云测试工具：http://www.teststars.cc/ 下载以后进行配置： 1.2，星云测试服务端的配置 TTLangage.config配置项说明：1、 运行下的星云测试server目录中ThreadingTestServer.exe，在右下的图表中点注册信息，查看其时间，星云测试有两个月的体验，若是超过两个月，发生KEY过期，请联系星云测试的工作人员，并提交服务端中的序列码 2、联系星云工作人员获取当前服务器的key.key文件，替换到星云的server目录下；3、启动server目录下的ThreadingTestServer.exe后会自动打开同级目录下的ThreadingTestServerFront.exe，看到自动弹出下面窗口后，表示连接正常。 1.3，星云测试客户端的配置 注：星云测试在线客户端的连接需要访问端口17262/17263.登陆之前需要保证网络连接不存在限制。打开客户端之前需要修改TTClient文件夹下的Server.cfg文件，配置localIP项为可以与服务端正常数据通信的本机IP地址。配置这个localIP的原因是，在客户端需要接收来自服务端传来的动态数据，配置本地的IP地址服务端才能把数据传到客户端中来。配置IP地址完成后双击运行TTClient/TT.exe文件进入星云测试客户端。选择文件->登录，输入星云测试服务端的IP地址以及自己的用户名和密码即可登录。如下图所示。 1.4，星云测试云报表平台服务启动 1、 运行星云测试TTWeb目录下的binredis-2.4.5-win32-win6432bit中的redis-server.exe2、运行星云测试TTWeb目录下的startTTwebserver.bat访问网页报表网页IP地址:3000 2，创建工程和版本并编译 1， 登录客户端2， 选中待插装的空版本，版本处于解锁状态（解锁状态：右键-解锁状态）3， javaForWindows目录下的Server.cfg配置文件，[SERVER] ip填写实际ip地址，修改[PROPERTY]字段，与客户端目录下的Server.cfg同步 4、修改javaForWindows目录下的ComplierPath.xml配置文件同一个版本下可添加多个子模块即proname，proname不能重复，一个子模块下可以配置多个工程路径ProName：子模块名称Project_path：测试程序源码文件路径Class_path：测试程序class文件路径注意：在进行编译插装的时候，编译插装的项目是edu-service-user，edu-web-boss这两个项目5、修改javaForWindows目录下tt_windows文件夹下Server.ini配置文件Ip设置为客户端的ip地址。6、在命令行运行autoCompiler.jar进行编译 jre\bin\java.exe -jar autoCompile.jar -e D:\J2EE_Enterprise_key_64bit0803\CompileToolsPkg\javaForWindows 注：-e后面的参数为ComplierPath.xml文件的目录7、在客户端查看数据,记得必须点击重新加载文件由于测试的时候需要运行我们插装后的代码（编译完成后会在java目录同层生成src-instru目录，src-instru目录即为编译插装后的源码）;具体操作：先将源码目录下未插装的java目录重命名为pre_java，再将编译插装生成的src-instru目录命名为java。并且插桩代码的运行需要我们的jar包，因此需要修改客户的pom.xml文件来引入我们的jar服务，加入到两个之间，加入的代码如下：systemPath需要按JavaParser-j2ee.jar和jeromq-0.3.0-SNAPSHOT.jar的绝对路径填写 <dependency> <groupId>com.zoa</groupId> <artifactId>JavaParser-ZMQ</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/JavaParser-J2EE.jar</systemPath> </dependency> <dependency> <groupId>com.zoa</groupId> <artifactId>jeromq</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/jeromq-0.3.0-SNAPSHOT.jar</systemPath></dependency> 在pom文件修改完成后即可打包发布 3，打包dubbo的工程例子 1 zookeeper环境搭建zk解压到指定目录下，解压后,将con文件夹下的zoo_sample.cfg拷贝一份,重命名为zoo.cfg，注意修改cfg的内容如下，根据自己的目录来修改：windows系统下会使用zkServer.cmd开启,所以在bin目录下找到zkServer.cmd,双击开启,这个是启动后的成功的图 打开以后就可以进行打包了，在eclipse打然后打包生产者和消费者(打包出来的是war包)，将打包好的war包分别放在不同端口的tomcat中。 生产者启动tomcat： 生产者在启动tomcat时，向注册中心注册自己提供的服务消费者启动tomcat： 消费者在启动时，向注册中心订阅自己所需的服务，注册中心返回生产者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。消费者将设置的标识通过一系列返回给生产者打包完成，为使函数覆盖率可视视图代码部分显示正常，需要手动修改源码路径：右键版本，点击修改源码路径，选择到pre_src目录即可。 4，编写测试用例 点击添加：启动测试用例 5，项目测试 1，设置标识 1,项目URL后面加teststars.jsp，访问teststars.jsp页面进行标识设置2,点击set标识进行设置，设置成功页面如下：注：为了区分测试，我们在设置的用户姓名与星云客户端当前登录用户一致，设置完成后页面显示是 消费者通过web页面设置标识 生产者：通过穿透将消费者设置的标识值穿透到生产者中页面点击登陆进就会有相应的测试数据传输过来（具体的展示见后面测试结果的第一个标题：示波器的展示），数据接收完以后点击停止，本条用例测试完毕 3， 生产者和消费者再客户端的覆盖率展示：消费者在客户端的展示： 生产者在客户端的展示： 三 测试结果 1，示波器波形展示 先选中测试用例，再点击开始后就可以进行相应的测试工作了，测试的时候示波器可以收到动态数据并以波形图的方式展示出来。注：采集的动态数据保存在服务端目录下的VersionData文件夹下 2，缺陷管理 为了让测式人员更好的对缺陷进行管理，采用测试用例、代码、BUG相关联方式，精准测试云平台使用了历史BUG追查功能，这使得在版本迭代过程中，同一个测试用例所有的BUG情况一目了然，避免了因人员变动或版本变动导致的相同的BUG的排查时间，以及重复提交未被解决的BUG。 图表 缺陷提交与管理 图表 bug信息一目了然 3，覆盖率 覆盖率可视化针对函数sc0、True、false 、both、Branch、C/DC 、MC/DC 7种覆盖率给出可视化展示下面针对每一种覆盖率展示界面给出说明：（以sc0为例）sc0为语句块覆盖，其颜色区分对象为基本语句块（包括隐含不可见语句块）其中绿色标示被覆盖的语句块。蓝色是未覆盖到的语句块。计算方法为：覆盖到块/应统计块 用红色的标出来的表示sc0覆盖率，函数列表右方为覆盖率的展示： 4，双向追溯 双向追溯是指通过运行测试用例，实现测试用例与被测源码间相互追溯。根据测试用、查看相关被测源码为正向追溯，根据被测源码查看相关测试用例为逆向追溯。在测试用例列表中选择测试用例，可以追溯到该测试用例的内容描述信息，在模块调用图中显示被测试到的函数；也可以在模块调用图中，点击相关的函数，也可以追溯到相关的测试用例。该追溯技术方便了用户查看和设计测试用例。 双向追溯功能可以运行的前提是，测试用例已经被运行过，并且示波器收到了波形采集到了动态数据。 1，正向追溯 正向追溯是指：将测试用例和海量的代码执行信息自动关联，可精确到函数级别及代码块级别；通过正向追溯可直接在代码级定位测试现场故障和缺陷逻辑，并提供最后运行的时序数据；通过正向追溯自动记录产生功能对应的详细设计实现，辅助软件解耦和架构分析。正向追溯的优势是：迅速定位缺陷对应的代码执行逻辑，帮助开发快速修复缺陷，可追踪难复现缺陷；精确、详尽的记录测试用例运行的情况，为精准软件测试提供大量原生分析性数据；可以进行事后的缺陷分析、追踪，辅助开发进行功能实现确认。生产者的正向追溯： 消费者的正向追溯：如图：点击测试用例追溯到这个用例运行过得函数，选中一个函数，追溯到这个函数运行过得控制流程图的逻辑分支 以下是正向追溯到代码和函数调用图： 2，反向追溯 反向追溯是指：分析代码关联的功能，为研发分析系统和进行一致性修改以及回归测试分析提供精确数据。反向追溯过程：点击需要查看的函数或函数中的某行代码，自动列出可以测试到该函数或者程序分支的测试用例生产者的反向追溯： 消费者的反向追溯： 选择函数追溯到运行过该函数的测试用例，查看该函数的控制流程图和代码点击代码，追溯到运行过该代码的测试用例 5，简易流程图的展示 前置条件：版本有数据，关联源码可在代码视图有显示源码，并且在简易控制流 程图的分支块有具体语句显示，有覆盖率数据，可在简易控制流程图显示当前覆盖到的块信息简易控制流程图功能，以语句块的形式清晰的展示函数内部的控制逻辑，界面上可以直观的看出控制流各节点的测试覆盖情况，在展示中，简易控制流程图还可以通过颜色对每个程序块进行覆盖率标识，在缩略图中整个模块的覆盖率非常直观。（背景色为绿色表示有测试用例覆盖到该块：以SC0覆盖为参考标准） 6，报表的展示 选择客户端所编译的项目和版本：显示所选取编译项目的一些基本信息，包括:项目指标信息、项目信息、版本信息、测试汇总信息、测试过程监控趋势图、测试设备组成和分布图、版本覆盖率汇总图、复杂度统计图项目汇总： 包含项目信息：项目的详情信息 版本信息：版本的详情信息 测试汇总信息：测试用例通过率：无BUG的测试用例 BUG累计：测试用例运行完毕后提交的BUG数 当前版本覆盖率(SC0)：(执行过可见段数/可见段数)*100%的比例 覆盖率增长：相比前一天的SC0增长差值 高复杂度预警函数个数：高复杂度的函数个数 测试用例列表：显示制作的测试用例的详细信息，包括测试用例的名称、创建时间、执行时间、关联函数、覆盖率占比、运行状态、测试人员等覆盖率按日增长曲线图： 覆盖率按日增长曲线图,让管理者更好的把握测试过程 测试漏洞列表： 在一个程序中，往往有成百上千的函数，这些函数有的是关联整个程序核心、有的则是开发人员弃而不用，但一直保留迟迟不肯删除的，针对这些大量的函数，“精准测试”采用通过静态、动态指标的综合分析，在大量的程序函数中，通过计算直接筛选潜在的高危的测试漏洞，通过报表给予展示。 通过复杂度和覆盖率进行计算 通过函数调用上下文和覆盖率进行计算
精准测试从某个层面来讲，是赋予了测试用例真正的生命力，传统的测试用例仅仅是一些只能够依赖人去理解和分析的文本文件而已，在计算机和算法层面则没有存在意义和价值。下图是精准测试的整体架构图： 大家首先可能会比较好奇，“用例魔方”的概念是怎么来的？测试用例魔方是在精准测试的设计、开发和商业实践中自然产生的功能集合的一个统称。当我们把精准测试的和用例分析相关的功能画成架构图形表示的时候，它自然而然地看起来就像魔方，所谓“魔”则是精准测试核心算法所赋予的超能力。上图是星云精准测试系统的总体结构图，“测试魔方”即分布在左上角区域。大家知道精准测试的核心技术是测试用例与代码的追溯关系的建立，而在此之上就可以构建测试魔方的核心功能区。如下： 所谓“方”实际上是代表测试用例的集合，每个测试用例用一个小方块标识，所有测试用例的集合用一个大方块。现在来看在精准测试架构下，“用例魔方”所能够提供的功能（对精准测试的底层技术不是很了解的话，可以预先温习下《精准测试框架白皮书》）。精准测试体系中，测试用例对应的代码逻辑都可以实现全自动的追溯和存储，因此测试用例就具备了进行深入分析的基础。在精准测试的用例魔方中，目前存在三个面（随着后续功能的增加，将增加分析的面），即回归测试用例选取、测试用例聚类分析、测试用最小化，同时辅之以智能缺陷定位技术。下面对“用例魔方”做详细的说明，选用的工具为星云精准测试平台ThreadingTest产品系列。 首先介绍回归测试用例选取。从魔方视图中可以看到回归用例选取（主要选取可能影响到的重点用例）。精准测试中所谓的回归测试和自动化回归有很大的差别，我们听的比较多的自动化测试中的回归其实是把自动化用例重新运行的意思，而精准测试中的回归测试是通过内部算法自动选取新版本修改后可能影响到的测试用例。通过回归测试用例选取，解决了新版本上线该对哪些用例进行测试和重点测试的问题，这也是敏捷开发中测试所面临的最大问题。下面是回归测试用例选取的原理图： 原理介绍： 测试用例A与测试用例B为在版本A中进行测试的用例，其绿圈中A1、A2、A3、B2…等为其测试用例所对应的运行中采集的函数信息。 在版本迭代过程中，版本B也对其测试用例A进行了测试，并添加了测试用例C，精准测试采集其对应的函数信息。 当版本C进行迭代发布时，精准测试根据测试用例A、B、C最后运行的版本所对应的函数信息与版本C的版本函数信息进行比较，根据变化差异进行回归优先级排序。 ① 测试用例A最后运行在版本B中，对应的函数信息为A1、A2、B1、A3，对比版本C中的函数无代码变化，计算回归优先级值为0。 ② 测试用例B因为在版本B中未运行，最后运行的版本为A，版本A的测试数据B1、B2、B3、C3和版本C中的函数比对，得出函数C3的代码有变化，计算回归优先级值为1。 ③ 测试用例C最后运行在B，对应的函数信息为C1、C2、C3、A3，和版本C中的函数比对，得出函数C3的代码有变化，函数C2进行了删除，计算回归优先级值为3。 ④ 结果进行回归优先级排序，得出测试用例C回归优先级最高优先值为3>测试用例B回归优先值为1>测试用例A，回归优先值0，不需要回归。 当新版本上线后，精准测试系统会自动给出本次发布波及到的测试用例列表以及收到波及的程度。如下图： 通常测试用例的分类都是人工根据功能组织进行硬性归类的，在精准测试体系中，用例魔方中的测试用例为聚类分析。由于测试用例都包含有对应的内部代码执行逻辑，执行路径直接可以通过代码块或者函数进行举例计算，例如一个程序总共有10个函数。 “用例魔方”中的聚类结果具有非常实用的价值，体现在以下几点： 1.通过用例聚类结果，可以从管理端审核测试执行的正确性。传统测试一般由人工执行，因此想确认测试用例是否本身执行有错误，或者是否按照预先设定的要求执行了，是非常困难的，这也是测试管理的成本一直很高的一个重要原因。通过对精准测试“用例魔方”的聚类结果分析，若两个功能迥异、本不应该分到一起的测试用例被分到了一组，那么产品经理或者项目管理者会非常容易识别出这里面存在测试用例的执行错误，并在产品发布的最后一环，及时处理。 2.通过“用例魔方”的测试用例聚类结果这一功能，可以发现缺陷分布的密集区域。因为聚类的依据是用例执行对应的代码路径差异信息，聚类结果充分而真实的体现了用例之间的空间感，结果非常有意义。缺陷的分布一般是有规律的：功能相近的用例如果有出现错误，那么同类型用例出错的概率也更大。所以当时间不充足的情况下，可以依据聚类结果，每个用例聚类簇随机选几个。如果没有bug，就可以放松对簇内其他用例的考察，如果发现了缺陷，那么其它簇内的用例也需要重点考察。 在企业大量应用自动化测试场景下，随着日积月累，产生了大量的、逻辑重复的测试用例。通过“用例魔方”的测试用例集最小化算法，可以把重复或者存在包含关系的用例从用例集中剔除出去。原理非常简单：假设两个用例，在代码覆盖上存在完全包含关系，那么被包含的用例就可以从用例集中剔除。算法所依据的数据依然是测试用例与代码的追溯关系技术数据。 “用例魔方”中另外一个精彩的功能是智能的缺陷定位技术，星云精准测试提供了3种计算公式。   通过智能缺陷定位，测试工程师仅需要标记用例从功能角度的执行状态（是否存在缺陷），再结合星云精准测试“用例魔方”自动记录的对应程序执行的代码频谱，就可以对缺陷进行代码级的精准定位。 1.源代码 简单分析第15行代码，当第十行y=y且x 2.创建7个测试用例test1、test2、test3………..test7并进行测试 ① test1输入为3 3 5输出为3，预期输出为3，符合预期，此用例记为通过 ② test2输入为1 2 3输出为2，预期输出为2，符合预期，此用例记为通过 ③ test3输入为3 2 1输出为2，预期输出为2，符合预期，此用例记为通过 ④ test4输入为5 5 5输出为5，预期输出为5，符合预期，此用例记为通过 ⑤ test5输入为5 3 4输出为4，预期输出为4，符合预期，此用例记为通过 ⑥ test6输入为2 1 3输出为1，预期输出为2，不符合预期，此用例记为未通过 ⑦ test7输入为3 2 4输出为2，预期输出为3，不符合预期，此用例记为未通过 3.针对test6、test7提交缺陷，表明test6与test7输出与预期不符 4.打开缺陷分析界面进行分析 5.可疑度算法包括如下三种，可自主选择 其中aep表示通过且覆盖到该块的测试用例的个数、anp表示通过且未覆盖到该块的测试用例的个数、aef表示未通过且覆盖到该块的测试用例的个数、anf表示未通过且覆盖到该块的测试用例的个数。结果表示该块的可疑度。 6.代码可视化查看位置 关联源码之后可根据代码可视化定位第十二块位置，根据实际分析可得第十二块确实为缺陷语句，分析过程见第一步。 （大家如果感兴趣可以到星云测试的官网上www.teststars.cc 试用。） 精准测试的精髓在于通过专用测试软件实现表层功能和底层代码的关联，并且获取成本很低。它在测试用例执行的过程中，通过软件示波器以透明方式自动获取两者的关联关系。通过精准测试系统，使针对用例的深入分析“用例魔方”成为可能。目前精准测试的核心用例分析算法正在持续增强，“用例魔方”的软件研发辅助分析功能，为软件测试的智能化、专业化成长，带来曙光和方向。
微服务是Devops场景下热门的开发框架，在大型项目中被广泛采用。它把一个大型的单个应用程序和服务拆分为数十个的支持微服务，独立部署、互相隔离，通过扩展组件来处理功能瓶颈问题，比传统的应用程序更能有效利用计算资源。微服务之间无需关心对方的模型，它通过事先约定好的接口进行数据流转，使业务可以高效响应市场变化。但微服务一个明显的表象就是随着服务的增多，传统的测试模式受到很大制约，无法有效进行下去，威胁到整体系统质量。所有J2EE代码层白盒采集工具都无法区分覆盖和具体功能的对应关系，只能以后台模式“笼统“的采集一个阶段的总的覆盖，无法满足对于Devops下对于故障定位、深度测试分析以及敏捷发布算法的要求。 星云测试（www.teststars.cc）发布分布式微服务精准测试解决方案，是目前市场上唯一可达到在复杂分布式系统中，跨多个服务器进行代码白盒级分析、实现请求分布式追踪的测试平台。其中产品内的穿透模块，可以支持各种主流微服务通信架构。例如httpclient，springcloud微服务架构、阿里dubbo微服务架构，以及消息队列，将并发访问场景下跨多个服务多组代码逻辑分离并重建追踪出来。实现业务逻辑的代码在开发层面通过微服务离散后，在测试阶段则可以反向复原整个完整代码执行视图。精准测试里面的穿线概念（Threadingtest）增加了第三层含义，即针对的分布式服务的穿透能力。 微服务场景下，一个完整请求会跨多个计算（服务）节点，而对于以节点为剖面的各种测试和监控手段都变得不那么直接和有效。一个请求链路的失效和性能故障等问题，从一个计算节点剖面去分析是很困难的，因为在一个计算节点剖面上的数据是混合型数据，而无法区分这里面的数据来自于那个请求。原始的方法无法将一个调用链路上的所有信息完整的重新刻画出来。业界流行的APM技术可以某种程度实现这种调用链路分析，该项技术主要用于监控，体现的数据是组件级的，而且为了性能考虑还经常抽取样 本，无法达到测试要求的代码级的分析。 微服务采用的“分而治之”的策略，而精准测试对于微服务的测试和运营管控上采用的是“概览全局”的策略。精准测试在编译阶段，重新将微服务所有模块视为一个完整项目，统一编译和插装，经过插装后的代码重新部署到原有节点上。在微服务的启动过程中附加上分布式追踪所需要的agent启动，即可完成微服务场景下达到测试用例级的代码全调用路径分析。由于微服务有多个程序模块，星云测试平台支持模块级增量编译模式，即每次编译替换某一个模块就可以生成一个新的版本，而无需将所有微服务模块全新编译。 穿透和分布式追踪的原理，这里要重点将以下星云测试JavaEE应用服务器agent的能力。agent提供了一个虚拟jsp的技术，通过agent启动的被测应用，都附加了一个虚拟jsp，地址类似于http://www.appundertest.com/teststars.jsp。 访问这个页面可以用来指本机的用户，一般这个设置和精准测试示波器的登录用户需要一致。设置完成后，对被测试应用的请求将附加上一个用户标识的cookie信息，这个信息会在微服务的多层架构中一直携带和穿透。例如从浏览器发起的一个带着用户标识信息的请求，到了应用服务的处理线程中，这个线程执行的所有代码将附加上这个用户信息，如果应用在向后调用其他的节点的服务，则这个用户信息会继续向后传递，直到最后的执行节点。由于每个节点的代码均有精准测试系统插装的代码，会自动的向用户请求发起端的示波器回馈数据，那么就可以实现将整个调用链路上的代码逻辑发送给示波器。示波器收到数据后，将动态数据和代码编译阶段的程序静态数据结合起来，即可展示全链路的程序调用路径信息。从另外角度，当微服务系统有多个请求同时并行的时候，那么每个示波器收到的是自己对应的请求代码的全链路执行情况，而其他示波器用户和其他普通用户的数据则不会被收录进来。 上图是一个spring cloud微服务架构下两个节点的调用图。当从第一层入口组件访问后，入口组件向后调用下一层节点的时候，后一层节点的运行线程自动取到了前一层节点的用户信息，并且加入到了第二层节点的运行线程控件。这样，通过精准测试示波器（登录用户标识和请求标识一致）就可以收到两个节点的数据。实现多个用户同时访问分布式应用的时候，不同用户出发的数据自动分离，路由到对应的示波器，最终对应到用例上。
1、微服务简介 微服务英文名称Microservice，Microservice架构模式就是将整个Web应用组织为一系列小的Web服务。这些小的Web服务可以独立地编译及部署，并通过各自暴露的API接口相互通讯。它们彼此相互协作，作为一个整体为用户提供功能，却可以独立地运行。 2、Spring Cloud项目简介 Spring Cloud是基于Spring Boot的一整套实现微服务的框架。提供了微服务开发所需的配置管理、服务发现、断路器、只能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。 3、前期准备工作 3.1配置jdk 3.2配置tomcat 3.3配置maven 注：本文中Jetbrain的IDEA工具是集成了Maven的，如下图所示： 如若做修改，请按本地maven实际路径填写。 4、Spring Cloud的环境 Spring Cloud源码 IntelliJ IDEA（以下简称“idea”） MySQL JDK8 Tomcat7 Maven 4.1安装环境 注：IntelliJ IDEA和JDK的安装和安装包就用自己现有的就可以，星云测试将提供MySQL和Nodejs的安装包，但必须前提是用户自己的本机上不存在安装的MySQL和Nodejs。 4.1.1脚本一键安装mysql和nodejs 1、 打开TT_Soft文件夹 2、以管理员身份运行TeststarsSoftInstall.exe 3、等待自动安装完成，关闭窗口 4、使用net start mysql 命令启动MySQL服务 5、使用node –v查看node版本 5、配置Spring Cloud 5.1 idea创建eureka服务注册中心 以下简称“8000”项目。新建项目： idea新建spring boot项目，选择Spring Initializr，也可以在https://start.spring.io上创建再导入本地： 修改group等相关信息： 注意右上角的spring boot的版本选择： 直接点击完成即可： 到此，一个springboot项目就完成了。接下来要做的是配置一个eureka服务注册中心。此项目的pom.xml添加以下内容： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> 启动代码中添加@EnableEurekaServer注解和import...，如下所示： package com.teststars.springclouddemo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer; @EnableEurekaServer @SpringBootApplication public class SpringcloudDemoApplication { public static void main(String[] args) { SpringApplication.run(SpringcloudDemoApplication.class, args); } } 修改application.properties（加eureka.client.register-with-eureka=false和eureka.client.fetch-registry=false意思是不让服务中心注册自己）： server.port=8000 eureka.instance.hostname=localhost eureka.client.register-with-eureka=false eureka.client.fetch-registry=false eureka.client.service-url.defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ 启动该eureka server： 看到下面的LOG表明Eureka服务端启动成功： 打开谷歌浏览器（因IDEA中的默认设置），访问https://localhsot:8000/可看到微服务的查看面板： 至此，服务注册中心已配置完成，接下来进行服务的注册操作。 5.2 idea创建服务提供者 以下简称“8001”项目。 创建一个Eureka-Client客户端也就是服务提供者客户端在向注册中心会提供一些元数据，例如主机和端口，URL，主页等。Eureka server从每个client实例接收心跳消息。如果心跳超时，则通常将该实例从注册server中删除。 按照上面的创建方式创建项目springcloud-provider-demo： 启动代码中添加@EnableDiscoveryClient和import...，如下所示： package com.teststars.springcloudproviderdemo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.client.discovery.EnableDiscoveryClient; @EnableDiscoveryClient @SpringBootApplication public class SpringcloudProviderDemoApplication { public static void main(String[] args) { SpringApplication.run(SpringcloudProviderDemoApplication.class, args); } } 修改application.properties： server.port=8001 spring.application.name=springcloud-server eureka.client.service-url.defaultZone: http://localhost:8000/eureka/ 编写一个简单的controller。注意编写的controller一定要在启动类目录级别或下层。不然不会加载。项目启动类的同级目录下新建包：controller，添加类：HelloWorld，如下所示： package com.teststars.springcloudproviderdemo.controller; import org.springframework.web.bind.annotation.*; @RestController public class HelloWorld { @GetMapping("/test/{id}") public String test(@PathVariable String id){ return "hello"+id.toString(); } } 启动项目SpringcloudProviderDemoApplication； 在浏览器中刷新界面：https://localhsot:8000/ 查看Eureka信息面板服务信息，可看到已显示存在一个8001的服务： 点击图中绿色字体部分，显示如下图： 8001接口后加参数/test/test访问，注：test可为任意字符，显示如下图所示： 5.3 idea创建消费者 以下简称“8002”项目。 以下是在https://start.spring.io上创建再导入idea中的方式：  pom.xml添加以下内容： <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-ribbon</artifactId> </dependency> 修改application.properties： server.port=8002 spring.application.name=springcloud-customer eureka.client.service-url.defaultZone: http://localhost:8000/eureka/ 启动代码中添加@EnableDiscoveryClient，并加入RestTemplate的bean，RestTemplate是spring用来操作rest资源的类，使用了模板模式。同时注意注解@LoadBalanced，只需要这个注解就可以为RestTemplate整合ribbon，从而实现负载均衡。而eureka和ribbon配合使用时会将服务名自动映射成微服务的网络地址。使得可伸缩性增强。如下所示： package com.teststars.springcloudcustomerdemo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.client.discovery.EnableDiscoveryClient; import org.springframework.cloud.client.loadbalancer.LoadBalanced; import org.springframework.context.annotation.Bean; import org.springframework.web.client.RestTemplate; @EnableDiscoveryClient @SpringBootApplication public class SpringcloudCustomerDemoApplication { public static void main(String[] args) { SpringApplication.run(SpringcloudCustomerDemoApplication.class, args); } @Bean @LoadBalanced public RestTemplate restTemplate(){ return new RestTemplate(); } } 编写controller，这里restTemplate.getForObject中的url换成http://localhost:8001/test也是可以的，但是这样的话耦合度是比较高的，如果服务提供者的地址发生了变化那这个消费者就不能正常运行了。由于集成了ribbon，所以这里可以换成服务名。 项目启动类的同级目录下新建包：controller，添加类：Test，如下所示： package com.teststars.springcloudcustomerdemo.controller; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RestController; import org.springframework.web.client.RestTemplate; @RestController public class Test { @Autowired private RestTemplate restTemplate; @GetMapping("/test/{id}") public String test(@PathVariable String id){ return this.restTemplate.getForObject("http://SPRINGCLOUD-SERVER/test/"+id,String.class); } } 启动项目SpringcloudCustomerDemoApplication； 在浏览器中的刷新页面：https://localhsot:8000/ 查看Eureka信息面板服务信息可看到多了一个服务，如下图8002绿色字体部分所示： 点击图中绿色字体部分： 添加参数/test/aaa，注：aaa可为任意字符： 6、测试项目6.1下载工具及工具配置6.1.1从官网上下载星云测试工具：http://www.teststars.cc/ 下载以后进行配置。6.1.2星云测试服务端的配置TTLangage.config配置项说明： 1、 运行下的星云测试server目录中ThreadingTestServer.exe，在右下的图表中点注册信息，查看其时间，星云测试有两个月的体验，若超过两个月，发生KEY过期，请联系星云测试的工作人员，并提交服务端中的序列码。 2、联系星云工作人员获取当前服务器的key.key文件，替换到星云的server目录下； 3、启动server目录下的ThreadingTestServer.exe后会自动打开同级目录下的ThreadingTestServerFront.exe，看到自动弹出下面窗口后，表示连接正常。  6.1.3星云测试客户端的配置注：星云测试在线客户端的连接需要访问端口17262/17263.登陆之前需要保证网络连接不存在限制。打开客户端之前需要修改TTClient文件夹下的Server.cfg文件，配置localIP项为可以与服务端正常数据通信的本机IP地址。配置localIP原因是：在客户端需要接收来自服务端传来的动态数据，配置本地的IP地址服务端才能把数据传到客户端中。 配置IP地址完成后双击运行TTClientTT.exe文件进入星云测试客户端。选择文件->登录，输入星云测试服务端的IP地址以及自己的用户名和密码即可登录。如下图所示： 6.1.4星云测试云报表平台服务启动 1、运行星云测试TTWeb目录下的binredis-2.4.5-win32-win6432bit中的redis-server.exe： 2、运行星云测试TTWeb目录下的startTTwebserver.bat： 访问网页报表网页IP地址:3000 6.2创建工程和版本并编译 1、登录客户端 2、选中待插装的空版本，版本处于解锁状态（解锁状态：右键-解锁状态） 3、修改javaForWindows目录下的Server.cfg配置文件，[SERVER] ip填写实际ip地址，修改[PROPERTY]字段，与客户端目录下的Server.cfg同步： 4、修改javaForWindows目录下的ComplierPath.xml配置文件：同一个版本下可添加多个子模块即proname，proname不能重复，一个子模块下可以配置多个工程路径。 proName：子模块名称 project_path：测试程序源码文件路径 class_path：测试程序class文件路径 注：因为项目8002关联着8001，所以这里需要编译8001和8002两个模块。如下图： 5、修改javaForWindows目录下tt_windows文件夹下Server.ini配置文件，ip设置为客户端所在的ip地址： 6、在javaForWindows文件根目录，打开命令行运行autoCompiler.jar进行编译：jrebinjava.exe -jar autoCompile.jar –e D:J2EE_Enterprise_key_64bit0814CompileToolsPkgjavaForWindows 注：-e后面的参数为ComplierPath.xml文件的目录。编译成功如下图所示： 7、在客户端查看数据，选中之前新建的空版本，右键点击重新加载版本数据。 由于测试的时候需要运行插装后的代码（编译完成后会在java目录同层生成src-instru目录，src-instru目录即为编译插装后的源码）;具体操作：先将源码目录下未插装的java目录重命名为pre_java，再将编译插装生成的src-instru目录命名为java。为使函数覆盖率可视视图代码部分显示正常，需要手动修改源码路径：右键版本，点击修改源码路径，选择到pre_java目录即可。6.3测试前准备 6.3.1添加数据传输配置文件 数据传输配置文件是保证运行的数据可以回传到星云服务器的。配置方法是在具体的客户测试环境下的usr/local/bin文件夹下新建配置文件config.cfg 文件内容如下： state=1IP=（IP值写星云测试服务端IP，注意要大写）（如果发布环境是windows环境，需要在C盘根目录下配置上述文件） 6.3.2 agent启动项目 使用星云测试提供的agent包启动项目有以下两种方式：6.3.2.1 idea开发工具的项目启动项中添加agent参数 注：8001项目和8002项目中均需要作如下配置： VM options一项添加如下配置，jar文件按星云测试提供的agent解压缩文件的绝对路径填写： 修改点击Apply、OK；插桩代码的运行需要添加星云测试提供的jar包，需要修改pom.xml文件来引入jar，加入到两个之间，加入的代码如下： systemPath按JavaParser-j2ee.jar和jeromq-0.3.0-SNAPSHOT.jar的绝对路径填写： <dependency> <groupId>com.zoa</groupId> <artifactId>JavaParser-ZMQ</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>D:\J2EE_Enterprise_key_64bit0814\client\MQ\JavaParser-j2ee.jar</systemPath> </dependency> <dependency> <groupId>com.zoa</groupId> <artifactId>jeromq</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>D:\J2EE_Enterprise_key_64bit0814\client\MQ\jeromq-0.3.0-SNAPSHOT.jar</systemPath></dependency> 8001和8002项目做完以上操作修改后，idea中依次运行8000、8001、8002项目，启动项目成功如下图：  6.3.2.2 jar包的启动命令中添加agent参数 首先正常启动8000项目； 插桩代码的运行需要添加星云测试提供的jar包： idea中直接引入星云测试提供的jar包，操作如下图所示：   引入jar包后，在idea中对8001和8002项目进行打包：clean->package： 其次分别打开两个DOS窗口，输入以下带有agent参数的命令，启动8001和8002项目： java -javaagent:D:0823zoa-agent-1.6.2zoa-bootstrap-1.6.2.jar -jar D:springcloud-provider-demospringcloud-provider-demotargetspringcloud-provider-demo-0.0.1-SNAPSHOT.jar java -javaagent:D:0823zoa-agent-1.6.2zoa-bootstrap-1.6.2.jar -jar D:springcloud-customer-demotargetspringcloud-customer-demo-0.0.1-SNAPSHOT.jar D:0823zoa-agent-1.6.2zoa-bootstrap-1.6.2.jar =agent路径；D:springcloud-provider-demospringcloud-provider-demotargetspringcloud-provider-demo-0.0.1-SNAPSHOT.jar =项目路径； 出现以下界面表示项目启动成功： 6.3.3设置cookie 打开谷歌浏览器（因idea中默认设置的是谷歌浏览器），输入网址：http://localhost:8000打开eureka服务注册中心；可以看到已经面板上已显示8001和8002： 点击8002对应的绿色字体部分进入8002对应的界面： 1、在项目URL后加参数teststars.jsp，访问页面进行cookie设置： 2、点击setcookie进行设置，设置成功页面如下： 注：为了区分测试，设置的用户名与星云客户端当前登录用户名要保持一致。查看控制台打印信息可知，username设置成功： 7、测试结果7.1示波器波形展示先选中测试用例，再点击开始后就可以进行相应的测试工作了，测试的时候示波器可以收到动态数据并以波形图的方式展示出来。 刷新数据，因为8002关联着8001，所以这里可以看到，测试8002，8001也被覆盖到： 上图是一个spring cloud微服务架构下两个节点的调用图，当从第一层入口组件访问后，入口组件向后调用下一层节点的时候，后一层节点的运行线程自动取到了前一层节点的用户信息，并且加入到了第二层节点的运行线程控件，这样通过精准测试示波器（登录用户标识和请求标识一致）就可以收到两个节点的数据。并且实现在多个用户同时访问分布式应用得时候，不同用户出发的数据会自动分离并路由到对应的示波器并最终对应到用例上。
配置测试Guns Guns简介 Guns是一个近几年来基于SpringBoot的开源便利且较新的JavaEE项目开发框架，它整合了springmvc + shiro + mybatis-plus + beetl + flowable多项开源技术，致力于让Java后台开发更简洁快速 一，Guns的环境Guns 源码 Maven Eclipse-Photon JDK8 MySQL 安装环境 注：Eclipse和JDK的安装和安装包就用自己现有的就可以，星云测试将提供MySQL和Nodejs的安装包，但必须前提是用户自己的本机上不存在安装的MySQL和Nodejs脚本安装mysql和nodejs（一键安装） 1、解压星云提供TT_Soft安装包（例如D盘根目录，mysql和node的安装路径） 2、打开TT_Soft文件夹 3、以管理员身份运行TeststarsSoftInstall.exe 4、等待自动安装完成，窗口提示mysql初始化完成，关闭窗口 5、注销或重启电脑 6、使用net start mysql 命令启动MySQL服务 7、使用node –v查看node版本 二，下载guns代码 下载地址：https://gitee.com/naan1993/guns/ 将下载下来的代码进行解压 三，配置Guns 一， Eclipse导入Guns项目 点击“Import...”后会出现如下图的导入对话框，请选择Maven选项中的“Existing Maven Projects”。 之后，点击“Next”按钮后，按如下图的①、②和③的操作选中之前解压的Guns-master目录 导入成功后如下图所示，可看见guns-admin、guns-core、guns-generator、guns-parent和guns-rest五个项目。成功将guns项目导入eclipse guns-admin是Guns管理系统guns-generator是maven代码的生成guns-core是其他模块提炼出来的公共的代码guns-parent是maven的的父模块，父模块的作用就是管理其它的子模块，可以把我们依赖都提到parent，并且对我们依赖的版本做一个统一的维护。gun-rest本意是些一个app 服务端，提供rest API服务，权限和md5加密 二，配置Guns项目的数据库 在导入成功的“guns-admin”项目中，我们能够找到“sql”目录下的guns.sql文件，如下图所示，将打开后的guns.sql中所有的内容复制一下。 新建数据库名为guns，点击guns数据库中的“查询”后，将上面复制的sql直接运行，出现下面这些表即为正确 三，修改Guns项目的配置文件并运行 在Eclipse中，找到guns-admin项目中的“application.yml”文件，它在src/main/resource路径下，并将该文件中所有的“username和password”部分的password默认的root值改为读者安装MySQL时所设置的密码，该步骤具体如下图所示： 修改完此配置文件后，我们就可以开始运行guns项目了，请找到guns-admin项目中的src/main/java路径下的，com.style.guns目录中的GunsApplication.java文件，它是guns项目的主程序文件，点击运行成功运行后，打开浏览器，在浏览器的地址栏中输入：http://localhost:8080 点击登录后，可进入如下图界面： Guns已成功部署并运行成功。 四，测试项目 1， 下载工具及工具配置1， 从官网上下载星云测试工具：http://www.teststars.cc/ 下载以后进行配置： 2，星云测试服务端的配置 TTLangage.config配置项说明： 1、 运行下的星云测试server目录中ThreadingTestServer.exe，在右下的图表中点注册信息，查看其时间，星云测试有两个月的体验，若是超过两个月，发生KEY过期，请联系星云测试的工作人员，并提交服务端中的序列码 2、联系星云工作人员获取当前服务器的key.key文件，替换到星云的server目录下； 3、启动server目录下的ThreadingTestServer.exe后会自动打开同级目录下的ThreadingTestServerFront.exe，看到自动弹出下面窗口后，表示连接正常。 3，星云测试客户端的配置 注：星云测试在线客户端的连接需要访问端口17262/17263.登陆之前需要保证网络连接不存在限制。 打开客户端之前需要修改TTClient文件夹下的Server.cfg文件，配置localIP项为可以与服务端正常数据通信的本机IP地址。配置这个localIP的原因是，在客户端需要接收来自服务端传来的动态数据，配置本地的IP地址服务端才能把数据传到客户端中来。配置IP地址完成后双击运行TTClient/TT.exe文件进入星云测试客户端。选择文件->登录，输入星云测试服务端的IP地址以及自己的用户名和密码即可登录。如下图所示。 4，星云测试云报表平台服务启动 1、 运行星云测试TTWeb目录下的binredis-2.4.5-win32-win6432bit中的redis-server.exe 2、运行星云测试TTWeb目录下的startTTwebserver.bat 访问网页报表网页IP地址:30002，创建工程和版本并编译 1， 登录客户端 2， 选中待插装的空版本，版本处于解锁状态（解锁状态：右键-解锁状态） 3， javaForWindows目录下的Server.cfg配置文件，[SERVER] ip填写实际ip地址，修改[PROPERTY]字段，与客户端目录下的Server.cfg同步 4、修改javaForWindows目录下的ComplierPath.xml配置文件 同一个版本下可添加多个子模块即proname，proname不能重复，一个子模块下可以配置多个工程路径ProName：子模块名称Project_path：测试程序源码文件路径Class_path：测试程序class文件路径因为项目是四个子项目，所以，必须得有四个模块，如下图： 5、修改javaForWindows目录下tt_windows文件夹下Server.ini配置文件Ip设置为客户端的ip地址。 6、在命令行运行autoCompiler.jar进行编译 jrebinjava.exe -jar autoCompile.jar -e D:J2EE_Enterprise_key_64bit0803CompileToolsPkgjavaForWindows注：-e后面的参数为ComplierPath.xml文件的目录 7、在客户端查看数据,记得必须点击重新加载文件 由于测试的时候需要运行我们插装后的代码（编译完成后会在java目录同层生成src-instru目录，src-instru目录即为编译插装后的源码）;具体操作：先将源码目录下未插装的java目录重命名为pre_java，再将编译插装生成的src-instru目录命名为java。 并且插桩代码的运行需要我们的jar包，因此需要修改客户的pom.xml文件来引入我们的jar服务，加入到两个之间，加入的代码如下：systemPath需要按JavaParser-j2ee.jar和jeromq-0.3.0-SNAPSHOT.jar的绝对路径填写 <dependency> <groupId>com.zoa</groupId> <artifactId>JavaParser-ZMQ</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/JavaParser-J2EE.jar</systemPath> </dependency> <dependency> <groupId>com.zoa</groupId> <artifactId>jeromq</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/jeromq-0.3.0-SNAPSHOT.jar</systemPath> </dependency> 在pom文件修改完成后即可打包发布 编译以后打包成jar包（具体的打包方法参考6，运行项目） 打包完成，为使函数覆盖率可视视图代码部分显示正常，需要手动修改源码路径：右键版本，点击修改源码路径，选择到pre_java目录即可。 3，测试前准备 1、添加数据传输配置文件 数据传输配置文件是保证运行的数据可以回传到星云服务器的。配置方法是在具体的客户测试环境下的usr/local/bin文件夹下新建配置文件config.cfg 文件内容如下：state=1IP=（IP值写星云测试服务端IP，注意要大写）（如果发布环境是windows环境，需要在C盘根目录下配置上述文件） 2，agent启动项目cmd输入命令：java -javaagent:E:zoa-agent-1.6.2zoa-agent-1.6.2.jar -jar G: naan1993-guns-masterguns-admintarget guns-admin-1.0.0.jar E:zoa-agent-1.6.2zoa-agent-1.6.2.jar =agent路径G: naan1993-guns-masterguns-admintarget guns-admin-1.0.0.jar =项目路径出现这样的界面表示运行成功： 3，设置cookie 1,项目URL后面加teststars.jsp，访问teststars.jsp页面进行cookie设置 2,点击setcookie进行设置，设置成功页面如下： 注：为了区分测试，我们在设置的用户姓名与星云客户端当前登录用户一致， 4，星云测试云报表平台服务启动 １、 运行星云测试TTWeb目录下的binredis-2.4.5-win32-win6432bit中的redis-server.exe 2、运行星云测试TTWeb目录下的startTTwebserver.bat  访问网页报表网页IP地址:3000 4，编写测试用例 点击添加：  5，项目测试 访问地址：http://localhost:8080/login  页面登陆进去以后，假如测试内容管理的文章管理的测试用例，则选择内容管理的文章管理的用例，点击开始，在页面上点击内容管理的文章管理，就会有相应的测试数据传输过来（具体的展示见后面测试结果的第一个标题：示波器的展示），数据接收完以后点击停止，本条用例测试完毕 五，测试结果 1，示波器波形展示 先选中测试用例，再点击开始后就可以进行相应的测试工作了，测试的时候示波器可以收到动态数据并以波形图的方式展示出来。 注：采集的动态数据保存在服务端目录下的VersionData文件夹下，对应版本的动态数据注：采集的动态数据保存在服务端目录下的VersionData文件夹下，对应版本的动态数据保存在相应的版本号目录下（版本号可在数据库management表的version表中查看） 2，缺陷管理 为了让测式人员更好的对缺陷进行管理，采用测试用例、代码、BUG相关联方式，精准测试云平台使用了历史BUG追查功能，这使得在版本迭代过程中，同一个测试用例所有的BUG情况一目了然，避免了因人员变动或版本变动导致的相同的BUG的排查时间，以及重复提交未被解决的BUG。  图表 bug信息一目了然 3，覆盖率 覆盖率可视化针对函数sc0、True、false 、both、Branch、C/DC 、MC/DC 7种覆盖率给出可视化展示下面针对每一种覆盖率展示界面给出说明：（以sc0为例）sc0为语句块覆盖，其颜色区分对象为基本语句块（包括隐含不可见语句块）其中绿色标示被覆盖的语句块。蓝色是未覆盖到的语句块。计算方法为：覆盖到块/应统计块 用红色的标出来的表示sc0覆盖率，函数列表右方为覆盖率的展示： 4，双向追溯 双向追溯是指通过运行测试用例，实现测试用例与被测源码间相互追溯。根据测试用、查看相关被测源码为正向追溯，根据被测源码查看相关测试用例为逆向追溯。在测试用例列表中选择测试用例，可以追溯到该测试用例的内容描述信息，在模块调用图中显示被测试到的函数；也可以在模块调用图中，点击相关的函数，也可以追溯到相关的测试用例。该追溯技术方便了用户查看和设计测试用例。 双向追溯功能可以运行的前提是，测试用例已经被运行过，并且示波器收到了波形采集到了动态数据。 1，正向追溯 正向追溯是指：将测试用例和海量的代码执行信息自动关联，可精确到函数级别及代码块级别；通过正向追溯可直接在代码级定位测试现场故障和缺陷逻辑，并提供最后运行的时序数据；通过正向追溯自动记录产生功能对应的详细设计实现，辅助软件解耦和架构分析。正向追溯的优势是：迅速定位缺陷对应的代码执行逻辑，帮助开发快速修复缺陷，可追踪难复现缺陷；精确、详尽的记录测试用例运行的情况，为精准软件测试提供大量原生分析性数据；可以进行事后的缺陷分析、追踪，辅助开发进行功能实现确认。 如图：点击测试用例追溯到这个成而是用例运行过得函数，选中一个函数，追溯到这个函数运行过得控制流程图的逻辑分支以下是正向追溯到代码和函数调用图： 2，反向追溯 反向追溯是指：分析代码关联的功能，为研发分析系统和进行一致性修改以及回归测试分析提供精确数据。 反向追溯过程：点击需要查看的函数或函数中的某行代码，自动列出可以测试到该函数或者程序分支的测试用例 选择函数追溯到运行过该函数的测试用例，查看该函数的控制流程图和代码 点击代码，追溯到运行过该代码的测试用例 5，简易流程图的展示 前置条件：版本有数据，关联源码可在代码视图有显示源码，并且在简易控制流程图的分支块有具体语句显示，有覆盖率数据，可在简易控制流程图显示当前覆盖到的块信息简易控制流程图功能，以语句块的形式清晰的展示函数内部的控制逻辑，界面上可以直观的看出控制流各节点的测试覆盖情况，在展示中，简易控制流程图还可以通过颜色对每个程序块进行覆盖率标识，在缩略图中整个模块的覆盖率非常直观。（背景色为绿色表示有测试用例覆盖到该块：以SC0覆盖为参考标准） 6，报表的展示选择客户端所编译的项目和版本：显示所选取编译项目的一些基本信息，包括:项目指标信息、项目信息、版本信息、测试汇总信息、测试过程监控趋势图、测试设备组成和分布图、版本覆盖率汇总图、复杂度统计图项目汇总： 包含项目信息：项目的详情信息 版本信息：版本的详情信息 测试汇总信息：测试用例通过率：无BUG的测试用例 BUG累计：测试用例运行完毕后提交的BUG数 当前版本覆盖率(SC0)：(执行过可见段数/可见段数)*100%的比例 覆盖率增长：相比前一天的SC0增长差值 高复杂度预警函数个数：高复杂度的函数个数 测试用例列表： 显示制作的测试用例的详细信息，包括测试用例的名称、创建时间、执行时间、关联函数、覆盖率占比、运行状态、测试人员等 覆盖率按日增长曲线图： 覆盖率按日增长曲线图,让管理者更好的把握测试过程 测试漏洞列表： 在一个程序中，往往有成百上千的函数，这些函数有的是关联整个程序核心、有的则是开发人员弃而不用，但一直保留迟迟不肯删除的，针对这些大量的函数，“精准测试”采用通过静态、动态指标的综合分析，在大量的程序函数中，通过计算直接筛选潜在的高危的测试漏洞，通过报表给予展示。 通过复杂度和覆盖率进行计算 通过函数调用上下文和覆盖率进行计算
伴随着软件规模的扩大和软件快速迭代的双重业务加速要求，软件质量控制的压力也越来越明显。但黑盒测试的无力感和白盒测试的高复杂度，让软件测试工程师和管理者都非常郁闷，多样化的自动化测试工具也解决不了根本性的问题。目前正在业内流行的精准测试技术，从企业级应用的反馈来看，它最为主要的三个技术特性，使企业在软件质量改进方面，突破了原有的天花板。1、 测试用例与代码的双向追溯技术：使开发和测试过程可视化，达到软件与团队管理的数据化交流，不再流于形式和口头交流；灰盒的透明运行模式，不改变传统企业流程，却能够将功能测试的数据映射到代码层面进行精准分析。2、 延展测试数据的应用价值：精准测试在运行中会产生大量的数据，基于这些数据可以让测试过程的价值拓展到整个研发体系，例如通过深度测试数据直接进行智能缺陷定位，通过逆向追溯帮助开发分析进行代码一致性修改等。3、 通过智能算法全面支持敏捷：全自动的智能回归用例选取、用例聚类分析、测试漏洞分析，累计覆盖率等技术全面支持敏捷场景下的质量保证。 本文将重点分析精准测试在研发体系中应用后的整体运行效率和质量改进分析。另本文分析数据对应的标的产品是星云测试的ThreadingTest产品，目前也是精准功能最全面、商用化程度最高的精准测试产品（读者可提前阅读精准测试框架白皮书以及到体验精准测试产品，熟悉精准测试的整体功能）。精准测试运行效率很高。它采用的技术路线为系统级灰盒技术范畴，因此精准测试的运行过程依然是黑盒，不直接改变用例的运行方法及团队成员构成，上手比较快。它的数据采集是基于软件测试示波器全自动采集，用于标记采集数据和用例的映射关系，对原有测试的运行效率干扰极小，实际运行分析额外附加工作量在2%以下。精准测试必要的插装过程无需人工干预，实施成本也是一次性的。 下图是精准测试的运行效率图： 传统意义上的黑盒测试方法一般在覆盖率进入到40-50区间以后，会逐步开始产生较大运行瓶颈，测试专业上形象的称之为杀虫剂效应。而黑盒的瓶颈点又恰恰是精准测试的发力点。精准测试可以关联到代码看到语句块，分支，条件等的覆盖率，也可以根据精准测试提供的各种彩色分析视图确定漏测点。因此不管被测系统有多复杂，精准测试的运行效率均呈线性45度角稳步上升。从上图可以看出，越过瓶颈点后的中等覆盖率水平，精准测试所使用的时间仅仅是传统黑盒测试的一半，因此成本投入也将是普通黑盒测试的一半。这一点对于企业来讲不仅仅是大幅度提升了测试的工作效率、加快了产品发布时间，同时节约了大量的人力成本投入。 精准测试的核心技术要点是测试用例与代码的追溯技术。这项技术简单来说就是当功能执行完成以后对应的整体代码执行情况就会立即产生，可以理解为一种强大的全景调试器，即当点击一个测试用例，就立即追踪到对应的代码和模块。如果你有一个足够大的屏幕，可以想象场景是多么的震撼… 精准测试测试漏洞分析功能，适用于敏捷测试。它可以基于程序静态数据和动态运行数据，自动分析软件缺陷最高风险的位置，引导首先对于高风险的模块完成覆盖，在有限时间内完成最具有风险的模块的覆盖测试。基于智能缺陷定位技术，精准测试结果可以直接定位到缺陷的位置，因此精准测试让开发人员定位缺陷的效率可以至少提升2-3倍。 企业最为头痛的回归测试维护，精准测试也给予了很好的方案。根据国际权威统计，平均每6行代码的修改，就会引入一个未知的难以直接预测的缺陷。从另一个角度来看，回归测试会随着项目人员记忆模糊以及团队调整，使不可预知的缺陷比例逐步上升。而精准测试由于其内置算法的原因，各种信息都极其完整的保存在了计算机里。我们实际对比了5个用例集在1000个左右的系统的测试，其计算用例集可控制在20%左右。另外在从回归测试的风险角度上看，传统通过经验判断型方法，由于周期拉长后人员变动以及记忆模糊。导致发现迭代引起的未知关联的概率越来越低，上线后引入风险。而采用精准测试，由于每轮测试记录的数据越来越多，基础代码覆盖辐射面越来越广，其计算准确性亦在持续上升。经过一定量的版本迭代后，其发现关联缺陷的概率可以达到80%以上。 精准测试的测试用例聚类分析功能，可以有效地发现“测试的错误”。比如一个用例执行步骤错误，它的聚类结果必然会发生变化，管理者通过系统分析的结果就可以发现并纠正这一类的错误，而之前可能需要在现场反复的确认。 从管理角度看，传统架构下平均4-5个测试执行人员就需要一个管理者，管理成本极高。精准测试体系下，由于过程管理均由计算机自动记录，管理者只需看报表就能清楚获知项目进度情况及每位项目参与者的工作效率。通过日报、周报、月报等，轻松了解各项目状况。后续团队无论如何变更，都可以在被授权的情况下，通过平台清楚地了解到整体框架结构与细致追溯关系，达到快速接手、大量节省开发与维护成本的目的。根据上述分析，精准测试适合应用于研发、测试的成熟体系中，特点是引入成本低，提高企业研发、测试效率显著，软件风控成果卓越。正如网络上所说，精准测试正在快速成为主流技术。
简介：本文主要介绍把现今主流的springboot框架项目和精准测试工具进行结合和应用，通过精准测试的数据穿透、数据采集、测试用例与代码的双向追溯、数据分析等一系列精准测试的特有功能，达到对项目质量的保证。 本次环境搭建分为基础环境准备、springboot环境搭建、精准测试环境搭建、精准测试与springboot环境对接等一整套完整的配置过程，用户可以通过下图中的流程图确认自己所部署过程中进行到的阶段点，从而排查部署中可能遇见的问题。 一，Spring Boot配置流程 1，使用工具 1， Eclipse Java Photon 2， Spring Boot 3， JDK 1.8 4， MySQL 5.7 5， Navicat for MySQL 6， apache-maven-3.5.4 7， zoa-agent-1.6.2 8， J2EE_Enterprise_key_64bit0614 9， 项目：Moxi（https://github.com/daleiwang/moxi） 2， 配置所需的安装 1，安装Eclipse、JDK、MySQL、Nodejs 注：Eclipse和JDK的安装和安装包就用自己现有的就可以，星云测试将提供MySQL和Nodejs的安装包，但必须前提是用户自己的本机上不存在安装的MySQL和Nodejs 脚本安装mysql和nodejs 1、解压星云提供的mysql-5.7.16-winx64安装包和nodejs安装包到服务器根目录中（例如D盘根目录）。 2、右键以管理员身份运行星云提供的自动化安装工具mysql_nodejs_install.exe 3、输入nodejs的目录，回车。如下图所示： 4、输入mysql的绝对路径（到bin），然后回车。等程序运行完毕，mysql的root密码被修改成root就可以手动关闭程序。 2，安装Spring Boot插件 Eclipse安装Spring Boot插件，Help-Eclipse Marketplace，搜索Spring Tools安装STS，如图： 也可以通过 下载地址：https://spring.io/tools/sts/all 进行下载， 下载以后安装，Eclipse——Help——Install new Sofware，下一步、下一步安装即可。 3,安装Maven Eclipse本身会带Maven，但是不如自己安装的灵活，解压apache-maven-3.5.4.zip（例如：E:apache-maven-3.5.4），配置系统变量添加变量名： MAVEN_HOME变量值= E:apache-maven-3.5.4， Path添加变量值= %MAVEN_HOME%bin，cmd测试用mvn -v如下即安装成功。 1，Eclipse替换自带为本地Maven Windows-Preferences-Maven-Installations-Add，路径指向E:apache-maven-3.5.4，加载完成后勾选新的apache-maven-3.5.4，Apply。 2，定义本地Maven依赖库 修改E:apache-maven-3.5.4confsettings.xml，添加如下一行代码定义，例如：C:Usersluxper.m2repository，C:Usersluxper.m2repository是我的本地maven仓库地址。 Eclipse：Windows-Preferences-Maven-User Settings-Global Settings，Browse= E:apache-maven-3.5.4confsettings.xml，Apply。 3，新建工程和运行工程 选择Spring Starter Project 工程名字，定义为moxi，工程选择Web下面的Web，然后Finesh，接下来会初始化下载Maven管理的相关jar包。 工程结构大致如下： 工程——右键——Run As——Spring Boot App 添加调试： 为了解决每次修改代码还要重新启动工程，工程——右键——Spring Tools——Add Boot Devtools，那么每次修改类文件就会自动编译了。 4，整合Mybatis 刚才已经下载好了MySQL，现在我们添加pom.xml文件build标签加一行compile如下 然后是mybatis和mysql： <!-- mybatis --> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>1.2.0</version> </dependency> <!-- mysql --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> 在application.properties文件中添加数据源配置：、 Navicat连接本地mysql，新建数据库moxi，查询执行项目git页面列出来的sql语句自动建立该项目需要的数据库内容。 可以通过创建Model、Service和Controller验证数据库是否连接成功 5，整合thymeleaf 添加thymeleaf依赖 配置application.properties 引入文件：如图，引入相应的样式、图片和js文件，引入页面文件: 引入html：注demo和news里面也是html文件 6，运行程序 Eclipse环境运行：Run As——Spring Boot App 打包运行：右键项目Maven-Maven install，项目目录target文件夹生成jar包，cmd运行。项目初次运行会下载所需依赖库，消耗时间较长。 在Eclipse环境运行成功以后界面是这样的： 二，测试项目 1， 下载工具及工具配置 2， 从官网上下载星云测试工具：http://www.teststars.cc/ 下载以后进行配置： 2，星云测试服务端的配置 TTLangage.config配置项说明： 1、 运行下的星云测试server目录中ThreadingTestServer.exe，在右下的图表中点注册信息，查看其时间，星云测试有两个月的体验，若是超过两个月，发生KEY过期，请联系星云测试的工作人员，并提交服务端中的序列码 2、联系星云工作人员获取当前服务器的key.key文件，替换到星云的server目录下； 3、启动server目录下的ThreadingTestServer.exe后会自动打开同级目录下的ThreadingTestServerFront.exe，看到自动弹出下面窗口后，表示连接正常。 3，星云测试客户端的配置 注：星云测试在线客户端的连接需要访问端口17262/17263.登陆之前需要保证网络连接不存在限制。 打开客户端之前需要修改TTClient文件夹下的Server.cfg文件，配置localIP项为可以与服务端正常数据通信的本机IP地址。配置这个localIP的原因是，在客户端需要接收来自服务端传来的动态数据，配置本地的IP地址服务端才能把数据传到客户端中来。 配置IP地址完成后双击运行TTClient/TT.exe文件进入星云测试客户端。选择文件->登录，输入星云测试服务端的IP地址以及自己的用户名和密码即可登录。如下图所示。 4，星云测试云报表平台服务启动 1、 运行星云测试TTWeb目录下的binredis-2.4.5-win32-win6432bit中的redis-server.exe 2、运行星云测试TTWeb目录下的startTTwebserver.bat 访问网页报表网页IP地址:3000 2，创建工程和版本并编译 1， 登录客户端 2， 选中待插装的空版本，版本处于解锁状态（解锁状态：右键-解锁状态） 3， javaForWindows目录下的Server.cfg配置文件，[SERVER] ip填写实际ip地址，修改[PROPERTY]字段，与客户端目录下的Server.cfg同步 4、修改javaForWindows目录下的ComplierPath.xml配置文件 同一个版本下可添加多个子模块即proname，proname不能重复，一个子模块下可以配置多个工程路径 ProName：子模块名称 Project_path：测试程序源码文件路径 Class_path：测试程序class文件路径 5、修改javaForWindows目录下tt_windows文件夹下Server.ini配置文件Ip设置为客户端的ip地址。 6、在命令行运行autoCompiler.jar进行编译 jrebinjava.exe -jar autoCompile.jar -e D:J2EE_Enterprise_key_64bit0803CompileToolsPkgjavaForWindows 注：-e后面的参数为ComplierPath.xml文件的目录 ７、在客户端查看数据,记得必须点击重新加载文件 由于测试的时候需要运行我们插装后的代码（编译完成后会在java目录同层生成src-instru目录，src-instru目录即为编译插装后的源码）; 具体操作：先将源码目录下未插装的java目录重命名为pre_java，再将编译插装生成的src-instru目录命名为java。 并且插桩代码的运行需要我们的jar包，因此需要修改客户的pom.xml文件来引入我们的jar服务，加入到两个之间，加入的代码如下： systemPath需要按JavaParser-j2ee.jar和jeromq-0.3.0-SNAPSHOT.jar的绝对路径填写 <dependency> <groupId>com.zoa</groupId> <artifactId>JavaParser-ZMQ</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/JavaParser－J2EE.jar</systemPath> </dependency> <dependency> <groupId>com.zoa</groupId> <artifactId>jeromq</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>/D:/J2EE/client/MQ/jeromq-0.3.0- SNAPSHOT.jar</systemPath> </dependency> 在pom文件修改完成后即可打包发布 编译以后达成jar包（具体的打包方法参考6，运行项目） 打包完成，为使函数覆盖率可视视图代码部分显示正常，需要手动修改源码路径：右键版本，点击修改源码路径，选择到pre_java目录即可。 3，测试前准备 1、添加数据传输配置文件 数据传输配置文件是保证运行的数据可以回传到星云服务器的。配置方法是在具体的客户测试环境下的usr/local/bin文件夹下新建配置文件config.cfg 文件内容如下： state=1 IP=（IP值写星云测试服务端IP，注意要大写）（如果发布环境是windows环境，需要在C盘根目录下配置上述文件） 2，agent启动项目 cmd输入命令： java -javaagent:E:zoa-agent-1.6.2zoa-agent-1.6.2.jar -jar E:moxi-0.0.1-SNAPSHOT.jar E:zoa-agent-1.6.2zoa-agent-1.6.2.jar =agent路径E:moxi-0.0.1-SNAPSHOT.jar =项目路径出现这样的界面表示运行成功： 3，设置cookie 1,项目URL后面加teststars.jsp，访问teststars.jsp页面进行cookie设置 2,点击setcookie进行设置，设置成功页面如下： 注：为了区分测试，我们在设置的用户姓名与星云客户端当前登录用户一致， 4，编写测试用例 点击添加： 5，项目测试 访问地址：http://localhost:8080/admin/login 页面登陆进去以后，假如测试内容管理的文章管理的测试用例，则选择内容管理的文章管理的用例，点击开始，在页面上点击内容管理的文章管理，就会有相应的测试数据传输过来（具体的展示见后面测试结果的第一个标题：示波器的展示），数据接收完以后点击停止，本条用力测试完毕 三，测试结果 1，示波器波形展示 先选中测试用例，再点击开始后就可以进行相应的测试工作了，测试的时候示波器可以收到动态数据并以波形图的方式展示出来。 注：采集的动态数据保存在服务端目录下的VersionData文件夹下，对应版本的动态数据保存在相应的版本号目录下（版本号可在数据库management表的version表中查看） 2，缺陷管理 为了让测式人员更好的对缺陷进行管理，采用测试用例、代码、BUG相关联方式，精准测试云平台使用了历史BUG追查功能，这使得在版本迭代过程中，同一个测试用例所有的BUG情况一目了然，避免了因人员变动或版本变动导致的相同的BUG的排查时间，以及重复提交未被解决的BUG。 图表 缺陷提交与管理 图表 bug信息一目了然 3，覆盖率 覆盖率可视化针对函数sc0、True、false 、both、Branch、C/DC 、MC/DC 7种覆盖率给出可视化展示下面针对每一种覆盖率展示界面给出说明：（以sc0为例） sc0为语句块覆盖，其颜色区分对象为基本语句块（包括隐含不可见语句块）其中绿色标示被覆盖的语句块。蓝色是未覆盖到的语句块。计算方法为：覆盖到块/应统计块 用红色的标出来的表示sc0覆盖率，函数列表右方为覆盖率的展示： 4，双向追溯 双向追溯是指通过运行测试用例，实现测试用例与被测源码间相互追溯。根据测试用、 查看相关被测源码为正向追溯，根据被测源码查看相关测试用例为逆向追溯。在测试用例列表中选择测试用例，可以追溯到该测试用例的内容描述信息，在模块调用图中显示被测试到的函数；也可以在模块调用图中，点击相关的函数，也可以追溯到相关的测试用例。该追溯技术方便了用户查看和设计测试用例。 双向追溯功能可以运行的前提是，测试用例已经被运行过，并且示波器收到了波形采集到了动态数据。 1，正向追溯正向追溯是指：将测试用例和海量的代码执行信息自动关联，可精确到函数级别及代码块级别；通过正向追溯可直接在代码级定位测试现场故障和缺陷逻辑，并提供最后运行的时序数据；通过正向追溯自动记录产生功能对应的详细设计实现，辅助软件解耦和架构分析。 正向追溯的优势是：迅速定位缺陷对应的代码执行逻辑，帮助开发快速修复缺陷，可追踪难复现缺陷；精确、详尽的记录测试用例运行的情况，为精准软件测试提供大量原生分析性数据；可以进行事后的缺陷分析、追踪，辅助开发进行功能实现确认。 如图：点击测试用例追溯到这个成而是用例运行过得函数，选中一个函数，追溯到这个函数运行过得控制流程图的逻辑分支以下是正向追溯到代码和函数调用图： 2，反向追溯 反向追溯是指：分析代码关联的功能，为研发分析系统和进行一致性修改以及回归测试分析提供精确数据。 反向追溯过程：点击需要查看的函数或函数中的某行代码，自动列出可以测试到该函数或者程序分支的测试用例 选择函数追溯到运行过该函数的测试用例，查看该函数的控制流程图和代码 点击代码，追溯到运行过该代码的测试用例 5，简易流程图的展示 前置条件：版本有数据，关联源码可在代码视图有显示源码，并且在简易控制流 程图的分支块有具体语句显示，有覆盖率数据，可在简易控制流程图显示当前覆盖到的块信息 简易控制流程图功能，以语句块的形式清晰的展示函数内部的控制逻辑，界面上可以直观的看出控制流各节点的测试覆盖情况，在展示中，简易控制流程图还可以通过颜色对每个程序块进行覆盖率标识，在缩略图中整个模块的覆盖率非常直观。（背景色为绿色表示有测试用例覆盖到该块：以SC0覆盖为参考标准） 6，报表的展示 选择客户端所编译的项目和版本： 显示所选取编译项目的一些基本信息，包括: 项目指标信息、项目信息、版本信息、测试汇总信息、测试过程监控趋势图、测试设备组成和分布图、版本覆盖率汇总图、复杂度统计图 项目汇总： 包含项目信息：项目的详情信息 版本信息：版本的详情信息 测试汇总信息：测试用例通过率：无BUG的测试用例 BUG累计：测试用例运行完毕后提交的BUG数 当前版本覆盖率(SC0)：(执行过可见段数/可见段数)*100%的比例 覆盖率增长：相比前一天的SC0增长差值 高复杂度预警函数个数：高复杂度的函数个数 测试用例列表： 显示制作的测试用例的详细信息，包括测试用例的名称、创建时间、执行时间、关联函数、覆盖率占比、运行状态、测试人员等 覆盖率按日增长曲线图： 覆盖率按日增长曲线图,让管理者更好的把握测试过程 测试漏洞列表： 在一个程序中，往往有成百上千的函数，这些函数有的是关联整个程序核心、有的则是开发人员弃而不用，但一直保留迟迟不肯删除的，针对这些大量的函数，“精准测试”采用通过静态、动态指标的综合分析，在大量的程序函数中，通过计算直接筛选潜在的高危的测试漏洞，通过报表给予展示。 通过复杂度和覆盖率进行计算 通过函数调用上下文和覆盖率进行计算
Wings-让单元测试智能全自动生成 前言 单元测试是保证软件质量非常有效的手段，无论是从测试理论早期介入测试的理念来看或是从单元测试不受UI影响可以高速批量验证的特性，所以业界所倡导的测试驱动开发，这个里面提到的测试驱动更多的就是指单元测试驱动。但一般开发团队还是很少的系统化的执行单元测试，针对应用软件的测试更多是由专业测试团队来执行黑盒测试。单元测试的最大的难点不在于无法确定输入输出，这毕竟是模块开发阶段就已经定好的，而在于单元测试用例的编写会耗费开发人员大量的工时，按照相关统计单元测试用例的时间甚至会远超过功能本身开发的时间。以下是几个最常见的开发不写单元测试的理由：●需求总是无穷尽的，还有下阶段功能需求要实现，没空补单元●要补的单元测试太多，无从下手，主观上抗拒。●单元测试编写难度大。一方面原因可能是功能函数实现上不够合理，另一方面是没有(或者不知道)好用的单元测试框架和mock框架。●单元测试不算入工作量内。 其次，功能需求还不稳定，写单元测试的性价比不高。换句话说，万一明天需求一变，那不光功能代码废了，单元测试也废了。如果不写单元测试，那这部分工夫就不会白费。 上述几点其实分析根本原因是单元测试编写太耗时，最终导致测试驱动的发动机失去了动力，致使测试驱动开发的美好愿景在现实场景熄火，因为构建这个驱动用的发动机实在是难度和成本太大了。 市场上的各种“x”Unit，单元测试框架仅仅解决了生成测试驱动的外框，没有任何基于深度程序理解的用例逻辑和数据的产生能力。因此在各种开发相关场景中都让开发人员产生抵触情绪。Wings的发布（目前针对C语言）则解决了这个困扰程序员的一个最大的难题，同时也有可能从根本上改变单元测试的现状，充分的、高效率的单元测试将有效缓解基于海量人力的系统级黑盒测试以及自动化测试的压力。 制约测试用例采用程序自动生成，最关键的底层技术是复杂的参数解析技术。即：能够在编译器层面对于任意复杂的类型，任意定义嵌套层级的递归解析。如果没有这个关键技术的突破，那么测试用例自动生成系统要么无法商用，要么将以极低的效率来演化、产生合规的测试数据。例如著名的模糊测试工具American Fuzzy Lop，它并不能够识别用户的程序所需要的结构类型，需要从最外层进行基于搜索算法的演化。程序的特性是接口层面的输入和内部某个模块的数据要求距离很远，外部数据通常是经过层层复杂转换才可以成为内部模块所需要的数据结构类型，因此从外层探索所需要的计算量和时间将是难以想象的。基于American Fuzzy Lop,为了能够生成一个合法的SQL 语句，让程序内部模块能够通过外围数据校验需要探索时间以天数计，远非分钟或者小时可以生成。另外一个制约性条件是：每个程序能够接手的输入都是经过精心结构编制、含有大量规则的数据，而这些数据通过随机+探索的方式生成是非常不现实和极其耗时的。所以，从黑盒以及最外层输入产生自动产生用例是不可行的。 如果从软件内部结构分析产生用例驱动，就需要对软件的编译结构进行深度理解。可行的测试用例生成系统，应该是基于程序的中间（关键入口）作为测试切入最为合适。这些模块的输入，已经将模糊的输入转化为高度结构化的参数。只要能够识别这些复杂结构，将复杂数据类型一步步降解为简单数据类型，同时完成参数构造，就可以自动完成驱动用例的生成。 基于模块的测试，可以划归为传统的单元测试，它是将缺陷发现并遏制在研发阶段最好的方法。但受限于单元测试需要开发大量的驱动程序，在行业内的推广和应用受到了极大的限制。当然单元测试也可以在系统集成完毕后执行，避免构建虚拟的桩程序。星云测试日前全球首发的Wings产品，是一个智能的、全自动的单元测试用例生成系统，研究并解决了如下难点，现分享给大家。 （1） 程序参数深度分析问题 Wings通过编译器底层技术，将输入的源文件，按照函数为单位，形成模块对象。对象中包含函数的输入参数，返回值类型等信息，供驱动函数模块和测试用例模块使用。每个文件作为一个单元，针对其中的每个函数的每个参数进行深度解析，对于嵌套类型，复杂类型等都可以实现精确的解析和分解，将复杂类型逐层讲解为基础数据类型，并产生参数结构的描述文件（PSD）。 （2） 函数驱动自动生成模块 依据PSD文件的格式信息，自动生成被测源程序的所有驱动函数，单元测试过程不再依赖开发人员手动编写测试函数，只需将生成的驱动函数和被测源文件一起编译，即可执行测试并查看测试结果。测试驱动自动生成程序基于PSD描述，全自动构建驱动被测程序运行的所有参数，必须的全局变量，并可根据复杂变量的层级结构产生结构化的测试驱动程序，可以节省大量的单元测试用例的编写时间。 （3） 测试数据自动生成与管理 用于自动生成测试数据，测试数据与被测函数提取的信息相互对应，数据以一定的层次逻辑关系存储在json文件中。数据和经过分解和展开后的数据类型是一一对应的。这些数据用户可以根据业务要求随意边际，并且用json文件进行结构化，层次化展示，非常的清晰。其中的测试数据包括全局变量值、被测函数调用时的参数值。 Wings提供了一种自动生成驱动函数的单元测试方法，其中主要包含以下几个步骤： 图一：单元测试驱动生成流程 1 被测程序信息提取 通过对源程序的扫描提取出函数的结构信息，使用户不需要关心程序的结构信息，而被测程序的结构信息，主要包含程序中的全局变量以及函数信息，而函数信息主要包括函数的参数个数，参数类型以及返回值类型。而全局变量以及参数，最主要的提取出其中的符号信息，以及类型信息，针对一些复杂的类型，通过层层进行解析为基本数据类型，完成全局变量以及函数参数的构造。 变量的类型一般大致分为基本类型、构造类型、指针类型及空类型。Wings通过底层编译技术，针对不同的变量类型，进行不同的处理方式。 （1）基本类型，例如unsigned int u_int = 20等基本类型，Wings将解析出变量的名称为u_int，数据类型为unsigned int。 （2） 构造类型，构造类型大致分为数组，结构体，共用体，枚举类型。 数组类型，例如int array2,数组名称为array，类型为int以及二维数组的长度，行为2，列为3。 结构体类型，针对结构体为数组，结构体链表等，进行不同的标记划分。 （3） 指针类型，例如int **ptr = 0;，解析出指针为int类型的2级指针。（4） 空类型，解析出类型为NULL。（5） 系统类型，例如File、size_t等，标记为系统类型，不在对其往下进行分析，会添加到模板中，由用户进行赋值操作。（6） 函数指针类型，分析出函数的返回值类型、参数类型以及参数个数 针对被测源程序的每个编译单元，将解析到的函数信息，保存在对应的PSD结构中，针对以下源代码实例进行说明： typedef struct my_structone { //基本类型 int i_int; //数组类型 int array_one[2]; int array_two[3][4]; //指针类型 int *point_one; int **point_two; //空类型 void *point; //位域类型 unsigned int w : 1; //函数指针是指向函数的指针变量，即本质是一个指针变量 int(*functionPtr)(int, int); union { int a; char b; long long c; }Dem; enum DAY { MON = 1, TUE, WED = 200, THU, FRI = 100, SAT, SUN }dy; }myy_structone; typedef struct my_struct { //结构体包含结构体 myy_structone *structone; //结构体中包含系统头文件的类型 FILE file; struct my_struct *next; }myy_struct; //结构体作为函数参数 void StructTypeTest1(myy_struct m_struct); void StructTypeTest2(myy_struct *mm_struct); void StructTypeTest3(myy_struct mm_struct[2]); void StructTypeTest4(myy_struct mm_struct[2][3]); 以上程序中，void StructTypeTest3(myy_struct mm_struct[2])保存的PSD结构如下： <StructTypeTest3 parmType0="myy_struct [2]" parmNum="1"> <mm_struct baseType1="ArrayType" RowSize="2" type="StructureOrClassType" name="my_struct"> <structone baseType1="PointerType" type="StructureOrClassType" name="my_structone"> <i_int baseType1="BuiltinType" type="ZOA_INT" /> <array_one baseType1="ArrayType" RowSize="2" type="ZOA_INT" /> <array_two baseType1="ArrayType" RowSize="3" baseType2="ArrayType" ColumnSize="4" type="ZOA_INT" /> <point_one baseType1="PointerType" type="ZOA_INT" /> <point_two baseType1="PointerType" baseType2="PointerType" type="ZOA_INT" /> <point baseType1="PointerType" type="ZOA_VOID" /> <w baseType1="BuiltinType" type="ZOA_UINT" bitfield="1" /> <functionPtr baseType1="FunctionPointType" type="ZOA_FUNC" returnType="int" parmType0="int" parmType1="int" parmNum="2" /> <Dem baseType1="UnionType" type="ZOA_UNION" name="NULL"> <a baseType1="BuiltinType" type="ZOA_INT" /> <b baseType1="BuiltinType" type="ZOA_CHAR_S" /> <c baseType1="BuiltinType" type="ZOA_LONGLONG" /> </Dem> <dy baseType1="EnumType" type="ZOA_ENUM" name="DAY"> <MON type="ZOA_INT" value="1" /> <TUE type="ZOA_INT" value="2" /> <WED type="ZOA_INT" value="200" /> <THU type="ZOA_INT" value="201" /> <FRI type="ZOA_INT" value="100" /> <SAT type="ZOA_INT" value="101" /> <SUN type="ZOA_INT" value="102" /> </dy> </structone> <file baseType1="StructureOrClassType" type="StructureOrClassType" name="_iobuf" SystemVar="_iobuf" /> <next NodeType="LinkNode" baseType1="PointerType" type="StructureOrClassType" name="my_struct" /> </mm_struct> <g_int globalType="globalVar" /> <returnType returnType="void" /> </StructTypeTest3> 其中PSD文件各节点代表的意义如下： StructTypeTest3代表函数名，parmType0代表参数类型，parmNum代表参数个数 mm_struct代表函数参数的符号，baseType1代表类型的分类（基本数据类型、构造类型、指针类型、空类型），type代表具体的类型，包括int，char，short，long，double，float，bool，以及这些类型的unsigned类型等基础的类型，还有一些特殊的类型诸如：ZOA_FUN类型表示函数类型，StructureOrClassType表示结构体类型，等等，name代表结构体、联合体、枚举类型的名称 i_int代表基本类型，基本类型作为最小的赋值单位 array_one代表数组类型，RowSize代表数组的长度，数组可以划分为一维数组，二维数组等 point代表指针类型，指针分为一级指针、二级指针等，一般指针当做函数参数作为数组使用，因此，针对基本类型的指针，采用动态分配数组的方式进行赋值，用户可依据需要，修改对应的值文件。 w代表位域类型，bitfileld代表所占位数 functionPtr代表函数指针类型，分别分析出参数类型、参数个数、返回值信息 Dem代表联合体类型 dy代表枚举类型，value代表枚举类型的取值 file代表结构体类型，SystemVar代表此变量属于系统头文件中的变量，针对此种类型的变量，Wings通过添加模板变量的方式，添加在模板库中，用户可依据具体需要进行特殊赋值。例如File类型的，处理方式为： /* 系统内置类型，特殊处理或者模板处理 */ char * fname = "E:/spacial.txt"; FILE * file = fopen(fname,"r"); _st.file = _file; 用户也可自行添加赋值方式。针对系统类型，Wings可以和普通用户自定义类型进行区分，当解析到系统内置类型的时候就可以停止向下进行递归分析。 g_int代表全局变量，globalType代表全局 next代表链表结构体，NodeType代表此结构为链表 returnType代表函数的返回值类型。 2 驱动程序的自动生成 在上文中，针对全局变量和函数的结构信息，进行了分析和提取，以下将利用提取到保存在PSD中的信息，完成被测源程序的驱动框架整体生成。生成主要分为以下几个方面： 全局变量的声明 函数参数的赋值操作，针对函数参数的个数，依次赋值操作 全局变量的赋值，针对分析得到函数使用的全局变量的个数，依次进行赋值操作 原函数的调用 一些需要注意点如下： 驱动生成过程中，针对一些特殊函数，例如main函数，static函数等，因为外部无法访问到，驱动生成暂时不做处理。 针对每个被测源文件，生成对应的一个驱动文件。 驱动控制包含在Driver_main.cpp中，可以通过宏自动配置函数的测试次数 由以上源程序，生成的驱动函数如下： 所有变量的命名为在原变量的名称前，添加_ 通过获取生成对应的测试数据，对变量依次进行赋值操作 针对系统内置参数，以及用户比较特殊的参数，通过模板方式统一配置赋值方式。 对被测函数进行参数赋值与调用。 3 测试数据自动生成 测试用例的自动生成，利用提取到保存在PSD中的函数信息，进行测试用例数据的生成，以下是图三中PSD格式生成的一组数据，每组数据保存为JSON格式，更容易看到数据的层次关系。 "StructTypeTest30" : { "g_int" : 11624, "mm_struct" : [ { "file" : "NULL", "next" : "NULL", "structone" : { "Dem" : { "a" : 20888, "b" : "A", "c" : 19456 }, "array_one" : [ 24441, 12872 ], "array_two" : [ [ 18675, 30300, 32216, 19566 ], [ 13566, 13319, 11179, 18867 ], [ 30514, 21664, 21641, 28262 ] ], "dy" : 101, "functionPtr" : "NULL", "i_int" : 18271, "point_one" : [ 28024, 32245, 2129 ], "point_two" : [ [ 18165, 32335, 6429 ], [ 30225, 18252, 2764 ], [ 3177, 3622, 29789 ] ], "w" : 16862 } }, { "file" : "NULL", "next" : "NULL", "structone" : { "Dem" : { "a" : 2651, "b" : "7", "c" : 12159 }, "array_one" : [ 1274, 24318 ], "array_two" : [ [ 27944, 1208, 29647, 20840 ], [ 4972, 27297, 17456, 13614 ], [ 22441, 1160, 8940, 29420 ] ], "dy" : 200, "functionPtr" : "NULL", "i_int" : 15434, "point_one" : [ 29394, 3868, 25406 ], "point_two" : [ [ 13575, 14736, 20728 ], [ 9132, 2297, 2113 ], [ 26252, 14896, 10985 ] ], "w" : 12354 针对每个编译单元，默认生成一组所有函数的对应的测试数据文件，值生成可以通过配置次数进行修改。 4 Mysql程序测试结果展示如何完成驱动框架的生成，下面针对开源程序MySQL完整的生成过程，进行详细说明。以下是Wings测试Mysql的主界面图： 点击文件按钮，设置被测源程序的工程目录。设置完成之后，点击功能操作，功能操作主要包括参数解析、驱动生成、值文件生成以及模板添加四个操作。分析对应生成以下几个文件夹： 其中，参数解析模块，对应生成FunXml以及GlobalXml，分别存放提取到的每个编译单元的函数信息及全局变量的信息。 驱动生成模块，会对应生成Wings_Projects文件夹，其中存放每个编译单元的驱动文件 值生成模块，存放每个编译单元的生成的测试数据。 下图为Mysql对应加载的驱动文件结构体信息，左侧导航树为生成的对应驱动文件，包含每个编译单元的函数以及函数的参数、全局变量的信息。点击其中某个编译单元，可以加载对应的驱动文件以及对应的值文件。 以上是Mysql的整体生成对应的驱动文件以及值文件，针对以下代码详细说明驱动文件。 针对每个编译单元，全局变量的引用通过extern的方式。 驱动函数，统一命名为Driver_XXX的方式，JSON作为获取测试数据的方式，times代表单函数的测试次数。 针对每个参数的赋值操作，利用解析到的PSD存储格式，对每层结构依次进行赋值操作。
发表了文章
2020-03-31
发表了文章
2019-10-18
发表了文章
2019-09-17
发表了文章
2019-08-15
发表了文章
2018-12-04
发表了文章
2018-11-30
发表了文章
2018-11-28
发表了文章
2018-09-06
发表了文章
2018-09-04
发表了文章
2018-08-23
发表了文章
2018-08-14
发表了文章
2018-08-13
发表了文章
2018-08-05
