软工测试复习.docx
《软工测试复习.docx》由会员分享，可在线阅读，更多相关《软工测试复习.docx（18页珍藏版）》请在冰点文库上搜索。
软工测试复习
软件测试基础
1.为什么要进行软件测试？
——为了保证软件质量
“程序测试是为了发现错误而执行程序的过程”。
测试的目的是发现程序中的错误，是为了证明程序有错，而不是证明程序无错。
在软件开发过程中，分析、设计与编码等工作都是建设性的，惟独测试是带有“破坏性”，测试可视为分析、设计和编码3个阶段的“最终复审”，在软件质量保证中具有重要地位。
2.软件质量的内涵
总结说来，高品质软件应该是相对的无产品缺陷（bugfree）或只有极少量的缺陷，它能够及时递交给客户，所花费用都在预算内，并且满足客户需求，是可维护的。
但是，有关质量好坏的最终评价依赖于用户的反馈
3.软件缺陷的定义：
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
4.软件错误产生的可能原因是：
1）需求规格说明书包含错误的需求、或漏掉一些需求，或没有准确表达客户所需要的内容
2）需求规格说明书中有些功能不可能或无法实现
3）系统设计（systemdesign）中的不合理性
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）：
测试人员验证fixedbug后，确认bug不存在之后的状态。
此外，还有下面一些中间状态：
4）保留（Hold）：
bug目前无法解决或是由第三方软件产品引起的
5）延期（Differed）:
bug暂时不需要解决或在下一版本中解决更彻底一些
7.软件缺陷产生的主要原因：
1）技术问题
主要包括：
算法错误、语法错误、计算和精度问题、系统结构不合理、算法不科学，造成系统性能低下、接口参数传递不匹配，导致模块集成出现问题
2）团队工作
对客户的需求不是十分清楚，或者和用户的沟通存在一些困难；
开发人员相互理解不一致；
设计或编程上的一些假定或依赖性，没有得到充分的沟通
3）软件本身
文档错误、用户使用场合（userscenario），时间上不协调、或不一致性所带来的问题。
系统的自我恢复或数据的异地备份、灾难性恢复等问题
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）测试人员:
负责完成测试用例设计、集成测试环境搭建、执行集成测试、记录测试、撰写测试报告。
3）开发人员:
将欲测试的内容集成到测试环境。
负责及时修复测试出的问题。
过程
工作结果
人员和职责
制定集成测试计划
集成测试计划
测试设计员负责制定集成测试计划（要经过评审）
设计集成测试
集成测试用例、测试过程
测试设计员依照测试计划设计集成测试用例，设计测试过程
实施集成测试
测试脚本（可选）、驱动程序或桩程序
测试设计员负责编制测试脚本（可选），搭建独立的测试环境（该环境可执行代码）
开发人员负责将已通过的单元测试的程序单元提交集成到测试环境中
执行集成测试
测试结果
测试员负责执行测试并记录测试结果
评估集成测试
测试评估摘要
测试设计员负责同编码员、设计员等有关人员评估此次测试，并生成测试评估摘要
31.系统测试包括：
功能测试、压力测试、容量测试、性能测试、安全性测试、健壮性（容错）测试、GUI测试、安装测试、故障转移与故障恢复测试、备份测试、兼容性测试、回归测试、易用性测试、文档测试、在线帮助测试、数据转换测试等。
32.功能测试
1）功能测试，是在系统集成过程中和系统集成之后所进行的系统功能测试，不仅要考虑模块之间的相互作用，而且要考虑系统的应用环境，其衡量标准是实现产品规格说明书上所要求的功能。
2）根据产品规格说明书，检验系统是否满足各方面功能的使用要求
33.回归测试?
非功能性测试
34.性能测试
1）性能测试的目的：
为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。
2）主要的性能指标：
服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间
35.压力测试
1）压力测试是在一种需要反常数据、频率或资源的方式下，执行可重复
的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。
本
质上说，测试者是想破坏程序。
2）压力测试是对异常情况的检测，异常情况主要指的是峰值、大量数据
的处理能力、长时间运行等情况。
压力测试总是迫使系统在异常的资
源配置下运行。
36.容量测试
1）容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项特
征极限值，系统在其极限值状态下还能保持主要功能正常运行。
容量测
试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
2）容量测试完成的标准可以定义为：
所计划的测试已全部执行，而且达到
或超过指定的系统限制时没有出现任何软件故障。
压力测试、容量测试和性能测试的测试目的虽然有所不同，但其手段和方法在一定程度上比较相似，通常会使用特定的测试工具，来模拟超常的数据量、负载等，监测系统的各项性能指标，如CPU和内存的使用情况、响应时间、数据传输量等。
36.故障转移测试
Failover测试:
故障转移（Failover）和故障恢复（Failback）.
服务器的Failover测试的目的:
检查系统是否具备某种灾难性恢复的手段.当系统局部或全部出错时,能否在指定时间内修正错误.具有良好故障恢复的系统,当遇到软件原因或无法克服的自然原因时,能够进行故障的转移与恢复.使用户最低限度的感受到故障的发生。
37.安全性测试
1）根据ISO8402的定义，安全性是“使伤害或损害的风险限制在可接受的水平内”。
2）安全性测试是检查系统对非法侵入的防范能力。
安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。
例如：
I.想方设法截取或破译口令；
II.专门开发软件来破坏系统的保护机制；
III.故意导致系统失败，企图趁恢复之机非法进入；
IV.试图通过浏览非保密数据，推导所需信息等等。
3）理论上讲，只要有足够的时间和资源，没有不可进入的系统。
因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值，此时非法侵入者已无利可图。
38.可靠性测试
1）可靠性（Reliability）是产品在规定的条件下和规定的时间内完成规定功能的能力，它的概率度量称为可靠度。
2）软件可靠性是软件系统的固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的可靠程度。
可靠的软件系统应该是正确、完整、一致和健壮的。
Ø规定的时间：
软件可靠性只是体现在其运行阶段，因此将“运行时间”作为“规定的时间”度量
Ø规定的环境条件：
环境条件指的是软件的运行环境。
涉及软件系统运行时所需的各种支持要素，如支持硬件、操作系统、支持软件、输入数据格式和范围以及操作规程等。
Ø规定的功能：
软件可靠性还与规定的任务和功能有关。
39.容错性测试
容错性测试是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。
如当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。
容错性测试包括两个方面：
Ø输入异常数据或进行异常操作，以检验系统的保护性。
如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
Ø灾难恢复性测试。
通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复。
40.验收测试
1）验收测试（AcceptanceTest）:
也称为交付测试，旨在向软件的购买者展示该软件系统满足其用户的需求。
2）它的测试数据通常是系统测试的测试数据的子集。
所不同的是，验收测试必须有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。
3）是一个以用户为主的测试，这是软件在投入使用之前的最后测试。
测试前提:
系统或软件产品已通过了系统测试的软件系统。
41.文档的种类?
42.性能测试常见术语
1）请求响应时间:
是指从客户端发出请求到得到响应的整个过程的时间。
2）并发
3）并发用户数量:
在同一时刻与服务器进行交互的在线用户数量。
4）吞吐量:
指在一次性能测试过程中网络上传输的数据量的总和。
吞吐量/传输时间，就是吞吐率。
5）吞吐率：
通常用来指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量。
是衡量网络性能的重要指标。
6）TPS:
每秒钟系统能够处理的交易或事务的数量，是衡量系统处理能力的重要指标
7）点击率：
每秒钟用户向Web服务器提交的HTTP请求数。
8）资源利用率：
是指对不同系统资源的使用程度。
是分析系统性能指标进而改善性能的主要依据，是Web性能测试工作的重点。
主要针对Web服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参数。
43.性能测试工作流程（LR）
44.测试项目管理主要内容
1）测试项目管理背景分析
2）测试项目管理价值分析与目的
3）测试项目管理任务介绍
4）测试项目管理工具
45.测试项目管理的功能价值
1）明确工作范围
2）提高工作质量
3）提高工作效率
4）减低成本
5）减少风险
6）培养企业质量意识，推行质量控制方法
7）收集有价值的测试管理数据
46.测试项目管理目的
1）保证测试质量
测试的可跟踪性
测试的有效覆盖
测试的科学性，系统性
2）提高测试效率
减少不必要的测试人力浪费
提高交流的效率
提高小组团队工作的能力
测试技能的科学应用（用最科学的测试策略解决相应的系统问题）
47.测试环境
测试环境是软件测试的基础，影响测试结果的真实性和正确性。
测试环境要素：
软件、硬件、网络环境、数据准备、测试工具。
测试环境维护：
1）测试环境原则：
尽可能地模拟实际用户环境
测试环境必须是正确性
测试环境必须是可以跟踪的
测试环境要及时调整
测试环境的及时生成、并且可以复原各种状态
测试环境要求足够安全
2）分析
有效的测试环境会发现很多开发无法发现的问题。
失败的测试环境维护将会给工作带来很大的成本浪费
测试环境必须有专人负责
48.TestDirector特点
1）问题提出：
软件测试是一个复杂的过程,大型项目往往要编写成百上千的测试用例,有的测试还需要跨平台以及测试不同硬件平台和操作系统的兼容性,管理测试过程是非常繁琐的工作。
2）TestDirector是MI公司开发的一款基于WEB的测试管理工具。
3）可以实现需求管理、测试计划管理、用例管理和缺陷管理。
可以对缺陷进行增删改查等操作,同时也可以给开发人员发送E-mail通知缺陷测试情况。
4）TestDirector具有强大的数据管理功能,在后台的数据库中集中管理测试需求、测试用例和测试步骤等资源。
5）TestDirector是B/S结构的软件,只需要在服务器端安装软件,所有的客户端就可以通过浏览器来访问TD,方便测试人员的团队合作和沟通交流。
6）TestDirector能够很好的和MI公司的其他测试工具集成,例如:
WinRunner,LoadRunner,QuickTestProfessional（QTP）等,同时也支持一些第3方公司开发的测试工具。
7）强大的图表统计功能,自动生成丰富的统计图表。
49.TestDirector工作流程
1建立测试环境
（1）创建TestDirector数据库;
（2）定义TestDirector用户。
2设计测试用例
（1）建立测试需求;
（2）定义测试用例;（3）关联测试需求。
3执行测试用例并分析结果
（1）建立测试集（组）;
（2）测试执行;（3）分析测试结果。
4报告并跟踪错误
（1）缺陷跟踪;
（2）自动的Email通知:
通过自动的Email方式,将缺陷发到项目指定人员,对出错的模块进行修改;（3）缺陷报告。
50.软件缺陷
1）软件缺陷生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程
2）严重性（severity）衡量缺陷对客户满意度的影响程度
致命的（fatal）、严重的（critical）、一般的（major）、微小的（minor）
3）优先级（Priority）：
指缺陷被修复的紧急程度。
4）其他属性:
缺陷标识、缺陷类型、缺陷产生可能性、缺陷来源、缺陷原因
5）基本要求:
单一准确、可以再现、完整统一、短小简练、特定条件、补充完善、不做评价
51.软件测试文档的管理
1）文档的分类管理
2）文档的格式和模板管理
3）文档的一致性管理
4）文档的存储管理
升级会员 