软件测试学习（一）软件测试基础知识

1. 软件测试定义

首先要明确测试的定义,所谓测试,就是以检验产品是否满足需求为目标。
而软件测试,自然是为了发现软件(产品)的缺陷而运行软件(产品)
比较标准的软件测试的定义是:在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估。

IEEE 标准的定义:使用人工或自动的手段来运行或测定某个系统的过程，其目的在于检验;它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

软件测试的目的：
测试目的会随着不同测试阶段而有所侧重点，主要体现在：

1）发现缺陷

尽早和尽量多的发现被测对象中的缺陷，应该是测试人员测试过程中最常提起的一个测试目标，也是所谓测试价值的一个的重要体现。发现缺陷的目的是推动开发人员定位和修复问题，测试人员通过再测试和回归测试，确保开发人员已修复缺陷，并没有影响原来正常的区域，从而提高产品质量。开发生命周期的每个阶段，都应该有测试的参与，并尽量多的发现本阶段的缺陷，从而大大提高本阶段的缺陷阶段遏制能力，从而提高测试效率、降低成本和提高质量。

软件产品的质量是多维度的，因此软件测试的关注点不仅仅在被测对象的功能上面，各种非功能质量属性都应该是测试的关注点。更多的产品质量属性可参考标准ISO 9126 - 软件产品质量。

2）增加信心

当测试过程中发现很少或没有发现缺陷时，测试就可以帮助树立对于软件产品质量的信心。除了没有发现缺陷时可以降低风险增加信心之外。通过测试增加信心还体现在：

（1）确认Verification：确认软件产品描述的需求已经得到正确实现；

（2）验证Validation：被测对象可以按照用户/客户的要求工作（客户/用户是多个层面的含义，不仅包括最终的用户）；

例如：假如我们参加用户现场的验收测试，此时测试的主要目的是为了确保软件产品可以正常工作，从而增加用户对使用产品质量的信心。

3）提供信息

测试过程的每个阶段都在为开发过程提供信息，包括给软件产品的不同利益干系人提供不同维度不同详细程度的信息。提供信息的主要目的是帮助利益干系人作出正确的决策：

（1）评估质量：通过测试过程提供的各种数据，可以帮助利益干系人评估被测软件产品的质量。例如：根据测试过程中发现缺陷的累积趋势、测试执行的进度数据、执行通过率和覆盖率等，可以判断软件产品是否满足计划中定义的质量要求；

（2）评估进度：通过提供的各种数据，可以帮助管理人员作出是否能及时发布软件产品的决策，包括评估：测试执行进度是否在计划范畴内、开发修复缺陷进度是否满足质量和发布要求等；

评估产品质量和进度情况，测试过程中提供的数据是非常重要的输入。

4）预防缺陷

测试过程中发现的缺陷，以及遗漏到用户现场的缺陷，都应该对它们进行缺陷根本原因分析，找到引入缺陷的主要原因。从测试角度也要分析为什么能发现缺陷，以及为什么缺陷会遗漏到用户现场。

缺陷根本原因分析的目的是从以前软件开发和测试过程中吸取经验和教训，避免同样的问题重复发生，从而改进开发和测试过程。过程改进反过来可以预防相同的缺陷再次引入或遗漏，从而提高软件产品质量，这也是软件质量保证的重要一环。

发现缺陷、增加信心、提供信息和预防缺陷这4个测试目的同样贯穿于整个生命周期，并且4个测试目标是相互支持和补充的。同时，不同阶段、不同利益干系人对不同测试目标的要求和详细程度都会不一样。

2.软件测试方法分类

3. 软件测试原则

测试证明软件存在缺陷
测试的本质是证明软件存在缺陷，而不是软件没有缺陷。

人无完人，只要是人写的代码，肯定不能保证百分之百正确，除非特别简单的功能。即便如此，也会存在各种环境问题，网络问题等，更何况现在软件原来越复杂，缺陷更是难以避免。

不可能执行穷尽测试
举个很简单的例子来说明，比如测试一个计算器功能里的加法，你可以尝试1+1,1+2 ,1+3 …你能把所有数组相加的情况都测试吗，所以穷尽测试时不可能的，更别提是实际情况中，项目进度还有明确时间节点。截止日期。

测试应尽早启动，尽早介入
这条很重要，但是对测试的要求也会更高。
先来讲为什么要尽早启动，举例说明，软件工程和盖房子一样，先也得设计，打好地基，试想假如设计阶段，或者地基没打好，你后面楼房盖得越高，推到重来，或者回头再去修改所耗费的成本也就越大，所以，测试要尽早介入。

系统测试阶段什么时候介入呢，对着需求文档设计测试用例的时候，就开始测试了。软件此时还在设计阶段，测试站在质量和安全性角度，应该多多思考功能本身的可测试性，可靠性，完善用例的同时也可注意下整个业务流程是否能形成完整的闭环。是否存在明显的需求错误。

集成测试阶段
还有一个场景，比如开发app时候，往往后端工程师服务器先开发完成，此时无论ios还是android工程师都在开发中，等待更多接口完成，等待接口文档。测试工程师此时便可以对着接口文档，先进行服务器端的接口测试了。这样联调之前就可以先找到部分服务器缺陷，减少了前后端开发调试和纠错时间。

单元测试阶段
这个对测试来说有一定难度，多半还是开发人员自己完成，也就是每一个方法，类完成之后。自己对软件的最小组成单元编写测试代码进行验证。这就好像你盖楼房，组成楼房的每一层阶梯，每一块砖头质量先保证是好的。

缺陷存在群集现象（二八原则）
这个也是经验之谈了，一般认为，百分之80的缺陷集中出现在百分之20的核心功能区域。一旦你在某个功能模块找到缺陷，相关附近功能多半也会存在问题。实战中如何使用呢，写缺陷报告的时候，做横向对比，比对类似功能，相近模块，版本，机型。指定回归测试策略的时候，也可以重点测试。

杀虫剂悖论
杀虫剂悖论，很简单，意思就是相同的功能，相同的用例，多次执行，后几轮就慢慢找不到缺陷了。仿佛软件对你的测试用例产生了抗药性。所以，用例在每次执行完之后应该及时进行更新和维护，升级你的装备。

不同测试活动依赖不同的测试背景
举个例子来说明，你在金融公司测试，安全性就是第一位。电子商务测试，功能性则更加重要。

不存在缺陷的谬论
假如系统无法使用，或者系统不能完成客户的需求和期望，发现和修改缺陷是没有任何意义的。

4.软件测试策略

因为软件开发中测试资源和时间是有限的，测试需要策略，更何况测试总是有风险的，就更需要测试策略。什么是软件测试策略？简单地说，软件测试策略就是在测试质量和测试效率之间的一种平衡艺术（Leverage Test）。更明确地说，测试策略是为了以最低的成本最大程度地揭示（／降低）产品的质量风险或尽早地完成测试所选择（或制定的）的最合理／合适的方式、方法、过程等，这里：
最低的成本是指完成测试所需的资源、时间等最少，“最”是相对的，即基于目前的认识或能力所能做到的；

完成测试，即达到特定的测试目标，如达到测试覆盖率的某个值、发现尽可能多的缺陷、完成所有主要功能特性的验证，这也依赖于对“软件测试”是如何理解的，或测试目标是如何定义的；

方式，包括手工方式、自动化方式；探索式测试或基于脚本的传统测试；自己团队测试还是众测、外包；

方法，包括基于需求的、基于数据流、基于控制流、组合测试、形式化等方法、技术、工具等

过程：先测什么、后测试什么；对测试阶段的不同划分等。

**一般来说测试策略是测试计划的一部分，但也不一完全是。**从一个项目来看，在测试需求、测试风险分析之后，需求制定测试策略尽量降低测试风险，在有限的资源和时间内达到测试目标。但通用的测试策略（如测试四象限）、测试分析策略（如启发式测试策略HTSM）、自动化测试策略（如著名的金字塔策略）、通用的回归测试策略就不属于具体项目，也就不属于测试计划，但可能在测试计划中可能采用或强调其应用。测试策略也不等同于测试方案，测试方案是找到如何测试对象的具体方法（完整的解决办法），虽然包含项目级别的测试策略，但也包括具体的技术运用、新的工具定义／设计等。它们有相交，也有区别，见下面图示。另外，测试策略也不仅仅指导测试设计，而且也指导测试的执行。

基于风险的测试策略是指评估测试项的优先级，先进行高优先级的测试项，或者／并将测试的优质资源（包括人力、物力等）优先放在高优先级的测试项上。如果时间或精力不够，低优先级的测试可以暂时不做。基于风险的测试，也就是根据事情的轻重缓急来决定测试工作的重点和工作的顺序，而这建立在对测试风险的分析评估的基础上。

5. 软件测试模型

以下内容转载自：http://www.51testing.com/html/70/n-4461370.html
按测试模式来分类： 瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。

5.1 传统瀑布模型

优点：

强调需求，设计的作用；
前一阶段完成后只需关注后续阶段；
为项目提供按阶段划分的检查点，里程碑清晰
文档规范

缺点：

线性研发过程难以适应需求的频繁变化
项目周期后段才可看到成果，用户要到末期才能看到开发结果，增加了开发的风险
强制的里程碑，对于开发过程中出现的变化，适应能力较差，
文档工作量较大，测试在项目的后期，文档的开发带来很大的工作量。

5.2 V模型

优点：
　　在V模型里，强调软件开发的协作和速度，反应测试活动和分析测试的关系，并且将软件的实现和验证有机的结合了起来，V模型，明确的界定测试过程是存在不同阶段的。
缺点：
　　但是V模型也有一定的局限性,它仅仅把测试过程放在需求分析、系统设计、编码之后的一个阶段，忽视了测试对于需求的分析和验证。我们对需求的验证，对系统设计的验证，到后期的验收测试才有可能被发现，对于我们测试当中的测试需要尽早进行的原则在V模型中没有体现，这是V模型的局限。

5.3 W模型（双V模型）

优点：开发与测试并行，有利于尽早发现问题，有利于及时的了解项目的测试风险，来及早的执行相应的应对方案，加快项目的进度。
局限性：需求、设计、编码仍然是串行进行的，测试和开发保持线性的关系，上一个阶段完成之后才能进行下一个阶段，不能够很好的支持迭代的开发模型。

5.4 X模型

左边描述的是针对单独的程序片段相互分离的编码和测试，此后进行频繁的交接，再通过集成，最终合成可执行的程序，对这些程序进行测试，这些程序还是需要冀衡测试，已经通过的程序可以进行封板提交给用户，也可以作为更大集成的一部分，X模型还定位了探索式测试，探索式测试是不进行事先计划的特殊类型的测试，能够帮助测试人员在测试计划之外发现更多的错误。

5.5 H模型：

把软件测试看成一个完全独立的流程，与其他流程并发进行，比如设计流程，编码流程，甚至是测试流程

H模型强调把测试分为测试准备和测试执行两个不同的阶段，只要由于其他流程的进展引发了测试就绪点的到位，这时候，只要测试准备不能完成，测试执行活动就可以或者需要开展，在H模型当中，测试是一个完全独立的模型，所以可以和其他的流程交叉地进行，也便于我们尽早的执行测试。

最后总结一下：
如果你对此文有任何疑问，如果你也需要接口项目实战，如果你对软件测试、接口测试、自动化测试、面试经验交流感兴趣欢迎加入：软件测试技术群：593462778，群里的免费资料都是笔者十多年测试生涯的精华。还有同行大神一起交流技术哦。

作者：暗潮汹涌
原创不易，欢迎转载，但未经作者同意请保留此段声明，并在文章页面明显位置给出原文链接。-