测试理论基础知识概要.docx
《测试理论基础知识概要.docx》由会员分享，可在线阅读，更多相关《测试理论基础知识概要.docx（101页珍藏版）》请在冰豆网上搜索。
测试理论基础知识概要
测试理论基础知识概要
编制人：
目录
1.目的和意义1
2.软件测试流程2
2.1进行软件测试的一般流程2
2.2测试工作总体流程2
3.测试理论基础3
3.1软件测试基础知识概览3
3.2软件质量概述3
3.2.1软件质量的定义3
3.2.2软件公共质量属性3
3.3软件测试背景4
3.4软件测试定义4
3.5软件测试与质量保证的区别5
3.6软件缺陷的产生5
3.7软件测试的目的6
3.8软件测试的意义7
3.9软件测试的原则7
3.10软件测试的对象9
3.11软件测试的模型10
3.11.1V模型10
3.11.2W模型10
3.11.3两个模型之间的比较11
3.11.4H模型11
3.11.5X模型12
4.测试技术方法13
4.1软件测试分类13
4.2测试类型13
4.2.1按照测试技术划分：
13
4.2.2从是否执行角度划分：
14
4.2.3按照开发阶段划分：
14
4.2.4按照测试实施组织划分：
17
4.2.5应用负载压力测试：
17
4.2.6安全测试19
4.2.7易用性测试20
4.2.8回归测试21
4.2.9健全性测试21
4.2.10认同测试21
4.2.11裸机测试21
4.2.12可用性测试21
4.2.13安装/卸载测试21
4.2.14恢复能力测试21
4.2.15兼容性测试22
4.2.16容错性测试22
4.2.17配置测试22
4.2.18随机测试22
4.3基于WEB系统的测试方法22
4.3.1Web系统测试特点22
4.3.2基于Web的系统测试方法22
4.4自动化测试技术27
4.4.1概念27
4.4.2优点与缺点27
4.4.3误区28
4.4.4关键字驱动技术29
4.5测试工具29
5.测试计划31
5.1测试计划可能存在的问题31
5.2生成测试计划书31
5.2.1确定工程31
5.2.2定义测试策略32
5.2.3分解软件，写测试需求32
5.2.4估计测试工作量33
5.2.5确定资源33
5.2.6创建工程调度表33
5.2.7书写测试计划书34
6.测试设计35
6.1测试设计的本质35
6.2测试设计可能存在的问题35
6.3测试用例的概念35
6.3.1测试用例的定义35
6.3.2测试用例的元素35
6.4测试用例设计36
6.4.1测试用例的作用36
6.4.2测试用例设计的主要影响因素36
6.4.3测试用例设计的基本思想37
6.5白盒测试用例的设计37
6.5.1代码走查37
6.5.2语句覆盖38
6.5.3分支覆盖38
6.5.4条件覆盖39
6.5.5路径覆盖39
6.6黑盒测试用例的设计39
6.6.1等价类划分法40
6.6.2边界值分析法42
6.6.3因果图+判定表43
6.6.4错误推断法45
6.6.5功能图法46
6.6.6场景法47
6.6.7正交排列法53
6.6.8测试方法选择的综合策略55
7.测试执行56
7.1测试执行可能存在的问题56
7.2测试记录分析56
7.3测试执行具体步骤56
8.测试跟踪和缺陷管理57
8.1测试跟踪57
8.1.1提出问题57
8.1.2缺陷的定义57
8.1.3缺陷描述的主要元素57
8.1.4并非所有缺陷都会修改58
8.2缺陷管理58
8.2.1软件缺陷的分类58
8.2.2软件缺陷的生命周期59
8.2.3缺陷管理的简单流程60
8.2.4缺陷报告62
8.2.5缺陷跟踪的目标62
8.2.6常见缺陷62
8.2.7缺陷的属性64
9.测试总结（评估测试质量）67
9.1测试报告67
10.工作参考69
10.1WEB测试经验69
10.2WEB安全测试点71
10.3常用的网站功能测试方法73
10.4GUI基本测试内容76
10.5重庆研发中心缺陷等级标准78
1.目的和意义
掌握测试理论是作为一个测试工程师的必备知识和技能，是测试工作的基础。
本文归纳了软件测试理论的基础知识，为使新员工能更快地了解和掌握测试理论知识，为以后的工作打好基础。
2.软件测试流程
2.1进行软件测试的一般流程
图2.1软件测试的一般流程
2.2测试工作总体流程
图2.2测试工作总体流程
3.测试理论基础
3.1软件测试基础知识概览
图3.1软件测试基础知识概览图
3.2软件质量概述
3.2.1软件质量的定义
在1991年软件产品质量评价国际标准ISO9126中定义的“软件质量”是：
软件满足规定或潜在用户需求特性的总和。
到1999年，软件“产品评价”国际标准ISO14598经典的“软件质量”定义是：
软件特性的总和，软件满足规定或潜在用户需求的能力。
2001年软件“产品质量”国际标准ISO9126定义的软件质量包括“内部质量”、“外部质量”和“使用质量”三部分。
也就是说，“软件满足规定或潜在用户需求的能力”要从软件在内部、外部和使用中的表现来衡量。
3.2.2软件公共质量属性
软件公共质量属性如下图所示
图3.2软件公共质量属性
3.3软件测试背景
我们生活在信息时代，信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质量自然成为人们共同关注的焦点。
不论软件的生产者还是软件的使用者。
（1）竞争机制决定企业必须提高产品质量；
（2）质量不佳的产品不仅会使维护费用大幅增加，还会产生其他的责任风险，造成公司信誉下降。
在一些关键应用（如民航订票系统、银行结算系统、证券交易系统等）中使用质量有问题的软件，还可能造成灾难性的后果。
3.4软件测试定义
测试（test）最早出于古拉丁字，它有“罐”或者“容器”的含义。
在工业制造和生产中，测试被当作一个常规的检验产品质量的生产活动。
测试的含义为“以检验产品是否满足需求为目标”。
而软件测试活动包括了很重要的任务，即发现错误。
“软件测试”的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。
我们知道，软件是由文档、数据以及程序组成的，那么软件测试就应该是对软件形成过程的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试。
随着人们对软件工程化的重视以及软件规范的日益扩大，软件分析、设计的作用越来越突出，而且有资料表明，60%以上的软件错误并不是程序错误，而是分析和设计错误。
因此，做好软件需求和设计阶段的测试工作就显得非常重要。
这就是我们提倡的测试概念扩大化，提倡软件全生命周期测试的理念。
3.5软件测试与质量保证的区别
软件测试人员的一项重要任务是提高软件质量，但不等于说软件测试人员就是软件质量保证人员，因为测试只是软件质量保证工作中的一个环节。
软件质量保证和软件测试是软件质量工程的两个不同层面的工作。
（1）质量保证（QA）：
质量保证的重要工作通过预防、检查与改进来保证软件质量。
QA采用“全面质量管理”和“过程改进”原理开展质量保证工作。
所关注的软件质量的检查与测试。
虽然在QA的活动中也有一些测试活动，但所关注的是软件质量的检查与测量。
QA的工作是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求，因此主要着眼于软件开发活动中的过程、步骤和产物，而不是对软件进行剖析找出问题或评估；
（2）软件测试：
测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。
测试人员要“执行”软件，对过程中的产物——开发文档和源代码进行走查，运行软件，以找出问题，报告质量。
测试人员必须假设软件存在潜在的问题，测试中所做的操作是为了找出更多的问题，而不仅仅是为了验证每一件事是正确的。
对测试中发现问题的分析、追踪和回归测试也是软件测试中的重要工作，因此软件测试是保证软件质量的一个重要环节。
3.6软件缺陷的产生
（1）沟通不畅：
交流不够、交流上有误解或者根本不进行交流，需求调查和分析不充分，在应该做什么或不应该做什么的细节（应用的需求）不清晰的情况下进行开发。
（2）软件复杂性：
图形用户界面（GUI），客户/服务器结构，分布式应用，数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长。
（3）需求变化：
需求变化造成的影响，如：
工作产品、进度、质量、成本等。
（4）编码缺陷：
程序员在开发过程中由于经验不足或者其他方面的原因，导致的编码缺陷。
（5）时间压力：
工作量估算很难做到精确，很多时候是根据项目经理的经验来进行估算，没有量化数据支持。
客户对进度的压力、公司对成本的严格控制。
（6）角色双刃剑：
开发人员需要自信：
“我开发的程序不会有缺陷”。
（7）代码文档说明贫乏：
有的程序员没有为代码编写文档的习惯或者认为编写与代码相关的文档不重要，相反他们认为少写文档可以更快的进行编码。
贫乏或者质量不高的文档使得代码维护和修改变的异常艰辛，其结果是带来许多缺陷。
（8）软件开发工具：
可视化工具，编译器，脚本工具可能会将自身的缺陷带到应用软件中。
3.7软件测试的目的
早期的软件定义指出软件测试的目的是寻找错误，并且尽最大的可能找出最多的错误。
GrenfordJ.Myers就软件测试的目的提出了以下观点。
（1）测试是程序的执行过程，目的在于发现错误；
（2）一个好测试用例在于能发现至今未发现的错误；
（3）一个成功的测试是发现了至今未发现的错误的测试。
BillHetzel提出了测试目的不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量。
测试的目的，是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。
同时，测试是以评价一个程序或者系统属性为目标的活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求的程度，为用户选择与接受软件提供有力的依据。
此外，通过错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。
同时，通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。
当然，通过最终的验收测试，也可以证明软件满足了用户的需求，树立人们使用软件的信心。
3.8软件测试的意义
（1）暴露软件产品存在的缺陷，帮助开发人员提高软件质量；
（2）验证软件产品正确实现了用户需求，帮助人们树立对产品的信心。
3.9软件测试的原则
对于相对复杂的产品或系统来说，Zero-Bug是一种理想，Good-Enough是一条合适的原则。
Good-enough原则就是一种权衡投入/产出比的原则：
不充分的测试是不负责任的；过分的测试是一种资源的浪费。
我们的操作困难在于：
如何界定什么样的测试是不充分的，什么样的测试是过分的。
目前状况唯一可用的答案是：
制定最低测试通过标准和测试内容，然后具体问题具体分析。
在进行软件测试时，应该遵循一定的原则，以确保能够更加有效的进行测试：
基于测试是为了寻找软件的错误与缺陷，评估与提高软件质量，我们提出这样的一组测试原则，如下所示。
（1）所有的软件测试都应追溯到用户需求。
这是因为软件测试的目的是使用户完成预定的任务，并满足用户的需求，而软件测试所提示的缺陷和错误使软件达不到用户的目标，满足不了用户需求。
（2）应当把“尽早的和不断的进行软件测试”作为软件测试者的座右铭。
由于软件的复杂性和抽象性，在软件生命周期各个阶段都可能产生错误，所以不应把软件测试仅仅看作是软件开发的一个独立阶段的工作，而应当把它贯穿到软件开发的各个阶段中。
在软件开发的需求和设计阶段就应开始测试工作，编写相应的测试文档。
同时，坚持在软件开发的各个阶段进行技术评审与验证，这样才能在开发过程中尽早发现和预防错误，杜绝某些缺陷和隐患，提高软件质量。
只要测试在生命周期中进行得足够早，就能够提高被测试软件的质量，这就是预防性测试的基本原则。
（3）完全测试是不可能的，测试需要终止。
想要进行完全的测试，在有限的时间和资源条件下，找出所有的软件缺陷和错误，使软件趋于完美，是不可能的。
主要有三个原因：
①输入量太大；
②输出结果太多；
③路径组合太多。
一个适度规模的程序，其路径组合近似天文数字，对于每一种可能的路径都执行一次的穷举测试是不可能的。
此外，测试也是有成本的，越是测试后期，为发现错误所付出的代价就会越大，因此也要根据测试错误的概率以及软件可靠性要求，确定最佳停止测试时间，我们不能无限的测试下去。
（4）测试无法显示软件潜在的缺陷。
进行测试是可以查找并报告发现的软件缺陷和错误，但不能保证软件的缺陷和错误全部找到，继续进一步测试可能还会找到一些，也就是说测试只能证明软件存在错误而不能证明软件没有错误。
（5）充分注意测试中的群集现象。
经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。
根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。
在所测程序段中，若发现错误数目多，则残存错误数目也比较多。
这种错误群集性现象，已为许多程序的测试实践所证实。
例如，在美国IBM公司的OS/370操作系统中，47%的错误仅与该系统的4%的程序模块有关。
这种现象对测试很有用。
如果发现某一程序模块似乎比其他程序模块有更多的错误倾向，则应当花费较多的时间和代价测试这个程序模块。
（6）程序员应避免检查自己的程序。
基于心理因素，人们认为揭露自己程序中的问题总不是一件愉快的事，不愿否认自己的工作；由于思维定势，人们难于发现自己的错误。
因此，为达到测试目的，应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试。
（7）尽量避免测试的随意性。
应该从工程的角度去理解软件测试，它是有组织、有计划、有步骤的活动。
3.10软件测试的对象
根据软件定义，软件包括数据、程序和文档，所以软件测试并不仅仅是程序测试。
软件测试应贯穿整个软件生命周期中。
在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。
需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明书、概要设计规格说明书、详细设计规格说明以及源程序，都应成为“软件测试”的对象。
在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；在集成测试后，需要检测与证实软件是否满足需求说明书中规定的要求，这就称为“确认测试”。
将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。
由于软件分析、设计与开发各阶段是互相衔接的，前一阶段工作中发生的问题如未及时解决，很自然要影响到下一阶段。
从源程序的测试中找到的程序错误不一定都是在程序编写过程中产生的。
如果简单的把程序中的错误全都归罪于程序员，未免冤枉了他们。
据美国一家公司的统计表明，在查找出的软件错误中，属于需求分析和软件设计的错误约占64%，属于程序编写的错误仅占36%。
这都说明，对程序编写而言，它的许多错误是“先天的”。
事实上，到程序的测试为止，软件开发工作已经经历了许多环节，每个环节都可能发生问题。
为了把握各个环节的正确性，人们需要进行各种验证和确认（verification&validation）工作。
验证（verification）是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。
确认（validation）是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。
验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。
3.11软件测试的模型
3.11.1V模型
图3.3V模型示意图
3.11.2W模型
图3.4W模型示意图
3.11.3两个模型之间的比较
V模型旨在改进软件开发的效率和效果。
Ｖ模型反映出了测试活动与分析设计活动的关系。
从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。
但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。
W模型相对于V模型，增加了软件各开发阶段中应同步进行的验证和确认活动。
W模型由两个V字型模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系。
W模型强调：
测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。
W模型有利于尽早地全面的发现问题。
例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。
同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
但W模型也存在局限性。
在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
这样就无法支持迭代的开发模型。
对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
3.11.4H模型
H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。
软件测试可以尽早的进行，并且可以根据被测物的不同而分层次进行。
这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。
图中标注的其它流程可以是任意的开发流程，例如设计流程或者编码流程。
也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。
H模型揭示了一个原理：
软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
H模型指出软件测试要尽早准备，尽早执行。
不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。
3.11.5X模型
X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。
X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。
己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。
多根并行的曲线表示变更可以在各个部分发生。
由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。
4.测试技术方法
4.1软件测试分类
从不同的角度出发，软件测试可以划分为不同的分类：
（1）按照测试技术划分，软件测试可以划分为：
白盒测试，黑盒测试与灰盒测试；
（2）从是否执行程序的角度，软件测试可以划分为：
静态测试与动态测试。
（3）按照开发阶段划分，软件测试可分为：
单元测试，集成测试，系统测试，确认测试，验收测试；
（4）按照测试实施组织划分，软件测试可分为：
开发方测试（α测试），用户测试（β测试），第三方测试
4.2测试类型
4.2.1按照测试技术划分：
4.2.1.1白盒测试
白盒测试也称为结构测试、逻辑驱动测试或基于程序的测试。
白盒测试是已知程序内部逻辑，覆盖代码的测试，旨在充分地覆盖软件的结构，并以软件中的某类成分是否都已得到测试为准则来判断测试的充分性。
白盒测试包括单元测试和集成测试：
（1）单元测试：
指最小函数或模块的测试（详见4.2.3.1节）；
（2）集成测试：
指对由各部分组合起来的程序进行测试（详见4.2.3.2节）。
4.2.1.2黑盒测试
黑盒测试亦称为功能测试、数据驱动测试或基于规格说明的测试。
黑盒测试是从用户观点出发的测试，它假定测试者无须了解程序的内部结构，根据软件所需的功能和所实现的功能选择测试数据，分析测试的充分性。
黑盒测试包括功能测试和系统测试：
（1）功能测试：
指使软件适合应用程序的功能需求的测试；
（2）系统测试：
指基于全部需求说明，覆盖系统所有组合部分的测试。
4.2.1.3灰盒测试
介于白盒测试与黑盒测试之间的测试。
灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。
4.2.2从是否执行角度划分：
4.2.2.1静态测试
基本特性：
在对软件进行分析、检查和测试时不实际运行被测试的程序。
静态测试可以用于对各种软件文档进行测试，是软件开发中十分有效的质量控制方法之一。
静态测试实质是同行评审，不只是测试人员单独执行。
（1）需求评审：
需求定义的静态测试（需求说明评审），对需求定义的静态测试着重于测试对用户需求的描述和解释是否完整、准确；
（2）设计评审：
设计文档的静态测试（设计文档评审），对设计文档的静态测试着重于分析设计是否与需求定义一致。
（3）代码走查：
源代码的静态测试（代码走查，代码评审），对源代码的静态测试着重于分析实现是否正确、完备。
4.2.2.2动态测试
所谓动态测试，就是通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。
4.2.3按照开发阶段划分：
4.2.3.1单元测试
测试中的最小单位，测试特殊的功能或代码模块。
单元测试是对类中的各个方法进行单独的、隔离的测试。
由于需要对内部代码和设计的详细知识，该测试一般由开发者完成而不是由测试人员完成。
该测试的难易程度同代码设计的好坏直接相关。
单元测试用例的核心是输入数据、期望输出数据。
用覆盖率来度量单元测试的完成度。
单元测试的目的：
（1）保证局部代码的质量；
（2）改良项目代码的整体结构；
（3）降低后续阶段缺陷修复的成本。
编写测试代码的基本流程：
图4.1单元测试中编写测试代码的基本流程
4.2.3.2集成测试
随着新功能的增加，不断的对应用程序进行测试。
在程序的所有部分完成之前，需要一个应用程序的各个部分之间能够相对独立的进行工作。
这类型测试可以有开发者或测试者完成。
测试应用程序
升级会员 