手动测试

手动测试是一种软件测试过程，其中，无需使用任何自动化工具即可手动执行测试用例。测试人员将根据最终用户的角度手动执行所有测试用例。它确保应用程序是否正常运行(如需求文档中所述)。计划并实施了测试用例，以完成几乎100％的软件应用程序。测试用例报告也是手动生成的。

手动测试是最基本的测试过程之一，因为它可以发现软件的可见和隐藏缺陷。由软件给出的预期输出与输出之间的差异被定义为缺陷。开发人员修复了缺陷，并将其交给测试人员进行重新测试。

在进行自动测试之前，必须对每个新开发的软件进行手动测试。此测试需要大量的精力和时间，但可以确保没有错误的软件。手动测试需要具备手动测试技术知识，而无需任何自动化测试工具。

手动测试是必不可少的，因为软件测试的基本原则之一是“不可能实现100％自动化”。

为什么我们需要手动测试

只要应用程序进入市场，并且在最终用户使用它时不稳定，出现错误或问题或造成问题。

如果我们不想面对此类问题，则需要执行一轮测试，以使应用程序无漏洞且稳定，并向客户提供高质量的产品，因为如果应用程序无漏洞，则最终用户将更方便地使用该应用程序。

如果测试工程师进行手动测试，则他/她可以从最终用户的角度测试应用程序，并更加熟悉产品，这有助于他们编写正确的应用程序测试用例并提供应用程序的快速反馈。

手动测试的类型

手动测试有多种方法。每种技术均根据其测试标准使用。手动测试的类型如下：

• 白盒测试
• 黑匣子测试
• 灰箱测试

白盒测试

白盒测试由开发人员完成，开发人员在检查代码的每一行之前，将其提供给测试工程师。由于代码在测试过程中对开发人员可见，因此也称为白盒测试。

有关白盒测试的更多信息，请参考以下链接：

https://www.javatpoint.com/white-box-testing

黑匣子测试

黑匣子测试由测试工程师完成，他们可以根据客户/客户的需求检查应用程序或软件的功能。这样，在执行测试时代码是不可见的。这就是为什么它被称为黑盒测试。

有关黑盒测试的更多信息，请参考以下链接：

https://www.javatpoint.com/black-box-testing

灰盒测试

灰盒测试是白盒测试和黑盒测试的组合。可以由熟悉编码和测试的人员执行。如果单人执行该应用程序的白盒测试以及黑盒测试，则称为灰盒测试。

要获取有关灰盒测试的更多详细信息，请参考以下链接：

https://www.javatpoint.com/grey-box-testing

如何执行手动测试

• 首先，测试人员观察与软件有关的所有文档，以选择测试区域。
• 测试人员分析需求文档以涵盖客户说明的所有需求。
• 测试人员根据需求文档开发测试用例。
• 所有测试用例都是使用黑盒测试和白盒测试手动执行的。
• 如果发生错误，则测试团队会通知开发团队。
• 开发团队修复了错误并将软件交给测试团队进行重新测试。

软件构建过程

• 一旦需求被收集，它将提供给两个不同的团队开发和测试团队。
• 获得要求后，有关的开发人员将开始编写代码。
• 同时，测试工程师了解需求并准备所需的文档，到目前为止，开发人员可以完成代码并存储在Control Version工具中。
• 之后，代码在UI中发生更改，并且这些更改由一个单独的团队(称为构建团队)处理。
• 该构建团队将获取代码，并在构建工具的帮助下开始编译和压缩代码。一旦我们得到一些输出，输出就会进入zip文件中，该文件称为Build (应用程序或软件)。每个Build都有一些唯一的编号，例如(B001，B002)。
• 然后，此特定版本将安装在测试服务器中。之后，测试工程师将在“测试URL”的帮助下访问该测试服务器，并开始测试应用程序。
• 如果测试工程师发现任何错误，则会向相关开发人员报告。
• 然后，开发人员将在测试服务器中重现该错误，并修复该错误，然后将代码再次存储在Control版本工具中，它将安装新的更新文件并删除旧文件；持续进行此过程，直到获得稳定的Build。
• 一旦我们获得了稳定的版本，它将被移交给客户。

注1

• 从Control版本工具收集文件后，我们将使用构建工具将代码从高级语言编译为机器语言。编译后，如果文件大小增加，那么我们将压缩该特定文件并转储到测试服务器中。
• 此过程由构建团队，开发人员(如果没有构建团队，开发人员可以做到)或测试负责人(如果构建团队直接处理zip并将应用程序安装到测试服务器并通知测试工程师)完成。 。
• 通常，我们无法为每个错误获取一个新的Build。否则，大多数时间只会浪费在创建构建上。

笔记2

建立团队

构建团队的主要工作是创建应用程序或Build，并将高级语言转换为低级语言。

建立

它是软件，用于将代码转换为应用程序格式。它包括一组功能和错误修复，这些功能和错误修复已移交给测试工程师以进行测试，直到变得稳定为止。

控制版本工具

它是一种软件或应用程序，用于以下目的：

• 在此工具中，我们可以保存不同类型的文件。
• 它始终是安全的，因为我们使用相同的登录凭据从工具访问文件。
• 这些工具的主要目的是跟踪对现有文件所做的更改。

构建过程示例

让我们看一个示例，以了解如何在真实场景下构建流程工作：

一旦测试工程师发现错误，他们就会将其发送给开发人员，他们需要一些时间来进行分析。之后，他/她仅修复错误(测试工程师无法提供错误的集合)。

开发人员根据他们的时间决定可以修复多少个错误。然后确定测试工程师，首先应根据他们的需要修复哪个错误，因为测试工程师无力停止测试。

而测试工程师收到邮件后，他们只能知道该错误修复列表已修复了哪个错误。

时间会增加，因为在第一次构建时，开发人员应该以不同的功能编写代码。最后，他/她只能修复错误，并且天数会减少。

注3

测试周期

测试周期是给予测试工程师测试每个Build的持续时间。

两者之间的差异

在一个版本中发现的错误，可以在将来的任何版本中修复，这些错误取决于测试工程师的要求。每个新的Build是旧版本的修改版本，这些修改可能是错误修复或添加了一些新功能。

我们获得新版本的频率

最初，我们曾经获得每周一次的构建，但是在测试的最新阶段，当应用程序变得稳定时，我们过去也每三天，两天或每天一次获得新的构建。

我们得到多少个建筑

如果考虑任何项目工期的一年，我们将获得22-26个版本。

修复错误后

通常，我们仅在测试周期完成后才了解错误修复，或者在一个内部版本中修复了错误集合，并在下一个内部版本中进行了移交。

手动测试的优点

• 使用黑匣子方法时，不需要编程知识。
• 它用于测试动态更改的GUI设计。
• Tester以真实用户的身份与软件进行交互，以便他们能够发现可用性和用户界面问题。
• 它确保该软件百分百无缺陷。
• 具有成本效益。
• 对于新测试人员来说很容易学习。

手动测试的缺点

• 它需要大量的人力资源。
• 这非常耗时。
• 测试人员根据其技能和经验来开发测试用例。没有证据表明它们涵盖了所有功能。
• 测试用例不能再次使用。需要为每个新软件开发单独的测试用例。
• 它不提供测试的所有方面的测试。
• 由于两个团队一起工作，有时很难理解彼此的动机，因此可能会误导该过程。

手动测试工具

在手动测试中，在单元，集成，安全性，性能和错误跟踪等不同类型的测试中，我们提供了多种工具，例如Bugzilla ，Mantis，Zap，NUnit，Tessy，LoadRunner，Citrus，SonarQube等。市场。有些工具是开源的，有些是商业的。

有关测试工具的更多信息，请参考以下链接：

https://www.javatpoint.com/software-testing-tools