一个自动测试实战项目案例曹炼

《一个自动测试实战项目案例曹炼》由会员分享，可在线阅读，更多相关《一个自动测试实战项目案例曹炼（80页珍藏版）》请在金锄头文库上搜索。

1、第十四章一个自动测试实战项目案例 主讲人：徐光侠本章内容提要 测试项目案例介绍 自动测试计划 自动测试用例的设计 自动测试脚本开发 自动测试脚本的运行和调试 自动测试结果分析 14.1 测试项目案例介绍 本测试项目案例是软件学院前期 制作的一个小型学习交流平台（ 如图10-1所示），它是基于J2EE 开发代码的内容管理系统（CMS ）上搭建的。该学习交流平台实 现的主要功能是发布信息、交流 论坛、下载文件等，使得学院内 之间建立更活跃的互动关系。 和大多数的论坛管理系统一样， 本系统的主要功能可以分为用户 管理、技术文章管理、论坛管理 和文件下载这几个主要模块和其 他非功能模块。根据用户的实际

2、 需求，使用面向对象技术分析一 下各主要功能模块的用例（Use Case）图。项目案例-在线学习交流平台 1用户管理：用户管理模块主 要实现用户的注册、登录、用户 信息修改、用户短信的发送和接 收、用户好友的添加和删除、管 理员对用户信息和权限的维护。 如图所示，这里有两种不同的角 色，即一般用户（会员）和管理 员（admin），管理员通过后台 的用户管理模块对一般用户的权 限、短信、好友进行管理。他们 的操作过程如下： （1）一般用户：注册登录用户信息维护。 （2）管理员：后台登录用户信息维护用户权 限管理。2会员中心管理：会员中心模块 主要实现用户短信的发送和接收 、用户好友的添加和删除。

3、如图 10-3所示，这里有两种不同的角 色，即一般用户（会员）和管理 员（admin），管理员通过后台 的用户管理模块对一般用户的短 信、好友进行管理。他们的操作 过程如下： （1）一般用户：登录用户短信收发 （2）管理员：后台登录用户短信管理 （3）一般用户：登录用户好友维护 （4）管理员：后台登录用户好友管理3技术文章管理：技术文章管理分为技术文章维护 和技术文章查看两部分。如图10-4所示，管理员 可以对发布信息进行维护，一般用户只能在前台 查看信息。4论坛管理：论坛提供几个版块的设置，如学习交 流、社会生活等，能够实现发帖和回帖等功能。 如图所示，版块的设置和管理是管理员独有的权 限，

4、发帖和回帖是一般用户的权限。5文件下载：文件下载分为下载内容管理和下载文 件两部分。如图10-6所示，管理员可以对下载内 容进行维护，一般用户只能查看下载内容和下载 文件。 6访客留言：分为访客留言管 理和访客留言两部分。管理员可 以对访客留言进行管理，一般用 户和其他非登录用户只能查看留 言或进行访客留言。 7站内搜索：任何用户在系统 的首页可以使用关键字对技术文 章的标题进行站内搜索。 8在线论坛搜索：一般用户在 在线论坛的版块主题下，可以对 发帖的标题进行关键字搜索。14.2 自动测试计划 自动测试计划是整个项目计划的一部分，更 是整个测试计划的重要组成部分。作为一个 小型项目，自动测试

5、计划可以作为测试计划 的一部分来说明。14.2.1 自动测试方案的选择首先，结合“重要事情优先做”的原则， 要先要握自动化产品的关键和基本功能。在 选择自动测试用例的时候，一定要选择比较 适合自动测试的用例，这对于整个项目都有 很多好处，不仅能提供软件测试的能效比， 还可以降低自动测试的引入风险和成本，让 自动测试在软件测试中真正地、循序渐进地 应用。其次，在选择自动测试脚本编写方 法时要结合“降低测试成本”的原则。 在刚刚入门编写自动测试脚本时，往往 会感到整体代码不规范，代码复用性很 差。这样会增加项目成本，因此有必要 采用结构化的编码方法。测试脚本的结 构化对项目而言有很多好处，能使代码

6、 结果清晰、便于脚本维护、降低维护成 本；增加复用程序，降低开发成本；能 够实现代码的统一管理，降低管理成本 。但是过于追求结构化，放弃很多QTP提 供的“录制”功能，这本身又是一种对 开发成本的无谓增加。怎样找到这个平 衡点，是自动测试成本分析的工作目的 。本测试项目案例所选用的软件属于中小型 应用软件，其特点为运行周期较短，版本更 新较快，需求变更较频繁。针对此软件的自 动测试创建遵循如下规则： 选择重要功能的测试用例作为高优先级。选择需求不经常变更的模块的测试用例作为高优先级。 选择自动化可测试性高、符合团队技术特点、容易实现自动 化的测试用例作为高优先级。选择重复执行比率高的测试用例作

7、为高优先级。鉴于读者都是初次接触自动测试，采用录制回放和结构化的 测试脚本编写方法。对于用户界面的输入可引入数据驱动的脚本编写方法。14.2.2 自动测试计划的内容1测试目标根据自动测试需求分析的结果对可以自 动化的模块及其手工测试用例进行自动测试 。本次自动测试过程需要3名自动测试人员在 15天内完成自动测试脚本并运行，分析运行 结果，并提交“项目自动测试报告”。14.2.2 自动测试计划的内容2项目概述本测试项目案例是软件学院前期制作的一 个小型学习交流平台，它是基于J2EE开发代 码的内容管理系统（CMS）上搭建的。该学 习交流平台实现的主要功能是发布信息、交 流论坛、下载文件等，使得学

8、院内之间建立 更活跃的互动关系。14.2.2 自动测试计划的内容3测试对象 （1）注册 （2）修改个人信息 （3）登录 （4）在线论坛管理 版块的设置 发帖 回帖14.2.2 自动测试计划的内容4测试环境测试环境分为软件环境和硬件环境。由于 兼容性等问题，不同的软硬件环境会产生不同 结果，而一些客观的原因决定不可能对所有的 环境进行测试，因此需要分析现在用户主流软 件环境，以满足大部分用户的需求。同时，当 软件升级时也可考虑更多的兼容性。对于硬件 环境没有特殊的要求，只要配置的性能足够高 。软件测试的软硬件环境可以按照如表14-1和 14-2所示进行归类和划分。14.2.2 自动测试计划的内容

9、14.2.2 自动测试计划的内容 由于自动测试工具本身也存在兼容性等问题，因此需要选 择适合于自动测试工具运行的客户端软件环境。QTP10.0对 应Window 2003、FireFox等软件环境的兼容性比较差，为适 应工具的运行，可以指定一类客户端测试环境。本项目的客 户端软件配置如表14-3所示。5项目通过标准自动测试项目的通过标准如下： 自动测试用例和数据包达到100%需求 覆盖。自动测试用例100%被执行。测试过程中缺陷率达到公司系统测试 质量标准。经测试经理和资深自动测试工程师审 核通过。6项目挂起和恢复条件自动测试项目的挂起条件如下：测试流程管理工具或测试工具等环境要素出现故 障。

10、基本功能出现致命问题，导致50%用例被堵塞， 自动测试无法执行。用例版本质量太差，50%执行用例无法通过，自 动测试执行无意义。出现其他突发事件，需要对其他产品优先测试。 自动测试项目的恢复条件如下：导致测试堵塞的问题被修复，并通过了回归测试。测试工具等环境因素被修复。用例版本质量得到较大改善。突发事件处理完成，可正常进行测试。14.2.2 自动测试计划的内容7资源分配 物力资源为配有QTP10.0的Window XP计算机3台， 人力资源的配置如表14-4所示。14.2.2 自动测试计划的内容8时间安排 自动测试周期预计为15天，具体安排如表14-5所 示。14.2.2 自动测试计划的内容9

11、各阶段提交文档自动测试计划。自动测试用例。自动测试工作周报。自动测试报告。14.2.2 自动测试计划的内容10风险管理 启动自动化测试的假设如下： 手工测试用例100%执行并通过。 E测论坛至少上线运行3周并且被测模块没有发生致命缺陷。 可能存在的风险如下： 计算机软件/硬件故障。 规避方案：准备备用机器（虚拟机）。 测试人员没有实际参加过项目，可能对测试产生一定的影响 。 规避方案：增加评审的频率和力度。 自动测试人员突发性事假/病假/离职导致项目无法继续开展 。 规避方案：从其他组抽取1名资深自动测试工程师或高级自动 测试工程师，一直参与自动测试项目的所有会议并作为应急人 员。14.3 编

12、写自动测试用例 14.3.1 自动测试用例的设计v 在编写自动测试用例前需要对自动测试用例进行 设计。我们采用分类设计是因为不管多么复杂的 事情，只要按照某个原则对其进行分类，思路就 会变得清晰，就会让复杂问题简单化。在分类时 我们结合测试的对象、测试的内容和测试的方法 进行综合分析。 v 在上一节测试计划中我们按照功能模块的划分选 择了测试的对象。从测试内容的角度上讲又可以 分为用户界面（UI）、功能、性能、产品的安装 与卸载。我们的测试内容只考虑UI和功能测试。 而测试方法有很多，在基础中我们用了很大的篇 幅进行了叙述，像等价类划分法、边界值法、因 果图法和错误推测法等。14.3.1 自动

13、测试用例的设计下面我们采用测试用例分类设计的方法，选取重点模块，即测试的对象分 类；每个对象都要从测试的角度进行测试内容的分类；每个内容都要 以熟悉的测试方法进行测试方法的分类。测试的内容包括如下： （1）注册 （2）修改个人信息 （3）登录 （4）在线论坛管理 版块的设置 发帖 回帖14.3.1 自动测试用例的设计同时在设计测试用例的时候还要遵循以下的原则：（1）场景选择的方法：选择操作过程相同的一些测试需求，来组成用例场景，使用测 试用例结构化指导测试脚本的结构化。（2）场景包含用例的复杂度：场景包含的用例不能太多，当一个场景包含的用例数大 于15时，可以考虑对场景进行分拆。 相互独立的测

14、试用例，使测试用例之间在逻辑上没有线性关系，不至因一个用例的 错误而导致连锁错误。 基于拥有前置数据的测试用例，每一个用例需要有前置的数据，避免这些数据必须 通过其他脚本的执行来生成，这样从数据上消除脚本的线性依赖。 基于同一起始点的测试用例，需要让每个用例都从一个已知的条件出发。当程序第 一次执行时，会从一个前置条件出发，生成一定的测试结果，这样已经对前置数据进行 了修改，因此需要提供数据恢复方法，保证测试执行每一次出发点是相同的。 不要设计相同的测试用例。每一个用例的设计不是随意选择的组合，需要根据一些 测试用例的方法来开发完成，这些常用的技术包括等价类划分、边界值分析、决策逻辑 表等 ，

15、通过这些方法的组合来达到使用最少的测试用例来测试最大的测试覆盖面的目 的。接下来，我们对被测试的对象模块进行举例。14.3.1 自动测试用例的设计v 1注册 测试对象：注册。 测试内容：UI测试。 测试方法：等价类划分、边界值。 一般用户注册的UI如图所示，从图14-1的主页上单击“注册”，就会显示用户的 注册页面。14.3.1 自动测试动测试用例的设计设计v 注册模块的场景一为注册页面的各个输入域。使用等价类划分和边界值法对“ 用户名”域进行设计，我们可以得到如表14-6所示的5个测试用例。 14.3.1 自动测试用例的设计 使用等价类划分和边界值法对其他3个必填项“密码”、“重复密码 ”、

16、“电子邮件”进行设计，可以得到和表14-6类似的测试用例。对 6个选填项用同样的设计也可以得到类似的测试用例。对于“验证码”，输入为空和输入不匹配都提示“验证码对比错误” 提示框。对于重复密码是否和密码一致的一致性检查也要作为测试用例。至此，我们对注册页面场景一的测试用例设计完毕。场景二是提交注册信息，即在注册页面填入合法信息，单击“提交” ，注册信息提交成功，页面显示注册的个人信息，检查显示的个人信 息是否与刚才填入的信息一致。在设计测试用例时我们设计的是黑盒 测试用例，不需要知道输入的注册信息是否成功地写入数据库，用户 通过浏览器是否成功地读取数据库中的注册信息，只需要检查浏览器 上显示的个人信息是否与输入的一致。14.3.1 自动测试用例的设计v 2登录 测试对象：登录 测试内容：功能测试。 测试方法：错误推测、等价类划分。 该系统