软件测试重点总结.docx

软件测试重点总结.docx

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

软件测试重点总结

第一章软件测试基础

1：

软件的驻留故障密度：

每千行代码的故障数。

2：

软件的可靠性：

系统在特定的环境下，在给定的时间内无故障运行的概率。

注解：

软件可靠性是对软件在设计、开发以及所预定的环境下具有能力的置信度的一个度量，是衡量软件质量的主要参数之一。

而软件测试则是保证软件质量、提高软件可靠性的最重要手段。

3：

软件缺陷产生的原因：

56%是因为对软件产品规格说明书（软件需求说明书）的理解不够。

4：

软件测试的定义：

软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码实现的最终审查，它是软件质量保证的关键步骤。

通常对软件测试的定义有两种描述：

定义1：

软件测试是为了发现错误而执行程序的过程。

定义2：

软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以及发现错误的过程，即执行测试步骤。

5：

测试：

测试活动有两种结果：

a）找出缺陷和故障b）显示软件执行正确。

测试是一个或多个测试用例的集合。

6：

测试用例：

所谓测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果；测试用例是执行测试的最小实体。

7:

测试步骤：

测试步骤详细规定了如何设置、执行、评估特定的测试用例。

8:

软件生命周期：

一个软件生命周期包括制定计划、需求分析定义、软件设计、程序编码、软件测试、软件运行、软件维护、软件停用等8个阶段。

9:

软件测试的对象：

——软件测试不等于程序测试。

——软件测试贯串于软件定义和开发的整个过程。

——软件开发过程中所产生的需求规格说明、概要设计规格说明、详细设计规格说明以及源程序都是软件测试的对象。

10:

（1）测试是程序的执行过程，目的在于发现错误

（2）一个好的测试用例在于能发现至今未发现的错误；

（3）一个成功的测试是发现了至今未发现的错误的测试。

11:

软件测试的原则：

1）.所有的测试都应追溯到用户的需求

系统中最严重的错误是那些导致程序无法满足用户需求的错误。

2）.尽早地和不断地进行软件测试

需求和设计时出现的缺陷占很大的比例；

缺陷的修改成本随着阶段的推移将急剧上升；

缺陷具有放大的特点；

3）.不可能完全的测试

输入量太大

执行路径太多

注：

软件测试最致命的缺陷就是：

不能进行彻底的测试

4）.80-20原则

测试发现的错误中80%很可能起源于20%的模块中。

应孤立这些疑点模块重点测试

5）.注意测试中的群集现象

在所测程序段中，若发现错误数目多，则残存错误数目也比较多。

6）.避免测试自己的程序

程序员轻易不会承认自己写的程序有错误；

程序员的测试思路有局限性，做测试时很容易受到编程思路的影响；

程序员测试不具有典型性

7）.设计周密的测试用例

软件测试的本质就是针对要测试的内容确定一组测试用例。

测试用例至少应包括：

执行测试用例前，应满足的前提条件

输入

预期输出

设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

8）.回归测试

程序修改后必须进行回归测试，避免引入新的错误。

9）.严格执行测试计划，排除测试的随意性。

10）.确认BUG的有效性

对测试错误结果一定要有一个确认的过程。

有时候测试人员提交的BUG并不是真正的BUG。

11）.妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

12：

（1）、按是否执行被测软件划分:

动态测试

通过运行软件来检验软件的动态行为和运行结果的正确性

静态测试

不运行被测程序，而是通过在对软件进行分析、检查和审阅达到测试目的的

静态测试方法

①代码审查；

②代码走查；

③桌面检查；

④技术评审；

静态测试除了进行人工测试外，还可以借助于计算机辅助分析。

（2）、按软件测试用例设计方法的划分：

黑盒测试（Black-BoxTesting）

白盒测试（White-BoxTesting）

灰盒测试（Gray-BoxTesting）

（3）、按照软件测试的策略和过程划分：

单元测试（UnitTesting）

集成测试（IntegrationTesting）

确认测试（ValidationTesting）

系统测试（SystemTesting）

验收测试（VerificationTesting）

（4）、按测试实施组织划分

开发方测试

用户测试（β测试）

第三方测试

（5）、按是否使用工具划分

手工测试

自动化测试

按照企业中实际工作需要，测试主要包含下面的类型:

（1）功能测试

（2）接口测试（3）健壮性测试（4）强度测试

（5）压力测试（6）性能测试（7）用户界面测试（8）安全测试

（9）可靠性测试（10）安装/反安装测试（11）文档测试（12）恢复测试（13）兼容性测试（14）回归测试（15）α测试（16）β测试

13：

测试过程需要三类输入：

软件配置：

包括软件需求规格说明、软件设计规格说明、源代码等；

测试配置：

包括测试计划、测试用例、测试驱动程序等；

测试工具：

测试工具为测试的实施提供某种服务。

例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的工作台等。

14：

1、软件测试的发展历程

20世纪50-60年代

软件测试才开始与调试区别开来，成为一种发现软件缺陷的活动

70年代以后

软件技术的成熟和完善使得软件测试的规模和复杂度加大，软件测试也逐渐形成了一套完整的体系，逐渐走向规范化。

20世纪80年代早期

“质量”的号角才开始吹响

20世纪90年代

测试工具终于盛行起来

15：

软件产品组成部分

（1）程序代码

（2）帮助文件（3）用户手册

（4）样本和示例（5）标签（6）产品支持信息

（7）图表和标志（8）错误信息（9）广告与宣传材料

（10）软件的安装（11）软件说明文件

（12）测试错误提示信息

16：

测试与开发各阶段的关系

需求分析说明书---确认测试

概要设计说明书---集成测试

详细设计说明书---集成测试，单元测试

源程序代码---单元测试

17：

在集成测试过程中的两个重要的里程碑是功能冻结和代码冻结的确定

18：

软件质量：

是软件产品的特性可以满足用户的功能、性能需求的能力。

软件质量保证活动（SQA）：

是通过对软件产品有计划地进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程。

SQA与软件测试之间相辅相成，存在包含和交叉的关系。

问题1：

造成软件缺陷的主要原因有哪些？

答：

典型的软件缺陷产生的原因只要有以下几种类型：

（1）需求解释有错误

（2）用户需求定义错误（3）需求记录错误（4）设计说明错误

（5）编码说明有误（6）程序代码有误（7）数据输入有误（8）测试错误（9）问题修改不正确（10）不正确的结果是由于其他的缺陷而产生，其中导致软件缺陷最大的原因是软件产品规格说明书（需求），其次是软件设计方案和代码编写

问题2：

为何说软件缺陷的最大来源是软件产品规格说明书？

答：

（1）用户一般是非计算机专业人员，软件开发人员和用户的沟通存在较大的困难，对要开发的产品功能理解不一致。

（2）由于软件产品还没有设计、开发，完全靠想象去描述系统的实现结果，所以有些特性还不够清晰。

（3）需求变化的不一致性。

用户的需求总是在不断变化的，这些变化如果没有在产品规格说明书中得到正确的描述，容易引起前后文，上下文的矛盾。

（4）对规格说明书不够重视，在规格说明书的设计和写作上投入的人力、时间不足。

（5）没有在整个开发队伍中进行充分沟通，有时只有设计师或项目经理得打比较多的信息。

问题3：

如何看待软件测试和缺陷修复的代价？

答：

软件在从需求、设计、编码、测试一直到交付用户使用后的过程中，都有可能产生和发现缺陷。

随着整个开发过程的时间推移，在需求阶段没有被修正的错误问题或缺陷有可能不断扩展到设计阶段、编码和测试阶段，甚至到维护阶段。

而且越是软件开发后期，更正缺陷或修复问题费用越大，呈几何级数增长。

在编写产品说明书早期发现的软件缺陷，如果说费用是按元计算，则同样的软件缺陷若在软件编制完成再开始测试的时候才发现，费用将要上升十倍；如果软件缺陷

是在发售后由用户发现则修正费可能要上升上百倍。

这就说明额越是在软件开发过程的早期就发现软件的缺陷，修正缺陷的费用就越低，反之，代价是很大的。

第二章软件测试模型与过程

1：

常用测试模型：

V模型、W模型、H模型、X模型、测试前置模型（测试驱动模型）

V模型：

W模型：

H模型：

H模型说明了：

1）、软件测试不仅仅指测试的执行,还包括很多其他的活动。

2）、软件测试是一个独立的流程,贯穿产品的整个开发周期,与其它流程并发进行。

3）、软件测试要尽早准备,尽早执行。

2：

软件测试流程：

制定测试计划、测试设计、测试开发、测试执行、测试评估

注解：

制定测试计划既是完成测试的策略。

测试设计阶段要设计测试用例和测试过程，要保证测试用例完全覆盖测试需求。

测试设计阶段最重要的是如何将测试需求分解，如何设计测试用例。

测试执行过程由4个部分组成：

输入、执行过程、检查过程、输出。

软件测试的主要评测方法包括：

覆盖评测：

主要是对需求的覆盖和对代码的覆盖。

质量评测:

在测试过程中，已发现缺陷的评估提供了最佳的软件质量指标。

性能评测:

评估测试对象的性能时，侧重于获取与行为相关的数据，如响应时间、事务处理数、内存占用率、操作可靠性等。

3：

软件测试的复杂性分析：

1）、无法对程序进行完全测试

2）、测试无法显示潜在的软件缺陷和故障

3）、存在的故障现象与发现的故障数量成正比

4）、不能修复所有的软件故障

5）、软件测试的代价

4:

1、静态测试

静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。

静态测试包括代码检查、静态结构分析、代码质量度量等。

它可以由人工进行，也可以借助软件工具自动进行。

静态测试方法也可利用计算机作为对被测程序进行特性分析的工具，但与人工测试方式有着根本区别。

另一方面，因它并不真正运行被测程序，只进行特性分析，这又与动态方法不同。

所以，静态方法常常称为“分析”，静态测试是对被测程序进行特性分析方法的总称。

1、黑白盒的区别：

若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试（Black-boxTesting）方法。

若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试（White-boxTesting）方法

♦2、单元测试：

针对每个单元的测试，以确保每个模块能正常工作为目标。

♦集成测试：

对已测试过的模块进行组装，进行集成测试。

目的在于检验与软件设计相关的程序结构问题。

♦确认（有效性）测试：

是检验所开发的软件能否满足所有功能和性能需求的最后手段。

♦系统测试：

检验软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作。

♦验收（用户）测试：

检验软件产品质量的最后一道工序。

主要突出用户的作用，同时软件开发人员也应有一定程度的参与。

第四章和第五章

1、软件测试体系构成：

软件测试模型+人事组织理论

测试团队组织结构

测试流程测试技术

♦2、软件bug包括从软件失效、崩溃，到返回错误信息，以及混乱的显示。

简单地说，Bug就是软件做了没有期望它去做的事（或者相反，软件没有做到所期望它去做的事），具体来说主要表现以下几个方面：

软件没有达到产品说明书表明的功；软件出现了产品说明书中不一致的表现；软件功能超出产品说明书的范围；软件没有达到用户期望的目标（虽然产品说明书中没有要求）；测试员或用户认为软件的易用性差

♦3、软件Bug的状态：

Bug初始状态（Unfirmedd&New）；Bug分配状态（Assigned&Open）；Bug修复状态（Resolved&Fixed）；Bug关闭状态（Closed）

♦Bug暂缓状态（Suspend）；Bug重新分配状态（Reassigned&Reopen）；Bug被拒绝状态（Reject）

♦4、软件BUG的类型：

需求类BUG、分析设计类BUG、程序功能错误、程序运行时错误、编码规范类错误、数据库类错误、接口类错误、界面类错误、配置类BUG、建议性错误

♦5、严重性和优先级是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布与否。

♦注解：

对于缺陷的严重性，可以分为4个等级：

1-非常严重的缺陷，主要指程序运行时错误、需求及设计错误。

例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。

2-较严重的缺陷，主要是指功能错误等。

例如，软件的某个菜单不起作用或者产生错误的结果；3-软件一般缺陷，主要指界面错误。

例如，本地化软件的某些字符没有翻译或者翻译不准确；4-软件细微缺陷，主要是指建议性Bug,例如，某个控件没有对齐，某个标点符号丢失等；

♦6、对于缺陷的优先性，如果分为4级，则可以参考下面的方法确定：

♦1-最高优先级，主要是指

♦2-较高优先级，例如，影响软件功能和性能的一般缺陷；

♦3-一般优先级，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷；

♦4-低优先级，例如，对软件的质量影响非常轻微或出现几率很低的缺陷；

♦7、Bug管理的中的人员角色：

测试组长：

直接面对测试人员，对测试和缺陷报告的质量负责。

♦测试工程师：

负责报告缺陷，并监控所报告的缺陷的解决。

♦测试经理：

测试组长和测试工程师的领导，对测试工作的质量负责，监督测试人员。

♦程序员：

使得系统出于现状的关键人物，并负责Bug修改。

♦产品经理：

主要关心产品稳定性和技术支持成本；可能是最有力的质量支持人士；可能最关心产品能按时发布；从市场的角度对一些特定问题特别感兴趣。

♦技术支持（售后服务），工程实施人员：

需要知道产品中有多少已知的缺陷；出席缺陷延期处理评审会，就那些会增加客户服务电话比率的问题提出反对延期处理建议；有时在关键的最后时刻报告缺陷；客户报告缺陷的接口。

♦系统分析设计人员：

系统需求与设计修改者。

♦项目经理：

负责开发高质量的软件；决定缺陷修正优先次序；最终决定缺陷修正的相关事项；分配给适当的程序员。

♦高级管理者：

喜欢缺陷的统计数量，缺陷报告和修正图表；不关心单个缺陷，除非程序的行为使公司感到不安或一个非常大的吸引客户的特征出现了失败或程序的表现惹恼了用户。

♦8、Bug报告示例

♦

♦第七章单元测试

♦1、单元测试：

单元测试又称模块测试，是针对软件设计的最小单位─程序模块，进行正确性检验的测试工作。

♦单元测试主要需要测试者非常清楚代码内部结构，单元测试是软件开发人员的职责，测试人员一般不参与单元测试。

♦2、单元测试的主要目的有：

验证代码和详细设计相符合；发现设计中存在的错误；

♦发现在编码过程中引入的错误；

♦3、单元测试的依据是详细设计和概要设计，在代码编写完成后的单元测试工作主要分为两个步骤即人工静态检查（即静态测试）和动态执行测试（即动态测试）

♦其测试策略是：

自顶向下的单元测试、自底向上的单元测试、孤立单元测试

♦自顶向下的单元测试：

方法：

先对最顶层的基本单元进行测试，把所有调用的单元做成桩模块。

然后再对第二层的基本单元进行测试，使用上面已测试的单元做驱动模块。

依此类推直到测试完所有基本单元。

♦优点：

在集成测试前提供早期的集成途径。

在执行上和详细设计的顺序一致。

不需要开发驱动模块。

缺点：

随着测试的进行，测试过程越来越复杂，开发和维护成本增加。

总结：

比孤立单元测试的成本高很多，不是单元测试的一个好的选择。

♦自底向上的单元测试：

方法：

先对最顶层的基本单元进行测试，把所有调用的单元做成桩模块。

然后再对第二层的基本单元进行测试，使用上面已测试的单元做驱动模块。

依此类推直到测试完所有基本单元。

♦优点：

在集成测试前提供早期的集成途径。

在执行上和详细设计的顺序一致。

不需要开发驱动模块。

缺点：

随着测试的进行，测试过程越来越复杂，开发和维护成本增加。

总结：

比孤立单元测试的成本高很多，不是单元测试的一个好的选择。

♦孤立单元测试：

方法：

不考虑每个单元与其它单元之间的关系，为每个单元设计桩模块或驱动模块。

每个模块进行独立的单元测试。

优点：

简单、容易操作，可达到高的结构覆盖率。

♦缺点：

不提供一种系统早期的集成途径。

♦总结：

最好的单元测试策略。

♦4、单元测试输入：

《软件需求规格说明书》《软件详细设计说明书》《软件编码与单元测试工作任务书》《软件集成测试计划》《软件集成测试方案》用户文档

♦单元测试的输出：

《单元测试计划》《单元测试方案》《需求跟踪说明书》或需求跟踪记录、代码静态检查记录《正规检视报告》问题记录、 问题跟踪和解决记录

♦、软件代码开发版本《单元测试报告》《软件编码与单元测试任务总结报告》

♦5、静态测试方法：

♦同行评审的形式：

走读（Walkthrough）、小组评审（TeamReview）、审查（Inspection

♦数据流测试

♦6、评审所应注意的问题：

♦7、需求评审常见问题：

♦第八章集成测试

♦1、集成测试的定义：

集成测试又称组装测试、联合测试、子系统测试或部件测试。

集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成子系统或系统进行的测试活动。

单元测试完成后便进入集成测试阶段。

♦2、集成测试的依据：

来自系统的高层设计（架构设计或概要设计）。

具体指：

需求规格说明书、概要设计及详细设计说明书。

♦3、集成测试关注的是模块间的接口，接口之间的数据传递关系，单元组合后是否实现预计的功能。

♦4、集成测试目的

♦在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；

♦一个模块的功能是否会对另一个模块的功能产生不利的影响；

♦各个子功能组合起来，能否达到预期要求的父功能；

♦全局数据结构是否有问题；

♦单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

♦在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。

♦5、集成测试的层次：

子系统内集成测试（模块）、子系统间集成测试（可执行程序）

6、集成测试的策略：

非增值式和增值式、混合增值式策略

⏹非增值式策略：

先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。

⏹优点：

一是方法简单，二是允许多个测试人员并行工作，对人力、物力资源利用率较高。

⏹缺点：

必须为每个模块准备相应的驱动模块和辅助桩模块，故测试成本较高；其次，一旦集成后的系统包含多种错误，难以对错误定位和纠正。

⏹增值式策略：

这种集成方式又称渐增式组装。

首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。

通过增值逐步组装成为要求的软件系统。

⏹相对非增值式策略，可以较早发现模块间的接口错误；发现问题也易于定位。

它的缺点是测试周期比较长，可以同时投入的人力物力受限。

⏹混合增值式策略：

对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向上”法，两者相结合

⏹7、集成测试的方法：

a）静态测试：

概要设计的测试）动态测试:

黑盒测试，但有时候需了解内部细节并结合白盒测试，所以更多的资料将黑盒和白盒相结合的测试称为灰盒测试。

8、自动化测试：

⏹9、验收测试：

验收测试是部署软件之前的最后一个测试操作。

⏹验收测试的目的是：

确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

⏹施验收测试的常用策略有三种，它们分别是：

⏹正式验收测试

⏹非正式验收或α测试：

测试员充当用户进行实施。

⏹β测试：

最终由用户实施

♦第九章系统测试

1、系统测试定义：

系统测试是将通过确认测试的软件，作为整个基于系统的一个元素，与硬件、某些支持软件和人员等其它系统元素结合在一起，在实际运行环境下，对系统进行一系列的组装测试和确认测试。

2、系统测试目的：

系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统的定义不符合或与之矛盾的地方

3、系统测试对象：

系统测试对象为整个产品系统，它不仅包括产品系统的软件，还要包含系统软件所依赖的硬件、外设甚至包括接口。

4、系统测试依据：

系统的需求规格说明书、概要设计说明书、各种规范

5、系统测试层次：

用户层测试、应用层测试、功能层测试、指标/协议层测试

用户层测试：

用户层测试是面向产品使用者的测试，它包括：

用户支持、用户界面、安全性、可维护（自检有效性、远程维护、软件加载和升级）

应用层测试：

应用层测试主要是针对产品工程稳定性的测试，它考察一个产品在实际应用背景下的功能实现、性能表现等情况，它包括以下几个测试方面：

系统性能、系统可靠性、稳定性、版本兼容性、系统安装升级

功能层测试：

在设计功能层的系统测试方案时，我们需要考虑以下几个步骤:

✧根据市场调查或规格说明书输出产品的功能概图，概图提供产品的功能列表和功能使用频度；

✧功能概图应该保证重要的产品功能的完全覆盖；

✧产品功能测试可根据功能概图提供的测试优先次序进行进度和资源的调配；

✧产品特性里概念性功能可逐步分解，直至能够对产品进行输入和输出测试的可实施操作（基本功能）；

✧对产品的不同功能进行组合，考虑各类功能的组合测试方案。

指标/协议层测试：

指标/协议层测试往往根据规格说明书和产品标准（包括国际和国内标准）进行验证测试，它强调的是标准的符合性，测试项目为预定义的产品规格、行业标准、如新国际测试、ITUT标准测试等等。

6、系统测试方法:

主要分为静态测试和动态测试

7、功能测试：

功能测试是系统测试中最基本的测试，它不管软件内部的实现逻辑，主要根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格。

8、性能测试：

进行测试来评估一个组件或被测应用符合指定性能需求的程度，性能测试是一种特殊的非功能测试，衡量执行的速度和在典型工作条件下被测应用的响应以便确定这些特性是否满足被测应用的用户的需求。

9、软件开发过程中会经常看到两个关于需求的文档

a）用户需求说明书

b）产品需求规格说明书

系统静态测试的对象是产品需求规格说明书

用户需求说明书重点在用户  就是把用户的需求文字化专业化的过程  比如盖个房子  你总得知道住的人要不要门要几个门

产品规格说明书  就是说我们要做一个什么要的软件出来  比如盖个房子你总得知道有门没有门有几个门怎么样的门用户会喜欢

10、系统静态测试采用的同行评审中的小组评审。

⏹需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。

⏹如何进行有效需求评审呢？

⏹分层次评审

⏹正式评审与非正式评审结合

⏹分阶段评审

⏹精心挑选评审员

⏹对评审员进行培训

⏹充分利用需求评审检查单

⏹建立标准