软件测试基本流程与要求
-
软件测试基本流程与要求（提纲）
1
目标
<
/p>
制定完整且具体的测试路线和流程，
为快速、
高效和高质量的软件测试提供基础流程框
架。
最终目标是实现软件测试规范化，标准化。
2
测试流程说明
需求分析
评审、沟通
是
编写测试计划
否
评审、完善
是
提取测试需求
否
设计测试用例
否
评审
、完善
是
搭建测试环境
冒烟测试
执行测试用例
完善测试用例
Bug
跟踪处理
测试报告输出
3
测试需求分析
测试需求是整个测试过
程的基础；确定测试对象以及测试工作的范围和作
用。用来确定整个测试工作（如安排时
间表、测试设计等）并作为测试覆盖的基
础。而且被确定的测试需求项必须是可核实的。
即，它们必须有一个可观察、可
评测的结果。
无法核实的需求不
是测试需求。
所以我现在的理解是测试需求是一
个比较大的概念
，
它是在整个测试计划文档中体现出来的，
不是类似的一个用例
或者其他
.
·测试需求是制订测试计
划的基本依据，
确定了测试需求能够为测试计划提供客
观依据；
·测试需求是设计测试用例的指导，
确定了要测什么、
测哪些方面后才能有针对
性的设计测试用例
；
·测试需求是计算测试覆盖的分母，没有测试需求就无法
有效地进行测试覆盖；
3.1
测试方法与规范
3.1.1
测试方法
随着软件技术发展，
项目类型越来越多样化。
根据项目类型应选用针对性强
的测试方法，
合适的测试方法可以让我们事半功倍。
以
下是针对目前项目工程可
以参考的测试方法：
•
β
测试
（<
/p>
beta
测试）
--
非程序员、测试人员
β
测试，英文是
Beta testi
ng
。又称
Beta
测试，用户验收测
试（
UAT
）。
β
测试是
软件的多个用户在一个或多个用户的实际使用环境下进行的测
试。开发者通常不在测试现
场，
Beta
测试不能由程序员或测试员完成。
当开发和测试根本完成时所做的测试，
而最终的错
误和问题需要在最终发行
前找到。
这种测试一般由最终用户或其
他人员完成，
不能由程序员或测试员完成。
•
α
测试（
Alpha
测试）
--
非程序员、测试人员
α
测试，英文是
Alpha test
ing
。又称
Alpha
测试
.
Alpha
测试是由一个用户在开发环境下进行的测试，
也可以是公司内部
的用
户在模拟实际操作环境下进行的受控测试，
Alpha
测试不能由该系统的程序员或
测试员完成。
在系统开发接近完成时对应用系统的测试
;
测试后，仍然会有少量的设计变
更。这种测试一般由最终用户或其他人员来完成，不
能由程序员或测试员完成。
•
兼容性测试
--
测试人员
兼容性测试是指测试软
件是否可以成功移植到指定的硬件或者软件环境中，
例如在
B/
S
项目中各个不同浏览器之间的测试。
•
用户界面测试
-UI
测试
--
测试人员
用户界面测试，英文是
User interface tes
ting
。又称
UI
测试。
用户界面，英文是
User interface
。是指软件中的可见外观及其底层与用
户交互的部分（菜单、对话框、窗口和
其它控件）。
用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，
页面
是否美观，文字，图
片组合是否完美，操作是否友好等等。
UI
< br>测试的目标
是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览
功能。
确
保用户界面符合公司或行业的标准。
< br>包括用户友好性、
人性化、
易操作性
测试。
用户界面测试用户分析软件用户界面的设计是否合乎用户期望
或要求。
它常常包括菜单，
对话框及对
话框上所有按钮，
文字，
出错提示，<
/p>
帮助信息
(Menu
和
Help content)
等方面
的测试。比如，测试
Microsoft Excel
中插入符
号功能
所用的对话框的大小，
所有按钮是否对齐，
字符串字体大小，
出错信息内容和字
体大小，工具栏
位置
/
图标等等。
•
冒烟测试
--
版本编译者
冒烟测试，英文是
Smoke
testing
。
冒烟测试的名称可以理解为该种测试耗时短，
仅用一袋烟功夫足够了。
也有
人认为是形象地类比新电
路板功基本功能检查。
任何新电路板焊好后，
先通电检
查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，
目的是确认
软
件基本功能正常，
可以进行后续的正式测试工作。
冒烟测试的执行者是版本编译
人员。
•
随机测试
--
测试人员
随机测试，英文是
Ad hoc
testing
。
随机测试没有书面测试用例、
记录期
望结果、
检查列表、
脚本或指令的测试。
主要是根据测试者的经验对软件进行功能和性能抽查。
随机测试是根据测试说明
书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
< br>
随机测试主要是对被测软件的一些重要功能进行复测，
也包括测试那些当前
的测试样例
(TestCase)
没有覆盖到的部分。另外，对于软件更新和新增加的功
能要重点测试
。
重点对一些特殊点情况点、
特殊的使用环境、
并发性、
进行检查。
尤其
<
/p>
对以前测试发现的重大
Bug
，进行再次
测试，可以结合回归测试
(Regressive
testing)
一起进行。
•
黑盒测试（功能测试）
--
测试人员
黑盒测试，英文是
Black
Box Testing
。又称功能测试或者数据驱动测试。
黑盒测试是根据软件的规格对软件
进行的测试，
这类测试不考虑软件内部的
运作原理，因此软件对
用户来说就像一个黑盒子。
软件测试人员以用户的角度，<
/p>
通过各种输入和观察软件的各种输出结果来发
现软件存在的缺陷，
而不关心程序具体如何实现的一种软件测试方法。
•
性能测试
性能测试，英文是
Performance
Testing
。
性能测试是在交替进行负荷和强迫测试时常用的术语。理想的
“性能测
试”(和其他类型的测试
)
应
在需求文档或质量保证、
测试计划中定义。
性能测试
一般包括负载测试和压力测试。
通常验证软件的性能在正常环境和系统条件下重复使用是否还
能满足
性能指标。
或者执行同样任务时新版本不比旧版本慢。<
/p>
一般还检查系统记忆容量
在运行程序时会不会流失
(memory leak)
。比如，验证程序保存一个巨大的文件
新版本不比旧版本慢。
3.1.2
测试规范
测试规范是根据开发规范而
制定的测试标准，
测试规范也是后期测试用例编
写的重要依据。
因为开发规范因公司而异，
因产品而异，
所以测试规范的标准程
度每个公司都不一样。
从理论到方法到各类流程到各类报告模版，
都属于测试规范的范畴，
当一整
套规范形成之后，可使得测试工作进行更加稳健，所有问题有据可
查。
3.2
软件需求规格说明书
软件需求规格说
明书是软件达到的各项功能的目标。
是测试人员各项工作的依据，
没有
需求就无法判断测试结果是正确的。
3.3
软件设计说明（概要与详细设计）
设
计说明书包含软件的一些框架、
字段、
数据库设计等。
软件设计说明对测试工作开展
有很大影响，
没有
软件设计说明很多问题将无法溯源，
测试准备的前期工作也是根据软件设
计说明来制定的。
3.4
页面原型（
d
emo
< br>）
页面原型是项目人员快速熟悉项目
的最佳路径。
在需求不够明确，
设计说明书不够全面
的情况下，页面原型也是后期测试用例编写思想的重要根据。
4
测试过程设计
明确测试目的，最终达
成目的并验证结果是测试要做的事情。包括：
1.
测试范围：描述本次测试中的测
试范围，如：测试软件功能范围、测试种类等。
2.
简单的描述如何搭建测试平台以及测试的潜在的风险。
3.
项目信息：说明要测试的项目的
相关资料，如：输入输出文档，产品描述，软件主
要功能。
4.
人力资源的分配。
5.
测试需求：笼统说，就是测试中
的所有设计和需求文档。作为本次测试的依据
4.1
测试策略制定
这一阶段在于需求、详细设计、测
试计划完成之后，主要是本次测试的策略阶段。
很多公司少这个一个阶段，
需要有计划性的分出产品的功能扣出测试的功能点，
现
阶段大多公司都是直接拿着文档就开始做用例设计。
对需求进行分析，列出具体的功能
列表。
（一般根据功能交互文档就能明确出此功
能的大体功能，
一层层的分下去，
一直到没个功能表单。
然后考虑到使用那些测试