软件测试概述

软件测试是对软件根据从用户和系统规范收集的需求进行评估。在软件开发生命周期的阶段级别或程序代码的模块级别进行测试。软件测试包括验证（Validation）和确认（Verification）。

软件验证（Validation）

验证是检查软件是否满足用户需求的过程。它在 SDLC 结束时进行。如果软件符合其开发需求，则视为已验证。

• 验证确保正在开发的产品符合用户需求。
• 验证回答问题：“我们是否正在开发满足用户对该软件所有需求的产品？”
• 验证强调用户需求。

软件确认（Verification）

确认是确认软件是否满足业务需求，并按照适当的规范和方法开发的过程。

• 确认确保正在开发的产品符合设计规范。
• 确认回答问题：“我们是否严格遵循所有设计规范开发此产品？”
• 确认关注设计和系统规范。

测试的目标包括 -

• 错误（Errors） - 这些是开发者实际的编码错误。此外，软件输出与预期输出不一致也被视为错误。

• 故障（Fault） - 当错误存在时就会发生故障。故障，也称为 bug，是错误的结果，可能导致系统失败。

• 失败（Failure） - 失败是指系统无法执行预期任务。当系统中存在故障时，就会发生失败。

手动测试与自动化测试

测试可以手动进行，也可以使用自动化测试工具进行：

• 手动（Manual） - 此测试不借助自动化测试工具进行。软件测试人员为代码的不同部分和级别准备测试用例，执行测试并向经理报告结果。

  手动测试耗时且占用资源。测试人员需要确认是否使用了正确的测试用例。测试的主要部分涉及手动测试。

• 自动化（Automated） 此测试是借助自动化测试工具进行的测试过程。手动测试的局限性可以通过自动化测试工具克服。

一个测试需要检查网页是否能在 Internet Explorer 中打开。这可以通过手动测试轻松完成。但要检查 web-server 是否能承受 100 万用户的负载，手动测试几乎不可能。

有一些软件和硬件工具可以帮助测试人员进行负载测试、压力测试和回归测试。

测试方法

测试可以基于两种方法进行

• 功能性测试
• 实现性测试

当测试功能性时而不考虑实际实现，这被称为 black-box testing。另一侧被称为 white-box testing，不仅测试功能性，还分析其实现方式。

穷尽测试是完美测试的最佳方法。对输入值和输出值范围内的每一个可能值进行测试。如果值范围很大，在现实场景中不可能测试每一个值。

Black-box testing

它用于测试程序的功能性，也称为行为测试。在这种情况下，测试人员拥有一组输入值及其相应的期望结果。提供输入后，如果输出与期望结果匹配，则程序测试通过，否则有问题。

在这种测试方法中，测试人员不知道代码的设计和结构，测试工程师和最终用户对软件进行此测试。

Black-box testing 技术：

• Equivalence class - 将输入分为相似的类。如果一个类的元素通过测试，则假设整个类通过。

• Boundary values - 将输入分为高值和低值端点。如果这些值通过测试，则假设中间的所有值也可能通过。

• Cause-effect graphing - 在前两种方法中，一次只测试一个输入值。Cause（原因，输入）Effect（结果，输出）是一种测试技术，以系统方式测试输入值的组合。

• Pair-wise Testing - 软件的行为依赖于多个参数。在 pairwise testing 中，将多个参数两两组合测试其不同值。

• State-based testing - 系统在提供输入时改变状态。这些系统基于其状态和输入进行测试。

White-box testing

它用于测试程序及其实现，以提高代码效率或结构，也称为结构测试。

在这种测试方法中，测试人员知道代码的设计和结构。代码的程序员对代码进行此测试。

以下是一些 White-box testing 技术：

• Control-flow testing - control-flow testing 的目的是设置测试用例，覆盖所有语句和分支条件。分支条件被测试为 true 和 false，以便覆盖所有语句。

• Data-flow testing - 这种测试技术强调覆盖程序中包含的所有数据变量。它测试变量在哪里声明和定义，以及在哪里使用或更改。

测试级别

测试本身可以在 SDLC 的各个级别定义。测试过程与软件开发并行进行。在进入下一个阶段之前，会对当前阶段进行测试、验证和确认。

单独进行测试是为了确保软件中没有隐藏的 bug 或问题。软件会在各个级别进行测试 -

Unit Testing

在编码过程中，程序员会对该程序单元执行一些测试，以确认其无误。测试采用 white-box testing 方法。Unit testing 帮助开发者确认程序的各个独立单元是否按照需求正常工作且无误。

Integration Testing

即使软件的各个单元单独工作正常，也需要检查这些单元集成在一起后是否仍能无误运行。例如，参数传递和数据更新等。

System Testing

软件被编译成产品，然后作为一个整体进行测试。这可以通过以下一种或多种测试来实现：

• Functionality testing - 根据需求测试软件的所有功能。

• Performance testing - 此测试证明软件的效率。它测试软件完成预期任务的有效性和平均用时。Performance testing 通过 load testing 和 stress testing 进行，在各种环境条件下对软件施加高用户和数据负载。

• Security & Portability - 当软件需要在各种平台上运行并被多人访问时，进行这些测试。

Acceptance Testing

当软件准备交给客户时，需要经过最后一阶段测试，检查用户交互和响应。这很重要，因为即使软件满足所有用户需求，如果用户不喜欢其外观或工作方式，也可能被拒绝。

• Alpha testing - 开发团队自己使用系统像在工作环境中一样进行 alpha testing。他们尝试找出用户对软件中某些操作的反应，以及系统对输入的响应方式。

• Beta testing - 软件内部测试完成后，会交给用户在他们的生产环境中仅用于测试目的使用。这还不是最终交付的产品。开发者期望用户在此阶段会发现那些被忽略的细微问题。

Regression Testing

每当软件产品用新代码、功能或特性更新时，都需要彻底测试，以检测新增代码是否有负面影响。这称为 regression testing。

测试文档

测试文档在不同阶段准备 —

测试前

测试从用例生成开始。以下文档需要作为参考

• SRS document - 功能需求文档

• Test Policy document - 该文档描述了在产品发布前测试应进行的程度。

• Test Strategy document - 该文档详细说明了测试团队的各方面、责任矩阵以及测试经理和测试工程师的权利/责任。

• Traceability Matrix document - 这是 SDLC 文档，与需求收集过程相关。随着新需求的到来，它们会被添加到这个矩阵中。这些矩阵帮助测试人员了解需求来源。它们可以向前和向后追溯。

测试进行中

测试开始并进行时，可能需要以下文档：

• Test Case document - 该文档包含需要执行的测试列表。它包括 Unit test plan、Integration test plan、System test plan 和 Acceptance test plan。

• Test description - 该文档是对所有测试用例及其执行程序的详细描述。

• Test case report - 该文档包含测试结果的测试用例报告。

• Test logs - 该文档包含每个测试用例报告的测试日志。

测试后

测试后可能生成以下文档：

• Test summary - 该测试摘要是对所有测试报告和日志的集体分析。它总结并得出软件是否准备好发布的结论。如果软件准备好发布，则在 version control system 下发布软件。

测试与质量控制、质量保证和审计的区别

我们需要理解，软件测试不同于软件质量保证、软件质量控制和软件审计。

• Software quality assurance - 这些是软件开发过程监控手段，通过这些手段确保按照组织标准采取所有措施。这种监控是为了确保遵循了正确的软件开发方法。

• Software quality control - 这是一个维护软件产品质量的系统。它可能包括软件产品的功能性和非功能性方面，这些方面提升了组织的声誉。该系统确保客户收到符合其需求的高质量产品，并且产品被认证适合使用。

• Software audit - 这是对组织用于开发软件的程序的审查。一个独立于开发团队的审计团队检查软件过程、程序、需求以及 SDLC 的其他方面。软件审计的目的是检查软件及其开发过程是否都符合标准、规则和法规。