一种基于统一建模语言系统测试方法.docVIP

一种基于统一建模语言系统测试方法.doc

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
一种基于统一建模语言系统测试方法

一种基于统一建模语言的系统测试方法   摘要 本文描述了一种可以用于改进应用软件确定性的,能自动生成和执行的系统测试方法。该测试可以通过统一建模语言编制的应用动作模块自动生成,而后再适配的测试执行环境中执行。本文用在绘图界面中与用户互动的实际应用方法描述了我们的测试方法,从而讨论了有关商业用户界面或捕捉-释放工具的测试执行状态。在本文中,我们按步骤展示了测试途径:第一步,测试设计者如何手动注释UML模块,这个过程也可以按照测试要求半自动地从现存实力文件中导入;第二步,测试生成工具自动创建一套文本测试程序(测试案例)或执行测试原本;第三步:测试执行者依靠测试系统用商业用户界面测试工具运行这些程序。   关键词 UML;系统测试方法   中图分类号TP31 文献标识码A 文章编号 1674-6708(2011)48-0212-02   0 引言   系统测试在西门子是一种有明确定义的程序,用以保证功能按要求实现。然而,许多软件中,它还是一个手动的过程。测试设计者典型地导出他们的测试数据,也就是基于许多原始资料的必需的系统输入和预期的输出信息,包括文本使用规范和商业程序标准。然后创建了由一系列单独步骤组成的测试程序,在测试过程中需要测试者依据系统手动操作执行。自动化测试执行环境在任何时候都是很有用的,因此测试者们应该将这些句文测试程序转化为执行测试程序。 我们的测试方法目的是使测试设计、生成和执行尽可能的自动化和程序化,以便编制一个更加系统、有效的系统测试程序。我们的方法包括以下几个方面:   1)模拟系统行为   通过模拟撤销或半自动转化现存文本使用规范为适当的UML模块,我们相信可以改进测试设计阶段的效力。通过可视化捕捉系统和其用户之间的互动流程,可以抽象、演变、传达一种更好、更完整的测试设计。它可以使设计者识别并简单证明一种比原来编写复杂的、使用文本的程序描述更多样化的测试设想。   2)产生测试程序   使用以上外在可视的系统行为模块,能够更容易地手动或自动创建出一系列的测试程序,使得测试推导更为系统有效。我们的测试方法的另一优点是引入了有关系统功能的测试充分性或测试覆盖的概念。测试者现在还可以更好的量化他们的测试效果。   3)执行测试程序   程序自身的自动测试执行有助于减轻错误倾向和繁重的回归测试工作,然而在我们的测试手段中,测试步骤可能潜在的导致创建大量执行测试文件。本测试方法最主要的优点是它可以鼓励测试执行者在初始用户界面测试捕捉设计和创建测试文件或测试片段模块程序,这些程序可以促进再次使用原始文件和简化文件维护。一旦被捕捉和参数化,这些片段模块就会在测试生成过程中组合成完整的测试文件。   1 UML中的模型系统行为   在这一部分中,我们通过模拟系统的动态行为描述了UML应用案例和行为图表的应用。为了更好的传达本方法的观念,我们利用图例进行了说明。   1.1 使用案例规范   当使用案例图表可以有效地表示各种独立案例之间的相互作用时,使用案例规范和行为图表使测试设计者能够分别使用文本和可视化捕捉系统和用户之间的控制交流。   使用案例规范以表格的形式得以详细描述,并且提供用户刺激和系统测试步骤中的响应的描述文本。这些在成功设想和其他过程中都有描述,本文还提到了相关使用案例的命名问题,详细地使用案例应该贯穿测试的全过程。   当文本使用案例文件创建特别是使用文件模版时直接运行,当涉及到复杂案例和测试设想时这些文件很快就变得难以控制,这些复杂案例和设想包括多元的和嵌套的选择流程。随着复杂性的提高,测试设计者可能会在从这些文件中提取他的测试程序过程中忽略重要的测试设想。一种更简明的抽象、演变和传达的测试设想通过行为图表得以描述,因而,我们提供UML编辑工具帮助用户快速将现存文档转化为UML行为图表。   1.2 行为图表   行为图表是可以通过划分“泳道”,很好的反应用户输入和系统响应。第一对泳道显示了典型的测试设想、交互作用流程或适当的路径,其余的泳道表示了其他供选的通道。   下面描述的测试要求代表了大量的在整个过程中产生的和功能存储界面获得的首先影响测试生成过程的图表注释,还有许多可选择的和有代表性的没有出现在图表的我们也一一标出。   2 相关研究   使用UML自动生成测试案例的研究在近几年已经广泛地开展,许多文献讨论了与面向个人和辅助系统成员的自动测试程序的生成和执行相关的程序,这些程序更适用于单位和整体测试。   我们的方法中列出了更多的讨论UML应用于系统测试的文献和集中研究基于图形用户界面(GUI)测试程序生成的文献,包括西门子公司研究的早期的缺少目的性的非正式的操作指南等。   例如Beer等描述了面向GUI测试的整体设计和自动测试案例生成环境(

文档评论(0)

189****7685 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档