软件测试英文1.doc

本文档系作者精心整理编辑，实用价值高。Testing During Rapid ChangeBy 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.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, thats 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 scrpt 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 scrpts 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.Back to list译文:如何在快速变更的环境中开展测试工作作者:Randall W. Rice, CSTE, CSQA 翻译:connie 如同一句古老的谚语说的，世界上唯一永恒的东西就是改变。在软件开发过程当中，传统的开发模式的一个缺点就是他能够呈现较少的改变甚至没有改变。真实世界每天都在改变。正因为此，其他的开发模式，如快速应用开发（RAD）已经提升到可以包含改变并在计划过程中使用改变来精炼开发。在RAD模式帮助软件开发者更早的得到更新的版本并更快的运行程序的同时，他也给测试人员带来很多令人头疼的烦恼。因为每个改变都可能产生新的缺陷。找到新缺陷的唯一的方法就是使用回归测试，回归测试可以完整的重复先前的测试过程并与得到的结论进行比较，以便找到不同的地方。接下来就产生了2个问题：1）能否在快速变更的需求过程中进行彻底的测试？2）在测试快速变更的软件时需要采用什么策略？能否在快速变更的需求过程中进行彻底的测试？答案是，不能。这是一个恶作剧式的问题，因为在大多数情况下，即便是在稳定的环境当中，进行彻底的测试都是不可能的。我们可以将这个问题改成这样，“能否在快速多变的环境中进行有效的测试？”我们能否期望在测试软件时能够充分有效的利用人力及其他资源？我们能否期望在测试中找到预期数量的缺陷？通过观察使用RAD模式进行开发的项目，我发现要找到缺陷和得到任何程度的成效的本质的部分就是测试过程。由于在软件开发中，大多数我们使用的测试标准是规范是使用不重复的过程，所以很多人在测试RAD环境的软件时，采用的方法是平时我们在其他环境中使用的方法在各个不同的地方使用较少的用例来查找问题和缺陷。我们可以采用什么样的策略呢？研究每个单独的环境当中需要采用的策略将会耗费过多的时间，这里有一些通用的策略，可以在快速改变的测试环境中使用。首先，你必须接受一个事实，那就是不可能花去6个星期的时间来测试一个天天都在改变的软件。这就意味着你需要限定测试过程使得他可以快速并有效的进行。做一个风险程度的估定。知道风险的标准是关键所在，因为你需要在一个较短的时间内来确定你要测试内容的优先级。风险越高，册是的优先级越高。自动化测试过程。回归测试工具帮助你在短时间内进行重复的测试工作。好的工具需要在软件及培训方面进行重要的投资，但他不能一天不间断的工作。有一些事情需要在自动测试之前考虑并提前做好。你必须拥有软件的工作标准文档来跟将来的测试进行比较。你必须定义需求，测试用例和测试环境。工具只能记录并回放基于操作者的操作行为的活动。数据维护是关键。你将怎样维护这些测试数据？例如，如果你使用回归测试工具来添加一个记录，脚本文件将得到“重复的记录”这样的错误。这将耗费相当多的时间以及金钱来使得这个工具融入到你们的公司。在此之前还必须对相关人员进行工具使用的培训。因此，必须使人们相信，跟目前工作当中需要建立测试脚本和测试用例这些琐碎的事情相比，这样做对于长期利益的发展是非常有价值的。在快速多变的环境中进行测试并不是不可能的，但是他需要能够做出快速的响应，灵敏的进行操作，并且与变更的轨迹保持一致。那些不愿意考虑新技术，如自动化测试的公司、组织将不能在快速多变的开发环境中开展有效的测试工作。这就好比是手工工具来盖一座房子，很显然他最终是无法成功的。在快速多变开发环境中同样也需要一个对于机构和过程的新观念。单独使用工具并不是最终的答案。必须有一个能快速执行并且充分有效的利用人力资源和时间的操作程序。要达到工具使用、操作程序以及人力的完美结合，必将是一个很大的挑战。如果你想得到用户验收测试相关的更多的培训及方法，可以通过以下的链接联系e-mail Randy Rice.第二篇Predicting the Future of Testing By Harry Robinson Summary: As the end of the year approaches, psychics and pundits alike will start making their predictions about whats in store for us in 2004 and beyond. In this weeks column, industry veteran Harry Robinson gives us his forecast on the future of software testing. It is tough to make predictions, especially about the future.Yogi Berra Every December, tabloid fortune-tellers reveal what will happen in the coming year: “Madonna will fly on the space shuttle,” “the U.S. capital will move to Wichita, Kansas” and so forth. Id like to jump on that bandwagon and make a few predictions of my own about where software testing is going in the next few years. And I can only hope my prophecies fare better than those of my esteemed tabloid colleagues! My main prediction is that software testing in the future will look very different than it does today. My reasoning is straightforward: Software testing largely stinks today. It comes into a project too late, contributes too little, and costs too much. If we care about the quality of our products and the health of our bottom lines, we need to re-think our approach to testing and quality. I will even go out on a limb and say that better methods, better training and a better appreciation for testers will revolutionize the software industry. To be specific, technologies such as executable specifications, model-based test generation, bug prevention, and system simulation will play important roles in the unfolding drama. Here are some scenes we will see in the industry over the next few years. In fact, some of these trends are starting to emerge already. Testers, Spec Writers, and Developers See Themselves as Partners Testers Help Spec Writers Testers work with spec writers to review and understand the spec as it is being written. Early review and modeling exposes many consistency, completeness, and ambiguity bugs while they are still cheap to fix. Spec Writers Help Testers The test team creates models to generate tests of its applications behavors. Spec writers review the models to ensure that they adequately cover the feature set. The resulting test model becomes an executable spec. Testers Help Developers Because the spec is clean and unambiguous, the developers understand better what their code should accomplish. Testers provide lightweight models that developers can run against their code before they officially hand it over for testing. Developers Help Testers Proceeding on a feature-by-feature basis (to avoid the late-in-the-cycle, product-pounding approach of the past), developers and testers ensure that the code is easy to test with automated methods. Developers code is now full of testability hooks, making errors more detectable. Testers Help Testers Tests are now modeled in a high-level language, so teams working on other features (and even other products) can help review and improve the test models. This creates a community of test generation experts. Methods and Metrics Get Better Bug Prevention and Early Detection Because the emphasis is now on the quality of the deliverable (and not on how many bugs you found along the way), prevention practices and detection tools, such as static analyzers, are mainstream. Simulation in Testing Simulation tools become common, making it easy to “fake” computer environments. Testing for exceptions and error paths now happens early in the development process. After the code has stabilized, real environments verify that the simulations were accurate. Just-in-time Test Cases Massive test case management systems are a thing of the past. Most tests are generated on the fly. Test cases are no longer stored away like rotting inventory, so it is easy to keep tests up to date. Positive Metrics Misleading metrics, such as bug counts and test case counts, are dead. Useful metrics, such as spec coverage, model coverage, and code coverage, drive the projects. Fewer Testers, Better Testers Machines now perform much of the mundane work that testers previously did creating tests. Teams require fewer testers, and the testers who remain are more highly trained. Their work is more interesting to them because they are focused on bigger issues in their tests rather than slogging through grunt work. More Tests, Better Tests Testers can now generate millions of tests on any day, so the challenge becomes how to run the most useful tests first. Combinatorial tools allow testers to prioritize their testing and aim their test runs at the areas most likely to have significant bugs. Roles Will Change for Testers Distinctions Blur in Testing Work in the testing field blurs the line between people who only specialize in hands-on testing and those who only create test tools. A new specialty emerges that encompasses both testers who like to break things via programs and programmers who like to create programs that break things people in newsgroups debate endlessly about what to call the new specialty. Boundaries Blur Between Testing and Development Testers and developers work in tandem to produce testable, high-quality code. Testers help iron out spec issues to make the developers job easier, and developers create cleaner, more testable code to make the testers job easier. Feedback from Customers Becomes Integrated with Testing The quality of deliverables becomes higher. Testers routinely conduct root cause analyses. We ask questions such as How did we miss this bug? and How can we prevent this type of bug in the future? We work to delight our customers. New Challenges Emerge The sophisticated and interconnected environment of the computing world guarantees that new problems such as security testing continue to keep testers running hard. This is OKtesters find these challenges invigorating. Testers Get Respect Testers are no longer called in at the last moment to pound on the product. They provide a visible, vital, value-added service throughout the software development process. People realize that testing can be rewarding, interesting, and even fun. Testing Gets Trendy Software testers start to hold their heads high. And, because breaking stuff is at least as much fun as building it, people begin to rotate between positions in development and testing. Everyone learns more about what makes good code. Adrenaline Junkies Move On The new process works so well that spec writers, developers, and testers end up having lives. This is disconcerting to some who were raised in the adrenaline-charged world of late-night, last-minute, firefighting sessions. These people gravitate to companies that remain out of control. Elvis Presley Is Discovered Working as a Software Tester The giveaway is his conference paper titled “Software Quality: Its Now or Never”. Prepare for the future today Whether or not my predictions come true, the future is on its way. Here are five ideas for how you can prepare to meet it: 1. Get Actively Dissatisfied Dont accept the current state of testing. Look around and think, What are we doing that makes no sense? 2. Push the Envelope Figure out how to test better and share that knowledge. Overall quality will improve only if everyone seeks to make the code they are working on the best it can be. 3. Learn More about Testing At this moment, the industry is exploding with innovative software testing ideas. Go to conferences, join mailing lists, and scour the Web to see what is happening on the cutting edge of testing. 4. Learn More about Development Take a programming class. Even if you dont plan to write significant amounts of code, view the class as a reconnaissance flight over bug territory. 5. Change the World! As PC pioneer Alan Kay said: The best way to predict the future is to invent it. For more info: On executable specs: “Executable Specifications: Creating Testable, Enforceable Designs” On model-based testing: “Intelligent Test Automation” On system simulation: “Softwares Invisible Users” About the Author Harry Robinson is Test Architect for Microsofts Enterprise Management Division. In addition to his day job, he teaches classes on advanced software test automation and is a driving force behind Microsofts model-based testing initiative. He has been at Microsoft for five years and has a Bachelors and Masters in Electrical Engineering. You can reach him at . 测试未来的预测 作者: 未知 来源: 网络 摘要：一年将尽，心理学家或者一些博学者们，又将对2004年或者更久的将来作出预测。在这次的周末专栏中，Harry Robinson将向我们讲述他对测试未来的预测。 “预测是件很难的事情，尤其是预测未来” Yogi Berra 每年十二月，小报的“未来预测者”们会向大家切揭示即将到来的一年将要发生的事情：“麦丹娜将要乘坐航天飞机”，“美国将迁都 Wichita”，等等。我将加入这个潮流，对软件测试何去何从做一个我自己的预测。并且我希望，我的预测费用能够比我的那些值得尊敬的小报同事更高些。 我的主要预测就是，将来的软件测试与现在的软件测试看起来很不一样。原因很直接：今天的软件测试很大程度上是臭名昭著的：软件测试参与到项目中的时间太晚、贡献太少、花费太高。如果我们关心我们产品的质量以及我们的账本底线的话，我们就需要重新思考测试和质量的方法。 即使遭到一致反对，我也要说：更好的方法，对测试人员更好的培训、更好的欣赏将改革软件产业。具体地说，诸如可执行的说明书、基于模型的测试产生、BUG预防、系统模拟这些技术，将在这场演变过程中扮演重要的角色。 下面就是我们在将来的几年里可能看到的情形。事实上，某些趋势已经开始了。 测试人员，需求撰写人员和开发人员，都将看到自己是其中的一份子。 测试人员帮助需求撰写人员 测试人员与需求撰写人员共同工作，在需求完成以后，审查以及理解需求。早期的审查以及建模可以暴露很多关于一致性、完整性和模糊性的BUG，这个时候修补这些BUG付出的代价还十分小。 需求撰写人员帮助测试人员 测试小组建造模型，用于产生对其产品行为的测试。需求撰写人员审查模型，以确保他们充分覆盖了产品特征集。这样产生的测试模块将成为一个“可执行需求”。 测试人员帮助开发人员 因为需求清楚，毫不含糊，开发人员更好的理解了他们的代码将要完成什么。 在正式的将代码提交做测试之前，测试人员提供给开发人员一些模型，以便开发人员可以在自己的代码中实现它们。 开发人员帮助测试人员 基于”特征对特征”这样的方式(防止以往的“后期才介入开发,一股脑找出产品问题”的方式),开发人员和测试人员共同保证代码易于实施自动测试.开发人员的代码中处处都是易测试性的开关,使得错误检测更加容易. 测试人员帮助测试人员 测试用一种高级语言来模拟,因此别的特征的测试小组(甚至别的产品的测试小组)可以复查和改进测试模型.这就形成了一个测试专家的共同体. 方法日趋完善 BU