软件测试-测试分类

Posted 2022-07-02 rayman8560

软件测试-测试分类
一、按软件测试阶段：
a. 单元测试
b. 集成测试
c. 系统测试
d. 验收测试
1、单元测试
单元测试的原则：
1、尽可能保证部没测测试用例相互独立
2、一般由代码的编写人员来实施

单元测试的优点：
1、能尽早发现缺陷
2、有利于重构
3、可以简化集成

单元测试的缺陷
1、不可能穷尽测试，即测试用例不可能覆盖所有的执行路径，不可能捕捉到所有的错误
2、每一行代码需要3-5行测试代码来完成测试

单元测试框架
xUnit，比如：JUnit
例：eclipse->new->Java project->(finish)->右键项目->properties->Java Build Path->Add library->选择JUnit->next->选择Junit版本->finish
选中需要测试的类，在上右键->new->junit test case(勾选setUp()和tearDown() )->next( 选择需要测试类中待测试的方法 ) -> finish()

2、集成测试
在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块，子系统或者系统的过程中各部分工作是否达到或者实现相应3技术指标及要求的活动。

集成测试实施方案
1、BIg Bang（一次性集成/大爆炸）：把大部分开发模块耦合起来，形成一个完整的软件系统，或者系统的主要组成部分，把它们拿来做测试。
2、自顶向下：递增组装软件结构的方法，从主程序开始，沿控制层，逐层向下来集成，
3、自底向上（常用）：从程序模块最底层模块开始，逐层向上组装，逐层测试。优点是能比较好的锁定软件故障的所在位置。
4、核心系统集成：将核心软件挑选出来，对这些部件进行集成测试，在测试通过的基础上，再逐步扩展到外围部件。
5、高频集成测试：持续集成就是高频次的不断进行集成测试。

核心集成和高频集成的结合一般是现在敏捷开发比较常用的集成测试方式，而自顶向下和自底向上是传统瀑布模式主要采用的集成测试方式。

单元测试和集成测试的不同
1、测试对象不同：单元测试针对软件的基本单元，而集成测试主要针对软件的模块或者子系统，主要测试模块之间接口的关系。
2、测试的依据不同：单元测试主要是针对软件的详细设计，测试用例设计的主要依据就是详细设计文档，而集成测试主要是针对软件的概要设计进行测试，测试用例的主要依据是概要。
3、测试的方法不同：集成测试主要关注模块之间接口的集成，而单元测试只关心在单元的类。

3、系统测试（测试主要阶段）
系统测试是将经过集成测试的软件，作为计算机系统的一个 部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。

单元测试和集成测试很多地方会采用模拟的方式来做测试，而系统测试更多的是用真实的运行环境，来系统的对软件进行测试。

系统测试一般要进行功能测试，性能测试，稳定性测试等多种测试类型。

系统测试主要关注系统本身的使用（功能上使用的问题），与其他相关系统的关联性连通性，关注系统不同使用压力下的表现，关注系统在真实环境下的表现。

系统测试和集成测试的不同
1、测试对象不同：集成测试是由通过了单元测试的各个模块所集成起来的构件，系统测试是除软件之外，还包括计算机硬件及相关的外围设备、数据采集的传输机构，支持软件部、系统操作人员等整个系统。
2、测试时间不同：集成测试介于单元测试和系统测试之间，系统测试在集成测试之后
3、测试内容不同：集成测试主要测试各个单元模块之间的接口，系统测试则是测试整个系统的功能和性能
4、测试角度不同：集成测试偏于技术角度的验证，系统测试偏于业务角度的验证

4、验收测试（交付测试）
针对用户需求，业务流程的正式测试。确定系统是否满足验收的标准，由用户、客户或者其他授权机构决定是否接受系统。

验收测试分为：
用户验收测试
运行验收测试
合同和规范验收测试
alpha测试：在开发者所提供的场所和环境中运行
Bata测试：完全脱离开发者，在用户提供的环境中运行

二、按软件测试手段：
a. 黑盒测试
b. 白盒测试
c. 静态测试
d. 动态测试
e. 手工测试
f. 自动化测试
1、黑盒测试（功能测试）
只检查程序的功能是否能够按照我们需求规格说明的规定能够正常使用，程序能否正常的接受数据，并产生合理的输出
黑盒测试主要通过用户的视角，对软件进行测试

黑盒测试的优缺点：
优点：容易实施，不需要考虑内部实现，更贴近用户的角度
缺点：测试覆盖率低，一般只能覆盖到代码量的不到40% ，针对黑盒自动化测试，复用率较低，维护成本高

黑盒测试的主要内容
1、是否有不正确或者功能遗漏
2、在接口上，输入是否能正确的接受，能否输出正确的结果
3、是否有数据结构错误（例如数据文件）访问错误
4、性能上是否能满足要求

黑盒测试的主要设计方法
1、等价类划分：针对程序的输入条件，将所有输入中，等价的归为一类，这样就形成若干典型的代表性的输入，通过典型的数据进行测试用例的设计，这样的方法称为等价类划分法。
2、边界值分析法：其实是一种特殊的等价类，关注
3、因果图+判定表
4、错误推测法：基于经验或者直觉，判断程序中可能出现的错误，进而针对性设计测试用例的方法
5、流程图分析法
6、正交实验分析法:主要用于
7、状态迁移图法

2、白盒测试（结构化测试）
白盒测试中测试人员要对内部结构是非常了解，白盒测试是对程序的逻辑结构来设计测试用例，用逻辑的覆盖率来衡量测试的完整性。

逻辑单位有：语句，条件，条件组合，分支，路径
对应的测试覆盖方法有：语句覆盖，条件覆盖，条件组合覆盖，分支覆盖（判定覆盖），路径覆盖，判定和条件的组合覆盖

白盒测试的优缺点：
优点：迫使测试人员去仔细思考软件的实现，理解原理。可以检测带代码中的每条分支和路径。揭示隐藏在代码中的错误，对代码的测试比较彻底。
缺点：成本高。无法检测代码中遗漏的路径和敏感性错误。不能直接验证需求的正确性。

白盒测试的主要测试方法
1、代码检测法
2、静态结构分析法
3、静态质量度量法
4、逻辑覆盖法（主要）
5、基本路径测试法（主要）

3、灰盒测试
介于黑盒和白盒测试之间的，关注输出对于输入的正确性，同事也关注内部表现

4、静态测试
静态测试是指无需执行被测程序，而是通过评审软件文档或者代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率。

静态测试的特点是程序不被运行。

静态测试的方式有：
1、互审
2、走查
3、会议

5、动态测试
动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性。

黑盒测试中相关的方法主要是动态测试，而白盒测试中一些测试方法主要是静态测试方法。

6、手工测试
指由专门的测试人员从用户视角来验证软件是否满足设计要求的行为，更适用针对深度的测试和强调主管判断的测试，如众包测试、探索式测试

7、自动化测试
使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。单元测试、接口测试、性能测试更多的是用自动化测试。

手工测试和自动化测试的比较
手工测试易发现缺陷，容易实施，创造性和灵活性。但是手工测试覆盖量化难，重复测试效率低，不一致性、可靠性低，人力资源的依赖。
自动化测试高效率、速度快，高复用性，覆盖使用容易度量，准确。可靠，不知疲劳。但是机械，发现缺陷率低，一次性投入较大。

三、按测试类型：
a. 功能测试
b. 性能测试
c. 安全测试
d. 兼容性测试
1、功能测试
根据产品的特性，操作描述和用户反感，测试一个产品的特性和可操作行为以确定它们满足设计需求。

针对问题：
功能错误或遗漏，界面问题，性能错误（一般指软件本身的性能错误），数据及访问错误，初始化及终止错误。

测试工具（自动化）
QTP（基于关键字驱动，web应用）、winrunner（桌面软件）、silkTEST、Rationalrobot；selenium、Watir、Sikuli

2、性能测试
验证软件系统的性能能否满足需求规格给定的指标要求。

性能测试点：
性能测试一般包括负载测试、压力测试、稳定性测试。
性能指标：并发用户数、每秒事务数TPS、系统响应时间、设备性能
测试工具：LoadRunner、Sillperformer、Jmeter、WebLoad、Apache Bench、LoadUI
静态性能评估：YSlow、PageSpeed（均为浏览器插件）

3、安全测试
安全测试：对软件产品进行测试以确保产品安全需求和质量标准。
渗透测试：通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试。

渗透测试和安全测试
渗透测试的侧重点是攻，安全测试的侧重点是防。渗透测试和安全测试是点到面的过程。
OWASP：Open Web Application Security Project
OWASP Top10、 Test Guide

安全测试工具：
1、Appscan（针对web应用的漏洞扫描工具）
2、Webinspect（和Appscan功能上类似）
3、Nessus（针对服务器主机类漏洞检查工具）
4、Nmap（端口show探工具）
5、MetaSploit（攻击框架，包含大量插件，做渗透测试）
6、WebScarab（基于代理劫持的分析，来进行攻击路径的检测）
7、Fortify（白盒测试工具，静态分析代码中可能出现的问题）
8、W3AF（针对web应用）

4、兼容性测试
验证被测对象在不同的操作系统、硬件信息等环境下的运行情况

三、按测试模式
a. 瀑布模型
b. 敏捷测试
c. 基于脚本的测试
d. 基于风险的测试
e. 探索式测试等
1、传统的瀑布模型
项目测试阶段：
项目计划->需求分析->软件设计->程序开发->软件测试->集成维护

各阶段对应输出：
项目计划书->需求说明书->概要设计/详细设计说明书->产品版本->测试报告

瀑布模型每一个阶段都是以上一个阶段的输出作为下一个阶段的输入。

瀑布模型优缺点
强调需求、设计的作用，前一阶段完成后，只需要关注后续阶段，为项目提供了按阶段划分的检查点，里程碑清晰，文档规范
难以适应需求的频繁变化，项目周期后端才能看到成果，强制的里程碑、完成时间点，文档工作量大

从测试角度，瀑布模型并没有体现软件测试的地位和价值

2、V模型（目前使用较广泛的模型）
项目测试阶段：
需求分析->概要设计->详细设计->软件编码->（V转折点）->单元测试->集成测试->系统测试->验收测试

V模型中，强调软件开发的协作，反映测试活动和设计分析的关系，并且将软件的实现和验证有机地结合了起来。

W模型（双V模型）

X模型

H模型

3、敏捷测试（Agile Testing）
敏捷测试更加的拥抱变化

敏捷测试的特点：
强调从客户的视角进行测试，重点关注迭代测试新功能，不再其强调测试阶段，尽早测试，不间断测试，具备条件即测试，强调持续反馈，预防缺陷重于发现缺陷

传统测试与敏捷测试比较

传统测试 敏捷测试
测试是质量的最后保护着 开发和测试人员是紧密合作，大家都有责任对软件负责
严格的变更管理 变更是可接受的，拥抱变更
预先的计划和细节的准备 计划随着进展时常调整
重量级文档 只需要绝对必要的文档
各阶段测试严格的入口和出口标准 各迭代之间已经没有明显的入口和出口标准
更多的在早会测试时进行重量级的自动化测试 所有阶段都需要早自动化测试，每个人都需要做，是项目集成的一部分
严格依赖流程执行 流程不再需要严格执行
测试团队和开发团队是相互独立的 团队合作是无缝隙合作，没有明确区分
4、基于脚本的测试
Script-based Testing SBT
Scripted Testing （ST）
Exploratory Testing（ET 探索式测试）

ET：完全抛开测试脚本的测试

文档测试
针对软件产品的交付品，配套的文档类部件的测试。如用户手册，使用说明，用户帮助文档等。

文档测试关注点：
完整性，正确性，一致性，易理解性，易浏览性

可靠性测试
软件的可靠性测试
硬件的可靠性测试

易用性测试
是指测试用户使用软件时是否觉得方便，是否能保证用户使用体验的测试类型

本地化测试
针对软件的本地实施的针对性测试
主要测试内容：语言，书写习惯，时区，日期格式，货币类型，当地风俗，法律法规，政治敏感内容

部署测试（安装测试）
主要验证系统部署过程，并确保软件经过安装测试后可以正常使用
主要测试内容：在不同环境下的部署验证，参照部署文档执行，过程的合理、正确性，基础数据

无障碍测试（访问性测试）
是指软件需要提供便于特殊人群使用的功能，如视障8，听障，老人，身体残疾用户等。

回归测试
软件功能修改后，对软件进行重新测试以确认修改没有引入新的错误或导致其他部分产生错误。
回归测试的重心在关键模块和终点功能组件。
软件研发周期中会进行多次回归测试，且尽量实现自动化。

Monkey测试（搞怪测试）
用一些随机、稀奇古怪的方式来操作软件，以测试系统的健壮性和稳定性

猫眼测试
来自于硬件板卡验证术语，软件上则用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

A/B测试
多用于互联网行业，通过页面提供2个版本给用户使用并记录相关的用户行为数据，来确定更优化设计的一种测试方案。

测试实施要点
1、多个方案并行
2、每次测试仅改动一个变量
3、按照某种规则进行优胜劣汰

测试工具
Google Analytics Content Experiments，Visual Website Optimizer
---------------------
版权声明：本文为CSDN博主「??_zero」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zero_201605/article/details/81902357