Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
The community reviewed whether to reopen this question 8 months ago and left it closed:
Original close reason(s) were not resolved
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(8)
这很简单。
单元测试:这是由具有编码知识的开发人员实际完成的测试。该测试在编码阶段完成,是白盒测试的一部分。当软件进行开发时,它被开发成称为单元的代码段或代码片。这些单元的单独测试称为单元测试,由开发人员完成,以找出某种人为错误,例如缺少语句覆盖率等。
功能测试:此测试是在测试(QA)阶段完成的,它是测试的一部分黑盒测试。之前编写的测试用例的实际执行。该测试实际上是由测试人员完成的,他们找到站点中任何功能的实际结果,并将该结果与预期结果进行比较。如果他们发现任何差异,那么这就是一个错误。
验收测试:称为 UAT。这实际上是由测试人员以及开发人员、管理团队、作者、作家以及所有参与该项目的人员完成的。确保项目最终准备好交付且没有错误。
集成测试:代码单元(在第 1 点中解释)相互集成以完成项目。这些代码单元可能是用不同的编码技术编写的,也可能是不同的版本,因此此测试由开发人员完成,以确保所有代码单元与其他单元兼容并且不存在任何集成问题。
This is very simple.
Unit testing: This is the testing actually done by developers that have coding knowledge. This testing is done at the coding phase and it is a part of white box testing. When a software comes for development, it is developed into the piece of code or slices of code known as a unit. And individual testing of these units called unit testing done by developers to find out some kind of human mistakes like missing of statement coverage etc..
Functional testing: This testing is done at testing (QA) phase and it is a part of black box testing. The actual execution of the previously written test cases. This testing is actually done by testers, they find the actual result of any functionality in the site and compare this result to the expected result. If they found any disparity then this is a bug.
Acceptance testing: know as UAT. And this actually done by the tester as well as developers, management team, author, writers, and all who are involved in this project. To ensure the project is finally ready to be delivered with bugs free.
Integration testing: The units of code (explained in point 1) are integrated with each other to complete the project. These units of codes may be written in different coding technology or may these are of different version so this testing is done by developers to ensure that all units of the code are compatible with other and there is no any issue of integration.
一些(相对)最近的反对过度模拟和纯粹单元测试的想法:
Some (relatively) recent ideas against excessive mocking and pure unit-testing:
我将用一个实际的例子来解释这一点,而不是理论:
开发人员编写代码。尚未实现 GUI。此级别的测试验证函数是否正常工作以及数据类型是否正确。此阶段的测试称为单元测试。
当开发 GUI 并将应用程序分配给测试人员时,他会与客户端验证业务需求并执行不同的场景。这称为功能测试。在这里,我们将客户需求与应用程序流程进行映射。
集成测试:假设我们的应用程序有两个模块:人力资源和财务。 HR模块之前已交付并测试。现在 Finance 已开发完毕并可供测试。相互依赖的功能现在也可用,因此在此阶段,您将测试两者之间的通信点,并验证它们是否按要求工作。
回归测试是另一个重要的阶段,它是在任何新的开发或错误修复之后完成的。其目的是验证以前工作的功能。
I will explain you this with a practical example and no theory stuff:
A developer writes the code. No GUI is implemented yet. The testing at this level verifies that the functions work correctly and the data types are correct. This phase of testing is called Unit testing.
When a GUI is developed, and application is assigned to a tester, he verifies business requirements with a client and executes the different scenarios. This is called functional testing. Here we are mapping the client requirements with application flows.
Integration testing: let's say our application has two modules: HR and Finance. HR module was delivered and tested previously. Now Finance is developed and is available to test. The interdependent features are also available now, so in this phase, you will test communication points between the two and will verify they are working as requested in requirements.
Regression testing is another important phase, which is done after any new development or bug fixes. Its aim is to verify previously working functions.
单元测试:对应用程序中的单个模块或独立组件进行的测试称为单元测试,单元测试将由开发人员完成。
集成测试:组合所有模块并测试应用程序,以验证模块之间的通信和数据流是否正常工作,此测试也由开发人员执行。
功能测试检查应用程序的各个功能意味着功能测试
验收测试此测试由最终用户或客户完成,无论构建应用程序是否符合客户要求,以及客户规范,这被称为验收测试
unit test: testing of individual module or independent component in an application is known to be unit testing , the unit testing will be done by developer.
integration test: combining all the modules and testing the application to verify the communication and the data flow between the modules are working properly or not , this testing also performed by developers.
funcional test checking the individual functionality of an application is mean to be functional testing
acceptance testing this testing is done by end user or customer whether the build application is according to the customer requirement , and customer specification this is known to be acceptance testing
根据您观察的位置,您会得到略有不同的答案。我读过很多关于这个主题的文章,以下是我的精华;再说一次,这些都有点毛茸茸的,其他人可能不同意。
单元测试
测试最小的功能单元,通常是方法/函数(例如,给定一个具有特定状态的类,在该类上调用 x 方法应该会导致 y 发生)。单元测试应集中于一项特定功能(例如,当堆栈为空时调用 pop 方法应抛出
InvalidOperationException
)。所触及的一切都应该在记忆中完成;这意味着测试代码和被测代码不应该:任何类型缓慢/难以理解/初始化/操作的依赖项应该使用适当的技术进行存根/模拟/任何操作,这样您就可以专注于代码单元正在做什么,而不是它的依赖项做什么。
简而言之,单元测试尽可能简单、易于调试、可靠(由于外部因素减少)、执行速度快,并有助于证明程序的最小构建块在组合在一起之前能够按预期运行。需要注意的是,尽管您可以证明它们可以单独完美地工作,但代码单元在组合时可能会崩溃,这使我们...
集成测试
集成测试通过组合单元构建在单元测试的基础上代码并测试生成的组合是否正确运行。这可以是一个系统的内部结构,也可以将多个系统组合在一起来做一些有用的事情。此外,集成测试与单元测试的另一个区别是环境。集成测试可以并且将会使用线程、访问数据库或执行任何所需的操作,以确保所有代码和不同的环境更改都能正常工作。
如果您已经构建了一些序列化代码并在不接触磁盘的情况下对其内部进行了单元测试,那么您如何知道它在加载和保存到磁盘时是否可以工作?也许您忘记刷新和处置文件流。也许您的文件权限不正确,并且您已经使用内存流测试了内部结构。确定答案的唯一方法是使用最接近生产的环境对其进行“真实”测试。
主要优点是他们会发现单元测试无法发现的错误,例如接线错误(例如,A 类的实例意外收到 B 的空实例)和环境错误(它在我的单 CPU 机器上运行良好,但我的同事的4核机器无法通过测试)。主要缺点是集成测试涉及更多代码、可靠性较低、故障更难以诊断并且测试更难以维护。
此外,集成测试并不一定能证明完整的功能有效。用户可能不关心我的程序的内部细节,但我关心!
功能测试
功能测试通过将给定输入的结果与规范进行比较来检查特定功能的正确性。功能测试不关心中间结果或副作用,只关心结果(他们不关心在执行 x 后,对象 y 具有状态 z)。编写它们是为了测试规范的一部分,例如“使用参数 2 调用函数 Square(x) 返回 4”。
验收测试
验收测试似乎分为两种类型:
标准验收测试涉及在整个系统上执行测试(例如,通过网络浏览器使用您的网页),以查看应用程序的功能是否满足规范。例如,“单击缩放图标应将文档视图放大 25%”。没有真正的连续结果,只有通过或失败的结果。
优点是测试以简单的英语进行描述,并确保软件作为一个整体功能完整。缺点是您已经将测试金字塔提升了另一个级别。验收测试涉及大量代码,因此追踪故障可能很棘手。
此外,在敏捷软件开发中,用户验收测试涉及创建测试来反映软件客户在开发过程中创建的/为软件客户创建的用户故事。如果测试通过,则意味着软件应该满足客户的要求,并且故事可以被认为是完整的。验收测试套件基本上是用特定于域的语言编写的可执行规范,它用系统用户使用的语言描述测试。
结论
它们都是互补的。有时,专注于一种类型或完全避开它们是有利的。对我来说,主要的区别是一些测试从程序员的角度看待事物,而其他测试则以客户/最终用户为中心。
Depending on where you look, you'll get slightly different answers. I've read about the subject a lot, and here's my distillation; again, these are slightly wooly and others may disagree.
Unit Tests
Tests the smallest unit of functionality, typically a method/function (e.g. given a class with a particular state, calling x method on the class should cause y to happen). Unit tests should be focussed on one particular feature (e.g., calling the pop method when the stack is empty should throw an
InvalidOperationException
). Everything it touches should be done in memory; this means that the test code and the code under test shouldn't:Any kind of dependency that is slow / hard to understand / initialise / manipulate should be stubbed/mocked/whatevered using the appropriate techniques so you can focus on what the unit of code is doing, not what its dependencies do.
In short, unit tests are as simple as possible, easy to debug, reliable (due to reduced external factors), fast to execute and help to prove that the smallest building blocks of your program function as intended before they're put together. The caveat is that, although you can prove they work perfectly in isolation, the units of code may blow up when combined which brings us to ...
Integration Tests
Integration tests build on unit tests by combining the units of code and testing that the resulting combination functions correctly. This can be either the innards of one system, or combining multiple systems together to do something useful. Also, another thing that differentiates integration tests from unit tests is the environment. Integration tests can and will use threads, access the database or do whatever is required to ensure that all of the code and the different environment changes will work correctly.
If you've built some serialization code and unit tested its innards without touching the disk, how do you know that it'll work when you are loading and saving to disk? Maybe you forgot to flush and dispose filestreams. Maybe your file permissions are incorrect and you've tested the innards using in memory streams. The only way to find out for sure is to test it 'for real' using an environment that is closest to production.
The main advantage is that they will find bugs that unit tests can't such as wiring bugs (e.g. an instance of class A unexpectedly receives a null instance of B) and environment bugs (it runs fine on my single-CPU machine, but my colleague's 4 core machine can't pass the tests). The main disadvantage is that integration tests touch more code, are less reliable, failures are harder to diagnose and the tests are harder to maintain.
Also, integration tests don't necessarily prove that a complete feature works. The user may not care about the internal details of my programs, but I do!
Functional Tests
Functional tests check a particular feature for correctness by comparing the results for a given input against the specification. Functional tests don't concern themselves with intermediate results or side-effects, just the result (they don't care that after doing x, object y has state z). They are written to test part of the specification such as, "calling function Square(x) with the argument of 2 returns 4".
Acceptance Tests
Acceptance testing seems to be split into two types:
Standard acceptance testing involves performing tests on the full system (e.g. using your web page via a web browser) to see whether the application's functionality satisfies the specification. E.g. "clicking a zoom icon should enlarge the document view by 25%." There is no real continuum of results, just a pass or fail outcome.
The advantage is that the tests are described in plain English and ensures the software, as a whole, is feature complete. The disadvantage is that you've moved another level up the testing pyramid. Acceptance tests touch mountains of code, so tracking down a failure can be tricky.
Also, in agile software development, user acceptance testing involves creating tests to mirror the user stories created by/for the software's customer during development. If the tests pass, it means the software should meet the customer's requirements and the stories can be considered complete. An acceptance test suite is basically an executable specification written in a domain specific language that describes the tests in the language used by the users of the system.
Conclusion
They're all complementary. Sometimes it's advantageous to focus on one type or to eschew them entirely. The main difference for me is that some of the tests look at things from a programmer's perspective, whereas others use a customer/end user focus.
重要的是您知道这些术语对您的同事意味着什么。例如,当不同的群体说“完整的端到端”测试时,他们的定义会略有不同。
我最近在他们的测试中遇到了谷歌的命名系统,我很喜欢它——他们只使用小、中和大来绕过争论。为了确定测试属于哪个类别,他们会考虑几个因素——运行需要多长时间,是否访问网络、数据库、文件系统、外部系统等等。
http://googletesting.blogspot.com/2010/12/test-sizes.html
我想您当前工作场所的小型、中型和大型之间的区别可能与 Google 的有所不同。
然而,这不仅关乎范围,还关乎目的。马克关于测试的不同观点(例如程序员与客户/最终用户)的观点非常重要。
The important thing is that you know what those terms mean to your colleagues. Different groups will have slightly varying definitions of what they mean when they say "full end-to-end" tests, for instance.
I came across Google's naming system for their tests recently, and I rather like it - they bypass the arguments by just using Small, Medium, and Large. For deciding which category a test fits into, they look at a few factors - how long does it take to run, does it access the network, database, filesystem, external systems and so on.
http://googletesting.blogspot.com/2010/12/test-sizes.html
I'd imagine the difference between Small, Medium, and Large for your current workplace might vary from Google's.
However, it's not just about scope, but about purpose. Mark's point about differing perspectives for tests, e.g. programmer vs customer/end user, is really important.
http://martinfowler.com/articles/microservice-testing/
Martin Fowler 的博客文章讲述了测试代码的策略 (特别是在微服务架构中),但其中大部分适用于任何应用程序。
我将引用他的摘要幻灯片:
http://martinfowler.com/articles/microservice-testing/
Martin Fowler's blog post speaks about strategies to test code (Especially in a micro-services architecture) but most of it applies to any application.
I'll quote from his summary slide:
单元测试 - 顾名思义,此方法在对象级别进行测试。测试各个软件组件是否存在任何错误。此测试需要了解程序,并创建测试代码来检查软件是否按预期运行。
功能测试 - 在不了解系统内部工作的情况下进行。测试人员将尝试通过遵循要求、提供不同的输入并测试生成的输出来使用系统。此测试也称为闭盒测试或黑盒测试。
验收测试-这是将软件移交给客户之前进行的最后一个测试。这样做是为了确保开发的软件满足所有客户要求。有两种类型的验收测试 - 一种由开发团队成员执行,称为内部验收测试(Alpha 测试),另一种由客户或最终用户执行,称为(Beta 测试)
集成测试 - 已经经过单元测试的各个模块相互集成。通常遵循两种方法:
1)自上而下
2)自下而上
Unit Testing - As the name suggests, this method tests at the object level. Individual software components are tested for any errors. Knowledge of the program is needed for this test and the test codes are created to check if the software behaves as it is intended to.
Functional Testing - Is carried out without any knowledge of the internal working of the system. The tester will try to use the system by just following requirements, by providing different inputs and testing the generated outputs. This test is also known as closed-box testing or black-box.
Acceptance Testing - This is the last test that is conducted before the software is handed over to the client. It is carried out to ensure that the developed software meets all the customer requirements. There are two types of acceptance testing - one that is carried out by the members of the development team, known as internal acceptance testing (Alpha testing), and the other that is carried out by the customer or end user known as (Beta testing)
Integration Testing - Individual modules that are already subjected to unit testing are integrated with one another. Generally the two approachs are followed :
1) Top-Down
2) Bottom-Up