软件测试基础知识

Posted 2020-09-04 安小

软件测试基础知识

1．  软件质量与软件测试

软件测试：在规定条件下对程序进行操作，以发现错误，对软件质量进行评估，包括对软件形成过程的文档、数据以及程序进行测试

软件质量：软件特性的总和，软件满足规定或潜在用户需求的能力

2．  软件测试与质量保证

软件测试只是质量保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作；

质量保证：通过预防、检查与改进来保证软件质量，采用全面质量管理和过程改进的原理来开展质量保证工作，主要关注软件质量的检查与测试，主要着眼于软件开发活动的过程、步骤和产特

软件测试：通过执行软件来，对过程中的产物（开发文档和程序）进行走查，发现问题，报告质量

3．  软件测试的目的

测试是程序的执行过程，目的在于发现错误；

一个好的测试用例在于发现了至今未发现的错误；

一个成功的测试是发现了 至今未发现的错误的测试；

4．  软件测试原则

所有的软件测试都应追溯到用户需求

应当把“尽早地和不断地进行软件测试”作为测试者的座右铭

完全测试是不可能的，测试需要终止

测试无法显示软件潜在的缺陷；

充分注意测试中的群集现象

程序员应避免检查自己的程序

尽量避免测试的随意性

5．  软件测试对象

程序开发过程中的各个文档、源程序

6．  软件测试过程模型－V模型

 

 

非常明确地标明了测试过程中存在的不同级别，主要反映测试活动与分析和设计的关系；

• 从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。
• 左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。

局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现

7．  软件测试过程模型－W模型

 

在V模型的基础上，增加了开发阶段的同步测试，形成W模型；在模型中不难看出，开发是“V”，测试是与此并行的“V”。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

局限性：仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整

8．  软件测试过程模型－H模型

 

 

在H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；软件测试可以进行尽早的进行；软件测试可以根据被测物的不同而分层次进行

9．  测试模型使用

在实际工作中应灵活地运用各种模型的优点

V模型	强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试
W模型	补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明
H模型	强调测试是独立的，只要测试准备完成，就可以执行测试

 

10．  单元测试

定义	又称模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作；可以从程序的内部结构出发设计测试用例，多个模块测试可以平行地独立进行测试
目的	发现模块内部可能存在的各种差错
内容	模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
步骤	利用设计文档设计测试用例；创建被测模块的桩模块或驱动模块；利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试

 

 

11．集成测试

定义	又称组装测试或联合测试，在单元测试基础上，将所有模块按概要设计和详细设计进行组装
目的	发现模块连接中的接口可能存在的各种差错
内容	穿越模块之间的数据是否会丢失；一个模块组装后是否会对另一模块或其他模块存在影响；各个子功能组装在一起是否会达到预期的父功能；全局数据结构是否有问题；单个模块的错误累积起来是否会放在
组装方法	一次性组装方式，非增殖式方式也叫整体拼装，对模块分别测试然后将所有模块组装；第二种增殖式组装方式，可以是自顶向下或自底向上
完成标志	成功地执行了测试计划中规定的所有测试用例；修正了所发现的错误；测试结果通过专门小组的评审

 12．确认测试

目的	验证软件的功能和性能及其他特性是否与用户的要求一致
测试内容	有效性测试 运行黑盒测试方法验证所测软件是否满足需求规格说明书列出的需求；所有文档正确且便于使用；软件可移植性、易用性、兼容性进行测试；软件配置复查 保证软件配置的所有成分都齐全

 

13．系统测试

目的	验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试
测试内容	在真实或模拟系统运行环境下，检查完整的程序系统能否和系统（硬件设备、网络、系统软件）正确配置、连接，满足用户需求

14．白盒测试

通过对程序内部结构的分析、检测来寻找问题，检查程序的结构及路径是否正确，检查程序的内部动作是否按照设计说明的规定正常进行

15．黑盒测试

又称功能测试，通过运行程序发现其缺陷和错误，在程序界面处进行测试

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。

a.功能不正确或遗漏；

b.界面错误；

c.输入和输出错误；

d.数据库访问错误；

e.性能错误；

f.初始化和终止错误等。^[1] 

 

 

从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。

 

a.等价类划分

等价类划分的办法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的，常用的黑盒测试用例设计方法。

  

 

 

b.边界值分析法

边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于的边界值作为测试数据，而不是选取等价类中的典型值或是任意值作为测试数据。

例如，我们上述中所说的密码的格式是6~10个的自然数，我们可以根据等价类的划分法来确定边界值的测试用例表示。

 

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于的边界值作为测试数据，而不是选取等价类中的典型值或是任意值作为测试数据。

例如，我们上述中所说的密码的格式是6~10个的自然数，我们可以根据等价类的划分法来确定边界值的测试用例表示。

 

c.场景法

 

 

 

     

16. 测试方法的综合策略

1. 首先进行等价划分，包括输入、输出条件的等价划分，将无限测试变成有限测试。

2. 使用边界值分析法。

3. 使用错误推测发，追加一些用例。

4. 对照程序逻辑，检查用例设计的逻辑覆盖，力求达到覆盖标准。

5. 程序功能说明中有输入条件组合，就可选用因果图和判定表驱动法。

6. 对于参数配置类软件，用正交试验法选择较少组合到达最佳效果。

7. 功能图是用例设计的好方法，通过不同时期条件的有效性设计不同的测试数据。

对应业务流程清晰的系统，用场景法贯穿测试过程，在案例中综合使用各种测试方法。

 

17．黑盒测试与白盒测试区别

黑盒测试	白盒测试
不涉及程序结构	考查程序逻辑结构
用软件规格说明书生成测试用例	用程序结构信息生成测试用例
可适用于从单元测试到系统联调	适用于单元测试和集成测试
某些代码段得不到测试	对所有逻辑路径进行测试

 

18．测试分类

开发过程	单元、集成、确认、系统、验证
实施组织	开发方、用户、第三方
测试技术	白盒、黑盒、灰盒或静态、动态

 

19．软件测试风险分析

软件测试风险：是软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，造成测试的补充以及结果不准确

软件测试风险主要是对测试计划执行的风险分析与制定要采取应急措施；重点在措施

测试计划的风险：一般指测试进度滞后或出现非计划事件；常见的有交付日期、测试需求、测试范围、测试资源、人员的能力、测试预算、测试环境、测试支持、测试工具；

20．文档测试的范围

用户文档	用户手册、操作手册、维护修改建议
开发文档	需求说明书、概要设计、数据库设计、详细设计、可行性研究报告
管理文档	项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告

21．用户手册的测试

准确的按照手册的描述使用程序；尝试每一条建议；检查每条陈述；查找容易误导用户的内容；

22. 测试计划

   测试计划（Test Plan）一般由测试负责人来编写。

   测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：

 

1．  测试背景

a.       软件项目介绍；

b.       项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。

2．  测试依据

a.       软件需求文档；

b.       软件规格书；

c.       软件设计文档；

d.       其他，如参考产品等。

3．  测试资源

a.       测试设备需求；

b.       测试人员需求；

c.       测试环境需求；

d.       其他。

4．  测试策略

a.       采取测试方法；

b.       搭建哪些测试环境；

c.       采取哪些测试工具以测试管理工具；

d.       对测试人员进行培训等。

5．  测试日程

a.       测试需求分析；

b.       测试用例编写；

c.       测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

6．  其他。

 

测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。

计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。

 

23. 测试设计

测试设计主要包括测试用例编写和测试场景设计两方面。

一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。关于测试用例编写，请参见前面写的《也谈测试用例》一文，里面有详细阐述。

测试场景设计主要也就是测试环境问题了。

 

24．测试用例说明

 测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。

测试用例英文名叫Test case，测试用例是开展测试工作的重要一项，测试用例是否完善、质量高低以及执行的情况如何是影响软件测试结果的一个重要方面。可以说测试用例是软件测试中一个举足轻重的因素。本文就有关问题进行阐述。

【关键词】测试用例

 

概述

用例文档（checklist），是关于具体测试步骤的文档，它描述了测试的输入参数、条件及配置、预期的输出结果等，以判断被测软件的工作是否正常。从表现形式上而言，测试用例可以是纯文本的说明文档，也可以是用脚本语言或高级语言编写的一段代码。

 

测试用例文档由简介和测试用例两部分组成。简介部分编制测试目的、测试范围、定义术语以及测试背景等。测试用例部分逐一列示各测试用例，测试用例应当包括测试标识、测试用例名称、目标、测试条件、测试设置、输入数据要求、步骤、以及预期的结果等。

写测试用例有什么好处：

• 1. 理清思路，避免遗漏 2.跟踪测试进展 3. 历史参考 4. 重复性（可供别人参考使用）

 

 

 

 

 

（1）      定义（ANSI/IEEE829）：编写用于输入的实际数据和预期结果，并明确指出使用具体测试用例产生的测试程序的任何限制

（2）      包含的内容

l  标识符：由测试设计过程说明和测试程序说明引用的唯一标识符

l  测试项：描述被测试的详细特性、代码模块等

l  输入说明：列举执行测试用例的所有输入内容或者条件

l  输出说明：描述进行测试用例预期的结果

l  环境要求：执行测试用例的软件、硬件、测试工具及人员等要求

l  特殊要求：描述执行测试用例的特殊要求

l  用例之间的依赖性：注明与其分用例的依赖关系或受其他用例的影响

 

  网页登录测试例子：http://www.cnblogs.com/TankXiao/p/3154017.html

 

25. 测试执行

测试执行过程又可以分为以下阶段：

单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。

 

26. 测试记录

缺陷记录总的说来包括两方面：由谁提交和缺陷描述。

一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。

在缺陷的描述上，至少要包括以下一些方面内容：

序号

标题

预置条件

操作步骤

预期结果

实际结果

注释

严重程度

概率

版本

测试者

测试日期

 

以上是描述一个bug时通常所要描述的内容，当然在实际提交bug时可以根据实际情况进行补充，如附上图片、log文件等。

另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。

 

27. 软件评估

这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。

软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。

 

28. 测试总结

每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成RTM后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。测试总结无严格格式、字数限制。应该说，测试总结还是很总要的。

 

29. 测试维护

   由于测试的不完全性，当软件正式release后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。

 

30．功能自动化测试

作用	帮助测试工程师自动处理测试开发到测试执行的整个过程中的问题，可以创建可修改且可复用的测试脚本，随时执行脚本，减少劳动量、提高测试效率
原理	采用录制回放的方式来模拟用户的实际操作；采用环境判断录制模式或模拟模式
步骤	创建脚本、调试脚本、执行测试、结果分析