重点归纳软件测试概论.docx

重点归纳软件测试概论.docx

《重点归纳软件测试概论.docx》由会员分享，可在线阅读，更多相关《重点归纳软件测试概论.docx（12页珍藏版）》请在冰豆网上搜索。

重点归纳软件测试概论

软件测试概论

NO.1软件测试基础

1、IEEE对测试的定义：

使用人工或自动化手段来运行或测定某个系统的过程。

其目的在于检验系统是否满足规定的需求或者是否弄清楚预期结果和实际结果之间的差别。

——目的：

验证系统满足需求，或确定实际结果和预期结果之间的差别。

2、GB/T11457对测试的定义：

依据规范的软件检测过程和检测方法，按照测试计划和需求对软件的文档、程序和数据进行测试的技术活动。

3、测试与调试的区别：

测试是测试员利用测试方法和工具，发现软件存在的Bug，即缺陷，暴露软件潜在的错误；调试是开发人员识别缺陷的产生原因，修改代码，纠正错误，消除软件故障，验证是否正确修改了软件的缺陷，保证软件程序的可靠运行。

4、“测试工程师的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。

”

5、“测试活动包括测试执行前后的一系列活动，包括计划和控制、选择测试条件、设计测试用例、检测测试结果、评估出入口准则、报告测试过程、测试结果或总结、文档评审和静态分析。

”——第五章测试过程详述

6、软件测试目的：

A、验证软件是否满足开发合同或法律法规的要求，或者是否满足行业标准的要求（项目开发计划、设计文档、需求规格说明、设计说明和软件产品说明等规范的软件质量要求）；B、发现更多潜伏在软件里的缺陷和软件失效问题；C、为软件产品的质量测量和评价提供依据（质量监督和评审）。

7、“在开发测试中，如组件测试、集成测试、系统测试等，测试的主要目标就是尽可能多的发现缺陷或失效，从而识别和修改尽可能多的缺陷。

在验收测试中，测试的主要目标就是依据用户的需求说明书，确认系统是否按照用户需求安排工作。

”——第六章中详述

8、软件测试目标：

A、功能性需求：

确保软件产品符合需求的说明，可以执行它所承诺或公布的功能。

B、性能需求：

确保软件产品满足性能和效率的需求。

C、稳定性需求：

确保软件产品是健壮的，不轻易随着环境变化而失效，它是软件产品质量的基本要求。

“在短时间内发现尽可能多的缺陷，并确保这些缺陷得到修复。

”

9、软件测试的意义：

保证发布出去的软件产品达到了一定的质量标准（合同的要求或行业的普遍标准）

10、“软件测试工程师的工作就是利用测试工具按照测试方案、策略和流程对软件产品进行功能和性能测试，并根据需要编写不同的测试工具，设计和维护测试系统，对测试可能发现的问题进行分析和评估。

执行完测试用例后，要跟踪缺陷的解决，保障开发的软件产品满足用户的需求。

”

11、软件测试原则：

A、所有的测试都应追溯用户需求。

“从用户的角度来看，最严重的错误是那些导致程序无法满足需求的错误，所以，所有测试都是根据用户需求来进行的，一旦在测试过程中存在争议的情况，所有问题的解决都要依据用户需求说明中的规定，追溯用户的需求。

”

B、要尽早启动测试工作。

“缺陷发现的越早，修复其的成本就越低。

”

阶段

相对的修复费用比例

需求阶段

1

设计阶段

5

编码阶段

10

单元测试阶段

20

验收阶段

50

维护阶段

200

C、在测试工作开始前就进行测试计划。

“未雨绸缪”

D、应用帕累托最优原则：

软件系统80%的错误存在于20%的关键核心业务模块中。

又称为80/20效率原则。

集中力量，优先测试核心业务模块中存在的错误，可以减少投入和付出的代价。

“测试只能证明缺陷存在，但不能证明缺陷不存在！

”

E、应从小规模开始，逐步转向大规模。

测试的级别——单元、集成、系统、验收。

F、为了达到更好的效果，应有第三方来构造测试。

G、穷尽测试是不可能的。

H、测试是有风险的。

一方面对软件产品无法进行穷举测试；另一方面不足的测试还会漏掉很多缺陷。

测试员应学会的一个关键思想：

“如何把数量巨大的可能测试减少到可控的范围，以及如何针对风险作出明智的抉择，确定哪些测试不重要，哪些测试重要，从而找到最优测试量。

”P11

I、测试工作的Good—enough原则：

不充分的测试是不负责任的测试，但是过度的测试却是一种时间和资源的浪费。

如何界定哪些测试时不充分的，哪些测试是充分的。

J、测试旨在发现软件产品存在的缺陷。

K、发现的软件的缺陷越多，说明软件缺陷越多。

L、杀虫剂怪事：

测试工作执行的越多，缺陷对测试的免疫力增强，导致发现缺陷越少。

所以测试需要编写不同崭新的测试程序或工具，并对程序不同部分进行测试，以找出更多的软件缺陷。

M、并非所有的软件缺陷都需要修复。

“风险的评估决定哪些缺陷需要，那些不需要修复”

原因：

没有时间来修复、开发人员认为不是真正的软件缺陷、修复缺陷的风险太大耗费资源太多、不值得去修复的小缺陷。

N、木桶原理：

测试是提高产品质量的必要条件，也是提高产品质量最直接有效快捷的手段，但不是一种根本手段。

O、前进两步，后退一步。

缺陷解决后，不是一劳永逸，而是会随着条件的变化产生更多新的缺陷。

12、“软件生命周期每一个阶段都必须包括软件测试，以便检验每个阶段的成果是否满足预期的目标，尽可能早的发现错误并加以修正。

”

13、软件是指一组计算机程序、规程以及相关文档和数据。

软件不仅仅是程序。

14、测试通常被认为是一种破坏性的活动。

测试工程师要具有一颗好奇的心、专业的怀疑态度、一双挑剔的眼睛、对细节的关注、与开发人员良好的沟通能力以及对常见错误进行判断的经验。

15、“在以建设性的方式讨论缺陷、进度和风险时，测试员和测试负责人都需要具有良好的人际沟通能力。

”

A、以合作而不是争斗的方式开始测试项目，时时提醒项目中的每位成员共同的目标是追求高质量的软件产品，满足用户的需求。

B、对产品中出现的问题要以中性的和以事实为依据的方式来沟通，而不要指责引入这个问题的小组成员，共同面对和解决问题。

C、尽量理解其他成员的心理感受。

D、确信其他的成员都已经理解你的描述。

（表达能力）

NO.2软件工程基础

1、软件工程是一门交叉性学科，用工程科学中的观点来进行费用估算、进度管理、制定实施计划和方案；用管理科学中的方法论对软件生产进行管理；用数学的方法建立软件开发的各种模型和各种算法。

“软件工程ＳＥ是一门专门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。

”

2、主要环节分为：

人员管理、项目管理、可行性需求分析、系统设计、程序设计、测试发布、后期维护等。

3、目标是“提高软件的质量和生产率，最终实现软件的工业化。

”

其中质量是软件需求方最关系的问题，高生产率必须以质量合格为前提。

高质量对所有的用户都有价值，而高生产率只对开发方有意义。

4、

Modifiability可修改\efficiency有效\reliability可靠\understandability可理解\maintainability可维护\reuseability可重用\adaptability可适应\portability可移植\traceability可跟踪\interoperability可互操作。

5、软件开发生命周期模型：

大爆炸、边写边改、瀑布、螺旋

6、在每个软件开发生命周期中，一个好的测试应该具备以下几个特点：

A、每个开发活动都对应测试的活动；B、每个测试级别都有其特有的测试目标；C、对于每个测试级别，需要在相应的开发活动中进行相应的测试分析和设计，如测试用例的设计；D、在开发生命周期中，测试工程师在文档初稿阶段就应该参与文档初审，有助于理解用户的需求、了解系统设计的结构以及测试策略和方法等。

7、

软件测试过程生命周期模型：

A、V模型：

有的人认为测试只是一个收尾工作，V模型就是对这种认识的改进，是软件开发瀑布模型的变种，它反映了测试活动与分析和设计活动的关系。

从左至右详细描述了基本的开发过程和测试行为，非常明确标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段工作的对应关系。

V模型的问题：

测试是开发之后的一个阶段。

测试的对象就是程序本身。

实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。

整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度

B、W模型：

V模型不能体现“尽早地和不断地进行软件测试”的原则。

W模型就是将测试阶段变成与开发相并行的V。

在W模型中，既强调了测试方案设计，也强调了测试执行。

相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。

W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W模型强调：

测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。

W模型有利于尽早地全面的发现问题。

但W模型也存在局限性。

在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。

这样就无法支持迭代的开发模型。

对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

C、H模型：

为了解决V模型和W模型存在的问题，有专家提出了H模型。

它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

H模型揭示了一个原理：

软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

H模型指出软件测试要尽早准备，尽早执行。

不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。

D、X模型：

RobinFGoldsmith

E、前置测试模型：

RobinFGoldsmith

前置测试模型体现了以下几个要点：

开发与测试相结合：

将开发和测试的生命周期整合在一起，标示了项目生命周期从开始到结束之间的关键行为。

业务需求最好在设计和开发之前就被正确地定义。

对每一个交付内容进行测试：

每一个交付的开发结果都要通过一定的方式进行测试。

源程序代码并不是唯一需要测试的内容，诸如可行性报告、业务需求说明、系统设计文档都要开展测试活动。

在设计阶段进行测试计划和测试设计：

设计阶段是作测试计划和测试设计的最好时机。

测试和开发结合在一起。

验收测试和技术测试保持相互独立。

这样可以提供双重保险，保证设计及程序编码能够符合最终用户的需求。

在W模型的框架中，运用H模型的思想进行独立的测试，并且将开发和测试紧密结合，寻找恰当的“就绪点”开始测试并反复迭代测试，最终保证按期完成预定目标。

NO.3软件缺陷报告

1、软件测试人员是“不是缺陷的缺陷”的创造者。

所谓不是缺陷的缺陷是测试人员误解用户需求，从而不进行合理的报告的结果。

2、什么是软件的缺陷bugdefect

软件未达到产品说明书标明的功能；

软件出现了产品说明书指明不会出现的错误；

软件功能超出产品说明书指明范围；

软件未达到产品说明书虽未指出但应达到的目标；

软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

3、缺陷产生的原因：

缺陷产生的主要原因：

大部分客户不懂软件开发技术，提出的需求不明确，或者提出的需求本身是矛盾的

软件产品的制造商无法百分之百地收集到用户的所有使用需求

在软件的需求调研和设计阶段存在的各种问题会导致用户需求被错误地理解和传递

用户需求随着工作或使用环境的变化，以及时间的推移也会随之改变

软件技术的发展落后于不断复杂的软件需求。

如何正确识别软件缺陷：

“软件的缺陷不仅仅是程序代码的错误。

”　“用户的需求就是判断缺陷的关键（需求说明阶段产生最多的缺陷）”

首先，可以将软件需求说明书、用户手册及联机帮助作为识别和判断缺陷的辅助工具。

这些文档反映了大量的用户需求，所以被大多数测试人员在实际测试过程中广泛地使用；

其次，通过增加自己对所测试软件产品的行业背景知识的了解来发现被忽视的问题，这些问题中往往隐藏着软件的致命缺陷；

最后，通过沟通的方式来收集、学习和分享其他人判断缺陷的方法和经验。