1 .软件测试的定义首先要明确测试的定义。 测试是指检验产品是否满足需求为目标
软件测试为发现软件(产品)的缺陷而运行软件(产品)
比较标准的软件测试定义为： 在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估。
IEE标准的定义： 使用人工或自动的手段来运行或测定某个系统的过程，其目的在于检验；它是否满足规定的需求或是弄清预期结果与实际结果之间的差别
软件测试的目的是：
测试的目的侧重于不同的测试阶段，主要体现在以下几个方面：
1）发现缺陷
尽快发现更多被试的缺陷，应该是测试仪测试中最常提出的测试目标，也是所谓测试价值的重要体现。 缺陷发现的目的是推动开发者的定位和问题的修复，测试者通过复测和回归测试，使开发者修复缺陷，不影响原正常区域，提高产品质量。 开发生命周期的每个阶段都需要测试的参与，通过尽可能多的发现本阶段的缺陷，大幅提高本阶段缺陷阶段的抑制能力，提高测试效率，降低成本，提高质量。
由于软件产品的质量是多维的，软件测试的关注点不仅是被测对象的功能，各种非功能质量属性也应该是测试的关注点。 更多的产品质量属性可以参考标准ISO 9126 -软件产品质量。
2）增加信心
如果在测试中缺陷很少或找不到，测试有助于建立对软件产品质量的信心。 如果找不到缺陷，除了可以降低风险，提高自信之外。 通过测试提高自信心还体现在：
(1)验证：验证软件产品描述需求是否正确实现；
)验证验证(Validation )受试者可以根据用户/客户的要求工作(客户/用户是多级含义，不仅仅是最终用户)；
例如，如果您参加了用户的现场验收测试，则该测试的主要目的是保证软件产品正常运行，提高用户对产品质量的信心。
3）提供信息
测试过程的每个阶段都向开发过程提供信息，包括向软件产品的不同利益相关者提供不同维度的不同细节级别的信息。 提供信息的主要目的是帮助利害关系方做出正确的决策。
(1)质量评估：通过测试过程提供的各种数据有助于利益相关者评估被测软件产品的质量。 例如，根据测试中发现的缺陷累积趋势、测试执行进度数据、执行通过率和覆盖率等，可以判断软件产品是否符合计划中定义的质量要求；
)评估进展)通过提供的各种数据，帮助管理者决定是否能及时发布软件产品。 包括评估)测试执行进度是否在计划范围内，缺陷修复开发进度是否符合质量和释放要求等；
评估产品质量和进展情况，测试中提供的数据是非常重要的输入。
4）预防缺陷
测试中发现的缺陷以及用户现场存在的缺陷，应进行缺陷的根本原因分析，找出缺陷引入的主要原因。 从测试的角度来看，也必须分析为什么能发现缺陷，以及为什么缺陷会漏到用户的现场。
根本原因分析的目的是从以前的软件开发和测试过程中吸取经验和教训，避免同样的问题的重复，改善开发和测试的过程。 工艺的改进反过来又可以防止相同缺陷的再次引入和泄漏，提高软件产品的质量，这也是软件质量保证的重要环节。
发现缺陷、增加信心、提供信息和预防缺陷这四个测试目的同样贯穿于整个生命周期，四个测试目标相互支持和补充。 另外，各阶段、各利益相关者对测试目标的要求和详细程度也不同。
2 .软件测试方法分类
3 .软件测试原则测试证明软件存在缺陷
测试的本质是证明软件有缺陷，而不是软件没有缺陷。
没有人是完美的。 如果是人写的代码，除非是特别简单的功能，否则不能保证100%正确。 即便如此，也存在着各种各样的环境问题、网络问题等，更何况现在软件越复杂，缺陷就越不可避免。
不可能执行穷尽测试
举个简单的例子来说，比如测试一个计算器功能的加法，11、12、13……所有的数组加起来的情况能测试吗？ 所以全面测试是不可能的。 在实际情况下，项目进度当然有明确的时间节点。 截止日期。
测试应尽早启动，尽早介入
这很重要，但对测试的要求也很高。
首先，让我解释一下为什么要早点开始。 例如，软件工程就像盖房子一样，必须先设计，打好基础。 如果没有设计阶段和基础，你身后大楼里的爱心列车越高，推回去、回头修正的成本也就越大。 所以，测试必须早点介入。
系统测试阶段什么时候介入呢？ 在为需求文档设计测试用例时，开始测试。 此时软件还处于设计阶段，测试站在质量和安全性的角度，在完善功能自身可测试性、可靠性、用例的同时，也要注意整个业务过程能否形成完整的闭环。 是
否存在明显的需求错误。集成测试阶段
还有一个场景，比如开发app时候，往往后端工程师 服务器先开发完成，此时无论ios还是android工程师都在开发中，等待更多接口完成，等待接口文档。测试工程师此时便可以对着接口文档，先进行服务器端的接口测试了。这样联调之前就可以先找到部分服务器缺陷，减少了前后端开发调试和纠错时间。
单元测试阶段
这个对测试来说有一定难度，多半还是开发人员自己完成，也就是每一个方法，类完成之后。自己对软件的最小组成单元编写测试代码进行验证。这就好像你盖楼房，组成楼房的每一层阶梯，每一块砖头质量先保证是好的。
缺陷存在群集现象（二八原则）
这个也是经验之谈了，一般认为，百分之80的缺陷集中出现在百分之20的核心功能区域。一旦你在某个功能模块找到缺陷，相关附近功能多半也会存在问题。实战中如何使用呢，写缺陷报告的时候，做横向对比，比对类似功能，相近模块，版本，机型。指定回归测试策略的时候，也可以重点测试。
杀虫剂悖论
杀虫剂悖论，很简单，意思就是相同的功能，相同的用例，多次执行，后几轮就慢慢找不到缺陷了。仿佛软件对你的测试用例产生了抗药性。所以，用例在每次执行完之后应该及时进行更新和维护，升级你的装备。
不同测试活动依赖不同的测试背景
举个例子来说明，你在金融公司测试，安全性就是第一位。电子商务测试，功能性则更加重要。
不存在缺陷的谬论
假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何意义的。
因为软件开发中测试资源和时间是有限的，测试需要策略，更何况测试总是有风险的，就更需要测试策略。什么是软件测试策略？简单地说，软件测试策略就是在测试质量和测试效率之间的一种平衡艺术（Leverage Test）。更明确地说，测试策略是为了以最低的成本最大程度地揭示（／降低）产品的质量风险或尽早地完成测试所选择（或制定的）的最合理／合适的方式、方法、过程等，这里：
最低的成本是指完成测试所需的资源、时间等最少，“最”是相对的，即基于目前的认识或能力所能做到的；
完成测试，即达到特定的测试目标，如达到测试覆盖率的某个值、发现尽可能多的缺陷、完成所有主要功能特性的验证，这也依赖于对“软件测试”是如何理解的，或测试目标是如何定义的；
方式，包括手工方式、自动化方式；探索式测试或基于脚本的传统测试；自己团队测试还是众测、外包；
方法，包括基于需求的、基于数据流、基于控制流、组合测试、形式化等方法、技术、工具等
过程：先测什么、后测试什么；对测试阶段的不同划分等。
**一般来说测试策略是测试计划的一部分，但也不一完全是。**从一个项目来看，在测试需求、测试风险分析之后，需求制定测试策略尽量降低测试风险，在有限的资源和时间内达到测试目标。但通用的测试策略（如测试四象限）、测试分析策略（如启发式测试策略HTSM）、自动化测试策略（如著名的金字塔策略）、通用的回归测试策略就不属于具体项目，也就不属于测试计划，但可能在测试计划中可能采用或强调其应用。测试策略也不等同于测试方案，测试方案是找到如何测试对象的具体方法（完整的解决办法），虽然包含项目级别的测试策略，但也包括具体的技术运用、新的工具定义／设计等。它们有相交，也有区别，见下面图示。另外，测试策略也不仅仅指导测试设计，而且也指导测试的执行。
基于风险的测试策略是指评估测试项的优先级，先进行高优先级的测试项，或者／并 将测试的优质资源（包括人力、物力等）优先放在高优先级的测试项上。如果时间或精力不够，低优先级的测试可以暂时不做。基于风险的测试，也就是根据事情的轻重缓急来决定测试工作的重点和工作的顺序，而这建立在对测试风险的分析评估的基础上。
以下内容转载自：http://www.51testing.com/html/70/n-4461370.html
按测试模式来分类： 瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。
优点：
缺点：
线性研发过程难以适应需求的频繁变化项目周期后段才可看到成果，用户要到末期才能看到开发结果，增加了开发的风险强制的里程碑，对于开发过程中出现的变化，适应能力较差，文档工作量较大，测试在项目的后期，文档的开发带来很大的工作量。 5.2 V模型
优点：
在V模型里，强调软件开发的协作和速度，反应测试活动和分析测试的关系，并且将软件的实现和验证有机的结合了起来，V模型，明确的界定测试过程是存在不同阶段的。
缺点：
但是V模型也有一定的局限性,它仅仅把测试过程放在需求分析、系统设计、编码之后的一个阶段，忽视了测试对于需求的分析和验证。我们对需求的验证，对系统设计的验证，到后期的验收测试才有可能被发现，对于我们测试当中的测试需要尽早进行的原则在V模型中没有体现，这是V模型的局限。
优点：开发与测试并行，有利于尽早发现问题，有利于及时的了解项目的测试风险，来及早的执行相应的应对方案，加快项目的进度。
局限性：需求、设计、编码仍然是串行进行的，测试和开发保持线性的关系，上一个阶段完成之后才能进行下一个阶段，不能够很好的支持迭代的开发模型。
左边描述的是针对单独的程序片段相互分离的编码和测试，此后进行频繁的交接，再通过集成，最终合成可执行的程序，对这些程序进行测试，这些程序还是需要冀衡测试，已经通过的程序可以进行封板提交给用户，也可以作为更大集成的一部分，X模型还定位了探索式测试，探索式测试是不进行事先计划的特殊类型的测试，能够帮助测试人员在测试计划之外发现更多的错误。
把软件测试看成一个完全独立的流程，与其他流程并发进行，比如设计流程，编码流程，甚至是测试流程
H模型强调把测试分为测试准备和测试执行两个不同的阶段，只要由于其他流程的进展引发了测试就绪点的到位，这时候，只要测试准备不能完成，测试执行活动就可以或者需要开展，在H模型当中，测试是一个完全独立的模型，所以可以和其他的流程交叉地进行，也便于我们尽早的执行测试。
最后总结一下：
如果你对此文有任何疑问，如果你也需要接口项目实战，如果你对软件测试、接口测试、自动化测试、面试经验交流感兴趣欢迎加入：软件测试技术群：593462778，群里的免费资料都是笔者十多年测试生涯的精华。还有同行大神一起交流技术哦。
作者：暗潮汹涌
原创不易，欢迎转载，但未经作者同意请保留此段声明，并在文章页面明显位置给出原文链接。-