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

项目测试验收方案一、测试方案1概述软件产品在发布前，如果能够经过全面的测试过程，可以有效控制软件缺陷最后遗留给用户，从而减少软件质量事故发生的概率，减少返工修复成本，增加用户对产品的信赖程度，提高产品在市场上的竞争力，这已经是不争的事实。因此软件测试过程应该与整个软件开发过程是平行进行的，测试计划应该在需求分析阶段就已经开始制定了，随后的工作则会伴随着软件开发的过程逐步展开。目前的测试主要还是依赖于开发人员自测或测试人员非流程化测试，这是有一些不妥或需要改进的地方:第一是开发人员和专职测试人员可能关注点不同，思考问题的侧重点不同，导致开发人员测试出结果不能覆盖全面；第二开发人员更多的喜欢并乐于研究一些代码上的东西，让开发人员频繁的做测试会产生抵触情绪，通常会没有耐心去深入测试下去，或许可能发现不了深入的系统问题；另外测试人员如果没有建立起测试流程化理念，会导致测试的随意性和盲目性，对软件的质量也无法做充分的肯定和把控，缺乏流程化测试，也不利于技术的积累和传递。测试人员会告诉你他们的主要工作是发现bug。但我们知道测试永远不能发现所有的bug，而且不可能去测试软件质量。许多领域内专家也极力主张软件测试的目的主要是在于发现软件错误，希望在软件开发生命周期内尽可能早的发现尽可能多得bug。这种认识源于我们没有办法对软件进行完全测试，即对程序的正确性进行完全证明，但遗憾的是，我们至今还没有使用的技术做到这一点。包括E.W.Dijkstra指出“测试只能证明程序有错,不能保证程序无错”。所以，人们认为能够发现程序缺陷的测试是成功的测试，测试的根本目的就是为了发现尽可能多地缺陷。然而不幸的是，这种对软件测试过分单一的阐述和解释会带来两个原则性的问题。首先，尽可能早的发现尽可能多的bug，会使软件测试成为一个数字游戏。大量的bug数量的统计会意味着软件测试的工作做的特好？大量的bug数量并不一定意味着测试的结果是最重要的关键问题被越早被发现,另一个潜在的方面，简单的尽可能早的发现尽可能多的bug将导致貌似bug统计数量的爆炸，这是因为许多虚报或者重复的bug也被统计在内了。缺陷表现在许多方面。如果一个测试这部花费时间对导致bug的原因作认真的调查研究，那就有可能导致对同一个错误根源引起的若干个bug作若干个bug报告。不幸的是，许多测试人员（不一定是新手）经常坚信他们越早发现越多的bug可以改善软件质量。请记住，我们并不能测试软件质量！其次,当测试工程师集中精力寻找更多的错误，他们往往跳过一些不容易发现错误的地方或者想当然认为一些地方没有错误，从而使软件测试覆盖率降低。有证据表明，许多测试人员由于太过专注于发现重大或者重要的错误，往往忽略过一些极易发现错误的所谓简单地方。比如，在测试边界条件的时候，测试人员会简单的在边界条件有效值范围内指定最小值、最大值和中间值来做测试，如果通过则认为没有问题；但这样则错过了超出边界条件的无效值的验证。比如，最小值减一（Min-1）和最大值加一（Max+1），这恰恰是最容易出现错误的地方。软件测试工程师的角色应体现在质量度量，质量控制和缺陷预防等方面，遵循应用系统的质量标准，有效的计量和评估系统的功能，性能和其他属性是否达到或满足质量标准；确保软件开发过程中，开发流程和处理过程以及职责定义符合软件质量标准要求；通过开发过程中各个环节的正式检查，程序代码审查以及可测性的检查等预防缺陷发生；作为客户代表，建立客户档案，准备产品支持服务数据等。从长远考虑，测试人员需要很强的软件测试技能和对软件工程的深刻理解，要知道测试存在于软件开发生命周期的每一个阶段。测试工作应在软件开发周期的每一个阶段都要展开。软件测试应贯穿于软件定义与开发的整个期间。因此，需求分析、概要设计、详细设计程序编码等个阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应当成为软件测试的对象。测试的目的主要有下列用途：质量改进Toimprovequality.应用于关键应用中的计算机和软件系统出现问题的后果是十分严重的。软件错误将引起巨大的损失。比如软件错误可以导致飞机失事，火箭失去控制，股市交易中断等。更糟糕的是，比如计算机2000年问题，产生于家庭手工作坊式的计算机工具系统差一点导致现代社会中止在21世纪来临的第一天。在嵌入式应用系统中,软件质量和可靠性更是生死攸关.质量意味着产品符合设计的要求规范。正确性是软件质量的最低要求，正确性是指软件符合特定环境下可运行的要求。调试是软件测试中的一个重要方法，是程序员定位和修复软件错误的一个过程。发现和修复错误是程序调试的主要目的。验证和确认ForVerification&Validation(V&V)软件质量是客观的，能被精确地度量和比较。质量属性包括功能性，可用性，安全性，可靠性和可测性等；而价值是主观的，价值的判断包括满意度，足够好，幸福感，喜好性，憎恶感等。软件测试的一个重要目的是验证和确认软件质量。测试作为一个度量尺度，是一个验证和确认软件质量的过程。测试人员对产品质量的评测主要基于对测试结果的解释，比如软件是否在特定条件下能够正常工作。软件质量依赖于对软件需求的正确分析和设计以及实现,测试有助于提高软件的质量，但是提高软件的质量不能依赖于测试。测试与质量的关系很象在考试中“检查”与“成绩”的关系。学习好的学生，在考试时通过认真检查能减少因疏忽而造成的答题错误，从而“提高”了考试成绩（取得他本来就该得的好成绩）。而学习差的学生，他原本就不会做题目，无论检查多么细心，也不能提高成绩。可见，软件的高质量是设计出来的，而不是靠测试修补出来的。所以，我们不能直接对质量进行测试，但我们可以通过测试质量相关的因素对软件质量进行度量。质量因素表现在三个典型方面：功能性,工程性和适应性。这三个方面的因素可视为软件质量的三维空间。VerificationandValidation功能性（外在质量）Functionality(exteriorquality)正确性，可靠性，可用性，完整性工程性（内在质量）Engineering(interiorquality)有效性，可测性，文档化适应性（未来质量）Adaptability(futurequality)可扩展性，可重用性，可维护性良好的测试会对所有质量相关的因素做度量。而对于软件质量维度，则其特殊因素的重要程度因应用不同而不同。对人们生活息息相关的应用系统尤其强调可靠性和完整性，而可用性和可维护性则是典型商务应用系统的两个关键因素，一个适时的科学计算程序则更强调正确性和可靠性。我们的测试，要充分发挥作用，就必须面向衡量各相关因素，使质量度量成为有形的可见的。以有效性和正确性验证为目的的软件测试称之为正面测试。即验证软件是工作的。这种测试缺点在于它只能验证软件在特定用例情况下能正常工作。有限次数的测试不能确认软件能在各种条件下都能正常工作，反之，如果有一个测试失败，则足以确认该软件是不能正常工作。负面测试，指按规范注入错误，旨在破坏软件的正常工作，以检验软件处理错误的能力。即验证软件是不工作的。一个好的软件，必须有足够的例外处理能力去接受破坏性测试的考验。好的可测的软件设计是能够容易被验证，更新和维护的设计。由于测试是一项严格的工作，需要花费大量的时间和费用，可测性设计，也是软件开发设计规范一个重要的因素。可靠性评估Forreliabilityestimation软件可靠性有着重要的关系，表现在软件的许多方面，主要包括软件结构以及受制于它的大量测试。基于软件使用操作描述，可以通过对各种相关输入使用频率进行估计，作为统计抽样的方法得到软件使用可靠性量化的评估。软件测试远远没有成熟，它仍然是一门艺术，而不能使它成为一门成熟的学科。虽然软件测试及其技术在近些年有了飞速发展，但仍然没有本质上的改善和提高，我们仍然使用与10年20年前相同的技术和方法，其中有些仍属于炮制性或启发式的方法而非良好的工程方法。软件测试的花费的代价可能很昂贵，但没有经过测试的软件在投入使用后将会带来更大更昂贵的代价付出。解决软件测试的问题并不比解决图林的停止问题Turinghaltingproblem更容易。我们甚至不能完全确认即使很小的软件是正确的，也不能完全确认软件规格描述是正确的。使用没有经过认证的系统来验证某一程序或系统的正确性，我们当然不能确信这一系统或程序的正确性。2相关术语黑盒测试：基于软件需求，而不是基于软件内部设计和程序实现的测试方式。白盒测试：基于软件内部设计和程序实现的测试方式，重点关注程序代码逻辑方面。灰盒测试：灰盒测试是介于白盒测试与黑盒测试之间的一种测试模模式，重点关注模块接口。单元测试：主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行，因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外的测试驱动程序。集成测试：将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以是程序模块、客户机－服务器程序等等。系统测试：测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。功能性需求可分系统测试又可为功能测试、性能测试、易用性测试等。一般由独立测试人员执行，通常采用黑盒测试方式或灰盒子测试方法。功能测试：测试软件的功能是否符合功能性需求，测试是据软件需求规格说明书。性能测试：测试软件在各种状况下的性能，如在正常或最大负载下的状况。易用性测试：测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。冒烟测试：是指在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性,冒烟测试通常由测试人员或开发人员完成。回归测试：指错误被修正后或软件在功能、环境发生变化后进行的重新测试，回归测试的重点是保证修改后的bug都得以解决，回归测试的困难在于不好评估或判断修改的bug是否会引起其它问题发生，从而来确定哪些内容应当被重新测试。缺陷（bug）：软件工程中明确规定和定义软件缺陷是指：1.软件没有达到产品说明书表明的功能；2.软件出现了产品说明书中不一致的表现；3.软件功能超出产品说明书的范围；4.软件没有达到用户期望的目标(虽然产品说明书中没有要求)；5.测试员或用户认为软件的易用性差。满足一项以上就可定义为软件存在缺陷。3测试目的本方案是完成全国大中专教材网络采选系统-包2项目测试的指导性文件。本方案给出了对测试需求、测试环境、测试过程及测试结果的总体要求,这也是本测试项目中其他文档编写及结果评价的基础。目的是为判定该系统是否满足招标方规定的功能与性能指标。软件测试的原则:应当把“尽早地不断地进行软件测试“作为软件开发者的座右铭。测试用例应由测试数据和与之对应的预期输出结果这两部分组成。程序员应避免检查自己的程序。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。充分注意测试中的群集现象。严格执行测试计划，排除测试的随意性。应当对每一个测试结果做全面的检查。妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。4测试范围本方案的测试范围含本文档第二部分的所有功能模块，以及和招标方签订的合同中附加的项目需求说明文档等其他项目功能描述文件所涵盖的功能。测试为基于web的系统测试，除了根据需求说明书进行系统功能覆盖测试之外，还需要测试系统在不同用户的浏览器端的显示是否合适，以及从最终用户角度进行安全性和可用性测试，因此需添加连接速度测试以及安全性测试，鉴于测试时间紧迫，将负载测试和压力测试合并为压力测试。优先对比需求功能点与已实现功能的差异；提前关注系统稳定性和并发测试；界面测试以UI设计师设计页面为准；测试时间比较紧，系统测试覆盖范围要以重点功能、新增重点功能为主，常用功能其次，后台非重要功能、界面最次；测试时尽量以用户的使用角度提出合理建议，增加易用性；测试前要考虑部署方法对系统应用的影响；测试期间