测试--基础知识篇

前言

这一篇是关于测试基础知识的讲解，基本就是相当于一个复习吧，不会涉及的太深，主要就是全面些吧。

一丶基础概念

<1>关于软件测试

1>什么是软件测试

软件测试就是你要去验证，一个软件是否合理并且全面的实现了需求

如果说你最终交付的产品和用户的需求不一致，那么你就需要找出不一致的点。

2>那什么是需求

所谓的需求有两种，一种是用户需求也就是用户想要实现的功能。一种是软件需求，软件需求是根据用户需求转化而来，是对用户需求的细化和具体实现的细节。

这里的软件需求是测试人员进行测试工作的基本依据。因为用户需求比较粗略，直接实现的话会有很大的难度，所以软件需求会把用户需求规范化和细节化，把用户需求变成一个具体的可以实现的文档。

3>需求的重要性

那以上说了那么多，需求为什么那么重要呢？

1.从软件功能需求出发，无遗漏的识别出测试需求是直观重要的，这将直接关系到测试用例的测试覆盖率
2.对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计

<2>关于测试用例和BUG

1>什么是测试用例呢？

所谓测试用例就是向被测试系统发起的一系列集合，
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：

测试环境、操作步骤、测试数据、预期结果等要素

测试用例解决了两大问题：测什么，怎么测。
测试过程中可能会遇到以下问题： 1.不知道是否较全面的测试了所有功能
2.测试的覆盖率无法衡量 。3.对新版本的重复测试很难实施 4.存在大量冗余测试影响测试效率。
测试用例的产生就是为了解决上述的问题。所以测试用例主要优点如下：

1.衡量需求的覆盖率
2.有着复用性，对之后的测试用例书写有着借鉴意义
3.可以用于回归测试
4.防止遗漏测试需求

2>说一下什么是BUG（软件错误）？

所谓的BUG，指的就是

当软件规格说明书（软件需求）存在并且并且合理，如果此时软件的功能和规格说明书不符合，那这就是一个BUG
或者说当软件规格说明书（软件需求）不存在，但是用户需求存在并且合理，软件功能和用户功能不符合，这也是BUG。

<3>关于开发模型和测试模型

1>关于开发模型

(1)软件开发的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。

(2)瀑布模型（Waterfall Model）

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点： 1.阶段性强，每一个阶段比较独立； 2.强调早期计划及需求调查； 
3.强调产品测试。

缺点：1.依赖于早期进行的唯一一次需求调查，不能适应需求的变化； 2.由于是
单一流程，开发中的经验教训不能反馈应用于本产品的过程； 3.风险往往迟至后
期的测试阶段才显露，因而失去及早纠正的机会。

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

(3)螺旋模型（Spiral Model）

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

优点： 1.强调严格的全过程风险管理。 2.强调各开发阶段的质量。 3.提供机会
检讨项目是否有价值继续下去。  4.强调每一次迭代的测试质量和风险分析

缺点：风险管控人力物力投入很多，成本比较大

(4)增量模型和迭代模型

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。
这两者虽然经常混为一谈，但是还是有区别的，比如说现在有ABCD四个功能块

增量模型：第一周开发A B功能块，第二周开发C D功能块
迭代模型：第一周先开发 A B C D基础功能，第二周在第一周的基础上进行完善
其他功能。

特点就是抗风险能力强。

(5)敏捷模型

敏捷开发有很多种方式，其中scrum是比较流行的一种。

scrum角色由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
其中

product owner负责整理user story(用户故事)，把用户需求转化为userstory
scrum master 负责召开各种会议，协调项目，为研发团队服务。
研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

敏捷模型具体流程如下：

1.发布计划会议：产品负责人负责整理user story，排出这一期迭代要完成的userstory列表，也就是sprintbacklog
2.迭代计划会议：分析用户故事，项目团队把userstory分解成一个个的任务，分配开发人员指定计划
4.每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
5.演示会议：迭代结束之后，召开演示会议，同时向大家展示本次迭代取得的成果。PO整理不足之处，形成新的story。
6.回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

敏捷模型的主要特点就是：轻文档，轻流程，重目标，重产出

2>关于测试模型

(1)V模型

V模型最早是由Paul Rook在20世纪80年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种

优点：独立性强，并且清楚的描述了测试阶段和开发过程期间各阶段的对应关系

缺点：把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

（2W模型

W模型也叫双V模型

特点就是：1.每一个阶段独立性强
2.测试一开始就介入
3.可以保证前期的问题及时发现和纠正
4.测试和并发并行

缺点就是：每一个阶段都是串行的过程，一个阶段完了之后进行下一个阶段。

注意这里是不支持敏捷开发的，因为我们要拥抱变化。

<4>关于软件测试的生命周期

软件测试的生命周期： 需求分析→测试计划→ 测试设计→ 测试开发→ 测试执行→ 测试评估

1>软件测试&软件开发生命周期

需求阶段
测试人员了解需求、对需求进行分解，得出测试需求
计划阶段
根据需求编写测试计划/测试方案
设计阶段
测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例
编码阶段
测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。
测试阶段
测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告。
运行维护
测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人。

2>如何描述一个BUG

一个合格的bug描述应该包括以下几个部分

1、测试版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2、测试环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是
app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、测试步骤
描述问题重现的最短步骤。
4、预期结果和实际结果
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。
要相信：测试人员是最懂需求的。
5、提交对应错误信息
描述错误的现象。crash等可以上传log，UI问题可以有截图。

3>BUG的级别

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

大约可以分为以下几种：

1、Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2、Critical（严重）
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）
4、Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

4>关于BUG的声明周期

每个公司、每一个工具对bug生命周期的定义都是不一致的，测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open->rejected->closed

缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。

二丶关于测试用例

<1>测试用例的基本要素

测试用例就是向被测试系统发起的一系列集合，包含测试环境，测试数据，测试步骤，预期结果等。

<2>为什么需要测试用例

换一个说法，测试用例有什么好处？

1.测试用例是测试执行的依据
2.回归测试的时候可以复用
3.衡量需求的覆盖率
4.自动化测试的依据
5.借鉴意义，后续测试人员可以借鉴前者写的东西

<3>基于需求设计测试用例

需求是测试人员进行测试的依据，测试人员首先要分析需求，验证需求的正确性与合理性，无二义性，逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计；在分析测试需求时，一般分为功能测试需求和非功能测试需求

1>功能性需求

对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以下，通常包括以下几个方面。

（1）系统各个功能界面的验证
（2）借助业务把功能串起来进行测试
（3）功能的一致性，交互性（多功能互操作）的测试
（4）系统的不同输入，结果输出的业务数据测试。
（5）功能的错误操作，异常操作的测试（属于负面测试）
（6）功能实现用到的算法验证，有时需要用运代码评审
（7）用户操作的易用性，用户体验，往往结合功能测试同时验证

3>非功能性需求

非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。
所以总结一下，非功能性需求就是在功能的基础上做一些限制，满足特定用户的场景，让用户有更好的体验。
这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。

（1）纯客户端软件，比如字处理软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。
（2）企业内部的客户端/服务端（C/S)应用系统。比如电子邮件，即时通信系统（飞Q，企业QQ）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全性，兼容性要求不高。
（3）外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

<2>具体的设计方法

1>等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过

有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
无效等价类：根据需求说明书，不满足需求的集合。

等价类可以解决测试用例无法穷举的情况

那这里有一个问题，有效等价类是合理的，是验证软件是否实现了功能和性能，那无效等价类呢？不满足需求的话还需要检测嘛？答案是：需要的。

2>边界值

边界值我们是和等价类在一起使用的，也就是针对输入和输出的边界针对性的进行测试用例的设计，叫做边界值法。所以其实该测试用例就是来自于等价类的边界值

3>错误猜测法

这个错误猜测法，就很考验测试人员本身的功底了。错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。
这个方法的缺点是难以系统化，并且过度依赖个人能力。

4>场景法

所谓场景法，就是把一个个孤立的功能串联起来形成一个场景，每一个功能的选择触发不同的走向，根据这些不同功能的不同输入触发形成的场景进行测试用例的设计。举一个例子，比如说银行ATM机的插卡流程

5>因果图法

所谓因果图，就是一种逻辑图，恒等，与，或，非。能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、
程序的输出又依赖于输入条件的各种情况。

恒等：输入为真，输出为真
与：输入的多个条件为真，输出才为真
或：输入的多个条件有一个为真，输出就是真
非：输入为真，输出为假。输入为假，输出为真

那么我们怎么根据因果图法去设计测试用例呢？

1.分析所有的输入和输出
2.找出输入和输出之间的逻辑关系
3.根据输入和输出画因果图
4.根据因果图画判定表
5.根据判定表去设计测试用例

6>正交法

所谓正交法，就是由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）
水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值）
正交表的构成：
行数(Runs)：正交表中的行的个数，即试验的次数,用N代表。
因素数(Factors)：正交表中列的个数，用C代表。
水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数”，用T代表。
正交表的表示形式： L=行数(水平数*因素数) L=N(TC)
正交表的两条性质：1.每一列中各数字出现的次数都一样多 2.任何两列中的各有序数对出现的次数都一样多。

设计测试用例的步骤

1、有哪些因素（变量）
2、每个因素有哪几个水平（变量的取值）
3、选择一个合适的正交表
4、把变量的值映射到表中
5、把每一行的各因素水平的组合作为一个测试用例
6、加上你认为可疑且没有在表中出现的用例组合

三丶测试分类

<1>按照测试对象划分

1>界面测试

界面测试（简称UI测试)，指按照界面的需求（一般是UI设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：

1.验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
2.验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
3.对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等功能是否可以正常使用，有效和无效的状态是否设计合理；
4.界面的布局和色调符合当下时事的发展

比如常见的界面错误就有重叠，截断，文字不合理自动换行等。

2>可靠性测试

可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示。
可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%，一般来说可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%

如果可用性达到99.99%，对于一个全年不间断（7*24的方式）运行的系统，意味着全年（252600min)不能正常工作的时间只有52min，不到一个小时。
如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min。

当然这个是要分种类的，不同的系统有不同的要求

3>容错性测试

容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。主要有以下几方面

1.输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。比如数据级测试，校验测试，环境容错性测试，界面容错性测试
2.灾难恢复性测试
通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

4.文档测试

在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。主要有以下几个关注点

文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性

5>兼容性测试

兼容性测试需求是指明确要测试的兼容环境，考虑软，硬件的兼容，就软件兼容来说，主要考虑以下几个方面：

1.系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的。
2.测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容
3.测试与第三方系统以及第三方数据的兼容性

6>易用性测试

是产品在使用起来更加灵活和，舒适。软件产品也始终关注用户体验，让用户获得舒适，易用的体验，针对软件这方面的测试称之为易用性测试。
易用性包含七个要素：符合标准和规范，直观性，一致性，灵活性，舒适性，正确性和实用性。

1.标准性和规范性
对于现有的软件运行平台，通常其UI标准已经不知不觉地被确立了，成为大家的共识。多数用户已经习惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。比如安装软件的界面的外观，在什么场合使用恰当的对话框等。
所以用户界面上的各中信息应该符合规范和习惯，否则用户使用起来会不舒适，并得不到用户的认可。测试人员需要把与标准规范，习惯不一致的问题报告为缺陷
2.直观性
用户界面的直观性，要求软件功能特性易懂，清晰。用户界面布局合理，对操作的响应在用户的预期之中。比如数据统计结果用报表的形式（条形图，扇形图等）展示清晰直观；现在主流的很多搜索引擎和日历的设计也有直观性的特点；
3.灵活性
软件可以有不同的选项以满足不同使用习惯的用户来完成相同的功能。但是灵活性的设计要把握好度，不然可能由于太多的用户状态和方式的选择，增加了软件设计的复杂性，和程序实现的难度。
例如手机键盘有九宫格和全键盘，还支持手写，满足了不同用户的需求
4.舒适性
主要强调界面友好，美观，操作过程顺畅，色彩用运恰当，按钮的立体感等。例如左手鼠标的设置给习惯用左手的人带来了便利，也为右手十分劳累时提供了另一种途径；

7>安装卸载测试

应用的安装和卸载在任何一款APP中都属于最基本功能。一旦出错，就属于优先级为紧要Critical的缺陷。主要需要考虑以下方面：

1.软件不同的安装和卸载方式；
2.应用是否可以在不同的环系统，版本下安装（安装兼容性）
3.安装或者卸载过程中是否可以手动暂停，或者取消
4.安装空间不足的时候系统是否有提示
5.是否可以正常的卸载，以及应用软件的各种卸载方式
6.卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等

8>安全测试

安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下

1.输入域，如输入恶性或者带有病毒的脚本或长字符串；
2.代码中的安全性问题，如SQL/XML注入
3.不安全的数据存储或者传递
4.数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
5.有问题的访问控制，权限分配等
6.假冒ID：身份欺骗
7.篡改，对数据的恶意修改，破坏数据的完整性

安全性测试的方法有代码评审，渗透测试，安全运维等，常用的静态安全测试工具有，Coverity，IBMAppscan Source，HPFortify，常用的动态安全测试有OWASP的ZAP，HP WebInspect等。其中静态安全测试是常用的安全性测试的方法。

9>性能测试

我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运
行越来越慢等问题，这些问题都是系统的性能问题引起的。
要进行软件产品的性能问题，要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完
成性能测试的设计和执行，最后要进行持续的性能调优。常见的性能问题如下

资源泄露
资源瓶颈
线程死锁，线程阻塞
查询速度慢或效率低
受外部系统影响越来越大

10>内存泄露测试

很多软件系统都存在内存泄露的问题，尤其是缺乏自动垃圾回收机制的“非托管”语言编写的程序，例如C、CH、Delphi等。从用户使用的角度来看，内存泄露本身不会造成什么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。可以把这种软件的问题比喻成软件的“慢性病”。造成内存泄露的原因有很多，最常见的有以下几种。

分配完内存之后忘了回收。
程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）。
某些API函数的使用不正确，造成内存泄露。

内存泄漏的检测方法

1.人工静态法：代码走读，人工查找未被回收的内存。
2.自动工具法：借助相应测试内存泄漏的工具，如Visual Leak Detector，记录每次内存分配，清楚告诉用户内存是如何泄漏的。

<2>按照是否查看代码划分

在软件测试岗位的面试中，常常被面试官问到的概念就是黑盒和白盒的测试了，下面就来彻底讨论一下

1>黑盒测试

黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。所以，黑盒测试又称之为数据驱动测试，只注重软件的功能黑盒测试的优点

1. 不需要了解程序内部的代码以及实现，不关注软件内部的实现。
   2.从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维
   3.测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。

黑盒测试的缺点是不可能覆盖所有代码

常用的方法有等价类，边界值，错误猜测法，因果图法，场景法

2>白盒测试

白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。
白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖

3>灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

<3>按开发阶段划分

1>单元测试

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试

测试阶段：编码后或者编码前（TDD）
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

2>集成测试

集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

3>系统测试

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试

测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

4>回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

5>冒烟测试

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。
回归测试和冒烟测试都属于系统测试。

6>验收测试

验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求

测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）。
测试人员：主要是最终用户或者需求方。
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试(功能...各类文档等)

<4>按测试实施组织

1>α测试(Alpha Testing)

手机出厂前最后一次测试，开发和测试人员不参与。

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。

大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成

2>β测试(Beta Testing)

Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个场所进行。
α测试与Beta测试的区别：
测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。

3>第三方测试

介于开发方和用户方间的组织的测试。

<5>按是否运行划分

1>静态测试(Static testing)

所谓静态测试（static testing）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。不以测试数据的执行而是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格和规格等来检查程序的正确性。

2>动态测试(Dynamic testing)

动态测试（dynamic testing），指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行
程序。

<6>按是否手工划分

1>手工测试(Manual testing)

手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。总结优缺点：
优点：自动化无法替代探索性测试、发散思维结果的测试。
缺点：执行效率慢，量大易错。

2>自动化测试(Automation Testing)

就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。
自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。

自动化实施步骤：
1.完成功能测试，版本基本稳定
2.根据项目特性，选择适合项目的自动化工具，并搭建环境
3.提取手工测试的测试用例转化为自动化测试的用例
4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期
5.生成自动测试报告
6.持续改进，脚本优化。

<7>按测试地域划分

1>国际化测试

软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及，还有软件外包行业的兴起，软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。
本地化和国际化测试与其他类型的测试存在很多不同之处。下面是本地化和国际化测试 的一些要点。
1、本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否墼齐、不走样。
2、是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括
声音的提示）、日志等。
3、在不同的屏幕分辨率下界面是否正常显示。
4、是否存在不同的字体大小，字体设置是否恰当。
5、日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日
年。
6、排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按
照首字母排序。
7、在不同的国家采用不同的度量单位，软件是否能自适应和转换。
8、软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上。
9、软件是否能在Windows或者其他操作系统的当地版本上正常运行。
10、联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当， 是否有语法
错误。
软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。它要求测 试人员具备一定的翻译能力、语言文化，同时具备测试人员的基本技能。

2>本地化测试

之前我们所讲的全是本地化测试。