2018-03-21 14:00:19 xqtesting 阅读数 16209
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158103 人正在学习 去看看 李晓鹏

 

 

1. 验收测试简介

1.1简介

验收测试即由产品开发方按照新浪提供的需求文档中所有内容(或按合同及其它有效约定,对方承诺实现的需求)进行开发、内测完毕,提交版本符合验收测试标准,通过新浪质量保证部进行的测试。通过验收测试判断产品质量是否符合产品需求,功能实现是否正确并可以最终上线。

1.2角色定义

验收提交方:产品研发方

验收接收方:新浪质量保证部

 

2. 验收测试目的

通过验收测试判断产品质量是否符合产品需求、功能实现是否正确,性能和安全性方面是否符合发布标准,并且产品可以最终上线。

 

3. 验收测试版本

3.1测试版本命名

提交验收测试的产品版本统一按如下格式命名:产品名称_版本_ATx 各部分释义如下:

产品名称:提交测试的产品名称,例如“易享收藏夹”(EasyShareFolder)

版本:提交测试的产品版本号,例如“1.0.1”

ATx:其中“AT”表示Acceptance testing;“x”表示提交验收测试的次数后,如1、2、3等

示例: EasyShareFolder_1.0.1_AT1(表示“易享收藏夹”第一次提交验收测试的版本)

3.2测试版本保存

每次提交验收测试的版本统一保存至新浪主体产品的版本库中,上线版本以验收测试通过版本为准。

 

4. 验收测试范围

4.1界面测试

所有页面浏览,连接的正确、所有功能按钮及界面显示正确

4.2功能测试

所有需求文档描述的功能实现正确

4.3性能测试

重点业务功能、性能能满足上线运营需求

4.4安全性测试

接口和数据调用等方面符合安全性规范;没有安全性漏洞

 

5. 验收测试流程

验收测试基本工作流程如下:

5.1. 准入条件检测

5.1.1文档

进入验收测试的文档准备齐全:

a) 验收版本的需求文档(提交方提供):要求需求文档与最终提交验收测试的程序完全匹配 ;

b) 验收版本的测试用例(提交方提供):要求测试案例覆盖最终版本的需求文档;

c) 验收版本的测试告(提交方提供):在测试报告书中说明测试总体情况,缺陷列表及修复情况;

5.1.2缺陷

要求开发方在WindowsXP IE6 /IE7/Firefox3.x兼容环境中(该兼容性需求会根据项目情况有变动,以新浪要求的为准),对需要文档上提及的所有功能进行全面测试,且提交验收测试时,开发方发现的所有缺陷都已解决。

5.1.3测试环境

验收测试环境准备完成,与线上真实环境一致

我方项目负责人负责测试环境控制,保证测试期间环境一致、稳定

5.1.4沟通和联系

1. 提交验收测试的开发方负责人联系方式及测试工程师联系方式齐全 ;

2. 提交验收测试缺陷的沟通渠道建立完毕,要求快捷、准确、反馈及时 ;

5.2 验收测试

5.2.1文档验收

进入标准:文档准备必须齐全且符合标准,可以进入文档验收流程

中断标准:

1. 需求文档并非最终版,需求文档上描述的功能程序并未实现

2. 测试用例与需求文档不匹配,测试用例中测试的模块在需求文档中不存在或者需求文档中的功能模块未在测试用例中体现

3. 测试报告书不完整,遗留缺陷不符合遗留缺陷允许限制的数量

退出标准:

文档符合标准并通过验收,进入程序验收流程

5.2.2程序功能验收

进入标准:文档验收流程结束

中断标准:

1. 出现 A,B级缺陷

2. C级缺陷达到3-10个(视项目大小而定)

3. 验收测试过程中,提交新的版本

退出标准:

验收测试合格,缺陷按照标准修复完成

通过标准:

要求验收测试结束后,未解决的缺陷达到以下要求时,才能验收通过:

a) A级缺陷:0个;

b) B级缺陷:0个;

c) C级缺陷:小于等于总缺陷数的3%;

d) D级缺陷:小于等于总缺陷数的5%个;

e) E级缺陷:小于等于总缺陷数的15%个。

注:对于放弃处理的提案,必须提前经过我方同意。

5.2.3验收完成

1.验收完成后质量保证部提交的文档:

a) 最终版需求文档

b) 提交方提供的最终版测试用例

c) 提交方提供的最终版测试报告

d) 质量保证部提供的最终版验收测试报告

2.验收完成后提交程序:

验收完成锁定的程序最终版本,要求保存至我方版本库中。

 

附录:缺陷级别定义

缺陷分为 A、B、C、D 、E 5个级别:

级别

说明

A级

操作系统崩溃

功能严重缺失

程序不能运行

B级

主要功能不能实现

程序崩溃

主要页面文字错误

调试信息没有清除

C级

功能实现与需求说明不符

功能不能实现但不影响使用

程序逻辑错误

用户使用严重不便

D级

功能实现但使用不便

提示信息不统一

界面布局不符合用户习惯

E级

提示信息文字错误

可商榷的页面布局

整体程序色调

 

2018-06-17 19:31:32 seagal890 阅读数 3007
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158103 人正在学习 去看看 李晓鹏

今天聊到测试的标准与规范,突然想到我们国家现在在软件评测和测试领域有什么强制性的标准和规范?

查了一些资料找到了两个规范:

国家标准:GB/T25000.51-2010 软件工程软件产品质量要求与评价(SQuaRE)商业现货(COTS)软件产品的质量要求和测试细则;GB/T16260-2003(ISO 9126-2001) 《软件工程产品质量》;验收测试依照需求说明书、项目建设合同等;技术鉴定测试的依据是用户需求规格说明书。

补充:

软件测试依据的国家技术标准规范主要有以下八个:

  • GB/T 17544-1998 《信息系统及软件完整性级别》
  • GB/T 16260-2006 《软件质量模型与度量》
  • GB/T 18905-2002 《软件工程产品评价》
  • GB/T 8567-2006 《计算机软件文档编制规范》
  • GB/T9386-2008 《计算机软件测试文件编制规范》
  • GB/T 25000.1-2010 《软件质量要求与评价(SQuaRE)指南》
  • CSTCJSBZ02 《应用软件产品测试规范》

学习一下。

2008-09-25 15:00:00 ahu201 阅读数 3121
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158103 人正在学习 去看看 李晓鹏
 

.概述... 1

软件测试理论... 2

1.什么是软件测试... 2

2.软件测试的目标... 2

.软件测试流程... 3

1.软件测试流程图... 3

2.软件测试流程细则... 4

3.软件测试注意事项... 5

.软件测试类型... 6

1.模块测试... 6

2.子系统测试... 6

3.系统测试... 6

4.验收测试... 6

.黑盒测试方法... 7

1.等价类划分... 7

2.因果图... 8

3.边值分析法... 8

4.猜错法... 8

5.随机数法... 9

.白盒测试方法... 10

1.语句覆盖... 10

2.判定理盖... 10

3.条件覆盖... 11

4.判定/条件覆盖... 11

5.条件组合覆盖... 11

.测试错误类型... 12

.测试标准... 13

附录一 单元测试报告... 14

附录二 集成测试报告... 15

附录三 测试大纲... 16

附录四 测试大纲附录... 17

附录五 测试计划... 18

附录六 程序错误报告... 19

附录七 测试分析报告... 20

 

 

 

黑盒测试(blackbox testing)又称功能测试、数据驱动测试或基于规范的测试(eccationbased testing)。用这种方法进行测试时,被测程序被当作看不见内部的黑盒。在完全不考虑程序内部结构和内部特性的情况下,测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。因此黑盒测试是从用户观点出发的测试,黑盒测试直观的想法就是既然程序被规定做某些事,那我们就看看它是不是在任何情况下都做的对。完整的“任何情况”是无法验证的,为此黑盒测试也有一套产生测试用例的方法,以产生有限的测试用例而覆盖足够多的“任何情况”。由于黑盒测试不需要了解程序内部结构,所以许多高层的测试如确认测试、系统测试、验收测试都采用黑盒测试。

黑盒测试首先是程序通常的功能性测试。要求:

每个软件特性必须被一个测试用例或一个被认可的异常所覆盖。

用数据类型和数据值的最小集测试。

用一系列真实的数据类型和数据值运行,测试超负荷、饱和及其他“最坏情况”的结果;

用假想的数据类型和数据值运行,测试排斥不规则输入的能力;

对影响性能的关键模块,如基本算法、应测试单元性能(包括精度、时间、容量等)

不仅要考核“程序应该做什么?”还要考察“程序是否做了不该做的2同时还要考察程序在其他一些情况下是否正常。这些情况包括数据类型和数据值的异常等等。下述几种方法:(a)等价类划分,(b)因果图方法,(c)边值分析法,(d)猜错法,(e)随机数法,就是从更广泛的角度来进行黑盒测试。每一个方法都力图能涵盖更多的“任何情况”,但又各有长处,综合使用这些方法,会得到一个较好的测试用例集。

1.等价类划分

    等价类划分是一种典型的黑盒测试方法。等价类是指某个输入域的集合。它表示对揭露程序中的错误来说,集合中的每个输入条件是等效的。因此我们只要在一个集合中选取一个测试数据即可。等价类划分的办法是把程序的输入域划分成若干等价类,然后从每个部分中选取少数代表性数据当作测试用例。这样就可使用少数测试用例检验程序在一大类情况下的反映。

    在考虑等价类时,应该注意区别以下两种不同的情况:

有效等价类:有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合。在具体问题中,有效等价类可以是一个,也可以是多个。

无效等价类:无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。

确定等价类有以下几条原则:

如果输入条件规定了取值范围或值的个数,则可确定一个有效等价类和两个无效等价类。例如,程序的规范中提到的输入条包括“……项数可以从1999……”,则可取有效等价类为“l考项数<999,无效等价类为“项数<l,,及“项数>999”。

输入条件规定了输入值的集合,或是规定了“必须如何”的条件,则可确定一个有效等价类和一个无效等价类。如某程序涉及标识符,其输入条件规定“标识符应以字母开头……”则“以字母开头者”作为有效等价类,“以非字母开头”作为无效等价类。

如果我们确知,已划分的等价类中各元素在程序中的处理方式是不同的,则应将此等价类进一步划分成更小等价类。

输入条件

有效等价类

无效等价类

。。。。。。

。。。。。。

。。。。。。

。。。。。。

。。。。。。

。。。。。。

    根据已列出的等价类表,按以下步骤确定测试用例:

为每个等价类规定一个唯一的编号;

设计一个测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步,最后使得所有有效等价类均被测试用例所覆盖;

设计一个新的测试用例,使其只覆盖一个无效等价类。重复这一步,使所有无效等价类均被覆盖。这里强调每次只覆盖一个无效等价类。这是因为一个测试用例中如果含有多个缺陷,有可能在测试中只发现其中的一个,另一些被忽视。等价类划分法能够全面、系统地考虑黑盒测试的测试用例设计问题,但是没有注意选用一些“高效的”、“有针对性的”测试用例。后面介绍的边值分析法可以弥补这一缺点。

2.因果图

等价类划分法并没有考虑到输入情况的各种组合。这样虽然各个输入条件单独可能出错的情况已经看到了,但多个输入情况组合起来可能出错的情况却被忽略。采用因果图方法能帮助我们按一定步骤选择一组高效的测试用例,同时,还能为我们指出程序规范的描述中存在什么问题。

利用因果图导出测试用例需要经过以下几个步骤:

分析程序规范的描述中哪些是原因,哪些是结果。原因常常是输入条件或是输入条件的等价类。结果是输出条件。

分析程序规范的描述中语义的内容,并将其表示成连接各个原因与各个结果的“因果图”。

由于语法或环境的限制,有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况,在因果图上使用持殊的符号标明约束条件。把因果图转换成判定表。把判定表的每一列写成一个测试用例。

3.边值分析法

    边值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值,设计测试用例,包含全部边界值的方法。典型地包括IF语句中的判别值,定义域、值域边界,空或畸形输入,末受控状态等。边值分析法不是一类找一个例子的方法,而是以边界情况的处理作为主要目标专门设计测试用例的方法。另外,边值分析不仅考查输入的边值,也要考虑输出的边值。这是从人们的经验得出的一种有效方法。人们发现许多软件错误只是在下标、数据结构和标量值的边界值及其上、下出现,运行这个区域的测试用例发现错误的概率很高。

用边值分析法设计测试用例时,有以下几条原则:

如果输入条件规定了取值范围,或是规定了值的个数,则应以该范围的边界内及刚刚超出范围的边界外的值,或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例。如有规范“某文件可包含l255个记录……“,则测试用例可选12550256等。

针对规范的每个输出条件使用原则〔a〕。

如果程序规范中提到的输入或输出域是个有序的集合(如顺序文件、表格等)就应注意选取有序集的第一个和最后一个元素作为测试用例。

分析规范,尽可能找出可能的边界条件。一个典型的边值分析例子是三角形分类程序。选取abc构成三角形三边,“任意两边之和大于第三边”为边界条件。边值分析相等价类划分侧重不同,对等价类划分是一个补充。如上述三角形问题,选取a3b4c5a2b4c7则覆盖有效和无效等价类。如果能在等价类划分中注入边值分析的思想。在每个等价类中不只选取一个覆盖用例,而是进而选取该等价类的边界值等价类划分法将更有效,最后可以用边值分析法再补充一些测试用例。

4.猜错法

    猜错法在很大程度上是凭经验进行的,是凭人们对过去所作的测试工作结果的分析,对所揭示的缺陷的规律性作直觉的推测来发现缺陷的。

一个采用两分法的检索程序,典型地可以列出下面几种测试情况:

被检索的表只有一项或为空表;

表的项数恰好是2的幂次;

表的项数比2的幂次多1等。

猜错法充分发挥人的经验,在一个测试小组中集思广益,方便实用,特别在软件测试基础较差的情况下,很好地组织测试小组 (也可以有外来人员)进行错误猜测,是有效的测试方法。

5.随机数法

即测试用例的参数是随机数。它可以自动生成,因此自动化程度高。使用大量随机测试用例测试通过的程序会提高用户对程序的信心。但其关键在于随机数的规律是否符合使用实际。

 

 

 

 

.白盒测试方法

白盒法测试,是以程序的内部逻辑为基础,有选择地执行程序中最有代表性的通路。因此,白盒法也叫逻辑覆盖法(bgic MMe)。最彻底的逻辑覆盖法,是覆盖程序巾的诲一条通路。但当程序中含有大量循环时,要执行每一条通路是44可能的。因此,我们只能寄希望于程序的覆盖度尽可能高一些。目前常用的一些覆盖标准有:语句覆盖、判定覆盖、条件澄盖、判定涤件覆盖、条件组合覆盖、路径覆盖等。

白盒法考虑的是测试用例对程序内部逻辑的覆盖程度,所以又称为逻辑覆盖法。最彻底的白盒法是覆盖程序中的每一条路径,但这不可能,我们希望覆盖的路径尽可能多一些。为了衡量测试的覆盖程度,需要建立一些标准,目前常用的一些覆盖标准是:

(1)语句覆盖;

(2)判定覆盖;

(3)条件覆盖;

(4)判定/条件覆盖;

(5)条件组合覆盖。

1.语句覆盖

程序的某次运行一般并不能执行到其中的每一个语句,因此,如果某语句含有一个错误,而它在测试中没执行,这个错误就不可能被发现。为了提高发现错误的可能性,应该在测试时至少要执行程序中的每一个语句。

所谓“语句覆盖”测试标准,它的含义是:选择足够的测试用例,使得程序中每个语句至少都能执行一次。

例子:

Procedure Example(Var A,B,C:real)

begin

if(A>1)and(B=0)

then x:=x/A

if(A=2)or(x>1)

then x:=x+l

end;

为了使程序中每个语句至少执行一次,只需设计一个能通过路径ace的例子就可以了。例如选择输入数据为:

A=2B=0x=3

就可达到“语句覆盖”标准。

显然,语句覆盖是一个比较弱的覆盖标准。如果第一个条件语句中的and错误地写成or,上面的测试用例是不能发现这个错误的,或者是第二个条件语句中x>1误写成x>0,这个测试用例也不能暴露它。我们还可以举出许多错误情况是上述测试数据不能发现的。所以,一般认为“语句覆盖”是很不充分的最低的一种覆盖标准。

2.判定理盖

比“语句覆盖”稍强的覆盖标准是“判定覆盖”(或称分支覆盖)。这个标准是:执行足够的测试用例,使得程序中每个判定至少都获得一次“真”值和“假”值,即使得程序中的每一个分文至少都通过一次。

对上面那个例子,如果设计两个测试用例,就可以达到“判定覆盖”的标难。为此,我们可以选择输人数据为:

(1)A=3B=0x=l

(2)A=2B=1x=3

“判定覆盖”比“语句覆盖”严格,因为如果每个分支都执行过了,自然每个语句也就执行了。

3.条件覆盖

它的含义是:执行足够的测试用例,使得判定中每个条件获得各种可能的结果。

对于例子程序,我们只需设计以下两个测试用例就可满足这标准:

(1)A2Box4(沿路径ace执行)

(2)A1Blxl(沿路径aN执行)

虽然同样只要两个测试用例,但它比判定覆盖中两个测试用例更有效。一般来说,“条件覆盖”比“判定覆盖”强,但是,并不总是如此,满足“条件覆盖”不一定满足“判定覆盖”。例如对语句。

    IF(A AND B)THEN S

设计两个测试用例:A“真”B“假”和A“假”B“真”。对于上例我们设计两个测试用例为:

    (1)A1Box3

    (2)A2Blx1

亦是如此,它们能满足“条件覆盖”但不满足“判定覆盖”。

4.判定/条件覆盖

    针对上面的问题引出了另一种覆盖标准,这就是“判定/条件覆盖”,它的含义是:执行足够的测试用例,同时满足判定覆盖和条件覆盖的要求。显然,它比“判定覆盖”和“条件覆盖”都强。

    对于例子程序,我们选取测试用例:

    (1)A=2B=0x=4

    (2)A=1B=lx=l

它满足判定/条件覆盖标准。

值得指出,看起来“判定/条件覆盖”似乎是比较合理的,应成为我们的目标,但是事实并非如此,因为大多数计算机不能用一条指令对多个条件作出判定,而必须将源程序中对多个条件的判定分解成几个简单判定。这个讨论说明了,尽管“判定/条件覆盖”看起来能使各种条件取到所有可能的值,但实际上并不一定能检查到这样的程度。针对这种情况,有下面的条件组合覆盖标准。

5.条件组合覆盖

“条件组合覆盖”的含义是:执行足够的测试用例,使得每个判定中条件的各种可能组合都至少执行一次。这是一个最强的逻辑覆盖标准。

再看例子程序,必须使测试用例覆盖八种组合结果

(1)A>1B=0   (5)A=2x>1

(2)A>1B<>0  (6)A=2x<1

(3)A<lB=0   (7)A<>2x>1

(4)A<1B<>0  (8)A<>2x<1

必须注意到,(5)(6)(7)(8)四种情况是第二个条件语句的条件组合,而x的值在该语句之前是要经过计算的,所以我们还必须根据程序的逻辑推算出在程序的人口点x的输入值应是什么。

要测试八个组合结果并不是意味着需要八种测试用例,事实上,我们能用四种测试用例来覆盖它们:

(1)A2Box4

(2)A2B1xl

(3)AlBox2

(4)A1B1xl

上面四个例子虽然满足条件组合覆盖,但并不能覆盖程序中的每一条路径,可以看出条件组合覆盖仍然是不彻底的,在白盒测试时,要设法弥补这个缺陷。

 

 

 

 

附录一 单元测试报告

1  测试过程与结果

1.1 (某程序模块/文档名称)测试

测试对象:(某程序模块/文档)

测试方面:(设计规范/应用功能及流程/程序代码)

责任人:

测试人及测试时间:

问题及影响、处理结果:

1.2 (某程序模块/文档名称)测试

测试对象:(某程序模块/文档)

测试方面:(设计规范/应用功能及流程/程序代码)

责任人:

测试人及测试时间:

问题及影响、处理结果:

……

2  测试结论

对单元测试的结果评价。

 

   测试负责人:                          审核(项目经理):

                                               

 

 

 

 

 

附录二 集成测试报告

项目名称

 

项目编号

 

测试人

 

测试时间

 

问题类型:

                        程序代码        数据库        项目文档

问题及影响描述、处理结果(可加附页)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

测试结论

 

 

测试负责人:

                       

 

 

 

    审核(项目经理):

                                        

                 

 

 

 

 

 

 

附录三 测试大纲

1 概述

1.1  编写目的

[可照抄下列语句,也可适当修改。]

本文档的编写目的在于为XXXX(软件名称)软件测试人员提供详细的测试步骤和测试数据,以保证测试人员对软件测试的正确性和完整性。

1.2  参考资料

说明软件测试所需的资料(需求分析、设计规范等)。

1.3  术语和缩写词

说明本次测试所涉及到的专业术语和缩写词等。

1.4  测试内容和测试种类

 

2  系统结构

图表形式表示。

3  测试目的

 

4  测试环境

4.1  硬件

列出进行本次测试所需的硬件资源的型号、配置和厂家。

4.2  软件

列出进行本次测试所需的软件资源,包括操作系统和支持软件(不含待测软件)的名称、版本、厂家。

5  人员

列出一份清单,说明在整个测试期间人员的数量、时间、技术水平的要求。

6  测试说明

可以把整个测试过程按逻辑划分为几个组(包括测试计划中描述的总体测试要求的每个方面),并给每个组命名一个标识符。

6.1  [测试1名称及标识符]说明

6.1.1 测试概述

对测试1进行一个总体描述,主要说明这组测试的基本内容。

6.1.2 测试准备

描述本测试开始前系统必须具备的状态和数据。

6.1.3 测试步骤

对各测试操作按先后顺序进行编号。具体操作和数据见附录。

6.2  [测试2名称及标识符]说明

 

 

                             测评组:

              

                                           

 

 

 

 

 

 

 

 

附录四 测试大纲附录

 

本附录描述了各测试步骤的详细说明,在填入测试结果后,可直接作为测试记录。内容较多时,可一页只放一个测试说明。

测试名称

 

标识符

 

测试时间

 

测试人

 

操作序号

 

错误等级

 

测试输入

说明输入的具体数据或动作

预期输出

说明预期的输出或结果

实际输出

说明实际的输出或结果

操作序号

 

错误等级

 

测试输入

说明输入的具体数据或动作

预期输出

 

实际输出

 

 

 

 

 

 

 

附录五 测试计划

1  概述

1.1  编写目的

[可照抄下列语句,也可适当修改。]

本文档的编写目的在于为整个测试阶段的管理工作和技术工作提供指南;确定测试的内容和范围,为评价系统提供依据。

1.2  参考资料

说明软件测试所需的资料(需求分析、设计规范等)。

1.3  术语和缩写词

说明本次测试所涉及到的专业术语和缩写词等。

1.4  测试种类

说明本次测试所属的测试种类(单元测试、集成测试、有效性测试、系统测试、用户测试)及测试的对象。

2  系统描述

简要描述被测软件系统,可用图表加解释的形式,说明被测系统的输入、基本处理功能及输出,为进行测试提供一个提纲。

3  测试环境

3.1  硬件

列出进行本次测试所需的硬件资源的型号、配置和厂家。

3.2  软件

列出进行本次测试所需的软件资源,包括操作系统和支持软件(不含待测软件)的名称、版本、厂家。

4  测试安排

4.1 (子系统1名称和项目唯一标识号)

4.1.1 测试总体要求

描述本次测试的要求,如:

对所有功能进行正确性测试;

使用一些虚假值、最大值和错误值对软件进行测试;

对软件进行错误检测和出错恢复的测试;

对特定环境条件的组合,用模拟测试数据对软件进行测试;

使用从环境中提取的“真实数据”作为输入,对软件进行测试。

4.1.2 主要测试内容

列出提纲。

4.1.3 测试进度安排

给出进行测试工作的时间安排。

4.2 (子系统2名称和项目唯一标识号)

5  测试数据的记录、整理和分析

说明对本次测试得到数据的记录、整理和分析的方法和存档要求。

 

                                          审核:

                                                         

批准:

                                                         

 

 

 

 

 

 

 

 

 

 

 

附录六 程序错误报告

(系统名称)

                                                             

测试项目

项目名称

测试类型

 

模块名称

模块名称

版本

 

测试时间

 

测试批次

 

序号

错误等级

     

修改情况

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

测试人:  

 

 


 

 

 

 

 

 

 

 

 

附录七 测试分析报告

1   概述

1.1  编写目的

编写本文档的目的在于

通过对测试结果的分析得到对软件的评价;

为纠正软件缺陷提供依据;

使用户对系统运行建立信心。

1.2  参考资料

说明软件测试所需的资料(需求分析、设计规范等)。

1.3  术语和缩写词

说明本次测试所涉及到的专业术语和缩写词等。

2  测试对象

包括测试项目、测试类型、测试批次(本测试类型的第几次测试)、测试时间等。

3  测试分析

3.1  测试结果分析

列出测试结果分析记录,并按下列模板产生BUG分布表和BUG分布图。

分析模版:

从软件测试中发现的并最终确认的错误点等级数量来评估:

从以上提出的BUG等级来统计等级和数量的一个分布情况:(如下表)

 

A

B

C

D

E

BUG数量

2

17

3

0

1

所占比例

9%

74%

13%

0%

4%


3.2  对比分析

若非首次测试时,将本次测试结果与首次测试、前一次测试的结果进行对比分析比较。

3.3  测试评估

通过对测试结果的分析提出一个对软件能力的全面分析,需标明遗留缺陷、局限性和软件的约束限制等,并提出改进建议。

3.4  测试结论

根据测试标准及测试结果,判定软件能否通过测试。

  测试主管:                              

 

2018-04-12 11:24:19 qq_29077265 阅读数 2724
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158103 人正在学习 去看看 李晓鹏
软件验收标准
1 验收内容
a) 功能项测试
对软件需求规格说明书中的所有功能项进行
测试。
b) 业务流程测试
对软件项目的典型业务流程进行测试。
c) 容错测试
容错测试的检查内容包括:
1) 软件对用户常见的误操作是否能进行提示;
2) 软件对用户的的操作错误和软件错误, 是
否有准确、清晰的提示;
3) 软件对重要数据的删除是否有警告和确认
提示;
4) 软件是否能判断数据的有效性, 屏蔽用户的错误输入, 识别非法值, 并有相应的错误提示。
d) 安全性测试
安全性测试的检查内容包括:
1) 软件中的密钥是否以密文方式存储;
2) 软件是否有留痕功能, 即是否保存有用户的操作日志;
3) 软件中各种用户的权限分配是否合理。
e) 性能测试
对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明书中的各项性能指标。
f ) 易用性测试
易用性测试的内容包括:
1) 软件的用户界面是否友好, 是否出现中英文混杂的界面;
2) 软件中的提示信息是否清楚、易理解, 是否存在原始的英文提示;
3) 软件中各个模块的界面风格是否一致;
4) 软件中的查询结果的输出方式是否比较直
观、合理。
g) 适应性测试
参照用户的软、硬件使用环境和需求规格说明书中的规定, 列出开发的软件需要满足的软、硬件环境。对每个环境进行测试。
h) 文档测试
用户文档包括: 安装手册、操作手册和维护手册。
对用户文档测试的内容包括:
1) 操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块;
2) 用户文档描述的信息是否正确, 是否没有歧义和错误的表达;
3) 户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达;
4) 用户文档对主要功能和关键操作是否提供应用实例;
5) 用户文档是否有详细的目录表和索引表。
i) 用户有特别要求的测试。
2 验收标准
1) 测试用例不通过数的比例< 3 %;
2) 不存在错误等级为1 的错误;
3) 不存在错误等级为2 的错误;
4) 错误等级为3 的错误数量≤ 10;
5) 所有提交的错误都已得到更正。
2011-02-25 19:48:00 bingjingfan 阅读数 7471
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158103 人正在学习 去看看 李晓鹏

从网上找了一下,找到了下面的内容,学习并收藏了,谢谢信息的发布者。

1.1 软件测试停止标准

1) 软件系统经过单元、集成、系统测试,分别达到单元、集成、系统测试停止标准。

2) 软件系统通过验收测试,并已得出验收测试结论。

3) 软件项目需暂停以进行调整时,测试应随之暂停,并备份暂停点数据。

4) 软件项目在其开发生命周期内出现重大估算,进度偏差,需暂停或终止时,测试应随之暂停或终止,并备份暂停或终止点数据。

1.2 单元测试停止标准

1) 单元测试用例设计已经通过评审

2) 按照单元测试计划完成了所有规定单元的测试

3) 达到了测试计划中关于单元测试所规定的覆盖率的要求

4) 被测试的单元每千行代码必须发现至少3 个错误

5) 软件单元功能与设计一致

6) 在单元测试中发现的错误已经得到修改,各级缺陷修复率达到标准

1.3 集成测试停止标准

1) 集成测试用例设计已经通过评审

2) 按照集成构件计划及增量集成策略完成了整个系统的集成测试

3) 达到了测试计划中关于集成测试所规定的覆盖率的要求

4) 被测试的集成工作版本每千行代码必须发现2 个错误

5) 集成工作版本满足设计定义的各项功能、性能要求

6) 在集成测试中发现的错误已经得到修改,各级缺陷修复率达到标准

1.4 系统测试停止标准

1) 系统测试用例设计已经通过评审

2) 按照系统测试计划完成了系统测试

3) 达到了测试计划中关于系统测试所规定的覆盖率的要求

4) 被测试的系统每千行代码必须发现1 个错误

5) 系统满足需求规格说明书的要求

6) 在系统测试中发现的错误已经得到修改,各级缺陷修复率达到标准

1.5 缺陷修复率标准

1) 一、二级错误修复率应达到100%

2) 三、四级错误修复率应达到80%以上

3) 五级错误修复率应达到60%以上

1.6 覆盖率标准

语句覆盖率最低不能小于80%

测试用例执行覆盖率应达到100%

测试需求覆盖率应达到100%

在软件消亡之前,如果没有测试的结束点,那么软件测试就永无休止,永远不可能结束。软件测试的结束点,要依据自己公司具体情况来制定,不能一概而论!个人认为测试结束点由以下几个条件决定:

  1.基于“测试阶段”的原则:

  每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段,我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后,再进行后面一个阶段的测试。举个例子来说:单元测试,我们要求测试结束点必须满足“核心代码100%经过code review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在ab类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准,当然也是如此。

  2.基于“测试用例”的原则:

  测试设计人员设计测试用例,并请项目组成员参与评审,测试用例一旦评审通过,后面测试时,就可以作为测试结束的一个参考标准。比如说在测试过程中,如果发现测试用例通过率太低,可以拒绝继续测试,待开发人员修复后再继续。在功能测试用例通过率达到100%,非功能性测试用例达到95%以上,允许正常结束测试。但是使用该原则作为测试结束点时,把握好测试用例的质量,非常关键。

  3.基于“缺陷收敛趋势”的原则:

  软件测试的生命周期中随着测试时间的推移,测试发现的缺陷图线,首先成逐渐上升趋势,然后测试到一定阶段,缺陷又成下降趋势,直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向,来定测试是否可以结束,这也是一个判定标准。

  4.基于“缺陷修复率”的原则:

  软件缺陷在测试生命周期中我们分成几个严重等级,它们分别是:严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时,严重错误和主要错误的缺陷修复率必须达到100%,不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到85%以上,允许存在少量功能缺陷,后面版本解决;对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题,可以暂时不用修改。

  5.基于“验收测试”的原则:

  很多公司都是做项目软件,如果这种要确定测试结束点,最好测试到一定阶段,达到或接近测试部门指定的标准后,就递交用户做验收测试。如果通过用户的测试验收,就可以立即终止测试部门的测试;如果客户验收测试时,发现了部分缺陷,就可以针对性的修改缺陷后,验证通过后递交客户,相应测试也可以结束。

  6.基于“覆盖率”的原则:

  对于测试“覆盖率”的原则,个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求,包括行业隐性需求、功能需求和性能需求等等,只要测试用例执行的覆盖率达到100%,基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心,非得要看看测试用例的执行效果,检查是否有用例被漏执行的情况,可以对常用的功能进行“抽样测试 ”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试,每个阶段都不能忽略。

  7.基于“项目计划”的原则:

  大多数情况下,每个项目从开始就要编写开发和测试的schedule,相应的在测试计划中也会对应每个里程碑,对测试进度和测试结束点做一个限制,一般来说都要和项目组成员(开发,管理,测试,市场,销售人员)达成共识,团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了,测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成,就可以作为一个结束点。很多不规范的软件公司,都是把项目计划作为一个测试结束点,但是如果把它作为一个结束点,测试风险较大,软件质量很难得到保证。

  8.基于“缺陷度量”的原则:

  这个原则也许大家用的不是很多,了解比较少。我们可以对已经发现的缺陷,运用常用的缺陷分析技术和缺陷分析工具,用图表统计出来,方便查阅,分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题,我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然,最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说:一万行代码最多允许存在多少个什么严重等级的错误,这样比较好量化,比较好实施,成为测试缺陷度量的主流。

  9.基于“质量成本”的原则:

  一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是:人命关天的航天航空软件, 那还是质量重要些,就算多花点钱、推迟一下进度,也要测试能保证较高质量以后才能终止测试,发布版本。如果是一般的常用软件,由于利益和市场的原因,哪怕有bug,也必须得先推出产品,没办法呀。一般来说,最主要的参考依据是:“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候,可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”,同时保证公司利益最大化。

    本贴来自天极网群乐社区--http://q.yesky.com/group/review-18169597.html

 

 

 

验收测试模板

阅读数 1026

没有更多推荐了,返回首页