【软测】软件测试的基本概念

软测的基本概念

1. 软件测试的基本概念

📌 1.1 什么是软件测试

食品、药品需要检测，软件产品也需要检测，软测是为了防止服务中止、服务质量下降，甚至是社会动荡。从起初的调试到后来的证真（证实软件能够按照预期运行）、证伪（测试软件是为了发现错误），归根到底都是一个目的，那就是保证软件质量。

软件测试的对象是软件，包含程序、数据和文档，大量的测试活动需要支持测试的环境，包括软件的运行环境、测试环境，以及软件以外的软硬件环境、数据环境、网络环境、应用环境。这些环境不仅会给测试提供支持，也会影响测试结果。

📌1.2 验证与确认

官方术语
验证：通过提供客观证据来证实规定需求已经得到满足。
确认：通过提供客观证据来证实针对某一特定预期用途或应用需求。

通俗来说，验证就是看你做的是否满足产品要求，确认是看你做的是否满足用户的特定需求

📌1.3 软件缺陷

软件缺陷是什么（Bug）

错误、问题、异常、故障、失效、偏差等，词汇有一定区别，但一般没有将它们区分的十分清晰，混合使用也不影响软件的工程活动。
错误：软件缺陷的静态表现，是存在于软件中的一种小缺陷
故障：软件缺陷的动态表现，是因为软件的缺陷造成软件工作时出现的问题
失效：软件因缺陷而导致的结果

软件缺陷产生的原因

软件是团队合作的成果，基于每个人的理解思维能力的局限性、团队的沟通和工作规范化等方面原因，加上技术因素，软件出现缺陷的概率很高。
需求分析阶段（产生软件缺陷的比例>40%）：需求本身不够明确、需求变化频繁、用户的需求表述不够准确、需求工程师和用户的沟通问题
设计阶段（产生软件缺陷的比例>30%）：需求的获取方式、文档化工作和质量、需求确认造成的
编码阶段（产生软件缺陷的比例<30%）：在开发工程师调试程序时就能暴露许多缺陷

软件缺陷的分类

属性很多，包括缺陷的状态、优先级、严重性、发生概率等20余项，但对于软件缺陷的处理，应该根据缺陷的严重性和优先级进行，同时也考虑缺陷的其它属性。

表1-1 缺陷的优先级

属性值	描述
紧急	需要立刻处理
高	应在下一个可运行版本中解决
中	应在第一个交付版本中解决
低	期望在第一个交付版本中解决（在第一个交付版本后升级到优先级“中”）
无	无需再第一个交付版本中解决

表1-2 缺陷的严重性

属性值	描述
阻塞	在纠正或发现合适的方法之前，测试无法进行
严重	主要操作被打乱，导致安全性受到影响
一般	主要操作受到影响但软件产品仍能继续运行
轻微	非主要操作受到影响
可忽略	操作未受到影响

📌1.4 测试与质量保证

官方表述
质量保证（QA）：以保证各项质量管理工作实际地、有效地进行与完成为目的的活动体系

通俗来讲，质量保证就是确保产品或服务按照规定标准生产或提供，并且达到客户期望的质量水平。

软件测试与质量保证的关系

包含关系：软件测试是实现质量保证的方式之一

📌1.5 测试用例

官方表述
测试用例：为某个特定目标而开发的输入、执行条件以及预期结果的集合

说白了，就是测试人员根据特定目标去设计，设计内容要涵盖输入的测试数据、执行条件、逻辑过程、预期的逻辑结果（这些内容可以展现软件的具体运行场景），这个设计内容就是测试用例

测试用例对测试实施的重要作用

a、测试用例是测试实施的依据，测试人员应该根据测试用例进行测试，获取结果并进行判定
b、测试用例是根据测试目标设计出来的，在测试用例的指导下可以保证测试的规范性，提高测试效率，保证测试质量
c、企业软件的开发迭代需要频繁的回归测试，建立、维护良好的测试用例库，测试用例的复用可以提高回归测试的效率，降低企业成本

【回归测试】: 在软件或系统发生变化后，重新运行已经通过测试的测试用例，以确保软件或系统在更改后仍能够正常工作

官方软件测试用例模板

包含用例名称、用例标识、测试追踪、用例说明、环境说明、操作过程、各种条件、评价准则、建立用例的人员和时间等信息，其中操作过程要描述每一步操作的输入数据、过程说明、预期结果和通过准则等。在设计测试用例的时候，要考虑用例对测试的覆盖情况，例如测试的功能、性能、可用性、安全性等方面，避免出现较大的遗漏，也要考虑用例的大小、是否可判定、是否具有可操作性。

测试用例与测试脚本的关系

测试脚本是一段程序代码，可以自动化执行测试用例。因为测试脚本中的代码就是描述了测试用例中应该如何执行的具体步骤和操作，测试工具可以执行测试脚本来模拟测试用例中的交互和操作，然后检查软件是否按照预期的方式运行，并将测试结果报告给测试人员。

测试脚本通常由测试工程师编写，并且在自动化测试过程中使用。测试脚本可以模拟用户的操作，自动化执行各种测试任务，比如输入数据、点击按钮、检查结果等等。当然，也可以通过自动化测试工具录制测试操作生成测试脚本，例如Selenium IDE。

📌1.6 测试策略

测试策略是需要平衡测试时间、测试成本、测试人力、质量要求之间的关系，达到最佳的测试效果，从而实现最大化的测试投入产出比。

测试策略的输入

测试所需软硬件资源的详细说明；
针对测试和进度约束，需要的人力资源的角色和职责；
测试方法、测试标准和完成标准；
目标系统的功能性和非功能性需求、技术指标；
系统局限(即系统不能够满足的需求)等

【功能性和非功能性需求】: 功能性需求是指系统必须具备的功能，例如用户登陆、数据查询等，通常是从用户或系统需求中提取的，是系统与外部环境的接口规定。非功能性需求则是指系统的非功能方面的要求，如性能、可用性、安全性、兼容性、可维护性等方面的需求。

测试策略的输出

已批准或审核的测试策略文档、测试用例、测试计划；
需要解决方案的测试项目

制定测试策略的过程

确定测试的需求
①测试需求必须是可观测、可测评的
②软件需求与测试需求以及测试用例不是一对一关系。
③测试需求可能有许多来源
评估风险并确定测试优先级
成功的测试需要在测试工作中权衡资源约束和风险。为了确定测试工作优先级，需执行风险评估和实施概要。
确定测试策略
一个好的测试策略应该包括：实施的测试类型和测试目标、实施测试的阶段、技术、评估测试结果和测试是否完成的标准、对测试工作存在影响的特殊事项等。

【不是一对一关系】: 软件需求和测试需求之间不是一一对应的关系，即有时候一个软件需求可能需要多个测试需求来验证，或者一个测试需求可能需要多个软件需求来满足。测试用例也不是一对一地对应于软件需求或测试需求，因为有时候一个测试需求可能需要多个测试用例来覆盖所有情况，或者一个测试用例可能覆盖多个测试需求或软件需求。