软件测试


网站首页 | 软件测试论坛 | 软件测试培训 | 软件测试博客 | 软件测试杂志 | 软件测试沙龙 | 软件测试下载 | 软件测试顾问
业界新闻 | 软件测试人才 | 软件测试技术 | 软件测试工具 | 行业软件测试 | 软件测试管理 | 软件质量专栏 | 软件开发专栏
当前位置:首页>>软件测试技术>>用例设计>>正文
测试用例的有效维护
文章出处:CSDN博客 作者:朱少民 发布时间:2006-07-05

开发一个软件产品,会发布多个版本,伴随着测试用例(Test case)的不断维护, 使测试用例不断完善并与产品功能、特性(features)的变化保持一致,所以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品,多个版本常常共存,为客户提供服务,这时多个版本的测试用例也是并存的,所以在新建、修改、删除测试用例时要十分小心,并有相应的规则。
根据产品特性和test case一致性,分下面几种情况分别处理:

1. 产品特性没变,只是根据Late Discovery Bug 或 Remedy Ticket 来完善 test case,只有这时候可以修改Test case, 也就意味着当前修改的test case,对目前和以前的版本都有效。

2. 原有产品特性发生了变化,不是new feature, 而是enhanced features(功能增强), 这时候原有的 test case 只对先前版本(如version 1.0、2.0) 有效,而对新的版本(如 version 3.0)无效,这时绝不能修改 test case ,只能增加新的 test case,这一点很重要。原有的 test case 依然对原有版本有效(如version 1.0、2.0)。

3. 原有功能取消了,这时只要在新版本上使之对应的test case置为inactive(无效)。

4. 完全新增加的特性,大家比较清楚,增加对应的、新的测试用例。

这样,新旧版本的相同测试用例得到一致的维护,测试用例数也不会成几、十几倍的增加,可以真正保证 test case  的完整性、有效性!

 


Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=876118


站内搜索
相关文章
◎黑盒测试的测试用例设计方法
◎谈谈关于测试覆盖
◎使用组合改进软件测试用例的生成
◎用例建模指南
◎掌握可用性规则
◎通用设计的原则
◎用路径分析的方法编写测试用例
◎系统测试设计的层次
◎快速划分测试用例的优先级
◎为什么测试全覆盖很难?
◎边界值法
◎如何写性能测试用例
◎安装测试指南
◎强化测试用例在测试活动中的作用
◎高手过招的乐趣---测试用例预演
◎构件可测试性挑战
◎软件测试入门书籍
◎一个基于UML协作图的集成测试用例生成方法(三)
◎一个基于UML协作图的集成测试用例生成方法(二)
◎一个基于UML协作图的集成测试用例生成方法(一)
◎细说软件测试错误
◎测试用例设计的误区
热门文章
◎软件测试入门书籍
◎黑盒测试的测试用例设计方法
◎用例建模指南
◎如何写性能测试用例
◎测试用例设计的误区
◎高手过招的乐趣---测试用例预演
◎用路径分析的方法编写测试用例
◎系统测试设计的层次
◎一个基于UML协作图的集成测试用例生成方法(一)
◎边界值法
◎细说软件测试错误
◎谈谈关于测试覆盖
◎界面测试
◎软件测试用例的认识误区
◎如何设计编制软件测试用例
◎功能测试用例的书写方式(适于新手学习)
◎快速划分测试用例的优先级
◎通用设计的原则
◎强化测试用例在测试活动中的作用
◎使用组合改进软件测试用例的生成
◎安装测试指南
◎设计功能和界面测试用例一
◎一个基于UML协作图的集成测试用例生成方法(三)
◎为什么测试全覆盖很难?
◎前期测试用例编写规范和流程
◎构件可测试性挑战
◎一个基于UML协作图的集成测试用例生成方法(二)
◎设计功能和界面测试用例二
◎掌握可用性规则
◎黑盒测试之边界值分析、错误猜测-《软件测试艺术》读书笔记(19)
◎黑盒测试之因果图分析-《软件测试艺术》读书笔记(20)
◎测试用例容易遗漏的内容
◎黑盒测试之等价类划分-《软件测试艺术》读书笔记(18)
◎JUnit in java 真正的测试用例实战
◎覆盖率测试用例设计
◎白盒测试-《软件测试艺术》读书笔记(17)
◎测试用例设计自动化
◎浅谈测试用例-《软件测试艺术》读书笔记(16)
◎从测试用例看测试的问题及变化
◎测试用例具体用法
◎界面测试经验总结
◎测试用例的复审
◎测试用例具体用法续
◎测试驱动开发全攻略

Google提供的广告