软件测试重点内容

牢记2、5、6、7、8

理解1、3、4、9 

第一章 软件工程要点

 

软件：文档+程序+数据

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

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

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

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

软件危机影响：（1）用户满意度（2）成本与进度（3）质量（4）可维护性（5）文档支持（6）与时俱进

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

C/S结构

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

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

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

B/S（Browser/Server，浏览器/服务器）模式又称B/S结构

第二章 软件测试基础

软件测试定义：

定义1：评价程序和系统的功能，并确定是否达到预期效果。

定义2：测试是为发现错误而执行程序或系统的过程。

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

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

软件测试目的（立场不同）

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

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

软件测试的目的

 

 

 

开发人员的测试：是调试（Debug）还是测试（Test）?

调试是“建设性”的？          测试是“破坏”性的？

 

软件测试的目的

 

 

 软件测试原则

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

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

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

除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不可能的。通过运用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。

（3） 测试尽早介入 #3

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

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

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

（5）杀虫剂悖论 #5

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

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

针对不同的测试背景，进行的测试活动也是不同的。比如，对安全关键的软件进行测试，与对一般的电子商务软件的测试是不一样的。

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

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

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

 

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

软件测试工具的好处：

（1）提高工作效率，减少重复性工作量，保证测试的准确性

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

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

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

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

 

 

软件测试工作流程

 

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

综合能力:

（1）较强的沟通能力、团队合作精神

（2）测试中要做到“五心”：专心、细心、耐心、责任心和自信心

（3）具有怀疑精神和洞察力

（4）具有探索、创新和挑战精神，努力追求完美

（5）积极、主动的学习能力

软件测试心理学

开发人员的思维

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

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

3、思维的局限性

测试人员的思维

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

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

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

4、实践思维能力（将想法变成现实的能力）

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

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

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

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

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

（4）确信其他成员已经理解你的描述

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

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

2、V模型 W模型

 

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

 

软件配置项的概念

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

基于软件配置项的分类

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

软件测试分级

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

软件测试中的错误分级

 

 

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

单元测试主要能发现组件内部的功能性和非功能性问题，这些问题包括：功能性问题（逻辑错误、功能丢失）

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

软件生命周期的测试分级（续）

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

主要测试类型：（1）根据合同的验收测试（2）用户验收测试（3）运行（验收）测试（4）现场测试

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

第五章 软件缺陷管理

软件缺陷的定义

 

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

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

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

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

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

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

软件缺陷产生的原因

调查研究表明：大多数软件缺陷并不是由于编码造成的，导致大多数软件缺陷产生的最大的原因是需求分析阶段，其次是在软件设计阶段

 

 

软件缺陷报告

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

报告缺陷的基本原则

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

 

 

或：Reject 评审委员会评审通过

 

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

软件测试模型——V模型

 

 V模型特点

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

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

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

 

W模型特点

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

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

V模型和W模型的局限性

（1）串行活动，无法更好适应变更：把软件的开发视为需求、设计、编码等一系列的串行活动，无法解决需求变更等变更调整。

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

（3）测试完整性不足：顺序模型中没有很好体现测试流程的完整性

软件测试流程

 

软件测试过程度量

 

 

第八章 动态测试

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

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

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

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

白盒测试的特点

（1）可以构成测试数据使特定程序部分得到测试（2）有一定的充分性度量手段（3）可获得较多工具支持（4）通常只用于单元测试

白盒测试技术

 

 

 

 

逻辑覆盖的种类

语句覆盖（语句全部覆盖）

判定覆盖（针对判断条件的分支，使分支真假都执行一次）

条件覆盖（条件全覆盖）

判定/条件覆盖（条件真假/判定真假执行一次）

条件组合覆盖（条件取值组合执行一次）

路径覆盖（所有路径）

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

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

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

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

黑盒测试分类：

等价类划分

考虑因素（输入数据、输出数据）

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

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

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

划分等价类的经验原则

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

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

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

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

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

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

边界值分析法

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

原则：

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

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

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

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

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

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

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

还有：因果图、随机数法、猜错法

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

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

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

这是不可能的

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

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

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

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

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

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

灰盒”测试思想

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

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

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

软件测试的对象

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

02、程序源代码

03、需求规格说明

软件测试计划的内容

01测试目的、背景

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

03测试内容和评价标准