测试流程的引入
前言:
在软件系统的开发生命周期,软件测试是极其重要的一个环节,它直接关系到软件产品的最终质量。
软件系统测试/软件质量保证来源于传统行业,它的发展一共经历了三个阶段:
1) 事后检查
2) 事先预防+事后检查
3) 全面控制
就整个软件系统产品测试流程而言,虽然有很多既成模式可以引用,但一定要结合本公司产品,公司文化,员工反映等诸多因素进行剪裁,要避免生搬硬套。我个人的观点是:测试流程主要原则是简单适用。(The simple is the best!)为此,我建议如下流程。
一、软件系统开发生命周期
阶段名称
(按发生时间顺序)
|
所属部门
|
流程的下一部门
| |
市场需求分析(MRD)
|
市场部
|
| |
产品设计文档(PRD)
|
研发部
|
| |
产品需求说明书(SPEC)
|
研发部
|
| |
编码(Coding)
|
设计测试用例
|
研发部,测试部
|
|
编码结束(Code Complete)
|
研发部
|
| |
黑盒测试开始
(Black box testing)
|
测试部
@
|
研发部
@
| |
代码修复
(Code Fix)
|
研发部
@
|
测试部
@
| |
产品安装调试
(Hosting )
|
安装部
|
研发部
@
| |
用户反馈(Tickets)
|
市场部
|
测试部@
|
二、软件开发生命周期图表
三、软件测试的流程
四、一个Bug
的生命周期
五、测试Case
模板
测试case的执行应该是在一定的测试环境的情况下进行的,测试环境要真实,正确。所以执行测试的case的第一步首先要是测试环境的建立。我建议把所测试功能相关的测试cases放在一起,组成一个cases集,便于管理与维护。
Case
编号
|
|
Case
名称
|
有意义的名称,如case
验证对象是谁,验证标准是什么?
|
Case
步骤
|
前提:测试环境是正确的
1)
2)
…
|
验证标准
|
在上面的Case
步骤中,软件应该表现的行为及输出(注:标准应该是可测量的)
|
例子:
Case
编号
|
1001
|
Case
名称
|
测试MD1200,
引脚7
在不同电源下的状态
|
Case
步骤
|
前提条件:MD1200
处于连机状态,测试软件启动侦听
1)
分别将引线的电压调节到5V,10V,15v
2)
查看测试软件的测试状态显示
…
|
验证标准
|
应该输出”***”
|
六、Bug
模板
通常bug要与测试cases相联系,因为只有从测试cases中你才能得到最为正确的“验证标准”。同时,我们也应该鼓励测试人员进行相应的ad-hoc测试,经验表明,这种测试也能发现很多严重的问题。但如果ad-hoc 测试发现了很多bug,从另一个方面讲,测试cases也需要加强了。
Bug
编号
|
Xxxx, numeric
|
Bug
名称
|
有意义的名称,应该能望文生义
|
Bug
状态
|
Open/Fixed/Close/On Hold/RFE…
|
Bug
级别
|
对bug
性质的一种描述,其目的是便于开发对bugs
的处理有轻重缓急,也有助于产品经理从总体上对产品的质量有所了解。通常有严重的(Critical)
,重要的(Major),
次要的(Minor
)之分。
|
步骤
|
1)
2)
…
|
期望结果
|
请参考相对应case
中的验证标准
|
实际结果
|
记录下实际发生的结果,最好能找出bug
产生的真正原因,便于开发fix
|
测试人员
|
XXX
|
开发人员
|
XXX
|
主要术语:
测试用例(Test Cases):所谓的测试用例就是将软件测试的行为活动,做一个科学化的组
织归纳。
Bug: 即产品缺陷,凡是与产品需求说明书不相符的产品功能,都应该算是产品缺陷。当然与产品的兼容性,一致性及与业界标准不符的也应该算是软件缺陷。