Monkey测试环境搭建

如果想要搭建好Monkey的测试环境,首先几个必要的步骤和环境不能少,分别是java相关环境、Android SDK环境,启动android虚拟机或连接真机与执行monkey测试。现在我分步总结如下:

一、JAVA环境的搭建
1、首先要安装java的JDK;
2、安装好JDK之后需要配置环境变量,
在“系统变量”中,设置3项属性,JAVA_HOME,PATH,CLASSPATH(大小写无所谓),若已存在则点击“编辑”,不存在则点击“新建”; 
JAVA_HOME指明JDK安装路径,就是刚才安装时所选择的路径,如:D:\java\jdk1.5.0_08,
此路径下包括lib,bin,jre等文件夹(此变量最好设置,因为以后运行tomcat,eclipse等都需要依*此变量);
 
  Path使得系统可以在任何路径下识别java命令,设为: 
 
  %JAVA_HOME%\bin;%JAVA_HOME%\jre\bin 
 
  CLASSPATH为java加载类(class or lib)路径,只有类在classpath中,java命令才能识别,设为: 
 
  .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar (要加.表示当前路径) 
 
  %JAVA_HOME%就是引用前面指定的JAVA_HOME;
3、“开始”->;“运行”,键入“cmd”;输入命令“java -version”,“java”,“javac”几个命令,出现了JAVA的版本信息,说明环境变量设置成功.
上传1
二、Android SDK工具安装

1.下载基于windows 的 androidSDK

下安装的官网地址请参照:http://developer.android.com/intl/zh-cn/sdk/index.html#Other,截图如下:

Monkey测试教程-Monkey介绍及测试环境搭建1上传2

2. 设置sdk下面tools的环境变量

下载安装完成后,鼠标右击“计算机”-》属性-》高级系统设置-》环境变量-》先设置Android的环境变量,与JAVA一样,先新建ANDROID_HOME环境变量

上传3

 再在Path编辑加入%ANDROID_HOME%\tools;%ANDROID_HOME%\platform-tools;

上传4

3.安装完成之后,打开android SDK显示如下:

上传5
三、Android Monkey 测试准备[注意:保证手机内存充足,否则无法测试]

  上面的步骤如果都完成之后,如果想要启动Monkey测试环境,必须先启动android虚拟机或者连接上真机。这里以真机来说:

   [注意:保证手机内存充足,否则无法测试]

 1.  启动命令行,输入cmd,打开命令窗口;
 

 2. 进入路径为SDK的platform-tools的安装路径,如下:

F:\Program Files (x86)\Android\android-sdk\platform-tools】

上传6

输入adb空格shell:

上传7

出现error:device not found,说明安卓设备没有被找到,此时可以使用手机连接电脑,手机的USB模式必须打开,电脑上必须安装有手机的驱动,连上设备之后,我们在输入adb shell命令,如下:

上传8

上图就是能执行操作的命令,此时就可以执行Monkey Test命令了。

此时我们可以执行monkey命令:

Monkey –p com.qq –v 1000

此命令意思为执行1000次随机用户模拟操作,com.jianke.doctor为安装包的名字,例如Monkey –p com.jianke.doctor –v 100

上传9上传10

以上是我使用Monkey测试的基础环境搭建,欢迎大家一起学习。

 

测试用例的设计方法(全)

等价类划分方法:

一.方法简介

1.定义
是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

2.划分等价类:
等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试,因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。
1)有效等价类
是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
2)无效等价类
与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。
设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验,这样的测试才能确保软件具有更高的可靠性。

3.划分等价类的标准:
1)完备测试、避免冗余;
2)划分等价类重要的是:集合的划分,划分为互不相交的一组子集,而子集的并是整个集合;
3)并是整个集合:完备性;
4)子集互不相交:保证一种形式的无冗余性;
5)同一类中标识(选择)一个测试用例,同一等价类中,往往处理相同,相同处理映射到”相同的执行路径”。

4.划分等价类的方法
1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如:输入值是学生成绩,范围是0~100;                     2)在输入条件规定了输入值的集合或者规定了”必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类;
3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
4)在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。例:输入条件说明学历可为:专科、本科、硕士、博士四种之一,则分别取这四种这四个值作为四个有效等价类,另外把四种学历之外的任何学历作为无效等价类。
5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则);
6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

5.设计测试用例
在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件:有效等价类、无效等价类,然后从划分出的等价类中按以下三个原则设计测试用例:
1)为每一个等价类规定一个唯一的编号;
2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;
3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。

二.实战演习
1.某程序规定:”输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算 … “。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。)
分析题目中给出和隐含的对输入条件的要求:
(1)整数    (2)三个数    (3)非零数   (4)正数
(5)两边之和大于第三边     (6)等腰     (7)等边
如果 a 、 b 、 c 满足条件( 1 ) ~ ( 4 ),则输出下列四种情况之一:
1)如果不满足条件(5),则程序输出为 ” 非三角形 ” 。
2)如果三条边相等即满足条件(7),则程序输出为 ” 等边三角形 ” 。
3)如果只有两条边相等、即满足条件(6),则程序输出为 ” 等腰三角形 ” 。
4)如果三条边都不相等,则程序输出为 ” 一般三角形 ” 。
列出等价类表并编号

覆盖有效等价类的测试用例:
a     b     c             覆盖等价类号码
3     4     5             (1)–(7)
4     4     5             (1)–(7),(8)
4     5     5             (1)–(7),(9)
5     4     5             (1)–(7),(10)
4     4     4             (1)–(7),(11)
覆盖无效等价类的测试用例:

2.设有一个档案管理系统,要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的”日期检查功能”。
1)划分等价类并编号,下表等价类划分的结果

输入等价类

有效等价类 无效等价类
日期的类型及长度

①6位数字字符

②有非数字字符

③少于6位数字字符

④多于6位数字字符

年份范围

⑤在1990~2049之间

⑥小于1990

⑦大于2049

月份范围

⑧在01~12之间

⑨等于00

⑩大于12

2)设计测试用例,以便覆盖所有的有效等价类在表中列出了3个有效等价类,编号分别为①、⑤、⑧,设计的测试用例如下:
测试数据    期望结果      覆盖的有效等价类
200211      输入有效     ①、⑤、⑧
3)为每一个无效等价类设计一个测试用例,设计结果如下:
测试数据   期望结果     覆盖的无效等价类
95June     无效输入         ②
20036      无效输入          ③
2001006   无效输入         ④
198912     无效输入         ⑥
200401     无效输入         ⑦
200100     无效输入         ⑨
200113     无效输入         ⑩

3.NextDate 函数包含三个变量:month、 day 和 year ,函数的输出为输入日期后一天的日期。 例如,输入为 2006年3月 7日,则函数的输出为 2006年3月8日。要求输入变量 month 、 day 和 year 均为整数值,并且满足下列条件:
①1≤month≤12
②1≤day≤31
③1920≤year≤2050
1)有效等价类为:
M1={月份:1≤月份≤12}
D1={日期:1≤日期≤31}
Y1={年:1812≤年≤2012}
2)若条件 ①~ ③中任何一个条件失效,则NextDate 函数都会产生一个输出,指明相应的变量超出取值范围,比如 “month 的值不在 1-12 范围当中 ” 。显然还存在着大量的 year 、 month 、 day 的无效组合, NextDate 函数将这些组合作统一的输出: ” 无效输入日期 ” 。其无效等价类为:
M2={月份:月份<1}
M3={月份:月份>12}
D2={日期:日期<1}
D3={日期:日期>31}
Y2={年:年<1812}
Y3={年:年>2012}
弱一般等价类测试用例
月份   日期      年              预期输出
6      15       1912           1912年6月16日
强一般等价类测试用例同弱一般等价类测试用例
注:弱–有单缺陷假设;健壮–考虑了无效值

(一)弱健壮等价类测试
用例ID  月份  日期    年         预期输出
WR1      6     15    1912      1912年6月16日
WR2     -1    15    1912      月份不在1~12中
WR3     13    15    1912      月份不在1~12中
WR4      6     -1    1912      日期不在1~31中
WR5      6     32    1912      日期不在1~31中
WR6      6     15    1811      年份不在1812~2012中
WR7      6     15    2013      年份不在1812~2012中

(二)强健壮等价类测试
用例ID  月份    日期     年         预期输出
SR1       -1     15       1912     月份不在1~12中
SR2       6      -1       1912      日期不在1~31中
SR3       6      15      1811      年份不在1812~2012中
SR4       -1     -1       1912      两个无效一个有效
SR5       6      -1       1811      两个无效一个有效
SR6       -1     15       1811      两个无效一个有效
SR7       -1     -1       1811      三个无效

4.佣金问题等价类测试用例,它是根据佣金函数的输出值域定义等价类,来改进测试用例集合。
输出销售额≤1000元     佣金10%
1000<销售额≤1800    佣金=100+(销售额-1000)*15%
销售额>1800             佣金=220+(销售额-1800)*20%
测试用例        枪机(45)   枪托(30)     枪管(25)         销售额     佣金
1              5            5              5                 500        50
2             15          15             15                1500       175
3             25          25             25                2500       360
根据输出域选择输入值,使落在输出域等价类内,可以结合弱健壮测试用例结合。

边界值分析方法:

一.方法简介
1.定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。

2.与等价划分的区别
1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。
2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。

3.边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。
使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

4.常见的边界值
1)对16-bit 的整数而言 32767 和 -32768 是边界
2)屏幕上光标在最左上、最右下位置
3)报表的第一行和最后一行
4)数组元素的第一个和最后一个
5)循环的第 0 次、第 1 次和倒数第2 次、最后一次

5.边界值分析
1)边界值分析使用与等价类划分法相同的划分,只是边界值分析假定错误更多地存在于划分的边界上,因此在等价类的边界上以及两侧的情况设计测试用例。
例:测试计算平方根的函数
–输入:实数
–输出:实数
–规格说明:当输入一个0或比0大的数的时候,返回其正平方根;当输入一个小于0的数时,显示错误信息”平方根非法-输入值小于0″并返回0;库函数Print-Line可以用来输出错误信息。

2)等价类划分:
I.可以考虑作出如下划分:
a、输入 (i)<0 和 (ii)>=0
b、输出 (a)>=0 和 (b) Error
II.测试用例有两个:
a、输入4,输出2。对应于 (ii) 和(a) 。
b、输入-10,输出0和错误提示。对应于 (i) 和(b) 。

  3)边界值分析:
划分(ii)的边界为0和最大正实数;划分(i)的边界为最小负实数和0。由此得到以下测试用例:
a、输入{最小负实数}
b、输入{绝对值很小的负数}
c、输入0
d、输入{绝对值很小的正数}
e、输入{最大正实数}

4)通常情况下,软件测试所包含的边界检验有几种类型:数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。
5)相应地,以上类型的边界值应该在:最大/最小、首位/末位、上/下、最快/最慢、最高/最低、  最短/最长、 空/满等情况下。
6)利用边界值作为测试数据

边界值 测试用例的设计思路
字符

起始-1个字符/结束+1个字符

假设一个文本输入区域允许输入1个到255个 字符,输入1个和255个字符作为有效等价类;输入0个和256个字符作为无效等价类,这几个数值都属于边界条件值。

数值

最小值-1/最大值+1

假设某软件的数据输入域要求输入5位的数据值,可以使用10000作为最小值、99999作为最大值;然后使用刚好小于5位和大于5位的 数值来作为边界条件。

空间

小于空余空间一点/大于满空间一点

例如在用U盘存储数据时,使用比剩余磁盘空间大一点(几KB)的文件作为边界条件。

7)内部边界值分析:
在多数情况下,边界值条件是基于应用程序的功能设计而需要考虑的因素,可以从软件的规格说明或常识中得到,也是最终用户可以很容易发现问题的。然而,在测试用例设计过程中,某些边界值条件是不需要呈现给用户的,或者说用户是很难注意到的,但同时确实属于检验范畴内的边界条件,称为内部边界值条件或子边界值条件。
内部边界值条件主要有下面几种:
a)数值的边界值检验:计算机是基于二进制进行工作的,因此,软件的任何数值运算都有一定的范围限制。

范围或值

位(bit)

0或者1
字节(byte) 0——225

字(word)

0~65535(单字)或 0~4294967295(双字)

千(K)

1024

兆(M)

1048576
吉(G)

1073741824

b)字符的边界值检验:在计算机软件中,字符也是很重要的表示元素,其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

字符

ASCII码值

字符

ASCII码值

空 (null)

0 A 65

空格 (space)

32 a 97

斜杠 ( / )

47 Z 90
0 48 z 122

冒号 ( : )

58

单引号 ( ‘ )

96
@ 64

c)其它边界值检验

6.基于边界值分析方法选择测试用例的原则
1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。
例如,如果程序的规格说明中规定:”重量在10公斤至50公斤范围内的邮件,其邮费计算公式为……”。作为测试用例,我们应取10及50,还应取10.01,49.99,9.99及50.01等。
2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
比如,一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。
3)将规则1)和2)应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。
例如,某程序的规格说明要求计算出”每月保险金扣除额为0至1165.25元”,其测试用例可取0.00及1165.24、还可取一0.01及1165.26等。
再如一程序属于情报检索系统,要求每次”最少显示1条、最多显示4条情报摘要”,这时我们应考虑的测试用例包括1和4,还应包括0和5等。
4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
5)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。
6)分析规格说明,找出其它可能的边界条件。

二.实战演习
1.现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:

①标题:这一组只有一个记录,其内容为输出成绩报告的名字。
②试卷各题标准答案记录:每个记录均在第80个字符处标以数字”2″。该组的第一个记录的第1至第3个字符为题目编号(取值为1一999)。第10至第59个字符给出第1至第50题的答案(每个合法字符表示一个答案)。该组的第2,第3……个记录相应为第51至第100,第101至第150,…题的答案。
③每个学生的答卷描述:该组中每个记录的第80个字符均为数字”3″。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号,第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50,则第2,第3……纪录分别给出他的第51至第100,第101至第150……题的解答。然后是学生乙的答卷记录。
④学生人数不超过200,试题数不超过999。
⑤程序的输出有4个报告:
a)按学号排列的成绩单,列出每个学生的成绩、名次。
b)按学生成绩排序的成绩单。
c)平均分数及标准偏差的报告。
d)试题分析报告。按试题号排序,列出各题学生答对的百分比。
解答:分别考虑输入条件和输出条件,以及边界条件。给出下表所示的输入条件及相应的测试用例。

输出条件及相应的测试用例表。

2.三角形问题的边界值分析测试用例
在三角形问题描述中,除了要求边长是整数外,没有给出其它的限制条件。在此,我们将三角形每边边长的取范围值设值为[1, 100] 。

3.NextDate函数的边界值分析测试用例
在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为1912≤year≤2050 。

因果图方法

一.   方法简介

1.定义:是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

2.因果图法产生的背景:

等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。

3.因果图介绍

1) 4种符号分别表示了规格说明中向4种因果关系。

2) 因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或称原因),右结点表示输出状态(或称结果)。

3) Ci表示原因,通常置于图的左部;ei表示结果,通常在图的右部。Ci和ei均可取值0或1,0表示某状态不出现,1表示某状态出现。

4. 因果图概念

1)    关系

①恒等:若ci是1,则ei也是1;否则ei为0。

②非:若ci是1,则ei是0;否则ei是1。

③或:若c1或c2或c3是1,则ei是1;否则ei为0。“或”可有任意个输入。

④与:若c1和c2都是1,则ei为1;否则ei为0。“与”也可有任意个输入。

2)    约束

输入状态相互之间还可能存在某些依赖关系,称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

A.输入条件的约束有以下4类:

   ① E约束(异):a和b中至多有一个可能为1,即a和b不能同时为1。

   ② I约束(或):a、b和c中至少有一个必须是1,即 a、b 和c不能同时为0。

   ③ O约束(唯一);a和b必须有一个,且仅有1个为1。

   ④R约束(要求):a是1时,b必须是1,即不可能a是1时b是0。

B.输出条件约束类型

   输出条件的约束只有M约束(强制):若结果a是1,则结果b强制为0。

5. 采用因果图法设计测试用例的步骤:

1)分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。

2)分析软件规格说明描述中的语义,找出原因与结果之间, 原因与原因之间对应的关系,根据这些关系,画出因果图。

3)由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现,为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。

4)把因果图转换为判定表。

5)把判定表的每一列拿出来作为依据,设计测试用例。

二. 实战演习

1. 某软件规格说明书包含这样的要求:第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果第一列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息M。

解答:

1) 根据题意,原因和结果如下:

       原因:

         1——第一列字符是A;

         2——第一列字符是B;

         3——第二列字符是一数字。

       结果:

         21——修改文件;

         22 ——给出信息L;

         23——给出信息M。

2) 其对应的因果图如下:

11为中间节点;考虑到原因1和原因2不可能同时为1,因此在因果图上施加E约束。

3)根据因果图建立判定表。

 表中8种情况的左面两列情况中,原因①和原因②同时为1,这是不可能出现的,故应排除这两种情况。表的最下一栏给出了6种情况的测试用例,这是我们所需要的数据。

2.有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。

1) 分析这一段说明,列出原因和结果

原因:

1.售货机有零钱找

2.投入1元硬币

3.投入5角硬币

4.押下橙汁按钮

5.押下啤酒按钮

结果:

21.售货机〖零钱找完〗灯亮

22.退还1元硬币

23.退还5角硬币

24.送出橙汁饮料

25.送出啤酒饮料

2)画出因果图,如图所示。所有原因结点列在左边,所有结果结点列在右边。建立中间结点,表示处理的中间状态。中间结点:

11. 投入1元硬币且押下饮料按钮

12. 押下〖橙汁〗或〖啤酒〗的按钮

13. 应当找5角零钱并且售货机有零钱找

14. 钱已付清

3)转换成判定表:

4) 在判定表中,阴影部分表示因违反约束条件的不可能出现的情况,删去。第16列与第32列因什么动作也没做,也删去。最后可根据剩下的16列作为确定测试用例的依据。

判定表驱动分析方法

一.    方法简介

1.定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

2.判定表的优点

能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。

在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。

3.“阅读指南”判定表

4. 判定表通常由四个部分组成如下图所示。

1)条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

2)动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3)条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。

4)动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。

5.规则及规则合并

1)规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。

2)化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。

6.规则及规则合并举例

1)如下图左端,两规则动作项一样,条件项类似,在1、2条件项分别取Y、N时,无论条件3取何值,都执行同一操作。即要执行的动作与条件3无关。于是可合并。“-”表示与取值无关。

2)与上类似,下图中,无关条件项“-”可包含其他条件项取值,具有相同动作的规则可合并。

3)化简后的读书指南判定表

1

2

3

4

你觉得疲倦吗?

Y

N

你对内容感兴趣吗?

Y

Y

N

N

书中内容使你胡涂吗?

Y

N

 

请回到本章开头重读

x

继续读下去

X

跳到下一章去读

x

停止阅读,请休息

x

7.判定表的建立步骤:(根据软件规格说明)

1)确定规则的个数.假如有n个条件。每个条件有两个取值(0,1),故有2n种规则。

2)列出所有的条件桩和动作桩。

3)填入条件项。

4)填入动作项。等到初始判定表。

5)简化.合并相似规则(相同动作)。

二. 实战演习

1.问题要求:”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器,应给予优先的维修处理……” 。这里假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。请建立判定表。

解答:

①确定规则的个数:这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则。

②列出所有的条件茬和动作桩:

③填入条件项。可从最后1行条件项开始,逐行向上填满。如第三行是: Y N Y N Y N Y N,第二行是: Y Y N N Y Y N N等等。

④填入动作桩和动作顶。这样便得到形如图的初始判定表。

1

2

3

4

5

6

7

8

功率大于50马力吗?

Y

Y

Y

Y

N

N

N

N

维修记录不全吗?

Y

Y

N

N

Y

Y

N

N

运行超过10年吗?

Y

N

Y

N

Y

N

Y

N

进行优先处理

x

x

X

X

X

作其他处理

X

x

x

初始判定表

⑤化简。合并相似规则后得到图。

1

2

3

4

5

功率大于50马力吗?

Y

Y

Y

N

N

维修记录不全吗?

Y

N

N

运行超过10年吗?

Y

N

Y

N

进行优先处理

x

x

X

作其他处理

x

x

2.NextData函数的精简决策表

M1={月份, 每月有30天}

M2={月份, 每月有31天}

M3={月份,2月}                 有29=512条规则

D1={日期,1~28}                 12月末31日和其它31

D2={日期,29}                    日月份的31日处理不同

D3={日期,30}                    平年2月28日处理不同

D4={日期,31}                    于2月27日

Y1 ={年:年是闰年}

Y2 ={年:年不是闰年}

改进为

M1={月份: 每月有30天}

M2={月份: 每月有31天,12月除外}

M4={月份:12月}

M3={月份:2月}

D1={日期:1<=日期<=27}

D2={日期:28}

D3={日期:29}

D4={日期:30}

D5={日期:31}

Y1 ={年:年是闰年}

Y2 ={年:年不是闰年}

输入变量间存在大量逻辑关系的NextData决策表

3. 用决策表测试法测试以下程序:该程序有三个输入变量month、day、year(month、day和year均为整数值,并且满足:1≤month≤12和1≤day≤31),分别作为输入日期的 月份、日、年份,通过程序可以输出该输入日期在日历上隔一天的日期。例如,输入为2004年11月29日,则该程序的输出为2000年12月1日。

1)分析各种输入情况,列出为输入变量month、day、year划分的有效等价类。

2)分析程序规格说明,结合以上等价类划分的情况给出问题规定的可能采取的操作(即列出所有的动作桩)。

3)根据(1)和(2),画出简化后的决策表。

案例分析如下:

1)month变量的有效等价类:

 M1: {month=4,6,9,11}

 M2: {month=1,3,5,7,8,10}

M3: {month=12}

 M4: {month=2}

2)day变量的有效等价类:

    D1:{1≤day≤26}         D2: {day=27}         D3: {day=28}                    D4: {day=29}                    D5: {day=30}                D6: {day=31}

3)year变量的有效等价类:

Y1: {year是闰年}                Y2:  {year不是闰年}

4)考虑各种有效的输入情况,程序中可能采取的操作有以下六种:

a1: day+2                       a2: day=2                    a3: day=1

a4: month+1                     a5: month=1                  a6: year+1

4. 判定表在功能测试中的应用

1)一些软件的功能需求可用判定表表达得非常清楚,在检验程序的功能时判定表也就成为一个不错的工具。如果一个软件的规格说明指出:

I. 当条件1和条件2满足,并且条件3和条件4不满足,或者当条件1、3和条件4满足时,要执行操作1。

II. 在任一个条件都不满足时,要执行操作2。

III. 在条件1不满足,而条件4被满足时,要执行操作3。 根据规格说明得到如下判定表:

这里,判定表只给出了16种规则中的8种。事实上,除这8条以外的一些规则是指当不能满足指定的条件,执行3种操作时,要执行1个默许的操作。在没必要时,判定表通常可略去这些规则。但如果用判定表来设计测试用例,就必须列出这些默许规则(如下表)。

规则5

规则6

规则7

规则8

条件1

N

Y

Y

条件2

Y

Y

N

条件3

Y

N

N

N

条件4

N

N

Y

默许操作

x

x

x

x

默许的规则

2)判定表的优点和缺点

I.  优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。

II. 缺点:不能表达重复执行的动作,例如循环结构。

3)B. Beizer 指出了适合使用判定表设计测试用例的条件:

①规格说明以判定表形式给出,或很容易转换成判定表。

②条件的排列顺序不会也不影响执行哪些操作。

③规则的排列顺序不会也不影响执行哪些操作。

④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。

⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。

正交实验设计方法

一.方法简介

利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人,给软件测试带来沉重的负担,为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。

正交实验设计方法:依据Galois理论,从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.

利用正交实验设计测试用例的步骤:

1.提取功能说明,构造因子–状态表

把影响实验指标的条件称为因子.而影响实验因子的条件叫因子的状态.利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个因子的取值当作状态.对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求.这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据.确定因子与状态是设计测试用例的关键.因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。

2.加权筛选,生成因素分析表

对因子与状态的选择可按其重要程度分别加权.可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小。

3.利用正交表构造测试数据集

正交表的推导依据Galois理论(这里省略,需要时可查数理统计方面的教材)。

利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率。

功能图分析方法

一.方法简介

一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例. 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。

(功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的.)

1.功能图

功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置(或时间),而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.例,一个简化的自动出纳机ATM的功能图。

2.测试用例生成方法

从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试用例.若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题(如白盒测试)问题了.

3.测试用例生成规则

为了把状态迁移(测试路径)的测试用例与逻辑模型(局部测试用例)的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移(SST)中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.(其表示图形省略)。

4.从功能图生成测试用例的过程

1)生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。

2)测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径。

3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。

5.测试用例的合成算法:采用条件构造树.

场景设计方法

一.方法简介

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。

基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。

二.实战演习

1. 例子描述

下图所示是ATM例子的流程示意图

2.场景设计:下表所示是生成的场景。

表3-8 场景设计

场景1——成功提款

基本流

场景2——ATM内没有现金

基本流

备选流2

场景3——ATM内现金不足

基本流

备选流3

场景4——PIN有误(还有输入机会)

基本流

备选流4

场景5——PIN有误(不再有输入机会)

基本流

备选流4

场景6——账户不存在/账户类型有误

基本流

备选流5

场景7——账户余额不足

基本流

备选流6

注:为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。

3.用例设计

对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。

表3-9 测试用例表

TC(测试用例)ID号

场景/条件

PIN

账号

输入(或选择)的金额

账面

金额

ATM内的金额

预期结果

CW1

场景1:成功提款

V

V

V

V

V

成功提款

CW2

场景2:ATM内没有现金

V

V

V

V

I

提款选项不可用,用例结束

CW3

场景3:ATM内现金不足

V

V

V

V

I

警告消息,返回基本流步骤6,输入金额

CW4

场景4:PIN有误(还有不止一次输入机会)

I

V

n/a

V

V

警告消息,返回基本流步骤 4,输入 PIN

CW5

场景4:PIN有误(还有一次输入机会)

I

V

n/a

V

V

警告消息,返回基本流步骤 4,输入 PIN

CW6

场景4:PIN有误(不再有输入机会)

I

V

n/a

V

V

警告消息,卡予保留,用例结束

4.数据设计

一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。

测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。

表3-10     测试用例表

TC(测试用例)ID号

场景/条件

PIN

账号

输入(或选择)的金额

(元)

账面
金额(元)

ATM内的金额(元)

预期结果

CW1

场景1:成功提款

4987

809-498

50.00

500.00

2 000

成功提款。账户余额被更新为450.00

CW2

场景2:ATM内没有现金

4987

809-498

100.00

500.00

0.00

提款选项不可用,用例结束

CW3

场景3:ATM内现金不足

4987

809-498

100.00

500.00

70.00

警告消息,返回基本流步骤6,输入金额

CW4

场景4:PIN有误(还有不止一次输入机会)

4978

809-498

n/a

500.00

2 000

警告消息,返回基本流步骤4,输入PIN

CW5

场景4:PIN有误(还有一次输入机会)

4978

809-498

n/a

500.00

2 000

警告消息,返回基本流步骤4,输入PIN

CW6

场景4:PIN有误(不再有输入机会)

4978

809-498

n/a

500.00

2 000

警告消息,卡予保留,用例结束

错误推测方法

一.方法简介

1.定义:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

2.错误推测方法的基本思想:

列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

1)例如, 输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

2)例如,前面例子中成绩报告的程序,采用错误推测法还可补充设计一些测试用例:

I.程序是否把空格作为回答

II.在回答记录中混有标准答案记录

III.除了标题记录外,还有一些的记录最后一个字符即不是2也不是3

IV.有两个学生的学号相同

V.试题数是负数。

3)再如,测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:

I.输入的线性表为空表;

II.表中只含有一个元素;

III.输入表中所有元素已排好序;

IV.输入表已按逆序排好;

V.输入表中部分或全部元素相同。

测试用例设计综合策略

1.Myers提出了使用各种测试方法的综合策略:

1)在任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。 【文章来源:文斯测试技术研究中心http://blog.csdn.net/vincetest

2)必要时用等价类划分方法补充一些测试用例。

3)用错误推测法再追加一些测试用例。

4)对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例。

5)如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。

2.测试用例的设计步骤【文章来源:文斯测试技术研究中心http://blog.csdn.net/vincetest

1)构造根据设计规格得出的基本功能测试用例;

2)边界值测试用例;

3)状态转换测试用例;

4)错误猜测测试用例;

5)异常测试用例;【文章来源:文斯测试技术研究中心http://blog.csdn.net/vincetest

6)性能测试用例;

7)压力测试用例。

3.优化测试用例的方法

1)利用设计测试用例的8种方法不断的对测试用例进行分解与合并;

2)采用遗传算法理论进化测试用例;

3)在测试时利用发散思维构造测试用例。

原网页地址:http://blog.csdn.net/wanglilingb/article/details/54019467

总结:

通过这篇文章我更加详细的了解了测试用例的设计方法,对于测试用例有了更新的认识,这篇文章讲到的测试用例的设计方法有等价类划分方法、边界值分析法、因果图法、判定表驱动法、正交实验设计法、功能图分析法、场景设计法、错误推测法。这些方法我会在以后的工作中去尽量的尝试使用。

get与post方法的一些简单认识

        我们在工作过程中,有很多的时候在使用chrome的F12来进行抓包操作,去看一些具体的错误信息,便于开发来更好的定位问题。在过程中也很常见get和post请求。其实在HTTP协议中,这两种请求方法用的是最多的,但是很多时候我们并不清楚这两种请求的差别在哪,今天稍微谈一下。
        我们都知道HTTP协议是一种请求/响应式协议,过程是客户端来发送请求到服务器端,然后服务器返回响应到客户端,即完成了一次请求过程。可是用get也可使用post,或者其他方式。我们来做个比喻,把这个过程比喻成一辆越野车。出发点为客户端,终点站为服务器端。
get请求是所有的请求参数放在URL后面,?隔开,各个参数以&连接,这是所有人都能看到的,就相当于越野车出发时,把货物装在了车顶, 所有人一眼就看到装了什么,参数是什么。而在post请求时,我们会把所有需要执行的参数放在body里去做请求,这样呢就相当于越野车把货物装到了后备箱,人们并不能一眼看出请求的参数是什么,因为已经被后备箱(body)加了外衣。从安全的角度出发,post请求相对于get请求较为安全,因为参数是相对保密的,但是post的执行效率相对差一些。
但是从本质来讲,两种方式请求本质是一样的只是请求方式不一样,日常生活中,同样的get请求,我们可以从越野车车顶把一些货物放到后备箱来进行请求,同样的post请求也可以从后备箱把一些货物放在车顶来请求,这从本质来看是没有问题的,只是有些浏览器不支持这样而已。服务器端取值方式不同:get方式提交的数据,服务器端使用request.QueryString获取变量的值 而post方式提交的数据,服务器端使用request.Form获取数据

python webdriver环境搭建

环境搭建
准备工具如下:
————————————————————-下载 python【python 开发环境】
http://python.org/getit/
下载 setuptools 【python 的基础包工具】
http://pypi.python.org/pypi/setuptools
下载 pip 【python 的安装包管理工具】
https://pypi.python.org/pypi/pip

setuptools 是 python 的基础包工具,可以帮助我们轻松的下载,构建,安装,升级,卸载 python
的软件包。
pip 是python软件包的安装和管理工具, 有了这个工具, 我们只需要一个命令就可以轻松的python 的任意类库。

windows 环境安装
第一步、安装 python 的开发环境包,选择需要安装路径进行安装,笔者下载的是目前最新的
python2.7.5版本,安装目录为:C:\Python27。
第二步、安装 setuptools 通过前面提供的 setuptools 的连接,拖动页面到底部找到,
setuptools-1.3.2.tar.gz 文件(版本随着时间版本会有更新) ,对文件进行解压,找到 ez_install.py
文件,进入 windows 命令提示(开始–运行–cmd 命令,回车)下执行 ez_install.py:
C:\setuptools-1.3>python ez_install.py
如果提示 python 不是内部或外部命令!别急,去添加一下 python 的环境变量吧!桌面“我的电脑”
右键菜单–>属性–>高级–>环境变量–>系统变量中的 Path 为:
变量名:PATH
变量值:;C:\Python27
第三步、安装 pip ,通过上面提供的链接下载 pip-1.4.1.tar.gz(版本随着时间版本会有更新) ,我
默认解压在了 C:\pip-1.4.1 目录下,打开命令提示符(开始–运行–cmd 命令,回车)进入 C:\pip-1.4.1
目录下输入:
C:\pip-1.4.1 > python setup.py install
再切换到 C:\Python27\Scripts 目录下输入:
C:\Python27\Scripts > easy_install pip
第四步、安装 selenium,如果是电脑处于联网状态的话,可以直接在 C:\Python27\Scripts 下输入
命令安装:
C:\Python27\Scripts > pip install -U selenium

如果没联网,可以通过下载安装:
selenium 下载地址: https://pypi.python.org/pypi/selenium
下载 selenium 2.33.0 (目前的最新版本) ,并解压把整个目录放到 C:\Python27\Lib\site-packages
目录下。

测试是否安装成功:

在开始菜单找到 python 目录,打开 IDLE(python GUI)程序,启动的是一个
交互模式。可以输入:from selenium import webdriver

上面的命令为导入 selenium 的相关包,如果回车后没有报错表示我们的 selenium 安装是成功的。

需要学习更多,可以找我一起学习哦

自动化测试的学习方向

自动化测试是一个很广义的概念,一般说来所有能替代人工测试的方式都属于自动化测试,我们一般说的单元测试就是自动化测试的一种,单元测试很多人称之为“毫秒级的自动化测试”。

自动化测试是很难的,从某种意义上来说比性能测试更难。性能测试可以依仗的东西很多,比如LR等,而自动化测试的工具很多情况下只是一个半成品,比如selenium webdriver,你需要花很多时间去使用代码编写用例,并且维护这些用例,这一过程是漫长而艰辛的,特别对一些没有开发经验的测试同学来说,这个过程非常痛苦,每天的工作内容好像是自虐,而且自虐一段时间后信心基本崩溃,从此谈自动化色变,把所以的错归结于自动化测试策略与技术,而不从本身去找问题。

不过相比于性能测试而言,自动化测试的实践者往往是更加幸运的。最简单的例子是一般的性能测试人员离开了工具基本上就无所作为了,而自动化测试人员则可以利用自己掌握的语言知识与代码知识自己创造工具,说实在的,这是一件很有成就感的事情,乙醇自己就在写工具,从简单的cli工具到复杂的web工具,一切都是托以前自动化测试实践的福。
自动化测试很难,那么我们为什么要坚持自动化呢?
单元测试是保证代码质量最基本也是最根本的途径,单元测试是自动化测试的一种,因此自动化的重要性不言而喻;
集成测试在很多情况下非常适合使用自动化的手段去运行,最明显的例子是rails里的integration test;
当你的单元测试和集成测试都没做好,甚至是没有做的情况下,UI级的自动化测试可以扮演救火队员的角色,尽管成本很高,但是可维护的UI测试代码是回归测试的福音,也是提高测试生产力的重要手段;
自动化测试可以培养团队,一个团队如果可以把自动化测试做好,那么他们的开发水平一定不低,而且如果这些人去做开发,代码的质量反而比一般的开发人员要高,原因很容易理解,测试人员坚信没有测试过的东西就是不可信的,代码如果没有被测试过,那么代码自然是不可信的,不可信的代码就需要用单元测试去覆盖,因此这可以从根本上提高代码的质量。
下面是一下学习自动化测试应注意的问题,由大神总结,我摘过来的
一:大神,帮帮忙啊,救命啊,老是搞不定啊
这句话我经常看到,一般来说有时间的话,我会教你怎么去解决这个问题。不过几天后,类似的问题出现了,你还是解决不了。首先,大神很忙。有些大神愿意分享,他们贡献的资料很多,但是,你不查,你不看,你总是认为”不耻上问”最直接,但大神帮你解决问题的同时又增加了你的惰性和依赖性,结果你进步的很慢,一直没有自信,后来问题太多,直接放弃。
遇到问题不要害怕,去网上搜一下,很多人会遇到同样的问题,大概看一下别人怎么解决的,然后自己举一反三,不仅解决了问题,而且还能有所进步,这才是正道。
后来有人问我问题,我一般的回答是”去网上搜一下XXXX”,不是我不愿意帮你,我是在教你,无论做什么事,最后你只能靠自己。
一般遇到这种节奏的人学习能力恐怕是不强的,如果自动化测试交给这些人来做,那么作死是可以预期的到的。
提高自己的学习能力与纠错能力,遇事不慌,有一套比较好的解决问题的方法,坚持下去,慢慢的改进,慢慢的提升自己,这样就可以了。

二:我看了,这些代码我都看过了,但是这个项目到底怎么做啊
这是典型的光说不练。有一本书叫做webdriver实用指南,里面有很多代码,涵盖了ruby/python/java/watir-webdriver等。有人一再问我书里面提到的问题,我的回答总是:”这些代码你敲过了吗?”,答曰:”没,但是我有看过了”。对此我只能哭笑不得,看过不等于做过,自动化测试项目说白了就是代码实践,光看不写是学不会堆代码的。因此,在做项目的时候,一定要多做,别只是在收集别人的意见,比如”你觉得我这个项目适合做自动化吗?”, “我应该用什么工具做自动化啊?”,别人总是旁观者,只有你亲自实验得出的结果才是准确的,不要把别人的意见当作圣旨箴言,自己实践才是第一要务。
对于自动化测试,我的理解是先把代码敲熟练了。如果一个工具或者代码不能掌握到得心应手的程度,那么做起项目来应该是困难重重的。还有,自己多写代码,多去理解错误提示,很多问题你自己就能顿悟了,不要遇到一点点小问题就去问别人,别人不但不会帮你,也许心里还会鄙视你,真的,我以前就被鄙视过。
看过不等于做过,这点很重要。就算你看过岛国所有一线女优的片子,但如果没做过的话,你仍然只是个可怜的处男,连逆袭的机会都没有。

三:大神,为什么出错了啊
这是太言简意赅了。我很想帮你,但是在帮你之前我会先问一串:”你用的是什么工具,什么操作系统,什么编程语言之类”,当然了,这是在我心情好的时候,有时候心情不爽,直接拉黑,整个世界就清静了。提问是有艺术的,把问题描述清楚,别人才好去帮你,不然没人会理你。然后你感到自己被忽略了,然后你伤心了,然后你吐槽了,然后你无力吐槽了,最后你放弃了。一样的作死的节奏。其实,只要你把问题描述清楚,然后去网上搜索一下,基本就能得到答案。记住,google是你最好的朋友,大神不是。

四:我只要会xxx语言就可以了,其他的语言不需要
理论上这是正确的,但是语言说白了还是工具,在做一件很复杂事情的时候,单一的工具往往是难以很好的完成任务的。任何语言都有其擅长的部分,不擅长的地方,取长补短才是王道。我用过很多的语言,但是在做前端UI自动化的时候,我发现ruby+watir webdriver很方便,于是一直用,项目一直在做,几年了都没失败。但如果当年用的是java的话,我估计我们的产品在改版几次以后,这个自动化项目就要寿终正寝了。多学一点语言其实没坏处,不过如果你选择专注,那么你有你的道理,你可以坚持,没人会责怪你。

稍微总结一下自动化应该怎么做。

原则一:能力使然
这个能力是指的综合能力。首先你要会测试,自动化测试毕竟是在用代码写用例。其次你要会写代码,你要把用例翻译成代码。不要迷信于录制回放工具,光用这个基本上做不成项目。而且会录制回放对你来说也没什么意义,任何一个人学习个一天一定能学会录制回放。做自动化测试实际上是对自身能力一个很好的提升,一定要抓住这个机会,不要去弄没啥技术含量的录制回放,学会了有什么用,大家都会录,凭什么让你录。
做自动化测试其实挺难的,会有很多困难,毕竟前端UI的东西是最容易变化的,但是如果你能力足够强大的话,这些变量对你来说总会有办法去克服。比如UI老是变,就可以封装一些page object的思想,让UI修改变得容易一些。还有用例老是跑出错,不如在代码里加入自动截图,一眼就能定位问题,代码维护起来自然就容易不少。
没有一个成功的自动化项目是菜鸟做成功的,当你做成功了一个项目以后,你自然就从菜鸟变成了高手。

原则二:不变应万变
UI总是在变,比孙悟空还会变。但是在变的过程中一定有一些东西是不变的,我们做自动化测试的时候要尽量用这些不变的东西。比如表单元素的name,一般不会频繁变动,相对稳定。另外数据是会变的,比如你进入一个工单的列表页面,有时候会有10条数据,有时候会有20条。有时候第一条数据的内容是A,有时候是B,这是因为数据在变化,这时候你只要让数据能固定住,这样进入工单列表后一定只有10条数据,第一条数据永远是A,那么你的用例写起来自然是神清气爽,难度不高,也容易维护。

原则三:团结一切可团结的力量
对我来说,很多时候我总是一个人在战斗。开发努力改一个迭代,改出若干新功能和若干bug,然后我更新对应的自动化用例。因为我的框架扩展性还不错,所以开发改两周的UI,我两天就能改完,不过如果老是我一个人在改,那么我一定会非常孤独吧。这时候不如让手工测试人员帮我一起改,对他们来说自动化是福音,能节约其回归的时间,所以改用例对他们来说是很有必要的一件事情,然后我教他们怎么改,他们学会了以后我就可以放手去做其他事情。现在我已经基本不做自动化了,原因就在这里,有人帮我做,而且比我更有动力去做。

原则四:把成果展示出来
我专门写了个报告平台来展示自动化的测试报告。一定要让团队成员知道你在干什么,报告是最简单的途径。成功的项目一定有很不错的报告,这点不容置疑。

原则五:可维护的代码
代码要容易读,容易改。看看我写的lazyman框架里的示例代码吧,再看看原生的webdriver代码,你应该会有所感触。记住,原生的webdriver代码一定是不太好维护的,没有框架支持和封装,原生的webdriver代码一般很难规模化,很难达到成百上千个用例的规模。好的框架可以使你事半功倍,不要迷恋原生代码,可以用,但不够用。

最后是学习路线

1.学习python基本语法。

2.上w3cschool这个网站,学习HTML/CSS下的html、xml、webservice三个教程。

3. 然后下一个python的requests库学习写最简单的网络爬虫。知乎上爬虫教程一大堆。3是第一个里程碑,学写简单爬虫一方面有一定的成就感,一方面又知道了接口到底是怎么回事。同时还学到了怎么解析一个页面。

4.学习python的测试框架unittest,知道怎样用unittest和python的mock模块写一个小单元测试。

5.把3和4结合起来,你掌握http自动化接口测试。

6.学selenium的库和页面对象模式

7.把2、4、5、6结合起来,你应该能写既支持web测试又支持接口测试的自动化测试脚本了。

8.学robotframework,你可以把自动化测试变成关键字驱动和数据驱动的了。

9.学python的高级一点的语法。如装饰器、线程进程协程。你可以让测试并行执行,并自动记录测试步骤到log文件里了。

10.学jenkins,测试不再需要你手工去启动了。测试也可以分步式运行到多个环境上了。

11.学docker、git、gitlab等的简单使用,从此测试脚本不用再人肉更新、测试环境也不用人工搭建。这里也要学linux的简单使用,

12.回到w3cshool,学习javascript、ajax、jquery、bootstrap。至此你可以写50%以上简单网站的前端了。

13.学习python的flask库,学mysql或mongodb是怎样和flask一起用的。至此你可以写简单网站的后台了。你还可以快速开发webservice接口了。

14.综合12和13,你可以开发一些测试管理工具了。比如写一个管理很多jenkins master的ci调度平台。也可以写一个提供统一样式的测试报告的web展示平台。写一个监控所有测试情况的看板。写帮你生成测试文档的脚本。写测试环境的管理工具。

并且14是一个里程碑,你可以理解开发人员的一些思路了,比如为什么开发人员老是不愿意好好写单元测试、老是说这不是bug、老是说几点干完但却拖到半夜还做不完,特别是你做的东西交给别人测的时候。你也可以理解web测试的接口测试、单元测试怎样做比较好,因为如果不好,你是不愿意用到自己写的网站工具上的,你会觉得浪费时间。

15.学压测工具locust、jmeter等,7里写的框架可以支持压力测试了。同一套接口测试脚本,既做自动化测试又做压测了。

16.想做app测试的话,学一个appnium之类的框架。

17.补课时间,好好把计算机网络补起来,这个是真有用

18.java补起来。没办法,用java的单位多。要找工作机会也多。现在流行java+python都要会。其实都差不多,举一反三。

19.不知道后面再怎么学了。再提高提高web开发能力。前端框架学一个,以后开发一些更漂亮更炫的前端页面。再学下什么消息中间件之类的

这些步骤不用走完,写这些步骤的人也才到14,但是可以做个参考

白盒、灰盒、黑盒测试区别

什么是黑盒测试和白盒测试?

黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。

黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。

“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。

实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。

黑盒测试主要是为了发现以下几类错误:

1、是否有不正确或遗漏的功能?

2、在接口上,输入是否能正确的接受?能否输出正确的结果?

3、是否有数据结构错误或外部信息(例如数据文件)访问错误?

4、性能上是否能够满足要求?

5、是否有初始化或终止性错误?

白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检

查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。

第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。

第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。

灰盒测试,确实是介于二者之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

白盒测试主要是想对程序模块进行如下检查:

1、对程序模块的所有独立的执行路径至少测试一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性,等等。

灰盒测试,确实是介于二者之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

灰盒测试结合了白盒测试盒黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。

灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识盒与之交互的环境,能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

灰盒测试涉及输入和输出,但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

●黑盒测试有可能是动态测试(运行程序,只看输入和输出),也有可能是静态测(不运行程序,只是查看界面)

●白盒测试有可能是动态测试(运行程序,并分析代码结构),也有可能是静态测(不运行程序,只是静态查看代码)

●动态测试有可能是黑盒测试(运行程序,只看输入和输出),也有可能是白盒测(运行程序,并分析代码结构)

●静态测试有可能是黑盒测试(不运行程序,只是查看界面),也有可能是白盒测(不运行程序,只是静态查看代码)

以上事实说明,软件测试有一个致命的缺陷,即测试的不完全、不彻底性。由于任何程序只能进行少量(相对于穷举的巨大数量而言)的有限的测试,在未发现错误时,不能说明程序中没有错误。

APP与web测试的区别

测试流程

1.用一个手机先做冒烟测试;冒烟通过之后,先用一个android或者IOS做详细测试。
2.有时间测试之前应该写好测试用例,按照用例执行功能;没有时间写用例,也要一边测试,一边记录:你每走一个测试流程测试的是那个模块的什么功能。这样记录下已经测试的点,如果测试点没有通过的,要记录下,以便做回归测试重点关注。
3.详细测试:所有的功能都要走一遍(不管所有功能通没通过),第一轮就算测试完。并做好相应记录。这样可以直观看到,第一轮测试完成之后,剩余的bug情况。
4.第二轮测试,除了验证第一轮遗留的bug做回归测试之外,需要换一个手机测试,如果之前用的是IOS,这次改成android。所有功能再跑一遍。
5.测试完2轮,基本上bug就解决了有80%。然后再使用其他的手机做兼容性测试。如果时间不充分,也一定保证android与IOS一个必须每个测试一部手机。
6.如果时间充分,再使用其他的手机做一下主流程测试,保证兼容性没有大问题。
7.熟练使用抓包工具,看日志,查数据库,协助开发定位问题。
8.对爱学习系统整个流程熟悉,数据源知道怎么来,各个跟APP有关的功能,流程都要特别熟悉。
APP测试
1.功能
a.基本功能,主要指app是否完成了设计的所有功能。分清模块,写一份checklist,避免漏测。考虑横竖屏切换,不过很多app现在只支持竖屏。
b.UI测试
c.系统交互:电话短信干扰,低电量提醒,push提醒,usb数据线插拔提醒,充电提醒等,

2.App在经过功能测试后,也需对其进行适配兼容测试需要检查的项主要有以下几点:(a) 在不同平牌的机型上的安装、拉起、点击和卸载是否正常;

(b) 在不同的操作系统上的安装、拉起、点击和卸载是否正常;

我们在实际测试中,常常会遇到下列问题:

(a) 在某个平牌某个系统上,app安装不上;

(b) 在某个平牌某个系统上,app无法拉起;

(c) 在某个平牌某个系统上,app拉起后无响应或拉起后黑屏、花屏;

(d) 在某个平牌某个系统上,app无法顺利卸载;

3.性能:稳定性,兼用型(android碎片化是个难题,bug也多,ios相对bug少),app运行的内存消耗和cpu消耗,app后台长时间运行的耗流量,耗电量。
4.易用性:面是否吸引人、容易理解。界面整洁、简单。无错别字。点击范围确定等。这部分测试中,如果测试认为有不合理的地方通常会提交需求bug。
4.外场:网络切换,网络信号强,弱下的app运行情况。

APP与web的区别:

根据两者载体不一样,则区别如下:

  系统结构方面
  web项目,b/s架构,基于浏览器的;web测试只要更新了服务器端,客户端就会同步会更新。
  app项目,c/s结构的,必须要有客户端;app 修改了服务端,则客户端用户所有核心版本都需要进行回归测试一遍。
(1)web项目:
  1. 浏览器(火狐、谷歌、IE等)
  2. 操作系统(Windows7、Windows10、Linux等)
(2)app项目:
  1. 设备系统:iOS(ipad、iphone)、Android三星华为、联想等) 、Windows(Win7、Win8)、OSX(Mac)
  2. app考虑的是不同手机型号、厂家、分辨率和屏幕大小,系统等。
相对于 Wed 项目,APP有专项测试
  1. 干扰测试:中断,来电,短信,关机,重启等
  2. 弱网络测试(模拟2g、3g、4g,wifi网络状态以及丢包情况);网络切换测试(网络断开后重连、3g切换到4g/wifi 等)
  3. 安装、更新、卸载
  安装:需考虑安装时的中断、弱网、安装后删除安装文件等情况
  卸载:需考虑 卸载后是否删除app相关的文件
  更新:分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新
  4. 界面操作:关于手机端测试,需注意手势,横竖屏切换,多点触控,前后台切换
  5. 安全测试:安装包是否可反编译代码、安装包是否签名、权限设置,例如访问通讯录等
  6. 边界测试:可用存储空间少、没有SD卡/双SD卡、飞行模式、系统时间有误、第三方依赖(QQ、微信登录)等
  7. 权限测试:设置某个App是否可以获取该权限,例如是否可访问通讯录、相册、照相机等
闪退,卡死。

网络种类多

移动端有多种网络:无线网络、2G、3G、4G等,断网、网速较差及网络之间的切换时页面的显示等,这些对于移动端来说很重要。此外,在非wifi下,还需要注意网络使用量问题。

中断测试

移动端有一个很重要的问题,一般情况下在使用软件的过程并不是长久的,这中间可能发生很多中断,如电话、短信、通知、断电等等,软件

需要特殊处理这些特殊情况。
打开一个页面,或在操作的过程中(点击一个按钮后),将手机屏幕锁住,再打开时,应用能否正常处理。

1. 来电中断: 呼叫中断, 被呼叫挂断,通话挂断,通话被挂断

2. 短信与消息中断: 接受短信, 查看短信使用app过程中,有短信或者扣扣微信等消息

3. 其他中断: 蓝牙,闹钟,插拔数据线, 手机锁定, 手机断电, 手机问题(系统死机, 重启)

4.异常测试:

4.1对app断网测试,断电测试

4.2服务器异常测试

5.内存泄漏测试

5.1使用内存比较少的手机进行测试,看是否出现内存泄漏(导致闪退等)

9.2打开app挂在后台,去进行他操作,再次回来,看是否资源被回收(导致闪退等)

屏幕的限制

图片及文字的显示;上传不同的图片尺寸显示是否正常;图片和文字一起显示时,效果如何。
操作区域;web端的应用,一般不会受 到屏幕的限制,而且通过鼠标操作更加准确。但是移动端由于屏幕较小,页面及按钮会受到屏幕大小的限制,再加上用户都是通过手指进行操作,一些按钮、选择框 等是否容易点击,多个可点区域位置较近时,点击部位稍微偏移,也许就会造成不同的结果,这种情况下是否可以达到预先的效果。

 

软件启动运行

移动端启动、卸载、升级几个特性,这是比较常见、也很重要的,比如升级时用户的数据怎么办,卸载后用户的数据怎么处理,卸载再安装用户登录数据的显示等。

升级测试

从上一个版本/上两个版本直接升级到最新版。

全新安装最新版

新版本覆盖旧版本安装

卸载旧版本, 安装新版本

卸载新版本, 安装新版本

增量更新

强制更新

 

测试点在于:  升级之后, 已经登录的用户,是否仍处于登录的姿态,  用户的缓冲文件, 配置文件是否还在。

安装和卸载测试:

1.1从开发给的地方获取包进行安装,看是否可以正常安装

1.2通过第三方软件转发安装包,进行安装看是否可以正常安装

1.3上线后,在应用商店下载,看是否可以安装

1.4安装后,直接卸载,看是否可以正常卸载

1.5安装后,利用第三方工具,看是否可以卸载

软件启动运行

移动端启动、卸载、升级几个特性,这是比较常见、也很重要的,比如升级时用户的数据怎么办,卸载后用户的数据怎么处理,卸载再安装用户登录数据的显示等。

手势

移动端还有一大特性,就是移动端有自己比较简单的手势,用户可以通过手势进行一个操作,比如左滑删除、右滑返回上一个页面、左右滑动图片等,软件需要对这个手势进行适配。

多点触控,

事件触发区域

测试的时候还要注意手势,横竖屏切换,多点触控,事件触发区域等测试。

以上是我个人观点,如有差别,欢迎指正.

APP测试要点

APP测试要点
APP测试的时候,建议让开发打好包APK和IPA安装包,测试人员自己安装应用,进行测试。在测试过程中需要注意的测试点如下: 1.安装和卸载
●应用是否可以在IOS不同系统版本或android不同系统版本上安装(有的系统版本过低,应用不能适配)
●软件安装后是否可以正常运行,安装后的文件夹及文件是否可以写到指定的目录里。
●安装过程中是否可以取消
●安装空间不足时是否有相应提示
●如果应用需要通过网络验证之类的安装,需要测试一下断网情况下是否有相应提示
●是否可以删除应用(可通过桌面删除,也可以通过软件卸载安装。曾发现在IOS手相上有个应用安装时未完全安装,终止安装后,未完成安装的应用图标一直显示在手机上,并且无法成功删除)
●测试卸载后文件是否全部删除所有的安装文件夹
●卸载过程中出现死机,断电,重启等意外的情况,待环境恢复后是否可以正确卸载
●卸载是否支持取消功能,单击取消后软件卸载情况是否正常
2.运行
●APP安装完成后,是否可以正常打开软件
●APP运行时,是否有加载图示
●APP的速度是可以让人接受,切换是否流畅
●用户登录状态太久,sessionId会过期,会出现“虽然是登录状态,系统会提示用户没有登录。
 3.登录
●登录用户名和密码错误时,界面有提示信息
●用户主动退出登录后,下次启动APP时,应该进入登录界面
●对于支持自动登录的APP,数据交换时  ,是否能自动登录成功且数据库操作无误
●密码更改后,登录时是否做到了有效数据的校验
●对于未登录时一些页面的操作,是否做了控制
●切换账号登录,检验登录的信息是否做到及时更新
●对于多个端都进行操作时,确保数据库操作无误,且每个端可以及时看到数据的更新
●对于一些软件,支持一个账号只允许登录一台机器,这时,需要检查账号登录多个手机时,是否将原用户剔除,且能够给出提示信息
● APP切换到后台时,再次切换到前台的测试,如登录时,有电话打进来
●对于IOS与android不同设备登录同一个账号时,对个人信息等数据进行操作后,确保数据数库操作无误,且IOS与android设备看到的数据都是最新的。
 4.离线
  离线是应用程序在本地的客户端会缓存一部分数据以功程序下次调用
●对于一些程序,需要在登录进来后,这时没有网络的情况下可以浏览本地数据
●对于无网络时,刷新获取新数据时,不能获取数据且能给出友好提示
●切换到后台,再次切换到前台时,可以正常查看
●离线后又连上网,这时对数据有更新时,需要从服务器端获取新数据来更新客户端数据,且要更新本地缓存信息
●对于一些界面的数据不提供离线查看,需要给出相应提示且界面更新后无任何数据
●确认在无网情况下可以浏览本地数据
●确认退出APP再开启APP时能正常浏览
●确认切换到后台再切回APP应用时可以正常浏览
●锁屏后再解锁回到应用前台可以正常浏览
●服务端的数据有更新时有离线的提示
5.数据更新
●确认有数据更新后,哪些地方需要手动刷新,哪些地方需自动刷新。
●确认从后台切换回前台时,哪些页面需要进行数据更新
●根据需求和逻辑,确认哪些数据是从服务端请求实时响应,哪些是缓存到本地的数据。
 6.消息推送开关设置
●默认开关应该是全打开状态
●设置开关可以自由打开关闭
●设置开关打开状态下,消息推送是否可正常接收(应用启用中和应用关闭时都应该可以收到)
●确认后台未打开APP客户端时,手机消息栏可以接收到消息提醒。且点击可查看。点击后消息栏中消失
●确认APP客户端启动时,可以收到消息提醒,且点击可查看。客户端运行时,消息不会进消息栏。
●设置开关关闭时,客户端接收不到消息推送。 7.软件更新
●当客户端有新版本时,有更新提示
●软件更新一定要测,确保android软件更新可以正确更新新版本,且安装运行正确。
●确保IOS软件更新会有限制,只有上了商店且有版本更新时才会测试,但是如果真有问题,再发现问题不点晚,可以让开发先在测试机上模拟一个地址进行测试。
●用户取消版本更新时,老版本可以正常使用,但是下次启动应用时,仍出现更新提示
●当有新版本时,不删除客户端的情况下,直接更新检查是否能正常更新,且更新后客户端的功能是否最新版本(正常来讲不用强制删除本地客户端可以正常更新)
8.异常测试
●没有内存空间时,APP能否正确响应
●APP运行中手机断电
●APP运行中断开网络
●反复操作某个功能,不断点击,刷新时,是否会闪退
●APP运行时拔打或接听电话
●APP运行时发送信息、收取邮件等
●多个APP运行时
●不断切换前台和后台,是否影响应用正常功能
●APP运行时,启动相机功能
9.网络环境
●测试2G、3G,4G,wifi 网络下应用运应的速度
●内网测试时,选择到外网操作是否有异常处理
●网络不好时 , 提交数据是否一直处理提交中,是否会有延迟,数据交换失败是否会有提醒
●有网到无网再到有网环境时,数据是否可以自动恢复,正常加载
10.其它
●接口测试。让开发提供一份接口文档,一定要将接口测试通。在接口测试阶段,将缺少接口,接口不完善的缺陷挖掘出来。这个需要准备充分的后台数据。
●导航测试。在运行APP时,不管在哪个接点,导航是否直观,精准,页面切换是否正确。
●图片测试。图片,按钮是否自适应。
●内容测试。要进行超长字符,空字符校验且校验是否有错别字
●功能测试。功能是否实现。
●易用性测试。所开发的功能,是否让用户容易接受,是否符合大众的操作习惯。
●适配性测试。应用在不同设备,不同系统上是否适配。
●UI测试。应用的设计是否够美观。
总结:
这篇文章加强了我对APP测试的认识,让我更加深刻的认识了APP测试的测试点。我会在以后的测试中尽可能的去全面考虑测试点。认真分析每个可能出现问题的点。

接口测试

我们常说的api就是接口的意思,现在常用的web项目,app项目的接口都是基于http请求的,有些系统内部之间调用的接口一般不需要我们测试,这些很多是基于jar包那种类型的接口;

1.接口类型常见的有get,post,put…类型。get类型的接口一般是指获取信息的接口,比如列表查询的功能,点击查询按钮就调用一个get接口,然后把信息返回出来。就是指把内容从服务器拉下来。post类型一般是提交表单的功能,比如注册、上传、发布帖子之类的就是post接口。就是指把内容推到服务器上去。

2.接口测试的流程是:1)测试接口文档。2)根据接口文档编写测试用例(用例编写方法完全可以按照黑盒测试的用例编写规则来编写,如:边界值、正交表等等设计方法)。3)执行测试,查看接口返回的接口数据是否正确,主要检查返回的接口是否和接口文档中定义的一样,还有要检查返回的数据是否和数据库中的保持一致。

3.get型的接口可以直接通过浏览器访问,参数就带在地址的后面以‘?’连接。但是post的就不行了,要用专门的工具来测试,常用的推荐jmeter。

4.post型的接口

首先查看接口文档:
例如:根据接口文档可知,接口实现一个更新用户昵称的功能,由此可以开始设计测试用例。userId和ickName均不为空,测试输入类型,测试更新成功后再数据库中是否同步更新。jemter中操作如下图:

  IMG_1772

  IMG_1773

第一张图片的设置content-type为application/json是因为接口文档中要求如此。如果没要求,可以不用添加HTTP信息头管理器。因为要求的是json格式的传参,所以post的参数要在(图二)body Data中以json格式书写。

(转)面向开发的测试技术:面向开发的测试技术

(原文链接:https://juejin.im/post/5919c6c10ce4630069002339)

1 QE的成人礼:从功能测试到自动化测试

自动化测试是很接近传统功能测试(也即手工测试)的一种测试技术,也可以说是区分QE和QA的分水岭。而Web自动化测试作为最常见的一类自动化测试,相关的资料和工具也是最丰富的。

2 自动化测试的利弊

在介绍具体的Web自动化测试技术之前,首先看一下自动化测试和功能测试的区别。在我看来,两者最大的区别在于测试人员身份的不同。在功能测试中,测试人员既要设计测试用例,又要运行手工测试,既是导演又是演员,既是教练又是球员。而在自动化测试中,演员和球员的角色都被机器所取代,测试人员只负责设计测试用例和编写自动化测试脚本。除此之外,相对于功能测试,自动化测试的不同还包括:

2.1 自动化测试的优势

  • 更快的测试速度,带来更高的测试效率。一般而言,运行一遍功能测试都要以小时为单位,有的甚至以天为单位。而自动化测试则一般都在分钟级别,如果运行在分布式环境下,甚至可以降到秒级。由此可见,通过自动化测试,测试人员可以省去大量的手工测试时间,从而有更多时间去熟悉业务和完善测试用例,在提高自身测试效率的同时,也有助于提升整体的软件质量。
  • 提高测试覆盖率。要理解这一点,首先要从正交测试法说起。假设一个测试场景涉及3个测试因素,每个测试因素有3种可能的取值(水平),那么根据正交测试法,总共需要设计8个(因素数*(最大水平数-1)+1)测试用例。测试场景越复杂,所需的测试用例越多。当测试场景的复杂度超过一定程度后,纯手工的功能测试显然就无力覆盖所有的测试用例了,并且随着复杂度的升高,测试覆盖率会越来越低。然而,借助自动化测试脚本,无论测试场景多复杂,都能保证一定的测试覆盖率。
  • 更好的稳定性和可扩展性。功能测试靠人,自动化测试靠机器,因此,无论是运行测试的稳定性,还是测试能力的可扩展性(比如从测试1个应用变为测试10个应用),自动化测试都远超功能测试。 

    根据上面的描述,你就不难推导出自动化测试适用的测试场景了:

    • 回归测试。每一次应用发布,都伴随着一次回归测试。对于重复性的工作,机器显然更适合。
    • 兼容性测试。不管是Web测试,还是App测试,兼容性测试都是必不可少的一环。以Web测试为例,同样的测试用例,需要在不同的浏览器上分别运行一遍,这对测试人员而言不可谓不是一种折磨。
    • 大规模测试。如果一次测试涉及的测试用例过多(比如100+),功能测试难免会有遗漏或者重复,而自动化测试可以轻松确保一个不少,一个也不多。

    一图以蔽之,自动化测试的优势可概括为下图:

2.2 自动化测试的局限

说了这么多自动化测试的好处,但自动化测试也不是万能的,再来看一下它的局限所在:

  • 不低的技术门槛。不论是使用哪种自动化测试框架,对于测试人员而言,都存在一定的技术门槛,一般至少需要学习并掌握一门编程语言。
  • 可观的开发成本和维护成本。跟任何程序一样,无论是编写自动化测试脚本,还是在需求变化时修改脚本,都需要花费大量的时间。
  • 需求要稳定。自动化测试的前提是测试用例要稳定,而测试用例稳定的前提是需求要稳定。对于临时的或者说一次性的需求,自动化测试往往是得不偿失的。
  • 应用周期长。应用的生命周期越长,自动化测试节省的时间越多,带来的价值也越大。

应该说,功能测试是自动化测试的基础,自动化测试是功能测试的补充,两者相互依赖,又相互促进。测试人员两手都要抓,两手都要硬。

3 如何进行Web自动化测试?

接下来我以Selenium为例,介绍一下如何进行Web自动化测试。

3.1 Selenium简介

Selenium是目前最流行的Web自动化测试框架之一,支持主流的浏览器和操作系统,同时支持多种编程语言接入。无论是测试,还是开发,都可以轻松上手。最新的版本是3.4.0。

同类的Web自动化测试框架还有:

图片出处:www.edureka.co/testing-wit…

组成

  • Selenium IDE: 一款Firefox插件,以图形化方式支持录制脚本、自动生成脚本等功能。用于本地开发和调试TC(Test Case)。
  • Selenium WebDriver: 通过各浏览器厂商提供的原生Driver,指挥浏览器进行各类页面操作。

图片出处:Join the darkside: Selenium testing with Nightwatch.js

  • Selenium RC(已废弃): 通过植入统一的JS脚本,指挥浏览器进行各类页面操作。兼容性比较差,2.0以后已废弃。
  • Selenium Grid: 适用于分布式环境下运行大量的TC,Hub根据TC的环境要求分发给各个符合条件的Node执行。

图片出处:Join the darkside: Selenium testing with Nightwatch.js

特性

  • 多浏览器支持:除了三大浏览器Firefox, Chrome, IE之外,还支持Android, iOS内置的浏览器。
  • 多平台支持:三大操作系统Linux, Mac, Windows上面都可以运行。
  • 多语言支持:可以用Python, Java, Node, Ruby等编写TC。
  • 录制脚本(仅限IDE):记录Firefox上的各类页面操作,自动生成HTML格式的TC。
  • 自动生成脚本(仅限IDE):将录制的HTML格式的TC转化成任意其他语言的TC。
  • Headless:支持在命令行下,执行各类TC脚本。
  • 分布式支持:通过Selenium Grid将TC分发到各个节点执行。

3.2 入门:Selenium IDE

首先安装Firefox,然后下载Selenium IDE插件。通过Firefox的Tools->Selenium IDE菜单项可以启动Selenium IDE,操作界面如下:

使用Selenium IDE生成自动化测试脚本的一般步骤是:

  1. 选择Action->Record菜单项或者点击右上角的小红点录制原始测试脚本
  2. 以调试模式运行脚本-查看日志-修改脚本直至脚本可以稳定的运行
  3. 保存测试脚本(仅限IDE运行)或者通过File->Export Test Suites As…菜单项导出其他语言的测试脚本(可在命令行下运行)

进一步信息可以参考官方文档

3.3 进阶:Selenium WebDriver

以Python3 + Firefox为例,

1) 命令行下运行pip install selenium==3.3.0安装selenium

  • 由于最新版的Selenium Python package不支持Grid,只能降级安装3.3.0版本

2) 下载Mozilla GeckoDriver,解压然后添加到系统Path

准备就绪后,打开命令行,试着运行之前从Selenium IDE导出的Python测试脚本,也可以直接手写脚本。

示例脚本:

from selenium import webdriver
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

browser = webdriver.Firefox()
browser.get('http://www.baidu.com/')
assert '百度一下,你就知道' == browser.title
kw = browser.find_element_by_id("kw");
kw.send_keys('selenium')
kw.send_keys(Keys.RETURN)

WebDriverWait(browser, 10).until(EC.title_contains('selenium_百度搜索'))
assert browser.find_element_by_css_selector("div.nums").is_displayed()
print("Test pass!")
browser.quit()

进一步信息可以参考官方文档Selenium Python API

3.4 高阶:Selenium Grid

前面提到,使用Selenium Grid可以轻松搭建一个分布式的自动化测试环境,特别适合运行大规模的测试用例和兼容性测试(各个节点运行不同的WebDriver)。

利用官方提供的Docker镜像,可以在本地启动多个容器来搭建一个Selenium Grid环境,以2个运行phantomjs WebDriver的节点的Grid为例:

  1. 启动Hub: docker run -d -p 4444:4444 –name hub selenium/hub
  2. 启动Node-1: docker run -d –link hub:hub –name pnode1 selenium/node-phantomjs
  3. 启动Node-2: docker run -d –link hub:hub –name pnode2 selenium/node-phantomjs

等所有容器成功启动之后,打开浏览器访问http://<ip-of-local-docker-machine:4444>,就可以看到Selenium Grid的控制台了。

然后修改测试脚本指向本地Selenium Grid的服务地址,就可以通过Selenium Grid运行测试了。

browser = webdriver.Remote(
    command_executor="http://192.168.99.100:4444/wd/hub", 
    desired_capabilities={'browserName': 'phantomjs'})
browser.implicitly_wait(30)

进一步信息信息参考官方文档Wiki

4 小结

现在开发和测试的边界变的越来越模糊,从原本上下游的依赖关系,逐步演变成你中有我、我中有你的互赖关系,甚至很多公司设立了新的QE(Quality Engineer)职位。和传统的QA(Quality Assurance)不同,QE的主要职责是通过工程化的手段保证项目质量,这些手段包括但不仅限于编写单元测试、集成测试,搭建自动化测试流程,设计性能测试等。可以说,QE身上兼具了QA的质量意识和开发的工程能力。所以测试人员具备一定的开发能力还是很有必要的。