文件很少时如何提供适当的测试

#1 楼

“玩转”和诸如用户手册之类的文档无疑可以为开发测试提供一个开始，但它们应该仅仅是一个开始。正确测试应用程序正在执行应做的事情需要更多的领域知识。一直在使用该应用程序并且知道该怎么做的最终用户可以成为创建测试的良好来源。应用程序的要求或早期规范也可能有助于生成测试。为了确保利益相关者实际上从测试中获得了他们想要的东西（并确保您没有测试错误的假设），一旦计划了测试，则请求管理者/利益相关者应批准并签字批准测试。

#2 楼

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

我将提出一个数字关于事物为何如此的假设，并加以记录。然后，我将接受这些假设，并由我能选的任何人进行检查，最好是主题专家，利益相关者和最终用户。

因此，我实质上记录了这些假设，这些假设用于需求量中并对齐我的对他们进行测试。

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

#3 楼

有条理地，有意地接近应用程序会产生大量您需要的信息。
从简单的问题开始-任何应用程序都应该/几乎肯定会在显示屏上显示最常用的功能-遵循菜单一会儿。开始映射您知道应用程序具有的功能。只有设计最糟糕的软件才会隐藏其最重要的功能（我从未见过这种情况）。

通过与软件利益相关者交谈来获取信息-要求功能开发人员进行快速演示，如果您与最终用户/项目发起人联系，请与项目经理讨论该项目应该取得什么样的成功，并讨论对他们而言重要的事情。抓住一切机会，从与您合作的每个项目涉众那里学习。

借助您自己的经验或使用Google来了解应用程序或项目发起人的直接竞争对手是什么，从而获取领域知识。 >
问一个应用程序问题，您认为它应该可以回答。注意响应。跟随另一个问题。然后是另一个问题。从应用程序为您提供的答案中构建更好的问题。

如果除了您的直觉之外，真的没有什么可以创建测试的，您可能会发现错过了。还要从这些经验中学习-确保您的测试从这些经验中学习。鼓励与您一起工作的开发团队从这些经验中学习。

沟通您需要哪些资源，以便随着时间的推移以及在连续的项目中进行有效测试，您应该开始发现需要做的事情将开始提供有效的测试。不断提供有关您获得的支持，信息和应用程序的建设性反馈。永不停止学习，永不停止教书。

另外，我也不同意上面关于敏捷项目的陈述，因为这些陈述没有提供足够的文档。以我的经验，敏捷项目针对重点和相关性提供了更好的文档。
如果您发现自己正在接受针对敏捷项目进行测试的应用程序，却不知道该做什么，请意识到您可能不在敏捷项目中。

#4 楼

首先，寻找一般要求并进行记录。这些要求中的一些来自应用程序的早期版本，一些来自公认的用法。例如：


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

如果是网站或应用程序，则一些其他要求可能包括：


一定不要丢失任何图像
不得有任何断开的链接
在公司正式支持的所有浏览器中，基本上都必须使用相同的功能。

，然后，与项目经理或开发人员进行面谈，以了解他们打算如何使用此版本。记录意图并将其用作需求。

从项目的任何利益相关者那里征求意见。与所有人共享您发现的所有内容，并根据需要进行修改。

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

产品是否存在销售材料？当然，该产品应该按照这些材料的说明进行操作。

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

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

找出产品内部是否一致。 （这是我认为非常有用的领域）即使我对产品一无所知，我也认为它必须在其内部以及在其必须运行的环境中保持一致。

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

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

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

#5 楼

这是软件开发中极为普遍的问题。组织中有许多测试资源：支持团队，最终用户，文档编写者和错误数据库。利用这些资源来帮助确定潜在的问题区域和常见用例，以使您的测试更加集中。

#6 楼

我们的团队通过让测试人员在线创建Wiki页面或在开发人员创建的现有Wiki规范上创建问答部分来开始解决此问题。在规范中询问有关模糊区域的所有问题，并在此处记录所有答案。如果您得到“脱机”答案，则可以在此处进行记录，然后向提供该信息的人发送电子邮件，并可能与其他感兴趣的参与者（例如，开发人员，企业所有者）联系，要求他们验证您是否记录了信息正确地。测试人员每隔一段时间（至少每天一两天，可能会更频繁，具体取决于公司的文化），将电子邮件发送到问答页面的链接发送给业务负责人，开发人员，适当的管理人员等，直到所有问题都得到解决为止输入电子邮件中的关键问题。

我发现随着人们对测试人员提出的问题的预期，该过程的使用更加广泛，规范开始得到改进。开发人员开始从企业主那里获得更好的规格（或任何规格！），并且更好地理解了测试的延迟，因为没有人会合理地期望您在没有良好信息的情况下进行测试。

#7 楼

正确的方法是：进行探索性测试，了解业务需求和影响，与程序员，客户互动，使用您自己的知识来正确处理事情。
例如。对于购物车网站，您可以检查amazon.com如何用于各种常用功能，例如产品搜索，展示等。

#8 楼

这取决于您的大脑如何连接。我个人从画图开始。阅读文档并浏览该站点之后，我想对我对产品的了解进行图解。我拿起最大的纸，可以找到并绘制产品管理的实体，实体之间的关系，用户角色，这些用户执行的操作的图表。在绘制图表时，我会遇到我不理解的问题。我保留了这些问题的列表，一旦列表足够长，我就会找到可以帮助我解决这些问题的专家。 （如果每次遇到问题都会打扰到别人，则可能会惹恼他们。）

如果专家有时间，请向他们显示图表。您可能会花时间去理解产品，这可能会给他们留下深刻的印象，并且这可能告诉他们值得花时间回答您的问题。他们也许也能够发现错误或遗漏。 （他们甚至可能会索要一份副本。）当然，如果产品很大，您可能没有时间来绘制整个图。没关系;您可以从老板要求您专注的部分开始。

一旦有了图，将高级测试计划和单个测试用例放在一起要容易得多。

#9 楼

沟通与探索。我没有任何文件或文件很少就可以开始我的每个项目。我的方法如下：


弄清楚（与团队中的某人进行探索和初步培训）产品应该做什么-轻松的路
弄清楚产品的关键部分
经常与开发人员，产品人员和其他团队成员进行交谈
了解产品的用户是谁，以及公司试图为构建给定产品的用户提供哪些服务。
如果该产品已经存在了一段时间，请找出对断裂敏感度更高的模块。

这有助于进行健全性测试。然后一次取一个模块，并扩展测试。

随手编写文档，测试用例不必冗长，您可以最初跳过详细的步骤-主要目标是记录所需内容待验证。这些初始TC可以用作学习平台，清单和用于记录未记录规范的参考。

#10 楼

是的，其他人基本上都写了。同样，当您在AGILE项目中时，将遇到尽可能少的文档。因此，您必须在如何测试应用程序方面发挥创意。

以上都是很好的起点，也是从零开始的想法。基本上，您必须与人交谈，并通常承担一些事情。

但是！疲倦！测试人员从不承担任何责任，也从不相信任何事情。始终确保您对一项功能有多种看法。