软件测试技术工作总结(精选多篇)

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

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

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

-测试用例

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

-必须以需求为依据。

-软件测试分类

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

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

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

-是否执行被测试软件

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

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

-基于不同的测试阶段：

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

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

客户机-服务器程序等，需要编写测试仿真程序，采用白盒和黑盒(收藏好 范 文，请便下次访问：wWw.HAOwoRd.coM)相结合的方式，通常由 开发人员承担。

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

独立的测试

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

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

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

-软件测试的三个步骤：

-测试计划：测试人员首先对需求进行分析，最终定义一个测试集合，通过刻画和定义测试发现需求中的

问题，然后根据软件需求同测试主管制定并确认“测试计划”。

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

-执行测试：需要做的工作包括搭建测试环境、运行测试、记录测试结果、报告软件缺陷、跟踪软件缺陷、

分析测试结果，必要时进行回归测试。

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

+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：可以不测试

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

软件测试方法和技术 课程总结作业 2014-2014学年第一学期

软件测试方法和技术

课程总结作业

1、提交期限和方法

期限：第17周周2晚。

方法：由各班学习委员收集所有学生的纸质作业上交到授课老师处，其中电子档报告以e-mail提交给任课教师（可发邮箱：dfeng808@126.com ）。

2、实验任务

任务1：（30分）判断三角形类的核心代码如下：

/** 判断三角形的类 */

public class triangletestmethod {

/** 判断三角形的种类。参数a, b, c分别为三角形的三边，

* 返回的参数值为0，表示非三角形；

* 为1，表示普通三角形；

* 为2，表示等腰三角形；

* 为3，表示等边三角形。

*/

public static int comfirm(int a, int b, int c) {

if((a + b > c) && (b + c > a) && (a + c > b)) // 判断为三角形{if((a == b) && (b ==c)) // 判断为等边三角形

return 3;

if((a == b) || (b == c) || (a == c)) // 判断为等腰三角形

return 2;

else // 判断为普通三角形

return 1;

}

else { // 为非三角形

return 0;

}

}

}

要求：1、首先画出程序的流程图；

2、为以上所示的程序段设计一组测试用例，要求分别满足语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。

3、对上述程序用基本路径测试法设计测试用例；具体按下列步骤进行：

①

②

③

④

依据代码绘制流程图（参考书的流程图，必须类似） 确定程序环路复杂度； 确定线性独立路径的基本集合； 设计测试用例覆盖每条基本路径 第 1 页 共 2 页

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

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

3、补充说明

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

第 2 页 共 2 页

第四篇：软件测试转正工作总结

本人自2014年6月25日起进入梦龙移通公司从事手机软件测试工程师一职，在不知不觉中已经经过了2个月的试用期。在这段时间里，我感悟颇多，虽然这并不是我的第一份工作，但是在此期间，我对于工作一贯谦虚谨慎、认真负责的工作态度，从来没有改变过。

在本部门工作中，我一直严格要求自己，认真及时地完成领导布置的每一项任务，并虚心向同事学习，不断改正工作中的不足；配合各部门负责人落实及完成公司各项工作，

在过去的2个月中，通过不断的学习和自我提高，已经适应了本职的工作，但对于一个初入公司的新人，要全面融入企业的方方面面，可能在一些问题的考虑上还不够全面，但我相信，通过公司领导及同事的悉心指导，我一定会在今后的工作中更好的提高自己的水平、素质，更好的完成本职工作。

在今后的工作中，我要继续努力，克服自己的缺点，弥补不足，向白盒测试、内部代码测试方向了解，加强 软件测试、计算机语言方面的知识，不断自我学习，力争成为学习型、创新型、实干型兼备的新世纪人才。

第五篇：软件测试工程师年终工作总结

2014年终工作总结

一：2014年工作回顾及总结

回顾2014年这一年来的工作，我在公司领导及各位同事的支持和帮助下，严格要求自己，按照公司要求，比较好地完成了本职工作。通过近一年的学习和工作，工作模式上有了新的突破，工作方式有了较大的改变。现将这一年的工作情况总结如下：

1、总体来说，2014年我主要完成了“……银行系统”、“……渠道管理平台”、“……”、“……”、“……”“……”的日常测试以及质量控制工作；“……”已经稳定上线运行6个多月，“……”即将上线。

2、日常我主要负责项目测试工作、测试文档编辑、参与功能需求设计、协调开发进度、总结经验分享、完成所需知识积累、工具学习及研究、兼容性软件测试。就在银联项目工作来说，主要的工作内容有：a、测试项目案例、测试用例的设计与编写；b、对测试过程中遇到的问题进行沟通，并提供意见；c、设计业务功能流程，提供参考意见，绘制关键业务流程；d、进行主要功能的界面测试、功能测试；e、按照测试用例执行测试计划；f、进行需求验证工作

3、知识的总结与分享，完成客户端在安卓4.0/4.1，ios6.0以上系统上出现的兼容等问题，完成了兼容性测试案例的编写以及兼容性测试的培训工作。在日常工作中，发现兼容上重大问题，在测试部门群中发布分享。

4、完成所需知识积累，学习所需知识、工具以及技能。在工作中学习了银行业务流程规范、学习公司研发规范、参加了公司组织的技术培训、学习了各种

测试工具的使用。

二：对公司的建议与意见

对公司和部门建设上，我有以下几点建议：

1、对员工进行金融知识的系统培训，让测试人员了解银行业务流程，有助于测试人员更加详细了解业务流程，测试过程会少走很多弯路。

2、部门内希望多组织技术交流讨论，促进测试工作的开展和提高。一年至少有2次这样的交流。

3、公司在项目开发前期，希望尽可能的明确需求，尽可能的详尽需求说明书内容。在测试过程中发现很多项目缺少需求说明书，需求说明书不明确或者需求说明书内容错误，误导了开发和测试，浪费了时间，影响了项目进度。

4、建议项目需求设计可以有测试员参与讨论。

5、公司管理有点混乱，个人感觉公司对每位员工的重视程度不够！节假日公司应该给每位员工一定的福利和关心。

6、个人感觉平时的效率比较低，希望测试部门能够有所调整。希望公司能制定质量控制标准以及开发、测试工作流程，让开发更好的了解测试的流程，增强开发团队与测试团队的配合，提高工作效率。

7、加强部门测试成果的积累与沉淀，提高团队测试水准，希望我们的团队能够做的更好，能够已团队的形式参与软件项目的开发，而不仅仅是一个项目中毫不起眼的小小测试员。

三：2014年工作计划与学习计划

2014年工作计划就是希望通过自己的努力，让我们的产品更加完美，让自己在软件测试技能上有所提高，更多的关注软件产品的开发过程，提高工作效率、做到与用户的需求一致，提高公司软件产品用户满意度。

具体来说2014年工作计划有：努力提高自身测试水准，努力学习金融知识以及业务流程，学会需求分析，掌握需求分析在测试中的作用，参与公司更多的开发项目的测试工作。

********

201*年^月^日