初级软件测试工程师零基础入门指南

１.基本概念

１.１软件

　软件就是可以在计算机上运行的计算机程序，如操作系统Windows、办公软件Office、聊天ＱＱ、手机游戏等。软件和我们的生活和工作之间的联系越来越密切。

１.２软件测试

　软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件品质，并对其是否能满足设计要求进行评估的过程。

　软件测试的现实定义是：软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。

１.３测试的方法

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

黑盒测试

黑盒测试，软件测试的主要方法之一，也可以称为功能测试、数据驱动测试或基于规格说明的测试。测试应用程序的功能，而不是其内部结构或运作。测试者不需具备应用程序的代码、内部结构和编程语言的专门知识。测试者只需知道什么是系统应该做的事，即当键入一个特定的输入，可得到一定的输出，这是从用户的角度针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构。测试用例是应用系统应该做的功能，照规范、规格或要求等设计。测试者选择有效输入和无效输入来验证是否正确的输出。此测试方法可适合大部分的软件测试，例如单元测试(unit testing)、集成测试(integration testing)以及系统测试(system testing)。

白盒测试

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

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

１.４测试的类型

功能测试

按照测试软件的各个功能划分进行有条理的测试，在功能测试部分要保证测试项覆盖所有功能和各种功能条件组合。

更详细的描述请参见“黑盒测试”。

系统测试

对一个完整的软件以用户的角度来进行测试，系统测试和功能测试的区别是，系统测试利用的所有测试数据和测试的方法都要模拟成和用户的实际使用环境完全一样，测试的软件也是经过系统集成以后的完整软件系统，而不是在功能测试阶段利用的每个功能模块单独编译后生成的可执行程序。

极限值测试

对软件在各种特殊条件，特殊环境下能否正常运行和软件的性能进行测试。

特殊条件一般指的是软件规定的最大值，最小值，以及在超过最大，小值条件下的测试。

特殊环境一般指的是软件运行的机器处于CPU高负荷，或是络高负荷状态下的测试，根据软件的不同，特殊环境也有过不同。

性能测试

性能测试是对软件性能的评价。简单的说，软件性能衡量的是软件具有的响应及时度能力。因此，性能测试是采用测试手段对软件的响应及时性进行评价的一种方式。根据软件的不同类型，性能测试的侧重点也不同。

压力测试

压力测试，确立系统稳定性的一种测试方法，在软件工程、金融风险管理等领域应用比较普遍。通常在系统正常运作范围之外进行，以考察其功能极限和隐患。

压力测试与性能测试的区别

压力测试常常和性能测试相混淆。它们主要不同点是，压力测试要求进行超过规定性能指标的测试。例如一个站设计容量是100个人同时点击，压力测试就要是采用120个同时点击的条件测试。

１.５测试的阶段

单元测试

单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位—模块。单元测试一般由开发人员完成。

集成测试

集成测试又称组装测试，是将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。

实践表明，有时模块虽然可以单独工作，但是并不能保证组装起来也可以同时工作。

系统测试

系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。

回归测试

回归测试是为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件测试阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。

与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用，因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。

Alpha测试

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

在这个阶段中，通常是在开发单位由开发人员与测试的测试人员，以模拟或实际操作性的方式进行验证测试。

Beta测试

Beta测试和黑盒测试的区别

对Alpha和Beta测试常见的一个认识误区是“Beta测试＝黑盒测试”。实际上，Alpha和Beta测试对应在软件产品发布之前的Alpha和Beta阶段，而白盒、黑盒和灰盒测试技术是从技术和方法层面对测试的描述，不应该将这两部分概念混淆。

验收测试

验收测试是系统部署到用户环境后，用户运行系统，考察系统是否满足用户需求的过程。验收测试是用户主导的，用户可能聘请专家帮助验收测试。

１.６软件测试的作用

1.对产品质量完成全面的评估，为软件产品发布（如验收测试）、软件系统部署（如性能规划测试）、软件产品鉴定（第三方独立测试）委托方和被委托方纠纷仲裁（第三方独立测试）和其它决策提供信息；

2.通过持续的测试（包括需求评审、设计评审、代码评审等）可以对产品质量提供持续的、快速的反馈，从而在整个开发过程中不断地、及时地改进产品的质量，并减少各种返工，降低软件开发的成本；

3.通过测试发现所要交付产品的缺陷，特别是尽可能地发现各种严重的缺陷，降低或消除产品质量风险，提高客户的满意度，扩大市场份额，提高客户的忠诚度。

4.通过对缺陷进行分析，找出缺陷发生的根本原因（软件过程中的问题，包括错误的行为方式）或总结出软件产品的缺陷模式，避免将来犯同样的错误或产生类似的产品问题，达到缺陷预防的目的

２.初级软件测试工程师主要工作

２.１编写功能测试用例

１）测试用例设计步骤

设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：
1、测试需求分析
　　从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。
　　测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。
2、业务流程分析
　　软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。
从业务流程上，应得到以下信息：
A、主流程是什么
B、条件备选流程是什么
C、数据流向是什么
D、关键的判断条件是什么
3、测试用例设计
　　完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。
黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：
功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。
适合的技术：由业务需求和设计说明导出的功能测试、等价类划分
边界测试：对某个功能的边界情况进行测试。
适合的技术：边界值划分
异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的，类似这样的情况需要书写相关的异常测试。
适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、
性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。
适合的技术：业务需求和设计说明导出的测试
压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或络流量给应用软件兼容测试：测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。
4、测试用例评审
测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。
测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。

5、测试用例更新完善
测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。

２）测试用例设计方法

黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里，主要讨论的是黑盒测试的测试用例的设计方法。

一、等价类划分

等价列划分设计方法是把所有可能的输入数据划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例，测试某等价类的代表值就等于对这一类其他值的测试。

使用等价类划分方法设计测试用例主要有两个步骤：（1）确定等价类；（2）生成测试用例。

1、划分等价类

等价类划分有两种不同的情况：有效等价类代表对程序的有效输入和无效等价类代表不正确的输入值，设计时要同时考虑这两种等价类。下面是确定等价类的原则：

（1）在输入条件规定了取值范围的情况下，则可以确立一个有效等价类（在取值范围之内）和两个无效等价类（小于取值范围和大于取值范围）。例如：使用手机发送短信的时候，短信内容长度必须在70个字符之内，则有效等价类：短信内容长度在70个字符之内，无效等价类：短信内容长度为0、短信内容长度大于70。

（2）在输入条件规定了取值的个数的情况下，则可以确立一个有效等价类（在取值个数范围之内）和两个无效等价类（小于取值个数和大于取值个数）。例如：一名学生一个学期可以选修一至五门课程，则有效等价类为：1<=学生选修课程<=5，无效等价类为：没有选修课程、选修课程大于5

（3）在输入条件规定了输入值的集合的情况下，则可以确立一个有效等价类和一个无效等价类。比如：发送短信的编码的取值范围是0、3、4、8、15或16，则有效等价类是：短信编码为0或3或4或8或15或16，无效等价类是：短信编码不是0或3或4或8或15或16其中任何一种。

（4）在输入条件规定了 “必须如何”的条件的情况下，则可以确立一个有效等价类和一个无效等价类。例如：变量的命名比如以大写字母开头，则有效等价类为：变量命名以大写字母开头，无效等价类为：变量开头非答写字母开头。

（5）在输入条件是一个布尔量的情况下，可以确立一个有效等价类和一个无效等价类。例如：在神州行手机码预扣费成功的情况下，允许该用户发送短信，则有效等价类为：神州行预扣费成功，无效等价类为神州行预扣费失败。

（6）在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类。

（7）在规定了输入数据必须遵守的规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

（8）在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

2、生成测试用例

在确立了等价类后，可建立等价类表，列出所有划分出的等价类，过程为：

（1）为每一个等价类规定一个唯一的编。

（2）设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。

（3）设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

二、边界值分析法

边界条件指的是输入和输入等价类中刚好处于边界、或超过边界或小于边界的状态，使用边界值分析方法设计测试用例应先确定边界情况，然后选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。

基于边界值分析方法选择测试用例的原则：

（1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界值设计有效测试用例，以及刚刚超过这个范围的边界值作设计无效测试用例。比如：短信内容的有效长度为70个汉字以内，则有效测试用例：短信内容长度为1，短信内容长度为70个汉字，无效测试用例：短信内容长度为0，短信内容长度为71个汉字。

（2）如果输入条件规定了值的数量，则应取最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试输入的数据。例如：短信的有效编码为1~255，则应取0、1、255、256设计边界值测试用例。

（3）根据规格说明的每个输出条件，使用前面的原则1。

（4）根据规格说明的每个输出条件，使用前面的原则2。

（5）如果程序的输入或输出是一个有序集合，则应选取集合的第一个元素和最后一个元素设计测试用例。

（6）如果程序中使用了一个内部数据结构，应当选择这个内部数据结构边界上的值设计测试用例。

（7）分析规格说明书，找出其他可能的边界条件。

三、因果图法

因果图法是一种适合于描述对于多种条件的组合、相应产生多个动作的形式的测试用例设计方法。

利用因果图生成测试用例的步骤为：

（1）将规范说明书分解成可执行的片段。

（2）确定规格说明书中的因果关系。分析软件规格说明描述中那些是原因，那些是结果，并给每个原因和结果赋予一个标识符。

（3）分析软件规格说明描述的语义，找出原因和结果之间、原因和原因之间的关系，并将其转换成因果图。

（4）在因果图上加上注解符，用一些记表明约束或限制条件。

（5）跟踪图中的状态变化情况，把因果图转换为判定表。

（6）把判定表的每一列拿出来作为依据，设计测试用例。

四、错误推测法

错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

错误推测法的基本思路是列举出程序中所有可能有的错误和容易发生错误的清单，根据清单设计测试用例；另一个思路就是在阅读规格说明时有哪些容易被程序员忽略的内容来设计测试用例。

错误推测法是一种非常有效的测试用例设计方法，这要求测试人员有丰富的测试经验和对业务的处理非常熟悉。比如，在短信发送的时候，如果发送短信之后，对方关没有响应或者超时响应或者没有回复状态告，那程序怎样处理呢？

进阶参考：

测试用例设计

http://www.cnblogs.com/mayingbao/category/82529.html

　　如何编写有效测试用例

http://blog.csdn.net/smilings/article/details/840917

２.２执行功能测试

　　根据测试计划和测试用例进行测试，在测试过程中记录测试结果和提交发现的Bug。下班前将当天的测试情况汇给测试组长或测试经理。

２.３提交Bug

２.２.１Bug基本概念

１）BUG的定义

BUG：(小错误，缺陷，不足，过失 …) 一个计算机bug指在计算机程序中存在的一个错误（error）、缺陷（flaw）、疏忽（mistake）或者故障（fault），这些bug使程序无法正确的运行。Bug产生于程序的源代码或者程序设计阶段的疏忽或者错误。

Defect：(缺陷) 在软件工程（Software Engineering）中，软件与它的需求（requirements）不一致，常常指软件无法正确完成需求所要求的功能，也称之为bug。

２）BUG分级－严重性

我们一般把发现的错误(Bug)/缺陷(Defect)按严重性分为4类：

1.严重：系统崩溃或挂起等导致系统不能继续运行；

2.主要：使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题；

3.次要：系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题，如：显示不正确但输出正确；

4.轻微：界面拼写错误或用户使用不方便等小问题或需要完善的问题；

３）BUG分级－优先级

我们也把发现的错误按优先级分为三种：

1.高：立即修改；

2.中：必须修改，但不一定马上修改；

3.低：允许不修改；

一般来说是越影响用户接受或使用该产品的错误优先级越高。

２.２.２怎样提交Bug

首先，确保你所发现的问题是确实是一个bug，不要出现因为测试人员操作错误或配置错误所引起的“bug”，这样会降低你在开发人员心中的可信度。在测试的时候，如果发现测试的实际结果与预期测试结果不符时，不要着急马上 bug，先想想为什么会出现错误。作为专业的测试人员，应该能够对出现的问题进行跟踪，确认了在配置、操作没有错误的前提下，通过追踪分析确认所测试的业务流程确实是存在bug，并能大概对bug的产生原因进行定位。测试人员，需要做到专业，尽量少给开发找麻烦，不要制造实际上并不存在的bug。

确认了所发现的问题是一个bug之后，按照测试步骤再执行一次，确保bug是可重现的而不是随机的。如果bug不能重现，应该尽量找到bug重现的规律，在一些比较难重现的问题可以找开发配合一起查找原因，如果还是无法重现则需要在bug report中对出现的问题描述清楚并说明出现的随机性。

接下来就是填写bug report了，在填写bug report的时候，最重要的是bug的标题和bug描述。在bug 告中，首先用一句话对bug进行简要精确的描述作为bug的标题，让开发或项目经理一看就知道存在什么问题，比如“XX模块在压力测试2小时后出现内存泄露”。而在bug的描述中，需要使用简明准确的语言描写出现bug的测试步骤、实际的测试结果、预期的测试结果和结论；也就是说描述导致出现bug的操作步骤是怎样，由测试步骤所做的操作引起的测试结果是什么，而预期的结果应该是怎样，并由实际结果与预期结果相对比说明问题所在。比如：“在管理页新增用户，当新增的用户登录名名称很长（例如登录名长度为输入框允许的最大长度），按‘新增’按纽新增后系统提示已经有该用户存在，而事实上该用户并不存在，建议对超长的用户名进行处理。”

在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的流程？同一个故障是否会引起更加严重的问题？如果存在，也需要提出来让开发一并处理。

在开发对bug进行修改之后，测试需要着怀疑的态度认真地对问题进行验证，需要严格按照测试步骤来进行测试，检查开发是否已经正确修改了所出现的问题，以及开发对bug进行了修复之后是否会引进新的问题。不要相信开发说“已经修改好了，肯定没问题了”就不对问题进行细致的检查了，如果开发修改得不彻底，问题仍然会存在的，或者可能会由于开发在修改bug的时候忽略了另一些细节导致了新bug的出现。尽量不要在关闭bug之后，才发现这个问题还没有修改彻底；也不要出现bug关闭之后，出现了新的bug。

测试对bug进行验证确认已经修改ok之后，关闭bug。在关闭的时候，应该对Bug最终修改结果进行简要描述，如果bug的修改引起配置或数据库或业务流程的变更，也需要在bug关闭描述中进行说明。

进阶参考：

如何编写有效bug 告

http://blog.csdn.net/smilings/article/details/840840

　准确告软件缺陷

http://blog.csdn.net/kerryzhu/article/details/1436398

２.３编写功能测试告

测试告是测试人员在测试过程中用于反映测试状况的文档。其实测试告的内容基本都是模板的那些，只是在实际测试过程中，如何去整理内容结构，使得告的通常阅读者：开发人员、测试经理、产品经理、项目负责人能够一目了然地查看想要了解的内容才是测试告最值得注意的地方。

产品要想有广阔的市场，得需要切实了解用户的需求及感受，同理测试告要想能够让阅读者能够满意，也需要能将质量情况条理性地列出。通常来说，开发人员往往希望能从告中了解缺陷的情况，而测试经理还关心用例的执行情况及覆盖率、项目责任人则最关心还有多少问题，此次版本是否测试通过。因此测试告根据内容的侧重点，分为『版本测试告』和『总结测试告』，目的也是希望不将所有内容列举在一个告中，造成内容臃肿繁杂。

总体来说，功能测试告的编写就是要做到简约而不简单。

版本测试告

ü 主要反映开发人员提交的测试版本的质量状况。

ü 测试用例设计与执行、缺陷概况及问题概要是版本测试告中的主要内容。

ü 测试人员在每个轮次测试结束时编写提交。

其内容结构和每个章节的编写内容说明如下：

大纲

子章节

详细内容

测试简介

测试目的

本次测试的背景及主要内容

测试资源

测试人员、本次测试开始和截止日期、花费工作日

测试环境

硬件环境

实际情况的详细列举，过低的配置、软件版本的不匹配、络拓扑的错误都会让提交的缺陷缺乏说服力，也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。

软件版本

络拓扑图

测试方法

无

本次测试的功能点、各功能点对应的测试用例设计、测试用到的测试工具

测试用例

用例分析

测试用例维护记录

用例执行情况

用例执行总数、通过用例数、未通过用例数、阻塞用例数

测试执行率=（已执行的用例数）/用例总数

测试用例效率=发现的缺陷总数/测试用例的数量

测试过程

缺陷统计

新建bug数、修复bug数、未修复bug数、bug总数

问题摘要

遗留问题、拒绝问题、挂起问题、长期验证问题、待评估问题

测试结果

资源占用

测试项目的启动、退出时间

测试项目的CPU占用率初始值、峰值（如果项目启动会有多个进程，则分多个进程进行统计）

测试项目的内存占用初始值、峰值

测试结论

测试结论不论仅仅只是测试通过或不通过，应该使用详细的数据来支持测试结论，需要列举的数据有:

『测试用例通过率』

总用例

未通过用例

未通过比率

『遗留bug情况』

总bug数

未修复bug

遗留bug率

备注

用例执行记录

插入测试用例的详细执行结果文档

资源监控记录

说明资源占用监控的场景，详细列举各场景的监控时长、监控内容，场景操作

总结测试告

ü 主要偏重于各已测试版本的缺陷变化分析，风险预估。

ü 各测试版本质量情况概况统计、缺陷分布统计、风险分析是总结测试告中的主要内容。

ü 测试人员在项目发布上线前编写提交。

其内容结构和每个章节的编写内容进行说明如下：

标题