您应该先进行哪种类型的测试？

#1 楼

如其他评论所述，第一步是分析产品和需求，一旦了解了产品的预期功能和测试范围，该过程通常会演变如下：

探索性测试：

我们在哪里导航和使用该产品，以了解有关“被测系统”的更多信息。在这里，我们了解了该产品，并确定了可能适用于测试环境的可能的测试方案（“由于测试取决于上下文，因此所有可能的方案都不适用于所有产品”）测试：

一种测试方法是测试人员尝试在不了解产品的情况下使用随机动作破坏系统。猴子测试可能是愚蠢的，聪明的或聪明的，每一个都定义了测试人员的产品和领域知识水平。

临时测试：

一种集中的方法，使用从上述方法中学到的产品设计和要求来破坏系统。

API功能和非功能测试（集成测试）：

这是您开发用于API功能测试的测试用例的系统方法。测试用例通常是手动完成的，然后是自动化的，也可以像TDD方法那样直接自动化。

GUI测试（系统测试）系统，以确保将所有系统集成在一起后，系统可以整体工作。 UI自动化，手动测试用例都在此之下。

非功能测试：

通过安全性，压力和负载测试来确保系统健壮性的测试方法

注意：非功能测试可以纳入任何测试级别。不一定经过系统测试后

我们主要使用烟雾测试和健全性测试来确保我们获得的用于测试的构建具有足够的资格进行进一步严格的测试。对于我们不了解的应用程序，它并没有完成。

烟雾测试：

一种测试方法，仅测试要实现的系统的关键功能确保这些关键功能稳定且不会破坏。 ）。这里对所有常用功能（例如页面导航，登录等）进行了测试，以确保产品正常运行，并可以用于进一步的严格测试。
验证对一项功能的修复不会破坏另一项功能。因此，您将运行测试以涵盖所有功能，并确保在添加或修复某些东西后它们可以正常工作

重新测试：

测试缺陷修复程序以验证报告的缺陷/ issue确实是固定的

#2 楼

自然，这取决于。

您将首先进行哪种类型的测试？

如果您长时间使用此产品，则可能需要关注了解其功能。

这里的目标不是发现问题，而是学习以改善您的产品组件的心理模型。

游览，更具体地说是特色游览：


他建议的第一个是特色游览。在功能介绍中，
您只需浏览应用程序，熟悉所遇到的所有
控件和功能。您会问一些简单的问题，例如
“这是什么，它做什么？”此导览一次有效地利用一个因素（或OFAAT）进行启发式操作。测试案例等。

从那里，您的心理模型可用于进行风险评估；这将指导您将来的测试。

但是，如果您的工作时间较短，那么您可能会受到情况的更多指导。在2015年软件测试世界杯上，我的团队只有3个小时与移动应用程序进行交互。

我们自然进行了一些测试之旅，但我们的策略更着重于可用性启发式-根据说明来自客户端-和兼容性问题，因为我们知道Android中的碎片问题，并且iPhone应用程序是本机的，与Android并行开发。

#3 楼

当发布用于测试的版本时，我们执行的第一个测试是BVT（版本验证测试）或冒烟测试。有时BVT中断，构建失败的原因有很多，例如测试用例编码错误，自动化套件错误，基础结构错误，硬件故障，连接故障等。

#4 楼

在面试中，是否允许您提出问题？开发从未发布给客户？还是将新代码添加到现有产品中？
是什么类型的应用程序（工作产品，游戏等）？
应用程序的目标受众是谁？
会有多少人得到该应用程序？
何时设置发布？

经过几次面试，如果候选人足够周到，有条理，能够提出问题并收集更多信息，就会比其他刚加入答案的人更引人注意。

#5 楼

如果对您来说是全新的，那么这是进行可用性测试的好时机。

直到您知道它是如何工作的，应该做什么，用例是什么...好，什么

想一想，这个问题可能旨在确定您知道多少种测试。不同类型的测试及其效用每年都在变化。因此，这个问题是放在顶层抽屉中的一个好问题。

#6 楼

您以前从未见过，它绝对是新的。


我想说，以上内容将随后进行的测试视为探索性测试。除了您的感觉告诉您的内容之外，您还没有任何类型的地图或任何有关地形的知识，就被带进了一个未知的荒野中，并且您有责任带回尽可能多的信息。您是一位探险家。

#7 楼

“据我了解，他们在一般的功能和非功能测试中都提到过，但是当我说功能（使用文档）时，他们说我错了。”和其他人一样，我想集中讨论他们的断言，即您的回答是错误的，我认为是他们的两个选择，即功能性和非功能性。

如果他们的问题包括某种形式的压缩时间表-或根本不包括任何时间表，尽管由于通常的dev蠕变而在任何项目结束时都使用了压缩测试时间表，那么将会至少在这两者之间有一定的上下文可供选择。两种选择。假设这对我来说是一个有效的断言，他们问了一个相当自由的问题，试图找出您的想法，这只能是一个有效的方案（或在您面试的工作环境中使用），如果该应用程序的测试计划压缩，结果让您感冒。如果他们说有压缩的测试计划，我会说我将一部分时间用于非功能性测试（查找明显的UI问题和可用性方面），并将一部分时间用于在审查文档后进行有针对性的功能测试。帮助指出了受测应用程序的最重要功能，以确保基本功能正常运行。

#8 楼

对我来说，方法是双重的。


首先，要找出重要的是什么


/关键/基本功能是在任何情况下都可以在AUT中安装。（无论是探索性测试，还是使用文档，如果有的话）。


其次，确保它可以正常工作/>
通过烟雾测试。

这是我的第一步，在确认它可以在基本的基本水平上使用后，我们可以进一步深入研究不同的水平。

#9 楼

假设此应用程序（或其部署-在其运行的地方）将来会发生变化，那么您需要知道更改或部署是否起作用或破坏该应用程序。您通常想非常全面地了解。因此，您需要自动化测试，因此我将从编写自动化测试开始。我会按以下顺序写信给他们：


单元测试。验证它们是否存在，因为应用程序开发人员应该已经编写了它们，并且它们还可以帮助提供用于编写​​其他更高级别测试的文档。
吸烟测试。快速且易于编写。通常最有价值。页面加载。该函数存在，等等。
快乐路径测试。确保应用程序在更改后可以正常工作
悲伤路径测试。确保考虑到错误路径和情况。
性能和（对于UI）最终用户可用性（非功能性）

#10 楼

好吧，当您说没有可用的文档或参考文献时，这有点含糊。这就是测试本质上成为启发式的地方。您可以先确保以下内容：


不应该断开任何链接
在访问应用程序的任何部分时不会出现服务器错误
确保从URL正确重定向链接
确保正确的行业标准验证
确保跨应用程序理解消息错误
确保跨应用程序没有拼写错误
确保跨主要浏览器的支持

这些仅仅是一些示例来开始测试一个全新的应用程序。请在上述内容中添加更多内容。谢谢！