软件测试收集.docVIP

  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文档。上传文档
查看更多
测试计划制订活动的开始执行如下步骤: 测试用例开发为每个工作版本确定可验证的测试用例集。确定并说明要用于测试的条件测试所需的特定数据预期结果如何实现测试用例的测试过程。测试环境准备 为确保测试执行得以顺利进行所需的测试环境方面的准备活动测试执行创建或生成可复用的测试脚本维护从测试实施工件到相关的测试用例及用例或测试需求的可追踪性注:测试过程的执行方式将依据测试是自动测试还是手工测试而有所不同。 自动测试:执行在实施测试活动中创建的测试脚本。 手工测试:按照在设计测试活动中制定的结构化测试过程来手工执行测试。 测试在测试执行活动中,测试结果要经过复审以确保测试已执行完全,并确保报告的测试结果没有受到非测试对象因素的影响。在此活动中,经过分析的测试结果可以确定预期测试结果与实际测试结果之间存在的细微差异。这些差异表明了测试对象中存在潜在缺陷,应将差异作为变更请求输入跟踪系统,下一步则应采取相应的纠正操作。 在本项目测试步骤管理层、应用开发组用户。在该报告中测试组将给出测试结论及建议。 图 9.4.3软件的持续测试过程 在执行测试时,上图中的过程将颠倒过来,即从单元测试开始。执行集成测试是把单个的、单元测试过的代码组合在一起进行测试,集成测试一旦完成,就会从系统的整体出发,对系统进行测试。系统测试是个多方面的测试,需评估系统的功能,性能及可用性等等。最后是验收测试,是用户运行的测试,用来检查系统是否满足用户的原始目标和需求。 4.3.2验证程序单元设计阶段 在软件开发的程序设计阶段实施单元测试。即在程序员编码之后,代码已经通过编译后进行单元测试。单元测试侧重于核实软件的。测试的目标是核实数据的接受、处理和是否正确,以及是否恰当确保测试对象的功能正常,。利用有效的和无效的数据来执行各个用例、或功能,以核实以下内容在使用有效数据时得到预期的结果 在使用无效数据时显示相应的错误消息或警告消息 各都得到了正确的应用。程序的响应时间、处理速度、精确范围、存储要求以及负荷等性能的满足情况性能评测的目标是核实性能需求是否都已满足。目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能核实用户与软件之间的交互。另外,测试还可确保中的对象按照预期的方式运行,并符合公司或行业的标准性能核实浏览包括窗口与窗口之间、字段与字段之间的浏览,窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准访问方法(Tab 健、鼠标移动、和快捷键)的使用每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。 工具名称 产商 工具版本 功能测试 Robot IBM Rational 2003.06.00 性能测试 Robot IBM Rational 2003.06.00 缺陷管理 ClearQuest IBM Rational 2003.06.00 4.3.5.2通过标准 系统的修复确实使系统缺陷消除; 系统的修复有没有产生新的系统漏洞。 4.3.6验证需求阶段 验收测试部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。实施验收测试计划和设计在此测试中,确定并记录要研究的功能和业务任务,但遵循特定测试用例。测试内容由各测试决定。这种验收测试方法不正式验收测试那样组织有序,而且更为主观。非正式验收测试是由最终用户组织执行的。要测试的功能和特性都是已知的可接性标准是已知的可以发现更多由于主观原因造成的缺陷。 开发组织与最终用户组织的代表一起执行完全由最终用户组织执行,或者由最终用户组织选择人员组成一个客观公正的小组来执行。 测试案例拟定时应同时依需求规格及开发设计文件的内容,说明本测试测试用例执行后的预期结果。 测试案例执行结果如果不符合预期结果要求时,即应判为问题,填写BUG报告单,并交测试负责人确认。 测试案例执行结果如果有需求规格说明书未明确规定,但依信息系统惯例为明显不合理或不便于使用时,亦判为问题,如前项处理。 测试负责人应确认问题并交付改错,如果相关人员对问题的判定有所疑义时,应报请项目经理召开项目会议共同判定。 执行结果被判定有问题的测试用例,其测试结果即为不通过。 4.4.2测试项目通过准则 各测试项目满足下列条件之一时即通过测试工作: 功能性测试用例通过率达到100%。 非功能性测试用例通过率达到95%时。 所有测试案例均执行完毕而未发现异常。 所有测试案例均已执行完成,所有发现的问题均已被解决或列出为系统限制,且留有问题报告。 4.4.3系统测试结束准则 测试项目满足下列条件时,可由项目经理决定是否提早结束测试工作。 (1)非预期性情况 非预期性项目计划终止。 有限的时间与成本无法支持本测试计划执行。

文档评论(0)

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

本账号下所有文档分享可拿50%收益 欢迎分享

1亿VIP精品文档

相关文档