●Software Development Life Cycle（软件生命周期）:SDLC是软件的产生直到报废的生命周期，周期内有问题定义，可行性分析，总体描述，系统设计，编码，调试和测试，验收与运行，维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班，逐步推进，每个阶段都要有定义，工作，审查，形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
●Software Quality Assurance（软件质量保证）:SQA介入于整个软件开发过程——监督和改进过程，确认达成的标准和过程被正确的遵循，保证问题被发现和解决。它以预防为主。
●Software Testing（软件测试）:软件测试是在一定控制的条件下，围绕一个系统或应用的操作并评价其结果（一个最简单的例子：如果用户使用硬件A，在应用接口B上做了操作C，那么结果D应当出现），控制的条件应当包括正常和异常的条件。测试企图使事情变得很糟糕，从而来检测出一些应当发生而没有发生，或者不应当发生而发生的事情。测试以检测为主。
●Black Box Testing（黑盒测试）: 又称功能测试或数据驱动测试。它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。（ISTQB/CSTQB）不考虑组件和系统内部结构的功能或非功能测试。
●White Box Testing（白盒测试）: 又称结构测试或逻辑驱动测试。它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。（ISTQB/CSTQB）通过分析组件/系统内部结构进行的测试。
●Functional Test（功能测试）: 是一种黑盒测试，同应用程序的功能需求紧密相关，对各功能进行验证。这类测试应当由测试人员来完成。这并不意味着开发人员在发布版本之前就不需要检查他们的代码。（ISTQB/CSTQB）通过对组件/系统功能规格说明的分析而进行的测试。
●Performance Test（性能测试）: 该术语通常同负载测试和压力测试是可交换的。理想的性能测试是定义在需求文档或QA测试计划中的。性能测试是通过自动化工具模拟多种正常，峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。
◆Load Testing（负载测试）:通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力，在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特性，当负载逐渐增加时，系统各项性能指标的变化情况，例如，响应时间，事务处理速度和其他与时间相关的方面。
◆Stress Testing（压力测试）:压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。
●Unit Testing（单元测试）: 单元测试是在软件开发过程中要进行的最低级别的活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修复，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。该测试一般由开发者完成而不是由测试人员完成。该测试的容易程度同代码设计的好坏直接相关。
◆Code Review（代码走读）:
◆Static Analysis（静态分析）:对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。
◆Dynamic Analysis（动态分析）:通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。
●Integration Testing（集成测试）: 又称组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。 这类型测试典型的是与客户/服务器和分布式系统相关。
◆（非增量式集成测试）:有些设计人员习惯于把所有模块按设计要求一次性全部组装起来，然后进行整体测试。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。
◆（增量式集成测试）:程序一段一段地扩展，测试范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。
●System Testing（系统测试）:
●Acceptance Testing（验收测试）:系统开发生命周期方法论的一个阶段，这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。
◆（正式验收测试）:正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。
◆（非正式验收测试）/Alpha Testing（α测试）: 由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。目的是评价软件产品的FLURPS（即功能，局域化，可使用性，可靠性，性能和支持）。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。它是一种受控测试。α测试不能由程序人员或测试人员完成。
◆Beta Testing（β测试）:软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况，提出批评意见，然后软件开发公司再对β版本进行改错和完善。β测试也是黑盒测试。黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。它是一种不受控测试。β测试不能由程序人员或测试人员完成。开发者通常不在现场。
