软件测试[2](Guru99软件测试教程翻译！！！)

软件测试（2）:软件测试的分类

单元测试：

Mock Objects

Unit Testing Tools

• Jtest: Parasoft Jtest是一个IDE插件，它利用了开源框架(Junit、Mockito、PowerMock和Spring)，以及用于创建、扩展和维护单元测试的一键操作。通过自动化单元测试的这些耗时方面，开发人员可以将精力集中在业务逻辑上，并创建更有意义的测试套件。

• Junit: Junit是一个用于Java编程语言的免费测试工具。它提供断言来识别测试方法。这个工具先测试数据，然后插入到代码中。

• NUnit: NUnit广泛用于所有。net语言的单元测试框架。它是一个开源工具，允许手工编写脚本。它支持可以并行运行的数据驱动测试。

• JMockit: JMockit是开源单元测试工具。它是带有行和路径度量的代码覆盖工具。它允许使用记录和验证语法模拟API。这个工具提供线覆盖、路径覆盖和数据覆盖。

• EMMA: EMMA是一个用于分析和报告用Java语言编写的代码的开源工具包。Emma支持覆盖类型，比如方法、行、基本块。它是基于java的，所以它没有外部库依赖，可以访问源代码。

• PHPUnit: PHPUnit是PHP程序员的单元测试工具。它取一小部分代码，称为单元，并分别对它们进行测试。该工具还允许开发人员使用预定义的断言方法来断言系统以某种方式运行。

Extreme Programming & Unit Testing

极限编程&单元测试

测试是在代码之前编写的

严重依赖测试框架

应用程序中的所有类都经过测试

快速和容易的集成成为可能

单元测试的神话：

Unit Testing Techniques

结构技术

功能测试技术

基于误差的技术

Unit Testing Best Practices

• Unit Test cases should be independent. In case of any enhancements or change in requirements, unit test cases should not be affected.

• Test only one code at a time.

• Follow clear and consistent naming conventions for your unit tests

• In case of a change in code in any module, ensure there is a corresponding unit Test Case for the module, and the module passes the tests before changing the implementation

• Bugs identified during unit testing must be fixed before proceeding to the next phase in SDLC

• Adopt a “test as your code” approach. The more code you write without testing, the more paths you have to check for errors.

• 单元测试用例应该是独立的。在需求的任何增强或变更中，单元测试用例不应该受到影响。

  每次只测试一个代码。

  为单元测试遵循清晰一致的命名约定

  如果任何模块中的代码发生了更改，请确保该模块有相应的单元测试用例，并且该模块在更改实现之前通过了测试

  在进行SDLC的下一个阶段之前，必须修复单元测试期间识别的错误

  采用“测试为代码”的方法。没有测试就编写的代码越多，检查错误的路径就越多。

Integration Testing

集成测试的重点是检查这些模块之间的数据通信。

因此，它也被称为“I & T”(集成和测试)，“字符串测试”，有时是“线程测试”。

为什么要做集成测试？

• 模块一般由单个软件开发人员设计，他们的理解和编程逻辑可能与其他程序员不同。集成测试对于验证软件模块在unity中的工作是必要的

• 在模块开发时，客户的需求很可能发生变化。这些新的需求可能不会被单元测试，因此系统集成测试是必要的。

• 软件模块与数据库的接口可能是错误的

• 外部硬件接口(如果有的话)可能是错误的

• 不适当的异常处理可能导致问题。

集成测试用例与其他测试用例的区别在于它主要关注模块之间的数据/信息的接口和流。这里优先考虑的是集成链接，而不是已经测试过的单元功能。

案例1：

下面场景的示例集成测试用例:应用程序有3个模块，分别是“登录页面”、“邮箱”和“删除邮件”，每个模块逻辑集成。

Test Case ID	Test Case Objective	Test Case Description	Expected Result
1	Check the interface link between the Login and Mailbox module	Enter login credentials and click on the Login button	To be directed to the Mail Box
2	Check the interface link between the Mailbox and Delete Mails Module	From Mail box select the an email and click delete button	Selected email should appear in the Deleted/Trash folder

集成测试的策略：

• 大爆炸的方法:

• 增量法:进一步分为以下几种

• 自顶向下方法

• 自底向上的方法

• 夹层方法-自顶向下和自底向上的组合

大爆炸的方法:

这里所有的组件都被集成在一起，然后进行测试。

优点:

方便的小系统。

缺点:

故障定位是很困难的。

考虑到在这种方法中需要测试的接口的绝对数量，一些需要测试的接口链接很容易被忽略。

由于集成测试只能在“所有”模块被设计好之后才开始，测试团队在测试阶段执行的时间就会减少。

由于所有模块都是一次性测试的，因此高风险关键模块不会被隔离并在优先级上进行测试。处理用户界面的外围模块也不是独立的，并根据优先级进行测试。

增量的方法:

在这种方法中，测试是通过连接两个或多个逻辑相关的模块来完成的。然后，添加其他相关模块并测试其正常功能。这个过程一直持续到所有的模块都被成功地连接和测试。

这个过程是通过使用称为存根和驱动程序的虚拟程序来执行的。存根和驱动程序并没有实现软件模块的全部编程逻辑，只是模拟了与调用模块的数据通信。

Stub:由被测模块调用。

驱动程序:调用要测试的模块。

增量法依次采用两种不同的方法:

自底向上

自顶向下

自底向上集成

在自底向上策略中，在较低级别的每个模块都要用较高级别的模块进行测试，直到所有模块都被测试。测试需要驱动测试

优点:

故障定位更容易。

没有时间浪费在等待所有模块被开发不像大爆炸方法

缺点:

控制应用程序流的关键模块(在软件体系结构的顶层)最后进行测试，可能会出现缺陷。

早期的原型是不可能的

优点:

故障定位更容易。

获得早期原型的可能性。

对关键模块进行优先级测试;主要的设计缺陷可以发现并首先修复。

缺点:

需要许多存根。

较低级别的模块测试不充分。

Integration Testing Procedure

1. Prepare the Integration Tests Plan
2. Design the Test Scenarios, Cases, and Scripts.
3. Executing the test Cases followed by reporting the defects.
4. Tracking & re-testing the defects.
5. Steps 3 and 4 are repeated until the completion of Integration is successfully.

Brief Description of Integration Test Plans:

• Methods/Approaches to test (as discussed above).
• Scopes and Out of Scopes Items of Integration Testing.
• Roles and Responsibilities.
• Pre-requisites for Integration testing.
• Testing environment.
• Risk and Mitigation Plans.

Best Practices/ Guidelines for Integration Testing

• First determine the Integration Test Strategy that could be adopted and later prepare the test cases and test data accordingly.
• 首先确定可以采用的集成测试策略，然后相应地准备测试用例和测试数据。
• Study the Architecture design of the Application and identify the Critical Modules. These need to be tested on priority.
• 研究应用程序的体系结构设计，识别关键模块。这些需要在优先级上进行测试。
• Obtain the interface designs from the Architectural team and create test cases to verify all of the interfaces in detail. Interface to database/external hardware/software application must be tested in detail.
• 从架构团队获得接口设计，并创建测试用例来详细验证所有接口。必须详细测试数据库/外部硬件/软件应用程序的接口。
• After the test cases, it’s the test data which plays the critical role.
• 在测试用例之后，测试数据扮演了关键角色。
• Always have the mock data prepared, prior to executing. Do not select test data while executing the test cases.
• 总是在执行之前准备好模拟数据。在执行测试用例时，不要选择测试数据

System Testing

它们的唯一目的是测试整个基于计算机的系统。

系统测试属于软件测试的黑盒测试类别。

白盒测试是对软件应用程序内部工作或代码的测试。相反，黑盒或系统测试则相反。系统测试涉及到从用户的角度看软件的外部工作。

系统测试包括测试下面的软件代码

• 测试包括外部外围设备在内的完整集成应用程序，以检查组件之间以及与系统作为一个整体的交互方式。这也称为端到端测试场景。

• 验证应用程序中每个输入的完整测试，以检查所需的输出。

• 测试用户对应用程序的体验。

• 这是对系统测试所涉及内容的一个非常基本的描述。您需要构建详细的测试用例和测试套件，以测试从外部看到的应用程序的每个方面，而不必查看实际的源代码

下面是按时间顺序排列的软件测试类别列表。以下是为准备销售新软件而全面测试新软件所采取的步骤:

• 单元测试——在开发过程中对每个模块或代码块执行的测试。单元测试通常由编写代码的程序员完成。

• 集成测试——将新模块集成到主软件包之前、期间和之后进行的测试。这涉及到对每个代码模块的测试。一个软件可以包含几个模块，这些模块通常由几个不同的程序员创建。测试每个模块对整个程序模型的影响是至关重要的。

• 系统测试-由专业的测试代理在软件产品上市之前对其进行测试。

• 验收测试-由实际最终用户完成的产品的beta测试。

不同类型的系统测试：

• 可用性测试Usability Testing ——可用性测试主要关注用户使用应用程序的便捷性、处理控件的灵活性和系统达到目标的能力
• 负载测试Load Testing ——负载测试对于了解软件解决方案将在实际负载下执行是必要的。
• 回归测试Regression Testing——回归测试涉及到测试，以确保在开发过程中所做的任何更改都不会导致新的bug。它还确保随着时间的推移，新软件模块的添加不会出现旧的bug。
• 恢复测试Recovery Testing——恢复测试是为了证明软件解决方案是可靠的、值得信赖的，并且能够从可能的崩溃中成功恢复。
• 迁移测试Migration Testing ——迁移测试是为了确保软件可以从较旧的系统基础结构转移到当前的系统基础结构，而不会出现任何问题。
• 功能测试Functional Testing——也被称为功能完整性测试，功能测试涉及考虑任何可能的缺失功能。测试人员可能会列出产品在功能测试期间需要改进的其他功能。
• 硬件/软件测试Hardware/Software Testing —IBM将硬件/软件测试称为“HW/SW测试”。这时，测试人员将注意力集中在系统测试期间硬件和软件之间的交互上。

Sanity Testing Vs Smoke Testing

健全测试与冒烟测试：

软件构建：

如果您正在开发一个仅由一个源代码文件组成的简单计算机程序，您只需编译并链接这个文件，就可以生成一个可执行文件。这个过程很简单。

通常情况并非如此。一个典型的软件项目由数百甚至数千个源代码文件组成。从这些源文件创建可执行程序是一项复杂而耗时的任务。

你需要使用“构建”软件来创建一个可执行程序，这个过程被称为“软件构建”。

冒烟测试：

烟雾测试是在软件构建后进行的一种软件测试，用于确定程序的关键功能运行良好。它是在软件构建上执行任何详细的功能测试或回归测试之前执行的。其目的是拒绝一个严重损坏的应用程序，以便QA团队不浪费时间安装和测试软件应用程序。

在冒烟测试中，选择的测试用例覆盖了系统最重要的功能或组件。目标不是执行详尽的测试，而是验证系统的关键功能是否正常工作。

例如，典型的冒烟测试是—验证应用程序是否成功启动，检查GUI是否响应…等。

健全测试：

完整性测试是在接收到软件构建之后执行的一种软件测试，在代码或功能上有微小的更改，以确定bug已经被修复，并且不会因为这些更改而带来进一步的问题。目标是确定所提议的功能大致按照预期工作。如果完整性测试失败，则拒绝构建，以节省更严格测试所涉及的时间和成本。目标“不是”彻底验证新功能，而是确定开发人员在生产软件时应用了一些合理性(健全)。例如，如果你的科学计算器给出的结果是2 + 2 =5!那么，测试sin30 + cos50这样的高级函数就没有意义了。

Smoke Testing Vs Sanity Testing - Key Differences

Smoke Testing	Sanity Testing
烟雾测试是为了确定程序的关键功能运行良好	健全测试是为了检查新的功能/ bug已经修复
这次测试的目的是验证系统的“稳定性”，以便进行更严格的测试	测试的目的是验证系统的“合理性”，以便进行更严格的测试
这个测试是由开发人员或测试人员执行的	健全测试通常由测试人员执行
烟雾测试通常是文档化或脚本化的	健全测试通常没有文档化，也没有脚本
烟雾测试是验收测试的一个子集	完整性测试是回归测试的一个子集
烟雾测试从头到尾测试整个系统	健全测试只测试整个系统的特定组件
吸烟测试就像一般的健康检查	健全测试就像专门的健康检查

完整性测试也称为测试人员验收测试。

在特定构建上执行的烟雾测试也称为构建验证测试。

最好的行业实践之一是在软件项目中进行每日构建和冒烟测试。

冒烟测试和健全测试都可以手动执行或使用自动化工具。当使用自动化工具时，测试通常由生成构建本身的相同过程启动。

根据测试的需要，您可能必须在软件构建上执行健全测试和冒烟测试。在这种情况下，您将首先执行冒烟测试，然后进行健全测试。在工业中，用于健全测试的测试用例通常与用于冒烟测试的测试用例相结合，以加速测试执行。因此，这是一个常见的术语经常混淆和互换使用。

Regression Testing

回归测试定义为一种软件测试，用于确认最近的程序或代码更改没有对现有特性产生不利影响。

回归测试不过是对已经执行的测试用例的全部或部分选择，这些测试用例被重新执行，以确保现有功能正常工作。

这个测试是为了确保新的代码更改不会对现有的功能产生副作用。它确保在完成新代码更改后，旧代码仍然可以工作。

Need of Regression Testing

当存在a时，需要进行回归测试

• 根据需求修改需求和代码

• 软件增加了新功能

• 缺陷修复

• 性能问题解决

软件维护是一项活动，包括改进、错误纠正、优化和删除现有功能。这些修改可能会导致系统工作不正确。因此，回归测试是必要的。回归测试可以使用以下技术进行:

Retest All

这是回归测试的一种方法，在这种方法中，现有测试桶或套件中的所有测试都应该重新执行。这是非常昂贵的，因为它需要大量的时间和资源。

Regression Test Selection

与其重新执行整个测试套件，不如选择要运行的测试套件的一部分

所选择的测试用例可以归类为

1)可重用的测试用例

2)过时的测试用例。

可重用的测试用例可以用于后续的回归周期。

过时的测试用例不能用于后续的循环。

Prioritization of Test Cases(测试用例优先级)

根据业务影响、关键功能和常用功能对测试用例进行优先级排序。基于优先级的测试用例的选择将大大减少回归测试套件。

为回归测试选择测试用例

从行业数据中发现，客户报告的大量缺陷是由于在最后一分钟错误修复产生了副作用，因此选择测试用例进行回归测试是一种艺术，并不是那么容易。有效的回归测试可以通过选择下面的测试用例来完成

• 经常有缺陷的测试用例

• 用户更容易看到的功能

• 验证产品核心特性的测试用例

• 功能的测试用例经历了更多和最近的变化

• 所有集成测试用例

• 所有复杂的测试用例

• 边界值的测试用例

• 成功测试用例的示例

• 失败测试用例的样本

Regression Testing Tools

• Selenium:这是一个用于自动化web应用程序的开源工具。Selenium可以用于基于浏览器的回归测试。

• Quick Test Professional (QTP): HP Quick Test Professional是一种自动化软件，用于自动化功能测试和回归测试用例。它使用VBScript语言来实现自动化。它是一个基于关键字的数据驱动工具。

• Rational Functional Tester (RFT): IBM的Rational Functional Tester是一个Java工具，用于自动化软件应用程序的测试用例。这主要用于自动化回归测试用例，它还与Rational test Manager集成。

回归测试和配置管理

• 正在进行回归测试的代码应该在配置管理工具下进行

• 在回归测试阶段，不允许修改代码。回归测试代码必须不受开发人员更改的影响。

• 用于回归测试的数据库必须隔离。不允许更改数据库

下面是做回归测试的主要测试问题:

随着连续的回归运行，测试套件变得相当大。由于时间和预算的限制，整个回归测试套件不能执行

最小化测试套件同时实现最大的测试覆盖率仍然是一个挑战

回归测试频率的确定，即在每次修改或每次构建更新或修复一堆bug之后，都是一个挑战。

Non-functional Testing

非功能测试是检查软件应用程序的非功能方面(性能、可用性、可靠性等)的测试。它的设计目的是根据功能测试从未处理过的非功能参数测试系统的准备情况。

非功能测试的一个很好的例子是检查有多少人可以同时登录到一个软件。

非功能测试与功能测试同等重要，影响客户满意度。

1. 非功能性测试的目标

   非功能测试应该提高产品的可用性、效率、可维护性和可移植性。

   有助于降低产品非功能性方面的生产风险和成本。

   优化产品的安装、安装、执行、管理和监控方式。

   收集和生产内部研究和开发的度量和度量。

   提高和提高产品行为和使用中的技术的知识。

2. 非功能性测试的特点

   非功能测试应该是可测量的，所以没有地方进行主观的特性描述，比如好的、更好的、最好的等等。

   在需求过程开始时，不太可能知道确切的数字

   对需求进行优先排序很重要

   确保正确识别质量属性

3. 非功能性测试参数

   

   ​

4. 测试类型

   

   ​

5. 非功能性测试类型

Non-functional Testing Types

• Performance Testing性能测试

• Load Testing负载测试

• Failover Testing故障转移测试

• Security Testing安全性测试

• Compatibility Testing兼容性测试

• Usability Testing可用性测试

• Stress Testing压力测试

• Maintainability Testing可维护性测试

• Scalability Testing可伸缩性测试

• Volume Testing容量测试

• Security Testing安全性测试

• Disaster Recovery Testing灾难恢复测试

• Compliance Testing遵从性测试

• Usability Testing可用性测试

• Portability Testing可移植性测试

• Efficiency Testing效率测试

• Reliability Testing可靠性测试

• Baseline Testing基线测试

• Endurance Testing耐力测试

• Documentation Testing文档测试

• Recovery Testing恢复测试

• Internationalization Testing国际化测试

• Localization Testing本地测试

  ​