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

忘是亡心i 2021-09-17 13:46 696阅读 0赞

注 : 本文来源：[ack Tang的博客][ack Tang]  《  [初级软件测试工程师零基础入门指南][Link 1]  》

> **１.基本概念**
> 
> **１.１软件**
> 
> 　软件就是可以在计算机上运行的计算机程序，如操作系统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_www.cnblogs.com_mayingbao_category_82529.html]
> 
> 　　如何编写有效测试用例
> 
> [http://blog.csdn.net/smilings/article/details/840917][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_smilings_article_details_840840]
> 
> 　准确报告软件缺陷
> 
> [http://blog.csdn.net/kerryzhu/article/details/1436398][http_blog.csdn.net_kerryzhu_article_details_1436398]
> 
> **２.３编写功能测试报告**
> 
> 测试报告是测试人员在测试过程中用于反映测试状况的文档。其实测试报告的内容基本都是模板的那些，只是在实际测试过程中，如何去整理内容结构，使得报告的通常阅读者：开发人员、测试经理、产品经理、项目负责人能够一目了然地查看想要了解的内容才是测试报告最值得注意的地方。
> 
> 产品要想有广阔的市场，得需要切实了解用户的需求及感受，同理测试报告要想能够让阅读者能够满意，也需要能将质量情况条理性地列出。通常来说，开发人员往往希望能从报告中了解缺陷的情况，而测试经理还关心用例的执行情况及覆盖率、项目责任人则最关心还有多少问题，此次版本是否测试通过。因此测试报告根据内容的侧重点，分为『版本测试报告』和『总结测试报告』，目的也是希望不将所有内容列举在一个报告中，造成内容臃肿繁杂。
> 
> 总体来说，功能测试报告的编写就是要做到简约而不简单。
> 
> **版本测试报告**
> 
> ü  主要反映开发人员提交的测试版本的质量状况。
> 
> ü  测试用例设计与执行、缺陷概况及问题概要是版本测试报告中的主要内容。
> 
> ü  测试人员在每个轮次测试结束时编写提交。
> 
> 其内容结构和每个章节的编写内容说明如下：
> 
> **大纲**
> 
> **子章节**
> 
> **详细内容**
> 
> 测试简介
> 
> 测试目的
> 
> 本次测试的背景及主要内容
> 
> 测试资源
> 
> 测试人员、本次测试开始和截止日期、花费工作日
> 
> 测试环境
> 
> 硬件环境
> 
> 实际情况的详细列举，过低的配置、软件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力，也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。
> 
> 软件版本
> 
> 网络拓扑图
> 
> 测试方法
> 
> 无
> 
> 本次测试的功能点、各功能点对应的测试用例设计、测试用到的测试工具
> 
> 测试用例
> 
> 用例分析
> 
> 测试用例维护记录
> 
> 用例执行情况
> 
> 用例执行总数、通过用例数、未通过用例数、阻塞用例数
> 
> 测试执行率=（已执行的用例数）/用例总数
> 
> 测试用例效率=发现的缺陷总数/测试用例的数量
> 
> 测试过程
> 
> 缺陷统计
> 
> 新建bug数、修复bug数、未修复bug数、bug总数
> 
> 问题摘要
> 
> 遗留问题、拒绝问题、挂起问题、长期验证问题、待评估问题
> 
> 测试结果
> 
> 资源占用
> 
> 测试项目的启动、退出时间
> 
> 测试项目的CPU占用率初始值、峰值（如果项目启动会有多个进程，则分多个进程进行统计）
> 
> 测试项目的内存占用初始值、峰值
> 
> 测试结论
> 
> 测试结论不论仅仅只是测试通过或不通过，应该使用详细的数据来支持测试结论，需要列举的数据有:
> 
> 『测试用例通过率』
> 
> **总用例**
> 
> **未通过用例**
> 
> **未通过比率**
> 
> 『遗留bug情况』
> 
> **总bug数**
> 
> **未修复bug**
> 
> **遗留bug率**
> 
> 备注
> 
> 用例执行记录
> 
> 插入测试用例的详细执行结果文档
> 
> 资源监控记录
> 
> 说明资源占用监控的场景，详细列举各场景的监控时长、监控内容，场景操作
> 
> **总结测试报告**
> 
> ü  主要偏重于各已测试版本的缺陷变化分析，风险预估。
> 
> ü  各测试版本质量情况概况统计、缺陷分布统计、风险分析是总结测试报告中的主要内容。
> 
> ü  测试人员在项目发布上线前编写提交。
> 
> 其内容结构和每个章节的编写内容进行说明如下：
> 
> **标题**
> 
> **子章节**
> 
> **详细内容**
> 
> 测试简介
> 
> 测试目的
> 
> 本次测试的背景及主要内容
> 
> 测试资源
> 
> 测试人员、第一轮测试的开始日期和最后一轮测试的截止日期、总共花费工作日统计
> 
> 测试环境
> 
> 硬件环境
> 
> 实际情况的详细列举，过低的配置、软件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力，也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。
> 
> 软件版本
> 
> 网络拓扑图
> 
> 测试过程
> 
> 各版本测试状况
> 
> 各测试版本的计划提交日期、实际提交日期、测试类型（回归或全量）、测试耗时、备注（被打回或提交补丁次数）
> 
> 各版本bug统计
> 
> 各测试版本的新建bug数、修复bug数、遗留bug数，表格统计、线形图或饼状图辅助表示
> 
> 测试分析
> 
> 缺陷分析
> 
> 缺陷的总体分布情况，以线形图或饼状图辅助表示
> 
> ²  根据功能模块进行划分
> 
> ²  根据严重、较严重、普通、轻微级别进行划分
> 
> 遗留问题
> 
> 打开状态bug、长期验证bug、用户体验问题
> 
> 测试小结
> 
> 资源占用
> 
> 测试项目的启动、退出时间
> 
> 测试项目的CPU占用率初始值、峰值（如果项目启动会有多个进程，则分多个进程进行统计）
> 
> 测试项目的内存占用初始值、峰值
> 
> 风险分析
> 
> 测试进度、人员安排导致的风险
> 
> 测试内容考虑范围之外导致的风险
> 
> 测试环境不全面导致的风险
> 
> 其他因素导致的风险
> 
> 进阶参考：
> 
> 软件测试阶段报告编写指南
> 
> http://blog.csdn.net/smilings/article/details/1032221
> 
> 软件测试报告编写指南
> 
> http://blog.csdn.net/smilings/article/details/1032246
> 
> **３.测试牛人Randall W.Rice给测试新手的话**
> 
> **前言**
> 
> 因为已经带领和训练测试团队多年，所以按惯例我总有些东西确定需要传达给测试新手。不管你是一个测试新手还是一个经验丰富的测试专家，都有不少有益的东西需要牢记在心。
> 
> **1****、你是一个检查者，你不需要为质量负责**
> 
> 很多测试人员误入歧途，不明白他们是评测产品的而不是控制产品的。这两者之间有着天壤之别。例如，一个测试团队花费好几周时间测试并发现很多缺陷，只是为了看着管理层决定发布一个有已知严重缺陷的产品。测试团队经常会感到士气受挫，置疑他们测试的目的。
> 
> 我询问团队中的成员他们是否被支付薪水了，通常得到的回答都是“是”。我又询问他们是否尽力去做工作了，再一次，通常得到的回答都是“是”。我于是告诉他们，“你们做了你们的工作。你们尽力测试，发现了缺陷并进行了上报。那么现在可以回家休息了。实际上，作为一名测试人员唯一失败的地方是不上报一个已知的缺陷。”
> 
> 这不会提高士气，但却有助于事情向正确的方向发展，特别是能让人不用每天晚上都在家接着办公。
> 
> 很多测试人员，包括我，当我们刚开始测试工作时，似乎会觉得自己对我们所测试的系统应用的质量负责。尽管这个工作的出发点是让人钦佩的，可实际上我们测试人员对于产品的质量基本没有控制能力。也是由于这个原因，测试人员不为质量负责。现在问题是管理层并不总是能看到这种区别。所以经常看见管理层提出类似于“我们付钱给这些人不是为了获得高质量的软件吗？”的问题。
> 
> **2****、缺陷都是有价值的**
> 
> 每一个缺陷都是深入了解和提高的机会。我们可能只有一次机会观察到一个缺陷，所以我总是告诉测试人员始终保持高度注意力，不要为测试的乏味所折磨。
> 
> 缺陷信息可能是可获取的项目数据中最有效的资源之一。但是这都取决于我们能多好的捕捉和传达我们所发现的缺陷的相关信息。
> 
> 每个缺陷都会花费整个组织的金钱。如果我们不能从中更进一步了解产品，我们会浪费大量时间和金钱。当我们把一个错误转换成一次深入了解的机会时杠杆作用就出现了。让我们面对它――有些教训只能通过经历来学习的。
> 
> 由于一个缺陷而责备谁不会有任何好的作用。责备只会让士气低落、沟通中断。这就像不断鞭打一匹死马希望它能活过来一样。
> 
> **3****、你报告第一个问题之前一切都是美好的**
> 
> 这就是一个测试人员所面对的现实。你可以计划测试，获取所需要的资源，看起来所有人都站在你这边。可当你报告第一个问题之后，事情就开始变得紧张了。
> 
> 出现这种态度上的突然变化的原因是现在你在批评某些人的工作了。自尊心使得自我收到伤害，关系变得紧张。有些情况下自尊心是值得期盼的，只要知道当你开始发现问题的时候态度有可能变化就可以了。
> 
> 我经常建议测试人员做的一件事是读一读一些你过去写的缺陷报告，假设自己是接收缺陷报告的人。你会发现自己需要更老练一些。写一个没有任何挖苦语句的缺陷报告可能没什么乐趣，但它的确有助于和开发人员之间保持一个好的关系。
> 
> **4****、只能测试你能观察的**
> 
> 你可能总想测试一些真正有创造性的用例，但如果你没有办法观察到结果，那有什么意义？尽管有些应用让你能观察到很多，但仍然有你没办法接近的，例如结构、隐藏的对象、后台进程等。
> 
> **5****、别忘记你是怎样到一个地方的**
> 
> 我不是在谈论知道为什么你走进一个房间，而是在测试时执行的步骤。对于测试新手常见的是发现了一个重大的缺陷，但却无法复现它以便定位解决。这样你只会觉得不舒服，不知道自己到底是真发现了一个缺陷，还是说仅仅是错误的使用了应用。
> 
> 你能用来跟踪你的测试步骤的方法有测试脚本、测试记录、敲键记录器如Spector和屏幕视频捕捉工具如Hypercam。
> 
> **6****、标准和流程是你的朋友**
> 
> 尽管标准和流程让一些人觉得受限，但它们为你的工作提供了有价值的指导。不要拒绝标准因为它们是详细的、具体的。因此用它们指导自己更快、更一致的完成自己的工作。
> 
> **7****、没有足够的时间用于测试**
> 
> 几乎每一个测试人员都抱怨没有足够的时间用于测试，但实际情况是测试任何东西到完整的程度都是不可能有充足时间的。当你充分考虑软件的特性如可用性、安全性、兼容性、互操作性等时这一点尤其正确。
> 
> 不要再抱怨缺少时间，学会根据风险来进行优先级排序，把注意力都放在对管理层很重要的应用目标上。有时候我们测试的内容超出了我们需要测试的，因为我们的目标偏离了产品的价值。
> 
> **8****、你不可能发现所有的缺陷**
> 
> 如果你测试的东西后来有缺陷被发现，不要变得气馁。你可能已经做了非常全面的工作，获得了高水平的缺陷移除，但100%都是不可能的目标。
> 
> **9****、保持幽默感和对前景充满信心**
> 
> 经常微笑、保持健康可能是你最好的生存方式。如果你正处在困难条件下，请相信，这一切都将过去。
> 
> **10****、争取做到最好而不是完美**
> 
> 测试新手经常会陷入追求完美的过程中，认为100%的正确才是标准。我曾经也是受害者之一，但要为自己辩护的是，我以前深受80年代后期类似于“99.9%还不够好”的TQM帖子和文章的影响。
> 
> 追求完美的问题在于它会让测试进程变慢，将担心引入你所做的一切，使得你对别人更挑剔，而且通常会让你的朋友和家人感到失望。
> 
> 当然，没人愿意犯错误，但他们稍不注意就出现了。想不犯错误就是否认现实。争取做到最好是一种好的习惯，表明你对工作的态度和投入程度。如果你想努力做到最好，你就会往前再多走一点。
> 
> 根据我的观察，大多数人看到错误或者经历失误时都是很宽容的。人们最关心的是你对待问题的反应。
> 
> **11****、开发人员不是敌人**
> 
> 需要整个项目团队的努力才能递交高质量的产品。有时候似乎开发人员不太关心质量，这个时候事情背后可能存在隐情。这时候你需要更好的和开发人员合作而不是反对他们。要始终牢记良好的交流是一个项目成功的关键因素。当你和开发人员站到对立面时，交流就停止了，你测试所需的很多信息也无法获取了。
> 
> **12****、建立和维护一个私人的交际网**
> 
> 你的私人工作关系是一个很重要的资产。无论时当你有工作时还是当你没工作时他们都是一个很好的支持系统。找一个好的指导者，而当你学到足够的东西时成为别人的指导者。
> 
> **13****、持续锻炼自己的技能**
> 
> 你的技能把你和别人区分开。始终通过参加专业会议、获取认证、阅读专业资料等来不断学习。我给自己制定的目标是每周至少读一本和个人发展以及职业发展相关的书（测试、领导艺术、商业、IT等）。
> 
> 一个个人发展方面的专家说过如果你每天在任何特定的主题上花费30分钟进行阅读，五年之内你肯定能成为这个主题方面的专家。这一点对我是起作用的――你也可以试试。
> 
> 另一种让自己始终内行并建立网络的好的方式是活跃在一些QA或者测试论坛上。
> 
> **14****、当前进变得困难，懒惰就需要创造力了**
> 
> 当我第一次成为一个测试团队负责人时，我用这句话做了一个字条挂在我的桌上。它不断提醒我把创造力作为我解决问题的一个杠杆。
> 
> 学着从一个新的有创造性的方式来看待问题。你可能有一个好的测试计划，但你如何应付各种变化呢？弹性是一个优秀的问题解决负责人的关键特性。
> 
> **15****、简单并不总是很容易**
> 
> 我们测试中做的很多工作看起来都很简单。但是，挑战在于保持努力的连贯性。
> 
> 有些解决问题的方式刚开始看起来很简单，但不要由于它简单和明显就丢弃任何一种想法。同样，不要低估实现一个简单想法所需要付出的努力。
> 
> 一些看过我和William E.Perry合著的书“Surviving the Top Ten Challenges of Software Testing”评论说这些挑战都很简单且很容易解决。这就让我奇怪为什么人们还在年复一年的提出“人的问题”。我认为在大脑中产生想法比实际实现出来要简单的多。
> 
> **结论**
> 
> 智慧比知识更重要。你可能已经学习了大量测试技术，但如果你没有足够的智慧判断什么时候采用它们，没有从整体上理解它们，你应用它们的能力将受到很大限制。对任何都有涉猎的你存在的一个问题是“你不知道什么你不知道”。智慧帮助你明白你需要知道哪些东西才能成功。
> 
> **４.软件测试工作求职**
> 
> **４.１测试人员面试时常见问题及问题背后的考核内容分析**
> 
> **1****）你最近3-5****年的职业规划是什么？**
> 
>    重点考察测试人员的职业发展方向是否与当前职位招聘相符? 从其中可以侧面看出来其员工稳定性。
> 
> **2****）一个项目测试结束，有没什么经验总结？如果有，具体是如何开展的？**
> 
>    重点考察测试人员对自己能力提升方面，有没有提高总结的地方，从项目中吸取的经验与教训。从中可以看出来，测试人员是否属行自我驱动型人才！
> 
> **3****）为什么会选择做测试这份工作？**
> 
>    重点考察测试人员对待测试工作的态度及是否有发展潜力？面试过很多测试人员，经常见到的回答，自己是女孩子，做测试细心，各位你认为这样回答你会满意吗？其码不是我想要的答案！
> 
> **4****）请说出一个你以前参与项目，对你测试经验提升很高的，具体是哪方面？**
> 
>    重点考察测试人员在以往的测试工作中能力提升方面，有哪些？然后重点询问此部分内容，是否测试经验增长，具备一定的深度？
> 
> **5****）通常做测试时会碰到，提交的某个bug****开发人员不认同你的观点？这时你如何办？**
> 
>    重点考察测试人员是否坚持自已的价值观？是否具备协调沟通处理问题能力？
> 
> **6****）有没有看过什么测试书，具体是哪本？带给你的收获是？**
> 
>   重点考察测试人员是否为测试这个职业肯付出多少？从中也可以看出这个测试人员是否上进心？是否有求知心？我的定义是如果哪个应聘者来面试时，都没系统的看过一本测试书籍，基本上不会录取！
> 
> **7****）如果安排一项测试技术研究工作，你如何应对？**
> 
> 重点考察测试人员是否具体测试技术专研精神？是否喜欢接受挑战？是否属于以后培养骨干对象？
> 
> **8****）某个项目上线后，出现问题，恰巧你是负责的，你如何应对这突如其来的事件？**
> 
> 重点考察测试人员应对问题的压力，责任感，及如何处理项目上线后的技术问题及应对解决能力。
> 
> **9****）周末放假有什么业余爱好？**
> 
>    重点考察面试测试人员性格特质，测试工作本身就是复杂且富有技术性的工作，而且不同的职位所需要的测试人员性格品质差异性很大。
> 
> **10****）公司产品，具体应用什么编程技术？具体的架构是？具体的应用场景有哪些？**
> 
>    重点考察测试人员对以往的工作所负责的产品测试，是否具备一定的深度！通常我都是让面试者自己讲述或是在纸上画出具体系统架构的图！
> 
> **11****）公司测试团队的规模如何，具体你所处的角色是什么？**
> 
>    重点考察测试人员在以往的公司测试团队中，具体的工作职责，评判其工作是否与当要求职位是否符合？是否有哪些优缺点？
> 
> **12****）特定测试技术考察：性能测试，安全性测试，自动化测试等以前有开展过没？如果有，具体是如何实施的？**
> 
>    重点考察测试人员技术能力，是否在各方面都有所涉及？或是在各方面技术上都有一定深度？当然从中也能看出一个测试人员是否属于是技术路线发展方向！
> 
> **13****）你自己所期待加入的测试团队是什么样的？**
> 
>    重点考察测试人员在以前测试团队中有哪些不协调？当然最重要的是也能提供给你一些信息，这个员工以后如何更好的管理与沟通！
> 
> **５.软件测试职业发展**
> 
> **1****）技术方向**
> 
>     在技术方向上面，通常是初级测试工程师，中级测试工程师，高级测试工程师，资深测试工程师，专家等方向发展；当然像国外技术分工比较细如：通常有白盒测试，黑盒测试，自动化测试，性能测试，安全测试，易用性测试等。
> 
>  **2****）管理方向**
> 
>     在管理方向上面，通常是测试组长，测试主管，测试经理，测试总监等方向发展。
> 
>  **3****）业务领域方向**
> 
>     在业务领域则取决于各测试人员所处行业，通常像金融，银行，证券，ERP类的，通常有初级业务测试，中级业务测试，高级业务测试等。
> 
> **４）其他方向**
> 
> 配置管理、质量保证（QA）等
> 
> **６.优秀的测试网站和个人博客**
> 
> **６.１优秀测试个人博客（排名不分先后）**
> 
> **软件工程专栏测试.质量.管理之最佳实践**
> 
> [http://blog.csdn.net/KerryZhu/][http_blog.csdn.net_KerryZhu]
> 
> **卖烧烤的鱼测试博客**
> 
> [http://mayingbao.cnblogs.com/][http_mayingbao.cnblogs.com]
> 
> **Smilings****（永恒的旋律）--Enjoying testing**
> 
> [http://blog.csdn.net/smilings/][http_blog.csdn.net_smilings]
> 
> **Jackei** **的测试生活与人文社会读本**
> 
> [http://jackei.cnblogs.com/][http_jackei.cnblogs.com]
> 
> **OscarXie.net**
> 
> [http://oscarxie.cnblogs.com/][http_oscarxie.cnblogs.com]
> 
> **６.２优秀测试网站（排名不分先后）**
> 
> **中国测试平台网**
> 
> [http://www.chinatesting.cn/][http_www.chinatesting.cn]
> 
> **TestAge** **中国软件测试时代**
> 
> [http://www.testage.net/html/index.html][http_www.testage.net_html_index.html]
> 
> **51Testing****软件测试论坛**
> 
> [http://bbs.51testing.com/][http_bbs.51testing.com]
> 
> **７.参考资料**
> 
> **维基百科-****软件测试**
> 
> [http://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95][http_zh.wikipedia.org_wiki_E8_BD_AF_E4_BB_B6_E6_B5_8B_E8_AF_95]
> 
> **软件工程专栏测试.****质量.****管理之最佳实践**
> 
> [http://blog.csdn.net/KerryZhu/][http_blog.csdn.net_KerryZhu]
> 
> **Smilings****（永恒的旋律）--Enjoying testing**
> 
> [http://blog.csdn.net/smilings/][http_blog.csdn.net_smilings]
> 
> **卖烧烤的鱼测试博客**
> 
> [http://mayingbao.cnblogs.com/][http_mayingbao.cnblogs.com]
> 
> **寻觅****2010-****功能测试报告的编写**
> 
> [http://www.cnblogs][http_www.cnblogs]

[ack Tang]: http://www.cnblogs.com/jacktang/
[Link 1]: http://www.cnblogs.com/jacktang/archive/2012/10/31/2747480.html
[http_www.cnblogs.com_mayingbao_category_82529.html]: http://www.cnblogs.com/mayingbao/category/82529.html
[http_blog.csdn.net_smilings_article_details_840917]: http://blog.csdn.net/smilings/article/details/840917
[http_blog.csdn.net_smilings_article_details_840840]: http://blog.csdn.net/smilings/article/details/840840
[http_blog.csdn.net_kerryzhu_article_details_1436398]: http://blog.csdn.net/kerryzhu/article/details/1436398
[http_blog.csdn.net_KerryZhu]: http://blog.csdn.net/KerryZhu/
[http_mayingbao.cnblogs.com]: http://mayingbao.cnblogs.com/
[http_blog.csdn.net_smilings]: http://blog.csdn.net/smilings/
[http_jackei.cnblogs.com]: http://jackei.cnblogs.com/
[http_oscarxie.cnblogs.com]: http://oscarxie.cnblogs.com/
[http_www.chinatesting.cn]: http://www.chinatesting.cn/
[http_www.testage.net_html_index.html]: http://www.testage.net/html/index.html
[http_bbs.51testing.com]: http://bbs.51testing.com/
[http_zh.wikipedia.org_wiki_E8_BD_AF_E4_BB_B6_E6_B5_8B_E8_AF_95]: http://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95
[http_www.cnblogs]: http://www.cnblogs