软件测试知识总结.docx

上传人:b****8 文档编号:30662707 上传时间:2023-08-19 格式:DOCX 页数:22 大小:635.56KB
下载 相关 举报
软件测试知识总结.docx_第1页
第1页 / 共22页
软件测试知识总结.docx_第2页
第2页 / 共22页
软件测试知识总结.docx_第3页
第3页 / 共22页
软件测试知识总结.docx_第4页
第4页 / 共22页
软件测试知识总结.docx_第5页
第5页 / 共22页
点击查看更多>>
下载资源
资源描述

软件测试知识总结.docx

《软件测试知识总结.docx》由会员分享,可在线阅读,更多相关《软件测试知识总结.docx(22页珍藏版)》请在冰豆网上搜索。

软件测试知识总结.docx

软件测试知识总结

第1章软件工程要点

1、软件:

文档+程序+数据

(1)当运行时,能够提供所要求功能和性能的指令或计算机程序集合。

(2)该程序能够具有满意的处理信息的数据结构

(3)描述程序功能需求以及程序如何操作和使用所要求的文档。

2、软件危机:

指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

软件危机影响:

(1)用户满意度

(2)成本与进度(3)质量(4)可维护性(5)文档支持(6)与时俱进

3、软件工程:

是一门研究如何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和维护的学科。

4、C/S结构与B/S结构

4.1、C/S结构主要有两层C/S结构和三层C/S结构

(1)两层结构的C/S前端是客户机(通常是PC);后端是服务器,运行数据库管理系统,提供数据库的查询和管理。

(2)三层结构的C/S模式是利用中间件将应用分为表示层、业务逻辑层和数据存储层三个不同的处理层次,即客户机、服务器和中间件。

4.2、B/S(Browser/Server,浏览器/服务器)模式又称B/S结构

第2章软件测试基础

1、软件测试定义:

定义1:

1983(Bill)、评价程序和系统的功能,并确定是否达到预期效果。

定义2:

1979(myers),测试是为发现错误而执行程序或系统的过程。

现代软件测试:

在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复查,是软件质量保证的关键步骤。

软件测试培训机构定义:

使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于验证它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

2、软件测试目的(立场不同)

开发者:

确认软件已正确地实现了用户的要求,证明软件中不存在错误,建立对软件质量的信心

用户:

发现软件中隐藏的错误和缺陷,以考虑是否可接受该产品

3、软件测试原则

(1)测试显示缺陷的存在#1

测试可以显示缺陷的存在,但不能证明系统不存在缺陷。

测试可以减少软件中存在未被发现缺陷的可能性,但即使测试没有发现任何缺陷,也不能证明软件或系统是完全正确的。

(2)穷尽测试是不可能的#2

除了小型项目,进行完全(各种输入和前提条件的组合)的测试是不可能的。

通过运用风险分析和不同系统功能的测试优先级,来确定测试的关注点,从而替代穷尽测试。

(3)测试尽早介入#3

在软件或系统开发生命周期中,测试活动应该尽可能早的介入,并且应该将关注点放在已经定义的测试目标上。

(4)缺陷集群性#4(80-20原则)

版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。

(5)杀虫剂悖论#5

采用同样的测试用例多次重复进行测试,最后将不再能够发现新的缺陷。

为了克服这种“杀虫剂悖论”,测试用例需要进行定期评审和修改,同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分,从而发现潜在的更多的缺陷。

(6)测试活动依赖于测试背景#6

针对不同的测试背景,进行的测试活动也是不同的。

比如,对安全关键的软件进行测试,与对一般的电子商务软件的测试是不一样的。

(7)不存在缺陷(就是有用系统)的谬论#7

假如系统无法使用,或者系统不能完成客户的需求和期望,发现和修改缺陷是没有任何意义的。

4、开发人员的测试:

是调试(Debug)还是测试(Test)?

调试是“建设性”的?

测试是“破坏”性的?

测试(Testing):

诱发错误

重现错误

定位错误(功能·需求·模块)

记录错误

调试(Debugging):

在源程序内定为错误

分析错误的原因

修改错误

在程序运行时检验程序功能

 

5、软件测试工作流程

●计划(

(1)识别测试任务

(2)定义测试目标(3)定义为达到测试目标和任务所必须的测试活动)

●分析

(1)评审测试依据(比如需求、系统架构、设计和接口说明等)

(2)评估测试依据和测试对象的可测性

(3)通过对测试项、规格说明、测试对象行为和结构的分析,识别测试条件并确定其优先级

●设计

(1)设计测试用例并确定优先级

(2)确定测试条件和测试用例所需的必要的测试数据

(4)规划测试环境的搭建和确定测试需要的基础设施和工具实现

●实现

(1)测试用例的开发、实现并确定它们的优先级

(2)开发测试规程并确定优先级,创建测试数据,同时也可以准备测试用具和设计自动化测试脚本

(3)根据测试规程创建测试套件,以提高测试执行的效率

(4)确认已经正确搭建了测试环境

●执行

(5)根据计划的执行顺序,通过手工或使用测试执行工具来执行测试规程

(2)记录测试执行的结果,以及被测软件、测试工具和测试件的标识和版本

(3)将实际结果和预期结果进行比较

(6)对实际结果和预期结果之间的差异,作为事件上报

(7)缺陷修正后,重新进行测试活动

●评估出口准则

(8)按照测试计划中定义的测试出口准则检查测试日志

(9)评估是否需要进行更多的测试,或是否需要更改测试的出口准则

●报告:

依据评估结果,向利益相关者(stakeholders)汇报测试情况

6、软件测试与软件开发各阶段的关系

7、软件测试工具对测试工作的支持

7.1软件测试工具的好处:

(1)提高工作效率,减少重复性工作量,保证测试的准确性

(2)有些测试必须使用工具(如性能测试等)

(3)更好地保证测试工作的规范性和一致性

(4)测试工具体现了先进的测试思想、方法和技术,能够快速地提升软件测试的专业化水平

(5)系统化地记录测试日志和度量目标

8、软件测试人员应具备的素质

综合能力:

(1)较强的沟通能力、团队合作精神

(2)测试中要做到“五心”:

专心、细心、耐心、责任心和自信心

(3)具有怀疑精神和洞察力

(4)具有探索、创新和挑战精神,努力追求完美

(5)积极、主动的学习能力

9、软件测试心理学

9.1开发人员的思维

1、开发人员的思维是构造思维(开发人员在设法通过程序实现用户需求时,更多的是思考如何来实现功能而并非破坏该功能。

2、同时具备构造思维和破坏思维是一件不容易的事情

3、思维的局限性

9.2测试人员的思维

1、技术思维能力(对技术的建模能力和理解原因与后果的能力。

2、创造思维能力(提出新想法和预见可能性的能力。

3、批判思维能力(评价想法并进行推理的能力。

4、实践思维能力(将想法变成现实的能力)

测试人员的思维是一种破坏性的思维(逆向思维)

9.3开发人员与测试人员之间的关系

(1)以合作而非斗争的方式开展项目,共同目标是追求高质量的产品

(2)以中性的语调和事实为依据的方式来沟通,而不要指责和批评他人

(3)尽量理解其他成员的感受,以及他们为什么会有这种反应

(4)确信其他成员已经理解你的描述

第三章基于生命周期的软件测试

1生命周期各个阶段的测试内容

1.1需求阶段测试

1.11需求阶段测试的目标:

保证需求分析的正确性和充分性

1.12测试活动

(10)彻底分析需求的充分性,生成基础测试用例

(11)澄清和确定哪些需求是可测试的,舍去含糊的、不可测试的需求,建立产品需求和确认需求

1.2设计阶段测试

1.21设计阶段测试任务

(1)分析测试要素

(2)给测试要素打分(3)对设计进行评审

(12)检查修改的部分

1.22设计阶段的测试活动

(1)在概要设计阶段,测试人员应阐述测试方法和测试评估准则,编写测试计划,成立测试小组,安排具有里程碑的测试日程

(2)在详细设计阶段,测试人员要开发或获取确认支持工具,生成功能测试数据和测试用例

1.3编码阶段测试

(1)在编程阶段完成测试用例开发,对程序进行实际的测试:

(2)系统是否可维护

(3)解决的首要问题是编码是否和设计一致

(4)系统的规格说明是否正确地实现

(5)编码是否按照既有的标准进行

(6)是否有充分的测试计划评价可执行的程序

(7)程序是否提供了足够的文档资料

(8)程序内部是否有足够的注释等

测试阶段

安装阶段测试

验收阶段测试

维护阶段

2、V模型与W模型

V模型特点

定义:

基本的开发过程和测试行为

标明:

测试过程中存在不同类型、不同级别的测试

描述:

不同测试阶段和开发过程期间各阶段的对应关系

W模型特点

(1)增加了软件各开发阶段中应同步进行的验证(verification)和确认(validation)活动。

(2)基于“尽早地和不断地进行软件测试”的原则

V模型和W模型的局限性

(1)串行活动,无法更好适应变更:

把软件的开发视为需求、设计、编码等一系列的串行活动,无法解决需求变更等变更调整。

(2)线性的前后关系,无法有效支持迭代:

开发和测试保持线性的前后关系,上一阶段完成才能开始下一阶段,无法有效,快速支持产品迭代。

(3)测试完整性不足:

顺序模型中没有很好体现测试流程的完整性

 

第4章软件测试分类与分级

1、软件测试分类

2、软件配置项的概念

软件配置缩写为CSCI(ComputerSoftwareConfigurationItem),是为独立的配置管理而设计的且能满足最终用户要求的一组软件,简称软件配置项

2.1、基于软件配置项的分类

功能测试、性能测试、外部接口和人机交互界面测试、强度测试、余量测试、可靠性测试、安全性测试、恢复性测试、边界测试、功能多余物测试、安装性测试、本地化测试、应用基准测试测试

3、软件测试分级(详细请看第八章动态测试)

组件/单元测试、集成测试、系统测试、验收测试

4、软件生命周期的测试分级(续)

4.1验收测试:

验收测试通常由使用系统的用户来进行测试

主要测试类型:

(1)根据合同的验收测试

(2)用户验收测试(3)运行(验收)测试(4)现场测试

4.2维护测试:

指软件被市场接受后,在运行一段时间后,需要做某些修正、改变或扩展的情况下进行的维护测试

5、软件测试中的错误分级

对软件错误进行级别定义或分级,目的就是科学地指导软件测试工作,提高软件测试的目的性,确保软件测试的质量

第5章软件缺陷管理

1、软件缺陷的定义

1.1一般符合下列5个规则之一,就是软件缺陷

(1)软件未实现产品说明书要求的功能

(2)软件出现了产品说明书指明不应该出现的错误

(3)软件实现了产品说明书未提到的功能

(4)软件未实现产品说明书虽未明确提及但应该实现的目标

(5)软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好

1.2软件缺陷分类

检测缺陷和残留缺陷(错误:

软件错误、软件失效、软件故障)

1.3软件缺陷产生的原因

调查研究表明:

大多数软件缺陷并不是由于编码造成的,导致大多数软件缺陷产生的最大的原因是需求分析阶段,其次是在软件设

计。

2.软件缺陷描述

2.1可追踪信息——缺陷ID

2.1缺陷基本信息

3、缺陷管理基本流程

或:

Reject评审委员会评审通过

4、软件缺陷报告

在软件测试过程中,每发现一个软件错误都要记录该错误的特征和复现步骤等信息,以便分析、处理和管理测试发现的软件错误

报告缺陷的基本原则

尽快报告缺陷、有效描述缺陷、报告缺陷时不做任何评价、确保缺陷可以重现

5、软件缺陷度量、数据分析与统计

5.1软件缺陷度量的方法

缺陷密度、缺陷率、整体缺陷清除率、阶段性缺陷清除率、缺陷趋势、预期缺陷发现率

5.2软件缺陷分析的步骤

(1)记录缺陷

(2)把测试出来的缺陷进行缺陷分类,找出那些关键的缺陷类型,进一步分析其产生的根源,针对性的制定改良措施

(3)进行缺陷预防分析

(4)编写缺陷分析报告,绘制缺陷分析图

5.3软件缺陷统计

统计方式:

表格、图(因果图、散点图、趋势图、直方图、条形图、排列图)

第6章软件测试过程及测试过程管理

1、软件测试流程

2、软件测试过程中的各阶段内容、职责、交付物

3、软件测试过程度量

第7章软件静态测试

1、软件静态测试技术的基本概念

1.1静态测试是指不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程

1.2对象:

各种与软件相关的有必要进行测试的产物,比如各类文档、源代码等

1.3静态测试的特点:

(1)不必动态地运行程序。

(2)可以人工进行,充分发挥人的思维优势。

(3)不需要特别的条件,容易展开。

(4)对测试人员要求比较高。

1.4静态测试主要包括各阶段的评审、代码检查、程序分析、软件质量度量等

2、评审的类型:

培训评审、预备评审和同行评审

2.1同行评审的类型和区别

3、代码检查(代码审查、桌面检查、代码走查和技术评审)

主要检查代码和设计的一致性、代码对标准的遵循、代码的可读性、代码的逻辑表达正确性,代码的合理性

3.1代码审查:

不少于4人,分别为组长、资深程序员、程序编写者、专职测试人员。

组长不能是被测程序的编写者。

3.11步骤:

准备、程序阅读、审查会、编写报告

3.2桌面检查:

程序员自己检查所编写的程序,即对源程序代码进行分析、检验,根据相关的文档,检验程序中是否有错误的过程。

3.3代码走查:

讨论过程是非正式的。

3.4技术评审:

最正式的审查类型,具有高度的组织化,要求每一个参与者都接受训练。

由开发者、测试组和相关人员联合进行,综合运用走查、审查技术,逐行、逐段的检查软件。

4、软件复杂性度量方法及度量元

4.1度量方法:

面向对象/过程的软件复杂性度量

对象:

c&k方法、MOOD方法

过程:

LineCount语句行度量、基于FPA功能点分析的度量、Halstead软件科学度量法、McCabe结构复杂性度量。

4.2软件复杂性度量的度量元

(1)规模,即总共的指令数或源程序行数。

(2)难度,通常有程序中出现的操作数的数目所决定的量来表示。

(3)结构,通常用与程序结构有关的度量来表示

(4)智能度,算法的难易程度

第八章动态测试

1、白盒测试的定义

1.1“白盒”测试又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。

1.将软件看做是透明的盒子

2.查看代码功能+实现方式

3.确定测试内容和测试方法

1.2白盒测试的特点

(1)可以构成测试数据使特定程序部分得到测试

(2)有一定的充分性度量手段(3)可获得较多工具支持(4)通常只用于单元测试

1.3白盒测试技术

动态白盒测试技术

1.逻辑覆盖测试

2.路径测试

3.数据流测试

4.信息流分析

5.覆盖率分析

......

静态白盒测试技术

1.代码检查

2.编码标准和规范

......

 

1.4逻辑覆盖的种类

语句覆盖(语句全部覆盖)

判定覆盖(针对判断条件的分支,使分支真假都执行一次)

条件覆盖(条件全覆盖)

判定/条件覆盖(条件真假/判定真假执行一次)

条件组合覆盖(条件取值组合执行一次)

路径覆盖(所有路径)

2、黑盒测试

2.1黑盒测试又称功能测试或数据驱动测试,即把测试对象当作看不见内部的黑盒,在完全不考虑程序内部结构和处理过程的情况下,测试者仅依据程序功能的需求规范考虑,确定测试用例和推断测试结果的正确性.

1.站在使用软件或程序的角度,从输入数据与输出数据的对应关系进行的测试

2.在软件的接口处进行测试

3.通过导出执行程序所有功能需求的输入条件集,实现功能覆盖,需求覆盖

2.2黑盒测试分类:

2.21等价类划分

考虑因素(输入数据、输出数据)

有效等价类:

对于程序规格说明来说,是合理的,有意义的输入数据构成的集合

无效等价类:

对于程序规格说明来说,是不合理的,无意义的输入数据构成的集合

设计测试用例时,要同时考虑有效等价类和无效等价类设计

划分等价类的经验原则

(1.输入条件的取值范围,可以划分出一个有效等价类和两个无效等价类

2.如果输入条件规定了输入值的集合,或者是规定了“必须如何”的条件,这时可确立一个有效等价类和一个无效等价类

3.如果输入条件是一个布尔量,则可以确定一个有效等价类和一个无效等价类。

4.如果规定了输入数据的一组值(假设N个),而且程序要对每个输入值分别进行处理。

5.如果规定了输入数据必须遵守的规则,则可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)

6.在确知已划分的等价类中,各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步地划分为更小的等价类

2.22边界值分析法

边界值分析是等价类划分方法的补充,所有测试阶段都可使用

原则:

1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界值,以及刚刚超越这个范围的边界值作为测试的输入数据。

例如:

输入值的范围是“1~9”,则可以选取“1”、“9”、“0.9”、“9.1”作为测试输入数据。

2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为册数数据。

例如:

一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。

3)根据规格说明的每个输出条件,使用原则1)

4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

5)分析规格说明,找出其他可能的边界条件。

2.23因果图

定义:

是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系。

适用范围:

适合检查程序输入条件的各种组合情况

产生背景:

等价类法、边界值法分析着重考虑输入条件,未考虑输入条件之间的关系

用因果图生成测试用例的基本步骤

(1)分析软件规格说明描述:

原因、结果、标识符

(2)分析软件规格说明描述中的语义:

找出逻辑关系

(3)由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现,添加必要的约束条件

(4)把因果图转换成判定表

(5)把判定表的每一列拿出来作为依据,设计测试用例

随机测试:

随机测试指测试输入数据是所有可能输入值中随机选取的,是一种基本的黑盒测试方法。

猜错法:

基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性地设计测试用例的方法。

3、灰盒”测试

3.1灰盒”测试与白盒测试的区别

1、“白盒”测试在测试过程中测试者可以看到被测的源程序,通过分析程序的内部结构,根据其内部结构设计测试用例

2、理想的“白盒”测试应该使选取的测试用例覆盖所有的路径

这是不可能的

3、“白盒”测试它不关注测试程序的外部功能

4、灰盒测试无需关心模块内部的实现细节

3.2灰盒测试与黑盒测试的区别

1、“黑盒”测试是在测试者完全不考虑程序内部结构和内部特征的情况下,根据需求规格说明书设计测试用例和推断的测试结果的正确性

2、“黑盒”测试只考虑了程序的输入,以及在该情况下的输出,并没有考虑程序的内部结构。

3、灰盒测试需关心模块与模块之间的交互

3.3灰盒”测试思想

基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例,执行程序并采集程序路径执行信息和外部用户接口结果的测试技术

目的是验证软件满足外部指标以及软件的所有通道或路径都进行了检验

通过该程序的所有路径都进行了检验和验证后,就得到了全面验证

4、测试用例设计

4.1测试用例:

是为特定的目的而设计的一组测试输入、执行条件和预期的结果,体现测试方案、方法、技术和策略。

4.2特点:

正确性、完整性、准确、清晰和简洁、可维护性、适应性、可重用性。

4.3测试用例覆盖内容

(1)正确性测试

(2)容错性测试(3)完整(安全)性测试(40接口间测试(5)数据库测试(6)边界值分析法(7)压力测试(8)等价划分(9)错误推测(10)效率(11)可理解(操作)性(12)可移植性

(13)回归测试(14)比较测试

4.4测试用例编写要素

(1)测试环境

(2)测试输入数据(3)测试执行步骤(4)测试预期结果

5、单元测试

定义:

又称模块测试,是针对软件设计的最小单元—程序模块或功能模块,进行正确性检验的工作。

测试对象:

(1)独立的函数、方法和过程

(2)独立的类

单元测试可发现的主要问题

单元测试主要能发现组件内部的功能性和非功能性问题,这些问题包括:

功能性问题(逻辑错误、功能丢失)

非功能性问题(语法错误、缺少代码注释、代码不具有良好的结构性、空指针、数组下标越界)

6、集成测试,也叫组装测试或联合测试。

在单元测试的基础上,将所有模块按照设计要求集成为子系统或系统,进行集成测试

集成测试方法:

非渐增式集成(一次性组装方式)

渐增式集成(自顶向下集成测试方法、自底向上集成测试方法、混合渐增式集成测试)

软件测试的对象

01、需求分析、概要设计、详细设计

02、程序源代码

03、需求规格说明

软件测试计划的内容

01测试目的、背景

02测试任务、资源分配、人员角色、进度安排

03测试内容和评价标准

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 工作范文 > 制度规范

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1