自动化测试

什么时候自动测试实施才是最好的时候呢？
我想很多做测试的人都在想这样的一个问题，哪怕公司里面没有涉及到自动化测试，也会希望自己负责的项目与自动化测试能挂上勾，能够从中学习到自动化测试过程。
其实自动化测试只是作为测试的一种技术实施手段，并非一个职业发展方向，在项目没有稳定，或者是有大量变动的时候，自动化测试反而往往是比较鸡肋的辅助手段了。测试的目的无在乎是更准确更早的去发现系统出现的问题，奔着这个目的，才会去需要去需求各种技术手段来实现。
就目前我们公司项目重构而言，在项目立项时，我做了一个测试的规划：

1. 用例设计规范与重构
   1.1 目的
   统一测试用例编写规范，为测试人员提供测试用例用例编写的指导，提高编写的测试用例的可读性，可执行性，合理性。为测试执行人员更好执行测试和开发人员进行自测依据，提高测试效率，最终提高公司整个产品的质量。
   1.2 工具选型
   主要公司现在统一使用禅道，所有目前暂定为在禅道上做用例设计

1.3 测试用例作用

便于测试负责人检查测试人员对系统的理解程度
便于测试人员、开发人员和产品，ux就测试内容和范围达成一致，利于交流
指导测试执行人员的执行过程，使测试过程有序不重复
方便测试负责人了解测试进度
便于测试结果分析

1.4 测试用例设计范围和原则
测试用例按安装配置测试、业务流程测试、角色模块功能点测试、数据权限测试、用户界面测试进程测试范围划分和管理，测试用例按照基本流和异常流进行设计，基本流和异常流中每一个测试点标题明确测试目的，每个测试集（业务目标和功能点）开始明确测试范围和前置条件（可选），每个测试点前置条件，紧跟测试标题，测试目录和测试集按测试优先级进行编号排序，基本流和异常流中的测试点也按测试优先级进行编号排序，测试用例管理如下

测试用例可分为两大类：
1.4.1 通用型测试用例：
安装配置测试，用户界面测试
安装配置测试
正确性验证，依据安装配置手册设计基本流程测试用例，按角色操作设计测试用例，突出操作
用户界面测试进程测试
界面完整性、分页显示、页面跳转、提示窗口、标题、易用性测试等
界面测试的测试点主要为：除去ux需要介入的页面调整外，还需要做输入值测试，
数据类型判断，数据长度，约束条件是否满足，是否完整，tab与enter是否有用，特殊字符输入（~！@#￥%……&*（）-+等），是否为空验证等
1.4.2 业务型测试用例：
业务流程测试，角色模块功能点测试，数据权限测试
业务流程测试
根据产品需求说明书、产品需求，测试设计流程图，以便于理清业务逻辑
角色模块功能点测试
根据产品需求规格说明书，产品测试需求文档整理、沟通测试需求理清角色模块功能点
数据权限测试
角色管理、不同管辖范围数据权限，交叉管理数据权限测试等
1.5 测试用例设计方法
1.5.1 等价类划分
把程序的输入域划分为若干的部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类的其它值
1.5.2 边界值分析
通过选择等价类边界值的测试用例，边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界
1.5.3 错误推测设计方法
该方法是基于经验和直觉推测程序中所有可能存在的各种错误，从而设计有针对性的测试用例
1.5.4 因果图方法
该方法是用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判断表
1.5.5 正交试验设计法
该方法是使用已经造好的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率
1.5.6 功能图法
该方法是由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来表示。一个状态指出数据输入的位置（或时间），一个迁移指明状态的改变，同时要依靠判定表或因果图表示逻辑功能
1.6 测试用例标准
1）需求点要100%覆盖
2）被测功能点或控件100%覆盖。（用户需求说明书形成测试功能说明书）
3）必须验证正确性操作，正常数据和可能导致出错的数据，操作
4）有数据值域的必须考虑数据值域覆盖：边界值，等价类
5）所有的边界值都必须覆盖
6）等价类必须包含有效和无效等价类
7）所有的等价类都必须覆盖（等价类数量过多导致超过测试成本的，优先考虑8）有效等价类）后根据数据使用率，几率高低分优先级，高优先级先覆盖，同时考虑自动化测试
9）核心功能点的数据排列组合对功能产生不同影响的，必须考虑排列组合（排列组合以有效等价类优先）
10）用例可以直接执行或易于准确执行
11）用例有明确的预期结果能够用于准确判断是否符合要求，或定义缺陷
12）核心功能点必须被覆盖多次（用例数量比非核心功能点至少多2倍）
测试用例的数量不少于功能点的数量

1.7 接口用例设计规范
1.7.1 优先级–针对所有接口

1、暴露在外面的接口，因为通常该接口会给第三方调用；

2、供系统内部调用的核心功能接口；

3、供系统内部调用非核心功能接口；

1.7.2 优先级–针对单个接口

1、正向用例优先测试,逆向用例次之(通常情况，非绝对)；

2、是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 >业务逻辑是否正确> 参数之间是否存在关联 > 参数数据类型限制 >参数数据类型自身的数据范围值限制
1.7.3 设计分析
通常，设计接口测试用例需要考虑以下几个方面：
1、是否满足前提条件
有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token。
逆向用例：
针对是否满足前置条件(假设为n个条件)，设计0~n条用例
2、是否携带默认值参数
正向用例：
带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计1条用例；
3、业务规则、功能需求
这里根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例
5、参数是否必填
逆向用例：
针对每个必填参数，都设计1条参数值为空的逆向用例
4、参数之间是否存在关联
有些参数彼此之间存在相互制约的关系
逆向用例：
根据实际情况，可能需要设计0~n条用例
5、业务逻辑是否正确
6、参数数据类型限制
逆向用例：
针对每个参数都设计1条参数值类型不符的逆向用例
7、参数数据类型自身的数据范围值限制
正向用例：
针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例
逆向用例：
针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例
针对每个参数(假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例
以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖：
主流程测试用例：正常的主流程功能校验；
分支流测试用例：正常的分支流功能校验。
异常流测试用例：异常容错校验
1.7.4 编写描述
尽量逻辑化，这样方便后续的维护
1.7.5 实践操作
链接如下：
接口用例示例.docx

2 缺陷
2.1 现状
对目前公司项目情况来看，在测试报告输出时需要定义完整的缺陷报告，来反应本次迭代的测试遗留缺陷情况
2.2 改进
在大版本迭代中，除总结性缺陷报告外，还需要在测试执行日邮件形式输出每日严重缺陷，便于及时反映缺陷情况，给予及时解决方案

2.3 缺陷规范

2.3.1 标题
　　1. 首先要做一个“标题党”（此标题党非彼标题党）。标题一定要清晰简洁易理解，不应该臃长
　　2. 尽量前缀要规范，例如模板： [Product][Version][Feature][Title]，这样描述会很清晰，也方便查找
　　3. 缺陷的标题一定要描述在什么情况下发生了什么问题
　　4. 尽量避免使用人称（比如you, I等等）
　　缺陷标题的例子： DemoApp 1.0_Login_Cannot enter username by copy/paste enternal string
　　这个标题包含了产品名，版本号，模块，发生了什么（cannot enter username),什么情况下(copy/paste enternal string)
2.3.2 描述或总结
　　描述或总结这个模块可以用来描述标题不能容纳的更详细的内容，它可以包括很多方面，比如相关、历史版本是否重现、用户操作等。目的是更清晰详细的描述缺陷。
2.3.3 影响
　　　这部分用以描述该缺陷对用户实际应用中的影响。　
2.3.4 前置条件
　　用以描述在重现缺陷之前环境、数据或者其他的一些特殊需求。
2.3.5 重现步骤
　　从用户角度出发来描述重现步骤，步与步之间不应该有太大的业务跳跃，最好是连贯的。
　　例如：
　　Repro Steps：
　　1. Open DemoApp to enter Login screen
　　2. Copy username from enternal file
　　3. Paster username to username field of Login Screen
2.3.6 结果
　　结果可以分为“期望结果”和“实际结果”，结果可以有多个，也可以穿插在重现步骤之间（比如重现步骤中有多个缺陷的问题）
2.3.7 优先级
　　凡事都有轻重缓急，缺陷也是，需要标明缺陷优先级和紧急程度，以便开发团队决定先做还是延后。
2.3.8 重现频率　　
　　当然，大部分的缺陷是可以100%重现的，对于少数缺陷可能很难重现，或者不太容易重现，这就要标明重现的几率，比如50%。往往这种缺陷需要提供详细的日志文件，以便从日志角度获取重现或者解决突破口。
2.3.9 附件
　　附件非常重要！附件的格式可以多种多样，图片，日志文件，视频等。除了可以提供直观的认识（图片，视频），还可以有更多的信息（缺陷讨论邮件，日志等）。
2.3.10 变通方案（Workaround）
　　变通方案是提供一种绕过当前问题而使用其它的产品功能的一种方式。这样客户就可以在缺陷未解决的情况下继续使用产品。
2.3.11 发生原因分析（Root Cause Analysis）
　　描述从代码角度，该缺陷是如何发生的。能做到这一步的测试人员需要有较高的读写代码的能力。
2.3.12 环境配置
　　用以描述测试环境的配置，比如OS，相应产品版本等。

2.4 缺陷流程
缺陷处理：处理流程
禅道处理流程
2.5 缺陷报告模板

3 接口测试规范及测试侧重点
3.1 接口测试规范及测试工具选型
3.1.1 正常逻辑功能，正确参数值，接口请求返回正确
3.1.2 异常情况需要完成内容：
数值字段边界值：服务返回正确的msg
接口字段为空：接口字段返回是否为空处理（所有后台返回字段如果查询不到数据，返回为空字符串或空对象，不可缺失）
参数类型：字段参数类型验证
字段长度：字段长度需要验证
接口响应时间：
根据258原则，接口响应时间在5s内
业务逻辑
参数的规范校验
需提供api文档注释：
返回字段及参数的注释
Code响应码定义需要提供文档，列出code值表示意思

3.1.3 接口文档需要提供部分：
接口功能描述
接口请求方,传输格式与编码方式
url : 需要对url进行规范
1)移动端：http://app.***.cn/v版本号/模块名/功能名/方法名
2)Web前端：http://www.***.cn/v版本号/模块名/功能名/方法名
参数说明：
参数中应该包含：名称，类型，长度，描述信息
请求参数事例与返回参数事例

3.1.4 接口流量控制
Nginx前端限流
按照一定的规则如帐号、IP、系统调用逻辑等在Nginx层面做限流
业务应用系统限流
1、客户端限流
2、服务端限流
数据库限流
红线区，力保数据库
3.1.5 接口测试工具
介于目前公司所掌握的知识点与工具熟练程度，与实际情况而言，接口测试工具暂时采用postman来进行测试
使用方法见如下文档：
Postman使用方法
3.2 接口测试侧重点
参照接口用例设计规范
4 测试流程
4.1 测试流程图

4.2 测试报告模板
详情见：测试报告模板
5 自动化接口测试框架
5.1 目的
介于目前公司项目情况，项目业务迭代较为紧张，所有后续版本稳定后需要对大体功能做自动化测试，自动化测试主要是帮助测试人员减轻工作量，提高工作效率，找出更多的问题，提高产品质量
5.2 自动化工具选型
通过pytest+requests来实现接口自动化测试，设计用例完成后，采用Jenkins进行持续化集成，实现自动化的持续化集成
还有就是postman+Jenkins方式进行测试实现
Jenkins+postman
5.3 自动化测试实现方式
环境准备：
pytest：需要在python中安装pytest，pytest-html（完美html测试报告生成）、pytest-rerunfailures（失败case重复执行）

例子代码如下：

默认执行当前目录下的所有以test_为前缀(test_.py)或以_test为后缀(_test.py)的文件中以test_为前缀的函数
控制台执行结果为：

在结合Jenkins进行新增：
pytest + allure + jenkins 生成漂亮的测试报告
Jenkins环境配置：
安装插件：

5.3.1 安装插件
HTML Publisher plugin
Allure Jenkins Plugin
5.3.2 Allure Commandline 配置
“全局工具配置”页面找到Allure Commandline，进行如下配置：

5.3.3 Job配置
3.1创建一个自由风格的软件项目，如建一个名称为 pytest allure 的 Job。
3.2 使用自定义的空间（即后面的${workspace}）:

5.3.4 配置构建步骤

5.3.5 配置构建后操作
allure结果路径需要和构建步骤中相统一：

我们还可以再加上构建后发邮件配置，此处不再赘述。
5.3.6 执行Job查看构建结果

Allure报告展示：

6 性能测试规划
6.1 性能测试工具选型
性能测试工具选择为：
Jmeter，由于是开源的工具，可以节约开销成本，并且jmeter可支持多台设备同时对一个接口进行测试
6.2 性能测试场景设计模板
单接口进行性能测试，测试场景如下：
比如库存查询接口：
对jmeter设置如下，首先是线程组的设置，：可设置线程请求数，并发数，每秒新增与减少，如图所示，总共为100线程同时请求，等待10s，然后一下启动20个线程，后续每30秒启动10个线程，增加5s后，运行60s，然后平均每秒停止5个线程，直到结束（这仅仅是一个场景的设置，场景设置需要根据接口的实际情况进行指定）

然后是jmeter对接口方式的设置，首先需要有信息头添加contentype为json方式，然后设置cookie管理器用于登录后获取taken认证，最后就是登录接口与查询接口，查询接口需要在简单控制器里面，因为其没有json方式的信息头

测试结果如下，如下为平均响应时间与聚合报告信息，可根据明显变化的时间点，来逐步排查性能问题：

如果出现了需要并发在3000以上，那么需要多台测试设备同时对同一个接口进行访问，则可以做如下设置：
Jmeter里面设置远程启动，如下图，所有的测试机指定到同一台测试机上，并在jmeter.properties中设置每个测试机ip，如下图所示

6.3 性能测试报告模板
测试报告模板
7 Monkey自动化设计实现
7.1 环境搭建
采用python实现monkey自动执行策略，Jenkins+python实现自动化monkey测试，所以本机需要有Jenkins，并且Jenkins中安装有python插件，需要安装python，与adb，并且需要对python与adb配置环境变量，就目前而言只是针对于android，并未对ios进行设计
7.2 Monkey测试作用
Monkey 主要用于Android 的压力测试 自动的一个压力测试小工具，主要目的就是为了测试app是否会Crash或者出现anr.
7.3 实现方式
Jenkins配置如下：
首先会设置三个参数，devices（手机设备唯一识别号），packagename（app包名），paths（存放crash日志地方），如下图所示：

代码实现部分（暂时定为测试50万点击次数），通过Jenkins传递参数后来对app发送执行指令，后生成log日志，如下图所示：

Crash日志情况如下：

7.4 改进
就目前实现情况需进行后续改进，改进大概内容如下：
测试时间：根据实际情况设置测试执行时间
手机自带下拉框设置隐藏：由于进行monkey测试的时候，会点出手机自带下拉框，选择手机模式，可能会关闭wifi，所以需要采用一种方式对下拉框进行屏蔽，不让其点击，以便于能够正常使用wifi进行测试
电量检查：在测试开始时，需要对手机进行电量检查，查看电量是否能够支持后续的monkey测试
登陆：由于app需要登陆操作，需要设置自动化用例对app进行登陆，每次需要登陆后才对其进行monkey测试，并且进行后需屏蔽登陆退出按钮，以便于测试的准确性。
后续若存在多项目的monkey测试，需要对其进行判断手机使用情况，通过Jenkins的api方式进行合理安排monkey测试
通过python筛选出log中的crash内容
8 App自动化测试初步方案
8.1 工具选型
采用Jenkins+python+appium的方式进行app自动化测试
8.2 环境搭建
安装jenkins，python，appium，python中需要安装Appium-Python-Client库
8.3 实现
具体实现方式如下所示，以高值耗材登录为例：

首先需要对appium设置环境配置，如下图所示：

需要设置为自身手机的版本号，目前测试机为华为mate7，版本为5.1.1，所以设置版本为5.1。

需要勾选覆盖之前的session，以便于避免session过期问题
再设置后，则点击启动appium:

如图则表示启动成功

此时需要把手机连接电脑，如下图，确保手机已经连接电脑：

采用uiautomatorviewer进行元素定位

则此时采用python实现登录功能，如下图：

运行代码则可实现自动登录功能，做后续操作或判断，则需要appium中的api去做后续操作
9 App兼容性测试方案选取
App兼容性测试需要依赖于多个手机，多个版本，鉴于目前条件情况，暂定为采用第三方测试平台进行测试：
由于第三方测试平台不提供本地内网支持，所以测试环境为预发布环境，第三提供功能为登陆后随机点击事件
采用第三方平台为：testin，腾讯质量开放平台
以下是testin测试结果图：

10 Ui自动化
Ui自动化会采用python+selenium+Jenkins的方式进行实现，但是目前项目情况不适合做ui自动化，并且ui自动化成本较高，人员暂时不符合预期，所有暂不考虑，后续有需要后，进行评估