软件测试之捉虫记-大容量Web应用性能测试与LoadRunner实战

第 1 章 什么是软件测试 由安博测试空间技术中心 在我国宋代 有一位叫宋慈的法医学家写了一本 洗冤集录 在书中 他讲述了很 多断案的经验 其中有一个用银针验毒的方法至今仍广为流传 比如在很多电视剧中 我 们能经常看到皇帝在进膳的时候 由于害怕被人暗害 总要让可怜的太监或者宫女先用银 筷子尝上几口饭菜 没有出现问题再正式用餐 这种用银针进行的试验就可以说是一种测 试的雏形吧 银针充当了测试工具 而太监或者宫女就是古代的测试工程师 时光飞逝 随着科技的发展 我们生活周围有了越来越多的产品 它们在出厂销售前 都要进行测试 不仅要保证功能完好 还要确保对使用者的伤害在允许范围内 因此在工 厂里 逐渐出现了这样一个部门 由它来负责检验产品 被称之为质量检验或者质量保 证部 上个世纪中后期 软件出现了 它作为人们日常生活中天天都会使用的产品 同样也 需要质量的保证 有一种误解 软件的质量问题并不那么重要 比如 Windows 等操作系 统 各种桌面的应用软件 像 IE 浏览器 如果它出现了问题 程序会失去响应甚至严重 的系统会蓝屏 那么只需要在任务管理器中将它删掉就可以了 最多重新启动电脑 一般 都能够继续使用 这只是一方面 另一方面 有很多非常重要的软件在我们看不见的地方 默默地运行着 如果它们出现了问题 影响就很大了 为了说明软件质量的重要性 这里举一个比较著名的软件质量造成的事故 1962 年 美国的航海家 1 号 Mariner 1 火箭升空 由于控制火箭的软件出现问题 直接导致火箭升空后因偏离轨道而被迫引爆 造成当时 1800 万美元的损失 事后查明 是程序员在编写软件代码时 误写了其中一个公式的上标造成轨道计算失误的 第 1 章 什么是软件测试 1 因此 软件公司也需要质量保证部门 我们把该部门的组成人员称为 QA 工程师 Q A 即 Quality Assurance 质量保证的简称 软件是否符合质量是通过测试来验证的 因此他 们也被称为软件测试工程师 在本书中您即将遇到的各种行为 绝大多数都将是软件测试 工程师在工作中所要实现和完成的 1 1 软件开发的基本知识 对于每一位进入软件测试行业的新人来讲 公司的入职培训是一个很好的学习机会 1 1 1 软件开发公司技术部门的基本结构 可将软件测试部门类比于工厂车间的质量保证部门 那么显而易见 如果在工厂中要 做好质量控制的工作 必须熟悉本厂生产的产品和流程 换句话来说 作为软件生产的参 与者 了解被测试的软件也是非常重要的一件事情 这也正是经理要求小白在短期内尽快 熟悉的内容 什么是软件 中国大百科全书中对软件的定义是 软件是计算机系统中的程序和相关文件或文档的 总称 软件是从英文 Software 翻译过来的名词 与硬件 Hardware 相对应 因此 软件开发公司就是制造这些程序和相关文件或文档的商业机构 一般来说 软 件开发公司的技术部门由几个子部门或者角色组成 开发部门 测试部门 部门经理或者 项目经理 另外有的公司还有技术支持部门 对应于传统行业 分别相当于生产车间 质 量控制部门 部门经理和售后服务部门 如表 1 1 列出了常见软件开发公司技术部门的不 同职责 表 1 1 常见软件开发公司技术部门的角色分类 部 门职 责 软件开发部门开发软件 确定软件实现方法 编写软件程序代码 软件测试部门 测试软件 确定测试方法 编写自动测试软件的代码 手工测试软件 记录并跟 踪软件 Bug 技术总监或项目 经理 在所属或其他部门之间沟通 协调项目或者开发测试进度 为成员提供各种资源 技术支持部门软件开发完成后在客户处部署产品 并解决与反馈使用中出现的问题 Web 应用是一种特殊的软件 那么开发 Web 应用的网站与一般的软件开发公司有什 么不同呢 对于小白所处的商业网站来说 网站程序和相关文件或文档也可以称之为软件 其技 术部门的结构也和软件开发公司基本类似 但是各部门日常工作的方式则有所不同 商业网站每天都要有很多页面的更新 每次更新后当时浏览网站的人立即可以看 到 而软件开发公司一般一年或者几年推出一个产品 在产品没有上市的时间内 用户只能使用旧的版本 也就是说网站软件的变化要比软件开发公司频繁 网站 第 1 篇 Web 测试背景知识 2 软件的开发与用户使用处于同一时间段内 商业网站以服务器为核心 网站软件主要运行在服务器上 而软件开发公司的产 品主要运行在用户的电脑上 演唱会与专辑 商业网站与软件开发公司的运作模式有点类似于歌手开演唱会和发专辑的区别 在演 唱会上 歌手与观众的互动性更强 每一个细节的变化也都能被观众捕捉到 而歌手专辑 则相当于软件产品的某个版本 是提前制作完成之后再上市销售的 1 1 2 软件危机 小白在熟悉了技术部门的大致结构 网站与软件开发公司的区别之后 经理开始介绍 和软件测试相关的背景知识 软件危机就是产生软件测试这一职业的重要推动力之一 从 20 世纪 50 年代以来 软件的规模越来越大 复杂性也越来越高 另外 在 20 世 纪 80 年代 伴随着计算机的普及和应用需求的飞速增长 互联网开始蓬勃兴起 现在 现代人的生活已经越来越依赖各种各样的软件 软件不再是大学实验室里科学家的工具 而成为我们生活的一部分 从操作系统 比如每一台个人电脑所安装的 Windows XP 或者 Vista 系统 到小小的桌面程序 一个简单的连连看小游戏 再到 Google 网站上可以编 辑的在线文档工具 软件的开发 管理 维护的复杂性和高成本现象也日益突出 在某一 段时期 暴露了很多问题 因此在 20 世纪 有人提出了 软件危机 的说法 来说明这 种现象 软件复杂性的类比 其实我们中国人是很容易理解软件复杂性的 一些在人口少的国家不成为问题的问题 放在十几亿人口的环境中 就会产生不大不小的麻烦 比如每年的春运 需要火车票的 人是如此之多 而火车的座位是固定数量的 需要回家的人的分布是如此之广 而火车站 的位置也是固定的 依此类比 当软件的代码量越来越庞大 要满足的需求越来越广泛时 出现局部的危机是很容易理解的 1 1 3 软件危机的几个体现 随着软件越来越复杂 质量越来越难于控制 于是出现了所谓 软件危机 具体而 言 软件危机有以下几个体现 软件需求的增长无法快速得到满足 这一点在前文已经有所讲述 软件生产成本变高 价格越来越昂贵 软件的代码量增加 所投入的人工成本 也就是软件开发相关人员的成本也会增加 还要增加采用各种新技术的成本等 软件生产进度难于控制 软件的用户需求不容易定义 这一点也很重要 目前绝大多数的软件已经不止满 足单一的需求 因此用户真正所需要的不一定能够完美地实现 软件质量不容易保证 这一点也是由软件复杂度的增加而增加 还是举春运的例 子 如果火车上人人都有座位 那么每个人的心情都会很好 但如果到处挤满了 人 每位旅客回家的心情总会受到影响 从而影响对列车服务的评价 软件质量 第 1 章 什么是软件测试 3 和用户的评价同样是相关的 经常造成死机 异常退出或者按钮单击后没有反应 的软件 很难说是质量好的软件 软件可维护性变差 软件同样是需要维护的 一方面是对于用户使用过程中的维 护 这一功能由客户服务或者技术支持部门来完成 另一方面是对于软件本身代 码和文件文档的维护 这一功能由开发部门或者测试部门来完成 随着软件的日 益庞大 软件本身经历的修改越来越多 管理维护软件的各种版本变得日益困难 由于软件危机有这么多的影响和危害 所以促使人们静下心来研究软件开发过程中的 规律 这就产生了软件生命周期的概念 1 1 4 软件生命周期 软件生命周期 英文为 Software Lifecycle 就是软件开发 使用和消亡的过程 具体 而言 包含软件需求分析 软件设计 软件实现与测试和软件发布 部署与维护这 4 个 过程 在商业软件开发公司内部 人们往往遵循一定的软件生命周期模型 这样和被开发软 件相关的所有人员都按照这个模型的标准或者步骤开展工作 统一行动 有助于提高生产 效率 从而减少沟通和实施的成本 获得更大的商业利益 而对于软件生命周期的不同理 解和划分 就形成了不同的软件生命周期模型 1 1 5 常见的软件生命周期模型 目前来讲 主要的软件生命周期模型有如下几种 Big Bang 大爆炸模型 Waterfall 瀑布模型 Spiral 螺旋模型 Code and Fix 边做边改模型 由于本书并不是以软件工程为探讨内容 因此在这里只通过人们过河的类比来简单介 绍一下前述这几种软件生命周期模型的特点 小学课本里有个寓言叫做 小马过河 小马在过河前遇到了不同的小动物 它们对 于河水深度的理解是不同的 会导致小马过河时的不同选择 参见图 1 1 假设把待开发 的软件产品比喻为小马面前横着的那条小河 那么开发软件的过程也就是过河的过程 那 么如何过河就会有不同的结果 第 1 篇 Web 测试背景知识 4 图 1 1 小马过河 对河深度的理解影响过河的方法 1 1 6 直接冲过河去的大爆炸模型 大爆炸这个名称来自于天体物理有关宇宙形成方式的一种理论 宇宙是在亿万年前的 大爆炸中诞生的 与此类似 软件开发公司把金钱 办公场地和人员全部投入到一个产品 的开发当中 经过一段时间 产品出炉 这样的形式就是大爆炸模型 大爆炸模型的优点就是简单 没有很多的软件设计 对项目的管理也很少 目前不少 小公司由于各方面的限制不得已或者不自觉地采用了这样的开发模型 但是它的优点也造 成了它的缺点 开发出来的软件质量不可控制 在这样的模型中 由于没有周密的计划 软件测试往往是在产品即将上市的前夕才开 始 在很多公司中甚至没有专职的测试工程师 由开发人员或者其他人员代劳 因此测试 人员面对的产品与客户 使用者要面对的产品基本一致 从前文所述可以得知 在这样的 阶段发现 Bug 返工修改代码的代价是非常大的 回到过河的比喻中来 大爆炸模型就相当于小马先退后几步 集中精力和能量 然后 快速冲过去 这样的结果取决于河的宽度和深度 如果软件非常复杂 很可能过河的小马 半途就淹死了 无法到达对岸 1 1 7 摸着石头过河的边做边改模型 边做边改模型比起大爆炸模型来说进了一步 在开发软件产品的开始阶段 先有一个 大概的设计 然后开始编码 测试 发现 Bug 修改 Bug 这样的循环 直到整个产品的轮 廓日渐清晰 最终完成产品 用一句俗话来描述 就是 摸着石头过河 的过程 先以河 里的一些石头为支点 走入河道 再经过不断的试探和返回得到一条路线 最终到达目 的地 第 1 章 什么是软件测试 5 由此可见 边做边改模型中测试的参与要比大爆炸模型中要早得多 而且也重要得多 边做边改模型的优点就是适用于某些中小型项目的快速开发 软件产品的成果也会在最早 的阶段显现出来 和在岸边冥思苦想如何过河的人相比 先站在河道里的石头上 总是让 人看到更多的希望 边做边改模型被较多采用 这种开发模型被大多数公司所采用 是大多数测试工程师在实际工作中最常遇到的开 发模型之一 而且 它和最近几年很流行的敏捷开发也有一定的关系 1 1 8 制定周密过河计划的瀑布模型 从现在开始 下面的这两个模型就不适合小马了 只有人和外星人才有这样的能力 如图 1 2 介绍了软件开发的瀑布模型 由于图中的箭头好像瀑布的水流 从上至下 因此 得名 回到过河的例子中来 瀑布模型过河具备如 下特点 过河前 首先花费大部分的时间对河进 行详细的勘察 选择合适的下水点 选 择合适的过河工具 制定详细的分步骤 过河计划 一旦过河计划制定 将不会大更改 开 始过河 在河中完全按照计划进行 无 法返回起点 这也是为什么称此模型为 瀑布的原因 瀑布是飞流直下三千尺 想从下面返回瀑布的顶端 何其难 在每步骤即将完成时 都会对这一步骤进行总结 如果进行下一步骤的条件不具 备 将停留在原地 等待条件具备 瀑布模型看起来给人很专业的感觉 所以 对于软件开发人员有比较高的要求 要对待开发的软件 或者要过的河 有细致 全面 准确的了解 如果理解错误 将导致计划失败 没有返回重来的机会 职业素质 职业纪律要比较高 软件开发人员要具备坚定执行计划的能力 这种要求也就产生了瀑布模型的缺点 那就是无法完美适应当今要求快速开发产品 从而占领市场的软件行业现状 因为制定详细的 理解完整的计划很难 聚合很多专业的 开发人员有时候也很难 而市场对于软件更新换代的要求期限越来越短 为了适应变化 人们又提出了螺旋模型 1 1 9 计划赶得上变化的螺旋模型 前文提到 为了适应计划和变化两方面的因素 螺旋模型被提出 螺旋模型的示意如 图 1 3 所示 可以看到 它的确很类似一个螺旋 图 1 2 瀑布模型示意图 第 1 篇 Web 测试背景知识 6 与边做边改模型类似 螺旋模型也具有循序渐进的 特点 对软件最终实现什么不一定有完全确定的理解 而是摸着石头先下水 但是在选择过河的每一个石头前 经过了周密的计划和考虑 从这一点看 又类似瀑布模 型 可见 螺旋模型实际上是边做边改模型和瀑布模型 的有机结合 螺旋模型有如下 4 个步骤 1 确定项目目标 可用资源 各种实现的方法 项目的各个阶段 2 在某个阶段中 确认 解决当前阶段项目进 展中出现的风险 3 评估各种方法 开发 测试代码 实现当前 阶段的目标 4 总结当前阶段 计划下阶段的目标和实现方法 重复第 2 步 在图 1 3 中螺旋线被两条直线划分成 4 个部分 分别是上述的 4 个步骤 在每一步骤 中由于被直线切割会有多段曲线 每一段曲线就代表了在不同阶段中所进行的相同某个 步骤 螺旋模型的优点 由此可见 螺旋模型是多次计划 边做边改 这样既保证了软件开发任务的清晰 也 降低了开始一次计划 因为理解不完整或者市场变化后导致项目失败的可能性 1 1 10 4 种模型的总结 前文讲述了 4 种软件开发模型 那么在具体项目开发中采取哪一种最好呢 答案是它 们各有利弊 需要灵活采用 这几种开发流程的优缺点比较如表 1 2 所示 表 1 2 4 种软件开发流程的优缺点 开发流程分类优 点缺 点 大爆炸模型简单 不用学习就会 拍脑门的想法 产品质量无法保证 尽量避免使 用 边做边改模型快速得到可运行的版本 计划有些缺乏 导致版本前后变化较大 可选择 的模型之一 瀑布模型 计划周密 专业 按部就班实 现 相对难于做到快速开发 以抢占市场 可选择的 模型之一 螺旋模型计划变化同时考虑可选择的模型之一 当然 在几十年的软件开发过程中 人们还提出了很多其他的开发模型 不过 作为 测试工程师 我们对这几种主流模型有所了解就可以了 进一步深入的内容并不是本书所 讲述的范畴 读者可以参看软件工程的相关书籍 图 1 3 螺旋模型示意图 第 1 章 什么是软件测试 7 1 1 11 软件开发的几个阶段 不管采用哪一种开发模型 按照时间顺序 所有的软件开发项目都要经历如下 4 个 阶段 1 项目启动阶段 了解客户需求 配置相关资源 2 项目设计阶段 明确客户需求 确立软件开发 测试的方法 3 项目执行阶段 开发与测试阶段 4 项目竣工阶段 软件的上市 后期维护与技术支持 这一分类很好理解 下面再结合小白的工作场景 进行展开介绍 1 项目启动阶段 这一阶段一般技术人员参与较少 主要是市场部门 销售部门 技术总监 项目经理等角色的参与 项目成本是多大 开发人员有多少 测试人员有多少 完成时间在什么时候等 2 项目设计阶段 这一阶段主要参与者就是需求分析人员 开发人员 项目经理 和小白这样的测试人员了 主要目的是确定软件该如何做 做什么 开发人员利用何种技 术开发 测试工程师该如何测试该软件 客户如何使用该软件等 这些问题都要确定 形 成各自的开发文档 测试文档和需求文档等 3 项目执行阶段 开发 测试以及对其的管理就是执行 这一阶段的参与者是开 发人员 测试人员和项目经理 开发人员编写程序代码 进行单元测试 测试人员编写测 试代码 测试用例 进行功能测试等多种测试 项目经理控制进度 协调各种资源 与设 计人员沟通等 4 项目竣工阶段 当项目执行完毕的时候 依然要进行部署 软件光盘生产 客 户支持 升级补丁包开发和测试等多项工作 这阶段主要的参与者是项目经理 少量的开 发人员和测试人员 售后技术支持人员 客户服务人员等 1 1 12 软件发布的方式 按照目前的软件发布方式 一般有 RTM Ready To Market 市场发布 RTW Ready To Web 在网络上发布 RTO Ready To Operation 可以运营 等多 种方式 RTM 方式需要在工厂进行光盘的复制生产 用户购买光盘后安装 大部分的操作 系统和应用软件采用这种方式的比较多 RTW 方式需要在网络上提供下载链接 一般的软件升级包或者游戏软件采用这种 方式的比较多 RTO 方式则很简单 在服务器上部署软件产品 用户购买其中的某项或者多项服 务即可 这是大部分网站或者在线游戏采用的方式 1 1 13 项目管理与甘特图 前面提到软件项目的流程很重要 那么这种流程的控制一般是由项目经理来完成的 第 1 篇 Web 测试背景知识 8 他或者她所从事的这个工作叫做项目管理 小白所在的技术部门一般一周都要开一个例会 在会上 开发部门 测试部门和项目 经理都要对上一周各自所做的工作进行一番总结 安排下周将要做的工作 在这样的例会 上 同事们经常会查看项目的进度图来进行讲解 他们把这样的进度图称为甘特图 Gantt Chart 如图 1 4 显示的是软件开发过程中常用的项目管理工具 Microsoft Office Project 软件 在这里是 2003 版本 最新为 2007 版本 运行的界面 在其中我们可以清楚地看到软件 生命周期中的各个子任务的时间分配 负责人员和项目进度的甘特图 图 1 4 Project 2003 中的甘特图 甘特图的来历 甘特图的名称由发明者亨利 劳伦斯 甘特 Henry Laurence Gantt 1861 1919 而 来 甘特早年从事的是电气工程师的职业 后来转而从事管理业界的咨询 甘特图是他在 晚年发明的一种用于显示项目计划和进度的图表 在诞生的初期 甘特图就被誉为 20 世 纪 20 年代的最重要发明之一 广泛应用于一系列的大工程之中 比如 1931 年前后修建的 美国胡佛水坝 如果你看过 2007 年的热门电影 变形金刚 那么对关押威震天的那个 水坝应该有印象 它就是胡佛水坝 在软件开发领域 很多公司也应用甘特图这一工具 来进行项目管理 比如著名的微软公司 1 2 关于虫子的故事 在熟悉了公司的结构 开发流程 参与了部门例会之后 小白要开始从事具体的软件 测试工作了 对于他来说 这一领域陌生而令人兴奋 在刚上班的一周内 小白不断地听到周围的测试工程师高兴得喊道 又发现 Bug 了 看着他们那兴奋的样子 小白也有点跃跃欲试 想赶紧在捉虫的战场上大展身手 那么 什么是 Bug 呢 它为什么这么重要 发现 Bug 为什么这样兴奋 第 1 章 什么是软件测试 9 1 2 1 虫子的来世今生 在本章的序幕部分 我们已经了解了很多由于软件代码的问题使得事情失败的案例了 它们有的后果真的很严重 甚至能够造成对生命的威胁 这肯定不是软件设计者和开发者 想要达到的目标 因此 出现这样的情况可以说是软件的错误 细细的分起来 软件的错误有如下几个词语来描述 缺陷 偏差 错误 问题 事故 异常 在这一堆词语当中 除了偏差之外 其他的 词语所造成的后果给人的感觉都相当严重 所谓偏差 就是软件在使用过程中 和软件设 计说明 product specification 所不一致的行为 那么为什么将这样的软件问题称为 Bug 呢 这里面还有一个故事 史上第一个软件 Bug 该词的原意是 臭虫 或 虫子 1947 年 9 月 9 日 正值计算机刚刚被发明的时 候 哈佛大学的某个计算机实验室正在做实验 由于当时的原始计算机由很多庞大且昂贵 的真空管组成 运行时会产生光和热 在下午 15 点 45 分的时候 一个飞蛾 英文是 Moth 钻入了真空管内 导致整个计算机无法工作 当把这只小虫子从真空管中取出后 计算机又恢复正常 后来 虫子的泛称 Bug 这个名词就沿用下来 而那个被拍死的飞蛾 也成为了历史上发现的第一个 Bug Bug 渗透到日常生活中 一般来说 拥有一定知识产权的产品的错误都能称之为 Bug 这方面有一个我们比较 熟悉的例子就是电影 影迷们经常议论某热门电影中出现了所谓的 穿帮 镜头 比如在 描述古代武侠的影片中天空掠过一架飞机 主角刚才是右脸有伤痕 过一会变成左脸等 这样的镜头也可以说是 Bug 甚至还有专门的网站来记录这些影迷的细心发现 比如 1 2 2 软件 Bug 的 5 个要素 前文笼统解释了软件 Bug 是软件的错误或者偏差 那么在具体的工作中 小白如何 判断软件的行为是 Bug 呢 说来简单 根据软件设计阶段形成的功能说明书 英文为 Specification Document 一般简称 Spec 对于具体的判断标准 经理介绍了如下 5 个要素 软件没有实现说明书中所列出的功能 软件出现了说明书中提到不应出现的事情 软件实现了说明书中没有提到的功能 软件没有实现说明书中没有提到但应该实现的功能 软件非常难于学习 使用 运转速度很慢 用户认为无法达到预期 为了充分理解上述 5 个要素 小白自己打开了 Windows 系统中最简单的一款软件 Notepad 也就是我们平时 不屑于 用到的记事本程序 开始了自己的思考 第 1 篇 Web 测试背景知识 10 1 软件没有实现说明书中所列出的功能 对于 软件没有实现说明书中所列出的功能是 Bug 这一点是比较好理解的 如果打 开记事本软件 却无法在其中输入汉字 或者输入了文本 无法保存成文件 那么肯定是 一个很重要的 Bug 2 软件出现了说明书中提到不应出现的事情 对于第 2 点 软件出现了说明书中提到不应出现的事情也是 Bug 这一点和小白 的性能测试工作有相对更紧密的关系 小白要测试的是公司的网站 它要求用户在浏览网 站时显示页面尽可能地快 如果超出 5 秒钟则认为是不可接受的 这个 超出 5 秒钟 就 是说明书中提到不应该出现的事情 实际出现后肯定是一个 Bug 需要开发人员找出哪里 耗费了页面显示时间 在记事本程序中 如果程序保存文件时出现了程序崩溃 Crash 现象 即属于此类 3 软件实现了说明书中没有提到的功能 软件实现了说明书中没有提到的功能也是 Bug 这一点可能有点难于理解 一个软件 功能难道不是越多越强大吗 其实不尽然 实现额外的功能有如下几个缺点 如表 1 3 所示 表 1 3 软件实现说明书中未提到功能所带来的问题 缺 点说 明 代码量增大 由于代码可能相互影响 因此这部分额外的功能可能对其他 功能的实现造成影响 带入新的 Bug 增加额外的开发 测试时间 在软件项目时间固定的情况下 导致投入到其他必备功能的 开发测试时间减少 可能影响它们的完成质量 增加了成本 与软件的宣传不完全符合 虽然用户对于增加功能一般不会有意见 但可能影响了公司 的销售策略和市场定位 4 软件没有实现说明书中没有提到但应该实现的功能 小白一般是将网上找到的有用文档保存在随身携带的 U 盘中 这一次 他在测试记 事本程序的时候 同样打算将文件保存在 U 盘上 可是由于连日来的文档太多了 优盘 已经没有空间 记事本提示无法保存 同时系统托盘有提示说磁盘空间已满 在这种情况 下记事本的行为 就属于实现了说明书中没有提到却应该实现的功能 在磁盘满的情况下 给用户以提示 如果没有提示 不符合绝大部分用户的使用习惯 也是一个 Bug 5 软件难于使用 性能差 软件是拿来用的 再好的界面使用不方便也不会产生多大效果 一个网站如果半天都 打不开 很难想象还会有多少用户会访问它 因此这样的问题也是 Bug 而且对于性能测 试来说 这一个规则很重要 第 1 章 什么是软件测试 11 1 2 3 发现虫子的危害 既然软件 Bug 对产品造成了这么多的影响 那么发现它就显得非常重要了 业内人 士都认为 在软件生命周期内的不同阶段发现 Bug 所节省的成本是不同的 如图 1 5 所 示 图 1 5 软件生命周期内各阶段发现与改正 Bug 所需成本示意图 从图中可以看出 在产品设计阶段发现 Bug 要比在产品维护阶段发现好得多 这是 很好理解的 在需求分析阶段 对于用户需求的理解停留在需求文档中 对其中理解不正确的 部分只需要修改文档即可以 基本不会产生什么成本 在软件设计阶段 发现的 Bug 很多都是设计思想的缺陷 由于尚未开始编码 这 样的 Bug 一般需要进行深入的讨论最终获得一种正确的结论 因此改正成本也 不高 在软件编码阶段和测试阶段 代码通过开发人员和测试人员的努力在进行不断的 完善 有关 Bug 的成本主要花费在项目内部的沟通与时间成本方面 但是一旦产品发布 在软件维护阶段发现的 Bug 其修改成本会非常高昂 一是 因为软件成为了系统 与开发阶段重点检查各模块功能相比更为复杂 寻找代码 上的产生 Bug 根源更加困难 特别是 如果前期工作没有做好的话 甚至软件产 品的结构都需要进行大修改 二是因为牵扯的部门明显增加 比如客户服务部门 产品部署部门 销售部门等都要参与 导致公司内部 公司与客户之间的沟通成 本急剧增加 第三点则是影响产品质量与公司的信誉 未来产品的销售 千年虫的问题 在前几年 有一个著名的虫子把业内搅得不可开交 那就是千年虫问题 也叫做 2000 年问题 它是指在某些使用了计算机程序的智能系统 比如一般的计算机系统以及 自动控制芯片等 中 由于其中的年份沿用早期的设计 只使用 2 位十进制数来表示 比 如用 80 代表 1980 年 因此当系统进行 或者涉及到 跨世纪的日期处理运算 比如计算 第 1 篇 Web 测试背景知识 12 1980 年到 2080 年之间的日期 时 就会出现错误的结果 从而引发各种各样的系统功能 紊乱甚至系统崩溃 从千年虫的实际例子中也可以看出 不考虑硬件上的限制 如果当初在设计日期表示 格式的时候能够想得更长远一些 就完全可以避免这个虫子的发作 从而节省一大笔修改 更新软件等的费用 据未经证实的来自美国国际资料公司调查报告表明 光是 1995 年到 1998 年 全球捉 千年虫 的开销就已经达到惊人的 1840 亿美元 1 3 软件测试的定义与分类 前文花费了不少文字来讲述 Bug 的定义 危害和判断原则 本节将在更广的范围内 介绍软件测试的定义与分类 1 3 1 软件测试的定义 软件测试就是利用一定的方法对软件的质量或者使用性进行判断和评估的过程 这一 定义获得了较广泛的认同 1 3 2 软件测试工程师的工作内容 软件测试是由软件测试工程师来完成的 他们的主要工作内容则是 寻找软件中的 Bug 并且是越早发现越好 原因见 1 2 节 确认 Bug 的可重复性 Repro 以及 Bug 产生的步骤 确认 Bug 是否被解决 Fixed 测试方法 测试计划 测试平台 测试代码 测试用例 测试文档 测试报告的 确定 编写和执行 对于小白这样刚入职的新人来说 主要工作就是前 3 项以及测试用例的编写了 在 1 4 节将讲述测试用例的知识 1 3 3 软件测试的分类 软件测试可以有很多种分类 常见的有如下一些 黑盒测试 Black box testing 白盒测试 White box testing 功能性测试 Functional testing 兼容性测试 Compatibility testing 性能测试 Performance testing 安全测试 Security testing 压力测试 Stress testing 虽然看起来很多很复杂 但是目前 小白所要做的工作就是先熟悉这些名词 这样在 第 1 章 什么是软件测试 13 阅读众多的技术文档时 了解这些名词属于软件测试的范畴就可以了 对于软件测试的两个核心 则有必要在第 1 章详细的介绍 这两个核心分别是测试用 例和测试工程师 分别代表了软件测试的两个方面 工具和人 1 4 软件测试的核心 I 测试用例 前文提到 测试用例代表了软件测试的工具方面 是它的核心之一 那么什么是测试 用例 它又有哪些要点需要我们去掌握 1 4 1 什么是测试用例 软件测试的核心行为就是针对要测试的软件设置测试用例 所谓测试用例 英文名为 Test Case 是一个与程序部分行为以及输入 输出相关的描述或者标识 测试用例的 IEEE 定义 美国电气与电子工程师协会 IEEE The Institute of Electrical and Electronics Engineers 它出台了一个标准的测试用例定义 即 测试用例是描述输入实际值和预期 输出行为或者结果的文档 它同时也标识了测试过程结果与约束 在实际工作中 花费测试工程师大部分时间的 都是与测试用例相关的 1 4 2 测试用例的几大要素 一般来说 测试用例应该清楚地描述出对被测试软件发出什么数据或者条件 以及该 输入所期望的结果 在小白这样的商业网站 测试部门规定测试用例应该具备如下几个 要素 1 标识符 这一点虽然和测试用例的内容没有关系 但却是测试过程中不可缺少的 比如 小白 所在的部门每周都要开一次例会 向经理或者开发部门的同事说明当前整个产品的测试状 态 有时候需要特别指出某个测试用例的内容 那么用一个简单的代号来代表这一测试用 例是非常适合的 这个代号一般情况下都是一个正整数 比如 1 88 437 等这样 在小 白所在的公司 测试用例是存放在一个数据库中的 代号也就自然地采用了数据库系统中 的标识符字段类型 如果采用其他的方式存储测试用例 可以人工指定 只要保证标识符 不重复就可以了 如图 1 6 显示了应用于真实测试场景的某测试用例文档 它实际上是一个 Office Word 文件 测试工程师 即编写者 在文件内容中手工指定了各个测试用例的标识符 第 1 篇 Web 测试背景知识 14 图 1 6 测试用例的标识符 2 测试的内容 测试内容可以说是测试用例最重要的部分 它一般指明了当前测试用例的运行目的 比如测试网页是否可以打开 单击按钮后是否能够显示正确的计算结果等 在很多情况下 测试内容与下个要点 输入的条件区别并不是很清楚 3 输入的条件 输入条件可以是操作步骤 也可以是输入的数据 还可以是系统运行环境的需求 比 如处于某种特别的操作系统环境内这一条件 图 1 6 中的各个测试用例 都详细地写明 了每一步骤的具体操作 复现步骤 对于被测试软件而言 不同的输入条件会导致不同的输出预期 因而可能出现的 Bug 表现并不一定相同 如果重复某些输入条件 总会导致某个 Bug 的出现 那么就把这些 输入条件称为 Bug 的复现步骤 Repro Step 4 输出的预期 该项信息描述了在当前的输入条件下 预期的输出 比如计算器程序中十进制数字的 2 3 的输出应该等于 5 若输出预期与实际结果不同 则应该考虑为 Bug 的可能性 有的 时候 输出预期也会随项目的进度而变化 因此预期与实际不同并不意味着 100 是 Bug 此时需要与项目经理等相关人员进行协商 第 1 章 什么是软件测试 15 5 测试环境信息 这一部分的内容描述了该测试用例所适用的环境 比如操作系统的版本 所依赖硬件 软件的版本 语言等 测试环境信息有时候也可以成为输入条件或者复现步骤的一部分 比如某个按钮只有在 IE 浏览器中才会出现 某个 Bug 只在 IE 浏览器中才会产生 那么 IE 既是测试环境信息 也是输入条件和复现步骤 6 与其他测试用例的依赖关系 在测试某些软件的时候 比如 MSN 如果登录这个测试用例都无法通过 那么剩下 的发消息 发文件等测试用例也肯定继续进行 除去直接调用接口的那些测试之外 这 就是一种测试用例之间的依赖关系 合理地应用测试用例之间的依赖关系 能够提高测试 效率 减少无谓的测试时间浪费 7 测试用例需要被开发 审阅 使用 维护和保存 这也是测试工作很重要的一部分 软件的说明书 Spec 可能会变化 因此测试用例需 要变化 这就要求对测试用例进行增加 修改和删除 测试用例是文档 需要有固定的场 所进行保存 一般是数据库或者文件 测试用例需要审阅 以达到预期的效果和更高的工 作效率 重复的测试用例肯定会浪费测试工程师的时间 1 5 软件测试的核心 II 测试工程师 除了测试用例之外 软件测试的另一个核心 同时也更为关键 就是测试工程师了 这是因为 测试用例也是由测试工程师来编写的 受人的因素影响很大 可以说 人是决 定软件成败的主要因素 本节将介绍测试工程师所必备的一些素质 1 5 1 测试工程师与软件质量保障 有的时候我们在招聘广告上能够发现有些公司招聘测试人员的时候 列出的职位名称 是软件质量保障工程师 QA quality assurance 那么这两种称呼是否是代表同一种工 作内容呢 回答是基本一样 但有细微不同 软件测试工程师的主要职责在于发现并确认 Bug 的解决与否 而软件质量保障工程师则更进一步 在测试工程师的职责之外 还包括创建 维护为保障软件质量而确立的规范 规则与流程 比如软件配置管理 Software Configuration Management 又称 SCM 工程师 等 字面意义的理解 从字面意义上来看 测试工程师主要针对软件的已有 Bug 类似体检部门 而软件质 量保障工程师则不光针对已有 Bug 还对预防 Bug 的产生提出建议 类似健康顾问 当然 在实际工作中 两者的区别并不是那么清晰的 在很多公司内部 他们所从事的工作内容 是完全一致的 第 1 篇 Web 测试背景知识 16 1 5 2 测试工程师应该具备的素质 一个合格的测试工程师 应该具备如下专业素质 具备基本的数据结构 操作系统等专业知识 这一点对于从事性能测试的人员来 说更为重要 具备一定的程序开发经验 掌握一到两门语言对于进行自动测试是大有益处的 另外 具有程序开发经验 也更容易理解软件 Bug 的来龙去脉 这一到两门语言 可以是某些高级语言 比如 C 和 VB net 以及一种脚本语言 比如 JavaScript VBScript 或者 Python 等的组合 软件使用经验丰富 对于软件的不正常行为敏感 这一点对于发现 Bug 是很有帮 助的 同时 测试工程师还应该具备如下的性格特征 有好奇心 乐于探索软件功能 乐于尝试新的软件产品 乐于探索谜题 追根溯源 对于一个 Bug 必须有追根溯源的精神 才能够发现 它的特点 这个性格特征在判断 Bug 的产生原因 以及是否与其他 Bug 重复等日 常的工作内容中都会展现 有耐心 不轻言放弃 测试工程师在工作中经常会试图复现一个软件中