冒烟测试 Smoke Test
我很喜欢这个名字，它的来源很有意思。Smoke Test是从电子硬件测试来的，表示第一次对硬件原型prototype加电时，如果硬件冒烟了，就表示产品有问题。
从smoke test名字的来由我们就可以看出，smoke test是比较初级的测试(a quick test)，仅仅是为了检查各个组件是否能一起工作，而并不去深究功能上是否正确。
A simple integration test where we just check that when the system under test is invoked it returns normally and does not blow up.
注意smoke test一般是大范围的集成测试。通常可以是整个系统/端到端的测试。
例如，一个项目：客服人员在终端上输入用户的信息，最终用户可以在互联网上查询到自己的信息。
此时的smoke test就可以是在终端上输入某个用户的信息，然后查询通过web程序是否可以找到这个用户的信息，而不必关注该用户信息的正确性。
因此有人认为它是测试的第一步：first tests on which testers can conclude if they will continue testing. 但并非是必须的。
回归测试 Regression Test
A test that was written when a bug was fixed. It ensure that this specific bug will not occur again. The full name is "non-regression test".
A regression test re-runs previous tests against the changed software to ensure that the changes made in the current software do not affect the functionality of the existing software."
上面两种观点并不一致：一种认为回归测试是为了覆盖fix的bug，另一种认为回归测试是覆盖新添加的功能。
但是我们可以看到这两种说法的统一之处：
回归测试是为了覆盖系统新发生的变化而进行的测试。
回归测试可以由测试人员编写，也可以由开发人员编写。
形式上可以就是一个覆盖新功能或者bug的UT，或者测试人员写的专用测试工具。
端到端测试 End-To-End Test
validates the entire application to ensure that it satisfies previously established acceptance criteria and performs as an integrated system. The purpose of system testing is not to test all possible positive and negative conditions (reserved for functional and integration testing)， but to instead execute business functions and infrastructure management (i.e.； batch processing， system security features， backup and recovery etc.) in an isolated and controlled environment to validate that a quality system is ready for production.
因此端到端测试强调的是全面的，包含硬件环境等等的测试。
最后一句话很重要：是为了上production。
因为覆盖面广，因此一般都是人工测试。通常也没有专用工具来做端到端测试。
功能测试 Functional Test
Functional tests are related to integration tests， but refer more specifically to tests that test an entire system or application with all of the code running together， almost a super integration test.
非功能测试 Non-funtional Test
非功能测试在我公司，主要指除程序主要功能以外的附属功能。如GMI，log，report，failover等，为了监控程序运行，实现程序稳定性而附加的功能。
acceptance tests 不知道中文是什么
总的来说，acceptance tests 和 Functional Test是非常接近的，甚至有些地方认为二者完全一样。二者的异同在于：
functional testing： This is a verification activity； did we build the thing right？ Does the software meet the business requirements？
For this type of testing we have test cases that cover all the possible scenarios we can think of， even if that scenario is unlikely to exist "in the real world". When doing this type of testing， we aim for maximum code coverage. We use any test environment we can grab at the time， it doesn't have to be "production" caliber， so long as it's usable.
acceptance testing： This is a validation activity； did we build the right thing？ Is this what the customer really needs？
This is usually done in cooperation with the customer， or by an internal customer proxy (product owner). For this type of testing we use test cases that cover the typical scenarios under which we expect the software to be used. This test must be conducted in a "production-like" environment， on hardware that is the same as， or close to， what a customer will use. This is when we test our "ilities"：
Reliability， Availability： Validated via a stress test.
Scalabilitiy： Validated via a load test.
Usability： Validated via an inspection and demonstration to the customer. Is the UI configured to their liking？ Did we put the customer branding in all the right places？ Do we have all the fields/screens they asked for？
Security (aka， Securability， just to fit in)： Validated via demonstration. Sometimes a customer will hire an outside firm to do a security audit and/or intrusion testing.
Maintainability： Validated via demonstration of how we will deliver software updates/patches.
Configurability： Validated via demonstration of how the customer can modify the system to suit their needs.
简单的说，functional testing倾向测试软件的所有具备的功能。倾向于是否完全了所有的需求。
acceptance testing倾向测试的是尽量真实的用户体验。测试是否完成用户的实际需求，在完全和production相同或尽量类似的环境中。
同时，二者都应该是完全的黑盒测试。
下面这句话很重要：
Acceptance Tests/Criteria (in Agile Software Development) are usually created by business customers and expressed in abusiness domain language. These are high-level tests to test the completeness of a user story or stories 'played' during any sprint/iteration.
a business domain language指非开发人员可以理解的类自然语言。现在比较流行的框架是JBehave。
Acceptance test cards are ideally created during sprint planning or iteration planning meeting， before development begins so that the developers have a clear idea of what to develop. Sometimes (due to bad planning！) acceptance tests may span multiple stories (that are not implemented in the same sprint) and there are different ways to test them out during actual sprints. One popular technique is to mock external interfaces or data to mimic other stories which might not be played out during an iteration (as those stories may have been relatively lower business priority). A user story is not considered complete until the acceptance tests have passed.
也就是说在一个sprint中，如何确定开发人员是否完成了一个功能？标准就是对应的acceptance test通过。
这也就是Acceptance-Test Driven Development的来由。
