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