51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 17247|回复: 20
打印 上一主题 下一主题

Rapid Software Testing

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-1-20 15:16:05 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
James Bach讲的一门课,附件是课程的相关资料,大家也可以从他的网站直接下,还有一个Rapid Software Testing-appendices,做附件传不上来,内容很丰富。
http://www.satisfice.com/

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    无聊
    2015-6-14 21:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    2#
    发表于 2006-1-20 15:24:15 | 只看该作者

    谢谢版主

    顶一下!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2006-1-26 00:54:30 | 只看该作者

    多谢BZ

    学习中... Thanks
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2006-2-20 13:06:03 | 只看该作者

    慢慢学……

    好长的文档,学习!!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2006-2-23 23:00:40 | 只看该作者
    此网站有很多好文章!赞!!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2006-6-29 14:12:11 | 只看该作者
    have a look.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2006-7-11 13:10:09 | 只看该作者
    不错哦,多谢了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2006-7-11 13:59:54 | 只看该作者
    rapid testing,感觉和现有的一些测试观念有很大的冲突,看来要接收这些观点,还要有些时间。
    另外,我想问一下,rapid testing好像是96年的理论?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2006-7-18 18:12:58 | 只看该作者
    Rapid Testing,正在试着翻译,不过才40页,只完成了20%的工作量
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2006-7-19 12:18:10 | 只看该作者
    kankan
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2006-9-5 17:44:02 | 只看该作者
    ding
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2007-4-3 14:25:05 | 只看该作者
    thx
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2007-4-13 14:41:05 | 只看该作者
    Testing During Rapid Change   
    By Randall W. Rice, CSTE, CSQA
    As the old adage goes, "the one thing that remains constant is change." In software development, one of the weaknesses of the classic waterfall approach is that it assumes little or no change. The real world changes every day. Because of this, other development models such as Rapid Application Development (RAD) have been promoted to embrace change and use it to refine the software through planned iterations.

    While RAD helps software developers get early versions up and running very quickly, it causes testers many headaches. With each and every change is the opportunity to create new defects. The only way to find new defects is to perform a regression test which completely repeats a previous test and compares the results to find differences.

    Two questions come to mind: 1) "Is it possible to completely test during rapid change?", and 2) "Which strategies can be used to test rapidly changing software?"

    Is It Possible to Completely Test During Rapid Change?

    Actually, no. However, that's a trick question because in most cases it is not possible to completely test software even in stable environments1. The essence of this question might be to ask, "Is it possible to test effectively during rapid change?" Can we expect to make the best use of people and other resources to test software? Can we expect to find the expected number of defects?

    By observing projects using RAD, I have observed that a process for testing is essential to finding defects with any degree of effectiveness. Since the norm is to have no repeatable processes for most of what we do in building software, many people test in a RAD environment the same way they do in other environments - try a few cases here and there and look for problems.

    Which Strategies Can Be Used?

    It takes time to learn what works in each unique environment, but here are some general strategies that can be used for testing during rapid change:

    First of all, accept the fact that you do not have the luxury of performing a six week test on software that changes every day. This means you will need to define a testing process that can be performed quickly and efficiently.

    Perform a risk assessment. Knowing the level of risk is crucial, since you will need to prioritize your testing efforts to fit within a short window of time. The higher the risk, the higher the testing priority.

    Automate your testing. Capture/playback tools help you perform repeatable tests in an unattended session. Good tools require a significant investment in software and training, but it beats working 24 hours a day. Some things to consider before automating:

    You must have a working baseline version of the software to perform comparisons with future tests.

    You must define business requirements, test cases and test scenarios. The tool can only record and playback based on what actions the user performs.

    Data is a key consideration. How will you maintain the test data? For example, if you use a capture/playback tool to add a record, a reply of the script will get a "duplicate record on file" error.

    It takes time and a whole lot of spending money to integrate the tool into your organization. People need to be trained in how to use the tool. In addition, people need to be sold on the long-term benefits as compared to the short-term work required to setup the test scripts and test cases.

    Testing during rapid change is not impossible, but it does require rapid response, working smart, and keeping track of changes. Organizations that have been unwilling to consider new technologies such as automated testing tools will not be able to effectively test during rapid change. It is like building a house with hand tools - sure it can be done, eventually.

    Testing during rapid change also requires a new mindset of organization and processes. Tools alone are not the answer. There must be a process that can be executed quickly and makes the best use of people and time. It is arriving at the optimal combination of tools, processes, and people that is the challenge. To find out more about training and approaches for user acceptance testing, e-mail Randy Rice.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2007-5-12 12:20:16 | 只看该作者
    sdlkfj2
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2007-5-29 15:57:33 | 只看该作者

    回复 #1 skinapi 的帖子

    sdlkfj2
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2007-6-3 23:29:05 | 只看该作者
    谢谢楼主了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2007-6-12 17:15:53 | 只看该作者

    回复 #1 skinapi 的帖子

    谢谢了哪
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2007-9-17 16:15:36 | 只看该作者
    学习学习
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2012-3-7 11:48:30 | 只看该作者
    wonderful book.Thank you !
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-11-25 15:40
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    20#
    发表于 2012-3-7 16:21:09 | 只看该作者
    Thanks
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-22 01:43 , Processed in 0.085186 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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