测试之旅Ⅰ-软件测试综述

软件测试综述

一、软件测试的背景

软件失败的常用术语

  • 指确实严重的情况,甚至是危险的情况。
    • 故障(fault)
    • 失败(failure)
    • 缺点(defect)
  • 不是那么尖锐,主要指未按预料的运行。
    • 异常(anomaly)
    • 事件(incident)
    • 偏差(variance)
  • 其他常用术语。
    • 问题(problem)
    • 错误(error)
    • 缺陷(bug)

软件缺陷的官方定义

  1. 软件未实现产品说明书要求的功能。
  2. 软件出现了产品说明书指明不应该出现的错误。
  3. 软件实现了产品说明书未提到的功能。
  4. 软件未实现产品说明书虽未明确提及但应该实现的目标。
  5. 软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。

软件测试员的职责

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

软件测试员的素质

  • 探索者 软件测试员不会害怕进入陌生环境。他们喜欢拿到新软件,安装在自己的机器上,观看结果。
  • 故障排除员 软件测试员善于发现问题的症结。他们喜欢解谜。
  • 不放过任何蛛丝马迹 软件测试员总在不停地尝试。他们可能会碰到转瞬即逝或者难以重现的软件缺陷。他们不会当作是偶然而轻易经过,而会想尽一切可能去发现它们。
  • 具有创造性 测试显而易见的事实,对软件测试员来说还不够。他们的工作是要设想出富有创意甚至超常的手段来寻找缺陷。
  • 追求完美者 他们力求完美,但是当知道某些无法企及时,不去苛求,而是尽力接近目标。
  • 判断准确 软件测试员要决定测试内容、测试时间,以及看到的问题是否是真正的缺陷。
  • 注重策略和外交 软件测试员常常带来的是坏消息。他们必须告诉程序员,你的孩子(程序)很丑。优秀的软件测试员知道怎样策略和职业地处理这些问题,也知道如何和不够冷静的程序员合作。
  • 善于说服 软件测试员找出的缺陷有时被认为不重要,不用修复。测试员要善于清晰地表达观点,说明软件缺陷为何必须修复,并推进缺陷的修复。

二、软件开发的过程

产品设计文档清单

  • 结构文档 描述软件整体设计的文档,包括软件所有主要部分的描述以及相互之间的交互方式。
  • 数据流图 表示数据在程序中图和流动的正规示意图。有时被称为泡泡图,因为它是用圆圈和线画的。
  • 状态转换图 把软件分解为基本状态或者条件的另一种正规示意图,表示不同状态间转换的方式。
  • 流程图 用图形描述程序逻辑的传统方式。流程图现在不流行了,但是一旦投入使用,根据详细的流程图编写程序代码是很简单的。
  • 代码注释 有一个老的说法,你写一次代码,至少被别人看10次。在软件代码中嵌入有用的注释是极为重要的,这样便于维护代码的程序员轻松掌握代码的内容和执行方式。

测试文档

  • 测试计划 描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等。
  • 测试用例 列举测试的项目,描述验证软件的详细步骤。
  • 缺陷 告 描述执行测试用例找出的问题。可以记录在纸上,但通常记录在数据库中。
  • 测试工具和自动测试 如果测试小组使用自动化测试工具测试软件,不管是购买的还是自己编写的工具,都必须有文档记录。
  • 度量、统计和总结 测试过程的汇总。采用图形、表格和 告等形式。

软件产品组成

  • 最终产品
  • 帮助文件
  • 用户手册
  • 样本和示例
  • 标签和不干胶
  • 产品支持信息
  • 图标和标志
  • 错误信息
  • 广告和宣传材料
  • 安装
  • 说明文件

软件项目成员

  • 体系架构是或者系统工程师
    产品小组中的技术专家。他们一般经验丰富,可以胜任设计整个系统的体系架构或软件。他们的工作与程序员关系紧密。
  • 测试员和质量保证(QA)
    负责找出并 告软件产品的问题。他们与开发小组全部成员在开发过程中密切合作,进行测试并 告发现的问题。

软件开发生命周期模式

  • 大爆炸模式
  • 边写边改模式
  • 瀑布模式
  • 螺旋模式

大爆炸模式

大爆炸模式的优点是简单。计划、进度安排和正规开发过程几乎没有,所有精力都花在开发软件和编写代码上。假如产品需求无需很好理解,而且最终发布日期可以随便更改,这样的开发过程很理想。此外,还要有聪慧过人的客户,因为他们直到最后才知道自己会拿到什么样的软件。
加入测试员参与大爆炸模式下生产产品的测试,就会面临一个既容易又困难的任务。因为软件已经完成,测试员手里有了完美的产品说明书——产品本身。但同时,因为不可能回头修复已经打乱的事情,软件测试的工作其实就是 告发现的问题让客户知道。
更差的情况是,从项目管理的角度看,产品已经完工,准备交付,因此软件测试员的工作妨碍了交付。测试工作越深入,就会发现越来越多的软件缺陷,争吵就越多。尽量避开在此模式下进行测试。

边写边改模式

边写边改模式是项目小组在未刻意采用其他开发模式时默认的开发模式。采用这种方式的小组通常最初只有粗略的想法,接着进行一些简单的设计,然后开始漫长的来回编写、测试和修改缺陷的过程。等到觉得足够了,就发布产品。
由于开头几乎没有计划和文档编制,项目小组得以迅速展现成果。因此,边写边改模式及其适合意在快速制作而且用完就扔的小项目,例如原型范例和演示程序。
与大爆炸模式类似,测试在边写边改模式中未特别强调,但是在编写代码和修复缺陷过程中举足轻重。
作为边写边改的项目的软件测试员,需要和程序员一样清醒地认识到自己将陷入无休止的循环往复。几乎每一天都会拿到新的软件版本并着手测试。当新版本出来时,旧版本的测试可能尚未完成,而新版本还可能包含新的或者经过修改的功能。最后,终于有机会对几乎所有功能进行测试了,并且发现软件缺陷越来越少,这时某人(或者进度)决定该发布软件了。

瀑布模式

步骤

构思->分析->设计->开发->测试->最终产品
采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时,项目小组组织审查,并决定是否进入下一步。如果项目未准备好进入下一步,就停滞下来,直到准备好。

三点强调
  • 瀑布模式非常强调产品的定义。注意,开发或者代码编制阶段只是其中单独的一块。
  • 瀑布模式各步骤是分立的,没有交叉。
  • 瀑布模式无法回溯。一旦进入某一个步骤,就要完成该步骤的任务,然后才能向下继续——无法回溯。

对于拥有明确清晰的产品定义和训练有素的开发人员的项目而言,该模式的效果很好。该模式的目标是在编写代码之前解决所有的未知问题并明确所有细节。缺点是,在这个变化迅速、在互联 上开发产品的时代,当软件产品还在细细考虑和定义时,当初制造它的理由都可能会变了。
瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时,所有细节都已确定并有文档记录,而且实现在软件之中。由此,测试小组得以制定精确的计划和进度。测试对象非常明确,在分辨是功能还是缺陷上也没有一点问题。
然而因为测试仅在最后进行,所以一些根本性问题可能出现在早期,但是知道准备发布产品时才可能发现。那时的软件缺陷修复费用可能比较高。

螺旋模式

螺旋模式的总体思想是一开始不必详细定义所有细节。从小开始,定义重要功能,努力实现这些功能,接受客户反馈,然后进入下一个阶段。重复上述过程,直至得到最终产品。

步骤
  1. 确定目标、可选方案和限制条件
  2. 明确并化解风险
  3. 评估可选方案
  4. 当前阶段开发和测试
  5. 计划下一阶段
  6. 确定进入下一阶段的方法

由于该模式发现问题早、成本低的特点,可以算做相当好的开发模式。该模式下,软件测试员的测试一直都在进行,所以最后一步只是一个验证表面所有部分都没有问题。

三、软件测试的实质

测试的原则

完全测试程序是不可能的

  • 输入量太大
  • 输出结果太多
  • 软件执行路径太多
  • 软件说明书是主观的。可以说从旁观者来看是缺陷。

软件测试是有风险的行为

如果决定不去测试所有的情况,那就是选择了冒险。软件测试员不能做全部的测试,不完全测试又会漏掉软件缺陷。软件终归是要发布的,所以测试需要停止,但是如果过早停下来,就还有地方没有测试到。
软件测试员要学会的一个关键思想是,如何把数量巨大的可能测试减少到可以控制的范围,以及如何针对风险做出明智的抉择,哪些测试重要,哪些不重要。
如果试图测试所有情况,费用将大幅增加,而软件缺陷漏掉的数量在到达某一点后没有显著变化。如果减少测试或者错误地确定测试对象,虽然费用很低,但是会漏掉大量软件缺陷。我们的目标是找到最优的测试量,使测试不多不少。

测试无法显示潜伏的软件缺陷

软件测试员可以 告软件缺陷存在,却不能 告软件缺陷不存在。你可以进行测试,发现并 告软件缺陷,但是任何情况下都不能保证软件缺陷没有了。唯一的方法是继续测试,可能还会找到一些。

找到的软件缺陷越多,就说明软件缺陷越多

通常,软件测试员会在很长时间内找不到软件缺陷。接着找到一个,之后很快就会接二连三地找到更多。其中的原因是:

  • 程序员也有心情不好的时候
  • 程序员往往犯同样的错误
  • 某些软件缺陷实乃冰山一角

杀虫剂怪事

用于描述软件测试越多,其对测试的免疫力越强的现象。
为了克服杀虫剂怪事,软件测试员必须不断编写不同的、新的测试程序,对程序的不同部分进行测试,以找出更多软件缺陷。

并非所有软件缺陷都要修复

  • 没有足够的时间
  • 不算真正的软件缺陷
  • 修复的风险太大
  • 不值得修复

什么时候才叫缺陷难以说清

遵守软件缺陷定义规则,有助于澄清什么样的软件缺陷才算缺陷这个模棱两可的问题。
尚未发现或未观察到的软件缺陷只能说是潜在缺陷。

产品说明书从没有最终版本

软件测试员必须要想到产品说明书可能改变。未曾计划测试的功能会增加,经过测试并 告软件缺陷的功能可能发生变化甚至被删除。

软件测试员在产品小组中不受欢迎

保持小组成员和睦的建议:

  • 早点找出缺陷
  • 控制情绪
  • 不要总是 告坏消息

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

软件测试的术语和定义

  • 精确和准确
    准确代表产品的输出是否正确,精确代表着产品的精确度。软件测试要精度还是准度很大程度上取决于产品是什么,最终取决于开发小组的目标。只要软件测试员清楚产品说明书,就可以量身定做测试程序来确认。
  • 确认和验证
    确认是保证软件符合产品说明书的过程。
    验证时保证软件满足用户要求的过程。
  • 质量和可靠性
    如果说软件产品质量高,就是指它能够满足客户要求。客户会感到该产品性能卓越,优于其他产品。可靠性仅仅是质量的一个方面。
    软件使用者心目中的质量可能包括,软件功能的多少、在自己的旧PC上运行的能力、软件公司的服务电话好不好打以及软件的价格。产品的可靠性或者产品多长时间崩溃的问题,也许重要,但常常不被考虑到。
    为了保证程序质量高而且可靠性强,软件测试员必须在整个产品开发过程中进行确认和验证。
  • 测试和质量保证(QA)
    • 软件测试员的目标是尽可能早地找出软件缺陷,并确保缺陷得以修复。
    • 软件质量保证人员的主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法。

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2019年1月16日
下一篇 2019年1月16日

相关推荐