软件项目测试验收方案-草稿VIP免费

项目测试验收方案一、测试方案1概述软件产品在发布前，如果能够经过全面的测试过程，可以有效控制软件缺陷最后遗留给用户，从而减少软件质量事故发生的概率，减少返工修复成本，增加用户对产品的信赖程度，提高产品在市场上的竞争力，这已经是不争的事实。因此软件测试过程应该与整个软件开发过程是平行进行的，测试计划应该在需求分析阶段就已经开始制定了，随后的工作则会伴随着软件开发的过程逐步展开。目前的测试主要还是依赖于开发人员自测或测试人员非流程化测试，这是有一些不妥或需要改进的地方:第一是开发人员和专职测试人员可能关注点不同，思考问题的侧重点不同，导致开发人员测试出结果不能覆盖全面；第二开发人员更多的喜欢并乐于研究一些代码上的东西，让开发人员频繁的做测试会产生抵触情绪，通常会没有耐心去深入测试下去，或许可能发现不了深入的系统问题；另外测试人员如果没有建立起测试流程化理念，会导致测试的随意性和盲目性，对软件的质量也无法做充分的肯定和把控，缺乏流程化测试，也不利于技术的积累和传递。测试人员会告诉你他们的主要工作是发现bug。但我们知道测试永远不能发现所有的bug,而且不可能去测试软件质量。许多领域内专家也极力主张软件测试的目的主要是在于发现软件错误，希望在软件开发生命周期内尽可能早的发现尽可能多得bug。这种认识源于我们没有办法对软件进行完全测试,即对程序的正确性进行完全证明,但遗憾的是,我们至今还没有使用的技术做到这一点。包括E.W.Dijkstra指出“测试只能证明程序有错，不能保证程序无错”。所以,人们认为能够发现程序缺陷的测试是成功的测试,测试的根本目的就是为了发现尽可能多地缺陷。然而不幸的是，这种对软件测试过分单一的阐述和解释会带来两个原则性的问题。首先，尽可能早的发现尽可能多的bug，会使软件测试成为一个数字游戏。大量的bug数量的统计会意味着软件测试的工作做的特好？大量的bug数量并不一定意味着测试的结果是最重要的关键问题被越早被发现,另一个潜在的方面，简单的尽可能早的发现尽可能多的bug将导致貌似bug统计数量的爆炸，这是因为许多虚报或者重复的bug也被统计在内了。缺陷表现在许多方面。如果一个测试这部花费时间对导致bug的原因作认真的调查研究，那就有可能导致对同一个错误根源引起的若干个bug作若干个bug报告。不幸的是，许多测试人员（不一定是新手）经常坚信他们越早发现越多的bug可以改善软件质量。请记住，我们并不能测试软件质量！其次,当测试工程师集中精力寻找更多的错误，他们往往跳过一些不容易发现错误的地方或者想当然认为一些地方没有错误，从而使软件测试覆盖率降低。有证据表明，许多测试人员由于太过专注于发现重大或者重要的错误，往往忽略过一些极易发现错误的所谓简单地方。比如，在测试边界条件的时候，测试人员会简单的在边界条件有效值范围内指定最小值、最大值和中间值来做测试，如果通过则认为没有问题；但这样则错过了超出边界条件的无效值的验证。比如，最小值减一（Min-1）和最大值加一（Max+1），这恰恰是最容易出现错误的地方。软件测试工程师的角色应体现在质量度量，质量控制和缺陷预防等方面，遵循应用系统的质量标准，有效的计量和评估系统的功能，性能和其他属性是否达到或满足质量标准；确保软件开发过程中，开发流程和处理过程以及职责定义符合软件质量标准要求；通过开发过程中各个环节的正式检查，程序代码审查以及可测性的检查等预防缺陷发生；作为客户代表，建立客户档案，准备产品支持服务数据等。从长远考虑，测试人员需要很强的软件测试技能和对软件工程的深刻理解，要知道测试存在于软件开发生命周期的每一个阶段。测试工作应在软件开发周期的每一个阶段都要展开。软件测试应贯穿于软件定义与开发的整个期间。因此，需求分析、概要设计、详细设计程序编码等个阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应当成为软件测试的对象。测试的目的主要有下列用途：质量改进Toimprovequality.应用于关键应用中的计算机和软件系统出现问题的后果是十分严重的。软件错误将引起巨大的损失...