软件测试.docx
《软件测试.docx》由会员分享，可在线阅读，更多相关《软件测试.docx（24页珍藏版）》请在冰豆网上搜索。
软件测试
第1章软件测试的基本概念
1.软件质量是产品、组织和体系或过程的一组固有特性，反映它们满足顾客和其他相关方面要求的程度。
2.越是关注客户的满意度，软件就越有可能达到质量要求。
程序的正确性固然重要，但不足以体现软件的价值。
3.使用质量分为4个属性：
有效性、生产率、安全性和满意度。
4.软件的效率：
在规定条件下，相对于所用的资源的数量，软件产品可提供适当性能的能力。
5.软件的易用性：
在指定条件下，软件被理解、学习、使用和吸引用户的能力。
6.软件的功能性：
当软件在指定条件下使用，软件产品提供明确的和隐含的要求的功能的能力。
7.软件的可靠性：
在指定的条件下使用时，软件产品维持规定的性能水平的能力。
8.软件必须首先提供用户所需的功能，其次这个产品能够正常工作。
9.外部质量是针对要求的满足程度而言的，是表征软件产品在规定条件下使用时，满足规定的和隐含的要求的程度。
10.内部质量主要是根据软件产品的情况给出的，是表征软件产品在规定条件下使用时，决定其满足规定的和隐含的要求的能力的产品属性的全体。
11.使用质量是软件产品在规定的使用环境中规定的用户能实现规定目标的要求。
12.测试是为了证明程度有错，而不是证明程序正确。
13.一个好的测试用例在于它能发现以前未发现的错误。
14.一个成功的测试是发现了以前未发现的错误的测试。
15.软件测试的目的：
用最少的时间和人力，找出软件中潜在的各种错误和缺陷。
这一目的贯穿于整个测试的过程中。
16.测试的另一个收获是，它能够证明软件的功能和性能与需求说明相符合。
17.测试用例由测试的输入数据和与之对应的预期输出结果两部分组成。
18.程序员应避免测试自己的程序。
19.设计测试用例时，应该包括合理的和不合理的输入条件。
20.妥善保存测试计划，测试用例、出错统计和最终分析报告。
21.由于软件开发的各个环节都有可能会出错，所以我们要坚持在各个阶段的技术评审，对能尽早地发现和预防错误，把出现的错误克服在早期，杜绝某些发生错误的隐患，减少开发费用，提高软件质量。
22.模块中发现的错误数越多，残余的错误也较多。
23.缺陷：
存在的某种破坏正常运行能力的问题、错误、或者隐藏的功能缺陷。
24.缺陷未必一定会导致系统崩溃。
25.缺陷的主要类型：
软件没有实现产品规格说明要求的功能。
软件出现了不该出现的错误。
软件实现了说明没提到的功能。
软件没有实现规格说明中未明确提及但应实现的目标。
软件难理解、不易使用。
26.致命的错误导致系统或者应用程序崩溃、死机、系统悬挂，或者造成数据丢失、主要功能完全丧失。
27.严重的。
功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。
28.一般的。
功能没有被很好地实现，没有达到预期的要求。
29.微小的。
无关紧要的小问题，软件仍然可以使用，不影响功能的实现。
30.故障、失效、缺点三者都是指软件中确实存在问题，若不及时改正就会导致严重的后果，而异常、偏差等表示问题不是那么尖锐，通常是指未按预期运行，而不会导致整体失效。
31.软件缺陷产生的原因从大的方面讲主要有技术问题、团队工作、软件本身。
32.技术问题包括：
算法错误；语法错误；计算和精度错误；系统结构不合理，算法不科学，接口参数传递不匹配。
33.团队工作：
系统需求分析时对客户的需求理解不清楚，或者和用户沟通时存在困难；不同阶段的开发人员相互理解不一致；对于设计或者编程上的一些假定或依赖性，相关人员没有充分沟通。
34.软件本身：
文档错误、内容不正确或者拼写错误；
35.功能缺陷包括：
规格说明书缺陷、功能缺陷、测试缺陷和测试标准引起的缺陷。
36.软件生产的3个最重要的因素是：
质量、进度和费用。
37.黑盒测试的测试数据完全来源于软件规格说明。
38.软件质量保证工作贯穿于整个软件开发过程，而软件测试是其最为关键的内容之一。
尽量防止软件缺陷的产生。
39.软件测试是尽可能地发现软件缺陷并确保缺陷得以改正，使得软件产品更加稳健。
40.验证是检查软件开发各个阶段过程活动的结果是否满足规格说明的描述，证实各阶段之间的逻辑协调性、完备性和正确性。
41.确认是证实在一个给定的外部环境中软件的逻辑正确性，即是否满足用户的要求。
42.验证和确认的主要活动有关键性分析、可跟踪性分析、评估、接口分析、测试、危害性分析和风险分析等。
43.关键性分析的目的是为了保证资源的有效利用。
44.可跟踪性分析就是标识原始需求和开发结果之间关系的能力。
45.评估的目的是要确认产品是否符合规格说明，是否正确，完整、清楚、一致，是否满足规定的特性。
46.接口分析的目的是评估软件交付物是否正确、完整说明了接口需求。
47.质量保证活动的实施步骤：
目标（设定评价标准），计划（确定适合于被开发软件各个阶段的度量方法），实施（在软件开发的过程中，参与评审，审核各项活动和中间产品的生成是否遵循相应的过程规范，形成报告），检查（以计划阶段确定的质量度量标准进行评价，看质量是否合格），行动（对评价发现的问题进行改进活动）。
第2章软件测试类型及其在软件开发过程中的地位
1.对程序中已发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档，称为调试。
2.软件测试不仅仅限于程序编码之后，而应该贯穿于软件开发的全过程。
软件测试并不等于程序测试，因此，需求分析、概要设计、详细设计以及程序编码等各个阶段所得到的文档资料，包括需求规格说明、软件概要设计规格说明、软件详细设计规格说明以及源程序，都应做为软件测试的对象。
3.面向对象的软件设计要首先考虑问题中的数据实体，通过实体提供的服务和实体之间的消息的传递来实现某种计算，这种体系结构的好处体系在稳定性。
4.软件规划阶段的主要目标是需求的获取和定义，包括：
目标阐述，需求分析，功能定义，规划阶段进行的测试（评审）。
5.鼓励对所有的回归测试用例进行自动化测试。
6.测试的目标是确定程序代码的质量。
7.程序员不可能测试完所有的路径，覆盖准则规定了必须测试的一组路径。
8.增量测试是将程序模块逐步集成进行测试。
9.大突击测试是将程序成块地进行测试，即把所有的模块一次性集成在一起进行完全测试。
10.性能测试的主要目标是发现和改下性能缺陷并提高性能。
在大多数实际情况下，人们通过黑盒测试来实现性能测试。
11.回归测试：
重新执行以前发现这个缺陷的测试，查看此缺陷是否重现，当对发现的缺陷进行修改之后，执行一系列基准测试，以确认程序的修改没有对其他部分产生干扰。
鼓励对所有回归测试用例进行自动化测试。
12.大多数实际情况下，性能测试的实现方法是黑盒测试。
第3章代码检查、走查与评审
1.桌上检查是一种传统的检查方法，由程序员自己检查自己编写的程序。
2.桌上检查的目的就是发现程序中的错误。
3.桌上检查的静态分析分为两部分：
生成引用表和进行静态错误分析。
4.代码检查小组的角色分配：
协调人员，开发人员，检查人员，讲解员，记录员。
5.在代码检查过程中发现大部分错误的人通常是程度员。
6.桌上检查的文档是一种过渡性的文档，不是公开的正式文档。
7.在代码检查中，负责提供关于检查项目的资料并回答检查人员问题的角色是开发人员。
8.走查与代码检查的比较：
相同点：
两者都是以小组为单位进行，是一系列规程和错误检查技术的集合。
不同点：
两种检查方法过程大致相同，只有规程和错误检查技术上略有不同，另外参加走查小组的人员有限制，通常仅有一人是程序编写者。
9.走查是对程序进行模拟，一步步地展示程序如何处理测试数据，其主要目标是发现缺陷、遗漏和矛盾的地方，改进产品，考虑可替换的实现方法。
10.走查的步骤：
计划走查会议，走查产品，执行走查，解决缺陷，走查记录，产品返工。
11.小组成员开会，集体扮演计算机角色，把测试数据沿程序的逻辑结构走一遍是执行走查。
12.同行评审是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。
13.同行是一个项目组成员，被分配执行指定产品的一个同行评审任务。
14.同行评审中的“产品”可以理解为最终产品的组成部分，它是软件开发过程中产生或需要的一个可交付的文档。
15.评审的目的是发现产品的缺陷，因此在评审上的投入可以减少大量的后期返工。
16.同行评审的作用非常突出，既缩减了工作时间，又节约了大量成本。
及时进行同行评审不仅有利于提高软件的质量，而且可以时一步提高工程师的工作效率。
17.同行评审根据正式化程度不同，从非正式到十分严格依次为：
临时评审，轮查，结对评审，走查，小组评审，正式审查。
第六章单元测试和集成测试
1.单元测试的目标：
验证代码是与设计相符合的，跟踪需求与设计的实现，发现设计和需求中存在的缺陷，发现在编码过程中引入的错误。
2.单元测试活动模型：
准备，代码编写，代码审查，单元测试，跟踪调试。
3.单元测试主要是白盒测试，集成测试是白盒与黑盒相结合，也称为灰盒测试，系统测试主要是黑盒测试。
4.系统测试是从用户角度上出发看问题，主要目的是证明系统已满足用户的需要，系统测试是基于需求规格说明的。
单元测试是基于详细设计规格说明的。
5.驱动模块，相当于被测模块的主模块。
6.桩模块，用于代替被测模块调用的子模块。
7.参与单元测试主要人员均为开发人员。
8.自顶向下，不停的编写桩模块。
9.自底向下，不停的编写驱动模块。
10.孤立测试分别为每个模块单独设计桩模块和驱动模块，逐一完成所有单元模块的测试。
11.综合测试：
将自底向上测试策略与孤立测试策略相结合。
12.当在详细设计文档中缺少结构细节时，我们做单元测试时通常会采用自底向上的测试策略。
13.为了发现因计算错误、比较不正确和控制流不恰当而造成的错误，最常用且最有效的测试技术是基本路径测试和循环测试。
14.基于分解的集成策略可以分为非增量式集成和增量式集成。
15.非增量式集成先针对系统中的每一个模块进行单元测试，然后把所有已经被单元测试过的模块按照层次结构的要求一次性组装在一起进行测试。
16.增量式集成首先对一个模块进行单元测试，然后将这些模块逐步组装为较大的系统，在组装过程中边连接边测试，用以发现连接过程中产生的问题。
17.大突击测试是一种非增量式测试，这种方式是把所有系统构件一次性集成到一起进行测试，不考虑构件之间的相互依赖性或可能存在的风险。
其主要目标是在最短的时间内把系统组装起来，使用最少的测试来难整个系统。
适用范围：
老版本的产品比较稳定，新增项目涉及被更改的模块比较少，这样的软件项目通常是维护型项目。
每个构件都已经经过了充分的单元测试的小型系统。
产品的开发质量和单元测试质量都比较高。
18.自顶向下的增量式集成方式需要开发许多桩模块，测试的开销较大。
适用范围：
软件产品的控制结构清晰、稳定。
软件产品的高层模块接口稳定，变化不大，但底层模块的接口变化可能比较大。
控制模块需要被很早地被验证，以降低风险。
希望能够较早地看到系统功能行为。
在极限编程中使用探索式开发风格时。
19.自底向上的增量式集成方式开发驱动模块。
适用范围：
采用契约式设计的产品。
底层模块的接口比较稳定，便高层接口可能经常变化的产品。
底层模块较早完成的产品。
20.基于功能的集成策略：
按照功能的关键程度对模块的集成顺序进行组织。
适用范围：
关键功能具有较大风险，需要对其进行更加充分的测试的软件产品；探索性项目，功能实现大于软件质量；对功能实现的信心比较小。
21.三明治集成方式大部分软件开发项目都可以使用这种集成测试策略。
22.成对集成的思想是免除驱动/桩模块的开发，使用实际代码代替驱动模块和桩模块。
23.源结点是在基于路径集成测试中涉及的重要概念。
程序中的源结点是指程序开始执行或重校报开始处的语名片段，因此单元中第一个可执行语句就是源结点，另外，程序的源结点还会出现在转移控制到其他单元的结点之后。
24.接口分析必须关注的有三种接口：
用户接口，硬件接口和软件接口。
第七章系统测试
1.系统测试目标：
通过与系统的需求规格说明进行比较，检查软件是否存在与系统规格不符合或与之矛盾的地方，从而验证软件系统的功能和性能等满足规格说明所指定的要求。
2.不要对软件测试环境库所在的硬盘分区进行磁盘管理，以免对镜像文件造成破坏。
3.破坏性测试重点关注超出系统正常负荷N倍的情况下，错误出现状态和出现比率以及错误的恢复能力。
4.功能测试用例是功能测试工作的核心，常见的测试用例设计方法有：
规范导出法；等价类测试法；边界值测试法；因果图法；基于判定表的测试；正交实验设计法；基于风险的测试。
5.GUI测试更关注对图形界面的测试。
一般分为3层：
界面层，功能层和界面与功能的接口层。
6.健壮性测试又称容错测试，用于测试系统在出故障时，是否能自动恢复或者忽略故障继续运行。
7.系统错误应记入文档。
8.敏感测试属于压力测试。
9.确认测试阶段的主要工作就是功能测试和软件配置复审，其中功能测试是在模拟的环境下的测试，目的是验证软件是否满足软件需求规格说明书的要求。
10.β测试的管理者最好是主持产品发行的人员。
第8章软件性能测试和可靠性测试
1.软件的性能是软件的一种非功能特性。
它关注的不是软件是否能够完成特定的功能而是在完成该功能时展现出来的及时性。
2.之所以要定义一系列软件性能指标，目的是为了能够客观地度量软件的性能。
3.性能指标：
响应时间（指系统对请求做出响应的时间。
响应时间的值本身并不能直接反映软件性能的高低，这还要取决于用户的接受程度。
系统响应时间和应用延迟时间（系统响应时间是指从客户端接收到用户请求到客户端接收到服务器端发来的数据所需要的时间；应用延迟时间是指网站软件实际处理请求所需的时间）。
吞吐量（指系统在单位时间内处理请求的数量，如果没有并发操作，吞吐量与时间成反比关系。
吞吐量在软件性能测试中的另一个用途是测量系统的最大负载）。
并发用户数（是指系统可以同时承载的正常使用系统功能的用户数量）。
资源利用率（资源利用率反映的是在一段时间内资源被占用的情况）。
4.软件性能的视角：
用户视角（关注响应时间），管理员视角（关注性能调优），开发人员视角（注重软件性能）
5.软件测试的目标不仅仅是发现（和改正）性能缺陷，还包括探索和规划软件的实际性能。
6.软件性能测试的目标：
发现缺陷，性能调优，能力检验与规划。
7.性能测试指的是测试软件的性能与软件需求规格说明是否相符。
8.并发测试是指模拟多个用户并发使用软件，以测试软件是否在在与并发有关的缺陷。
9.并发测试从严格意义上说并不属于性能测试，甚至与性能测试没有直接的关系。
但是性能测试中经常涉及多用户并发的情况，在性能测试中附带并发测试可以节省一定的测试开销。
10.压力测试是指在较大的业务压力下，即系统运行环境超常的情况下，测试软件是否在在功能和性能上的缺陷。
11.可靠性测试是指在比较大的业务压力情况下进行的软件可靠性测试。
12.负载测试是指不断增加软件的业务压力，探测软件在保证预定性能指标的情况下所能负担的最大压力。
13.配置测试是指通过调整软件的运行环境，测试不同的环境配置对软件性能的影响程度。
14.失效恢复测试是指验证系统从故障中恢复能力的测试。
15.性能测试通用模型（PTGM）是针对功能测试的自动化模型进行适当调整，以适应性能测试的需要。
16.PTGM模型包括6个步骤：
测试前期准备，引入测试工具，制订测试计划，测试设计与开发，测试执行与管理，测试执行与管理，测试结果分析。
17.性能平坦区：
正常状态
18.性能轻微下降区：
压力测试
19.性能急剧下降区：
瓶颈现象
20.基于性能计数器的分析技术：
内存分析（是否遇到内存瓶颈），处理器分析，磁盘I/O分析，进程分析（进一步查看每个进程的性能指标，以确定哪个进程是造成性能瓶颈的原因）。
21.性能测试过程中最核心的技术力量是设计人员。
22.错误：
是指在软件生存周期的所有阶段软件的状态或行为与人们预期的软件状态或行为的偏差。
23.软件错误不仅包括程序代码错误，而且应当包括软件开发过程中所有制品的错误以及软件的文档、手册等中的错误。
24.缺陷：
泛指软件中一切不好的东西，它涵盖了软件错误，比软件错误更加广泛。
25.难以理解的程序一般不认为是错误，而把它归到软件缺陷里去。
26.故障：
是指软件代码中的错误。
27.失效：
是指故障引起的在软件运行期间出现的错误。
28.一般而言，软件故障可能引起软件失效，也可能不引起软件失效。
29.在可靠性测试中，人们关心的重点是软件失效。
30.软件可靠性有两方面的含义：
在规定条件下、规定时间内，软件不引起系统失效的概率。
在规定时间周期内，在所述条件下执行所要求的功能的能力。
31.MTTF（平均无失效时间）：
是指软件运行后，到下一次发生失效的平均时间。
32.软件失效对软件运行的影响既与失效概率有关，又与失效的严重程度有关。
33.成本包括额外运行成本，修复成本，恢复成本等。
34.软件的复本都是一样的，而硬件设计出来总有所偏差。
35.一个正确的硬件器件会国为物理退化在某时刻失效，便正确的软件则不会因为物理退化而发生失效。
36.软件是纯逻辑产品，具有复杂的内部逻辑，而硬件的内部逻辑则相对简单。
37.硬件的更新很慢而软件很快，这也给可靠性的评估带来的困难。
38.软件可靠性测试目的：
通过受控的软件测试过程来预测软件在实际运行中的可靠性，而不是通过测试揭示软件缺陷并通过修改缺陷来提高可靠性。
39.软件可靠性测试过程包括5个步骤：
确定可靠性目标，定义软件运行剖面（用户层次，功能层次），设计测试用例，实施可靠性测试，分析测试结果。
40.软件可靠性预测目的：
根据软件在可靠性测试时揭示的故障情况来预测软件在正式运行时的故障和失效情况。
41.可靠性分析方法：
失效模式影响分析，严酷度分析，故障树分析，事件树分析，潜在线路分析。
42.失效模式影响分析：
假设产品本身的逻辑没有故障，但从各大部件出现的故障可能会导致产品出现故障。
43.严酷分析：
对失效模型方法的扩展，主要添加了对各种故障的出现概率和严酷度的分析。
44.故障树分析：
是在产品设计过程中分析可能造成产品故障的各因素间影响和依赖关系，从而获得树。
45.事件树分析：
关注可能导致失效的事件及其失效概率，并计算出各种事件组合导致失效的概率。
46.潜在线路分析：
发现程序中异常的控制流和数据流。
47.定义软件运行剖面是软件可靠性测试的重要步骤。
48.通过分析产品与其各个部件的逻辑，从而分析出各个部件的故障对整个产品可靠性的影响，这是失效模式影响分析的路。
第9章面向对象软件的测试
1.面向对象的3个主要特点是：
封装，继承和多态。
2.封装：
信息隐蔽。
一组相关的变量和方法被封装在同一个类中。
需要构造复杂的驱动程序。
3.面向对象程序的基本单位是类，在测试面向对象软件时，不能够简单地对每个类的成员方法进行测试，在调用任何一个成员方法之前必须保证相应的实例处于该成员方法的预期状态。
4.在为每个类设计测试用例的时候，一般需要对测试序列是否合理进行分析，并且给出相关的约定。
5.继承是面向对象中的一个重要机制，它允许子类直接获得父类的属性和方法，从而实现对父类的复用。
6.多态：
是指对一个类的引用可以与多个类实现绑定，绑定分为静态绑定（编译时）和动态绑定（运行时）。
7.只有虚方法才可以进行动态绑定，而普通方法不进行动态绑定。
8.抽象类是面向对象软件开发的一个重要方法，它体现了继承和多态的思想。
抽象类有一些成员方法没有被实现，所以不能直接创建抽象类实例。
9.通过执行程序代码完成的测试通常包括单元测试、集成测试和系统测试3个方面。
10.面向对象的一个类甚至都不能作为可以被独立测试的单元。
11.对于由多个类组成的继承树的测试，传统的集成测试技术也难以适用。
12.一个测试用例可以调用该类的多个方法，但每个方法只能调用一次。
13.在存在多态的情况下，为了达到较高的测试充分性，应对所有可能的绑定都进行测试。
14.面向对象程序集成测试策略主要有：
传统的集成测试策略，协作集成，基干集成，高频集成，基于事件（消息）的集成。
基于使用的集成。
客户机/服务器的集成，分布式集成。
15.传统的集成测试策略：
自底向上集成，自顶向下集成。
16.协作集成：
在集成测试时，针对系统完成的功能，将可以相互协作完成特定功能的类集成在一起进行测试。
优点：
编写测试驱动和测试桩的开销小。
缺点：
当协作关系复杂时，测试难以充分进行，与传统集成测试相比，协作集成通常不完备。
17.基干集成：
内核部分和外围应用部分。
优点：
集中了传统集成的优点，并对缺点进行了控制，更加适合大型复杂项目的集成。
缺点：
必须对系统的结构和相互依存性进行分析；必须开发桩模块和驱动模块；由于局部采用一次性集成策略导致有些接口可能测试不完整。
18.不变式边界测试是一种类级别的单元测试技术。
19.测试动态绑定是类树测试的一个目标。
20.对于抽象类，需要进行单元测试。
21.高频集成一般采用冒烟测试的方式，即不预测每个测试用例的预期结果，如果测试中未出现反常情况，就认为通过测试。
22.在面向对象软件的基干集成测试策略中，将基干中的模块形成基干子系统使用的集成方式是大突击集成方式。
23.在实际应用时，往返场景测试可以不
24.基于代码而基于顺序图。
第十章Web应用软件测试
1.Web应用软件的特点：
基于无连接协议，内容驱动，开发周期短，深化频繁，安全性要求较高，美观性要求较高。
2.Web应用软件基于超文本传输协议和HTML构建。
3.大多数服务器都遵循J２EE规范，早前出现的Tuxedo和MTS不遵循J２EE规范。
4.应用服务器的功能主要包括３方面：
构件运行环境，互操作机制和公共服务（查找服务，事务服务和安全服务）。
5.B/S软件的业务层可细分为：
CGI层，构件层，服务层。
6.目前软件厂商和组织均认为，一个具体的网络应用应当梦筑在应用服务器上。
7.能够为Web应用软件集成异构成分和实现负载均衡提供帮助，体现的是应用服务器互操作机制方面的功能。
8.Web软件测试分为3层：
表示层，业务层和数据层。
9.表示层的测试主要关注Web应用软件的界面和与客户的交互，测试的重点是HTML文档的结构与客户端的程序。
10.业务层的测试主要关注Web应用软包含的业务逻辑，测试的重点是服务器端的程序。
11.数据层的测试主要关注Web应用软件处理不同数据能力，测试的重点包括对数据完整性的测试以及对大数据量下数据库操作的性能测试。
12.表示层的测试主要集中在客户端，包括：
排版结构的测试，链接结构的测试，客户端程序的测试，浏览器兼容性测试。
13.业务层主要针对Web应用软件的业务逻辑，主要集中在对服务器端程序的测试上，分为对单个程序的测试，对一组程序的测试。
14.数据层的测试，这里所涉及的性能测试与通常意义上的性能测试有所区别，因为它是针对大数据量的，而不是针对多用户并发操作的。
可以在整个应用程序开发完毕之前就开始进行大数据量下数据库的性能测试。
15.层间的集成测试：
表示层与业务层的集成，表示层与数据层的集成，业务层与数据层的集成。
16.Web应用软件的系统测试包括功能测试、性能测试、易用性测试、内容测试、安全性测试、接口测试等。
17.功能测试：
链接测试，表单测试，Cookie测试。
18.性能测试：
并发测试，负载测试和压力测试，配置测试和性能调优。
19.内容测试：
测试数据库中的内容，测试服务器端程序和客户端程序是否会在数据的处理过程中引入错误的内容（这方面的测试通常与功能测试一起）。
20.安全性测试：
服务器端的内容安全
升级会员 