23.1 信息系统综合测试与管理

软件测试模型

软件测试模型总表

1. V模型

在这里插入图片描述
在这里插入图片描述

V模型及优缺点

在这里插入图片描述

2. W模型

在这里插入图片描述

W模型及优缺点

在这里插入图片描述

3. H模型

在这里插入图片描述

H模型及优缺点

在这里插入图片描述

4. X模型

在这里插入图片描述
针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交互和集成最终合成为可执行的程序。

X模型及优缺点

在这里插入图片描述

5. 前置测试模型

在这里插入图片描述
说明:
前置测试模型将开发和测试的生命周期整合在一起,标识了项目生命周期从开始到结束之间的关键行为。每一个交付的开发结果都必须通过一定的方式进行测试源程序代码并不是唯一需要测试的内容,其他的测试内容如:可行性报告、业务需求说明、系统设计文档等。用较低的成本来及早发现错误,并且充分强调了测试对确保系统的高质量的重要意义。

前置测试模型的验收测试中所包含的3个要素:基于测试的需求、验收标准和验收测试计划。

前置测试模型的技术测试主要是针对开发代码的测试,如V模型中所定义的动态的单元测试,集成测试和系统测试前置测试还提示我们应增加静态审查,以及独立的QA测试。

软件测试类型

软件测试分为不同的类型:

1. 按照开发阶段划分

软件测试类型分为单元测试、集成测试、系统测试和验收测试。

1)单元测试:单元测试又称模块测试,是针对软件设计的最小单元(即程序模块)进行正确性检验的工作。程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。

2)集成测试:集成测试又称组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成子系统或系统进行的测试活动。
集成测试关注的是模块间的接口,接口之间的数据传递关系,单元组合后是否实现预计的功能,其目的是要找出在模块接口上面,包括整体体系结构上的问题。有非增值式策略(单个→整体)和增值式策略(单个→逐步到整体)。

3)系统测试:是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等是否满足其规约所指定的要求。系统测试的对象不仅仅包括需要测试的产品系统的软件,还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。系统测试更多程度上是站在用户的角度上对系统做功能性的验证,同时还对系统进行一些非功能性的验证,包括压力测试、安全性测试、容错测试、恢复性测试等。

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

验收测试是按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接收系统。验收测试主要包括易用性测试、兼容性测试、安装测试、文档(如用户手册、操作手册等)测试等几个方面的内容

2. 按照测试实施组织划分

软件测试类型分为开发方测试、用户测试、第三方测试。

1)开发方测试:通常也叫“验证测试” 或“α测试” 。开发方通过检测和提供客观证据证实软件的实现是否满足规定的需求。Alpha测试是由一个用户在开发环境下进行的测试, 并且在开发者对用户的“指导”下进行测试, 也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。开发方测试的目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。

2)用户测试:是在用户的应用环境下,用户通过运行和使用软件,检测与核实软件实现是否符合自己预期的要求。Beta测试(即β测试) 通过被看成是一种“用户测试”。Beta测试由软件的最终用户们在一个或多个客户场所进行。与Alpha测试不同的是开发者通常不在Beta测试的现场。Beta测试着重于产品的支持性, 包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后, 才能开始Beta测试。

3)第三方测试:也称为独立测试,是介于软件开发方和用户方之间的测试组织的测试。由专业的第三方承担,引入第三方测试后,由于测试方相对的客观位置,由用户、开发方、测试方三方组成的三角关系也便于处理以往用户、开发方双方纠缠不清的矛盾,使得许多问题能得到比较客观的处理

3. 按照测试技术划分

软件测试类型分为黑盒测试、白盒测试和灰盒测试。

1)黑盒测试:黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试。它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表法、正交试验设计法、功能图法、场景分析法等。

2)白盒测试:白盒测试又称结构测试,白盒测试可以把程序看成装在一个透明的白盒子里,也就是清楚了解程序结构和处理过程,检查是否所有的结构及路径都是正确的,检查软件内部动作是否按照设计说明书的规定正常进行。其目的是通过检查软件内部的逻辑结构,对软件中逻辑路径进行覆盖的测试。可以覆盖全部代码、分支、路径和条件。

3)灰盒测试:介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不像白盒测试详细、完整,只是通过一些表征的现象、事件、标志来判断内部的运行状态。灰盒测试是基于程序运行时的外部表现同时又结合程-序内部逻辑结构来设计用例,执行程序并采集程序路执行信息和外部用户接口结果的测试技术。如果使用灰盒测试,就需要关心模块与模块之间的交互,这是灰盒测试与黑盒测试的区别。缺点:投入的时间比黑盒测试大概多20%~40%的时间。

4. 按照测试执行方式划分

软件测试类型分为静态测试和动态测试。

1)静态测试:是指不运行程序,通过人工对程序和文档进行分析与检查;静态测试技术又称为静态分析技术,静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码、用户手册等进行非运行的检查。静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行,也可以借助软件工具自动进行。

2)动态测试:动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。动态方法指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率结果与预期结果的差异,并分析运行效率和健壮性等性能,这种方法由三部分组成:编写测试用例,执行程序,分析程序的输出结果。

静态测试与动态测试的区别如下:
a.静态测试是用于预防的,动态测试是用于校正。
b.多次的静态测试比动态测试要效率高。
c.静态测试综合测试程序代码。
d.在相当短的时间里,静态测试的覆盖率能达到100%,而动态测试经常是只能达到50%左右。
e.动态测试比静态测试更花时间。
f.静态测试比动态测试更能发现Bug。
g.静态测试的执行可以在程序编码编译前,动态测试只能在编译后才能执行

5. 按照测试对象类型划分

软件测试类型分为功能测试、界面测试、流程测试、接口测试、安装测试、文档测试、源代码测试、数据库测试、网络测试和性能测试。

1)功能测试:对软件功能进行的测试,主要检查软件功能是否实现了软件功能说明书(软件需求)上的功能要求。

2)界面测试:对软件的用户界面进行的测试,主要检查用户界面的美观度、统一性、易用性等方面的内容

3)流程测试:按操作流程进行的测试,主要有业务流程、数据流程、逻辑流程,其目的是检查软件在按流程操作时是否能够正确处理。流程测试是测试人员把系统各个模块连贯起来运行、模拟真实用户的实际操作,满足用户需求定义的功能来进行测试的过程。

4)接口测试:是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。

5)安装测试:确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。

6)文档测试:包括a.非交付用户的文档测试(需求文档测试:需求规格说明书、概要设计和详细设计说明书;测试相关文档测试:测试计划、测试用例、测试报告);b.交付用户的文档测试(需求文档、用户手册、安装手册)

7)源代码测试:通过本类型的测评发现应用程序、源代码中包括OWASP十大Web漏洞在内的安全漏洞(如注入、失效的身份认证和会话管理、跨站脚本、失效的访问控制、安全配置错误、敏感信息泄露、攻击检测与防范不足、跨站请求伪造、使用含有已知漏洞的组件、未受保护的APIS等) , 识别、定位存在的安全漏洞, 并分析漏洞风险, 提出整改建议, 提高系统的安全性。

8)数据库测试:数据库测试的主要因素有:数据完整性、数据有效性和数据操作和更新。

9)网络测试:网络测试就是验证网络的建设是否成功的手段。主要是验证以下几个方面:链路连接情况、错包率、连通性、网络质量、路由策略、备份路由、网管等。

10)性能测试:包括负载测试、压力测试(并发测试、大数据量测试)、稳定性测试
a.负载测试。
负载测试,又叫强度测试,是通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足性能指标的情况下,系统所能承受的最大负载量的测试。负载测试也是检查在系统运行环境不正常到发生故障的情况下,系统可以运行到何种程度的测试。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
b.压力测试。
对系统逐渐增加压力的测试,来获得系统能提供的最大的服务级别的测试或者不能接收用户请求的性能点。压力测试是为了发现在什么条件下应用程序的性能会变得不可接受。压力测试包括并发测试和大数据量测试。
①并发测试。
主要指当测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题,如内存泄漏、线程锁、资源争用等问题,几乎所有的性能测试都会涉及并发测试。并发测试目的不是为了获得性能指标,而是为发现并发引起的问题。
②大数据量测试。
大数据量测试包括独立的数据量测试和综合数据量测试两类。独立的数据量测试指针对某些系统存储、传输、统计、查询等业务进行的大数据量测试。综合数据量测试指和压力性能测试、负载性能测试、稳定性性能测试相结合的综合测试。大数据量测试主要是针对数据库有特殊要求的系统进行的测试。
c.稳定性测试。
稳定性测试,也叫疲劳强度测试。通常是采用系统稳定运行情况下的并发用户数,或者日常运行用户数,持续运行较长一段时间,保证达到系统疲劳强度需求的业务量,通过综合分析交易执行指标和资源监控指标,来确定系统处理最大工作量强度性能的过程。

并发测试及用户量计算

我们可以关注用户的总量、用户平均在线数值、用户最高峰在线数值,通过这些用户数来推算出并发用户数。例如,公司OA系统账号或者总用户有2000人,最高峰在线500人,但是这500人并不是作为并发用户存在的概念,即并不表示服务器实际承载的压力。有可能40%的用户关注的是首页新闻公告板之类(注意看新闻这个阶段是不能造成服务器的压力),20%的用户在查询资料或者操作表格,20%用户在发呆,20%在页面之间跳转。在这种情况下,只有真正20%用户的查询或操作表格才会对服务器造成实质的影响,我们将这个查询、操作表格作为一个业务范畴来说,直接将这部分业务并发用户称为并发用户数。

计算并发用户数公式如下:
计算平均并发用户数:C=NL/T ----------------公式(1)
并发用户峰值数: C ′ ≈ C + 3 C {C}'\approx C + 3\sqrt{C} CC+3C ----------------公式(2)
【N是登录的用户数量,L是登录的平均时长,T指考察的时长】

假设有一个OA系统,该系统有3000个用户,(可以看注册信息)平均每天大约有400个用户要访问该系统,(日志文件查看)对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。则根据公式(1)和公式(2),可以得到:
C=400X4/8=200
C ′ ≈ 200 + 3 200 = 242 {C}'\approx 200 + 3\sqrt{200}=242 C200+3200 =242

但是一般的做法是把每天访问系统用户数的10%作为平均的并发用户数。最大的并发用户数乘上一个值2或者3。

6. 按照质量属性划分

软件测试类型分为容错性测试、兼容性测试、安全性测试、可靠性测试、维护性测试、可移植性测试和易用性测试。【质量属性属于非功能性的测试】
1)容错性测试:容错性测试主要检查系统的容错能力,检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。容错性测试是检查软件在异常条件下的行为。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面:

·输入异常数据或进行异常操作,以检验系统的保护性

·灾难恢复性测试

2)兼容性测试:兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等环境中是否能够很友好的运行的测试

3)安全性测试:安全测试是在IT软件产品的生命周期中,特别是产品开发基本完成到发布阶段,对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。安全性的两个关键方面如下。

·应用程序级别的安全性,包括对数据或业务功能的访问。

·系统级别的安全性,包括对系统的登录或远程访问。

4)可靠性测试:软件可靠性测试是指在预期的使用环境中,为检测出软件缺陷,验证和评估是否达到用户对软件可靠性需求而组织实施的一种软件测试。软件可靠性测试是面向故障的测试。

5)可用性测试:可用性测试,是评估(测试)设计方案或者产品的可用性水平。目前最常用的评估可用性水平的指标有:用户在没有帮助的情况下完成任务的比例,完成任务所用的时间,用户寻求帮助的次数等。

6)维护性测试:可维护性是衡量对已经完成的软件进行调整需要多大的努力。包括纠正性、适应性和完善性等(还有预防性)。提高软件可维护性一般方法如下:a、提升软件工具模块化和质量技术;b、创建精密的软件品质目标和优先级;c、选有可维护的程序设计语言

7)可移植性测试:可移植性指未经修改或修改部分源代码后,应用程序或系统从一种环境移植到另一种环境中还能正常工作的难易程度。这里的环境包括软件环境、硬件环境和组织环境。

8)易用性测试:易用性测试主要考察评定软件的易学易用性、各个功能是否易于完成、软件界面是否友好等,在很多类型的管理类软件中是非常重要的。可以从几个方面入手进行易用性测试:导航测试、图形测试、内容测试和整体界面测试。

通常对易用性有如下定义:

·易见(Easy to Discover) :单凭观察, 用户就应知道设备的状态, 该设备供选择可以采取的行动。

·易学(Easy to Leam) :不通过帮助文件或通过简单的帮助文件, 用户就能对一个陌生的产品有清晰的认识。

·易用(Easy to Use) :用户不翻阅手册就能使用软件

7. 按照测试地域划分

软件测试类型分为本地化测试和国际化测试
1)本地化测试

本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。
测试内容包括:软件界面测试、基本功能测试、安装/卸载测试、文档测试

2)国际化测试

软件国际化的测试就是验证软件产品是否支持一些特性,包括多字节字符集的支持、区域设置、时区设置、界面定制性、内嵌字符串编码和字符串扩展等。软件国际化的测试通常在本地化开始前进行,以识别潜在的不支持软件国际化特性的问题。

设计评审和代码审查是国际化测试中最有效的方法。除此之外,I18N测试(对程序来说,在不修改内部代码的情况下,能根据不同语言及地区显示相应的界面方法)有两种基本方法:

  • 一种是针对源语言的功能测试。在源语言版本中,直接检查某些功能特性是否符合要求,如不同的区域设置、不同的时区显示等。
  • 另一种是针对伪翻译(pseudocode, pseudo-translation) 版本的测试。即文字、图片信息中的源语言被混合式的多种语言(如英文、中文、日文和德文等)替代,然后进行全面的I18N测试,包括相关的功能测试、界面测试,但不包括翻译验证等。

附:
负载测试,压力测试和性能测试的区别:https://www.cnblogs.com/loved-wangwei/p/8992980.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值