软件测试网学习教程-中文员

经过大家的不懈努力，测试时代终于有了一份经过大家的不懈努力，测试时代终于有了一份面向软件测试专业人员的技术性期。众所周知，在软件开发过程中对软件测试的误解较大，多数公司将其作为软件业中不重要的工作。产生这种误解主要原因是由于这些公司对软件开发过程认识不足造成。除此之外作为软件测试人员也应从自我做面向软件测试专业人员的技术性期性的文章，通过测试时代网识、增强测试人员之间交流，同时也为广大软件测性的文章，通过测试时代网识、增强测试人员之间交流，同时也为广大软件测试人员提供一个信息发布的平台，鼓励大家在测试测试时代 上多发上和测上和测试时代 相结合，真正实现网上网互动，提高软件测试人员的技能，进而推动整个软件测试行业的发展。期总编：Http 期关于测试人员的角 突然就开始了这个角色的扮演：来跟大家介绍作为一个测试人员的角色定位，以及刚入门需要了解的相关知识和心态方面的问题。说实话，感觉到很为难，有时候有些事情做起来感觉并不是很难，但是要把它转化为文字的形式表达出来对我

栏 ERP方面的测试知识解：来说确实比较为难的。但是我还是很愿意去用 解：支拙笔来慢慢描述我对测试人员定位的一个理当一个人在一个漫长而坎坷的 走过人后，我相信他一定会有自己沉淀下来的东西。前段时间参加华东测试交流会时，听到海松大哥解析测试人员如何定位自己的角色的时候就感触很深，感觉自己

还有很多值得钻研的地方，在测试领域，自己的很多认识还是很肤浅的。随着公司规模逐渐扩大，测试人员也由以前的几个人发展到现在的几十人。队伍的壮大是显而易见的。然而很多刚进入门的同仁却开始慢慢对做测试流露出迷茫的眼神，问其原因，很简单，做测试学不到东西，整天就鼠标点点，键盘敲敲，很难学到真正的东西。听了之后不由得露出理解的笑容，想当年我也是从这样的境遇走过来的。刚进入公司的时候就让做测试，经历了同样的鼠标点点，键盘敲敲的经历。然而正是这样的一些成长经历让我在平淡中明白了很多道理，并且慢慢从因为工作而做测试转化为因为而继续做测试工作。做测试不仅仅是表面看到的这种敲敲点点现象的延续，还有更深层次的内涵，是我们很多人还没到达这个境界而已，所以看起来很枯燥。（我也没达到这个境界，不过我知道自己做的工作并不是很枯燥的，呵呵。刚开始做测试的朋友很多都在做黑盒测试，而黑盒测试往往对代码编写能力要求不是很高，这样给刚入门的人就造成了一个测试人员不需要太多知识的误解。然而，做测试往往需要很广泛的知识。不仅仅只是专业上的，而且要了解很多开发人员不了解的东西，在一个系统里面开发人员可以只了解客户需求，而我们的测试人员需要了解整个全局的东西。呵呵，感觉有点统筹全局的成就感。不过有时候相对于开发人员来说也的确是这样的。开发人员可以不用太多了解用户的需求，而我们却需要能够准确捕获用户的观点，对很多细节需要非常注意。往往很多人在初入测试行业的时候非常热衷于测试工具的学习以及使用，其实这并不是一个很系统的认知。知识的学习也是分阶段的。测试这两个字很表面来看很简单，只是给程序挑错误，找出bug来，但是在整个软件开发过程中我们该如何把测试跟开发结合起来有效地进行都需要经过实践来证明。而这些不是工具所能完成的。我们对整个测试流程方面的东西需要了解得很多很多，而工具只是需要了解的其中一部分而且是比较小的一部分知识而已。你所了解的不仅仅只是测试的表 面，你需要了解测试的流程，你需要了解如何用一个好的测试计划来规划我们的测试时间、测试范围（有些公司把测试范围的设计归纳在测试需求里面，但是很多公司都是在测试计划里面），需要了解如何用一个好的测试用例来覆盖整个测试范围之内的测试实施。了解如何保证所测试出来的bug是开发人员的问题而不是因为自己了解不够导致出现的问题。Bug分析报告之内如何总结问题都是我们需要注意到的知识。对自己的测试时间也需要进行详细规划，尽量多地考虑进去各种可能。这样才可以尽量减少相关的风险。测试里面的知识学习可以分为以下三个阶段来进行（这个阶段只是自己的一种个人见解）：第一个阶段须要让做测试的人明白测试在整个软件工程里面的重要性，了解测试的相关基础知识，并且在了解这些知识的过程中逐渐挖掘出他对测试的。是很好的从事一项工作的一个重要条件。让一个对测试丝毫不懂而且不感的人去直接去做测试，你不觉得是在耽误别人的青春吗？第二个阶段 须对测试的流程的管理工作通过实际的软件测试有个非常明确的认识。因为很多时候工作都是在团队相互协调的情况下进行的，所以对于整个软件开发流程以及开发流程当中的测试流程都需要很熟悉，这样才可以更好的配合工作。当我们这些都很熟悉并且在工作当中应用很流畅的时候，我们就可以对测试工具进行相对应的学习。诚然，现在很多公司在招聘测试人员的时候总是要求了解自动化测试工具，实际上据了解，很多公司并不能真正用自动化测试。所以不要一进门就想着学习自动化测试工具，很多知识在你了解了其他知识之后学习效果跟用途可能会更好。在了解测试相关流程的同时 须扩充我们的其他相关知识，包括对我们的产品的客户的需求的了解要比开发人员了解更全面，更深入。这样才能保证我们的流程，我们的测试按照客观的正确的方向前进，而不至于被开发人员的思想所牵引。呵呵。我喜欢做事主动而不是 的去执行。到第三个阶段我们可以跟区分专业一样走自己喜欢的途径：一方面可以继续深入提高自己的测试的专业技能并且能够真正从事自动化测试，成为技术领域里面的专家。另一方面我们可以慢慢趋于测试管理方面。上次在交流会上，海松大哥对测试人员的发展阶段跟发展路径规划曾作出一个很形象的比喻来，我画了一个粗略的流程，大家下面的发展图（自下向上的发展趋势）（当然并不是每个人都在这个曲线发展之内）（直线的长度可以粗略的概括发展的不同时间长短从这个图形我们大家也可以粗略的看出，对于初级测试工程师，这是两个不同的发展方向，但是最终还是发展为一个终点（PM。从一个初级测试工程师晋升到一个高级测试工程师比较快，但是从一个初级测试工程师发展到一个TeamLeader所需要的时间相对比较长。而从一个高级测试工程师发展到一个资深测试工程师花费时间更长一点，到达资深测试工程师之后就可以很容易做到测试主管了，以后可以发展到PM。当然从初级测试人员到高级、资深测试人员在上面的图中并不是表述为“曲线发展过程”的，很多时候行业经验、行业知识的累积等都很重要。而这点只有深入发展的人才会发现其重要性的。很多随着时间的推移和经验的增长，一些沉淀下来的东西不是表现在字面上，别人就可以理解并领悟的。所以要有信心的同时我们做事还必须有耐心，罗马非一日建成。相信明天就要紧紧把握今天。我们很多人在测试的时候感觉到不爽的另外一个比较大众化的原因，可能就是对测试不感的同时知识层次不够（建议接触测试一年之后还对此不感兴趣的朋友找找自己的原因，实在找不出来就早点看看别的比较好发展的行业吧。。因为自己知识层次的不够，这样往往感觉自己找出的bug在开发人员那里得不到很好的重视，感觉自己的劳动成果没有得到相应的尊重一样。一个测试人员在跟开发人员打交道的时候往往会产生这么一个现象，随着开发的进行，测试人员提交的bug越来越不被开发人员重视了，这里面除了开发人员比较忙碌的缘故之外，另外一个不容忽视的原因就是我们测试人员自身的知识不够层次，很多时候因为我们不了解需求，不了解相关专业知识而误认为正确的东西是bug。任何一个领域里面的人都应该有这样的想法并且比较这个想法：那就是外行对内行进行不正确的指点，这相当于对别人劳动成果的一种不负责任的否定。所以我们一定要加强我们自身的专业知识的学习。这个时候大家可能会问，那么一个真正的测试人员应该具备哪些知识呢？在除了相关专业知识之外还有一些比较共性的知识需要我们大家了解，专业知识因为行业的不同所以有很多的不同之处，这儿不详细介绍了，我从大众化的方面来阐述下面几个需要我们注意的地方，这也是作为一个测试人员应该具备的基本素质：1、我们需要具备很好的沟通能力：沟通是人类相互进步的一个重要标志，用在我们这个行业里面沟通也比较适用。我们的沟通往往不仅是跟开发人员的沟通，有时候也会跟我们的客户进行沟通的。这是两种不同类型的人，他们关心问题的侧重点也不同。所以我们沟通时候需要掌握一定的技巧，这样才能从客户那儿得到比较准确的需求。有时候我们的工作会被开发人员认为是“破坏”性的工作，这样就会引起我们跟开发人员的 ，所以当我们发现一个bug之后如何跟开发人员沟通也是一门艺术。很多时候我们不仅仅是把bug写出来，也要很好地说给开发人员知道。从而达到我们彼此想要的一种结果。2、我们需要具备很好的自信心：很多时候开发人员会经常认为测试人员的开发相关知识不如自己，所以会有一种轻视的态度，这个时候我们除了补充我们的专业知识之外还需要有很强的自信心。呵呵。如果允许他对我们说这说那，那么我认为我们的工作还没开展就已经处在十分不利的地步了， 会被他们牵鼻子走。这种现象很正常。而我却属于那种很讨厌被别人牵着鼻子走的人。所以我知道 要很专业才能让别人尊重自己的劳动成果并听取自己的见解。当然这种自信心也是建立在心平气和下的沟通，不是完全对立的。3、我们需要保持一种怀疑的精神（这点我很擅长，我经常怀疑那些跟 经质。亏大了）我们会经常碰到这样一种情况，我们往往发现的bug交给开发人员时他们总是尽他们最大的努力解释每个他们认为不是bug的bug。我们在他们解释的同时必须要怀疑他们的观点直到我们自己确认过之后。4、我们需要耐心和很好的 力：有时候往往一个bug需要我们很耐心的花费时间、精力去投入在上面，而且当我们再找到有些类似的bug的时候，要能从脑子里面找出来这些bug，这就需要我们有很好的 力。其实如果不具备这些条件了那么相关的文档就是我们最好的查询资料。我就是属于这种类型的，很多时候总是翻阅以前的文档。但是这样也有一个好处，那就是在不断的查询过程中我们对文档的修改，使文档日臻完善，当然这种完善也是相对的。5、我们需要一颗安静的心：因为浮躁的人是找不出隐藏在深处的bug的，（所以我们的开发人员总是喜欢让我测试他们的东西，因为我汇报的bug很少，这样他们的绩效就表现得很好啊。所以我总是挨批啊。不过现在学乖了，呵呵）所以当我们测试的时候我们应该保持内心的平静，这样我们才会保持很好的洞察力来找到那些隐藏很深的bug。而且也会抓到相关的重点的。这点是很重要的。否则你的测试跟 做也没什么区别，根据业务流程，根据用户需求，根据开发人员的思路一路跑下去，发现一些皮毛的bug。这不是一个好的测试人员应该做的。我们在平静当中才能保持自己的观点不被别人左右。6、我们还需要能够承受压力并排遣压力：无须质疑，我们的工作承受着一定的压力，当然这样说有点片面，不过大体上应该是这样的。所以我们经常承受着一定的压力，客户在催促，开发人员在delay，风箱里面的老鼠两头受气。所以我们要能够承受压力，包括外界的、工作上的压力。并且因为压力而导致的不好的情绪带到工作当中。学会排遣这些压力，保持一颗轻松的，平静的心，然后全身心投入到我们的工作。上面的只是根据实际的一些经验以及曾经看过的一些朋友的见解总结而来的，还有很多其他方面的知识但是我实在没有时间了呵呵抱歉。以后有时候还可以继续补充。只是想强调一点：测试的发展前景是非常好的这点从这几年无论测试人员和测试环境的变化还是客户对产品质量的要求越来越高都可以看出的。还是上面说的那句老话：相信明天，有关黑盒测试、白盒测试和灰盒测试的 ]黑盒测试黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进试。白盒测试白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进 试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序 了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了—些与数据相关的错误。灰盒测试灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。慧灵科技依托测试时代资源，推出面向实践的软件测试专业课程，由国内著名软件企业的一线技术专家主讲，为您的企业解决实践中的关键问题。如果您培训的目的不是拿一个，而是想学习软件测试的最佳实践那我们会是您一个不错的选择。登陆公司： ]概念和定义不完全、不彻底是软件测试的致命缺陷，任何程序只能进行少量而有限的测试。测试用例在此情况下产生，同时它也是软件测试系统化、工程化的产物。而测试用例的设计一直是软件测试工作的重点和难点，那么

：：什么是测试用例？为达到最佳的测试效果或高效 隐藏的错误而精心设计的少量测试数据，称之为测试用例。我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。怎样的用例算是好用例？—个好的测试用例是在于它能发现至今未发现的错误。使用测试用例的好处在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。测试用例的使用令软件测试的实施重点突出、目的明确。在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。设计测试用例的方法黑盒测试：等价类划分法边界值分析法错误推测法因果图法白盒测试：逻辑覆盖法基本路径测试法测试用例的设计过程测试设计员（分析设计员）依据不同阶段的测试计划、设计模型和实施模型来设计该阶段测试用例。测试设计员是具有丰富测试经验或具有软件分析设计能力的高级测试工程师。如果没有测试设计员，则可用分析设计员代替。针对白盒，还应有驱动程序和桩模块。测试点的确定ISO质量体系：在概要设计或详细设计中应明确 每个单元模块的测试要点、指标和方法。CMM质量体系：在系统的用例模型描述中应明确每个用例模型的优先级及用例工作流程，每一个用例模型为一个测试点，用例模型中每一个测试需求至少应有两个测试用例。理解上的误区测试用例应由测试设计员或分析设计员来制定，而不是普通的测试员。测试点应由分析设计员确立，与测试人员无关。测试工作展开于项目立项后，而不是代码开发完成之后。测试对象不仅仅是源代码，还包括需求分析、需求规格说明书、概要设计、概要设计说明书、详细设计、详细设计说明书、使用手册等各阶段的文档。用例场景的定义用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。为什么引入用例场景现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行。提出这种测试思想的是Rational公司，在RUP2000中文版当中有其详尽的解释和应用，用例场景贯穿其中。用例场景例子下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（1和3），还可能于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和4）遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：场景1基本流场景2基本流备选流场景基本流备选流备选流场景基本流备选流场景基本流备选流备选流场景基本流备选流备选流备选流场景7基本流备选流4场景8基本流备选流3备选流注：为方便起见，场景5、6和8只描述了备选流3指示的循环执行一次的情测试用例生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。测试用例例子假定上图描述的用例对备选流3规定如下：“如果在上述步2‘输入提款金额’中输入的量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤2‘输入提款金额’，此时银行客户可以输入新的提款金额。”据此，可以开始确定需要用来执行备选流3的测试用例：测试用例场景预期结果本用例的开端是ATM本用例的开端是ATM处于准备就绪状态。基本流准备提款-客户将插入ATM机的读卡机。验 -ATM机 。帐户代码，并检查它是否属于可以接收的输入PIN-ATM要求客户输入PIN码（4位）验证帐户代码和PIN-验证帐户代码和PIN以确定该帐户是否有效以及所输入的PIN对该帐户来说是否正确。对于此事件流，帐户是有效的而且PIN对此帐户来说正确无误。ATMATM显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。输入金额-要从ATM中提取的金额。对于此事件流，客户需选择预设的金额（10 、20 、50 或100 权-ATM通过将卡ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对 请求给予答复，批准完成提款过程，并且据此更新帐户余额。TC场景步骤2-提款金额>帐户余额在步骤2处重新加入基本流TC场景步骤2-提款金额<帐户余额不执行备选流3，执行基本流TC场景步骤2-提款金额=帐户余额不执行备选流3，执行基本流注：由于没有提供其他信息，此简单。实用举例下面是一个由用例生成测试用例的更符合实际情况的示例。示例：ATM机器的主角和用例。下表包含了上图中提款用例的基本流和某些备用流：返 被返还收据-打印收据并提供给客户。ATM还相应地更新内部记录。用例结束时ATM又回到准备就绪状态。备选流1-银行卡无效 在基本流步骤2中-验证 ，如果卡是无效的，则卡被退回，同时会通知相关消息。备选流2-ATM内没有现

在基本流步骤5中-ATM选项，选项将无法使用。如果ATM内没有现金，则“提款”选流3-ATM内现金不 在基本流步骤6中-输入金额，如果ATM机内金额少于请提取的金额，则将显示一则适当的消息，并且在步骤6-输入金额处重新加入基本流。选流4-PIN有 在基本流步骤4中-验证帐户和PIN，客户有三次机会输PIN。如果PIN输入有误，ATM将显示适当的消息；如果还存在输入机会，则此事件流在步骤3-输入PIN处重新加入基本流。如果最后一次尝试输入的PIN码仍然错误，则该卡ATM机保留同时ATM返回到准备就绪状态，本用例终止。选流5-帐户不存 在基本流步骤4中-验证帐户和PIN，如果银行系统返回的码表明找不到该帐户或 从该帐户中提款，则ATM显示适当的消息并且在步骤9-返回 处重新加入基本流。选流6-帐面金额不 在基本流步骤7-授权中，银行系统返回代码表明帐户余少于在基本流步骤6-输入金额内输入的金额，则ATM显示适当的消息并且在步骤6-输入金额处重新加入基本流。选流7-达到每日最大的提款金额

在基本流步骤7-中，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在24小时内允许提取的最多金额，则ATM显示适当的消息并在步骤6-输入金额上重新加入基本流。选流x-记录错 如果在基本流步骤10-收据中，记录无法更新，则ATM进银行系统发送一条适当的警报信息表明ATM已经暂停工作。客户可随时决定终止交易（退出）。交易终止， 选流y-退出

退出。选流z- ATM包含大量的传感器，用 各种功能，如电源检测器不同的门和出 处的测压器以及动作检测器等。在任一时刻，如果某个传感器被激活，则警报信号将发送给 而且ATM进入“安全模式”，在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。第一次迭代中，第一次迭代中，根据迭代计划，整个用例，只实施了下面的事件流：基本流-提取预设金额（备选流2ATM内没有现金备选流3ATM内现金不足备选流4-PIN有误、20美元、、）备选流5-帐户不存在/帐户类型有误备选流6-帐面金额不足以从这个用例生成下列场景场景1-成功的提款基本流场景2-ATM内没有现金基本流备选流场景3-ATM内现金不足基本流备选流场景4-PIN有误（还有输入机会基本流备选流场景5-PIN有误（会基本流备选流场景6-帐户不存在/帐户类型有误基本流备选流场景7-帐户余额不足基本流备选流注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（）用于表明这个条件必须是VALID（有效的）才可执行基本流，而ITC（例）ID号场景/条件输入TC（例）ID号场景/条件输入的金（选择的金额ATM内的金额预期结果场景1-成功的提款VVVVV成功的提款。场景2-ATM内没有VVVVI提款选项不可用，用例结束场景3-ATM内现金VVVVI本流步骤6-输入金额场景4PIN有误（有不止一次输入机会IVVV本流步骤4，场景4PIN有误（有一次输入机会）IVVV本流步骤4，场景4PIN有误（再有输入机会）IVVV留，用例结束在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例CW1称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括测试用例，以确保只有在符合条件的情况下才执行基本流。这些测试用例由CW2至6表示（阴影单元格表明这种条件下需要执行备选流）。虽然CW2至6对于基本流而言都是测试用例，但它们相对于备选流2至4而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1-基本流）。每个场景只具有一个正面测试用例和测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场景4-PIN有误，至少需要三个正面测试用例（以激活场景4）：输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤-输入PIN输入了错误的PIN，而且不再有输入机会，则此备选流将保留 用例。最后一次输入时输入了“正确”的PIN。备选流在步骤5-输入金额处重新加入基本流。注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看V和I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景6-不存在的帐户/帐户类型有误和场景7-帐户余额不足就缺少测试用例。—旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）设定测试数据。TC（测试用例）ID号场景/条件输入的金额或选择的金额帐面金金额预期结果场景-成功的提款50.00成功的提款。帐户余额被更新为450.00场景2-ATM内没有提款选项不可用，用例结束场景3-ATM内现金警告消息，返回基本流步骤6-输入金额场景4-PIN有误（还有不止一次输入机会）警告消息，返回基本流步骤4，输入场景4-PIN有误（还有一次输入机会）警告消息，返回基本流步骤4，输入场景4-PIN有误（不再有输入机会警告消息，卡予保留，用例结束以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：场景6-帐户不存在/帐户类型有误：未找到帐户或帐户不可用场景6-帐户不存在/帐户类型有误：从该帐户中提款场景7-帐户余额不足：请求的金额超出帐面金额在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：无效卡（所持卡为挂失卡、卡、非承兑银行发卡、损坏等）法读卡（读卡机堵塞、脱机或出现故障）.帐户已消户、冻结或由于其他方面原因而无法使用.ATM内的现金不足或不能提供所请求的金额（CW3CW3中只是一种币值不足，而不是所有币值都不足）.无法联系银行系统以获得认可.银行网络离线或交易过程中断电. ]Leveret现在大家在写测试用例的时候每个人都有自己的特点，但是什么样的一个测试用例才是一个比较好的用例，这是一个比较真实的现象，有这样几个问题大家可以交流一下自己的心得（如果愿意交流的朋友）：系统测试的用例要如何设计才能验证需求？有时候不知道结果的情况下如何预测结果，测试用例应该在不同的阶段下实施的时候应该是独立的。一般在设计测试用例的时候要包括合理输入，不合理输入，预测结果，一般常用的测试用例的设计主要用到：等价类划分，边界值分析法，错误推测法，但是这些都是理论方面的概念，我们在实际设计当中往往并不是按照这些去做的。大家在设计测试用例的时候应该都有自己的心得，如果愿意，可以把自己的观点 出来大家来讨论。Seanhe我感觉测试用例没有什么好坏之分：）当初的那句话，能发现最多错误的，发现至今为止没有发现的bug的用例就是好的用例，我认为是错误的。因为，测试不是解决问题，测试用例的好坏不是指单个的用例，而是用例的覆盖度，单个用例再好，所有用例的覆盖度不够，那测试工作还是失败的。所以测试的关键不是用例设计，而是测试范围的圈定，使用的方法，用例的设计只是自然而然的事情。再说说一开始的用例怎么写，开始肯定有很多不清楚所以用例中很多的内容无法填写，所以我们应该默认用例的书写是个迭代的过程，不同阶段完成不同的内容，执行之前全部完成就可以了。Leveret用例的覆盖率也应该是从单个开始的，而且很多时候发现用例在很多输入输出方面的设计基本都是雷同的，至于测试范围的圈定，在系统设计阶段我们能考虑周全吗？考虑的出发点呢？根据测试的类别来考虑还是根据需求方面呢？不过对你所说的用例的书写的迭代过程比较赞同，我们一般测试正式开始之前会对用例有一个评审过程，明白了这个道理之后应该会比较轻松的。对设计测试用例的来说。欢迎大家自己的观点.Zhybing测试用例的好坏，主要看本测试用例是否满足了测试内容的要求，满足了测试内容要求的测试用例就是好的，不满足测试内容要求的测试用例就是不好的.Leveret:那测试内容是在测试计划里面反映的？按照你的说法。仅仅只是满足测试内容吗？你是这么认为的？Jackei下面列举了我的一些看法：对于有时候不知道结果的情况下如何预测结果”，个人觉得这个问题比较明确，如果需求无法明确，或者说需求不够明确，则对于该需求的测试用例设计应该推迟，并及时同需求人员进行交流，尽快将需求准确的定义下来。一般在系统测试阶段考虑的测试方法是黑盒测试，这时对于测试用例的设计如何使用那几种方法呢？个人认为可以先使用等价划分的方法划分出等价类，然后使用边界分析法确定下测试数据，最后通过自己以往的厕所经验或者其他的经验来进行错误推测，增补一部分用例。对于这个问题，个人对于现在市面上的很多测试书籍都有的看法，很多书提到的一些用例设计的例子都是用windows计算器或者其他单纯用几个数字来作为例子——比如输入域是0-100，让你设计用例。很多时候我们在进行用例设计时看到的并不是很明显的数字，这些东西都是隐含在业务规则中的，感觉我们现在很多初学测试的朋友这种分析业务规则的能力还是比较欠缺，看不到的测试需求。当然这些方法也就应用的很有限了。对于“测试用例应该在不同的阶段下实施的时候应该是独立的”，我也比较赞成。个人认为关键要搞清楚测试用例的作用。作为开发过程，是先有需求人员进行需求的收集，然后是系统分析员对需求整理分析，形成用例或者软件需求规格说明书，之后由系统架构人员进行架构设计，开发人员完成详细设计和编码工作——当然这也未必是一成不变的，但是大体的任务都是这么多。同样，我们看一下RUP中对于测试工作的流程介绍，为什么要把测试设计同测试实现以及测试执行明确的区分开来呢？因为测试工作现在同开发工作已经越来越相似，包括测试需求的整理、测试用例的设计以及测试用例的实现。我们现在很多所在的公司可能从人力资源或者从公司的流程上无法保证完全按照这个规范来操作，但是我们可以从RUP中明确测试用例的作用。用例本身就是用来指导实现的，用例实现的时候可以是自动化也可以是手工操作的具体步骤。测试用例是可以同具体的应用程序实现完全独立的，可以不受应用程序具体实现变动的影响。至于为什么我将在下面说明。对于“很多时候发现用例在很多输入输出方面的设计基本都是雷同的”，我觉得这个就可以考虑测试用例的“复用”。其实雷同也是正常的。下面将阐述我个人对于测试用例设计工作的一些看法。我很赞成seanhe对于测试用例迭发的观点，现实中我们也是这样考虑的。测试用例不会平白无故的被设计出来，它是有目的和前提的。个人认为测试用例是用来指导具体测试实现的，包括自动化的实现和手工测试步骤的实现。对于测试用例对测试需求的覆盖，个人认为不是测试用例编写的目的，而是对测试工作的要求——是要求测试用例设计人员的阶段性工作的结果必须符合一定的要求的。测试用例本身是无法保证覆盖需求的。那么说到了测试需求，这里顺便说说测试需求的确定。leveret也问到了这个问题——“至于测试范围的圈定，在系统设计阶段我们能考虑周全吗？考虑的出发点呢？”个人认为测试范围的圈定也就是测试需求的确定。对于一个产品来说，它的开发和测试都不是的，随着开发版本的迭代，测试工作也将继续进行下去，同时，我们对每个版本的测试范围都是不同的。注意，这里有一个关键，也就是测试范围圈定的出发点——软件需求的确定。那么怎样来明确软件的需求呢？——版本。如果希望工作的进度和内容可以明确的定义下来，就首先要考虑版本的确定——软件需求的版本确定。通过软件需求的版本控制，可以明确每个不同版本的产品中所实现的特性，哪些特性将在以后的版本中实现。这里重点提到的是对于需求也需要使用版本的概念来进行管理。既然某个版本的软件需求已经确定，那么接下来的开发工作就可以在这个需求版本划定的范围内开展。在需求阶段，软件需求规格说明书和用例中对于软件的描述、业务规则的描述就可以整理出我们最早的测试需求，这部分测试需求将完全来源于软件需求，是当前阶段测试工作的一个基础。不过大家要看到，我们的测试工作从现在开始。这个时期我们有一个非常非常重要的工作，尝试着进行需求文档的检查。这里，对于需求文档的检查主要是两个方面：（1）检查需求文档描述的正确性，愚以为测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身就要对会计工作熟悉，财务制度熟悉，在检查需求文档的时候不要所谓的“都是用户真实的需求”，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需求。另外，还有一个用户的需求是否符合行业规范的问题，如果不符合，那么是否要确认——这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。（2）检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性——我得意思是证需求是可以完全为测试工作服务的。再说的具体一点，要保证所有的软件需求都是可以用某种方法来明确的判断是否符合要求的。如果对于某个需求，无法获得一个明确的判断标准，则应该请需求人员对需求进行修改或补充——一个缺乏准确定义的需求，我们可以认为开发人员也无法准确的实现或者实现一个错误的需求，如果在应用程序交付测试时才发现这个问题，带来的就因项目而异了。随着开发工作的开展，开发部门的架构设计以及详细设计也将陆续提交，这时候，我们可以根据设计文档来对原来的需求进行增补。注意，这里我们对于设计文档中提到的内容要有选择的采用，只有符合软件需求规格说明书或用例中已经定义的部分才可以用来调整我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，确定下以哪一个为准，然后调整测试需求。这部分工作其实已经包含了对设计的检查，继续努力尽早的发现缺陷出现的征兆。在应用程序交付后，测试部门开始执试。这时很有可能通过一些我们根据测试需求设计的测试用例所没有包含的方找到一些缺陷，那么，这部分方法我们也应该整理到测试需求中。OK，相信说到这里，各位看客也应该可以理解了我的观点。对于一个持续发展的公司或者持续开发的产品，它的所有东西都是要不断积累的。对于测试需求，不仅仅是在一个版本的开发过程中，在不同的阶段进行迭代，在产品的整个生命周期中的不同版本间也是不断迭代的。既然明确了测试需求，测试用例的考虑也就变成seanhe所说的那种自然而然的事情了。我们可以根据不同阶段已经确定下来的那些测试需求来进 试用例的设计，然后随着开发过程的继续，在测试需求增补或修改后不断的调整测试用例。如果我们从产品的整个生命周期来看，就会发现其实根本没有测试工作终结而测试需求和测试用例 结束的时候，因为一个版本的结束就是下一个版本的开始。从这个大的范围来看，我们的测试需求和测试用例将 的不断迭代下去。啊，今天心情好，比原来那个回复又多写了很多，希望对所有的朋友多可以有些帮助。不过好像有些跑题，本来题目是“关于评价测试用例的好坏”，我还是要给出答案的：个人认为测试用例的好坏可以有几个方面。第一，是否独立于具体的实现；第二，是否可以比较方便的指导实现工作；第三，是否比较容易 而其他方面，个人认为则可以看做是“关于评价测试用例设计人员工作的好坏” 参考。如果朋友们希望就这些问题展开讨论，可以发 到我的邮箱：jacke Jackei我又想到了一点评价测试用例好坏的因素：易用性：是否方便使用，比如是否可以随便哪个人都可以拿来简单的看看就知道如何根据用例进 试； 性：是否方便 ，特别是当需求或者设计发生变化的时候，是否付出较少的成本就可以完成 工作；有效性：是否可以保证一个用例在整个产品的一个相对较长的生命周期中可以反复使用，保证有效性。抛砖引玉，望大家继续补充。您是否对软件测试的整体规划一直比较模糊？您是否觉得软件测试工作技术含量不高，不知道如何提高自己？您是否发觉测试用例的复用率非常低而且检索困难？您是否觉得测试工作不太容易规划，总是不如预期？您是否觉得性能测试很重要但是不知道如何组织和实施有效的性能测试？您是否非常想知道大型的企业级系统是如何进行性能规划的？您是否想知道流行的测试工具的使用方法？ 性能测试怎样提高性能测试的效率和质量 日新月异的今天，顺应世界经济一体化的潮流，中国软件行业加强了与世界 沟通与交流，基于本身提高软件质量的迫切需要，在国外优秀的软件企业中被证明为提高软件质量行之有效的途径，软件测试开始越来越受国内软件行业重视。各种各样的测试工具和测试理论，也都逐渐被我们所熟知。软件测试也开始成为人们平时谈论和网上探讨的热点话题。在软件测试倍受注目的情况下，身为一名软件测试人员，如何高质量的完成公司交给的测试任务，无疑是我们应该考虑首要问题。从事软件测试已近两年，从刚开始的一脸茫然，到如今的手到擒来，期间也经历了很

栏 工作时间：3多曲折，总结这两年来的经念教训，我认为有必要就软件性能测试这个话题和大家展开探讨，与大家共同 软件测试的得失，为提高我们的测试水平尽一分薄力。作为评价产品性能的重 ，性能测试在软件测试工作中占 一直很大，要最终提供一份准确， 的测试报告，测试人员的努力工作自然不可或缺，但更重要的是测试人员清晰的工作思路，简洁的测试流程和良好的测试方法。目前性能测试存在的问题总结以往进行的性能测试，虽然测试人员自始至终对测试工作都做到了认真负责，但测试报告出炉后，大家总觉得美中不足对测试结果都心存疑虑，尤其在那些时间跨度较长、针对不同的测试对象的性能对比测试中，或多或少都存在以下几个方面的问题：测试准备不充分，测试目标不明确，测试计划不详细；缺乏测试以及针对测试对象的技术储备；测试环境的稳定性及前后一致性不足；测试数据精确性和代表性不足；测试描述不精练；下面，我们就剖析以上问题的同时，探讨一下如何解决这些问题。性能测试准备这是一个经常被测试人员忽略的环节，在接到测压任务后，基于种种其它因素的考虑，测试人员往往急于进度，立即投入到具体的测试工作去了，测试、记录、分析，忙的不亦乐乎，工作进行了一半才发现，或是硬件配置不符没有做好测试准备惹的祸。那么我们应该如何 能测试的准备工作呢 、需要分析，我们做测试也一样。在拿到测试任务后，我们首要的任务就是分析测试任务，在开始测试前，我们至少要弄清以下几个问题：要测试什么或测试的对象是谁？要测试什么问题或我们想要弄清楚或是论证的问题？哪些因素会影 需要怎样的测试环境？应该怎样测试？只有在认真测试需求和仔细分析测试任务后，才有可能弄清以上一系例的问题，只有对测试任务非常清楚，测试目标极其明确的前提下，我们才可能制定出切实可行的测试计划。明确测试目标,详尽测试计划在对测试需求充分了解的基础上，制定尽可能详细的测试计划，对测试的实施是大有裨益的。测试计划的制定，大多专业的测试书籍多有详述，故本文不再鏊述。测试技术准备在目前的大环境下，要求测试人员在短时间撑握所有的软、硬件知识是不太现实的，但平时测试人员应抓紧对测试工具和测试理论的研究，在测试计划中，应给研究测试对象和测试工具分配充足的学习时间，只有在充分撑握测试工具，完全了解测试对象的前提下，我们才能够实施测试。建力在错误的认识上的测试，既使你再努力结果也是背道而驰，也很难证明问题，更不用说用这样的测试报告去说服用户。配置测试环境只有在充分认识测试测试对象的基础上，我们才知道每一种测试对象，需要什么样的配置，才有可能配置一种相对公平、合理的测试环境（这在性能对比测压中尤其重要）考虑到其它因素，如网络锁、网速、显示分辩率，数据库权限、容量等对测试结果的影响。如条件允许，我们最好能配置几组不同的测试环境。测试数据的获取和处理在所有的测试中，测试数据的收集工作都是较为 的，GIS软件更是如此，每一种软件都有它的文件格式，有的软件还有几种格式。在这种情况下，我们只能把 格式的数据转换成每一种被测试软件自已的格式。同时，还应对数据作一定的处理，如处理数据冗余，处理显示风格等。如在测试时会更新数据，操作前一定要备份数据。其外，还应评估数据格式和数据量对测试的影响， 必要，应准备多组数据。最后，一定要检查测试数据的有效性，避免损坏数据对 的影响。如何开展性能测试测试前期的准备工作纷繁复杂，做好测试准备工作，已是完成了测试工作的一大半，但要产生一份具有说服力的测试报告，还应正确把握测试的强度，保持测试的一致性，提高测试的精度。判断软件的好坏，要看软件解决实际应用的能力，只有在一定的测试强度下，才能测试出各种软件资源的消耗率，软件运行的速度，软件的稳定性。通过对比在不同的测试强度下，不同软件每一个功能模块解决实际问题的能力和软件运行的效率，我们才可能判断出不同软件的每一个模块的强弱，甚至于整个软件的优劣。性能测试开始后，所有参数的输入都应遵循统一的标准，无论是哪一个环节，哪怕是一点点偏差，都应立即纠正，觉不能心存侥幸。要特别注意外部环境对的影响，如果在整个测试过程中，外部境不一致，如网速、机器内存使用率不一样，就有可能导制 与实际情况有出入。如何总结性能测试对测试的终结，实际就是对测试数据的分析和处理。我们测试工作做的再好，如最终到用户手中的是一堆杂乱无章的数据，那也是美中不足。首先，我们最好从所有的测试数据中，筛选出具有代表意义的数据，做出统计图，然后和开发人员一起，认真分析数据，找出软件存在的问题，得出测试结论。大多数用户，真正需要的就是科学、客观的测试结论。结论各种软件性能测试，范围大小不同，强度高底有别，但只要本着认真、客观，科学的工作态度，遵循本文论述的方法，做好测试工作是不难的。本篇文章主要谈的是软件性能测试方面的问题，相信对其它方面的软件测试也有一定的借鉴作用。43《单元测试技术――Nunit3《测试管理――TD》2《自动测试工具――Robot2《自动测试工具――LoadRunner2上面是目前我们开发的课程，企业内训可以直接们。如 ：Alan：Alan工作时间：6： ]Mail: 通过测试和其他形式的软件质量 活动而发现的偏差，统称为软件缺陷。我们通常说到的bug就是软件缺陷的一种，是隐藏于代码中的问题，它可以通过软件测试，代码的走查形式而加以发现。在本文中，我们现就bug来进行分析，为了表述方便称为缺陷分析。这里提醒大家注意的是，缺陷的含义较广，不同类型的缺陷需要用到不同的分析Mail: 什么是缺陷分析？缺陷分析本质上是对缺陷中包含的信息项进行收集，汇总，分类之后使用统计方法（或者分析模型）得出分析结果。缺陷分析得出的结果可以用来度量（软件）开发过程中各软件阶段中工作产品的质量，了解缺陷集中的区域，明晰缺陷发展趋向。对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值缺陷数据的收集在我们提交缺陷报告的时候，实际上就是在记录一些必要的信息项。在不同的软件生产企业中，需要记录的信息项是大相径庭的。以下是分析缺陷活动中必须收集的一些数据项目缺陷提交时需要收集的信息缺陷的严重等级缺陷所在的模块缺陷发现的时间缺陷所在的版本号缺陷的发现者负责修改缺陷的工程师缺陷关闭时需要收集的信息缺陷关闭的时间关闭缺陷的版本修复缺陷而改动的代码行数产生缺陷的根本原因（例如：需求，分析，编码，软/硬配置）分析点缺陷的发展趋势缺陷的发展趋势包括新发现缺陷数量增长趋势和关闭缺陷数量的增长趋势。对于软件产品发布而言，发展趋势图是辅助决策的重要依据。一般来说，软件发布的必要条件是新缺陷的数量增加呈下降趋势，见下图。CumOpenedCumBugs02004-4- 2004-4- 2004-4- 2004-4- 4-30Date在软件过程中，缺陷发展趋势图有助于我们了解各版本中缺陷数量的分布。特别在回归测试阶段中，缺陷的分布可以直接反映本的质量状况。见下图中各版本缺陷的分布状况。缺陷的分布状况缺陷分布状况图有两种，第一种是缺陷按模块的分布状况，另外一种是缺陷按产生的根本原因的分布状况。模块分布图SubsystemSubsystem50 Account Bug缺陷产生原因分布图该分布图是缺陷分析中最为重要的一张图表，因为它可以直接反映出各软件工程活动的质量，为软件过程的改进提供直接的参考数据。一般来说，缺陷产生的根本原因划分的越细致，分析的结果就越精确。见下图：

Bad

Functional

SystemBad但当我们发现需求中出现的缺陷比较多的时候，在未来的项目中我们可以通过需求评审，需求变更控制来减少该种缺陷的数量，以起到软件质量保证的目的。同样如果我们发现软件设计过程中产生的问题比较多，那么就可以通过加强软件设计阶段中的活动来保证设计的质量。源代码修改趋势图和模块分布图源代码修改数量趋势图可以为回归测试风险分析和软件发布提供参考。源代码修改的数量越多，那么代码产生的负作用的风险就越大，为了规避风险，回归测试的强度就需要相应的加强。同样的道理，如果某一个产品的源代码修改数量呈上升趋势的话，那么它是不适合现在发布的。信息反馈1、本电子期的封面设计、版面设置有何建议？2、本电子期中各文章内容的质量如何？3、本电子期中您最喜欢的文章？4、你最希望在本电子期中看到哪方面的测试内容？5、读者个人信息简录：：从事测试工作年限：测试团队人数：最关心的那种测试类别功能或性能或其它)：以何种方式知道测试时代的：感谢您花费宝贵的时间来填写对本电子期的建议或意见，请将您的反馈信息发至 .cn。我们会认真对待每一封来信，并会衷心采纳每一个有意义的建议。感谢大家对测试员电子期的支持与厚爱。欢迎投稿 稿件要求稿件要求含有标题、作者 及作者简介(如：单位、个人爱好、联系地址等可根据本人要求).属于摘录或拷 章，请注明文章出处及 作者。提倡大家多性文章.文 （不超过200字）（35个）正文,字体为宋体5号字.稿件格式为 Word格式， 在稿件中使用标题、分页符等排版设置。加入我们测试行业的发展需要依托测试行业的同仁共同来推动，测试时代是一个开放的平台，在这个平台上需要的有志于测试行业的朋友共同来建设，在这个平台上我们已经筹建了测试Blog社区，测试员电子期，测试时代试交流会等一系