- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
1-软件测试基础
功能测试及工具
焦忭忭
2017.3
第一讲 软件测试基础
1.软件缺陷
2.软件测试的发展过程
3.软件测试原则
4.软件测试常用术语
1. 软件缺陷
什么是BUG?
臭名昭著的BUG
迪斯尼的狮子王
爱国者导弹防御系统
配置测试
疲劳测试
千年虫问题
/view/9349.htm
中国铁路订票系统问题
臭名昭著的BUG
兼容测试
性能测试
Add Your Text in here
Add Your Text in here
Defect
Failure
Fault
Incident
Bug
Error
软件缺陷的术语
Add Your Text in here
Add Your Text in here
一般符合下列5个规则之一,就是软件缺陷
软件未实现产品说明书要求的功能
软件出现了产品说明书指明不应该出现的错误
软件实现了产品说明书未提到的功能
软件未实现产品说明书虽未明确提及但应该实现的目标
软件难以理解、不易使用、运行缓慢
软件缺陷的定义
案例
如果按下加法键,没什么反应;
计算结果出错
2. 产品规格说明书还可能规定计算器不会死机,或者停止反应, 如果随意敲键盘导致计算器停止接受输入。
3. 如果使用计算器进行测试,发现除了加、减、乘、除之外还可以求平方根,但是产品规格说明没有提及这一功能模块。
4. 在测试计算器时若发现电池没电会导致计算不正确,而产品说明书是假定电池一直都有电的。
5. 软件测试员如果发现某些地方不对,比如测试员觉得按键太小、“=”键布置的位置不好按、在亮光下看不清显示屏等。
人本身容易犯错误
时间的压力
复杂的代码
复杂的系统架构
技术的革新
复杂的外部系统
程序
文档
为什么会出现软件缺陷?
为什么会出现软件缺陷?
PM:小李,订单模块明天之前编码必须完成,并提交给测试组进行测试。
Programmer:明天?..那好吧,这个模块功能很多,需要编写的代码非常的多。
……
紧接着,他只好埋头苦干,拼命的写着代码。
If intPrice0 Then
receipt = intPrice * 1.0
……
A mistake!
这应该是10,被程序员错误的写成了1.0
调查研究表明:大多数软件缺陷并不是由于编码造成的,导致大多数软件缺陷产生的最大的原因是需求分析阶段,其次是在软件设计阶段
为什么会出现软件缺陷?
各阶段修复成本
2. 软件测试的发展过程
软件测试发展史
60年代以前
软件测试跟“调试”(Debug)关联在一起,由开发人员执行。没有单纯意义上的软件测试,软件测试还没有形成概念。
70年代初期
Bill Hetzel提出软件测试是为了证明程序是正确的,建立一种信心。
70年代末期
Glenford J Myers提出软件测试是为了证明程序是有错误的,《软件测试的艺术》。
80年代
提出了一系列各种复杂而精密的软件开发设计流程和管理方法,例如CMM、CMMI软 件测试,也有了行业标准IEEE/ANSI,V模型。
90年代
手工测试(Manual Test)到测试工具的发展。
2000
软件测试管理工具的大量应用,测试是为了度量和提高被测软件的质量。
现在
敏捷测试、持续集成测试及嵌入式测试
软件测试定义
3. 软件测试的原则
软件测试原则
测试显示缺陷的存在 #1
测试可以显示缺陷的存在,但不能证明系统不存在缺陷。测试可以减少软件中存在未被发现缺陷的可能性,但即使测试没有发现任何缺陷,也不能证明软件或系统是完全正确的。
穷尽测试是不可能的 #2
除了小型项目,进行完全(各种输入和前提条件的组合)的测试是不可能的。通过运用风险分析和不同系统功能的测试优先级,来确定测试的关注点,从而替代穷尽测试。
软件测试原则
测试尽早介入 #3
在软件或系统开发生命周期中,测试活动应该尽可能早的介入,并且应该将关注点放在已经定义的测试目标上。
软件测试原则
缺陷集群性 #4(80-20原则)
版本发布前进行的测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。
杀虫剂悖论 #5
采用同样的测试用例多次重复进行测试,最后将不再能够发现新的缺陷。为了克服这种“杀虫剂悖论”,测试用例需要进行定期评审和修改,同时需要不断增加新的不同的测试用例来测试软件或系统的不同部分,从而发现潜在的更多的缺陷。
软件测试原则
测试活动依赖于测试背景 #6
针对不同的测试背景,进行的测试活动也是不同的。比如,对安全关键的软件进行测试,与对一般的电子商务软件的测试是不一样的。
不存在缺陷(就是有用系统)的谬论 #7
假如系统无法使用,或者系统不能完成客户的需求和期望,发现和修改
文档评论(0)