update
This commit is contained in:
limeng
parent
602bc5af32
commit
5d7689c63b
|
|
@ -64,9 +64,13 @@ module.exports = {
|
|||
{text:'接口测试', link: '/auto/api'},
|
||||
{text:'App测试', link: '/auto/app'},
|
||||
{text:'Web测试', link: '/auto/web'},
|
||||
{text:'测试开发', link: '/testdev'}
|
||||
// {text:'测试开发', link: '/testdev'}
|
||||
]},
|
||||
{text: '测试开发', link: '/testdev', icon: 'reco-three',
|
||||
items:[
|
||||
{text:'Woody效能平台', link: '/woody/base'},
|
||||
{text:'精准测试', link: '/accurate/base'},
|
||||
]},
|
||||
// {text: '测试开发', link: '/testdev', icon: 'reco-three'},
|
||||
{text: '质量相关', icon: 'reco-blog',
|
||||
items:[
|
||||
{text:'研发流程与规范', link: '/quality/dev-flow'},
|
||||
|
|
@ -115,6 +119,33 @@ module.exports = {
|
|||
searchMaxSuggestions: 10,
|
||||
subSidebar: 'auto',
|
||||
sidebar: {
|
||||
'/accurate': [
|
||||
{
|
||||
title: '精准测试', // 必要的
|
||||
collapsable: false, // 可选的, 默认值是 true,
|
||||
sidebarDepth: 2, // 可选的, 默认值是 1
|
||||
children: [
|
||||
'/accurate/base',
|
||||
'/accurate/coverage',
|
||||
]
|
||||
},
|
||||
],
|
||||
'/woody': [
|
||||
{
|
||||
title: 'Woody效能平台', // 必要的
|
||||
collapsable: false, // 可选的, 默认值是 true,
|
||||
sidebarDepth: 2, // 可选的, 默认值是 1
|
||||
children: [
|
||||
'/woody/base',
|
||||
'/woody/framework',
|
||||
'/woody/product',
|
||||
'/woody/flow',
|
||||
'/woody/code',
|
||||
'/woody/api',
|
||||
'/woody/agree',
|
||||
]
|
||||
},
|
||||
],
|
||||
'/auto/api': [
|
||||
{
|
||||
title: '接口测试', // 必要的
|
||||
|
|
@ -152,7 +183,7 @@ module.exports = {
|
|||
],
|
||||
'/auto/web': [
|
||||
{
|
||||
title: '功能测试', // 必要的
|
||||
title: 'Web测试', // 必要的
|
||||
collapsable: false, // 可选的, 默认值是 true,
|
||||
sidebarDepth: 2, // 可选的, 默认值是 1
|
||||
children: [
|
||||
|
|
@ -272,6 +303,7 @@ module.exports = {
|
|||
sidebarDepth: 2, // 可选的, 默认值是 1
|
||||
children: [
|
||||
'/code/fastapi/begin',
|
||||
'/code/fastapi/app',
|
||||
]
|
||||
},
|
||||
],
|
||||
|
|
|
|||
|
|
@ -0,0 +1,159 @@
|
|||
---
|
||||
title: 精准测试相关概念
|
||||
date: 2022-01-28 15:48:48:53
|
||||
categories: [精准测试]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- 精准测试
|
||||
- 覆盖率
|
||||
---
|
||||
## 背景
|
||||
|
||||
### 范围评估
|
||||
|
||||
对于分布式系统中的绝大部分应用，随着业务发展，自身应用的代码复杂度会不断增加。
|
||||
|
||||
一些业务架构设计不太合理的系统，当任何一个接口产生变动，则会使多个其他应用也受到影响。在测试过程中会发现只是自身应用代码的修改，会导致对外暴露的接口逻辑发生很大变动，此时开发人员和测试人员需要判定出这个对外暴露的接口对哪些上层应用有影响。
|
||||
|
||||
随着软件的频繁更迭，需要大量的时间和人力去测试， 而业务快速迭代交付导致测试时间不断压缩，全回归是一件很困难的事情。加上回归测试完全依赖于测试人员的能力、经验和业务熟悉度，受主观因素影响太大，并且测试对代码覆盖程度，质量高低，没有客观数据可衡量，完全靠人为主观介定，不确定性太多，这是产生漏测的根本原因。
|
||||
|
||||
> 显然，如何基于代码变更准确、全面地判定影响范围会越来越重要！
|
||||
|
||||
当前测试行业的范围评估情况，如下图：
|
||||
|
||||
|
||||
|
||||
往往上图中的这些内容是没有数据支撑的。当应用的代码有变更，无法获知变更影响了哪些功能，也无法精准地选取测试用例，因此不得不进行全量回归。
|
||||
|
||||
### 代码质量分析
|
||||
|
||||
在软件团队不断发展的今天，团队内各个人员的代码水平就显得尤为重要。
|
||||
在编写代码时，研发人员也会编写代码进行测试，但这样一来，导致代码质量下降的因素除了一些代码写法上不规范的代码、出漏洞的代码，同时还会有一些冗余的代码。由此引发出的代码质量问题，也需要可度量。
|
||||
|
||||
### 传统软件测试的主要短板
|
||||
|
||||
现如今，软件产品的规模以及复杂度的扩展速度，可谓超乎想象，而传统的软件测试方法，在面临这些挑战时已经表现出了些许力不从心。这些力不从心，也就是传统软件测试的短板，简单可以分为下面这五大类:
|
||||
|
||||
**第一大短板：测试的维护成本日益升高。**
|
||||
|
||||
传统测试用例数量的增长会导致测试用例的代码覆盖率增长，但当覆盖率到达一定的数值时（75%左右），则出现了增长瓶颈，这时为了维护一个庞大的测试用例集，以保证产品新特性和老功能的正确性与稳定性，使覆盖率继续增长，需要花费越来越多的时间和人力成本，如下图：
|
||||
|
||||
|
||||
|
||||
而在这成千上万的测试用例中，有很多陈旧的用例已经失效了(不再能满足现有产品的测试需求了)，但是整个团队还是要花费很多精力去维护这个庞大的测试用例集。
|
||||
|
||||
**第二大短板：测试过程的低效。**
|
||||
|
||||
随着软件功能的不断丰富，相应测试用例集也愈加庞大，这时难免会出现“杀虫剂”效应，即：测试用例越来越多，而产品的“免疫力”也越来越强，测试效果却不明显。
|
||||
造成这种问题的原因是，我们在测试早期已经发现了80%的软件缺陷，除非再花费巨大的人力和时间成本分析并增加大批量的测试用例，否则后期新增的测试用例已经很难再发现新的缺陷。
|
||||
|
||||
|
||||
**第三大短板：缺乏有效的回归用例选取机制。**
|
||||
|
||||
在传统测试理念中，每次添加新功能或者修复缺陷，一般都需要在产品上线前进行一轮全回归测试，哪怕这次的改动只有一行代码。但是，全回归测试的测试用例数量以及执行代价一般都比较大。
|
||||
这里，我们之所以要采用全回归测试，是因为我们无法准确地知道这次更新到底会影响哪些功能，也无法知道应该从测试用例集中选取哪些必要的测试用例，无奈之下只能两眼一抹黑地执行全部用例。
|
||||
|
||||
**第四大短板：测试结果的可信度不高。**
|
||||
|
||||
在传统软件测试中，人工因素占据了测试数据的统计分析的绝大部分比重，由此导致测试数据本身的技术公信力不够高，进而需要依靠管理手段来保证真实的测试数据被准确地记录。这种做法不仅可靠性差，而且执行成本高。
|
||||
|
||||
**第五大短板：无论是白盒测试技术还是黑盒测试技术都有其局限性。**
|
||||
|
||||
如果完全基于黑盒测试，那么注定无法深入代码实现的细节，也就无法做到有的放矢地设计测试用例；而如果基于白盒测试技术，为了保证代码质量，往往会采用代码级测试和代码覆盖率技术。
|
||||
但是，这些测试方法都强依赖于产品代码，一旦代码发生改变，很多测试都会因此失效，因此很难适应快速迭代的开发流程。
|
||||
另外，由于目前的代码级测试和代码覆盖率技术还不支持测试用例级别的覆盖率分析，而是要将所有测试结果混在一起，导致白盒测试时无法区分代码覆盖率的贡献到底来自于哪个测试用例，这将极大地限制白盒测试工具在测试结果分析上的作用。
|
||||
|
||||
## 精准测试简介
|
||||
|
||||
> 精准测试，就是借助一定的技术手段、通过算法的辅助对传统软件测试过程进行可视化、分析以及优化的过程。
|
||||
>
|
||||
> 它是一种代码和测试用例双向可追溯的软件测试技术。精准测试可以使得测试过程变得：可视、智能、可信和精准。
|
||||
|
||||
### 精准测试的核心思想
|
||||
|
||||
**精准测试是对传统测试的补充**
|
||||
|
||||
精准测试是基于传统测试数据的，并不会改变传统的软件测试方法，更不会取代传统测试。也就是说，精准测试在不改变原有测试集的基础下，能够优化测试过程和数据，提高测试效率。
|
||||
|
||||
**精准测试采用的是黑盒测试与白盒测试相结合的模式**
|
||||
|
||||
在执行黑盒测试时，收集程序会自动产生白盒级别的运行数据，然后通过可视化或者智能算法识别出测试未覆盖的变更代码，继而引导开发人员和测试人员有的放矢地补充测试用例。
|
||||
同时，在黑盒测试的执行过程中，可以实现测试用例和产品代码的自动关联，将基于黑盒的功能测试直接映射到基于白盒的代码层测试，这将使智能回归测试用例选取的想法成为可能。
|
||||
|
||||
**精准测试的数据可信度高**
|
||||
|
||||
精准测试的数据都是由系统自动录入和管理的，人工无法直接修改数据，因此我们可以直接将传统测试产生的数据导入精准测试系统，用于测试结果的分析，从而使测试结果具有更高的可信度。
|
||||
|
||||
**精准测试过程中，不直接面对产品代码**
|
||||
|
||||
精准测试通过算法和软件实现对测试数据和测试过程的采集，因此并不会直接面向代码，也就不会强依赖于产品代码。
|
||||
但是，精准测试能够实现测试用例和产品代码的自动关联，也就是说代码覆盖率的统计能够以测试用例为单位来进行，具体实现的核心思想还是基于代码覆盖率的统计，只是在代码覆盖率的元数据上增加了测试用例的信息。
|
||||
因此，代码的改变并不会影响测试过程，但却能够将功能测试间接映射到代码级别。这样，精准测试就实现了测试用例和被测产品代码的双向追溯。
|
||||
|
||||
**精准测试是与平台无关的、多维度的测试分析算法系统**
|
||||
|
||||
精准测试系统是一种通用的测试分析系统，独立于任何测试平台，其内部算法和业务无关，因此适用于各种不同类型的产品。
|
||||
同时，精准测试为我们提供了多维度的测试分析算法，拓展了白盒测试的范畴。而，精准测试对测试用例和产品代码的自动关联，使得它可以为测试过程提供大量的智能分析结果。
|
||||
|
||||
### 支撑技术
|
||||
|
||||
在现代测试环节中，我们往往会考虑如何避免多测，漏测，如何提高测试的效率和准确率。
|
||||
|
||||
由于系统之间的种种依赖以及测试人员对系统架构的理解并没有研发人员熟悉等因素，导致测试的数据可追溯性差，对结果的判断偏主观性，强依赖个人经验等种种痛点。
|
||||
|
||||
我们考虑到测试人员对这些问题的困扰，特别是跨系统，跨业务的测试复杂性，数据追溯等问题。
|
||||
|
||||
一套精准回归测试解决方案——跨应用精准回归、用例代码覆盖率技术、用例代码染色技术、用例代码双向追溯技术。
|
||||
|
||||
|
||||
|
||||
#### 跨应用精准回归
|
||||
|
||||
跨应用精准回归能力智能动态链路追踪技术，规避了传统静态代码扫描技术只能在单系统、单应用下做到代码质量静态分析的窘境，它能分析多个应用在多个集群之间的链路关系，
|
||||
无论应用之间通过何种RPC或HTTP等协议互相调用，都能动态绘制调用链路图，跨应用、跨系统追溯代码变更，深度分析变更对测试用例的影响，针对影响发现需要回归的测试用例，
|
||||
解决测试人员对应用架构理解不足的痛点，同时也解决系统之间的依赖变更所造成的漏测，未测等不确定因素。使精准回归做到跨系统、跨应用的能力。
|
||||
|
||||
主要作用：
|
||||
|
||||
● 评估影响范围 ：明确修改内容以及影响功能
|
||||
|
||||
● 根据变更圈定执行用例 ：解决测试冗余，漏测的问题
|
||||
|
||||
● 程序执行透明化 ：提供用例执行路径，帮助熟悉代码
|
||||
|
||||
● 评估精准测试结果 ：精准分析评估反馈，建立闭环
|
||||
|
||||
● 发现测试死角 ： 找到应该覆盖，但未覆盖的代码
|
||||
|
||||
● 标记冗余代码 ：为RD删代码提供数据参考
|
||||
|
||||
● 代码准入门槛 ： 增量覆盖率指标衡量RD自测程度
|
||||
|
||||
● 问题自动排查 ： 提供用例执行轨迹跟踪
|
||||
|
||||
● 建立更可信的自动化测试
|
||||
|
||||
#### 用例代码双向追溯技术
|
||||
|
||||
每一个测试用例与代码之间都拥有双向追溯能力，量化测试数据，不再依靠个人的主观判断。
|
||||
|
||||
#### 用例代码染色技术
|
||||
|
||||
用例代码染色技术智能分辨用例与代码之间的关联关系，细到每一个分支，每一个节点，让测试结果精准可信赖。
|
||||
|
||||
|
||||
|
||||
#### 用例代码覆盖率技术
|
||||
|
||||
采用白盒级的代码覆盖率来衡量测试的充分性和完整性。通过统计代码覆盖率找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些不可达的废弃代码。
|
||||
|
||||
覆盖率度量有不同的类型，但是大多数工具都关注行覆盖率，除了提供行覆盖率，仍然提供分支覆盖率、方法覆盖率，测试人员可以使用覆盖率数据来评估与功能测试有关的领域，
|
||||
促进质量风险缓解。覆盖率测量为有效的测试过程提供了深度和精确度。
|
||||
|
||||
### 精准测试在测试流程中的体现
|
||||
|
||||
精准测试在整个迭代版本的测试生命周期中不同阶段的均有不同的价值输出。
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,102 @@
|
|||
---
|
||||
title: 覆盖率相关概念
|
||||
date: 2022-01-28 16:07:07:31
|
||||
categories: [精准测试]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- 代码覆盖率
|
||||
- 精准测试
|
||||
---
|
||||
## 覆盖率计数器
|
||||
|
||||
Jacoco使用一系列的不同的计数器来做覆盖率的度量计算。所有这些计数器都是从java的class文件中获取信息，这些class文件可以（可选）包含调试的信息在里面。即使在没有源码的情况下，这种方法也可以实时有效地对应用程序进行度量和分析。在大部分情况下，收集到的信息可以映射到源码，可视化到每一行代码的粒度。但这种方法还是有一些限制。这些class文件必须使用调试信息来编译，这样才可以计算行的覆盖率和提供出源码的高亮。但不是所有的JAVA语言的结构都可以直接编译成一致的二进制代码。在这种情况下，java 编译器会创建所谓的“合成”代码，会导致产生一些不期望得到的覆盖率结果。
|
||||
|
||||
### 指令（C0 Coverage）
|
||||
|
||||
Jacoco最小的计数单元是单个java二进制代码指令。指令覆盖率提供了代码是否被执行的信息。这个度量完全独立源码格式，并且总是可用，即使class文件里面没有调试信息。
|
||||
|
||||
### 分支（C1 Coverage）
|
||||
|
||||
Jacoco也计算分支的覆盖率，包括所有的if和switch语句。这个度量计算一个方法里面的总分支数，确定执行和不执行的分支数量。分支覆盖率总是可用的，即使class文件里面没有调试信息。注意异常处理是不在分支度量里面统计的。
|
||||
|
||||
如果class文件使用调试信息编译的话，产生的覆盖率可以映射到源码行并且高亮提示：
|
||||
|
||||
● 没有覆盖：在这一行中没有分支被执行（红色方块）
|
||||
|
||||
● 部分覆盖：这一行的分支中只有一部分被执行（黄色方块）
|
||||
|
||||
● 完全覆盖：这一行的所有分支都被执行（绿色方块）
|
||||
|
||||
### 圈复杂度
|
||||
|
||||
Jacoco同样可以为每一个非抽象方法计算复杂度，最终计算出类、包和组的复杂度。根据由McCabe1996圈复杂度的定义是，在（线性）组合中，计算在一个方法里面所有可能路径的最小数目。所以复杂度可以作为度量单元测试是否有完全覆盖所有场景的一个依据。复杂度即使是在没有调试信息的情况下也可以计算。
|
||||
|
||||
圈复杂度V（G）的正式定义是基于方法的控制流图的有向图表示：
|
||||
|
||||
v(G) = E – N + 2
|
||||
|
||||
E是边界的数量，N是节点的数量。Jacoco 基于下面的方程来计算复杂度，B是分支的数量，D是决策点的数量：
|
||||
|
||||
v(G) = B – D + 1
|
||||
|
||||
基于每个分支的被覆盖情况，Jacoco也为每个方法计算覆盖和缺失的复杂度。缺失的复杂度同样表示测试案例没有完全覆盖到这个模块。注意Jacoco不将异常处理作为分支，try/catch块也同样不增加复杂度。
|
||||
|
||||
### 行
|
||||
|
||||
所有的class文件使用debug信息编译之后，就可以计算行的覆盖率信息。一行源代码是否被执行，要看这一行中是否至少有一个指令被执行。
|
||||
|
||||
由于实际上一行代码一般被编译成多个二进制代码指令，这样源码在高亮显示时，会显示成3种不同的状态：
|
||||
|
||||
● 没有覆盖：这一行中没有指令被执行（红色背景）
|
||||
|
||||
● 部分覆盖：这一行中只有一部分指令被执行（黄色背景）
|
||||
|
||||
● 完全覆盖：这一行中所有指令都被覆盖（绿色背景
|
||||
|
||||
### 方法
|
||||
|
||||
每一个非抽象方法至少包含一个指令。一个方法是否执行取决于方法中是否有至少一个指令被执行。在Jacoco中，构造器和静态初始化同样会像方法一样统计。其中一些方法可能没有可以直接对应的源码，比如默认构造器或常量的初始化命令。
|
||||
|
||||
### 类
|
||||
|
||||
一个方法是否执行取决于类中是否有至少一个方法被执行。注意Jacoco认为构造器和静态初始化都是方法。Java的接口一般包含静态初始化，所以接口也同样被认为是可执行的类。
|
||||
|
||||
## 覆盖率
|
||||
|
||||
覆盖率统计类型：全量代码覆盖率、差异代码覆盖率、增量代码覆盖率
|
||||
|
||||
**有效代码行数：**
|
||||
|
||||
字节码解析后，能被执行的代码行。
|
||||
|
||||
**全量代码覆盖率：**
|
||||
|
||||
根据版本查看，此版本内所有有效代码行的执行覆盖率。
|
||||
|
||||
**差异代码覆盖率：**
|
||||
|
||||
对比两个版本，有效代码行数中差异代码的执行覆盖率。
|
||||
|
||||
**增量代码覆盖率：**
|
||||
|
||||
对比两次收集，覆盖率增加的数值。
|
||||
|
||||
**行覆盖率计算方式：**
|
||||
|
||||
覆盖率总计：已覆盖行数/过滤后服务中的代码的行数
|
||||
|
||||
类级别：已覆盖行数/类中行数
|
||||
|
||||
**分支覆盖率计算方式：**
|
||||
|
||||
覆盖率总计：已覆盖分支数/过滤后服务中的代码涉及的分支数量
|
||||
|
||||
类级别：已覆盖分支数/类中总分支数
|
||||
|
||||
**方法覆盖率计算方式：**
|
||||
|
||||
覆盖率总计：已覆盖方法数/过滤后服务中的代码涉及的方法数量
|
||||
|
||||
类级别：已覆盖方法数/类中总方法数
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
---
|
||||
title: App应用对象
|
||||
date: 2022-01-28 16:15:15:06
|
||||
categories: [FastApi]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- Python
|
||||
- FastApi
|
||||
---
|
||||
# 认识App应用对象FastAPI
|
||||
|
||||
**实例化应用对象**
|
||||
|
||||
```Python
|
||||
app = FastAPI()
|
||||
```
|
||||
|
||||
**查看源码**
|
||||
|
||||
```Python
|
||||
class FastAPI(Starlette):
|
||||
def __init__(
|
||||
self,
|
||||
*,
|
||||
debug: bool = False,
|
||||
routes: Optional[List[BaseRoute]] = None,
|
||||
title: str = "FastAPI",
|
||||
description: str = "",
|
||||
version: str = "0.1.0",
|
||||
openapi_url: Optional[str] = "/openapi.json",
|
||||
openapi_tags: Optional[List[Dict[str, Any]]] = None,
|
||||
servers: Optional[List[Dict[str, Union[str, Any]]]] = None,
|
||||
dependencies: Optional[Sequence[Depends]] = None,
|
||||
default_response_class: Type[Response] = Default(JSONResponse),
|
||||
docs_url: Optional[str] = "/docs",
|
||||
redoc_url: Optional[str] = "/redoc",
|
||||
swagger_ui_oauth2_redirect_url: Optional[str] = "/docs/oauth2-redirect",
|
||||
swagger_ui_init_oauth: Optional[Dict[str, Any]] = None,
|
||||
middleware: Optional[Sequence[Middleware]] = None,
|
||||
exception_handlers: Optional[
|
||||
Dict[
|
||||
Union[int, Type[Exception]],
|
||||
Callable[[Request, Any], Coroutine[Any, Any, Response]],
|
||||
]
|
||||
] = None,
|
||||
on_startup: Optional[Sequence[Callable[[], Any]]] = None,
|
||||
on_shutdown: Optional[Sequence[Callable[[], Any]]] = None,
|
||||
terms_of_service: Optional[str] = None,
|
||||
contact: Optional[Dict[str, Union[str, Any]]] = None,
|
||||
license_info: Optional[Dict[str, Union[str, Any]]] = None,
|
||||
openapi_prefix: str = "",
|
||||
root_path: str = "",
|
||||
root_path_in_servers: bool = True,
|
||||
responses: Optional[Dict[Union[int, str], Dict[str, Any]]] = None,
|
||||
callbacks: Optional[List[BaseRoute]] = None,
|
||||
deprecated: Optional[bool] = None,
|
||||
include_in_schema: bool = True,
|
||||
**extra: Any,
|
||||
) -> None:
|
||||
```
|
||||
|
||||
在源码中我们可以看到FastApi应用的配置项、以及它集成的接口文档
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
---
|
||||
title: 协议仿真
|
||||
date: 2022-01-28 15:37:37:34
|
||||
categories: [测试开发, Woody]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- 测试开发
|
||||
- 测试平台
|
||||
- Woody
|
||||
- 协议仿真
|
||||
---
|
||||
# 介绍
|
||||
|
||||
:::tip
|
||||
协议方针平台主要是为测试提供测试或开发人员，对app 网关 tsp对车辆各种操作的测试,常见的有 开车门，故障主动上报，车辆登录，错误数据的发送，底层ecu信号模拟，等功能。
|
||||
:::
|
||||
|
||||
# 主要功能
|
||||
|
||||
- 车况模拟
|
||||
根据协议信息指定信号模拟车况
|
||||
- 报文定义
|
||||
平台本身维护了多种上下行报文信息，并且会持续更新
|
||||
- 车辆在线
|
||||
可以根据时间完成模拟车况，车辆可以一直模拟在在线状态
|
||||
- Chat对话
|
||||
可根据指定信息，平台后默认与对应网关链接，建立仿真平台与tbox 上游持续对话能力，提高测试效率
|
||||
|
||||
# 技术框架
|
||||
|
||||
通讯协议：TCP、Websocket
|
||||
|
||||
中间件：Mysql、Es、Redis、Mogodb、Nginx
|
||||
|
||||
框架/语言：Spring Boot、Spring Cloud、Spring Cloud Alibaba、Netty、Shiro、Vue+Axios
|
||||
|
||||
# 流程图
|
||||
|
||||
|
||||
|
||||
# 架构图
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
title: 自动化测试
|
||||
date: 2022-01-28 15:19:19:55
|
||||
categories: [测试开发, Woody]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- 测试开发
|
||||
- 测试平台
|
||||
- Woody
|
||||
- 接口自动化
|
||||
- 执行引擎
|
||||
---
|
||||
|
||||
# 思考
|
||||
|
||||
此执行引擎服务，为自主研发，并未使用任何单元测试框架。
|
||||
|
||||
在实际使用中，会发现接口测试中会穿插很多其他的类型，例如数据、中间件，而在UI测试中，也会涉及到一些这部分的内容，为避免重复造轮子，以综合方式实现的用例结构。
|
||||
|
||||
推广下来成果喜人。
|
||||
|
||||
引擎服务支持多节点分布式部署，实现了多执行任务之间的高可用。
|
||||
|
||||
# 架构图
|
||||
|
||||
|
||||
|
||||
# 分层
|
||||
|
||||
|
||||
|
||||
# 执行流程
|
||||
|
||||
**流程图**
|
||||
|
||||
|
||||
|
||||
**UML图**
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
---
|
||||
title: 什么是Woody
|
||||
date: 2022-01-28 10:51:51:36
|
||||
categories: [测试开发, Woody]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- 测试开发
|
||||
- 测试平台
|
||||
- Woody
|
||||
sticky: -1
|
||||
---
|
||||
|
||||
:::danger
|
||||
系统为本人设计内部实现的内部系统，仅此说明，不予公开系统内部细节，仅为设计相关
|
||||
:::
|
||||
|
||||
# Woody效能平台
|
||||
|
||||
:::tip
|
||||
Woody工程效能平台 是集成接口自动化、UI自动化、性能测试、工单系统、报告系统（安全、性能）、数据平台（覆盖率、千行代码Bug率等）、
|
||||
代码扫描分析、功能用例管理、事故、发布统计、精准测试、常用工具、管理后台等的综合管理平台
|
||||
:::
|
||||
|
||||
## Woody的由来
|
||||
|
||||
**Woody** 取义啄木鸟。
|
||||
|
||||
啄木鸟是著名的森林鸟，除消灭树皮下的害虫，其凿木的痕迹可作为森林卫生采伐的指示剂。它们觅食天牛、吉丁虫、透翅蛾、蝽虫等有害虫，每天能吃掉1500条左右。
|
||||
|
||||
啄木鸟于测试、质量上有异曲同工之处，即得名称 **Woody**。
|
||||
|
||||
## 平台发展
|
||||
|
||||
近几年，不仅互联网行业发展飞速，也引领着其他相关岗位飞速发展。
|
||||
|
||||
测试岗位，也由大批量的手工功能测试，开始往**自动化测试**、**工具化**、**平台化**方向快速靠拢。
|
||||
|
||||
在做整个效能平台之前，也曾为公司实现过自动化测试相关的平台，但是在嵌入整体流程中时，总会有很多不方便之处。
|
||||
|
||||
Woody效能平台，**旨在**从测试角度出发，向左连通需求、研发，向右连接运维，嵌入公司整体流程。
|
||||
|
||||
其实也是在流程中打入测试相关内容的一种探索。
|
||||
|
||||
## 首页预览
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: 千行代码Bug率
|
||||
date: 2022-01-28 15:18:18:23
|
||||
categories: [测试开发, Woody]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- 测试开发
|
||||
- 测试平台
|
||||
- Woody
|
||||
- 千行代码Bug率
|
||||
---
|
||||
|
||||
# 千行代码Bug率
|
||||
|
||||
每千行代码，产生的Bug数据。这个数据可以作为参考，但是不能作为主要指标。
|
||||
|
||||
根据开发习惯，还有一些高阶用法，这个数据就很扯淡了。
|
||||
|
||||
# 流程图
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
---
|
||||
title: 任务管理（工单）
|
||||
date: 2022-01-28 15:08:08:31
|
||||
categories: [测试开发, Woody]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- 测试开发
|
||||
- 测试平台
|
||||
- Woody
|
||||
- 工单
|
||||
---
|
||||
|
||||
## 从需求开始的大体流程
|
||||
|
||||
|
||||
|
||||
## 任务管理流程
|
||||
|
||||
|
||||
|
||||
## 测试计划执行流程图
|
||||
> 此图过大，想看详细可[下载](https://limeng-blog.oss-cn-hangzhou.aliyuncs.com/woody/%E6%B5%8B%E8%AF%95%E8%AE%A1%E5%88%92%E6%89%A7%E8%A1%8C%E6%B5%81%E7%A8%8B%E5%9B%BE.png?x-oss-process=style/_blog)后查看
|
||||
|
||||
|
||||
|
||||
## 提测单流程图
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
title: 系统架构
|
||||
date: 2022-01-28 14:46:46:23
|
||||
categories: [测试开发, Woody]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- 测试开发
|
||||
- 测试平台
|
||||
- Woody
|
||||
- 架构
|
||||
---
|
||||
|
||||
## 引言
|
||||
|
||||
做之前也经过很多推敲和思考，整体系统架构偏向分布式微服务架构。
|
||||
|
||||
后来选定后，以Naoos为注册中心，整合Java以及Python语言多服务，搭建Python+Java的微服务体系。
|
||||
|
||||
## 微服务体系简单方案
|
||||
|
||||
|
||||
|
||||
## 系统架构
|
||||
|
||||
|
||||
|
||||
## 简单平台架构
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
title: 平台产品
|
||||
date: 2022-01-28 14:50:50:22
|
||||
categories: [测试开发, Woody]
|
||||
author: Anges黎梦
|
||||
tags:
|
||||
- 测试开发
|
||||
- 测试平台
|
||||
- Woody
|
||||
- 架构
|
||||
---
|
||||
|
||||
# 权限说明
|
||||
|
||||
整个平台，采用后台动态模式，管理平台中嵌入的子产品以及菜单。
|
||||
|
||||
用户可以通过授权，授权访问某些产品、以及菜单。
|
||||
|
||||
# 产品说明
|
||||
|
||||
截止我离职，共完成子产品21个
|
||||
|
||||
其中包含：
|
||||
|
||||
- 管理后台、操作手册
|
||||
|
||||
- 接口自动化v1、接口自动化v2、UI自动化、性能测试、功能用例管理v1、功能用例管理v2、协议仿真、精准测试
|
||||
|
||||
- 造数工厂、报告管理、移动设备管理、云真机
|
||||
|
||||
- 数据产品、报表产品、代码覆盖率、项目管理、工单系统、安全应急等产品。
|
||||
Loading…
Reference in New Issue