저자 : 한 조명
공공 수에서 : 바이 QA
☞ ☜ 배경
현재 시스템이나, 케이스 디자인 시나리오에 근거한 경우에도 인터페이스 테스트하는 경우 웹 응용 프로그램 백엔드 서비스 테스트, 테스트 대부분의 블랙 박스 테스트 계정에서이 시험 방법은 시험 인력, 경험과 비즈니스의 능력에 달려 친숙하고, 인터넷 산업의 주요 기능은 회선 품질이 종종하게 높은 직원 회전율이다 "날씨에 따라 다릅니다." 프로젝트 테스트하는 동안 다음과 같은 문제의 존재에 대한 테스트 블랙 박스 테스트를 기반으로 :
너무 주관적인 인적 요소 (1) 블랙 박스 테스트 : 블랙 박스 테스터는 개인의 능력, 경험과 비즈니스에 대한 지식에만 의존, 매우 주관적인 요소, 시험의 누설 너무 많은 불확실성에 의해 영향을 근본 원인.
테스트 코드 검사 과정, 품질 수준이, 객관적인 데이터를 측정 할 인간의 주관적인 유전율에 전적으로 의존하고, (2) 시험 범위는 객관적인 측정 데이터는 없다. 우리가 전액 또는 증분 코드 검사 데이터를 (증분 범위가 일반적으로 사용 사례의 총량 두 번 실행해야 할) 수 있지만, 증분 특정 코드 경로를 충당하기 위해이 수 있지만, 보고서는 커버의 전체 양의 수동 분석에 의존하지 수 있습니다 레거시 코드 인 구별, DIFF 인 코드, 프로젝트 약간 큰 코드의 양이 시험은, 실질적으로 테스트 모드의이 행을 허용하지 않도록 블랙 박스 테스트에 테스터, 어떤 코드 분석 지원이 없기 때문에, 블랙 박스 테스트 커버리지는 테스트의 반복을 더는 유효하지 않습니다, 범위의 천장을 만지지 것, 시간과 사용 사례 증가 하였다.
(3) 자동화 사용 사례를 효과적으로 무 지방의 역할 재생 : 시험을 수동으로 테스터 이외에 웹 / API 또는 앱 백엔드 서비스 시스템의 경우, 대부분의 개선을 시도하면 인터페이스 자동화 시험이에 자동화 그러나 몇몇 회사를 구축, 건축 의미입니다 불량한 안정성 프로젝트의 반복과 축적 점점 자동화 사용 사례에 수백에서 : 방향은 특히, 특히 높은 출력 비율 (ROI)에 넣어 않는 근본적인 이유는 자동화 코어 지표 인 수천, 그들은 거의 모든 80 % 이상으로 할 가능성이 안정화 모든 환자 CI 트리거 레벨 (한 번에 한 번 트리거 제출 코드), 이러한 사용 사례를 자동화 할. 가난한 안정성의 자동화 사례, 자동화에있을 것입니다, 수익을 창출하지 않는 말을하지만, 부담 QA 될 것입니다, 그래서 그들은 시간이 지남에 따라, 유효한 버그를 찾을 수 없습니다 대처하기 위해 애 쓰고, 실패 조사 위에서 자동화 사용 사례에 소요되는 시간을 많이 넣지 신뢰의 손실, 또는 포기.
분석 및 ☜ 생각 ☞
저자의 제품 라인이 SSH 자바 내장 프레임, 모듈 수의 백엔드 서비스에 기반 RPC 통신 단계와, 다중 모듈 결합 간의 합의에 기초하여 인터 - 모듈은 다양한 전달 시스템은 더 복잡한 비즈니스 로직이고, RD는 새로운 QA있다 전통적인 블랙 박스 테스트는 사람들의 더미를 통해 사업을 확장 수용하고 어려운 높은 수준에서 테스트 프로젝트의 품질을 유지할 수, 업계는 같은 문제에 직면하는, 시간외 작업을 계속할 수 있습니다, 피할 수없는 배경도있다 세 가지 질문에 언급했다. 수천 많은 경우의 수와 반복 축적 인터페이스 테스트 자동화 제품 라인이 자동화 사용 사례 재생하면 그들의 유틸리티 할 수 있도록?
질문 1과 배경이, 우리는 다음과 같이 요약 될 수있다 : 시험 범위가 쉽게 객관적인 데이터로 측정 할 수 있는지 여부, 테스트 커버리지는 더 자신감없고, 그 과정에서이 빠르게지지하는 도구가 없습니다보다 효과적으로 QA에 도달 자신감의 정도를 달성하기 위해 ? 3의 맥락에서 문제마다 우리는 이러한 경우의 수를 줄일 수없는, 그들에게 모든 사용 사례를 통해 거의 불가능 실행할 수 있도록 백퍼센트 경우 수천을 통해 순서의 자동화 수준과 경우의 수는, 그 때마다 사용하기 단지 실행하고 사용 사례 관련 코드 변경, 그 밖의 경우의 심사와 아무 상관이있다?
업계와 일부 연구의 회사의 다른 제품 라인을 통해, 우리는 어떤 팀이 어떤이 문제에 대해 탐구 할 필요가 있음을, 즉 정확한 테스트입니다 찾았지만, 기본적으로 즉에 환자의 실행 사례를 선별 감소 세 가지 문제에 집중되었다 CI의 L은 실질적으로 동일한 사상의 안정성을 향상시킬 수 있지만, 다양한 구현이 아니다. 몇몇 팀은 또한 프런트 엔드 템플릿 응용 프로그램과 다른 제품 기능을 기반으로 회사 내에서 시도하고 여기를 반복하지, 다른 프로세스를 얻을 수 있습니다. 우리는, 정밀 기반 인터페이스 자동화 된 테스트를 (구현 언어에 국한되지 웹 또는 앱의 백엔드 서비스 또는 API) 백엔드 서비스 모듈에 대한 방향을 모색하고, 할 수있는이 개념을 확장, 더 이상 심사 환자에 국한되지 하지만 세 가지 수준, 즉 :
(1) 검사 자동화 예
영향 표면 (2) 평가 시험 범위
(3) 증분 코드 커버리지 분석
다음의 특정은이 세 가지 수준의 의미를 설명한다.
단일 자동 코드 커버리지 경로 정보에 대응하는 형태를 수득 기반 자동화 예 및 커버리지 정보 및 데이터 소스로 적절한 매핑 라이브러리 (KB)를 설정 : 우리 / 프로그램. 도에 도시 된 바와 같이.
추가 정보는 다음과 같은 세 가지 기본 시나리오를 지원하기 위해 제공되는 라이브러리 시스템 취득을지도 할 수있는 능력을 기반으로 :
（1）自动化用例筛选： 在生成用例和代码覆盖路径映射库信息后，当RD提测时，可以根据代码diff计算出变更的方法列表(新增/修改/删除) ,用方法列表反查映射库，便可以筛选出与变更代码相关联自动化用例，与CI相结合，达到精简用例，减少执行时间， 同时减少不必要的用例执行，进而提升CI稳定性，减少CI维护排查代价。
（2）测试范围评估：与场景1相似，在RD 提交代码代码后，以变更方法列表做为条件反查映射库，获取与之关联的自动化用例，根据用例URI聚合，并结合用例描述和FE代码注释，分析给出手工测试范围，一是可以减少测试回归范围，二是可以防止漏评导致的漏测
（3）增量代码覆盖分析：新项目测试过程中，新增自动化用例对增量代码变更diff 覆盖信息（生成映射库过程），可以和增量代码变更方法列表做为数据源，通过算法生成增量代码行和分支覆盖率报告，并具体标记哪个分支或行未覆盖，QA可以根据增量代码覆盖率分析报告，针对性进行用例设计补充，从而提升覆盖率，减少漏测。同时报告也使得对增量代码覆盖情况可量化(常见的增量覆盖率数据生成要运行2次全量用例集合，自动化稳定性很难保证，手动回归成本太大，基本不太可行)。另外，对未覆盖函数或分支进行提醒QA做相应的自动化用例补充，从面形成精准测试，双向反馈提升良性循环，更有的放矢，更有据可依，更自信任。
☞方案☜
整体的设计方案如下：
方案背景介绍：
（1）接口自动化用例：基于公司通知接口自动化框架平台书写，分为Http和Rpc两种接口类型
（2）后端服务实现语言为Java，基于SSH+ RPC分布式协议框架
（3）覆盖率工具采用Jacoco开源框架
（4）代码管理系统为公司基于git开发通用代码管理平台
3.1 基础用例和覆盖代码映射信息库生成
顾名思义，用例与代码映射关系即：单个用例与其能覆盖所有代码方法列表（不是类，分支或行）映射关系，这里面有2个难点要解决：一是单个用例覆盖率文件生成代价比较大，二是要消除自动化用例数据构造和清理带来的代码覆盖路径干扰，在这里我们称之为消振。
先看第一个问题， 单个用例覆盖率文件生成代价大。对于收集web或jvm运行后端服务来说，接口级用例覆盖率收集比单测更为复杂，需要很大的时间、空间开销，并带来稳定性隐患。具体如下
（1）时间开销，每个用例都需要命令行插桩，启动被测服务，停止补测服务，dump并生成覆盖率文件，且不说覆盖率工具的命令行操作，单服务的启停服务就会带来不菲的时间开销
（2）空间开销调用脚本及源代码，用列执行，被测服务分别处于不同的机器，在生成覆盖报告时需要源代码和覆盖文件同源，需要额外的操作成本
（3）启停被测服务给覆盖文件生成带来不可控因素，每次服务启动都可能在启动中或启动失败
常见的离线插桩方式获取单个用例覆盖报告流程如下：
通过调研选型，我们发现基于Jacocoon-the-fly模式可以在不停服的情况下，通过api导致覆盖率文件。关于Jacoco的注入原理以及注入方式，在官方网站上写的非常详细了，不做过多赘述。基于 On-the-fly 方式无须入侵应用启动脚本，只需在 JVM 中通过 -javaagent 参数指定 jar 文件启动 Instrumentation 的代理程序，代理程序在通过 Class Loader 装载一个 class 前判断是否需要注入 class 文件，将统计代码插入 class ，测试覆盖率分析就可以在 JVM 执行测试的过程中完成。Jacoco提供了自己的Agent，完成插桩的同时，还提供了丰富的dump输出机制，如File,Tcp Server,Tcp Client。覆盖率信息可以通过文件或是Tcp的形式输出。这样外部程序可很方便在任意机器上通过api随时拿到被测程序的覆盖率。
基于Jacocoon-the-fly 模式获取单个用例覆盖率报告流程如下：
再来看第二个问题：如何消除自动化用例数据构造和清理带来的代码覆盖路径干扰。即单个用例可以独立重复在不同环境间重复运行，要求用例只能依赖setup/teardown做数据构造和清理，举例来说，验证一个update物料属性A的用例，setup里需要构造2个请求创建物料管理计划，及物料本身，Case为修改物料属性A接口请求及其对应的校验点，最后是teardown里的数据清理，删除物料及基对应的管理计划。在这种情况下，若以Case为粒度收集与之对应的代码方法列表，会有很多干扰数据进来， 物料所属的管理计划，物料对应 add和delete接口关联的方法都会被收集到，所以我们要清除这些干扰数据，要收集以包含校验点请求与之对应代码方法列表，即只收集update 物料属性A这个请求对应关联方法列表。
来看我们的解决方案：
（1）自动化用例的原子性：单个用例验证一个接口，且被校验接口所在请求统一命名，如”request”。
（2）利用AOP原理，在自动化框架的执行器加一个拦截器，在覆盖率收集开关打开且请求名称命中request的请求时，请求执行前：reset 被测服务桩数据，请求执行后：用api导出内存中的覆盖率数据，生成exec文件
（3）在全局变量设置覆盖率收集开关及其它配置，这样即不影响其它产品线使用，就可以在同一台机器上完成用例执行，覆盖率数据收集，桩数据重置，覆盖率报告生成等一系列操作了。
解决这两个问题后，用例和覆盖代码方法列表映射关系生成方案如下图：
3.2 自动化用例筛选
有了用例和代码方法列表映射基础信息库后， 我们来看下用例筛选实现逻辑， 这里有2个点，一是如何获取变更代码方法列表，二是如何将筛选出散列的用例在自动化框架规则里执行。
先来看获取变更代码方法列表，在这里我们没有采用git原生 diff 函数获取代码库2次代码提交中间的代码变更，若基于git原生diff功能，不管是命令行还是api方式，都需要在本地维护一个代码库的副本，过于笨重且稳定性差。所以我们在实现是基于公司通用代码托管平台提供版本对比功能，可以直接获取2次commitid间的代码变更文件，并以json格式返回，处理起来更为方便。获取到代码变更文件，再基于不同语言方法结构，便可直接获取到变更方法列表。
用变更方法列表查询映射信息库便可筛选出受影响的自动化用例，但这些用例是处在松散状态，批量执行需要在计划或测试套件绑定后，加上全局变量配置等要素是无法在自动化框架下执行的。为解决这个问题，我们在自动化框架内开发计划动态更新的API，使计划和用例绑定可以动态更新，并同时配置环境，变量，权限等要素，这样就可以以计划为单位执行筛选出来的自动化用例了。具体的业务逻辑实现见下图：
3.3 测试影响范围评估
在敏捷开发模式下， 迭代多，且快。项目在迭代升级的过程，虽然自动化能帮忙覆盖一部分后端代码逻辑回归，但和前端交互部分，当前还没有好的自动化手段来解决，这部分内容回归还是主要靠手工测试来保障。影响范围评估大了，全量手动回归低效，代价太大；影响范围评估小了，容易造成漏评漏测。
这种测试影响范围评估完全靠RB和QA 主观判断来评估，强依赖于个人的经验和能力，再加上人员变更，项目交接等外在因素，经常会有测试范围漏评的现象。例如：工具类B项目开发过程中，对主流程A底层方法methodA有改动，由于RD和 QA测试范围评估，经常专注B 升级业务点测试，主流程A的回归测试没有评估到，从而导致没有回归到造成线上问题。那我们能不能用客观的数据来精准评估哪部分需要测试，使手工测试范围也更具体针对性呢？
在这里当某模块的核心接口主流程场景都被自动化用例覆盖到以后，我们可以认为，底层业务逻辑的改动方法列表，同样查询映射库关系获取影响到用例列表，然后将这些用例请求URI或者接口名称去重，聚合，以报告的形式展示出来， QA便可以根据这个报告更有针对性去做手动回归测试，防止漏评现象发生，同时可以减少回归范围，使回归更有针对性。具体的实现原理和3.3中用例筛选类似，这里不再展开。
3.4 增量代码覆盖率分析
在传统黑盒测试过程中， 在测试前期能够比较有效发现bug，但在后期主要依赖个人能力和经验探索性测试， 往往都是在进行无效的重复测试，而且测试质量没有置信度，基本上没有度量，或者因为度量代价太大被裁剪掉了。
就java语言来说，要产出模块代码增量覆盖率，一般要运行前后2个代码版本全量的用例，分别生成2次生成的全量代码覆盖率做，再计算出增量代码覆盖率。这种情况下全量手工用例回归太低效，自动化全量运行情况下，稳定性很难保证，所以没有可操作性。
另外，在黑盒测试过程，如果想针对提升增量代码覆盖率，只能依赖开源工具生成全量代码覆盖率报告，但全量代码覆盖率报告是无法标记变更代码和已有代码区别的，也不具备可操作性。
为解决这2个问题，我们利用从代码托管平台获取变更方法列表和新增自动化用例生成的覆盖率报告，在分析器中组合计算，一次性产出变更代码增量覆盖率报告，同时标记出未覆盖到方法和分支代码，为测试覆盖提供衡量数据并可以针对设计用例走到未覆盖到的代码，具体的业务逻辑实现如下图：
到现在我们便可以将精准测试3个落地场景的业务逻辑综合起来，如下：
☞当前进展（应用现状）☜
（1）产品线后端模块接口自动化用例对应增量代码分支覆盖率>40%做为测试准出标准，测试覆盖面可衡量且可针对性提升。
（2）产品线核心模块local 阶段自动化用例回归，接入自动化用例筛选，CI级别的触发只运行和代码变更相关的用例，用例平均精简比例在50%以上。
（3）产品线线下拦截漏评4次，增量代码覆盖率提升过程中发现10个bug。
☞后续规划☜
(1) 지원 CI 트렁크 / 느린 액세스 정확한 테스트 단계
(2) 실시 예 필터 액세스 서비스 단부 흐름 필터 시스템 레벨 테스트를 사용할 수있는 능력을
(3) 열 및 범용 확장에 의해 액세스의 오픈 API 공통 언어 및 기타 자동화 워크를 지원하는 기능을
(4) 데이터 소스 나 같은 경우 역사 온라인 버그 코드 품질로, 사용되는 더 테스트, 역사적 방법 번째 라인은, 시험의 기본 데이터에 대한보다 효과적인 지원을 제공,에 포함 할 수있는, 온 포함, 우리의 사용하기에 더 곧 테스트 데이터
부호 변화의 정밀한 검사에도 다른 RD 내지 (5) 확장 정밀 시험 범위, 정도가 될 것이다 것에 테스트 할 필요가 수행 될 시험의 유형이 테스트는 모든 기술적 어느 정도까지 시험을 이 시스템은 조언과 분석 지표를 제공 할 수 있습니다.