需求测试

Question

我刚刚完成我的软件系统的实施，现在我必须记录它是否满足其要求。我应该包括哪些信息，我应该如何布置它？

我最初的功能性和非功能性需求是在一个两列的表，看起来是这样的：

• FN-01的系统应该允许用户 私人信息发送到每个 等。
• NFN-03设置/配置 窗体应包含大多数字段的合理默认值 值。

Answer 1

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

用粗体左边的要求编号，然后将要求文本标签和斜体。将校样文本/屏幕截图与需求文本对齐，只留下需求编号的左栏。 EG：

REQ-1  italicized requirement text 

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

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

REQ-2  italicized requirement text 

      etc... 

你应该组成章节或部分基于逻辑方案领域，并开始与一个对整个项目区如何满足需求的Blurb的部分或章节（是普通

Answer 2

我会继续它的简单，并添加下列：

• 交付满意的要求 - 一个下拉含是，否列表，打开
• 评论 - 关于交付任何评论，如“需要取消细邮件大小”，‘不能完全满足该消息的布局，而是由客户端’等
• 完成日期接受 - 当改变交付
• 日期满足 - 当变更被接受

随着使用要求的ID中，我假设他们重新指向包含更详细的信息，包括布局，屏幕截图的文档等

Answer 3

我就已经在使用的要求编号方案到位，而不是创建一个新的。我会记录每个要求的下列项目：

1. 的需求状态：这可以在许多不同的方式来表述，但你tyring沟通，如果完成的要求，因为上市，完成的经修饰的变什么被列入名单或根本无法完成。
2. 要求注释：描述先前列出的需求状态。这就是“为什么”能解释那些不能完全满足要求的项目。
3. 完成日期：这主要用于未来的产品规划，但也作为历史参考。

几个其他点要记住：

1. 要求可以由客户进行审查，特别是如果客户是要求的来源。因此，这份文件需要尽可能准确和翔实。 （这也是另一个原因，除非必须，否则不要更改需求编号方案。）
2. 您的测试部门（假设您有测试部门）应该使用这些文档进行测试计划，并且他们需要知道需求是否满足哪些不是最重要的哪些改变了，怎么改变。

最后，除非您正在为某人展示狗和小马秀，否则您不需要截图作为需求文档的一部分。你也不需要提供完成的“证明”。测试部门将为您做到这一点。

Answer 4

我们通常会制定一个测试计划，如果满意，每个项目都可以打勾。该计划将基于原始要求（功能性或非功能性），例如：

要求：用户帐户应在三次尝试使用不正确的密码登录后锁定。

测试：尝试使用不正确的密码登录超过三次。用户帐户现在是否被锁定？

我们会为每个需求做这件事，并重新运行每个候选发布者的计划。一些测试是自动化的，但我们也有一个测试团队来执行手动测试！

根据运行这些测试计划和用户验收测试的结果，我们会将RC签名为正确并适合发布。

请注意，即使测试计划中的某些项目未通过，我们有时也会签署发布，这一切都取决于项目的性质！

Answer 5

验证需求的正式方法是测试 - 通常是验收测试。

这个想法是：对于每一个需求，应该有一个或多个测试来验证需求。在正式的开发情况下，客户在签署要求的同时签署验收测试。

然后，当产品完成后，您会在接受最终产品之前提交验收测试结果和客户评审结果。

如果您有要求无法测试，那么他们可能写得不好。

例如不要说“加载文件应该很快”，比如说“一个大小为X的文件应该在Z的硬件上加载不超过Y毫秒”或类似的东西。

Answer 6

有一些技术可以将您的需求转换为测试用例。 但这些取决于您的要求如何记录。 如果您已经完成了基于场景的需求分析，那么这将非常容易：只需为您的场景的每个路径创建一个序列图，写/做一个测试 - >完成。 除了这种方式创建的文档也应该打动你的讲师。

如果你没有方案，你应该创建一些你的用例。

的这里缺点是，它是非常密集的工作，应该只有在证明其使用的情况下使用（论文例如;））