pytest+jenkins+allure 生成测试报告发送邮件

 

 

 

前言

本次集成示意图

解释：

1. 代码来自IDE、SVN、GIT、xCopy 此处咱们用的IDE commit代码到 git(State)缓存区状态

2. 多人协同的话merge代码到git(State), 不然直接 push 代码到中央仓库 (此处咱们用Gitee)

3. 若是推送成功，程序根据预先设置的webhook进行飞书机器人提醒

4. jenkins有两种方式检测是否进行拉取代码进行构建

   • 自带的post build插件，自动检检测到代码有合并 ，trigger拉取事件进行CICD流程

   • 手工设置定时任务进行触发 ，即SchemeTask定时任务

5. 构建成功，发送邮件到飞书邮箱

6. 飞书邮箱里的URL地址连接打开连接到jenkins上关联的报告，报告可否打开取决于先前在jenkins上设置的权限认证，匿名用户配置具备查看Job 以及报告的权限

第一部分：Pycharm for Gitee

1. pycharm安装gitee插件

点击File

点击Settings...

弹出

点击Plugins

输入gitee，以下图

点击Search in repositories

弹出下图

点击Install（绿色的）

等待安装便可

而后到从新启动pycharm

看到上图的Checkout from Version Control下有Gitee

说明安装成功了

2. gitee关联本地Git

快速设置— 若是你知道该怎么操做，直接使用下面的地址

强烈建议全部的git仓库都有一个README, LICENSE, .gitignore文件

Git入门？查看 帮助 , Visual Studio / TortoiseGit / Eclipse / Xcode 下如何链接本站, 如何导入仓库

简易的命令行入门教程:

Git 全局设置:

git config --global user.name "Young"
git config --global user.email "vincentsys@yeah.net"

建立 git 仓库:

mkdir test
cd test
git init
touch README.md
git add README.md
git commit -m "first commit"
git remote add origin https://gitee.com/vincentsys/test.git
git push -u origin master

已有仓库 ?

cd existing_git_repo
git remote add origin https://gitee.com/vincentsys/test.git
git push -u origin master

 

3. Git关联远程仓库

一.本地安装GIT版本控制软件

二.配置Git,设置用户信息

git config --global user.name "Youngg"
​
git config --global user.email "vincentsys@yeah.net"

git config --list 获取Git配置信息

注意：git config命令的--global参数，用了这个参数，表示你这台机器上全部的Git仓库都会使用这个配置，固然也能够对某个仓库指定不一样的用户名和Email地址。

三.Git链接远程仓库Gitee

1. 在本地根据配置帐户(user.name)生成密钥

　　命令: ssh-keygen -t rsa -C "vincentsys@yeah.net"

2. 在GitHub里配置密钥

   登陆GitHub帐户，在SSH keys里添加sshkey（打开.ssh文件下的 id_rsa.pub文件把密钥复制到Gitee ）

 

 

 

 

 

 

 

3. 检验是否连接上了github

The authenticity of host 'github.com (192.30.252.131)' can't be establis

RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.

直接yes

链接成功!

四.本地远程仓库关联

1. 在Gitee上建立仓库

2. 本地建立仓库

3. 本地仓库链接远程仓库

4. 远程本地仓库同步

5. 修改本地提交远程

   @1.添加文件

@2.把文件添加到版本库

第一步 git add 0701.txt ，命令git add告诉Git，把文件添加到仓库

第二步git commit -m 'first commit 命令git commit告诉Git，把文件提交到仓库，

-m后面输入的是本次提交的说明，能够输入任意内容，固然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

@3.把本地推送到远程

此时已提交到远程

常遇问题

 

 

第二部分：Jenkins for Gitee

（一）简介

Gitee Jenkins Plugin 是Gitee基于 GitLab Plugin 开发的 Jenkins 插件。用于配置 Jenkins 触发器，接受Gitee平台发送的 WebHook 触发 Jenkins 进行自动化持续集成或持续部署，并可将构建状态反馈回Gitee平台。

1. 目前支持特性：

• 推送代码到Gitee时，由配置的 WebHook 触发 Jenkins 任务构建。

• 评论提交记录触发提交记录对应版本 Jenkins 任务构建

• 提交 Pull Request 到Gitee项目时，由配置的 WebHook 触发 Jenkins 任务构建，支持PR动做：新建，更新，接受，关闭，审查经过，测试经过。

• 支持 [ci-skip] 指令过滤 或者 [ci-build] 指令触发构建。

• 过滤已经构建的 Commit 版本，如果分支 Push，则相同分支Push才过滤，如果 PR，则是同一个PR才过滤。

• 按分支名过滤触发器。

• 正则表达式过滤可触发的分支。

• 设置 WebHook 验证密码。

• 构建后操做可配置 PR 触发的构建结果评论到Gitee对应的PR中。

• 构建后操做可配置 PR 触发的构建成功后可自动合并对应PR。

• 对于 PR 相关的全部事件，若 PR 代码冲突不可自动合并，则不触发构建；且若配置了评论到PR的功能，则评论到 PR 提示冲突。

• PR 评论可经过 WebHook 触发构建（可用于 PR 触发构建失败是便于从Gitee平台评论从新触发构建）

• 支持配置 PR 不要求必须测试时过滤触发构建。（可用于不需测试则不构建部署测试环境）

• 支持相同 PR 触发构建时，取消进行中的未完成构建，进行当前构建（相同 PR 构建不排队，多个不一样 PR 构建仍需排队）

2. 计划中特性

1. PR 审查并测试经过触发构建（可用户触发部署，且可配合自动合并 PR 的特性完善工做流。）

2. 勾选触发方式自动添加WebHook至Gitee。

（二）插件安装

1. 在线安装

   • 前往 Manage Jenkins -> Manage Plugins -> Available

   • 右侧 Filter 输入： Gitee

   • 下方可选列表中勾选 Gitee（如列表中不存在 Gitee，则点击 Check now 更新插件列表）

   • 点击 Download now and install after restart

1. 手动安装

   • 从 release 列表中进入最新发行版，下载对应的 XXX.hpi 文件

   • 前往 Manage Jenkins -> Manage Plugins -> Advanced

   • Upload Plugin File 中选择刚才下载的 XXX.hpi 点击 Upload

   • 后续页面中勾选 Restart Jenkins when installation is complete and no jobs are running

（三）插件配置

1. 添加Gitee连接配置

1. 前往 Jenkins -> Manage Jenkins -> Configure System -> Gitee Configuration -> Gitee connections

2. 在 Connection name 中输入 Gitee 或者你想要的名字

3. Gitee host URL 中输入Gitee完整 URL地址： https://gitee.com （Gitee私有化客户输入部署的域名）

4. Credentials 中如还未配置Gitee APIV5 私人令牌，点击 Add - > Jenkins

   1. Domain 选择 Global credentials

   2. Kind 选择 Gitee API Token

5. Scope 选择你须要的范围

   4. Gitee API Token 输入你的Gitee私人令牌，获取地址：https://gitee.com/profile/personal_access_tokens

6. ID, Descripiton 中输入你想要的 ID 和描述便可。

7. Credentials 选择配置好的 Gitee APIV5 Token

8. 点击 Advanced ，可配置是否忽略 SSL 错误（视您的Jenkins环境是否支持），并可设置连接测超时时间（视您的网络环境而定）

9. 点击 Test Connection 测试连接是否成功，如失败请检查以上 3，5，6 步骤。

配置成功后如图所示：

2. 新建构建任务

前往 Jenkins -> New Item , name 输入 'Gitee Test'，选择 Freestyle project 保存便可建立构建项目。

3. 任务全局配置

任务全局配置中须要选择前一步中的Gitee连接。前往某个任务（如'Gitee Test'）的 Configure -> General，Gitee connection 中选择前面所配置的Gitee连接，如图：

4. 源码管理配置

前往某个任务（如'Gitee Test'）的 Configure -> Source Code Management 选项卡

1. 点击 Git

2. 输入你的仓库地址，例如

   git@your.gitee.server:gitee_group/gitee_project.git

   1. 点击 Advanced 按钮, Name 字段中输入 origin， Refspec 字段输入 +refs/heads/*:refs/remotes/origin/* +refs/pull/*/MERGE:refs/pull/*/MERGE ，注意新版jenkins再也不接受多条同时包含 * 通配符的refs描述，如只对push触发可写前半部分，如只对PR触发可只写后半段。具体可见下图：

3. 凭据Credentials 中请输入 git 仓库 https 地址对应的 用户名密码凭据，或者 ssh 对应的 ssh key 凭据，注意 Gitee API Token 凭据不可用于源码管理的凭据，只用于 gitee 插件的 API 调用凭据。

4. Branch Specifier选项:

   1. 对于单仓库工做流输入: origin/${giteeSourceBranch}

5. 对于 PR 工做流输入: pull/${giteePullRequestIid}/MERGE

6. Additional Behaviours选项：

   1. 对于单仓库工做流，若是你但愿推送的分支构建前合并默认分支（发布的分支），能够作如下操做：

   2. 点击 Add 下拉框

      2. 选择 Merge before build

   3. 设置 Name of repository 为 origin

      4. 设置 Branch to merge to 为 ${ReleaseBranch} 即您要合并的默认分支（发布分支）

   4. 对于 PR 工做流，Gitee服务端已经将 PR 的原分支和目标分支做了预合并，您能够直接构建，若是目标分支不是默认分支（发布分支），您也能够进行上诉构建前合并。

配置如图所示：

5. 触发器配置

前往任务配置的触发器构建： Configure -> Build Triggers 选项卡

1. Enabled Gitee triggers 勾选您所须要的构建触发规则，如 Push Event, Opened Merge Request Events，勾选的事件会接受WebHook，触发构建。目前支持触发事件有：

   • Push Events ：推送代码事件

   • Commit Comment Events ：评论提交记录事件

• Opened Merge Request Events ：提交 PR 事件

  • Updated Merge Request Events ：更新 PR 事件

• Accepted Merge Request Events ：接受/合并 PR 事件

  • Closed Merge Request Events ：关闭 PR 事件

• Approved Pull Requests ： 审查经过 PR 事件

  • Tested Pull Requests ：测试经过 PR 事件

2. Build Instruction Filter :

   • None : 无过滤

   • [ci-skip] skip build ：commit message 或者 PR 说明包含 [ci-skip] 时，跳过构建触发。

• [ci-build] trigger build ：commit message 或者 PR 说明包含 [ci-build] 时，触发构建。

3. Ignore last commit has build 该选项能够跳过已经构建过的 Commit 版本。

4. Cancel incomplete build on same Pull Requests 该选项在 PR 触发构建时，会判断是否存在相同 PR 且未完成的构建，有则取消未完成构建，再进行当前构建。

5. Ignore Pull Request conflicts 该选项在 PR 触发构建时，会根据 PR 冲突状况选择是否进行构建。

6. Allowed branches 能够配置容许构建的分支，目前支持分支名和正则表达式的方式进行过滤。

7. Secret Token for Gitee WebHook 该选项能够配置 WebHook 的密码，该密码须要与Gitee WebHook配置的密码一致方可触发构建。

8. 注意：若 PR 状态为不可自动合并，则不触发构建。

6. 构建后步骤配置

前往任务配置的构建后配置： Configure -> Post-build Actions 选项卡

7. 构建结果回评至Gitee

1. 点击 Add post-build action 下拉框选择：Add note with build status on Gitee pull requests

2. Advanced 中能够配置：

   • Add message only for failed builds ：仅为构建失败回评到Gitee

   • 自定义各状态的回评内容（内容能够引用 Jenkins 的环境变量，或者自定义的环境变量）

3. 若开启该功能，还可将不可自动合并的状态回评至Gitee

8. 构建成功自动合并PR

点击 Add post-build action 下拉框选择：Accept Gitee pull request on success

9. 新建Gitee项目WebHook

进入源码管理配置中设置的Gitee项目中，进入 管理 -> WebHooks

1. 添加 WebHook， URL 填写 触发器配置：Build when a change is pushed to Gitee. Gitee webhook URL 中所示 URL，如：: http://127.0.0.1:8080/jenkins/project/fu

2. 密码填写：触发器配置第 5 点中配置的 WebHook密码，不设密码能够不填

3. 勾选 PUSH， Pull Request

10. 测试推送触发构建

1. Gitee的 WebHook 管理中选择勾选了PUSH的 WebHook 点击测试，观察 Jenkins 任务的构建状态

2. Gitee项目页面编辑一个文件提交，观察 Jenkins 任务的构建状态

11. 测试PR触发构建

1. Gitee的 WebHook 管理中选择勾选了 Pull Request 的 WebHook 点击测试，观察 Jenkins 任务的构建状态

2. 在Gitee项目中新建一个Pull Request，观察 Jenkins 任务的构建状态

（四）环境变量

目前支持环境变量见如下函数，其中不一样的 WebHook 触发可能致使有些变量为空，具体请安装插件 EnvInject Plugin，于构建中查看 Environment Variables

    public Map<String, String> getBuildVariables() {
       MapWrapper<String, String> variables = new MapWrapper<>(new HashMap<String, String>());
       variables.put("giteeBranch", branch);
       variables.put("giteeSourceBranch", sourceBranch);
       variables.put("giteeActionType", actionType.name());
       variables.put("giteeUserName", userName);
       variables.put("giteeUserEmail", userEmail);
       variables.put("giteeSourceRepoHomepage", sourceRepoHomepage);
       variables.put("giteeSourceRepoName", sourceRepoName);
       variables.put("giteeSourceNamespace", sourceNamespace);
       variables.put("giteeSourceRepoURL", sourceRepoUrl);
       variables.put("giteeSourceRepoSshUrl", sourceRepoSshUrl);
       variables.put("giteeSourceRepoHttpUrl", sourceRepoHttpUrl);
       variables.put("giteePullRequestTitle", pullRequestTitle);
       variables.put("giteePullRequestDescription", pullRequestDescription);
       variables.put("giteePullRequestId", pullRequestId == null ? "" : pullRequestId.toString());
       variables.put("giteePullRequestIid", pullRequestIid == null ? "" : pullRequestIid.toString());
       variables.put("giteePullRequestTargetProjectId", pullRequestTargetProjectId == null ? "" : pullRequestTargetProjectId.toString());
       variables.put("giteePullRequestLastCommit", lastCommit);
       variables.put("giteePushCreated", created ? "true" : "false");
       variables.put("giteePushDeleted", deleted ? "true" : "false");
       variables.putIfNotNull("giteePullRequestState", pullRequestState);
       variables.putIfNotNull("giteeMergedByUser", mergedByUser);
       variables.putIfNotNull("giteePullRequestAssignee", pullRequestAssignee);
       variables.put("giteeTargetBranch", targetBranch);
       variables.put("giteeTargetRepoName", targetRepoName);
       variables.put("giteeTargetNamespace", targetNamespace);
       variables.put("giteeTargetRepoSshUrl", targetRepoSshUrl);
       variables.put("giteeTargetRepoHttpUrl", targetRepoHttpUrl);
       variables.put("giteeBefore", before);
       variables.put("giteeAfter", after);
       variables.put("giteeBeforeCommitSha", before);
       variables.put("giteeAfterCommitSha", after);
       variables.put("giteeRef", ref);
       variables.put("ref", ref);
       variables.put("beforeSha", beforeSha);
       variables.put("isTag", isTag);
       variables.put("sha", sha);
       variables.put("status", status);
       variables.put("stages", stages);
       variables.put("createdAt", createdAt);
       variables.put("finishedAt", finishedAt);
       variables.put("duration", buildDuration);
       variables.put("jsonBody", jsonBody);
       variables.put("noteBody", noteBody);
       variables.putIfNotNull("giteeTriggerPhrase", triggerPhrase);
       return variables;
   }

（五）打包或运行测试

打包 hpi 文件在仓库目录中执行： mvn package

直接运行测试执行：mvn hpi:run

 

第三部分：jenkins构建APIAutomation项目

1.基础环境配置

• 安装allure-report插件

• JDK配置

  参考上一章jenkins关联jmeter自动化部署教程

• git配置

  参考上一章jenkins关联jmeter自动化部署教程

• allure配置

  Manage Jenkisn -> 全局工具配置 ，配置以下图所示

   

• gitee配置

  1. Manage Jenkins -> 系统配置，配置以下图所示

  2. 配置全局凭证：选择Gitee API令牌

  3. Gitee API 令牌生成，登陆gitee ->设置->私人令牌->生成

      

      

      

  4. 将如上生成的令牌粘贴进入测试以下所示成功

      

      

   

• 全局属性配置

  Manage Jenkins -> 系统配置->全局属性，配置以下图所示

• 字符编码配置

  1. Manage Jenkins -> 系统配置->全局属性

  2. Mange Jenkins -> Manage Nodes and Clouds

      

  3. 配置jenkins 启动文件

     添加以下内容:

     -Dhudson.model.DirectoryBrowserSupport.CSP= -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8

      

  4. 配置服务器环境变量

     设置jenkins所在服务器环境变量,右键个人电脑→属性→高级系统设置→环境变量，添加JAVA_TOOL_OPTIONS

  5. CMD配置

     chcp 65001

     在命令行标题栏上点击右键，选择"属性"->"字体"，将字体修改成True Type字体"Lucida Console"

 

2. 构建项目

源码管理

配置凭证

全部配置的凭证在首页都可查看

构建触发器

 

 

生成的webhook钩子程序复制生成的密码粘贴到Gitee 项目 ->管理 ->

构建

 

 

 

PATH=$PATH;D:\user\local\Python\Python38-32\Scripts
PATH=$PATH;D:\user\local\Python\Python38-32\Scripts
xcopy /y /c /h /r /s APIAutomatormation D:\user\workspace\py_workspace\APIAutomatormation\
cd /d D:/user/workspace/py_workspace/APIAutomatormation
pytest -s -q --alluredir result
rem D:\user\local\allure-2.13.8\bin\allure.bat generate   result -o report --clean
rem xcopy /y/c/h/r/s report C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins\workspace\APIAutomatormation\report
exit 0

构建后操做：添加Allure报告

 

 

 

 

 

第三部分：jenkins构建APIAutomation项目点击高级

构建后操做：邮件通知

邮件模板完整内容：

成功填写完成，build无误后 jenkins上会看到以下结果：

邮件成功通知：

邮件模板完整内容以下:

<!DOCTYPE html>
<html lang="en">
<body leftmargin="8" marginwidth="0" topmargin="8" marginheight="4" offset="0">
   <table width="95%" cellpadding="0" cellspacing="0" style="font-size: 11pt; font-family: Tahoma, Arial, Helvetica, sans-serif">
       <tr>
             测试邮件，无需回复！<br/>
             各位同事，你们好，如下为${PROJECT_NAME }项目构建信息</br>
             <h4><font color="red">allure报告在线查看or下载allure-report.zip用firefox离线查看，测试用例见附件</font></h4>
             <h2>在线图表测试报告：<br/>
             <a HREF="${PROJECT_URL}${BUILD_NUMBER}/allure">${PROJECT_URL}${BUILD_NUMBER}/allure</a><h2>
            
       </tr>
       <tr>
           <td><br/>
           <b><font color="#0B610B">项目描述：${JOB_DESCRIPTION}<br></font></b>
           <hr size="2" width="100%" align="center" /></td>
       </tr>
       <tr>
           <td>
               <ul>
                   <li>项目名称 ： ${PROJECT_NAME}</li>
                   <li>构建编号 ： 第${BUILD_NUMBER}次构建</li>
                   <li>SVN 版本： ${SVN_REVISION}</li>
                   <li>触发缘由： ${CAUSE}</li>
                   <li>构建状态： ${BUILD_STATUS}</li>
                   <li>构建日志： <a href="${BUILD_URL}console">${BUILD_URL}console</a></li>
                   <li>构建 Url ： <a href="${BUILD_URL}">${BUILD_URL}</a></li>
                   <li>工做目录 ： <a href="${PROJECT_URL}ws">${PROJECT_URL}ws</a></li>
                   <li>项目 Url ： <a href="${PROJECT_URL}">${PROJECT_URL}</a></li>
                   <li>系统allure测试报告：<a HREF="${PROJECT_URL}${BUILD_NUMBER}/allure">${PROJECT_URL}${BUILD_NUMBER}/allure</a><li>
               </ul>
　　　　</td>
       <tr>
　　　　     <td>
           <b><font color="#0B610B">构建日志 (最后 100行):</font></b>
　　　　   <hr size="2" width="100%" align="center" />
           </td>
       </tr>
       <tr>
　         <td>
               <textarea cols="80" rows="30" readonly="readonly" style="font-family: Courier New">${BUILD_LOG, maxLines=100}</textarea>
           </td>
       </tr>
       ${JELLY_SCRIPT}
   </table>
</body>
</html>

第四部分：采坑记录

一. 本地测试经过，上传代码等到gitee服务器运行到jenkins主机，出现以下目录or路径不存在

本地排查思路：

1. 看到有 unucodeescape 错误，开始觉得乱码致使，而后在每一个文件头加字符编码配置# _*_ coding:utf-8 _*_ 以后发现不可用

2. 看到提示No such file or directory ：在本机排查发现该文件在当前目录存在，可是就是为什么找不到，怀疑是sys.path没有将当前项目路径添加到 PYTHONPATH当中，修改代码以下：

    execFilePath = os.path.dirname(__file__) + '/testcase'
      # 追加logging
      # D:\user\workspace\py_workspace\APIAutomationFramework\testcase
      # execfile = execFilePath + '/test_API.py'
       
      # execfile = r'D:/user/workspace/py_workspace/APIAutomationFramework/testcase/test_API.py'
      #此处修改成绝对路径
      execfile = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'testcase', 'test_API.py')
      python_install_cmd = os.path.join(sys.path[10], 'python.exe')
      os.system("python " + execfile)

   以后发现仍然不可用，

   3. 定位代码logUtils类， 怀疑该行代码有问题

   查看对应的源码解析，排查到 **os.path.dirname(__file__)**引用相对路径的问题，查询结果以下

   python3 获取当前路径及os.path.dirname的使用

   方法一：

   import sys,os
   os.getcwd()#而后就能够看见结果了

   方法二：

   import os
   os.path.dirname(os.path.realpath('__file__'))#注意：添加单引号

   python中的os.path.dirname(file)的使用

   (1)当"print os.path.dirname(file)"所在脚本是以完整路径被运行的， 那么将输出该脚本所在的完整路径，好比：

   python d:/pythonSrc/test/test.py

   那么将输出 d:/pythonSrc/test

   (2)当"print os.path.dirname(file)"所在脚本是以相对路径被运行的， 那么将输出空目录，好比：

   python test.py

   那么将输出空字符串

   python中的os.path.dirname(path)

   语法：os.path.dirname(path) 功能：去掉文件名，返回目录 如：

   print(os.path.dirname('W:\Python_File\juan之购物车.py'))
   #结果
   #W:\Python_File
   print(os.path.dirname('W:\Python_File'))
   #结果
   #W:\

   参考博客：http://www.javashuo.com/article/p-fxxgkyic-vg.html

   而后并无卵用， 再次排查

   4. 定位到多是否因为fileConfig(p) 加载参数配置只能以windows环境下“\” 标识，查阅相关资料以下

   首先，"/"左倾斜是正斜杠,""右倾斜是反斜杠,能够记为：除号是正斜杠通常来讲对于目录分隔符，Unix和Web用正斜杠/，Windows用反斜杠，可是如今Windows 不限制，均可使用

   （一）目录中的斜杠们

   python读文件须要输入的目录参数，列出如下例子：

   path = r"C:\Windows\temp\readme.txt"

   path1 = r"c:\windows\temp\readme.txt"

   path2 = "c:\windows\temp\readme.txt"

   path3 = "c:/windows/temp/readme.txt"

   打开文件函数open()中的参数能够是path也能够是path一、path二、path3。

    

   path：""为字符串中的特殊字符，加上r后变为原始字符串，则不会对字符串中的"\t"、"\r" 进行字符串转义

   path1：大小写不影响windows定位到文件

   path2：用一个""取消第二个""的特殊转义做用，即为"\"

   path3：用正斜杠作目录分隔符也能够转到对应目录，而且在python中path3的方式也省去了反斜杠\转义的烦恼

   （二）正则表达式中的斜杠们

   正则表达式匹配反斜杠""，为何是"\\"或是 r"\"呢？

   由于在正则表达式中\为特殊符号，为了取消它在正则表达式中的特殊意义须要加一个\就变成了\，可是问题又来了，\也是字符串中的特殊字符，因此又要分别对两个\取消其特殊意义，即为\\。Python中有一个原始字符串操做符，用于那些字符串中出现特殊字符，在原始字符串中，没有转义字符和不能打印的字符。这样就能够取消了\在字符串中的转义功能，即r"\"。

   然而仍然没有卵用 ，

   5. 最后排查到最后一行代码：

   定位该行问题发现，该文件只有配置文件引用，在logging.conf 下

   的确因为该路径被找不到，目前很疑惑根本缘由暂未找到一样是windows操做环境，换台机器就没法操做，很让人疑惑，总之更改成项目路径好使

 

二. 本地测试，生成的报告单独在桌面直接用index打开数据没法加载，可是在IDE里能够

显示以下状况：

处于loading状态，说明有数据只是无法加载出来

问题解决

• 其实在allure-report下index.html文件是不能直接打开的，出现页面都是loading的状况，这是由于直接allure报告用浏览器是打不开的，须要用allure命令渲染以后打开才能展现效果（allure常识）。

• allure使用了两种方式来渲染页面。分别是 allure open 和 allure serve。前者用于在本地渲染和查看结果，后者用于在本地渲染后对外展现结果。这里咱们使用allure open。运行命令

   

allure open allure-report目录

便可自动打开浏览器展现渲染好的结果。这里的allure-report为allure generate生成的结果所在目录。

三. 集成到jenkins上发现结果无数据

这里有两两种场景：1. 一种是无数据 2. 一种是有数据只不过处于loading状态加载不出来

目前处于第1种结果：具体表现形式以下：

排查可能缘由：

1. 首先明确 pytest生成的数据默认在allure-result目录下，这里我更改了result目录，经过本地的IDE和cmd命令行发现没有问题，那么只能是jenkins windows Execute shell命令行有问题

   命令行内容以下

   xcopy  /y /c /h /r /s  APIAutomatormation  D:\user\workspace\py_workspace\APIAutomatormation\
   cd /d D:/user/workspace/py_workspace/APIAutomatormation
   python run_main.py 
   exit 0

   以后发现，是压根''python run_main.py '' 压根就没有执行，估计是jenkins内部没有识别python变量，手工添加python执行路径：

   $PYTHON_PATH\python.exe run_main.py

   发现执行到一半又不能执行了：

   定位到以下位置：

   发现代码里又引用了相对路径，再次添加绝对路径进行执行该命令，console控制乱码错误显示以下：

   估计问题不在这里，再次查询Google， 查到原来jenkins集成allure执行的时候是不须要手工执行生成报告的，查看会自动帮你作

2. 再次更改执行命令以下：

   PATH=$PATH;D:\user\local\Python\Python38-32\Scripts
   PATH=$PATH;D:\user\local\Python\Python38-32\Scripts
   xcopy /y /c /h /r /s APIAutomatormation D:\user\workspace\py_workspace\APIAutomatormation\
   cd /d D:/user/workspace/py_workspace/APIAutomatormation
   pytest -s -q --alluredir result
   D:\user\local\allure-2.13.8\bin\allure.bat generate   result -o report --clean
   exit 0 

   运行以后发现仍然没有数据，而且pytest -s -q --alluredir result 这行命令彷佛没有执行 ，发现pytest找不到该命令，实际path已经配置了python环境变量 ， 手工将pytest所在目录也添加到path环境变量中，显示以下：

3. 终于pytest能够执行了，可是report没有结果数据,查看jenkins console发现 取的report是工做空间目录的结果report数据 ， 因而手工复制生成的报告拷贝到jenkins工做空间当中

   命令行变为以下

   xcopy  /y /c /h /r /s  APIAutomatormation/report  C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins\workspace\APIAutomatormation\report

   然而很坑爹并无卵用

4. 再次查看result路径，发现其实生成了 result是有数据的，只不过没有体如今report里，原来jenkins 不用你手工生成报告，插件会自动帮你生成，最后一步取消 ；完整结果显示以下：

   PATH=$PATH;D:\user\local\Python\Python38-32\Scripts
   PATH=$PATH;D:\user\local\Python\Python38-32\Scripts
   xcopy /y /c /h /r /s APIAutomatormation D:\user\workspace\py_workspace\APIAutomatormation\
   cd /d D:/user/workspace/py_workspace/APIAutomatormation
   pytest -s -q --alluredir result
   exit 0

   完美解决

   最后构建后操做生成报告的地方必定要注意 result 和 report填写路径要正确，不然数据仍然不会展现的

 

至此，该篇幅文章讲解结束，以上都是博主亲自在公司实践记录的内容，若有描述错误的地方还请留言批评指出。