Grenford J. Myers在《The Art of Software Testing》一书中提出：一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试，由此可见测试用例设计工作在 整个测试过程中的重要地位。测试用例设计的好坏直接影响到测试的效果。目前很多公司的测试用例都是依据需求或者规范规格，测试用例设计人员根据经验来写测 试用例，这种情况就会导致测试用例覆盖面不全、测试用例规划不合理，甚至存在测试用例冗余的情况。测试用例覆盖面不全会导致出现漏测少测，将问题直接流向 用户；测试用例规划不合理、测试用例冗余会造成人力浪费，导致测试效率低下。因此不能只凭借一些主观或直观的想法来设计测试用例，应该以一些比较成熟的测 试用例设计方法为指导，再加上设计人员个人的经验积累来设计测试用例。

　　目前业界比较成熟的测试用例设计方法主要有：等价类划分法，边界值分析法，错误推测法，因果图法，正交实验设计法等。

　　等价类划分法

　 　等价类划分法是测试用例设计中一种重要而常用的设计方法，它将不能穷举的测试用例进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。等价类 划分是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

　　边界值分析法

　 　边界值分析法就是对输入或输出的边界值进行测试设计的一种方法。通常边界值分析法是作为对等价类划分法的补充。长期的测试工作经验告诉我们，大量的错误 发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用 例，首先应确定边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值而不是中间值作为测试数据。

　　错误推测法

　　错误推测法是指在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。错误推测方法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。例如， 在单元测试时曾列出的许多在模块中常见的错误、以前产品测试中曾经发现的错误、输入数据和输出数据为0的情况、输入表格为空格或输入表格只有一行等。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。

　　因果图法

　 　因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。等价类划分法和边界值分析方法都 是着重考虑单个输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件 组合起来可能出错的情况却被忽视了。而如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件 的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图来设计。

　　正交试验设计法

　 　正交试验设计法。利用因果图来设计测试用例时，作为输入条件的原因与输出结果之间的因果关系，往往因果关系非常庞大，以至于据此因果图而得到的测试用例 数目多的惊人，给软件测试带来沉重的负担。为了有效地、合理地减少测试的工时与费用，可利用正交试验设计方法进行测试用例的设计。正交试验设计方法依据 Galois理论， 它是根据正交性，按照 “均匀分散，齐整可比”的特点从大量的（试验）数据（测试例）中挑选适量的，有代表性的点（例），从而合理地安排试验（测试）的一种科学实验设计方法。它 简单易行，计算表格化，使用者能够迅速掌握，是一种高效率、快速、经济的试验设计方法。

　　以上这些方法各有优缺点，在设计过程中可以叠加使用，取长补短，使得设计出来的测试用例规划合理，裁剪得当，既能保证覆盖面，又能保证测试的效率，所以在测试用例的设计过程中得到了广泛的应用。

　　OPhone测试团队在测试用例的设计阶段充分运用这些方法，在测试用例的设计过程中极大的减少主观因素的影响，并在保证测试用例完备性和有效性的前提下，对测试用例进行有效裁剪，减少无效测试用例和冗余，在很大程度上提高了测试效率，从根本上确保测试的质量。

　　以前在这里看到一篇文章说，要积累各个常用模块的测试点，然后到需要测试的时候就根据这些测试点设计测试用例，我觉得这是一个好方法，就决定总结一下。我的实际经验不多，根据我在论坛中学到的零散的东西和自己的想象，总结出以下几点，欢迎各位继续补充。

　　1、登陆
　　2、添加
　　3、查询
　　4、删除

　　1、登陆
　　① 用户名和密码都符合要求（格式上的要求）
　　② 用户名和密码都不符合要求（格式上的要求）
　　③ 用户名符合要求，密码不符合要求（格式上的要求）
　　④ 密码符合要求，用户名不符合要求（格式上的要求）
　　⑤ 用户名或密码为空
　　⑥ 数据库中不存在的用户名，不存在的密码
　　⑦ 数据库中存在的用户名，错误的密码
　　⑧ 数据库中不存在的用户名，存在的密码
　　⑨ 输入的数据前存在空格
　　⑩ 输入正确的用户名密码以后按[enter]是否能登陆

　　2、添加
　　① 要添加的数据项均合理，检查数据库中是否添加了相应的数据
　　② 留出一个必填数据为空
　　③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例
　　④ 不符合要求的地方要有错误提示
　　⑤ 是否支持table键
　　⑥ 按enter是否能保存
　　⑦ 若提示不能保存，也要察看数据库里是否多了一条数据

　　3、删除
　　① 删除一个数据库中存在的数据，然后查看数据库中是否删除
　　② 删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除
　　③ 输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。
　　④ 输入的正确数据前加空格，看是否能正确删除数据
　　⑤ 什么也不输入
　　⑥ 是否指出table键
　　⑦ 是否支持enter键

　　4、查询
　　精确查询：
　　① 输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据
　　② 输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据
　　③ 输入格式或范围不符合要求的数据，看是否有错误提示
　　④ 输入数据库中不存在的数据
　　⑤ 不输入任何数据
　　⑥ 是否支持table键
　　⑦ 是否支持enter键
　　模糊查询：
　　在精确查询的基础上加上以下一点
　　① 输入一些字符，看是否能查出数据库中所有的相关信息

　　设计功能和界面测试用例

　　1.1 文本框、按钮等控件测试

　　1.1.1 文本框的测试
　　如何对文本框进行测试
　　a，输入正常的字母或数字。
　　b，输入已存在的文件的名称；
　　c，输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
　　d，输入默认值，空白，空格；
　　e，若只允许输入字母，尝试输入数字；反之；尝试输入字母；
　　f，利用复制，粘贴等操作强制输入程序不允许的输入数据；
　　g，输入特殊字符集，例如，NUL及\n等；
　　h，输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
　　i，输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

　　例如，关于测试用例设计方法，最常用的说法是：等价类，边界值，因果图等。实际上这些只是软件测试用例设计中如何确定测试输入数据，对于对话框中的数据控件输入值有效。如果把确定输入数据的方法，描述成测试用例的方法，那么，这样设计出来的测使用例就很有局限性。

　　实际上，编写测试用例包括两个方面：第一是编写测试用例输入数据，第二是编写测试用例实体（即包含测试目标，测试步骤，测试期望结果）。

　　为此，有必要把编写测试用例的工作分解成两个阶段：第一阶段称为“测试用例设计”，第二阶段称为“测试用例实现”。第一阶段的任务是如何确定测试用例的组织结构（模块化、阶段化），模块化即把被测软件分解成各个模块，每个模块组织成测试用例组。阶段化即按照软件开发的不同阶段分别编写软件测试用例，例如单元测试用例、系统测试用例、验收测试用例等。

　　编写软件测试用例的过程如图所示。

　　再来谈一下测试人员应该掌握的技术，就我个人来看，测试最核心的技术还是测试用例的设计，不论是纯手工测试，自动化测试，黑盒测试，白盒测试，功能测试还是性能测试都离不开测试用例的设计，至于更牛的测试专家他们所掌握的诸如开发测试工具这样的技术，仔细想想，也只是为了更方便的设计和实现测试用例。

　 　只要接触过测试的人不难发现，其实用例不难，大家或多或少都接触过用例，可真正明白用例的用途的还是在少数，以下我将用例的设计分为4个阶段当然只是给 新人朋友的一点建议，与我以前发过得一片新人朋友看的博文是同样效果的，只是给新人朋友指引一条测试的道路，所谓条条道路通罗马，也希望更多的朋友能够分 享自己的一些心得和体会。

　　第一个阶段，茫然

　　在这个阶段的朋友多半是第一次接触到测试用例，虽然用例的格式都有，但总是自己设计不出来或者设计出来的用例效果很差，其实用例的格式并不重要，有时候可以根据你自己的实际项目，所采用的设计方法，思维模式而改变，如果你感到无处下手，那么你应该去看一看有哪些用例的设计方法，同时仔细的分析下你现在的状态和手上的系统比较适合什么方法。

　　第二阶段，用例过多，覆盖面积虽然达到但是工作量太大

　 　这个阶段的朋友，你们已经掌握了1种或2种基础的用例方法，比较常见的诸如场景法，等价类划分法，边界值法，你会发现，像是场景法一条比较复杂的业务流 程能够分出10多20条备选流，而场景法和等价类结合确实能够实现一个较为客观的覆盖面积，但是你会发现要达到这个效果所需要用的测试用例实在太多，这就照成了工作量增大，无意义的用例和重复的用例也会直接造成你的工作有百分之20甚至更多是无效的，这个时候你就应该尝试去了解一下高级的用例设计方法了，比如因果图判断。

　　第三阶段，用例大瘦身，覆盖面积依然可观

　 　这个阶段，其实你在用例的方向已经颇为厉害了，至少掌握了三种用例设计方法的你，已经能在短时间内对一个一般的系统做出一个较为完整的测试用例了，通过 2中基础的用例设计方法，将整个系统所有功能点都包括起来，再通过因果图判断，将重复的测试功能点排除掉，可以说你现在设计的测试用例已经是优秀的用例 了，完全能够达到使用尽可能少得用例覆盖尽可能多的面积，那么这个时候你应该继续提高自己的能力，可以尝试着将用例进行复合，进行复合用例的设计了，难度 颇高哦

　　第四阶段，这个阶段实际上你已经是达人了，我也就不在达人面前献丑了，只是借助这个阶段，提 醒一下新人朋友，不要认为自己的技术已经很好了，要知道第一阶段巅峰的人是比不上第二阶段初级的，你觉得自己很优秀了，只是因为你不知道在你之上还有很多 层面是你没接触到得，千万不要止步不前。其实测试这个行业，要做好很不容易，常常看见很多人做了4，5年还是觉得自己还是什么都不知道一样，从这也能看出 测试的难度，国内的测试，还不够成熟，最直接的体现就是测试的易学，还有和开发工资的对比，为什么测试易学而我却说测试很难呢，因为所谓的易学的测试，甚 至不需要去学，有些公司直接就是让你东点一下西点一下，看看报不报错，这不算测试，至少在我看来真的不算入行， 测试难学，难就难在测试是纯思维上得职业，我们不需要一直敲代码，不需要一直去设计系统，但是我们必须要在思维了模拟很多场景，模拟很多操作，我们的工作 实际上核心部分都是在脑子里进行的，是不能通过肢体来表达的，你在思考新增人员的操作时，如果你直接就操作了，那么抱歉，你还不合格，如果想到什么就做什 么，你的测试效果会很差，因为这一个节点可能的情况你还没考虑清楚就充充开始操作，照成结果不外胡两点，一，大面积遗漏，二，工作量增加，有经验的测试 员，会在脑子里将所有可能的情况都考虑到最后形成文档，在依照文档来进行测试，这份文档也就是测试用例，能够保证覆盖面就又不让我们过多的重复操作，更能 让开发或经理清楚的了解到这个系统哪些地方已经测了哪些地方已经遗忘了，我们从最初做测试的时候应该就会了解到，不存在百分百测试，也不存在2个人设计的 用例百分百相同，这个时候 用例文档的好处就体现出来了，即使开发人员在看了你的文档后也有可能提出一些你没有考虑到的地方，毕竟这些系统的核心还是开发人员自己开发出来的，同时开 发也是人，开发考虑的角度也代表着一部分用户的角度。即使你所在的项目组，公司不重视用例，但是如果你想在测试这个行业有所成就，那你就要注意这些地方， 我在上一篇博文里也提到过，公司不给你安排，并不代表不允许你做，不要等着公司给你安排任务，学到的技术学到的经验都是你自己的，能力提高的也是你自己， 相应的，能力提高了，工作量减少是必然的，同样的一个项目，别人要用1周测完，而你只需要1天，多余的4天，就是你自己努力的奖励。

　　期待同行参与讨论，我始终相信，分享自己的心得能让自己收获更多，一人一年的工作经验，虽然不能让你直接拥有5年10年的这样累加，但是也能让你的一年工作经验比别人的一年经验充实5倍，10倍。

　　最近，我也在网上看了一些贴子有关测试团队的管理问题，觉得在测试管理方面确实是个难题，这也可能测试团队确实不太好管理的原因吧，但我想只要自己去思考、去探索，总会找到适合自己团队管理的理念和模式吧。

　　我自己总结了一下，也结合自己的一些管理经验跟大家分享一下吧，欢迎大家把自己的提意见并把自己的经验也分享出来吧， 也算是大家相互学习的一个机会吧！

　　1、作为一个团队的管理者，最起码的是要自己懂自己产品或项目的业务。这一点很重要，第一这样有助自己分配工作给团队中的成员，要不然自己都搞不清楚业务难度和业量就分配工作给team member是件很让人难以接受的事情。第二，有助于自己和其它team或department的合作和沟通，不至于其它team提出的问题，自己还不清楚就答应或否定要做。

　　2、作为一个管理者，要懂更多的技术，至少是了解更多的测试技术，要了解其工作原理，这样有助于自己帮助团队成员research或者说技术的应用到实际的测试工作中来。也可以提高自己在测试团队中的威性，自己懂得多能让更多的同学认可和信服。

　　3、平衡按特长分配工作任务给team member。对于senior的测试员我们分配更多的任务是design test case的，junior的测试员可能更多的是分配执行测试。分配工作也是看看哪位测试员的特长，有些测试员对GUI比较敏感，有些测试员对Logic比 较关注，有些测试员对整个系统的流程更清楚，这些都是作为测试管理者分配任务的一个基线，这样可以更好地带好一个团队，提高软件测试的水平和质量。

　　4、做好测试风险的管理。一 般来说我们要尽可能降低测试风险，也是测试管理中一个很重要的课题，我也只能讲讲自己的一些片面的观点。测试风险从软件需求分析开始就存在，我们要更好地 在前期发现这些潜伏在需求或开发设计中的风险：1）如需求提出无法达到的功能，或有违背现有功能的需求我们在需求分析时一定要提出来；2）软件需求设计中 的有些无法测试的功能或要点，也要在测试需求分析中提出来；3）开发设计文档的静态测试，这一点我觉得很重要，很多小公司基本上会忽略这一点，静态测试 （主要是指文档方面的测试），对开发设计文档或原型设计文档的Review或测试有助于测试风险的降低，也能发现一些与需求冲突的设计，争取错误在前期发 现。同时我们测试用例在 测试方面也可以更好地与其配合，设计更好的的测试用例去测试，无论是从GUI，还是开发测试技术上测试都是有益的；4.对测试用例的Review或静态测 试，这样有利于优化测试用例，补充更多有用的测试用例和除去一些无用或重复的用例，这样能提高测试执行效率。5.监测测试执行及bug管 理，Bug算是测试员的成果之一，我们作为管理者一定要管理好，同时也能让我们清楚看到测试风险的存在，可以通过现有的Bug趋势判断系统中未来还有多少 bug存在，可以通过bug的类型分析fix bug还要多长时间还可能会产生多少bug，这样我们就能清楚知道当前测试人员和开发人员什么时候哪些人要开始加班了或要加派人手了...，我们还要关注 测试执行进度，测试执行初期bug趋势图，哪些类型的bug多些，此时会不会影响到测试中期，Logic的bug多的话一定会影响到测试中期的质量和测试 效率的，此时要提醒开发团队要注意logic类型bug的fix，不能把这类bug拖到后期fix，这样会影响质量。

　　当然软件质量风险还有其它的因素影响，如项目或产品时间评估，我想这部分大多是硬性的，我们可以协商测试的项目时间；还有人员请假或离职，以及测试组人员的变动，还有测试人员情绪波动都会影响到测试质量风险的。

　　5、合理评估测或衡量测试人员的绩效和水平。相 信这一点也是很难做到的一点，做得不好，不仅无法让整个团队好好工作，内部矛盾多，造成员工离职都会有，是让一个团队最头痛的事情，那么我们如何合理评估 测试人员的工作呢？首先我觉得公开硬性绩效标准，让大家都明白一个标准，也是团队共同发展的目的，这样做到公正，不会有私心。我觉得我们可以从几个方面去 衡量：a）工作态度及积极性 b）工作量和工作质量的一个线性比较，工作量大的一定是最辛苦的，但要与其工作质量作参考的，当然我们不能把一个员工发现的Bug量作为其工作成绩好坏的 标准，我记得以前一位测试经理就是这么做的，这是很要命和害了整个公司的做法，因为测试的对象不同或开发人员水平不一样及项目大小和难易程度，都是影响 bug数量是不一样的因素，我觉得一个比较好的标准是从中多方面来看的，测试执行过程和测试用例两方面，执行测试过程中bug趋势图和bug类型分布图及 软件交付后bug反馈率，测试员应在测试执行过程中发现各阶段中应当发现的bug，不能说很明显的bug而在最后才发现，这些都可以看出测试员的水平；另 外测试用例的设计也是一个很重要的标准，很好的测试用例，会尽可能早地发现bug，当然测试用例的设计可操作性、详细度等都是衡量的标准。

　　6、凝聚团队和激发团队成员的潜力。这 一点，虽说是有点大话，但真的也是很重要的，我觉得很重要的一点就是让团队中的每一个人都在成长，安排合理的工作角色很重要，让他们能更好的看到自己的成 长空间，如让比较junior的测试员设计比较简单的测试项目或需求的测试用例，这样让他也觉得自己也能设计测试用例；让很Senior的测试员负责项 目，让他觉得是项目中的主角而不是测试经理的身影，这样让团队中的成员也会更有责任心；安排比较空闲的测试去Research更新的技术或测试技巧并通过 讲课的形势分享给所有的成员；在项目执行中，安排测试员在执行这程中去交换测试，这样可以让参与这个项目的成员对整个系统了解，这样项目的每一部分都相当 于有backup人员，不担心项目哪位请假而为难了，也培养了测试人员的业务知识。多多让成员之间沟通，一起参加工作之外的活动。

　　7、沟通成员，了解成员的心态。作为一个管理者要多多关心成员的心态问题和成长问题，为什么工作不太积极？为什么项目质量不高？....都可以通过私下聊天谈心来了解，并帮助他们解决！

　　好了，我也暂时只总结了这么几条，希望以后的工作中能总结更好的经验分享给大家，也希望大家来提提意见，分享一下自己的观点吧！！谢谢各位了，我们一起成长中....

　　Q1：什么是负载测试？什么是性能测试？

　　A1：负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试，例如，访问一个页面的响应时间规定不超过1秒，负载测试就是测试在响应时间为1秒时，系统所能承受的最大并发访问用户的数量。

　　性能测试：指在一定的约束条件下（指定的软件、硬件、网络环境等），确定系统所能承受的最大负载压力。

　　Q2.性能测试包含了哪些测试（至少举出3种）

　　A2：性能测试包含负载测试、压力测试、大数据量测试、疲劳强度测试等。

　　Q3.简述性能测试的步骤

　　Q4.简述使用Loadrunner的步骤

　　A4：制定性能测试计划—>开发测试脚本—>设计测试场景—>执行测试场景—>监控测试场景—>分析测试结果

　　Q5.什么时候可以开始执行性能测试？

　　A5：功能测试通过；一般需要进行性能测试的系统，都是用户量比较大、业务使用比较频繁、比较重要的功能模块。

　　Q6.LoadRunner由哪些部件组成？

　　A6：主要有三部分组成：

　　Q7.你使用LoadRunner的哪个部件来录制脚本？

　　A7：使用Virtual User Generator录制测试脚本

　　Q8.LoadRunner的哪个部件可以模拟多用户并发下回放脚本？

　　A8：LoadRunner的Controller组件。

　　Q9.什么是集合点？设置集合点有什么意义？Loadrunner中设置集合点的函数是哪个？

　　A9：在性能测试过程中，需要模拟大量用户在同一时刻，访问系统并同时操作某一任务，可以通过配置集合点来实现，多个用户同时进行某操作；

　　集合点可以在服务器上创建密集的用户负载，使LoadRunner能够测试服务器在负载状态下的性能。

　　设置集合点函数：lr_rendezvous("Meeting")；  // Meeting是集合点名称

　　Q10.什么是场景？场景的重要性有哪些？如何设置场景？

　　A10：场景用于模拟用户实际业务操作；

　　LoadRunner中场景有手工场景和面向目标的场景。

　　设置场景：选择场景类型、设置运行时设置、模拟用户数、加减压方式、持续时间，配置负载生成器。

测试三问——新手必看

　　在进入软件测试行业之初，很多人都会存在下面最原始的问题，我称之为“测试三问”：

　　1、什么是软件测试？

　　2、为什么会有或会需要做软件测试？

　　3、软件测试的目的是什么？

　　答：

　　一、什么是软件测试？

　　软件测试是一个过程。是一个质量保证中的一个环节，是一个验证被测产品是否符合客户需求的过程。而且是一个有计划、有规律、有组织的活动。

　　二、为什么会有或需要进行软件测试？

　　先简单来描述一个逻辑：

　　第一、随着信息化的发展，我们在各行各业使用了越来越多的软件。一方面为我们提高工作效率，一方法丰富了我们的生活，甚至在有些行业已经离不开相关的专业软件；

　　第二、既然这些软件为我们工作，我们就需要它正确的为我们工作，否则会给我们带来不必要的麻烦甚至是危害；

　　第三、既然如此，我们在使用软件之前，就需要知道它能不能如我们所需要的那样工作。

　　这样，就产生一个需求：对软件进行测试。

　　有需要就会产生使其存在，以上简单的回答了上面第二个的问题。

　　不仅如此，在很多软件在从程序员手中开发完之初，都会有或多或少的问题，更是提出了软件测试的必要性，随着时间推移，逐渐催生了软件测试行业。

　　软件测试是为了保证我们的软件产品的质量。那么什么是我们软件产品的质量？如何才能说我们保证了我们软件产品的质量呢？

　　我们说如果我们实现了客户的所有要求，同时保证了程序运行的效率，保证了程序的可读性，可维护性，那么我们就保证了我们软件产品的质量。

　　前面这些点是我们软件测试的最最核心的思想。我们的一切软件测试活动都是为了保证这个核心思想而存在的，为了保证这个核心思想，出现了软件测试工程，出现了软件测试这个专门的学科。

　　三、软件测试的目的是什么？

　　在谈到软件测试目的时，许多人都引用grenford j. myers在《the art of software testing》一书中的观点：

　　1、软件测试是为了发现错误而执行程序的过程；

　　2、测试是为了证明程序有错，而不是证明程序无错误；

　　3、一个好的测试用例是在于它能发现至今未发现的错误；

　　4、一个成功的测试是发现了至今未发现的错误的测试。

　　这种观点可以提醒人们测试要以查找错误为中心，而不是为了说明软件的正确性，实际上大部分未经过测试软件产品都或多或少的存在着错误。

　　但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目，查找不出错误的测试就是没有价值的，事实并非如此。

　　首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

　　其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。