[翻译完成]Some Pointers to Planning
大致内容：写测试计划应该注意哪些问题。Some Pointers to Planning
Submitted by Stevan Zivanovic on Mon, 25/07/2005 - 15:56. test management
A common theme that I have come across when coming onto client sites is that people cannot tell me why they are testing what they are. If I am lucky, the reply is that it is identified in the Test Plan. When I look at the Test Plan however, I tend get 20 to 30 pages of hard work that still does not tell me what and why people are testing.
Now I am not planning on re-analysing the IEEE 829 template test plan. This is a great document and can assist greatly. However I want to look at the overall purpose and necessity to plan. Regardless of the overall development methodology, e.g. SCRUM or Waterfall, some time needs to be spent defining the approach to testing.
All good development starts off with a plan, whether that is a story board within Agile or detailed specifications in the highly formalised project, the same applies to testing. To do good, relevant and appropriate testing requires some careful thinking. Good questions to ask and to try to define are:
• What is the system I am testing?
This relates to the software, the infrastructure and any related systems/applications. Try drawing a schematic of the system you will be testing, showing what software will sit on which piece of hardware and how these connect to other applications.
• How am I going to test this?
What approach am I going to use? Am I using exploratory testing, test driven design, validation or any other approach or mix of approaches. This can help highlight issues around having the right resources to support the activities, including people and skills.
• What is the purpose of my testing?
Am I trying to ensure that this safety critical system is fit to fly? Is to confirm that an application is stable enough to go for a demo somewhere? More fundamentally, what do my customers, the business, require from me? Depending on the response to this will determine the depth and rigour required.
• What will I test for?
By answering the questions above and then using whatever knowledge of the system is available, you can start to highlight key areas that need testing. This could start as a list of key risk areas, features, scenarios or even test techniques (e.g. I know I need to do some performance testing, but I don’t know quite what I need testing yet).
By answering these questions and communicating them to others, significant improvements can made very rapidly in clarifying and defining clearly to all the stakeholders what testing is required and why.
[ Last edited by skinapi on 2005-8-25 at 00:01 ] 标题可以翻译为：测试计划要点
内容谁来翻译一下？
拭目以待 :p 我认为标题翻译为：测试计划中要提出的几点
[翻译]如何写测试计划
当我访问一些站点的时候，发现一个很常见的问题，人们总是无法说出为什么他们要测试他们正在测试的内容。幸运的话，我将会得到这样的答案：这些都是在测试计划中计划好的。但是当我看测试计划的时候，却发现辛苦工作换来的20-30页计划文档的内容，却仍然没有告诉我他们到底在测试什么以及为什么要这样测试。现在我并不是打算重新分析IEEE 829模板的测试计划。这是一份非常棒的文档，能给我们提供很多帮助。我想看一下整体的目的以及计划的必要性。撇开整体的开发方法不谈，如SCRUM或Waterfall，我们需要花费一些时间来给测试的方法下定义。
无论这是一个活泼轻快的故事性记叙或是一个非常正式、规范的详细的项目，好的开发都要从计划开始，这一点也适用于测试。为了做好这项工作，需要对相关的及适当的测试进行仔细的思考。以下是我们在下定义时能用到的一些好问题：
我要测试的是什么？
这个问题的内容包括与之相关的软件、基础结构以及相关的系统和应用。你可以把你将要测试的系统用图解的形式表示出来，用来表现哪个软件将会依赖哪部分硬件以及如何与其他应用建立连接。
怎样进行测试工作？
我要用什么方法来开展测试工作？我是否会用到探测性测试、测试驱动设计、确认测试或者其他任何一种方法，又或者是这些方法的综合。这样做可以帮助我们突出重点，并合理利用资源来支持我们的测试活动，包括人力和技术资源。
测试的目的是什么？
我是否需要保证关键系统的安全性满足运行条件？应用程序是否已经足够稳定以供在某地发行试用版？或者更加基本的，我的客户以及商业需求到底是什么？考虑清楚这些以后将决定测试需要进行的深度以及精确程度。
需要测试什么内容？
为了回答上面这个问题，需要对系统的各个方面都有认识，你可以在需要测试的内容里面突出关键部分。可以列出关键及风险内容、属性、场景或者测试技术（如，我知道我需要进行一些性能测试，但是我还不是十分清楚我到底需要测试什么）
通过回答上述所有问题并将他们与其他各方面联系起来，那么在向所有利益相关者阐明并清楚地定义测试什么内容和为什么这么测试时，就很快可以得到重要的改善了。
[ Last edited by connie on 2005-8-25 at 10:10 ] 翻译得不错，感谢connie，加分了。：） thx斑竹的鼓励：） In my opinion, the order of the four to define should be:
What will I test for?
What is the purpose of my testing?
What is the system I am testing?
How am I going to test this? 简明扼要。
测试计划要点：
我遇到很多这样的问题，就是人们并不知道自己为什么要测试他们正在测试的东西。如果比较幸运的话，答案在测试计划中可以找到。然而当我看测试计划20-30页时仍然不知道人们要测试的是什么和为什么要测试。现在我的测试计划不再是建立在再分析IEEE 829测试模板计划之上了。这是一个很有帮助的文档。不过我想知道测试计划的目的和必要性，不管全面测试的方法是什么，比如SCRUM和Waterfall，需要花点时间去设计一下测试的方法。
一切良好的测试都开始于计划，不管它是一个关于精灵的故事模式还是有高度专业细节的正式项目，计划同样被应用在测试中。为了做得更好，相关的和恰当的测试需要更仔细的思考。
.正在测试的系统是什么？
这涉及到软件、内部构造及任何和系统及应用程序相关的东西。试着为要测试的东西制定一个系统的计划，列出在什么软件和硬件基础上使用及与其他应用程序的联系。
.将如何测试？
我将用什么方法去测试呢？我将使用要摸索测试吗：测试驱动设计，确认或者其它方法或者将几种方法混合来测试。这将有助于使项目更合理的使用资源，包括人力和技术。
.测试的目的是什么？
我是不是在试着使人相信这个安全标准系统是适合使用的？是不是能肯定这个应用程序在任何条件下都能稳定的演示？更基础的来说，我的客户和经理从我这里需要得到什么东西？对这些问题的回答将决定需求的深度和严谨度。
.测试什么内容？
对以上问题的回答后使用任何系统知识都是可行的，你将明确哪个地方是最需要测试的。可以从关键区域开始，特征、情况甚至测试技术（比如，我知道我需要做一些结果测试，但我实在不知道我要测试什么）
回答了这些问题又和其他人交流之后，测试者们很快的就有了实质性的提高，可以清晰的阐述和定义需要什么样的测试及为什么要测试。
鼓足勇气发了上面这篇翻译
向来英文就不好，把自己翻译的和connie的一比，简直无地自容。但为了刺激自己更好的学习英语，在犹豫了几天之后，还是把它呈现在众人面前，接受大家的批判！ 很受启发, 辛苦辛苦！ 辛苦！辛苦！ 原帖由 genius 于 2005-9-1 10:09 发表 http://bbs.51testing.com/images/common/back.gifIn my opinion, the order of the four to define should be:
What will I test for?
What is the purpose of my testing?
What is the system I am testing?
How am I going to test this?
前两点的顺序……不敢苟同。
页:
[1]
