- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
第7章总结.ppt
3.1基本概念 一、定义:通过自动化测试工具或其他手段,按照我们预定的计划进行自动测试的活动。 二:目的:减轻手工测试的劳动量,从而节约资源(包括人工、物品),提高软件质量。 PS:自动化测试并不是万能的!经济、有效 如:业务流程过于复杂的软件,界面变化频繁的软件。微软对MSN的测试,很多人工测试,自动化测试用的很少。 自动化测试的基本原理 三、工作过程: 四、测试工具 LoadRunner 性能测试工具 QTP和IBM Rational Functional Tester 功能测试工具 1. LoadRunner: 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。 如:测试淘宝1000个用户同时登录 企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。 1)轻松创建虚拟用户 2)创建真实的负载 3)定位性能问题 4)分析结果,精确定位问题所在 2. QTP和IBM Rational Functional Tester: 是功能测试工具,主要帮助测试人员完成软件的功能测试,不能完全取代测试人员的手工操作,但是在某个功能点上,可以帮助测试人员做很多工作。 在测试计划阶段,首先要分析被测应用的特点,决定应该对哪些功能点进行测试,可以考虑细化到具体页面或者具体控件。 如:对购物网站测试,单价已知,测试多个物品价钱总和。 应用在某些界面变化不大的回归测试中。 例如,用户界面以前要求输入电话号码,现在变为提供一个可视的电话键盘,使用鼠标点击数字来模拟使用真实的电话。 虽然通过两种界面向被测试的代码传递的都是相同的数据,但是因为没有了提供输入电话号码的地方,自动化测试可能就会中止。 3.2 自动化测试的基本理论 一、需要考虑如下几个主要问题: 1.同手工测试相比,只运行一次的自动化 测试要多付出多少代价? 2.自动化测试的生命周期是有限的。那么,这类测试是否迟早要终止?什么事件将会导致测试中止? 3.在整个生命周期内,这次测试能捕获到新bug的可能性会有多大?这些难以预计的收益能够使自动化测试的成本得到补偿吗? 二、自动化测试的成本 创建一次自动化的测试所花费的时间要比一次手工测试所花费的时间多得多。 介绍如下几种(费用由高至低): 1通过图形用户界面来测试产品;需要写驱动脚本 2使用GUI捕捉/回放工具来跟踪测试与产品之间的交互,同时建立脚本; 3测试的是一个编译器;编写测试程序使编译器进行编译 PS:还要考虑测试时间、Bug的多少等问题。 三、自动化测试的生命周期 四、自动化测试的特点 可以对程序的新版本自动执行回归测试; 可以执行手工测试困难或不可能实现的测试; 更好地利用资源;(加班测试,如回放) 测试具有一致性和可重复性 测试的可重用性; 更快地将软件推向市场; 增加软件信任度 手工测试与自动化测试的比较 五、自动化测试的局限性 下列情况下,自动化测试不能取代手工测试: 测试很少进行; 软件不稳定; 软件升级时,用户界面和功能频繁变化,修改的开销较大。而手工测试可很快发现故障。 结果很容易通过人验证的测试; 如彩色模式的合适程度 屏幕轮廓的直观效果 是否能否正确播放声音。 涉及物理交互的测试; 在读卡机上划卡 断开物理连接 开关电源 手工测试比自动化测试发现的故障多 自动化:回归、重复、正确性验证 15% 手工:85% 自动化测试不能提高测试的有效性,只能提高效率。 自动化测试不具有想象力,不能处理意外。 二、被测试代码的变化所带来的影响。 主要考虑这样一些问题: 1.就给定的结构而言,代码的变化将会产生什么样的影响? 2.什么样的变化具有测试价值? 假设一些功能代码发生了变化,如图7-3中灰色图形所示: 这种变化极有可能会导致调用功能代码的测试中止。因此,如果希望使用自动化测试的方法在发生变化的功能代码(feature code)中找到bug,就必须终止原有测试。如果测试的成本很高,这样做是很不经济的。 为了使原有的测试行为仍然能够保留,通常采用的做法是更改支撑代码(support code)以便能够支持其他功能代码的变动。请看图7-4: 三、支撑代码的变化对测试的影响 主要从以下两方面来考虑这个问题: 代码的变化有多少?这些变化会引入多少bug?
文档评论(0)