软工测试复习

软件测试基础1.为什么要进行软件测试？——为了保证软件质量“程序测试是为了发现错误而执行程序的过程”。

测试的目的是发现程序中的错误，是为了证明程序有错，而不是证明程序无错。

在软件开发过程中，分析、设计与编码等工作都是建设性的，惟独测试是带有“破坏性”，测试可视为分析、设计和编码3个阶段的“最终复审”，在软件质量保证中具有重要地位。

2.软件质量的内涵总结说来，高品质软件应该是相对的无产品缺陷(bug free)或只有极少量的缺陷，它能够及时递交给客户，所花费用都在预算内，并且满足客户需求，是可维护的。

但是，有关质量好坏的最终评价依赖于用户的反馈3.软件缺陷的定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

4.软件错误产生的可能原因是：1)需求规格说明书包含错误的需求、或漏掉一些需求，或没有准确表达客户所需要的内容2)需求规格说明书中有些功能不可能或无法实现3)系统设计(system design)中的不合理性4)程序设计中的错误5)程序代码中的问题，包括错误的算法、复杂的逻辑等5.软件缺陷的种类:按照严重性级别的定义不尽相同，但一般可以概括为4种类型：1)致命的(fatal)：致命的错误，造成系统或应用程序崩溃(crash)、死机、系统悬挂，或造成数据丢失、主要功能完全丧失等。

2)严重的(critical)：严重错误，指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，提示信息不太准确，或致命的错误声明3)一般的(major)：不太严重的错误，这样的软件缺陷虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预期效果。

如次要功能丧失，提示信息不太准确，或用户界面差，操作时间长4)微小的(minor)：一些小问题，对功能几乎没有影响，产品或属性仍可使用，如有个别错别字、文字排列不整齐等。

5)此外，有时还需要“建议(Suggestion)”级别来处理测试人员所提出的建议或质疑。

6.软件缺陷的状态软件缺陷除了严重性以外，还存在反映软件缺陷处于一种什么样的状态，便于跟踪和管理某个产品的缺陷，可以定义不同的bug状态：1)激活状态(Active或Open)：问题没有解决，测试人员新报的bug，或验证后bug依然存在2)已修正状态(Fixed或Resolved)：开发人员针对所存在的缺陷，修改程序，认为已解决问题，或通过单元测试3)关闭或非激活状态(Close或Inactive)：测试人员验证fixed bug后，确认bug不存在之后的状态。

此外，还有下面一些中间状态：4)保留(Hold)：bug目前无法解决或是由第三方软件产品引起的5)延期(Differed):bug暂时不需要解决或在下一版本中解决更彻底一些7.软件缺陷产生的主要原因：1)技术问题主要包括：算法错误、语法错误、计算和精度问题、系统结构不合理、算法不科学，造成系统性能低下、接口参数传递不匹配，导致模块集成出现问题2)团队工作对客户的需求不是十分清楚，或者和用户的沟通存在一些困难；开发人员相互理解不一致；设计或编程上的一些假定或依赖性，没有得到充分的沟通3)软件本身文档错误、用户使用场合(user scenario)，时间上不协调、或不一致性所带来的问题。

系统的自我恢复或数据的异地备份、灾难性恢复等问题8.软件缺陷的构成在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。

规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会逐步发现，而不能在需求分析一个阶段发现9.软件缺陷的发现随着时间的推移带来的成本越来越大。

(8,9结合作业)10.评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。

检验工作产品是否正确地满足了以往工作产品中建立的规范。

11.软件测试的分类根据测试过程中被测软件是否被执行，分为静态测试和动态测试12.软件测试模型：V模型(书P67)13.软件测试的工作范畴1)软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。

2)测试工作的实施：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动。

14.测试工作流程15.执行测试主要有下列一些活动：1)建立必要的测试环境2)按照所写的测试用例，编写测试脚本3)根据测试对象和目的，构造测试用例的集合4)运行测试脚本或手工按测试用例进行5)记录测试结果6)结果比较分析，找出软件缺陷7)将软件缺陷记录到缺陷数据库中，清楚地描述该缺陷8)跟踪和管理软件缺陷9)验证被处理的软件缺陷，并进行回归测试10)对测试过程进行管理，保证测试工作执行的正确性，实现资源调拨和相关合作方的协调。

对测试中的问题进行全程跟踪16. 在单元测试阶段，主要用白盒测试方法设计测试用例；在功能测试阶段，主要用黑盒测试方法来设计测试用例。

17.白盒法常用的覆盖标准(PPT 第三章P18-38)18. 黑盒测试方法(PPT 第三章P40-88)19. 单元测试的定义1)定义:单元测试是对软件基本组成单元进行的测试。

2)测试对象：软件设计的最小单位-模块。

3)时机:一般在代码完成后由开发人员完成,QA人员辅助。

4)过程:在详细设计阶段完成单元测试计划。

建立单元测试环境，完成测试设计和开发。

执行单元测试用例，并且详细记录测试结果。

判定测试用例是否通过。

提交《单元测试报告》。

20. 单元测试的目标和任务1)主要目标：确保各单元模块被正确地编码2)单元测试的主要任务有：程序语法检查、程序逻辑检查、模块接口测试、局部数据结构测试、路径测试、边界条件测试、错误处理测试、代码书写规范检查。

21. C++Test 实验报告22. 静态测试的方法?23. 集成测试，也叫组装测试或联合测试。

在单元测试的基础上，将所有模块按照设计要求（如根据结构图）集成为子系统或系统，进行集成测试24. 集成测试基本可以概括为以下两种：1)非渐增式测试模式（一次性集成）：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。

2)渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

3)非渐增式测试模式优缺点：工作量较小；发现模块间接口错误较晚；发现错误较难诊断，可以并行测试。

4)渐增式测试模式优缺点：要编写的软件较多，工作量较大；发现模块间接口错误较早；测试执行更彻底；需要较多的机器时间。

25. 驱动程序和桩程序1)驱动程序/驱动模块（driver），用以模拟被测模块的上级模块。

驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块。

2)桩程序/桩模块（stub），也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。

桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口。

26. 自顶向下法自顶向下法，从主控模块(主程序)开始，沿着软件的控制层次向下移动，逐渐把各个模块结合起来。

组装过程可以采用深度优先策略和宽度优先策略优点：1)不需要测试驱动程序；2)能够在测试阶段的早期实现并验证系统的主要功能；3)能在早期发现上层模块中的接口错误。

缺点：1)需要桩程序，要使桩模块能够模拟实际子模块的功能十分困难；2)同时涉及复杂算法，真正输入/输出的模块一般在底层，他们是最容易出问题的模块，到测试和集成的后期才遇到这些模块，一旦发现问题导致过多的回归测试。

27. 自底向上法自底向上法，测试从原子模块(软件结构最底层的模块)开始集成以进行测试1)优点：不需要桩程序；同时由于涉及到复杂算法和真正输入/输出的模块最先得到集成和测试，可以把最容易出问题的部分在早期解决；自底向上增值的方式可以实施多个模块的并行测试，提高测试效率。

2)缺点：“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。

也就是说，在自底向上集成和测试的过程中，对主要的控制直到最后才接触到。

28. 大棒集成方法1)采用大棒集成方法,先是对每一个子模块进行测试（单元测试阶段），然后将所有模块一次性的全部集成起来进行集成测试。

2)因为所有的模块一次集成的，所以很难确定出错的真正位置、所在的模块、错误的原因。

只适合在规模较小的应用系统中使用。

29. 三明治集成方法1)三明治集成方法自两头向中间集成。

2)采用三明治方法的优点是：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。

采用这种方法的主要缺点是：在真正集成之前每一个独立的模块没有完全测试过。

30. 集成测试过程主要参与角色：1)项目软件经理(开发负责人):负责审批测试计划;评审测试用例。

2)测试人员:负责完成测试用例设计、集成测试环境搭建、执行集成测试、记录测试、撰写测试报告。

系统测试包括：功能测试、压力测试、容量测试、性能测试、安全性测试、健壮性（容错）测试、GUI测试、安装测试、故障转移与故障恢复测试、备份测试、兼容性测试、回归测试、易用性测试、文档测试、在线帮助测试、数据转换测试等。

32. 功能测试1)功能测试，是在系统集成过程中和系统集成之后所进行的系统功能测试，不仅要考虑模块之间的相互作用，而且要考虑系统的应用环境，其衡量标准是实现产品规格说明书上所要求的功能。

2)根据产品规格说明书，检验系统是否满足各方面功能的使用要求33. 回归测试?非功能性测试34. 性能测试1)性能测试的目的：为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

2)主要的性能指标：服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间35. 压力测试1)压力测试是在一种需要反常数据、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。

本质上说，测试者是想破坏程序。

2)压力测试是对异常情况的检测，异常情况主要指的是峰值、大量数据的处理能力、长时间运行等情况。

压力测试总是迫使系统在异常的资源配置下运行。

36. 容量测试1)容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项特征极限值，系统在其极限值状态下还能保持主要功能正常运行。

容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

2)容量测试完成的标准可以定义为：所计划的测试已全部执行，而且达到或超过指定的系统限制时没有出现任何软件故障。

压力测试、容量测试和性能测试的测试目的虽然有所不同，但其手段和方法在一定程度上比较相似，通常会使用特定的测试工具，来模拟超常的数据量、负载等，监测系统的各项性能指标，如CPU和内存的使用情况、响应时间、数据传输量等。