软件测试基础

1：软件的概念：

由数据、文档、程序组成

2.2: 软件危机

落后的软件生产方式无法满足迅速增长的计算机软需求，从而导致软件开发与维护过程中出现严重问题。

3.3：软件工程：

方法、工具、过程

4.4：软件生命周期：

定义——设计——实施——测试——部署——运行——维护

5.5: 瀑布模型：

计划（定义阶段）——需求分析——设计——编码（开发阶段）——测试——运行维护（维护阶段）

优点：提供基本框架  提供阶段检查点  前面完成后只需关注后续

缺点：阶段之间缺少反馈，线性模型，错误不能及时发现，增加了开发风险，产生大量的文档，工作量加大

 

6666.6：V模型：

需求分析——概要设计——详细设计——编码 ——单元测试——集成测试——系统测试——验收测试

第二章知识点

2.1：软件测试的定义：

 为了发现错误而执行程序的过程，是对软件需求、设计、编码的进一步复查，是软件质量保证的关键步骤

2.2：软件测试的目的：

Ø 发现缺陷，提高质量

Ø 验证是否满足需求

Ø 建立软件质量信心

2.3：软件测试的原则：

Ø 测试显示缺陷的存在

Ø 尽早介入的原则

Ø 穷尽测试时不可能的

Ø 测试依赖于测试背景

Ø 缺陷集群性

Ø 杀虫剂悖论

Ø 缺陷不存在的谬论

2.4：软件测试类型

手册语文当测试    一致性测试  功能测试 覆盖性测试 压力测试         

2.5：软件测试的流程:

    测试计划和控制——测试需求和测试用例——实行和执行测试用例——评估测试报告——测试活动结束

 

3.1什么是生命周期测试

生命周期测试应该伴随整个软件开发周期，此时测试的对象不仅仅是程序，需求，功能和设计同样要测试。测试与开发同步进行，有利于尽早发现问题，同时缩短项目的开发建设周期。

3.2缺陷报告编写

软件缺陷报告里边需要包含哪些知识点？

     缺陷ID、缺陷标题、报告者、报告的日期、状态、优先级、严重级 、运行环境、详细描述、问题重现步骤、结果对比

3.3软件测试的过程：

  需求分析 测试计划 用例设计 执行用例 缺陷追踪 测试报告

3.4生命周期各阶段测试内容：

1.需求阶段 确认定义的需求复合机构要求

2.设计和编程阶 验证设计的程序实现了需求

3.测试和安装阶段 检查实现的系统符合系统规格说明书

4.维护阶段 重新测试确定改变的部分和未改变的部分能继续工作

     第四章知识点

4.1：软件配置CSCI：

    是为独立的配置管理而设计的且能满足最终用户要求的一组软件。软件开发过程中，产生的所有信息或构成软件设置，它们是：代码、文档、报告等，统称为配置项。

4.2：基线：

    指受配置的某个研制阶段的结束点时软件成分的技术状态，是已经通过正式审核和同意，是下一步软件开发的基础。任何一个软件配置项，一旦通过形成文档并审议通过，即成为基线。

4.3：软件测试分类：

Ø 1 是否关心内部结构   白盒测试赛、黑盒测试、灰盒测试

Ø 2 开发过程级别  单元测试、集成测试、系统测试、验收测试

Ø 3 是否执行程序  静态测试、动态测试

Ø 4 执行是否人工干预   手工测试、自动化测试

Ø 5 测试实施组织   开发测试、用户测试、第三方测试

第五章知识点

5.1：软件缺陷原因：

Ø 1.需求定义不完善，甚至没有需求文档

Ø 2.人员之间的沟通交流不够

Ø 3.软件需求的不断变化

Ø 4.软件复杂程度高，缺陷很难避免

Ø 5.开发人员能力有限

Ø 6.开发人员出现编码错误

Ø 7.不符合文档编制和编码规定

Ø 8.工期短任务中开发和测试工作不充分

Ø 9.文档编制错误

                                                                                 

5.2：软件缺陷的定义：

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

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

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

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

Ø  5  软件难以理解，不易使用，运行缓慢

5.2软件缺陷基本信息：

    缺陷ID、标题、报告人、报告日期、程序的名称、严重性、优先级、缺陷描述、重新步骤、结果对比

6.1：软件测试过程模型

Ø   V模型    特点：不同测试阶段和开发过程期间各阶段的对应关系，强调阶段性

Ø   W模型   特点：增加了软件开发阶段中应同步进行的验证和确认活动，基于“尽早地和不断地进行软件测试”的原则

Ø   H模型    特点：软件测试时一个独立的构成，贯穿整个生命周期。强调独立性

6.2：软件测试过程

   提取测试需求——制定测试计划——制定测试策略和方案——开展测试设计——执行测试用例——分析测试结果

6.3：软件测试过程中的管理理念：

1、尽早测试

2、全面测试

3、全过程测试

4、独立的迭代测试

第七章知识点

7.1：软件静态测试：

Ø     不执行程序代码而寻找代码中可能存在的错误评估程序代码的过程

①　不必动态地进行程序

②　可以人工进行，充分发挥 人的想象力

③　不需要特别的条件，容易展开

④　对测试人员要求比较高

7.2：同行评审：

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

审查 ：非作者等专家在内的针对特定对象进行检查以发现缺陷的过程，最正式

小组评审： 一种“轻型审查”,可采用审查的指导方针和流程

走查 ：是产品的作者向一组同事说明该产品，希望获得他们的意见以满足自己的需要

同级桌查 ：指除作者以外只有一位评审专家对工作产品进行检查

临时评审：请团队内其他同事帮忙，在短时间内解决一些问题，最不正式

7.3：代码检查方法：

代码检查是白盒测试的一种静态测试方法，是众多软件测试方法中发现软件缺陷最有效的方法之一。

代码走查、代码审查、桌面检查、技术审查

7.4：需求规格说明书的测试：

1、规格说明书的概要评审

2、规格说明书的详细评审（完整性、精确性、准确性、一致性、相关性、可行性）

第八章知识点

8.1白盒测试

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

8.2白盒测试的特点

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

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

 8.3白盒测试与调试的区别

    调试和动态白盒测试都包括处理软件缺陷和查看代码的过程，但是他们的目标不同。动态白盒测试的目的是发现问题，而调试的目的是改正缺陷，但他们的共同目的是分离缺陷。

动态白盒测试技术包括：

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

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

Ø     条件覆盖：不仅每一个语句至少执行一次，使得判定中的每个条件获得各种可能的结果。

Ø  判定覆盖只关心整个判定表达式的结果，条件覆盖关心的则是每个条件各种取值的结果。

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

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

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

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

 8.3 黑盒测试 

    黑盒测试又称功能测试或数据驱动测试把测试对象当作看不见内部的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性.站在使用软件或程序的角度，从输入数据与输出数据的对应关系进行的测试在软件的接口处进行测试通过导出执行程序所有功能需求的输入条件集，实现功能覆盖，需求覆盖。

 8.4 等价类划分

Ø     等价类，把所有可能的输入数据,即程序的输入域划分成若干部分,划分，从每一部分中选取少数有代表性的数据做为测试用例，代表性数据等同于该类中的其他值（按区间划分，按数值划分，按数值集合划分，按限制条件或规划划分，按处理方式划分）

Ø      划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合

 8.5边界值分析

   边界值分析是对等价类划分方法的补充，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，采用边界值分析法设计测试用例进行软件测试，常常可以查处更多的错误，取得良好的测试效果。

  8.6边界值分析原则：

  如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围的边界值作为测试的输入数据。 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为册数数据。根据规格说明的每个输出条件，使用原则 ；如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。分析规格说明，找出其他可能的边界条件。

 8.7 因果图

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

适用范围: 

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

Ø  产生背景

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

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

①　分析软件规格说明描述：原因、结果、标识符

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

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

④　把因果图转换成判定表

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

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

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

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

• 这是不可能的

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

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

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

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

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

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

8.10测试用例设计

Ø    测试用例特点

   正确性，完整性（涵盖功能、性能、压力等），准确性，清晰、简洁，可维护性，适应性，可重用性，可追溯性，可移植性等

Ø  测试用例设计的基本原则

1、基于测试需求的原则；

2、基于测试方法的原则；

3、兼顾测试充分性和效率的原则；

4、测试用例的代表性；

5、测试结果的可判定性；

6、测试执行的可再现性原则；

8.11测试用例编写要素

追踪/来源：            涉及的参考资料，如用户的需求、涉及文等

用例说明：             测试对象，采用的方法

测试的初始化要求:      哪个测试对象？在什么硬件/软件—平台？

测试的输入:           输入数据

测试结果：            期望测试结果

评价测试结果：        精度等

操作过程：            测试步骤

前提和约束：           约束

测试终止条件：        正常终止或异常终止

8.12单元测试

单元测试的定义：是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

8.13集成测试

集成测试的定义：是单元测试的逻辑扩展。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合为程序的更大部分。方法是测试片段的组合，并最终扩展成进程，将模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程

集成测试的方法：

1、一次性组装方式2、混合渐增式集成测试方法1）自顶向下集成测试2）自底向上集成测试方法

3）回归测试4）组装测试

集成测试的内容：

1、集成后的功能性测试

2、2、接口测试

3、全局数据结构测试

4、资源测试（共享资源测试和资源极限测试）

5、性能测试

6、稳定性测试

8.14确认测试

确认测试基本概念：确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样

确认测试过程

1、确认测试流程 2、有效性测试3、软件配置复查4、α测试和β测试5、验收测试

6、确认测试结

8.15系统测试

系统测试设计

1、测试设计的一般流程——理解软件和测试目标

2、测试设计的一般流程——设计测试用例

3、测试设计的一般流程——运行测试用例并处理测试结果

4、测试设计的一般流程——评估测试用例和测试设计

系统测试手段

典型攻击方法——25种典型攻击

 1）用户接口输入攻击(6种)

 2）用户接口输出攻击(4种)

 3）用户接口数据攻击(3种)

 4）用户接口计算攻击(4种)

 5）文件系统介质攻击(3种)

 6）文件系统文件攻击(3种)

 7）操作系统和软件接口攻击(2种)

第九章 软件手工测试与自动化测试

1.软件手工测试与自动化测试的概念:

1.手工测试的概念：手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。

2.自动化测试的概念：一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。

2.手工测试的特点：

测试人员要负责大量文档，报表的制定和整理工作，会变得力不从心。

受软件发布日期，开发成本及人员，资源等诸多方面因素的限制，难以进行全面的测试、

如果修正缺陷所需时间太长。那么想将手工测试应用用于回归测试将变得异样困难。这是因为需要测试的测试用例太多。

对测试过程中发现的大量缺陷缺乏科学，有效的管理手段，责任变得含混不清，没有人能向决策层提供精确的数据以及度量当前的工作进度及工作效率。这样往往会导致最后的汇总报表数据不准确。

发福测试带来的倦态情绪及其他人喂因素使得测试标准前后不一，测试花费的时间越长，测试的严格性也就越低。

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

 自动化测试的特点：
1）高效率的进行测试。

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

测试的准确性得到提高。测试人员的技术要求可以降低。

资源利用率得到提高。

具有一致性和可重复性、

有利于进行回归测试。

测试具有一致性和可重复性。

缩短测试的时间。

手工测试和自动化测试各自使用的场所：

测试很少执行的项目中。

软件运行仍然不稳定时，适合使用手工测试。

测试结果很容易通过人验证的测试项目适合手工测试。

测试项目中涉及物理交互表较多的时候适合手工测试、

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

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

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

3.测试框架的概念：

答：测试框架是一组自动化测试的规范、测试脚本的基础代码，以及测试思想、惯例的集合。

 

一.常用的测试自动化框架：

1）测试脚本模块化框架

2）测试库框架

3）数据驱动测试框架

4）关键字驱动或者表驱动的测试框架

5）混合测试自动化框架

4.自动化测试技术：

答：自动化测试， 是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入自动化测试的概念。

脚本技术：

1）线性脚本

2）结构化脚本

3）共享脚本

l 数据驱动脚本

l 关键字驱动脚本

l 录制/回放技术