软件测试基础知识大全必备
-
1.
软件生命周期
(SDLC)
的六个阶段
1
、问题的定义及规划
此阶段是
软件开发
方与
需求
方共同讨论,主要确定软件的开发目
标及其可
行性。
2
、
需求分析
在确定软件开发可行的情况下,对软件需要实现的
各个功能进行详细分
析。需求分析阶段是一个很重要的阶段,这一阶段做得好,将为整个
软件开发
项目的成功打下良好的基础。
唯一不变的是变化本身。
,同样需求也是在整
< br>个软件开发过程中不断变化和深入的,因此我们必须制定需求变更计划来应付
这种
变化,以保护整个项目的顺利进行。
3
、软件设计
此阶段主要根据需求分析的结果,对整个
软件系统
进行设计,如系统
框架
设计,
数据
库设计
等等。软件
设计一般分为总体设计和详细设计。好的软件设计将为
软件程序
编写打
下良好的基础。
4
、
程序
编码
此阶段是将软件设计的结果转换成
计算机
可运行的
程序代码。在程序编码中必
须要制定统一,符合标准的编写规范。以保证程序的可读性,
易维护性,提高
程序的运行效率。
5
、
软件测试
在软件设计完成后要经过严密的测试,以发现软件
在整个设计过程中存在
的问题并加以纠正。整个测试过程分
单元
测试
、
组装测试
以及
< br>系统测试
三个阶
段进行。测试的方法主要有
白盒测试
和
黑盒测试
两种。
在测试过程中需要建立
详细的测试计划并严格按照测试计划进行测试,以减少测试的随意
性。
6
、运行维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用
后,由于
多方面的原因,软件不能继续适应用户的要求。要延续软件的使用寿
命,就必须对软件进
行维护。软件的维护包括纠错性维护和改进性维护两个方
面。
2
、软件生命周期模型
从概念提出的那一刻开始,软件产品就进入了软件生命周期。
在经历需求、分
析、设计、实现、部署后,软件将被使用并进入维护阶段,直到最后由于
缺少
维护费用而逐渐消亡。这样的一个过程,称为
生命周期模型
(
Life
Cycle
Model
)。
典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。
p>
瀑布模型的特点
(文档是主体)
,很多的问
题在最后才会暴露出来。迭代模型比
瀑布模型问题暴露的要早;快速原型法比瀑布模型直
观。
3.
软件测试概念
< br>广义概念:指软件生存周期中所有的检查、评审和确认工作,其中包括了对分
析、
设计阶段,以及完成开发后维护阶段的各类文档、代码的审查和
确认
狭义概念:识别软件缺陷的过程,即实际结果与预期结果的不一致
4.
软件测试目的
测试的目的就是发现软件中的各种缺陷
测试只能证明软件存在缺陷,不能证明软件不存在缺陷
测试可以使软件中缺陷降低到一定程度,而不是彻底消灭
p>
以较少的用例、时间和人力找出软件中的各种错误和缺陷,以确保软件
的质量
5
.软件测试原则
Good-enough:
一种权衡投入
/
产出比的原则
保证测试的覆盖程度,但穷举测试是不可能的
所有的测试都应追溯到用户需求
越早测试越好,测试过程与开发过程应是相结合的
测试的规模由小而大,从单元测试到系统测试
为了尽可能地发现错误,应该由独立的第三方来测试
不能为了便于测试擅自修改程序
既应该测试软件该做什么也应该测试软件不该做什么
6
.软件测试的的重点
测试用例的设计
–
测试用例的设计是整个软件测试工作的核心
–
测试用例反映对被测对象的质量要
求,决定对测试对象的质量评
估
测试工作的管理
–
尤其是对包含多个子系统的大型软
件系统,其测试工作涉及大量
人力和物力,有效的测试工作管理是保证有效测试工作的必
要前
提
测试环境的建立
–
测试环境应该与实际测试环境一致
7
.黑盒测试
什么是黑盒测试
–
又称功能测试或数据驱动测试,是
针对软件的功能需求
/
实现进行
测试,
通过测试来检测每个功能是否符合需求,不考虑程序内部
的逻辑结构
黑盒测试方法
–
功能划分
–
等价类划分
–
边界值分析
–
因果图
–
错误推测等
8
.什么是白盒测试
–
白盒测试也称结构测试或逻辑驱动
测试,必须知道软件内部工作
过程,通过测试来检测软件内部是否按照需求、设计正常运
行
–
白盒测试的主要方法
–
对应于程序的一些主要结构:语句
、分支、逻辑路径、变量;白
盒测试的主要方法是:
–
语句覆盖方法
–
分支覆盖方法
–
逻辑覆盖方法
9.
什么是动态测试
动态测试需要在开发
/
测试环境或实际运行环境中运行软件,并使用测试用
例去查找软件缺陷;动态测试包括功能确认与接口测试、覆盖率分析、性
能分析、内存分析等
10.
什么是静态测试
静态测试不实际运行软件,主要是对软件的编程格式、结构等方面进行评估
.
静态测试包括代码检查、程序结构分析、代码质量度量等。它可以由人工进
行,也可以借助软件工具自动进行
11.
手工测试和自动测试
a.
手工测试缺点在于测试工作量大,重复多,回归测试难以实现
b.
自动测试利用软件测试工具自动实现全
部或部分测试工作:管理、设计、
执行和报告;节省大量的测试开销,并能够完成一些手
工测试无法实现的测
试
手工完成测试的全部过程无法保证测试的科学性与严密性
:
–
修改的缺陷越多,回归测试越困难
–
没有人能向决策层提供精确的数据
以度量当前的工作进度及工作
效率
–
反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一
–
测试花费的时间越长,测试的严格性也就越低
自动测试将测试人员从反复、烦杂的测试执行中解放出来,用更多的时
间进行测
试设计和结果分析
软件测试不可能完全自动化
不能完成所有手工测试任务
无创造性且灵活性差,不能改进测试的有效性
过程中可能会遇到许多意想不到的问题,特别是当软件不稳定时
测试脚本的维护高
12.
测试流程
需求分析
确认测试计划(说明)
系统测试计划(说明)
概要设计
集成测试计划(说明)
单元测试
集成测试
系统测试
用户验收测试
回归测试
确认测试报告
系统测试报告
系统
< br>/
确认测试
集成测试报告
集成测试
单元测试报告
单元测试
单元测试计划
编码
详细设计
p>
确
定
测
试
要
求
制
定
测
试
计
< br>划
有
修
改
p>
双
方
确
定
测
试
计
划
通
过
< br>制
定
测
试
方
案
安
排
项
目
进
度
p>
培
训
测
试
人
员
建
立
测
试
< br>环
境
编
写
测
试
用
例
测
试
报
p>
告
填
写
客
户
否
p>
执
行
测
试
计
划
未
完
成
p>
检
测
并
在
数
据
库
中
记
录
缺
陷
< br>
完
成
是
回
归
p>
测
试
否
向
用
户
提
交
缺
陷
列
< br>表
开
发
人
员
修
正
错
误
13.
单元测试
完成对最小的软件设计单元
—
模块的验证工作
目标是确保模块被正确地编码
使用过程设计描述作为指南,对重
要的控制路径进行测试以发现模块内
的错误
通常情况下是面向白盒的
对代码风格和规则、程序设计和结
构、业务逻辑等进行静态测试,及早
地发现和解决不易显现的错误
单元测试的内容
–
接口测试
–
内部数据结构
–
全局数据结构
–
边界
–
语句覆盖,错误路径
14.
集成测试
通过测试发现与模块接口有关的问题
目标是把通过了单元测试的模块拿
来,构造一个在设计中所描述的程序
结构
应当避免一次性的集成(除非软件规模很小),而采用增量集成
集成测试主要内容
API
API/
参数组合
15
.系统测试
p>
根据软件需求规范的要求进行系统测试,确认系统满足需求的要求
系统测试人员相当于用户代言人
在需
求分析阶段要确定软件的可测性,保证有效完成系统测试工作
系统测试主要内容
所有功能需求得到满足
所有性能需求得到满足
其他需求(例如安全性、容错性、兼容性等)得到满足
16.
用户验收
/
确
认测试
Alpha
测试
–
是由用户在开发者的场所来进行的
,
Alpha
测试是在一个受控的
环境
中进行的
Beta
测试
–
由软件的最终用户在一个或多个用
户场所来进行的,开发者通常
不在现场,用户记录测试中遇到的问题并报告给开发者
p>