51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2883|回复: 3
打印 上一主题 下一主题

[求助] 关于敏捷测试,请教下!

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-9-8 09:56:15 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
我对敏捷测试是不太懂的,也不知道自己是否有做过,估计没有吧!

按照我看网友的资料了解就是比较快速响应问题!

那如何在敏捷测试中保证软件测质量呢,不知道实行敏捷测试需要做如何的测试方式呢?

说说我异想天开的想法:实施敏捷测试(不管是黑白盒或者灰褐测试系统测试),主要流程为:测试--》快速响应验证等测试--》回归

像我现在的公司,我做的属于黑盒测试的,一般我们的流程是:1.评审需求 2.评审报告,修改等... 3.测试策划(看需求,写计划等等) 4.编写测试用例 5.提交评审并根据评审结果修改用例 6.部署并执行系统功能测试 7.提交功能测试报告  这属于正常一轮的功能测试
然后验证的时候就是:1.编写测试计划  2.部署并执行验证测试 3.提交验证测试报告......直至没有BUG

我这公司一直处于理想状态下做事,希望一轮功能+一轮验证,就搞定一个软件一个项目(实际上几乎不可能)

当然从这个过程中我也觉得很浪费时间在提交测试申请、计划、报告等一系列过程中,而且每一轮都需要经过开发重新提交测试申请等等一个等待的操作过程,我之前公司,一般来说是发现BUG马上告知开发,开发一修改,马上告知我,然后我马上进行验证,并没有提交验证申请的过程,现在想想看,确实有点像敏捷测试的意思,当然不管多少个BUG得到我们验证通过了,在发布之前,我们一定会使用QTP进行功能回归测试。不知道这是否就是所谓的敏捷测试呢?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2009-9-8 14:07:50 | 只看该作者

回复 2# 的帖子

恩,你这样一说,就是以公司实际出发来定制,这样说起来,前期也要经过调研?
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-9-13 18:08:28 | 只看该作者
“我之前公司,一般来说是发现BUG马上告知开发,开发一修改,马上告知我,然后我马上进行验证,并没有提交验证申请的过程”

是的,这个的确有敏捷的味道。

我觉得你已经发现了你们目前流程中不敏捷的地方,比如说重复提交报告之类的。最简单的讲,如果你干活觉得不爽,那多半有什么是不敏捷的。如果你能够很爽的把项目做完,然后客户也满意。那说明你足够敏捷了。

关于敏捷测试,可以看看我的博客,欢迎交流。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2009-9-13 18:40:01 | 只看该作者
敏捷这个东西,要理解其思想;敏捷好不好主要还是根据公司和项目来看;就像C一样,JAVA出来的时候大家都说,面向对象语言好,面向过程落后了,可能被淘汰,可是实际上呢?C照样大行其道,在嵌入式上成为王者;CMMI,敏捷也是如此;真正的开发流程和管理还是要基于自己公司的项目和产品特点的,所以说大公司一般都有自己的开发流程和管理流程,而不是照搬CMMI或者ISO9000,微软、IBM都是如此;敏捷的确是应需求而生的一种生产效率更高的理念,但是如果不理解CMMI,那怎么能知道敏捷的好?
学习编程语言一般都是通过面向过程、面向对象这样的过程,因为这样的学习路线有助于把基础打的很扎实,所以建议学习敏捷之前,还是把CMMI和ISO之类的理念先搞个清楚吧
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-23 08:31 , Processed in 0.068481 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表