# PowerTest

**Repository Path**: liuliniyi/test

## Basic Information

- **Project Name**: PowerTest
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2021-09-29
- **Last Updated**: 2021-09-29

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 一、前言
很多小团队由于业务发展迅速，产品开发中一直保持一个高频率的迭代开发，测试体系不规范，导致软件产品质量难以把控。
实际上，不单是小团队，大团队也有同样的烦恼，产品迭代过快，导致测试无法跟上，软件质量无法把控。希望能通过该教程让开发者快速掌握构建测试防护网的能力。

#### 现有大部分公司都有的困窘，高速运作产品研发过程：
##### 客户需求：造一条船，能过河就好
![需求](image/前言/客户需求造船.jpg)
##### 产品设计：我们可以提供这样的产品方案
![需求](image/前言/产品设计造船.jpg)
##### 架构师：按照需求规划蓝图
![需求](image/前言/首席架构师设计.jpg)
##### 研发经理：进行项目分解
![需求](image/前言/高级研发经理分解.jpg)
##### 技术评估：这个项目起码需要1.5年
![需求](image/前言/技术评估造船.jpg)
##### 老板发话：市场不等人，先上线再迭代，给技术团队1个月时间搞定！！！
![需求](image/前言/市场不等人造船.jpg)
##### 研发团队：重新更改设计，马上开始编码
![需求](image/前言/需求重新设计造船.jpg)
##### 测试团队：提前进入单元测试阶段
![需求](image/前言/测试团队-单元测试.jpg)
##### 测试团队：突击进入集成测试阶段
![需求](image/前言/集成测试造船.jpg)
##### 测试团队：项目终于正式上线了
![需求](image/前言/系统上线.jpg)
##### 苦逼的人肉运维
![需求](image/前言/人力运维.jpg)

## 1.1 软件测试不单单是测试人员的事
新兴的`DevOps`产品开发模式悄声而至，其中，`持续集成`、`持续部署`、`持续交付`需要高质量高频率地运作。软件自动化测试必须由开发者与测试人员共同完成，而`开发者测试防护网是最高效、最关键的第一道防护网`，是以开发者个人+白盒测试方法为主导的质量工程技术关键一环。

![修水管1](image/修水管1.gif)
![修水管2](image/修水管2.gif)
![修水管3](image/修水管3.gif)

### 1.1.1 开发者测试用例参与的产品研发全流程
![修水管1](image/DevOps测试介入全流程.png)

## 1.2 基础概念
### 1.2.1 回归测试
回归测试，即开发者修改完BUG，经过一系列DevOps活动发布软件版本，部署到测试环境，让测试人员对整一个软件进行的测试活动。
- 回归测试不仅仅只验证修改的接口或功能，并且需要测试其他功能接口，以避免修改过程中，改坏了其他功能接口；
- 回归测试的特点是测旧不测新；
- 回归测试必须是有验证点，版本号、部署时间、修改的问题有哪些。


### 1.2.2 测试因子
测试因子是一般进行测试时,该测试受到哪几种因素的影响,比如环境与测试难易程度等,有几种影响因素就有几个测试因子。

**例如：用户登录功能**

![登录界面](image/用户登录.png)

测试因子（即受影响因素）：
- 用户名
- 密码
- 验证码

# 二、测试阶段
![测试](image/测试阶段.png)

`L0 单元测试`: 开发同学主导 & 白盒测试
 
`L1 集成测试`：开发同学主导 + 测试同学介入 & 白盒测试为主 + 黑盒测试为辅

`L2 系统测试`：测试同学 & 黑盒测试

`L3 验收测试`：测试同学 + 用户 & 黑盒测试
## 2.1 执行顺序
`L0 单元测试` > `L1 集成测试` > `L2 系统测试` > `L3 验收测试`
>
## 2.2 覆盖情况
`L0 单元测试` > `L1 集成测试` > `L2 系统测试` > `L3 验收测试`
>一般来说，白盒测试覆盖到的功能与逻辑都是比黑盒测试多，低级别的测试覆盖要比高级别的测试要多。
## 2.3 缺陷成本
`L0 单元测试` < `L1 集成测试` < `L2 系统测试` < `L3 验收测试`
>级别越高的测试阶段，出现问题故障的成本越大，投入人力物力资源越高，排查问题越困难。

# 三、测试用例设计
测试用例设计一般是由测试人员提供。但是，种种原因导致开发人员无法获得所需的测试用例设计文档，开发人员仍然需要掌握一定的设计方法。
## 3.1 用例设计方法
用例设计以组为单位，每一组由各个测试因子取值即预期结果组成
- A组：测试因子1，测试因子2，测试因子3，预期结果
- 例如：用户登录功能

|用例组编号|用户名|密码|验证码|预期|
| :-----| ----: | :----: |:----: |:----: |
|1|合法字符|合法字符|正确|登录成功|
|1|非法字符|合法字符|正确|请输入正确的用户名|
|2|合法字符|非法字符|正确|请输入正确的用户名或密码|
|3|合法字符|合法字符|错误|请输入正确的验证码|
### 3.1.1 等价类划分法
将一个测试因子分成若干个区域，每一个区域内都是同一类型的数据，称之为等价类，等价类中可以任意取值，得到的预期都是一致的，所以一个等价类中挑选具有代表性的取值即可。
#### 3.1.1.1 有效等价类 
符合需求文档规定的数据，即为有效数据，有效数据进行等价类划分，得到的就是有效等价类。
#### 3.1.1.2 无效等价类
不符合需求文档规定的数据，即为无效数据，无效数据进行等价类划分，得到的就是无效等价类。

例如：用户登录功能，对用户名测试因子（只允许字母+数字，且长度最小为5）进行等价类划分。

|等价类组|是否为有效等价类|数据范例|
| :-----| ----: | :----: |
|长度大于等于5，包含非字母、数字的其他字符|是|`['adc%s', 'adc&ssf', ... ,'&&&&']`|
|长度大于等于5，只有字母与数字|否|`['', 'a', 'a2', ... ,'123f']`|
|长度小于5，包含非字母、数字的其他字符|否|`['&', 'a#', 'a2@', ... ,'@#$%']`|
|长度小于5，只有字母、数字|否|`[a', 'a2', ... ,'123f']`|
|空串|合法字符|否|`['']`|

### 3.1.2 边界值分析法
在功能测试中，边界值分析法也是测试人员常用的一个方法，它通常被视为对等价类划分法的一种补充。
边界值分析法是取稍高于或稍低于边界的一些数据进行测试。为什么要取这些数据进行测试呢？因为测试经验告诉我们，程序在处理边界数据的时候较容易出错。
边界值分析法在以下两种情况下经常被用到。
* 第一种情况：输入条件是一个取值范围，对于这个取值范围的边界要进行边界值测试。
* 第二种情况：输入条件中规定输入的数据是一个有序集合，对这个有序集合的边界要进行边界值测试。

例如：注册用户，需要输入年龄

需求文档明确表示年龄范围`[10~99]`，边界是10与99，那么边界值就是`9,10,11,98,99,100`。
## 3.2 组合测试方法
以上等价类划分法与边界值分析法，都是为单个测试因子，实际上，测试用例中基本都是多个测试因子。如何对对个因子取值组合测试？
- AC 全组合，穷举所有因子取值
- BC 基本选择组合，以基本组合为基础，通过更改一个输入的取值创建新的组合
- EC 单一选择组合，每一个测试输入的每一个取值在所有组合中至少出现一次
- PAIR-WISE/2-WISE/N-WISE 个输入的全组合的组合方式，覆盖任意N个输入的全组合的组合方式

### 3.2.1 PAIR-WISE/2-WISE
Pair-wise又称为结对测试法，是一种有效的测试用例生成技术，通过对测试变量的所有维度及值的组合，避免穷举测试所有维度的所有值及其组合来减少测试用例量。
保持每对组合值至少出现一次。

例如：注册功能，假设有三个测试因子：用户名、性别、年龄（大于等于18岁），取值分别为，用户名={合法字符,非法字符,空串}，性别={男,女}，年龄={17,18,19}
那么，如果穷举就需要3*2*3=18种组合

|用例组编号|用户名|密码|年龄|
| :-----| ----: | :----: |:----:|
|1|合法字符|男|17|
|2|合法字符|男|18|
|3|合法字符|男|19|
|4|合法字符|女|17|
|5|合法字符|女|18|
|6|合法字符|女|19|
|7|非法字符|男|17|
|8|非法字符|男|18|
|9|非法字符|男|19|
|10|非法字符|女|17|
|11|非法字符|女|18|
|12|非法字符|女|19|
|13|空串|男|17|
|14|空串|男|18|
|15|空串|男|19|
|16|空串|女|17|
|17|空串|女|18|
|18|空串|女|19|

Pairwise算法过程：从表的最后一行开始，如果这行的两两组合值能够在上面的行或此表中找到，那么这行就可从用例集中删除。

18行，两两组合分别为：`[空串,女]、[空串,19]、[女,19]`；那么，`[空串,女]`这对组合在`16/17`行都出现了，`[空串,19]`在`15`行出现，`[女,19]`在`6/12`行出现，所以判定`18`可以删除。
依次类推，最终得到用例组为：

|用例组编号|用户名|密码|年龄|
| :-----| ----: | :----: |:----:|
|1|合法字符|男|17|
|5|合法字符|女|18|
|6|合法字符|女|19|
|8|非法字符|男|18|
|9|非法字符|男|19|
|10|非法字符|女|17|
|14|空串|男|18|
|15|空串|男|19|
|16|空串|女|17|


#### 3.2.1.1 使用《PICT工具》生成PAIR-WISE用例
由于实际上，测试因子可能有很多，且因子取值过多，使得组合呈爆炸式增长，人工难以一个个筛选，使用PICT工具可以，自动生成。
下载地址：http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa-8dbd-8c6f76cc014b/pict33.msi

安装使用教程：https://blog.csdn.net/qq_22003641/article/details/84957448?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522160484623619725255550322%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=160484623619725255550322&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_click~default-1-84957448.pc_first_rank_v2_rank_v28p&utm_term=PICT&spm=1018.2118.3001.4449

# 四、软件打桩
涉及编程实现的单元测试请查看[测试技术框架.md](测试技术框架.md)
# 五、测试用例编写规范
请查看[测试用例编写规范.md](测试用例编写规范.md)

# 六、测试用例指标
- 类覆盖率：测试用例覆盖的类数与全部类的占比
- 方法覆盖率：测试用例覆盖的方法数与全部方法的占比
- 行覆盖率：测试用例覆盖的代码行数与全部代码行的占比
## 6.1 本地IDEA运行覆盖率测试
![测试](image/覆盖率指标.png)

## 6.2 MAVEN覆盖率测试插件
```
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>cobertura-maven-plugin</artifactId>
                <version>${cobertura-version}</version>
            </plugin>
        </plugins>
```

## 6.3 使用jenkins可以加入maven测试覆盖率插件，生成覆盖率报告
![测试](image/maven-test.png)

![测试](image/maven-test-report.png)