Testing During Rapid Change
文章介绍：这篇文章对需求、开发快速变化情况下的测试提出了自己的看法，给出了几点可以参考的策略，希望能给大家以启示。 文中提到了自动化测试的引入，其实按照我们的认识，在需求、开发变化太快的情况下是不建议引入自动化测试的，不知道大家怎么看。^_^ 我觉得这要看你的自动测试是怎么做的，为了什么做的。 如果你让它跑regression test.我觉得这有必要在任何时候都让自动测试跑起来。 当然，自动测试脚本的好坏，决定了你工作量的多少。 而且，最好能和开发人员达成共识，尽可能的不改变对象的标识。
尝试翻译了一下，锻炼e文
By Randall W. Rice, CSTE, CSQAAs 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.
如同一句古老的谚语说的，世界上唯一永恒的东西就是改变。在软件开发过程当中，传统的开发模式的一个缺点就是他能够呈现较少的改变甚至没有改变。真实世界每天都在改变。正因为此，其他的开发模式，如快速应用开发（RAD）已经提升到可以包含改变并在计划过程中使用改变来精炼开发。
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.
在RAD模式帮助软件开发者更早的得到更新的版本并更快的运行程序的同时，他也给测试人员带来很多令人头疼的烦恼。因为每个改变都可能产生新的缺陷。找到新缺陷的唯一的方法就是使用回归测试，回归测试可以完整的重复先前的测试过程并与得到的结论进行比较，以便找到不同的地方。
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?"
接下来就产生了2个问题：1）能否在快速变更的需求过程中进行彻底的测试？2）在测试快速变更的软件时需要采用什么策略？
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.
通过观察使用RAD模式进行开发的项目，我发现要找到缺陷和得到任何程度的成效的本质的部分就是测试过程。由于在软件开发中，大多数我们使用的测试标准是规范是使用不重复的过程，所以很多人在测试RAD环境的软件时，采用的方法是平时我们在其他环境中使用的方法——在各个不同的地方使用较少的用例来查找问题和缺陷。
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.
首先，你必须介绍一个事实，那就是不可能花去6个星期的时间来测试一个天天都在改变的软件。这就意味着你需要限定测试过程使得他可以快速并有效的进行。
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.
在快速多变开发环境中同样也需要一个对于机构和过程的新观念。单独使用工具并不是最终的答案。必须有一个能快速执行并且充分有效的利用人力资源和时间的操作程序。要达到工具使用、操作程序以及人力的完美结合，必将是一个很大的挑战。如果你想得到用户验收测试相关的更多的培训及方法，可以通过以下的链接联系e-mail Randy Rice. 翻译的不错，顶一下先。^_^
这篇文章整体来讲由于作者并没有展开来写，所以感觉内容有点单薄，说服力不强。对于快速变化下的测试，我的看法是首先要把这个变化局限在一定的范围内，其实比较理想的是没有变化，这样测试会方便很多（当然这几乎是不可能的了）。然后就是测试策略的选取了，可以基于风险，也可以先测试相对稳定的部分，把极不稳定的放到后面来测。至于自动化测试的引入，需要考虑是否引入，以及引入的程度，再就是测试教本不要太细，以避免大量的教本修改。
欢迎大家讨论！！！
关于本文翻译内容的几点修改
connie的翻译已经非常完整，这里只是对其中的3句话，提出自己的观点。欢迎讨论1.传统的开发模式的一个缺点就是他能够呈现较少的改变甚至没有改变。
建议修改为：在软件开发过程中，传统瀑布模式的一个主要缺点是，它首先假设整个开发过程中没有或者只能有极少的变更。
2.如快速应用开发（RAD）已经提升到可以包含改变并在计划过程中使用改变来精炼开发。
建议修改为：如快速应用开发（RAD）模式已经提倡去拥抱变化，并通过有计划的迭代过程来利用变化，使最终的软件产品不断精华
3.因为你需要在一个较短的时间内来确定你要测试内容的优先级
建议修改为：因为你需要在一个很短的机会窗时间内，确定你的测试工作（任务）的优先级，以适应（环境的快速变化）
这句原文中有一个概念“a short window of time”，通常翻译为：“机会窗”。所以，我理解这句话的意思，即：由于环境（包括需求、资源等）的快速变化，使软件开发具有了机会窗特性，产品的功能、性能往往只能在某一个教小的时间区间（机会窗）能引起市场的注意。所以，就要求我们的研发管理过程也引入机会窗概念，通过迭代、风险管理等方式来实现 to real0705：
非常感谢提点啊。：）有些地方的确是有缺陷，没有处理好。匆匆的在上班空闲时翻译的。刚好当时在看，就一边看一边翻译了一下。
还要多多练习，才能熟悉很多专业用语。谢谢了。
页:
[1]
