软件测试入门基础

前言

1983年，IEEE定义软件测试是使用人工或自动的手段对系统运行或测试的过程，其目的在于检验它是否满足规定的需求，或弄清预期结果与实际结果之间的差别。

测试人员的主要工作职责

1. 编写测试计划
2. 编写测试用例
3. 执行测试，发现缺陷提交缺陷报告
4. 验证所发现的缺陷是否得到修改
5. 编写测试总结报告（以客观数据说话，数据统计。和测试计
   划对应）

错误(error) 是指“与所期望的设计之间的偏差，该偏差可能产生不期望的系统行为或失效”。
失效(failure) 是指“与所规约的系统执行之间的偏差”。失效是系统故障或错误的后果。
故障(fault) 是指“导致错误或失效的不正常的条件”。故障可以是偶然性的或是系统性的。

测试工作应该要尽早介入（尽早测试原则），并且要贯穿整个开发过程始终（不断测试原则）。尽早测试可以降低解决缺陷的成本。需求分析阶段引入的bug最多（大概占bug总数的55%左右）；其次是设计阶段（大概占缺陷总数的25%左右）；编码阶段引入bug最少（只占缺陷总数的15%左右）；还有5%左右的bug是由兼容性问题和配置原因造成的。

软件测试是一种有效的提高软件质量的手段，但即使在投入上有所保证，测试也不能百分之百发现所有质量隐患，况且软件质量并不仅仅是测试出来的----测试能提高软件的质量，但是提高质量不能依赖测试
测试只能证明缺陷存在，不能证明缺陷不存在

每个开发人员应该测试自己的程序（这是他们的份内之事），但是不能作为该程序已经通过测试的依据（所以我们测试需要进行独立的测试）。

80-20原则：80%的缺陷聚集在20%的模块中，经常出错的模块改错后还会经常出错，这就是聚集效应，也成为群聚效应
测试应当循序渐进，不要企图一次干完整个项目的测试工作

软件测试的原则.
(1)所有的测试都应当追朔到用户需求。软件测试的目的在于发现错误，而从用户角度看，最严重的错误就是那些致使程序无法满足需求的错误。
(2)在测试工作开始前，要进行测试计划的设计。测试计划可以在需求分析一完成时开始，详细的测试用例定义可以在设计模型被确定后立即开始。
(3)测试应从小规模开始，逐步转向大规模。最初的测试通常放在单个程序模块上，测试焦点逐步转移到在集成的模块簇内寻找错误，最后在整个系统中寻找错误。
(4)穷举测试是不可能的。一个大小适度的程序，其路径排列的数量是惊人的。
(5)为了尽可能发现错误，应由独立的第三方来测试。
(6)在一-般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的bug,而系统测试又能找出其余一些bug，最后剩下的bug可能只能在用户的大范围、长时间的使用后才会暴露。因此测试只能保证尽可能多地发现错误，无法保证能够发现所有的错误。

软件测试流程

单元测试
单元测试：单元测试是对软件中的基本组成单位（比如模块，类）进行的测试。目的是检验软件基本组成单位的正确性。 主要目的是根据详细设计说明书来验证和确认每个单元模块是否符合预期的要求，发现编码过程中可能存在的各种错误。

驱动模块：模拟被测模块的上一级调用模块。（调用被测模块的那个模块）
桩模块：模拟被测模块的下一级被调模块。
（被测模块调用的模块）

集成测试
集成测试：主要目的是根据概要设计来验证和确认各个模块是否已正确集成到一起， 主要是检查各单元与其它模块之间的接口上可能存在的错误集成测试是在软件系统集成过程中所进行的测试。目的是检查软件单位之间的接口是否正确。

集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。
集成测试是检验程序单元或部件的接口关系（就是调用关系）逐步集成为符合设计要求的程序部件或整个系统。
软件集成的过程是一个持续的过程，会形成很多个临时版本，在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。
——冒烟测试也叫版本验证测试、提交测试。

系统测试
系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求

验收测试
验收测试：验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，向软件购买者展示该软件系统满足其用户的需求。

W模型

软件测试方法

软件测试方法的分类有很多种，以测试过程中程序执行状态为依据可分为静态测试（Static Testing，ST）和动态测试（Dynamic Testing，DT）;以具体实现算法细节和系统内部结构的相关情况为根据可分黑盒测试、白盒测试和灰盒测试三类;从程序执行的方式来分类，可分为人工测试（Manual Testing，MT）和自动化测试（Automatic Testing，AT）

软件测试可分为静态分析和动态测试
(1)进行静态分析时，不必运行软件，只是通过对源代码进行分析，检测程序的控制流和数据流，以及发现执行不到的“死代码”、无限循环、未初始化的变量、未使用的数据、重复定义的数据等;也可能包括对多种复杂性度量值的计算。静态分析虽然不能取代动态测试，但它是动态测试开始前有用的质量检测手段。
(2)动态测试技术借助于输入样例( 即测试用例)来执行软件，一般又分为功能测试(即黑盒测试)以及结构测试(即白盒测试)。

黑盒测试和白盒测试

黑盒测试（功能测试）
白盒测试（逻辑结构测试）

白盒测试与黑盒测试，主要是测试工作对软件代码的的可见程度的划分。这是软件测试中领域中最基本的两个概念。

黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。

黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测等，主要用于软件确认测试。

黑盒测试试图发现以下错误类型:

• 功能不对或遗漏;
• 界面错误;
• 数据结构或外部数据库访问的错误;
• 性能错误;
• 初始化和终止错误.

测试步骤

1. 第一步:获取事务流程图，即建立被测对象模型;
2. 第二步:浏览与复审
   主要对事务进行分类，为设计用例奠定基础;
3. 第三步:用例设计
   设计足够测试用例，实现基本事务覆盖。
   涉及：覆盖策略，事务选取等;
4. 第四步:测试设备开发:
   路径分析器，测试用例数据库，测试执行调度器等等
5. 第五步:测试执行;

白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。白盒测试的主要方法有逻辑覆盖、基本路径测试等，主要用于软件验证。

缺陷

软件缺陷（Defect—bug）
只要满足下列5个规则之一则称为发生了一个软件缺陷：

• 软件未实现产品说明书要求的功能
• 软件出现了产品说明书指明不应该出现的错误
• 软件实现了产品说明书未提到的功能（画蛇添足）
• 软件未实现产品说明书虽未明确提及但应该实现的功能（隐式需求）
• 软件难以理解、不易使用、运行缓慢，或者从测试员的角度看，最终用户会认为不好。

美国电气和电子工程师协会 （IEEE）对缺陷的定义：

• 从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；
• 从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

简单地说，用户在软件使用过程中遇到的任何软件错误、异常都可以称之为“软件缺陷”。

缺陷报告

测试用例是在执行测试之前由测试人员编写的指导测试的重要文档。解决要测什么（测试对象）、怎么测（测试过程）和如何衡量（预期结果）的问题。
包括：编号，测试目的，用例描述（步骤，数据）， 预期结果

缺陷报告
缺陷编号
缺陷标题
缺陷发现者
日期
所属模块
版本
处理人
缺陷状态
严重程度
优先级
缺陷描述

①缺陷编号（Defect ID）:提交缺陷的顺序

②缺陷标题（summary）：简明扼要的描述缺陷

③缺陷的发现者（Defected By）:测试人员

④缺陷发现日期（date）：一般为当天

⑤缺陷所属的模块（subject）：在测试哪个功能模块时发现的bug.
开发组可以据此决定由谁负责修改该bug

⑥发现缺陷的版本（Defected in release）

⑦指派给谁处理（Assigned to）:测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员。

⑧缺陷的状态（status）：缺陷此时所处的处理阶段或处理情况
（1）测试人员发现缺陷，提交缺陷报告、把缺陷的状态置为new（新）
（2）开发经理验证提交的bug，如果是bug,把状态改为open（打开的bug，开发组承认的bug），指派给具体的开发人员解决；如果不是bug,把状态改为rejected（拒绝的bug）
（3）开发人员看到指派给自己解决的bug，进行缺陷修复，修改完后，把缺陷状态改为fixed（已经修复的bug，可以返测的bug）
（4）测试人员对修复的bug进行返测，若返测成功，将状态改为closed（关闭的缺陷，归档的bug）；如果返测不成功，把状态改为reopen（重新打开的bug）

⑨缺陷的严重程度（severity）：bug对软件的影响有多大
urgent：造成系统死机、重启、崩溃的缺陷
very high：非常严重的缺陷
high：大的缺陷
medium：中等程度的缺陷
low：小的缺陷

⑩缺陷的优先级（priority）
测试人员希望该缺陷程序员在什么时间或者在哪个版本中解决
urgent：立刻修改（影响开发或测试的进度）
veryhigh：本版本修改（一个软件开发过程可能就含有多个版本，比如一个星期就是一个版本）
high：下版本修改
medium：产品发布前修改
low：允许在产品发布后存在的软件缺陷

测试用例

测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

每个具体测试用例都将包括下列详细信息：版本号、模块名称、用例编号、用例名称、用例级别、预知条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。