软件测试（英语：software testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

软件测试永远不可能完整的确立任意计算机软件的正确性。然而，在可计算理论（计算机科学的一个支派）一个简单的数学证明推断出下列结果：不可能完全解决所谓“死机”，指任意计算机程序是否会进入死循环，或者罢工并产生输出问题。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。

1、所有测试都应该能追溯到用户需求。 2、应该远在测试开始之前就制定出测试计划。 3、把Pareto原理应用到软件测试中。（“二八法则”，测试中80%的错误很可能是由程序中20%的模块造成。） 4、应该从“小规模”测试开始，并逐渐进行“大规模”测试。 5、穷举测试是不可能的/ 6、为了达到最佳的测试效果，应该由独立的第三方从事测试工作。

软件测试一般分为黑盒测试和白盒测试。

黑盒测试（black-box testing），也称黑箱测试，是软件测试方法，测试应用程序的功能，而不是其内部结构或运作。测试者不需具备应用程序的代码、内部结构和编程语言的专门知识。测试者只需知道什么是系统应该做的事，即当键入一个特定的输入，可得到一定的输出。测试案例是依应用系统应该做的功能，照规范、规格或要求等设计。测试者选择有效输入和无效输入来验证是否正确的输出。

此测试方法可适合大部分的软件测试，例如集成测试（integration testing）以及系统测试（system testing）。

白盒测试（white-box testing，又称透明盒测试glass box testing、结构测试structural testing等）是一个测试软件的方法，测试应用程序的内部结构或运作，而不是测试应用程序的功能（即黑箱测试）。在白盒测试时，以编程语言的角度来设计测试案例。测试者输入数据验证数据流在程序中的流动路径，并确定适当的输出，类似测试电路中的节点。

白箱测试可以应用于单元测试（unit testing）、集成测试（integration testing）和系统的软件测试流程，可测试在集成过程中每一单元之间的路径，或者主系统跟子系统中的测试。尽管这种测试的方法可以发现许多的错误或问题，它可能无法检测未使用部分的规范。

Alpha测试通常是阶段性的开发完成后所开始进行，一直持续到进入Beta测试阶段前的阶段。Alpha测试是一种验证测试，在模拟的环境中以模拟的数据来运行。

在这个阶段中，通常是由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。

在系统测试中通常先进行Alpha测试以验证信息系统符合用户以及设计需求所期望的功能。当Alpha阶段完成后，开发过程进入到Beta阶段，由公众参与的测试的阶段。Beta测试可称为确认测试，在一个真实的环境中以实际的数据来运行测试，以确认性能，系统运行有效率，系统撤销与备份作业正常，透过测试让信息系统日后可以更趋完善。

封闭测试（Closed Beta，常简作封测或CB）是软件或服务等产品在开发完成后、将公开上市前的测试过程。相对于公开测试，封闭测试的主要用途是测试软件的功能和检查程序错误等等，因此通常只提供给少数人进行测试。有些公司会要求参与测试者签署保密协议，以避免测试的产品提前外流。

公开测试（Open Beta，常简作公测或OB），一般常指软件或服务等产品在正式上市前开放给不特定人试用，虽然原意是希望试用者能够提报bug，但并不是把试用者当做真正的验证人员。由于通常为免费性质，故常常能够吸引到大批的试用者参与，可视为另一种营销策略。另一方面也节省下测试人员的成本，和验证稳定度（对于多人使用的带宽及机器是否能负载，又称压力测试）的时间。

Gamma测试是一个很少被提及的非正式测试阶段，该测试阶段对应的是对“存在缺陷”产品的测试。考虑到任何产品都可以被称为“存在缺陷”的产品（测试只能发现产品中存在的问题，不能说明产品不存在问题），因此这个概念存在一定的不确定性。

参照冯永华书籍

一个项目的测试包括文档测试，易用性测试，逻辑功能测试，界面测试，配置和兼容等多个方面。我们可以根据人员的特点为每个人员分配不同的测试内容。

内容分工方式的优点： 1、分工明确，每位人员都清楚自己的测试的内容重点。 2、责任到位，通过漏测的缺陷就可明确是谁的责任。

我们的项目测试流程一般需要，制定测试计划，编写测试用例，执行测试用例，输出测试报告等工作，我们可以根据流程中的各个阶段来进行划分。

不同的人员负责不同测试阶段的工作。优点：　　 1、流程清晰，就像瀑布试项目开发流程，不同阶段的工作由不同的人员担任。　　 2、划分流程的每个阶段难易程度和所需要的技能。

编写测试计划人员需要对整个项目的工作时间、资源分配，测试内容，实施过程有整体的把控能力。 用例辨析人员，需要对项目需求，测试方法，测试点有深入的了解。 用例执行人员需要细心，使用缺陷系统，沟通，协助研发定位缺陷。 输出测试报告人员需要对项目的测试过程，缺陷数量，类型，分布。用例执行请况等进行统计。也可以由测试执行人员担任。

对中大型的项目，这种划分就非常必要了，项目的模块非常多，功能也非常多。不同的测试人员负责不同模块的功能，这样会使用测试工作变得更加清晰。

1、人员利用率高，为什么这么说呢? 不同的人员负责的功能不一样。工作就不会存在交叉与重复。 2、更容易挖掘深度缺陷，假如A人员今天测试这个功能，明天测试那个功能，他就不可以对被测功能内部逻辑与业务有深入有了解。找到的也只是很表面的缺陷。那么如果一个人员长期负责一个模块的功能，那么就会更容易发现更有深度的缺陷。而往往深度的缺陷是致命的。

我们知道软件除了功能需要测试以外，软件在编码阶段需要单元测试，接口测试等，在系统测试阶段，为提高功能测试的效率，可能对某些模块进行功能自动化，我们还要考虑软件的性能、安全性等问题。这些类型也是我项目中最常见的分类。我们可以根据这些类型为测试人员分配测试工作。当然，其专业性对测试人员的要求也比较高。

这种分工方式的特点：　　 1、专业技能要求较高，在这些分类中除了手工测试要求较低外（表面看是这样的），其它分类都需要较高的专业技能。例如，安全性测试需要掌握网络协议，编程技术，脚本攻击，SQL注入，漏洞分析等方面的技能。　　 2、不同分类之间交互性低，正国为不同分类需要的技能不同，虽然同为“测试”工作，但一个做单元测试的人就无法让其去做性能测试。

这里存放条目相关的国家标准

这里存放于条目相关的其他文档