工具_测试工作指导.docVIP

六.系统测试计划 6.1测试测试组 对项目测试作项目总结，为日后的工作提供经验和教训 6.1.2好的测试人员应具备的素质 沟通能力——既要和开发人员，又要和客户交流 技术能力——有几年编程经验的测试工程师能在测试领域的多方面发挥潜力 自信心——开发人员可能会指责测试人员测错了，但测试者必须自信自己的观点。 外交能力——当告诉开发者他出错时，适当的外交手法有助维护和开发人员的协作关系 强的记忆力——因为许多新发现的问题其实和我们已经发现的问题相差无几。 耐心——识别和分析一个错误也可能要大量时间，坐不住的人是无法完成这些工作的。 怀疑精神——开发者会尽最大努力将所有错误解释过去。测式者必须听每个人的说明，但他 必须保持怀疑直到他自己看过以后。 自我督促——测试工作只有自我督促才能使自己每天正常的工作，学到更多知识。 洞察力——好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的 质量追求，对细节的关注能力。 6.1.3测试人员的培训 对新加入测试组的同事进行培训，使他们了解到整个系统的架构，测试在项目中的作用，使他们了解测试的工作流程、工作规范、并介绍各种经验。基本教会他们在测试中常用软件和操作系统等的使用，培训要基本能支持他们投入到正常的测试工作中去。 6.2系统测试技术 6.2.1测试的重要性 软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场危机，软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况，那就是系统中有错误，正是这些错误导致了系统开发在成本、进度和质量上的失控。有错是系统的属性，而且是无法改变的，因为系统是由人来完成的，人做的工作都不会是完美无缺的,给系统带来错误的原因很多，具体地说，主要有如下几点： 交流不够、交流上有误解或者根本不进行交流 系统复杂性 程序设计错误 需求变化 时间压力 代码文档贫乏 软件开发工具 事实上，对于系统来讲，不论采用什么技术和什么方法，系统中仍然会有错。采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是不可能完全杜绝系统中的错误，这些引入的错误需要测试来找出，系统中的错误密度也需要测试来进行估计。 测试是所有工程学科的基本组成单元，是系统开发的重要部分。自有程序设计的那天起测试就一直伴随着。统计表明，在典型的系统开发项目中，系统测试工作量往往占系统开发总工作量的40％以上。而在系统开发的总成本中，用在测试上的开销要占30％到50％。因此，测试对于系统生产来说是必需的。 6.2.2系统测试的目标 测试目标作了如下的归纳： 测试是程序的执行过程，目的在于发现错误； 一个好的测试用例在于能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。 换言之，测试的目的是： 想以最少的时间和人力，系统地找出系统中潜在的各种错误和缺陷。如果我们成功地实施了测试 我们就能够发现系统中的错误。 测试的附带收获是，它能够证明系统的功能和性能与需求说明相符合。 实施测试收集到的测试结果数据为可靠性分析提供了依据。 测试不能表明系统中不存在错误，它只能说明系统中存在错误。 6.2.3系统测试的原则 应当把“尽早地和不断地进行系统测试”作为系统开发者的座右铭。 程序员不应测试自己设计的程序。 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。 测试用例的设计不仅要有合理的输入数据，还要有不合理的输入数据。 除了检查程序是否做完了应做的事之外，还要检查它是否做了不应做的事。 经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。 6.2.4系统测试信息流 系统配置：系统需求规格说明、系统设计规格说明、源代码等； 测试配置：测试计划、测试用例、测试程序等； 测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及 驱动测试的测试数据库等等。 测试结果分析：比较实测结果与预期结果，评价错误是否发生。 排错(调试)：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改 相关的文档。 修正后的文档再测试：直到通过测试为止。 通过收集和分析测试结果数据，对系统建立可靠性模型 利用可靠性分析，评价系统质量： 系统的质量和可靠性达到可以接受的程度； 所做的测试不足以发现严重的错误； 如果测试发现不了错误，可肯定，测试配置考虑得不够充分，错误仍潜伏在系统中。 6.3系统测试的过程 单元测试—集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地 实现了规定的功能。 组装测试—把已测试过的模块组装起来，主要对与设计相关的系统体系结构的构造进行测试。 确认测试—是要检查已