我们继续上一期计算全栈故障注入没讲完的内容，这期主要介绍DemonCAT支持集成扩展能力、支持被集成能力和自定义故障模式。一、支持集成扩展能力DemonCAT工具具备两种集成方式，一种是提供编写配置文件的方式集成，通过将目标工具支持的故障注入类型，封装成一个个故障模式，并对所有故障模式按照规定的格式编写cfe.cnf配置文件，来完成DemonCAT工具的集成；另一种方式是Center（接口集成）方式，通过在Center侧导入工具支持的故障模式列表、命令参数说明，并将工具与已有工具打包在一起即可。   DemonCAT提供统一的工具应用框架和调用/回调接口，丰富故障注入的能力与范围，使得工具具备更加完整的故障注入能力。下图为配置文件的集成方式，Center接口继承方式原理相同：当前业内有许多优秀的故障注入工具，如chaosblade、chaos tools，但往往只能针对某一领域，无法做到计算全栈的故障注入，导致故障注入能力不全，工具可用性不足；DemonCAT工具设计之初就为后期集成提供了对应的方案，仅需要掌握被集成工具的参数、执行命令，按照DemonCAT的集成规范编写对应的配置文件即可，大大降低了工具集成的难度。 二、支持被集成能力描述DemonCAT工具支持被集成，由用户将工具集成到自己的测试系统和流程中，用户根据测试方案或用例自定义故障注入的方案，测试系统根据测试方案或用例自动化调用DemonCAT工具实现对应的故障注入，既可实现单个原子故障注入，又能实现多个原子故障编排能力，即使测试人员不懂故障测试方法，通过测试用例或测试系统调用工具能力，也能完成目标测试任务，大大降低了故障测试的门槛。 DemonCAT被集成的方式同样存在两种，一种是通过封装 DemonCAT Core侧的故障注入命令至系统或工具中，再通过系统调用对应的故障注入命令即可；另一种集成方式，不考虑封装命令，直接调用 DemonCAT Center实现的接口，这样省去封装的过程。两种方式各有优劣，命令封装具有更高的灵活性，接口封装具有更高的集成效率。 集成示例如某测试系统集成DemonCAT，采用了命令行封装的方式进行集成，该种集成方式是与DemonCAT Center集成DemonCAT Core的形式一致： 1) 通过在系统中录入DemonCAT支持的故障模式，并按照故障模式录入相关的参数与说明信息； 2) 将已有的DemonCAT Core故障注入工具，与被集成系统的后端服务放在一起； 3) 用户在前端页面录入环境信息，录入完成后系统将主动将匹配的工具推送至目标系统之中； 4) 可在用例页面设计编排用例执行的故障模式、参数以及时间等内容； 5) 最后，用户执行相关用例时，由系统下发故障注入命令至对应的被测系统之上，并返回命令的执行结果，即完成一次故障注入。 三、自定义故障模式描述DemonCAT工具具备二次开发的能力，提供的二次开发文档可降低开发的难度，开发人员可自行添加特殊的故障模式和注入功能，仅需按文档实现对应接口，再将配置、参数信息写入工具配置文件，用户使用通过统一的接口进行该功能的调用，即可实现工具的二次开发。开发人员通过 DemonCAT工具的二次开发能力，可丰富工具的功能或特性，增强工具的可用性。自定义流程推荐的自定义开发步骤如下，这里仅仅是提供参考，如果已有更优秀的自定义故障模式开发流程，可以不遵从下列开发流程：1) 分析故障模式：在开发故障模式之前，需要明确故障模式的原理、影响、实现的语言以及实现的方案等等，这些内容建议以文档的方式输出，并经过相关人员的评审归档。只有明确了这些才能正式着手进行开发。 2) 实现故障模式：依据第一步中得到的部分文档，进行故障模式的实现，实现 之后的程序即是故障注入工具。实现的过程中需要注意不同OS、内核版本的 兼容，比如：X86与Arm架构在某些库函数存在差异，3.X与4.X的内核版本 也存在一些差异性，CentOS与EulerOS在工具的支持方面可能会有所不同。每一种故障模式实现的语言并无限制，不过由于一些故障模式注入可能会涉及到底层的一些系统调用或库函数调用，这时 C/C++就有天然的优势；而针对 Linux本身支持的一些工具或命令，这时shell语言就具有天然的优势；而可能也存在一些故障模式的开发既不需要系统调用，也不需要调用Linux本身的工具或命令，这时就可以选择那些编码简单拥有大量库的语言。 3) 编写配置文件：第二步故障模式实现完成之后，需要整理出这些故障模式的 注入、清除、查询等关键命令信息，并按照配置文件的规范，编写配置文件。 4) 打包工具：按照配置文件中配置的故障注入、清除、查询命令的工具路径， 打包第二步中已开发完成的故障模式注入工具，并按照配置文件中配置的路径放置打包后的工具程序。 5) 编写使用文档：编撰故障模式的相关说明文档，列出注入的命令示例、故障 影响范围、故障表现以及相关注意事项。至此，第四步的工具包与本步编撰的文档，即可交付用户使用。这期我们一起学习了计算全栈故障注入，下一期简单指导下DemonCAT工具的使用方法，工具使用非常简单方便，敬请期待~

教程指引：https://support.huaweicloud.com/bestpractice-dws/dws_05_0007.html实践介绍：      在本教程中，您将学习如何优化表的设计。您首先不指定存储方式，分布键、分布方式和压缩方式创建表，然后为这些表加载测试数据并测试系统性能。接下来，您将应用优秀实践以使用新的存储方式、分布键、分布方式和压缩方式重新创建这些表，并再次为这些表加载测试数据和测试系统性能，以便比较不同的设计对表的加载性能、存储空间和查询性能的影响。      在本教程中，您将学习调优表设计的步骤。基于这些步骤的掌握，通过进一步应用优秀实践方法来改进表的分配，以达到您所期望的数据加载、存储和查询方面的效果。估计时间：60 分钟。实践步骤：步骤1：创建初始表并加装样例数据步骤2：测试初始表结构下的系统性能并建立基线步骤3：选择存储方式和压缩级别步骤4：选择分布方式步骤5：选择分布列步骤6：创建新表并加载数据步骤7：测试新的表结构下的系统性能步骤8：评估结果步骤9：清除资源课程反馈：场景分析：问题记录：如果你也想申请GaussDB(DWS)免费试用，请点此一键申请免费试用>>3500元套餐，我就免费，哎，就是玩儿~

你已经学过如何设置开发集和评估指标，就像是把目标定在某个位置，让你的团队瞄准。但有时候在项目进行途中，你可能意识到，目标的位置放错了。这种情况下，你应该移动你的目标。  我们来看一个例子，假设你在构建一个猫分类器，试图找到很多猫的照片，向你的爱猫人士用户展示，你决定使用的指标是分类错误率。所以算法和分别有3％错误率和5％错误率，所以算法似乎做得更好。 但我们实际试一下这些算法，你观察一下这些算法，算法由于某些原因，把很多**图像分类成猫了。如果你部署算法，那么用户就会看到更多猫图，因为它识别猫的错误率只有3%，但它同时也会给用户推送一些**图像，这是你的公司完全不能接受的，你的用户也完全不能接受。相比之下，算法有5％的错误率，这样分类器就得到较少的图像，但它不会推送**图像。所以从你们公司的角度来看，以及从用户接受的角度来看，算法实际上是一个更好的算法，因为它不让任何**图像通过。  那么在这个例子中，发生的事情就是，算法A在评估指标上做得更好，它的错误率达到3%，但实际上是个更糟糕的算法。在这种情况下，评估指标加上开发集它们都倾向于选择算法，因为它们会说，看算法A的错误率较低，这是你们自己定下来的指标评估出来的。但你和你的用户更倾向于使用算法，因为它不会将**图像分类为猫。所以当这种情况发生时，当你的评估指标无法正确衡量算法之间的优劣排序时，在这种情况下，原来的指标错误地预测算法A是更好的算法这就发出了信号，你应该改变评估指标了，或者要改变开发集或测试集。在这种情况下，你用的分类错误率指标可以写成这样：  是你的开发集例子数，用表示预测值，其值为0或1，这符号表示一个函数，统计出里面这个表达式为真的样本数，所以这个公式就统计了分类错误的样本。这个评估指标的问题在于，它对**图片和非**图片一视同仁，但你其实真的希望你的分类器不会错误标记**图像。比如说把一张**图片分类为猫，然后推送给不知情的用户，他们看到**图片会非常不满。  其中一个修改评估指标的方法是，这里（与之间）加个权重项，即： 我们将这个称为，其中如果图片不是**图片，则。如果是**图片，可能就是10甚至100，这样你赋予了**图片更大的权重，让算法将**图分类为猫图时，错误率这个项快速变大。这个例子里，你把**图片分类成猫这一错误的惩罚权重加大10倍。  如果你希望得到归一化常数，在技术上，就是对所有求和，这样错误率仍然在0和1之间，即：  加权的细节并不重要，实际上要使用这种加权，你必须自己过一遍开发集和测试集，在开发集和测试集里，自己把**图片标记出来，这样你才能使用这个加权函数。 但粗略的结论是，如果你的评估指标无法正确评估好算法的排名，那么就需要花时间定义一个新的评估指标。这是定义评估指标的其中一种可能方式（上述加权法）。评估指标的意义在于，准确告诉你已知两个分类器，哪一个更适合你的应用。就这个视频的内容而言，我们不需要太注重新错误率指标是怎么定义的，关键在于，如果你对旧的错误率指标不满意，那就不要一直沿用你不满意的错误率指标，而应该尝试定义一个新的指标，能够更加符合你的偏好，定义出实际更适合的算法。 你可能注意到了，到目前为止我们只讨论了如何定义一个指标去评估分类器，也就是说，我们定义了一个评估指标帮助我们更好的把分类器排序，能够区分出它们在识别**图片的不同水平，这实际上是一个正交化的例子。  我想你处理机器学习问题时，应该把它切分成独立的步骤。一步是弄清楚如何定义一个指标来衡量你想做的事情的表现，然后我们可以分开考虑如何改善系统在这个指标上的表现。你们要把机器学习任务看成两个独立的步骤，用目标这个比喻，第一步就是设定目标。所以要定义你要瞄准的目标，这是完全独立的一步，这是你可以调节的一个旋钮。如何设立目标是一个完全独立的问题，把它看成是一个单独的旋钮，可以调试算法表现的旋钮，如何精确瞄准，如何命中目标，定义指标是第一步。  然后第二步要做别的事情，在逼近目标的时候，也许你的学习算法针对某个长这样的成本函数优化，，你要最小化训练集上的损失。你可以做的其中一件事是，修改这个，为了引入这些权重，也许最后需要修改这个归一化常数，即：  再次，如何定义并不重要，关键在于正交化的思路，把设立目标定为第一步，然后瞄准和射击目标是独立的第二步。换种说法，我鼓励你们将定义指标看成一步，然后在定义了指标之后，你才能想如何优化系统来提高这个指标评分。比如改变你神经网络要优化的成本函数。 在继续之前，我们再讲一个例子。假设你的两个猫分类器和，分别有用开发集评估得到3%的错误率和5%的错误率。或者甚至用在网上下载的图片构成的测试集上，这些是高质量，取景框很专业的图像。但也许你在部署算法产品时，你发现算法看起来表现更好，即使它在开发集上表现不错，你发现你一直在用从网上下载的高质量图片训练，但当你部署到手机应用时，算法作用到用户上传的图片时，那些图片取景不专业，没有把猫完整拍下来，或者猫的表情很古怪，也许图像很模糊，当你实际测试算法时，你发现算法表现其实更好。  这是另一个指标和开发集测试集出问题的例子，问题在于，你做评估用的是很漂亮的高分辨率的开发集和测试集，图片取景很专业。但你的用户真正关心的是，他们上传的图片能不能被正确识别。那些图片可能是没那么专业的照片，有点模糊，取景很业余。 所以方针是，如果你在指标上表现很好，在当前开发集或者开发集和测试集分布中表现很好，但你的实际应用程序，你真正关注的地方表现不好，那么就需要修改指标或者你的开发测试集。换句话说，如果你发现你的开发测试集都是这些高质量图像，但在开发测试集上做的评估无法预测你的应用实际的表现。因为你的应用处理的是低质量图像，那么就应该改变你的开发测试集，让你的数据更能反映你实际需要处理好的数据。 但总体方针就是，如果你当前的指标和当前用来评估的数据和你真正关心必须做好的事情关系不大，那就应该更改你的指标或者你的开发测试集，让它们能更够好地反映你的算法需要处理好的数据。 有一个评估指标和开发集让你可以更快做出决策，判断算法还是算法更优，这真的可以加速你和你的团队迭代的速度。所以我的建议是，即使你无法定义出一个很完美的评估指标和开发集，你直接快速设立出来，然后使用它们来驱动你们团队的迭代速度。如果在这之后，你发现选的不好，你有更好的想法，那么完全可以马上改。对于大多数团队，我建议最好不要在没有评估指标和开发集时跑太久，因为那样可能会减慢你的团队迭代和改善算法的速度。本视频讲的是什么时候需要改变你的评估指标和开发测试集，我希望这些方针能让你的整个团队设立一个明确的目标，一个你们可以高效迭代，改善性能的目标。

我想了解下当前cloudtable 支不支持云上环境和云下环境的作为现网使用的互联方式？有没有方式支持云下资源直接链接云上CloudTable服务，进行开发和联调？支不支持大规模的云下资源链接云上cloudtable进行联调测试？

　精准测试从某个层面来讲，是赋予了测试用例真正的生命力，传统的测试用例仅仅是一些只能够依赖人去理解和分析的文本文件而已，在计算机和算法层面则没有存在意义和价值。下图是精准测试的整体架构图：　　大家首先可能会比较好奇，“用例魔方”的概念是怎么来的？测试用例魔方是在精准测试的设计、开发和商业实践中自然产生的功能集合的一个统称。当我们把精准测试的和用例分析相关的功能画成架构图形表示的时候，它自然而然地看起来就像魔方，所谓“魔”则是精准测试核心算法所赋予的超能力。上图是星云精准测试系统的总体结构图，“测试魔方”即分布在左上角区域。大家知道精准测试的核心技术是测试用例与代码的追溯关系的建立，而在此之上就可以构建测试魔方的核心功能区。如下：　　　所谓“方”实际上是代表测试用例的集合，每个测试用例用一个小方块标识，所有测试用例的集合用一个大方块。现在来看在精准测试架构下，“用例魔方”所能够提供的功能（对精准测试的底层技术不是很了解的话，可以预先温习下《精准测试框架白皮书》）。精准测试体系中，测试用例对应的代码逻辑都可以实现全自动的追溯和存储，因此测试用例就具备了进行深入分析的基础。在精准测试的用例魔方中，目前存在三个面（随着后续功能的增加，将增加分析的面），即回归测试用例选取、测试用例聚类分析、测试用最小化，同时辅之以智能缺陷定位技术。下面对“用例魔方”做详细的说明，选用的工具为星云精准测试平台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<z成立且第十二行x<y不成立且第十四行x<z成立时即得y<z且x>=y且x<z.此时可得y<=x<z,中间数为x,所以此处正确语句应为m=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 试用。）　　精准测试的精髓在于通过专用测试软件实现表层功能和底层代码的关联，并且获取成本很低。它在测试用例执行的过程中，通过软件示波器以透明方式自动获取两者的关联关系。通过精准测试系统，使针对用例的深入分析“用例魔方”成为可能。目前精准测试的核心用例分析算法正在持续增强，“用例魔方”的软件研发辅助分析功能，为软件测试的智能化、专业化成长，带来曙光和方向。