软件测试的基本概念

一、什么是软件产品？
大多数人认为，软件产品仅仅是从互联网上下载或者从光盘上安装到计算机上的程序。
软件就是从存储设备安装到计算机或终端设备的应用程序
实际上许多“藏在背后”的东西最容易被遗忘和忽视。作为软件测试员，要记得所有这些都是可能含有缺陷的，这就是我们要测试的对象
二、软件产品的构成
需求、功能、设计、界面、文本、说明、按钮、代码
三、软件研发中的过程文件
用户需求 产品需求 需求规格 项目计划 版本计划 技术选型报告 竞争对手报告 同行评审 概要设计 详细设计 测试方案 测试用例 测试计划 缺陷跟踪单 测试报告 操作文档
四、软件开发过程
软件产品从最初构思到公开发行的过程，称为软件开发过程。
开发过程有不同的方法，没有最好的模型
最常见的有四种开发模型：
1 瀑布模型
2 V模型
3 双V模型（W）
4 敏捷模型
开发过程中最常见的——瀑布模型
是一种线性的，顺序的软件开发模型
上一阶段的变换结果就是下一阶段的变换输入，相邻两个阶段具有因果关系，紧密相连
瀑布模型可变形为V模型、双V（W）模型
瀑布模型允许步骤回溯、步骤交叉
测试贯穿全过程，以减少缺陷修复成本，减低项目的进度风险
瀑布模型的特点：
1 线性化的结构
2 各阶段的里程碑特征
3 基于文档的驱动
4 严格的阶段评审机制
优点：
提供了软件开发的基础框架，比靠个人技艺开发好
有利于大型软件开发过程的人员的组织和管理
有利于开发方法和工具的使用
提高了软件质量和效率
缺点：
初始阶段就提出所有的需求，导致软件开发的生命周期很长，用户和项目负责人需要很长一段时间才能拿到需求版本，若进行修改，将会蒙受损失

V模型是瀑布模型的一种进阶
也是软件开发模型中的一个重要的模型，由于结构像V，所以称为V模型
通过开发和测试同时进行的方式爱缩短软件研发周期，提高软件开发效率
单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候测试人员就开始写测试用例了
集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法时，就把集成测试用例根据概要设计中的模块功能及接口等实现方法编写出来，以备以后做集成测试的时候可以直接引用
系统测试时根据需求分析来的 在系统分析员作系统分析，编写需求说明书的时候把最后能实现系统功能的各种测试用例写出来，为做最后系统测试做准备
验收测试与用户需求对应，是非设计流程
V模型仅仅是把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析，系统设计的验证，需求满足情况一直到后期才被验证
解决的思路：
当一个软件开发的时候，研发人员和测试人员需要同时工作，测试子啊软件做需求分析的同时就会有测试用例的跟踪，遮掩可以尽快找出程序的错误和需求p偏离，从而更高效的提高程序质量，最大可能减少成本，同时满足用户的实际软件需求。

双V模型——V模型的进阶
相对于V模型，W模型增加了软件开发各个阶段中同步进行的验证和确认活动
W模型强调：吃伴随整个软件开发周期，而且测试的对象不仅仅是程序、需求、设计等，开发输出的文档同样也要测试（这里针对设计文档，一般可划分为需求设计文档、概要设计文档、详细设计文档和代码文档），也即是说，测试和开发是同步进行的。
优点：
1 测试活动与软件开发同步进行
2 测试的对象不仅仅是程序，还有需求和设计
3 尽早发现软件缺陷可减低修复软件开发的成本

五、软件的生命周期
软件的生命周期又被叫做软件生存周期或系统开发生命周期，是软件的产生直到报废的过程。
周期内有问题 定义、可行性分析、总体描述、系统设计、编码、调试和测试验收与运行、维护和升级到废弃等阶段，这种按时间分过程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，没哥哥阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件质量。
生命周期的每一个周期都有确定的任务，并产生一定规格的文档（资料），提交给下一个周期作为继续工作的依据

六、软件测试的流程
1 需求分析
2 测试计划
3 测试方案
4 测试用例
5 测试执行
6 测试报告

七、软件项目成员
项目经理——Progran Manager
驱动整个项目的运转，负责制定计划，安排人员，管理进度，协调团队，进行重大决策
架构师/系统工程师（全栈工程师）
技术专家，经验丰富，负责整个系统的体系架构的设计以及关键模块的设计
产品经理
负责产品的设计，包括功能，性能，界面–UI，业务流等
程序员/开发人员
设计、编写软件，并修复软件中的缺陷
测试工程师
负责找出软件产品存在的问题并报告
运维工程师
主要是在正式环境对软件系统进行后期的跟踪和维护
资料工程师
负责编写软件产品附带的文件和联机帮助文档
配置管理员
负责管理程序员写的代码和资料工程师写的文档资料，并组合成一个软件包
QA
质量监管人员

软件测试概念
1 软件测试起源
2 软件测试的经典定义是在规定的条件内对程序进行操作，发现其中存在的错误，并对软件质量进行评估
3 软件测试范围是对软件形成的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试
4 软件测试的重要性：60%以上的软件错误并不是程序错误，而是对需求分析和设计的错误，因此做好软件需求和设计阶段的测试工作就是非常重要的

软件测试的目的
测试不仅仅是为了发现软件的缺陷和错误（bug），也是对软件质量进行度量和评估，以提高软件的质量
1 测试是程序的执行过程，目的在于发现错误
2 一个好的测试用例在于能发现至今未发现的错误
3 一个成功的测试是在于发现了至今未发现的错误的测试

软件测试质量（ISO）
软件测试质量就是 ”软甲明确的和隐含的定义与需求相符的程度“
明确的需求是：
软件符合明确叙述的功能和性能的需求、文档中明确描述的开发标准
隐含的需求是：
所有专业开发的软件都要具有的隐含特征的程度

软件测试的原则
1 所有的软件测试都应该符合用户的需求
2 应当把 “尽早的和不断的测试”作为测试人员的座右铭
3 完全测试是不可能的，测试需要终止
4 充分注意测试中的群集现象
5 测试无法显示软件潜在的缺陷
6 程序员应避免检查自己的程序
7 尽量避免测试的随意性

软件测试对象
1 根据软件的定义，软件包括程序、数据、文档，所以软件测试并不仅仅是程序测试。软件测试贯穿在整个软件生命周期中
2 由于在整个软件生命周期中，各个阶段有不同的测试对象，形成了不同的开发阶段的不同类型的测试。需求分析、概要设计、详细设计以及程序编码等各阶段产生的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都是作为 “软件测试”的对象。

软件测试分类
1 按照开发阶段划分软件测试：
单元测试、集成测试、系统测试、验收测试
2 按照测试实施组织划分软件测试：
开发方测试、用户测试（Beta测试）、第三方测试
3 按照测试技术划分：
白盒测试、黑盒测试、灰盒测试
软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件的生命周期。

软件测试风险
1 软件测试中的软件风险分析是根据预测软件将出现的风险，制定软件测试计划并排列优先等级，风险分析是对软件中潜在的问题进行识别、评估和评价的过程。
2 风险也包括进度风险、质量风险、人员风险、变更风险、成本风险等。

优秀的软件测试工程师所具备的技能：
1 计算机相关知识，能够熟练使用常用的管理工具
2 开发语言：C，C++，Java，JavaScript，VBScript，Shell。
3 数据库：SQL，Server，Oracle，MySQL等数据库知识
4 操作系统：Windows 2003以及2008，UNIX，Linux，MAC，Solaris等
5 网络基本知识，能够独立完成测试环境的搭建
6 软件基础知识：软件工程，软件生命周期，测试理论和测试方法有较深的理解
7 软件测试技术、方法、流程、测试文档编写，能独立设计和执行测试用例，提交完整的缺陷报告单，编写测试报告
8 测试工具，能够熟练使用至少一种功能性能自动化测试工具
9 质量管理知识，如CMM，CMMI以及ISO 9001等

软件测试工程师的职责
1 配置测试环境
2 执行软件测试
3 报告软件缺陷
4 更新缺陷报告内容
5 验证修正的缺陷
6 报告测试状态
7 完成测试相关的其它任务

测试划分标准
按阶段（等级）划分
1 单元测试
2 集成测试
3 系统测试
4 验收测试
单元测试
什么是单元测试？
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。

对于单元测试中单元的含义，一般来说，要结合实际情况来判定其具体含义，如C语言中单元是指一个函数，Java里单元是指一个类，图形化的软件中可以指一个窗口或一个菜单等。

总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

单元测试的内容：
1 入口和出口函数
2 输入和输出信息
3 错误处理信息
4 部分边界值测试

集成测试
什么是集成测试？
集成测试，也叫组装测试或联合测试。

集成测试是在单元测试的基础上，测试子啊将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各个部分工作是否达到或实现相应技术指标及要求的活动。

实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。

集成测试实施方案
1 自顶向下测试
从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来
2 自底向上测试
从程序模块结构最底层的模块开始组装和测试
3 核心系统测试
先对核心软件部分进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。
4 高频集成测试
同步于软件开发过程，每个一段时间对开发团队的现有代码进行一次集成测试。

集成测试的目的
集成测试的目标是按照设计要求使用那些通过单元测试的构件来构造程序结构。单个模块具有高质量单不足以保证整个系统的质量。有许多隐蔽的失效是高质量模块间发生非预期交互而产生的。以下两种技术用于集成测试：
1 功能性测试：使用黑盒测试技术针对被测模块的接口规格说明进行测试。
2 非功能性测试：对模块的性能或可靠性进行测试。

集成测试完成的标准
1 成功的执行了测试计划中规定的所有集成测试
2 修正了所发现的错误
3 测试结果通过了专门小组的评审
集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。

系统测试
什么是系统测试？
系统测试（System Testing）
将已经确认好的软件、计算机硬件、外设、网络等其它元素结合在一起，进行信息系统的各种组装测试和确认测试
系统测试是针对整个产品系统进行的测试
目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或矛盾的地方，从而提出更加完善的方案
系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体说明书的黑盒测试，应覆盖系统所有联合的部件。
对象不仅仅包括需测试的软件，还要包括软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。

系统测试范围
功能、性能、界面、强度、容量、安全性、配置、安装、卸载、数据库等

常见系统测试后期工作
（1）恢复测试
恢复测试作为一种系统测试，主要关注导致软件运行失败的各种条件。并验证其恢复过程能否正确执行。咋特定情况下，系统需具备容错能力。另外，系统失效必须在规定时间段内被更正，否则将会导致严重的经济损失。
（2）安全测试
安全测试用来验证系统内部的保护机制，以防止非法侵入。在安全测试中，测试人员扮演试图侵入系统的角色，采用各种办法试图突破防线。因此
系统安全设计的准则是想方设法使侵入系统所需的代价更加昂贵。
（3）压力测试
压力测试是指在正常资源下使用异常的访问量、频率或数据来执行系统。在压力测试中可执行一下测试
1.如果平均中断数量是每秒一到两次，那么设计特殊的测试用例产生每秒十次中断。
2.输入数据增加一个量级，确定输入功能将如何响应。
3.在虚拟操作系统下，产生需要最大内存量或其他资源的测试用例，或产生需要过量磁盘存储的数据。

验收测试
什么是验收测试？
它是一项确定产品是否满足合同或用户所规定的测试。
主要确认软件是否按合同要求进行工作，即是否满足软件规格说明书中的要求。
验收测试分类
1.非正式的验收测试
alpha测试（阿尔法）
软件开发公司组织内部人员模拟你各类用户行为对即将上市的产品进行测试。
beta测试（贝塔）
软件开发公司组织各方面的典型客户子啊日常工作中实际使用，并要求用户报告异常情况，提出改进意见，然后公司再进行完善。
2.正式的验收测试
有正规的测试过程，需要制定测试计划、定义测试方案，选择测试用例，进行测试，结果提交。着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其它界面。

按是否运行程序划分
静态测试
不运行被测试的软件，只是静态的检查代码、界面或者文档

实际运行被测试的软件，输入相应的测试数据，检查实际的输出结果是否和预期结果相一致的过程。

按技术含量划分
1、黑盒测试
把软件看成一个盒子，不管内部逻辑和内部特性，只依据规格说明书检查程序的功能是否符合功能说明
2、白盒测试
又称为结构测试。着重于程序内部结构和算法，不关心功能和性能指标。
3、灰盒测试
介于白盒和黑盒测试之间，基于程序运行时刻的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序把那个采集程序路径执行信息和外部用户接口结果的测试技术。

其它划分
冒烟测试（BVT测试（Build Verification Test））
冒烟测试的对象是每一个新编译需要正式测试的版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。
回归测试
对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例。防止出现 “以前应用没有的问题现在出现问题了“
随机测试（猴子测试、自由测试）
测试数据时随机产生的，在测试用例之外，只能作为一个测试的补充。

-测试计划的定义-

描述了要进行的测试活动范围、方法、资源和进度的文档，是对整个信息系统应用软件组装测试和确认测试。
它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。

为什么要编写测试用例？
（1）领导能够根据测试计划做宏观调控，进行相应资源配置等
（2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作
（3）便于其他人员了解测试人员的工作内容，进行有关配合工作

什么时间开始编写测试计划
测试需求分析和总体测试计划书/测试需求分析后详细测试计划书
由具有丰富经验的项目测试负责人来编写测试计划

测试计划的作用
（1）作为测试计划的结果，让相关人员和开发评审
（2）存储计划执行的细节，让测试人员进行同行评审
（3）存储计划进度表、测试环境等更多的信息

测试计划的外部作用是为顾客提供一种信心，通常向顾客交代有关测试过程、人员的技能、资源、使用工具等信息

为测试过程提供指导
——测试目标
——测试内容
——测试方法
——测试时间周期
改善测试任务与测试过程的关系
提高测试的组织、规划和管理能力

如何制定测试计划
认真做好测试资料的搜集整理工作
明确测试的目标，增强测试计划的实用性
坚持 “5W1H”规则，明确内容与过程
采用评审和更新机制，保证吃素计划满足实际需求
why：为什么要进行这些测试
what：测试哪些方面，不同阶段的工作内容
where：相应的文档、缺陷的存放位置，测试环境等
when：测试不同阶段的起止时间
who：项目有关人员组成，安排哪些测试人员进行测试
how：如何制定测试计划，如何实施

测试计划的内容
1.测试项目简介
2.需要测试的特征
3.不需要测试的特征
4.测试的方法（测试人员、测试工具、测试流程）
5.测试环境（软件、硬件、网络）
6.测试开始条件和结束条件
7.测试者的任务、培训
8.测试进度与跟踪
9.测试风险与解决
10.本测试计划的审批与变更的方式

测试工具及描述
Zentao：项目管理/bug管理系统
xshell/xftp：Linux访问工具
selenium：自动化测试
LoadRuner：性能测试
SVN：版本控制

测试环境（一）
从软件的编码、测试到用户实际使用，存在着：开发环境、测试环境、用户环境
“环境”，是指被测试软件所运行的软件环境和硬件环境
测试环境是测试人员为进行软件测试而搭建的环境

测试环境（二）
软件、硬件环境详情：
PC：客户端（4）
server：Linux服务端（1）
Linux：操作系统（1）
MySQL：数据库（1）
Apache：服务（1）
PHP：编程语言（1）
浏览器：IE（多版本）、FireFox、Chrome（1）

测试开始/结束条件
1.启动条件
软件测试时在项目启动、需求分析开始时随之启动的
2.结束条件
需求覆盖率、用例执行率、缺陷遗留率、达到预定质量目标。
（备注：每个公司的流程不同，制定的质量标准也不一定一样，但大同小异）

测试进度与跟踪

测试风险与解决（一）
流程
测试风险与解决（二）

测试方案的目的
软件测试方案的作用非常类似于产品设计说明（文档），开发工程师工具产品功能需求和设计说明来编码实现功能，
二测试工程师需要基于产品功能需求和测试方案来设计和执行测试用例，同时也要参考产品设计说明文档，所以测试方案目的是：在方向上明确要测什么、怎么测，以及达到什么样质量标准。
软件测试方案有助于软件项目成员理解和执行测试过程中的各项活动，同时测试方案也有助于测试活动的管理。

测试计划于方案的区别
定义不同：测试计划是对测试过程的组织、资源、原则等进行规定和约束；二测试方案则是描述所测软件的测试特性、测试方法、测试用例设计、测试代码设计、测试环境规划以及测试工具设计和选择的一种策略与方法。
层次不同：测试计划是管理层面的，从组织管理的角度规划测试活动；而吃素方案是技术层面的，从技术的角度规划测试活动。
总而言之，测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，而吃素方案明确“怎么做”。

如何编写出有效的测试方案
1.测试需求分析
2.测试策略
3.测试资源
4.测试进度计划
5.风险管理
6.质量

测试需求分析
测试需求分析及时把产品需求和对用户的理解（用户体验）和转化、分解成测试功能点，产品需求是我们测试需求主要输入，但那不是全部，我们还需要仔细分析产品设计说明，可以产出更多可测试的功能点（这些功能点往往没有包含在产品需求中）。还要加入度性能。安全。接口和回归测试范围分析。测试需求是确定测试进度计划和资源的主要依据。
评估风险并确定测试优先级

制定测试策略
一个好的测试策略应该包括下列内容：
实施的测试类型和测试目标
实施测试的阶段
技术
用于评估测试结果和测试是否完成的评测和标准
对测试策略所述的测试工作存在影响的特殊事项

测试资源
一般情况下，团队同时有多个项目，测试PM需要根据项目的优先级来确定每个项目的测试资源，主要包括人力和设备机器

测试进度计划
根据测试需求和策略，结合项目优先级和测试资源情况，评估测试进度计划，一般情况里，测试资源越充分，测试进度越乐观，但是并非绝对，有时候一些软件BUGhi阻塞测试进度，这也是项目风险的一部分。

风险管理
在测试执行开始之前，对可能的风险进行风险和识别很重要，可以提前进行预防和采取应对措施，所以项目过程中，我们需要定期评估测试进度情况，提前进行风险预警。

质量
质量是指测试项目需要达到的标准，各个公司和项目都会有相应的标准要求，由于质量标准可以是公司内多数项目共识，所以也可以不必在测试方案中列出。对于测试项目来说，比较常见的是已测试用例执行率、通过率和未关闭BUG级别/数量来设定质量标准。

测试类型
功能测试
界面测试
安全测试
本地/国际化测试
数据库测试
可靠性测试
集成测试
兼容性测试
自动化测试
性能测试
回归测试

什么是测试用例？
1.测试用例是一份测试文档，描述输入、动作、一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作
2.测试用例是软件测试团队的主要工作成果之一
3.测试用例的质量与写该用例的测试人员的 水平关系极大。
4.执行测试用例：当一个软件版本被测试时，测试人员会使用一整套的测试用例（或者筛选其中一部分），将这些用例逐个在被测的软件上执行，并判断其结果是否和预期相符，并以此评价软件版本的质量。

测试用例实例（一）

测试用例实例（二）

测试用例的主要构成要素
用例编号
用例标题
用例级别
预置条件
操作步骤
预期结果
实际结果
测试人员

用例编号
测试用例（Test Case）是将软件吃素的行为活动作为一个测试用例。科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一；不同类别的软件测试用例是不同的，不同于诸如系统、工具、控制、游戏软件。
测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障，管理软件的用户需求更加不同的趋势。
格式：项目简称+模块简称+顺序编号
如：QQ-登录-001

用例标题（名称）
就像人的名字一样，给所写的用例起一个名称，以便执行用例，书写bug，其它人参考时容易理解。另外，用例名称尽量不要重复。
一般格式：子啊程序的某个位置执行什么操作能够（不能够）实现什么结果
如：在ERP用户管理系统搜索框中输入正确的名字可以查找到对应的用户信息

用例级别
测试用例级别，根据功能大小，以及对系统的影响，划分等级，以便于应对风险。
根据公司规则不同，通常测试级别包含：
1级，影响很大，阻碍性的、流程性的用例。如登录按钮不可用
2级，大的功能点，已经会阻碍少部分的用例执行。
3级，小的功能点
4级，小的UI问题

预置条件
顾名思义，就是在软件中执行操作验证用户的需求之前，需要准备的前提条件。

操作步骤
为了验证某个功能点，对其进行的具体操作行为步骤的描述，要求详细具体，但不要冗余。

预期结果
1.测试用例预期的结果，用例执行后要达到什么结果。
2.根据功能点和需求点的不同，期望结果也不同。可以对测试用例名称进行扩展。

实际结果
既是根据测试用例中的步骤描述一步步执行测试后得到的最终结果。
实际结果与预期结果相悖，说明软件出现 bug
测试人员：执行该用例的测试工程师

测试用例的作用和价值
1 指导测试的实施
测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。
根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

2 规划测试数据的准备
在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

3 编写测试脚本的设计规格说明书
为提高测试效率，软件测试已大力发展自动测试。

自动化测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4 评估测试结果的质量基准
完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。

例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

5 分析缺陷的标准
通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。

漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

设计测试用例基本原则

1 用语简洁清晰，但不能过于简单
2 用语无歧义，尽量少用过长的句子
3 用例的各个基本要素要齐备，不能缺失
4 用例的步骤应该足够详细，操作应该明确
5 容易被其它测试工程师读懂，并能顺利执行
6 用例有自己的颗粒度，可粗可细。

用例的颗粒度
1.颗粒度，指的是粗细程度。粒度大，就是说一个用例所覆盖的关注内容比较多，反之同理。
2.用例的粒度大，则总的用例数就少，用例看起来也简洁。
3.用例的粒度小，则单条用例关注的测试点很集中，不容易遗漏，并且执行需要的时间比较好估计。

掌握一个度
粒度该大该小，如何把握，其实不难。一是看你这个用例写出来会不会测试好几个小时都没能测试完。二是看你这个用例会不会被另一个人执行的时候只执行了涵盖了一部分的测试点而遗漏了另一部分。

用例的整合
整合测试用例
用例写作的技术含量体现，并不是单条用例本身，而是针对整个特性，写出的整套的测试用例，是否有效地覆盖了应该验证的各个测试点。
优秀的测试用例写作者，具有的是灵活发散的思维，和全面的视野，写出的用例套能保证涉及软件运行时的各个关键要点，在执行完这样的用例并且没有发现问题，我们就可以对软件的质量下一个良好的结论

更新用例
1.测试用例并不可能一开始就写得很完美，可能也有写错的，可能也有遗漏的测试点
2.随着软件的版本不断更新，软件本身的需求和规格以及设计都可能在不断地变更。
3.随着测试的不断开展，测试人员对产品的理解逐渐加深。

基于上述，就使得我们完全有理由在测试用例执行的过程中，同时不断地优化我们的测试用例，使得用例的质量越来越高。

执行测试用例
根据已有的测试用例，按照里面的步骤一步一步的执行，查看预期结果与实际结果是否一致

测试执行过程注意事项
搭建测试环境事项
注意前提条件和特殊说明
测试用例要全部执行
不要忽视任何偶然现象
加强测试过程记录
详细记录预期与实际的不一致
提交缺陷时与开发的关系处理
提交一份优秀的问题报告单
及时更新测试用例

搭建测试环境事项
测试用例执行过程前，成功搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份被测试软件产品的详细安装指导书。

如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。

注意前提条件和特殊说明
有些测试软件是有顺序性的，那么它的测试用例就会有一些执行前提或特殊说明。
比如要测试某个软件的登陆功能，那么测试前必须创建用户，并为用户分配一定的权限等。如果前提条件和特殊说明没有注意，会导致测试用例的无法执行

测试用例要执行全部
因为编写测试用例时，它考虑了测试覆盖率的问题，每条测试用例都对应一个功能点，如果少执行一条，就会有一个功能点没有测试到。

执行测试前要认为待测试软件的每条功能点都是未实现的，每个功能点我们都要测试一遍，才能保证待测试软件能正确满足用户需求

不要忽视任何偶然现象
在执行某条用例时，软件会出错，但是当再次执行时这个错误就不再重现。这种情况，一般大家就会认为是偶然现象，就会忽略过去。其实，这种错误才是隐藏最深的，最难发现的错误。

遇到这种情况时，要仔细分析这种情况，不要忽视任何小的细节，多测试几次，尽可能准确的找出问题的原因。

加强测试过程的记录
测试执行过程中，一定要加强测试过程记录。执行过的用例做好对应标记，发现了缺陷应及时提交确认。

一般软件产品提供 了日志功能，比如有软件运行日志、用户操作日志。如果发现比较复杂难定位的问题，一定要在测试用例执行后记录相关的日志文件，作为测试过程记录，这样开发人员可以通过这 些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

提交缺陷时与开发人员的关系处理
测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力

及时更新测试用例
测试执行过程中，应该注意及时更新测试用例：
1.往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充

2.有些测试用例在具体 的执行过程中根本无法操作，这时候应该删除这部分用例

3.若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。

总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

软件的定义
1 软件未实现需求和规格要求的功能

2 软件出现了需求和规格指明不该出现的错误

3 软件实现了需求和规格未提及的功能

4 软件未实现需求和规格未明确提及但应该实现的内容

5 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。

6 测试用例执行中发现的与预期结果不符的现象

 缺陷又名为BUG（臭虫）

凡是与用户需求不符的执行结果都被称为bug。

缺陷产生的原因

缺陷修复成本

缺陷的分布特征
集结（二八定律）

缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。

缺陷的抗药性
测试进行得越多，新缺陷就越难被发现
因为之前一直使用同样的测试思路，同样的一套测试用例，没有新的突破
某些缺陷天然地只有在很特殊或者很极端的情况下才会被触发

并非所有的缺陷都需要被修复
有一些原因，使得有些缺陷我们不修复：
1.没有足够的时间
2.不算真正的软件缺陷
3.修复的风险过大
4.不值得修复

缺陷的生命周期
当一个缺陷被发现了之后：

   1.  测试工程师填写《缺陷跟踪单》，提交测试经理审核 
    2.  测试经理作出初步判断，将问题单转项目经理审核
    3.  项目经理确认问题单,转给开发人员定位问题
    4.  开发人员定位错误后修复缺陷转给 项目经理确认
    5.  项目经理确认完转给转给测试经理确认并组织测试
    6.  测试人员对该修复进行验证，确认是否正确修复，确认是否有引发新问题，是否影响了原有正常的功能

缺陷的跟踪流程

缺陷的等级
1.致命：软件无法运行，或者软件的主要功能丧失，或者很大可能性会造成严重不良后果

2.严重：软件的次要功能丧失，或者主要功能在一些特定情况下会出错 ，比如金额计算等

3.一般：软件在某些情况下会出错，但是造成的后果影响不大

4.轻微：在某些情况下会出错，但是造成的后果影响很小

附带上所有你认为有价值的信息
一个好的缺陷单，是你提交之后就再也没人联系你，然后过了一段时间已经被完美地修复，转回到你手上进行验证测试这样的一个单子

要做到这样，你应该提供足够的信息，使得开发人员既能够明确如何重现故障现象，又有足够的信息定位到问题的根源

除了书写良好的重现步骤，你还可以考虑附上打印日志，抓图，网络抓包，等等。

合理地利用各种手段强调关键信息
假如你的缺陷跟踪单支持字体颜色

关键词强调

特殊标记

测试结果分析
测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。

因为通过对问题单的分析、总结不仅能发现不同人提交问题的类别与差异，还能发现自身思维的局限性，避免下轮测试进入自我盲区。

测试总结
每做完一个项目都应该进行总结回顾，总结个人成长经验，归纳不足点，整理方法并与其他测试人员进行交流讨论，分享，也是对工作进行的一个理性的分析与思考。

最后

以上就是称心画笔为你收集整理的软件测试的基本概念的全部内容，希望文章能够帮你解决软件测试的基本概念所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。