关于手机软件测试技术的学习与研究 毕业论文

图书分类号：

密级：

毕业设计(论文) 题目：关于手机软件测试技术的学习与研究

学生姓名

班级

学院名称

专业名称

指导教师

学位论文原创性声明

本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独立进行研究工作所取得的成果。除文中已经注明引用或参考的内容外，本论文不含任何其他个人或集体已经发表或撰写过的作品或成果。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标注。

本人完全意识到本声明的法律结果由本人承担。

论文作者签名：日期：年月日

学位论文版权协议书

本人完全了解关于收集、保存、使用学位论文的规定，即：本校学生在学习期间所完成的学位论文的知识产权归所拥有。有权保留并向国家有关部门或机构送交学位论文的纸本复印件和电子文档拷贝，允许论文被查阅和借阅。可以公布学位论文的全部或部分内容，可以将本学位论文的全部或部分内容提交至各类数据库进行发布和检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。

论文作者签名：导师签名：

日期：年月日日期：年月日

关于手机软件测试技术的学习与研究

摘要：近年来，随着智能手机的产生以及不断发展，智能手机的应用大范围增加，手机软件的质量要求也就越来越高，也只有高质量的软件，才能满足人们对手机功能的需求。智能手机已经完全渗透到人们工作和生活中。同时，手机的软件质量特别重要，手机软件优秀程度如何，直接关系到整个公司的产品销售的情况。现在的智能手机的市场竞争也越来越强烈，近年来，各个企业都与千元智能手机作为公司的主打机，以此来赢得市场。

软件测试在软件生存期非常重要，工作量和开销占将近一半，是保证软件质量的主要手段，对于查找软件缺陷、保证产品质量，提高企业效益具有不可替代的作用。据统计，国外在软件开发中，开发费用的近一半甚至更多要用于软件测试，由此也可以看出软件测试在软件开发中的重要地位。

关键词：测试的意义、测试流程、测试用例、BUG、白盒测试、黑盒测试

目录

第一章引言 (3)

一、软件测试的背景和意义 (3)

1、软件测试的背景 (3)

2、软件测试的意义 (3)

二、软件测试的定义与概述 (3)

1、软件测试的定义 (3)

2、软件测试的概述 (3)

三、软件测试的基本原则 (4)

第二章软件测试的流程与内容 (5)

一、测试流程简介 (5)

二、软件测试的内容 (6)

1、正确性测试 (6)

2、容错性测试 (6)

3、性能与效率测试 (6)

第三章软件测试的分类 (5)

一、常用分类 (7)

二、白盒测试和黑盒测试 (7)

三、静态测试 (10)

四、动态测试 (10)

第四章提交BUG定义与提交技巧 (12)

第五章软件测试技术拓展 (13)

一、用例编写与原则 (13)

1、设计概述 (13)

2、功能测试用例 (13)

3、性能测试用例 (14)

二、开发修改 (15)

三、回归测试 (15)

1、简述回归测试 (15)

2、回归测试策略 (15)

参考文献 (16)

致谢 (21)

第一章引言

一、软件测试的背景和意义

1、软件测试的背景

随着智能手机的广泛应用，手机软件的质量要求也就越来越高。落后的软件生产方式无法满足日趋复杂大型软件系统的开发需求。手机是属于消费品，随着用户对手机有着不同的要求，从只能简单通话的手机到3G的智能手机，手机所扮演的不再是一个简单的通话工具，而是成为人们办公、娱乐的得力助手。随着手机功能越来越多，只有高质量的软件，才能满足人们对手机功能的需求。

软件测试在软件生存期非常重要，工作量和开销占将近一半，是保证软件质量的主要手段，对于查找软件缺陷、保证产品质量，提高企业效益具有不可替代的作用。

2、软件测试的意义

软件测试是保证软件质量的重要手段，软件测试深入软件开发过程中每个阶段，在有限的开发条件下，最大程度地保证最终软件产品符合用户需要。只要拥有高质量的软件，对提高企业效益就有很大的帮助。

二、软件测试的定义与概述

1、软件测试的定义

软件测试使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。

(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进；

(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性；

(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法。

2、软件测试的概述

测试是软件开发过程的重要组成部分, 是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的, 第一是确认软件的质量, 其一方面是确认软件做了你所期望的事情（Do the right thing）, 另一方面是确认软件以正确的方式来做了这个事件（Do it right）；第二是提供信息, 比如提供给开发人员或程序经理的反馈信息, 为风险评估所准备的信息；第三软件测试不仅是在测试软件产品的本身, 而且还包括软件开发

的过程。如果一个软件产品开发完成之后发现了很多问题, 这说明此软件开发过程很可能是有缺陷的。

三、软件测试的基本原则

软件测试时为了使软件质量得到改善，以确保满足产品的需求。在设计有效测试用例之前，测试工程师必须理解软件测试的基本原则，具体有以下原则：

（1）、所有的测试都是为了满足用户的需求。

（2）、在测试开始之前，拟好测试计划。

（3）、应尽早地和不断地进行软件测试。

应当把软件测试贯穿到整个软件开发的过程中，而不应该把软件测试看作是其过程中的一个独立阶段。因为在软件开发的每一环节都有可能产生意想不到的问题，其影响因素有很多，比如软件本身的抽象性和复杂性、软件所涉及问题的复杂性、软件开发各个阶段工作的多样性，以及各层次工作人员的配合关系等。所以要坚持软件开发各阶段的技术评审，把错误克服在早期，从而减少成本，提高软件质量。

（4）、对测试用例要有正确的态度

第一，测试用例应当由测试输入数据和预期输出结果这两部分组成；第二，在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件。因为软件投入实际运行中，往往不遵守正常的使用方法，进行了异常操作，就很容易产生一系列的问题，轻则输出错误的结果，重则瘫痪失效。因此常用一些不合理的输入条件来发现更多的鲜为人知的软件缺陷。

（5）、人以群分，物以类聚。

软件测试也不例外，一定要充分注意软件测试中的群集现象。不要以为发现几个错误并且解决这些问题之后，就不需要测试了。反而这里是错误群集的地方，对这段程序要重点测试，要经过反复测试，才能真正地解决问题，这样才能提高测试投资的效益。

（6）、严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作。在测试过程中，要仔细，不能有半点马虎，这样才能找出问题的所在，以便更快地解决问题。

（7）、应当对每一个测试结果进行全面检查。一定要全面地、仔细地检查测试结果，但常常被人们忽略，导致许多错误被遗漏。

（8）、妥善保存测试用例、测试计划、测试报告和最终分析报告，以备回归测试及维护之用。

第二章软件测试的流程与内容一、测试流程简介

以下是软件测试主要流程图：

二、软件测试的内容

1、正确性测试

正确性测试又称功能测试，它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素，所以其测试也最重要。

2、容错性测试

容错性测试是检查软件在异常条件下的行为。容错性好的软件能确保系统不发生无法意料的事故。比较温柔的容错性测试通常构造一些不合理的输入来引诱软件出错。

3、性能与效率测试

性能与效率测试主要是测试软件的运行速度和对资源的利用率。性能与效率测试中很重要的一项是极限测试，因为很多软件系统会在极限测试中崩溃。

第三章软件测试的分类

一、常用分类

从是否需要执行被测软件的角度, 可分为：

静态测试、动态测试

从测试是否针对系统的内部结构和具体实现算法的角度来看, 可分为：

白盒测试、黑盒测试

二、白盒测试和黑盒测试

1、黑盒测试和白盒测试

黑盒测试

指的是把被测软件看作是一个黑盒子, 我们不去关心盒子里面的结构是什么样子, 只关心软件的输入数据和输出结果。

黑盒测试方法是在程序接口上进行测试, 主要是为了发现以下错误:

是否有不正确或遗漏了的功能?在接口上, 输入能否正确地接受? 能否输出正确的结果?是否有数据结构错误或外部信息(例如数据文件)访问错误? 性能上是否能够满足要求? 是否有初始化或终止性错误?

用黑盒测试发现程序中的错误, 必须在所有可能的输入条件和输出条件中确定测试数据, 来检查程序是否都能产生正确的输出。但这是不可能的。

n假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数, 按黑盒方法进行穷举测试：

n可能采用的测试数据组：232×232＝264 n如果测试一组数据需要1毫秒, 一年工作365× 24小时, 完成所有测试需5亿年。

黑盒测试的测试用例设计:等价划分法、界值法、推测法、果图法

1.等价类划分

1>等价类划分是一种典型的黑盒测试方法, 使用这一方法时, 完全不考虑程序的内部结构, 只依据程序的规格说明来设计测试用例。

2>等价类划分方法把所有可能的输入数据, 即程序的输入域划分成若干部分, 然后从每一部分中选取少数有代表性的数据做为测试用例。

3>使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。

4>划分等价类

等价类是指某个输入域的子集合。在该子集合中, 各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。

等价类的划分有两种不同的情况：

①有效等价类：是指对于程序的规格说明来说, 是合理的, 有意义的输入数据构成的集合。

②无效等价类：是指对于程序的规格说明来说, 是不合理的, 无意义的输入数据构成的集合。

在设计测试用例时, 要同时考虑有效等价类和无效等价类的设计。

划分等价类的原则

(1) 如果输入条件规定了取值范围, 或值的个数, 则可以确立一个有效等价类和两个无效等价类。

n例如, 在程序的规格说明中, 对输入条件有一句话：

“……项数可以从1到999 ……”则有效等价类是“1≤项数≤999”

两个无效等价类是“项数＜1”或“项数＞999”。

(2) 如果输入条件规定了输入值的集合, 或者是规定了“必须如何”的条件, 这时可确立一个有效等价类和一个无效等价类。

例如, 在Pascal语言中对变量标识符规定为“以字母打头的……串”。那么所有以字母打头的构成有效等价类, 而不在此集合内（不以字母打头）的归于无效等价类。

(3) 如果输入条件是一个布尔量, 则可以确定一个有效等价类和一个无效等价类。

(4) 如果规定了输入数据的一组值, 而且程序要对每个输入值分别进行处理。这时可为每一个输入值确立一个有效等价类, 此外针对这组值确立一个无效等价类, 它是所有不允许的输入值的集合。

2.边界值分析

边界值分析也是一种黑盒测试方法, 是对等价类划分方法的补充。

人们从长期的测试工作经验得知, 大量的错误是发生在输入或输出范围的边界上, 而不是在输入范围的内部。因此针对各种边界情况设计测试用例, 可以查出更多的错误。

比如, 在做三角形计算时, 要输入三角形的三个边长：A、B和C。我们应注意到这三个数值应当满足

A＞0、B＞0、C＞0、

A＋B＞C、A＋C＞B、B＋C＞A, 才能构成三角形。但如果把六个不等式中的任何一个大于号“＞”错写成大于等于号“≥”, 那就不能构成三角形。问题恰出现在容易被疏忽的边界附近。

这里所说的边界是指, 相当于输入等价类和输出等价类而言, 稍高于其边界值及稍低于其边界值的一些特定情况。

使用边界值分析方法设计测试用例, 首先应确定边界情况。应当选取正好等于, 刚刚大于, 或刚刚小于边界的值做为测试数据, 而不是选取等价类中的典型值或任意值做为测试数据。

3.错误推测法

人们也可以靠经验和直觉推测程序中可能存在的各种错误, 从而有针对性地编写检查这些错误的例子。这就是错误推测法。

错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况, 根据它们选择测试用例。

4.因果图

因果图的适用范围，如果在测试时必须考虑输入条件的各种组合, 可使用一种适合于描述对于多种条件的组合, 相应产生多个动作的形式来设计测试用例, 这就需要利用因果图。

因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

(1)分析软件规格说明描述中, 哪些是原因 (即输入条件或输入条件的等价类), 哪些是结果 (即输出条件), 并给每个原因和结果赋予一个标识符。

(2)分析软件规格说明描述中的语义, 找出原因与结果之间, 原因与原因之间对应的是什么关系? 根据这些关系, 画出因果图。

(3)由于语法或环境限制, 有些原因与原因之间, 原因与结果之间的组合情况不可能出现。为表明这些特殊情况, 在因果图上用一些记号标明约束或限制条件。(4) 把因果图转换成判定表。

(5)把判定表的每一列拿出来作为依据, 设计测试用例。

白盒测试：指的是把盒子盖打开, 去研究里面的源代码和程序结构。

白盒测试也称结构测试或逻辑驱动测试, 它是知道产品内部工作过程, 可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行, 按照程序内部的结构测试程序, 检验程序中的每条通路是否都有能按预定要求正确工作, 而不顾它的功能。使用被测单元内部如何工作的信息, 允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例, 对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识, 测试是基于覆盖全部代码、分支、路径、条件。

白盒测试的主要方法：逻辑驱动测试、基本路径测试。主要用于软件验证。使用程序设计的控制结构导出测试用例。逻辑驱动测试：主要是测试覆盖率, 以程序内在逻辑结构为基础的测试。包括以下6种类型：语句覆盖、判断覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖。

白盒测试的主要目的：保证一个模块中的所有独立路径至少被执行一次；对所有的逻辑值均需要测试真、假两个分支；在上下边界及可操作范围内运行所有循环；检查内部数据结构以确保其有效性。

白盒测试的实施方案：在开发阶段要保证产品的质量, 产品的生产过程应该遵循一定的行业标准。软件产品也是同样, 没有标准可依自然谈不上质量的好坏。所有关心软件开发质量的组织、单位, 都要定义或了解软件的质量标准、模型。其好处是保证公司实践的均匀性, 产品的可维护性、可靠性以及可移植性等。

在测试阶段，与软件产品的开发过程一样, 测试过程也需要有一定的准则, 来指导、度量、评价软件测试过程的质量。定义测试准则：为控制测试的有效性以及完成程度, 必须定义准则和策略, 以判断何时结束测试阶段。准则必须是客观的, 可量化的元素, 而不能是经验或感觉。根据应用的准则和项目相关的约束, 项目领导可以定义使用的度量方法, 和要达到的覆盖率。度量测试的有效性、完整性，对每个测试的测试覆盖信息和累计信息, 用图形方式显示覆盖比率, 并根据测试运行情况实时更新, 随时显示新的测试所反映的测试覆盖情况。允许所有的测试运行依据其有效性进行管理, 用户可以减少不适用于非回归测试的测试的过程。

概念：

1.语句覆盖：语句覆盖就是设计若干个测试用例, 运行被测试程序, 使得每一条可执行语句至少执行一次；

2.判定覆盖（也称为分支覆盖）：设计若干个测试用例, 运行所测程序, 使程序中每个判断的取真分支和取假分支至少执行一次；

3.条件覆盖：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的每个可能取值至少执行一次；

4.判定-条件覆盖：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的所有可能取值至少执行一次, 并且每个可能的判断结果也至少执行一次, 换句话说, 即是要求各个判断的所有可能的条件取值组合至少执行一次；

5.条件组合测试：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的所有可能的条件取值组合至少执行一次；

6.路径测试：设计足够多的测试用例, 运行所测程序, 要覆盖程序中所有可能的路径。

三、静态测试

指不实际运行被测软件, 而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。

其中包括代码测试、界面测试和文档测试3个方面。对于代码测试, 主要测试代码是否符合相应的标准和规范。对于界面测试, 主要测试软件的实际界面与需求中的说明是否相符。对于文档测试, 主要测试用户手册和需求说明是否符合用户的实际要求。

四、动态测试

是指实际运行被测程序, 输入相应的测试数据, 检查实际输出结果和预期结果是否相符的过程。所以, 我们判断一个测试属于动态还是静态测试 , 唯一的标准就是看是否运行程序。

单元测试是件中的最小可测试单元进行检测和验证。

1、什么时候进行单元测试？

通常在程序员编码以后, 代码已经通过编译后进行单元测试, 而且在前期就应该做一些准备工作, 比如撰写单元测试计划、编写单元测试用例等。千万不要等到项目后期再进行单元测试, 那样就失去了检查代码、预防缺陷的意义了。

2、由谁来进行单元测试？

单元测试一般由白盒测试工程师或开发人员来测试。如果由开发人员来测试, 最好做到交叉测试, 避免1个人只测试自己的代码。

3、单元测试的依据是什么？

单元测试依据主要有两个, 一个事源程序本身, 包括代码和注释；还有一个是项目的《详细设计》文档。

4、如何进行单元测试？

主要用白盒测试方法, 一般先静态检查代码是否符合规范, 然后动态地运行代码, 检查其实际运行结果。当然检查运行结果是否正确是一个最基本的要求, 我们还要检查很多项, 比如程序的容错处理, 程序的边界值处理等。

集成测试（也叫组装测试或联合测试）是在单元测试的基础上, 将所有模块按照设计要求集成为系统或子系统, 并进行测试。如果是集成为子系统, 也可以叫做部件测试。

目的

当单个模块集成为系统的过程中, 软件仍然可能出现问题。比如：穿越模块接口的数据是否丢失；一个模块功能的实现可能破坏了另一个模块的功能；子功能组合之后不一定可以达到预期的功能；全局数据可能被异常修改；单个模块的误差被放大到了不能接受的地步。因此, 需要在模块集成的时候进行整体测试以发现上面可能出现的问题。

必要性

仅仅保证了模块的局部正确性。而系统测试一般在整个系统完成之后进行, 错误难以定位。

集成测试具有以下不可替代性：单元测试不彻底, 对于模块间接口信息内容的正确性, 相互调用关系是否符合设计无能为力。必须依靠集成测试来保证。

和系统测试相比较, 集成测试从程序结构出发, 目的性, 针对性更强。发现问题的效率高。较容易测试特殊的处理流程。定位也比较准确, 迅速。集成测试的可重复性强, 错

误发生后容易定位。联调和集成测试的区别，成和联调都是对系统的装配过程, 不过属于不同的级别。测试人员在开发人员的协助下, 制定集成测试计划；集成测试主要关注的是接口上消息覆盖, 异常流程, 性能指标等深入测试。

集成测试是分层次的, 一个模块集成测试后, 可以按照计划进行下一个模块的集成或者更高级别的集成。当集成测试完成之后就可以开始联调了。联调：一般是指软件系统和硬件平台之间的联调。可以认为是最高级别的集成测试。开发经理在开发测试人员的协助下, 制定系统联调计划。

相关人员将已通过集成测试的软件系统和硬件平台集成在一起, 构成将交付的系统, 并调通系统的基本功能。使用系统预测试项来确定基本功能是否都已经实现。

通过系统联调调通后的版本提交系统预测试组进行系统预测试。在系统的规模比较小比较简单的时候, 可以考虑忽略集成测试而直接进行联调。但是当系统的规模较大的时候, 跳过集成测试会带来问题难以发现, 难以定位的问题。

完整的测试流程：

单元测试->集成测试->联调->系统预测试->系统测试。成测试的层次和阶段，成测试需要分层次, 分阶段完成。

一般情况下, 分层次阶段可以按照以下规律：

第一个层次是组件测试。为后继测试提供更加好的原料。如果系统的一些组件已经充分被测试过, 可以跳过这些组件。第二个层次是做好集成测试规划：考虑人力, 物力, 时间, 测试的重点等。找出关键的部分, 以此作为主线进行计划和资源安排。按照计划, 把集成测试划分成为不同的阶段, 明确各个阶段的主要任务, 确定任务完成的标记。集成, 单元和系统测试的关联。单元测试是针对模块内部功能的白盒测试。需要辅助测试代码才可以进行测试。

集成测试也叫：组装测试, 子系统测试, 部件测试等。比如对于模块A进行集成的时候, 需要把相关模块一起结合起来才可以进行。集成测试是注重功能和性能测试的黑盒测试。

系统测试是将提交的完整软件版本作为一个系统的元素, 和硬件、支持软件、人员等结合起来, 尽可能地模拟实际运行环境进行测试。测试用例通过系统的需求说明书得到, 需要在实际的运行环境下测试。

集成测试的基本方案：可以根据集成测试时组装模块的方式把集成测试方案分成两大类: 一次性集成测试方式；测试方式；向下方式；向上方式；增殖方式；成测试的实施。

集成测试的方法和步骤：首先确定子系统有哪些模块组成,保证这些模块都进行过单元测试.，开发人员组装这些模块,生成子系统,并保证在此子系统中,各个模块的功能尽可能发挥出来。测试前, 以一个关键模块为核心设计测试用例。以功能和性能为主线, 注重模块间的接口。搭建必要的测试环境, 按照所写的测试用例, 进行模块连接的充分测试。记录测试结果, 总结测试问题。

集成测试工作的主要内容：测试主要依据材料：概要设计说明书。集成测试计划的制定：包括集成测试进度安排, 人员分配, 测试用例设计。集成测试计划的评审。集成测试过程：包括测试过程记录, 问题记录, 问题定位和解决, 问题回归。集成测试报告的编写：包括测试总结, 测试活动评估和测试问题分类统计和分析。集成测试计划的影响因。定集成测试计划的时候, 应该考虑如下因素：采用何种系统集成方法来进行集成测试，成测试过程中连接各个模块的顺序，块代码编制和测试进度是否与集成测试的顺序一致，试过程中是否需要专门的硬件设备，出各个模块的编制、测试计划表, 标明每个模块单元测试完成的日期、首次集成测试的日期, 需要的测试用例等。同时考虑测试所需特殊设备的日期情况。留出时间余量，成测试计划的编制编制之前最好能够明确把握被测试对象。

第四章 BUG定义与提交技巧

BUG定义

所谓bug也就是进行某一输入后，软件输出是错误的或者不是我们所期望的结果。 bug 在英语中是臭虫的意思。在以前的大型机器中，经常出现有些臭虫破坏了系统的硬件结构，导致硬件运行出现问题，甚至崩溃。时间长了，bug被引伸为错误的意思，什么地方出了问题，就说什么地方出了bug.

提交BUG的技巧

提交bug时描述的越详细越好。随着测试管理工具的完善、利用，提交bug时很多项系统已帮我们自动实现了，如提交者姓名、提交日期等。但有些项仍然需要我们自己填写。如摘要、操作步骤、预期结果、输出结果等。

误所引起的“bug”，这样会降低你在开发人员心中的可信度。在测试的时候，如果发现测试的实际结果与预期测试结果不符时，不要着急马上报bug，先想想为什么会出现错误。作为专业的测试人员，应该能够对出现的问题进行跟踪，确认了在配置、操作没有错误的前提下，通过追踪分析确认所测试的业务流程确实是存在bug，并能大概对bug的产生原因进行定位。测试人员，需要做到专业，尽量少给开发找麻烦，不要制造实际上并不存在的bug。

确认了所发现的问题是一个bug之后，按照测试步骤再执行一次，确保bug是可重现的而不是随机的。如果bug不能重现，应该尽量找到bug重现的规律，在一些比较难重现的问题可以找开发配合一起查找原因，如果还是无法重现则需要在bug report中对出现的问题描述清楚并说明出现的随机性。

在开发对bug进行修改之后，测试需要报着怀疑的态度认真地对问题进行验证，需要严格按照测试步骤来进行测试，检查开发是否已经正确修改了所出现的问题，以及开发对bug 进行了修复之后是否会引进新的问题。不要相信开发说“已经修改好了，肯定没问题了”就不对问题进行细致的检查了，如果开发修改得不彻底，问题仍然会存在的，或者可能会由于开发在修改bug的时候忽略了另一些细节导致了新bug的出现。尽量不要在关闭bug之后，才发现这个问题还没有修改彻底；也不要出现bug关闭之后，出现了新的bug。

测试对bug进行验证确认已经修改ok之后，关闭bug。在关闭的时候，应该对Bug最终修改结果进行简要描述，如果bug的修改引起配置或数据库或业务流程的变更，也需要在bug关闭描述中进行说明。

第五章软件测试技术拓展

一、用例编写与原则

1、设计概述

测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。

2、功能测试用例

测试种类繁多，针对不同的测试，测试用例的设计方式完全不同。本小节主要探讨的是功能测试中使用的测试用例。

测试用例是测试人员执行测试时的重要参照标准。因此，测试用例必需使测试人员能够明确理解，并能够依据测试用例的描述执行测试。为此，一个设计良好的测试用例应当包括如下几个关键几点：

（1）、.用例编号(testcaseIndex)，一个软件项目可能拥有数量庞大的测试用例。应根据项目设计一个良好的用例编号体系，那么通过用例编号，便可对测试用例进行快速定位，查询时事半功倍，以便更快地解决问题。

（2.）、用例名称(testCaseName)，用例名称的编写应使用最精简的文字，描绘出用例的全貌。编写良好的用例名称如同书籍的目录，能够帮助阅读者整理思路，定位用例。

（3）、.前置条件(precondition)，前置条件指测试执行者在执行测试用例的操作步骤前，必须完成的准备工作。常见的前置条件有:系统的配置、权限的设置、数据的准备、前置工序的执行等。

（4）、.测试步骤 (Teststep)，测试用例中，每个操作均可设计为一个步骤。一个测试用例由一个或多个测试步骤组成。常见可将测试步骤分为正常步骤和容错步骤。正常步骤指普通用户为了实现正常功能，进行的普遍的、正确的、系统期待的操作。正常步骤描述的操作通常在需求文档中会有明确的说明，也是程序需要实现的主要功能。

容错步骤指用户有意或无意进行的一些错误的、甚至于有破坏性的操作。对此类错误操作，系统应有足够的容忍性，进行一些友好的提示、阻止或处理，而不是产生异常。

需求文档中，通常会对正常步骤进行明确定义。因此，正常步骤是严谨的，甚至是唯一的，编写者的发挥空间非常狭小。容错流程恰恰相反。一个思维活跃、经验丰富的测试人员在编写容错步骤时，能够考虑到各类不同的容错步骤，其编写出的测试用例也是全面、广泛而又犀利的。容错流程的编写深度与广度能够很好的反映编写者的技术实力，这样才能更加全面的进行软件测试。

（5）、.步骤描述(Deseription)，步骤描述是测试步骤的主体，是测试人员执行测试时的重要阅读对象。因此，测试步骤必须表述详细，描述清晰，用语必须规范、严谨而又客观。最基本的要求是能够使其他人理解，并能正确的执行编写者期望的操作。

（6）、.期望结果，期望结果是执行测试时，测试者所进行比对的标尺，是一个测试步骤是否通过的标准答案。期望结果必须要保证其正确性。错误的期望结果带来的后果是严重的。

（7）、.实际结果 (ActualResultS)实际结果供测试人员在运行测试时填写观察到的实际结果。填写的内容同样需做到规范、严谨与客观。

（8）、.测试结论 (TestResult)与实际结果类似，测试结论供测试人员运行测试时填写。若实际结果与期望结果两者一致，或虽然不一致，但在可接受范围内，则可以认为该步骤是通过的，测试结论应置为passed;若两者不一致，且无法接受，则应将结果置为Failed。

3、性能测试用例

性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数据量测试，网络性能测试，服务器性能测试五大部分，具体编写测试用例时要根据实际情况进行裁减，在项目应用中遵守低成本，策略为中心，裁减，完善模型，具体化等原则；

WEB 全面性能测试模型：Web 性能测试模型提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，这些类型的性能测试的实施是有着相似之处的；

（1）、预期指标的性能测试

系统在需求分析和设计阶段都会提出一些性能指标，完成这些指标的相关的测试是性能测试的首要工作之一，这些指标主要诸于“系统可以支持并发用户200个；”系统响应时间不得超过20秒等，对这种预先承诺的性能要求，需要首先进行测试验证；

（2）、独立业务性能测试

独立业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。

（3）、组合业务性能测试

通常不会所有的用户只使用一个或者几个核心业务模块，一个应用系统的每个功能模块都可能被使用到；所以WEB性能测试既要模拟多用户的相同操作，又要模拟多用户的不同操作；组合业务性能测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。

（4）、疲劳强度性能测试

疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试，其主要目的是确定系统长时间处理较大业务量时的性能，通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定。

（5）、大数据量性能测试

一种是针对某些系统存储，传输，统计查询等业务进行大数据量时的性能测试，主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试。

第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者常用的组合业务。

第三种大数据量测试结合了前面两种的测试，两种测试同时运行产生较大数据量的系统性能测试。

（6）、网络性能测试

主要是为了准确展示带宽，延迟，负载和端口的变化是如何影响用户的响应时间的，在实际的软件项目中，主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成。

（7）、服务器（操作系统，WEB服务器，数据库服务器）性能测试。

（8）、一些特殊的测试

主要是指配置测试，内存泄露测试的一些特殊的WEB性能测试。

二、开发修改

软件开发中测试及修改bug的基本流程:

1、测试人员发现问题后，记录bug出现位置（模块、界面、触发事件的控件等），截图，时间，能否重演等。对于不甚紧急的问题先归档，等待处理。

2、在例会或者讨论会上提出所有出现的问题，经过项目负责人主持商讨之后决定是否修改。若修改则交由该功能模块的开发人员查找产生bug原因，并写出分析报告。

3、在例会或者讨论会上由开发人员提出已明确产生原因的bug列表和分析报告，并经由项目负责人商讨确定是否修改，并制定修改计划（修改人、修改时间段、预期完成情况）。

4、修改人按计划修改bug，并书写修改报告（功能模块、问题描述、修改内容明细、完成情况、修改时间、修改人）。

5、修改后的版本交由测试人员测试，并记录测试结果。

6、如果测试通过，则发布新版本，否则从第一步开始重复。

三、回归测试

1、简述回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试包括两部分：函数本身的测试、其他代码的测试。在对被修改的函数重新测试。如果函数的设计功能没有变化，直接运行函数测试就可以了。如果修改了设计功能，则要根据增减的功能点，增加或删除测试用例。

函数代码的修改可能导致调用该函数的代码产生错误，所以需要测试其他代码。在函数列表中选择类测试或工程测试，编译运行测试工程，即可执行对其他代码的回归测试。

2、回归测试策略

对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。

为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。同时，被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其中的问题，有必要追加新的测试用例来测试这些新的功能或特征。

回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下，尽可能有效率和有效力地进行回归测试，需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。

参考文献

[1] Robert V.Binde r《面向对象系统测试模型视图与工具（影印版）》

[2] 古乐，史九林.软件测试技术[M].北京：清华大学出版社，2003：49-51.13-400

[3] Dustin,E.《软件自动化测试：引入、管理与实施》电子工业出版社2003

毕业设计（论文）开题报告

论文指导进度