基于Linux的软件测试技术及测试工具应用.doc

《基于Linux的软件测试技术及测试工具应用.doc》由会员分享，可在线阅读，更多相关《基于Linux的软件测试技术及测试工具应用.doc（31页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、内 容 摘 要本文以自己所实习的DeviceVM公司的产品Splashtop的测试项目为基础，结合自己在测试岗位上所从事的工作，对基于Linux的软件测试技术进行了研究，详细介绍了DeviceVM公司的软件测试流程，并结合现有的测试理论对其测试流程和测试工具进行了分析。最后对如何更好地开展基于Linux的软件测试提出了一些建议。关键词：软件测试、自动化测试、测试技术、Linux操作系统、Python语言ABSTRACTThis paper is based on testing project of DeviceVM company where I have worked as an inte

2、rn productSplashtop. To combine my testing job, it makes full and deep analysis on Linux-based software testing theories and techniques, present DeviceVM company software testing process in detail, and analysis on its testing processes and testing tools with reference to the current software testing

3、 theories. Finally introduce some suggestions on how to do Linux-based software testing better.KEYWORDS：Software Testing、Automatic Testing、Testing Technology、Linux、Python 正文目录第一章 引言1第一节 选题背景1第二节 研究的意义1第三节 研究的内容2第二章 软件测试理论与工具应用3第一节 软件测试理论3一、软件测试的产生及发展历史3二、软件测试的定义3三、软件测试分类4四、软件测试技术7五、软件测试过程8第二节 软件测试工具

4、9一、黑盒测试工具9二、白盒测试工具10三、测试管理工具10第三章 基于Linux的软件测试技术及工具应用分析11第一节 Splashtop系统介绍11第二节 软件测试技术及流程12一、软件测试背景12二、QA测试流程分析12第三节 测试实例15第四节 自动化测试实例19第四章 公司软件测试方法及工具的总体评价23第一节 软件测试方法评价23第二节 软件测试工具评价23一、软件测试工具的优点24二、软件测试工具的局限性24第五章 结论26【参考文献】27致 谢28第一章 引言第一节 选题背景随着计算机技术的发展，计算机软件正在被广泛地应用到社会的各个领域。为确保软件正确运行，防止由软件引起灾难

5、性事故，开发或选择高质量的软件产品具有重要意义。对软件进行测试和评价是提高软件质量的两个有效途径。软件在开发和使用过程中都不可避免地存在错误，这些错误使软件开发在成本、进度和质量上都难以控制。而且，软件中的错误带来的损失是多方面的，有的会使软件开发项目以失败告终。例如，IBM公司开发的美国空军后勤系统OS/360，该系统花费2.17亿美元；有的软件投入使用后给用户带来不同程度的影响，有些后果是灾难性的。例如，20世纪90年代中期，美国Therac25型放射治疗仪2号治疗模式发生的54号故障，多次产生超计量辐射，造成了两人死亡和多人受伤的重大医疗事故；1990年1月，美国长途电话中断9小时；19

6、91年2月海湾战争期间，美国“爱国者”系统未能截拦伊拉克“飞毛腿”导弹，导致28人被炸死。还有许多的其他损失，这些都是由软件中的错误所致。多年实践证明，测试是发现软件错误的最有效途径，也成为软件开发中的重要环节之一。中国软件产业发展相对滞后，自2000年开始紧追世界软件产业发展的步伐，这就对软件测试技术及工具的使用提出了现实的要求，本人实习即是在DeviceVM杭州分公司的软件测试岗位上，软件测试技术及软件工具的使用成为我关注和研究这一领域的选择。第二节 研究的意义 在计算机领域，人们对“软件测试”的认识是随着软件开发的发展而逐渐深入的。最初，人们对软件测试存在着错误的认识，认为测试是对软件的

7、调试，是证明软件正确的过程。伴随着软件生存周期概念的产生及软件工程的实施，人们逐渐认识到，软件测试是软件生存周期中发现错误的过程，是度量软件质量的过程，是保证软件质量的重要手段。 度量软件质量的过程，也就是对软件产品进行质量评价，是继对软件开发过程进行质量管理和对软件进行测试之后的又一个推动软件质量提高的重要手段，是软件业今后的发展方向。实践证明，在软件开发过程中软件供方根据质量需求适时地对软件中间产品的质量进行评价，能够尽早发现软件问题，从而能够及时纠正问题、降低成本、控制进度，并且保证了软件最终产品的质量；而软件的需方在购买现货软件或定制软件时，通过质量评价，能够了解软件产品能否满足系统需

8、求、是否是最适合的产品。总之，软件质量评价为改进开发过程、提高软件质量、为软件验收和鉴定提供了客观、公正的科学依据。 按照Myers的定义，测试是为了发现程序中的错误。实际中，软件测试把一套测试用例设计方法与不同级别实施的测试结合起来，发现了大多数隐藏在软件中的错误，从而保证了软件质量。令人遗憾的是，软件测试不能发现所有的软件错误。另一方面，通过测试，可以验证软件需求和性能指标等是否满足用户要求，从而给软件开发者和用户建立一个信心。虽然软件测试是软件质量保证工作中的重要一环，但它不能取代其他软件质量保证工作。正如IBM在总结航天飞机软件开发的成功经验时指出的，“一是认真实施软件工程”，“二是特

9、别加强软件检测”。只有综合利用各种手段，才能使软件质量得到有利保证。第三节 研究的内容本文通过软件测试相关资料的收集、文献的阅读，并结合在DeviceVM公司的具体实践，通过在软件测试项目上的测试任务及所完成的测试工作，以实习公司的测试流程为背景，对基于Linux的软件测试技术及测试工具应用进行论述，并得出相关结论，提出参考性的过程改进意见及建议。第一章结合自身的实习经历介绍了选题的背景，并对研究的意义和研究的内容进行了阐述。第二章通过软件测试的文献及资料的收集和整理，论述了软件测试理论与工具应用。第三章结合公司的项目背景，根据该公司的软件测试流程，分析了基于Linux的软件测试技术及工具应用

10、。第四章结合本人实习中的工作任务及公司的测试流程，对测试方法及工具的做出了总体评价。第五章得出结论，并提出了建设性的意见及建议。第二章 软件测试理论与工具应用第一节 软件测试理论一、软件测试的产生及发展历史20世纪60年代（软件工程建立前），为表明程序正确而进行测试。 1972年在北卡罗来纳大学举行了首届软件测试正式会议。1975年John Good Enough和Susan Gerhart在IEEE上发表了测试数据选择的原理的文章，软件测试被确定为一种研究方向。1979年，Glenford Myers的软件测试的艺术，对测试做了定义：测试是为发现错误而执行的一个程序或者系统的过程。20世纪8

11、0年代早期，“质量”的号角开始吹响。软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。制定了各类标准。1983年，Bill Hetzel在软件测试完全指南中指出：测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。 20世纪90年代，测试工具盛行起来。1996年提出的测试能力成熟度TCMM（Testing Capability Maturity Model）、测试支持度TSM（Testability Support Model）、测试成熟度TMM（Testing Maturity Model）。 到了2002年，Rick和Stefan

12、在系统的软件测试一书中对软件测试做了进一步定义：测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。二、软件测试的定义(一) 早期定义在1979年出版的一本经典著作软件测试的艺术（The art of software testing）中，Glenford Myers曾经对软件测试下过如下的定义：软件测试就是为了发现错误而执行程序或系统的过程。这一定义明确指出软件测试是以“寻找错误”为目的，他把软件测试的目的和手段搞混了，发现错误仅仅是软件测试的手段而已，软件测试的最终目的是检验实际的软件系统是否符合用户需求，所以不能为了发现错误而发现错误。当然，在当时的

13、环境下，这个定义是说得通的，因为那是的用户需求、质量保证等概念比较模糊，测试也仅仅是编码后的一个阶段，测试的主要工作也是用来发现错误的。(二) 标准定义1. 狭义定义使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别（1983，IEEE软件工程标准术语）。这一定义指出了软件测试是通过运行程序以检验软件是否满足软件需求的一个过程，是狭义的软件测试概念。这一定义相对来说比较完善，但也有不足之处，比如“运行或测试某个系统”，软件测试并不一定要运行系统，测试的定义中也不应该再出现测试的字眼。2. 广义定义由于在软件开发的需求分析、设计

14、、编码实现的各阶段都可以把错误引入软件中，为了及时地发现并解决这些错误，避免对软件质量和开发后期工作地影响，需要在软件开发过程中不断地对软件进行复查、评估、检验，确定系统或部件的需求是否完成和正确，每一开发阶段的产品是否实现了在上一阶段规定的需求或条件，以及最后的系统或部件是否依从规定的需求。这些贯穿于软件开发各阶段的复查、评估与检测活动，被统称为软件测试。这种定义超出了狭义上的软件测试的范围，包含了对软件的确认和验证，是软件测试的广义概念。三、软件测试分类 目前软件测试领域有许多测试名称，这些名称来自于不同的分类原则，以下是常见测试名称的分类。(一) 按测试阶段或测试步骤划分按测试阶段或测试

15、步骤来分，有单元测试（unit testing）、集成测试（integration testing）、系统测试（system testing）和验收测试（acceptance testing）。单元测试，是指对软件中的最小可测试单元进行检查和验证。单元就是人为规定的最小的被测功能模块。目前，国内的很多软件公司的单元测试还很不正规，只是由开发人员来简单地编译和调试一下自己的程序，没有相应的单元测试计划、单元测试用例和代码覆盖率的统计。集成测试，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分。系统测试，指的是将整个软件系统看作一个整体进行测试，包括对功能、性能，

16、以及软件所运行的软硬件环境进行测试。验收测试，指的是系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。在验收测试中，按照测试的方式又有Alpha测试和Beta测试。这两种测试针对的是由多用户使用的软件，由用户来发现那些似乎只有最终用户才能发现的错误。Alpha测试是这样的测试，在开发方的场所，用户在开发人员的指导下对软件进行测试，测试是受控的，开发人员负责记录错误和使用中出现的问题；Beta测试由软件的最终用户在一个或多个用户场所来进行，开发人员通常不在现场，整个测试不被控制，用户记录下所有的问题，并报告给开发人员。很多软件都有

17、Beta版，比如QQ2009 Beta版、网络游戏Beta版等。其目的是交给用户免费试玩，再根据用户的反馈去修改软件，这个过程中即使有些错误也能被用户理解和接受。Alpha测试和Beta测试都不能由软件开发人员或测试人员完成。这种划分来自于软件的开发过程，目的是验证软件开发过程各阶段的工作是否符合需求和设计要求。在软件单元完成编码后，首先进行单元测试，验证软件单元是否正确实现了规定的功能和接口等要求；在确认没问题后，将软件单元组装在一起进行集成测试，验证软件是否满足软件需求规格说明的各项需求；最后使通过验收测试的软件与其他系统成分组合在一起，并使其在实际运行环境中运行，进行系统测试。(二) 按

18、测试对象划分按测试对象来分，有单元测试、部件测试、配置项测试和系统测试。(三) 按使用的测试技术划分按使用的测试技术来分有静态测试和动态测试，他么代表了程序不同的运行状态。动态测试又分为白盒测试和黑盒测试，白盒测试包括逻辑覆盖测试、域测试、程序变异测试、路径测试、符合测试等，黑盒测试包括功能测试、强度测试、边界值测试、随机测试等。(四) 按软件质量特性划分 按软件质量特性来分，有功能性测试、可靠性测试、易用性测试、效率测试、可移植性测试和维护性测试。(五) 按测试项目划分按测试项目来分，有功能测试、性能测试、接口测试、强度测试、可靠性测试、安全性测试、人机界面测试、健壮性测试、恢复测试、安装测

19、试、压力测试、兼容测试、负载测试、文档测试等。1. 功能测试主要针对软件/产品需求规格说明的测试，验证功能是否符合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。2. 性能测试测试软件是否达到需求规格说明中规定的各类性能指标，并满足相关的约束和限制条件。3. 接口测试测试被测对象与其他软件（包括软件单元、部件、配置项）或硬件的接口。4. 强度测试使软件在其设计能力的极限状态下、进而超过此极限下运行。检验软件对异常情况的抵抗能力。5. 可靠性测试这里是比较狭义的可靠性测试，它主要是对系统能否稳定运行进行一个估计。6. 安全性测试测试软件在没有授权的内部或者外部用户的攻击或者恶意破坏时如何进行

20、处理，是否能保证软件和数据的安全。7. 人机界面测试对人机界面提供的操作进行测试，测试人机界面的有效性、便捷性、直观性等，如用户界面是否友好、是否方便易用、设计是否合理、位置是否正确。8. 健壮性测试侧重于软容错能力的测试，主要是验证软件对各种异常情况（如数据边界、非法数据、异常中断等）是否进行正确处理。9. 恢复测试对每一类导致恢复或重构的情况进行测试，验证软件自身运行的恢复或重构，软件控制的系统的恢复或重构以及系统控制的软件的恢复或重构。10. 安装测试安装测试主要检验软件是否可以正确安装，安装文件的各项配置是否有效，安装后能否影响原系统，卸载后是否删除干净，是否影响原系统等。11. 压力

21、测试对系统不断施加压力的测试，通过确定一个系统的瓶颈或者不能接收的性能点，获得系统能提供的最大服务级别的测试。例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。压力测试注重的是外界不断施压。12. 兼容测试测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。13. 负载测试负载测试是性能测试的一种，通常是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。14. 文档测试测试开发过程中生成的文档，以需求规格说明、软件设计、用户手册、安装手册等为主，检验文档是否和实际存在差别。文档测试不需要编写测试用例。(六) 回归测试、冒烟测试、随机测试这3个

22、概念很重要，但是它们既不算是测试阶段，也不算是具体的测试方法。回归测试（regression testing）,是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。回归测试可以再任何测试阶段进行，既有黑盒测试的回归，也有白盒测试的回归。冒烟测试（smoke testing），是指对一个新版本进行系统大规模的测试之前先验证一下软件的基本功能是否实现，是否具备可测性。冒烟测试和回归测试往往结合起来使用：每当我们拿到一个新版本时，都首先进行冒烟测试，如果通过，则进行回归测试。随机测试（random testing）,是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一

23、些边缘性的错误。四、软件测试技术软件测试技术主要有两大类：静态测试技术和动态测试技术。(一) 静态测试静态测试是不执行程序代码而采用其他手段寻找文档和代码中可能存在的错误或评估程序代码的过程。静态测试可以手工进行，也可以借助软件工具自动进行。静态测试技术主要用于软件单元、部件的源代码、在狭义的测试概念范畴，静态测试技术主要包括桌面检查、代码审查、代码走查和静态分析。1. 桌面检查桌面检查通常是在程序通过编译之后，由人工模拟程序执行情况，逐步检查源代码清单、测试结果或其他文档，以发现其中有无逻辑或语法错误、对标准的违反或其他错误情况。2. 代码审查代码审查是通过对程序的可视检查，以发现软件错误、

24、对开发标准的违反情况以及其他问题的一种有效地静态测试技术。IBM的统计数据显示，用代码审查发现的错误占全部查出错误的80%。3. 代码走查代码走查与代码审查有些相似，也是由一组程序和错误检查技术组成，只是所用的技术不同于代码审查。代码走查过程由准备、生成测试实例、会议走查、形成报告4个步骤组成。桌面检查、代码审查和代码走查3种技术比较而言，后两种比第一种更能有效地发现软件错误。Myers研究发现，代码审查和代码走查平均查出全部错误的38%。而且与其他测试技术相比，代码审查和代码走查也有许多优点。例如，当发现错误时，代码审查和代码走查知道错误的性质和位置，不需要开发人员用大量的时间去寻找错误的位

25、置。4. 静态分析 静态分析师一种对程序代码进行机械性、程序化的特性分析方法，一般包括控制流分析、数据流分析、接口分析、表达式分析。(二) 动态测试动态测试是在抽样测试数据上执行软件并分析输出以发现错误的过程。根据测试理论，如果抽样测试数据满足一定要求，那么测试可以发现软件中的大多数错误。动态测试的优点是：通过实际运行被测软件，可获得软件运行的实际情况。但这也给动态测试提出了要求，即软件的运行需要实际运行环境、输入数据及输出处理，有时还需要有控制运行的手段。因此，动态测试的工作量很大。动态测试需要测试数据，如何用少的测试数据发现尽可能多的软件错误是动态测试的关键，黑盒测试和白盒测试就是两类从不

26、同方面设计测试数据的方法，灰盒测试是这二者的一种有效结合。1. 白盒测试白盒测试又称结构测试、逻辑测试或基于程序的测试，这种测试是对软件的内部结构和工作原理进行检查。常用的白盒测试技术有逻辑覆盖、数据流测试、基本路径测试、域测试、程序插装、符合求值、程序变异、弱程序变异。2. 黑盒测试黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试。顾名思义，黑盒测试是把被测程序看成是内部不可见的黑盒子，测试人员完全不考虑程序内部逻辑结构和内部性，也不考虑程序中的语句及路径，只依靠软件的需求规格说明、设计文档或用户手册等相关资料，根据软件的功能及输入和输出关系设计测试用例，检查软件是否符合需求。常用的黑

27、盒测试技术有：功能分解等价类划分法、边界值分析法、判定表法、因果图法、随机测试、猜错法、正交验证法、域测试、场景法、功能图法。3. 灰盒测试 灰盒测试是近年来提出的，它是介于黑盒测试和白盒测试之间的一种测试技术。灰盒测试结合了白盒测试和黑盒测试的要素，基于白盒方法分析软件结构的逻辑覆盖，基于黑盒方法生成满足覆盖条件的输入和输出组合的测试数据。在关注输出对于输入的正确性的同时，也关注了软件的内部结构。但它关注软件内部结构不像白盒测试那样详细和完整，它通过一些表征性的现象、事件、标志来判断软件内部的运行状态。 五、软件测试过程(一) 测试策划阶段在测试策划阶段，测试人员应对测试要求（例如合同、项目

28、计划、任务书等）及被测软件进行分析，规划整个测试过程。策划的启动时间不应太晚，否则会影响到整个测试工作。同时软件开发方应尽早向测试方提供受控的、版本明确的被测软件（包括文档、程序和数据）。测试策划阶段的主要活动有12项，他们是确定测试目标、确定测试需求、确定测试技术和方法、确定充分性要求、确定终止要求、确定资源要求、确定测试通过准则、确定测试进度、风险分析、确定工作产品、编制文档、阶段评审。(二) 测试设计和实现阶段软件测试设计和实现阶段的工作由测试设计人员和测试程序员按照上一阶段制定的测试计划来实施。该阶段的主要活动有：设计测试用例、设计和获取测试数据、获取测试资源、开发测试程序、建立和校准

29、测试环境、编制文档、评审。其中设计测试用例的目的是告诉测试人员“怎样测”，它是软件测试核心，也是软件测试的难点。所谓测试用例就是在测试活动中为特定目的开发的一组测试输入、执行条件和期望结果。有效的测试用例能够覆盖用户的需求并发现软件中存在的错误，避免测试的盲目性，提高测试效率。测试用例的设计不仅需要采用适当的技术和方法，还要遵守一些规则，这样才能保证测试用例是有效地。这些原则有：基于测试需求原则、基于测试技术原则、可重复性、不要使单个测试用例覆盖过多的条件、明确测试期望结果。(三) 测试执行阶段测试执行阶段的工作由测试执行人员完成，主要工作是执行测试计划和测试说明中规定的测试用例。在执行过程中

30、，测试人员应认真观察并如实记录测试过程，测试结果和发现的问题，认真填写测试记录。(四) 测试总结阶段测试总结阶段的活动主要有分析测试结果、编制测试报告、评审。第二节 软件测试工具根据应用领域，一般将软件测试工具分为黑盒测试工具、白盒测试工具和测试管理工具3类。一、黑盒测试工具黑盒测试工具是指测试软件功能或性能的工具，主要用于系统测试和验收测试；其又可分为功能测试工具盒性能测试工具。常见的性能测试工具是MI(Mercury Interactive)公司的LoadRunner，是跨平台的，可以安装运行在Windows、Linux等多种操作系统，主要用于C/S和B/S结构的软件系统测试，其通过模拟虚

31、拟的并发用户数来对被测系统进行压力测试。常见的功能测试工具是MI公司的WinRunner,是基于Windows操作系统的，通过脚本的录制和回放来进行自动化的功能测试，另外还有QTP（Quick Test Professional）。二、白盒测试工具白盒测试工具是指测试软件的源代码的工具，可以实现代码的静态分析、动态测试、评审等功能，主要用于单元测试。常见的工具是Telelogic公司的Logiscope，C+Test等。三、测试管理工具测试管理工具是指管理整个测试流程的工具，主要功能有测试计划的管理、测试用例的管理、缺陷跟踪、测试报告管理等，一般贯穿于整个软件测试生命周期。常见的工具是MI公司

32、的TestDirector,它是B/S结构的软件，方便测试人员合作和沟通。可以实现需求管理、测试计划管理、用例管理、缺陷管理，能和改公司的其他测试工具很好的集成，并具有强大的图表统计功能，会自动生成丰富的统计图表。所有的测试工具都可以归到上面的3个大类里面，比如一些数据库测试工具，链接测试工具可以归到黑盒测试工具里面，一些缺陷管理工具如Bugzilla、Mantis可以归到测试管理工具里面，但有时缺陷管理工具也可以自成一类。第三章 基于Linux的软件测试技术及工具应用分析数年前，知道Linux的人群还很少，从事Linux的公司也基本处于培育市场阶段，相比国外，Linux在中国的发展处于初级阶

33、段。而如今，Linux在很多中小企业的应用已经悄然登上了台面。我所实习的DeviceVM公司就是这样一家以Linux为核心技术的公司。第一节 Splashtop系统介绍Splashtop是一个即时启动系统，无需启动主操作系统即可快速访问网络和常用程序，Splashtop是预先集成在台式电脑或笔记本电脑里的小型Linux系统，系统里已经安装了常用程序，能在网上冲浪，收发邮件，观看视频，和朋友聊天，拨打VOIP电话，所有这一切都在打开电脑电源后几秒内完成。Splashtop由两大部分组成。一部分是在系统BIOS里的实时操作系统，另一部分是优化过的Linux系统，能快速启动，运行绝大部分基于Linu

34、x的应用程序。主要由以下几个应用程序组成：Splashtop 浏览器:在按下电源开关数秒后就能做到上网冲浪，和Skype上的朋友和同事聊天，观看照片，聆听数字音乐，所有这一切，都可以在传统操作系统开机启动之前就能享受。它是基于Firefox2技术的网页浏览器，功能齐全，能像Firefox一样的分页式浏览，播放Flash视频和玩游戏，阻止弹出式广告。Splashtop 音乐播放器：通过Splashtop音乐播放器，可以聆听存储在硬盘或外置存储介质上的数字音乐。Splashtop 照片管理器：浏览电脑上的照片，创建相册，欣赏幻灯，上传照片。通过Splashtop照片管理器，可以让一切更简单快捷。S

35、kype：通过Skype从电脑上拨打全世界各地的固定电话和手机，节省费用。Splashtop 聊天：使用流行的即时软件和朋友沟通，如ICQ，MSN，Yahoo通，AOL即时通信软件或QQ等。Splashtop控制面板：实现对系统各种设置的功能。 第二节 软件测试技术及流程一、软件测试背景该公司有自己独立的软件测试部门QA（quality assurance），有自己的软件测试项目经理，由于是一家外资企业公司，为了便于交流，公司内部交流文档以及工作文档都统一使用英语。测试的内容主要是测试Splashtop在华硕的台式机的不同型号主板、各大笔记本生厂商的对应型号笔记本上的兼容性，主要采用测试的技术

36、是黑盒测试。二、QA测试流程分析本人通过在该公司的实习，对QA的测试流程作了许多记录，现将测试流程做如下归纳：(一) 从项目经理/研发部门得到项目规格说明或需求。 在这个过程中QA项目经理要做好如下工作：1. 测试人员的工作分工及任务和必要的培训。2. 平台（platform） 和VA 虚拟工具，Virtual Appliance 的简称，指在VAE中制定的应用程序，这些应用程序会为了这种特殊的环境做合适的配置。VAE：Virtual Appliance Environment的简称，一个具备所有的驱动，库文件，用户界面来安装，运行，配置虚拟工具（VA）。 的测试计划实施：从文件服务器上得到测

37、试计划/测试用例的样板；清楚地识别出所有定制项目作为在测试计划中的测试项目；尽量多地列出重要的里程碑（Milestone） 里程碑，即预定的每个阶段完成的时间。，例如internal(alpha), global(beta), RC 候选发行版本，Release candidate的简称。, GM；基本上，STP（Software Test Plan）是一个给外部OEM（Original Equipment Manufacture） 需求的标准文档，STP会根据要求来做，不会根据默认值传送。3. platform 和VA的测试用例的实施。4. 创建测试机器信息。 5. 在Mantis 是一个基

38、于PHP技术的轻量级的开源缺陷跟踪系统，以Web操作的形式提供项目管理及缺陷跟踪服务。 上创建项目。6. 创建项目任务管理器。7. 在服务器上创建相关文件。(二) 研究学习 在这个过程中包括了测试成员的训练，以及对早期版本的学习；程序的研究学习和规格说明的学习。(三) 准备QA文档 QA文档按照先后顺序分别是写测试计划、写测试用例。在这个过程中，如果必要的话，从杭州QA这里请求各个VA的更新的 STP/STC，杭州QA为了保证VA质量会对所有的VA进行一个常规的周期测试，如果没有特殊的要求，在项目新版本发行测试中该项目只能给各个VA做一个简单的测试。(四) 进行测试并修复Bug 这一步是测试的

39、核心环节，研发部门（RD）开发好应用程序后，交给测试小组的系统集成负责人使用集成工具对应用程序进行打包（make build）将文件打包成sqx 是组成Splashtop系统文件。如chat.sqx 文件（将此文件添加到Splashtop系统），如果集成失败，就交回给RD重新打包；如果成功就进入下一环节，由测试人员对系统做内部发行版本（Internal release） 测试，其输出有：功能控制列表（Features control list）、内部检查列表结果（Internal check list result）、内部版本检查列表的测试结果（Internal release check l

40、ists test result）、新版本发布的注意点（Release note）、QA的内部发行版本注意点（Internal release note for QA）、写正式的QA测试注意事项邮件（Enter formal QA test notice mail）。如果没有通过QA的检查，就通知系统集成人员拒绝RD的程序，让其重新打包，以上所有测试只能在1到2个稳定的测试机上应用，到这一阶段发现的bugs不会进入Mantis。在这一过程中，QA项目经理的工作是确认基本测试项目是否通过测试，包括启动时间需要符合基本需求（不比前面的版本慢），在功能控制列表中的各种功能能很好的运作，通过所有的在内

41、部发行版本检查列表中测试项目；当版本准备好并通过了他的基本测试，系统集成人员会发送一个内部发行版本注意事项；QA项目经理通知系统集成人员发送一个邮件接收或者拒绝进入正式的QA测试。如果通过了检查，就进入了正式的QA测试，这其中包括了系统测试（System test）、回归测试(Regression test)、安装测试(Installation test)、本地化测试(Localization test) 即对软件在不同的地域中兼容性的测试，如测试Splashtop系统语言在中国使用汉语的环境中语言显示是否正确。、帮助文档测试,在这些测试当中有一部分都是通过自动化测试（Auto test）来实

42、现的，例如，对Splashtop浏览器进行在Alexa Alexa在1996年4月在美国创建，是一家专门发布网站世界排名的网站。 排名前一百的网站就是否能正常访问进行测试，VA游戏（Gaming）的测试，局域网的测试，WiFi测试，本地化测试，各个VA主要项目测试。正式的QA测试结束后会产生一个质量报告，现在的系统就是一个外部版本（External release）。系统测试的内容是压力测试、内存泄漏测试、性能测试、电源管理器测试，安全性测试。这些测试都有一个常规的周期可能是1个星期/2个星期/1各月，这个阶段的bugs开始进入Mantis。在这一过程中，QA项目经理的工作是对项目测试人员做合

43、适的工作分工，谁测试项目的那一部分及谁测试那一台机器等；根据STC对测试项目做出合适的判断，是否在资源或进度上有所限制的情况，通过关于特定的目标机器上的测试用例的完整测试，测试高优先级用例时，如果资源或时间不充足，至少要完成在不同机器上进行兼容性测试；当正式QA测试完成时发送质量报告；如果必要召开bug回顾会议。(五) 发布该版本（RC/GM） 由QA项目经理根据软件的质量及客户的要求决定是否把外部版本发布给客户，如果不发布那么就把他交还给RD，等到下一个常规的版本发布（regular release）用；如果发布该系统就作为RC或常规的外部版本发布。在一个新版本发布后OEM会根据用户的使用反

44、馈及发现的一些问题要求对系统做一些系统补丁(Patch)，由研发部做出相应的修改打入补丁后再交付给客户。在这个过程中，QA项目经理的工作是发送项目测试报告；发送质量报告给该项目经理，由他决定是否能在RC之前作为一个外部发行版本；如果有必要，在RC之前和项目经理为下一个发行版本确认需求。对该过程做出了图解，如图3-1：图3-1 QA软件测试流程 第三节 测试实例 本节例举了一些工作中的测试实例。该例子是以华硕的笔记本某一型号为测试项目，根据该项目平台测试中的软件测试用例（STC），取出了其中一部分 安装测试中的一个升级（upgrade）的测试用例对其进行探讨。该测试用例共有10个要素：测试计划编

45、号（Test Plan ID）、功能类型（Function Type）、测试项目(Test Items)、测试用例编号(Test Case ID)、测试结果(Result)、测试步骤(Test Steps)、预期结果(Excepted Result)、优先级(Priority)、时间(Time)、评论（Comment）。本测试用例把升级这一功能分成了两个测试点：正常升级和静态升级。然后分别根据这两个测试点给出的测试步骤对其进行测试，最后如有异常现象把结果记录在评论这一栏。本人在正常升级测试过程中发现了一个Bug,就是在安装了前一个版本1.4.4.0后再升级到最新版本1.4.5.0，安装好重启后

46、桌面背景会出现异常，桌面完全模糊，甚至看不清楚各个VA，用户将会无法使用系统，这是个不能接受的错误。于是把Bug上报给小组长，很快负责相应功能实现的RD程序员就过来向我了解情况，并且确认了这的确是一个Bug,本人和该程序员谈了自己的想法，据我自己估计是主题（Theme）的问题，之后该程序员就回去检查引起这个Bug原因，QA这边把这个bug上报到EPC 是DeviceVM公司的一个集成了缺陷跟踪、员工论坛、消息发布、资产管理等功能的综合型网站。 里的Bug跟踪系统当中。表3-1列出了这个测试用例。表 3-1 安装测试用例（部分） 从bug发现，到上报到EPC系统以及QA和RD采取的一系列反应、处

47、理这个bug的整个流程在EPC的bug跟踪系统中记录的非常详细。如图3-2所示。图3-2 Bug在EPC的Bug tracking system中的处理过程 最后该程序员发现了代码中问题所在，即在写主题这个常量代码时仅仅少写了一个S，就导致了问题的发生，下面是修改前后的代码，加下划线的就是出错的主题常量。修改前代码:ISSKIN=$(grep skinFile $BOXTOOLRC)if x$ISSKIN != x ; thencat /.setskin.sed/skinFile/c session.skinFile: $BBSKINEOFsed -f /.setskin.sed $BOXTOOLRC /.skin.confmv /.skin.conf $BOXTOOLRCrm -fr /.setskin.sedelseecho session.skinFile: $BBSKIN $B