学习笔记04_软件测试过程

测试阶段划分

软件测试按照测试阶段划分大致可以分为:单元测试、集成测试、系统测试、验收测试等阶段。
在这里插入图片描述

一、单元测试

单元测试用于检测软件设计的最小单元在语法、格式、逻辑等方面可能存在的算法冗余、分支的覆盖率以及内存泄漏等问题。由于单元本身不是一个独立程序,所以需要一些辅助单元测试来完成单元测试。辅助单元测试有两种:驱动单元和桩单元。

目前在国内大多数公司进行单元测试时都是由开发人员来完成。

目前比较流行的2个开源的工具为:CppUnit和JUnit。
在这里插入图片描述

测试策略

孤立的测试策略、自顶向下测试策略、自底向上测试策略

单元测试常见的错误

单元测试常见的错误一般出现在以下几个方面:单元接口、局部数据结构、独立路径、出错处理以及边界条件。

二、集成测试

集成测试(Integration Testing,简称IT)是在单元测试的基础上,将所有的模块按照设计的要求进行集成,主要验证组装后的功能以及模块之间的接口是否正确安装的测试工作。主要目的是检测软件与概要设计说明书(High Level Design,简称HLD)的符合程度。

1. 集成测试环境

现在的软件越来越复杂,往往一个系统会分布在不同的软硬件平台上,需要所有分布在这些平台上的子系统集成为一个整体并完成系统的功能。因此,对于这样的系统,其集成测试的环境就要复杂很多。在我们测试时,需要考虑以下几个方面:

1)硬件环境:
在集成测试的时,尽可能考虑实际的环境。如果实际环境不可用时,考虑在模拟环境下进行。如在模拟环境下使用时,需要分析模拟环境与实际环境之间可能存在的差异。
2)操作系统环境:
考虑不同机型使用的不同操作系统版本。对于实际环境可能使用的操作系统环境,尽可能都要被测试到。
3)数据库环境:
数据库的选择要根据实际的需要,从容量、性能、版本等多方面考虑。4)网络环境:一般的网络环境可以使用以太网。

2. 集成测试策略

集成测试策略就是在测试对象分析的基础上,描述软件模块集成的方式、方法。集成测试的基本策略比较多,通常分为2种:非增量式集成测试策略和增量式集成测试策略

1)非增量式集成测试策略

非增量式集成又称为大爆炸集成也称为一次性集成。该集成就是在最短的时间内把所有的系统组件一次性集成到被测系统中,并通过最少的用例来验证整个系统,不考虑各组件之间的相互依赖性或者可能存在的风险。

该方法的特点是容易理解、比较简单,并且可以多人并行工作,对人力、物力资源利用率较高。

它最大的缺点是当发现错误的时候,其问题定位和修改都比较困难。即使被测系统能够一次性集成,但还会有许多接口上测试被遗漏,甚至会躲过测试遗留在系统中。

非增量式集成一般适用于维护型的项目,并且新增的项目只有少数的模块被增加或修改。还适用于被测系统比较小,并且它的各个组件都经过了充分的单元测试。

2)增量式集成测试策略

增量式集成的测试策略有很多种,包括自顶向下集成、自底向上集成、三明治集成、基于功能的集成、基于风险的集成、分布式集成等。

该策略最大的特点就是支持故障隔离、定位问题。

3. 集成测试分析

要想做好集成测试,必须加强集成测试的分析工作。集成测试分析可以从以下几个方面进行考虑:

1)体系结构分析

体系结构分析需要从2个角度出发,首先从需求的跟踪实现出发,划分出系统实现上的层次结构图。其次需要划分系统模块之间的依赖关系图。

2)模块分析

一个关键模块应具有以下特性:

1)一个模块和多个软件需求有关或与关键功能相关;
2)该模块处于程序控制结构的顶层;
3)模块本身比较复杂或容易出错的;
4)模块中含有性能需求的;
5)模块被频繁使用的。

3)接口分析

集成测试的重点就是要测试接口的功能性、接口的可靠性、接口的安全性、接口的完整性、接口的稳定性等多个方面。因此对被测对象的接口进行详细的分析。在这里主要说一下系统内常见的接口包括:函数接口、类接口、消息接口、其他接口以及第三方接口等。

4)可测试性分析

在一个系统中,可测试性分析应当在项目开始的时候作为一项需求提出来,并设计到系统中去。在集成测试阶段,分析可测试性主要是为了平衡随着集成范围的增加而导致的可测试性下降。所以应尽可能早的分析接口的可测试性,提前为测试实现做好准备。

4. 集成测试工具

能够直接用于集成测试的测试工具不是很多,一般来说,一些通用的商用测试工具由于需要满足一定的通用性,因此在实际使用的时候功能是有限的,大部分工具需要进行二次开发。

集成测试主要关注接口的测试,常用的接口测试工具:POSTMan、HTTPRequest、jmeter等。

三、系统测试(System Testing)

其目的是验证系统是否满足了需求规格,找出与需求规格不符或与之矛盾的地方,从而提出更加完善的方案。大多数公司还是以系统测试为主,并将系统测试大致分为四个阶段:系统测试计划阶段、系统测试设计阶段、系统测试实现阶段、系统测试执行阶段。

1. 系统测试环境

大致分为:开发环境、测试环境、真实环境。被测系统开发环境下,所包含的代码不同,所有的测试代码都包含在Debug中,这样调试比较方便。

2. 系统测试策略

功能测试

功能测试是系统测试中最基本的测试,它不管软件内部的实现逻辑,主要根据产品的需求规格说明书和测试需求的列表,来验证产品的功能实现是否符合产品的需求规格。特别要注意的是一些隐含功能的需求。

主要检查被测试对象是否存在以下几种错误:

1)是否有不正确、遗漏的或多余的功能。
2)功能实现是否满足用户的需求和系统设计的隐藏需求。
3)对输入是否做了正确的响应,对输出结果是否做了正确的显示。
4)对系统的流程设计是否正确、合理。
5)所有的路径是否达到全覆盖。

功能测试时需要注意以下几点:

1)站在用户角度,考虑用户处于什么情况,如何使来用该功能。
2)考虑用户对多个功能的组合运用以及前后台的交互。
3)对Web端软件,还要考虑多用户使用时,是否会导致功能的失效。

四、性能测试

性能测试是指在一定软件、硬件及网络环境下,对系统的各项性能指标来进行测试,主要检测其性能特性否满足特定的性能需求。
常用的性能指标包括并发数、响应时间、每秒处理的事务数、吞吐量、点击率、访问量以及硬件资源等

性能测试可以发生在测试过程的所有阶段中,即使在单元层也需要考虑性能问题,比如某个函数或类的处理性能。

在系统测试层,需要模拟用户真实的业务场景来进行测试。

通常性能测试需要借助测试工具来完成,如Loadrunner、JMeter等。

性能测试需要从以下两个方面考虑

1)验证系统实现的性能是否与性能需求完全一致。
2)检测系统实现的具体性能到底怎么样。

五、压力测试

压力测试也称强度测试,也是性能测试的一种,是指在极限状态下,长时间或超大负荷地连续运行的测试,主要检测被测系统的性能、可靠性、稳定性等。

压力测试检的目的是检查系统在资源超负荷的情况下的抗压能力。

1)进行简单的多任务测试。
2)在简单压力缺陷被修正后,增加系统的压力直到系统中断。
3)在每个版本循环中,重复进行压力测试。

六、容量测试

容量测试是指检查当系统运行在大量数据,甚至最大或更多的数据测试环境下,系统是否会出问题。还可以看作系统性能指标中一个特定环境下的一个特定性能指标,即设定的界限或极限值。
容量测试是面向数据的,并且它的目的是显示系统可以处理目标内确定的数据容量。

进行容量测试一般可以通过以下几个步骤来完成

1)首先分析系统的外部数据源,并对数据进行分类;
2)对每类数据源分析可能的容量限制,对数据类型分析记录的长度和数量限制;
3)对每类数据源,构造大容量数据对系统进行测试;
4)分析测试结果,与期望值进行比较,最后确定系统的容量瓶颈;
5)对系统进行优化并重复上面的步骤,直到系统达到期望的容量处理能力。

七、安全性测试

安全测试是用来验证系统内的保护机制是否能够在实际应用中保护系统不受到非法的侵入。该测试用来保护系统本身数据的完整性和保密性。随着互联网的发展,安全测试尤为重要,特别是一些金融类的产品,往往都把安全放到首位。

安全测试常用的方法有以下几点:

1)静态代码检测主要验证功能的安全隐患。
2)可以借助安全测试工具APPScan进行漏洞扫描。
3)模拟攻击来验证软件系统的安全防护能力。
4)利用Wireshark工具对网络数据包进行截取分析。

八、兼容性测试

兼容性测试是指检查软件在一定的软硬件、数据库、网络、操作系统环境下是否可以正确地进行交互和共享信息。

兼容性测试的策略有向下兼容、向上兼容、交叉兼容。

兼容性测试一般考虑以下几点:

1)软件本身能否向前或向后兼容,即不同版本之间的兼容。
2)软件能否与其他相关软件的兼容。
3)软件在不同的操作系统上兼容。
4)数据的兼容性,主要是指数据能否共享等。
5)硬件上的兼容性,如手机APP软件需要考虑不同品牌的手机。

九、GUI测试

GUI(Graphical User Interface,图形用户界面)是计算机软件与用户进行交互的主要方式。
GUI软件测试是指对使用GUI的软件进行的软件测试。GUI测试与用户友好性和可操作性有点重复,但GUI测试更关注的是对图形界面的测试。

GUI测试主要包括两个方面,一方面是界面实现与界面设计的吻合情况;另一方面是确认界面处理的正确性。

界面设计与实现是否吻合,主要指界面的外形是否与设计内容一致;
而界面处理的正确性,主要指当界面元素被赋予各种值的时候,系统处理是否符合设计以及是否存在异常。

通常将系统分为三个层次,界面层、功能层、界面与功能的接口层
GUI测试的重点关注在界面层和界面与功能接口层上。为了更好地进行GUI测试,提倡界面与功能的设计进行分离,而且GUI测试也要尽早进行。

对于界面层我们可以从以下几点进行考虑:

1)对于界面元素的外观需要考虑,界面元素的大小、形状、色彩、明亮度、对比度以及文字的属性(大小、字体、排列方式)等。
2)对于界面的布局需要考虑,各界面元素的位置、对齐方式、元素间间隔、色彩的搭配以及Tab顺序等。
3)对于界面元素的行为需要考虑,输入和输出的限制、提醒、回显功能、功能键或快捷键以及行为回退等。

十、可靠性测试

可靠性测试是软件质量中一个重要标志,是指为了评估产品在规定的寿命期间内,在预期的使用、运输或储存等所有环境下,保持功能可靠性而进行的测试活动。

通俗的说法是指系统在特定的环境下,在给定的时间内无故障地运行的概率。

软件的可靠测试要评估软件在运行时功能、性能、可安装、可维护等多方面特性。系统的可靠性是设计出来的,而不是测试出来的。但是通过可靠性测试出来的数据,有助于我们进一步优化系统积累经验,设计和测试是一个互为反馈的过程。

可靠性测试一些常用的指标有:

平均无故障时间(Mean Time To Failure,简称MTTF)
平均恢复的时间(Mean Time ToRestoration,简称MTTR)
平均故障间隔时间(Mean Time Between Failure,简称MTBF)
故障发生前平均工作时间(Mean Time To First Failure,简称MTTFF)等。

十一、配置测试

配置测试主要是指测试系统在各种软硬件配置、不同的参数配置下系统具有的功能和性能。

配置测试并不是一个完全独立的测试类型,需要和其他测试类型相结合,如功能测试、性能测试、兼容性测试、GUI测试等。

通常配置测试的可以分为服务器端和客户端的配置测试。

1)服务器端的配置需要考虑服务器的硬件、Web服务器、数据库服务器等。
2)客户端的配置需要考虑操作系统、浏览器、分辨率、颜色质量等。

十二、异常测试

异常测试是指通过人工干预手段使系统产生软、硬件异常,通过验证系统异常前后的功能和运行状态,达到检测系统的容错、排错和恢复的能力。
它是系统可靠性评价的重要手段。

通常异常测试关注的要点如下:

1)强行关闭软件的数据库服务器或者用其他方式导致数据库死机。
2)非法删除或修改数据库中的表数据或者表。
3)断开网络或者人为增加网络流量。
4)强行重启软件的web服务器或者中间件服务器,测试系统的恢复能力。
5)通过人为手段,增加cpu、内存、硬盘等负载进行测试。
6)对部分相关软件测试机器进行断电测试。

十三、安装测试

安装测试就是确保该软件在正常情况和异常情况的不同条件下,都能进行安装。
安装系统是开发人员的最后一个活动,通常在开发期间不太受关注。然而,它却是用户使用系统的第一个操作,如果因为安装的问题导致用户拒绝这将是一件非常令人痛苦的事情。因此,清晰并简单的安装过程是系统文档中最重要的部分。

在进行安装测试时需要关注以下3点:

1)安装前测试:首先要检查安装包文件以及安装手册是否齐全,其次关注是否有权限以及空间进行安装,还需要考虑杀毒软件和防火墙的影响。
2)安装中测试:主要是安装流程的测试以及检查安装时文件、注册表、数据库的变动。
3)安装后测试:主要检查安装好的软件是否能正常运行,基本功能是否可以使用。

另外还要进行卸载测试和升级测试。卸载测试主要注意能否恢复到软件安装前的状态,包括文件夹、文件、注册表等,是否能把安装时所做的修改都去除掉。升级测试主要注意升级对已有数据的影响。

十四、网络测试

网络测试是在网络环境下和其他设备对接,进行系统功能、性能与指标方面的测试,保证设备对接正常。

网络测试考察系统的处理能力、兼容性、稳定性、可靠性以及用户使用等方面。

网络测试的关注点如下:

1)功能方面需要考虑的是协议测试和软件内的网络传输与架构。
2)性能方面需要考虑网络吞吐率和网络I/O占有率等。
3)安全性则考虑网络传输加密,常用的加密方式有MD5和RSA加密。
4)网络技术上对网络数据收集、分析,常用网络监控工具有Wireshark。

在工作中网络主要进行协议测试,它有以下几点:

1)一致性测试:检测所实现的系统与协议规范的符合程度。
2)性能测试:检测协议实体或系统的性能指标(数据传输率、连接时间,执行速度、吞吐量、并发度等)。
3)互操作性测试:检测同一协议不同实现厂商之间,同一协议不同实现版本之间或同一类协议不同实现版本之间的互通能力和互连操作能力。
4)坚固性测试:检测协议实体或系统在各种恶劣环境下运行的能力(信道被切断、通信技术掉电、注入干扰报文等)

十四、可用性测试

可用性测试和可操作性测试有很大的相似性,它们都是为了检测用户在理解和使用系统方面是否满意。
这包括系统功能、系统发布、帮助文档和过程,以保证用户舒适的和系统交互。

在实际测试的时候,通过观察有代表性的用户,完成产品的典型任务,而界定出可用性问题并解决这些问题。它的目的就是让产品用起来更容易。可用性测试的难点在于可用性有时候比较难以量化,因此可用性测试通常而言由行业专家或用户来进行。行业专家结合自己对行业和用户的了解来进行测试。在系统测试中,需要结合一些经验进行分析,要针对一些容易量化的特性进行检查,如:菜单级数、快捷键的使用和网站导航等。

十五、健壮性测试/容错性测试(Fault Tolerance Testing)

主要用于测试系统在出现故障时,是否能够自动恢复或者忽略故障继续运行。为了使系统具有良好的健壮性,要求设计人员在做系统设计时必须周密细致,尤其是在系统的异常处理方面。即一个健壮的系统是设计出来的而不是测试出来的。

对于一般软件企业来讲,成本、时间和人员的约束经常限制软件测试关注于重要的功能正确性领域,而往往忽略或仅分配少量的资源用于确定系统在异常处理方面的健壮性。一个好的软件系统必须经过健壮性测试之后才能最终交付给用户。

1)容错性测试:通过构造不合理的输入来引诱软件出错,如输入错误的数据类型、输入定义域之外的数值等。
2)恢复性测试:重点考察系统能否重新运行、有无重要的数据丢失、是否毁坏了其他相关的软、硬件。

十六、文档测试

文档测试的目标是验证用户文档是否正确的并且保证操作手册的过程能够正确工作。主要针对系统提交给用户的文档的验证。文档测试有助于发现系统中的不足并且使得系统更可用。

因此文档的编制必须保证一定的质量,通常考虑有以下几点:

1)针对性:分清读者对象,按不同类型、层次的读者,决定怎样适应他们的需要。
2)精确性:文档的行文应当十分确切,不能出现多义性的描述。
3)清晰性:文档编写应力求简明,适当可以配图表以增强其清晰性。
4)完整性:任何一个文档都应当是完整的、独立的、自成体系的。
5)灵活性:各个不同软件项目,其规模和复杂程度有着许多实际差别,文档测试应灵活应对。

部分理论摘于《软件测试技术指南》斛嘉乙 符勇蔚 樊映川

发布了22 篇原创文章 · 获赞 0 · 访问量 556

猜你喜欢

转载自blog.csdn.net/pulapulahs/article/details/104559679