问需求测试

EN

我会使用已经存在的需求编号计划，而不是创建一个新的。我将记录每一项要求的下列项目：

1. Requirement Status：这可以用许多不同的方式来表达，但是如果需求是按列表完成的，或者是在all.
2. Requirement Comment上无法完成的修改版本中完成的，那么您就需要进行通信:描述以前列出的需求状态。这就是解释那些不能完全满足requirements.
3. Date完成的的“原因”：这主要是为了将来的产品规划，但也是作为历史参考的服务器。

还有几点要记住：

客户可以对

1. Requirements进行评审，特别是如果客户是需求的来源。因此，这份文件必须尽可能准确，尽可能提供信息。(这也是除非您必须更改需求编号方案的另一个原因。)
2. 您的测试部门(假设您有一个)应该在测试计划中使用这些文档，他们需要知道满足了哪些需求，哪些没有，最重要的是哪些更改了，以及如何更改。

最后，除非您正在为某个人举办狗和小马表演，否则您不需要将截图作为需求文档的一部分。你也不需要提供完成的“证据”。测试部门会帮你的。

有一些技术可以将您的需求转换为测试用例。但这取决于您的需求是如何被记录的。如果您已经进行了基于场景的需求分析，那么将非常容易:只需为场景的每个路径创建一个序列图，编写/完成一个测试->即可。此外，这样创建的文件也会给你的讲师留下深刻印象。

如果您没有场景，您应该从用例中创建一些场景。

这里的缺点是，它是非常密集的工作，只有在有理由使用它的情况下才能使用(例如，一篇论文；)

一个一个地列出需求编号和需求行，然后是文本和/或屏幕截图，以证明它是这样做的。

以粗体显示左边的需求编号，然后将需求文本加为斜体。将示例文本/屏幕截图与需求文本对齐，左列只显示需求编号。例：

REQ-1      italicized requirement text

           text discussing how the software has
           fulfilled the requirements, possibly
           with a picture:

           -----------------------
           |                     |
           |                     |
           |                     |
           |                     |
           |                     |
           -----------------------

REQ-2      italicized requirement text

           etc...

您应该根据逻辑程序区域分组为章节或部分，并以关于整个程序区域如何满足需求的模糊信息开始该节或章节(请保持一般性)。