查看: 4573|回复: 15

[转载] 软件测试的問答

[复制链接]
论坛徽章:
1
发表于 2009-10-2 09:12 | 显示全部楼层 |阅读模式
软件测试的理想模式是什么?
Marick:我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效,而其他测试则由独立测试组来进行。因为如果你把所有测试都交给独立测试组,他们不可能有时间把所有测试都做好。所以,最佳的方式是让开发人员承担一定量的测试,独立测试组给予他们支持。独立测试组主要承担整个系统的测试,去寻找开发人员还没有发现的缺陷,如子系统间的交互、运行条件、内存使用等。

如何更有效地开展系统测试呢?让测试人员在项目初期就参与进踪去,让他们看到第一版的系统需求、用户手册和系统原型,在系统实现前就对需求进行捕获和跟踪。在该过程中,他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行,并且在该过程中会发现一些缺陷。大家都知道,这个阶段,问题发现是非常“便宜”的。

这样,系统测试工程师在项目早期就介入,产生测试设计及基本的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计,因为书写完整测试的条件还不成熟,但这却是构建完整测试的基础。
论坛徽章:
1
 楼主| 发表于 2009-10-2 09:13 | 显示全部楼层
测试经理角色定位
Rothman:测试经理服务于两种完全不同的客户:测试工程师和高层管理者。对于测试工程师,测试经理帮助他们开发产品测试策略,积累产品测试经验并在测试组内充分共享。对于高层管理者,测试经理搜集尽可能全面的产品信息,供其就产品是否可以发布进行决策。但是有一点是相同的:无论是对于测试工程师还是高层管理者,测试经理将帮助其定义和校验产品发布标准。

产品发布标准的定义和校验:作为一个测试经理,应该找机会与市场、开发人员商讨产品发布标准,并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望,要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义,就可以通过测试去验证产品在多大程度上满足了客户需求。

对于测试工程师而言有一点非常重要:将测试任务按优先级划分,使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情,所以告诉测试工程师关于“测什么和何时测”是测试经理的一个重要职责。

高层管理者需要充分理解产品发布标准,以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布,该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后,项目组也可以更清楚地了解和认识产品质量。

使用道具 举报

回复
论坛徽章:
1
 楼主| 发表于 2009-10-2 09:13 | 显示全部楼层
测试的基本原则
在设计有效测试用例之前,测试工程师必需理解软件测试的基本原则。这里有一组测试原则:

1、所有的测试都应追溯到用户需求。正如我们所知:软件测试的目标在于揭示错误。而最严重的错误(从用户角度来看)是那些导致程序无法满足需求的错误。

2、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后立即开始。因此,所有测试应该在任何代码被产生前就进行计划和设计。

3、Pareto原则应用于软件测试。简单地讲,Pareto原则暗示着测试发现的错误中的80%很可能起源于程序模块中的20%。当然,问题在于如何孤立这些有疑点的模块并进行彻底的测试。

4、测试应从“小规模”开始,逐步转向“大规模”。最初的测试通常把焦点放在单个程序模块上,进一步测试的焦点则转向在集成的模块簇中寻找错误,最后在整个系统中寻找错误。

5、穷举测试是不可能的。即使是一个大小适度的程序,其路径排列的数量也非常大。因此,在测试中不可能运行路径的每一种组合。然而,充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。

6、为了达到最佳效果,应该由独立的第三方来构造测试。“最佳效果”指最有可能发现错误的测试(测试的主要目标),所以创建系统的软件工程师并不是构造软件测试的最佳人选。

使用道具 举报

回复
论坛徽章:
1
 楼主| 发表于 2009-10-2 09:15 | 显示全部楼层
什么是“好”的测试?
1、一个好的测试发现错误的可能性很高

为了达到这个目标,测试者必需理解软件、并尝试设想软件如何才能失败,例如:在GUI(图形用户界面)中有一种潜在的错误,即错误识别鼠标位置,那么就应该设计一个测试集来验证是否存在鼠标位置识别的错误。

2、一个好的测试并不冗余

测试的时间和资源是有限的,没有必要构造一个与其他测试用例完全相同的测试,每一个测试都应该有不同的用途〔哪怕是细微的差异〕。例如,软件SafeHome中有一个模块被用来识别用户密码以决定是否启动系统,为了测试密码输入的错误,测试者设计了一系列的输入密码。在不同的测试中输入有效与无效密码(4个数字),然而,每一个有效/无效密码将只检测一种不同错误模式,例如一个将8080作为有效密码的系统将不会接受非法密码1234,如果接受1234,将产生错误,另一个测试输入1235,与1234的测试意图相同,因此是冗余的,然而,非法输入8081或8180就有些细微的差异,即对与有效密码相近但并不相同的密码应该进行测试。

3、一个好的测试应该是“最佳品种”

在一组目的相似的测试中,时间和资源的限制可能只影响其某个子集的执行,此时,应该使用最可能找到所有错误的测试。

4、一个好的测试既不会太简单,也不会太复杂

虽然有时会将一组测试组合到一个测试用例中,其副作用可能屏蔽错误,通常每一个测试应该独立执行。

使用道具 举报

回复
论坛徽章:
1
 楼主| 发表于 2009-10-2 09:16 | 显示全部楼层
软件可测试性
理想情况下,软件工程师在设计计算机程序、系统或产品时应该考虑可测试性,这就使得测试工程师能够更容易地设计有效的测试用例。

什么是“可测试性”?软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性,以及在一定的时间和成本前提下,进行测试设计、测试执行的能力。James

Bach这样描述可测试性:软件可测试性就是一个计算机程序能够被测试的容易程度。

以下是一个常见的软件可测试性检查表:

·可操作性-“运行地越好,被测试的效率越高。”

·可观察性-“所看见的,就是所测试的。”

·可控制性-“对软件的控制越好,测试越能够被自动执行与优化。”

·可分解性-“通过控制测试范围,能够更好地分解问题,执行更灵巧的再测试。”

·简单性-“需要测试的内容越少,测试的速度越快。”

·稳定性-“改变越少,对测试的破坏越小。”

·易理解性-“得到的信息越多,进行的测试越灵巧。”

使用道具 举报

回复
论坛徽章:
1
 楼主| 发表于 2009-10-2 09:16 | 显示全部楼层
实时系统测试
很多实时系统的时间依赖性和异步性给测试带来新的困难--时间!测试用例的设计者考虑的不仅是白盒和黑盒测试用例,而且包括事件处理(如中断处理)、数据的时间序列以及处理数据的任务(进程)的并发性。很多情况下,提供的测试数据有时使得实时系统在某状态下可以正常运行,而同样的数据在系统处于不同状态时有时又会导致错误。

另外,实时系统的软件和硬件之间的密切关系也会导致测试问题,软件测试必须考虑硬件故障对软件处理的影响,这种故障很难实时仿真。由于实时系统的特殊性和复杂性,还没有一个完善的综合性的测试用例设计方法,但是,大致可以分为以下四个步骤:

1、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例,并在测试时执行每个任务。任务测试能够发现逻辑和功能错误,但是不能发现时间和行为错误。

2、行为测试。利用CASE工具创建软件模型,就可能仿真实时系统,并按照外部事件的序列检查其行为,这些分析活动可作为创建实时系统时设计测试用例的基础。

3、任务间测试。在隔离了任务内部和系统行为错误以后,测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务,看任务间的同步是否会产生错误。另外,测试通过消息队列和数据存储进行通讯的任务,以发现这些数据存储区区域大小方面的错误。

4、系统测试。集成软件和硬件,并进行大范围的系统测试,以发现软件/硬件接口间的错误。

使用道具 举报

回复
论坛徽章:
1
 楼主| 发表于 2009-10-2 09:18 | 显示全部楼层
单元测试、集成测试、系统测试、验收测试、回归测试
单元测试:单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此,单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

集成测试:集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

系统测试:系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。因此,系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多,主要有功能测试、性能测试、随机测试等等。

验收测试:验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

回归测试:回归测试是在软件维护阶段,对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里,修改的正确性有两重含义:一是所作的修改达到了预定目的,如错误得到改正,能够适应新的运行环境等等;二是不影响软件的其他功能的正确性

使用道具 举报

回复
论坛徽章:
1
 楼主| 发表于 2009-10-2 09:18 | 显示全部楼层
软件测试策略
测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因,应当为软件工程过程定义一个软件测试的模板-我们可以把特定的测试用例方法放置进去的一系列步骤。

人们已经提出了许多软件测试策略,所有这些策略都为如开发人员提供了一个供测试用的模板,而且它们都包含下列的类属特征:

·测试开始于模块层,然后“延伸”到整个基于计算机的系统集合中。

·不同的测试技术适用于不同的时间点。

·测试是由软件的开发人员和(对于大型系统而言)独立的测试组来管理的。

·测试和调试是不同的活动,但是调试必须能够适应任何的测试策略。

软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试,同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南,并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的,所以测试的进度必须是可测量的,而且问题要尽可能早的暴露出来。

使用道具 举报

回复
论坛徽章:
5
ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44ITPUB季度 社区新星
日期:2010-05-17 16:12:542010广州亚运会纪念徽章:足球
日期:2010-11-11 17:57:47ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262012新春纪念徽章
日期:2012-01-04 11:53:29
发表于 2009-10-6 22:19 | 显示全部楼层
哇哦,好长哦,顶。

使用道具 举报

回复
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2009-10-7 14:20 | 显示全部楼层
好多,一个帖子拆了这么多

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表