【软件测试基础】

书生－w

已于 2023-05-20 16:38:10 修改

阅读量9.2k

点赞数 1

分类专栏：软件测试文章标签：测试 java 软件测试测试用例

于 2023-05-20 13:45:50 首次发布

本文链接：https://blog.csdn.net/m0_53882348/article/details/130776075

版权

软件测试专栏收录该内容

2 篇文章 0 订阅

订阅专栏

🎉🎉🎉点进来你就是我的人了
博主主页：🙈🙈🙈戳一戳,欢迎大佬指点!

欢迎志同道合的朋友一起加油喔🤺🤺🤺

1、什么是软件测试(CASE)

1.1 软件测试就是验证软件产品特性是否满足用户的需求。

5.5 因为BUG和开发人员发生冲突的解决方法

1、什么是软件测试(CASE)

最常见的理解是：软件测试就是找BUG，发现缺陷，从而保证软件的质量!!!

1.1 软件测试就是验证软件产品特性是否满足用户的需求。

早期，人们更多的将测试看成是对软件产品“检验”，检查软件的每个功能是否运行正常。

1983年，Bill Hetzel将软件测试定义为：软件测试就是一系列活动，这些活动是为了评估一个程序或者软件系统的特性或能力，并确定是否达到了其预期的效果。

从这话我们可以看出以下两点：

测试试图验证软件是“工作的”，也就是验证软件功能执行的正确性。
测试的活动是以测试人员“预期的结果”为依据，这里的“预期结果”指的是需求定义。

1.2 软件测试的特点：

软件测试只是一个样本试验，具有不可穷尽性。

2、软件测试和开发的区别

1.工作内容
开发：通过不同的编程语言，最终做出软件(coding)
测试：写测试用例，执行，发送测试报告，编写自动化测试用例，开发相关的测试工具
2.技能区别
测试：技能广度的掌握(因为测试人员要对产品进行全方面的测试，外观是否好看，WEB的UI自动化，后端的接口进行测试，性能，安全…)

开发: 技能深度的掌握(因为开发要写出高效的代码)
3.开发前景
开发：初级开发工程师 -> 中级开发工程师 -> 高级开发工程师 -> 架构师 -> CTO
测试：初级测试工程师 -> 中级测试工程师 -> 高级测试工程师 -> 架构师 -> 项目经理
4.薪资：
通常情况下，大厂测试和开发薪资是一样的。中小厂的测试薪资比开发略低

2.1 软件测试与调试的区别：

1.角色
调试：开发自己调试
测试：测试 + 开发一起执行(通常情况下，黑盒测试由测试人员执行，部分白盒测试、系统测试是由开发人员执行)
2.阶段
调试：开发的时候才调试
测试：测试是伴着整个软件的生命周期的(测试介入的时间比调试早的)
3.目的
调试：确保程序做了程序员想它做的事情
测试：确保程序解决了它该解决的问题
4.手段
调试：debug，分析代码逻辑
测试：等价类划分法、边界值法、黑白盒测试...

2.2 软件测试的岗位

软件测试工程师： 主要工作一般包含需求分析、编写测试计划和测试方案、设计测试用例、执行测试用例、跟踪BUG、编写测试报告等
测试开发工程师： 根据项目的特点来开发一些自动化测试的脚本，或自动化测试的工具，或者是软件测试工作中用到的提高工作效率的小工具什么的，从而能够更有效地进行测试，提高软件产品的质量，测试开发工程师工作的目的就是为了更高效，更快捷地让测试工程师进行测试工作；测试开发岗位一般要求一定的开发能力，解决能力尤为重要
性能测试工程师： 针对系统进行性能测试，包括使用工具和编写性能自动化测试脚本
安全测试工程师： 主要分析产品可能会出现的安全问题，做各个方面的渗透测试，提高产品的安全性
其他：系统测试工程师、嵌入式测试工程师、硬件测试工程师

3. 什么是需求

需求就是用户的期望或者满足合同（文档，标准，规范）所需要的条件或者权限

需求包含了两个方面：

用户需求：可以简单的理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务，该需求一般比较简略
软件需求：从用户需求转化而来，是用户需求的细化和具体实现细节

用户需求不一定是正确的、合理的、需要进行用户需求的提取和分析(产品经理来提取)，如果说用户需求是合理的，而且有开发的必要，产品经理就会将用户需求转变成软件需求文档

说明：软件需求是测试人员进行测试工作的基本依据

软件测试人员如何深入了解需求？

从需求分析阶段就开始介入了解需求
站在用户的角度
参加需求评审会议
查阅文档
多交流多沟通

4. 认识测试用例

4.1 测试用例的概念

测试用例就是向被测试系统发起的一组集合，包含测试环境，测试数据，测试步骤，预期结果

示例：

4.2 为什么要设计测试用例

测试用例可以衡量需求覆盖率
测试用例可以复用，提高工作效率
测试用例具有借鉴意义
测试用例可以用于回归测试
防止遗漏测试的需求
测试用例是建立自动化的基础

自动化就是把测试人员双手解放，让代码代替人员执行测试.

5. 关于BUG的常见问题

5.1 什么是BUG

当且仅当程序规格说明书（软件需求）存在并合理，如果软件功能和软件需求不符合，就说是软件错误（BUG）

当软件需求不存在，用户需求存在并合理，软件功能和用户功能不符合，就说是软件错误

5.2 如何描述一个BUG（面试题）

对于如何描述一个BUG，可以从以下几点来进行描述

1、发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2、问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤
描述问题重现的最短步骤。
4、预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。要相信：测试人员是最懂需求的。
5、错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。
6、其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
7、不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

5.3 BUG的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的，下面仅是一个常见的例子。
测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。

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

缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。

例如，测试人员新发现的Bug，必须由测试组长评审后才决定是否Open并分派给开发人员。测试人员Open的Bug可以直接分派给Bug对应的程序模块的负责人，也可以要求都先统一提交给开发主管，由开发主管审核后再决定是否分派给开发人员进行修改。 Bug的跟踪以及状态变更应该遵循一些基本原则：
1、测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。
2、对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审

问题：如果发现了一个BUG，开发人员修改了，但是测试人员又复现了这个BUG，是哪些原因可能导致的？

测试环境不一样
开发人员没有理解到，没有修改成功
开发人员修改后没有提交代码到远程，测试人员仍然测试的是旧代码

5.4 如何定义bug的级别

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

5.5 因为BUG和开发人员发生冲突的解决方法

检查自己的BUG描述，看看是否自己将BUG描述清楚
站在用户角度考虑问题应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。
BUG的定级要有理有据，符合公司规范
提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案
找产品经理去讨论问题的解决方案
如果开发不接受,不要争吵,可以发起第三方会议

第三方会议参加者一般是测试人员、开发人员和项目经理

开会前:一定要明确问题原因,问题是什么,解决方案是什么

开会后:确定问题要不要解决,什么时候解决,谁去解决

6. 软件开发和测试的生命周期

软件开发的生命周期

需求分析：分析需求是否合理，需求是否完整
计划：什么时候开始、什么时候结束、耗时多久
设计: 将大的需求转变为一个个可具体执行的任务。进行开发设计（开发哪些接口、使用什么开发框架、使用什么技术）
开发：开发人员参考需求文档和技术文档等等来进行代码开发
测试：进行测试，写测试报告
运行维护：如果项目有问题，测试人员需要协助开发定位问题 + 解决问题

软件测试的生命周期（软件测试的流程）

需求分析：验证需求的合理性与正确性，细化需求，根据需求提炼测试点
测试计划：确定测试范围，目表，测试人员，测试环境，时间等
测试设计：开发测试用例
测试执行：执行测试，提交BUG
测试报告：本次迭代的测试情况进行分析和总结，如写了多少测试用例，执行了多少，发现了多少BUG，修改了多少，剩余BUG的解决方案，测试的覆盖率

7. 开发模型

7.1 瀑布模型

特点：阶段性强，每一个阶段比较独立，因此是线性顺序进行的软件开发模式,看重前期的需求分析和后期的测试阶段
优点: 每个阶段做什么,产出什么十分清晰
缺点：测试在编码后才开始介入，导致前期的问题到后期才发现，失去错误补救机会
适用的项目: 小型的项目

7.2 螺旋模型

螺旋模型适合项目庞大，前期风险大，不是很明确的项目

特点：强调每一个迭代的测试质量和风险分析，抗风险能力很强
优点：每个阶段都会进行风险分析，尽早的发现问题
缺点：风险管控人力物力投入多，成本较大
适用项目：适用于比较大的项目，风险较多的

7.3 增量模型，迭代模型

比如同一个系统四个模块A，B ，C，D要花两周开发完

增量模型：第一周开发A,B模块，第二周开发C，D模块
迭代模型：第一周开发A，B，C，D的基础功能模块，第二周开发A，B，C，D的其他功能模块

特点：抗风险能力强

说明：通常开发将两个模型结合使用，在迭代的基础上使用增量

7.4 敏捷开发模型

敏捷开发是一种以人为本、迭代、循序渐进的软件开发方法，强调在整个软件开发过程中与客户进行频繁的沟通和协作。敏捷开发的核心在于不断地快速迭代、交付、反馈和改进，以适应需求变化和市场竞争的挑战。敏捷模型的流程通常有以下价值观：

个体与交互重于过程和工具 (个体之间面对面交流)
可用的软件重于完备的文档 (文档: 开发文档，需求文档)
客户协作重于合同谈判（）
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者（强调前者，并没有否定后者）

特点：轻文档，轻流程，重目标，重产出，拥抱变化（用户可以随时更改需求）

敏捷开发有很多方式，scrum是比较流行的一种