- 1、本文档共44页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
ch2—软件测试基本概念—stmt—2014
软件测试方法和技术
第2章 软件测试的基本概念
第1章回顾
什么是软件测试
软件测试的正反两面性
验证软件
发现缺陷
VV
软件测试和开发的关系
TDD
第2章 软件测试的基本概念
2.1 软件缺陷
2.2 软件测试的分类
2.3 静态测试与动态测试
2.5 黑盒测试与白盒测试
2.6 软件测试级别
2.7 软件测试计划与用例
2.8 专业测试人员的责任和要求
缺陷是质量的对立面
要了解什么是缺陷(defect),就必须清楚“质量(Quality)”概念,因为缺陷是相对质量而存在的,违背了质量、违背了客户的意愿,不能满足客户的要求,就会引起缺陷或产生缺陷
什么是 Bug?
2.1.2 软件缺陷的定义
Any problem/disfigurement/limitation in product design development
Feature or function can’t work
Unreasonable design
Partly realization in function
Data error
Run error
Limitation in features
Difference between actual results and expected results
Unfriendly UI, Low performance
Others
任何程序、系统中的问题,和产品设计书的不一致性,不能满足用户的需求
缺点(defect) 偏差 (variance)
谬误(fault) 失败 (failure)
问题(problem) 矛盾(inconsistency)
错误(error ) 毛病 (incident )
异常(anomy)
缺陷 – Defect, Bug
软件缺陷的现象
功能、特性没有实现或部分实现
设计不合理,存在缺陷
实际结果和预期结果不一致
运行出错,包括运行中断、系统崩溃、界面混乱
数据结果不正确、精度不够
用户不能接受的其他问题,如存取时间过长、界面不美观
软件缺陷的产生
技术问题
算法错误,语法错误,计算和精度问题,接口参数传递不匹配
团队工作
沟通不充分,误解
软件本身
文档错误、用户使用场合(user scenario),
时间上不协调、或不一致性所带来的问题
系统的自我恢复或数据的异地备份、灾难性恢复等问题
软件缺陷构成
软件缺陷在不同阶段的分布
在真正的程序测试之前,通过审查、评审会可以发现更多的缺陷。
规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会逐步发现,而不能在需求分析一个阶段发现
缺陷成本
2.3 软件测试的分类
不同的分类
按测试的对象或范围分类,如单元测试、文档测试、系统测试等)
按测试目的分类,如功能测试、回归测试、性能测试、可靠性测试、安全性测试和兼容性测试等
根据测试过程中被测软件是否被执行,分为静态测试和动态测试
根据是否针对系统的内部结构和具体实现算法来完成测试,可分为白盒测试和黑盒测试
2.3 静态测试和动态测试
2.3.1 产品评审
2.3.2 静态分析
2.3.3 验证和确认
静态的和动态的
运行程序
静态测试和动态测试
将需求和设计的评审纳入测试的范畴,可看作是广义测试
静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等
静态分析的查错和分析功能是其他方法所不能替代的,可以采用人工检测和计算机辅助静态分析手段进行检测,但越来越多地采用工具进行自动化分析
动态测试是通过真正运行程序发现错误,通过观察代码运行过程,来获取系统信息,对系统行为进行验证。
2.3.1 产品评审
通过软件评审,可以更早地发现需求工程、软件设计等各个方面的问题,大大减少大量的后期返工,将质量成本从昂贵的后期返工转化为前期的缺陷发现。
评审是对软件元素或者项目状态的一种评估手段,以确定其是否与计划的结果保持一致,并使其得到改进。检验工作产品是否正确地满足了以往工作产品中建立的规范。
评审的形式/方法
互为评审 (Peer review)
轮查 (Pass-round)
走查 (walk-through)
会议评审 (Inspection)
评审分类
管理评审
技术评审
文档评审
流程评审
需求和设计审查
测试人员参与产品需求分析和系统设计,认真阅读有关文档,真正理解客户的需求和技术上的设计,检查需求说明书对产品描述的准确性、一致性等,检查系统设计的合理性和可测试性等
2.3.2 静态分析
人工检测:人工检测偏重于编码风格、质量的检验,对设计、代码进行分析,有效地发现逻辑设计和编码错误。
文档评论(0)