所以我的问题是，有没有办法在没有任何领域知识的情况下测试完整的闪存产品？
#1 楼
是的，有办法。接受需求/规范（无论您叫什么），并证明软件是否符合要求。
评论
只是增加一点：可以从类似产品（例如Lotus和Word都是文字处理器），错误报告等推断出需求。
– dzieciou
18年1月2日在6:35
@NitinRastogi没有人说这很容易。这确实取决于您的域。如果它是来自许多人熟悉或直观使用的领域的应用程序，则可能更易于识别和测试。如果您正在测试微控制器而完全不了解微控制器，那么难度就更大了。您不能吃一个cookie但仍然拥有该cookie，即您需要学习一个域，即投入一些时间，金钱，资源等。
– dzieciou
18年1月2日在6:42
@NitinRastogi正如您所说-您没有任何领域知识。那么为什么要哲学化它是否重要呢？
–嵌入式
18年1月2日，6：50
@NitinRastogi不是“如果”，而是“他们是”。时间，金钱和其他资源总是有限的。
–嵌入式
18年1月2日，下午6:52
谁创建了规范？他们在领域和软件方面都具有5年以上的经验吗？如果没有，说明是错误的，并且在不了解域的情况下，您将无法在规范中找到错误，因此无法在最终软件中找到错误。
– wedstrom
18年1月2日在22:20
#2 楼
使用探索性测试。
探索性测试教程。
这是使用探索性测试的理想情况。同时进行探索，设计和测试。
设定期望值：首先，对您的公司就您的领域知识设定正确的期望值。
保持好奇心。根据常识/经验问自己有关产品功能的问题并通过设计测试并执行来找出答案。
逻辑上的进步：每个问题/答案都将带您进入下一个逻辑问题。
时间框会话：进行时间框（我做40分钟）密集的会话并做简单的笔记在此过程中观察到的意见。
所需工具：记事本（个人身体偏爱！）
提出问题而不是缺陷，并向业务分析师/产品负责人确认您的理解。
评论
我不同意，除非您有非常非常耐心的客户。作为领域专家，当您了解系统并寻找意外的东西时，探索性测试就很棒。但这是一种学习系统的可怕方法，因为您几乎肯定会做出很多无效的假设，并打开许多无效的缺陷。即使您将其视为问题，客户在这种情况下也要比我怀疑的要复杂得多，在这种情况下，他们正尝试将测试外包。
–凯文·麦坚时（Kevin McKenzie）
18年1月2日在23:14
凯文（Kevin）让我明白，您是说探索性测试仅适用于领域专家吗？
– Vishal Aggarwal
18年1月2日在23:17
在这种情况下，可以。原来的海报显然是为一家要求测试产品的外包公司工作的。他们没有产品的内部知识。他们可以通过探索性测试来学习产品吗？是的，但是这样做时，他们必须对产品的工作原理做出假设。您必须有一个先知。您可以成为自己的预言家，并猜测产品的工作方式，但是您可能会错过问题或发现许多无效问题。在这种情况下，我不清楚客户是否会接受。
–凯文·麦坚时（Kevin McKenzie）
18年1月2日在23:23
@KevinMcKenzie我同意这是学习系统的一种糟糕方法，但是以我的经验，即使是具有领域知识的用户也像蹒跚学步一样使用应用程序。因此，让一个不知道自己在做什么的人来测试它会突出显示用户可以并且会犯错误的领域，这些错误是领域知识本可以避免的。 “您提交了不加禁止的foo？当然坏了！在他们的头脑中没有人会提交不加禁止的foo！”
–corsiKa♦
18年1月3日在16:17
凯文（Kevin），我曾遇到过类似的情况，当拥有零域知识的熟练测试员开始系统/方法地询问团队中哪些领域专家难以回答时，我会感到惊讶。尽管如此，它需要出色的测试技能，信心和勇于开口。
– Vishal Aggarwal
18年1月4日，11：59
#3 楼
没有领域知识的测试需要遵循需求和测试脚本。仅仅报告对测试人员没有基础知识的“怪异”的事情，将导致报告如此多的误报，从而错误报告毫无用处。我有这种方法的第一手经验（在没有基础领域知识的情况下由测试人员测试产品），而在我之前的一个项目中，管理层希望通过一堆毫无知识的实习生对我们的应用程序进行测试来节省资金而且没有培训。他们报告了许多错误的问题（反复：他们甚至没有能力/没有经过培训/预期看到其他人已经报告过同一问题），因此对经过分类的问题进行报告成为了训练有素的专家的全职工作（最好花一些时间）测试中）。几天后就放弃了整个实验，很明显，这是解决问题的错误方法。
因此，如果必须这样做并保留客户，则需要内置内部领域的专业知识，快速：利用您已经掌握的知识对测试人员进行培训，对问题进行分类（这样您就不会报告重复的问题），并将从报告的错误中学到的所有知识都传播给测试人员。
#4 楼
有可能吗？也许。有可能做得好吗？这取决于。首先，您需要一个预言机，即一种确定在任何给定情况下正确行为是什么的方法。之前已经有一些关于需求规范的参考。那将是一个很好的起点，但很可能还不够，因为这样的事情通常会遗漏很多隐含的需求。
接下来，您需要一种方法来对问题进行优先级划分和对测试进行优先级划分。否则，您可能会花时间在无关紧要的事情上。
现在举个例子，似乎有人在给您一个黑匣子，并告诉您对其进行测试。因此，您要做的第一件事是将其放在地板上，然后爆炸。那是个错误吗？可能是，也可能不是。也许应该是炸弹，所以爆炸是好的。但是，也许只有当它以一定速度撞击物体时才会爆炸，在这种情况下，您需要验证该要求。没有甲骨文，您甚至无法开始测试。或者，也许您放下它并爆炸，这是不应该的，但是它永远只能在水下使用，因此您需要首先关注其与水下物体的相互作用。
至少，您需要获取尽可能多的文档。手册，任何先前的测试用例或测试方案，设计文档，问题数据库等。这可能不够，也可能不够。您需要与开发人员建立非常密切的关系，因为您将通过询问问题或打开无效的bug或同时使二者烦恼。
坦白地说，考虑到您之前说的话，不仅您不具备领域知识，没有时间，金钱或能力来雇用任何人，您的前进道路也非常艰辛。而且我会确保客户理解这一点。在公司内部，您需要讨论在公司内部进行不太可能顺利进行的风险是否值得，并且需要大量投资。而且，如果您在此项目上构建的领域知识可以转移到其他地方，也可以不转移到其他地方，以防其他公司改变主意。
#5 楼
37个测试思路的来源可能会对您有所帮助，但是，如果我在您的位置，我会坚持至少拥有一些领域知识。在链接中关注这些思想和其他答案只是获得这一领域通过随时随地学习知识。
我会尝试并提供一个更扎实的起点，例如参加短期课程或与有适当知识的人交谈。
评论
优秀的测试思路，必须阅读...！
– Vishal Aggarwal
18年4月17日在21:21
#6 楼
告诉客户您缺乏测试其产品的专业知识。认真。如果不告诉他们，这会使您自己和他们处于严重的风险中。
例如，请考虑一下，如果您的问题是这样，将会有什么影响已提交法院证据。
您的个人资料表明您是一个尽职的人。现在要认真。告诉客户您缺乏测试其产品的专业知识。
#7 楼
无法测试的内容如果您从字面上（字面意义上）拥有零域知识，则无法测试以下内容：
您不能测试任何产品要求，因为您不知道该怎么办，也无法测试从产品需求中得出的任何需求。
可以测试的内容
有很多基本的东西您可以进行测试：
您可以执行自动渗透测试和应用扫描以检测任何安全漏洞
您可以测试并验证部署是否成功完成
测试任何安装/卸载过程
您可以测试Web应用程序的浏览器兼容性（通过比较浏览器之间的结果；即使您不知道结果是否正确，也可以判断结果是否不同）。同样，您可以测试桌面应用程序的O / S兼容性，或测试移动应用程序的设备兼容性。
如果可以设法弄清楚如何执行基本流程，则可以执行负载和压力测试。 />您可以评估HTML5格式正确的任何标记
您可以评估WCAG，WAI或508法规遵从性的任何页面
因此您可以进行很多测试。您只是无法测试功能行为是否正确:)
您可以进行哪些测试
您可以以幼稚用户的角色执行探索性测试，如果您的最终用户是非专业人士，则大概也将具有非常有限的领域知识。将其视为可用性测试（而不是严格的功能测试），因为这种努力将帮助您和您的客户了解应用程序的行为对于典型的最终用户是否有意义（可用）。
做好准备但是，由于许多行为看起来像缺陷，但实际上是可以预料的，因此尤其是在边缘情况下，例如，处于锁定状态的用户或试图做某事的人。
#8 楼
我的看法是通过尝试不同的方案进行探索性测试（在没有任何有关业务和功能的知识的情况下进行测试）。当您开始使用这种方法时，它将引起一些问题，例如测试人员将不会上载错误，并且会花费更多的时间来理解和获取有关应用程序的知识。如果为应用程序找到了任何帮助文件，将减少时间并减少“不是bug”的问题。#9 楼
我已经在这里看到了许多好主意。我会补充-问一下，也许您知道有人正在/正在使用类似的产品。一旦我不得不测试簿记软件，我问我的朋友，簿记员，他的工作有什么重要意义。
另一个很棒的来源是Google :)在那里您能找到令人惊奇的东西！
评论
客户是否已提供供您遵循的测试计划，还是希望您也编写测试计划？执行现有的测试计划可以在没有太多领域知识的情况下完成，但是创建一个计划可能并不合理。