软件测试技术总结（共5篇）

第一篇：软件测试技术总结

IT公司面试手册提供最全的IT类面试题, 包括

Java：Java面试题 J2EE面试题 Hibernate面试题 Spring面试题Struts面试题EJB面试题.NET:.net面试题 ASP.NET面试题 C#面试题

数据库：数据库面试题Oracle面试题 SQL Server面试题 MySql面试题

网络：网络技术面试题 网络安全面试题

Web开发：PHP面试题 Web开发面试题

Linux Unix：Unix面试题Linux面试题

软件测试： 软件测试面试题

其他类： 英语面试 外企面试 Python面试题 程序员面试

更多面试题请访问： http://

软件测试技术总结

软件测试就是为了发现程序中的错误而分析和执行程序的过程。——概念

+基本知识+软件开发过程-定义-计划-实现-稳定化-部署

一、软件开发模型(四种典型的模型)

1、瀑布模型

概述：包括计划，需求分析，设计，编码，测试，运行维护六个阶段。六个阶段自上而下、相互衔接，以固定的次序进行。

特点：1.阶段的顺序性和依赖性；2.文档驱动；3.推迟实现的观点； 4.质量保证。

缺点：不适合需求模糊的系统

2、原型模型

概述：先建立一个能够反映用户需求的原型系统，使得用户和开发者可以对目标系统的概貌进行评价和判断，然后对原型系统进行反复的扩充、改进、求精，最终建立符合用户需求的目标系统。

特点：1.快速开发工具；2.循环； 3.低成本。

分类：按照对原型的处理方式，可以分为渐进型和抛弃型。

3、增量模型

概述：在增量模型中每个阶段都生成软件的一个可发布版本，阶段交错进行，版本逐渐完善。同原型模型的最大区别在于，在原型模型中每个阶段发布一个原型而在增量模型中则完成一个正式版本。

4、螺旋模型

概述：适用于大型软件的开发，它将瀑布模型和快速原型模型结合起来，并加入了风险分析。特点：1.每个阶段都包括制定计划，风险分析，实施工程，评审四个阶段；2.开发过程迭代进行，每迭代一次螺旋线增一周，工程前进一个层次，系统生成一个新版本，投入新的时间成本，最终得到客户满意的版本。-软件测试从需求开始：现代的软件测试将测试渗入到软件开发的各个阶段，即使瀑布模型，表面看测试工作是在测试阶段开始的，事实上，在计划、需求、设计阶段，测试人员便已经开始了他们的工作，如：了解软件需求，编写测试计划，搭建测试环境。

二、测试用例

1、三要素：前提条件和操作步骤、预期结果、实际结果。

2、必须以需求为依据。

三、软件测试分类

1、是否关注软件结构和算法

-黑盒测试：基于软件需求的测试方法。-白盒测试：基于软件内部设计和程序实现的测试方法。

2、是否执行被测试软件

-动态测试：在测试过程中执行被测试软件的测试方法。-静态测试：------------不----------------------。

3、基于不同的测试阶段：

1、单元测试：主要测试软件的单元模块，需要编写额外的测试驱动程序，采用白盒测试的方法，一般由 开发人员完成。

2、集成测试：将一些“构件”集成在一起时测试他们是否能正常运行，构件可以是程序模块，也可以是客户机-服务器程序等，需要编写测试仿真程序，采用白盒和黑盒相结合的方式，通常由 开发人员承担。

3、系统测试：测试软件系统是否符合所有的需求，包括功能性测试和非功能性测试。一般由独立的测试人员完成，通常采用黑盒测试方法。

4、验收测试：(α、β)与系统测试类似，但由客户或最终用户执行，测试软件是否符合需求规格说明书。

5、回归测试：指在软件开发过程中，每次错误被修正后或软件的功能、环境发生变化后进行的测试。

四、软件测试的三个步骤：

1、测试计划：测试人员首先对需求进行分析，最终定义一个测试集合，通过刻画和定义测试发现需求中的问题，然后根据软件需求同测试主管制定并确认“测试计划”。

2、测试设计和开发：软件测试人员根据软件需求和软件设计说明书完成测试用例的设计和必要的测试驱动程序的开发。

3、执行测试：需要做的工作包括搭建测试环境、运行测试、记录测试结果、报告软件缺陷、跟踪软件缺陷、分析测试结果，必要时进行回归测试。

五、测试工程师的能力要求：

1、5C

-Controlled /kEn'trEuld/ 接受管理，有条理的-Competent /'kCmpitEnt/了解正确的测试技术

-Critical /'kritikEl/专注于发现问题

-Comprehensive /.kCmpri'hensiv/ 注意细节

-Considerate /kEn'sidErit/能够和开发人员很好的交谈

2、职业素质-责任心-学习能力-怀疑精神-沟通能力-专注力-洞察力-团队精神-注重积累

六、制定测试计划的五个步骤：

1、分析和测试软件需求

2、定义测试策略

3、定义测试环境

4、定义测试管理

5、编写和审核测试计划

如果在需求分析阶段发现并结果问题需要花费$1，则在设计阶段解决同样的问题需花费$5，在编码阶段需$10，交付后解决同样的问题需花费$200。——越早测试越好

七、在需求分析过程中测试人员需要进行如下工作：

1)理解需求，参与审核需求文档；2)理解项目的目标、限制，了解用户的应用背景；

3)编写测试计划；4)准备测试资源。

八、需求测试

-需求测试测试的对象是主意而不是代码，针对文档进行测试。

九、好的需求文档的特征

1、具有清晰的格式和文档结构

2、需求的内容正确

3、需求的内容完整

4、需求具有可行性需求的必要性

5、对不同的需求优先等级进行定义

6、描述明确

7、可证性和可测试性

8、可修改性-可追踪

9、需求文档被及时更新

十、需求测试内容

1、需求文档是否符合公司的格式要求

2、是否正确

3、要保证需求文档中所描述的内容是真实可靠的4、这是“真正的”需求吗？描述的产品是否是要开发的产品？

5、需求是否完备？第一个发布的版本是否需要更多的功能？列出的需求可以减少一部分？

6、需求是否兼容？需求有可能是矛盾的。

7、需求是否可实现？如：需求设想的设备是否比实际运行的要快？需求要求的内存、I/0设备是否太多？需求的输入或输出设备要求的分辨率是否要求过高？

8、需求是否合理？在开发进度、开发费用、产品性能、可靠性和内存使用之间存在着平衡关系。

9、需求是否可测？对于软件测试人员来说判断需求是否可测是这个过程中最重要的工作。

十一、需求测试方法

1、复查review2、走查walkthrough3、审查inspection

十二、测试策略的内容

1、确定测试范围 软件是无法被完全测试的2、确定测试方法 不同的系统需要不同的测试方法

3、定义测试标准 入口标准，暂停和继续的标准，出口标准等

十三、软件测试结束的标准

-基于测试用例的使用规则

1)构造测试用例（由相关人员进行评审）

2)执行测试用例中，当测试用例的不通过率达到20%则拒绝继续测试，待开发人员修正软件后再继续。

3)当功能性测试用例通过率达到100%，非功能性测试用例通过率达到90%时，允许正常结束。

-基于“测试期缺陷密度”规则---------含义：对软件测试一个CPU小时发现的缺陷数，比较适用于系统测试-基于“运行期缺陷密度”规则---------含义：把软件运行一个CPU小时发现的缺陷数，比较适用于验收测试注：一个阶段的出口标准!=下一个阶段的入口标准

系统测试结束的标准!=软件的发布标准发布标准!=软件0缺陷

-选择测试工具 是否需要，需要什么工具，怎么获取

-降低软件测试代价是企业普遍关注的问题，可通过

a.减少冗余和无价值的测试；b.减少测试阶段(万般无奈下)

十四、测试环境

-基本内容：设备环境、软件环境、数据环境

-需考虑的因素-计算机平台-操作系统-浏览器-软件支持平台-外围设备-网络环境-其他专用设备-搭建测试环境时的配置原则：-使用的频度或范围-实效的可能性-最大限度的模拟真实环境

十五、测试管理

由于测试工程中设计的人员、活动、工具是很多的，在制定测试计划时需要对这些因素进行管理-选择缺陷管理工具和测试管理工具-定义工作进度

-建立风险管理计划

(1)可能遇到的风险

1.由于设计、编码阶段出现大量质量问题，导致测试工作量时间增加

2.开始测试时所需的硬件、软件没有准备好3.未能完成对测试人员的技术培训

4.测试时的人力资源安排不足5.测试过程中，发生了大量的需求变更

6.测试过程中，项目的开发计划被大幅度调整7.不能及时准备好测试所需的环境

8.不能及时准备好测试数据

(2)风险管理的过程

1.识别风险2.评估风险3.制定对策4.跟踪风险

+测试设计与开发

+总体设计

-投入产出：测试设计的输入是测试计划，输出是评审过的测试用例集合-定义设计目标遵循的原则

(-清楚地说明没项测试的目标-使每项测试的目标单一，可以对应到规格说明书中的一项需求-只说明测试应该完成什么工作，而不说明如何完成)

-流程：总体设计-开发测试用例-评审测试用例

I.定义设计目标II.定义输入说明III.定义测试环境和配置

IV.测试设计文档V.开发测试用例

+测试用例——概念：为特定目标开发的测试输入、执行条件和预期结果的集合。

+好的测试用例：

1.容易发现软件的错误2.精确的重复某测试失败的情景，可重复性

3.清晰的定义一个或多个期望的结果4.没有冗余

+测试用例的作用

-指导测试的实施-作为编写测试脚本的“设计规格说明书”-评估测试标准的度量基准-分析缺陷的标准 +白盒测试用例设计

+设计方法

+逻辑覆盖法

(-语句覆盖-判定覆盖-条件覆盖-判定-条件覆盖-条件组合覆盖-路经覆盖-基本路经法)

+辅助模块设计

(1.驱动模块：相当于被测程序的主程序。接受测试数据，把这些数据传给被测模块然后输出实际测试结果。

2.桩模块：用于调用被测模块调用的子模块。可以做少量的数据操作，不需要把子模块的所有功能都带进来，但不容许什么都不做。)

+黑盒测试用例设计

-等价类划分法

-边界值法——“缺陷遗漏在角落里，聚集在边界上。”

-因果图法弥补等价类和边界值法的不足

-错误推测法

-测试用例的管理可以通过配置管理工具cvs,vss,ClearCase等实现，以保证测试是可重复的。

+常见错误分析

-用户界面问题

·输入无合法性检查和值域检查。

·界面信息不能及时更新，不能正确反映数据状态，甚至对用户产生误导。

·表达不清或过于模糊的信息提示。

·要求用户输入多余的本来系统可以自己得到的数据。

·为了得到某个设置或对话框用户必须做许多冗余的操作，如对话框嵌套太多。

·不能记忆用户的设置或操作习惯，使每次进入系统用户都需重新操作一次初始环境。

·不经用户确认就对系统或数据进行了重大修改。

-形象类问题

·不符合用户的操作习惯。如，快捷键定义不科学不实用，甚至无快捷键。

·不够专业，缺乏基本知识。

·界面中英文混杂，甚至拼写错误。

·说明书或帮助的排版格式不专业：中英文不对应，标点的半全角问题，没有排版准则。

·界面元素参差不齐，文字不能完全显示。

－稳定性问题

·不可重现的死机，或不断申请但不能完全释放资源，使系统性能越来越低。

·主系统和子系统使用了相同的临界资源而相互不知道。如：使用相同的类名或临时文件名、使用同样的数据库字段名或登陆帐号。

·不能重现的错误，许多与代码中的未初始化变量有关，有些与系统不检查异常情况(网络中断、内存申请不成功、长时间无响应等)有关。

-其他问题

·运行时不检查内存、硬盘空间、数据库等。

·无根据的假设用户环境：硬件/网络情况；有些动态库；假设网络随时都是联通的。

·提供的版本带病毒。

·提供错误的版本给测试组或测试用户，或程序员与测试组使用不同版本。

·用户现场开放和修改，又没有记录和保留。

·版本中部分内容或接口倒退，或出现版本管理混乱。

·有些选项永远都是灰的，或有些在该变灰时没变灰。

+测试用例的评审

-测试或测试组件完全针对的是需求中列出的功能吗？

-测试组件是否覆盖了所有的需求？

-有冗余的吗？

-每个测试步骤都有清楚描述的预期结果吗？

+优先级

+3级

优先级1：此测试用例必须执行-2：有时间就执行-3：可以不执行

+5级

1：此测试必须通过，否则产品发布存在危险2：在发布前必须执行3：时间允许就执行4：此测试可以在下一次发布或发布后短期内执行5：可以不测试

第二篇：软件测试技术面试总结

软件测试就是为了发现程序中的错误而分析和执行程序的过程。——概念

+基本知识+软件开发过程-定义-计划-实现-稳定化-部署

+软件开发模型(四种典型的模型)

+瀑布模型

-概述：包括计划，需求分析，设计，编码，测试，运行维护六个阶段。六个阶段自上而下、相互衔接，以固定的次序进行。

-特点：1.阶段的顺序性和依赖性；2.文档驱动； 3.推迟实现的观点；4.质量保证。-缺点：不适合需求模糊的系统

+原型模型-概述：先建立一个能够反映用户需求的原型系统，使得用户和开发者可以对目标系统的概貌进行评价和判断，然后对原型系统进行反复的扩充、改进、求精，最终建立符合用户需求的目标系统。

-特点：1.快速开发工具；2.循环； 3.低成本。

-分类：按照对原型的处理方式，可以分为渐进型和抛弃型。

+增量模型

-概述：在增量模型中每个阶段都生成软件的一个可发布版本，阶段交错进行，版本逐渐完善。

-同原型模型的最大区别在于，在原型模型中每个阶段发布一个原型而在增量模型中则完成一个正式版本。+螺旋模型

-概述：适用于大型软件的开发，它将瀑布模型和快速原型模型结合起来，并加入了风险分析。

-特点：1.每个阶段都包括制定计划，风险分析，实施工程，评审四个阶段；

2.开发过程迭代进行，每迭代一次螺旋线增一周，工程前进一个层次，系统生成一个新版本，投入新的时间成本，最终得到客户满意的版本。

-软件测试从需求开始：现代的软件测试将测试渗入到软件开发的各个阶段，即使瀑布模型，表面看测试工作是在测试阶段开始的，事实上，在计划、需求、设计阶段，测试人员便已经开始了他们的工作，如：了解软件需求，编写测试计划，搭建测试环境。

-测试用例

-三要素：前提条件和操作步骤、预期结果、实际结果。

-必须以需求为依据。

-软件测试分类

-是否关注软件结构和算法

-黑盒测试：基于软件需求的测试方法。

-白盒测试：基于软件内部设计和程序实现的测试方法。

-是否执行被测试软件

-动态测试：在测试过程中执行被测试软件的测试方法。

-静态测试：------------不----------------------。

-基于不同的测试阶段：

-单元测试：主要测试软件的单元模块，需要编写额外的测试驱动程序，采用白盒测试的方法，一般由 开发人员完成。

-集成测试：将一些“构件”集成在一起时测试他们是否能正常运行，构件可以是程序模块，也可以是

客户机-服务器程序等，需要编写测试仿真程序，采用白盒和黑盒相结合的方式，通常由 开发人员承担。

-系统测试：测试软件系统是否符合所有的需求，包括功能性测试和非功能性测试。一般由

独立的测试

人员完成，通常采用黑盒测试方法。

-验收测试：(α、β)与系统测试类似，但由客户或最终用户执行，测试软件是否符合需求规格说明书。

-回归测试：指在软件开发过程中，每次错误被修正后或软件的功能、环境发生变化后进行的测试。

-软件测试的三个步骤：

-测试计划：测试人员首先对需求进行分析，最终定义一个测试集合，通过刻画和定义测试发现需求中的问题，然后根据软件需求同测试主管制定并确认“测试计划”。

-测试设计和开发：软件测试人员根据软件需求和软件设计说明书完成测试用例的设计和必要的测试驱动 程序的开发。

-执行测试：需要做的工作包括搭建测试环境、运行测试、记录测试结果、报告软件缺陷、跟踪软件缺陷、分析测试结果，必要时进行回归测试。

-测试工程师的能力要求：

+5C

-Controlled /kEn'trEuld/ 接受管理，有条理的-Competent /'kCmpitEnt/了解正确的测试技术

-Critical /'kritikEl/专注于发现问题

-Comprehensive /.kCmpri'hensiv/ 注意细节

-Considerate /kEn'sidErit/能够和开发人员很好的交谈

+职业素质-责任心-学习能力-怀疑精神-沟通能力-专注力-洞察力-团队精神-注重积累 +制定测试计划的五个步骤：-分析和测试软件需求-定义测试策略

-定义测试环境

-定义测试管理

-编写和审核测试计划

如果在需求分析阶段发现并结果问题需要花费$1，则在设计阶段解决同样的问题需花费$5，在编码阶段需$10，交付后解决同样的问题需花费$200。——越早测试越好-在需求分析过程中测试人员需要进行如下工作：

1)理解需求，参与审核需求文档；

2)理解项目的目标、限制，了解用户的应用背景；

3)编写测试计划；

4)准备测试资源。

+需求测试

-需求测试测试的对象是主意而不是代码，针对文档进行测试。

+好的需求文档的特征-具有清晰的格式和文档结构-需求的内容正确-需求的内容完整-需求具有可行性需求的必要性

-对不同的需求优先等级进行定义-描述明确-可证性和可测试性-可修改性-可追踪-需求文档被及时更新

+需求测试内容

-需求文档是否符合公司的格式要求

-是否正确

-要保证需求文档中所描述的内容是真实可靠的-这是“真正的”需求吗？描述的产品是否是要开发的产品？

-需求是否完备？第一个发布的版本是否需要更多的功能？列出的需求可以减少一部分？-需求是否兼容？需求有可能是矛盾的。

-需求是否可实现？如：需求设想的设备是否比实际运行的要快？需求要求的内存、I/0设备是否太多？

需求的输入或输出设备要求的分辨率是否要求过高？

-需求是否合理？在开发进度、开发费用、产品性能、可靠性和内存使用之间存在着平衡关系。

-需求是否可测？对于软件测试人员来说判断需求是否可测是这个过程中最重要的工作。+需求测试方法-复查review-走查walkthrough-审查inspection

+测试策略的内容

-确定测试范围 软件是无法被完全测试的-确定测试方法 不同的系统需要不同的测试方法

-定义测试标准 入口标准，暂停和继续的标准，出口标准等

+软件测试结束的标准

-基于测试用例的使用规则

1)构造测试用例（由相关人员进行评审）

2)执行测试用例中，当测试用例的不通过率达到20%则拒绝继续测试，待开发人员修正软件后再继续。

3)当功能性测试用例通过率达到100%，非功能性测试用例通过率达到90%时，允许正常结束。

-基于“测试期缺陷密度”规则

--------------含义：对软件测试一个CPU小时发现的缺陷数，比较适用于系统测试-基于“运行期缺陷密度”规则

--------------含义：把软件运行一个CPU小时发现的缺陷数，比较适用于验收测试注：一个阶段的出口标准!=下一个阶段的入口标准

系统测试结束的标准!=软件的发布标准

发布标准!=软件0缺陷

-选择测试工具 是否需要，需要什么工具，怎么获取

-降低软件测试代价是企业普遍关注的问题，可通过

a.减少冗余和无价值的测试；

b.减少测试阶段(万般无奈下)

+测试环境

-基本内容：设备环境、软件环境、数据环境

-需考虑的因素-计算机平台-操作系统-浏览器-软件支持平台-外围设备-网络环境-其他专用设备

-搭建测试环境时的配置原则：-使用的频度或范围-实效的可能性-最大限度的模拟真实环境 +测试管理 由于测试工程中设计的人员、活动、工具是很多的，在制定测试计划时需要对这些因素进行管理

-选择缺陷管理工具和测试管理工具

-定义工作进度

-建立风险管理计划

+可能遇到的风险

·由于设计、编码阶段出现大量质量问题，导致测试工作量时间增加

·开始测试时所需的硬件、软件没有准备好

·未能完成对测试人员的技术培训

·测试时的人力资源安排不足

·测试过程中，发生了大量的需求变更

·测试过程中，项目的开发计划被大幅度调整

·不能及时准备好测试所需的环境

·不能及时准备好测试数据

+风险管理的过程

·识别风险

·评估风险

·制定对策

·跟踪风险

+测试设计与开发

+总体设计

-投入产出：测试设计的输入是测试计划，输出是评审过的测试用例集合-定义设计目标遵循的原则

-清楚地说明没项测试的目标

-使每项测试的目标单一，可以对应到规格说明书中的一项需求

-只说明测试应该完成什么工作，而不说明如何完成-流程：总体设计-开发测试用例-评审测试用例

I.定义设计目标

II.定义输入说明

III.定义测试环境和配置

IV.测试设计文档

V.开发测试用例

+测试用例

-概念：为特定目标开发的测试输入、执行条件和预期结果的集合。

+好的测试用例：

-容易发现软件的错误

-精确的重复某测试失败的情景，可重复性

-清晰的定义一个或多个期望的结果

-没有冗余

+测试用例的作用

-指导测试的实施

-作为编写测试脚本的“设计规格说明书”

-评估测试标准的度量基准

-分析缺陷的标准

+白盒测试用例设计

+设计方法

+逻辑覆盖法

-语句覆盖

-判定覆盖

-条件覆盖

-判定-条件覆盖

-条件组合覆盖

-路经覆盖

-基本路经法

+辅助模块设计

-驱动模块：相当于被测程序的主程序。接受测试数据，把这些数据传给被测模块然后输出实际测试结果。

-桩模块：用于调用被测模块调用的子模块。可以做少量的数据操作，不需要把子模块的所有功能都带进来，但不容许什么都不做。

+黑盒测试用例设计

-等价类划分法

-边界值法——“缺陷遗漏在角落里，聚集在边界上。”

-因果图法弥补等价类和边界值法的不足

-错误推测法

-测试用例的管理可以通过配置管理工具cvs,vss,ClearCase等实现，以保证测试是可重复的。+常见错误分析

-用户界面问题

·输入无合法性检查和值域检查。

·界面信息不能及时更新，不能正确反映数据状态，甚至对用户产生误导。

·表达不清或过于模糊的信息提示。

·要求用户输入多余的本来系统可以自己得到的数据。

·为了得到某个设置或对话框用户必须做许多冗余的操作，如对话框嵌套太多。·不能记忆用户的设置或操作习惯，使每次进入系统用户都需重新操作一次初始环境。·不经用户确认就对系统或数据进行了重大修改。

-形象类问题

·不符合用户的操作习惯。如，快捷键定义不科学不实用，甚至无快捷键。

·不够专业，缺乏基本知识。

·界面中英文混杂，甚至拼写错误。

·说明书或帮助的排版格式不专业：中英文不对应，标点的半全角问题，没有排版准则。·界面元素参差不齐，文字不能完全显示。

－稳定性问题

·不可重现的死机，或不断申请但不能完全释放资源，使系统性能越来越低。

·主系统和子系统使用了相同的临界资源而相互不知道。如：使用相同的类名或临时文件名、使用同样的数据库字段名或登陆帐号。

·不能重现的错误，许多与代码中的未初始化变量有关，有些与系统不检查异常情况(网络中断、内存申请

不成功、长时间无响应等)有关。

-其他问题

·运行时不检查内存、硬盘空间、数据库等。

·无根据的假设用户环境：硬件/网络情况；有些动态库；假设网络随时都是联通的。·提供的版本带病毒。

·提供错误的版本给测试组或测试用户，或程序员与测试组使用不同版本。

·用户现场开放和修改，又没有记录和保留。

·版本中部分内容或接口倒退，或出现版本管理混乱。

·有些选项永远都是灰的，或有些在该变灰时没变灰。

+测试用例的评审

-测试或测试组件完全针对的是需求中列出的功能吗？

-测试组件是否覆盖了所有的需求？

-有冗余的吗？

-每个测试步骤都有清楚描述的预期结果吗？

+优先级

+3级

优先级1：此测试用例必须执行-2：有时间就执行-3：可以不执行

+5级

1：此测试必须通过，否则产品发布存在危险2：在发布前必须执行3：时间允许就执行4：此测试可以在下一次发布或发布后短期内执行5：可以不测试

第三篇：软件测试总结

1.软件测试定义：由人工或自动方法来执行或评价系统或系统部分的过程，以验证它是否满足规定的需求，或识别出期望的结果和实际结果之间的差异。2.软件测试的分类：

测试对象或范围分类：需求评审、设计评审、单元测试、程序测试、系统

测试、文档测试、Web应用测试、客户端测试、数据库测试等；

测试目的分类：集成测试、功能测试、压力测试、性能测试等等； 静态测试、动态测试； 白盒测试、黑盒测试。3.软件测试的基本流程与原则

基本流程：

测试用例设计-输入数据、预期结果； 测试执行-输入数据执行被测对象； 检查实际输出与预期结果。基本原则：

开始测试时认定软件有错，测试要证明有错； 测试应该由独立的测试团队来完成； 测试设计必须设计对应的预期输出；

要对合理、不合理（有效、无效）输入数据都进行测试； 检查软件的完备性、多余； 完整保留测试文档；

一个被测对象中有错误的概率与已发现错误的个数成正比。4.Beizer测试成熟度级别：

0级：没有区分测试与调试；

1级：测试的目的是证明软件能用； 2级：测试的目的是证明软件不能用；

3级：测试的目的不是为了证明什么，而是为了降低软件使用风险； 4级：测试是一种智能训练，能够帮助专业人员开发出更高质量的软件。5.软件测试与软件工程，软件过程的关系：

软件工程：在给定的条件下（成本、时间）开发出高质量的软件产品。软件生产过程的特性决定了软件产品中不可避免包含有错误。软件测试则是尽可能多地发现错误，从而保障软件产品的质量。6.McCall的质量因素：

产品修改：

可维护性，灵活性，可测试性 产品转移：

可移植性，可复用性，互操作性 产品运行：

正确性，易用性，可靠性，效率，完整性 7.软件质量困境

软件质量必须足够好：存在价值

软件产品无法完美：需要消耗过多的资源、时间、成本

软件开发需要在两个极端之间进行平衡：软件足够好的同时又不完美。8.质量控制、质量保证和质量管理

软件质量控制其实是基本方法，通过一系列的技术来科学地测量过程的状态。如缺陷率、测试覆盖率等。

软件质量保证则是过程的参考、指南的集合，如ISO9000、CMM/CMMI等，着重内部的检查，确保已获取认可的标准和步骤都已经遵循。

软件质量管理则是实际操作的思想，质量管理控制和协调组织的质量活动，包括质量控制、质量保证和质量改进。9.WebApp应用的属性：

网络密集型应用；并发性；大负载量；性能；高可靠性、高可用性；安全性-内容敏感；

10.软件评审的目的，评审度量及其应用

评审的目标在于：尽早发现软件过程中的错误，防止错误传递、蔓延至后续活动，防止错误转化为缺陷。

准备工作量Ep-实际评审会之前所需工作量； 评估工作量Ea-实际评审所花费的工作量 返工工作量Er-修改评审所发现错误的工作量 工作产品规模WPS-评审对象的规模

发现的主要错误数Errmajor-多于预期的改错工作量的错误数目 发现的次要错误数Errminor-少于预期的改错工作量的错误数目 总评审工作量Ereview = Ep+Ea+Er 错误总数Errtot = Errmajor+Errminor 错误密度：评审的每单位工作产品发现的错误数Ed = Errtot / WPS 错误密度数值的含义：较小（产品质量非常好或评审不够彻底）；较大（产品质量存在缺陷）

11.软件测试计划：描述对计算机软件配置项、子系统、系统进行测试的计划安排，内容包括测试的环境、测试工作的标识及测试工作的时间安排。

软件测试报告：是对计算机软件配置项、软件系统或子系统，或与软件相关项目执行合格性测试的记录 12.软件测试活动

制订测试计划（测试分析员）

测试设计（测试设计人员）－方案设计 测试及测试用例设计 测试过程

桩模块、驱动模块设计

测试实施（测试设计员）－实现测试设计 单元测试（测试员）集成测试（测试员）系统测试（测试员）

评估测试（测试设计人员）

13.无向图的相关定义：

连接性：节点ni、nj是连接的，当且仅当ni、nj在同一条路径上。组件：图的组件是相连节点的最大集合

图G的圈复杂度V（G)＝e－n＋2p，其中e为G的边数，n为节点数，p为组件数。14.图覆盖：给定一个关于图G的准则C的测试需求集合TR，测试集合T在图G上满足准则C当且仅当对TR中每个测试需求tr，path(T)中至少存在一条测试路径p满足tr。

简单路径：如果从ni到nj的一条路径中，除了始节点和终节点可以相同外，没有任何节点出现次数多于一次，则该路径为简单路径。

主路径：如果从ni到nj是一条简单路径，并且它不作为任何其他简单路径的子路径出现，则称之为主路径。

主路径覆盖（PPC）准则：TR包含图中每一条主路径。

指定路径覆盖（SPC)：TR包含一个测试路径集S，S为指定参数。15.白盒测试方法

白盒测试：根据被测对象的内部结构和运行机制来设计测试用例的方法，又称为结构测试、逻辑驱动测试、覆盖测试

被测对象的独立路径至少覆盖一次； 所有逻辑取值测试[真、假]； 循环边界测试；

检查内部数据结构、边界条件。16.黑盒测试方法

黑盒测试方法又称功能测试方法、数据驱动测试方法，测试设计时不考虑被测对象的内部结构，以检查系统功能（功能的正确、完整、逻辑流程、人机界面、文档内容、系统安装/初始化）

以被测对象的外部特征为测试依据。17.模糊测试方法

模糊测试方法：构造大量的随机数据作为系统的输入，从而检验系统在各种数据情况下是否出现问题。

18.增量测试：单元测试、调用依赖的模块集成测试，逐步扩展直到形成整个软件系统。

19.突击测试：所有模块一次性集成为一个完整的系统，然后进行完全测试。20.等价类划分：

等价类划分基于对输入或输出数据情况的评估，划分成两个或多个子集（等价类），然后从每个子集中选取一定的代表进行测试的测试用例设计方法。21.极限测试

极限编程：利用轻量、敏捷的开发过程，使开发人员能够更快地完成应用程序的开发。强调频繁测试、测试驱动的方式保证软件质量。

极限测试：为满足极限编程思想和过程而设计的一套测试策略和流程，原来的测试技术、方法均可以使用 22.配置项测试的内容

功能: 适合性

准确性：功能的准确与精度要求 互操作性：与外部设备、系统的接口 安全保密性：数据访问的可控制性 可靠性: 成熟性：容错处理、平均无故障时间

容错性：边界条件、功能、性能的降级情况、误操作模式、故障模式 易恢复性：自动修复能力/时间、平均宕机时间、平均恢复时间、恢复能力等 易用性

易理解性：功能描述清晰、准确；界面含义精确

易学性：在线帮助、帮助定位、各类手册的易学、易用 易操作性：数据的有效检查、解释信息明确、界面切换 吸引性：人机界面定制 效率

时间特性：响应时间、平均响应时间、响应极限时间、吞吐量、平均吞吐量、极限吞吐量，多任务并行测试

资源利用：大量并发任务下I/O设备利用、极限负载下I/O设备的负载、大量并发任务下用户等待时间、内存使用情况、数据传输能力等

维护性

易分析性：运行状态数据易分析 易变更性：软件的可配置、修改能力 易测试性：变更之后的易测试情况 可移植性

适应性：不同软件、硬件环境的适应能力 易安装性：安装、配置的复杂程度、难以程度 共存性：与其他软件协同的能力 易替换性：版本的替换难以程度 依从性

以上所有特性遵循标准、规范的情况测试

23系统测试：系统非功能性测试，以检验系统在超常数据规模或负载下，线程、CPU、内存资源的利用和响应时间、数据传输等性能指标是否满足要求

24.测试计划

确定测试充分性要求：覆盖范围、覆盖程度 确定测试终止要求； 确定测试所需资源； 确定测试的软件特性； 确定测试技术、方法； 确定测试准出条件； 确定测试进度计划； 测试风险分析。

25.测试设计：测试设计人员、测试程序员

测试用例设计：依据测试特性； 获取测试数据；

确定测试顺序：资源、被测特性； 获取测试资源：软硬件、工具； 编写测试程序； 建立测试环境； 撰写测试设计说明。

26.测试总结：

测试分析员－测试报告

总结测试计划、测试说明的变化情况； 异常终止时测试未覆盖范围； 未能解决的测试问题； 总结测试结果（发现问题）； 编写测试报告；

根据问题报告、测试记录，编写测试问题报告。

27.软件可靠性：在给定的运行时间内和给定的系统配置环境下，运行给定的软件功能时所 表现出来的质量能力 28.系统性能指标

系统资源利用率：分析性能指标，改善性能系统行为指标 请求响应时间：一次请求完成时间

事务响应时间：一个事务所有请求完成的总时间

数据吞吐量：单位时间内服务器接收、发送的数据量。

29.验收测试：用户执行的、使用真实数据进行的测试，依据需求规格中的确认标准进行测试。回归测试：验证已测试过的内容不受变更影响，确认变更没有引入新的错误。

30.α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操 作环境下进行的测试。

Beta测试由软件的最终用户在一个或多个客户场所进行，开发者通常不在Beta测试的现场。

31.WebApp测试关注的主要内容 Web内容测试 界面 构件

导航测试 安全性 性能

32.测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

33.软件生存期定义：从软件产品设计到软件被淘汰的时间段。又称软件生命周期、生存周期。进一步划分为两个阶段：开发阶段和维护阶段（40%+60%）。

34.软件安全定义：一种软件质量保证活动，他主要用来识别和评估可能对软件产生负面影响并促使整个系统失效的潜在灾难。

35.软件评审的目标在于：尽早发现软件过程中的错误，防止错误传递、蔓延至后续活动，防止错误转化为缺陷。36.V模型

优点：既有底层测试又有高层测试。底层：单元测试。高层：系统测试。

将开发阶段清楚的表现出来，便于控制开发的过程。当所有阶段都结束时，软件开发就结束了。

缺点：容易让人误解为测试是在开发完成之后的一个阶段。

由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源。

实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试，返工量大。37.W模型：

优点：

将测试贯穿到整个软件生命周期中，且除了代码要测试，需求、设计等都要测试。更早介入软件开发中，能尽早发现缺陷并修复。

测试与开发独立起来，并与开发并行。缺点：

对有些项目，开发过程中根本没有文档产生，故W模型无法使用。

对于需求和设计的测试技术要求很高，实践起来很困难。

从N0中某节点开始到Nf中某节点结束的一条路径称为一条测试路径。

1.软件缺陷：（符合下列规则的叫软件缺陷)：

１）．软件未达到产品说明书的功能

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

３）．软件功能超出产品说明书指明范围

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

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

2.单元测试：单元测试是对软件设计的最小单元——模块进行正确性检验的测试工作，主要测试模块在语法、格式和逻辑上的错误。3.回归测试

指软件系统被修改或扩充（如系统功能增强或升级）后重新进行的测试，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。

4.等价类：指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。

第四篇：软件测试总结

面向对象程序的软件测试方法

在软件生命周期过程中，软件测试是保证软件质量的关键环节之一。面向对象方法学在软件工程中的引入极大地方便了软件的设计、开发和维护，为创建高可靠性的软件系统提供了重要保证。但面向对象程序的封装、继承、多态和异常处理机制等新特性却给测试带来新的挑战。一方面需要调整、改进传统的测试策略和方法；另一方面探索出适应面向对象程序特征的测试理论与技术也尤为必要。

面向对象(Object Oriented,OO)是当前计算机界关心的重点，它是90年代软件开发方法的主流。面向对象的概念和应用已超越了程序设计和软件开发，扩展到很宽的范围。如数据库系统、交互式界面、应用结构、应用平台、分布式系统、网络管理结构、CAD技术、人工智能等领域。

面向对象的定义或说明对象的定义的非常少。其初，“面向对象”是专指在程序设计中采用封装、继承、抽象等设计方法。可是，这个定义显然不能再适合现在情况。面向对象的思想已经涉及到软件开发的各个方面。如，面向对象的分析（OOA，Object Oriented Analysis），面向对象的设计（OOD，Object Oriented Design）、以及我们经常说的面向对象的编程实现（OOP，Object Oriented Programming）。许多有关面向对象的文章都只是讲述在面向对象的开发中所需要注意的问题或所采用的比较好的设计方法。看这些文章只有真正懂得什么是对象，什么是面向对象，才能最大程度地对自己有所裨益。这一点，恐怕对初学者甚至是从事相关工作多年的人员也会对它们的概念模糊不清。

1、面向对象的基本概念

(1)对象。

对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。

(2)对象的状态和行为。

对象具有状态，一个对象用数据值来描述它的状态。

对象还有操作，用于改变对象的状态，对象及其操作就是对象的行为。

对象实现了数据和操作的结合，使数据和操作封装于对象的统一体中

(3)类。具有相同或相似性质的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。

类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。

类具有操作，它是对象的行为的抽象，用操作名和实现该操作的方法来描述。

(4)类的结构。

在客观世界中有若干类，这些类之间有一定的结构关系。通常有两种主要的结构关系，即一般--具体结构关系，整体--部分结构关系。

①一般——具体结构称为分类结构，也可以说是“或”关系，或者是“is a”关系。

②整体——部分结构称为组装结构，它们之间的关系是一种“与”关系，或者是“has a”关系。

(5)消息和方法。

对象之间进行通信的结构叫做消息。在对象的操作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种操作的信息。发送一条消息至少要包括说明接受消息的对象名、发送给该对象的消息名（即对象名、方法名）。一般还要对参数加以说明，参数可以是认识该消息的对象所知道的变量名，或者是所有对象都知道的全局变量名。

类中操作的实现过程叫做方法，一个方法有方法名、参数、方法体。消

2、面向对象的特征

(1)对象唯一性。

每个对象都有自身唯一的标识，通过这种标识，可找到相应的对象。在对象的整个生命期中，它的标识都不改变，不同的对象不能有相同的标识。

(2)分类性。

分类性是指将具有一致的数据结构(属性)和行为(操作)的对象抽象成类。一个类就是这样一种抽象，它反映了与应用有关的重要性质，而忽略其他一些无关内容。任何类的划分都是主观的，但必须与具体的应用有关。

(3)继承性。

继承性是子类自动共享父类数据结构和方法的机制，这是类之间的一种关系。在定义和实现一个类的时候，可以在一个已经存在的类的基础之上来进行，把这个已经存在的类所定义的内容作为自己的内容，并加入若干新的内容。继承性是面向对象程序设计语言不同于其它语言的最重要的特点，是其他语言所没有的。

在类层次中，子类只继承一个父类的数据结构和方法，则称为单重继承。

在类层次中，子类继承了多个父类的数据结构和方法，则称为多重继承。

在软件开发中，类的继承性使所建立的软件具有开放性、可扩充性，这是信息组织与分类的行之有效的方法，它简化了对象、类的创建工作量，增加了代码的可重性。

采用继承性，提供了类的规范的等级结构。通过类的继承关系，使公共的特性能够共享，提高了软件的重用性。

(4)多态性(多形性)多态性使指相同的操作或函数、过程可作用于多种类型的对象上并获得不同的结果。不同的对象，收到同一消息可以产生不同的结果，这种现象称为多态性。

多态性允许每个对象以适合自身的方式去响应共同的消息。

多态性增强了软件的灵活性和重用性。

面向对象方法的基本思想是一：面向对象方法是一种运用对象、类、封装、继承、多态和消息等概念来构造、测试、重构软件的方法。

二： 面向对象方法是以认识论为基础，用对象来理解和分析问题空间，并设计和开发出由对象构成的软件系统（解空间）的方法。由于问题空间和解空间都是由对象组成的，这样可以消除由于问题空间和求解空间结构上的不一致带来的问题。简言之，面向对象就是面向事情本身，面向对象的分析过程就是认识客观世界的过程。

面向对象方法从对象出发，发展出对象，类，消息，继承等概念。

面向对象方法的主要优点是：符合人们通常的思维方式；从分析到设计再到编码采用一致的模型表示具有高度连续性；软件重用性好。

面向对象软件测试的特点是: 1.掌握代码检查、走查与评审的基本方法和技术； 2.掌握白盒测试和黑盒测试的测试用例的设计原则和方法； 3.掌握单元测试和集成测试的基本策略和方法；

4.了解系统测试、性能测试和可靠性测试的基本概念和方法； 5.了解面向对象软件和WEB应用软件测试的基本概念和方法； 6.掌握软件测试过程管理的基本知识和管理方法； 7.熟悉软件测试的标准和文档；

8.掌握QESuite软件测试过程管理平台和QESat/C++软件分析和工具的使用方法。

第五篇：软件测试方法和技术—课程总结作业

软件测试方法和技术 课程总结作业 2012-2013学年

软件测试方法和技术 课程总结作业 2012-2013学年第一学期 任务2：（20分）设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定

在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的“日期检查功能”。任务3：（50分）用你已经设计好的系统或借用其他系统，来进行软件系统测试，编写出系统测试报告。

3、补充说明

课程总结作业必须自己独立、认真完成，不得抄袭，如发现抄袭别人，则视本门课程为不及格处理。希望大家切记。