分为了证真，证伪，质量管理三个阶段。
软件测试的目的就是保证软件的质量。
具体来说就是要保证软件或系统符合相关的法律法规，技术标准和应用需求。降低软件的产品风险及应用风险。
需要指出的是是否符合应用需求并不是软件测试的唯一目的，测试必须考虑软件对法规的符合性，标准的符合性以及如商务要求等方面的符合性。
对象是软件，包含了程序，数据和文档；但孤立的软件无法进行全面的测试，特别是动态的测试。
大量的测试活动需要支持测试的环境，包括软件的运行环境和测试环境，这一定会涉及除了被测对象软件之外的软件和硬件环境，数据环境，甚至是应用环境，这些环境不仅对测试提供支持，也会影响到一些测试的结果。
第一需要明确测试对象的边界
第二需要认识到环境对测试的影响，以获得适当环境下的真实测试结果；
验证：判断生产者是否按照需求规格正确的构造软件，或者说是不是正确的做事。
确认：检验软件是否有效，是否满足用户的预期用途和应用需求。
通过验证的软件不一定能够通过确认，因为需求规格不一定真实体现了用户的特定预期用途或应用要求。
在软件生命期内的不希望或者不可接受的人为错误，其结果是导致缺陷的发生。
存在与软件之中（程序，数据，文档）的那些不希望或者不可接受的偏差。
是指在软件运行过程中的不希望或者不可接受的内部状态。
软件运行时产生的一种不希望或者不可接受的外部行为。
软件在需求分析和设计阶段同样会引入缺陷，而且占比均超过了编码阶段。
在需求分析阶段引入的缺陷比率大概占40%；在设计阶段引入缺陷比率也大概在30%，而编码产生的缺陷低于30%。
在需求分析和架构设计中同样会引入缺陷，而且占比均高过编码阶段。在需求分析阶段引入的缺陷比率经常超过40%，在设计阶段引入的缺陷的比率也达到30%左右，而编码阶段，引入缺陷的比率少于30%。
一般而言在软件工程活动当中，缺陷从产生到发现的时间越短，修复的代价就越小，当缺陷从一个工程阶段跨入下一个工程阶段的时候，修复的代价将以指数级的形式增长。正因为如此，在整个软件工程当中要努力做到尽早的去发现缺陷，尽早的排除缺陷，对应的测试活动就不应该是编码完成之后的一个阶段性工作，应是贯穿一个软件工程的各个阶段，力争通过测试，尽早发现缺陷。
在规定条件下使用时，软件产品满足明确的或者隐含的要求的能力。
软件质量包括了软件测试，软件测试是保证软件质量的一种措施或手段。
测试用例是测试人员针对特定目标而设计或开发出来的，又非常强的目的性；
测试用例将体现软件的某一个具体运行实例或场景，包括输入的测试数据，执行条件，逻辑过程以及预期的逻辑结果
测试用例需要提供准确的判定准则，依照该用例实施测试获得实际结果时如何判定。
测试用例对于测试实施来说有非常重要的作用。首先测试用例是测试实施的依据，测试人员应该按照设计好的用例开展测试，获取结果并进行判定。
其次测试用例是根据测试系统严密设计出来的测试任务描述，在测试用例的指导下可以保证测试规范性，提高测试效率。
它可以提高测试的效率，避免测试的随意性和盲目性，从而保证测试的质量
此外测试用例还是软件企业的一类资产，具有相当大的价值。
标识，名称，说明，环境配置，操作过程，各种条件，评价准则，以及建立用例的人员和时间。
其中操作过程要描述每一步操作的输入数据，过程说明，预期结果，通用准则等。
测试所需软硬件资源的详细说明；
针对测试和进度约束，需要人力资源的角色和职责；
测试方法，测试标准，完成标准；
目标系统的功能性，非功能性需求，技术指标；
系统局限（即系统不能够满足的需求）
已经批准的测试策略文档，测试用例和测试计划。
需要解决方案的测试项目。
确定测试的需求
评估风险并确定测试优先级
确定测试策略
不同阶段的测试有不同的阶段性的测试目标，但汇集起来后的总目标是保证软件质量，测试应该溯源到原始需求，而不是仅仅只盯着眼前。
测试不仅仅只是某一个工程的活动，而是贯穿软件生产的各个部分的一个活动。需要以工程化的思想和方法来实施，需要尽早的按计划的来开展测试，甚至是预防性测试。
应该避免开发人员测试自己的程序，企业也应该设立独立的测试工程师岗位，或者设立测试部门去完成测试的工作。
对软件进行完整性的测试是不可能的，无法对软件进行穷尽的测试，基本规律是测试成本和测试强度成正比，预留的缺陷和测试强度成反比。
不管强度有多大，测试都不能暴露所有的缺陷，这个是由测试自身所决定的，测试能做的是尽可能多的发现错误，但不能证明软件不再包含错误。
在一个软件或一个模块中发现的缺陷越多，则在这个软件或者模块中剩下的缺陷也越多。这就是说缺陷具有的积聚现象，这个测试原则就提醒测试工程师，暴露的缺陷越多的模块，就越发需要加强测试。
测试的目标是发现软件缺陷，但更进一步的目标是修复发现的缺陷。在各方可以接受的前提下，可以允许某些缺陷遗留在软件当中，应该交给恰当的人员或者会议来进行决策。
测试虽然是为了降低或者化解软件的质量风险，但必须也要意识到测试其本身也是存在风险的。这就需要我们在做测试设计和构造测试用例的时候，考虑如何规避和减少风险。
测试超过了预定时间，执行了所有的测试用例，没有发现新的故障，采用特定的测试用例设计方案，查出某一预定数量的故障，单位时间内查出的缺陷数量少于预定量。
它对应于开发的瀑布模型。测试就成为了一个阶段性的工作。
它是测试模型的一个重要的改进，充分体现出了尽早开始测试的思想。并将V模型中s以发现缺陷为目标改进为保证软件质量为目标。
W模型其实就是两个V模型的叠加，一个V用来描述开发过程，另一个V用来描述测试过程；但是测试的开始时机不再是编码结束后，而是在需求分析的时候就要开始，且与开发的每一个活动都是同步进行。
它改进了V 模型和W模型高度依赖于软件开发瀑布模型的缺陷，该模型把测试活动从软件开发活动中独立了出来，该软件过程的任何一个时间点上，只要测试条件满足即可开展测试。测试的流程与其他流程是并行的，它相比于其他模型（如W模型）的最大的优势在于可以兼顾测试的效率和灵活性。适用于各种规模和类型的软件开发模型
该模型源于敏捷开发，敏捷测试是敏捷开发的组成部分，需要与开发流程相互融合，敏捷测试在整个测试流程当中，需要与项目的其他开发人员甚至是用户保持紧密协作，时刻关注需求变化并实施测试，以体现测试的实效性和适应性，它对测试人员有比较高的能力要求。
如果按软件开发的瀑布模型，测试活动可以划分为单元测试，集成测试，系统测试，确认测试，验收测试。
它是最小单位的测试活动，也称为模块测试。在封闭的单元内部进行的测试，关注一个单元是否正确的实现了规定的功能，逻辑是否正确，输入输出是否正确，从而寻找模块内部存在的各种错误。
单元测试的测试内容包括有：模块接口测试，局部数据结构，模块内路径，边界条件和错误处理。
单元测试的依据是详细设计文档。可能需要构造驱动模块和庄模块来完成测试活动。
集成测试是在单元测试完成并修复的基础之上，进行模块的集成时开展的测试
集成测试只要的任务就是发现单元之间的接口可能存在的问题，目标是验证各个模块组装起来之后，是否满足软件的设计文件要求。
常见的集成设计策略有一次性集成和增量式集成两种。
目标是确认软件应用系统能否按照预期的工作并满足应用的需求。
系统测试的对象是应用系统，除了软件以外可能还包括了硬件网络和数据，并且需要在一个比较真实的环境下进行。采用的测试方法主要是黑盒测试。
系统测试只能由独立的测试团队，用户或者第三方来实施进行。系统测试一般包括安全，性能，强度可靠性等等。
确认测试与验收测试他们把焦点放在与软件交付相关的验证与确认上，确认测试和验收测试与系统测试相似，以需求规格说明为依据，采用黑盒测试方法。
验收测试主要确认软件的功能与性能，以及其他特征是否满足软件需求规格说明书中列出的需求，是否符合软件开发商与用户签订的合同的要求。
验收测试是用户主导的，由开发商参与。
确认测试按照用户参与程度不同，可以分为内部确认测试，阿尔法测试，贝塔测试，验收测试。所以说验收测试可以是确认测试中的一个部分。
按是否执行代码来分，测试可以分为动态测试和静态测试两种。
就是通常意义上的测试。通过运行软件来发现错误，或者验证程序是否符合预期要求。
静态测试是不运行软件的，只做检查和审核。测试对象包括需求文档，设计文档，产品规格说明书和代码等等。
对各类文档的测试主要通过评审的方式来进行，对代码采用走查和代码审查的方式。
可以将测试分为开发方测试，用户方测试和第三方独立机构的测试。
可以分为白盒测试黑盒测试和灰盒测试。区别就在于测试实施的时候测试人员是否知道软件是如何实现的。
也称为结构化测试，逻辑驱动测试或者基于代码的测试，测试时完全清楚被测程序的内部结构，语句及工作过程。
黑盒测试通过软件的外部表现行为进行测试的方法，它不关心程序的内部结构和如何实现，只关心程序的输入输出；因此这种方法就好像黑盒一样完全看不到里面的处理过程。
它基于黑盒测试与白盒测试之间，既关注黑盒测试方法中的输入与输出，在一定程度上也关心程序的内部实现状况，是这两种方法的融合。
按照软件的八个质量属性来划分，可以分为功能，效率性，兼容性，易用性，可靠性，信息安全性，维护性和可移植性。相应的可以根据这些特征或者其子特征来开展测试。从而形成系统的功能性测试，性能效率测试，兼容性测试，易用性测试，可靠性测试等。
符合性测试是要通过测试去判断软件是否符合事先已经明确的文件性要求和约束。
例如有标准，规范，技术指标，招投标文件，合同等。
符合性测试是有先决条件的，包括含有符合性准则的文件，就绪的软件，以及软件的系统元素均以存在（测试者可以使用），因此符合性测试更加类似于前述的系统测试，确认测试和验收测试。
回归测试：发生在软件有变动的情况下，如果这种变动是对缺陷修复的话，回归测试首先就要验证缺陷是否已经被正常修复了，然后测试修复缺陷而可能影响到的功能是否依然正确；如果软件的变动是增加了新的功能，回归测试除了验证新的功能之外，同样要测试可能受到影响的其他功能。即便是删除了软件的某个功能，依然要通过回归测试来检查是否影响到保留的功能。