您将如何对各种软件测试方法进行分类？

Question

这是对的吗？

1. 黑匣子

   1.1功能

       1.1.1 Equivalence
       1.1.2 BVA
       1.1.3 Use case
       1.1.4 Regression
       1.1.5 UAT
   

   1.2非功能性

       1.2.1 Testing the System Design
   

2. 白盒

   2.1。功能

          2.1.1 Unit
          2.1.2 Integration
          2.1.3 System
   

上述内容属于正确的类别吗？

我之所以这样说，是因为作为报告的一部分，我试图提出一个很好的参考，将测试技术分类。这是我从各种来源的分析和研究给了我的。我希望这对其他可能正在进行相同研究的人有所帮助，但如果不正确则应该更新。

Answer 1

您可能还会考虑同时开发多个依赖于另一个的程序的情况。然后，您必须考虑 applicative architecture ，它将所有这些应用程序分组到多个功能域

因此，例如，必须处理大量数据的财务应用程序将是一个功能域，您必须在其中开发：

• 调度程序模块，以便在多台计算机上处​​理这些数据
• GUI以查看正在发生的事情
• 启动程序，以启动正确的连接，检索正确的数据并格式化它们
• 等

但这只是一个功能域，因为必须开发其他域才能利用程序的结果（例如，“参考域” “将那些结果存储到各种数据库中，并为其他程序提供访问它们的通信总线：这将是第二个功能域。”

所以我会在测试中添加以下类别：

• 程序集测试：在您自己的功能域中进行测试时（在部署域的不同应用程序时，使用一组测试数据在组装服务器上进行测试）
• 集成测试：当您测试 来自所有功能域的所有应用 时，也称为 前端到最终测试 。

注意：“集成测试”与“持续集成测试”不同，后者基本上可以处理您描述的黑白测试，对于 一个 程序，定期。

我所指的测试每周执行几次：

• “项目运营架构”您所在域的团队进行汇编测试：通常是团队的一些开发人员设置汇编服务器，检查数据是否是最新的并部署各种计划你负责发展。
• “生产运营架构”团队，负责设置“类似生产”的环境，谁是唯一能够真正测试所有应用程序链的人从字体到背面。

注意：“操作架构”团队的角色是“使操作成为执行环境”，这意味着：

• 正确的物流团队联系，以便拥有合适的服务器和网络，
• 正确的应用程序团队联系人，以了解所有系统应用程序的各种启动/停止应用程序流程和部署过程！

简而言之：您的类别适用于一个程序，但是当您开发IS（信息系统）时，您不得不承认您不是在谈论“一个由部署在一台生产机器上的一个团队开发的“......然后，欢迎来到一个全新的测试世界;）

Answer 2

我认为你的分类是一个很好的第一步。

黑盒和白盒（有些更喜欢玻璃盒）测试之间的分离关注的是你是否只能访问规范或更多（设计，源代码）。

我会在功能测试和结构测试之间添加第二个分离，重点在于您是否要考虑软件的功能（功能）或它是如何实现的（结构）。

第三种分离处理如何生成测试输入，确定性或统计性（具有故意分布而非随机分布）。无论哪种方式，您的重点都放在目标覆盖范围上。

最后，众所周知的分离是在不同级别的软件周期之间：单元测试，集成，系统，验收......

Answer 3

以下是软件测试中广泛定义的测试方法：

<强> 1。黑盒测试是一种软件测试方法，其中测试项目的内部结构/设计/实现不为测试人员所知。这些测试可以是功能性的或非功能性的，但通常是功能性的。测试设计技术包括：等价划分，边界值分析，原因效果图。

<强> 2。白盒测试是一种软件测试方法，其中测试项目的内部结构/设计/实现是测试人员已知的。测试设计技术包括：控制流测试，数据流测试，分支测试和路径测试。

第3。灰盒测试是一种软件测试方法，是黑盒测试方法和白盒测试方法的结合。