测试基础理论知识0311.docx
《测试基础理论知识0311.docx》由会员分享，可在线阅读，更多相关《测试基础理论知识0311.docx（20页珍藏版）》请在冰豆网上搜索。
测试基础理论知识0311
第一章基本概念
1.1.什么是软件测试
使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度、完全度和质量的软件过程；是SQA（softwarequalityassurance）的重要子域。
1.2.软件测试的内容
软件测试主要工作内容是验证（verification）和确认（validation）。
验证是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。
（Dotherightthing）
确认是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。
即保证软件以正确的方式来做了这个事件（Doitright）
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期问各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。
1.3.软件测试的目的
软件测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
测试是以评价一个程序或者系统属性为目标的一种活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求，为用户选择与接受软件提供有力的依据
通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。
同时通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。
1.4.软件测试的原则
（1）测试的标准是用户的需求
软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷
（2）事先定义好产品的质量标准
有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。
同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
（3）尽早地和不断地进行软件测试
在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%～60%。
，缺陷存在放大趋势。
如需求阶段的一个错误可能会导致N个设计错误，因此，越是测试后期，为修复缺陷所付出的代价就会越大。
因
（4）制定测试计划，排除随意性
在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。
测试计划应包括：
所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等以及评价标准。
（5）周密的测试用例，不可将测试用例抛开
要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。
除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。
（6）避免测试自己的程序
由于心理因素，人们潜意识都不希望找到自己的错误。
基于这种思维定势，人们难于发现自己的错误。
因此，由严格的独立测试部门或者第三方测试机构进行软件测试将更客观、公正，测试活动也会达到更好效果。
软件开发者应尽量避免测试自己的产品，应由第三方来进行测试，当然开发者需要在交付之前进行相关的自测。
一定程度的独立测试（可以避免开发人员对自己代码的偏爱），可以更加高效的发现软件缺陷和软件存在的失效。
但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷。
在软件开发的早期，开发人员对自己的工作产品进行认真的测试，这也是开发人员的一个职责之一
（7）充分注意群集现象
通常情况下，大多数的缺陷只是存在测试对象的极小部分。
缺陷并不是平均而是集群分布的。
因此，如果在一个地方发现了很多缺陷，那么通常在这个模块中可以发现更多的缺陷。
因此，测试过程中要充分注意错误集群现象，对发现错误较多的程序段或者软件模块，应进行反复的深入的测试。
（8）完全测试是不可能的，测试需要终止
穷尽测试是不可能的，应结合当前实际情况当满足一定的测试出口准则时测试就应当终止。
（9）回归测试
修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
（10）妥善保存一切测试过程文档
第二章测试组织
2.1.测试团队存在的必然
开发人员不适合测试自己的软件（不能否决自己的成果、设计理解唯一、对程序功能及接口熟悉）
独立测试组织（ITG）的存在必要性：
不受开发固有思维的影响
站在中立的角度，避免利益冲突
专职于查找问题，分工明确
更利于对软件进行评估
2.2.测试团队的基本责任
发现软件程序、系统或产品中所有的问题
尽早地发现问题
督促和协助开发人员尽快地解决程序中的缺陷
帮助项目管理人员制定合理的开发计划
对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人员能够及时、清楚地了解产品当前的质量状态
帮助改善开发流程、调高产品开发效率
促进程序编写的规范性、易读性、可维护性等
2.3.测试团队的组成
如何组织一个测试团队，应当视企业的人力资源而定。
一般，一个比较健全的测试组，所具有的角色包括测试组长、实验室管理人员、自动化测试工程师、资深测试工程师、初级测试工程师。
测试组长：
业务专家，负责项目的管理、测试计划的制定、项目文档的审查、测试用例的设计和审查、任务的安排、与项目经理和开发组长的沟通等
实验室管理人员：
设置、配置和维护实验室的测试环境，主要是服务器和网络环境等
资深测试工程师：
负责产品设计规格说明书的审查、测试用例的设计和技术难题的解决，主要参与数据库、系统性能和安全性等技术难度较高的测试
自动化测试工程师：
负责测试工具的开发、测试脚本的开发等
初级测试工程师：
执行测试用例和相关的测试任务，侧重功能测试用例的设计和执行
2.4.软件测试团队与开发团队的关系
软件测试与软件开发具有天然的联系。
软件测试的输入是软件开发的产品，测试输出的结果需要开发人员相应处理，处理后的结果再次需要测试人员的验证。
因此，软件测试与软件开发如影相随，互为服务对象。
软件测试人员和软件开发人员要多从别人的角度去想想，所谓“换位思考”，多尊重对方就一定能得到对方的尊重与配合；其次是加强和开发人员的沟通，让他清楚地认识到测试工作对开发工作的价值，发现的每一个Bug的重要性。
测试和开发只是软件工作的分工不同，都是软件项目团队不可分割的成员。
第三章测试流程
3.1.软件过程
软件生存周期是指软件从出现一个构思之日起，直到最后决定停止使用之时止。
包括可行性与计划研究、需求分析、设计、实现、测试、运行与维护等阶段。
软件过程是指开发和维护软件及相关产品（如项目计划、文档、代码、手册等）的一套行为、方法、实践及变换过程。
软件过程是软件生存周期的框架。
3.2.测试过程
软件测试过程一般包括:
测试计划、测试设计、测试准备、测试执行、测试评估和缺陷跟踪等阶段，每个阶段都有一系列的任务。
测试过程具有一下几个特点：
测试工作开始于需求分析之后。
测试经过评估后，达到了结束的标准后才能结束
测试也是迭代过程。
测试需求来自于软件需求。
测试过程与开发过程的关系
都是软件过程的有机组成部分。
测试过程与开发过程同步进行。
测试过程与开发过程相互依赖，又相互独立。
开发过程、测试过程、项目管理过程以及其他支撑过程相互交织共同组成了软件过程。
3.3.测试过程的常见模型
V模型
V模型反映出了测试活动与分析设计活动的关系。
从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。
W模型
W模型强调：
测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。
W模型有利于尽早地全面的发现问题。
但W模型也存在局限性。
在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
这样就无法支持迭代的开发模型。
H模型
H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
测试准备和测试执行分离，有利于资源调配，降低成本，调高效率。
有组织、结构化的独立流程，有助于跟踪测试投入的流向。
H模型还充分体现了测试过程（不是技术）的复杂性。
第四章测试技术
4.1.测试分类
从不同的角度出发，软件测试可以划分为不同的分类：
从是否关心软件内部结构和具体实现的角度划分：
A.白盒测试B.黑盒测试C.灰盒测试。
从是否执行程序的角度:
A.静态测试B.动态测试。
从软件开发的过程按阶段划分有：
A.单元测试B.集成测试C.确认测试D.验收测试E.系统测试
4.2.白盒测试与黑盒测试
白盒测试：
已知产品的内部工作量，可以通过测试证明每种内部操作是否符合设计规格的要求，所有内部成分是否已经过检查
黑盒测试：
又称功能测试、数据驱动测试或基于规范的测试。
用这种方法进行测试时，被测程序被当作看不见内部的黑盒。
在完全不考虑程序内部结构和内部特性的情况下，测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。
白盒测试
黑盒测试
测试依据
程序内部结构
规格说明
优点
能够对程序内部的特定部位进行覆盖测试
能站在用户的的立场进行测试
缺点
无法检验程序的外特性
无法对未实现规格说明的程序内部欠缺部分进行测试
不能测试程序内部特定部位
如果规格说明有误，则无法发现
4.3.单元测试、集成测试、系统测试、验收测试、回归测试
单元测试
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。
它是软件动态测试的最基本的部分，也是最重要的部分之一。
单元测试的目的是在于发现各模块内部可能存在的各种错误主要是基于白盒测试。
·验证代码是与设计相符合的；·发现设计和需求中存在的错误；
·发现在编码过程中引入的错误。
（和设计不相符/和设计相符，但是由于编码疏漏引起）
单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
集成测试
集成测试也叫组装测试、联合测试、部件测试、子系统测试，是在软件系统集成过程中所进行的测试，一般由开发人员担任。
其目的是验证软件的组建对概要设计说明书的符合度。
它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍
集成测试测什么:
1.外部接口：
各件呐在一起后表现的功能
2.内部接口：
各件间的接口是否正确
集成测试的策略主要有自顶向下和自底向上，三明治集成三种。
系统测试
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。
软件系统测试方法很多，主要有功能测试、性能测试、安全测试，随机测试等等。
验收测试
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。
它的测试数据通常是系统测试的测试数据的子集。
所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。
这是软件在投入使用之前的最后测试。
1）系统验收测试是在在系统测试完成后，项目最终交付前进行。
2）系统验收测试不是对系统的全面覆盖，而是针对用户的核心业务流进行测试。
3）验收测试的执行人员不是开发方的测试组成员，是由用户方的使用人员完成。
4）验收可以由第三方专业化全覆盖型技术测试团队测试。
回归测试：
回归测试是在软件维护阶段，对软件进行修改之后进行的测试。
其目的是检验对软件进行的修改是否正确。
这里，修改的正确性有两重含义：
一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。
测试类型
对象
目的
依据
方法
单元测试
模块内部程序错误
消除局部模块的逻辑和功能上的错误和缺陷。
详细设计
白盒为主，黑盒为辅。
集成测试
模块间的集成和调用关系
找出与软件设计相关的程序结构，模块调用关系，模块间接口方面的问题。
概要设计
白盒与黑盒相互结合。
确认与系统测试
整个系统中软硬件
对整个系统进行一系列的整体、有效性测试。
需求规格说明书
黑盒
4.4.自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。
在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
4.5.性能测试
软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性。
由于感受软件性能的主体是人，不同的人对于同样的软件能有不同的主观感受，而且不同的人对于软件性能关心的视角也不同。
（1）并发：
狭义的并发是指所有用户同一时刻做同一事件或操作。
广义的并发是指用户同时与服务器交互，但有可能是在进行不同操作。
（2）吞吐量：
一次测试中系统处理的客户请求的数量。
（3）吞吐率：
单位时间内系统处理的客户请求的数量。
（4）可靠性：
通过给系统加载一定的业务压力（例如资源在70%~90%的使用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。
（5）负载测试：
通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。
（6）压力测试：
对系统不断施加压力的测试。
通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统提供的最大服务级别的测试。
（70强度测试：
迫使资源在异常的系统资源配置下运行，检查程序对异常情况的抵抗能力，对测试系统的稳定性和扩展性都很重要。
（8）事务：
在业务上是用户的一个或一系列操作，代表一定的功能；在程序上表现为一段代码区块；测试人员可以将一个或多个操作步骤定义为一个事务，以衡量这部分的用户并发响应时间。
4.6.测试用例设计
测试用例设计的最基本要求：
覆盖住所要测试的功能。
测试用例设计原则
（1）单个用例覆盖最小化原则
这条原则是所有这四条原则中的”老大“，也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。
测试用例的覆盖边界定义更清晰，则测试结果对产品问题的指向性更强。
测试用例间的耦合度最低，则彼此之间的干扰也就越低。
上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。
每个测试用例应该尽可能的简单，只验证你所要验证的内容，不要“搂草打兔子”捎带着把啥啥啥啥都带进来，这样只会增加测试执行阶段的负担和风险。
（2）测试用例替代产品文档功能原则
通常我们会在开发的初期（Scrum每个Sprint的头两天）用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息，勾勒将要实现功能的样貌，便于团队进行交流和细化，并在团队内达成对产品功能共识。
但随着产品开发深入，团队会对产品的功能有更新的认识，产品功能也会被更具体细化，在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。
如此往复，在不断倾听和吸收用户的反馈，多个迭代过后，原本被描述为A的功能很可能最终变为了Z。
这是时候再去看看曾经的Word文档和OneNote页面，它们仍然记录的是A。
之所以会这样，是因为很少有人会去以及能够去不断地去更新那些文档，以准确地反映出功能当前准确的状态。
（3）单次投入成本和多次投入成本原则。
成本永远是任何项目进行决策时所要考虑的首要因素，项目中的测试也是如此，对成本的考虑也应该客观和全面的体现在测试的设计、执行和维护的整个阶段中。
测试中的成本按其时间跨度可以分为：
单次投入成本和多次投入成本。
例如：
编写测试用例可以看作是单次投入成本，因为编写测试用例一般是在测试的计划阶段进行（Scrum每个Sprint的开始阶段）的，虽然后期会有小的改动，但绝大多数是在一开始的设计阶段就基本上成型了；
（4）使测试结果分析和调试最简单化原则。
这条原则实际上是单次投入成本和多次投入成本原则-针对自动化测试用例的扩展和延续。
在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调试更为简单，包括：
用例日志、调试辅助信息输出等。
测试用例设计方法
1.等价类划分
定义：
等价类划分是一种典型的黑盒测试方法。
等价类是指某个输入域的集合。
它表示对揭露程序中的错误来说，集合中的每个输入条件是等效的。
因此我们只要在一个集合中选取一个测试数据即可。
等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例。
这样就可使用少数测试用例检验程序在一大类情况下的反映。
一般等价类划分可有两种不同的情况：
有效等价类和无效等价类。
2.边界值分析
定义：
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
与等价划分的区别：
边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
3.错误推测
定义：
猜错法在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的分析，对所揭示的缺陷的规律性作直觉的推测,从而有针对性的设计测试用例的方法。
错误推测方法的基本思想：
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
4.因果图
定义：
因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
因果图法产生的背景：
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。
这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
5、判定表驱动分析
定义：
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
判定表的优点
能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。
因此，利用判定表能够设计出完整的测试用例集合。
在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：
针对不同逻辑条件的组合值，分别执行不同的操作。
判定表很适合于处理这类问题。
6、正交实验设计
利用因果图来设计测试用例时,作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。
往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。
正交实验设计方法:
依据Galois理论,从大量的（实验）数据（测试例）中挑选适量的,有代表性的点（例）,从而合理地安排实验（测试）的一种科学实验设计方法.类似的方法有:
聚类分析方法,因子方法方法等.
7、场景设计方发
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
4.7.测试覆盖率
测试覆盖度评估是衡量阶段性软件测试执行状态的重要手段之一，来确定测试是否达到事先设定的测试任务完成的标准。
测试覆盖率则是测试覆盖度评估中一种量化的表示方法。
在测试里面，一般会将测试覆盖率分为两个部分，即“需求覆盖率”和“代码覆盖率”。
代码覆盖率又分为程序语句和代码行覆盖，分支覆盖和条件覆盖。
测试覆盖率可以提供给我们两个方面的信息：
测试覆盖率低的模块和重要模块的测试覆盖率。
这些数据可以帮助我们快速定位需要更多测试的模块，可以帮助我们了解重要模块的测试情况，以此来衡量我们测试用例的质量乃至测试的质量。
测试覆盖率有以下几个原则：
（1）测试覆盖率100%是一个理想的情况，是很难达到的；
（2）测试覆盖率100%不能说明我们做了完全的测试；
（3）较低的测试覆盖率能说明我们的测试还不够，反之是不成立的，参考第二条；
（4）同一模块高覆盖率相对于低覆盖率能说明我们做了更多的测试；
（5）测试覆盖率达到多少要考虑到软件整体的覆盖率情况，以及项目成本，包括人力，时间等等。
第五章测试文档
5.1.测试文档
每个测试过程有五个基本测试文档：
《测试计划》：
指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。
《测试方案》：
指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。
《测试用例》：
指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。
《测试规程》：
指明执行测试时测试活动序列的文档。
《测试报告》：
指明执行测试结果的文档。
5.2.测试计划
《测试计划》文档是计划测试阶段的测试文档，就是指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。
包括如下内容：
目标
概述
角色及职责
测试对象
测试通过/失败标准
测试任务安排
应交付的测试工作产品
工作量估计
5.3.测试方案
《测试方案》文档是计划测试阶段的测试文档，指明为完成软件或软件集成的特性测试而进行设计测试方法的细节文档。
具体包括：
概述
被测对象
应测试的特性
不被测试的特性
测试设计综述
测试模型
测试需求
测试设计
5.4.测试用例
《测试用例》文档是计划测试阶段的测试文档，指明为完成一个测试项的输入、预期结果、测试执行条件等因素的文档。
包括如下内容：
测试用例清单
测试用例列表
每个具体的测试用例一般包括：
测试项目、用例编号、用例级别、输入值、预期输出结果、实测结果、备注
5.5.测试报告
《测试报告》文档是执行测试阶段的测试文档，指明执行测试结果的文档。
包括如下内容：
概述
测试时间、地点、人员
环境描述
测试结果统计
测试评估
测试总结和改进意见
问题报告
第六章测试工具总结
6.1.负载压力测试工具
这类测试工具的主要目的是度量应用系统的可扩展性和性能，是一种预测系统行为和性能的自动化测试工具。
在实施并发负载过程中，通过实时性能监测来确认和查找问题，并针对所发现问
升级会员 