完整版7 软件静态测试

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

2. 评审
9
一、评审
评审是对软件元素或项 目状态进行评估的活动, 用以确定与预期结果之 间的偏差和相应的改进 意见,一般评审包括培 训评审、预备评审、同 行评审。在本节中我们 重点关心同行评审。
软件元素包括
? 软件开发管理人员文档 软件需求、软件项目计划
? 软件开发人员文档 用例、软件设计、软件规约、 数据流图、数据库和文件设计、 接口、安全规约、 GUI设计
? 测试人员文档 测试计划、测试用例、测试环 境规约、测试数据设计、测试 工具的安装和操作
? 管理员文档 安装指南、操作 /管理指南
? 最终用户文档 用户指南、帮助界面、培训手 册
同行评审
是由开发软件产品作者以外的其他人检查工作产品,以发现缺陷并寻找改 进的机会
– 评审方法是评审参与者通常采用一行一行仔细阅读被评审对象的形式发现 被测对象中的缺陷
评审类型
桌面评审 临时评审
走查
审查
经验表明,通过包括代码审查、桌面 检查、代码走查、审查和技术评审在 内的静态测试能够有效地发现30%70% 的逻辑设计和编码错误,而且
– 评审的时间点一般设在工作产品到达了一个完成的里程碑并即将进入下一 个开发阶段时
同行评审
评审过程
? 正式评审的阶段
计划 预备会 阶段 阶段
个人 准备 阶段
评审 会议 阶段
返工 阶段
跟踪 结果
阶段
计划阶段
? 定义评审标准 ? 选择人员 ? 分配角色 ? 为更加正式的评审类型(比如审查)制定入口和
静态测试的主要内容:
手工检查 (评审)
对软件工作产品(包括代码)进行测试的一种方式。可 以完全以人工的方式进行,也可以引入工具的支持来运 行。可以对软件工作产品进行评审,包括需求规格说明、 设计规格说明、代码、测试计划、测试规格说明、测试 用例、测试脚本、用户指南或web 页面等。
静态分析
主要检查代码和设计的一致性、代码对标准的遵循、代码的 可读性、代码的逻辑表达正确性,代码的合理性
出口准则 ? 选择需要进行评审的文档的内容 ? 核对入口准则(针对更正式的评审类型)
预备会阶段( Kick off )
? 分发文档 ? 向评审参与者解释评审的目标、过程和文档
个人准备阶段
? 先行评审文档,为评审会议做准备 ? 标注可能的缺陷、问题和建议。
评审会议阶段
? 讨论和记录,并留下文档化的结果或会议纪要( 针对更正式的评审类型)

无标准流程
每个阶段需要确 定的内容
审查原则
会议期间读者 的角色由评审 组长代替
发现问题的数 量是审查的 2/3
过程由作者主持
只有一位评审 专家
比审查发现的缺陷 发现问题较少 数量要少一半
团队同时帮忙 发现问题较少
场景描述
程序员A请项目经理与其一起评审自己的代码
程序员A请程序员B帮忙Review一下他写的代码
功能测试及工具
焦忭忭 2017.3
第七讲 静态测试
?静态测试概论 ?评审 ?需求规格说明书的测试 ?代码检查 ?静态分析
2
1. 静态测试概论
3
静态的和动态的
主持人 内审员 作者
技术专业人员
列席人员
记录员
用户代表
不正式
轮查
互审
走读
正式
审查会议
运行程序
动态测试
? 动态测试是通过真正运行程序发现错误,通过观察代码运 行过程,来获取系统信息,对系统行为进行验证。狭义测 试
典型的正式评审主要有下面几种角色:
? 经理:决定是否需要进行评审,在项目计划中分派时间,判断是否 已达到评审的目标。
? 主持人:主持文档或文档集的评审活动,包括策划评审、召开会议 和会议后的跟踪。假如需要,主持人可能还需要进行不同观点之间 的协调。主持人通常是评审成功与否的关键。
? 作者:待评审文档的作者或主要责任人。 ? 评审员:具有专门技术或业务背景的人员(也称为检查员(
一种“轻型审
查” ,可采用审 查的指导方针 和流程
是产品的作者向一 指除作者以外 组同事说明该产品, 只有一位评审 希望获得他们的意 专家对工作产 见以满足自己的需 品进行检查 要
请团队内其他 同事帮忙,在 短时间内解决 一些问题,最 不正式
审查流程
没有审查那么 没有标准的流程可 无标准流程
正式和严格
checker)或审查员(inspector)),他们在必要的准备后,标识 和描述被评审产品存在的问题(如缺陷)。所选择的评审员应该在 评审过程中代表不同的观点和角色,并且应该参与各种评审会议。 ? 记录员:记录所有的事件、问题,以及在会议过程中识别的未解决 的问题。
评审类型
同行评审一般包括审查、小组评审、 走查、桌面评审、临时评审五种类型。
同行评审越正式,发现的缺陷越多, 但评审越正式,花费成本越高
这些同行评审类型的区别在于正式程 度,可以从图示中看到。
被评审对象越重要或者风险越高,采 用的评审方式就越正式
正式程度高
审查
小组审查 走查 桌面评审
正式程度低
临时评审
审查
小组评审
走查
桌面评审 临时评审
非作者等专家在 内的针对特定对 象进行检查以发 现缺陷的过程, 最正式
? 标注缺陷、提出处理缺陷的建议、对缺陷作出决 策。
? 在任何形式的会议期间或跟踪任何类型的电子通 信期间检查 /评价和记录问题
返工阶段
? 修改发现的缺陷(通常由作者来进行) ? 记录缺陷更新的状态(在正式评审中)
跟踪结果阶段
? 检查缺陷是否已得到解决 ? 收集度量数据 ? 核对出口准则(针对更正式的评审类型)
? 将需求和设计的评审纳入测试的范畴,可看作是广义测试
静态测试
Βιβλιοθήκη Baidu
静静态态测测试概 念试概念
通常是指不执行程序而寻找代码或其他的项目文档中可 能存在的错误或评估程序代码的过程。
静试静试态对态对测象测象试测
各种与软件相关的有必要进行测试的产物,比如各类文 档、源代码等。
静态测试的特点:
不必动态地运行程序。 可以人工进行,充分发挥人的思维优势。 不需要特别的条件,容易展开。 对测试人员要求比较高。
系统关键模块设计已经完成,为了降低关键模块设计的风险,设计 人员组织了一次会议,并邀请了测试人员、其他开发人员、需求人 员参加会议,在会上设计人员演示并详细讲解了该模块的设计,从 中他也得到了与会人员广泛的意见和建议 项目经理计划对软件质量进行审查,他在项目计划中该活动安排了 相应的资源和时间,并指定了特定的人员负责此事。接下来,负责 人根据事先制定的评审标准,核对了相关资料并通知了相应人员进 行会前准备。
相关文档
最新文档