软件测试与软件维护 - 软考备战（二十五）

软件工程三参考资料单元测试从入门到精通 - jack_Meng - 博客园集成测试.pdf软件维护Software maintenance的流程 - hofmann - 博客园论软件维护方法及其应用-腾讯云开发者社区-腾讯云终于有人把Alpha测试和Beta测试讲明白了 - 知乎白盒测试及测试用例设计方法从入门到入土的完整指南 - 知乎软件测试的四个阶段单元测试、集成测试、系统测试、验收测试 - R-Bear - 博客园什么是α测试、贝塔β测试、伽马λ测试 - 知乎『软件测试1』你需要了解的软件测试基础知识对于一个软件来说总会存在各种各样的软件缺陷。因此我们需要通过软件测试来检查软 - 掘金『软件测试4』一文详解四大典型的白盒测试方法 - 掘金 - 飞书云文档『软件测试3』八大典型的黑盒测试方法已来袭快快接住有了软件缺陷的暴露我们就需要通过各种软件测试的方法来查找出软件的 - 掘金系统测试功能测试、性能测试、负载测试、压力测试、兼容性测试、安全测试、健壮性测试、配置测试、可用性测试、文档测试 - 知乎目录软件工程三4.3 软件测试与软件维护4.3.1 软件测试基础1. 测试的目的与准则2. 测试的分类维度4.3.2 测试阶段按过程划分1. 单元测试2. 集成测试3. 系统测试4. 确认测试验收测试4.3.3 测试技术与方法1. 白盒测试结构测试2. 黑盒测试功能测试4.3.4 软件维护1. 软件维护的类型纠错性维护改正性适应性维护完善性维护预防性维护2. 软件的可维护性决定因素可理解性可测试性可修改性可靠性3. 软件维护的副作用4. 逆向工程与再生工程4.3 软件测试与软件维护4.3.1 软件测试基础1. 测试的目的与准则目的发现错误注意测试的目的不是证明程序“没有错误”而是尽可能多地暴露潜在缺陷。黄金准则测试能证明缺陷存在但不能证明缺陷不存在。穷尽测试是不可能的需利用风险分析和优先级进行测试。尽早测试缺陷发现得越晚修复成本呈指数级上升。杀虫剂悖论反复使用相同的测试用例将无法发现新Bug需定期评审和修改测试用例。2. 测试的分类维度具体测试方法链接软件测试学习文档三-CSDN博客静态测试 vs 动态测试静态测试不实际运行被测软件只是静态地检查程序代码、界面或文档如代码走查、文档审查。动态测试实际运行被测程序输入测试用例观察输出并与预期结果比对。黑盒测试 vs 白盒测试详见4.3.3节对比项黑盒测试白盒测试关注点外部功能内部结构测试依据需求规格说明书源代码测试方法穷举输入测试穷举路径测试适用阶段全测试阶段主要单元测试阶段优势从用户角度验证深入代码逻辑验证劣势无法测试内部逻辑无法验证需求符合度测试人员测试工程师通常开发人员比喻汽车买家试驾汽车工程师拆解发动机检查4.3.2 测试阶段按过程划分具体软件过程模型链接软件测试学习文档一-CSDN博客测试过程通常呈现“V模型”对应关系需求 ↔确认测试概要设计 ↔系统测试详细设计 ↔集成测试编码 ↔单元测试1. 单元测试对象最小可测试单元模块、函数、类。依据详细设计说明书。内容模块接口、局部数据结构、重要执行路径、错误处理、边界条件。人员通常由程序员自己或白盒测试工程师完成多用白盒测试方法。辅助工具桩模块Stub模拟被调用模块和驱动模块Driver模拟调用模块。2. 集成测试对象将已测试的单元模块组装起来进行测试重点检查接口和全局数据结构。依据概要设计说明书。内容集成测试划分为5个阶段,即计划阶段、设计阶段、实施阶段、执行阶段、评估阶段。组装策略自顶向下从主程序开始不需驱动模块但需要大量桩模块。自底向上从底层模块开始不需桩模块但需要大量驱动模块。大爆炸集成一次性组装所有模块适合极小系统。3. 系统测试对象将整个软件系统与硬件、外设、操作系统等结合在实际运行环境下进行测试。依据需求规格说明书。内容测试类别主要内容核心目标功能测试业务逻辑验证、需求校验确认系统“做什么”非功能测试性能、安全、兼容性等确认系统“做得怎么样”重点分类测试类型目的典型指标负载测试验证正常负载下表现响应时间、TPS压力测试验证极限承载能力崩溃点、错误率稳定性测试长时间运行表现内存泄漏、资源占用容量测试最大可支持用户数并发上限功能测试验证功能是否正常。性能测试响应时间、吞吐量。负载测试在一定资源下系统能承受的最大并发用户数。压力测试突破系统极限资源看系统何时崩溃及恢复能力。恢复测试测试系统在崩溃后能否安全恢复。4. 确认测试验收测试目的验证软件是否满足用户的业务需求决定是否接收系统。分类Alpha测试在开发者的环境下由用户进行测试模拟实际操作环境。Beta测试软件发布前在用户的实际运行环境下由最终用户进行测试开发者通常不在场。4.3.3 测试技术与方法1. 白盒测试结构测试核心完全了解程序内部结构和逻辑针对语句和路径进行测试。逻辑覆盖标准由弱到强排序1.语句覆盖每条语句至少执行一次。最弱漏洞最多2.判定覆盖分支覆盖每个判定的真/假分支至少执行一次。3.条件覆盖每个判定中的每个独立条件至少取真/假一次。4.判定/条件覆盖同时满足判定覆盖和条件覆盖。5.条件组合覆盖每个判定中所有条件的各种可能组合都至少执行一次。强但测例数量爆炸6.路径覆盖程序中所有可能的执行路径都至少执行一次。最强但不一定能满足判定覆盖基本路径测试通过计算程序的环形复杂度McCabe圈复杂度导出基本路径集合设计测试用例。2. 黑盒测试功能测试核心把软件看作一个打不开的黑盒子只关心输入和输出不关心内部逻辑。四大经典方法1.等价类划分将输入域划分为若干“等价类”假设同类中的任何一个输入都能揭露相同问题。分为有效等价类、无效等价类。2.边界值分析错误往往发生在边界上。基于等价类重点测试边界及边界附近的值。如输入范围1-100应重点测0, 1, 2, 99, 100, 101。3.错误推测法依靠测试人员的经验和直觉猜测程序中可能存在的各种错误针对性编写用例。4.因果图适用于输入条件之间存在相互组合和约束关系的复杂场景。通过画因果图最终转换为判定表来设计用例。4.3.4 软件维护1. 软件维护的类型纠错性维护改正性改正开发阶段遗留的错误和缺陷。占比通常最小约20%适应性维护适应外部环境变化如操作系统升级、数据库更换而进行的修改。完善性维护扩充功能、提升性能、优化界面。占比最大通常占50%以上是软件进化的主力预防性维护为了提高软件未来的可维护性和可靠性主动进行的重构或代码优化。2. 软件的可维护性决定因素可理解性可测试性可修改性可靠性注意提高可维护性的根本途径是在需求分析和设计阶段就打好基础如采用高内聚低耦合架构、完善文档而不是等到维护阶段再去补救。3. 软件维护的副作用副作用修改代码或数据时由于牵一发而动全身可能引入新错误。代码副作用修改代码逻辑时引发的错误。数据副作用修改数据结构如修改全局变量、数据库表结构导致软件不兼容。文档副作用只改了代码没有同步更新文档导致后续维护人员误解。这是最常见、最容易犯的副作用。4. 逆向工程与再生工程针对无文档或少文档的“遗留系统”。逆向工程从源代码反推出现象模型或设计模型相当于“反编译”逻辑。再生工程在逆向工程的基础上重新构建系统以提升性能或可维护性通常结合软件重构技术。