您将如何对各种软件测试方法进行分类？
这是正确的吗？
黑匣子
1.1 功能
1.1.1 等价 1.1.2 BVA 1.1.3 使用案例 1.1.4 回归 1.1.5 终端测试1.2 非功能性
1.2.1 测试系统设计白盒
2.1。 功能性
<前><代码> 2.1.1 单位 2.1.2 集成 2.1.3 系统
以上是否属于正确的类别？
我问这个问题的原因是因为作为报告的一部分，我试图提供一个很好的参考，对测试技术进行了很好的分类。 这就是我对各种来源的分析和研究给我的结果。 我希望这对可能正在进行相同研究的其他人有所帮助，但如果它不正确，则应该更新。
Would this be right??
Black Box
1.1 Functional
1.1.1 Equivalence 1.1.2 BVA 1.1.3 Use case 1.1.4 Regression 1.1.5 UAT1.2 Non Functional
1.2.1 Testing the System DesignWhite box
2.1. Functional
2.1.1 Unit 2.1.2 Integration 2.1.3 System
Do the above fall under the right categories?
The reason I ask this is because as a part of a report I was trying to come up with a good reference that categorised Test Techniques well. This is what my analysis and research from various sources gave me. And I hope this is helpful for someone else who might be doing the same research, but if its incorrect it should be updated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您还可以考虑同时开发多个相互依赖的程序的情况。 然后，您必须考虑应用架构，它将所有这些应用程序分组为多个功能域
因此，例如，金融应用程序必须处理大量数据将是一个功能域，您必须在其中开发一个：
但这只是一个功能域，因为必须开发其他功能域才能利用结果 em> 您的程序（例如，“参考域”将在那里将这些结果存储到各种数据库中，并为其他程序访问它们提供通信总线：这将是第二个功能域）。
因此，我将向您的测试添加以下类别：
注意：“集成测试”与“持续集成测试”不同，“持续集成测试”基本上可以处理您所描述的黑白测试，对于一个程序，在一个非常定期。
我所指的测试由您所在域的“项目运营架构”团队每周执行几次，
注意：“运营架构”团队的角色是“使执行环境可操作”，这意味着：与
简而言之：您的类别适用于一个程序，但是当您开发IS（信息系统）时，您被迫承认这样一个事实：您不是在谈论“一个 > 由一个团队开发的、部署在一个生产机器上的exe”...然后，欢迎来到一个全新的测试世界；）
You might also consider the case when several programs depending one on another are developed simultaneously. You have then to take into account the applicative architecture which groups all those applications into several functional domains
So, for instance, a financial application having to process a large number of data would be one functional domain, in which you would have to develop a:
But that would only be one functional domain, as others would have to be developed in order to exploit the results of your programs (for instance, a "referential domain" would be there to store those results into various databases, and offer a communication bus for other programs to access them: that would be a second functional domain).
So I would add to your tests the following categories:
Note: "integration testing" is not the same as "continuous integration testing", which basically can process the black and white tests you describe, for one program, on a very regular basis.
The tests I am referring to are executed a few times a week by an:
Note: an "Operation Architecture" team has the role to "make operational an execution environment", meaning to have:
In short: your categories are for one program, but when you are developing an IS (Information System), you are forced to acknowledge the fact that you are not talking about "one exe developed by one team deployed on one production machine"... and then, welcome to an all new world of testing ;)
我认为你的分类是一个很好的第一步。
黑盒和白盒（有些人更喜欢玻璃盒）之间的分离测试重点在于您是否只能访问规范或更多（设计、源代码）。
我会在功能测试和结构测试之间添加第二个分离，重点是您是否要考虑软件的功能（功能）或软件的功能（结构）。
第三种分离涉及如何确定性或统计性地生成测试输入（具有故意分布而不是随机分布）。 无论哪种方式，您的重点都是您的目标覆盖范围。
最后，众所周知的分离是不同级别的软件周期之间的：单元测试、集成、系统、验收……
I think that your categorisation is a good first step.
Separation between black box and white box (some prefer glass box) testing focuses on whether you have access only to the specification or more (design, source code).
I would add a second separation between functional and structural testing, which focuses on whether you want to consider what the software does (functional) or how it does it (structural).
A third separation deals with how you generate test inputs, deterministically or statistically (with a deliberate distribution and not randomly). Either way, your focus is on what coverage you target.
Finally a well known separation is between different levels of software cycle: unit testing, integration, system, acceptance, ...
以下是软件测试中广泛定义的测试方法：
1. 黑盒测试是一种软件测试方法，其中测试人员不知道被测试项目的内部结构/设计/实现。 这些测试可以是功能性的，也可以是非功能性的，但通常是功能性的。 测试设计技术包括：等价划分、边界值分析、因果图。
2. 白盒测试是一种软件测试方法，其中测试人员已知被测试项目的内部结构/设计/实现。 测试设计技术包括：控制流测试、数据流测试、分支测试和路径测试。
3. 灰盒测试是黑盒测试方法和白盒测试方法相结合的一种软件测试方法。
Following are the Testing methodologies broadly defined in the Software Testing:
1. Black Box Testing is a software testing method in which the internal structure/design/implementation of the item being tested is not known to the tester. These tests can be functional or non-functional, though usually functional. Test design techniques include: Equivalence partitioning, Boundary Value Analysis, Cause Effect Graphing.
2. White Box Testing is a software testing method in which the internal structure/design/implementation of the item being tested is known to the tester. Test design techniques include: Control flow testing, Data flow testing, Branch testing, and Path testing.
3. Gray Box Testing is a software testing method which is a combination of Black Box Testing method and White Box Testing method.