测试详解 (概念篇、Bug篇、用例篇、测试分类)

	职责定位	掌握技术	思维方式
软件开发	实现需求功能，编写业务逻辑代码	具备良好的算法和数据结构基础	构建思维（如何实现功能）
软件测试	验证软件中的缺陷和问题，设计测试用例	熟悉各类测试工具	破坏性思维（如何发现缺陷）
测试开发	提升测试效率，开发自动化测试框架	具备良好开发水平，掌握软件测试流程与方法	兼具开发思维与测试思维

1.3软件的生命周期？

需求的开始是软件⽣命的起点，中间会经历需求的计划、设计，程序开发，程序测试等阶段，直⾄软件不再进⾏维护便到了⽣命的重点。

需求分析 —— 计划 —— 设计 —— 编码 —— 测试 —— 运行维护

二.概念篇

2.1什么是需求

大多数需求有两部分，一部分是用户需求、一部分是软件需求

用户需求：

可以简单理解为甲⽅提出的需求，如果没有甲⽅，那么就是终端⽤⼾使⽤产品时必须要完成的任务。该需求⼀般⽐较简略，通常是⼀句话。(是软件需求的来源和基础）

软件需求：

或者叫功能需求，该需求会详细描述开发⼈员必须实现的软件功能。软件需求是测试⼈员进⾏测试⼯作的基本依据。（是用户需求的具体实现）

2.2 开发模型

瀑布模型：

优点/特点	缺点
线性结构，每个阶段只执行一次是其他模型的基础框架适用于需求固定的小项目	容易产生风险，前面阶段遗留的分险会推迟到测试阶段才会发现，导致大面积返工周期太长，产品很迟才能看见和使用，会导致需求/功能过时

螺旋模型：

优点/特点	缺点
在每个阶段都增加的风险分析和原型强调严格的全过程分险管理强调各开发阶段的质量适用于规模大、复杂度高、分险大的项目	对风险分析管理人员的技能水平要求高额外增加了人员、资金、时间的投入，成本太高

增量模型、迭代模型：

增量模型：把一个大需求，分解为多个小需求，独自开发上线，相结合就是一个完整大需求

好处：发现bug时，只需要解决相应的小需求即可

迭代模型：初期的已经有整个框架了，不断的细化和完善即可

好处：每次迭代后根据反馈调整需求

敏捷模型：

在敏捷模型中，需求被分解成许多可以增量开发的⼩部分。敏捷模型采⽤迭代开发。每个增量部分都是在迭代中开发的。每次迭代都旨在⼩⽽易于管理，并且只能在⼏周内完成。⼀次为客⼾计划、开发和部署⼀个迭代。没有制定⻓期计划。

《敏捷宣言》中内容：

个体与交互重于过程和工具——强调高效的沟通
可用的软件重于完备的文档——强调轻文档
客户协作重于合同谈判——主动及时了解当下请求
响应变化重于遵循计划——主动迎接变化

敏捷模型四个特点：轻文档、请流程、重目标、重产出。

敏捷模型中的Scrum模型，又称迭代式增量软件开发模型

迭代开发：

与瀑布模型不同，Scrum将产品的开发分解为若干个小sprint(选代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

Scrum模型中，有三个角色和五个重要会议

三个角色：

由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成

product owner：负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
scrum master：负责召开各种会议，协调项目，为研发团队服务。
team：则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

五个重要会议：

发布计划会议——迭代计划会议——每日例会——演示会议——回顾会议

测试模型：

测试模型中有两个⾮常重要且具有标志性的测试模型：V模型和W模型

V模型：

优点：

清楚的标注了测试过程中存在的不同类型的测试，并且清楚的描述了开发阶段和测试阶段对应关系

缺点：

把所有测试阶段都放在编码之后了，如瀑布模型缺点一样

W模型 (双V模型)：

特点：

测试的对象不仅是程序，需求、设计等同样要测试
开发阶段和测试阶段是并行关系 (弥补了V模型的缺点)

优点：

因为开发和测试是并行关系，有利于尽早的全面测试出问题。

缺点：

测试和开发活动保持着一种线性的前后关系，上一阶段完全结束，才可开始下一个阶段工作

三.Bug篇

3.1软件测试的生命周期

概念: 软件测试贯穿于软件的整个生命周期

软件测试的生活周期是指测试流程（如下图）：

各阶段具体内容：

需求分析

测试计划

测试设计与开发

测试执行

测试评估

上线

运行维护

用户角度：软件需求是合理

技术角度：是否还有优化空间

测试角度：是否存在业务逻辑错误

什么是否开始测试

什么时候结束测试

耗时多久

根据需求文档、技术文档来编写测试用例

写测试文档

利用测试用例等全面启动测试

测试是否通过测试

是否遗留Bug

发布上线

持续跟进测试维护

3.2 什么是bug

定义：程序中存在的一个错误、缺陷、疏忽或者故障，这些bug使程序无法运行

也可以理解为：

程序功能和用户需求不符时，也是bug
当程序没有实现最终用户合理预期的功能时，就是软件错误也是bug

描述bug的要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果

bug级别一般分为：

崩溃	严重	一般	次要
阻碍开发或测试工作；造成系统崩溃、死机、死循环；导致数据库数据丢失，与数据库连接错误；主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等。	系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试；功能设计与需求严重不符，模块无法启动或调用；程序重启、自动退出，关联程序间调用冲突；安全问题、稳定性等问题。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等。	功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等。	界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等问题。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好。

bug的生命周期：

New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。
Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
Rejected：如果认为不是Bug，则拒绝修改。
Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。
Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

无效的bug流程：open->closed open-rejected-closed

四.用例篇

测试用例概念：

测试用例是为了实施测试而向被测试的系统提供的一组集合。这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

测试用例的好处：

测试执行者的依据；使得工作可重复；自动化测试的基础；评估需求覆盖率；用例的复用;积累测试的方法思路以供后续借鉴。
测试用例覆盖率越高，测试质量越高。

4.1设计测试用例

正确设计测试用例的思想：常规思维+逆向思维+发散性思维

设计测试用例的万能公式：功能测试+界⾯测试+性能测试+兼容性测试+易⽤性测试+安全测试 （不同的场景的还有弱网测试+安装卸载测试）

功能测试

界面测试

性能测试

兼容性测试

易用性测试

安全性测试

弱网测试

安装卸载测试

验证软件功能是否符合需求规格说明书的要求。

软件界⾯上所有的内容都需要进⾏测试。整体界面测试界面的实现与设计图要求一致。

系统在特定负载下的响应速度、稳定性和资源消耗。

验证软件在不同软硬件环境中的适配能力。

评估用户使用软件的便捷性与直观性

识别系统潜在漏洞，防止数据泄露或非法入侵。

模拟网络信号差、延迟高、带宽低的场景，验证软件在不良网络环境下的稳定性和容错能力

验证软件安装、升级、卸载过程的完整性和用户操作友好性。

例如博客系统测试用例（简写版）：

4.2设计测试用例方法

等价类：

概念：依据需求划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

等价类分类：

有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
无效等价类：根据需求说明书，不满足需求的集合。

等价类测试用例：

缺点：等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

边界值：

概念：边界值分析法就是对输入或者输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，其测试用例来自等价类的边界。

边界值包含：

边界值
次边界值

边界值测试用例：

根据上述等价类用例进行补充

其他方法：

错误猜测法：对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷,从而针对性地设计测试用例的方法。
场景设计法：是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
因果图：借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
正交排列：根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。

五.测试分类

5.1按执行方式划分

静态测试

定义：是指不运行程序的情况下，通过检查代码、文档来发现缺陷

优点

缺点

早期发现问题：在开发阶段即可发现问题

低成本：无需搭建运行环境。节省测试资源

无法验证运行时行为：如内存泄漏、性能问题需运行程序才会发现

依赖人工经验：需要测试人员有较高的技术水平

动态测试

定义：通过运行代码，来验证实际结果是否符合预期结果

优点	缺点
验证实际行为：可捕捉运行时错误（如崩溃、死锁、资源竞争）。覆盖功能与性能：支持功能验证、压力测试、安全性测试等。自动化支持：易通过工具（如JUnit、Selenium）实现自动化。	执行成本高：需准备测试环境、测试数据，耗时较长。覆盖率依赖用例设计：若用例设计不充分，可能遗漏潜在问题

5.2按照是否查看代码划分

黑盒测试：

定义：在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、满足规范需求。

优点	缺点
不需要了解程序内部的代码以及实现从用户角度出发设计测试用例，易知道用户需求测试用例基于软件需求开发文档，不容易遗漏需要测试的功能	覆盖率有限：无法测试代码分支、边界条件等内部逻辑。隐藏缺陷难发现：如内存泄漏、性能问题可能被遗漏。

白盒测试：

定义：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同的地方设立检查点，检查实际运行状态与预期状态是否一致。

优点	缺点
高覆盖率：可验证所有分支、循环和条件逻辑。早期缺陷发现：在开发阶段即可发现深层问题（如算法错误）。精准定位：直接关联代码，便于修复。	成本高：需要编程技能，耗时长。忽略整体功能：可能过度关注局部而忽略用户需求。

灰盒测试

定义：介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出输入的正确性，同时也关注程序内部的情况。

优点	缺点
平衡效率与深度：兼顾功能验证和部分代码覆盖。适合集成测试：验证模块间接口和交互（如API测试）。资源消耗适中：比白盒简单，比黑盒更深入。	覆盖不彻底：无法像白盒全面覆盖代码路径。依赖部分实现知识：需有限了解内部结构。

总结对比：

测试类型	优势	劣势	典型应用
黑盒	不需要了解程序内部的代码以及实现	覆盖率低隐藏问题难以发现	系统测试验收测试
白盒	高覆盖率精准定位问题	成本高需编程技能	单元测试安全测试
灰盒	兼顾功能与部分逻辑适合集成测试	覆盖有限	接口测试性能测试

选择建议：

需求导向：若需验证用户体验，选黑盒；若需代码级质量保障，选白盒。
阶段适配：单元测试用白盒，集成测试用灰盒，系统测试用黑盒。
资源平衡：灰盒适合资源有限但需一定深度的场景。

5.3按照开发阶段划分

单元测试（模块测试）

定义：与编码同步进行，针对代码最小单元（如函数、类方法）的测试，按照开发阶段划分主要采用白盒测试方法

测试目的：检验软件基本组成单位的正确性
测试阶段：编码后或编码前
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码+注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试，局部数据结构测试，路径测试，错误处理测试，边界测试

Java中也有很多单元测试框架，如Junit，Junit提供了⾮常多注解和断⾔函数，有效提升开发单元测试脚本的效率

集成测试：

定义：将程序模块采⽤适当的集成策略组装起来，对系统的接⼝及集成后的功能进⾏正确性检测的测试⼯作。集成主要⽬的是检查软件单位之间的接⼝是否正确，测试多个模块组合后的交互

测试目的：检查软件单位之间的接口是否正确
测试阶段：单元测试之后进行
测试对象：模块间的接口
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试+白盒测试
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

系统测试：

定义: 将软件系统看成一个系统的测试，包括对功能、性能以及软件所运行的软硬件环境进行测试

测试目的：确认系统符合需求规格说明书
测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

回归测试：

定义: 回归测试是指修改了旧代码后，重新进⾏测试以确认修改没有引⼊新的错误或导致其他代码产⽣错误。

测试目的：确保代码修改后，原有功能未被破坏。
测试阶段：代码变更后（如修复缺陷、新增功能）。
测试对象：受影响的功能模块或全系统。
测试人员：测试团队。
测试方法：
自动化测试：重用历史测试用例（如 Selenium）。
选择性测试：仅测试与修改相关的功能。

测试内容：关键功能、历史缺陷、核心业务流程。

冒烟测试：

测试目的：快速确认系统基本功能正常，避免后续测试资源浪费。
测试阶段：新版本构建后或每日测试开始前。
测试对象：系统核心功能。
测试人员：测试人员或开发人员。
测试方法：手动或自动化执行主干流程测试用例。
测试内容：登录/注册、主业务流程、关键接口等。

回归测试和冒烟测试虽然它们都属于系统测试，但冒烟测试注重最基本的功能，⽽回归测试关注全⾯的功能，包括已有功能和新添加的功能。这两种测试类型在测试策略中起到了不同的作⽤，帮助确保软件质量和稳定性。

验收测试：

定义：针对用户需求，对通过系统测试的软件进行交付性测试，以确定系统是否满足验收标准，验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试

测试目的：由用户确认系统是否满足业务需求。
测试阶段：系统测试完成后，产品上线前。
测试对象：完整交付的系统。
测试人员：客户、业务代表或产品经理。
测试方法：
用户验收测试（UAT）：模拟真实业务场景。
Alpha/Beta 测试：内部或外部用户试用。

测试内容：需求覆盖率、易用性、合同合规性等。