软件测试技术总结

软件测试技术总结

软件测试确实是为了发觉程序中的错误而分析和执行程序的进程。——概念

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

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

一、瀑布模型

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

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

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

二、原型模型

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

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

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

3、增量模型

概述：在增量模型中每一个时期都生成软件的一个可发布版本，时期交织进行，版本慢慢完善。同原型模型的最大区别在于，在原型模型中每一个时期发布一个原型而在增量模型中那么完成一个正式版本。

4、螺旋模型

概述：适用于大型软件的开发，它将瀑布模型和快速原型模型结合起来，并加入了风险分析。特点：1.每一个时期都包括制定打算，风险分析，实施工程，评审四个时期；2.开发进程迭代进行，每迭代一次螺旋线增一周，工程前进一个层次，系统生成一个新版本， 投入新的时刻本钱，最终取得客户中意的版本。

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

二、测试用例

一、三要素：前提条件和操作步骤、预期结果、实际结果。 二、必需以需求为依据。

三、软件测试分类

一、是不是关注软件结构和算法

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

二、是不是执行被测试软件

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

3、基于不同的测试时期：

一、单元测试：要紧测试软件的单元模块，需要编写额外的测试驱动程序，采纳白盒测试的方式，一样由 开发人员完成。

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

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

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

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

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

一、测试打算：测试人员第一对需求进行分析，最终概念一个测试集合，通过刻画和概念测试发觉需求中的问题，然后依照软件需求同测试主管制定并确认“测试打算”。

二、测试设计和开发：软件测试人员依照软件需求和软件设计说明书完成测试用例的设计和必要

的测试驱动程序的开发。

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

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

一、5C

-Controlled /kEn'trEuld/ 同意治理，有层次的

-Competent /'kCmpitEnt/ 了解正确的测试技术

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

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

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

二、职业素养 -责任心-学习能力-疑心精神 -沟通能力 -专注力-洞察力 -团队精神-注重积存

六、制定测试打算的五个步骤：

一、分析和测试软件需求 二、概念测试策略 3、概念测试环境 4、概念测试治理

五、编写和审核测试打算

若是在需求分析时期发觉并结果问题需要花费$1，那么在设计时期解决一样的问题需花费$5，在编码时期需$10，交付后解决一样的问题需花费$200。——越早测试越好

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

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

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

八、需求测试

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

九、好的需求文档的特点

一、具有清楚的格式和文档结构 二、需求的内容正确 3、需求的内容完整

4、需求具有可行性需求的必要性 五、对不同的需求优先品级进行概念 六、描述明确

7、可证性和可测试性 八、可修改性-可追踪 九、需求文档被及时更新

十、需求测试内容

一、需求文档是不是符合公司的格式要求 二、是不是正确

3、要保证需求文档中所描述的内容是真实靠得住的

4、这是“真正的”需求吗？描述的产品是不是是要开发的产品？

五、需求是不是完备？第一个发布的版本是不是需要更多的功能？列出的需求能够减少一部份？

六、需求是不是兼容？需求有可能是矛盾的。

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

八、需求是不是合理？在开发进度、开发费用、产品性能、靠得住性和内存利用之间存在着平稳关系。

九、需求是不是可测？关于软件测试人员来讲判定需求是不是可测是那个进程中最重要的工作。

十一、需求测试方式

一、复查review 二、走查walkthrough 3、审查inspection

十二、测试策略的内容

一、确信测试范围 软件是无法被完全测试的 二、确信测试方式 不同的系统需要不同的测试方式

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