关于自动化测试的一点了解
一 自动化测试基础的认识
1)首先，什么是自动化测试？
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的过程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。测试自动化可以在已经存在的正式测试过程中自动化一些重复但必要的任务，或者添加额外的难于手工执行的测试。
2)自动化测试主要有哪些？
自动化测试一般分四种：单元自动化测试，接口自动化测试，WEBUI自动化测试,移动终端的自动化。其中单元自动化测试一般由研发人员自己进行测试，测试人员主要进行接口以及UI的自动化测试，但是由于UI的需求变化比较频繁，所以接口测试是测试人员做的最多的。
3)自动化测试框架设计的模式有哪些？
自动化测试框架设计的模式主要有4种：
- 分布式。指的是测试需要在多台电脑上进行多线程或者多进程的测试，该模式主要针对测试用例比较大的情况，常用的工具是grid；
- PO模式（Page Object）是UI自动化测试常采用的一种设计模式，用于解决开发频繁修改UI页面而导致的自动化脚本维护困难的问题。
PO模式中心思想：
每一个页面为一个对象；
每一个对象维护着页面中的各元素和操作方法；
用例测试脚本只需要聚集业务逻辑和测试数据；
UI页面的变更，只需要修改对应的PO对象，无需修改测试脚本（理想情况下。实际上也很难100%做到，因为UI的变更很多时候意味着业务逻辑的变更）。
(3)数据驱动的模式。指的是讲测试程序与测试所需要的数据分离，每次测试程序的时候直接调用所需要的数据；
DDT（Data Driven Testing）数据驱动测试模式，用来解决部分自动化用例逻辑完全相同，只有测试数据和预期结果不同的问题。实际上就是同一测试脚本使用不同的测试数据来反复执行（但脚本只需要写一个），测试数据和测试行为完全分离。
DDT中心思想：
将测试数据分离出来，单独维护；
减少重复自动化用例的数量。
将以上两种思想进行结合，就可以做成 对象、数据、业务行为 三者分离的模型，再结合模块进行管理，为后续自动化用例脚本的长期维护打下基础。否则时间一长自动化就会乱成一团，维护成本越来越高，陷入自动化率不升反降的怪圈。
- 关键字驱动的模式
在前面的基础上，可以进一步实现关键字驱动。即将业务逻辑相同的部分，抽象成关键字库。这样在写自动化用例脚本时，只需要写关键字和对应测试数据即可，可以进一步减少工作量，减少测试人员对代码的学习和依赖。
如基础平台查找项目时直接写脚本需要好多步：
定位到搜索框
输入关键字
定位到搜索按钮
点击搜索按钮
定位结果列表
获取结果并返回
以关键字驱动的思想，即将这6步抽象出一个方法project_search()，测试人员只需要写一句话就能完成以上所有动作获得结果。如：
result = project_search('新德家园')
方便、省时省力，测试人员可聚焦于产品业务，而不是自动化脚本和语言学习。
甚至可以直接在设计测试用例的时候写关键字，由自动化平台去解析用例，都不需要写脚本。这方面最有名的自动化框架就是RobotFrameWork。但是RobotFrameWork过于笨重。建议大家适当抽象即可，不要过度抽象。
该模式主要从对谁做，怎么做，做什么三个要素进行衍生，每次只需要调用关键的函数就可以，即使不懂代码的人也能勾编写。现在很多的自动化测试工具例如KAMA即是如此，测试人员只需要了解测试功能的逻辑通过调用工具的内部函数就可以编写自动化测试脚本；
(5)混合型模式。指的是运用以上两种或以上的方法的一种模式。
4)自动化测试的优势
主要具备以下优势：
(1)回归测试更方便可靠，可运行更多、更繁琐的测试，且快速高效；
(2)可执行一些手工测试执行相当困难或者做不到的测试，如大量的用户并发；
(3)可以更好的利用资源，具有一致性和可重复性的特点，自动化测试脚本完全可复用；
(4)提升了软件的可信度；
(5)可以多环境下测试等。
5)自动化测试的不足
(1)永远不可能完全替代手工测试。自动化测试无法做到手工测试的覆盖率，不是每个测试用例都适合实行自动化；
(2)手工测试发现的bug远比自动化测试多。自动化测试几乎是无法发现新bug的，最大的用途是用来回归，确保曾经的bug没有在新的版本上重新出现；
(3)自动化测试工具比较死板，灵活性比较差。自动化测试的效果好坏，完全取决于测试工程师
(4)成本投入大，风险高。对测试人员的技术要求高，对测试工具同样也高；
(5)测试用例需要根据版本迭代进行更新，有一定的维护成本；
(6)自动化测试的产出价值往往在于长期的回归测试，短期内发挥的作用可能不明显。
6)适合引入自动化测试的情况
(1)回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；
(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；
(3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性；
(4)自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖；
(5)项目周期长，系统版本不断，并且需求不会频繁变更；
(6)系统的测试对象基本可以正常识别，以及对无法识别的控件能否提供一个解决方案；
(7)系统中不存在大量的不可识别第三方控件；
(8)需要反复测试，如可靠性测试、回归测试等需要进行上千次的系统测试。
7)不适合自动化测试的情况
(1)项目周期短，需求频繁变更。即使是周期长的项目，如果经常需求变更，也不适合做自动化测试；
(2)软件版本没有稳定，主功能或大量功能有被重新更改的可能的情况下，也不适合做自动化测试；
(3)没有明确的项目进行自动化测试计划、措施和管理的情况；
(4)多数对象无法识别，以及脚本维护频繁和艰难的情况下，不建议测试自动化。
以上是自动化测试入门的相关基础知识。
8)框架技术选择
大多数框架采用java语言或是python语言来实现，考虑到python容易掌握，各种库也比较全，所以采用python语言来实现。
python自动化框架最常用的有unittest和pytest，两者都可以，这里采用python自带的unittest。
对于WEB UI自动化测试，没有别的选择，基本都是采用selenium来驱动浏览器来完成。
对于接口自动化测试，可采用的办法较多，postman、jmeter都可以，但灵活性都不如直接采用python的request库。
Robot framework Robot Framework是python语言编写的功能自动化测试工具。具有良好的扩展性，支持关键字驱动，支持同时测试多种类型的客户端或者接口，还可以进行分布式测试。
Robot Framwork，通过这个来做自动化，别以为不要学习Selenium跟python了， 因为Robot Framework中的关键字可能不够用，不能满足你们的需求，那么我们需要自定义关键字
数据驱动，由于unittest没有直接可用的dataprovider，采用常见的ddt来实现。
对于手机自动化，暂未实现，后续考虑加入，可采用appnium来实现。
持续集成,集成到jenkins.
测试数据，第1阶段采用excel管理，对于大型系统，建议直接采用数据库进行管理。
所以总的来讲，这个所谓的框架，就是东拼本凑，即没有新思想，也没有新技术，只是将一些常用的技术，按一定的思路组织起来、驱动起来而已。
二 如何做接口自动化测试
1) 单个接口的自动化测试
1根据接口要求在/data文件夹中，根据业务系统找到对对应的yml添加对应的测试数
据;
注意：为了做好接口测试，每个接口抛出的业务异常，需要规范化的定义好对应的code 和 message 也有利于测试数据的制造
对于多个值的字段直接数组;
2 去/data文件夹 找到对应的业务系统和功能模块 录入对应的请求路径;最好写好接口是干什么的注释
3 关键字封装，如把多个Python接口封装为关键字；到operation目录下找到对应的模块编写
4 填写测试接口case
有前置条件的接口 需要写成测试场景case
需要写好allure 相关信息，结合Allure输出测试报告
5 测试结果报告
测试结果报告 主要是通过alllure来展示
当前要做单个接口的测试，首先要模拟进行登陆，获取token，转化token,最后请求接口
未按照 assert 的程序将不在往下执行，报错执行失败；也就是没有按照指定的执行流程来执行的算作执行测试用例失败。可以通过测试报告查看具体的接口测试的日志
以上也不是完全的单接口的测试，因为在进行单接口测试，需要调用模拟登陆，租户转换等接口
2) 接口场景化测试
- 关键字应该是具有一定业务意义的，在封装关键字的时候，可以通过调用多个接口来完成。在某些情况下，比如测试一个生成组织树接口的时候，在生成后可能需要调用查询接口得到最新组织树，来判断查询结果与预期结果是否一致，那么可以这样来进行测试：
- 1, 首先，可以把 生成-查询 的操作封装为一个关键字，在这个关键字中依次调用生成和查询的接口，并可以自定义关键字的返回结果。
- 2, 接着，在编写测试用例的时候，直接调用关键字来进行测试，这时就可以拿到关键字返回的结果，那么断言的时候，就可以直接对关键字返回结果进行断言。
先看一下demo 给的举例子
- 用例--注册/登录/查看--预期成功
分3个关键字： 注册 登陆 查询；每个关键字都是单个接口的请求
1 如何让一个测试用例在不改变数据的情况下重复执行呢？
为什么要可重复执行
A 保证测试case 的可重复执行是非常有必要的；比如这个测试用例 第一次执行 我们主要测正常数据是否可以 跑通，3个接口功能是否正常；第二次执行 注册/登陆 还是第一次执行的数据，但是查询变为其他数据 来用数据驱动测试的场景 这样就要可以重复执行，这是注册过的账号就不能重复执行了；
B 不用每次重复执行，都换一个新的账号进行注册
所以这里我们 需要重点关注哪些 唯一性数据的“关键字”，做好可重复执行工作
如何做：
做好“切面函数”，注册前 先删除数据 用例执行完后 在清理数据，这样我们一方面可以重复执行数据，另一方面 不会因为大量执行测试用例 产生大量的数据（这方面可以可以根据具体情况进行保留
2 场景测试的数据
和单接口测试的测试方式是不一样的，预期的code 和 msg 自定义的依据能可以是执行最后一个“关键字”为参考，而不一定是单个接口的返回作为参考的；可以理解为给一个“大函数”（多个关键字组合成） 定义好出入参数，最后做好assert
3 测试case 的定义流程
a 定义好测试数据
b 定义好“切面函数” 需要做前置或者后置操作的
c 定义好关键字
d 写好allure 的执行的步骤，方便打印到测试报告上
e 按照业务场景 组装执行不做 最后 assert 测试结果，每一步执行assert 不通过则终止测试 输出测试报告
4 预期失败的测试case
反向测试的用例，反向测试如果可以成功，说明程序是正常的，如果不成功就，程序接口就不正常
5 模拟一个查询接口测试
比如查询组织权限信息：现在我要知道我的测试用例，能不能覆盖一种场景，就是对于有些项目可以查出来，有些查不出这个比较独特的bug,比如 xx商务中心可以查出来，xx大厦 查不出来；
为了做好测试覆盖，我们模拟的数据要是可以明确，这些测试数据已经都被分配过项目
这种情况 我们要解决2个问题，一个是测试逻辑的判断，也就是我做模糊查询的结果的判断和断言，
另一个就是测试数据的循环测试；测试逻辑可以写入到“关键字”中，第二中可以直接写入到测试case 上：具体实现如下：(大家如果有这种case 可以参考)
对于多条执行的测试数据 转化测试数据 为列表即可，比第二种方式更好
将测试写入测试关键字中，这种逻辑可能会影响到其他测试case 共用函数可以通过参数分离
只要有一个本应该可以查询到的组织权限，但是查不到，本测试用例就不通过；前提是需要确保 测试的项目权限数据，都已经被分配过；测试数据导入到配置文件，后面得优化从excel 或者数据表中读取，方便测试
补充说明:场景测试数据，是通过配置化的文件信息录入的，不同的测试case 根据函数名去获取不同的测试数据
共用的前置需要处理，比如登陆操作，封装为前置函数
conftest.py这个文件主要放一些公共的内容；
大家后面有共性的内容都可以写入进来
6 模拟一个场景化测试：
//step1 模拟手机验证码，进行登陆; 一个关键字
//step2 创建公司 一个关键字
//step3 创建公司下的部门 一个关键字
//step4 创建部门下的项目 一个关键字
//step5 生成组织树/查询组织树 一个关键字
当然也可以优化为：
//step1 模拟手机验证码，进行登陆; 一个关键字
//step2 创建公司 一个关键字
//step3 生成组织树/查询组织树 一个关键字
最终要验证生成的树结构是否符合数据树结构要求排列；
这种封装的粒度，有些不利于测试，比如，我想更新 某个组织属性的不太方便的，所以还是需要将创建的组织节点进行分开处理，还是建议做成单接口的“关键字” 方便灵活的组装不同场景的测试用例
todo
三 自动化测试的范围
场景数据驱动:
根据不同的参数得到不同的结果
关键字驱动逻辑测试:
测试逻辑放到不同的“关键字”中
四 接口测试报告的查询
1、快速生成allure测试报告
allure会将测试用例的执行结果保存到测试结果数据文件当中，再通过allure命令将测试结果数据文件转换成html形式的测试报告。
（1）编写测试用例如下：
import pytest
def test_success():
"""this test succeeds"""
assert True
def test_failure():
"""this test fails"""
assert False
def test_skip():
"""this test is skipped"""
pytest.skip('for a reason!')
def test_broken():
raise Exception('oops')
'
运行运行
（2）pytest执行测试用例，保存测试结果到测试结果数据文件
pytest --alluredir=allure-results
项目如下，执行上面的命令将测试结果保存在allure-results文件夹中。
虚拟环境报错解决方案：python -m pytest --alluredir=allure-results
（3）从测试结果数据文件生成allure测试报告
allure generate allure-results
默认生成测试报告文件夹allure-report。
（4）打开allure测试报告
allure open allure-report
会使用默认浏览器打开allure测试报告
2 allure测试报告结构
https://docs.qameta.io/allure/#_report_structure
Overview：测试报告的整体概述页面。
Categories：类别选项卡为您提供了创建自定义缺陷分类以应用测试结果的方法
Suites：在“套件”选项卡上，可以找到按套件和类分组的已执行测试的标准结构表示。
Graphs：图表允许您查看从测试数据中收集的不同统计信息：状态细分或严重性和持续时间图
Timeline：该选项卡可视化测试执行的回顾，allure 适配器收集测试的精确时间，在此选项卡上，它们根据其顺序或并行时间结构进行排列。
Behaviors：对于行为驱动方法，此选项卡根据 Epic、Feature 和 Story 标签对测试结果进行分组。
Packages ：该选项卡表示测试结果的树状布局，按不同的包分组。
3、allure命令行参数大全
使用 allure --help 查看allure的所有命令行参数信息。
语法格式：
allure [options] [command] [command options]
参数说明：
[options]
--help ：打印allure命令行帮助信息
--version：打印allure版本信息
[command]
generate： 生成测试报告，默认：allure-report
用法：generate [options] <directory-with-results>
[options]参数：
-c, --clean 在生成新的测试报告文件之前，清除历史记录
-o, --report-dir, --output 指定生成测试报告的文件夹
open：使用默认浏览器打开测试报告
用法：open [options] <directory-with-report>
serve：生成测试报告到临时文件夹，然后使用默认浏览器打开测试报告
用法：serve [options] <directory-with-results>
4、allure常见命令
（1）以json文件格式保存测试结果：
pytest --alluredir=<directory-with-results>
（2）使用--clean-alluredir清除历史记录：
pytest --alluredir=allure-results --clean-alluredir
（3）从json格式的测试结果文件生成html格式的测试报告，默认生成测试报告文件夹allure-report：
allure generate <directory-with-results>
（4）使用-o更改生成测试报告的目标文件夹：
allure generate <directory-with-results> -o <directory-with-report>
（5）使用-c在生成新的测试报告文件之前，清除历史记录：
allure generate <directory-with-results> -o <directory-with-report> -c
（6）在默认系统浏览器中打开测试报告：
allure open <directory-with-report>
（7）生成测试报告到临时文件夹，然后直接使用web server打开测试报告：
allure serve <directory-with-results>
参考原文链接：pytest合集（15）— allure快速入门_allure使用教程-CSDN博客
管理历史测试用例的管理：
https://blog.csdn.net/songpeiying/article/details/138159479
4、allure测试报告分享
1、使用Anywhere插件分享Allure测试报告到局域网
工作中需要将测试报告分享给开发定位问题，或者分享测试报告给领导和同事。这个时候可以使用nodejs 的第三方模块anywhere实现简单快速分享。
Anywhere是一个基于 Node.js 的 Web 的文件服务器，可以将本地文件共享到 Internet。它使用简单、易于设置、支持多种文件类型和浏览器。使用 Anywhere 可以非常快速和方便地分享本地文件，特别适合用于在团队协作中分享文件或者在自己的设备与其他设备之间共享文件。
（1）安装nodejs
下载地址：下载 | Node.js
下载完之后按照步骤默认安装就行，安装完成后命令行输入命令"node --version"检查是否安装成功。
C:\Users\057776>node --version
v18.16.0
（2）安装anywhere
npm install anywhere -g
(3) 分享allure测试报告
allure-report测试报告文件夹路径下执行命令anywhere生成http和HTTPS服务。
在Allure中，Product defects类别是通过在程序中标记测试用例的结果为failed来定义的。当测试用例的实际执行结果不符合预期时，它会被标记为failed，这属于Product defects类别。Allure通过这种方式对测试用例的执行结果进行分类，帮助用户更好地理解和分析测试结果。此外，Allure还允许用户自定义缺陷分类，通过添加categories.json文件到allure-results目录中，可以创建自定义的缺陷分类，进一步丰富报告的内容和分析的维度；所有失败的用例都可在categories 上看到。
5 allure的内容以及用法
这一节主要是记录allure的内容以及用法，怎么让他生成一个完整的想要的报告。
allure生成的报告和其他五花八门的报告对比了一下，它的可读性是最好、最直观的;关于怎么安装的，请移步：
allure安装教程以及遇到的坑 - 漂泊的小虎 - 博客园
5.1 Allure相关装饰器函数
allure装饰器
# 作用：用于将测试用例的数据展示到测试报告中
# 导入：import allure
# 说明 ：
1.需要将这些装饰器函数添加测试方法或测试类的开头。
2.同一个类或者一个方法可以添加多个装饰器函数 ，这样此用例就具有了个作用属性 。
使用方法 参数值 参数说明
@allure.epic() epic描述 敏捷里面的概念，对用例或用例集进行描述分类
@allure.feature() 模块名称 与epic类似，只是比epic级别低
@allure.story() 用户故事 与epic类似，只是比feature级别低
@allure.title(用例的标题) 用例的标题 重命名html报告的用例名称
@allure.testcase() 测试用例的链接地址 与link类似
@allure.issue() 缺陷 与link类似
@allure.description() 用例描述 进行测试用例的描述
@allure.step() 操作步骤 进行测试用例的步骤
@allure.severity() 用例等级 blocker，critical，normal，minor，trivial
@allure.link() 链接 定义一个链接， 在测试报告展现（推荐使用）
@allure.attachment() 附件 报告添加附件
其实 ，在allure中主要分为以上的三部分，分别是用于集成在测试用例的装饰器函数 、 通过命令行命令收集测试用例的命令行工具、最后就是生成测试报告的展示 。
具体使用时，按照如下的流程实现即可 ：
在编写好的测试用例中添加allure装饰器函数 ，
在运行入口处编写运行allure执行命令 ，它就会生成测试报告
通过浏览器查看生成的测试报告 。
使用总结
将我们以上的装饰器整理后就是如下的结构 ，按照此结构可以整理出你的测试用例 。
如果你编写的测试用例装饰器函数都已经使用 ，那么它的层级就是如上的结构 ，当然这里还需要说明以下几点 ：
每一个装饰器都是可选项，可加可不加 。比如你把feature去掉了，那么在报告中就不展示这一层级了 ，其它也是如此。
epic、feature、story、title主要用来显示层级 ，而到了title层里，就是显示具体的内容 ，内容包括severity,description,testcase ,issue,link,step等
除了step和attachment比较特殊以外，它们都是放在方法内使用 ，其它的都是标注在测试方法的开头或者类的开头 。
那么，在项目中该怎么组织我们的测试用例呢 ？一般就是按照项目结构一层一层的组织下来 ，比如
5.2 命令行参数
命令行参数说明
所谓的命令行参数，就是通过cmd窗口运行的命令 ，如果你对allure的命令行参数不太清楚，可以打开cmd窗口输入：
allure --help
就可以看到如下的显示：
Usage: allure [options] [command] [command options]
Options:
--help
Print commandline help.
-q, --quiet
Switch on the quiet mode.
Default: false
-v, --verbose
Switch on the verbose mode.
Default: false
--version
Print commandline version.
Default: false
Commands:
generate Generate the report
Usage: generate [options] The directories with allure results
Options:
-c, --clean
Clean Allure report directory before generating a new one.
Default: false
--config
Allure commandline config path. If specified overrides values from
--profile and --configDirectory.
--configDirectory
Allure commandline configurations directory. By default uses
ALLURE_HOME directory.
--profile
Allure commandline configuration profile.
-o, --report-dir, --output
The directory to generate Allure report into.
Default: allure-report
serve Serve the report
Usage: serve [options] The directories with allure results
Options:
--config
Allure commandline config path. If specified overrides values from
--profile and --configDirectory.
--configDirectory
Allure commandline configurations directory. By default uses
ALLURE_HOME directory.
-h, --host
This host will be used to start web server for the report.
-p, --port
This port will be used to start web server for the report.
Default: 0
--profile
Allure commandline configuration profile.
open Open generated report
Usage: open [options] The report directory
Options:
-h, --host
This host will be used to start web server for the report.
-p, --port
This port will be used to start web server for the report.
Default: 0
plugin Generate the report
Usage: plugin [options]
Options:
--config
Allure commandline config path. If specified overrides values from
--profile and --configDirectory.
--configDirectory
Allure commandline configurations directory. By default uses
ALLURE_HOME directory.
--profile
Allure commandline configuration profile.
以上就是allure显示的命令行参数 ，你可以先看它的格式 ，具体如下：
allure格式: allure [options] [command] [command options]
其中除了allure是必须输入的，剩下括号内的都是可选项，可输可不输人
第一部分就是options，具体包括如下参数 ：
Options:
--help
Print commandline help.
-q, --quiet
Switch on the quiet mode.
Default: false
-v, --verbose
Switch on the verbose mode.
Default: false
--version
Print commandline version.
Default: false
这个里面都是一些基本信息，相对来说用的少，这里我们不做介绍
第二部分是command，具体包括：
generate ：Generate the report
serve ： Serve the report
open ：Open generated report
plugin：Generate the report
以上的命令虽然只有四个，但是每个命令下又都有若干个参数 ，一般加上那个命令，就的加上对应的一些参数 ，这里面我们主要介绍常用的generate命令 。
第三部分是command options，这里主要介绍generate选项 ：
Usage: generate [options] The directories with allure results
Options:
-c, --clean
Clean Allure report directory before generating a new one.
Default: false
--config
Allure commandline config path. If specified overrides values from
--profile and --configDirectory.
--configDirectory
Allure commandline configurations directory. By default uses
ALLURE_HOME directory.
--profile
Allure commandline configuration profile.
-o, --report-dir, --output
The directory to generate Allure report into.
Default: allure-report
这里主要使用的两个选项就是 ：
-c : 每次生成报告前清除之前生成的报告文件 ，不加此选项则默认为不清除 。
-o : 生成报告的路径 ，也就是你要将测试报告输出到哪里 。
所以 ，我们该如何使用此命令行参数呢 ？可以在cmd窗口运行如下命令：
allure generate JSON路径 -o 生成测试报告路径 -c
这里有一个JSON路径，这个需要通过pytest生成一堆json文件，存放这堆JSON文件的这个路径就是JSON路径。
不过这个命令一般集成在python中去使用的，具体写法参考项目文件。
5.4 生成测试报告
（1）整体说明
每个tab页都是啥意思呢 ？接下来我们来看下面的说明 ：
所以，此页面主要是展示和链接其它页面功能 ，相当与其它页面的汇总 。
（2）类别
所谓类别，就是按照不同用例的运行结果划分的一个分类 ，具体包括 ：
报错的用例
运行失败的用例
运行成功的用例
跳过的用例
未知的用例
（4）测试套
这里的测试套，并不是测试套件 ，它只是按照你项目测试用例的层级一层一层的组织展示的。比如我的代码层级为：
cases:
test_login.py
test_buy_flow.py
test_reg.py
# test_login.py中的代码为:
class TestLogin():
pass
# test_buy_flow.py中的代码为：
class TestBuyFlow():
pass
# test_reg.py中的代码为
class TestReg():
pass
以上的用例组织结构就变为下图的展示方式了
（5）时间刻度
主要统计各个用例的运行时间 ，比如想知道那些用例运行花费的时间长，看这个数据就可以知道 。
（6）图表
这个就是按照不同的维度进行了数据统计，包括：用例状态、优先级、耗时等。
（7）功能
在最开始我们介绍到了allure的装饰器函数 ，分别给每个用例都做了标记 ，那么所标记的结果就是从功能里查看 ，具体如下：
（8）包
此功能忽略中间层级 ，只展示测试方法，即测试用例 ，对于看测试具体结果来说更加直观。
总结
通过上我们可以看到 ，整体来说还是以测试报告的展示为主 ，只不过他的展示维度不同。既然展示维度不同 ，那么查看时更多的结合实际场景来查看，具体可参考如下方式 ：
（1）要看总体情况 ，先看总览，可以了解到编写了多少测试用例 ，有多少成功的、多少失败的。
（2）运行结果若出现用例运行失败的，报错的，可以查看类别 ，这里按照类别分类 ，查看时更加直观 ，帮助你更快的分析和定位问题。
（3）想查看哪些用例运行速度慢 ，可以看时间刻度，它可以帮你找出运行慢的用例 ，从而可以进行针对性的性能优化 。
（4）快速定位是那个用例运行失败的(要定位到测试方法的) ，可以查看包 ，这个能很直观的看到编写了哪些测试方法，那个成功、那个失败 ，结果一目了然 。
（5）若想核对你编写的测试用例情况(和测试用例文件核对) ，可以查看功能，因为它是按照项目层级展示，看起来更加直观 。
（6）若想从代码角度来看编写的测试用例情况，可以查看测试套 ，因为它就是按照代码层级所展示的 。
说明: @allure.severity(用例优先级)
表示测试用例的重要级别或错误的严重程度
BLOCKER：中断缺陷，如客服端程序无响应，无法执行下一步骤
CRITICAL：严重缺陷，如功能点缺失
NORMAL：普通缺陷，如数据计算错误，默认
MINOR：次要缺陷，如界面错误与ui需求不符
TRIVIAL：轻微缺陷，如必须项无提示，或者提示不规范
写法
allure.severity_level.CRITICAL
'critical'或'CRITICAL'
不能放到函数和方法中
对于一个子功能或测试需求的所有用例，共用一个severity
不能使用参数化的参数
链接
@allure.issue('缺陷链接地址', name='报告中的链接文字')
不能放入函数和方法中
对于一个子功能或测试需求的所有用例，共用一个issue
不能使用参数化的参数
@allure.testcase('用例链接地址', name='报告中的链接文字')
不能放入函数和方法中
对于一个子功能或测试需求的所有用例，共用一个testcase
链接地址可以与issue链接地址相同
issue和testcase链接，在函数外边先写的链接后显示
不能使用参数化的参数
@allure.link('缺陷或用例链接地址', link_type, name='报告中的链接文字')
不能放入函数和方法中
对于一个子功能或测试需求的所有用例，共用一个testcase
issue和testcase链接，本质是使用link
可以指定链接类型
types.LinkType.ISSUE、 types.LinkType.TEST_CASE
from allure_commons import types
不能使用参数化的参数
总结
@allure.severity
指定用例优先级或缺陷严重程度
@allure.issue
指定所有缺陷链接地址
@allure.testcase
指定所有用例链接地址
根据实际情况来定义测试用例的实际情况来定义
5.5 选择运行你要执行的用例
pytest执行用例时可以加上allure的标记参数，可以控制执行哪些用例。
--allure-severities=SEVERITIES_SET
Comma-separated list of severity names. Tests only
with these severities will be run. Possible values
are: blocker, critical, normal, minor, trivial.
--allure-epics=EPICS_SET
Comma-separated list of epic names. Run tests that
have at least one of the specified feature labels.
--allure-features=FEATURES_SET
Comma-separated list of feature names. Run tests that
have at least one of the specified feature labels.
--allure-stories=STORIES_SET
Comma-separated list of story names. Run tests that
have at least one of the specified story labels.
--allure-link-pattern=LINK_TYPE:LINK_PATTERN
Url pattern for link type. Allows short links in test,
like 'issue-1'. Text will be formatted to full url
with python str.format().
# 选择运行你要执行epic的用例
pytest --alluredir ./report/allure --allure-epics=epic对大Story的一个描述性标签
# 选择运行你要执行features的用例
pytest --alluredir ./report/allure --allure-features=模块2
# 选择运行你要执行features的用例
pytest --alluredir ./report/allure --allure-stories="用户故事：1"
执行脚本输入报告
运行方式一:
命令行模式下运行pytest，生产测试结果文件
pytest demo.py --alluredir ./report/allure
allure程序启动已经生产的文件
allure serve ./report/allure
运行方式二：
1 编写启动方法，运行pytest
pytest.main([allure_demo.py, "--alluredir", "report/result"])
2 使用进程，开启allure服务
import subprocess
# allure生成报表，并启动程序
subprocess.call('allure generate report/result/ -o report/html --clean', shell=True)
subprocess.call('allure open -h 127.0.0.1 -p 9999 ./report/html', shell=True)
(两种方法都需要安装allure工具)
6 allure介绍
Allure Framework 是一个开源的，灵活的，轻量级，多语言的测试报告框架（工具）。
allure支持多种测试框架，如Pytest、TestNG等。
allure支持的框架按语言分组：Java、Python、 JavaScript、Ruby、Groovy、PHP、.Net和Scala。
allure可以和Pytest测试框架集成，在 Pytest 执行完生成的测试数据的基础上，进行处理，生成格式统一、美观的测试报告。
它是一个生成HTML测试报告的工具包，使用java开发，所以需要java环境
功能强大 , 生成的报告美观、直观需要用pytest去搜集测试用例,使用浏览器打开，更易进行持续集成
官网文档教程：https://allurereport.org/docs/
、
五 自动化测试的评估优化
优化点：
1 对接口自动化进行Jenkins持续集成，每次发布时自动执行脚本
2 针对移动端/业主app / 服务版app / 小程序的接口 模拟登陆
目前只做了pc 端接口的优化
3 测试数据的批量处理
可优化点:将测试数据导入到数据库中，从数据表中读写测试数据；支持数据的批量导入和更新，减少维护成本。或者AI来辅助编写
6 可以将各用户的登陆获取的token 进行缓存，避免每次登陆都去调用接口
7 编写python 脚本+ ai 辅助生成python 的自动化测试
六 问题记录
1 自己新增的测试case 无法在根目录下运行
2 场景多条数据源进行场景测试
3 项目工程化改造 （完成 以bop_core 为实例模版）
工程化问题 所有的配置/case 都在一个工程包 通用基础工程单独处理 把顶级的项目和一级模块建好 再建一个模版工程
4 脚本处理报告生产
5 开发人员建api 测试，测试人员建场景测试 所有的测试尽量被重用
6 工程部署：allure_result 测试数据不用上传 生成项目测试报告
7 测试case 考虑不同环境的通用性
运行入口脚本：runner.py
import pytest
import os
if __name__ == '__main__':
# 1. 使用pytest生成测试报告时需要传递一个列表
json_dir_path = 'result'
args_list = ['-s', '-v', 'cases', '--alluredir', json_dir_path]
pytest.main(args_list)
# 2. 使用allure命令生成测试报告 ：allure generate 数据路径文件 -o html路径文件 -c
html_dir_path = 'report'
cmd = 'allure generate {} -o {} -c'.format(json_dir_path, html_dir_path)
os.system(cmd)
注意问题：
1 生产上的不允许执行sql 只做查询操作
2 生产环境测试|非生产环境的测试 要区分对待
3 开发人员建api 测试，测试人员建场景测试 所有的测试尽量被重用
4 版本管理 按照开发管理办法管理