简介

根据QA的测试需求、QA与策划约定好的配置规范、QA在测试过程中发现的配置异常等情况，可以对游戏项目的资源或配置项进行固定规则的静态检查

目前在上游，每个职能可能都会根据策划自己的需求指定一些零碎的检查规则（如：导表检查、FC配置检查、点位贴地检查等等）

这样的检查可以一定程度上的规避掉一些策划、QA同学在开发前提已经意识到的风险问题，但仍有一些问题会随着开发阶段和BUG的暴露出来的新的配置规范

目前可以用QA静态检查的框架去做一次QA的二次确认检查

关联代码和配置资源

Assets/Editor/QA/StaticReviewTools 内相关代码（EditorOnly Script）

Assets/NapResources/Data/ScriptConfig/Gm/StaticCheck/StaticCheckConfigs.asset （相关配置）

结构简介

如何编写单个基本的静态检查

定义一个检查函数

每一个检查都需要生成一个AutoCaseManager的实例

它定义了这个检查的名称、是否是自动化检查（此处默认False即可，只自动化需要使用到）、检查的结果、检查的Log存放处等等

每一个AutoCaseManager都有一个完整的寿命周期：

1.开启Case

2.开启CaseLog

3.执行检查

4.关闭CaseLog

5.关闭Case

这个实例和配置也需要一定的配合（在配置处会解释）

下面是一个结构的基本示例，每个检查的结构大体如此

public static bool CheckFunc(bool autoCheck = false)
{
	var acm = new AutoCaseManager("CheckFunc",
                "CheckFunc", false, isAuto: autoCheck);

	//var acm = new AutoCaseManager("CheckFunc", isAuto: autoCheck);  
	//AutoCaseManager初始化一般有两种形式
	//needResult为False时，这个检查被标记成数据输出类检查，这种检查只收集静态数据，不做结果的判断（结果必True，不存在失败Case）
	//needResult为True时，这个检查存在检查结果，若出现Error，即失败

    acm.CaseStart();
    acm.CheckerLogStart(acm.caseName, AutoCaseManager.logSuffix.CSV);

	/*

	此处编写检查内容

	*/

    acm.CheckerLogEnd();
    return acm.CaseEnd();
}

定义一个用于菜单执行的函数

这个函数只是方便在菜单中直接调用的一个函数

当前每个检查都会配一个这样的二次封装，便于本地在菜单中使用单个检查

[MenuItem(MENU_ITEM_ROOT + MENUITEM_BATTLE + "CheckFunc的执行菜单按钮", false, 300)]
private static void CheckFuncMenu()
{
    CheckFunc();
}

提交代码

这一步就不用多说了，写完了代码，确认没问题后提交即可

修改并提交静态检查配置

找到项目StaticCheckConfigs并CheckOut

TargetCase需要和对应检查的函数名对应（非Menu的那一个）

CaseType决定了他会在Unity工具窗和冒烟平台显示在哪一个分类

CaseDescription和Case Logic Description是一个解释用文本

Log Root Path的填写需要和函数里填写的参数相互对应，否则自动化结果是拿不到对应的文件的

Case Log Name的填写需要和函数里填写的参数相互对应，否则自动化结果是拿不到对应的文件的

Case Designer和Auto Case Responser也是一个跟进用的解释文本

点击更新冒烟平台静态资源检查信息，保证冒烟平台的同步，这一步是必要的

以上，我们完成了一个基本的静态检查开发过程

跟进结果

本地

手跑后每一个检查都会提示检查结束，弹出确认框

确认后即可打开对应log的文件夹，手动打开log即可

Web

可以在冒烟平台跟进每一个已经纳入静态检查自动化任务的内容

Q&A

欢迎提问和提需求