QA_Training

# 1、快捷键
## 1.1 截图：
- welink截图: `ctrl+alt+s`截图后, 可以固定在屏幕上;
- 微信截图: `alt+A`
- linux在终端中拷贝和粘贴:
    - 复制:`ctrl+insert`或`ctrl+shift+C`;
    - 粘贴:`shift+insert`或`ctrl+shift+V`;
- VNC以外粘贴到vncviewer中：
    - 从VNC以外粘贴到`vncviewer`中去, 需要打开`vncconfig`才行, 关闭掉`vncconfig`就不行(难道是bug?), `vncconfig`路径在`/usr/bin`下面(可以输入vnc然后tab查看)。
    - 需要从外部粘贴时，在终端中输入`vncconfig &`, 使其脱离终端后台运行并最小化弹出来的vncconfig设置框, 然后就可以粘贴外部clipboard上的内容了。
## 1.2 文件:
### 1.2.1 文件操作
- 希望每次打开文件夹后, 不是新开一个窗口(窗口太多了, 很乱), 可以这样操作:
    - 随便打开一个文件夹, 选择Edit->Preferences->tab中选择Behavior->勾选`Always open in browser windows`.
- 希望每次使用gedit打开文件, 不产生副本(如run.sh, 可能会产生run.sh~这样的副本), 可以这样操作：
    -  随意使用gedit打开一个文件, 选择Edit->Preferences->tab中选择Editor->取消勾选`Create a backup copy of files before saving`
### 1.2.2. 文件查找
- 查找当前路径./dbcmd下某某写的case(递归查找文件，而不是目录名):
    - 直接查找, 可能查找到目录名：`find . -name "file.txt"`
    - 输出到a.log中去：`find ./dbcmd -type f -name "*libo.tar.gz" > a.log`
    - 判断数量：`find ./dbcmd -type f -name "*libo.tar.gz" | wc -l`
- 仅查找当前文件夹中，文件名包含keyword的文件, 不包含文件夹:
    - `find . -type f -name "*keyword*"`
- 查找特定名字的文件夹：
    - `find . -type d -name "advancederr"`
    - 支持简单的"*"匹配：`find . -type d -name "advance*"`
- 查找压缩文件, 拷贝, 并解压:
```
# 1. 创建目标目录
mkdir -p ~/Data/pyCase

# 2. 查找并拷贝所有包含keyword的文件到目标目录
find . -type f -name "*keyword*" -exec cp {} ~/Data/pyCase/ \;

# 3. 进入目标目录
cd ~/Data/pyCase

# 4. 只解压.tar.gz文件
for file in *.tar.gz; do
    if [ -f "$file" ]; then
        echo "正在解压: $file"
        tar -xvzf "$file"
    fi
done

# 5. 可选：处理其他压缩格式
for file in *.tar; do
    if [ -f "$file" ]; then
        echo "正在解压: $file"
        tar -xvf "$file"
    fi
done
```
## 1.3 Git:
### 1.3.1 git设置 
- 注意, 配置了`git config --global`时，才会在~下创建.gitconfig, 默认情况下并没有这个文件。
- git配置别名: `git config --global alias.st status`
- git查看配置：`git config --list`，全局配置`git config --global --list`
```
# version: 1.0
# screenSize: 1440*900
```
### 1.3.2 迁分支
直接创建并迁移到新分支:
```
git checkout -b R202512P2 origin/R202512P2
```
这个命令等价于:
```
git branch R202512P2 origin/R202512P2  # 基于远程分支创建本地分支
git checkout R202512P2               # 切换到新分支
git branch --set-upstream-to=origin/R202512P2 R202512P2  # 建立关联
```
如果远端分支是别人刚刚新建的，那么自己这边本地是看不见的，可以先fetch后，再迁分支：
```
# 1. 拉取远程所有分支信息（更新本地缓存的远程分支列表）
git fetch origin
# 2. 基于远程分支创建并切换本地分支
git checkout -b branch1 origin/branch1
```
- 注意：
    - 虽然`git fetch R202512P2:R202512P2`也可以拉去远端分支，并直接创建本地分支,但是注意这样并不会自动关联, 需要手动关联，而`git checkout -b R202512P2 origin/R202512P2`是会自动关联的。
    - `git fetch R202512P2:R202512P2`的价值在于刷新本地分支，使用远程仓库强制覆盖本地，下面会叙述。
- 如果本地已经有R202512P2分支了，且上面有一些自己的提交，这些提交是有用的，那么如何同步分支？
    - 最简单的：`git pull -r`或者`git pull --rebase`
    - 或者可以先fetch, 再变基, 将本地分支R202512P2的提交“嫁接”到 origin/R202512P2 最新提交之后:
        - `git fetch; git checkout R202512P2;git rebase origin/R202512P2;`
- 如果不需要本地的这些提交了, 比如提交gerrit后abandon,此时如何同步分支呢？
    - 最戳的方法，就是先强制删除本地分支，再重新迁分支(但是显然太不优雅了):`git checkout -b R202512P2_tmp; git branch -D R202512P2;git checkout -b R202512P2 origin/R202512P2;git branch -D R202512P2_tmp;`
    - 稍微优雅一点的是, 直接回退代码丢失掉本地的提交即可, 如:
        - `git reset --hard HEAD~2`
    - 更优雅的方式是git fetch直接覆盖, 因为是直接覆盖而不是合并, 所以要注意会丢失提交, 慎用,(origin为默认的,可省略)：
        - `git fetch origin R202512P2:R202512P2`
        - 或者`git fetch R202512P2:R202512P2`
##1.4 查看文件及文件夹大小：
- du命令:
    - 查看当前目录总大小： `du -sh `(-s表示仅显示总计, -h：以人类可读的格式如 KB、MB、GB显示)。 
    - 查看当前目录下每个子目录的大小(非递归, 仅当前一级子目录)：`du -sh ./*`
    - 指定递归深度查看目录大小:`du -h --max-depth=1` --max-depth=1表示仅显示当前目录及其一级子目录的大小。
- ls 命令：
    - 可以列出文件和文件夹的大小，但不适合递归统计整个目录：
    - 以字节为单位显示文件大小: `ls -l`;
    - 以更直观的格式（KB、MB、GB）显示文件大小：`ls -lh`;
- df 命令:
    - 查看磁盘分区使用情况： `df -h -h`：以人类可读格式显示。
    - 查看特定目录所在分区的剩余空间：`df -h /path/to/directory`;

# QA环境准备
- source环境
验证bug要用非回归版本环境, 激活非回归版本：
```
adv模式：source /pla/products/aether/R202512P2_AE/setup_3.9.csh
fpd模式：source /pla/products/aetherfpd/R202512P2_FPD/setup_3.9.csh
mw模式：source /pla/products/aethermw/R202512P2_MW/setup_3.9.csh
```
- 激活回归版本环境：
```
adv模式：source /cicd/jenkins/aether/workspace/case/R202512P2/tools/setup.csh.ic 3.9
fpd模式：source /cicd/jenkins/aether/workspace/case/R202512P2/tools/setup.csh.fpd 3.9
mw模式：source /cicd/jenkins/aether/workspace/case/R202512P2/tools/setup.csh.mw 3.9
```
- 查看pyAether doc:
```
firefox /pla/products/aether/R202512P2_AE/emprean/tools/pyaether/docs/html/index.html
```
# Bug Case录制
- 如果bug描述没有指定adv/fpd/mv, 一般直接用adv即可;

- 常用的公共测例:
```
#!/bin/sh
cp -r ${PY_COMMON_TESTCASE}/comm/test_40ll.tgz .
#cp -r ${PY_COMMON_TESTCASE}/adv/smic14_adv.tgz .
```

# Bug流转流程
![title](https://leanote.com/api/file/getImage?fileId=68f09d54ab644172fc8fbae4)
# 日常回归自动分配处理流程
### 1 要求
- 1. 当天回复邮件。
- 2. 如果不是自己导致的，需要找出是谁导致的，回复邮件时cc给这个人。
- 3. 如果自己run_reg.sh可以跑过，去10.2.2.175网页上查看失败原因，然后逐步确认是否存在以下几种情况：
    - ① 文本顺序不一致导致的失败 （可以通过vi或者bcompare查看tar.gz文件中的postOperate.sh是否进行了sort排序，请联系录制者修改没有排序的reg case）
    - ② 运行时间长被杀掉了（自己run_reg.sh运行时间超过2分钟）
    - ③ 跑多次存在随机失败的情况
    - ④ 多线程失败
    - ⑤ 模仿bsub去指定服务器运行，查看失败原因

- 参考链接：http://10.2.1.190/wiki/#/team/7188kNqW/space/GCoUNsNP/page
/yrTXzuzA

# Code Commit说明
## 1. Z6
### 1.1 准备工作：
`z6/.git`下的`hooks`链接到`/cicd/devops/latest/git/hooks_z6`,具体命令如下(注意，要么先删除掉hooks, 要么先备份一下hooks，执行ln -s时.git下不要有hooks文件夹):
```
ln -s /cicd/devops/latest/git/hooks_z6 hooks
```
家目录下的.cshrc中
```
source /pla/tools/setup.csh
```
注意：R分支最后提交合并是git review, 而不是git push.
### 1.2 commit字段
- `Branch`： 提交所属的分支
- `IP`：
    - 例如`[SZ] 50.2.2.69` ，其中`[SZ]/[CD]/[BJ]I[SH]`自动生成,切勿更改。
50.2.2.69为git commit代码时所在服务器。
    - IP增加[SZ]/[CD]/[BJ]/[SH]的原因:
        - 区分4地提交，jenkins分别对于此字段进行判断。
        - 例如, `IP:[SZ]50.2.2.69`为深圳服务器提交的代码, 则会触发jenkins链接为深圳的链接, 此jenkinsjob上挂载的为深圳的服务器, 即整体的code提交流程均在深圳服务器完成(编译+跑case).
    - 注意:
    aether包及Report结果均在触发地当地,不需要研发跨地域进行验证包的正确性。即北京提交的代码打的包请在北京查找;成都在成都查找;其它两地相同。
- `CaseResult Path`:
    - 当第一次提交代码经过编译、run case等阶段后,部分case失败时,`确认这些case需要重新修改，则将这些case用jenkins打的包跑一遍，将自跑的结果路径填写到此项`。
    - 正常情况下，二次提交时才可能修改其值。
    - 注意：
        - 此自跑结果需和IP地址对应。jenkins需要把此结果cp到北京公共目录,有时需要跨服务器,所以文件存放的服务器需要是IP所指的服务器。
        - 自跑有两种方式：
            - LSF方式：`指定的路径下有job.json文件`。即使用lsf跑case时生成的目录路径(包含report.txt,job.json, index.html等）
            - run_reg.sh方式：
            由于run_reg方式自跑时，生成的result*目录文件，填写的实际上是生成的result目录的上一级目录, 这一级目录可以包含多个result子目录。 
            cases/../xxx.tar.gz为一个完整的case名称，所以result*目录中caseListA.log中的case名称必须是包含从cases开始的目录结构的，而不是一个单纯的xxx.tar.gz名称;
            填写的这个路径,下面只包含自跑的结果目录result*,不能存在其他文件。
- `Assigned Report`：
    - 结合CaseResult Path使用,默认N0。二次提交时修改其值。
    - NO：会将自跑结果与jenkins该branch跑的最新的case结果进行比较(研发刷case时，就是这样，因为case已经修复，自跑的结果理论上是要和最新的case一致的)。
    - yes：会将自跑结果与jenkins该commiter+branch跑的最新的case结果进行比较(case没修复，先自己和自己比较，通过了再说)。
    - gerritid_patchid：`填写gerritid_patchid时,对比结果时会取指定buildid的结果进行比较。`此选项解决的问题:
        - 同一个研发同一分支上,在一笔z6提交case未完全通过没有处理的情况下,又提交了第二份不同的代码,第二份代码也是因为case未完全通过fail这样再次处理第一个提交时,对比的report文件就会错乱的问题。
    - 引入gerritId_patchId的原因：
        - 由于提交代码分别运行在多地，分为4个job，这样每个job就会存在相同的buildlD(ienkins生成的id号)，为了提交case时能够准确找到自己想要找到的工具包，而不是想要找成都ienkins触发buildlD为3的代码打出的工具包但是找到了上海ienkins触发buildlD为3的代码打出的工具包的情况。
        - 为保证各地包的准确及唯一性,因为大家使用的gerrit为同一个,不会存在gerritid重复的情况，因此将jenkins的buildlD改为gerritlD pathD,保证每个包的唯一性
- `Coverage`:
    - 默认[NO]。可填写字段:`yes/ic/fpd/mw/icfpd/icmw/fpdmw`, (不带[])任选一，合包时修改其值。
    - yes:
    编译ic/fpd/mw三种模式, run case:adv模式跑adv+comm目录下case;fpd模式跑fpd+comm目录下case，mw模式跑mw+comm目录下case;
    - ic:
    编译ic模式，run case:adv模式跑adv+comm目录下case;
    - fpd:
    编译fpd模式，run case:fpd模式跑fpd+comm目录下case;
    - mw: 
    编译mw模式，runcase:mw模式跑mw+comm目录下case，
    - icfpd:
    编译ic/fpd模式，run case:adv模式跑adv+comm目录下case,fpd模式跑fpd+comm目录下case;
    - icmw
    编译ic/mw模式，run case:adv模式跑adv+comm目录下case，mw模式跑mw+comm目录下case;
    - fpdmw:
    编译mw/fpd模式，run case:mw模式跑mw+comm目录下case,fpd模式跑fpd+comm目录下case;
- `Coverage casePath`:
    - 默认None。可填字段:指定文件路径。合包时修改其值。
    - 此字段表示，`表示跑Coverage/valgrind时,所需跑的case路径(这些case需在开发分支的reg库可以找到。`eg:test分支向R202209P1分支合并，这些case需要提交到test分支的gitlab上)，case的路径包含cases/xxxxxx/xxx.tar.gz,即包含cases目录结构直到tar.gz
    
- `Valgrind`:
    - 默认[NO]。可填字段:yes/ic/fpd/mw。
    - valgrind模式跑case,检查代码内存问题。合包时修改其值。
    - yes:
        - 编译ic/fpd/mw三种模式,
        - run case:
            - /adv/目录下跑adv模式的case;
            - fpd目录下跑fpd模式的case;
            - mw目录下跑mw模式的case:/comm/目录下跑mw、fpd、adv模式的case
        - 最好能实际情况选择模式 选择yes模式三种模式时间较长。
    - ic:
    编译ae模式，run case:comm/adv目录下跑adv模式的case
    - fpd:
    编译fpd模式，run case:comm/fpd目录下跑fpd模式的case
    - mw:
    编译mw模式，run case:comm/mw目录下跑mw模式的case
    
- `Commit by`: 
提交者。默认为自己
- `Onesld`:
默认None。可填写ones上对一个的bugid。可填多个，以空格隔开
- `Compiler Mode`：
    - 默认None。可填字段：yes/ic/fpd/mw。
    - yes: 编译ic/fpd/mw/pt四种模式，run case：
        - ic模式跑 /comm/, /adv/, /advfpd/, /advmw/下的case;
        - fpd模式跑 /comm/, /fpd/, /advfpd/, /fpdmw/下的case;
        - mw模式跑/comm/, /mw/, /advmw/, /fpdmw/下的case;
        - pt模式跑/comm/, /pt/下的case.
        - 最好能实际情况选择模式, 选择yes模式四种模式时间较长.
    -  ic: 编译ae模式，run case：/comm/, /adv/, /advfpd/, /advmw/下的case
    -  fpd: 编译fpd模式，run case： /comm/, /fpd/, /advfpd/, /fpdmw/下的case
    - mw: 编译mw模式，run case：/comm/, /mw/, /advmw/, /fpdmw/下的case
    - pt: 编译pt模式，run case：/comm/, /pt/下的case
    - None: 如果是主分支，与yes作用相同。 如果是开发分支：根据提交文件自动匹配编译模式。

- `Related Command`:
    - 此命令从data/xml中提取的aether执行码命令和keyword中定义的某些命令；
        - 一般来说填写data/xml中定义的执行码命令，
        - 支持正则表达式。测试填写的正则表达式所匹配到的命令有哪些，请先使用`sax:/cicd/devops/tools/extractCmdXml.py`脚本查看，-h查看帮助
        - 可填写的tcl命令：`/cicd/devops/tools/cmd_case.list`, 此文件中为所有数据库中可用的tcl命令(北京)。
        - 可填写的keyword在`/cicd/devops/latest/config/code/aether/keyWord.list`中,该list文件中主要是一些路径, 比如`/py/dbcmd/`, `/advancederr/`等, 可以配合find命令查找cases下的这些具体路径在哪里,请自行查看。
    - 基本格式：
        - 多个命令用空格隔开
        - cmd1&cmd2&cmd3:取同时拥有三个命令的case的集合
        - cmd1 cmd2 cmd3:取包含任一命令的case的集合    
    - 如果需要添加keyword，请项目经理同我或者王雨说。
- `Detail Description`:提交信息描述。字符数量大于20

- `ASAN`：
    - AddressSanitizer（ASan）工具的任务。ASan 是 Google 开发的内存错误检测工具，可检测使用已释放内存、堆内存越界等问题。
    - 合包流程可触发Asan 任务。ASan可填写字段为:[No]、yes、fpd、mw、ic,默认值为[NO]。
        - 填写字段为默认值[NO]时,不触发ASan检查任务;
        - 填写字段为yes时,同时触发fpd、ic和mw 模式的ASan检查任务;
        - 填写字段为ic时,只触发ic 的ASan检查任务:
        - 填写字段为fpd时，只触发fpd的ASan检查任务;填写字段为mw时，只触发mw的ASan检查任务。
    - yes: 编译ic/fpd/mw三种模式，run case：
        - ic模式跑 /comm/, /adv/, /advfpd/, /advmw/下的case；
        - fpd模式跑 /comm/, /fpd/, /advfpd/, /fpdmw/下的case ;
        - mw模式跑 /comm/, /mw/, /advmw/, /fpdmw/下的case.
        - 最好能实际情况选择模式, 选择yes模式三种模式时间较长.
    - ic: 编译ae模式，run case：/comm/, /adv/, /advfpd/, /advmw/下的case
    - fpd: 编译fpd模式，run case： /comm/, /fpd/, /advfpd/, /fpdmw/下的case
    - mw: 编译mw模式，run case：/comm/, /mw/, /advmw/, /fpdmw/下的case
    - 注：Asan暂不支持pt模式
    
- 参考链接：
http://10.2.1.190/wiki/#/team/7188kNqW/space/PR7F1ZLS/page/3AxRKii6

## 2. Reg
## 2.1 准备工作:
- `reg/.git`下的`hooks`链接到`/cicd/devops/latestgithooks_reg`, 具体命令如下:
```
In -s /cicd/devops/latestgit/hooks_reg hooks
```
- 家目录下的.cshrc中添加:
```
source /pla/tools/setup.csh
```
- R分支最后执行的是git review, 而不是git push, 切记!
## 2.2 reg commit:
- `Branch`: 提交代码的所属分支；
- `OnesId`：默认None，可以填写Ones上任意一个bug id，可以填写多个，以空格隔开；
- `Commit by`：提交者，默认为自己；
- `Use My Aether[SZ]/[CD]/[BJ]/[SH]`:
    - 默认为No，可填字段：`yes，no，gerritId_patchId`, 作用：指定Aether包跑case；
    - [SZ]/[CD]/[BJ]/[SH]自动生成，切勿修改。增加此字段的原因：区分4地的提交，jenkins分别对于此字段进行判断。
    - `Yes`：匹配`user+branch`，找到指定提交者+分支gerritId最大中patchId最大的Aether包。研发可以填写yes，测试不能填写，因为测试人员没有提交过z6的代码，匹配不到user+branch的组合。
    - `No`：匹配`branch`，找到指定分支中时间gerritId最大中patchId最大的Aether包；
    - `gerritId_patchId`:匹配gerritId_patchId, 找到Aether包名中有指定gerritId_patchId的Aether包（指定gerritId_patchId触发的jenkins必须包含编译过程），此gerritId_patchId为提交z6代码时对应的gerritId和patchId，而不是提交reg case时对应的gerritId和patchId。
    
- `Detail Despcription`：提交信息描述，要求字符数量大于20。

lee-romantic 's Blog

导航

最近发表

友情链接