软件测试第二章

软件测试进阶

一、 软件测试环境的备份与恢复

1. 备份
在开展测试工作的过程中,可能随时会出现意料之外的情况,包括但不限于**“系统崩溃”、“测试数据丢失”、“测试过程中断”、“测试环境损坏”等。因此,为了在测试工作出现异常时可以迅速地将工作恢复至出现异常前的状态,测试团队应当定期、及时的对测试环境进行备份**。

备份位置:

  • 低重要度的备份文件可以放置在本地系统盘或其他分区。
  • 中等重要度的备份文件应当放置在外部存储介质,并且将多份备份文件存放至不同的位置
  • 高重要度的备份文件必须多份、异地存放,避免因火灾、地址等不可抗力造成备份数据丢失。

2. 恢复
一旦测试环境出现损坏导致测试工作被迫终止,应当尽快使用最新的备份进行还原将测试环境恢复为出现异常前的正常状态。

恢复目的:

  • 维持测试环境的一致性
  • 恢复丢失的测试数据
  • 恢复测试环境的异常状态

二、 软件测试策略

1. 软件测试工作的难度
软件测试工作虽然相比于软件开发工作“较为简单”,但是通过软件测试工作以达到“保证软件质量”的最终目的是非常困难的,因此在执行软件测试工作时应当保持慎重。

保证软件质量的困难度较高的原因:

  • 剩余时间可能较紧,无法完全测试整个软件。
  • 错误或缺陷可能隐藏比较深,无法轻易发现。
  • 软件测试存在免疫性,平均每修改3-5个错误或缺陷,就会引入1个新的错误或缺陷。
  • 保证软件永远无法没有错误或缺陷是基本不可能的,没有十全十美的软件。

2. 软件测试策略
软件测试策略:指的是在软件测试计划的指导下,根据被测项目的特定环境约束而制定的软件测试的原则、方式、思路等方法的集合

基本测试策略:

  • 如果未能做到测试软件所有可能的情况,则软件就是有风险的。
  • 如果软件在交付后由用户发现了错误或缺陷的话,此时是我负面代价是最大的。
  • 将发生各种意外的可能性尽可能的降低至可控范围。
  • 提前进行风险评估,针对风险的不同选择恰当的测试方法。
  • 找到最佳测试量,选择资金花费与剩余错误缺陷数量相平衡的位置终止测试。

三、 软件测试的方法

1. 静态测试与动态测试
(1) 静态测试
静态测试并不实际运行被测试的软件仅静态地检查程序代码、软件界面以及项目文档中可能存在的错误与缺陷过程。

静态测试主要检查以下三个地方:

  • 程序代码:检查编码风格是否符合规范;检查算法是否仍有优化空间、程序函数逻辑是否存在错误等;代码质量度量:使用人工或软件工具检查程序代码质量是否合乎设计标准。
  • 软件界面:测试软件的实际界面与需求文档中的说明界面是否完全相符。
  • 项目文档:测试用户手册与需求说明文档是否完全符合最终用户的实际需求。

(2) 动态测试
动态测试指的是实际运行被测试的软件向其中输入测试数据,检查实际输出结果与预期结果是否相符的过程。判断测试属于静态还是动态,仅需要确认是否实际运行了软件

动态测试包括:

  • 功能确认、接口测试
  • 覆盖率分析
  • 性能分析
  • 内存分析

2. 白盒测试与黑盒测试
(1)白盒测试
白盒测试指的是需要完全了解软件的结构与处理过程,按照软件的内部逻辑来测试软件,检验软件中的每条路径能否按照规格说明文档中的规定或要求正常执行

(2)黑盒测试
黑盒测试指的是将待测试软件当作一个“打不开的黑盒子”,在程序接口开展测试工作,只检查软件功能是否满足规格说明文档,根据软件需求来设计测试用例并执行测试。集成、系统、验收测试流程一般都使用黑盒测试作为主要的方法

黑盒测试特点:

  • 黑盒测试与软件的具体实现过程无关,如果实现过程发生了变化,测试用例与数据仍然可以正常使用。
  • 黑盒测试的测试用例设计可以与软件的开发工作同时进行,可以压缩项目的总开发时间。

3. 手工测试与自动化测试

  • 手工测试与自动化测试都是不可或缺的,两者是相辅相成的关系。
  • 手工测试与自动化测试都以测试用例为核心
  • 理论上,所有的手工测试都可以改为以自动化的方式来执行,不过应当考虑使用自动化测试工具带来的效率上的增益能否抵消掉项目资金的消耗。

四、 测试用例

1. 概念
软件测试用例指的是为了实施软件测试而向被测试软件提供的有关测试目标、输入数据、操作方式、测试环境、预期结果以及测试脚本等必要信息的特定集合。测试用例可以体现软件测试的方法、技术与策略,可以用于核实软件是否满足相应的需求。

软件测试用可以解决的问题:

  • 确定需要测试软件的哪些功能。
  • 具体如何执行软件测试。
  • 如何衡量软件测试得出的结果。

测试用例的用途:

  • 指导测试工程师开展测试工作。
  • 指导测试工程师规划测试数据。
  • 指导测试工程师编写测试脚本。
  • 作为测试工作成功与否的评判标准。
  • 作为软件缺陷严重程度的评判标准。

2. 内容与格式

(1) 内容

  • 简洁性:应当使用简单、精炼的语言来编写测试用例。
  • 正确性:工程师可以顺利地按照测试用例来执行工作,并且可以得到准确的测试结果。

(2) 格式
软件名称、软件版本、功能模块名称、编号、测试标题、主要级别、前置要求、测试数据测试输入操作步骤预期结果等。

3. 更新与维护
随着软件项目的需求变更与功能变化软件测试用例也需要不断地进行细化与完善,这是一个循序渐进的过程。软件测试用例一般需要由多名经验丰富的测试工程师进行正式、有效的评审,以便及时的就行查缺补漏。如果确实需要的话,推荐使用专业的软件来管理软件测试用例,而不仅仅是把测试用例放置在word文档中。

五、 黑盒测试技术

1. 等价类划分法
等价类划分法指的是依据软件需求对测试输入数据的范围进行细分,在每个细分区域中选取一个有代表性的测试数据,以此测试数据来展开测试工作。

等价类分为两种:有效等价类+无效等价类

  • 有效等价类:符合需求说明的合理软件测试输入数据的集合。
  • 无效等价类:不符合需求说明的无意义软件测试输入数据的集合。

2. 边界值划分法
边界值划分法指的是对软件的输入或输出的边界值进行着重测试的一种测试方法。通常情况下,软件中数据范围的边界值是最容易产生错误与缺陷的位置

3. 错误推测法
错误推测法指的是基于软件测试工程师的经验与直觉对软件中可能存在缺陷与功能与模块进行推测,并根据这些推测有针对性的设计软件测试用例的一种测试方法。

六、 白盒测试技术

1. 语句覆盖(最弱)
语句覆盖测指的是制定足够多的软件测试用例,使得软件中的每一个代码语句至少都能被执行一次的软件测试方法。这是一种效果较差的逻辑驱动覆盖测试方法。

2. 判定覆盖(较弱)
判定覆盖测试指的是制定足够多的软件测试用例,使得软件中的每一个分支至少都能被执行一次的软件测试方法。这是一种比 “语句覆盖测试” 效果稍强一些的逻辑驱动覆盖测试方法。

3. 条件覆盖(中等)
条件覆盖测试指的是制定足够多的软件测试用例,使得软件中的每一个判定条件都获得各种可能的取值的软件测试方法。这是一种效果更强一些的逻辑驱动覆盖测试方法。

4. 判定-条件覆盖(较强)
判定 - 条件覆盖指的是综合判定覆盖与条件覆盖,制定足够多的软件测试用例,使得软件判定中的每一个条件都获得各种可能的取值,同时使得软件中的每一个分支至少都能被执行一次的软件测试方法。

5. 条件组合覆盖(最强)
条件组合覆盖指的是制定足够多的软件测试用例,使得软件中的所有条件的各种组合都能被至少执行一次的软件测试方法。这是效果最强但仍不完美的逻辑驱动覆盖测试方法。

七、 软件缺陷

1. 概念
从软件的内部来看,软件缺陷指的是软件在开发或维护的过程中所存在的错误与其他各种问题。从软件的外部来看,软件缺陷指的是软件与其所需要实现的功能的失效与违背

一般情况下,满足以下情况之一,即可称为软件缺陷:

  • 软件未实现产品说明文档中要求的功能。
  • 软件出现了产品说明文档中明确指出的 “不应当出现” 的错误。
  • 软件实现了产品说明文档中未要求实现的功能。
  • 软件未实现产品说明文档中未要求实现、但是实际上应当实现的功能。
  • 软件难以使用、不易使用、运行缓慢或最终用户不满意。

2. 软件缺陷的产生原因

(1)技术问题

  • 算法错误
  • 语法错误
  • 计算与精度问题
  • 参数传递问题

(2)团队协作

  • 误解
  • 沟通不充分

(3)软件自身

  • 文档编写错误
  • 用户在不恰当的场合使用
  • 时间时区不一致

3. 软件缺陷的严重性与优先级

(1)严重性
软件缺陷的严重性用来表示缺陷所造成的危害的恶劣程度,一般分为以下几种:

  • 致命缺陷:指的是可以直接造成软件崩溃、挂起、冻结或无响应,或者可以造成软件数据丢失或主要功能完全失效等致命问题的软件缺陷。
  • 关键缺陷:指的是可以造成软件的主要功能部分失效或者次要功能完全失效的软件缺陷。
  • 主要缺陷:指的是几乎不影响软件正常使用,但是没有完全实现需求、未能达到预期效果的软件缺陷。
  • 次要缺陷:指的是完全不影响软件正常使用的细微的软件缺陷。
  • 建议:软件产品用户提出的友好建议。

(2)优先级
软件缺陷的优先级用来表示修复缺陷时应当遵循的先后顺序

  • A-1-最高优先级:停止进一步的测试与开发工作,立即修复此缺陷。
  • B - 2 - 次高优先级:在软件正式发布前必须修复此缺陷。
  • C - 3 - 中等优先级:如果时间允许的话,应当修复此缺陷。
  • D - 4 - 最低优先级:可以修复此缺陷,也可以不修复。

4. 软件缺陷报告的编写

(1)软件缺陷管理方式的演变

  • 口头传达:测试工程师直接联系开发工程师口头说明软件缺陷。
  • 流水记录:测试工程师将软件缺陷记录至 Word 文档中,开发工程师可以随时查看。
  • 系统管理:软件项目团队使用专业工具完整的记录与跟踪缺陷的实时处理情况。

(2)软件缺陷报告的用途

  • 记录软件缺陷
  • 分类软件缺陷(便于分配资源)
  • 跟踪软件缺陷的处理情况
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值