第一阶段知识总结及问题



问题总结：

测试用例需求覆盖考虑不全面，测试用设计方法使用不熟练。

思维能力薄弱，分析软件需求不全面。

1.知识总结

1.1
软件工程要点

1.1.1软件的概念及分类

软件最初的概念就是就是指程序，随着时代发展，软件就是指文档、程序和数据。

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

该程序能够具有满意地处理信息的数据结构。

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

软件种类：

系统软件：操作系统、数据库管理系统、设备驱动程序等。

应用软件：事物软件、娱乐软件、实时软件等。

工具软件：文本格式化软件、文本编辑软件等。

1.1.2软件危机

软件危机产生的原因：

（1）对用户的需求不明确是产生软件危机的主要原因之一；

（2）缺乏正确的理论指导；

（3）软件开发规模越来越大；

（4）软件开发复杂度越来越高；

如何消除软件危机：

（1）应该对计算机软件有一个正确的认识；

（2）必须充分认识到软件开发不是某个个体劳动的神秘技巧，而应该是一种组织良好、理严密、各类人员协同配合、共同完成的工程项目。

1.1.3软件工程

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

软件工程三要素：方法、工具、过程。

软件工程内容：软件开发技术、软件项目管理。

软件项目管理

软件项目管理包括软件度量、项目估算、进度控制、人员组织、项目计划等。

1.1.4软件生命周期

软件生命周期是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。

软件生命周期模型：

瀑布模型（开发者角度）

迭代式模型

V模型（测试人员的角度）

W模型（测试人员的角度）

敏捷模型

1.1.5软件开发主流技术

1.2软件测试基础

1.2.1软件测试基本概念

1.定义：

Hetzal：评级一个系统或程序的特性或能力，并确认他是否达到预期的结果，检查是否满足规定的需求。

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

现代：是对软件需求分析、设计、编码的最终复查的一系列过程，是软件质量保证的关键。

2.
软件测试目的

a）尽可能发现并改正被测试软件的错误，提高软件的可靠性

b）保证软件质量

c）建立软件质量信心

3.软件测试基本原则

（1）测试显示缺陷的存在；

（2）穷尽测试是不可能的；

（3）测试尽早介入；

（4）缺陷集群性（80-20原则）；

（5）杀虫剂悖论；

（6）测试活动依赖于测试背景；

（7）不存在缺陷的谬论。

4.软件测试质量度量

1.2.3软件测试工作流程

软件工作流程图，如图2。

图 2
软件测试工作流程图

1.2.4
测试工作内容

1.计划：识别测试任务、定义测试目标、定义为达到测试目标和任务所必须的测试活动

2.分析与设计：

评审测试依据（比如需求、系统架构、设计和接口说明等）、评估测试依据和测试对象的可测性、通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定其优先级；设计测试用例并确定优先级、确定测试条件和测试用例所需的必要的测试数据、规划测试环境的搭建和确定测试需要的基础设施和工具。

实现与执行：测试用例的开发、实现并确定它们的优先级、开发测试规程并确定优先级，创建测试数据，同时也可以准备测试用具和设计自动化测试脚本、根据测试规程创建测试套件，提高测试执行的效率、确认已经正确搭建了测试环境、根据计划的执行顺序，通过手工或使用测试执行工具来执行测试规程、记录测试执行的结果，以及被测软件、测试工具和测试件的标识和版本。、将实际结果和预期结果进行比较、对实际结果和预期结果之间的差异，作为事件上报、缺陷修正后，重新进行测试活动。

评估出口准则：按照测试计划中定义的测试出口准则检查测试日志

评估是否需要进行更多的测试，或是否需要更改测试的出口准则。

1.2.5软件测试心理学

1.开发人员的思维，如图3。

开发人员的思维是构造思维。

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

同时具备构造思维和破坏思维是一件不容易的事情思维的局限性。

2.测试人员的思维

技术思维能力、对技术的建模能力和理解原因与后果的能力、创造思维能力、提出新想法和预见可能性的能力、批判思维能力、评价想法并进行推理的能力、实践思维能力、将想法变成现实的能，测试人员的思维是一种破坏性的思维(逆向思维)。

3.开发人员与测试人员的关系

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

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

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

确信其他成员已经理解你的描述。

3.软件测试的心理学

⑴
端正对软件测试工作的认识。

⑵
具有较强的沟通能力、外交能力和移情能力。

⑶
掌握比较全面的技术。

⑷
测试中要做到“5心：专心、细心、耐心、责任心、自信心”。

⑸
要有很强的记忆力、怀疑精神和洞察力。

⑹
具有探索、创新和挑战精神，努力追求完美。

⑺
测试人员在测试时要注意的事项：①永远不要许诺或保证什么；②
文档反应了自己的精神面貌；③要学会逆向思维；④
编写缺陷时一定要保证重现；⑤测试要依据需求，关注对用户不利的缺陷；⑥
尽量使用测试工具；⑦牢记服务意识。

1.26测试工具

商业化的测试工具：

测试管理工具：HP ALM/QC

自动化测试工具：HP UFT(QTP & Service Test)

性能测试工具：HP Loadrunner

安全测试工具：HP Fortify、WebInspet

开源测试工具：

Testlink、Mantis、BugZilla、Selenium、JUnit、CppUnit

1.3基于生命周期的软件测试

1.3.1生命名周期的概念

生命周期测试的概念：生命周期测试应伴随整个软件开发周期，此时测试的对象不仅仅是程序，需求、功能和设计同样要设计。生命周期意味着测试与软件开发平行，在软件开发的所有阶段进行测试，确保在尽可能早的阶段点去修正缺陷，用来减少测试成本。

1.3.2生命周期模型

1.
V模型，如图3.

图3 V模型

特点：①
定义：基本的开发过程和测试行为②标明：测试过程中存在不同类型、不同级别的测试③
描述：不同测试阶段和开发过程期间各阶段的对应关系。

2.W模型，如图4.

图4 W模型

特点：①
增加了软件各开发阶段中应同步进行的验证
（verification）和
确认（validation）
活动。②
基于“尽早地和不断地进行软件测试”的原则。

1.3.2生命周期测试的主要任务

生命周期测试的主要任务：

测试要素：软件的属性，描述测试的主要目标；

测试用例；

测试种类/技术；

测试的准入准出条件。

1.4软件测试分类与分级

1.4.1软件测试分类

1.1
软件配置项

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

软件配置管理控制这些软件配置项的投放和变更，并且记录并报告配置的状态和变更要求，验证配置的完整性、正确性和一致性。

1.2基于CSCI的软件测试分类

①功能测试：功能测试主要对软件需求规格说明中的功能需求进行测试,找出被测软件的实现与需求不一致的地方,确认一致的地方。

②性能测试：主要对软件需求规格说明中定义的性能需求进行测试，费事在一定工作负荷和配置条件下，系统的响应时间及处理速度等特性。

③外部接口和人机交互界面测试：外部接口和人机交互界面测试主要对平台各个服务域提供的应用编程接口、应用程序接口、外部环境接口以及人机交互界面的符合性和可用性进行测试。

④强度测试：强度测试必须在预先规定的一个时期内，在软件设计能力的极限状态，进而超出此极限状态下，运行软件的所有功能。

⑤余量测试：测试程序全部存储量、输入/输出通道及处理时间的余量满足需求规格说明的要求。

⑥可靠性测试：可靠性测试是在有使用代表性的环境中，为进行软件可靠性估计而对其进行的功能测试。

⑦安全性测试：安全性测试主要对平台软件配置项的安全性进行测试，包括系统安全评估和系统侵入测试两个部分。

⑧恢复性测试：对有恢复或重置（RESET）功能的软件，必须验证恢复或重置功能，对每一类导致恢复或重置的情况进行测试。

⑨边界测试：测试程序在输入域（或输出域）、数据结构、状态转换、过程参数、功能界限等的边界或端点情况下运行状态。

⑩功能多余物测试：验证程序中没有附加的软件需求中没有指明的功能及功能边界的不适当。所有输出都应有意义并在软件需求中指明。

⑪安装性测试：安装性测试主要对平台软件配置项的可安装性/可卸载性进行测试。

⑫本地化测试：本地化测试的内容，主要对平台软件配置项的本地语言、时间等本地特色的支持能力进行测试，验证软件配置项是否能全面、正确地支持、处理本地特色化要素。

⑬应用基准测试测试：应用基准测试主要对平台软件配置项的综合性能进行测试。

1.3软件测试分类，如图5。

图5
软件测试分类

1.4.2软件测试分级

对软件测试的要求、目的、关注点、被测对象、工作产品及测试人员不同，相应的软件测试级别划分或分级是不同的。

四种软件测试级别，如图6.



图6
软件测试级别

1.
单元测试（组件测试）：

针对单个软件单元的测试都可以称为单元测试

在单元测试过程中，经常会用到桩、驱动器、模拟器

单元测试包括功能测试和特定的非功能测试

在写代码之前就开始准备测试和自动化测试用例是单元测试常用的一种方法

单元测试的任务包括：模块局部数据结构测试，模块参数边界值测试，模块中所有独立执行路径测试，以及模块的各条错误处理路径测试等

测试环境：当程序代码编写完成并通过评审和编译检查后，便可开始单元测试

2.
集成测试的

集成测试也叫组装测试、联合测试，目的是检验软件单元/系统之间的接口关系，是单元测试的逻辑扩展，其关注点是对单元之间的接口进行测试，以及检查与系统其它部分相互作用的测试，是旨在暴露接口以及集成组件/系统间交互时存在缺陷的测试，集成测试验证程序和概要设计说明的一致性，任何不符合该说明的程序模块行为都应该加以记载并上报。

3.系统测试

系统测试是将已经集成好的软件系统作为计算机系统的一部分，与计算机系统硬件、某些支持软件、数据和人员等系统元素结合起来，在实际运行环境下对计算机系统进行一系列严格有效的测试；系统测试对测试环境的要求是在集成测试完成后，系统已经完全组合起来后进行，应该在尽可能和目标运行环境一致的情况下进行；系统测试的目的是确认整个系统是否满足了系统需求规格说明中的功能和非功能需求，以及满足程度。

常见系统测试包括：压力测试、容量测试、性能测试、安全测试、容错测试等。

4.系统测试过程，如图7。

图7
系统测试过程

4.验收测试

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

1.4.3软件测试中的错误分级

对软件错误进行级别定义或分级，目的就是科学地指导软件测试工作，提高软件测试的目的性，确保软件测试的质量。软件错误分级涉及到两个方面：错误分类及错误级别划分

。

1.错误级别划分（按GB/T15532-2008划分）:

第1级错误：

妨碍由基线要求所规定的运行或任务的主要功能的完成

妨碍操作员完成运行或任务的主要功能

危及人员安全

第2级错误：

给由基线要求所规定的运行或任务的主要功能的完成造成不利的影响,以致降低效能,且

没变通的解决办法，给操作员完成由基线要求所规定的运行或任务的主要功能造成不利的影响,以致降低效能，且没有变通的解决办法。

第3级错误：

给由基线要求所规定的运行或任务的主要功能的完成造成不利的影响,以致降低效能,但已知有变通的解决办法

给操作员完成由基线要求所规定的运行或任务的主要功能造成不利的影响,以致降低效能，但已知有变通的解决办法

第4级错误

这种软件问题给操作员带来不方便或麻烦，但不影响所要求的运行或任务的主要功能

第5级错误：所有的其他错误

1.5软件缺陷

1.5.1
概念

软件错误或软件缺陷是软件产品的固有成分，是软件“生来具有”的特征，软件缺陷包括检测缺陷和残留缺陷。

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

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

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

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

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

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

1.5.2原因

导致软件产生缺陷的九类原因：需求的不完善定义、客户——开发者通信失败、对软件需求的故意偏离、逻辑设计错误、编码错误、不符合文档编制与编码规定、测试过程不足、规程错误、文档编制错误。

1.5.3软件缺陷基本属性

①
缺陷标识(Identifier)：缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识

②
缺陷类型 (Type)：缺陷类型是根据缺陷的自然属性划分的缺陷种类。

③
缺陷严重程(Severity)：缺陷严重程度是指因缺陷引起的失效对软件产品的影响程度。

④
缺陷优先级(Priority)：缺陷的优先级指缺陷必须被修复的紧急程度。

⑤
缺陷状态(Status)：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。

⑥
缺陷起源(Origin)：缺陷起源指缺陷引起的失效或事件第一次被检测到的阶段。

⑦
缺陷来源(Source)：缺陷来源指引起缺陷的起因。

⑧
缺陷根源(Root Cause)：缺陷根源指发生错误的根本因素。

1.5.4软件缺陷报告撰写

1）可追踪信息——缺陷ID

(唯一的缺陷ID，可以根据该ID追踪缺陷)

2）缺陷基本信息，如图8.

图8 缺陷基本信息

3）缺陷的详细描述

描述应尽可能详细

4）测试环境说明

对测试环境的描述

5）必要的附件

对于某些文字很难表达清楚的缺陷,使用图片等附件是必要的

6）从统计的角度出发

还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等项目

报告缺陷的基本原则：

①
尽快报告缺陷；②
有效描述缺陷；③
报告缺陷时不做任何评价；④
确保缺陷可以重现。

3.“5C”准则

①
Correct(准确)：每个组成部分的描述准确，不会引起误解。

② Concise(简洁)：只包含必不可少的信息，不包括任何多余的内容。

③ Clear(清晰)：每个组成部分的描述清晰，易于理解。

④ Complete(完整)：包含复现该缺陷的完整步骤和其他本质信息。

⑤ Consistent(一致)：按照一致的格式书写全部缺陷报告。

4.
衡量优秀的bug report的质量指标

①对管理层来说，是清晰明了的，特别是在概要这一级；②
对于开发部门是有用的，主要是给出能够让开发人员高效地调试问题的相关信息；③可以很快的将bug从“Opened”状态转变成“Closed”状态，减少为得到更多的信息从开发人员打回的差的bug
report并导致测试人员返工的时间。

1.5.5软件缺陷管理

1.缺陷管理流程，如图9、10.

图9 缺陷管理流程

图10 缺陷管理流程

2.缺陷管理流程中的各种角色，如图11.

图11
缺陷管理的角色

1.5.6软件缺陷度量

缺陷度量是对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有序而清晰。缺陷度量是软件质量度量的重要组成部分，它和软件测试密切相关。

软件缺陷度量方法较多，从简单的缺陷计数到严格的统计建模，软件缺陷度量的主要方法有：

缺陷密度（缺陷在规模上的分布）：缺陷密度=已知缺陷的数量/产品规模。

②缺陷率（缺陷在时间上的分布）：缺陷率=一定时间范围内的缺陷数/错误几率。

③缺陷清除率：整体缺陷清除率=开发过程中发现的所有缺陷数/发现的总缺陷数；阶段性缺陷清除率=开发阶段清除的缺陷数/产品潜伏的缺陷总数。

1.5.7软件缺陷分析

软件缺陷分析是将软件开发各个阶段产生的缺陷信息进行分类和汇总统计,计算分析指标，编写分析报告的活动。

软件缺陷分析步骤：记录缺陷、对缺陷进行分类、缺陷预防分析、编写缺陷分析报告，绘制缺陷分析图。

1.5.7软件缺陷统计

软件缺陷统计是软件分析报告中的重要内容之一，从统计的角度出发，可以对软件过程的缺陷进行度量：软件功能模块缺陷分布、缺陷严重程度分布、缺陷类型分布、缺陷率分布、缺陷密度分析、缺陷趋势分布、缺陷注入率/消除率等。

统计的方式：表格、散点图、趋势图、因果图、直方图、条形图、排列图等。

1.6软件测试过程

1.6.1
软件测试过程

1.软件测试流程图,如图12。

图12
软件测试流程图

2.软件测试过程中的活动及内容，如图13.

图13
软件测试过程中的活动及内容

3.各阶段按对应的任务：

①
测试项目启动

首先要确定项目组长，只要把项目组长确定下来，就可以组建整个测试小组，并可以和开发等部门开展工作。接着参加有关项目计划、分析和设计的会议，获得必要的需求分析、系统设计文档，以及相关产品/技术知识的培训和转移。

②
测试需求分析

测试需求通常以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试内容。因此，测试需求的分析包括五个部分：明确需求的范围；明确每个功能的业务处理过程；不同的功能点与业务的组合；挖掘显示需求背后的隐士需求；测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。

③
制定测试计划

确定测试范围、测试策略和方法，以及对风险、日程表、资源等进行分析和评估。

④
测试设计和测试开发

制定测试的技术方案、设计测试用例、选择测试工具、写测试脚本等。测试用例设计要事先做好各项准备，才开始进行，最后还要让其他部门审查测试用例。

⑤
测试实施和执行

建立或设置相关的测试环境，准备测试数据，执行测试用例，对发现的软件缺陷进行报告、分析、跟踪等，测试执行没有很高的技术性，却是测试的基础，直接关系到测试的可靠性、客观性和准确性。

⑥
测试结果的审查和分析

当测试执行结果后，对测试结果要进行整体得或综合分析，以确定软件产品质量的当前状态，为产品的改进或发布提供数据和依据。从管理角度看，要做好测试结果的审查并召开分析会议，以及做好测试报告或质量报告写作、审查。

根据测试需求、测试计划，对测试过程中每个状态进行记录、跟踪和管理，并提供相关的分析和统计功能，生成和打印各种分析统计报表。通过对详细记录的分析，形成较完整的软件测试管理文档，避免同样的错误在软件开发过程中再次发生，从而提高软件开发质量。

4.
软件测试过程结束的准则

① 软件系统在进行系统测试过程中，发现一、二级缺陷数目达到项目质量管理目标要求，测试暂停返回开发。

② 软件项目在其开发生命周期内出现重大估算和进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。

③ 如有新的需求变更过大，测试活动应暂停，待原测试计划和测试用例修改后，再重新执行测试。

④ 若开发暂停，则相应测试也应暂停，并备份暂停点数据。

⑤ 所有功能和性能测试用例100％执行完成。

1.7
软件静态测试

1.7.1静态测试概念

概念：是指不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。

特点：不必动态地运行程序、可以人工进行，充分发挥人的思维优势、不需要特别的条件，容易展开、对测试人员要求比较高、静态测试对象：的有必要进行测试的产物，比如各类文档、源代码等。

静态测试的主要内容：

各阶段的评审：一般评审包括：培训评审、预备评审、同行评审，我们所关心的是同行评审。

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

软件复杂性分析：主要包括软件复杂性度量与控制，软件复杂性度量元，面向对象的软件复杂性度量

软件质量度量：是从整体上对软件质量进行评测，用于软件开发中对软件进行质量控制，并最终对软件产品进行评价和验收

1.7.2静态测试评审类型

评审是对软件元素或项目状态进行评估的活动，用以确定与预期结果之间的偏差和相应的改进意见，一般评审包括培训评审、预备评审、同行评审。主要讲解同行评审。

1.同行评审

是由开发软件产品作者以外的其他人检查工作产品，以发现缺陷并寻找改进的机会

评审方法是评审参与者通常采用一行一行仔细阅读被评审对象的形式发现被测对象中的缺陷。审的时间点一般设在工作产品到达了一个完成的里程碑并即将进入下一个开发阶段时。

2、同行评审的类型和区别，如图14.

图14
同行评审的类型和区别表

1.7.3代码检查概念

定义：是以组为单位阅读代码，是一系列规程和错误检查技术的集合。

代码评审开展时间：代码全部或部分完成后。

测试目的：及早发现缺陷。

具体方法：一般采用静态“白盒”测试的方法。

代码检查输出的信息：度量标准、易产生错误的代码、代码规则的执行、流图和调用图的分析。

1.7.4代码检查方法

主要有代码审查、桌面检查、代码走查和技术评审这几种方法。

1.
代码审查

代码审查内容：代码和设计的一致性、代码执行标准的情况、代码的逻辑表达正确性、代码结构的合理性、代码的可读性等。

代码审查组由组长、资深程序员、程序编写者与专职测试人员等组成，进行准备、程序阅读、审查会、编写报告四项步骤，组长不能是被测程序的编写者。

2.桌面检查

定义：程序员自己检查自己所编写的程序，根据相关的文档对源程序代码进行分析、检验，以发现程序中是否有错误的过程。

主要工作：桌面检查主要做的工作是检查代码和设计是否一致、代码是否遵循标准、是否可读、代码逻辑表达是否正确、代码结构是否合理、程序编写与编写标准是否符合、程序中是否有不安全、不明确和模糊的部分、编程风格是否符合要求。

3代码走查

代码走查的讨论过程是非正式的，代码走查比代码审查要更技术性些，在代码走查中编写代码的程序员要向5人小组或者其他程序员和测试人员组成的小组做正式陈述，在这个小组中至少有一位资深程序员，测试人员应是具有经验或精通程序设计的程序设计人员，还要有一位没有介入到这个项目中的新人，这样的人不会被已有的设计约束，以发现问题

代码走查主要有：

文档和源程序代码、检查功能、检查界面、检查流程、检查提示信息、函数检查、数据类型与变量检查、条件判断检查、循环检查、输入输出检查、注释检查、程序（模块）检查、数据库检查、表达式分析、接口分析、函数调用关系图及模块控制流图等17项检查内容。

4.技术评审

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

技术评审由开发组、测试组和相关人员（QA、产品经理等）联合进行综合运用走查、审查技术，逐行、逐段的检查软件。技术评审与走查和审查的不同之处在于表述代码的表述者

表述者不是原来编写代码的程序员，这就迫使表述者学习和了解要表述的材料，从而有可能对程序提出不同的看法和解释，检查要点是设计需求、代码标准/规范/风格和文档的完整性与一致。

1.7.6软件复杂性分析

对软件复杂性进行分析、度量和控制，目的就是：

1.7.7软件复杂性度量与控制

软件复杂性度量是对软件复杂性的定量描述，是软件复杂性分析和控制基础。件复杂性度量的结果是软件复杂度；
对象不同，描述软件复杂性的角度和方法不同。

软件复杂性度量主要根据软件结构来实现对软件复杂性的度量

软件复杂性控制包括模块复杂性控制、模块结构复杂性控制和软件总体复杂性控制。

1.7.8软件复杂性度量元

软件复杂性性度量方法和标准，如图15.

图15
软件复杂性性度量方法和标准

度量元是软件复杂度度量的内容，主要分为如下几类：

规模：即总共的指令数，或源程序行数。

难度，通常由程序中出现的操作数的数目所决定的量来表示。

结构，通常用与程序结构有关的度量来表示。

智能度，算法的难易程度

1.8动态测试

1.8.1“白盒”测试

1.1白盒概念

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

白盒测试的特点：

（1）可以构成测试数据使特定程序部分得到测试；

（2）有一定的充分性度量手段；

（3）可获得较多工具支持；

（4）通常只用于单元测试

1.2白盒测试技术：

1.3逻辑覆盖

逻辑覆盖是以程序内部的逻辑结构为基础的测试方法，属于“白盒”测试。逻辑覆盖种类：

语句覆盖

语句覆盖是最起码的测试要求，使得每一条语句至少被执行一次，对程序的逻辑覆盖很少，只关心判定表达式的值，是很弱的逻辑覆盖标准。

判定覆盖

要求设计足够的测试用例，使得程序中的每一个分支至少通过一次即每一条分支语句的“真”值和“假”值都至少执行一次。

条件覆盖

不仅每一个语句至少执行一次，使得判定中的每个条件获得各种可能的结果。判定覆盖只关心整个判定表达式的结果，条件覆盖关心的则是每个条件各种取值的结果。

判定/条件覆盖

设计足够多的测试用例，使得判定中每个条件的所有可能取值至少能够获取一次，同时每个判断的所有可能的判定结果至少执行一次。

条件组合覆盖：

要求设计足够多的测试用例，使得每个判定中条件的各种组合至少出现一次。

满足条件组合覆盖标准的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准

路径覆盖

要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次。

逻辑覆盖之间的关系，如图16.

图16逻辑覆盖之间的关系

1.8.2黑盒测

1.1黑盒测试概念

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

优点：“黑盒”测试不能替代“白盒”测试，而是用来发现“白盒”测试以外的其他类型的错误，比如：（1）功能不对或遗漏；（2）接口错误或界面错误；（3）数据结构或外部数据库访问错误；（4）性能错误；（5）初始化和中止错误。

1.2黑盒测试方法

1.等价类划分法

等价类，把所有可能的输入数据,即程序的输入域划分成若干部分。划分，从每一部分中选取少数有代表性的数据做为测试用例，代表性数据等同于该类中的其他值。

等价类划分分为两种不同情况：

有效等价类：对于程序规格说明来说，是合理的，有意义的输入数据构成的集合

无效等价类：对于程序规格说明来说，是不合理的，无意义的输入数据构成的集合

等价类划分的方法：、按区间划分、按数值划分、按数值集合划分、按限制条件或规划划分、按处理方式划分。

划分等价类的经验原则

步骤：划分等价类、建立测试用例、列出所有划分的等价类表格、设计从测试用例。

2.因果图法

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

3.边界值分析法

选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据的方法。

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

（1）分析软件规格说明描述：原因、结果、标识符；

（2）分析软件规格说明描述中的语义：找出逻辑关系；

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

（4）把因果图转换成判定表；

（5）把判定表的每一列拿出来作为依据，设计测试用例。

4.猜错法

5.随机数法

因果图标识,如图17.

图17
因果图标识

因果图约束条件，如图18.

图18
因果图约束条件

1.8.3灰盒测试

“灰盒”测试与白盒测试的区别：

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

（2）理想的“白盒”测试应该使选取的测试用例覆盖所有的路径，这是不可能的，“白盒”测试它不关注测试程序的外部功能；

（3）灰盒测试无需关心模块内部的实现细节。

“灰盒”测试与黑盒测试的区别：

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

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

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

“灰盒”测试是一种综合测试法，它将“黑盒”测试、“白盒”测试、回归测试结合在一起，构成一种无缝测试技术。

灰盒测试一种软件全生命周期测试法，该方法通常是深入到用Ada/C/Fortran或汇编语言开发的嵌入式应用软件代码中进行功能的测试，或者与Web服务一起使用。

“灰盒”测试的优点：

（1）能够进行基于需求的覆盖测试和基于程序路径覆盖的测试；

（2）测试结果可以对应到程序内部路径，便于bug的定位、分析和解决；

（3）能够保证设计的“黑盒”测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组合；

（4）能够需求或设计不详细或不完整对测试造成的影响。

“灰盒”测试的不足：

1.8.4
测试用例设计

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

测试用例编写要素:名称和标识、用例说明、初始化要求、测试的输入、预期结果、评价测试结果的准则、操作过程、前提和约束、测试终止条件。

编写测试用例的注意事项：

功能检查

面向用户的考虑

数据处理

软件流程测试

测试用例的设计步骤：

测试需求分析

业务流程分析

测试用例设计

测试用例评审

测试用例更新完善

1.8.5单元测试

1.单元测试概念

单元测试（模块测试）是开发者编写的一小段代码，用于检测被测代码的一个很小的、很明确的功能是否实现。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为，是对单个的软件单元或者一组相关的软件单元所进行的测试，是代码级的测试。

2.
单元测试的目的

①
检验程序各模块中是否存在各种差异；②是否能正确实现其功能；③
满足该模块的性能要求；④
满足该模块的接口要求。

3.单元测试的内容

模块接口测试、局部数据结构测试、路径测试、错误处理结构、边界测试

单元测试的方法

驱动模块：相当于所测模块的主程序

桩模块：由被测模块调用的替代物

单元测试的步骤

第一步：构建测试用例的运行环境，即确定用例运行的前提条件，明确被测模块或被测单元所需的程序环境（全局变量的赋值或初始化实体），启动测试驱动，设置桩，调用被测模块，设置预期输出条件判断，最后恢复环境（包括清除桩）。

第二步：设计“黑盒”测试用例，即接口测试用例。（基本功能测试用例、功能正面测试用例、功能反面测试用例、性能测试用例）。

第三步：设计“白盒”测试用例，即覆盖测试用例，找出单元内部控制结构和数据使用可能存在的问题。

1.8.7
集成测试

集成测试概念

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求集成为子系统或系统，进行集成测试。即在集成测试之前，单元测试已经完成，并且集成测试所使用的对象应当是已经经过单元测试保证的单元，如果不通过单元测试，集成测试的效果将会受到影响，并且会付出更大的代价。单元测试完成后便进入集成测试阶段。

单元测试、集成测试与系统测试的差别（表1）

表1
单元测试、集成测试与系统测试的差别

测试类型	对象	目的	测试依据	测试角度	测试方法
单元测试	模块内部的程序错误	消除局部模块的逻辑和功能上的错误和缺陷	模块逻辑设计，模块外部说明	站在开发人员角度	大量采用白盒测试方法
集成测试	模块间的集成和调用关系	找出与软件设计相关的程序结构，模块调用关系，模块间接口方面的问题	程序结构设计	站在测试人员角度	灰盒测试，采用较多黑盒方法构造测试用例
系统测试	整个系统，包括系统中的硬件等	对整个系统进行一系列的整体、有效性测试	系统结构设计，目标说明书，需求说明书等	站在用户使用角度	黑盒测试

集成测试方法

⑴
非渐增式测试方法（一次性组织方式）

这种方式首先对每个模块分别进行单元测试，对单元的测试次序是无关紧要的，它可以顺序地进行，也可以平行的进行，最后再把所有模块集成在一起进行测试，最终得到要求的软件系统。

⑵
渐增式测试方法

①
自顶向下集成测试方法步骤

以主模块为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块对主模块进行测试。

采用深度优先或宽度优先的策略，用实际模块替换相应桩模块，再用桩代替它们的直接下属模块，与已测试的模块或子系统集成为新的子系统。如下图

进行回归测试（即重新执行以前做过的全部测试或部分测试），排除集成过程中引起错误的可能。

判断是否所有的模块都已集成到系统中，是则结束测试，否则转到b去执行。

分类：

深度优先方法

广度优先方法

②
自底向上集成测试方法步骤

由驱动模块控制最底层模块的并行测试，也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。

用实际模块代替驱动模块，与它已测试的直属子模块集成为子系统。

为子系统配备驱动模块，进行新的测试。

判断是否已集成到达主模块，是否结束测试，否则执行b。

③
混合渐增式集成测试方法（“三明治”集成方法）步骤

a.
首先对目标层之上一层使用自顶向下集成，因此测试A，使用桩代替B，C，D

b.
其次对目标层之下一层使用自底向上集成，因此测试E，F，使用驱动代替B，D

c.
其三，把目标层下面一层与目标层集成，因此测试（B，E），（D，F），使用驱动代替A

d.
最后，把三层集成到一起，因此测试（A，B，C，D，E，F）

1.8.8
系统测试

1.系统测试的概念

系统测试是为判断系统是否符合规定而对集成的软、硬件系统进行的测试活动。

2.系统测试各阶段的任务（表2）

表2
系统测试各阶段的任务

活动名称	输入工作	输出工作	角色
制定系统测试计划	软件需求文档、软件项目计划	系统测试计划	测试设计员
设计系统测试	系统测试计划、软件设计文档	系统测试用例	测试设计员
实施系统测试	系统测试计划、系统测试用例	系统测试脚本	测试设计员
执行系统测试	系统测试计划、被测软件系统、系统测试用例、系统测试脚本	测试结果	测试员
评估系统测试	测试结果	软件测试报告	测试设计员、测试员

3.系统测试采用的技术

4.系统测试主要采用“黑盒”测试技术设计测试用例，来确定软件满足需求规格说明的要求。

5.系统测试要交付的文档

系统测试要交付的文档主要有：系统测试计划、系统测试计划评审报告、系统测试用例、系统测试用例评审报告、系统测试脚本、系统测试脚本评审报告、系统测试报告、系统测试报告评审报告、缺陷问题单等。

6.系统测试的主要内容

功能测试、性能测试、接口测试、人机交互界面测试、强度测试、余量测试、可靠性测试、安全性测试、恢复性测试、数据处理测试、安装性测试、容量测试、互操作性测试、敏感性测试、标准符合性测试、兼容性测试、中文本地化测试。

7.系统测试设计一般的流程

首先理解软件和测试目标，然后设计测试用例，接着运行测试用例并处理测试结果，最后评估测试用例和测试设计。

1.9软件手工测试与自动化测试

1.9.1手动化测试

概念：测试人员按照事先为覆盖被测试软件的需求而编写的测试用例，根据测试步骤和方法，手工的一个一个输入执行，然后观察结果，看被测程序是否存在问题，或在执行过程中是否有异常发生。

特点：

1.能够较好的控制测试的速度，详细的执行软件的各个功能。

2.测试人员要负责大量文档、报表的制定和整理工作。

3.受软件发布日期、开发成本等诸多方面的因素的限制，难以进行全面的测试。

4.反复的测试，代价大，容易出错，降低效率。

5．难以对不可视对象或对象的不可视属性进行测试。

适用场合：

1.测试很少执行的项目中。

2.软件运行仍不稳定

3.测试结果很容易通过人验证的测试项目。

4.测试项目中涉及屋里交互比较多的时候。

1.9.2自动化测试

概念：将软件测试工具集成起来，并做进一步开发，使得软件测试的启动、执行、结果分析等不需要人工干预，由它自己执行测试用例、查找软件的缺陷、分析收集到的信息、记录结果等。

特点：

1.高效率进行测试。

2.可以执行一些手工测试困难或者不可能做的测试。

3.测试的准确性得到提高。

4.资源利用率得到提高。

5.具有一致性和可重复性。

6.有利于进行回归测试。

7.测试具有移植性和可重复性。

8.缩短测试时间。

局限性：

1.
自动化测试能够大大降低手工测试工作，但不能完全代替手工测试。

2.软件测试自动化可能降低测试的效率。

3.缺乏测试经验。

4.技术问题。

使用场合：

1.软件维护时使用回归测试时适合自动化测试。

2.执行压力测试时适合自动化测试。

3．配置和兼容性测试等项目适合自动化测试。

2
实训总结及问题反馈

2.1第一、二次实验

2.1.1.testlink中各角色职责

TestLink
有6种不同的默认权限级别，对于管理员，可以通过用户管理链很容易地改变权限。这些权限如表3所示：

表3.testlink中各角色职责

Guest	只能查看测试用例和项目度量。
Tester	只能执行分配给他们的测试用例。
Test Designer	可以开展测试用例和测试需求的所有工作。
Senior Tester	可以查看、创建、编辑和删除测试用例，并且可以执行测试用例，但是不能管理测试计划、管理产品、创建里程碑或分配权限。(针对初级测试和高级测试员)。
Leader	拥有一个Tester所有的权限，并且可以管理测试计划、分配权限、创建里程碑和管理关键字。
Admin(Administrator)	拥有一个Leader所有的权限 ，并且可以维护整个产品。

2.1.2问题反馈

整理testlink及mantis实验中遇到的问题及解决方法

表4重点难点问题列表

工具	问题描述	解决方法
Testlink	端口占用问题	在安装过程中出现服务启动问题，导致testlink的页面打不开的情况。需要在在XAMPP中修改端口，重启testlink.。
端口修改后问题	出现testlink的页面打不开的情况，需将修改后的端口号填写在地址栏中。
选填问题	创建项目时需在选择打钩处打钩，否则不会出现实验继续所须要的功能选项。
指派用户	容易因操作错误进入其他用户管理权限，不能继续进行操作
TextLink中无法输入文本	F12兼容性
Mantis	如何以不同身份登陆	打开xampp里的数据库用户表对默认的用户密码进行修改

2.2第三次实验

2.2.1.知识点

测试用例的设计方法：等价类划分法、因果图法、边界值分析法。

.等价类划分法设计一个新的测试用例应该尽可能多的覆盖尚未被覆盖的有效等价类，仅覆盖一个尚未被覆盖的无效等价类。

22.2.实验分析

1.等价类划分：

某城市电话号码由三部分组成。它们的名称和内容分别是：

（1）地区码：空白或3位数字；

（2）前缀：非‘0’或非'1'的3位数字；

首先分析案例的需求有：地区码，前缀和后缀，根据每个需求进行等价类划分,列出等价类表，根据需求和划分的等价类进行设计测试用例。

2.边界值分析法

持卡人消费返现问题：

首先理解案例，确定输入数据的边界值，开始设计测试用例。

3.因果图法

供货折扣计算模块：

首先理解案例，列出原因和结果，找出逻辑关系，画出因果图，添加必要的约束条件，填写真值表，设计测试用例。

2.2.3问题反馈

输入用户名和密码之后，需求上没有说明有没有相应的信息提示，所以期望结果不能乱写，要有依据，对于这种情况，可以将第二步和第三步合并到一块来写（图17）。

图17
合并步骤

2.3第四次实验

2.3.1知识点

测试要点编写：

1.首先要分析测试需求，找出其测试功能有几个模块；

2.根据测试功能点在往下分测试要点，要注意与测试功能点相结合；

3.再根据测试要点写测试点时，应完全覆盖测试需求而且无冗余；

4.在编写测试要点时，要注意编写规范以及模版规范。

测试用例编写：

测试用例ID ：用于唯一标识测试用例号，可根据自身需要定义规则，最好易于跟踪和维护；

测试前置条件：如果有则描述之；

测试用例等级：根据需求重要性区分测试用例等级；

优先级：根据需求重要性区分优先级。

缺陷报告编写：

在编写缺陷报告过程中，可能有测试用例覆盖不到的，要注意结合具体软件，边操作边写，以免漏掉部分缺陷，同样的，缺陷报告也要注意编写规范和模版规范，根据需求重要性区分优先级和问题级别。

2.3.2实验分析

案例：航天登录系统

编写测试用例之前，为了更明确需求，精确划分，首先编写测试要点，根据每个功能点作为一个测试要点，依据等价类划分法或其他方法进行对测试点的补充，做到全面覆盖且不冗余。下一步开始设计测试用例，每一条测试点对应一条测试用例。执行测试用例，查找缺陷，根据缺陷，正确填写缺陷报告。

2.5testlink报告附件

航空系统测试报告testlink_11班_张继雅.doc

2.6manti缺陷报告附件

Mantis航班预订系统缺陷报告_6组_张继雅.doc

3
学习规划

时光飞逝，在惠普的时间已经差不多一个月了，第一阶段也进入了尾声。在这一个月里，学到了许多的知识，对软件测试行业也有了新的认识。

我今后会更加努力和认真的去学习新的知识，同时也希望自己今后可以为自己的团队做出更大的贡献，尽自己最大的努力，做到最好。