第一章 精准测试诞生的背景（附完整版精准测试讲解视频和白皮书pdf下载）20年前（2000年），上网是一件很酷的事，叫做“网上冲浪”，主要是几个门户网站占据绝大多数注意力；20年后（2020年），我们已经全方位“浸泡”在软件的海洋里，很多大型软件系统已经超过亿行，架构模型越来越复杂。未来的20年（2020-2040年），随着各种智能应用的层出不穷，软件系统内部逻辑会不可逆转的越来越复杂，而外部操作会越来越“傻瓜”。用户一个眼神或者一动脑，就能够切换出不同的功能需求。同时中国的软件产品化进程，近些年来正在蓬勃的进行，大量的公司开始研发自己的产品。伴随着关键核心软件的国产替代，使得原本应用级难度的开发正在向高复杂度和高质量的产品型研发转型。这个转型的过程，注定将产生对于高端测试工具的巨大需求。软件缺陷发现得越晚，其处理费用即呈几何性激增，而不是线性增长。如何从庞大复杂的系统中迅速及时地找到故障所在，一直是行业的一大难点。无法对大型软件进行有效的质量把控，就无法真正构建与维护大型软件。目前国内软件测试基本处于两种状态：一是绝大多数企业采用功能（黑盒）测试，二是小部分对软件产品有高可靠性要求的软件，企业会使用代码级的白盒测试工具。但这两种传统测试办法在目前的软件日趋智能化复杂化下，弊端越来越明显。功能（黑盒）测试技术**，使墨菲定律在所难免。**由于无法获知程序内部逻辑结构，这种测试办法对软件可靠性要求不高的应用来讲问题不是很大，但是对于大型金融机构、智能工业、航天军工等关键系统，就意味着时刻携带隐形的巨大风险。为此，功能测试后期需要极高的人力投入才能完成复杂逻辑的用例分析和设计。然而对于黑盒测试来说，程序越大，杀虫剂效应越明显。而行业内当作银弹的自动化测试，当自动化程序本身规模扩大以后，它的维护本身就存在了很严重的问题。低效的黑盒测试状态，最终将影响和制约未来整体软件发展。代码级（白盒）测试工具一般重点应用在研发阶段的单元测试上，满足了客户的部分高可靠性需求，但由于其价格高昂、技术老化，仅适合于小规模迭代瀑布式开发的软件，无法完成复杂的系统级别的测试以及分布式基于云的测试，更不适应敏捷迭代的开发模式。另外白盒测试工具基本都是国外产品，通常这些产品无法完成深度的定制化功能实现以及快速的用户响应，代码安全更是一个较大的问题。所有先进的科技都是具备前瞻性眼光的。随着国内军民各项大型核心软件系统的上马，研发一种面向高复杂度大型软件、自主可控的高性能智能精准测试平台的必要性，逐渐凸显。在这个时代背景下，2012年初，星云测试团队开始了筚路蓝缕、心无旁骛的研发征程。精准测试是个交叉学科，里面涉及到编译器、测试分析、图形技术、高性能通信与存储，软件的研发等多项底层技术。经历无数个不眠之夜对技术难点突破的煎熬与最佳解决方案的反复推敲，星云精准测试产品在诸多方面率先实现了重大技术创新，成功突破了白盒测试使用难度大、价格高昂的桎梏，有效消弭了国外高端测试产品垄断的壁垒。星云精准测试产品更偏向于软件测试业界的“灰盒测试”，即用简单的黑盒操作办法，可以同时得到单元级和系统级的精准测试数据。“星云精准测试”不负众望，在众多性能上大幅超越国外进口高端白盒测试工具产品，并在数据追溯、覆盖率可视化、智能回归、智能缺陷定位、分布式数据穿透与追踪等特性上有突出贡献。星云精准测试，既继承了传统功能测试前期的高效率运行区间，又能在后期通过系统的数据，让开发、测试充分协同，完成全程高效的测试与数据分析。（1）将测试团队的价值放大，能够将开发与测试更加紧密的连接起来，互为支撑。（2）采用精准、可信的测试技术，测试管理的难度大幅度降低。（3）降低企业对人员的过度依赖，通过系统适应人员的变更。（4）为企业实现测试数据资产的有效积累和分析，打下坚实基础。“星云精准测试VIP大企业离线版云平台”在整体测试试功能上的优异特性，成功获得了一批重要大型企业的高度认可及产品采购。星云测试的首发版本为：穿线测试 ThreadingTest，2014年6月6日上线，侧重于系统级白盒测试技术，测试用例和代码逻辑的双向追溯技术，测试示波器技术，覆盖率可视化技术。2015年8月6日，“穿线测试”正式更名为“星云测试”。在继承穿线测试整体技术上，星云精准测试增强了回归测试用例的自动选取技术，缺陷最后执行时序分析、智能缺陷定位、敏捷环境下多版本白盒测试数据的聚合、聚类分析、结合代码结构与动态数据的测试漏洞检出、代码安全特性，全面的测试管理特性等几十种优秀功能。目前有“星云精准测试VIP大企业离线版云平台”、“星云精准测试PASS在线云平台www.teststars.cc”、“全自动测试用例驱动生成系统Wings”等多种工具产品。星云精准测试旗下产品平台有Horn、Paw、Shell、Wings等系列产品。适用语言和平台暂为：为响应广大用户的需求，目前正在进一步扩展适应的语言和平台覆盖面。图1-1 精准测试在大型系统的效率运行分析星云精准测试，既保证了传统功能测试前期的高效率运行区间，又能在后期通过系统的数据，让开发、测试充分协同，完成全程高效的自动化精准测试。第一章 精准测试技术体系对软件测试技术的升级解析精准测试技术体系经过近6年的商业项目实践日臻成熟，大量商业应用案例的正面积极反馈，表明它已经成为新的软件测试技术方向体系。星云精准测试灵巧详细的功能设计和高度可靠的产品内核得到了市场的广泛认可，对于国际上原有的白盒测试工具来讲，是一种质的飞跃。2012年，精准测试的商用工具正式进入设计和研发阶段。与引进国外技术不一样，精准测试的核心技术体系是星云测试团队在国内的原创设计和研发。产品经过3年的悉心研发、反复内测、不断优化后，2014年精准测试在CSTQB会议上，发布了第一个商用版本ThreadingTest，引起了很大反响。6年前，行业上还全面沉浸在黑盒测试的大氛围中，从未见过精准测试的超前的运行方法和提供的强大智能的功能，由于理念与设计过于超前，早期有一些业内质疑的声音。但由于产品独到的优秀特点和巨大的潜在价值，诸多伯乐开始试用，给了产品在实际场景中不断优化、强化的宝贵机会。经过不同领域、不同客户的各种高复杂度大型系统的百般锤炼、验证后，自2016年开始，精准测试开始赢得全行业的重视和响应。优秀的商用落地性是精准测试技术流行的一个重要因素。由于精准测试把准了黑盒测试无法解决的难题和固有瓶颈，踏准了测试技术发展大的进程，并从设计一开始就特意注重了商业场景下使用要求复杂性，因此它从诞生之日起就不仅仅是一套理论，而是有着非常强的实用性基因和可扩展架构，多场景应用成果卓然。精准测试最底层的核心技术：“一种基于用例与源码双向追溯的测试装置及方法”，类似在重建量子纠缠的场景和数据。它成功的将功能用例和对应的代码二者之间的追溯路线，实现了精准无误的可视化。这彻底解决了在黑盒的状态下，软件工程师们无法获知程序内部运行轨迹的难题。自此开始，计算机处理海量测试数据的强大分析能力开始展现。我们知道，所有的黑盒测试都是人工进行的，它依赖的是人的算力，而软件正确性验证的工作量，主要是组合路径膨胀的问题，人的算力是远远跟不上的。那么精准测试如何从测试的角度对业务进行深度的测试辅助分析呢？我们用量子纠缠的形象类比来说明这个问题。量子纠缠理论我们可以简单理解为两个处在纠缠态的粒子一旦分开，不论分开多远，如果对其中一个粒子作用，另一个粒子会立即发生变化，且是瞬时变化。“一个粒子”会与“另一个粒子”产生相互作用，两个表面互相不关联的粒子，互相作用互相影响，他们对外是一个整体，无法单独描述“单个粒子”的性质，只能描述这“两个粒子”的整体性质，这就叫做“量子纠缠”。类比到软件测试上，我们的被测试软件中常见的软件界面和功能输入输出以及渲染它的复杂代码，他们之间就和两个纠缠在一起的粒子一样，具备强关联性。一个发生了变化，另一个必定发生变化。精准测试的另一核心功能是：“回归测试用例的自动选取”，就是基于用例和代码的追溯（量子纠缠）关系在进行运算之后全自动得出的。用例和代码精准的追溯机制，使数据开始可以实施大量的智能测试算法。在软件测试理论界，大量论文算法的基础都是默认建立在用例和代码的关系上进行分析的，但因其追溯机制工业实现难度极大，所以一直停留在学术理论阶段。星云测试引领的精准测试方法体系，落地在精确便捷的商用产品和大型解决方案中，让大量先进的测试分析方法和理论，得以实实在在的验证。精准测试首次明确的提出了：如何采集和应用双向追溯数据，进行测试辅助分析系统的构建。不管是纯软件系统还是运行在设备中的软件系统，用例与代码精准的数据可追溯性，都是基础性的强需求。比如金融转账业务、用手机拍照、机器人控制器的动作控制指令等，每个操作都有与之对应的代码。星云精准测试产品的强大之处在于：所有的分析算法不需要和被测系统的业务功能做特定的适配，因此可以应用于任意软件系统的测试辅助分析。而传统的白盒在产品实现上以采集和分析总体覆盖率为主，没有能力将覆盖细化到用例层级，因此传统的白盒测试囿于覆盖率的概念中，无法实现更高层次的测试辅助分析需求。星云测试产品的技术优越性及应用的易用性，使它成为新一代软件测试技术流的中坚力量。星云精准测试在企业应用场景中，为了方便客户还设计了完全静默的“傻瓜”运行模式，客户基本无需增加额外的学习成本。比如测试工程师打开测试用例的excel表格，当他准备执行某个用例的时候，只需点击这一项测试用例。随后通过VBA技术，直接调用星云精准测试的后台接口，再附加一整套深入应用后台执行线程的用户标签技术，就可以将用例和代码关联和分离出来（这里说的分离是指类似于J2EE服务端后台应用）。在对外提供多用户并发访问的情况下，可分离出每个用户执行的用例所对应的相应代码。前面我们提到功能和代码这两个量子数据的重建，以前主要出现在研发/开发人员相对比较零散的执行单步调试功能的时候（即单元测试），无法存储。国外白盒工具因其设计基因的限制，无法支撑超大型、高复杂度的系统级测试需求。在星云精准测试体系中，只要测试工程师执行测试用例，几乎不需要额外付出，在建立测试用例与数据的对应关系的同时，瞬间即可将海量数据实时采集并存储起来，用于后续测试大数据的分析和运算上。它的内核设计，使之可以轻松应用在数亿行的超大型应用上，实时采集、存储测试数据，而对原有系统的响应性能不产生干扰。星云精准测试对软件测试体系是重大的技术革新，它从以下几个层面改变并提升了测试：对软件测试的深度进行了大幅度的拓宽，让计算机有能力直接对测试用例进行辅助分析，给出更深入的测试决策分析依据。传统测试主要通过人工业务测试发现缺陷，定位缺陷必须由开发人员进行，二者信息没有精确的数据交互。精准测试主要基于测试人员标识的用例状态，以及自动记录的用例对应的代码路径进行频谱分析。它可以自动计算缺陷产生的代码位置，在发现缺陷的同时，同步产生缺陷定位的结果数据。精准测试提供的测试用例的聚类分析，是基于测试用例的路径空间距离进行聚类，聚类的结果可以直接对用例执行正确性进行审核，对用例进行等价类划分、分析缺陷密集区以及对用例执行分布进行评估等。精准测试提供的回归用例选取结果，经由海量的计算精准推荐而来，总体算法思路与人工分析的思路是类似的，采用人工智能算法模式把大量的计算完全交由计算机去总结分析，精准、稳定、可靠、高速。这个功能相当于解放了测试和开发团队大量的人力资源，彻底解决因团队成员变更而引入的未知风险。精准测试开辟的测试方法新体系，支撑了黑盒测试快速提升测试效能比的刚需。精准测试对于企业来讲，相对于比需要人工编写、维护庞大自动化脚本的自动化测试，工作量是低很多的。精准测试和自动化测试是并行的技术方向，企业应用可以根据各自团队的特点来选择，并没有绝对的应用时序依赖关系。自动化测试近些年的应用遇到一个广泛的批评就是：让测试团队疲于应付用例的编写而不是测试用例设计等测试核心技术。精准测试属于测试分析系统，着眼点和立意相对较高，在测试理论、方法和商业应用落地验证与成果上，形成较好的整体闭环。它把测试需要关注的核心，引领到一个正确方向上来。精准测试在技术特性上解决了测试结果可信性的问题。在精准测试之前，我们所见到的所有测试数据都是易伪造、易篡改的。例如我们通常使用的测试管理系统，一个用例是否被有效执行，绝大部分是在测试管理系统中被人工录入的。精准测试是在用例动态执行过程中，由计算机内部算法真实记录对应的程序运行逻辑，然后形成后面对测试数据进行精确分析的数据源基础。所以其底层程序运行的数据是没有办法也绝对不允许进行伪造和篡改的。精准测试果断去除了阻碍测试行业发展的重要障碍，让测试的结果精准化、可量化、可衡量化、可信化。此举，将大幅减低测试行业本身的管理成本，有效推动测试行业的快速、健康发展。精准测试大幅提升了开发和测试部门的协作效能。前面提到全景调试器，测试工程师执行完用例，即时产生代码层级的全景调试数据；测试完成后一旦用例存在缺陷，那么基于这个全景调试图以及高度可视化的数据路径追溯，开发人员可以直接对缺陷进行定位，不需要在开发环境下重现缺陷，再单步调试以解决问题。实施精准测试之前，开发人员苦于很难有效参与对测试用例进行审核；实施精准测试后，用例的执行结果都映射到了代码层，开发人员通过代码的覆盖视图很容易就可以协助测试人员补充和确认用例，开发和测试的协作变得非常简单和直接有效。      不可否认，在精准测试之前，开发和测试存在沟通不畅的问题。通过精准测试在项目中的有效实施我们会发现，精准测试可以帮助开发提供非常有价值的数据： 例如代码和用例的反向追溯可以帮助开发人员修改代码做参考，精准测试自动计算回归范围减轻了开发人员必须协助测试进行分析的工作量，因此，精准测试对开发和测试来讲，是一举两得、相得益彰的。星云精准测试发明了多个全新的、适应敏捷迭代开发模型下的覆盖率计算方法。覆盖率是白盒测试最基本的技术，但是随着敏捷迭代的开发模式，即使最高端的白盒测试工具已经几乎没有用武之地，原因就在于由于迭代很快，在某个版本上通常只能采集少量的覆盖率后新版本就发布了。本应在一个版本上分析的覆盖数据，分布到了数个代码结构不一样的程序版本上，因此原有的统计方法和参考意义基本上都失效了。精准测试提供了累计覆盖率，能够将多个版本的覆盖率以最新版本的代码结构进行投影，在控制流上进行累加。这样测试团队无需关注每个版本的覆盖情况，即可关注一个完整测试周期内所有版本的累积覆盖率。另外，考虑到敏捷迭代每个版本的测试需求，即：针对特定模块和功能范围进行测试（并不是全量测试），精准测试提供了相关覆盖率的计算方法。它可以自动圈定某个用例和用例集有关的代码范围（这些也是基于用例和代码的关系分析基础上动态计算的），在运行少量用例或者某个功能模块的情况下，它可以自动确定相关代码，把不相关的代码从覆盖率的分母中过滤掉。这样相关覆盖率在仅仅运行部分少量用例的情况下，依然具有很强的统计和参照意义。第三章 精准测试的定义精准测试定义：由中国团队发起并原创完成测试理念设计和商用产品研发的全新测试技术。旨在测试用例执行过程中，全自动建立任意运行模式的软件系统的功能点与源代码之间高度的可视化追溯机制，获取功能点相关的代码覆盖率并进行精准回归等测试用例深度辅助分析算法的应用。精准测试是测试理论界首次同时使用测试用例及其相关代码两个关键因子，进行质量综合考量和分析的创新测试方法体系。3.1 基本定义星云精准测试在测试用例执行过程中，可以同步全自动建立任意运行模式的软件系统功能点与源代码之间的高度可视化追溯机制，即通过内部算法能够将缺陷对应的代码出错位置直接定位出来；能够获取功能点相关的代码覆盖率并进行精准回归等，使测试用例深度辅助分析算法得以强化应用。这是软件测试首次同时使用测试用例及其相关代码两个关键因子，进行质量综合考量和分析的创新测试理论方法体系。这种有效的数据追溯与“量子联动”的突破性技术特性，大大增强了测试的深度与广度，打破了测试部门的成长天花板，为测试过程本身的价值挖掘和测试数据资产的增值，提供了必要而充分的条件。3.2 关键技术精准测试体系贯穿整个软件测试生命周期。精准测试主要侧重于系统级测试，在单元测试、集成测试、系统测试、验收测试、回归测试中，均能赋予测试数据强大的追溯能力。关键核心技术有：测试用例和代码逻辑的双向追溯，测试示波器、覆盖率可视化、回归测试用例的自动选取、缺陷最后执行时序分析、智能缺陷定位、敏捷环境下多版本白盒测试数据的聚合、聚类分析、结合代码结构与动态数据的测试漏洞检出等。精准测试在测试用例执行过程中，为用户从底层自动建立任意运行模式的软件系统功能点与源代码之间的可视化追溯机制，使用户获取用例级的代码覆盖率等多种高级测试数据。这一突破性的创新智能算法，有力的打破了软件开发、测试、维护及管理人员等之间的数据孤岛状态，实现了软件测试过程和结果的高度精准可视化，在软件高可靠性和高可信度方面，提供了全面而有力的数据支撑。精准测试运行模式是灰盒模式，即：可以在黑盒功能测试的时候，同步完成数据采集和分析计算，让“点测”团队也可轻易切入到精准测试模式，无需改变现有测试形式与流程，不增加额外的技术学习与转换成本。3.3 应用范围精准测试适用于任何形态的软件系统。星云精准测试可应用于各种软件包括嵌入式系统、分布式系统、web应用系统、单机软件系统等各类软件的测试，并且完全不受限于被测试软件本身的业务需求。3.4 用户收益实现从发现缺陷到预防缺陷的转型。减少因为缺陷而对整个研发运维流程造成的返工成本。使发现缺陷前移，减少因项目后期的严重缺陷而导致产品交付延期、成本增高，影响交付质量。建立跨需求、开发、测试等部门的测试协同平台。实现业务数据可追溯化和路径可视化。优化技术与业务方案。根据不同的质量要求，优先级顺序、技术实现手段等，实现智能灵活的技术方案推荐、交付和应变机制。减少无数据支撑造成的内耗。企业“精准众测”平台，支撑千人团队同时在线。测试数据可以根据管理需要做分析，为企业内的成本管控提供选型参考。实现跨地区，跨部门的业务人员，开发人员和测试人员的测试协同，即使不在同一办公地点的人员，也可针对测试需求，测试任务，测试用例和测试缺陷等方面进行远程沟通和实时协同作用，最终完成整个测试过程的实施。支持敏捷开发与测试模式。关注新功能的增量测试，支持自动化回归测试，实现高效的IT交付。第四章 精准测试的基础架构介绍4.1 精准测试的技术架构精准测试从某些层面来讲，赋予了测试用例真正的生命力。测试用例是测试数据的一种，当测试数据实现路线可追溯可视化的时候，一些高级算法的强大能力就可以显示出来。我们从精准测试的整体架构图中可以做一具体分析。图4.1-1 精准测试的总体架构图第一层：利用先进的前置编译器，为客户做源码静态结构分析（在客户的实际环境中，根据客户的需求进行相关的技术配合）；第二层：将处理好的系统程序放入测试环境运行，测试工程师通过人工或程序自动化的形式，开始执行用例（人工执行用例可以和测试管理平台或者Excel表格方式进行对接)，精准测试的 “软件示波器”采集运行数据并进行高速智能运算，获取精确的测试数据；第三层：根据采集的代码与对应的测试用例，在星云精准测试平台中实现用例与源码的互相追溯；第四层：通过精准测试的分析平台，可以对测试数据进行缺陷定位、用例聚类分析、回归测试用例和最小测试用例集等功能的计算，用户还可以根据需求，批量生成相应的测试报告，或进行测试数据高级分析。图4.1-2 精准测试的用例魔方在总体业务架构图的左上角区域，我们可以看到“用例魔方”几个字。大家可能会比较好奇“用例魔方”的涵义，它是精准测试中非常核心的高级回归功能之一。所谓“魔”是精准测试核心算法所赋予的超能力，所谓“方”实际上是代表测试用例的集合，每个测试用例用一个小方块标识，所有测试用例的集合用一个大方块。当我们把精准测试的和用例分析相关的功能画成架构图形表示的时候，它自然而然地看起来就像魔方。精准测试体系中，测试用例对应的代码逻辑精确而完整的实现了全自动化的追溯和存储，因此赋予了测试用例深入分析的基础能力。在精准测试的用例魔方中，目前存在三个面（随着后续功能的增加，将增加分析的面）：即回归测试用例选取、测试用例聚类分析、测试用例最小化，同时辅之以智能缺陷定位技术。当测试用例与代码的追溯关系建立的时候，测试魔方的核心功能区即同步构建出来。为数据的多角度分析，提供了丰富的资源素材库。4.2 软件示波器软件示波器是星云精准测试独有的功能，它如同软件的质量运行情况“追溯穿行器”一样，在测试工程师按下启动键的同时，即时开始建立用例与代码的自动关联。示波器把采集到的测试数据通过可视化的窗口界面进行实时展示，内容涵盖采集到的块、条件和函数信息。蓝色波形代表写入的数值，黄色波形表示读取的数值，用户可以清晰的看到被测系统的数据变化。它如同心跳监控仪一样，如果被测试程序发生了崩溃，软件示波器就像人的心脏停止跳动一样，一根横线拉直向用户报警。如果正常采集到数据，会有持续的波形展示出来，高效而精准地监控程序细微的运行状况。示波器精密捕获每个软件单元任何微小的运行波动和行为改变，支持多次运行数据的比对。它可以根据需要记录崩溃前的至少50个块，使“崩溃重现”变得轻松简单。软件示波器中的测试用例可以从现有的测试管理系统导入进来，先选中用例点击开始，驱动被测试系统运行后，软件示波器就会采集到程序内部运行逻辑对应的波形信息。用例执行结束后，点击停止。这个用例运行阶段的数据，通过开始和结束的点击，边界就记录下来了。图4.2-1 软件示波器面板的正下方可以展示函数的各种调用信息。包括类、函数，参数类型等。清晰的列示出参数列表、类运行情况、内存检测数据、数据库拦截等多角度的数据分析追溯情况信息。示波器观测的维度较多，用例与代码的追溯是精准测试的基础功能，后面的高级算法都在这个基础上展开。用例和代码的追溯就像一个全景的调试器，只要功能由测试人员运行，所有的内部代码执行逻辑瞬间就可以展示出来。通过测试数据的反向追溯分析，开发人员可进行一致性修改，避免修改引入新的缺陷，通过正向追溯结果，开发可对用例的执行进行全面掌握，可用于快速修复缺陷和详细实现确认。同时软件示波器也提供一个辅助的等价类划分的功能，它将一个用例从开始到结束所执行的路径信息终值，完整记录下来。如果两个用例终值不一样，就可以确定为不是等价类。对于很多从功能表面很难界定是否等价类的测试用例，软件示波器可以给出精确结果。因此软件示波器的价值与意义在于：（1）只要测试开始执行，即可以透明方式高速采集功能运行过程中对应程序的运行逻辑。（2）在系统高速运转下采集，可保证对原有应用无干扰，超过1500w/s的采集速率。（3）可采集程序的条件，执行路径，执行参数，内存使用等动态运行数据。为了方便客户在运行项目测试时，一边对被测系统做实时数据监测，一边同步观察到示波器里面数据写入和读取的波形，星云做出了实时数据监测的悬浮窗缩略图，减少了切换带来的工作量。它不影响原有被测系统的界面，以半透明悬浮的方式展示在被测试应用界面的前面。图4.2-2 软件示波器悬浮窗4.3精准测试的双向追溯精准测试的测试用例和代码的双向追溯功能，是精准测试核心技术之一。如同前文的“量子纠缠”，即运行测试用例的同时，精准测试可以通过程序自动的记录并追溯到这个测试用例相应执行的代码。如果测试人员关注某一些代码行，它可以追溯出哪些测试用例在运行过程中运行过这段代码。通过这个技术特性，测试工程师的每个测试用例都可以进行量化分析和统计，提供了开发人员和测试人员之间精准的数字化交流依据， 增加测试和开发的交流效率。双向追溯技术记录了每个测试用例对应的程序内部的执行细节，细致到每个条件、分支、语句块的执行情况。开发人员亦可通过双向追溯的结果去理解程序逻辑，进行软件维护以及进行可一致性的修改。4.3.1 双向追溯技术正向追溯将测试用例和代码执行信息自动关联，可追溯到函数级别及代码块级别；通过正向追溯可直接把BUG定位到故障和缺陷逻辑相应的代码，并提供最后运行的时序数据；通过正向追溯自动记录产生功能对应的详细设计实现，辅助软件解耦和架构分析。图4.3.1-1 双向追溯(正向)-测试用例追溯到代码图4.3.1-2 双向追溯(正向)-测试用例追溯到代码4.3.2 双向追溯技术反向追溯将代码执行、函数、代码块级别和测试用例执行信息自动关联；通过反向追溯可直接观察代码变动所影响的测试范围；协助开发，进行代码修改后影响功能的范围评估；协助测试人员对代码修改部分所影响的测试用例进行评估。图4.3.2-1 双向追溯(反向)-代码追溯到测试用例图4.3.2-2 双向追溯(反向)-代码追溯到测试用例4.3.3 数据追溯技术-追溯测试用例的全景调用精准测试通过正向追溯把测试用例运行的代码执行进行了全景绘制，在全景图中，测试人员可以有效的观察到函数之间的整体的调用与走向，观察出被测模块与上层之间的调用关系。图4.3.3 测试用例运行的代码整体调用第五章 精准测试的核心组件与功能精准测试的核心组件与功能：软件测试示波器、用例和代码的双向追溯、智能回归测试用例选取、覆盖率分析、缺陷定位、测试用例聚类分析、测试用例自动生成系统等，完整的构成了精准测试技术体系。精准测试系统本质是一套强大的计算机开发与测试系统，实现了数据的可视化联动，以及开发辅助分析。它的关键技术赋予了测试用例和代码强大的相互追溯能力，随后衍生实现了很多高级测试功能与算法。精准测试系统将用例深入到代码层分析后，可以大幅改进人工测试所产生的各种问题。接下来将从风险控制、工作协同、敏捷迭代方面详细解析精准测试的核心功能和实际收益。5.1 风险控制5.1.1 七种测试覆盖率星云精准测试提供7种测试覆盖率：分别为：SC0语句块覆盖率、True覆盖率、Both覆盖率、CDC覆盖率、Branch覆盖率、MC/DC覆盖率。用户首先选择分析覆盖率的维度，例如选择了“SCO语句块”维度，那么系统就会将被测试程序的所有语句块结构展示出来，并且用颜色表达覆盖情况，绿色代表覆盖，深蓝色代表未覆盖。同时告知覆盖率的分子和分母都是哪些，非常清晰的展示覆盖率可视化结果。精准测试在前期已经对程序的静态结构进行了深度的分析，因此用户在覆盖率可视化界面，根据选择的维度在代码层面上把需要展示的结构单元都结构化的展示出来。例如图5.1.1-1 七种测试覆盖率中的第二张图 图5.1.1-1 七种测试覆盖率MC/DC覆盖率可视化MC/DC覆盖率，即修正判定条件覆盖，该覆盖率数据 MC/DC是DO-178B/C Level A认证标准中规定的、欧美民用航空器强制要求遵守的覆盖率标准。MC/DC覆盖率可以基本保证被测试软件无缺陷，对于大型系统的可靠性要求很高的一些关键模块，建议采用这个覆盖率标准。MC/DC覆盖简单来说，就是追踪复合条件中每个子条件的真假翻转，在其子条件不变前提下，是否都独立的影响了整个条件的真假值。星云精准测试系统会自动的把各种组合都列好，通过颜色表达哪些子条件已经满足，以及对应满足情况时其他独立子条件的组织情况。图5.1.1-2 MC/DC覆盖率可视化条件组合可视化展示精准测试对于多条件组合的代码，采用了最新研发的条件组合可视化视图进行展示。视图中，用户可以观察到每个条件的真假运行情况，以及条件与条件的组合运行情况。对于测试人员来说，当全部条件组合之间的T与F都完全满足时，即可实现代码全路径覆盖。图5.1.1-3条件组合可视化展示5.1.2 新增代码覆盖率敏捷模式下，因迭代频繁其存量的代码量很大，通常更关注增量覆盖度量。精准测试可以在程序新版本发布后，自动计算新增（变更）代码的范围，给出新增代码的覆盖率。覆盖率的分母中的函数都是变更和新增的函数。与此同时，基于反向追溯的功能，我们还可以给出新增代码对应的测试用例名称。当某个新增函数没有达到很高覆盖率的时候，我们通过反向追溯的用例，可以判定因为哪些功能范围的用例设计不充分，导致了新增代码覆盖率不高。图5.1.2 新增代码覆盖率5.1.3 测试覆盖率范围筛选与再统计在做精准测试或统计覆盖率时，往往测试管理者、开发人员、测试人员为了保证测试覆盖率的正确性，会对某个方法、类进行查看或在统计中把代码中一些废弃的函数、某些特殊情况下无法测试到的代码进行移除（至少是做相应备注），从而让测试代码覆盖统计率达到更加准确。星云精准测试在设计中，通过多种搜索、方法、类、模块过滤等功能，把需要统计的范围进行缩小、不需要统计的去除。根据用户的选择，进行覆盖率再统计展示。图5.1.3 测试覆盖率范围筛选与再统计5.2 工作协同5.2.1 打通开发与测试的隔阂精准测试打通开发与测试的协同工作通道，使得开发与测试能够更好的沟通，提高工作效率。传统模式下，开发人员关注的是代码，测试人员关注的是业务角度的测试用例，彼此的直接关联相对较弱。开发和测试的沟通，基本就是采用自然语言、Excel表格、内部系统等，存在交流信息不够严谨的问题。例如测试工程师发现一个缺陷，提交到缺陷系统，开发需要花费大量时间再行理解、准备数据、复现、调试，直到最后的修正。因为业务上的功能执行和代码并没有明确的关系，通常测试工程师执行完功能测试用例后，让开发人员帮助评审也非常困难。若测试工程师提供的测试结果都是比较模糊的功能逻辑描述，重现缺陷需要花费大量的时间。开发人员修改代码后，对于变更描述，以及变更引起的关联问题描述通常也都很模糊，导致测试又出现新问题。企业采用精准测试技术后，通过执行用例可以直接追溯到对应执行的程序代码块，这样的数据化沟通，将使开发人员和测试人员之间的协同工作效率大大提高。图5.2.1  协同模式5.2.2 源码动静态数据的统一星云精准测试通过插装得到的项目静态结构信息，结合测试后采集到的测试数据，能够精准记录测试的过程，通过这些静态数据和动态数据视图，便于开发人员基于图形化结果进行快速分析。对于不懂开发的测试工程师，通过程序控制流程图的图形以及通过颜色表示的覆盖信息，可以直接看到程序内部漏测的逻辑是什么，也可以通过这些结果直接与开发沟通，进行辅助用例和逻辑的补充。因为内部逻辑的强追溯性并且能够图形化的打开，可以有力保证黑盒测试后期开发快速理解并解决瓶颈问题，保持全程测试的高效执行。图5.2.2-1 源码静态结构与动态测试数据统一图（函数调用图）图5.2.2-2 源码静态结构与动态测试数据统一图（控制流程图）精准测试在程序静态分析的基础上，可以对程序绘制可视化的图形，同时将动态执行的覆盖信息染色到这些视图上。对于不懂开发的测试人员也可以很清晰的看到程序的哪些结构节点没有被覆盖到。例如图形中蓝色的节点是未覆盖的节点，绿色的是覆盖的，因为控制流程图本身有分支，嵌套等各种关系，测试工程师可以很容易判断出覆盖的范围大致是哪些。而如果有开发人员介入，可以更清晰地分析测试工程师执行的用例所遗漏的程序逻辑。图 5.2.2-3源码静态结构与动态测试数据统一视图5.2.3 缺陷最后执行时序分析星云测试可自动捕获缺陷或崩溃发生时，程序最后执行的详细路径信息。缺陷发生后，开发人员能够直接看到缺陷出现时，代码执行的时序和路径信息，直接定位缺陷并排查问题，节省大量的沟通、复现和调试的时间成本。当功能执行发现缺陷后，在软件示波器上可以立即按下“停止”键，那么最后执行的代码序列就可以被抓取到，开发人员可快速定位缺陷最后执行的50个代码块、条件、判断的各种执行信息。在下面视图中，我们可以根据标号（从1到50），看到代码最后的运行时序，在图形里面的每一个绿色小方块为一个代码语句块或者一个条件、判定，在一个大方框下的绿色方块代表一个函数内部的代码块。经过布局算法后产生下述图形。图5.2.3 缺陷最后执行时序分析5.2.4 智能缺陷定位通常测试工程师只是负责发现缺陷，缺陷的具体定位只能交由开发人员来执行。精准测试打破了测试部门的天花板，即通过内部算法能够将缺陷对应的代码出错位置直接定位出来。这相当于增加了测试深度，同时体现了测试数据和测试过程本身的价值。对于测试工程师来说，只要发现用例相似而程序在输出上有对错区分，就可以使用精准测试的智能缺陷定位功能。精准测试平台通过测试人员在功能测试阶段标记的用例执行状态，以及软件示波器自动记录的程序运行频谱，自动分析缺陷的出现的代码块。因精准测试平台可以获取每个用例执行时详细的路径追溯信息，测试工程师只要告知系统用例的状态，例如是否通过是否正确，那么精准测试内部算法就会去根据正确和失败的路径差异进行计算，给出缺陷出现具体位置的可疑度排名。这个功能可以大大增强测试在整个开发流程的参与度和测试数据价值，也让开发人员减少了自己去模拟场景的时间，快速提高开发和测试的协同和配合的效率。对于同类测试用例，经过多组测试可给出非常有效的结果。列出的可疑代码，可直接通过测试过程给出，提升测试的价值及产出。图5.2.4-1 通过功能测试频谱法分析进行智能缺陷定位选择可疑度算法、得到可疑度高的代码块，关联源码后，可根据代码可视化查看具体位置。可疑度计算有一个公式，并不复杂，通常每个代码块有2个变量，四种状态值。分别是：是否执行、是否通过，这样每代码块都有一个可疑度值。星云精准测试提供3种常用计算公式，供大家参考。aep表示通过且覆盖到该块的测试用例的个数、anp表示通过且未覆盖到该块的测试用例的个数、aef表示未通过且覆盖到该块的测试用例的个数、anf表示未通过且覆盖到该块的测试用例的个数。结果表示该块的可疑度。图5.2.4-2 智能缺陷定位展示5.3 精准测试对敏捷迭代的支持5.3.1 敏捷迭代下多版本白盒测试数据的聚合在敏捷环境下由于版本迭代速度很快，每个不用的代码版本上通常只能采集到少量的覆盖率。一旦发布新版本，就意味着代码发生了变化，覆盖率数据就需要重新采集，但是每个版本采集的少量覆盖率，从分析层面上并没有多大的意义。针对以上问题，精准测试给出了“**累计覆盖率”**的计算方法。它将一系列迭代版本的覆盖率，在最新的程序版本上进行投影累加。用户可将一个阶段各个版本的覆盖率累加起来进行分析。算法的思路是以最新版本代码为基础，以某个函数为单位，一直往前累加。直到这个函数在之前的某个版本代码发生了变化，就停止累加。例如下图函数A的4个版本的覆盖都可以累加，是因为这个函数在4个版本中都没有发生变化。而红色的函数B只累加了3个版本，是因为从版本v2.0-2后这个函数发生了代码变更。之前的代码覆盖就不能累加了。星云精准测试-敏捷环境下多版本白盒测试数据的聚合如图所示。图5.3.1-1敏捷环境下多版本白盒测试数据的聚合这种累加是在确保函数代码没有发生变化的情况下，在控制流上对相应节点的覆盖率进行累加。例如下图中3个版本，覆盖率不同的分支和控制流，数据累加后可以看到所有分支都覆盖到了。图5.3.1-2敏捷环境下多版本白盒测试数据的合并分析5.3.2 聚类分析星云精准测试提供的聚类分析功能，根据测试用例的函数执行剖面的向量化信息，对测试用例进行精确的空间距离计算后执行聚类分析。聚类结果可以分析被错误执行的用例，例如不相关的功能点聚类到一起，则说明其测试执行可能存在错误。精准测试提供的聚类分析功能，也可以辅助找到缺陷分布的密集区域。大部分情况下，缺陷分布会呈现2/8的聚集特性。在时间紧张的情况下，我们可以通过聚类结果，每个类选取中心点以及周边几个用例。如果没有问题，就可以去测试其他聚类，如果发现一个类缺陷概率高，那么这个类就需要进行重点测试。通过聚类结果可以分析测试用例的分布密度等信息，辅助进行测试决策。图5.3.2-1 测试密度下图中测试用例分类都有一个名字，这个名字是聚类结果中每个类中心点的测试用例名字，它基本标定了这个类的功能点范围。聚类的大小代表了某个功能范围测试是否足够充分。例如一些应该重点测试的功能，聚类结果中的用例数应该很多；一些小众的功能，聚类中用例数应该比较少。一个类中用例数越多，这个类圆圈比例越大，反之则越小。在聚类的基础上，我们也可以对一个类中的等价类用例进行分析。是等价类的用例，会分成一组专门展示。 图5.3.2-2 聚类分析5.3.3 覆盖率漏洞检出在敏捷迭代过程中，通常没有充分的时间将所有函数的覆盖率都达到一个很高的层级（Level）。精准测试结合代码结构和动态数据综合分析，通过计算直接筛选出潜在的高危测试漏洞，可以在短期内确定高危漏测模块并针对性的解决，帮助用户快速找到严重缺陷。当测试时间不充分的时候，执行完黑盒测试以后，先看测试漏洞列表，里面显示了通过静态信息和动态信息计算，得到的最高风险的漏测点模块。我们可以通过复杂度进行计算，因为复杂度高的模块一般来讲，它是相对重要的模块并且逻辑复杂，如果动态覆盖比较低，我们会优先筛选出来进行排序。处于调用和被调用中间的模块，因为属于中间关键模块，我们也会计算它的扇入扇出，和动态覆盖率信息。如果它的比率很高，将被认为是高风险模块，被筛选出来进行排序。回归时，应优先测试风险指数高的高危模块，补充他们的覆盖率。图5.3.3漏洞检测列表5.3.4 最小测试用例集精准测试也可以对用例集进行优化。比如用户有大量用例的情况下，尤其是自动化用例集含有长期维护的冗余用例。精准测试平台可以对很多重复用例的逻辑进行筛选和过滤，优化出满足当前总体覆盖的最小用例集。图5.3.4星云测试最小测试用例集第六章 精准测试支持不同剖面的分析报告在时间有限，经费有限，资源有限的情况下，我们既要考虑测试是否充分，也要顾及时间、人员、设备配置等限制条件。精准测试可以支持企业不同剖面的软件质量分析需求。6.1 详细的测试总结报告内容测试资源分析：多少人，多长时间、整体测试有效率及执行率测试结果分析：描述需求的测试结果，系统实现了哪些功能点，哪些还没有实现缺陷情况分析：缺陷复现、缺陷处理、缺陷数量、属性、状态分布，缺陷预防、缺陷收敛度度量指标分析：测试覆盖率、测试执行率、测试执行通过率、测试缺陷解决率效率指标分析：进度偏离度、缺陷发现率、用例执行效率和质量等高风险识别与排序：注明当前项目中面临的最严重、最优先的问题整体评估：哪些功能已经实现，哪些功能还未实现，还遗留哪些问题，遗留缺陷分析优化建议：测试过程优化，从测试组的角度为测试工作提出建议图6.1 星云测试的差异报告分析6.2 高级回归测试报告对前期测试执行阶段发现的问题、缺陷集中的功能，业务比较重要且使用频繁的功能进行再次测试，确保系统上线后，已被修复的问题不会重新出现，重要的、高优先级的业务不会发生错误。图6.2智能回归测试用例选取6.3 测试用例库评估报告软件测试的主要工作，是把软件需求映射为软件测试。测试用例是软件测试全过程的核心，也是测试执行环节的基本依据。精准测试充分满足软件测试执行过程中的各种指标：测试用例执行进度测试用例通过率测试用例颗粒度分析识别无用的测试用例识别冗余的测试用例从侧面提供增添新测试用例的依据从侧面提供调整测试用例库结构的依据图6.3 测试用例最小集6.4 精准测试的VIP企业内网私有云可信化报表星云精准测试提供多个剖面的高可靠性测试质量进度追踪报表。当客户端录入测试用例并采集数据后，用户内网web端将产生实时、详实的测试数据分析报表。该报表与普通的测试管理系统不同：普通的测试管理系统人为录入数据的情况比较多，使得数据状态的真实性没办法确切保证。精准测试提供的报表，底层数据来自于执行测试用例时候代码数据的采集，通过专用底层接口上传，完全无法进行数据调整或者篡改和伪造。通过浏览器登录测试系统，选择需要跟踪的项目，就可以实时对整个测试的质量、进度、人员进行精准的分析和管理。企业内网云端管理系统展示的数据基于精准测试数据的分析，所有数据原生精确，支持移动测试+本地测试。测试团队、开发团队、甲方负责人等多种角色都可以登录系统，从各个层面对测试、软件质量进行分析。图6.4项目汇总展示6.4.1 精准测试的VIP企业内网私有云-测试效率的直观展示精准测试报告可直观分析每天的测试效率，通过代码模块和复杂度关系图，看到函数群落测试情况分布及趋势，可直观精准识别系统测试所处阶段。每日增长覆盖率报表：管理者可以清晰的看到整个团队的效率趋势变化，比如刚开始测试的时候覆盖率增长快，到了黑盒测试瓶颈点上升就很慢了。这时候精准测试技术就开始发力，可以清晰地看到它在弥补效率损失方面的优势。覆盖率和复杂度报表：可以很直观地看到测试的质量深度，例如在测试不充分的时候，复杂度高的模块通常覆盖率都比较低，统计点分布自一个左上角的区域（表示高复杂度+低覆盖率），而当测试深入进行，这些点就会向右侧移动。管理者可以非常直观的看到系统测试的充分程度和上线的质量把握。图6.4.1-1 覆盖率每日增长趋势图与黑盒测试瓶颈图6.4.1-2 测试效率换档点与测试深度趋势观察表6.4.2 精准测试的VIP企业内网私有云-测试用例排行图测试用例排行分析报表：可直观展示参与测试工程师所执行的用例数、通过率和缺陷率，真实记录并分析每个测试用例的实效性。星云精准测试-测试工程师实效精准分析系统，将参与的测试工程师所执行的用例从逻辑覆盖映射到代码覆盖，真实记录并分析每个测试参与者的工作实效。以逻辑覆盖为基准的而不是用例数量为考核标准。图6.4.2 测试用例排行图6.4.3 精准测试的VIP企业私有云-测试用例双向追溯与覆盖率可视化通过用户的内网精准测试web报表，可以追踪每个测试用例执行的覆盖率和执行的函数路径信息，那些没有真正执行的用例，将无法伪造其对应的覆盖率信息。图6.4.3-1测试用例双向追溯追踪每个用例执行的函数信息以及具体的代码覆盖信息，在web端展示代码覆盖率视图，更具体的分析用例的执行情况。图6.4.3-1覆盖率可视化6.5 精准测试在数字化转型中的作用 完成数字化转型。提高软件交付质效、实现快速迭代持续交付，有效呈现测试价值。培养业务和测试的“两栖专家”。从不同角度提供有价值的数据依据，使测试团队既能熟悉业务知识、业务场景，又具备较强的业务分析评估和整合创新的能力。数据化交付。实现企业内部云平台建设、明确各工程活动环节的交付物和交付标准，并将质量验证标准、验证手段和监控工具嵌入流水线，保证各环节的有效性，对质量趋势进行提示和预警，及早发现缺陷，实现质量可视、过程可追溯、可审计。建立测试数据资源池，整合测试资产。利用大数据、人工智能等技术建立质量智能分析模型等，为“产品质量智能分析平台”提供有效数据。减少因人员变动而产生的成本影响。一般外包人员的流失率普遍为20-40%左右，重新招聘和培养，将对项目进度及成本进度，造成很大影响。因篇幅限制，完整版可查看 星云测试官网（www.teststars.cc）

隔离程序的每个部件，在隔离环境中运行测试用例。karma.conf.js ：文件是为了告知 Karma 需要启用哪些插件、加载哪些测试脚本、需要哪些测试浏览器环境、测试报告通知方式、日志等等。具体配置内容参见 karma.conf.js。https://karma-runner.github.io/5.0/config/configuration-file.html>测试文件的扩展名必须是 .spec.ts，这样工具才能识别出它是一个测试文件，也叫规约（spec）文件"test": {     "options": {         "codeCoverage": true     } }Jasmine Angular 单元测试是使用 Jasmine 框架来编写的。基础知识describe(string, function)：是 Jasmine 的全局函数，可以理解为一个测试集（Test Suite），主要功能是用来划分单元测试的。describe 可以嵌套使用。it(string, function)：可以理解为测试用例。Specs 通过调用 it 的全局函数来定义。每个 Spec 包含一个或多个 expectations 期望值来测试需要测试代码。Jasmine 中的每个 expectation 是一个断言，可以是 true 或者 false。当每个 Spec 中的所有 expectations 都是 true，则通过测试。有任何一个 expectation 是 false，则未通过测试。而方法的内容就是测试主体。每个 Matchers 实现一个布尔值，在实际值和期望值之间比较。它负责通知 Jasmine，此 expectation 是真或者假。然后 Jasmine 会认为相应的 spec 是通过还是失败。所有的 expect 都可以使用 not 表示否定的断言。JavaScript 的作用域的规则适用，所以在 describe 定义的变量对 Suite 中的任何 it 代码块都是可见的。beforeAll：每个 suite（即 describe）中所有 spec（即 it）运行之前运行，整个suite里只运行一次afterAll：每个 suite（即 describe）中所有 spec（即 it）运行之后运行 xdescribe：该 describe下的所有 it 将被忽略，jasmine 将直接忽略这些it，因此不会被运行 // 引入相关模块 import { async, ComponentFixture, TestBed } from '@angular/core/testing'; import { RouterTestingModule } from '@angular/router/testing'; import { HttpClientTestingModule } from '@angular/common/http/testing'; import { BackupListComponent } from './backup-list.component'; import { DebugElement } from '@angular/core'; describe('HorizontalGridComponent test', () => {    let component: HorizontalGridComponent;  let fixture: ComponentFixture<HorizontalGridComponent>;     // 配置 TestBed 环境    beforeEach(async(() => {       TestBed.configureTestingModule({          imports: [            HttpClientTestingModule          ],          declarations: [HorizontalGridComponent],   }).compileComponents();    }));    beforeEach(() => {         // 创建一个HorizontalGridComponent 的实例   fixture = TestBed.createComponent(HorizontalGridComponent);         // 使用 fixture.componentInstance 来访问组件实例   component = fixture.componentInstance;         // TestBed.createComponent 不能触发变更检测，使用 detectChanges() 触发检查。   fixture.detectChanges();  });     it('should create', () => {   expect(fixture).toBeDefined();        expect(component).toBeDefined();  });  it('should have <h3> with "Hello"', () => {         // const El: HTMLElement = fixture.nativeElement;         const De: DebugElement = fixture.debugElement;         const El: HTMLElement = De.nativeElement; // nativeElement相当于debugElement的一个属性         // js原生的querySelector api去获取h3标签         const p = El.querySelector('h3');         // 判断h3标签的内容         expect(p.textContent).toEqual('Hello');     });     it('should find the <h3> with fixture.debugElement.query(By.css)', () => {         const De: DebugElement = fixture.debugElement;         const El = De.query(By.css('h3')); // nativeElement相当于debugElement的一个属性         // js原生的querySelector api去获取h3标签         const p: HTMLElement = El.nativeElement;         // 判断h3标签的内容         expect(p.textContent).toEqual('Hello');     });    afterEach(() => {       TestBed.resetTestingModule();    }); });置好 TestBed 之后，调用它的 createComponent() 方法，它会创建一个 HorizontalGridComponent 的实例，把相应的元素添加到测试运行器的 DOM 中，然后返回一个 ComponentFixture 对象。ComponentFixture 用来与所创建的组件及其 DOM 元素进行交互。获取组件元素 nativeElement 和 DebugElement。 前者原生 DOM 元素，属性取决于运行环境，如果是浏览器，就提供浏览器的一些api，后者是由 Angular 进行包装可以安全的横跨其支持的所有平台运行并提供诸如 query 或者 triggerEventHandler 事件dom操作等方法。TestBed.createComponent 不能触发变更检测，使用 detectChanges() 触发检查。运行完成后，控制台输出：chrome浏览器输出：

压测模型，arm部署jmeter->slb->service1->service2压测时报502，抓包如下slb侧抓包看到service1发来FINservice1侧抓包，发现60s内未给slb返回200 OK，接着发FIN断链service2打桩不做处理，直接返回，依然存在上述问题，查看service1的metrics日志如下发现consumer_wake_consumer阶段最大耗时60sCSE SDK升级至1.2.0.B017r4，问题依然存在service1的配置如下APPLICATION_ID: HIDSCservice_description:  name: dsc-edge-service  version: 12.20.1  properties:    allowCrossApp: falseinstance_description:  properties:    x-is-gray: 0servicecomb:  service:    registry:      address: https://10.33.213.42:30100      instance:        healthCheck:          interval: 10          times: 3        watch: true        diagnose:          interval: 12  rest:    address: 10.33.213.43:8087?sslEnabled=false    server:      thread-count: 16    client:      thread-count: 8      connection-pool-per-thread: 8  loadbalance:    voipServiceManage:      strategy:        name: accountIdHashServer    retryEnabled: true    retryOnNext: 2    retryOnSame: 0    isolation:      enabled: true      enableRequestThreshold: 20      errorThresholdPercentage: 20      singleTestTime: 10000  handler:    chain:      Provider:        default: bizkeeper-provider      Consumer:        default: loadbalance  executor:    default:      group: 4      maxThreads-per-group: 200      coreThreads-per-group: 200service2的配置如下：APPLICATION_ID: HIDSCservice_description:  name: dsc-trs-service  version: 11.41.2  properties:    allowCrossApp: falseinstance_description:  properties:    x-is-gray: 0servicecomb:  service:    registry:      address: https://10.33.213.42:30100      instance:        healthCheck:          interval: 10          times: 3        watch: true        diagnose:          interval: 12  rest:    address: 10.33.213.132:8090?sslEnabled=false&protocol=http2    server:      thread-count: 16      verticle-count: 16      http2:        useAlpnEnabled: true        concurrentStreams: 100    client:      thread-count: 8      verticle-count: 8      connection:        maxPoolSize: 30        idleTimeoutInSeconds: 30        keepAlive: true      http2:        useAlpnEnabled: true        multiplexingLimit: -1        maxPoolSize: 16        idleTimeoutInSeconds: 0  loadbalance:    voipServiceManage:      strategy:        name: RoundRobin    retryEnabled: true    retryOnNext: 2    retryOnSame: 0    isolation:      enabled: true      errorThresholdPercentage: 20      enableRequestThreshold: 20      singleTestTime: 10000      continuousFailureThreshold: 2  handler:    chain:      Provider:        default: bizkeeper-provider      Consumer:        default: loadbalance  executor:    default:      group: 2      maxThreads-per-group: 200      coreThreads-per-group: 200求助上述问题原因及解决方案

背景在一次DevOps线上活动的提问环节中，有这样一个问题：“我们公司刚刚完成了DevOps转型，搭建了一条流水线，流水线确实让我们部署上线的效率提升了，但是也更快的让客户当上小白鼠，因为我们让问题更快的暴露出来了……”可以想象，一个开发人员开心的点了一下流水线的启动按钮，然后就开心的下班了，然后用户看着屏幕的404，然后就没有了然后（坏笑）……其实这真不是开玩笑，如果将项目中的流水线发布权限下放给了开发，那么404真的就是很现实和普遍的问题，因为很多开发认为自己的工作就是开发。像这样的坑你是否也掉进去过，我们一起基于此，来看看什么样的流水线是不坑人的吧。问题分析这些年来，DevOps已经逐渐的深入到软件企业中，尤其是一些互联网的项目中，需要更快的适应市场的变化迎合用户的需求，传统低效的方式来部署生产环境已无法存活， DevOps的流水线（部署流水线）也应运而生。然而在企业追求高效的同时，往往又引入了新的问题——高效的将bug展现给了用户。项目开发的前期，代码都是比较简单的，开发团队的人员也比较少。但慢慢随着时间的推移，代码越来越复杂，团队成员越来越越多，经手变更的也越来越频繁。一旦出现了问题，作为一个开发人员往往首先会想到的是——快速修复上线。DevOps在速度这点上确实帮了大忙，经历过传统部署发布的同学肯定深有体会。但是这样往往却又伴随了新的问题——“打地鼠现象”。何为打地鼠现象? 简单的说，就是一个问题你修复了，可能又会蹦出来几个新的问题。长期下去，不仅开发团队压力大，客户更是成了“小白鼠”。其实，这并不能把问题归结到部署流水线身上（无辜躺枪），借助流水线的快速发布，只是将问题更早的暴露出来，其归根结底上，问题还是出在质量上。那么，我们就不得不谈到——质量内建。戴明（William Edwards Deming）曾提出“问题发现得越早，修复的成本越低”，有数据指出85%的缺陷都是在代码编码阶段引入的，然而大部分的缺陷并不是在编码的时候发现的，而是在之后的测试阶段发现的，甚至是已经上线后。而且随着越往后发现缺陷，修复的成本也越高。来源《Applied Software Measurement:Global Analysis of Productivity and Quality》按照STICKYMINDS网站上上的一篇名为The Shift-Left Approach to Software Testing的文章中所给出的（如上图），假如在编码阶段发现的缺陷只需要1分钟就能解决，那么单元测试阶段需要4分钟，功能测试阶段需要10分钟，系统测试阶段需要40分钟，而到了上线之后再发现可能就需要640分钟来修复，这可以说是很难让人接受的，所以质量内建是至关重要的。在质量问题上，当然离不了我们老生常谈的开发阶段的编码规范、重构、检视等活动，这里不做叙述。随着DevOps的引入，我们需要将质量内建，加入到DevOps的各个环节中，而部署流水线就是贯穿这些环节的重要工具。某种程度上说，部署流水线的质量基本上决定了软件质量——是带伤上阵还是安稳的睡大觉，部署流水线是关键。那么如何算是一条不坑的部署流水线呢？解决方案测试左移（Shift-Left testing）如上面所提到了，在开发完成后，越到生命周期的后面修复的成本越高。那么基于这样的情况，测试应该尽早的开始。在传统的开发周期中，问题都在什么时候发现的呢？如下图所示：来源《Applied Software Measurement:Global Analysis of Productivity and Quality》可以看到传统模式下，问题很少会在开发阶段发现，而现在提出的测试左移，就是在要在开发阶段尽可能的发现更多的问题，而避免问题被发现在之后的阶段。这也就是我们搭建一条不坑的流水线最基本的理念之一。一般来说，在流水线的构建阶段我们会加入静态代码检查，比如使用Findbugs、Sonar等。可按需自行设置是否随代码提交而触发检查（推荐），或伴随持续集成的工程实践开展，可一天一次或多次，这就保障了不会掉进最基本静态代码层面的坑。此外在流水线的设计上一定要有API、UI等自动化测试。一般来说，可按部署到不同的环境，对应创建不同的流水线阶段，如集成环境有对应的流水线的集成阶段，测试环境有其测试阶段。当部署时，就可以在对应的阶段中加入所需要的测试活动。如当开发人员修复某一个bug后，想要保证其他功能的成长，可以通过在流水线的自测阶段通过加入API的测试等。总结来说，就是在流水线的构建阶段加入静态代码的检查，在部署阶段加入自动化的测试活动，以保证代码的质量和功能的可用。质量要求在质量建设中，不能仅停留在质量管控的基本要求——有，还要注重质量的高低。因为某种意义上来说，较松的管控等于没有，这也是最坑的地方——有等于没有，试想如果流水线中只有某个API测试的情况，那么验证的基本就是这个服务有没有成功启动而已。那么，这就需要加入一个质量阀值的要求。质量阀值的高低是一个衡量质量高低的重要标准。这个阀值可以是接口覆盖率达到多少，也可以是静态代码检查出来问题的数量等。一个严格的质量门禁可以说流水线完成后发布上线的定心丸，这也就可以用来解决了上文提到的“打地鼠”现象。一般来说，接口测试的覆盖率建议达到百分之百，而考虑单元测试和接口测试某些程度上的重复以及UI测试的ROI等因素可按需进行配置，因情况不同这里不做叙述。对于代码检查来说，也可设置某一个数值作为阀值，这个数值可以按照某种规则设定。如一般问题记1分，严重问题记5分，安全问题记8分等，当检查后所累积的数值超过10则不能发布或进入下个一个阶段，当然数值越低越好，具体设置（代码检查的维度不再此叙述）也需按实际情况而定。此外，还可以考虑如开源第三方jar包的扫描、安全漏洞扫描等活动。如果考虑划分的更有层级和模块化，相对于接口测试或静态代码检查的质量建设，扫描的可以单独作为一个阶段按需设置。总结来说，质量建设按照项目的实际情况来设置，而且对于团队来说，质量永远不仅仅是某一个人或团队的事情，而是所有人的事情。相对于质量的坑来说，意识上更是我们应该避免掉进的坑。如了解更多请访问华为DevCloud流水线的内容，详见附录。这里提到了意识，意识是关乎人的主观性层面的了，那么应用在流水线上，其实也是需要考虑的。诚然有些时候我们依赖于机器和自动化，如上面说提到的接口测试、安全扫描等。但是也不能完全依赖于自动化，比如我们也需要人工的代码检视活动。这在搭建流水线的时候也可以考虑到把人工环节加入到其中，比如在发布到生产环境的阶段增加一个发布看板，其中包含了是否有人工代码的检视以及检视出来的代码的质量的阀值或要求等。综上，一条流水线除了必须的、按需的自动化+人工以外，还需要在实践的过程中不断的总结结合自身特点加以定制，然后才能放心大胆的点击“启动”而不被坑。最后引用姚冬老师文章中的一句话“流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。”这也是笔者非常认同的，也相信搭建实现这一目标，提供这能力的流水线才能更好的实现持续交付，配合好我们的DevOps转型。参考附录测试左移以终为始，再谈持续交付流水线DevCloud的HE2E DevOps的流水线构建博客

RT求问，LiteOS有自动的内核测试工具吗？例如 syzkaller 之类的。

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

自动化测试曾被软件测试业界视为“救赎式银弹”，但随着项目越来越庞大，测试用例集变得越来越臃肿，查错能力却越来越弱，最后甚至成为QA部门沉重的包袱。本文主要以Junit为例，介绍如何在不改变原有自动化操作流程的情况下，对原有技术进行“精准测试“的技术升级，使覆盖率可视化、回归用例自动选取等先进特性能为我所用。现代的专业软件测试中心，随着项目的迭代，通常针对每个系统构建了大量的自动化测试用例集，而启动一次全量的自动化测试以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服务端IP3、对应修改引入的包(以mvn项目为例)，JavaPaser包主要包含了插装代码以及ParentTest类必须要的TT处理逻辑需要的库的引用。   对被测试代码通过TT进行插装打包，注意Junit自动化测试用例代码不需要插装，只需要插装Junit测试的业务逻辑代码即可。4、开始单元测试，在测试用例执行过程中，打开TT客户端示波器组件，显示实时采集的覆盖率波形，看到测试用例在TT系统中自动建立。TT客户端效果图（生成对应测试用例以及该测试用例的覆盖情况）     以上讲述了精准测试系统如何无缝与现有自动化测试框架的对接。除了Junit，其他自动化测试框架，均可以参照此思路进行实现（登录星云网站www.teststars.cc    离线企业测试中心即可免费试用）。精准测试系统与自动化进行对接后，可以使无法看清的黑盒状态中的自动化测试执行，变得有迹可循。基于精准测试强大的测试分析系统，可以对自动化测试执行和规划进程进行持续的优化，这一方案，可以有效解决自动化测试的投入产出比居高不下的业界难题。

随着国内大数据、云计算、人工智能等新技术的发展，银行业的前中后台正面临着全面改造，金融科技是业务转型发展的一个核心发力点。金融行业信息系统集中度高、规模庞大、多系统之间关联性强、业务复杂、需求变化快，另外各种新旧系统错综交互，软件质量控制难度异常复杂。通过技术手段精准地追溯每一个数据路线，有效实现信息系统的高可靠性和易维护性，是金融业界共同的目标。一、传统测试的局限  目前，在大部分金融机构中，主流的功能测试方法是黑盒测试辅之以一定量的自动化测试。由于自动化测试用例的维护问题较多，黑盒手工（功能）测试依然是主流。它有很多经典方法，如等价类、正交用例设计法以及近些年流行的探索性测试等。因黑盒测试方法总体依赖于业务经验，以及一定的测试“灵感”和临场发挥的“算力”，随着金融软件复杂性和迭代速度的不断加快、软件系统组合路径膨胀等问题，人脑的推算力显然远远跟不上了。即使很优秀的测试人员，也会因为状态问题而导致测试用例设计水准出现波动。后续测试覆盖不充分性日益凸显，剩余至少30%以上的漏测点。而白盒测试工具，因为技术没有跟上敏捷迭代的开发场景，目前在金融企业几乎很少在实际中应用。二、精准测试概念的提出  如何快速定位金融大型信息系统的测试死角，用“可量化”和“可视化”的分析与测试手段，有效地发现程序深层隐藏的缺陷、提高信息系统投产质量、降低投产风险、增强投产信心，金融业甚至软件业均在寻求最佳解决方案。  精准测试方法体系，是近年来业界颇为关注的新测试技术体系。它立足于“系统级”测试，建立了业务功能与代码之间的映射与追溯关系，在代码优化、快速定位代码缺陷、确保关键代码的测试覆盖、精准回归等方面表现突出。为金融信息系统实施高效管理，提供了质量抓手。三、 精准测试的关键技术1. 精准测试的核心技术  精准测试最底层的核心技术：“一种基于用例与源码双向追溯的测试装置及方法”，用一个量子纠缠的形象类比：如常见的金融转账、手机拍照、机器人控制等指令，每个操作都有与之对应的代码，他们之间如同两个纠缠在一起的粒子，具备强关联性。一个发生变化，另一个必定发生相应变化。星云精准测试将功能用例和对应的代码之间实现了精准无误的追溯路线可视化，彻底解决了“黑盒”的难题。在此核心技术基础上，诸如：“回归测试用例的自动选取”、“覆盖率可视化”、“智能缺陷定位”、“聚类分析”等精准测试的高级功能得以充分实现。　　　　　　　　　　　　　　 图 双向追溯(正向)-测试用例追溯到代码  由于优秀的内核设计，星云精准测试可以轻松应用在数亿行的超大型复杂应用上，在建立测试用例、代码、模块之间精准可视追溯机制的同时，瞬间可将海量数据实时采集并存储起来，用于后续测试大数据的分析和运算上。整体过程对原有系统性能，不产生干扰。2. 高度智能化的静默式落地方案  星云精准测试并不改变现有的测试流程和团队组成，它巧妙地使黑盒测试无缝对接到精准测试体系，快速实现提升测试效能比的刚需。测试工程师打开测试用例的Excel表格、执行点击用例，即可通过VBA技术，直接调用星云精准测试的后台接口，再附加一整套深入应用后台执行线程的用户标签技术，就可以将用例和代码关联和分离出来（分离是指类似J2EE服务端后台应用）。在对外提供多用户并发访问的情况下，可分离出每个用户执行的用例所对应的代码。测试者在整个过程中，几乎不需要增加额外工作量。3. 精准可信的测试数据记录过程  传统测试有点像挖矿藏，主要依赖测试用例执行数、时长、bug的数量等外在维度进行衡量，缺陷是未知数，结果不那么具备公信力。精准测试是传统测试走向可信测试的一个最好的技术手段。它的所有测试数据均是在测试执行过程中，由软件自动分析并录入的底层代码运行原生数据。由于用例和执行代码之间信息被完整跟踪，并且细分到测试用例级别，因此整个测试数据都可以在代码层面可视化出来，人工无法介入修改。它真实再现测试现场情况，结果可直接用于测试的过程管理和实效分析。从技术上确保所有数据精准无篡改。这一举措，使测试的衡量点回归到计算机程序的本质-“代码”上来。四、精准测试的应用实践  精准测试的用例与执行代码的强追溯性，为采集到的海量测试数据实现精准度量以及全面、多维度的测试分析，打下了坚实基础。测试管理从相对单一的覆盖率考量视角，扩展到多剖面的智能分析。由于篇幅限制，本文选择两个主要功能点做一介绍：1、企业级覆盖率方面的创新  测试覆盖率是测试界公认的测试结项可用量化指标。在敏捷迭代场景下，由于新版本快速发布，代码变更频繁，本应在一个版本上分析的覆盖数据，分布到了数个代码结构不一样的程序版本上，因此传统白盒覆盖率的统计方法和参考意义基本上都失效了。星云精准测试通过软件示波器在系统测试阶段取采集多种代码覆盖率（最高支持航天航空标准MC/DC的100%覆盖率要求），提供实时覆盖率增长趋势图及各类分析报表，管理者可清晰的观察整个测试进度情况、效率等。  覆盖率智能合并。精准测试可以按照敏捷的模式，将多个版本的覆盖率以最新程序代码版本为投影进行合并，在控制流上直接累加，无需在每个版本上跑全量用例。它在不同的版本上执行不同功能范围的用例，然后合并一个测试周期的覆盖率信息，看总体的覆盖情况。覆盖率合并算法将全自动分析每个版本序列上程序函数变更的情况，以最新版本往前合并，直到某个模块的代码发生变化，在此之间的覆盖率均可合并。  增量覆盖率分析。版本发布后，精准测试可以对增量代码覆盖专门有一个统计维度，这样也是对于覆盖率目标的一种工业应用新思路，不用去关注总体覆盖，而在迭代中关注调整代码的覆盖，尤其是新增代码的覆盖情况。  覆盖率可视化。在星云精准测试中，用户在选择分析的覆盖率维度后，系统就会将被测试程序的相关结构展示出来，并且用颜色表达覆盖情况：绿色代表覆盖，深蓝色代表未覆盖。同时告知覆盖率的分子和分母都是哪些，非常清晰的展示覆盖率可视化结果。  相关覆盖率。可将某个功能用例所触及的函数范围中，所有代码分支作为覆盖率的分母，真正运行到的分支作为分子，这样取得的相关覆盖率非常具有实际指导意义。使用者在有权限的情况下，随时可以看到：因此即使测试的是一个小功能范围的用例集，其覆盖结果也可以近似等价为这个功能范围相关代码的覆盖率情况，亦可以用于分析某个功能范围的测试是否充分。2、回归测试用例的推荐和选取：  对于测试效率的提升，一般会提到狭义的自动化测试，这也是行业内通常解决回归测试的办法。它是一种应对全局回归的方法，在无法有效确定回归范围的情况下，就通过技术手段全量回归以确保系统的修改没有引入新的问题。真正实施过全量自动化回归的团队，会对此项工作的难度和成本深有体会。  星云精准测试回归用例自动选取是属于一种机器智能计算下安全的局部回归。它根据历史测试用例执行的路径信息以及新版本的代码变更信息，自动推荐和选取回归测试用例集，并给出回归优先级和影响度。用户在测试人力有限的条件下，可以根据算法给出的优先级安排测试执行，以最有效的方法发现代码调整引入的缺陷。这种基于海量的程序运行路径计算的数据，精确而完整，不会因团队工作状态问题，而出现大量遗漏的现象。五、小结  精准测试将大幅度提升测试数据的价值，也将产出大量对研发极有意义的分析数据。它必将推动软件行业的数字化改革，为传统金融业务及金融创新（Fintech），提供更智能、有效的软件高端质量保障思路与方法。

      精准测试是近年来行业内流行的新测试技术体系，它通过建立功能用例与代码的关系，使得计算机可以通过智能算法对测试进行深度的辅助分析和提效。精准测试可以轻松的对接原有的功能测试流程，最新的静默方式工作可以确保用户完全不用改变原有测试流程，强大又没有额外的运行成本，得到了广大企业的好评并逐步开始全面流行。 如果一个软件系统的行为总是与预期相一致，称之为可信（trustworthy），目前对于可信软件的测试主要集中在对其进行可靠性、可用性、可维护性、动态测试方法等。由于现在企业大多执行的是黑盒测试，软件无法保证逻辑测试的完整性，约有30%的潜在缺陷在黑盒测试方法下无法被实别，所以，非常遗憾很多企业测试不属于可信测试范畴。 首先软件测试本身的目标标的物是一个未知数，这和开发有着本质的区别。一个程序是否存在缺陷，存在多少缺陷，这些都是相对未知数。软件测试的工作有一个缺陷数量不相关原理，即：发现的缺陷多，并不说明剩下的缺陷就少；同样发现的缺陷少，并不说明剩下的缺陷多。这个缺陷数量不相关性，给我们实际测试带来最大的困惑就是：无法明确判断测试后的程序交付的质量，进而导致测试的成效处于一种不可信状态。其次，不可信性来自于数据执行的不可追溯性。传统测试采用的测试管理系统类似于一种MIS系统，它只是在展示和分析人为填入的数据，测试是否真正被执行？测试是否充分？我们无从分辨。这个问题在这次“新型冠状肺炎”疫情爆发后显得格外明显，因为疫情原因，远程测试管理变得非常松散，测试的有效性成为一个很大的疑问。其实，这也是众包测试模式难以发展的最大瓶颈：发包方仅凭执行列表，完全无法识别真正被有效运行的功能，质量验收形同虚设。由于没有合理的考核办法，导致测试人员在企业内部的发展同样遭遇困境，经常容易被质疑并且很难和研发获得一样的待遇和地位。而个别团队却又把不可信性反过来当作挡箭牌来用，拒绝使用覆盖率等技术暴露工作的不足。 今天我们的主题是讲一下精准测试如何实现可信测试这个主题。 精准测试让功能用例和对应的代码之间实现了精准无误的追溯路线可视化，从技术底层解决了测试可信性的问题。星云测试“测试用例与源码的双向追溯技术”，如同全景调试器一样，记录了每个测试用例对应的程序内部的执行细节，细致到每个条件，分支，语句块的执行情况。它的所有测试数据均是在测试执行过程中，由软件自动分析并录入的底层代码运行原生数据。由于用例和执行代码之间信息被完整跟踪，并且细分到测试用例级别，因此整个测试数据都可以在代码层面可视化出来，人工无法介入修改。使每个业务功能与相应的源码如同“量子纠缠”一样具备强关联性。一个发生变化，另一个必定发生相应变化。它真实再现测试现场情况，从技术上确保所有数据精准无篡改，彻底解决了“黑盒”执行过程、质量度量和实效分析等难题。使测试的衡量点回归到计算机程序的本质-“代码”上来。 精准测试通过软件示波器采集数据，用例如何运行，就如何记录程序运行的路径信息，当用例没有被正确运行，或者没有被执行的情况下，示波器就不会采集和记录相关信息。所以星云精准测试在众包远程零监管的众测模式下，测试用例的有效性和被执行状态，很清晰地被记录下来。测试覆盖率是测试界公认的最佳的是测试结项的可用指标。每一行代码或者分支跳转理论上都是在实现某些特定的业务功能，因为某些原因没有被覆盖到的部分是必定蕴含着风险的。在传统测试中，我们可以用人工确认的方式表达某个用例已经执行过，但在精准测试中，没有被执行的用例对应的代码覆盖就是0或者是异常的覆盖，这个信息是没有办法伪造的。这实际上已经解决了测试众包业务验收难的问题：测试用例设计能力如何、有没有被执行、执行结果如何、调整增补后的代码及用例的运行结果如何等，在各剖面报表上展示得非常清晰。精准测试可以把每个测试用例进行量化分析和统计。在本次疫情中，大家都可以深刻的感受到由于因隔离而产生的团队人员变动，给项目造成巨大不确定因素。星云精准测试有一系列的算法，可以根据管理者对项目质量的要求，对验收指标进入深度回溯，快速定位BUG所牵涉到的业务逻辑、测试用例等要素，从而大大减小了人为影响。这些量化数据既可以用来对测试结果以及测试过程进行审核，也能帮助测试人员从数字化分析角度反观测试用例设计是否合理、执行的测试用例是否不足。极大弥补了由于测试人员自身的经验、能力、精神状况等因素，影响到的测试质量。管理者们也可以对症下药，拟定有针对性的学习计划、快速培养，使不同水准的梯队成员在有限的时间里，得到迅速提高。精准测试的覆盖率每日增长趋势图，对于团队的质量控制和整体测试进度情况具有很好的指导意义。它能够让高级管理人员对测试进度进行预判，也能够对测试效率进行有效的识别，例如通过对覆盖率增长曲线的拟合，可判断按照目前进度能够在上线日期到达前能够一个合理的测试水准。星云精准测试从各个角度提供可信化的测试数据，使管理者有效地把控测试节奏，主动地进行测试策略的调整。对数字化管理进行有效的数据采集，企业可以很自然的实现分布式测试，不同区域、不同任务分配的测试人员可以实现协同测试与协同管理，最终达到多人同地测试、多人异地测试、数据实时汇总共享与追踪、测试过程与完成度有理有据、测试结果一目了然。精准测试能自动识别测试设备、测试人员、测试用例等，并自动关联对应信息。在没有采用可信的精准测试之前，通常一个测试主管一般只能管理5名左右的测试工程师，管理人员需要投入大量的精力帮助测试人员审核用例，甚至监督用例的有效执行。应用星云精准测试以后，工作就简化了很多：每个项目的覆盖情况，每日增长情况都很直观，每位工程师的用例设计和执行的充分度也很清楚。项目管理者可以站在更高的角度，充分了解整个项目的资源使用、测试人员任务分配、测试进度等情况，并做数字化分析、管理和调度。因此精准测试非常适用于外包和众测领域，管理人员不用再特别花费时间去考核测试人员考勤、工作态度等主观因素，很容易看出不同团队、人员的业务水平。 精准测试可以基于可信的数据、依靠有效的算法计算出来的实施自动化回归测试。星云精准测试(www.teststars.cc)可以实现自动化的版本对比，分析出修改、增加、删除的代码以及这些代码相关联的测试用例，快速做测试用例回归测试、快速补充测试用例、删除无效测试用例。它大大减少了回归测试的时间、降低传统人工回归分析产生的测试盲点、精确计算回归用例的权重。测试人员在时间有限的情况下，可以重点回归受改动影响最大的用例，适应庞大的工程项目的快速版本迭代需求。 精准测试通过静态、动态指标的综合分析，快速筛选潜在的高危测试漏洞。测试人员可以通过星云精准测试漏洞分析，直接针对高危的核心模块功能与开发合作完成补充测试；也可以通过漏洞分析可视化的图形，检查出核心模块的测试遗漏点，进行测试用例补全，消除测试遗漏点与盲点。与此同时，亦可对无用的代码进行相应的注释与删除，提高软件的后期维护性，大大提高了废弃代码的排查率。 可信化的精准测试，解决了大量的传统测试的盲点与痛点。目前全行业都在逐步认识和推进精准测试，我们相信未来在新技术的推动下，注定会迎来远程松散式测试众包（外包）一个新的爆发点。这次疫情，让大家进一步深刻意识到，信息化让我们每个人都生活在软件的海洋里。疫情期间，大量用户涌入线上服务，让很多软件系统暴露了很多不足，在996和007的高密度的软件发布下，如果不配置上新型的智能化精准测试技术，如何有效支撑越来越复杂的软件应用的高可靠性和高可信化？ 自然语言的沟通，应更多体现在人文关怀上，庞大的软件帝国没有高度智能可视的精准测试管控，快速预警那些隐蔽很深的缺陷，必定有一天会像突发而至的疫情一样兜头而下、措不及防。借用最近事故频发后反思而来的金句：对于故障，没有借口。我们应认真复盘改进发布验证流程，研发人员应该敬畏每一行代码，测试人员应该敬畏每一份托付。我们每一个人都在有形无形中，构建人类信息世界的命运共同体。 

https://mp.weixin.qq.com/s?__biz=MzA5MjM5OTYzNA==&mid=2247485810&idx=1&sn=95e575d3508e698837399339065d0751&chksm=906cf80fa71b71198aacc683bd3eb0ea05ceb968b62cdedee8034206b85310140187922ae843&token=1156458741&lang=zh_CN#rd

1.       进入ABC平台，点击左上角云图标，进入预览，打开线上“智慧园区自动化测试”应用。 2、在config/settings文件中，修改以下对应被测环境信息。ABChost_QA1：填写开发环境地址。Client_id_QA1与Client_secret_QA1填写内容来源见下图。1、 进入ABC平台，点击“管理”，“设置”，“OAuth”，“新建”；2、 填写“名称”和“用户”，点击保存；3、找到刚新建的密钥，点击眼睛图标，确定下载；4、打开下载文件，填写Client_id和client_secret。5、进入ROMA平台，点击“服务集成”、“API网关”、“网关管理”、“网关域管理”，复制任意一个接入地址。6、将复制的接入地址填入RomaAPI_GW_QA1，其余填写如图。7、登录DAYU平台，点击“数据开发”，选择URL中的region和workspace数值填入。Password填写自己账户的登录密码。8、将HostType数值改为QA1。

概述智慧园区提供自动化测试解决方案，主要针对智慧园区业务资产BO、集成资产IO、数据平台DO、以及业务应用APP提供自动化测试服务。主要功能包括：用例执行：测试单个脚本、流、ABC服务接口、ROMA接口等业务场景。用例扩展：合作伙伴二次开发的新功能支持新增测试用例。测试任务：批量执行测试用例快速验证功能的可用性。测试桩服务：模拟响应，减少第三方系统或设备的依赖。 方案介绍智慧园区自动化测试解决方案围绕园区应用、业务平台、集成平台、数据平台进行全方位自动化测试。主要用到的测试方法：业务平台：服务模型驱动测试、业务数据驱动测试。集成平台：模拟请求测试、模拟服务桩测试。数据平台：批量数据上报、作业实时调度、大屏综合态势数据生成与校验。线上服务应用一、工具介绍智慧园区自动化测试借助ABC开发平台，提供免费测试服务应用。二、上传执行器镜像1、获取自动化测试原生BO的镜像文件 HiCampusAutoTest.zip > PyTest.tar文件。（外网用户发送邮件至Hicampus获取，仅支持有项目的用户）2、登录ABC， https://studio.e.huawei.com/studio/index.html选择“项目”，“创建Native Service”，标签与名称写“test”，分类选择“others”，创建成功。 3、选择“镜像”，“上传”，上传PyTest.tar文件。说明：私有云如果不支持ABC上传镜像，可以直接上传到目标主机，导入镜像，创建容器。 4、返回首页，点击“管理”。三、安装应用获取自动化测试软件包HiCampusAutoTest.zip > PyTestBO.zip和HiCampusAutoTest.zip > AutoTest.zip，在“软件包安装”中安装软件包。四、部署原生BO部署原生BO，选择“管理 > 工程与服务 > 部署“，点击PytestBO部署。说明：私有云如果不支持ABC部署容器，可以直接通过目标主机，导入的镜像，创建容器。五、修改系统参数1、回到首页，点击“PyTest BO”,2、点击“Charts”，点击眼睛图标3、复制主机名称4、回到主页，点击“管理”，“设置”，“系统参数”5、搜索“test”（创建时的标签与名称），找到对应的系统参数6、点击进入，点击“编辑”按钮，把“值”替换为刚才复制的主机名称：pytest.pytest.vbt7.dev.product。 六、添加应用授权在管理--权限配置中选择需要授权的角色，在应用程序设置中勾选“智慧园区自动化测试”的可见性。

1、问题现象描述 硬件配置TaiShan   2280服务器（Hi1616,8*32G   DDR4 2400MHz）测试工具Lmbench.stream测试工具操作系统Centos   7.6，GCC 7.3.0 glibc   2.2.8问题描述软件解压后，编译失败，提示“/tmp/ccid4aB6.o：在函数‘seekto’中：disk.c:(.text+0x44)：对‘llseek’未定义的引用”。/tmp/ccid4aB6.o：在函数‘seekto’中：disk.c:(.text+0x44)：对‘llseek’未定义的引用collect2: 错误：ld 返回 1gmake[2]: *** [../bin//disk] Error 1gmake[2]: Leaving directory   `/home/raowanjun/lmbench3/src'make[1]: *** [lmbench] Error 2make[1]: Leaving directory   `/home/raowanjun/lmbench3/src'make: *** [build] Error 2     2、关键过程、根本原因分析分析问题步骤如下：1、首先从提示信息已经很明确的反应出问题的发生点即在disk.c文件中seekto函数中llseek参数未定义就引用。2、在本地搜索出该源代码的位置./src/disk.c，打开源码文件并搜索出llseek的位置。seekto(int fd, uint64 off){#ifdef  __linux__        extern  loff_t llseek(int, loff_t, int);         if (llseek(fd, (loff_t)off, SEEK_SET) == (loff_t)-1) {                return(-1);        }        return (0);#else        uint64  here = 0;         lseek(fd, 0, 0);        while ((uint64)(off - here) > (uint64)BIGSEEK) {                if (lseek(fd, BIGSEEK, SEEK_CUR) == -1) break;                here += BIGSEEK;        }        assert((uint64)(off - here) <= (uint64)BIGSEEK);        if (lseek(fd, (int)(off - here), SEEK_CUR) == -1) return (-1);        return (0);#endif 3、将问题代码拷贝出来，简单写一个main函数单独编译。如下#include <stdlib.h>#include <string.h>#include <stdio.h>#include <sys/types.h>#include <unistd.h>#include <stdlib.h> int main(int argc, char **argv){int fd = 0;int off = 0;#if 1if (llseek(fd, (loff_t)off, SEEK_SET) == (loff_t)-1) {                return(-1);        }        return 0;#endif}                                               根本原因分析：大数据重新定位读/写文件偏移量时，llseek接口函数在GCC 7.3.0编译器中被lseek64替代3、结论、解决方案及效果将测试工具的disk.c源码文件中的llseek接口函数全部替换成lseek64，重新编译。 

1、问题现象描述 硬件配置TaiShan   2280服务器（Hi1616,8*32G   DDR4 2400MHz）测试工具Lmbench.stream测试工具操作系统Centos   7.6，GCC 7.3.0 glibc   2.2.8问题描述软件解压后，编译失败，提示“/tmp/ccid4aB6.o：在函数‘seekto’中：disk.c:(.text+0x44)：对‘llseek’未定义的引用”。/tmp/ccid4aB6.o：在函数‘seekto’中：disk.c:(.text+0x44)：对‘llseek’未定义的引用collect2: 错误：ld 返回 1gmake[2]: *** [../bin//disk] Error 1gmake[2]: Leaving directory   `/home/raowanjun/lmbench3/src'make[1]: *** [lmbench] Error 2make[1]: Leaving directory   `/home/raowanjun/lmbench3/src'make: *** [build] Error 2     2、关键过程、根本原因分析分析问题步骤如下：1、首先从提示信息已经很明确的反应出问题的发生点即在disk.c文件中seekto函数中llseek参数未定义就引用。2、在本地搜索出该源代码的位置./src/disk.c，打开源码文件并搜索出llseek的位置。seekto(int fd, uint64 off){#ifdef  __linux__        extern  loff_t llseek(int, loff_t, int);         if (llseek(fd, (loff_t)off, SEEK_SET) == (loff_t)-1) {                return(-1);        }        return (0);#else        uint64  here = 0;         lseek(fd, 0, 0);        while ((uint64)(off - here) > (uint64)BIGSEEK) {                if (lseek(fd, BIGSEEK, SEEK_CUR) == -1) break;                here += BIGSEEK;        }        assert((uint64)(off - here) <= (uint64)BIGSEEK);        if (lseek(fd, (int)(off - here), SEEK_CUR) == -1) return (-1);        return (0);#endif 3、将问题代码拷贝出来，简单写一个main函数单独编译。如下#include <stdlib.h>#include <string.h>#include <stdio.h>#include <sys/types.h>#include <unistd.h>#include <stdlib.h> int main(int argc, char **argv){int fd = 0;int off = 0;#if 1if (llseek(fd, (loff_t)off, SEEK_SET) == (loff_t)-1) {                return(-1);        }        return 0;#endif}                                               根本原因分析：大数据重新定位读/写文件偏移量时，llseek接口函数在GCC 7.3.0编译器中被lseek64替代3、结论、解决方案及效果将测试工具的disk.c源码文件中的llseek接口函数全部替换成lseek64，重新编译。