“玩转”和用户手册之类的文档绝对可以为开发测试提供一个开始，但它们应该只是一个开始。正确测试应用程序是否正在做它应该做的事情需要更多的领域知识。一直在使用该应用程序并知道它应该做什么的最终用户可以成为创建测试的良好来源。应用程序的需求或早期规范也有助于生成测试。为了确保利益相关者从测试中真正得到他们想要的东西（并确保您没有测试错误的假设），一旦计划了测试，提出请求的经理/利益相关者应该批准并签署测试.

我常用的一种策略是，我将戴上“最终用户”的帽子，然后像测试已部署给公众的应用程序一样测试系统。

我将对事物为什么会这样作一些假设，并记录下来。然后，我将接受这些假设，并让我能做到的人（最好是主题专家、利益相关者和最终用户）对其进行检查。

所以本质上我会记录假设，这些假设用于要求的替代品，并使我的测试与它们保持一致。

虽然这远非理想，但至少我可以完成一些工作。

有条不紊地、有目的地处理应用程序可以产生大量您需要的信息。从简单的问题开始 - 任何应用程序都应该/几乎肯定会在明显的显示上具有最常用的功能 - 关注菜单中的每个选项一段时间。开始映射您知道该应用程序具有哪些功能。只有设计最差的软件才会隐藏其最重要的功能（我从未见过这种情况发生）。

通过与软件利益相关者交谈来获取信息 - 要求功能开发人员进行快速演示，与项目经理讨论该项目的成功应该是什么样子，如果您与最终用户/项目发起人联系，讨论什么对他们来说很重要. 抓住每一个机会向与您合作的每个项目利益相关者学习。

获取领域知识也许可以通过借鉴您自己的经验或使用 Google 找出应用程序或项目发起人的直接竞争对手是什么。

问一个您认为它应该能够回答的应用程序问题。记下响应。跟随这个问题。然后另一个问题。从应用程序为您提供的答案中构建更好的问题。

如果除了你的直觉之外真的没有什么可以创建测试的，你可能会发现有些东西被遗漏了。也从这些经验中学习——确保你的测试从这些经验中学习。鼓励与您合作的开发团队从这些经验中学习。

沟通您需要哪些资源才能有效测试，随着时间的推移和连续的项目，您应该开始发现您需要有效测试的东西将开始提供。继续就您收到的支持、信息和申请提供建设性反馈。永远不要停止学习，永远不要停止愿意教书。

另外，我不同意上面关于敏捷项目提供的文档不足的说法。根据我的经验，敏捷项目提供了更好的文档，因为它专注、切题且相关。如果你发现你的应用程序要在敏捷项目上进行测试，而你不知道它的用途是什么，请意识到你可能不在敏捷项目中。

首先，寻找一般要求并努力记录它们。其中一些要求来自应用程序的早期版本，一些来自普遍接受的用法。例如：

• 必须在 x,​​y,z 平台上运行（可能是因为这些平台一直都受支持）
• 必须使用 abc 数据库
• 必须能够在 m 秒内处理 n 条记录
• 必须至少与版本 n - 1 一样快
• 不得消耗比释放 n - 1 更多的内存（或其他资源）
• 不得崩溃
• 不得损坏数据
• 必须使用与平台相关的标准（例如标准 Windows UI）
• 必须符合相关法律、法规或商业惯例
• 不得有任何拼写错误
• 必须语法正确
• 必须包含公司通常的外观和感觉
• 必须内部一致
• 必须在特定地区工作
• 必须在利益相关者期望的情况下完成（可能对于某些事件，例如 Beta）

如果它是一个网站或应用程序，一些额外的要求可能包括：

• 不得遗漏任何图像
• 不得有任何损坏的链接
• 在公司官方支持的所有浏览器中必须基本相同

然后，采访项目经理或开发人员，了解他们打算如何使用此版本。记录意图并将其用作要求。

征求项目利益相关者的意见。与所有人分享您找到的所有内容，并根据需要进行修改。

产品是否有帮助文件或用户指南？如果是这样，那是很好的需求来源。

产品是否存在销售材料？当然，产品应该按照这些材料所说的去做。

有时，将所有这些都写成假设可以大大有助于就您可以用来测试的“真实需求”达成共识。

一旦系统完全可测试，请进行一些探索性测试。当您发现“未记录的功能”时，将它们添加到要讨论的主题列表中。

查明产品是否内部一致。（这是我发现非常有用的一个领域）即使我对产品一无所知，我认为它必须在自身内部以及在它​​必须运行的环境中保持一致。

寻找产品必须在其中运行的外部标准。如果是税收或会计计划 - 必须以税法为准，并且必须适用公认的会计原则。

理想情况下，所有这些问题都已被考虑并写入提交给您的正式需求文档中。但如果没有，请不要放弃。挖掘并发现！

http://strazzere.blogspot.com/2010/04/there-are-always-requirements.html