软件测试Ultimate笔记【软件测试基础篇】：一篇搞懂，备考无忧

软件测试基础从“第一只Bug”到测试原则1947年一只飞蛾钻进哈佛马克二型计算机引发了人类历史上第一个“Bug”……七十年后的今天软件测试早已从“捉虫”演变为贯穿生命周期的系统工程。本文带你系统梳理软件测试的核心知识体系历史发展、经典模型、缺陷管理、质量衡量、测试原则……筑基必备收藏多多文章目录软件测试基础从“第一只Bug”到测试原则[toc]1. 软件测试的历史发展2. 软件测试的对象3. 软件测试模型 V模型 W模型 X模型 H模型 敏捷测试模型4. 软件开发模型5. ⏳ 软件生命周期6. 软件缺陷缺陷分类缺陷参数 管理缺陷生命周期7. 软件质量质量保证 vs 质量控制使用质量用户视角8. 测试用例测试用例要素设计基本原则测试用例管理工具9. 软件测试的分类按阶段按自动化程度按测试方法按测试目的10. ⚙️ 软件测试的流程测试基本过程测试报告主要内容测试结束标准基于客观度量11. 软件测试的原则12. 软件评审评审的好处正式评审角色测试用例评审目的主持人职责 后续预告✨ 写在最后1. 软件测试的历史发展1947年世界上第一个计算机 bug 被发现——一只飞蛾进入哈佛马克二型计算机导致故障此后“Bug”成为软件缺陷的代名词。IEEE 软件工程定义使用人工或自动手段运行或测试某系统的过程目的在于检验其是否满足规定需求或弄清预期结果与实际结果间的差别。2. 软件测试的对象-1.阶段性文档源代码、设计文档、需求/用户说明书 等……-2.程序本身3. 软件测试模型 V模型描述测试与开发阶段对应需求分析 → 设计 → 编码 → 单元测试 → 集成测试 → 系统测试 → 验收测试 W模型强调测试与软件开发同步进行测试对象不仅仅只是程序测试与开发同步进行。二者缺陷v模型与w模型都以软件开发为中心无法支持迭代、自发性及变更调整。 X模型V模型的改进对单独的程序片段进行相互分离的编码测试能发现更多错误但费时费力。 H模型测试完全独立于开发流程贯穿生命周期可随时根据需求执行测试适用于迭代开发。 敏捷测试模型测试贯穿每个迭代强调持续反馈和协作。“开发未动测试先行”4. 软件开发模型瀑布模型线性顺序开发测试阶段位于开发后期变更成本高。快速原型模型需求分析 → 构建原型 → 原型评价 → 循环确定要求。迭代模型分阶段迭代开发每个迭代都包含测试便于风险控制又称增量模型/进化模型。螺旋模型结合迭代和风险分析每个循环包括规划、风险分析、开发和测试。敏捷开发以用户需求为核心通过短周期迭代和持续交付测试全程参与。5. ⏳ 软件生命周期问题定义 → 可行性分析 → 总体描述 → 系统设计 → 编码 → 调试和测试 → 验收与运行 → 维护升级 → 废弃6. 软件缺陷定义软件中存在的与预期行为不符的问题包括功能错误、性能低下、界面问题等。为软件可靠性的特性和变化趋势提供判断依据。缺陷越早发现修复成本越低软件维护阶段成本最高。需求规格说明书是导致软件缺陷的最大原因。Bug管理流程中“重新打开”表示旧缺陷在新版本中重新出现。缺陷的集群现象已发现错误较多的模块残存错误通常也较多符合二八定律。缺陷分类维度类型举例按严重程度致命、严重、一般、次要按优先级立即解决、高、正常排队、低按阶段需求、设计、编码、测试等阶段按种类功能、性能、安全、兼容性、用户体验缺陷参数 管理缺陷参数状态、严重性、起源、优先级、类别、参与人员、产生版本缺陷管理工具JIRA、Bugzilla、禅道等缺陷分析方法缺陷趋势报告、分布报告、年龄报告缺陷生命周期新建 → 分配 → 修复 → 验证 → 关闭缺陷状态激活状态、已修正状态、关闭或非激活状态7. 软件质量定义软件满足明确和隐含需求的程度。ISO 25010 质量特性功能性、可靠性、可使用性、效率、可维护性、可移植性GB/T 软件产品使用质量特性有效性、生产率、安全性、满意度CMM/CMMI 能力成熟度模型初始级 → 可重复级 → 已定义级 → 管理级 → 优化级质量保证 vs 质量控制QA质量保证过程导向通过流程改进预防缺陷QC质量控制产品导向通过测试和审查发现缺陷使用质量用户视角有效性、生产率、安全性、满意度8. 测试用例为特定测试目标设计的一组输入、执行条件和预期结果。从需求分析阶段开始设计。测试用例要素用例ID、描述、前置条件、测试步骤、预期结果、实际结果、优先级……设计基本原则用例的代表性、结果的可判定性、结果的可再现性、实用性测试用例管理工具TestLink、XMind 等9. 软件测试的分类按阶段单元测试、集成测试、系统测试、验收测试回归测试、Alpha/Beta 测试按自动化程度手工测试 / 自动化测试按测试方法黑盒测试关注功能不关注内部结构白盒测试关注内部逻辑和代码覆盖灰盒测试结合黑盒和白盒方法按测试目的功能测试验证功能是否符合需求性能测试负载测试、压力测试、并发测试等回归测试确保修改后原有功能不受影响兼容性测试验证在不同平台、浏览器、设备上的表现安全测试检查漏洞和权限控制10. ⚙️ 软件测试的流程需求分析→ 制定系统测试计划测试计划→ 确定范围、目标、策略、资源、进度、风险 → 输出《测试计划文档》测试设计→ 编写测试用例准备数据与环境 → 输出《测试用例》《测试脚本》《测试数据》测试执行→ 运行用例记录结果识别缺陷缺陷跟踪与管理→ 报告缺陷并跟踪至关闭执行回归测试 → 输出《缺陷报告》测试分析、评估与总结报告→ 统计缺陷、评估覆盖率与质量 → 输出《测试报告》测试基本过程策划 → 设计 → 执行 → 总结测试报告主要内容测试效果评估、软件质量评价、系统 bug 分析、测试计划执行情况测试结束标准基于客观度量✅ 单位时间内故障数目低于预定值✅ 执行完所有测试用例且没有新故障❌ 资源不足如人员短缺不能作为结束标准⚠️ 测试超过预定时间可作为参考但需结合质量评估11. 软件测试的原则原则说明测试显示缺陷存在测试不能证明软件无缺陷只能揭示存在的缺陷基于用户需求测试必须以用户需求为中心测试贯穿整个生命周期从需求到维护持续进行穷尽测试不可能基于风险和优先级选择用例尽早进行测试尽早开始以降低修复成本缺陷集群性 / 二八定律少数模块通常包含大多数缺陷自动化不能完全替代手工探索性测试、可用性测试等仍需人工杀虫剂悖论重复相同的测试用例会失效需定期更新用例测试环境接近用户环境干净无毒真实模拟测试上下文相关不同项目、行业、平台需要不同的测试策略无错误谬误即使无缺陷也可能不满足用户需求和期望12. 软件评审评审的好处尽早发现缺陷、改善开发能力、缩短开发时间、缩减测试成本正式评审角色作者、评审员、记录员测试用例评审目的提高测试覆盖率、预防缺陷、确保需求可追溯性而不是直接寻找软件缺陷主持人职责主持评审活动引导讨论确保评审有效 后续预告系列文章链接持续更新中第二篇 黑盒测试即将发布告别点点点成为设计用例的高手第三篇 白盒测试即将发布还有更多…关注我第一时间获取更新✨ 写在最后如果本文对你有帮助欢迎点赞、收藏、评论转载引用请标明原作者(╹ڡ╹ )