测试流程的引入

 

测试流程的引入

前言:

在软件系统的开发生命周期，软件测试是极其重要的一个环节，它直接关系到软件产品的最终质量。

软件系统测试/软件质量保证来源于传统行业，它的发展一共经历了三个阶段：

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: 即产品缺陷，凡是与产品需求说明书不相符的产品功能，都应该算是产品缺陷。当然与产品的兼容性，一致性及与业界标准不符的也应该算是软件缺陷。