自动化测试20
python自动化测试(3)
自动化框架及工具
1 概述
手续的关于测试的方法论,都是建立在之前的文章里面提到的观点:
- 功能测试不建议做自动化
- 接口测试性价比最高
- 接口测试可以做自动化
后面所谈到的 测试自动化 也将围绕着 接口自动化 来介绍。
本系列选择的测试语言是 python 脚本语言。由于其官方文档已经对原理有了比较清楚的解释,本文就不做一些多余的翻译工作了。偏向于实战部分,而且为了偏向实战,也会结合 IDE 工具和项目组织来进行讲解。
理由如下:
- 脚本语言,开发和迭代的效率极高
- 第三方的扩展库极多,有很我现成的工具可以使用
在正式进入到 自动化测试 的领域之前,先要建立这样的价值观。在Google内部工程师发布的软件测试的出版物里面提到:
“软件的自动化测试是有成本的,而且成本不低,基本上相当于在原有的 功能开发工程 的基础上再建立一个平行的 测试开发工程 ”。
也就是说,如果你对自动化测试有你的期望值,那么就肯定是要付出相应的代价和精力的。好的东西也是需要优秀的人花大量的时间去完成的。
本文已经收入合集:《基于python的互联网软件测试开发(自动化测试)-全集合》,欢迎访问的查看:
2 PyUnit测试框架
使用 python 作为自动化编程语言,那么就自然的使用 pyunit 作为自动化测试框架了。
如下部分的内容主要来自于 pyunit 的官方文档,本文仅仅做了一些翻译和结构上的简单调整。这部分属于测试框架的基本原理和概念部分,在进行代码编写前,有必要进行了解。
python的单元测试框架 PyUnit,可以认为是 Java 语言下的单元测试框架 JUnit 的 Python 语言实现版本,甚至其作者之一 Kent Beck 就是 JUnit 的作者。
unittest要达到如下目标:
- 支持自动化测试
- 让所有的测试脚本共享 开启(setup) 和 关闭(shutdown) 的代码
- 可以通过集合(collections)的方式来组织测试用例脚本
- 将所有的测试脚本从测试报告框架中独立出来
为了达到以上目标,unittest支持如下几个重要概念:
- 测试装置(test fixture)
-
为一个或者多个测试用例做一些准备工作,例如:连接一个数据库,创建一个目录,或者开启一个进程
- 测试用例(test case)
-
测试用例是测试行为的最小单元,通过对一些输入输出值的对比来进行测试检查
- 测试套件(test suite)
-
将 测试用例 或者 测试用例集合 聚合组织起来的集合。可以批量执行一个测试套件内所有的测试用例
- 测试执行器(test runner)
-
组织安排测试脚本执行活动的组件。测试执行器通过一些图形界面,文本界面或者返回一些特殊的值来展示测试脚本的测试结果。主要用于生成测试报告
3 基本示例
如下示例也来自于官方文档 basic_demo.py:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
# coding:utf-8 """ 基本的自动化测试脚本 basic_demo.py """ __author__ = 'zheng' import unittest class TestStringMethods(unittest.TestCase): def setUp( self ): print 'init by setUp...' def tearDown( self ): print 'end by tearDown...' def test_upper( self ): self .assertEqual( 'foo' .upper(), 'FOO' ) def test_isupper( self ): self .assertTrue( 'FOO' .isupper()) self .assertFalse( 'Foo' .isupper()) self .assertTrue( 'Foo' .isupper()) def test_split( self ): s = 'hello world' self .assertEqual(s.split(), [ 'hello' , 'world' ]) # check that s.split fails when the separator is not a string with self .assertRaises(TypeError): s.split( 2 ) if __name__ = = '__main__' : unittest.main() |
虽然官方文档里面介绍了几种组织测试用例脚本的方式:
- 独立测试函数
- 单用例测试类
- 多用例测试类
不同的编写形态,会有不同的组织方式,具体的可以看官方文档。本文作者研究过官方文档后,最喜欢第三种方式 多用例测试类,也就是上面基本示例的方式,这种方式具有如下特点:
- 测试类 继承于 unittest.TestCase
- 一个测试类可以管理多个 测试脚本函数
- 测试脚本函数名称需要以 test_ 开头
- 一个测试类里面的所有的测试函数共享 setUp和tearDown函数
在控制台中运行此程序:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
➜ src git:(master) ✗ python basic_demo.py init by setUp... Fend by tearDown... init by setUp... end by tearDown... .init by setUp... end by tearDown... . ====================================================================== FAIL: test_isupper (__main__.TestStringMethods) ---------------------------------------------------------------------- Traceback (most recent call last): File "basic_demo.py" , line 24, in test_isupper self.assertTrue( 'Foo' .isupper()) AssertionError: False is not true ---------------------------------------------------------------------- Ran 3 tests in 0.001s FAILED (failures=1) ➜ src git:(master) ✗ |
前面的基本例子的 main 函数采用的最简单的方式,直接运行所有的测试用例,并生成默认的文本报告。其实只需要对调用函数做一些简单的修改,可以将这些测试用例进行合理组织,并获取其实有用的数据信息,以便和信息系统进行集成,形成较好的扩展。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
if __name__ = = '__main__' : # unittest.main() # 装载测试用例 test_cases = unittest.TestLoader().loadTestsFromTestCase(TestStringMethods) # 使用测试套件并打包测试用例 test_suit = unittest.TestSuite() test_suit.addTests(test_cases) # 运行测试套件,并返回测试结果 test_result = unittest.TextTestRunner(verbosity = 2 ).run(test_suit) #生成测试报告 print ( "testsRun:%s" % test_result.testsRun) print ( "failures:%s" % len (test_result.failures)) print ( "errors:%s" % len (test_result.errors)) print ( "skipped:%s" % len (test_result.skipped)) |
运行后生成的输出为:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
➜ src git:(master) ✗ python basic_demo.py test_isupper (__main__.TestStringMethods) ... init by setUp... FAIL end by tearDown... test_split (__main__.TestStringMethods) ... init by setUp... end by tearDown... ok test_upper (__main__.TestStringMethods) ... init by setUp... end by tearDown... ok ====================================================================== FAIL: test_isupper (__main__.TestStringMethods) ---------------------------------------------------------------------- Traceback (most recent call last): File "basic_demo.py" , line 23, in test_isupper self.assertTrue( 'Foo' .isupper()) AssertionError: False is not true ---------------------------------------------------------------------- Ran 3 tests in 0.001s FAILED (failures=1) testsRun:3 failures:1 errors:0 skipped:0 |
显然上面的输入结果已经将测试的结果进行了统计,这些数据都是一次测试活动中的重要指标,这些数据可以入库,和测试信息管理系统集成,后期生成仪表盘或者统计报表,形成稳定和产品测试线路图,这些都是和开发相关的了,在此不再多叙述了。
结合上面的具体例子,我们也可以找到上一节的理论部分对应的具体实现对象:
- 测试装置(test fixture)
-
由setUp函数来做初始化工作,由tearDown做销毁工作
- 测试用例(test case)
-
对应TestCase类,或者更细化的对应里面的测试脚本函数
- 测试套件(test suite)
-
对应TestSuite类
- 测试执行器(test runner)
-
对应TextTestRunner类
4 IDE工具
既然需要开发代码的生产力,那么就需要介绍一款IDE工具-- Pycharm。不可否认,它是目前最专注/专业的 Python 语言的 IDE 了。在对Pyunit 也有比较好的支持。
主要支持如下:
-
可视化的编程开发(这是IDE的基本特点)
-
对测试结果进行可视化的展示
-
导出生成HTML的测试报告
- 可视化控制用例执行(这个在开发调试阶段很方便,可以方便控制指定代码单元运行)
-
- 让一个目录下的所有用命执行
- 让单个文件内所有用例执行
- 让单个文件内的单个用命执行
4.1 运行和调试
Pycharm 对测试脚本提供了灵活的运行和调试支持。
通过pycharm,开发人员可以不用编写main函数,就可以实现如下功能:
- 运行一个文件下所有的测试类
- 运行一个测试类的所有测试脚本
- 运行一个测试类的某个测试脚本
其中 "运行一个测试类的某个测试脚本" 比较有用,适合在开发阶段快速地对单个脚本进行开发和运行调试。
使用方法:
- 将光标移动到测试函数内部
- 按下运行快捷键 ctrl+shift+F10 (Eclipse快捷键方案)
如果要断点调试,则使用Debug模式,即可对单个函数运行和断点调试了。
当然,也可以不必借用IDE,而通过对testSuit操作,也可以实现以上功能,但是IDE却提供了更灵活直接的选择。这只是一些IDE使用技巧,也不多述了。
4.2 结果可视化
对于前面提到的例子,如果选择在IDE中运行此程序,会看到如下效果:
可以看到全部运行通过。如果刻意将其中一个弄成不通过的,则会显示如下的结果:
4.3 生成测试报告
一般情况下,做自动化测试和开发,上面的那些那些技能已经完全能够满足要求了,接下来要做的事情就是利用各种计算机基本知识,面对不断增加的业务需求,而不断地增加测试用例脚本了。
功能开发项目,原理都很简单,但是随着量的增加,都会形成规模,测试开发工程也是一样。
5 项目组织
之前对测试用例的 开发调试态 的工具进行了介绍。但是如果真正的要纳入到 持续集成 的自动化体系,就显然不能依赖于 IDE 了。而是使用python 语言的组织和调用方式了,比如:要有 __main__ 函数来作为执行入口,等等。
详细的技术实现细节,在后面有机会,将再会写相应的文章进行介绍。
通过脱离IDE的项目组织方式,有如下优点:
- 可以通过事件触发来执行所有脚本(能够成为 持续集成 流水线的一环节)
- 可以将数据全部提出并进行自定义加工和处理(和测试信息系统集成,为质量分析系统提供数据源)
6 测试平台
关于如何自动化生成测试报告这个测试产物,现在有一些平台能够提供接口调用及报告展示和分享功能,详情参考:
http://www.jianshu.com/p/c5fa76cf87db
7 小结
本小部分的内容,主要是讲基于 python 语言的 自动化测试框架 pyunit的一些设计思想和基本使用示例。其实工具的使用方法很简单,但是如何利用好这些工具来进行软件生产,则需要其它的计算机技能了,在后续的文章中将会从工程方面和技术方面来对此框架的应用进行深入的扩展。
来自:https://www.cnblogs.com/beer/p/5075619.html