测试基础

软件测试模型

1、软件开发的主要模型有瀑布模型、原型模型、螺旋模型、增量模型以及Rational统一过程(RUP)模型等

2、软件测试过程的主要模型有以下几种

(1)V模型

(2)W模型

(3)H模型

(4)X模型

(5)前置测试模型。

3、V模型存在一定的局限性,其优缺点如图所示。它将测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段,这样会导致需求分析或系统设计阶段隐藏的问题一直到后期的验收测试时才被发现,当在最后验收测试中发现这些需求错误时,可能已经很难再更改程序的逻辑结构去修正问题,从而导致项目的失败。等到软件编码完成后才开始软件测试工作,那么必须在代码完成后给测试工作预留足够的时间,否则将导致测试不充分,并且开发前期未发现的错误可能会传递并扩散到后面的测试阶段才被发现。

4、V模型失败的原因是它把系统开发过程划分为具有固定边界的不同阶段,导致测试人员很难跨过这些边界来采集测试所需要的信息,并且也阻碍了测试人员从系统描述的不同阶段中取得信息进行综合考虑。

image-20210825212844148

5、由于V模型在软件开发编码完成后才介入测试工作,导致一些在需求和设计中的问题在后期验收测试中才被发现,这样不能体现“尽早地和不断地进行软件测试”的原则。由此演化成一种W模型。

6、相对于V模型,W模型增加了软件各开发阶段中同步进行的验证和确认测试活动。W模型由两个V字型模型组成,分别代表测试与开发过程,表示出了他们的并行关系

7、W模型相当两个V模型的叠加,一个是开发的V,一个是测试的V,由于在项目中开发和测试的是同步进行,相当于两个V是并列、同步进行的,测试在一定程度上是随着开发的进展而不断向前进行

image-20210825212923174

8、在V模型和W模型中都存在一定的局限性,它们都把软件的开发过程视为需求、设计、编码等一系列串行的活动,但实际上,这些串行活动之间存在着相互牵制的关系,并且在大部分时间内,他们是可以交叉进行的。

9、H模型将测试活动完全独立出来,形成一个完全独立的流程

10、H模型图仅仅演示了在整个生存周期中某个层次上的一次“测试循环”。图中的其他流程可以是任意开发流程,如设计流程和编码流程。也可以是其他非开发流程,如SQA流程,甚至是测试流程。也就是说,只要测试条测成试模型是一个独立的流程,贯穿子整个软件产品的周期,

11、H模型揭示了一个原理:软件测试模型是一个独立的流程,贯穿于其他流程并发地进行。

image-20210825213044592

12、对V模型的最主要批评是V模型无法引导项目的全部过程。X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接和集成最终合成为可执行的程序。

13、X模型的左边描述的是针对单独程序片段进行的相互分离的编码和测试14、X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试

image-20210825213111042

15、前置测试模型将测试和开发紧密结合,提供了一种轻松的方式,可以使你的项目加快速度。

16、前置测试模型将开发和测试的生命周期整合在一起,标识了项目生命周期从开始到结束之间的关键行为。

17、前置测试将测试执行和开发结合在一起,并在开发阶段以“编码一测试一编码一测试”的方式来体现。当程序片段一旦编写完成,就会立即进行测试。一般情况下,先进行的测试是单元测试,因为开发人员认为通过测试来发现错误是最经济的方式。

18、与V模型不同的是,前置测试模型认识到验收测试中所包含的3个要素:基于测试的需求、验收标准和验收测试计划,其中基于测试的需求和验收标准都与业务需求定义相联系,但是,验收测试计划则需要等到系统设计完成,因为验收测试计划是由针对按设计实现的系统来进行的一些明确操作定义所组成。

19、前置测试模型用较低的成本来及早发现错误,并且充分强调了测试对确保系统的高质量的重要意义。在整个开发过程中,反复使用了各种测试技术以使开发人员、经理和用户节省其时间,简化其工作。

image-20210825213304553

软件测试类型

1、按照不同的划分方式,软件测试分为不同的类型。当按照开发阶段划分时,软件测试类型分为单元测试、集成测试、系统测试和验收测试。当按照测试实施组织划分时,软件测试类型分为开发方测试、用户测试、第三方测试。当按照测试技术划分时,软件测试类型分为黑盒测试、白盒测试和灰盒测试。当按照测试执行方式划分时,软件测试类型分为静态测试和动态测试。当按照测试对象类型划分时,软件测试类型分为功能测试、界面测试、流程测试、接口测试、安装测试、文档测试、源代码测试、数据库测试、网络测试和性能测试。当按照质量属性划分时;软件测试类型分为容错性测试、兼容性测试、安全性测试、可靠性测试、维护性测试、可移植性测试和易用性测试。当按照测试地域划分时,软件测试类型分为本地化测试和国际化测试。

2、按开发阶段划分,如图

image-20210825213337309

3、单元测试又称模块测试,是针对软件设计的最小单元(即程序模块)进行正确性检验的工作。单元测试的原则如下。

(1)应该尽早进行软件单元测试。

(2)应该保证单元测试的可重复性。

(3)尽可能采用测试自动化的手段来支持单元测试活动。

4、集成测试又称组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成子系统或系统进行的测试活动。

5、系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等是否满足其规约所指定的要求。系统测试的对象不仅仅包括需要测试的产品系统的软件,还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。系统测试的目的是在真实系统工作环境下通过与系统的需求定义作比较,检验完整的软件配置项能否和系统正确连接,发现软件与系统设计文档或软件开发合同规定不符合或与之矛盾的地方

6、验收测试:验收测试是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动,它是技术测试的最后一个阶段,也称为交付测试、发布测试或确认测试。

通常会有四种情况。

(1)测试项目通过。

(2)测试项目没有通过,并且不存在变通方法,需要作很大的修改。

(3)测试项目没有通过,但存在变通方法,在维护后期或下一个版本改进。

(4)测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说清楚,应该修改测试计划。

按照测试执行者的不同,对不同项目的验收测试的称呼也不同。当测试的执行者是测试内部人员,且待测系统为公司内部产品时,我们称为发布测试或确认测试。当测试的执行者是客户或用户,且待测系统为交付客户的项目时,我们称为验收测试或交付测试。

7、按照测试实施组织划分

image-20210825213426657

8、开发方测试通常也叫“验证测试”或“α测试”。Alpha测试是由一个用户在开发环境下进行的测试,不能由程序员或测试员(有的地方又说可以让测试人员进行)完成。测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。

9、用户测试是在用户的应用环境下,用户通过运行和使用软件,检测与核实软件实现是否符合自己预期的要求。通常情况下用户测试不是指用户的“验收测试”,而是指用户的使用性测试。Beta测试(即β测试)通过被看成是一种“用户测试”。Beta测试由软件的最终用户们在一个或多个客户场所进行。与Alpha测试不同的是开发者通常不在Beta测试的现场,Beta测试不能由程序员或测试员完成。因而,Beta测试是在开发者无法控制的环境下进行的软件现场应用。

10、a、β、y常用来表示软件测试过程中的三个阶段: α是第一阶段,一般只供内部测试使用;β是第二个阶段,已经消除了软件中大部分的不完善之处,但仍有可能还存在缺陷和漏洞,一般只提供给特定的用户群来测试使用; y是第三个阶段,此时产品已经相当成熟,只需在个别地方再做进一步的优化处理即可上市发行。

image-20210825213540361

11、第三方测试也称为独立测试,是介于软件开发方和用户方之间的测试组织的测试。一般情况下是在模拟用户真实应用环境下,进行软件确认测试。第三方测试有别于开发人员或用户进行的测试,其目的是为了保证测试工作的客观性。从国外的经验来看,测试逐渐由专业的第三方承担。同时第三方测试还可适当兼顾初级监理的功能,第三方测试以合同的形式制约了测试方,使得它与开发方存在某种“对立”的关系,所以它不会刻意维护开发方的利益,保证了测试工作在一开始就具有客观性。

12、黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。黑盒测试是以用户的角度,从输入数据与输出数据的对应关系出发进行测试的。从理论上讲,黑盒测试只有采用穷举输入测试,把所有可能的输入都作为测试情况考虑,才能查出程序中所有的错误。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表法、正交试验设计法、功能图法、场景分析法等。

13、白盒测试又称结构测试其目的是通过检查软件内部的逻辑结构,对软件中逻辑路径进行覆盖的测试,可以覆盖全部代码、分支、路径和条件。

14、白盒测试和黑盒测试的联系如下。

(1)用白盒测试验证单元的基本功能;用黑盒测试的思考方法设计测试用例。

(2)黑盒测试中使用白盒测试的手段,常称为“灰盒测试”。

(3)白盒测试需要对程序的内部实现十分熟悉,黑盒测试是完全基于对系统需求的了解。

(4)仅仅使用白盒测试,或者仅仅使用黑盒测试都不能系统地全面测试一个软件。

15、灰盒测试是介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不像白盒测试详细、完整,只是通过一些表征的现象、事件、标志来判断内部的运行状态。灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例,执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。 其缺点:

(1)投入的时间比黑盒测试大概多20%~40%的时间。

(2)对测试人员的要求比黑盒测试高;灰盒测试要求测试人员清楚系统内部由哪些模块构成,模块之间如何协作。

(3)不如白盒测试深入。

(4)不适用于简单的系统。所谓的简单系统,就是简单到总共只有一个模块。由于灰盒测试关注于系统内部模块之间的交互。如果某个系统简单到只有一个模块;那就没必要进行灰盒测试了。

软件测试技术

软件测试技术主要包括白盒测试技术和黑盒测试技术,然而随着近些年测试技术的不断应用及实践,功能自动化测试技术、接口测试技术、性能测试技术以及探索式测试技术都被人们越来越重视

黑盒测试法

1、黑盒测试主要检查程序外部结构,不考虑内部逻辑结构。2、黑盒测试的优点主要有以下几点。

(1)比较简单,不需要了解程序内部的代码及实现。

(2)与软件的内部实现无关。

(3)从用户角度出发,能很容易地知道用户会用到哪些功能,会遇到哪些问题

(4)基于软件开发文档,所以也能知道软件实现了文档中的哪些功能。

(5)在做软件自动化测试时较为方便。

3、黑盒测试的缺点主要有以下两点。

(1)不可能覆盖所有的代码,覆盖率较低,大概只能达到总代码量的30%。

(2)自动化测试的复用性较低。

4、黑盒测试的测试用例设计方法主要有:测试区域确定法、数据覆盖法、逻辑推断法、业务路径覆盖法等等。

5、测试区域确定法分为等价类划分法和边界值分析法

6、等价类划分法是把所有可能的输入数据,即程序的输入域划分为若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。

7、边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部,因此针对各种边界情况设计测试用例,可以查出更多的错误。

8、边界值分析法与等价类划分法的区别在于:

(1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。

(2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。

9、组合覆盖是设计尽可能少的测试用例;使各个被测元素的中的各类测试数据组合都被至少执行一次。组合覆盖是覆盖率很高的覆盖法。组合覆盖测试技术是一种设计测试用例的方法,它利用组合产生能够覆盖规定组合的测试用例。根据覆盖程度的不同,可以分为全组合覆盖、成对组合覆盖、正交实验设计法、数据覆盖法等。这种方法力求用尽可能少的测试用例,覆盖尽可能多的影响因素

10、逻辑推断法包括因果图法、判定表法和大纲法等11、业务路径覆盖法包括场景分析法和功能图法

12、场景主要包括4种主要的类型:正常的用例场景,备选的用例场景,异常的用例场景,假定推测的场景。

白盒测试法

1、白盒测试又称为结构测试或逻辑驱动测试。

image-20210825214420533

4、静态白盒测试是在不执行的条件下,有条理地仔细审查软件设计、体系结构和代码从而找出软件缺陷的过程。静态白盒测试的优点:

(1)尽早发现软件缺陷。

(2)为黑盒测试员在接受软件进行测试时设计和应用测试用例提供思路。

5、动态白盒测试又称结构测试,因为软件测试员可以查看并使用代码的内部结构,从而设计和执行测试。

信息系统测试管理

测试管理概述

1、测试管理是为了实现测试工作预期目标,以测试人员为中心,对测试生命周期及其所涉及的相应资源进行有效的计划、组织、领导和控制的协调活动。 2、测试管理的主要因素包括测试策略的制定、测试项目进度跟进、项目风险的评估、测试文档的评审、测试内部和外部的协调沟通、测试人员的培养等。

测试管理内容

测试管理的内容按照管理范围和对象,一般可分为测试部门管理和测试项目管理两种。测试部门管理包含部门日常事务、部门人员、部门下属项目、部门资产等的跟赊及管理工作。测试项目管理包含测试人员管理、测试计划及测试策略的编写、测试评审的组织、测试过程的跟进、测试内部和外部的沟通协调、缺陷跟踪等。

测试监控管理

测试监控的目的是为测试活动提供反馈信息和可视性。测试监控的内容如下

(1)测试用例执行的进度。

(2)缺陷的存活时间

(3)缺陷的趋势分析

(4)缺陷分布密度。

(5)缺陷修改质量。

配置管理

测试过程中的配置管理不仅包括搭建满足要求的测试环境,还包括获取正确的测试、发布版本。

测试风险管理

回归测试风险:回归测试一般不运行全部测试用例,可能存在测试不完全。