【测试】——软件测试概念篇

📖 前言：在软件开发过程中，需求分析、测试用例设计和Bug管理是确保软件质量的关键步骤。本文将简要介绍用户需求与软件需求的区别、测试用例的定义及其重要性，以及如何设计有效的测试用例，Bug管理与修复。

---

🕒 1. 软件生命周期概述

1、开发流程/软件生命周期：从产品开始设想到不再维护使用。

2、产品/软件生命周期：需求分析 → 计划 → 设计 → 编码 → 测试 → 运行维护

• 需求分析：进行市场分析，确定投入与收益的比例，评估技术实施的可行性。
• 计划：设定项目的开始与结束时间，预计所需的总耗时。
• 设计：把一个大的需求分解为多个具体且可执行的任务，并进行技术设计，包括接口设计、框架选择、技术选型等。
• 编码：开发人员根据需求文档和技术文档编写代码。
• 测试：指的是执行测试，测试人员根据测试用例进行测试设计。
• 运行维护：包括修复性维护（及时修复项目中未发现的问题）、完善性维护（改进功能性能）、预防性维护（为防止产品在运行期间出现意外问题，采取预防措施）。

3、软件测试的生命周期：需求分析 → 测试计划 → 测试设计与开发 → 测试执行 → 测试评估

• 需求分析：从用户角度审视软件需求的合理性，从技术角度评估可行性及优化空间，以及从测试角度检查业务逻辑是否存在冲突或冗余。
• 测试计划：明确测试的开始时间、结束时间及预计耗时。
• 测试设计与开发：编写测试文档，详细标明所采用的测试方法、工具和形式。依据需求文档和技术文档来制定测试用例。
• 测试执行：利用测试用例和其他工具全面覆盖项目测试。
• 测试评估：对产品进行质量评估，并进行功能演示。

【面试题】如果线上出现问题，测试人员该怎么办？

项目测试完毕并上线后，测试人员需持续监控产品的线上表现，以便及时发现任何质量问题。若存在问题，应采取以下步骤：

1. 尝试复现问题（确定是普遍还是个别现象）：成功复现后，应立即通知项目组内所有成员，以便开始问题定位。
2. 尝试定位问题出现的原因，协助开发人员迅速定位并解决问题。
3. 反思问题的根源（出现的原因、解决办法及预防措施）：若问题严重或较为典型，应撰写相关文档。

🕒 2. 什么是需求

在企业中，需求主要分为两大类：用户需求和软件需求。

1. 用户需求：通常指的是甲方提出的需求，或者在没有甲方的情况下，终端用户在使用产品时必须完成的任务。这类需求通常较为简略。
2. 软件需求：也称为功能需求，它详细描述了开发人员必须实现的软件功能。

开发人员和测试人员的直接工作依据就是软件需求。

用户需求能否作为测试和开发的直接工作依据?

1. 绝对不可以！
2. 在大多数情况下，用户需求需要转化为软件需求。在转化过程中，需进行需求分析，例如：技术可行性、市场可行性、成本投入与收益比等。

🕒 3. 什么是测试用例

1. 测试用例是一组为执行测试而提供给被测系统的集合，包括测试环境、操作步骤、测试数据和预期结果等要素。
2. 测试用例提高测试人员工作效率，降低测试人员工作的重复性问题，是建立自动化的基础。
3. 测试用例解决了两个主要问题：测什么，怎么测。
4. 测试工程师应在需求分析和设计阶段开始参与，这是理解和掌握软件原始业务需求的最佳时机。
5. 举例：

测试网易邮箱注册功能

标题：网易邮箱正确注册功能
测试环境（硬件+软件）：
① 谷歌浏览器版本 128.0.6613.114（正式版本） （64 位）
② Windows11家庭版
操作步骤：（进入方式可能很多：如点击进入，直接地址栏网址进入）
① 进入网易邮箱登录主页
② 点击网易邮箱注册入口，进入注册页面
③ 以普通注册为例，输入对应的注册信息：邮箱地址、密码、手机号、协议勾选框，点击立即注册
测试数据： 具体的邮箱地址、密码、手机号、协议勾选框
预期结果： 页面跳转至注册成功页面，注册的账号可以正确登录

Q：请以手机打电话为例子，设计并完成测试用例。
A：以下为ChatGPT的回答：

标题：打电话测试用例
1、打电话前

阶段	类型	测试点
拨号功能	功能测试	输入电话号码、从联系人拨打、语音命令、最近通话记录
网络连接	功能测试	确保网络连接（4G/5G/Wi-Fi）
通话设置	功能测试	设置呼叫转移、静音模式、音量调整
拨号速度	性能测试	从拨号到呼叫的延迟、卡顿检测
网络延迟	性能测试	不同网络条件下拨号响应时间、信号弱情况
系统资源	性能测试	内存和处理能力、同时运行应用的表现

2、打电话中

阶段	类型	测试点
通话质量	功能测试	音质清晰、无杂音、声音音量合适
通话控制	功能测试	静音、挂断、音量调整、扬声器、三方通话等
信号稳定性	功能测试	信号强度变化、断线或信号丢失
延迟和卡顿	性能测试	不同网络条件下的通话延迟、声音延迟
系统负载	性能测试	CPU和内存使用、切换应用的流畅性
电池消耗	性能测试	通话中的电池消耗、长时间通话影响

3、打电话后

阶段	类型	测试点
通话记录	功能测试	记录保存、显示时间和时长、查看录音
通知与提醒	功能测试	通话结束后通知、未接来电提醒
数据同步	功能测试	通话记录的同步功能
数据处理	性能测试	记录保存和处理速度、大量记录表现
系统稳定性	性能测试	通话结束后的系统稳定性、功能正常性
电池回升	性能测试	通话结束后电池恢复情况

注：传统会采用Excel来编写和管理测试用例，但现在更倾向于采用敏捷模式。笔试中如涉及设计测试用例的题目，就需要按照Excel的方式来编写测试用例。而在面试中，则可以通过脑图或思维导图来进行阐述。

🕒 4. 软件错误Bug的概念

1、当且仅当规格说明是存在且正确的，程序与规格说明之间的不匹配才是错误。

规格说明：也就是软件需求、需求文档、产品规格说明书，是产品经理写的。

2、当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

🕒 5. Bug描述

一个有效的bug报告应该包含以下几个关键部分：

1. 发现问题的软件版本：

开发人员需要知道出现问题的版本，才能够获取对应版本的代码来进行故障复现。版本标识还有助于对每个版本的质量进行统计和分析。

2. 出现问题的环境：

包括硬件和软件环境。对于Web项目，应详细说明浏览器版本和客户端操作系统；对于App项目，应描述具体机型、分辨率和操作系统版本。这有助于快速定位问题。

3. 重现错误的步骤：

提供重现问题的最简步骤。

4. 预期的正确行为：

描述用户角度下程序应有的正确行为。如果问题基于特定需求，明确指出需求来源是最佳做法。

5. 实际的错误行为：

详细描述错误现象。对于crash，可以上传日志；对于UI问题，可以提供截图。

6. 其他信息：

根据公司政策，可能需要额外信息，如故障分类（功能、界面、兼容性故障等）和优先级（对测试影响大的故障应标记为高优先级）。

7. 单独报告每个bug：

除非确认多个问题由同一代码段引起，否则应分别报告每个bug。

案例：

故障发现版本：V6.1.0
故障类别：兼容性
故障优先级：中
故障标题：登录主界面显示异常，界面图标元素丢失
故障描述：

• 测试环境：win11
• 测试步骤：1、打开阿里云盘，扫码登录成功后进入首页。2、点选任意文件夹。
• 预期结果：首页元素显示正确，工具栏侧栏图标文字均正常。
• 实际结果：首页图标元素丢失，但文字显示正常。

附件：上传截图

🕒 6. Bug级别

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

以下为样例：

1. Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2. Critical（严重）

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3. Major（一般）：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等（该问题实际测试中存在最多）

4. Minor（次要）：

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

注：不同的Bug等级，惩罚机制不一样，也跟开发人员的开发质量有直接关系，也就是开发能力。

测试人员要先检查项目是否具有可测试性：冒烟测试

• 如果该项目有明显/主功能错误，或者是主流程走不通，测试人员进行项目的打回。
• 在测试人员测试之前，开发人员要进行单元测试、集成测试。

🕒 7. Bug的生命周期

测试人员在执行测试的过程中，如有发现Bug，就需要在Bug管理平台来创建Bug。（Bug生命起源）

Bug状态转换图：

1. New：测试人员新发现的Bug，未经评审决定是否指派给开发人员进行修改。
2. Open：开发人员要去确认是否是Bug，是Bug则状态改为Open，不是就拒绝（Reject）。
3. Fixed：开发人员在修复完成之后将Bug状态改为Fixed。
4. Rejected：开发人员确认不是Bug。
5. Delay：确认是Bug之后，如果Bug优先级比较低且开发人员不能立即修复Bug，状态修改为delay。
6. Closed：Bug确认修复完成之后，测试人员将Bug状态修改为closed。
7. Reopen：Bug确认未修复完成，测试人员将Bug状态改为reopen。

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

【面试题】跟开发起争执怎么办？

原则：对事不对人

1. 批判性思维：多反思自己，是不是Bug创建的时候描述不清楚
2. 规范定级：开发人员如果对Bug级别不认可，对Bug定级一定要有理有据；测试人员要明确企业Bug定级规范，拿着规范跟开发人员沟通为什么要这样定级。
3. 用户视角：提Bug必定会增加开发人员的工作量，如果对于小问题开发人员不想改，此时就需要合理友好地进行沟通，站在用户的角度进行反问。
4. 提供解决方案：不仅要能够发现问题，还要能够适宜地提出解决方案供开发参考，但是注意不能喧宾夺主。如果确实是Bug，并且友好沟通已经不能解决问题，此时就召开Bug评审。（参会人员：产品代表、开发代表、测试代表…）

---

OK，以上就是本期知识点“软件测试概念篇”的知识啦~~ ，感谢友友们的阅读。后续还会继续更新，欢迎持续关注哟📌~
💫如果有错误❌，欢迎批评指正呀👀~让我们一起相互进步🚀
🎉如果觉得收获满满，可以点点赞👍支持一下哟~

❗ 转载请注明出处
作者：HinsCoder
博客链接：🔎 作者博客主页