2019-05-07 21:01:08 weixin_38935235 阅读数 634
  • 软件测试2小时入门

    本课程内容系统、全面、简洁、通俗易懂,通过2个多小时的介绍,让大家对软件测试有个系统的理解和认识,具备基本的软件测试理论基础。 主要内容分为5个部分: 1 软件测试概述,了解测试是什么、测试的对象、原则、流程、方法、模型; 2.常用的黑盒测试用例设计方法及示例演示; 3 常用白盒测试用例设计方法及示例演示; 4.自动化测试优缺点、使用范围及示例‘; 5.测试经验谈。

    2077 人正在学习 去看看 曹红杏

前两部分 1~7章

(第一部分 软件测试综述)

第 1 章 软件测试的背景

本章重点:
(1)软件缺陷如何影响我们的生活
(2)软件缺陷是什么,为什么会出现
(3)软件测试员是谁,他们在做什么

1.1 臭名昭著的软件错误用例研究

1.2 软件缺陷是什么

  • 软件失败的术语
    缺点、故障、失败、异常、事件、偏差、问题、错误、缺陷、矛盾、特殊等。描述软件缺陷的术语很多,完全取决于公司的文化和开发软件的过程。在用词上过多计较是没有意义的。
    本书中,所有软件问题都称为 缺陷(bug)
  • 软件缺陷 的官方定义
    产品说明书:又称说明产品说明,是软件开发小组的一个协定。它对开发的产品进行定义,给出了 产品的细节、如何做、做什么、不能做什么。(详见第 2 章)
    至少满足下列 5 个规则之一才称发生了一个 软件缺陷(software bug)
    (1)软件未实现产品规格说明书要求的功能
    (2)软件出现了产品规格说明书指明不应该出现的错误
    (3)软件实现了产品规格说明书未提到的功能
    (4)软件未实现产品规格说明书虽未明确提及但应该实现的目标
    (5)软件难以理解、不易使用、运行缓慢、或者(从测试员的角度看)最终用户会认为不好
    注: 第(4)条,其目的是为了捕获产品说明书上的遗漏之处。第(5)条,并非所有测试发现的缺陷都要修改,要全面,最重要的是要客观。

1.3 为什么会出现软件缺陷

在这里插入图片描述
(1)最大的原因是 产品说明书。没有写、不够全面且经常更改、整个开发小组没有很好地沟通(随意、易变、沟通不足)
(2)第二大来源是 设计。这是程序员规划软件的过程(随意、易变、沟通不足)
(3)编码。许多看上去是编程错误的软件缺陷实际上是由产品说明书设计方案造成的
(4)其他

1.4 软件缺陷的修复费用

在这里插入图片描述
从开始到计划、编程、测试,到公开使用的过程中,都有可能发现软件缺陷。修复软件缺陷的费用呈 指数级 地增长(即,随着时间的推移,费用呈 十倍 地增长)

1.5 软件测试员究竟做些什么

软件测试员的目标: 尽可能早地找出缺陷,并确保其得以修复

1.6 软件测试员应具备的素质

(1)喜欢探索,喜欢拿到一个新的软件安装在自己的机器上,观看结果
(2)故障排除员,善于发现问题的症结,喜欢解谜
(3)不放过任何蛛丝马迹,喜欢不停地尝试,去发现软件缺陷
(4)具有创造性,创造新的手段来发现缺陷
(5)追求完美,但当知道某些无法企及时,不去苛求,而是尽力接近
(6)判断准确,要决定测试内容、测试时间,以及看到的问题是否是真的缺陷
(7)注重策略和外交
(8)善于说服

第 2 章 软件开发的过程

本章重点:
(1)软件产品构成的主要部分
(2)软件产品中包含哪些人的劳动和技术
(3)软件从构想到最终产品的过程

2.1 产品的组成部分

  • 软件产品需要多少投入
    在这里插入图片描述
  1. 客户需求。 通过问卷调查、收集软件以前的版本反馈信息、收集竞争产品信息、收集期刊评论、收集焦点人群意见等方式
  2. 产品说明书。 综合上述信息以及没有提出但必须要实现的需求,来定义产品是什么、有哪些功能、外观如何
  3. 进度表。 Gantt 图表或项目管理软件,制定进度的目的:了解哪项工作完成了、还有多少工作要做、何时全部完成
  4. 软件设计文档。 设计规划软件如何编写
    常用的软件设计文档清单:
    (1)结构文档: 描述软件整体设计的文档,包括软件所有主要部分的描述,以及相互之间的交互方式。
    (2)数据流图: 表示数据在程序中如何流动的正规示意图。有时被称为泡泡图。
    (3)状态转换图: 把软件分解成基本状态或者条件的另一种正规示意图,表示不同状态间的转换方式。
    (4)流程图: 用图形描述程序逻辑的传统方式。根据流程图编写程序代码是很简单的。
    (5)代码注释: 便于维护代码的程序员轻松掌握代码的内容和执行方式。
  5. 测试文档。
    测试提交清单:
    (1)测试计划: 包括质量目标、资源需求、进度表、任务分配、方法等。
    (2)测试用例: 列举测试的项目,描述验证软件的详细步骤。
    (3)缺陷报告: 描述执行测试用例时找出的问题。
    (4)测试工具和自动测试: (第 15 章)
    (5)度量、统计和总结: 测试过程的汇总。采用图形、表格和报告等形式。
  • 软件产品由哪些部分组成
    产品发布时,不仅仅发布代码,还包含许多支持,这些部分也需要测试。
    在这里插入图片描述

2.2 软件项目成员

  • 项目经理程序经理 或者 监制人员:自始至终驱动整个项目,负责编写产品说明书、管理制度、进行重大决策
  • 体系架构师 或者 系统工程师:产品小组中的技术专家,设计整个系统的体系架构或软件
  • 程序员开发人员 或者 代码制作者:设计、编写并修复软件中的缺陷。与项目经理和设计师密切合作制作软件,与项目经理和测试人员密切合作修复缺陷
  • 测试员质量保证员:找出并报告产品的问题。与开发小组全部成员在开发过程中密切合作
  • 技术作者用户协助专员用户培训专员手册编写员 或者 文案专员:编制软件产品附带的文件和联机文档
  • 配置管理员构建员:把程序员编写的代码及技术作者写的全部文档资料组合在一起,合成为一个软件包

2.3 软件开发生命周期模式

软件产生从最初构思到公开发行的过程称为 软件开发生命周期模式
(1)大爆炸模式
在这里插入图片描述
模式简单,几乎没有计划、进度安排、正规开发过程,几乎没有什么测试。即使有测试,也是在产品已经完工准备交付之前进行,这时测试工作会妨碍交付,测试工作越深入,就会发现越多的软件缺陷,争吵就越多。尽量避免在此模式下进行测试
(2)边写边改模式
在这里插入图片描述
最初只有粗略的想法,接着进行一些简单的设计,然后开始漫长的 来回编写、测试、修改缺陷 的过程。
(3)瀑布模式
在这里插入图片描述
每一个步骤结束时,项目小组组织审查,并决定是否进入下一步。如果项目未准备好进入下一步,就停滞下来直到准备好。
特点:非常强调产品的定义,各步骤是分立的、没有交叉,每一个步骤都 无法回溯
优点:编写代码之前解决所有的未知问题并明确所有细节;测试小组可以制定精确的计划和进度,测试对象非常明确,在分辨是功能还是缺陷上也没有一点问题
缺点:软件产品在仔细考虑和定义时,可能当初制造他的理由已经变了;软件修复费用会指数式增加
(4)螺旋模式
在这里插入图片描述
一开始不必详细定义所有的细节,先定义重要功能,努力实现这些功能,接收客户反馈,然后进入下一阶段。
每一阶段包括 6 个步骤:
(1)确定目标、可选方案和限制条件
(2)明确并化解风险
(3)评估可选方案
(4)当前阶段开发和测试
(5)计划下一阶段
(6)确定进入下一阶段的方法

软件测试员喜欢这个模式,因为他们很早就参与开发过程,有机会尽早发现问题,为项目节省时间和金钱。

第 3 章 软件测试的实质

本章重点:
(1)软件为什么永远不会完美
(2)软件测试为什么不仅仅是技术问题
(3)软件测试员的常用术语

3.1 测试的原则

  • 1. 完全测试程序是不可能的
    主要原因:
    (1)输入量太大。
    (2)输出结果太多。
    (3)软件执行路径太多。
    (4)软件说明书是主观的,从旁观者角度来看是缺陷。

  • 2. 软件测试是有风险的行为
    如果不测试所有的情况,就是选择了冒险。测试量和发现的软件缺陷数量之间的关系:
    在这里插入图片描述

  • 3. 测试无法显示潜伏的软件缺陷
    软件测试工作可以报告软件缺陷存在,但不能报告软件缺陷不存在。

  • 4. 找到的缺陷越多,说明软件缺陷越多
    原因:
    (1)程序员也有心情不好的时候
    (2)由于习惯,程序员往往犯同样的错误
    (3)某些软件缺陷实乃冰山一角。某些软件缺陷可能开始毫无联系,但可能是由一个严重的主要原因造成的

  • 5. 杀虫剂怪事
    软件会有“抗药性”。软件测试员必须不断编写不同的、新的测试程序,对不同的部分进行测试。

  • 6. 并非所有软件缺陷都要修复
    根据第 1 章软件测试员应具备的素质(5),进行良好的判断,搞清楚在什么情况下不能追求完美。
    不需要修复软件缺陷的原因:
    (1)没有足够的时间
    (2)不算真正的软件缺陷
    (3)修复的风险太大。修复一个软件缺陷可能导致其他软件缺陷出现
    (4)不值得修复。不常出现的缺陷、不常用功能中出现的缺陷、用户有办法预防或避免的缺陷等,通常不用修复,这些都归结为商业风险决策。

  • 7. 什么时候才叫缺陷难以说清
    根据第 1 章软件缺陷的定义去判定。
    没有看见就不能说存在缺陷。尚未发现或未观察到的软件缺陷只能说是潜在缺陷。

  • 8. 产品说明书没有最终版本

  • 9. 软件测试员在产品小组中不受欢迎
    保持小组成员和睦的建议:
    (1)早点找出缺陷
    (2)控制情绪
    (3)不要总是报告坏消息

  • 10. 软件测试是一项讲究条理的技术专业

3.2 软件测试的主语和定义

  • 1. 精确和准确
    在这里插入图片描述
    软件测试要精度还是准度很大程度上取决于 产品是什么,最终取决于 开发小组的目标
  • 2. 确认和验证
    确认:保证软件符合产品说明书的过程
    验证:保证软件满足客户要求的过程
  • 3. 质量和可靠性
    可靠性仅仅是质量的一个方面。
    软件产品质量高就是指它能够满足客户要求,客户感到该产品性能卓越,优于其他产品。
    为了确保程序质量高而且可靠性强,软件测试员必须在整个产品开发过程中进行确认和验证。
  • 4. 测试和质量保证
    软件测试员的目标:尽可能早地找出软件缺陷,并确保缺陷的已修复
    软件质量保证人员:创建和执行 改进软件开发过程并防止软件缺陷发生的 标准和方法
    双方的工作是交叉的。

(第二部分 测试基础)

第 4 章 检查产品说明书(静态黑盒测试)

本章重点:
(1)什么是黑盒测试和白盒测试
(2)静态测试和动态测试有何区别
(3)审查产品说明书有哪些高级技术
(4)在详细审查产品说明书时应注意哪些特殊问题

4.1 开始测试

确保最终产品符合客户要求 以及 正确计划测试投入 的唯一方法是 在产品说明书中完整描述产品
编写详细产品说明书的另一好处:软件测试员可以将其作为测试项目的书面材料,据此可以在编写代码之前找出软件缺陷。

4.1.1 黑盒测试和白盒测试

黑盒测试(功能测试、行为测试) 白盒测试
只需知道软件要做什么,无法知道软件是如何运行的 可以访问程序员的代码,并通过检查代码来协助测试

4.1.2 静态测试和动态测试

静态测试 动态测试
只是检查和审核 使用和运行软件

4.1.3 静态黑盒测试、测试产品说明书

测试产品说明书属于静态黑盒测试,因为:
(1)产品说明书是书面文档,而不是可执行程序,因此是静态的;
(2)产品说明书是利用各种资源获得的数据,不必了解怎样和为什么要获取这些信息,以及获取这些信息的途径,只需要知道它们最终构成产品说明书就可以了,因此是黑盒。

4.2 对产品说明书进行高级审查

测试产品说明书的第一步:站在一个高度上进行审查

  1. 假设自己是客户
    (1)了解客户所想(牢记,质量的定义是 “满足客户要求” ),但同时不要忘记软件安全性问题,因为客户可能会假设软件是安全的,但软件测试员不能这样。
    (2)假设什么知识也没有。要搞懂产品说明书的任何细节。
  2. 研究现有的标准和规范
    标准比规范更加严格。标准必须严格遵守,规范可选。
    项目经理 :定义软件要符合何种标准和规范
    软件测试员:观察、检查采用的标准是否正确、有无遗漏;在对产品进行确认和验收时,还要注意是否与标准和规范相抵触,把标准和规范视为产品说明书的一部分。
  3. 审查和测试类似软件
    类似软件有助于设计测试条件和测试方法,还可能暴露意想不到的潜在问题。

4.3 产品说明书的低层次测试技术

4.3.1 产品说明书属性检查清单

(1)完整
(2)准确
(3)精确、不含糊、清晰
(4)一致
(5)贴切
(6)合理
(7)代码无关
(8)可测试性

4.3.2 产品说明书术语检查清单

在这里插入图片描述

第 5 章 戴上眼罩测试软件(动态黑盒测试 / 行为测试)

本章重点:
(1)动态黑盒测试是什么
(2)如何通过等价类划分减少测试用例的数量
(3)如何判别故障边界条件
(4)使用良好数据引入缺陷
(5)如何测试软件状态和状态转换
(6)如何使用重复、压迫和重负的方法找出缺陷
(7)缺陷的一些秘密隐藏之处

5.1 动态黑盒测试:戴上眼罩测试软件

输入数据 ——> 接受输出 ——> 检验结果
动态黑盒测试 又称 行为测试,因为测试的是软件在使用过程中的实际行为。
测试用例:进行测试时使用的特定输入,以及测试软件的过程步骤。选择测试用例是软件测试员最重要的一项任务。

5.2 通过性测试和失效性测试

通过性测试: 确认软件至少能做什么,仅仅运用最简单、最直观的测试用例。在设计和执行测试用例时,总是先进行通过性测试
失效性测试 / 错误强制性测试: 为了破坏软件而设计和执行的测试用例。失效性测试通常不会出现

5.3 等价类划分

一个等价类:指的是 测试相同目标暴露相同软件缺陷 的一组测试用例。
等价类划分的目标:把可能的测试用例集缩减到可控制且仍然足以测试软件的小范围内。要注意,过分划分等价类就有漏掉那些可能暴露软件缺陷的测试的风险。

5.4 数据测试

对数据进行测试,就是在检查用户输入的信息、返回的结果、中间计算结果是否正确。使所有的数据得以测试的技巧:等价类划分,以合理减少测试用例
等价类划分的原则:边界条件、次边界条件、空值、无效数据

  1. 边界条件
    如果软件能在其边界运行,那么正常情况下就应该不会有什么问题。
    (1)边界条件类型
    边界条件是指:软件运行在计划操作界限的边界的情况。
    可能出现的边界条件:
    在这里插入图片描述
    (2)测试边界
    从等价划分中选择测试数据时,从边界条件中选择,往往会找出更多的软件缺陷。
    注意:要测试临近边界的有效数据,同时测试刚超过边界的无效数据。(越界测试)
    在这里插入图片描述
  2. 次边界条件
    次边界条件 / 内部边界条件:在软件内部的最终用户几乎看不到的边界。
    (1)2的幂
    (2)ACSII表
  3. 默认值、空白、空值、零值、无输入
  4. 非法、错误、不正确、垃圾数据
    边界测试、次边界测试、默认值测试等——都属于通过性测试
    垃圾数据——属于失效性测试(这类测试没有实际的规则,只是设法破坏软件,要发挥创造力、会走偏门)

5.5 状态测试

软件状态:软件当前所处的条件或者模式
例如:Windows画图程序中,铅笔绘画状态、喷涂状态等。一旦选中全部选项(工具、菜单、颜色)中的任一项,使软件改变了外观、菜单或是某些操作,就是改变了该软件的状态。

  1. 测试软件的逻辑流程
    运用等价划分技术选择状态和分支。
    (1)建立状态转换图
    状态转换图如果作为产品说明的一部分被提供出来,那么可以用第 4 章检查产品说明书的技术进行静态测试。
    否则,需要创建一个状态图,例如:
    在这里插入图片描述
    状态转换图应包含:
    (1)软件可能进入的每一种独立状态。不确定的也可以视为独立状态,若之后发现不是,随时可以剔除。
    (2)从一种状态进入另一种状态所需的输入和条件。
    (3)进入或者推出某种状态时的设置条件及输出结果。包括显示的菜单按钮、设置的标志位、产生的打印输出、执行的运算等。
    (2)减少要测试的状态及转换的数量
    将大量的可能性减少到可以操作的测试用例集合,有以下 5 种实现方法:
    (1)每种状态至少访问一次。
    (2)测试看起来最常见和最普遍的状态转换。
    (3)测试状态之间最不常用的分支。(容易被忽略)
    (4)测试所有错误状态及其返回值。
    (5)测试随机状态转换。(见第 15 章,自动测试和测试工具)
    (3)怎样进行具体的测试
    确定要测试的 状态 及其 转换 之后,就可以定义 测试用例 了。
    测试 状态 及其 转换 包括检查所有的 状态变量——与进入和退出状态相关的静态条件、信息、值、功能等。
  2. 失败状态测试
    (1)竞争条件和时序错乱
    指的是几个事件恰巧挤在一起,由于软件未预料到运行过程会被中断,以致造成混乱。也就是说,时序发生错乱。
    在这里插入图片描述
    (2)重复、压迫、重负
    重复测试:不断执行同样的操作。不停地启动、关闭同一个程序,反复读写数据等。主要是为了检查是否存在 内存泄漏
    如果一个程序在开始启动时工作状态良好,但是随后变得越来越慢,或者经过一段时间就表现不稳定,原因就可能是存在内存泄漏缺陷,重复测试就可以暴露这些问题。
    压迫测试:使软件在不够理想的条件下运行。观察软件对外部资源的要求和依赖程度。压迫测试就是将支持降到最低限度,目的在于尽可能地限制软件的必要条件。
    重负测试:与压迫测试相反,尽量提供条件任其发挥。让软件处理尽可能大的数据文件。如果软件对打印机或者通信端口之类的外设进行操作,就把可能的都连上。如果测试正在测试的因特网服务器可以处理几千个并发连接,就按它说的做。长时间运行也是重负测试。

5.6 其他黑盒测试技术

1 像笨拙的用户那样做
2 在已经找到软件缺陷的地方再找找
3 像黑客一样考虑问题
4 凭借经验、直觉和预感

第 6 章 检查代码(静态白盒测试 / 结构化分析)

本章重点:
(1)静态白盒测试的好处
(2)各种类型的静态白盒测试综述
(3)编码规范和标准
(4)如何从整体审查代码错误

6.1 静态白盒测试:检查设计和代码

静态白盒测试:不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码,从而找出软件缺陷的过程,有时称为结构化分析
静态白盒测试的原因:(1)尽早发现软件缺陷,以找出 动态黑盒测试 难以发现或隔离的软件缺陷。(2)为黑盒测试员在接受软件进行测试时设计和应用测试用例提供思路。

6.2 正式审查

正式审查 就是进行静态白盒测试的过程。
正式审查的 4 个基本要素:
(1)确定问题。 面向问题而不是面向个人。
(2)遵守规则。
(3)准备。
(4)编写报告。
正式审查的作用:发现问题。除此之外还有一些间接的效果:
(1)交流。正式报告中未包含的信息得以交流
(2)质量。可以使得程序员对自己的代码更加仔细
(3)小组同志化。可以建立测试员和程序员之间的相互尊重,并了解相互的工作需求
(4)解决方案。

6.2.1 同事审查 / 伙伴审查

初次正式审查。(聚集起来讨论代码,但仍然要尽量遵守正式审查的 4 个基本要素)
人员组成:编写代码或设计体系结构的程序员、充当审查者的其他一两个程序员。

6.2.2 走查

比同事审查更正规化的下一步。 同样要遵守正式审查的 4 个基本要素
人员组成:编写代码的程序员、5 人小组或其他程序员和测试员组成的小组。前者向后者做正式陈述。

6.2.3 检验

最正式的审查类型。
人员组成:表述者、检验员
与同事审查和走查不同之处: 表述代码的人不是原来的程序员。这就迫使表述者学习和了解要表述的材料,从而有可能在会议上提出不同的看法和解释。
检验员的职责是从不同的角度(用户、测试员、产品支持人员等)审查代码,还可能被任为会议协调员和会议记录员,以保证检验过程遵守规则及审查有效进行。

6.3 编码标准和规范

有三个重要的原因要坚持标准或规范:
(1)可靠性。 按照某种标准或规范编写的代码比不这样做的代码更加可靠和安全
(2)可读性 / 维护性。 符合设备标准或规范的代码易于阅读、理解和维护
(3)移植性。 如果代码符合设备标准,迁移到另一平台就会轻而易举,甚至完全没有障碍

6.4 通用代码审查清单

(1)数据引用错误。使用未经正确声明和初始化的变量、常量、数组、字符串或记录而导致的软件缺陷。
(2)数据声明错误
(3)计算错误
(4)比较错误
(5)控制流程错误。编程语言中循环等控制结构未按预期方式工作。
(6)子程序参数错误
(7)输入/输出错误。包括文件读取、接受键盘输入或鼠标输入、向打印机或者屏幕等输出设备输出错误。
(8)其他检查

第 7 章 带上 X 光眼镜测试软件(动态白盒测试 / 结构化测试)

本章重点:
(1)什么是动态白盒测试
(2)调试和动态白盒测试之间的区别
(3)单元和集成测试是什么
(4)如何测试底层功能
(5)底层测试所需的数据范围
(6)如何强制软件以某种方式运行
(7)衡量测试完整性的各种方法

7.1 动态白盒测试

动态白盒测试:查看代码功能(做什么)和实现方式(怎么做)得到的信息来确定哪些需要测试、哪些不需要测试、如何展开测试。(软件测试员可以查看并使用代码的内部结构,从而设计和执行测试,了解软件的运作方式有助于选择合适的测试方法。)
动态白盒测试包括以下 4 个部分:
(1)直接测试底层函数、过程、子程序、库
(2)以完整程序的方式从顶层测试软件,根据对软件运行的了解调整测试用例
(3)从软件获得读取变量和状态信息的访问权,以便确定测试与预期结果是否相符。
(4)估算测试覆盖率,调整测试,去掉多余测试用例,补充遗漏的测试用例

7.2 动态白盒测试和调试

在这里插入图片描述
都包括处理软件缺陷和查看代码,但 目标 不同。
动态测试的目标: 寻找软件测试
调试的目标: 修复缺陷
但他们在隔离软件缺陷的位置和原因上有交叉。

7.3 分段测试

7.3.1 单元测试和集成测试

代码分段构建和测试,最后合并在一起形成更大的部分,形成产品。
在这里插入图片描述

  • 在底层进行的测试称为单元测试模块测试
  • 对模块间的集成进行的测试称为集成测试
  • 最后对整个产品(至少是产品的主要部分)进行的测试称为系统测试
  • 自底向上测试:需要编写测试驱动模块来代替上层模块,调用正在测试的模块。测试驱动模块向处于测试的模块发送测试用例数据、接受返回结果、验证结果是否正确
  • 自顶向下测试:编写桩模块来代替下层模块。

7.3.2 单元测试示例

在这里插入图片描述
(1)首先确定此模块属于程序中的底层模块,可以由其他模块调用,但自己不能调用其他模块。所以需要编写一个驱动模块
(2)分析说明书,确定应该采用黑盒测试用例
(3)运用等价类划分法减少测试用例集合
(4)研究代码看函数是如何实现的,利用白盒测试知识增减测试用例,其实是根据程序内部的信息对等价类划分的进一步提炼

7.4 数据覆盖

查看代码决定如何调整测试用例合理的方法是,把软件分成数据状态(或程序流程)。
**数据:**包括变量、常量、数组、数据结构、键盘和鼠标的输入、文件、屏幕输入输出,以及调制解调器、网络等设备的输入输出。

  • 数据流
    数据流覆盖:是指在软件中完全跟踪一批数据
    黑盒测试只能知道变量开始和结束时候的值,动态白盒测试可以在程序运行期间检查变量的中间值,进而更改测试用例,保证变量取得感兴趣的、甚至具有风险的值。
  • 次边界
    进行白盒测试需要仔细检查代码找到次边界条件,并建立能测试它们的测试用例。
  • 公式和等式
    撇开代码中的公式和等式,查看它们使用的变量,在程序中正常输入和输出之外,为其建立测试用例和等价类划分。
  • 错误强制
    ???没懂

7.5 代码覆盖

测试程序的状态以及程序流程。代码覆盖是设法进入和退出每一个模块,执行每一行代码,进入软件每一条逻辑呵呵决策分支。
对于小程序或单独模块,可以利用编译环境的调试器通过单步执行程序查看代码。
但对大多数程序进行代码覆盖要用到代码覆盖分析器。利用代码覆盖分析器可以得到:
(1)测试用例没有覆盖软件的哪些部分
(2)那些测试用例是多余的
(3)为了使覆盖率更好,需要建立什么样的新测试用例
(4)还可以得到软件质量的大致情况。

  • 语句覆盖/代码行覆盖
    保证程序中每一条语句最少执行一次。
    但是,即使全部语句都被执行了,不能说明走遍了软件的所有路径
  • 分支覆盖/路径覆盖
    试图覆盖软件中的所有路径
    大多数代码覆盖率分析器将根据代码分支,分别报告语句覆盖分支覆盖的结果,使软件测试员更加清楚测试结果
  • 条件覆盖
    分支语句的条件考虑在内。
    代码覆盖率分析器可以被设置为将条件考虑在内。如果测试条件覆盖,就能达到分支覆盖,顺便也能达到语句覆盖

在这里插入图片描述

2019-07-02 21:47:13 hhl18 阅读数 473
  • 软件测试2小时入门

    本课程内容系统、全面、简洁、通俗易懂,通过2个多小时的介绍,让大家对软件测试有个系统的理解和认识,具备基本的软件测试理论基础。 主要内容分为5个部分: 1 软件测试概述,了解测试是什么、测试的对象、原则、流程、方法、模型; 2.常用的黑盒测试用例设计方法及示例演示; 3 常用白盒测试用例设计方法及示例演示; 4.自动化测试优缺点、使用范围及示例‘; 5.测试经验谈。

    2077 人正在学习 去看看 曹红杏

      这是一本在软件测试行业,非常经典的一本书了。

       记得,我在2009年,刚做软件测试这行时,读的第一本软件测试参考书,就是Ron Patton写的这本《软件测试》书籍(原书第2版)。

       这本书,介绍了软件测试的起源,软件测试的经典案例,以及,软件测试的流程,各个流程阶段的定义,以及方法。

各种测试方法,以及各个测试方法的应用。

       对于初次接触软件测试行业,或者,想要对软件测试行业有个大概了解的入门者,是本挺不错的参考书。

       这本书,迄今为止,已经过去了十年的时间,我也已从对测试的懵懂不解,到现在掌握测试知识,能够运用整个流程的知识,不止包括对测试的理解及掌握,甚至于,对需求文档的理解,并能提出需求文档的不足之处,在项目的初期,就对产品进行介入,提前进入测试状态,很好的诠释了,越早测试,发现的问题,成本越低;到现在也接触了测试管理工作,从入门,技能掌握,管理,这本书始终陪伴着一路以来的成长。

        以下,对《软件测试》这本经典书籍,做个简短的介绍,以便,让各位读者对这本书,有个大致的了解,以便根据个人情况,对是否阅读这本书的取舍,做个参考。 

       总体而言,这本书其实,对处于在软件测试行业不同阶段的人,一般都还是 普遍适用的。初入行者,可以了解,软件测试这个行业,软件测试的基本概念,软件测试的技术以及方法;对于进阶者,可以了解更高级的白盒测试,单元测试,安全测试,配置测试等测试;对于自动化或性能测试爱好者或者从业者,也可以了解自动化测试及性能测试;对于测试管理者,可以了解对整个城市流程的把控;对于软件测试职位方面的求职者,也有一定的指导意义。

 

内容简介  · · · · · ·

软件测试(原书第2版),ISBN:9787111185260,作者:(美)佩腾(Patton,R.) 著,张小松 等译;张小松译

作者简介  · · · · · ·

Ron Patton具有近20年软件测试和软件质量保证的工作经验,从事过各种产品的软件测试,从关键任务到儿单绘图程序。普先后就职于德州仪器公司、西门子公司和微软公司,担任过质量保证工程师、软件测试经理等职务。他现在是一个独立的软件项目管理和软件质量保证咨询师。

目录  · · · · · ·

第一部分 软件测试综述
第1章 软件测试的背景 3
1.1 臭名昭著的软件错误用例研究 3
1.1.1 迪斯尼的狮子王,1994—1995 3
1.1.2 英特尔奔腾浮点除法缺陷,1994 4
1.1.3 美国航天局火星极地登陆者号探测器,1999 4
1.1.4 爱国者导弹防御系统,1991 5
1.1.5 千年虫问题,大约1974 5
1.1.6 危险的预见,2004 5
1.2 软件缺陷是什么 6
1.2.1 软件失败的术语 6
1.2.2 软件缺陷的官方定义 7
1.3 为什么会出现软件缺陷 8
1.4 软件缺陷的修复费用 9
1.5 软件测试员究竟做些什么 10
1.6 优秀的软件测试员应具备的素质 10
1.7 小结 11
1.8 小测验 12
第2章 软件开发的过程 13
2.1 产品的组成部分 13
2.1.1 软件产品需要多少投入 13
2.1.2 软件产品由哪些部分组成 16
2.2 软件项目成员 17
2.3 软件开发生命周期模式 18
2.3.1 大爆炸模式 18
2.3.2 边写边改模式 19
2.3.3 瀑布模式 20
2.3.4 螺旋模式 21
2.4 小结 22
2.5 小测验 22
第3章 软件测试的实质 23
3.1 测试的原则 23
3.1.1 完全测试程序是不可能的 23
3.1.2 软件测试是有风险的行为 24
3.1.3 测试无法显示潜伏的软件缺陷 24
3.1.4 找到的软件缺陷越多,就说明软件缺陷越多 25
3.1.5 杀虫剂怪事 25
3.1.6 并非所有软件缺陷都要修复 26
3.1.7 什么时候才叫缺陷难以说清 27
3.1.8 产品说明书从没有最终版本 28
3.1.9 软件测试员在产品小组中不受欢迎 28
3.1.10 软件测试是一项讲究条理的技术专业 28
3.2 软件测试的术语和定义 29
3.2.1 精确和准确 29
3.2.2 确认和验证 30
3.2.3 质量和可靠性 30
3.2.4 测试和质量保证(QA) 30
3.3 小结 31
3.4 小测验 31
第二部分 测试基础
第4章 检查产品说明书 35
4.1 开始测试 35
4.1.1 黑盒测试和白盒测试 36
4.1.2 静态测试和动态测试 37
4.1.3 静态黑盒测试、测试产品说明书 37
4.2 对产品说明书进行高级审查 37
4.2.1 假设自己是客户 38
4.2.2 研究现有的标准和规范 38
4.2.3 审查和测试类似软件 39
4.3 产品说明书的低层次测试技术 39
4.3.1 产品说明书属性检查清单 39
4.3.2 产品说明书术语检查清单 40
4.4 小结 40
4.5 小测验 40
第5 章 带上眼罩测试软件 42
5.1 动态黑盒测试:带上眼罩测试软件 42
5.2 通过性测试和失效性测试 43
5.3 等价类划分 44
5.4 数据测试 46
5.4.1 边界条件 47
5.4.2 次边界条件 49
5.4.3 默认、空白、空值、零值和无 51
5.4.4 非法、错误、不正确和垃圾数据 52
5.5 状态测试 53
5.5.1 测试软件的逻辑流程 54
5.5.2 失败状态测试 57
5.6 其他黑盒测试技术 58
5.6.1 像笨拙的用户那样做 58
5.6.2 在已经找到的软件缺陷的地方再找找 59
5.6.3 像黑客一样考虑问题 59
5.6.4 凭借经验、直觉和预感 59
5.7 小结 59
5.8 小测验 60
第6章 检查代码 61
6.1 静态白盒测试:检查设计和代码 61
6.2 正式审查 62
6.2.1 同事审查 63
6.2.2 走查 63
6.2.3 检验 63
6.3 编码标准和规范 64
6.3.1 编程标准和规范示例 64
6.3.2 获取标准 66
6.4 通用代码审查清单 66
6.4.1 数据引用错误 66
6.4.2 数据声明错误 67
6.4.3 计算错误 67
6.4.4 比较错误 67
6.4.5 控制流程错误 68
6.4.6 子程序参数错误 68
6.4.7 输入/输出错误 68
6.4.8 其他检查 68
6.5 小结 69
6.6 小测验 69
第7章 带上X光眼镜测试软件 70
7.1 动态白盒测试 70
7.2 动态白盒测试和调试 71
7.3 分段测试 72
7.3.1 单元测试和集成测试 72
7.3.2 单元测试示例 74
7.4 数据覆盖 75
7.4.1 数据流 76
7.4.2 次边界 76
7.4.3 公式和等式 77
7.4.4 错误强制 77
7.5 代码覆盖 78
7.5.1 程序语句和代码行覆盖 79
7.5.2 分支覆盖 79
7.5.3 条件覆盖 80
7.6 小结 81
7.7 小测验 81
第三部分 运用测试技术
第8章 配置测试 85
8.1 配置测试综述 85
8.1.1 分离配置缺陷 88
8.1.2 计算工作量 89
8.2 执行任务 90
8.2.1 确定所需的硬件类型 90
8.2.2 确定有哪些厂商的硬件、型号和驱动程序可用 90
8.2.3 确定可能的硬件特性、模式和选项 91
8.2.4 将确定后的硬件配置缩减为可控制的范围 91
8.2.5 明确与硬件配置有关的软件唯一特性 92
8.2.6 设计在每一种配置中执行的测试用例 93
8.2.7 在每种配置中执行测试 93
8.2.8 反复测试直到小组对结果满意为止 93
8.3 获得硬件 93
8.4 明确硬件标准 94
8.5 对其他硬件进行配置测试 95
8.6 小结 95
8.7 小测验 95
第9章 兼容性测试 96
9.1 兼容性测试综述 96
9.2 平台和应用程序版本 97
9.2.1 向后和向前兼容 97
9.2.2 测试多个版本的影响 98
9.3 标准和规范 99
9.3.1 高级标准和规范 99
9.3.2 低级标准和规范 100
9.4 数据共享兼容性 100
9.5 小结 102
9.6 小测验 102
第10章 外国语言测试 103
10.1 使文字和图片有意义 103
10.2 翻译问题 104
10.2.1 文本扩展 104
10.2.2 ASCll、DBCS和Unicode 105
10.2.3 热键和快捷键 105
10.2.4 扩展字符 106
10.2.5 字符计算 106
10.2.6 从左向右和从右向左读 107
10.2.7 图形中的文字 107
10.2.8 让文本与代码脱离 107
10.3 本地化问题 108
10.3.1 内容 108
10.3.2 数据格式 109
10.4 配置和兼容性问题 110
10.4.1 国外平台配置 110
10.4.2 数据兼容性 111
10.5 测试量有多大 112
10.6 小结 113
10.7 小测验 113
第11章 易用性测试 114
11.1 用户界面测试 114
11.2 优秀UI由什么构成 115
11.2.1 符合标准和规范 115
11.2.2 直观 116
11.2.3 一致 117
11.2.4 灵活 117
11.2.5 舒适 118
11.2.6 正确 118
11.2.7 实用 119
11.3 为有残疾障碍的人员测试:辅助选项测试 119
11.3.1 法律要求 120
11.3.2 软件中的辅助特性 120
11.4 小结 122
11.5 小测验 122
第12章 测试文档 123
12.1 软件文档的类型 123
12.2 文档测试的重要性 125
12.3 审查文档时要找什么 126
12.4 文档测试的实质 127
12.5 小结 127
12.6 小测验 127
第13章 软件安全性测试 129
13.1 战争游戏—电影 129
13.2 了解动机 130
13.3 威胁模式分析 131
13.4 软件安全是一项功能吗?软件漏洞是一个缺陷吗 134
13.5 了解缓冲区溢出 134
13.6 使用安全的字符串函数 135
13.7 计算机取证 137
13.8 小结 139
13.9 小测验 139
第14章 网站测试 141
14.1 网页基础 141
14.2 黑盒测试 142
14.2.1 文本 143
14.2.2 超级链接 144
14.2.3 图片 145
14.2.4 表单 145
14.2.5 对象和其他各种简单的功能 145
14.3 灰盒测试 146
14.4 白盒测试 147
14.5 配置和兼容性测试 148
14.6 易用性测试 149
14.7 自动化测试简介 151
14.8 小结 151
14.9 小测验 151
第四部分 测试的补充
第15章 自动测试和测试工具 155
15.1 工具和自动化的好处 155
15.2 测试工具 156
15.2.1 查看器和监视器 156
15.2.2 驱动程序 157
15.2.3 桩 158
15.2.4 压力和负载工具 159
15.2.5 干扰注入器和噪声发生器 159
15.2.6 分析工具 160
15.3 软件测试自动化 160
15.3.1 宏录制和回放 161
15.3.2 可编程的宏 162
15.3.3 完全可编程的自动测试工具 163
15.4 随机测试:猴子和大猩猩 164
15.4.1 笨拙的猴子 165
15.4.2 半聪明的猴子 166
15.4.3 聪明的猴子 166
15.5 使用测试工具和自动化的实质 168
15.6 小结 168
15.7 小测验 169
第16章 缺陷轰炸和beta测试 170
16.1 让别人测试你的软件 170
16.2 测试共享 171
16.3 beta测试 172
16.4 外包测试 173
16.5 小结 173
16.6 小测验 174
第五部分 使用测试文档
第17章 计划测试工作 177
17.1 测试计划的目标 177
17.2 测试计划主题 178
17.2.1 高级期望 178
17.2.2 人、地点和事 179
17.2.3 定义 179
17.2.4 团队之间的责任 180
17.2.5 哪些要测试,哪些不要测试 182
17.2.6 测试的阶段 182
17.2.7 测试策略 182
17.2.8 资源需求 183
17.2.9 测试员的任务分配 183
17.2.10 测试进度 183
17.2.11 测试用例 185
17.2.12 软件缺陷报告 185
17.2.13 度量和统计 185
17.2.14 风险和问题 185
17.3 小结 185
17.4 小测验 186
第18章 编写和跟踪测试用例 187
18.1 测试用例计划的目标 187
18.2 测试用例计划综述 188
18.2.1 测试设计 189
18.2.2 测试用例 191
18.2.3 测试程序 192
18.3 测试用例组织和跟踪 194
18.4 小结 195
18.5 小测验 195
第19章 报告发现的问题 197
19.1 设法修复软件缺陷 198
19.2 分离和再现软件缺陷 200
19.3 并非所有软件缺陷生来就是平等的 202
19.4 软件缺陷的生命周期 203
19.5 软件缺陷跟踪系统 205
19.5.1 标准:测试事件报告 205
19.5.2 手工软件缺陷报告和跟踪 206
19.5.3 自动化软件缺陷报告和跟踪 206
19.6 小结 210
19.7 小测验 211
第20章 成效评价 212
20.1 使用软件缺陷跟踪数据库中的信息 212
20.2 在日常测试中使用的度量 213
20.3 常用项目级度量 216
20.4 小结 220
20.5 小测验 221
第六部分 软件测试的未来
第21章 软件质量保证 225
21.1 质量是免费的 225
21.2 工作现场的测试和质量保证 226
21.2.1 软件测试 226
21.2.2 质量保证 227
21.2.3 软件测试团队的其他名称 228
21.3 测试的管理和组织结构 228
21.4 能力成熟度模型(CMM) 230
21.5 IS0 9000 232
21.6 小结 233
21.7 小测验 233
第22章 软件测试员的职业 234
22.1 软件测试员的工作 234
22.2 寻求软件测试职位 235
22.3 获得亲身体验 236
22.4 正规培训机会 237
22.5 网站 237
22.6 专注于软件和软件质量的专业组织 238
22.7 更进一步阅读 238
22.8 小结 239
22.9 小测验 240
附录A 小测验问题解答 241

2016-11-07 19:42:30 bobljm 阅读数 749
  • 软件测试2小时入门

    本课程内容系统、全面、简洁、通俗易懂,通过2个多小时的介绍,让大家对软件测试有个系统的理解和认识,具备基本的软件测试理论基础。 主要内容分为5个部分: 1 软件测试概述,了解测试是什么、测试的对象、原则、流程、方法、模型; 2.常用的黑盒测试用例设计方法及示例演示; 3 常用白盒测试用例设计方法及示例演示; 4.自动化测试优缺点、使用范围及示例‘; 5.测试经验谈。

    2077 人正在学习 去看看 曹红杏

这里写图片描述
从事软件测试工作7年时间,参与了近百项测试项目,期间看了不少书籍和文章,对软件测试工作在理论和实践上都有了一定理解和认识,经历的越多就越觉得对软件测试理解和认识的不够深入。今年8月下旬正好有一些闲暇时间,买了老领导韩柯研究员和同事、好友杜旭涛博士翻译的《软件测试(原书第2版)Software Testing A Craftsman’s Approach(Second Edition)》进行了阅读学习,利用3个星期的时间阅读了一遍,看后感觉很受启发,感到这本书和其它书有着很大的区别:一是讲的内容并不是特别多,但很深入,很专一(只将了功能性测试和结构性测试技术),带有浓厚的研究者的色彩,每个问题都较为深入;二是所举的几个例子,从代码到测试一直贯穿全书,比较直观,易于帮助理解方法。感觉有些相见恨晚。
这本书共五个部分20章。第一部分数学背景共4章,主要包括测试概述、对书中用到的例子进行了较详细的介绍、并介绍了测试人员需要的数学知识,包括用于功能性测试的离散数学和用于结构性测试的图论,第二部分功能性测试,介绍了常用的边界值测试、等价类测试和基于决策表的测试,第三部分结构性测试,介绍了路径测试和数据流测试,第四部分集成与系统测试,介绍了测试层次、集成测试、系统测试和交互测试,第五部分面向对象的测试,介绍了类测试、面向对象的集成测试、GUI测试和面向对象的系统测试。本书是软件测试工程师的入门好教程,也是想成为Craftsman的测试工程师的重要参考材料。另外本书第3版中文版已经出版,第4版英文版也已出版。先以第2版为基础进行一下深入的学习,以弥补非软件测试“科班”出身,没有进行过系统学习的缺憾,如有机会再学习了解第3版和第4版的知识,进行弥补。所谓万变不离其中,基础打好后才能认识的更深,走的更远。
为了便于学习,接下来的学习未按照原书的章节进行,而是按照功能性测试和结构性测试2个分支进行。次序如下所示:
第1章 测试概述
第2章 举例
第3章 测试人员的离散数学
第5章 边界值测试
第6章 等价类测试
第7章 基于决策表的测试
第8章 功能性测试回顾
第12章 测试层次
第13章 集成测试
第14章 系统测试
第15章 交互测试
第16章 面向对象的测试问题
第17章 类测试
第18章 面向对象的集成测试
第19章 GUI测试
第20章 面向对象的系统测试
第4章 测试人员的图论
第9章 路径测试
第10章 数据流测试
第11章 机构性测试回顾
课后系统解答
为了鞭策自己,也为了更好地记录对问题的理解认识,采用博客的方式,争取每周能够完成1-2个章节的学习和整理。

2014-03-03 13:32:41 lihang421 阅读数 641
  • 软件测试2小时入门

    本课程内容系统、全面、简洁、通俗易懂,通过2个多小时的介绍,让大家对软件测试有个系统的理解和认识,具备基本的软件测试理论基础。 主要内容分为5个部分: 1 软件测试概述,了解测试是什么、测试的对象、原则、流程、方法、模型; 2.常用的黑盒测试用例设计方法及示例演示; 3 常用白盒测试用例设计方法及示例演示; 4.自动化测试优缺点、使用范围及示例‘; 5.测试经验谈。

    2077 人正在学习 去看看 曹红杏

全程软件测试(第2版)


全力主张“软件测试贯穿软件开发整个生命周期”的思想及其实践,无论在传统测试中还是在敏捷测试中都具有很好的指导作用。共分12章,以案例为背景,以项目实际运行的全过程为路线图,全面展开软件测试的思维方式、流程、方法和优秀实践。


阅读全文 和小伙伴们一起来吐槽

2006-10-26 09:06:00 chszs 阅读数 3339
  • 软件测试2小时入门

    本课程内容系统、全面、简洁、通俗易懂,通过2个多小时的介绍,让大家对软件测试有个系统的理解和认识,具备基本的软件测试理论基础。 主要内容分为5个部分: 1 软件测试概述,了解测试是什么、测试的对象、原则、流程、方法、模型; 2.常用的黑盒测试用例设计方法及示例演示; 3 常用白盒测试用例设计方法及示例演示; 4.自动化测试优缺点、使用范围及示例‘; 5.测试经验谈。

    2077 人正在学习 去看看 曹红杏

《软件测试的有效方法(第2版)》笔记(一)
第一章 评估软件测试的能力和人员资格


1、软件开发过程:计划P、执行D、检查C、行动A。--PDCA循环
2、软件测试涉及的人员:软件客户、软件用户、开发人员、测试人员、信息技术管理人员、高级组织管理人员、审计员。
3、软件测试的多种角色:制造、创作车间、专业化过程。
4、缺陷:与期望的产品属性存在的差异。分两类:
(1)产品规格书中的缺陷;
(2)与客户/用户的期望不符。
另一种分法:
(1)错误;
(2)遗漏;
(3)超额。
故障:当缺陷引起了运行错误或对客户/用户产生了消极影响时。
××注意:至少90%的缺陷是由于过程问题引起的。
创建软件时产生缺陷的数量主要取决于过程是否完备,完备指过程中可以允许多大的变化。
风险:指不希望的事件发生的可能性。
5、软件测试中的“三步测试法”:
(1)确定当前测试能力的状态;
(2)确定改进目标;
(3)制订测试计划以达到测试目标。
6、质量保证协会QAI确定了与世界级软件测试组织普遍相关的八项标准:
(1)测试计划;
(2)对测试人员的培训;
(3)对测试工作的管理;
(4)用户对测试的满意程度;
(5)测试过程的使用;
(6)有效的测试实践;
(7)应用测试工具;
(8)对测试全过程的质量控制。
如果一组织能达到这八项标准的要求,就可以称他为世界级的软件测试组织。
7、评估现有测试过程的质量
实现过程:
(1)组建评估小组;
(2)完成评估调查问卷;
(3)创建Kiviat图;
(4)评估结果。
软件测试工程师认证CSTE
通用知识主题CBOK:五大类:
(1)一般技能;
(2)测试技巧/方法;
(3)测试计划;
(4)执行测试计划;
(5)测试分析的报告与改进。

第二章 制定软件测试策略
1、确定解决方法的有效性是解决问题的必要步骤。测试就是用来确定解决方法的技术。
三个方面:
(1)在软件系统开发生命周期的每个节点对软件有效性的证明;
(2)根据用户的需要和要求确定最终系统的有效性;
(3)通过使用样本测试数据执行软件来检查系统的行为。
问题的紧急程度决定了解决方案。明确测试需求。
2、风险:是引起损失的一种情况。系统在开发和安装阶段可能存在的策略风险是:
(1)可能得出不正确的结果;
(2)系统接受了未经授权的事务处理;
(3)计算机文件的完整性受到破坏;
(4)处理过程不可重建。
(5)失去处理的连续性;
(6)提供给用户的服务达不到满意的程度;
(7)系统安全性达不到标准;
(8)处理过程不符合组织原则或政府规定;
(9)系统结果不可靠;
(10)系统使用难度大;
(11)程序不可维护;
(12)系统不能移植到其它硬件或软件中;
(13)系统不能与其它计算机系统互连;
(14)性能不合格;
(15)系统操作难度大。
有效的测试方法就是明确和评价计算机系统的各种风险。
“太少的测试是犯罪,太多的测试是罪恶。”
测试中的问题产生的原因:
(1)没有定义测试目标;
(2)测试软件生命周期的错误阶段;
(3)使用无效的测试技术。
测试费用的有效性可用测试费用曲线来表示。
3、测试信息服务系统不仅仅是一类IT问题,还是一类组织问题。
一些技术的发展会导致测试方法的修改,如下:
(1)一体化;
(2)系统链接;
(3)多米诺骨牌效应;
(4)依赖电子商务;
(5)多用户。
4、建立测试原则 四项标准:
(1)测试的定义:定义一个清晰、扼要、明确的测试;
(2)测试系统:通过这一方法实现测试和强制测试;
(3)评价:信息服务管理将如何衡量和评价测试;
(4)标准:衡量测试的标准。
建立测试原则的方法:
(1)直接管理:一个或多个高级管理员制定的原则;
(2)信息服务一致原则:IT管理部门召集一些高级专家和有声望的人来参与原则的制定;
(3)用户会议:联合IT各部门管理用户的关键人员制定测试原则。
5、测试的结构化方法
测试过程要包括生命周期的每个阶段:
(1)需求——决定验证方法;确定需求是否恰当;生成功能测试数据;确定设计是否符合需求。
(2)设计——确定设计是否恰当;生成结构合功能测试数据;确定是否符合设计。
(3)编程——确定程序完成得是否恰当;生成程序的结构合功能测试数据。
(4)测试——测试应用系统。
(5)安装——把测试过的系统投入生产。
(6)维护——修改和重新测试。
在每个阶段都要完成的活动有:
(1)分析该阶段的产品结构是否适合于测试;
(2)根据该阶段的结构产生测试单元。
另外,在设计和编程阶段完成的活动:
(1)确定该阶段的结构是否符合前面阶段产生的结构;
(2)精炼或重新定义前面阶段生成的测试单元。
6、测试策略的两个组件是:
(1)测试因素:需要由测试策略确定的风险和问题;
(2)测试阶段:系统开发生命周期里需要测试的各阶段。
7、测试因素:正确性、文件完整性、合法性、审计跟踪、处理的连续性、服务水平、访问控制、符合性、可靠性、易用性、可维护性、可移植性、耦合、性能、易操作性。
8、制定测试策略 步骤:
(1)选择和分级测试因素;
(2)明确系统开发阶段;
(3)明确系统开发时的商业风险;
(4)把风险置于矩阵中。
9、创建测试策略样例:
(1)选择和分类测试因素;
(2)明确受到影响的阶段;
(3)联系每个阶段和因素,确定测试需要考虑的问题;
(4)定义测试策略。
10、测试方法论:与测试策略相统一,代表了测试应用系统的详细工作程序。工作程序用测试方法论立方体表示。

第三章 建立软件测试方法论
测试方法论是使测试策略得以实施的一套方法。依照需求恰当的使用测试策略矩阵。任务是决定测试、制定可行的测试方法,识别出风险。
1、测试目的:发现和消除软件的缺陷或者与预期结果的偏差。两类缺陷:
(1)与规格说明不符;
(2)与期望不符。
2、导致软件缺陷的原因:
(1)信息技术对需求的解释不正确;
(2)用户提出了错误需求;
(3)没有正确记录用户的需求;
(4)设计规格说明不正确;
(5)程序规格说明不正确;
(6)程序编码中有错误;
(7)数据输入错误;
(8)测试错误;
(9)纠错时出现错误;
(10)纠错条件导致另外的缺陷。
测试的费用主要取决于在项目生命周期的什么时期开始测试,越晚越贵。
测试应该从生命周期的第一个阶段开始,并贯穿于整个软件开发的生命周期。
生命周期测试:是对解决方案的持续测试,即使在软件开发计划完成后或者被测试的系统处于执行状态的时候,都不能中断测试。直到正式开始开发过程,生命周期测试才能开始。
3、四个测试技术:
(1)验证:确保系统遵循组织标准和规程,主要靠评审或一些不可执行的方法。
验证需要的评审有:
    (1.1)需求评审:研究并讨论计算机系统的需求,以确保它能满足用户的需要及其可行性;
    (1.2)代码走查:对程序源代码进行非正式的分析,以发现缺陷并且验证编码技术;
    (1.3)代码审查:对程序源代码进行正式的分析,以发现为符合计算机系统设计规格说明所发生的设计缺陷;
    (1.4)设计评审:研究并讨论计算机系统的设计,以确保它支持系统需求;
    (1.5)回顾评审。
(2)确认:通过一系列可以看到和评价的测试来执行系统功能,以确保系统操作按照计划实现。
确认的测试有:
    (2.1)单元测试:单独程序、模块或代码单元的测试;
    (2.2)集成测试:相关的程序模块、代码单元测试;
    (2.3)系统测试:对于整个计算机系统的测试;
    (2.4)用户验收测试:对于计算机系统或系统某部分的测试,确保它们能配合系统工作,而无需考虑系统需求。
(3)功能测试:即黑盒测试。基本只能使用确认技术。
(4)结构测试:白盒测试。主要使用验证技术。
功能测试的优势:模拟实际系统的使用;进行没有系统结构的设想。
功能测试的不足:遗漏软件中潜在的逻辑错误;可能造成冗余测试。
结构测试的优势:可以测试软件的结构逻辑;测试时不用考虑是否完成了功能测试。
结构测试的不足:不能保证是否满足用户的需求;结构测试不可以模拟现实世界的情况。
两者结合才能确认整个系统。
4、工作流程:是一种方法,它用图示或文档的方式来说明指定的活动是如何完成的。
每一个工作流程由以下四个部分组成:输入、执行过程、检查过程、输出。
工作流程的概念可用作系统创建步骤的图示说明。
5、开发测试方法论中要考虑的八个问题
(1)获取和研究测试策略;
(2)确定开发项目的类型;
(3)确定软件系统的类型;
(4)确定项目的范围;
(5)确定战术风险;
(6)确定何时进行测试;
(7)建立系统测试计划;
(8)建立单元测试计划。
步骤如下:
(1)获取和研究测试策略;
(2)确定开发项目的类型;
项目类型:指开发的软件环境或方法论。
当环境变化大了,测试风险也会不同。
(3)确定软件系统的类型
软件系统的类型指该系统要完成的处理过程,一般有16种不同的软件处理类型:
    (3.1)批处理:可以运行一般的批量处理;
    (3.2)事件控制:由外部事件引发的实时处理数据;
    (3.3)处理控制:从外部接收数据,根据收到的数据发出命令来控制某些行为;
    (3.4)规程控制:控制其它软件;
    (3.5)高级数学模型:类似于模拟和商业策略软件,但具有过多运用数学模型造成的复杂性;
    (3.6)消息处理:管理输入输出消息,处理文本或者文本包中包含的信息;
    (3.7)诊断软件:检测和隔离硬件错误,这些硬件存在于电脑或与其通信的硬件中;
    (3.8)传感器和信号处理:类似于消息处理,但需更多的处理过程来分析输入数据,并使之转换成可用的数据处理格式;
    (3.9)模拟:模拟一种环境、任务状况、其它硬件;从这些输入中得出对计算机程序或硬件最真实的评价;
    (3.10)数据库管理:管理数据的存储和访问;
    (3.11)数据采集:实时接收信息,并以某种形式保存数据,用作以后的处理;
    (3.12)数据表示:格式化数据及转化数据;
    (3.13)决策和计划辅助:使用人工智能技术提供一个专家系统来评价数据,为决策和政策制订者提供附加的信息和考虑;
    (3.14)图形和图像处理:生成和处理计算机图像;
    (3.15)计算机系统软件:为运行计算机程序提供服务;
    (3.16)软件开发工具:为辅助软件开发提供服务;
(4)确定项目的范围:指包含在被测试的软件中的所有行为——可以理解的系统需求和规格说明的范围。
(5)确定战术风险  战术风险分为三类:
    (5.1)结构化风险:应用系统及创建应用系统的方法中所涉及的风险;
    (5.2)技术风险:创建和操作应用系统的技术所涉及的风险;
    (5.3)规模风险:软件各方面的规模所设计的风险。
确定战术风险的步骤:
    第一,理解风险和对风险的分级;
    第二,确定被测试的软件系统中适当级值;
    第三,计算和累计风险分数。
(6)确定何时进行测试
测试在项目的各个阶段都应该进行。在这些阶段的测试行为有:
  A. 需求阶段行为:确定测试策略;确定需求是否恰当;创建功能测试条件。
  B. 设计阶段行为:确定需求设计符合性;确定设计是否恰当;创建结构和功能测试条件。
  C. 编程阶段行为:确定设计符合性;确定执行是否恰当;创建程序单元的结构和功能测试条件。
  D. 测试阶段行为:确定测试计划是否恰当;测试应用系统。
  E. 安装阶段行为:修改和重新测试系统。
(7)建立系统测试计划
测试计划要提供测试软件的背景信息、测试目标和风险,以及测试的业务功能和要完成的特殊测试。
测试计划类似于执行测试的路线图,它被分解成特殊测试和低级测试。
测试执行后,要测试结果生成测试报告。
(8)建立单元测试计划
把系统分成组件和单元来执行具体的处理,这些单元都要有自己的测试计划。根据软件对质量的要求程度,决定这些计划的复杂程度。
单元测试计划着重确定单元测试完成时间。

 

没有更多推荐了,返回首页