软件测试知识总结Word文档格式.docx
《软件测试知识总结Word文档格式.docx》由会员分享，可在线阅读，更多相关《软件测试知识总结Word文档格式.docx（46页珍藏版）》请在冰豆网上搜索。
☐方向二:
管理路线轨迹
测试主管－>
测试经理－>
技术总监
4.软件测试的历史发展
表明程序正确而进行测试。
测试是为发现错误而执行的一个程序或者系统的过程。
测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。
测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。
5.软件测试的定义
软件测试是为了发现程序中的错误而实施的一些方法和手段。
6.软件测试的目标
（1）测试是程序的执行过程，目的在于发现错误，不能证明程序的正确性，仅限于处理有限种的情况。
（2）检查系统是否满足需求，这也是测试的期望目标。
（3）一个好的测试用例在于发现还未曾发现的错误；
成功的测试是发现了错误的测试。
7.软件测试标准
（1）软件测试的目标在于揭示错误。
测试人员要始终站在用户的角度去看问题，系统中最严重的错误的是那些导致程序无法满足用户需求的错误。
（2）软件测试必须基于“质量第一”的思想去开展各项工作。
（3）事先定义好产品的质量标准。
只有建立了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。
（4）软件项目一启动，软件测试也就开始，而不是等程序写完，才开始进行测试。
（5）测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性。
（6）对发现错误较多的程序段，应进行更深入的测试。
8.软件测试原则
（1）应当把尽早地和不断地进行软件测试作为软件开发者的座右铭。
坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些隐患，提高软件质量。
（2）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。
如果对测试输入数据没有给出预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。
（3）程序员应避免检查自己的程序。
如果由别人来测试程序员编写的程序，可能会更客观，更有效，并更容易取得成功。
（4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
（5）充分注意测试中的群集现象。
测试时不要以为找到了几个错误问题就已解决，不需继续测试了。
应当对错误群集的程序段进行重点测试，以提高测试投资的效益。
（6）严格执行测试计划，排除测试的随意性。
对于测试计划，要明确规定，不要随意解释。
（7）应当对每一个测试结果做全面检查。
这是一条最明显的原则，但常常被忽视。
必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住关键，暴露错误。
（8）妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。
9.软件测试分类
1．从是否需要执行被测软件的角度分类
（1）分为静态测试（StaticTesting）
静态测试就是通过对被测程序的静态审查，发现代码中潜在的错误。
它一般用人工方式脱机完成，故亦称人工测试或代码评审（CodeReview）;
代码评审又可分为代码会审，走查以及办公桌检查，同行评分4种。
（2）动态测试（DynamicTesting）
动态测试的对象必须是能够由计算机真正运行的被测试的程序。
它分为黑盒测试和白盒测试.
2．从软件测试用例设计方法的角度分类
（1）黑盒测试（Black-BoxTesting）
黑盒测试是一种从用户观点出发的测试，又称为功能测试，数据驱动测试和基于规格说明的测试。
使用这种方法进行测试时，把被测试程序当作一个黑盒，忽略程序内部的结构的特性，测试者在只知道该程序输入和输出之间的关系或程序功能的情况下，依靠能够反映这一关系和程序功能需求规格的说明书，来确定测试用例和推断测试结果的正确性。
简单地说，若测试用例的设计是基于产品的功能，目的是检查程序各个功能是否实现，并检查其中的功能错误，则这种测试方法称为黑盒。
（2）白盒测试（White-BoxTesting）
白盒测试基于产品的内部结构来进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分利用。
白盒测试又称为结构测试，逻辑驱动测试或基于程序的测试。
即根据被测程序的内部结构设计测试用例，测试者需事先了解被测试程序的结构。
3．从软件测试的策略和过程的角度分类。
单元测试（UnitTesting），集成测试（IntegrationTesting）,确认测试（ValidationTesting）,系统测试（SystemTesting）和验收测试（VerificationTesting）.
（1）单元测试是针对每个单元的测试，是软件测试的最小单位。
它确保每个模块能正常工作。
单元测试多数使用白盒测试，用以发现内部错误。
（2）集成测试是对已测试过的模块进行组装，进行集成测试的目的主要在于检验与软件设计相关的程序结构问题。
集成测试一般通过黑盒测试方法来完成。
（3）确认测试是检验所开发的软件能否满足所有功能和性能需求的最后手段，通常采用黑盒测试方法。
（4）系统测试的主要任务是检测被测软件与系统的其他部分的协调性。
（5）验收测试是软件产品质量的最后一关。
这一环节，测试主要从用户的角度着手，其参与者主要是用户和少量的程序开发人员。
10.软件测试与软件开发
1．测试与软件开发各阶段的关系
软件开发过程是一个自顶向下，逐步细化的过程。
首先在软件计划阶段定义了软件的作用域，然后进行软件需求分析，建立软件的数据域、功能和性能需求、约束和一些有效性准则。
接着进入软件开发，首先是软件设计，然后再把设计用某种程序设计语言转换成程序代码。
而测试过程则是依相反的顺序安排的自底向上，逐步集成的过程，低一级测试为上一级测试准备条件。
此外还有两者平行地进行测试。
首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。
再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误。
随后再对照需求，进行确认测试。
最后从系统全体出发，运行系统，看是否满足要求。
2．测试与开发的并行性
在软件的需求得到确认并通过评审后，概要设计工作和测试计划制定设计工作就要并行进行。
如果系统模块已经建立，对各个模块的详细设计、编码、单元测试等工作又可并行。
待每个模块完成后，可以进行集成测试、系统测试。
3．测试与开发模型
11.软件测试的复杂性
（1）完全测试是不现实的
（2）杀虫剂现象，即为了克服被测试软件的免疫力，软件测试人员必须不断编写新的测试程序，对程序的各个部分进行不断测试，以避免被测试软件对单一的测试程序具有免疫力而使软件缺陷不被发现。
（3）软件测试的代价不容易掌握，因为随着测试量的增加，测试成本将呈现几何数级上升，而软件缺陷数量降低到某一数值之后将没有明显的变化，寻求最优测试点，掌握好测试工作量是至关重要的。
（4）在实际操作中，测试人员要进行正确的判断，合理的取舍，根据风险分析来决定那些故障需要修复，那些故障不需要修复，即并不是所有的软件缺陷都需要被修复。
12.软件测试的经济性
13.软件测试的充分性准则
●对任何软件都存在有限的充分测试集合；
●当一个测试的数据集和对于一个被测的软件系统的测试是充分的，那么再多增加一些测试数据仍然是充分的。
这一特性称为软件测试的单调性；
●即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。
这一特性称为软件测试的非复合性；
●即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。
这个特性称为软件测试的非分解性；
●软件测试的充分性与软件的需求、软件的实现都相关；
●软件测试的数据量正比于软件的复杂度。
这一特性称为软件测试的复杂性；
●随着测试次数的增加，检查出软件缺陷的几率随之不断减少。
软件测试具有回报递减率。
14.软件测试流程
1.软件开发的V模型
（1）V模型
2.软件测试过程（如何描述软件测试的整体框架）
软件测试过程按各测试阶段的先后顺序可分为单元测试、集成测试、确认（有效性）测试、系统测试和验收（用户）测试5个阶段，如图所示。
（1）单元测试：
测试执行的开始阶段。
测试对象是每个单元。
测试目的是保证每个模块或组件能正常工作。
单元测试主要采用白盒测试方法，检测程序的内部结构。
（2）集成测试：
也称组装测试。
在单元测试基础上，对已测试过的模块进行组装，进行集成测试。
测试目的是检验与接口有关的模块之间的问题。
集成测试主要采用黑盒测试方法。
（3）确认测试：
也称有效性测试。
在完成集成测试后，验证软件的功能和性能及其他特性是否符合用户要求。
测试目的是保证系统能够按照用户预定的要求工作。
确认测试通常采用黑盒测试方法。
（4）系统测试：
在完成确认测试后，为了检验它能否与实际环境（如软硬件平台、数据和人员等）协调工作，还需要进行系统测试。
可以说，系统测试之后，软件产品基本满足开发要求。
（5）验收测试：
测试过程的最后一个阶段。
验收测试主要突出用户的作用，同时软件开发人员也应该参与进去。
15.单元测试
1.单元测试的目标
单元测试的主要目标是确保各单元模块被正确地编码。
单元测试除了保证测试代码的功能性，还需要保证代码在结构上具有可靠性和健全性，并且能够在所有条件下正确响应。
进行全面的单元测试，可以减少应用级别所需的工作量，并且彻底减少系统产生错误的可能性。
如果手动执行，单元测试可能需要大量的工作，自动化测试会提高测试效率。
2.单元测试的内容
模块接口测试；
局部数据结构测试；
独立路径测试；
错误处理测试；
边界条件测试。
3.单元测试的步骤
通常单元测试在编码阶段进行。
当源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。
利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。
对于每一组输入，应有预期的正确结果。
4.解释驱动模块和桩模块概念。
（1）驱动模块（driver）：
相当于被测模块的主程序。
它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。
（2）桩模块（stub）：
用以代替被测模块调用的子模块。
桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。
16.集成测试
1．集成测试的定义
集成测试的定义是根据实际情况对程序模块采用适当的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确校验的测试工作。
集成测试是针对程序整体结构的测试。
2．集成测试的层次
软件的开发过程是一个从需求到概要设计、详细设计以及编码的逐步细化的过程，那么单元测试到集成测试再到系统测试就是一个逆向求证的过程。
集成测试内部对于传统软件和面向对象的应用系统有两种层次的划分。
对于传统软件来讲，可以把集成测试划分为三个层次：
●模块内集成测试；
●子系统内集成测试；
●子系统间集成测试。
对于面向对象的应用系统来说，可以把集成测试分为两个阶段：
●类内集成测试；
●类间集成测试。
3．集成测试的模式
（1）一次性集成测试方式
一次性集成测试方式也称作非增值式集成测试。
先分别测试每个模块，再把所有模块按设计要求放在一起结合成所需要实现的程序。
（2）增值式集成测试方式
自顶向下增值测试方式（Top-downIntegration）
主控模块作为测试驱动，所有与主控模块直接相连的模块作为桩模
块；
根据集成的方式（深度或广度），每次用一个模块把从属的桩模块替换成真正的模块；
在每个模块被集成时，都必须已经进行了单元测试；
进行回归测试以确定集成新模块后没有引入错误。
自底向上增值测试方式（Bottom-upIntegration）
组装从最底层的模块开始，组合成一个构件，用以完成指定的软件子功能。
编制驱动程序，协调测试用例的输入与输出；
测试集成后的构件；
按程序结构向上组装测试后的构件，同时除掉驱动程序。
这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。
17.确认测试
1．确认测试的定义
确认测试是检验所开发的软件是否能按用户提出的要求运行。
若能达到这一要求，则认为开发的软件是合格的。
因而有的软件开发部门把确认测试称为合格性测试（QualificationTesting）。
2.确认测试各阶段的工作
3．进行有效性测试
有效性测试是在模拟的环境（可能是就是开发的环境）下，运用黑盒测试的方法，验证所测试件是否满足需求规格说明书列出的需求。
为此，需要首先制定测试计划，规定要做测试的种类，还需要制定一组测试步骤，描述具体的测试用例。
通过实施预定的测试计划和测试步骤，确定软件的特性是否与需求相符，确保所有的软件功能需求都能得到满足，所有的软件性能需求能达到，所有的文档都是正确且易于使用。
同时，对其他软件需求，例如可移植性、兼容性，自动恢复、可维护性等，也都要进行测试，确认是否满足。
4．确认测试的结果
在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
测试结果与预期的结果相符。
说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受；
测试结果与预期的结果不符。
说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
通过与用户的协商，解决所发现的缺陷和错误。
确认测试应交付的文档有：
确认测试分析报告、最终的用户手册和操作手册、项目开发总结报告。
5．软件配置审查
软件配置审查是确认测试过程的重要环节。
其的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，维护阶段所必需的细节，而且已经编排好分类的目录。
除了按合同规定的内容和要求，由工人审查软件配置之外，在确认测试的过程，应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。
必须仔细记录发现的遗漏和错误，并且适当地补充和改正。
18.系统测试
1.系统测试的定义
系统测试是将已经集成好的软件系统，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
2.系统测试的流程
系统测试流程如图2-11所示。
3.系统测试的目标
（1）确保系统测试的活动是按计划进行的；
（2）验证软件产品是否与系统需求用例不相符合或与之矛盾；
（3）建立完善的系统测试缺陷记录跟踪库；
（4）确保软件系统测试活动及其结果及时通知相关小组和个人。
4.系统测试的方针
（1）为项目指定一个测试工程师负责贯彻和执行系统测试活动；
（2）测试组向各事业部总经理/项目经理报告系统测试的执行状况；
（3）系统测试活动遵循文档化的标准和过程；
（4）向外部用户提供经系统测试验收通过的项目；
（5）建立相应项目的（BUG）缺陷库，用于系统测试阶段项目不同生命周期的缺陷记录和缺陷状态跟踪；
（6）定期对系统测试活动及结果进行评估，向各事业部经理/项目办总监/项目经理汇报项目的产品质量信息及数据。
5.几种常见的系统测试方法
（1）恢复测试
（2）安全测试
（3）强度测试（4）性能测试
（5）容量测试（6）正确性测试
（7）可靠性测试（8）兼容性测试（9）Web网站测试
19.验收测试
1.验收测试的常用策略
选择的验收测试的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。
实施验收测试的常用策略有三种，它们分别是：
（1）正式验收
（2）非正式验收或Alpha测试
（3）Beta测试
2.验收测试的过程
20.静态测试与动态测试
21.黑盒测试与白盒测试
1.黑盒测试
黑盒测试（Black-boxTesting）又称为功能测试、数据驱动测试和基于规格说明的测试。
是一种从用户观点出发的测试。
黑盒测试的基本观点是：
任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么。
黑盒测试作为软件功能的测试手段，是重要的测试方法。
它主要根据规格说明设计测试用例，并不涉及程序内部结构和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。
黑盒测试的具体技术方法主要包括边界值分析法、等价类划分法、比较测试法、因果图法、决策表法等。
黑盒测试属于穷举输入测试方法，只有把所有可能的输入都作为测试情况来使用，才能以这种方法查出程序中所有的错误。
2.白盒测试
白盒测试（White-boxTesting）也称作结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。
按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。
白盒测试的主要方法有逻辑覆盖、基本路径测试等，主要用于软件验证。
通常的程序逻辑覆盖有：
●语句覆盖；
●判断覆盖；
●条件覆盖；
●判断/条件覆盖；
●条件组合覆盖；
路径覆盖。
3.黑盒测试与白盒测试的对比
黑盒测试
白盒测试
优点
1适用于各个测试阶段；
2从产品功能角度进行测试；
3容易入手生成测试数据。
4可构成测试数据使特定程序部分得到测试；
5有一定充分性度量手段；
6可获较多工具支持。
缺点
1某些代码得不到测试；
2如果规则说明有误，无法发现；
3不易进行充分行测试。
4不易生成测试数据；
5无法对未实现规格说明的部分进行测试；
6工作量大，通常只用于单元测试，有应用局限性。
性质
一种确认技术，目的是确认“设计的系统是否正确”。
一种验证技术，目的是验证“系统的设计是否正确”。
22.黑盒测试概述
1.叙述黑盒测试技术的实质及要点。
黑盒测试又称为功能测试或数据驱动测试，是从用户观点出发，主要以软件规格说明书为依据，对程序功能和程序接口进行的测试。
黑盒测试方法着重测试软件的功能需求，是在程序接口上进行测试，主要是为了发现以下错误：
●是否有不正确的功能，是否有遗漏的功能；
●在接口上，是否能够正确地接收输入数据并产生正确的输出结果；
●是否有数据结构错误或外部信息访问错误；
●性能上是否能够满足要求；
●是否有程序初始化和终止方面的错误。
2.黑盒测试的方法
（1）等价类划分法
有效等价类和无效等价类
有效等价类是指对软件规格说明来说，合理、有意义的输入数据所构成的集合。
无效等价类则和有效等价类相反，即不满足程序输入要求或者无效的输入数据所构成的集合。
划分等价类的几个原则：
●如果规定了输入条件的取值范围或者个数，则可以确定一个有效等价类和两个无效等价类。
●如果规定了输入值的集合，则可以确定一个有效等价类和一个无效等价类。
●如果规定了输入数据的一组值，并且程序要对每一个输入值分别进行处理，则可为每一个值确定一个有效等价类，此外根据这组值确定一个无效等价类，即所有不允许的输入值的集合。
●如果规定了输入数据必须遵守的规则，则可以确定一个有效等价类和若干个无效等价类。
●如果已知的等价类中各个元素在程序中的处理方式不同，则应将该等价类进一步划分成更小的等价类。
（2）边界值分析法
边界值分析法（BoundaryValueAnalysis，BVA）是一种补充等价类划分法的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。
在测试过程中，可能会忽略边界值的条件，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。
因此针对各种边界情况设计测试用例，可以查出更多的错误。
在应用边界值分析法设计测试用例时，应遵循以下几条原则：
例题：
某程序要求输入三个整数x、y、z，分别作为长方体的长、宽、高，x、y、z的取值范围在2～20之间，计算长方体的体积。
表3-10给出了健壮性边界值分析测试用例。
（3）因果图法
因果图法就是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种情况的组合。
在因果图中使用4种符号分别表示4种因果关系，如图3-2所示。
用直线连接左右节点，其中左节点Ci表示输入状态（或称原因），右节点ei表示输出状态（或称结果）。
Ci和ei都可取值0或1，0表示某状态不出现，1表示某状态出现。
1.上图中各符号的含义如下：
恒等：
若C1是1，则e1也是1，否则e1为0。
非：
若C1是1，则e1是0，否则e1为1。
或：
若C1或C2或C3是1，则e1是1，否则e1为0。
与：
若C1和C2都是1，则e1是1，否则e1为0。
2.上图中各符号的含义如下：
E约束（异）：
a和b中最多有一个可能为1，即a和b不能同时为1。
I约束（或）：
a、b和c中至少有一个必须是1，即a、b和c不能同时为0。
O约束（惟一）：
a和b中必须有一个且仅有一个为1。
R约束（要求）：
a是1时，b必须是1，即a是1时，b不能是0。
对输出条件的约束只有M约束。
M约束（强制）：
若结果a是1，则结果b强制为0。
实例1：
某软件规格说明中包含这样的要求：
输入的第一个字符必须是A或B，第二个字符必须是一个数字，在此情况下进行文件的修改；
但如果第一个字符不正确，则给出信息L；
如果第二个字符不是数字，则给出信息M。
解法如下：
（1）分析程序的规格说明，列出原因和结果。
原因：
C1----第一个字符是AC2----第一个字符是BC3----第二个字符是一个数字结果：
e1---
升级会员 