没有合适的资源?快使用搜索试试~ 我知道了~
软件项目测试验收方案-草稿 (2).pdf
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 37 浏览量
2022-06-18
13:48:52
上传
评论
收藏 1.72MB PDF 举报
温馨提示
试读
24页
软件项目测试验收方案-草稿 (2).pdf软件项目测试验收方案-草稿 (2).pdf软件项目测试验收方案-草稿 (2).pdf软件项目测试验收方案-草稿 (2).pdf软件项目测试验收方案-草稿 (2).pdf软件项目测试验收方案-草稿 (2).pdf软件项目测试验收方案-草稿 (2).pdf软件项目测试验收方案-草稿 (2).pdf软件项目测试验收方案-草稿 (2).pdf
资源推荐
资源详情
资源评论
项目测试验收方案
一、测试方案
1 概述
软件产品在发布前,如果能够经过全面的测试过程,可以有效
控制软件缺陷最后遗留给用户,从而减少软件质量事故发生的概
率,减少返工修复成本,增加用户对产品的信赖程度,提高产品在
市场上的竞争力,这已经是不争的事实。因此软件测试过程应该与
整个软件开发过程是平行进行的,测试计划应该在需求分析阶段就
已经开始制定了,随后的工作则会伴随着软件开发的过程逐步展
开。
目前的测试主要还是依赖于开发人员自测或测试人员非流程化
测试,这是有一些不妥或需要改进的地方:第一是开发人员和专职测
试人员可能关注点不同,思考问题的侧重点不同,导致开发人员测
试出结果不能覆盖全面;第二开发人员更多的喜欢并乐于研究一些
代码上的东西,让开发人员频繁的做测试会产生抵触情绪,通常会
没有耐心去深入测试下去,或许可能发现不了深入的系统问题;另
外测试人员如果没有建立起测试流程化理念,会导致测试的随意性
和盲目性,对软件的质量也无法做充分的肯定和把控,缺乏流程化
测试,也不利于技术的积累和传递。
测试人员会告诉你他们的主要工作是发现 bug。但我们知道测
试永远不能发现所有的 bug,而且不可能去测试软件质量。许多领
域内专家也极力主张软件测试的目的主要是在于发现软件错误,希
望在软件开发生命周期内尽可能早的发现尽可能多得 bug。这种认
识源于我们没有办法对软件进行完全测试,即对程序的正确性进行
完全证明,但遗憾的是,我们至今还没有使用的技术做到这一点。
包括 E.W.Dijkstra 指出“测试只能证明程序有错, 不能保证程序无
错”。所以,人们认为能够发现程序缺陷的测试是成功的测试,测试
的根本目的就是为了发现尽可能多地缺陷。然而不幸的是,这种对
软件测试过分单一的阐述和解释会带来两个原则性的问题。
首先,尽可能早的发现尽可能多的 bug,会使软件测试成为一
个数字游戏。大量的 bug 数量的统计会意味着软件测试的工作做的
特好?大量的 bug 数量并不一定意味着测试的结果是最重要的关键
问题被越早被发现, 另一个潜在的方面,简单的尽可能早的发现尽
可能多的 bug 将导致貌似 bug 统计数量的爆炸,这是因为许多虚报
或者重复的 bug 也被统计在内了。缺陷表现在许多方面。如果一个
测试这部花费时间对导致 bug 的原因作认真的调查研究,那就有可
能导致对同一个错误根源引起的若干个 bug 作若干个 bug 报告。不
幸的是,许多测试人员(不一定是新手)经常坚信他们越早发现越
多的 bug 可以改善软件质量。请记住,我们并不能测试软件质量!
其次, 当测试工程师集中精力寻找更多的错误,他们往往跳过
一些不容易发现错误的地方或者想当然认为一些地方没有错误,从
而使软件测试覆盖率降低。有证据表明,许多测试人员由于太过专
注于发现重大或者重要的错误,往往忽略过一些极易发现错误的所
谓简单地方。比如,在测试边界条件的时候,测试人员会简单的在
边界条件有效值范围内指定最小值、最大值和中间值来做测试,如
果通过则认为没有问题;但这样则错过了超出边界条件的无效值的
验证。比如,最小值减一(Min-1)和最大值加一(Max+1),这恰
恰是最容易出现错误的地方。
软件测试工程师的角色应体现在质量度量,质量控制和缺陷预
防等方面,遵循应用系统的质量标准,有效的计量和评估系统的功
能,性能和其他属性是否达到或满足质量标准;确保软件开发过程
中,开发流程和处理过程以及职责定义符合软件质量标准要求;通
过开发过程中各个环节的正式检查,程序代码审查以及可测性的检
查等预防缺陷发生;作为客户代表,建立客户档案,准备产品支持
服务数据等。
从长远考虑,测试人员需要很强的软件测试技能和对软件工程
的深刻理解,要知道测试存在于软件开发生命周期的每一个阶段。
测试工作应在软件开发周期的每一个阶段都要展开。软件测试应贯
穿于软件定义与开发的整个期间。因此,需求分析、概要设计、详
细设计程序编码等个阶段所得到的文档,包括需求规格说明、概要
设计规格说明、详细设计规格说明以及源程序,都应当成为软件测
试的对象。测试的目的主要有下列用途 :
质量改进 To improve quality.
应用于关键应用中的计算机和软件系统出现问题的后果是十分
严重的。软件错误将引起巨大的损失。比如软件错误可以导致飞机
失事,火箭失去控制,股市交易中断等。更糟糕的是,比如计算机
2000 年问题,产生于家庭手工作坊式的计算机工具系统差一点导致
现代社会中止在 21 世纪来临的第一天。在嵌入式应用系统中, 软件
质量和可靠性更是生死攸关.
质量意味着产品符合设计的要求规范。正确性是软件质量的最
低要求,正确性是指软件符合特定环境下可运行的要求。调试是软
件测试中的一个重要方法,是程序员定位和修复软件错误的一个过
程。发现和修复错误是程序调试的主要目的。
验证和确认 For Verification & Validation (V&V)
软件质量是客观的,能被精确地度量和比较。质量属性包括功
能性,可用性,安全性,可靠性和可测性等;而价值是主观的,价
值的判断包括满意度,足够好,幸福感,喜好性,憎恶感等。软件
测试的一个重要目的是验证和确认软件质量。测试作为一个度量尺
度,是一个验证和确认软件质量的过程。测试人员对产品质量的评
测主要基于对测试结果的解释,比如软件是否在特定条件下能够正
常工作。软件质量依赖于对软件需求的正确分析和设计以及实现,
测试有助于提高软件的质量,但是提高软件的质量不能依赖于测
试。测试与质量的关系很象在考试中“检查”与“成绩”的关系。
学习好的学生,在考试时通过认真检查能减少因疏忽而造成的答题
错误,从而“提高” 了考试成绩(取得他本来就该得的好成绩)。
而学习差的学生,他原本就不会做题目,无论检查多么细心,也不
能提高成绩。可见,软件的高质量是设计出来的,而不是靠测试修
补出来的。所以,我们不能直接对质量进行测试,但我们可以通过
测试质量相关的因素对软件质量进行度量。
质量因素表现在三个典型方面:功能性,工程性和适应性。这三
个方面的因素可视为软件质量的三维空间。Verification and
Validation
功能性(外在质量)Functionality (exterior quality)
正确性,可靠性,可用性,完整性
工程性(内在质量)Engineering (interior quality)
有效性,可测性,文档化
适应性(未来质量)Adaptability (future quality)
可扩展性,可重用性,可维护性
良好的测试会对所有质量相关的因素做度量。而对于软件质量
维度,则其特殊因素的重要程度因应用不同而不同。对人们生活息
息相关的应用系统尤其强调可靠性和完整性,而可用性和可维护性
则是典型商务应用系统的两个关键因素,一个适时的科学计算程序
则更强调正确性和可靠性。我们的测试,要充分发挥作用,就必须
面向衡量各相关因素,使质量度量成为有形的可见的。
以有效性和正确性验证为目的的软件测试称之为正面测试。即
验证软件是工作的。这种测试缺点在于它只能验证软件在特定用例
情况下能正常工作。有限次数的测试不能确认软件能在各种条件下
都能正常工作,反之,如果有一个测试失败,则足以确认该软件是
不能正常工作。负面测试,指按规范注入错误,旨在破坏软件的正
常工作,以检验软件处理错误的能力。即验证软件是不工作的。一
个好的软件,必须有足够的例外处理能力去接受破坏性测试的考
验。
好的可测的软件设计是能够容易被验证,更新和维护的设计。
由于测试是一项严格的工作,需要花费大量的时间和费用, 可测性
设计,也是软件开发设计规范一个重要的因素。
可靠性评估 For reliability estimation
软件可靠性有着重要的关系,表现在软件的许多方面,主要包
括软件结构以及受制于它的大量测试。基于软件使用操作描述,可
以通过对各种相关输入使用频率进行估计,作为统计抽样的方法得
到软件使用可靠性量化的评估。
软件测试远远没有成熟,它仍然是一门艺术,而不能使它成为
一门成熟的学科。虽然软件测试及其技术在近些年有了飞速发展,
但仍然没有本质上的改善和提高,我们仍然使用与 10 年 20 年前相
同的技术和方法,其中有些仍属于炮制性或启发式的方法而非良好
的工程方法。软件测试的花费的代价可能很昂贵,但没有经过测试
的软件在投入使用后将会带来更大更昂贵的代价付出。 解决软件测
试的问题并不比解决图林的停止问题 Turing halting problem 更容
易。我们甚至不能完全确认即使很小的软件是正确的,也不能完全
确认软件规格描述是正确的。使用没有经过认证的系统来验证某一
程序或系统的正确性,我们当然不能确信这一系统或程序的正确
性。
2 相关术语
黑盒测试:基于软件需求,而不是基于软件内部设计和程序实
现的测试方式。
白盒测试:基于软件内部设计和程序实现的测试方式,重点关
注程序代码逻辑方面。
灰盒测试:灰盒测试是介于白盒测试与黑盒测试之间的一种测
试模模式,重点关注模块接口。
单元测试:主要测试软件模块的源代码。一般由开发人员而非
独立测试人员来执行,因为测试者需要懂得该单元的设计与程序实
现,测试者可能需要编写额外的测试驱动程序。
集成测试:将一些“构件”集成一起时,测试它们能否正常运
行。这里“构件”可以是程序模块、客户机-服务器程序等等。
剩余23页未读,继续阅读
资源评论
不吃鸳鸯锅
- 粉丝: 8244
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功