软件测试分类和方法

    --写在最前面--软件测试的方法,会随着软件测试技术的不断发展,越来越多样化,单一性更强(针对性更强);我们在测试工作中,应该着重选择合适的软测方法来完成任务。


一、测试分类

  1. β(Beta)测试,指的是(一个或多个)用户验收测试,通常是在UAT环境完成,测试过程中应该避免开发和测试人员来测。
  2. α(Alpha)测试,指的是一个用户在开发环境下进行测试。
  3. 兼容性测试,也称作软件的可移植性,一般对现如今流行的软件/硬件平台都应该做适配,供不同用户使用该软件/硬件。
  4. UI测试,也就是用户界面测试,这类型的测试一般需多站在用户的角度去考虑,讲究界面风格的完美搭配以及合理性。包括相应的用户友好性、人性化、易操作性等等。
  5. 冒烟测试,一般是需要测试人员与开发人员进行相应的协调进行;比如接口的冒烟测试,在测试过程中,对请求参数的相关要求就需要与开发进行沟通。此过程大体是:

参数-->> 接口内部逻辑-->> -->>输出参数

:测试过程中主要关注这三个方面测试,参数相关的用例、内部逻辑的导向正确性、输出参数是否与API文档相符、安全方面的测试....)

    6. 随机测试,这个很考验一个测试人员的测试经验与测试手段,这类型的测试主要是对软件功能与性能的一种抽查,想要一针见血的查出问题,还是需要一种严谨的测试思维,以及测试经验。

    随机测试还包括对一些用例所没有覆盖的部分进行测试,还有软件更新和新增的功能进行测试。重点还包括对一些特殊情况点、特殊的使用环境、并发性进行检查,结合回归测试一起进行。

二、测试方法

  • 黑盒测试,又称为功能测试、数据驱动测试,它根据软件的规格进行测试,不考虑其内部原理。大体测试原理为:

输入各类数据 -->> -->>查看相应的结果

  • 白盒测试,又称为结构测试或者逻辑驱动测试,需要测试软件产品的内部结构以及处理过程,而并非功能测试。

        白盒测试的覆盖标准包括:逻辑覆盖、循环覆盖和基本路径覆盖测试。其中逻辑覆盖又包含有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。测试主要方法有逻辑驱动、基路测试等,还可以借助相关工具来进行测试,如Jtest、C++ Test等。

  • 自动化

        其中包含有自动化测试、回归测试、验收测试。

  1. 自动化测试,通常会借助相应的工具,编写测试脚本进行测试;通常在GUI、性能等测试以及功能测试中用的较多。而常用的自动化工具包括UFT(QTP)、Testcomplete、autorunner和TAR等。(除了UFT,其它的我也没了解过。)
  2. 回归测试,显然回归测试属于对修改更新之后的软件进行复测,验证功能修改正确以及新功能符合需求。鼓励回归测试使用自动化测试?
  3. 验收测试,指的是系统开发生命周期方法论的一个阶段,它主要是确定产品能够满足合同或者用户的需求。

        验收测试一般分为三种策略:正式验收、非正式验收、α测试、β测试。

  • 静态测试,指的是不运行被测程序本身,通过验证/分析/检查源程序的文法、结构、过程、接口等来检查程序的正确性
  静态方法通过程序静态特性的分析,找出欠缺和可疑之处,例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错,并为测试用例选取提供指导。常用的工具:Logiscope、PRQA。

  • 动态测试,则是通过运行软件来检验它的动态行为和运行结果的正确性。
动态测试步骤
单元测试
集成测试
系统测试
验收测试
回归测试

  1. 单元测试,通常由开发进行测试,将代码直接编写为单元测试,对小功能或代码块进行测试。
  2. 集成测试,指的是整个系统各个部件联合测试,检测模块之间连接上是否会有冲突。这类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前,需要单元测试完成之后进行。
  3. 系统测试,是基于系统整体的需求说明书的黑盒类测试,应覆盖系统涉及的所有部件。系统测试不仅包括需要测试的产品系统的软件,还要包含软件所依赖的硬件、外设以及某些数据、某些支持软件及其接口等。(也就是资源整合在一起之后,整体的测试。)
  4. 验收测试,也就是客户或最终用户的测试;一般是从功能、用户界面、性能、业务关联性进行测试。

  • 性能测试,性能这一块的测试涉及点比较广,主要是测试系统在进行一些负荷或强迫性的(暴力)操作时,所做出反应以及检测其承受能力范围(峰值、零界点)。性能测试一般包括负载测试和压力测试。

        下面列举一下另一些性能测试的类别:

  1. 健全测试,指的是一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试能力。(理解为软件能够正常的运行,及软件足够健全)
  2. 衰竭测试,指软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。
  3. 负载测试,也就是需要验证出一个系统(特别是web端)在高负荷下的反应,比如电商系统,在活动期间能否经受住大量用户的访问以及操作(类似于天猫双11节这样的,够大型吧!!)。
  4. 强迫测试,指的是交替进行负荷和性能测试,如某个操作或输入大量重复数据这样,类似对一个数据库大量的复杂查询等。
  5. 压力测试,它是一种基本的质量保证行为,指的是在计算机数量较少或系统资源匮乏的条件下运行测试。通常需要压力测试的资源包括内部内存、CPU可用性、磁盘空间和网络带宽等。
  6. 恢复测试,是测试一个系统在“灾难”中的自适应、自恢复能力(也就是系统的容错能力)。这类“灾难”包括:系统崩溃,硬件损坏或其他灾难性问题。

        对于自动恢复,需要验证重新初始化、检查点、数据恢复和重新启动等机制的正确性。对于人工干预的恢复系统,还需评估平均修复时间,保证在接受范围之内。

  • 安全测试,简单点描述,就是防止系统被非法入侵,或是能够防止系统被故意的破坏操作。例如:

设法截取或破译系统口令
专门定制软件破坏系统的保护机制
故意导致系统失败,企图趁恢复之际非法进入
试图通多浏览非保密数据,推导所需信息......等等

  • 兼容性测试,也就是需要被测软件在一些指定的硬件/软件/操作系统/网络等环境下的性能如何。向上兼容向下兼容,软件兼容硬件兼容。等等......
  • 可用性测试,也就是对“用户友好性”的测试。
  • 比较测试,我把这个测试理解为竞品分析,两个相似或业务逻辑相似的软件,可以通过对比来找出软件系统的弱点、优点。
  • 可接受性测试,指的是将测试的版本交付给测试部门大范围测试以前进行的最基本功能的简单测试。
  • 边界条件,也就是边界值测试,类比黑盒测试。(这里就不再赘述,在之后的文档中一并总结。)
  • 强力测试,好比压力/负载测试,指的是验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。
  • 等价划分测试,根据等价类设计测试用例的一种技术。黑盒测试常用方法之一,包括有有效等价类,无效等价类。
  • 判定表,是分析和表达多逻辑条件下执行不同操作的情况的工具;优点:能够将复杂的问题按照各种可能的情况全部列举出来,可以设计出相对完整的测试用例集合。
  • 深度测试,指执行一个产品的一个特性的所有细节,但是不测所有特性。
  • 基于设计测试,是根据软件的构架或详细设计引出测试用例的一种方法。
  • 文档测试,其关注点包括:开发文件、用户文件、管理文件,如下所示:

文档测试

开发文档                                    

可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗
用户文件 用户手册、操作手册
管理文件 项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结等

  • 接口测试,定义为系统组件间接口的一种测试。(在这里也不再细述接口测试的含义了。)
  • 逆向测试,也就是测试系统会执行一些非需求定义之内的操作,这样也是不满足软件需求的。


************************************************************************************************************

这篇就先自我总结这么多,以后慢慢更新和优化这些基础的知识。

猜你喜欢

转载自blog.csdn.net/weixin_41055728/article/details/79896136