软件测试介绍

网友投稿 774 2022-05-30

软件测试

软件测试定义:通过人工或者自动化的检测方式,检测被测对象是否满足用户需求,不仅是执行文件,还包括对于文档的测试。

软件测试的目的:

1、发现缺陷(BUG),即被测对象与用户需求之间的差异。

2、增加大家对软件质量的信心,通过测试活动发现并解决缺陷。

3、为决策提供数据依据,通过测试活动了解被测对象的质量状况 。

4、降低产品失败的风险,通过测试活动积累经验,预防缺陷出现。

软件测试的阶段:

1、需求分析阶段:通过需求测试评审活动,检查需求文档是否与用户期望一致,主要检查文档错误(表述错误、业务逻辑错误等),属于静态测试。

2、软件设计阶段:主要检查系统设计是否满足用户环境需求、软件组织是否合理有效等。一般开发人员完成。

3、编码开发阶段:发现软件失效行为,修复缺陷

4、验收阶段:检验系统是否满足用户需求,达到可交付标准。

5、运营维护阶段:验证软件变更、补丁修复是否成功和是否引入了新的缺陷。

软件测试原则:

1、测试证明软件存在缺陷。

即使通过测试未能发现任何缺陷,也不能证明被测对象不存在缺陷。测试人员应该持怀疑一切的态度

2、不可能执行穷尽测试

人力、时间资源有限,数据无法穷尽。通过风险分析、被测对象测试点优先级分析、软件质量模型及不同测试方法的运用来确定测试点,从而替代穷尽测试,提高测试覆盖率。

3、测试应该尽早启动、尽早介入

下层建筑决定上层高度,缺陷发现越早,修复成本越低,测试评审活动应该尽早介入。

4、缺陷存在群集现象

二八定律:一个软件系统的核心功能往往占整个系统功能的20%左右,但这20%的核心功能往往产生80%的缺陷。测试过程中的人力、时间、资源分配比例应根据系统业务的优先级匹配。

5、杀虫剂悖论

测试用例经过多次迭代后,将不能再发现缺陷(开发人员熟悉了测试套路)。测试用例需要定期评审、及时调整。

6、不同测试活动依赖于不同的测试背景

例如电子商务业务系统和银行证券产品的测试方法可能不一样

软件测试级别(阶段) 针对不同研发阶段的测试

1、需求测试

对需求本身进行测试,重点在于检查需求规格说明书中是否存在描述不准确、定义模糊、需求用例不正确、语言存在二义性等。考虑其

完整性(功能描述清楚完整)、正确性(准确陈述需开发功能)、一致性(与其他软件需求不相矛盾)、可行性(在已知系统和环境内可以实施)、无二义性(只能有一个统一的解释)、健壮性(异常的分析和处理)、必要性(每项需求都能回溯到某项客户的输入)、可测试性(每项需求都可通过设计测试用例或其他方法来测试)、可修改性(唯一性,每项需求只出现一次)

测试人员负责

2、单元/组件测试

是针对软件基本组成单元来进行正确性检验的测试工作,检测被测组件/单元与《详细设计说明书》的复合程度。被测对象为组件、函数、类等。

一般由开发人员负责。

3、集成测试

是对组件/单元之间和组件/单元与第三方接口之间进行测试,验证接口是否与设计相符,是否与需求相符。组件/单元间集成、模块间集成、子系统间集成。

检验软件模块对《概要设计说明书》、《接口说明书》的复合程度,关注模块间接口和接口数据传递关系,以及模块组合后的整体表现。

一般由开发人员负责。

4、系统测试

将通过集成测试的软件部署到模拟的用户真实计算机环境中去,通过与系统的需求定义作比较,发现软件与系统的需求定义不符合或矛盾之处。

由测试团队完成,测试依据一般包括《需求规格说明书》、需求用例、功能规格说明、功能需求列表、风险分析报告等,以《需求规格说明书》为主。测试的对象包括软件系统、用户手册、操作使用说明书、系统配置和配置数据等。

一般由测试人员负责。

5、验收测试

系统测试完成后,在交付用户部署前,需进行验收测试。是以用户为主的测试。验收测试依据:合同、《需求规格说明书》、《验收测试计划》,对成品进行验收。目的是检查产品是否符合用户的预期。

验收测试形式分为三种:

(1)Alpha测试

用户在开发环境下测试,开发人员在用户旁,可以及时处理发现的问题。

(2)Beta测试

在实际使用环境中测试,开发人员通常不在场,解决问题相对较慢。

(3)UAT测试(user acceptance test)

用户接受度测试

软件测试类型(针对软件对象,进行思考的各个角度)

1、功能测试(检测软件是否满足用户要求的功能和隐藏功能)

特点:

是否有不正确、遗漏、多余的功能

是否满足用户需求和系统设计的隐藏需求

是否对输入做出了正确的响应,输出结果能否正确显示。

软件测试介绍

所有测试中,应该首先保证功能测试。

2、性能测试

模拟系统运行业务压力和使用场景组合,验证系统性能是否满足预先定义的性能要求

特点:

系统是否具有宣称具有的能力

需了解测试系统典型场景,并具有确定的性能目标

要求在真实的运行环境下执行

3、负载测试

在超过被测对象标准性能负荷指标下,验证系统的负载承受能力,并要求在超负荷时,被测对象依然能够正常实现业务功能。

特点:

找到系统处理能力的极限和性能临界点

在超过被测对象性能负荷情况下实施

用来了解系统性能容量,配合性能调优使用

4、压力测试

测试被测对象在超过性能指标的饱和状态下,系统处理业务的能力情况,以及系统是否会出现错误。在负载测试之上,持续增加压力,软件可能会出现失效或者崩溃的情况。可能出现错误是被允许的,但不能允许出现大面积的错误发生。

特点:

主要检查被测对象在峰值情况下应用的表现

一般使用负载测试的思想实施压力测试,持续关注被测对象持续服务的能力

一般用于系统的稳定性测试

5、容量测试

验证被测对象承受超额数据容量时,正确处理业务请求的能力。是面向数据的。

(负载、压力、容量测试都可作为性能测试的测试策略)

6、安全测试

验证被测对象的安全保护机制能否在实际应用中保护系统不受非法入侵,是用来保护系统本身数据的完整性和保密性。

7、兼容性测试

检查软件能否在不同的用户环境下正常运行使用。

8、可靠性测试

验证被测对象在规定时间、规定环境下,实现规定功能或性能的能力。(稳定性)

9、可用性测试

易用性测试。软件是否能够容易被用户理解、学习、使用。

10、移植测试

软件产品是否能顺利移植到新的硬件或软件平台上,移植之后,软件依然能满足用户需求。

11、维护测试

软件部署运行交付后,在实际使用过程中,因改正错误或需求变更而引发的确认验证测试活动。

维护测试可分为四种类型:改正性维护测试、移植性维护测试、完善性维护测试、预防性维护测试

12、确认测试

测试人员发现缺陷后,开发人员修复后生成新的版本。测试人员需要确认是否已经成功修复缺陷。

13、回归测试

对被测试过的程序在修复缺陷后进行的重复测试,目的在于验证修复缺陷没有引发新的缺陷或问题。

回归测试方法:(1)完全回归:需执行被测试对象的所有测试用例。时间充裕时。

(2)选择性回归:主要执行缺陷多的模块、使用频率高的模块、修复缺陷对应的

模块的测试用例。时间紧迫时。

自动化测试

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:【AI理论】惊为天人,NumPy手写全部主流机器学习模型,代码超3万行
下一篇:张小白带你体验昇思1.5的MindScience
相关文章