First, I think combining the requirements document with the test case document makes the most sense since much of the information is the same for both and having the requirements in front of the testers and the test cases in front of the users and developers reinforces the requirement and provides varying view points of them. Here's a good starting point for the document layout: http://www.volere.co.uk/template.htm#anchor326763 - if you add: steps to test, resulting expectations of the test, edge/bound cases - you should have a pretty solid requirement spec and testing spec in one.
For the steps, don't forget to include an evaluate step, where you, the testers, developers, etc. evaluate the testing results and update the requirement/test doc for the next round (you will often run into things that you could not have thought of and should add into the spec...both from a requirements perspective and testing one).
I also highly recommend using mindmapping/work-breakdown-structure to ensure you have all of the requirements properly captured.
David Peterson's Concordion web-site has a very good page on technique for writing good specifications (as well as a framework for executing said specifications). His advice is simple and concise.
As well you may want to check out Dan North's classic blog post on Behavior-DrivenDevelopment (BDD). Very helpful!
You absolutely need a detailed specification before starting work; otherwise your developers don't know what to write or when they have finished. Joel Spolsky has written a good essay on this topic, with examples. Don't expect the spec to remain unchanged during development though: build revisions into the plan.
meade, above, has recommended combining the spec with the tests. This is known as Test Driven Development and is a very good idea. It pins things down in a way that natural language often doesn't, and cuts down the amount of work.
You also need to think about unit tests and automation. This is a big time saver and quality booster. The GUI level tests may be difficult to automate, but you should make the GUI layer as thin as possible, and have automated tests for the functions underneath. This is a huge time saver later in development because you can test the whole application thoroughly as often as you like. Manual tests are expensive and slow, so there is a strong temptation to cut corners: "we only changed the Foo module, so we only need to repeat tests 7, 8 and 9". Then the customer phones up complaining that something in the Bar module is broken, and it turns out that Foo has an obscure side effect on Bar that the developers missed. Automated tests would catch this because automated tests are cheap to run. See here for a true story about such a bug.
If your application is big enough to need it then specify modules using TDD, and turn those module tests into automated tests.
An hour to run through all the manual tests sounds a bit optimistic, unless its a very simple application. Don't forget you have to test all the error cases as well as the main path.
我将详细阐述 Paul Johnson 关于使 GUI 层尽可能薄的说法。 将形式（GUI 或 HTML 或格式）与功能（它的作用）分开，并自动测试功能。 具有生成国家/地区列表的功能，请彻底测试。 然后是一个使用它生成 HTML 或 AJAX 或其他内容的函数，您只需测试它看起来是否正确，因为执行实际工作的函数已经过充分测试。 用户登录。 密码检查。 电子邮件。 这些都可以在没有 GUI 的情况下编写工作。 这将大大减少必须进行的缓慢、昂贵、有缺陷的手动测试的数量。
Go through old bug reports and build up your test cases from them. You can test for specific old bugs and also make more generalizations. Since the same sorts of bugs tend to crop up over and over again this will give you a test suite that's more about catching real bugs and less about the impossible (or very expensive) task of full coverage.
Make use of GUI and web automation. Selenium, for example. A lot can be automated, much more than you think. Your user registration scenario, for example, is easily automated. Even if they must be checked by a human, for example cross browser testing to make sure things look right, the test can be recorded and replayed later while the QA engineer watches. Developers can even record the steps to reproduce hard to automate bugs and pass that on to QA rather than taking the time consuming, and often flawed, task of writing down instructions. Save them as part of the project. Give them good descriptions as to the intent of the test. Link them to a ticket. Should the GUI change so the test doesn't work any more, and it will happen, you can rewrite the test to cover its intention.
I will amplify what Paul Johnson said about making the GUI layer as thin as possible. Separate form (the GUI or HTML or formatting) from functionality (what it does) and automate testing the functionality. Have functions which generate the country list, test that thoroughly. Then a function which uses that to generate HTML or AJAX or whatever, and you only have to test that it looks about right because the function doing the actual work is well tested. User login. Password checks. Emails. These can all be written to work without a GUI. This will drastically cut down on the amount of slow, expensive, flawed manual testing which has to be done.
发布评论
评论（5）
我开发了两个我使用的文档。
一种是针对您的更“标准网站”（例如商业网站）：
http://pm4web.blogspot.com/2008/07/quality-test-plan.html
我用于基于网络的应用程序的另一个：
http://pm4web.blogspot.com/2008/07/writing-system- test-plan.html
希望有帮助。
ive developed two documents i use.
one is for your more 'standard websites' (e.g. business web presence):
http://pm4web.blogspot.com/2008/07/quality-test-plan.html
the other one i use for web-based applications:
http://pm4web.blogspot.com/2008/07/writing-system-test-plan.html
hope that helps.
首先，我认为将需求文档与测试用例文档结合起来最有意义，因为两者的大部分信息是相同的，并且将需求放在测试人员面前，将测试用例放在用户和开发人员面前可以强化需求。并提供了他们的不同观点。 这是文档布局的一个很好的起点：http://www.volere.co。 uk/template.htm#anchor326763 - 如果您添加：测试步骤、测试结果期望、边缘/绑定案例 - 您应该拥有一个相当可靠的需求规范和测试规范。
对于这些步骤，不要忘记包括评估步骤，在该步骤中，您、测试人员、开发人员等评估测试结果并更新下一轮的需求/测试文档（您经常会遇到无法解决的问题）已经考虑过并且应该添加到规范中......无论是从需求角度还是测试角度）。
我还强烈建议使用思维导图/工作分解结构来确保您正确捕获所有需求。
First, I think combining the requirements document with the test case document makes the most sense since much of the information is the same for both and having the requirements in front of the testers and the test cases in front of the users and developers reinforces the requirement and provides varying view points of them. Here's a good starting point for the document layout: http://www.volere.co.uk/template.htm#anchor326763 - if you add: steps to test, resulting expectations of the test, edge/bound cases - you should have a pretty solid requirement spec and testing spec in one.
For the steps, don't forget to include an evaluate step, where you, the testers, developers, etc. evaluate the testing results and update the requirement/test doc for the next round (you will often run into things that you could not have thought of and should add into the spec...both from a requirements perspective and testing one).
I also highly recommend using mindmapping/work-breakdown-structure to ensure you have all of the requirements properly captured.
David Peterson 的 Concordion 网站 有一个非常好的页面，介绍了编写良好规范的技术（以及作为执行所述规范的框架）。 他的建议简单明了。
您可能还想查看 Dan North 关于行为驱动开发 (BDD) 的经典博客文章。 很有帮助！
David Peterson's Concordion web-site has a very good page on technique for writing good specifications (as well as a framework for executing said specifications). His advice is simple and concise.
As well you may want to check out Dan North's classic blog post on Behavior-DrivenDevelopment (BDD). Very helpful!
在开始工作之前，您绝对需要一份详细的规范； 否则您的开发人员不知道要写什么或何时完成。 Joel Spolsky 就该主题写了一篇很好的文章，并附有示例。 不过，不要指望规范在开发过程中保持不变：对计划进行修订。
上面的米德建议将规范与测试结合起来。 这称为测试驱动开发，是一个非常好的主意。 它以自然语言通常不会的方式确定事物，并减少工作量。
您还需要考虑单元测试和自动化。 这可以节省大量时间并提高质量。 GUI 级别的测试可能很难自动化，但是您应该使 GUI 层尽可能薄，并对下面的功能进行自动化测试。 这在以后的开发中可以节省大量时间，因为您可以根据需要经常彻底测试整个应用程序。 手动测试昂贵且缓慢，因此存在强烈的偷工减料诱惑：“我们只更改了 Foo 模块，因此我们只需要重复测试 7、8 和 9”。 然后客户打电话抱怨 Bar 模块中的某些东西被破坏了，结果发现 Foo 对 Bar 产生了一个开发人员忽略的不明显的副作用。 自动化测试可以解决这个问题，因为自动化测试的运行成本很低。 请参阅此处 有关此类错误的真实故事。
如果您的应用程序足够大，需要它，那么使用 TDD 指定模块，并将这些模块测试转变为自动化测试。
一个小时完成所有手动测试听起来有点乐观，除非它是一个非常简单的应用程序。 不要忘记您必须测试所有错误情况以及主路径。
You absolutely need a detailed specification before starting work; otherwise your developers don't know what to write or when they have finished. Joel Spolsky has written a good essay on this topic, with examples. Don't expect the spec to remain unchanged during development though: build revisions into the plan.
meade, above, has recommended combining the spec with the tests. This is known as Test Driven Development and is a very good idea. It pins things down in a way that natural language often doesn't, and cuts down the amount of work.
You also need to think about unit tests and automation. This is a big time saver and quality booster. The GUI level tests may be difficult to automate, but you should make the GUI layer as thin as possible, and have automated tests for the functions underneath. This is a huge time saver later in development because you can test the whole application thoroughly as often as you like. Manual tests are expensive and slow, so there is a strong temptation to cut corners: "we only changed the Foo module, so we only need to repeat tests 7, 8 and 9". Then the customer phones up complaining that something in the Bar module is broken, and it turns out that Foo has an obscure side effect on Bar that the developers missed. Automated tests would catch this because automated tests are cheap to run. See here for a true story about such a bug.
If your application is big enough to need it then specify modules using TDD, and turn those module tests into automated tests.
An hour to run through all the manual tests sounds a bit optimistic, unless its a very simple application. Don't forget you have to test all the error cases as well as the main path.
浏览旧的错误报告并从中构建您的测试用例。 您可以测试特定的旧错误并进行更多概括。 由于相同类型的错误往往会一次又一次地出现，这将为您提供一个测试套件，该套件更多地关注捕获真正的错误，而不是全面覆盖不可能的（或非常昂贵的）任务。
利用 GUI 和 Web 自动化。 例如，Selenium。 很多事情都可以自动化，比你想象的要多得多。 例如，您的用户注册场景很容易实现自动化。 即使它们必须由人工检查，例如跨浏览器测试以确保事情看起来正确，测试也可以在 QA 工程师观看时记录并稍后重放。 开发人员甚至可以记录重现难以自动化的错误的步骤，并将其传递给质量检查，而不是花时间写下指令，而且常常存在缺陷。 将它们保存为项目的一部分。 向他们提供关于测试目的的良好描述。 将它们链接到票证。 如果 GUI 发生变化，导致测试不再有效（这种情况确实会发生），您可以重写测试以涵盖其意图。
我将详细阐述 Paul Johnson 关于使 GUI 层尽可能薄的说法。 将形式（GUI 或 HTML 或格式）与功能（它的作用）分开，并自动测试功能。 具有生成国家/地区列表的功能，请彻底测试。 然后是一个使用它生成 HTML 或 AJAX 或其他内容的函数，您只需测试它看起来是否正确，因为执行实际工作的函数已经过充分测试。 用户登录。 密码检查。 电子邮件。 这些都可以在没有 GUI 的情况下编写工作。 这将大大减少必须进行的缓慢、昂贵、有缺陷的手动测试的数量。
Go through old bug reports and build up your test cases from them. You can test for specific old bugs and also make more generalizations. Since the same sorts of bugs tend to crop up over and over again this will give you a test suite that's more about catching real bugs and less about the impossible (or very expensive) task of full coverage.
Make use of GUI and web automation. Selenium, for example. A lot can be automated, much more than you think. Your user registration scenario, for example, is easily automated. Even if they must be checked by a human, for example cross browser testing to make sure things look right, the test can be recorded and replayed later while the QA engineer watches. Developers can even record the steps to reproduce hard to automate bugs and pass that on to QA rather than taking the time consuming, and often flawed, task of writing down instructions. Save them as part of the project. Give them good descriptions as to the intent of the test. Link them to a ticket. Should the GUI change so the test doesn't work any more, and it will happen, you can rewrite the test to cover its intention.
I will amplify what Paul Johnson said about making the GUI layer as thin as possible. Separate form (the GUI or HTML or formatting) from functionality (what it does) and automate testing the functionality. Have functions which generate the country list, test that thoroughly. Then a function which uses that to generate HTML or AJAX or whatever, and you only have to test that it looks about right because the function doing the actual work is well tested. User login. Password checks. Emails. These can all be written to work without a GUI. This will drastically cut down on the amount of slow, expensive, flawed manual testing which has to be done.