《网络测试技术与应用》课件网络测试与应用(第一部分)

1.1软件测试的背景与概念1、测试的背景今天我们使用的一切几乎都包含软件（包括嵌入式的软件）对于关键场合的各种软件应用，出现失效是根本不能接受的除了上帝，我们都要测试！软件是人编的—所以不完美实例：2005年9月13日，魔兽世界“腐血”问题2003年8月14日，北美停电问题约克郡号美国舰船事件,1997年9月21日Unix系统的2038年问题2013年光大证券“8·16”乌龙事件2000年的巴拿马城致命的辐射治疗2011年温州7.23动车事故1）软件未实现产品说明书要求的功能2）软件出现了产品说明书指明不应该出现的错误3）软件实现了产品说明书未提到的功能4）软件未实现产品说明书虽未明确提到但应该实现的目标5）软件难以理解、不易使用、运行缓慢或者---从测试员的角度--最终用户会认为不好软件测试的起源20世纪60年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机（softwarecrisis）开始爆发。软件危机1、软件危机的现象：开发费用与进度失控，引起质量问题可靠性差，难以维护文档资料的缺失与不合格问题2、产生软件危机的原因：软件本身的特点决定（用户需求、软件规模，复杂度等原因）开发人员的弱点1968年在德国召开的NATO（NorthAtlanticTreatyOrganization,北大西洋公约组织）会议上首次提出了“软件工程”概念，希望用工程化的原则和方法来克服软件危机。一个成熟的产品开发过程至少应该包括设计、开发和测试3个部分，一个成熟的产品部门是非常重视测试环节的。测试环节做的好与坏，直接影响到产品的质量和市场对产品的评价。做好测试不是一件容易的事情，有时甚至比开发更有挑战性。如何做好测试，是摆在整个测试团队面前的一个难题。早期测试的含义比较狭窄，往往等同于“调试”，在产品完成时才开始测试70年代开始出现的“第一类方法”，“试图验证软件是工作的”。70年代末GlenfordJ.Myers的第二类方法。。“测试的目的是证伪”（测试是为发现错误而执行的一个程序或者系统的过程）第二类测试方法与需求和设计没有必然的关联，更强调测试人员发挥主观能动性，用逆向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统各种的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。这种方法往往能够发现系统中存在的更多缺陷。

如果说开发者在创造世界，那么，测试者的任务就是要毁灭这个世界，当然，毁灭是为了重生！-——目的在于提高软件产品的质量！80年带开始引入“软件质量”的概念，SQA。BillHetzel在《软件测试完全指南》（CompleteGuideofSoftwareTesting）一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义至今仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。软件测试已有了行业标准（IEEE/ANSI）2、关于测试的误区1、“测试没有什么技术挑战”干测试是因为别无选择如果我做开发，可以用给定的程序设计语言创造产品，这是很有意义的事情，而测试不过是例行公事和重复性的工作，不需要什么特殊技能Technologyisthemaking,usage,andknowledgeoftools,machines,techniques,crafts,systemsormethodsoforganizationinordertosolveaproblemorperformaspecificfunction所以，测试工作本身，至少在测试的起步阶段，对于技术能力的要求是不高的。虽然测试本身对技术的要求越来越高，但是解决这些问题所需要的技术技能，应该还是比不过开发领域。如果你如果对纯粹的技术更加有偏好的话，你还是更应该做开发人员，而且最好还是做你们公司的核心的产品的开发，这样才能受到最大的锻炼，对你的成长更有帮助。1.1.2软件测试的目的、对象与原则软件、产品公司必须尽全力减少、最好消除所交付的产品中存在的缺陷；缺陷不可能在软件中隐藏得太久用户在使用软件时，存在不可预知的“误操作”，必须要保证软件仍能正确运行；1、测试的目地测试的目的是说明程序正确地执行它应有的功能”

这种说法正确吗？例1程序Triangle，输入三个整数，表示一个三角形的三个边长，该程序产生一个结果，指出该三角形是等边三角形、等腰三角形还是不等边三角形。为说明其能正确执行它的功能，可使用“测试用例”(3，4，5)，(5，5，6)，(6，6，6)，程序都能给出正确结果，是否就可认为程序是正确的？基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。GlenfordJ.Myers在<软件测试之艺术>中认为：1.测试是为了寻找错误而运行程序的过程。2.一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试。3.一个成功的测试是揭示了迄今为止尚未发现的错误的测试。E.W.Dijkstra指出：“程序测试能证明错误的存在,但不能证明错误不存在。”※软件测试的目的测试的目的：发现程序的错误；任务：通过在计算机上执行程序，暴露程序中潜在的错误。纠错的目的：定位和纠正错误；任务：消除软件故障，保证程序的可靠运行。软件测试是根据软件开发个阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。测试肯定是促成产品质量的因素之一，但是测试本身却不能提高产品的质量，对于一个好的产品，测试与其他阶段恰当的交互是必不可少的。2、软件测试的对象从传统意义上来说，测试被狭义地定义为测试程序代码。是为了发现错误而执行程序的过程；广义来说，测试包含了所有生产优质产品的相关活动，生产软件产品必须有几个阶段（需求获取，分析，设计与编码），除此之外还有测试（即传统意义的测试）

测试贯穿于全部软件生存周期，并且不是周期结束前的最后一个活动！测试与开发模型软件测试不仅仅是执行测试，而是一个包含很多复杂活动的过程，并且这些过程应该贯穿于整个软件开发过程。在软件开发过程中，应该什么时候进行测试，如何更好地把软件开发和测试活动集成到一起？其实这也是软件测试工作人员必须考虑的问题，因为只有这样，才能提高软件测试工作的效率，提高软件产品的质量，最大限度地降低软件开发与测试的成本，减少重复劳动。需要了解开发模型，瀑布、V、W、X等模型瀑布模型1970年WinstonRoyce提出了著名的"瀑布模型（WaterfallModel）"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型它将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。V模型20世纪80年代后期PaulRook提出了著名的软件测试的V模型，旨在改进软件开发的效率和效果。清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。W模型Evolutif公司针对V模型的缺陷，相对于V模型，提出了W模型的概念，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

测试贯穿于全部软件生存周期，并且不是周期结束前的最后一个活动！软件生存期各阶段间需保持的正确性用户要求用户：我要什么?运行结果计算机：程序运行得到的结果源程序程序员：我要让计算机什么做?设计说明书设计员：我要让软件做什么?需求说明书分析员：我可以提供什么?12345理解正确性表达正确性理解正确性设计正确性表达正确性理解正确性编码正确性运行正确性输入正确性相符吗?

开发前期出现错误的扩展计划需求分析设计编码测试AAB

软件缺陷的组成我们知道软件缺陷是由很多原因造成的，如果把它们按需求分析结果——规格说明书，系统设计结果，编程的代码等归类起来，比较后发现，结果规格说明书是软件缺陷出现最多的地方。3、测试的原则应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。程序员应避免检查自己的程序。pareto原则：测试发现的错误中80%很可能起源于20%的模块中。应孤立这些疑点模块重点测试。程序修改后要回归测试穷举测试是不可能的测试的原则检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。计划测试工作时不应默许假定不会发现错误最严重的错误(从用户角度)是那些导致软件无法满足需求的错误。程序中的问题根源可能在开发前期的各阶段解决、纠正错误也必须追溯到前期工作。1.3软件测试的分类软件测试按照不同的分类标准，存在着各种各样的测试名称，比如按照软件项目流程阶段划分，可分为单元测试、集成测试、系统测试、验收测试。如下是一个典型瀑布式软件开发流程：软件测试的分类单元测试：单元测试是对软件中的基本组成单位进行的测试，目的是检验软件基本组成单位的正确性。集成测试：集成测试是在软件系统集成过程中所进行的测试，目的是检查软件单位之间的接口是否正确。系统测试：是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求。验收测试：是部署软件之前的最后一个测试操作，验收测试的目的是确保软件准备就绪，向软件购买都展示该软件系统满足其用户的需求。软件测试的另一种分类法如果从测试工作对软件代码的可见程度划分，又可分为白盒测试、黑盒测试与灰盒测试，这也是软件测试领域中最基本的两个概念。黑盒测试软件输入不深入代码细节的测试方法称为动态黑盒测试。软件测试员充当客户来使用。输出这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。

黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误：

是否有不正确或遗漏了的功能?在接口上，输入能否正确地接受?能否输出正确的结果?是否有数据结构错误或外部信息(例如数据文件)访问错误?性能上是否能够满足要求?是否有初始化或终止性错误?

例2：假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组：

232×232

＝264

如果测试一组数据需要1毫秒，一年工作365×24小时，完成所有测试需5亿年。用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。白盒测试白盒测试，指的是把“盒子”盖子去掉，去研究“盒子”里面的源代码和程序结构。白盒测试按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。静态白盒测试即是利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方,不要求在计算机上实际执行所测程序。动态白盒测试通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。灰盒测试白盒和黑盒测试能发现软件在其生命周期不同阶段的不同类型的安全性隐患。而所谓的“灰盒测试”介于黑盒测试与白盒测试之间。可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。1.2测试用例“测试用例”（TestCase）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序是否满足某个特定的需求。测试用例是将软件测试的行为、活动进行科学化的组织和归纳，目的是能够将软件测试的行为转化成可管理的模式。比如，当不同的测试工程师在相同的“环境”（指相同的被测软件、测试环境等条件）下执行相同的的测试用例时，可以得出相同的结果，不会因为测试工程师的不同到导致测试结果的改变，这对于经常有测试工程师流动的企业、公司来说，在软件项目的管理上起到了非常重要的作用。测试用例也是将测试具体量化的方法之一，不同类别的软件或同一软件的不同功能，测试用例都是不同的。测试用例的重要性测试用例是测试部门的基石：测试用例是测试皇冠上的宝石测试用例的地位决定其重要性：测试用例在测试执行过程中的指导性：1.2.1测试用例的评估大体上，测试用例的质量可以从两个方面来衡量：单个测试用例的执行度所有测试用例的覆盖度。单个测试用例忠实度（测试用例应该忠实于被测设备和特性，应该严格遵守相关设计文档，标准协议和市场需求，这三个元素构成了测试用例的基本来源。如果测试步骤错误或者背离了产品设计的意图，无疑将导致错误的测试结果，会浪费测试人员，开发人员的宝贵时间）目的明确做任何事都要有目的，测试用例更是如此。整个测试用例应该围绕一个明确的测试目的，然后展开测试步骤。测试目的代表了产品的一个测试点，测试目的是测试用例的中心灵魂。执行度测试用例的执行度代表了对产品特性理解的程度，测试用例越细致深入，就越有可能发现深层的缺陷。然而，要做到这一点不是容易的事情，需要对产品特性，协议的精确理解和长期的测试经验积累。可重复性测试用例写好了，可能会交给不同的测试人员，在不同的时间和场合执行测试。测试用例的可重复性是指在这些不同的情况下，应该有一致的测试结果。可读性如同读文章一样，测试用例也是在测试人员之间传递阅读的。清晰的上下文关系，明确干净的描述让测试人员很容易理解测试的意图和步骤，避免了对测试意图的误解。通常，测试用例的可读性是容易被忽略的，然而要做好这一点并不困难。测试用例集合覆盖程度Testingcoverage（测试覆盖），指测试系统覆盖被测试系统的程度，一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。对于产品测试特别是复杂庞大的产品，错过了测试点，就等于错过了产品缺陷。如果说每个测试用例覆盖了一个测试点，所有的这些测试点构成了整个产品的测试覆盖面。整个测试用例集应该覆盖从单一功能到复杂功能测试，系统测试，性能测试，兼容性测试，场景测试等方方面面，力图使测试盲点降到最低。清晰的分层结构产品是复杂的，软件研发者面对这种复杂性采用的经典的方法瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。对于测试用例来说，非常自然的，我们也需要考虑用这种层次化的组织结构来管理测试用例。1.2.2测试用例的分类和要素构成测试用例的分类说法不一，其中一个普遍认同的说法是白盒测试和黑盒测试。本课程只对黑盒测试展开阐述黑盒测试着眼于被测物外部结构，不考虑内部逻辑结构。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。黑盒测试用例的分类（从测试过程来分）

单一功能测试（featuretesting）根据产品特征、操作描述和用户方案，测试产品的一个特性和可操作行为以确定它们满足设计需求。它只需考虑单个功能，不需要考虑整个软件的其他模块及代码。集成测试（integritytesting）集成测试，也叫组装测试或联合测试。在单一功能测试的基础上，将多个模块按照设计要求）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。

系统测试(systemtesting)系统测试是将已经确认的所有模块，包括软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案.。回归测试(regressiontesting)在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。为了验证修改的正确性及其影响就需要进行回归测试。黑盒测试用例的分类（从测试过程来分）

一致性测试(compatibilitytesting)又包括功能一致性和协议标准一致性。是检验被测设备是否和设计要求一致，是否和标准协议一致。边界值(boundarytesting)长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。黑盒测试用例的分类（从测试方法来分）

负面测试（Negativetesting）是相对于正面测试（Positivetesting）而言的。它们也是测试设计时的两个非常重要的划分。简单点说，正面测试就是测试系统是否完成了它应该完成的工作；而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点，正面测试就象一个毕恭毕敬的小学生，老师叫我做什么，我就做什么；而负面测试就象一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类缺陷的。执行负面测试时，不单单要测试系统是否处理了用户的异常操作，还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。黑盒测试用例的分类（从测试方法来分）

稳定性测试(robusttesting)压力测试(loadtesting)性能测试(performancetesting)测试用例的要素一个完整的测试用例应该包含以下要素：TestID(用例编号)Description（用例描述）Pre-setup（预置条件）Platform（测试平台）Priority（优先级）Complexity(复杂度)StepsExpectedresults(步骤/预期结果)用例描述应该是对测试用例目的和过程的简要描述，应该控制在几句话的范围内。用例描述应该使阅读者迅速并清楚地知道测试的意图，也就是测试的目的所在。对测试执行人员和测试管理者来说，最关注的其实就是用例描述，通过对每个用例描述的预览，可以初步判断整个测试集的覆盖面和深度。测试步骤和预期结果是测试目的的展开。简单来说：测试步骤就是让被测设备到达某种状态，预期结果就是被测设备在这种状态下应该有的表现。预期结果必须和测试步骤一一对应，用来验证被测设备是否正常。测试与测试用例测试的目标是在用户发现缺陷之前找到他们穷尽的测试是不可能的测试贯穿与全部的软件开发周期理解测试背后的原因（明白测什么，正确执行合适的测试）测试用例应该首先被测试测试用例需要不断完善，不断修订充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。缺陷成群集中出现，因此测试应该关注这些缺陷。在设计测试用例时，应包括合理的输入条件和不合理的输入条件。所有的测试都应追溯到用户需求应长期保留测试用例，直至系统废弃。1.3测试工作的生命周期软件测试不可能发现产品中的全部BUG，在现实的研发活动中，提供给测试人员的资源也是极为有限的，如时间、人力资源、设备资源等。那么一项产品的开发活动或项目实施，什么时候应该开始测试？什么时候停止测试呢？我们一般把软件测试周期分为如下七个阶段1.3.1计划阶段这是产品测试概念定义的阶段，定义测试标准和流程等。包含的9个方面的主要工作：1、制定测试计划（包含测试大纲），测试周期的设定、测试的目标、质量参数、beta测试阶段的验收标准等等。2、制定各个阶段进行review（评价、核实）的时间，对上阶段的情况进行分析和总结，以调整计划。如讨论测试覆盖率、人员有无不足之类。3、制定错误报告的流程，比如那些问题要上报，那些问题暂时不用上报，并制定书写的格式，跟踪的方法，以及制定错误报告的类型。………………………..1.3.2分析阶段分析阶段是一个外部文档阶段，这个阶段的主要工作是从客户和开发组得到的文档并进行分析和总结。根据获取的信息去创建测试的框架和相应的测试文档。所以本阶段主要的工作是完成分析，搭出测试框架，书写大纲等。包括的10个方面的主要工作（P14-15）1.3.3设计阶段

完成测试内部文档的阶段，这些文档大部分都是在分析阶段形成了大体的组织结构和大纲的文档，像测试用例之类的都有了一些基本的描述，本阶段主要的工作就是完成这些文档的最终书写。如测试计划，测试时间表，测试数据，各种相关文档都应该处于完成阶段。当然，仍然可以通过设计的危机处理机制进行更新。特别要指出的是，测试用例并不能够在本阶段完成。由于新功能的添加，具体功能的实现方法，修改功能等因素，测试用例只能不断的更新。1.3.4构建阶段构建阶段，是在开发人员编码的同时，最终完成系统预先设置的各种测试用例的阶段。本阶段的很多工作其实在上个阶段就已经涉及到了，完成本阶段的工作后，将进入到测试的主要阶段，对产品进行设定的各种测试。该阶段包括7个方面的工作，P161.3.5循环测试阶段

循环测试阶段是最花费时间的阶。按照之前制定好的计划，利用各种资源、工具，依循完成的测试用例对系统进行一轮又一轮的测试，直到代码开发冻结。本阶段也包含了不断设置的回归测试。1.3.6最后测试和实施阶段本阶段是代码冻结后的测试阶段，这个时候需要进行的是最后的验证测试，主要是完成最终的性能，压力，文档测试和UI等测试过程，开始形成系统说明书和用户手册。此时一般不在去修改主要的源代码，只是对外观和界面的错误进行修复。只是对现有的一些问题进行跟踪和管理，必要的时候准备发布修复版。1.3.7实施后阶段

对整个项目进行总结的阶段。通过书写一些最终的报告。例如，错误分析报告，包括一共有多少个，有效率是多少，分布情况如何等等。这个阶段主要是将好的经验总结下来，对不足进行思考，为下个项目做准备。1.4BUG管理什么是bugBug按照英文直译过来叫“虫子”。任何事物都不是完美的，何况是需要被测测试的物体。简单的来说，bug就是事物的缺陷。现实生活中充满了bug：人生病了，我们可以理解为有了bug；汽车抛锚了，我们可以理解为出了bug，电脑死机了，更是一个bug。如何判断Bug但不是所有的问题都是bug。严格来说，是产品在规定范围或正常操作下出现的错误，才能称为bug。如前面提到的汽车抛锚了，如果是因为汽车使用年限超过了应该的年限，或者是司机的错误操作，都不能称为bug。下面是一个bug举例：WindowsXP支持的最大共享文件夹名长度为80个英文字母或40个汉字，但设置共享文件夹名时可输入的范围是80个英文字符或80个汉字，如果共享文件夹名在41～80个汉字之间，系统会提示该共享名包含无效的字符摂。其实真正的原因是共享文件夹名超长。寻找Bug的目的测试究竟是用来做什么的？bug又有什么用处？测试不是为了找bug这么简单，测试的目的是通过找bug来提高产品质量，提高产品开发流程，继而满足市场和客户的要求。没有bug的完美产品是不存在的，一轮接一轮的测试就是为了让产品更加稳定，让bug被限制到尽可能小的范围。Bug的严重等级是对被测设备表现的一个评判。被测设备错误表现的严重性就决定了bug的严重等级。各家公司和机构对于严重等级的划分标准不一，但大体上可以按照下面的方式来定义：Priority1被测设备崩溃。被测设备重启。内存泄漏系统配置丢失（硬件类）Bug的严重等级Priority2功能或模块不工作,测试就结果或行为与预期不一致，且没有避开BUG的替代方法。功能缺失。系统性能与参考值相差太大。Priority3功能或模块不工作,测试就结果或行为与预期不一致，但有避开BUG的替代方法。Bug的优先级别Bug的优先级别是从客户需求角度来说的，用户认为重要的特性出了问题，哪怕只是小小的显示信息错误，也应该在第一时间解决。Bug的生命历程Bug也是有生命的，从bug的发现，到bug的修复。就是一个bug的生命历程：1.4.2发现bugBug从那里来？一个产品从设计到开发，凝聚了所有系统设计师，开发人员，设计人员，管理人员的心血。从另一个方面来讲，这些不同的环节和不同人的工作，却是导致bug的原因。举例来说，可能出现bug的情况有：新特性的增加对设计意图的错误理解代码的反复修改不严格的代码维护开发人员的素质紧张的开发进度。。。。。。怎么找bug？找bug决不是件简单的事情。一个高素质的测试人员应该做好一下的工作：熟悉产品设计需求熟悉标准协议规范熟悉产品操作手册熟悉测试工具仪器的使用有丰富的测试经验当bug出现时当我们在发现一个产品的问题时，怎么确定就是一个bug？这也不是个简单的问题，确定bug的过程称为bug定位。一般来说，可以按照一下几步来做：排除非正确因素：需要排除的因素包括是否按照合理的测试步骤，是否在合理的测试场景，是否在产品规格范围内，等等。只有排除了这些正常因素，而被测设备依然会有不正常行为，才能初步定位为bug。收集bug相关信息Bug出现时，应该保存好设备的配置，测试仪器的配置，设备的日志，屏幕输出等等。这些要素都是分析bug，修复bug的重要参考。寻找重现步骤这是bug定位中的难点，特别对于多功能多模块的系统测试，bug产生的原因会很复杂，不是简单的表面现象就能找到重现条件。寻求开发人员的帮助Bug找到了以后需要开发人员的确认和修复，测试人员需要和开发人员一起确认bug的原因，帮助开发人员找到bug的根源。报告bug这时找到bug需要做的最后一步，通常会有专业的bug管理软件，如bugzilla，clearDDTS等等。/about/什么是高质量的bug？找到了Bug的重现条件，从测试的角度来说，工作就完成了一大半。重现条件能够帮助开发人员更方便地定位，甚至开发人员会依赖于重现条件才能定位。找Bug的意义在于修复bug，不能重现的bug往往不能找到原因，更谈不上修复。分析Bug趋势图Bug不是越多越好，在适当的时候发现适当数量和质量的bug才是产品经理所希望看到的。如何报告bug在有些公司里，程序员几乎会把一半的测试bug返回给测试组，因为那些bug不可再现、发现bug同设计要求一致，或者bug报告根本无法操作。为了防止这类问题，要提交好的测试bug，作为一个好的测试人员，必须遵循以下步骤：1)总结：简要描述客户或用户的质量体验和观察到的一些特征。2)压缩：精简任何不必要的信息，特别是冗余的测试步骤。3)去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。4)中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。5)评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在你提交测试报告或测试评估报告之前先自己读一遍。好的测试bug描述是告诉读者测试人员发现了什么，而不是测试人员做了什么。因此只需要根据上述步骤写下最少的必需重现步骤如何提交bug一个好的错误跟踪系统包括了错误的必要信息，如果做得不好，会造成迷惑，并误导读者。

好的故障描述应该包括十个基本部分：标题、项目、所属模块、优先级、重要性、异常等级、可重复性、现象、操作过程和附件。标题使用一两句话来描述错误，告诉经理、开发人员以及其他读者为什么应该关心该问题。好的标题应该着重于出现的bug现象。但是过于简洁易引起误导，使得原本重要的问题被忽视。因此必须应该采用简洁、切中要害的概要，这样才能引起读者的重视。不重要的就描述比较轻微，例如：“联系人的email没有检查合法性”；重要的就要体现比较严重，例如：“填了运营商仍然提示运营商不能为空，使得无法进行下一步的操作”，会更容易让开发人员理解究竟是什么问题及其重要性，并及时处理。②项目是指该错误属于哪一个项目，归哪个项目组解决，使不同的项目组看到和及时定位自己项目的错误。③所属模块是指准确说明发异常等级生错误的模块，切忌发生错误指派模块，导致后续流程错误；④优先级分为以下4级：1级：“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求；2级：“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现；3级：“正常处理”，即进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的数据库等；4级：“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。⑤重要性分为以下5级：1级：“非常严重”，表示缺陷不修改整个系统流程不能继续；2级：“比较严重”，表示缺陷不修改不影响系统其他流程，但是本模块流程不能继续；3级：“一般”，表示缺陷不影响流程；4级：“轻微”，表示缺陷可以延期解决；5级：“优化”，表示修改以后流程会更好。⑥异常等级有以下5级：系统崩溃－指该错误使得操作系统死机等致命性的错误；应用程序崩溃－指该错误使得测试程序崩溃，即无任何反应；应用程序异常－指错误使得应用程序结果不符合逻辑或是最初的需求；轻微异常－指错误有，但是无伤大雅，例如错别字等；建议－指改进后更好，不改进也对程序无碍。⑦可重复性是针对问题是否通过执行“操作步骤”就可以重新出现，如果是就“可再现”；如果这个bug只出现了一次，就再也不出现了，称这类问题为“不可再现”；其余的就是“未知”，如每隔几天才出现一次；⑧现象是对标题的详细描述，因为标题不宜过长，所以现象也是对标题的具体化。⑨操作过程是指对于可重现的bug，执行这些操作步骤就可以出现该bug；对于不可重现和重现概率为未知的bug，通过备份的数据库和操作过程就可以重现该bug。⑩附件是粘贴必要的附件，如果是可重复性是“可重现”的bug，则可以参考步骤是否复杂，如果很复杂，则可以粘贴附件，从而使得开发人员直接可以明白是什么问题，提高开发人员的修改效率；如果步骤不多有能够重现，则可以不粘贴附件。如果可重复性是“不可再现”的，这种情况必须粘贴附件，以备份出现问题后的情形；如果是未知的，也必须粘贴附件，因为开发人员不可能把时间耗费在等待bug的重现上1.5自动化测试基础测试生命周期测试生命周期大致有几个阶段：计划、分析、设计、构建、测试周期，最后测试实施，包括了测试需求的分析、测试计划的提出、测试用例的设计、功能测试、系统测试、回归测试、验收测试等等内容。回归测试（RegressionTesting）不是一个特定的测试级别，只要对软件代码有修改，不论是修改错误还是增加新的功能或是提高性能，原则上都要进行回归测试，以保证对代码修改的正确性，确保代码修改不会对其余部分带来负面影响。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。自动化测试的优势脚本执行的自动化测试速度远远快于人工执行测试的速度，缩短测试项目的时间。减少人力投入，保证产品能按时发布。甚至缩短研发周期，提前发布产品。并且在同样的产品研发时间内，能对