软件测试基础学习
注意：
各位同学们，今年本人求职目前遇到的情况大体是这样了，开发太卷，学历高的话优势非常的大，公司会根据实际情况考虑是否值得培养（哪怕技术差一点）；学历稍微低一些但是技术熟练的话也不会缺少offer！
为了能拿到满意offer,努力学习吧！！！
基本概念
自动化测试，也叫软件测试自动化。要学习软件测试自动化，首先就需要清楚什么是软件测试。
软件测试
因为当局者迷，旁观者清的道理，软件开发是个复杂而周期性的过程，期间很容易产生或遗留下错误，而对于开发人员自己所编写与开发的应用程序（软件），往往有很多问题是他们自己发现不了，所以如果直接把存在不足的、有错误、有漏洞的应用程序直接运营上线提供给用户使用，那么很可能会给企业带来商业风险或影响企业受益，所以就需要软件测试人员进行软件测试了。
而软件测试（Software Testing）就是为了尽快尽早地发现软件的各种软件缺陷而展开的贯穿整个软件生命周期、对软件（包括阶段性产品）进行验证和确认的活动过程。这个过程是在规定的条件下对程序进行测试操作并对其是否能满足设计要求进行评估，以达到发现、纠正程序错误，衡量和提升软件质量的目的。通俗点说，软件测试就是通过各种各样的手段或工具来尽可能的找到软件的不足和错误。
软件测试只能查找出软件中的错误或不足，但不能证明程序中没有错误，而且软件测试不能完全消灭软件的错误，只能尽早尽量多的发现软件中的错误与不足。
软件生命周期是指从软件产品的可行性分析到软件不再使用而结束的时间。如果把软件看成是有生命的事物，那么软件的生命周期可分为6个阶段：需求分析、计划、设计、编码开发、测试、运行维护
测试分类
软件测试从不同的角度有着不同的分类方式。
在实际开发中，往往我们都是根据实际情况采用多种不同的测试手段、测试方式来对软件测试测试的。
软件缺陷
软件缺陷，通常又被叫做bug或者defect，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在的最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求。
-
从产品内部来说，软件缺陷是软件产品开发或维护过程中所存在的错误、误差等各种问题。
-
从产品外部来说，软件缺陷是系统所需要实现的某种功能的没有或不足。
出现原因
bug出现的原因一般有如下几种情况，也就是说符合以下情况的问题都属于bug：
| 原因 | 描述 |
|---|---|
| 功能遗漏 | 软件未实现用户或产品需求要求的或应有的功能。 |
| 异常错误 | 软件出现了不应该出现的错误。 |
| 功能冗余 | 软件出现了用户或产品需求没有要求的功能。 |
| 体验度低 | 软件的使用过程过于复杂或难以理解、软件运行缓慢导致用户体验不好。 |
缺陷管理
缺陷管理也叫bug管理，一般会集成到项目管理工具中，常用的项目管理工具：Teambition、禅道、pingcode、飞书、钉钉等。大部分的项目管理工具内置的缺陷管理功能都会对缺陷划分成不同类型、严重等级、优先级别，以及不同的状态。
缺陷类型
| bug类型 | 描述 |
|---|---|
| 功能缺陷 | 软件中的功能没有实现或不完善而导致 使用过程出现异常错误、逻辑错误等问题。 |
| 界面缺陷 | 用户界面外观缺失或不足，影响了用户正常使用的问题。 如：名称过长时被遮挡、文字部分被遮挡、图片只展示部分等。 |
| 需求缺陷 | 需求规格说明书未明确或存在遗留需求的问题。 |
| 性能问题 | 不满足系统可测量的属性值，如执行时间、处理速度等。 如：一个功能被用户使用时没有响应，或需要用户等待时间过久等。 |
| 接口缺陷 | 与其他组件、模块或程序、调用参数或参数列表等不匹配、出现冲突问题。 如传参个数与接口不匹配、传参类型与接口不匹配等。 |
| 兼容性缺陷 | 软件运行环境不匹配的问题 如操作系统、浏览器、网络环境等不匹配 |
| 易用性缺陷 | 新用户对软件难以快速熟悉或难以快速上手使用的问题。 |
| 代码错误 | 不满足需求、功能实现错误；对产品或项目质量有影响的bug |
| 配置相关 | 由于提供的配置不当或者配置不能够满足实际要求而出现的问题 |
| 安装部署 | 由于部署安装引起的问题 |
| 安全相关 | 出现安全隐患问题，如存在SQL注入，xss攻击等。 |
| 标准规范 | 不符合相关的国际、国家标准规范或业界规范等 |
严重等级
| 等级 | 描述 |
|---|---|
| 致命缺陷（S1） | 软件任何一个主要功能完全丧失，用户数据受到破坏，软件崩溃、 悬挂或者危及用户人身安全。如软件崩溃造成硬件设备漏电等 |
| 严重缺陷（S2） | 软件的主要功能部分丧失，数据不能保存，软件的次要功能完全丧失， 系统所提供的功能或服务受到明显的影响。如软件的某个菜单不起作用 |
| 一般缺陷（S3） | 软件的次要功能没有完全实现，但不影响用户的正常使用。 如软件内的某些内容输入有误或无法输入。 |
| 较小缺陷（S4） | 用户体验不好或操作不方便，但不影响功能使用和运行。 如软件内出现错别字或排版有问题等。 |
优先级别
| 优先级 | 描述 |
|---|---|
| 立即解决（P1） | 针对软件的致命缺陷，往往需要立即修复。 |
| 优先解决（P2） | 针对软件的严重缺陷，影响了测试，需要优先修复。 |
| 等候解决（P3） | 针对软件的一般缺陷，需要正常排队等待修复。 |
| 建议解决（P4） | 针对软件的较小缺陷，可以在开发人员有时间时再进行修复。 |
生命周期
从发现bug到关闭bug的这个时间段，我们称之为缺陷（bug）的生命周期。
在整个bug处理的流程上，一般会把bug划分成多个不同状态。
| 状态 | 描述 |
|---|---|
| 新建（New） | 当bug首次被发现时，测试人员会确认并记录下来，并将bug的状态为New |
| 已指派（Assigned） | 当bug被指认为New之后，将其传递给开发组，开发组将确认这是否是bug，如果是则开发组的leader会将bug指派给某位开发人员处理，并将bug的状态 设定为“Assigned”。 |
| 重新指派（Reassigned） | bug被重新指派给某位开发人员处理处理。 |
| 已打开（Open） | 一旦开发人员开始处理bug，就将bug的状态设为“Open”。 |
| 已修复（Fixed） | 当开发人员进行处理（并认为已经解决）之后，就可以将bug的状态设置为“Fixed”并将其提交给开发组leader，然后leader将bug返还给测试组。 |
| 等待再测试（Pending Reset） | 当bug被返还到测试组后，会将bug的状态设置为“Pending Reset” |
| 再测试(Reset) | 测试组的leader将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”。 |
| 已关闭的（Closed） | 如测试人员经过再次测试之后确认bug已被解决，会将bug的状态设置为 “Closed”。 |
| 再次打开的（Reopen） | 如果经过再次测试发现bug仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen” |
| 拒绝中（Pending Reject） | 如果测试人员传递到开发组的bug被开发组认为不是bug时，这种情况下开发组可以拒绝，将bug的状态设置为“Pending Reject”并返还给测试组。 |
| 被拒绝的(Rejected) | 测试组的负责人接到拒绝的bug时，如果发现并不能算作bug时，测试组负责人将bug的状态设置为“Rejected”。当然，无法重现，bug信息不足或重复的bug，有时候也会被拒绝。 |
| 延期（Postponed） | 对于一些特殊的bug的测试需要搁置一段时间，这种情况下，bug的状态就被设置为“Postponed“。 |
缺陷报告
缺陷报告，也叫bug报告，是软件测试人员重要的产出物之一，也是主要工作之一。一份高质量的缺陷报告可以帮助开发人员快速定位问题，修复Bug；也便于测试人员对缺陷进行统计、分析和跟踪管理，是测试人员和开发人员重要的沟通工具。开发中针对需求，测试bug，最怕的就是口口相传。
缺陷报告的基本组成：缺陷ID，缺陷标题，发现者，前置条件，是否可重现，操作系统，发现时间，所属项目，所属模块，所属版本，缺陷状态，严重等级，优先级别，附件描述，重现步骤，预期效果，实际效果等。注意：加粗部分为BUG六要素。
参考模板：
缺陷报告就是软件测试的结果产出物，而如何验证和测试缺陷？那就要继续往下学习更多内容了。
测试原则
| 原则 | 描述 |
|---|---|
| 测试显示软件存在缺陷 | 测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷，即零缺陷是不可能的。 软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。 |
| 穷尽测试是不可能的 | 现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。 测试人员可以根据严重等级、优先级、场景、目的来分类别进行集中和高强度的测试，从而保证软件的质量。 |
| 测试尽早介入 | 测试人员越早介入软件开发流程越好，最好在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现， 缺陷发现越早，修复的成本就越小，反之，越晚发现修复成本就越高。 |
| 缺陷存在集群现象（二八定律） | 80%的缺陷往往存在于20%的模块中。一般项目复杂功能往往会占据所有功能的20%左右，而这20%的复杂功能往往有可能会包含大部分的缺陷。一个功能模块发现的缺陷频率越高，那存在的未被发现的缺陷出现频率也越高，故发现的缺陷与未发现的缺陷成正比。 |
| 杀虫剂悖论 | 反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫，软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。 |
| 测试依赖于环境 | 测试在不同环境（操作系统，浏览器，解释器）下是不同的。所以不应该以完全相同的⽅法去测试两个不同的系统。 |
| 不存在缺陷的谬论 | 与第一条类似，期望仅仅发现并修复⼤量缺陷就能确保系统的成功，这是⼀个谬论。 |
测试自动化
著名的敏捷开发布道师 Mike Cohn（迈克·科恩） 在他的着作《Succeeding with Agile》(中文名：《Scrum敏捷软件开发》)一书中提出了测试金字塔的概念。
根据 Mike Cohn 的测试金字塔，测试的组合应该至少由以下三层组成 (自下往上分别是)：
-
单元测试（Unit Tests）
-
服务测试（Services Tests）
-
用户界面测试（UI Tests）
意思是，应该把测试不同粒度的测试分布到整个软件不同层次中，而随着层次越高，编写的测试内容应该越少，也就是写许多小而快的低层次单元测试，适当写一些更粗粒度的中层次接口测试或集成测试，写很少的高层次UI测试、系统测试或验收测试。
所以，根据测试金字塔理论，接下来我们按部就班对测试自动化的内容进行学习。
代码示例（昨天刚学的断言语句）：
# 以下是要测试的函数，这个函数将两个数字相加
def add_numbers(a, b):
return a + b
# 以下是单元测试的示例
import unittest
class TestAddNumbers(unittest.TestCase):
# 在setUp中进行一些初始化操作，如果需要的话
def setUp(self):
# 在这里可以添加一些准备工作，例如设置测试环境
pass
# 编写测试用例：测试两个正整数相加是否正确
def test_add_positive_numbers(self):
result = add_numbers(3, 5)
self.assertEqual(result, 8) # 使用assertEqual断言来检查结果是否等于预期值
# 编写测试用例：测试负数相加是否正确
def test_add_negative_numbers(self):
result = add_numbers(-2, -4)
self.assertEqual(result, -6)
# 编写测试用例：测试零相加是否正确
def test_add_zero(self):
result = add_numbers(0, 0)
self.assertEqual(result, 0)
# 在tearDown中进行一些清理操作，如果需要的话
def tearDown(self):
# 在这里可以添加一些清理工作，例如关闭测试环境
pass
if __name__ == '__main__':
unittest.main()
运行结果：
