手机软件测试范文

手机软件测试范文（精选12篇）

手机软件测试 第1篇

1. 软件测试的概念。

软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能的测试, 甚至根据需要编写不同的测试工具, 设计和维护测试系统, 对测试方案可能出现的问题进行分析和评估。执行测试用例后, 需要跟踪故障, 以确保开发的产品适合需求。可以说, 软件测试是发现软件错误的过程, 所以对软件要尽早测试和充分测试。

2. 黑盒测试。

大体上分, 软件测试方法可分为白盒测试和黑盒测试2种。黑盒测试也称功能测试或数据驱动测试。它在已知产品应具有的功能条件下, 通过测试来检测每个功能是否都能正常使用。在测试时, 把程序看作1个不能打开的黑盒子, 在完全不考虑程序内部结构和内部特性的情况下, 测试者在程序接口进行测试。常用的黑盒测试的测试方法包括等价类测试法、边界值测试法、决策表、因果图、场景法和正交试验法。

3. 白盒测试。

白盒测试则只根据程序的内部结构进行测试, 而不考虑外部特性, 如果程序结构本身有问题, 比如说程序逻辑有错误或是有遗漏, 则无法被发现。白盒测试可全面了解程序内部的逻辑结构, 无法对所有逻辑路径进行测试。在使用这一方案时, 测试者必须检查程序的内部结构, 从检查程序的逻辑着手, 得出测试数据。常用的白盒测试方法包括逻辑覆盖测试、基本路径测试、分支条件测试、循环测试和数据流测试等。

二、面向对象特征对软件测试的影响

类的封装性和继承性给面向对象软件的开发带来了很多好处, 但却给软件测试带来了不少负面影响。一方面, 面向对象测试用例设计的目标是类, 类的属性和操作是封装的, 而测试需要了解对象的详细状态。另一方面, 继承也给测试用例的设计带来了不少麻烦。继承并没有减少对子类的测试, 相反使测试过程更加复杂。

1. 类和对象对功能模块测试的影响。

在面向对象系统中, 系统的基本构造单元是封装了数据和方法的类和对象, 而不再是一个个能完成特定功能的功能模型。每个对象都有自己的生存期和状态。消息是对象之间相互请示或协作的途径, 是外界使用对象方法及获取对象状态的唯一方式。对象的功能是在消息的触发下, 由对象所属类中定义的方法与相关对象的合作共同完成, 并且对象在不同状态下对消息的响应也可能完全不同。

2. 系统功能实现对测试的影响。

在面向对象系统中, 系统的功能体现在对象间的协作上, 而不再是简单的过程关系调用。面向对象程序的执行实际上是执行一个由消息连接起来的方法序列, 方法的实现与所属对象本身的状态有关, 各方法之间可能有相互作用。为实现某一特定的功能, 可能要激活和调用属于不同对象类的多个成员函数, 形成成员函数的启用链。因此, 基于功能分解的自顶向下或自底向上的集成测试策略不适用于面向对象软件系统的测试。

3. 封装对测试的影响。

封装是指在词法单位之中或之间决定名字可见性的访问控制机制。它支持信息的隐蔽和模块化, 有助于防止全局变量的访问问题。尽管封装不会直接促成错误的发生, 但它却给测试带来了障碍。封装使对象的内部状态隐蔽, 如果类中未提供足够的存取函数来表明对象的实现方式和内部状态, 则类的信息隐蔽机制将给测试带来很多困难。

4. 继承对测试的影响。

继承也是面向对象语言中的一个本质特征。继承可用于一般与特殊关系, 并且方便编码。但继承削弱了封装性, 产生了类似于非面向对象语言中全局数据的错误风险。由于继承的作用, 一个函数可能被封装在具有继承关系的多个类中, 子类中还可以对继承的特征进行覆盖或重定义。

5. 多态对测试的影响。

多态是指一个引用可以与多个对象绑定的能力。多态能减少代码的复杂性和规模, 同时还可以实现动态绑定。但依赖于不规则类层次的动态绑定可能会产生编程人员想象不到的结果。虽然, 某些绑定能正确地运行但并不能保证所有的绑定都能正确地运行。以后绑定的对象可能很容易地将消息发送给错误的类, 执行错误的功能, 还可能导致出现一些与消息序列和状态相关的错误。

三、面向对象软件测试的层次划分

1. 方法测试。

主要考虑封装在类中的1个方法对数据进行的操作。可以采用传统的模块测试方法, 但方法是封装在类中的, 并通过向所在对象发消息来执行, 它的执行与状态有关, 特别是在操作多态性时, 设计测试用例时要考虑设置对象的初态, 并且要设计一些函数来观察隐蔽的状态值, 使它在收到消息时执行指定的路径。

2. 类测试。

在测试过程上等同于传统的单元测试, 面向对象的类测试主要考察封装在1个类中的方法和类的状态行为。进行类测试时要把对象与其状态结合起来, 进行对象状态行为的测试, 因为工作过程中对象的状态可能被改变并产生新的状态。测试范围主要是类定义之内的属性和服务, 以及有限的对外接口部分。在类测试过程中, 不能仅仅检查输入数据产生的结果是否与预期的相吻合, 还要考虑对象的状态, 整个过程应涉及对象的初态、输入参数、输出参数以及对象的终态。

3. 类簇测试 (集成测试) 。

把一组相互有影响的类看做一个整体称为类簇。类簇测试主要根据系统中相关类的层次关系, 检查类之间相互作用的正确性, 即检查各相关类之间消息连接的合法性、子类的继承性、父类的一致性、动态绑定执行的正确性和类簇协同完成系统功能的正确性等特性。其测试有2种不同策略:基于类间协作关系的横向测试和基于类间继承关系的纵向测试。

4. 系统测试。

是对所有程序和外部成员构成的整个系统进行整体测试, 检验软件和其他系统成员配合工作是否正确。另外, 还包括确认测试内容, 以验证软件系统的正确性和性能指标是否满足需求规格说明书的要求。

四、面向对象测试用例设计

1. 测试用例设计。

面向对象的软件测试用例则着眼于适当的操作序列, 以实现对类的说明。黑盒测试不仅适用于传统软件, 也适用面向对象的软件测试。白盒测试也可用于面向对象软件类的操作定义。但面向对象的软件中许多类的操作结构简单明了, 所以有人认为在类层上测试可能要比传统的软件中白盒测试更加方便。

2. 测试用例设计要点。

测试应该唯一地标识每一个测试案例, 并且与被测试的类明显地建立关联, 并陈述测试对象的一组特定状态。对每一个测试建立一组测试步骤, 需要思考或确定的问题包括:对被测试对象的一组特定状态, 一组消息和操作, 可能产生的一组异常, 一组外部条件, 辅助理解和实现测试的补充信息。

五、设计类测试用例

1. 基于故障的测试。

在面向对象软件中, 基于故障的测试具有较高的故障发现能力。基于故障的测试与传统的错误测试推测法类似。首先, 推测软件中可能有的错误。然后, 设计出可能发现这些错误的测试案例。为了推测出软件中可能存在的错误, 应该仔细研究分析模型和设计模型, 这在很大程度上要依靠测试人员的经验。

2. 基于脚本的测试。

基于脚本的测试主要关注用户需要做什么, 而不是产品能做什么, 即从用户任务 (使用用例) 中找出用户要做什么并去执行。这种基于脚本的测试有助于在一个单元测试情况下检查多重系统。所以基于脚本的用例测试比基于故障测试更加接近用户, 而且更复杂。

3. 随机测试。

如果一个类有多个操作功能, 这些操作功能序列有多种排列。而这种不变化的操作序列可随机产生, 用这种可随机排列的序列来检查不同类的实例, 叫做随机测试。随机测试是针对软件在使用过程中随机产生的一系列不同的操作序列设计的测试案例, 可以测试不同的类实例。

4. 划分测试。

划分测试方法与传统软件测试采用的等价划分方法类似, 它减少了测试类所需要测试用例的数量。首先, 用不同的划分方法 (包括基于状态的划分方法、基于属性的划分方法和基于功能的划分方法) 把输入和输出分类。然后, 针对划分出来的每个类别设计测试用例。

六、设计类间测试用例

1. 基于场景的测试。

基于场景的测试关注的是用户需要做什么, 这正是基于故障测试所忽略的。当与不正确的规约发生错误关联时, 软件就可能不执行用户所设定的工作, 这时软件质量就会受到影响。当一个子系统所建立的环境使得另一个子系统失效时, 子系统间的交互错误便会发生。

2. 行为测试。

手机软件测试类型 第2篇

1）Basic Function [基本功能测试]：就是验证手机基本功能是否实现，发短信、通话、照相等，包括他们的子功能如转发、连拍等。最基本的也是投入时间精力最大的测试类型，也是最重要的，如果基本功能都没有实现其他测试也就变成枉然了

2）UI [用户界面验证]：验证手机的界面、菜单等是否是与客户需求和设计保持一致，主要依据 UI spec[用户界面说明],MMI[人机交互界面]，Menu tree[菜单树]等，这些文档也是需要根据客户需求及时更新的3）Limit Value [极限值测试]：对应黑盒测试的边界值分析法，边界值分析法设计出的测试用例发现 bug 的能力也是最强的，一般依据极限值表设计测试用例，来指导测试。一般测试点如输入字符的个数，会议通话的个数，文档存储个数等

4）Confict Test[冲突测试]：主要依据冲突表，冲突表中列出各个事件之间是否存在冲突，冲突测试用例也是依据冲突表设计，这类用例往往可以发现一些比较严重的 bug，如游戏中来电，流览WAP时插拔充电器、USB线、camera 中低电等

5）Performance Test[性能测试]：主要测试项Call test，长时间通话，发送大容量的彩信ｘ条，开关机ｘ次，摄像ｘ时间，可以考虑用自动化测试，手机自动化测试与PC软件自动化测试类似，利用自动化测试工具录制、调试 写脚本、回放、分析结果，与PC软件不同的是手机自动化测试需要硬件的支持来固定手机和利用气压按键。

6）Stress Test[压力测试]：压力测试是在将手机容量存储状态到满后做的一系列操作，如短信、彩信满，Idle界面各事件个数满如未接电话、闹铃等

7）Network Compatibilit[网络兼容性测试]：网络参数的设置，GPRS等业务是否可用，本外地的联通移动卡各类业务卡在本地的作测试，还需要做Filed Test[场测]即到最终用户实际使用的环境作现场测试，Filed test 有国际专用用例。

8）SIM Card Compatibilit[SIM卡兼容性测试]：一般是对联通移动的各类业务卡，新出的大容量(64K)、国际漫游卡、呼叫限制卡、一卡双号卡等卡的验证，验证能否正确注册、对应的业务功能是否实现、基本功能的正确性

9）PD test [Project Design Test]：验证在项目设计阶段的设计的功能是否得以实现、是否正确，设计用例依据项目设计文档

10）CR Verification[客户需求验证]：验证客户的一些特定需求和变更后的需求

11）User Manual [用户手册验证]：其重要性是不言而喻的，用户手册一定要和手机实际功能相符合，不然将会影响用户对产品的信任

浅谈软件测试中回归测试 第3篇

关键词：软件测试；回归测试

中图分类号：TP311.52文献标识码：A文章编号：1007-9599 (2011) 03-0000-01

Regression Testing of Software Testing

Fan Xuedong

(Xi'an Foreign Affairs University,Xi'an710077,China)

Abstract:Regression testing despite the tedious,repetitive,but it must do the test,whether to take automated testing tools,or other test method is the problem discussed in this article.In this paper,the nature of regression testing,discusses the key,importance and testing methods,have their academic and practical significance.

Keywords:Software testing;Regression testing

一、概述

所谓回归测试就是当軟件发生改变时，重新测试已经通过测试的测试区域，以验证修改的正确性及其影响。在软件开发生命周期中，软件发生改变，就会带来问题。改变可能是源于发现了错误并做了修改，也有可能是因为集成或维护阶段加入了新模块。错误跟踪与管理系统不完善；对错误的理解不透彻，只修正了错误的外在表现，从而造成修改失败；修改还有可能产生副作用，从而导致软件未被修改的部分产生新的问题；新加入代码还有可能对原有代码带来影响。因此，我们就必须重新测试，以便确定修改是否达到了预期的目的。同时，为了验证修改的正确性及其影响就需要进行回归测试。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

二、测试的大部分工作是做回归测试，软件一旦作了修改就必须进行

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

（一）首先必须有个管理良好的测试用例库，用例库中的所有用例必须有效，达到足够的覆盖率。这需要有良好的测试管理工具，并有相应的资源（时间与人力）去维护这个测试用例库，使其中没有过时，冗余的测试用例。如何管理组织好测试用例库是一个值得深入研究的课题，要做好回归测试，组织管理良好的测试用例库是前提。测试用例库的维护为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或新版本软件会添加新的功能或者变化。同时，被修改的或新增添的软件功能，仅靠重新运行以前的测试用例不行，必须追加新的测试用例来测试。

测试用例库维护是一个连续的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括：（1）删除过时的测试用例。因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。（2）改进不受控制的测试用例。随着软件项目进展，库中的用例会不断增加，会出现对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，影响测试效率。（3）删除冗余的测试用例。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。（4）增添新的测试用例。程序段、构件或关键的接口在现有的测试中没有被测试，就应该开发新测试用例。不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。

（二）回归测试的实质在于它是一个能够检测到回归错误的受控实验。回归测试包的选择在软件生命周期中，即使一个得到良好维护的测试用例库，也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全缩减技术，就可决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：（1）再测试全部用例。选择基线测试用例库中的全部测试用例组成回归测试包，这是比较安全的方法，它具有最低遗漏和风险，但测试成本最高。往往超出我们的预算和进度。（2）基于风险选择测试。可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，其严重性也仅有三级或四级。（3）基于操作剖面选择测试。若基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可由测试预算确定，优先选择针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别风险，有助于尽早发现那些对可靠性有最大影响的故障。（4）再测试修改的部分。当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。

再测试全部用例的策略是最安全的策略，但过时回归测试不太可能揭示新的错误，而且由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可选择适当的策略进行缩减的回归测试。

（三）实际工作中，回归测试需要反复进行，回归测试的基本过程有了测试用例库的维护方法和回归测试包的选择策略。回归测试可遵循下述基本过程进行：（1）识别软件中被修改的部分；（2）从原基线测试用例库中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T。（3）依据一定的策略从T中选择测试用例测试被修改的软件。（4）若必要可生成新的测试用例集T1，用于测试T无法充分测试的软件部分。（5）用T1修改后的软件。第b和第c步测试验证修改是否破坏了现有的功能，第d和第e步测试验证修改工作本身。

三、结论

（一）无论采取何种策略，回归测试是必须的一种测试。回归测试时我们必须采取一些较为有效的方法。例如安排新的测试者完成手工回归测试，让更有经验的测试者开发新的测试用例，做一些探索性的测试。但最重要的就是基于实际可行的引进自动化测试，因为机器不会累。实际中，回归测试的重复将非常令人厌烦，因此，需要通过自动测试来实现重复的和一致的回归测试，提高回归测试效率。

（二）在测试软件时，应用多种测试技术是常见的。测试时，测试者希望采用多于一种回归测试策略来增加修改软件的信心。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例。回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际中可以采用一些策略减轻这些问题。可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化输入、按键和配置能够有助于激励测试者又能揭示新的错误。

（三）回归测试需要根据项目、测试资源等实际情况采取有效计划和组织。其中需要注意的是必须重视回归测试，在测试计划中有很好的进度安排及选择相应的回归，重视测试用例的维护，借助于自动化工具。在组织测试时需注意：首先是各测试阶段的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，测试期间应对软件版本冻结，将测试发现的问题集中修改，集中回归。建议将回归测试与兼容性测试结合起来。在新的配置条件下运行旧的测试可以发现兼容性问题，同时也可以揭示编码在回归方面的错误。

参考文献：

[1]贺平.软件测试教程.电子工业出版社,2010,1

基于手机软件测试框架设计探讨 第4篇

手机行业的发展正快速的改变着我们的生活, 随着智能手机的大众化, 手机软件产业正开始成为软件行业中非常重要的软件领域, 而手机软件虽然与计算机软件有着许多相似之处, 但是也有其特点。手机软件一般比计算机软件规模小, 更注重与使用者的交互性和体验感, 更注重耗电量和与手机相关产品的兼容性, 而且手机软件开发周期相对较短, 回归测试次数多。产品的大量涌向手机市场, 普通客户成为软件的第一使用者, 下载排行榜成为手机软件评定的重要标准, 软件质量是决定软件生存的直接因素。软件测试是保证软件质量的重要工程步骤, 良好的软件测试过程质量控制手机软件的良性开发过程, 为其维持市场占有率有着重要的作用。手机软件测试与计算机软件的测试不完全相同, 选择合理的测试框架和测试方法, 提高手机软件质量是很重要的研究课题。

二、手机软件测试

手机软件本身规模小, 手机本身属于嵌入式产品, 智能手机的软件大量需求等方面的原因, 因此手机软件测试中, 为了保证手机产品的质量, 测试过程中包含了大量的回归测试, 另一方面, 手机测试过程中有大量与软件和硬件相关兼容性测试。

这就对软件测试提出了一些特殊的要求:1) 由于软件规模小, 一般公司开发的手机软件并行开发多个软件, 因此测试小组一般会同时进行几个不同手机软件的测试, 给测试管理提出更高的要求;2) 一般手机测试任务要求的时间紧, 从项目完成提出测试需求到项目上线, 一般只有几天时间, 而在短短的几天时间里需要进行最重要的系统测试。3) 项目的大致结构相同, 总体架构相差不大, 一般可以按分层的方式划分模块。分析系统模块可以分为1级、2级子目录的方式进行, 测试模块的管理同样也可以以分级制度来管理。

手机软件小而大多软件结构层次简单分明, 因此可以考虑项目的测试模型可以采用相同框架结构来定义, 测试期限短, 用统一的框架和模式来管理测试过程和测试用例库。着眼考虑提高测试工作的重用性, 进而采用框架式管理, 减少重复性的工作, 可能会更适用于现有公司模式的测试领域的发展, 提高测试工作效率和精确度。

我们要明确, 针对手机软件的测试工作主要是以下几个方面:1) 设计好的测试用例, 形成比较全面的测试覆盖率;2) UI测试, 友好的用户界面, 在手机软件中有着至关重要的作用, 直接影响客户的下载量, 如何做好UI测试和评定是非常重要的;3) 耗电量测试, 网络流量占用测试, 内存占有测试, 这些都成为手机软件测试的一个全新的课题;4) 针对以上几种情况, 设计合理的测试用例, 得到完善的测试用例库和缺陷管理机制。而往往手机软件测试的时间普遍较短, 每次软件测试都要重复以上的设计和测试工作, 费时费力, 那么如何提高手机软件测试效率, 减少重复劳动, 本文将针对这个问题展开探讨。

三、框架式管理

1、框架式管理定义

软件测试的框架式管理是指对项目进行软件测试的全过程, 结构化框架化的过程。数据驱动测试和关键字驱动测试都采用的是框架式管理的方式。图1是关于软件自动化测试框架式管理的基本架构。

如何才能提高手机软件的测试效率呢?首先考虑从测试管理过程着手, 手机软件测试框架式管理是把测试管理过程规范化, 是基于不同手机软件测试工作的大同小异的测试过程, 而设想开发一个类似流水线操作的测试工作过程, 如图1所示。这里设想的手机软件测试框架可以是一个管理系统也可以是一种互相合作的工作模式, 每个单元都功能相对独立, 封装每个模块, 模块之间接口传递数据, 简化不同模块间传递的数据和传递方式。例如测试用例设计、执行测试、自动化测试等都采用单独的模块, 分别由不同的技术人员完成, 而不同模块之间采用接口数据传递的方式传递测试数据和测试结果。这里的重点和难点是每个模块都用自动化测试的过程贯穿始末, 比如测试计划可以利用需求的框架自动生成, 测试用例可以根据已有库和测试计划结合而自动生成和测试结果自动调整测试用例集等等。采用框架式自动化测试管理的, 对测试者分工明确的优势, 由较好的模块独立性, 不同技术工种人员合理分工构成, 操作规范化, 并且有比较高的测试覆盖率。

那么, 我们如何来建立框架式管理的模式呢?

2、框架管理构建步骤

刚开始建立整个框架式管理不是件容易的事情, 不过一旦建立起来以后, 重复的测试工作可以不断的优化框架本身和内容, 而让手机软件测试工作做到覆盖全面, 这是因为自动化控制模块可以成倍提高整个工作效率。初次建立框架, 可以按顺序从以下几个方面展开。

1) 测试用例库的管理工具、缺陷库管理工具的完善。

针对如果没有前期的测试工作积累的测试用例集, 或者测试数据不够规范, 最先要做的是, 对测试用例库的管理工具和缺陷库管理工具的完善, 统一测试用例的定义结构, 存储方式等。然后设计出相对某一款典型手机软件的测试用例集。

2) 自动化执行测试框架:这个过程无异于脚本的二次开发, 是一个漫长而需要不断完善的过程, 搭建从测试数据库, 到自动化脚本, 到测试结果与日志的数据生成的一系列的自动化执行测试过程的脚本开发。

自动化脚本开发主要分成三个部分, 如图2所示。因为手机测试要求时限一般比较短, 而核心模块的回归测试比较多, 所以可以有针对性的根据核心模块。自动化脚本开发要特别注意可重用性的独立模块的开发, 减少以后测试工作的脚本开发工作。这个方面的经验是借鉴应用软件开发的分层思想, 将有普遍意义的手机软件模块的测试工作独立开发测试脚本。

3) 自动化控制, 从测试计划自动生成测试用例库。

测试计划的自动化控制的可行性和前提, 关键在于能否成功的把测试计划以某种合理的数据结构的方式来定义 (如层次型数据) 。有一定的难度, 也是现在在软件测试领域的一个新课题。

4) 自动化控制, 根据缺陷库的生成和修复情况自动调整增减测试用例库的用例。

5) 最后一个阶段对于应用软件和网站开发算是理想状态, 但是我考虑一下对于手机软件, 还是可行的:根据需求自动生成测试计划。可行性是基于, 手机系统的模块可以分解为同一种数据结构 (层次型) , 系统结构比较明朗, 可以实现无缝的自然转接。

当完成这个框架后并且经过不同的手机软件测试, 逐渐达到框架稳定后, 测试管理者或者不同工种技术人员要做的工作可以做如下分工, 可以有效管理测试团队, 并极大提高测试工作效率。

测试组长或者测试工程师的工作为研读需求, 并根据需求将系统的需求转换为测试模块需要的数据层次结构, 然后输入测试框架系统。

系统自动生成测试计划, 并根据计划自动生成测试用例。接下来软件工程师调整系统自动生成后的测试用例库, 并标注哪些为手工测试哪些是自动化测试, 由脚本开发工程师开发自动化测试脚本, 然后有测试员执行自动化测试和手工测试, 填写缺陷, 系统则根据现有缺陷和修复情况, 返回自动调整测试用例库, 如此一直反复, 直到满足测试停止条件为止。

四、真机模拟测试系统

对于那些专业从事手机软件开发的公司, 结合自动化测试的真机模拟测试是非常重要, 也是手机软件测试的发展趋势的一个方面。基于提高手机软件测试效率, 对于真机模拟测试的框架探讨是必不可少的。测试脚本本身不依赖机型, 因此相对独立, 唯一需要解决的是接驳模块的问题, 接驳模块主要负责控制选择不同的真机, 然后调用脚本运行。

五、结论

本文讨论了根据手机软件的特点, 为提高测试效率, 减少重复劳动, 建立框架式测试管理, 测试框架涵盖了测试管理、自动化测试和动态测试用例库生成的整体构成, 讨论了测试框架的建立步骤。真机模拟系统也是手机软件测试的发展趋势之一, 本文仅在结构上做了探讨。对于框架式管理还有很多课题需要进一步研究, 例如, 如何根据缺陷库自动调整测试用例, 探讨一种合理的需求分析数据结构, 帮助系统自动生成测试计划和测试用例库等。

摘要：安卓和IOS的手机软件开发是时下热门行业, 关于手机软件的自动化测试逐渐成为测试领域中非常重要的一个领域, 基于手机软件的开发快速化短期化的特点, 如何有效管理测试工作和提高测试效率是手机测试中非常重要的课题, 本文在手机自动化测试流程和管理框架上提出一些设想与探讨。

关键词：手机软件,自动化测试,robotium,测试框架

参考文献

[1]张坤.基于业务流程驱动自动化测试研究与实现[J].计算机光盘软件和应用, 2013 (05) :268-269

[2]史健超.手机软件测试流程的研究[J].内江科技, 2013 (3) :32-33

手机软件测试实习报告 第5篇

展思维方法并学习实际业务流程中的相关技巧和同事之间的相处

问题。

二．实习时间：2011年11月26日——2011年1月7日

三．实习地点： 广州市萝岗区科学城三星通信研究院科学大道185号

四．实习单位： 广州三星通信研究院

五．实习内容：

1.公司背景

广州三星通信研究院（Samsung Guangzhou Mobile R&D Center，以下简称SGMC）座落于广州市萝岗区科学城，是由三星电子于2008年9月起，在中国设立的大型手机研发机构，设计开发面向中国、美洲、东南亚市场的CDMA和GSM手机；其业务领域覆盖手机的硬件、软件、结构设计、测试等全流程各环节。现有员工600多人； 未来将达到1000人以上的规模。

秉承三星电子致力于发挥人的潜能和技术，创造出众的产品和服务，从而造福全社会的经营哲学，全体SGMC人齐心协力，努力经营：不断建设、完善培训教育体系和管理手段，以良好的内部工作环境和氛围凝聚人，以高质量产品服务和回报社会，不断提升企业形象和吸引力，力争成为真正的“中国人民喜爱的企业，贡献于中国社会的企业”。

2.工作性质与工作职责

--执行手机在研发阶段的功能、性能、稳定性及相关软件的测试和ui测试；--制定测试计划，确认测试结果，输出测试报告；

--和研发人员进行沟通，快速反映问题，描述问题。

--负责撰写测试计划、测试用例、测试报告；

3.行业技术与产品

自成立以来，SGMC一直致力于通过产品开发和配件采购本地化，构筑产品企划到生产的“现地完结性开发体制”，从而打造中国现地化开发模式，确保产品的价格竞争力。从建立伊始，就制定了强化现地化开发的发展策略，从2008年10

月第一批员工加入至今，SGMC已承接多个CDMA，GSM等手机开发项目并取得了良好的市场反应。

手机测试是广州三星通信研究院新成立的一个部门，在者之前，国外已经有许多研究院创立手机测试这一部门。三星作为手机大型生产商，随着科技不断进步，市场竞争剧烈，需要完善手机功能才能满足客户的需求。

4.我所在的职位

职位名称：手机软件测试员

职位描述：

① 负责产品测试工作，根据软件需求大减测试环境和计划

② 负责软件不同功能模块的系统测试

③ 认真执行测试用例

④ 负责协助组长进行测试统计工作

⑤ 负责自己测试出的bug的提交工作

⑥ 负责填写自己测试模块的测试小结

⑦ 负责协助开发人员解决bug

⑧ 对解决的bug后的回归测试

⑨ 负责填写自己测试模块的回归测试小结

⑩ 每周提交工作总结报告

5.具体工作内容

① 每天根据软件测试需求，连接好正确的硬件设备，搭配好正确的端口，为测试

软件选择不同文件参数和版本号，最终搭建好测试环境

② 每天对组长分配给自己的手机模块进行测试，认真执行分配的手机模块的每一

条测试用例，在执行英文测试用例时要反复阅读Spec文档，保证测试用例的正确执行

③ 每台手机连接电脑，通过电脑软件让手机拨号和发短信大于1000次，如遇崩

溃，交还组长测试。

④ 在测试过程中，手机出现问题时，根据是手机硬件还是软件出现的问题，如果

是软件问题，需要抓取bug，首先抓取consolelog和genielog，然后抓取HSLlog，查看问题属于Manjor、minor、crash、再选择不同的工具抓取其他log，最后还要用相机拍取图片

⑤ 将抓取的log按照命名规则进行统一的命名，然后对log进行打包处理，处理

完毕后向本地服务器提交bug，由组长对bug进行审查

⑥ 组长审查完毕，如果bug的提取有问题，则feedback给reporter重新修改，如果组长审查完毕后bug没有问题，将bug向外网服务器上进行提交，并在固定的服务器上上传log

⑦ 当log提交后，开发人员会在外网服务器上看到自己提取的bug，我们负责解

决他们在解决bug过程中产生的疑问，并重新构建执行测试用例的测试环境，而且进行复现测试。

⑧ 对开发人员解决的bug，要重新进行回归测试，并对软件的其他一些功能进行

检查，执行更多的测试用例，尽量发现软件中一些其他的由于开发人员的代码变动而引起的其他错误，来保证软件的质量

⑨ 填写回归测试的测试小结，总结自己测试的case数量、时间以及自己测试过

程中产生的bug数量等内容

⑩ 每天和每周要提交自己的工作总结包括每天的收获和遇到的困难

5.工作中发现的问题

① 由于实习的时间不太长，培训灌输了大量的知识，在测试过程中遇到问题时常

常不知正确的操作流程，不能正确的抓取log或少抓log的现象时有发生，对手机进行测试时测试的环境把握很关键，常常由于对case没有很好的理解导致没有预置正确的测试环境而不能验证bug或复现bug。

② 在实习的这段时间中，对测试工具的使用不是很熟练，而且还有很多工具没有

用到和操作，因此在遇到问题时常常有些bug常常因为工具的不会使用而被漏掉。

六．实习总结：

这份测试工作是我在学校阶段最好的自我检查，让我有机会理论联系实践，增强了我的操作能力和分析能力，也为我的毕业论文设计提供了很好的素材。

在测试过程中，问题不断的出现，又不断的得到解决，一步步的前进，磨练了我的毅力，随着系统的不断完善，我对以前所学的知识领悟程度得到了提升，测试能力的到了质的提高，所学知识得到了综合应用。

在这次实习过程中，还使我对软件测试这份工作有了深刻的认识，虽然软件测试并不能为公司创造价值，但是却能够为公司最大程度的挽回损失，软件测试的目的在于发现软件中的问题并将这些问题演示给开发人员来解决问题。

9.自我评价

在这次实习过程中，我收获颇丰： 首先，本此实习最大的收获就是学会了适应环境。未工作之前我从没想象过这样的实习我能坚持下来，但是通过这次实习我慢慢的适应了这种紧张的生活。相信有了这段时间的锻炼，不论以后做什么工作心中都有了一种吃苦耐劳的毅力，学会了适应环境。其次，就是在工作中知道了一些与学校不同的问题，就是作为一名技术人员应该怎样去和开发人员交流等，同时扩展了自己的交际面，积累了一定的人脉关系。

于此同时，在测试工作中使我认识到我的缺点，不够有耐心，每次进行压力测试都有些不耐烦，但是经过这段时间的锻炼改变了我这个缺点。让我变的更加的专心、细心和有责任心。

七．个人收获：

1.通过公司的工作实习经历，让我有了学校学习的理论知识与实际操作相结合的机会，通过各环节的具体操作，我知道了平时在学校学习的一些理论会和实践操作产生某种程度上的冲突，并因此修正了自身的认知，增长了见识。

2.通过接近两个月的实习，认识了许多同事，并慢慢的知道了怎样进行相互之间的沟通交流，同事之间的相互帮助与合作，团队工作是重要的。

手机软件测试 第6篇

关键词：软件测试；软件质量保证；教学改革；软件测评师；实验教学

中图分类号：G642.0 文献标志码：A 文章编号：1674-9324（2014）51-0094-02

一、引言

随着我国软件产业迅速发展，企业面临着开发高质量软件系统的巨大压力，软件测试、软件质量保证受到越来越多的重视。软件企业对承担软件测试、质量保证工作的软件测试人才需要剧增，软件测试工程师的职业价值、发展前景得到前所未有的提升。为此，国内高校开设了软件测试相关课程。但是，由于其重理论、轻实践的教学模式使得培养出的学生软件测试实战能力差，导致大量毕业生应聘软件测试相关职位时受到冷遇。

为培养创新能力强、适应社会经济发展需要的软件测试人才，《软件测试与质量保证》实验教学亟需改变传统的教学理念，改进教学方法，更新教学内容。笔者结合自身教学科研和工程实践经验，分别从改革思路、实验教学内容设计等方面，论述常熟理工学院《软件测试与质量保证》实验教学改革的措施和体会。

二、实验教学面临诸多挑战

笔者调研国内高校软件测试课程的建设情况，发现普遍存在重理论、轻实践的教学倾向，实验教学环节存在诸多问题：

1.企业对软件测试工程师的能力要求是综合性的，要求软件测试人员具有软件项目经验，具备软件测试、软件质量保证知识，能够独立开展软件测试工作。但是，国内高校教学计划制定时片面强调软件测试的作用，对软件测试与软件质量保证之间的天然联系缺乏理解，对软件质量保证相关实验的重视程度，课时安排存在严重不足。

2.目前，《软件测试与质量保证》实验教材选择面临无书可选的尴尬局面。课程实验设计只能全凭任课教师把握，使得实验教学过程中存在较多风险。

3.国内高校在实验设计方面，多以基础性实验为主。这种单一的实验设计方式，难以适应软件测试工程实践能力培养的需要。

三、实验教学改革措施

在应用技术大学建设驱动下，以中小企业对软件测试人才的需求和软件测试工程师认证大纲为导向，我们整合已有的校企合作课程资源，按照Daniel Galan软件质量保证框架组织实验教学内容，采用项目驱动的案例教学法开展实验教学，让学生在实验实践中加深对软件测试与质量保证专业知识的理解，培养学生软件测试实践能力。

（一）教学改革基本思路

软件企业对软件测试人才的需求是软件测试课程改革的源动力和驱动力，软件测试相关的从业资格认证是学生入职的敲门砖。为此，在应用技术大学建设背景下，我们以切合中小企业对软件测试人才的需求为导向，结合全国计算机等级考试软件测试工程师认证、全国计算机技术与软件专业技术资格考试软件评测师认证的考试大纲要求，选择朱少民老师编写的《全程软件测试》[1]和NIIT培训教程《Software Testing and Quality Assurance：Student Guide》[2]作为课程教材，按照Daniel Galin软件质量保证框架组织教学内容。Daniel Galin软件质量保证框架[3]指出软件质量保证是建立企业软件质量文化所需的一些列活动的集合，认为软件测试是一种典型的软件质量保证措施，软件测试的目的是为了发现潜在的软件缺陷，软件测试工作贯穿软件项目的始终。按照Daniel Galin软件质量保证框架组织课程内容有助于保持软件测试与软件质量保证之间的内在联系，符合软件企业软件测试与质量保证的最新经验。

（二）实验设计

如何在有限的实验课时内，最大限度地加深学生对软件测试、软件质量保证的理解，增强其软件测试实践能力，是实验教学的主要任务。我们设计了导入性实验、基础性实验、创新项目实践三种类型的课程实验。导入性实验要求学生应用已修课程（包括程序设计、数据库设计、软件工程等）知识进行软件调试，在软件调试过程中理解软件调试与软件测试、软件质量保证之间的关系，实现到本课程学习的过渡；基础性实验目的在于强化课程基础理论、原理的理解，让学生在实验中理解所学知识，掌握软件测试工具的使用；创新项目实践以课程实训项目为载体，为学生运行所学知识解决软件测试实践过程中涌现的各类问题，锻炼学生的动手实践能力、自主学习能力，从而提高学生的工程实践素养。

1.导入性实验。软件测试的目的是发现软件系统中潜在缺陷，而缺陷的解决则通过软件调试手段实现。为此，设计导入性实验“软件调试”。本次实验以员工工资核算软件Employee作为实验对象，要求学生发现Employee中人为注入的软件缺陷，然后应用Java调试器的断点调试功能，结合回归测试手段修订所发现的缺陷。

通过导入性实验，学生体验了改正软件缺陷的艰辛，在教师引导下思考如何发现软件缺陷、如何提高软件质量。教师适时点拨学生，指出发现软件缺陷是软件测试工程师的职责，软件测试工程师需运行软件测试方法、技术和工具才能发现潜在的软件缺陷。教师进一步启发学生：提高软件质量需要开展包括软件测试在内的各项软件质量保证工作。

2.基础性实验。基础性实验旨在加深学生对课程基本概念、原理的理解，让学生在动手实践中加深对基础概念、原理的理解。课程安排8次基础性实验，实验2、3、4和5属于软件质量保证实验，6、7、8和9是软件测试实验。

（1）实验2：软件度量实践。实验2关注软件度量问题，介绍软件规模、项目工作量和软件成本之间的关系，要求学生掌握软件规模估算、工作量估算和成本估算的方法和过程。通过本次实验，学生可以应用USC CoCoMo II进行软件成本估算。（2）实验3：基于Microsoft Project的软件项目管理。软件项目计划及进度管理，是软件质量保证中重要的管理部件，也是开展软件测试活动的前提。实验3要求学生使用Microsoft Project建立软件项目计划、运用跟踪甘特图追踪项目进度，等等。（3）实验4：版本控制软件CVSNT。CVSNT是当前最流行的版本控制系统，是中小企业进行版本控制的利器。实验4讲解CVSNT的安装和使用，要求学生掌握CVSNT的操作技巧。（4）实验5：BugFree软件缺陷管理。软件缺陷管理贯穿软件测试项目的始终，记录软件缺陷从发现、修复直至关闭软件缺陷的全过程。实验5介绍开源缺陷管理软件BugFree的软件缺陷管理思想，要求学生掌握BugFree安装与配置、软件缺陷管理等技能。（5）实验6：软件静态测试。软件静态测试是软件测试技术中发现软件缺陷效率最高的技术。我们安排“软件静态测试”专题讲座，讲解软件制品阅读、静态分析的技巧，还介绍如何运用CheckStyle、FindBugs等静态测试工具分析程序源代码、目标程序中潜在缺陷。本次实验有学生利用课后时间，自主实践。（6）实验7：JUnit单元测试。实验7介绍单元测试工具JUnit的使用，要求理解JUnit单元测试框架，掌握单元测试脚本的编写技巧。本次实验还推荐学有余力的学生自学JMock，综合应用JUnit和JMock进行对Java应用系统进行集成测试。（7）实验8：软件功能测试。软件功能测试是检验目标软件是否正确实现了客户需求，是软件测试执行的重要内容。实验8要求学生使用QuickTest Professional（简称QTP）对机票预订系统进行功能测试。本次实验要求学生能够独立完成功能测试脚本的录制和编辑，掌握QTP检查点设计的方法及技巧。（8）实验9：软件性能测试。实验9介绍软件性能的概念和原理，讲述如何运用HP Mercury LoadRunner对Web系统进行性能测试，让学生在实验过程中理解虚拟用户技术，掌握基于LoadRunner的性能测试技术的过程及技巧。此外，本次实验要求学生利用课余时间使用开源的性能测试工具JMeter进行软件性能测试。

3.创新项目实践。为了培养学生的工程实践能力，我们从学生课程项目、毕业设计、大学生创新项目、开源软件项目等中筛选出软件规模适中的软件系统作为课程实训项目，让学生对课程实训项目进行系统化的软件测试，要到学生主动动手实践，在软件测试项目实践中培养工程素养。

在课程教学过程中，我们还加强对基础扎实、动手能力强、思维活跃的学生的培养，推荐这些学生参与到教师科研项目中，为学生在科研项目中积累软件评测经验。

四、结束语

《软件测试与质量保证》通过十余年的建设已形成了较完善的课程体系，十多轮的授课实践积累了丰富的教学经验，课程实验教学体系也日趋完善。

当前，我校正转型应用技术大学，这将对本课程的教学内容、教学方法、教学手段等提出更多、更高的要求。鉴于此，本课程教学团队正尝试通过校企合作模式开展课程教学活动，编写校本教材，多措并举提升学生软件测试能力。

参考文献：

[1]朱少民.全程软件测试[M].北京：电子工业出版社，2007.

[2]NIIT.Software testing and quality assurance[M].上海：NIIT（中国），2011.

软件故障模型驱动软件测试 第7篇

1 软件故障与软件测试

蔡开元先生对软件失效机理进行了如下描述:软件错误是一种人为错误, 一个软件错误必定会产生一个或多个软件缺陷;当一个软件缺陷被激活时, 便产生一个软件故障。同一个软件缺陷在不同条件下被激活, 可能产生不同的软件故障;软件故障如果没有及时的容错处理, 便不可避免的导致软件失效, 同一个软件故障在不同条件下可能产生不同的软件失效。这样的复杂关系如图1所示。

图1可以很好地说明软件故障产生与测试的复杂性, 软件功能层面的失效往往是由各种特定的条件和环境决定的, 存在必然的复杂性和多样性。而测试虽然能从软件的不同层次开展测试, 但如果不能从问题的根源处着手, 要测试出全部问题是不可能的, 这也导致了测试再充分也不能保证测试后的软件没有问题。同样地, 我们也能看出, 如果从问题产生的根源出发开展软件的测试, 是可以将后续环境中无穷发散的问题解决的。这无疑是改善测试不确定性和盲目性的一个有效办法。

2 用软件故障模型驱动软件测试

软件故障模型 (SFMEA) 从发生的软件错误入手探究和分析导致软件故障模型, 是寻找软件问题产生的根源的一种有效方法, 是软件测试的基础。这里以成熟的动态内存故障模型为例阐述利用故障模型来驱动软件测试的方法。

2.1 动态内存故障分析

(1) 动态内存是一个自由存储区域, 编程人员根据需要, 利用编程语言提供的动态内存管理命令, 进行动态内存的分配、访问、回收等操作。各类操作后的结果与该内存区域当前所处状态紧密相关, 由此产生了动态内存使用过程中的各类问题, 在分析导致其错误的原因的基础上, 可以建立动态内存故障模型。如图2所示。

Start表示开始状态;Memory Allocate表示对内存进行动态内存分配, 若没有足够的动态内存, 则内存指针为N ULL;Ch ec k Memory检查动态内存分配的结果, 以保证后续动态内存操作的正确性;Access Memory表示对动态内存中的内容进行写、读、修改等操作;Free Memory表示动态内存操作结束, 进行动态内存的释放;End表示结束状态;

(2) 动态内存的四个核心操作缺一不可, 且在不同状态下操作也有约束, 由此导致了诸多与动态内存使用相关的问题, 如图3所示。

图3中的连线表示了引起动态管理错误出现的几种操作, 箭尾表示当前的动态内存管理状态, 箭头表示在当前状态下的操作请求, 将引起动态内存错误产生的操作请求进行分类, 可分为如下几类:1) Memory allocate操作请求引起的错误, 在图中, 6, 5, 7表示了与动态内存分配操作请求有关的错误。2) Check memory操作请求引起的错误, 图中连线10表示了动态内存检测操作有关的错误。导致错误发生的原因是在动态内存释放之后, 又对动态内存进行检测 (试图重新使用已回收的动态内存) 。3) Accessmemory操作请求有关的错误。在图中, 3、9表示了由内存访问引起的错误。导致该错误出现的原因有两个, 3表示在动态内存访问之前未进行指针P的检测, 本文将这种错误定义为空指针引用, 操作9表示在动态内存释放之后, 重新进行动态内存的访问, 从而造成动态内存的未分配使用错误。4) Freememory操作请求引起的错误, 1, 11表示了由动态内存回收操作引起的错误, 1表示没有进行动态内存的分配而进行动态内存的释放, 11表示在对指针变量P进行了动态内存的释放之后, 重新进行释放工作, 这两种情况是等价的, 即在没有可以用的动态内存的情况下, 尝试使用动态内存空间, 产生了动态内存未分配使用错误。5) 与end有关的错误。在图中, 2, 6, 8表示在程序结束阶段出现的错误, 导致错误产生的原因是在进行了动态内存的分配、检测或访问之后, 没有进行动态内存的释放, 因此, 造成了内存泄露的问题。

以上就是动态内存故障模型分析的核心部分, 这样的故障模型能从问题产生的根源出发阐述软件缺陷发生的机制, 为软件测试提供了一个寻求有效测试方法的窗口。

2.2 故障模型驱动软件测试

(1) 在有了软件故障模型之后, 在软件测试时即可针对这类故障的根源开展测试, 做到有的放矢, 达到通过测试将该类软件问题从程序中剔除的目的。动态内存故障模型从动态内存故障产生机理开展分析, 切入软件代码编写的最初级过程, 我们这里以C语言为例阐述利用动态内存故障模型驱动软件测试的过程。C语言中与动态内存管理相关的操作有几类, 可以分别与动态内存管理的四个阶段对应:1) 动态内存分配类操作:如malloc;calloc;realloc等动态内存分配类函数。2) 动态内存检测类操作:内存指针检测if (p!=NULL) , 动态内存初始化memset等操作。3) 动态内存读写访问类操作:各种动态内存空间赋值、引用、函数间的调用等, 都可能形成动态内存的读写操作。4) 动态内存释放类操作:如free等内存释放函数。

(2) 与故障模型进行对应之后 (见图4) , 即可开展软件测试工作, 最简单的方式就是采用人工走查代码的方式进行, 这类方法对程序结构简单、规模不大的程序还是很有效的, 可通过同行评审等方式开展, 能很快排除与动态内存故障模型相关的软件错误, 进而达到根除该类软件错误的目标。

(3) 软件系统高速发展的今天, 小规模、结构简单的程序越来越少, 动态内存管理越来越复杂, 通过简单的人工代码走查方式明显跟不上时代的发展, 随之各类软件测试工具供应商推出了多种软件测试工具来解决这种大规模复杂情况下的软件代码故障检测问题。比如klockwork、C++Test等等, 成为了帮助软件开发、测试人员发现并解决软件问题的有力工具, 其核心也是依据不同软件故障模型对程序代码进行检测, 提供明确的软件故障指示。针对动态内存管理故障模型, 检测软件一般通过数据流分析、制定检测规则、软件故障检测三个过程来检测问题。1) 数据流分析:程序中的数据流分析可以描述出程序的结构流程, 变量间的定值与引用关系, 为故障检测提供有力支撑, 主要方法有到达-定值数据流分析法和活跃变量数据流分析法。2) 制定检测规则:在数据流分析的基础上, 通过抽象命名, 把规则涉及实体进行命名, 再依据软件故障模型制定工具检测遵循的规则, 并将规则转化为方便工具自动处理的“语言”。3) 软件故障检测:在数据流分析和检测规则的基础上, 完成对软件特定故障的检测, 并提供个性化的展示、统计和分析能力。

综上所述, 在软件故障模型成熟之后, 据此开展更有效的软件测试活动是可行的, 也为软件自动化测试工具设计提供了依据。使用软件故障模型驱动软件测试可以按如图5所示流程开展。

首先在故障模型研究的基础上, 对需测试的对象按照故障模型进行实例化, 完成由模型向具体问题的转化;然后对模型实例进行分析, 研究发掘更优更有效的测试方法, 并用测试方法对对象进行测试确认, 不断循环分析和方法优化的过程, 直至找最适合的方法;用寻找到的方法对一类问题进行普适性确认, 因为故障模型本身就是从众多实例中抽象提炼出来的模型, 因此普适性验证重点关注方法的效率和重用度;对于重用度高, 通过工具可以大幅提高效率的方法还可设计自动化测试工具对方法进行固化。

3 结语

现代信息技术的不断发展, 软件应用已经无处不在, 通过软件故障模型来指导软件测试是提高软件可靠性的一个有效办法, 其核心是不断地总结提炼科学有效的软件故障模型, 在应用场景和方式也日趋复杂的今天形成准确的软件故障模型是件不容易的事情, 特别是从覆盖度上要能让软件故障模型覆盖所有的软件故障更是困难, 即便如此, 发掘和提炼软件故障模型仍然是值得的, 可以让测试更有针对性, 更自信, 更有效。提炼软件故障模型需要大量的工程实践作为基础, 通过假设故障存在、反向推理、实践验证的方式进行。当前软件故障模型偏重于由软件代码层次, 对软件应用环境、模式、行业特点等方面指导系统级测试的软件故障模型还很欠缺。完善软件故障模型并应用到测试行为当中还是一个很长期的过程。

参考文献

浅谈手机软件测试的流程与策略 第8篇

随着科技的进步,手机与我们的关系已经到了密不可分的地步,手机扮演着通讯工具、多媒体、网络等多方面的角色。同时,用户对手机软件的质量、性能也提出了更高的要求。在商业模式的驱动下,手机的开发周期不断的缩短,更要确保手机软件质量。产品的软件质量与手机厂商的切身利益、市场竞争力和信誉度息息相关[1]。目前我国的手机软件测试的发展还处于刚刚起步的阶段。国内的手机厂商对手机软件测试的理解不够,在软件测试上投入的精力不够,因此不能制定出详尽的手机软件测试流程及测试策略来完成手机的软件测试工作。本文针对这一现象结合作者的实际工作经验,对手机软件测试的流程和策略进行的初步的探讨。

1 手机软件测试流程

1.1 手机软件测试是迭代的过程

手机软件测试是一个迭代的循环往复的过程。事实证明,测试工作的早期介入,可提早发现错误,避免不必要的生产花费和资源投入,因此手机软件测试将会从开发初期开始伴随整个手机软件开发的生命周期。手机软件开发采用的是面向对象的开发方法,它的生命周期模型是迭代生命周期模型(Iterative Lifecycle Model)。

1.2 一个循环迭代

1.2.1 需求分析阶段

测试人员与设计人员一起参加需求调研,编写软件质量需求,制定测试计划,尽早发现软件设计上存在的缺陷和任务书上不合逻辑的地方。

1.2.2 设计阶段

与设计人员一起参加软件结构设计和详细设计,熟悉设计方案,制定测试方案。

1.2.3 实现阶段

即是软件编码与单元模块测试阶段,对于手机测试而言,每个功能模块即是软件测试的最小单位划分,测试人员编写测试用例对某一功能模块进行测试。

1.2.4 回顾阶段

开发人员同测试人员一起对该阶段软件进行评估,回顾软件需求、改变或增加新的需求说明。自此,一个开发测试迭代完成[2]。

1.3 循环迭代至系统稳定

在完成两到三个模块的迭代及单元测试以后,将开始集成测试。把各模块集成在一起时,测试它们是否正常运行。集成测试介于单元测试和系统测试之间,起到“桥梁作用”[3]。迭代次数增加,软件逐步成熟的时候,测试将转入系统测试。系统测试一般由独立测试人员执行,通常采用黑盒测试方式。粒度最大,主要测试系统是否符合“需求规格说明书”[4]。循环到当在一段时间内测试出来的缺陷稳定维持在一个较少的水平线上,且出现的问题足以忽略时,可认为系统已初步稳定,即交付验收测试[5]。

2 手机软件测试策略

2.1 测试用例设计、测试策略

在测试一款产品的时候编写的测试用例要紧扣需求上描述的基本功能,少量的涉及到使用频率较高的功能交互,不涉及界面布局等GUI元素。这样做的好处是测试用例没有跟某一款产品的关联太紧,支持在同一个系统平台衍生出不同的很多款手机,完成同一系列的用例可以完全或部分复用于整个平台的其他产品,从而减少劳动力,缩短开发周期,降低商业成本[6]。当然,不同的硬件产品一定要有不同的测试侧重点,由于硬件不同引起的问题不同的例子也不在少数。

设计的所有用例将形成一个测试用例库,在每个迭代开始的时候,测试组长都会选取一部分用例组成测试用例集进行测试,选取的用例通常分两部分:一部分是基本功能的用例,保证这次迭代的软件能够实现最基本的功能;还有一部分是上次迭代时发现错误比较多的模块,在开发人员修改以后做一次比较集中的回归测试。

2.2 交互测试策略

手机软件是一个比较复杂的系统,仅仅靠测试用例里针对基本功能的测试是远远不够的,用户经常会在不知情或有需要的情况下打开很多个应用程序,或正在运行某个应用程序的时候有其他的手机跟他进行交互,这就产生了交互测试。这部分测试主要是通过测试人员常年积累的测试经验和对错误的敏感度来发现错误的。

2.3 错误报告、追踪策略

在测试中发现问题固然重要,但是在发现之后编写错误报告同样不可忽视。一个好的错误报告可以引导开发人员找到问题根源,及时解决问题。编写错误报告时一定要做到客观,真实,详细。详细描述问题发生的环境,步骤,版本,重现率,等等,并且只做到客观的描述问题现象,不做任何没有根据的猜测,以免误导开发人员。在有能力的情况下,提供错误记录,协助开发人员重现问题,确定问题本质。

报告错误以后要定期追踪所报错误状态,与开发人员沟通,确定错误修改进程。若错误修正,及时在新版本上对错误进行回归测试。

2.4 灰盒测试策略

在白盒测试中交叉使用黑盒测试,在黑盒测试中交叉使用白盒测试的方法称为灰盒测试。灰盒测试就是介于白盒测试和黑盒测试之间的测试,最常见的灰盒测试是集成测试[7]。测试人员可以在既通过用户界面测试又了解软件功能的源代码程序怎样设计的情况下,有的放矢的进行某种确定的条件/功能测试[8,9]。

2.5 临界测试策略

当手机的某些可用资源达到或者超过理论允许的极大值时,在手机上继续进行某种操作时候的测试,此时手机的行为应该是友好的,可被用户接受的。

2.6 自动化测试策略

手机功能众多,回归测试工作量大,且测试中常碰到很多重复性高的工作,手动执行的话费时费力,也容易让测试人员产生疲倦甚至是厌倦心理,很容易造成测试的遗漏。如果能有一套自动执行的机制,将能大大提高测试的效率。

2.7 性能测试策略

性能测试主要测试手机的反应速度是否达到标准。它通过计算手机在完成一个操作所用的时间来衡量[10]。

3 手机软件自动化测试应用举例

3.1 自动化测试工具简介

手机软件自动化测试工具Brat是一个手机自动化测试的平台,它通过手机驱动端口连接手机与PC,由Tcl脚本语言搭载其中,完成测试化脚本的开发。Brat具有脚本可视化显示、控制脚本循环操作批量操作、判断测试用例是否通过和产生运行日志的功能。

3.2 例子

3.2.1 测试用例的编写、执行

如表1测试用例。

3.2.2 测试结果

Brat运行完发送短信500遍以后的结果如图1所示,可见测试Pass。Brat还可提供运行的日志记录,以便在运行Fail的时候查找问题原因。

4 结论

本文通过对在实际工作中总结的手机软件测试的流程和策略的探讨,给予我国手机软件测试流程和策略一定的参考,说明了规范流程和拓展策略的重要性。并采用自动化测试方法进行了实测应用,实践证明基于自动化测试工具的平台,搭载开发的测试脚本,并结合一定的测试经验进行的自动化测试,完全可以达到软件压力测试标准,保证压力测试质量,缩短测试周期,提高测试效率。

参考文献

[1]秦烨,康伟,韩佳.浅谈黑盒测试技术在手机软件测试中的应用[J].今日科苑,2008.

[2]赵会群.通信软件测试技术基础[M].人民邮电出版社,2004.

[3]丰彦.软件测试的系统测试方法[J].引进与咨询,2005.

[4]Grenford J.Myers The Art of Software Testing[M].机械工业出版社,2005.

[5]林宁,孟庆余.软件测试实用指南[M].清华大学出版社,2004.

[6]刘海鹏.手机软件测试简介[J].科技咨询导报,2007.

[7]古乐,史九林.软件测试技术概论[M].清华大学出版社,2004.

[8]路金良.手机软件开发的质量控制[J].中国科技信息,2009.

[9]叶振宇.智能手机软件开发中的质量控制策略[J].绍兴文理学院学报,2005.

软件可靠性和软件测试 第9篇

关键词：软件可靠性,软件测试,关系

随着信息技术的快速发展, 对软件功能需求也逐渐提高, 软件复杂性也越来越高。基于这种环境下, 软件可靠性要求也越来越高。软件可靠性在一定程度上决定了软件可靠性, 而软件测试在一定程度上为软件可靠性提供了保障, 由此可见, 对软件可靠性和软件测试进行更深入研究是软件领域重要的工作之一。

1 软件可靠性

1.1 软件可靠性概述

在规定的条件下, 在规定的时间内, 软件不引起系统失效的概率, 该概率是系统输入和系统使用的函数, 也是软件中存在的缺陷函数。系统输入将确定是否会遇到已存在的缺陷。在规定的时间周期内, 在所述条件下程序执行所要求的功能的能力。软件可靠性的三个要素分别是规定的时间、规定的环境条件以及规定的功能。1) 规定的时间。在软件的运行阶段体现着软件可靠性, 因此, 一般采用“运行时间”t作为时间的尺度。这主要是因为具体要处理的问题是多种多样的, 把运行时间t当作随机变量来考虑主要是因为具有随机的输入环境、随机的选取程序中相应程序路径、随机的软件失效。软件系统运行后工作与挂起的累积时间作为运行时间。2) 规定的环境条件。环境条件指的是软件的使用环境, 无论是什么软件, 如果不对它的使用环境加以限制, 都是会失效的, 这中实效的数据是不能用来度量软件的可靠性。这里的环境条件包括与程序存储有关的计算机及其操作系统, 也就是指的是软件的运行环境, 软件系统运行时所需的各种支持要素都和环境条件有关, 例如:操作系统、支持硬件、支持软件等等。3) 规定的功能。在对软件可靠性进行考虑时, 首先应该知道软件有什么功能, 主要的功能是什么, 次要的功能是什么, 对这些的了解可以通过软件需求分析说明书和设计说明书。规定的任务和功能都和软件可靠性有关。软件的运行剖面随着完成的任务的不同而不同, 因此, 调用的子模块也就不同, 那么可靠性也可能不同。因此, 明确软件的任务和功能是保证准确度量软件系统的可靠性的前提。

1.2 软件可靠性模型

对于可靠性增长模型:

对于公理模型:

软件故障数

软件模型

1.2.2 数据模型

软件运行一次出现故障的概率。

如果τ (ei) ≠F (ei) , 如果τ' (ei) =F (ei) , P1=ni=∑1 (Yi⋅Pi) 其中iY=10。

1.3 软件可靠性测试

软件可靠性是程序在给定的时间间隔以及给定的环境条件下, 按照需求, 衡量程序执行所要求的功能的能力。根据定义, 软件可靠性包含了以下3个要素:给定的时间、给定的条件以及所要求的功能。1) 给定的时间:运行时间。2) 给定的条件:软件的运行环境。3) 所要求的功能:需求说明书上明确的任务和功能。软件可靠性测试是在使用典型的环境中, 为进行软件可靠性估计而对该软件进行的功能测试。需要说明的是, “典型环境”指的是在统计意义下该环境能反映出软件的使用环境特性。

2 软件测试

软件测试就是对产品进行功能和性能的测试, 并且要根据测试方案和流程再利用测试工具进行, 甚至还要对不同的测试工具要根据具体情况进行编写, 并且还要对测试系统进行设计和维护, 分析和评估测试方案可能会出现的问题。在执行测试用例后, 为了能够确保开发的产品适合需求, 需要进行跟踪故障。

2.1 软件测试方法

2.1.1 白盒测试

白盒测试也称为结构性测试, 它是对程序的内部结构进行测试, 因为牵涉到程序的内部结构, 所以这种测试方法一般在公司内部进行。白盒测试的测试方法主要有逻辑覆盖法, 基本路径测试法等。

2.1.2 黑盒测试

黑盒测试不需要测试人员对软件的内部结构有深层次的了解, 所进行的测试着重于软件的功能面, 所以也称为功能测试。黑盒测试需测试人员按照测试用例来进行, 主要的测试方法有等价类划分法、边界值分析法、因果图法和场景分析法等。

2.2 软件测试过程

软件测试过程一般分为四个步骤进行:单元测试、集成测试、确认测试和系统测试。

2.2.1 单元测试

单元测试是在软件开发过程中要进行的最低级别的测试活动, 在单元测试活动中, 软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试通过是采用白盒测试方法进行的, 使得单元内部的程序错误能够尽可能的发现。一般测试用例是分析单元的结构通过一种或者多种白盒测试方法进行, 得到一些测试用例, 然后再根据单元规范对原有的测试用例用黑盒方法进行补充。

2.2.2 集成测试

集成测试是指根据实际情况对程序模块采用适当的集成测试策略组装起来, 对系统的接口以及集成后的功能进行正确性检验的测试工作。集成测试通常采用灰盒测试。集成测试要求每增加一个新的单元, 必须对所加入的单元和已存在的单元之间的接口进行验证, 看其的正确性, 然后还要在新层次上进行类似单元测试的测试。集成测试的优点是:可以并行调试所有模块, 需要的测试用例数目少, 测试方法简单、易行。然后它也有一定的缺点:不能充分对各个模块之间的接口进行充分测试;不能很好的对全局数据结构进行测试;如果一次集成的模块数量多, 集成测试后可能会出现大量的错误;即使集成测试通过, 也会遗漏很多错误。

2.2.3 确认测试

确认测试是指检查产品是否满足在项目的需求阶段定义的确认准则, 或者说是否具备在真实环境中使用的条件。其实确认测试就是平常所说的验收测试, 这个阶段主要是检查程序所有的功能是否都已经实现。

2.2.4 系统测试

系统测试是指对完整集成后的产品和解决方案进行测试, 用来评价系统对具体需求规格说明的功能和非功能的符合性的测试。系统测试是既测试产品功能也测试产品非功能的唯一测试阶段。系统测试的目的就是发现可能难以直接与模块或接口关联的缺陷, 发现产品设计。体系和代码的基础问题。

3 软件测试是软件可靠性的一个重要保障

软件测试就是为了发现程序中的错误而执行程序的过程, 换句话说, 软件测试就是为了软件的可靠性而进行的。只有测试通过才能使系统具有较高的可靠性。而为了使软件测试的效率得到保证, 就必须使测试用例的合理和恰当得到保证, 并且一定要严格按照软件生存周期的方法进行软件开发, 前一阶段工作的完成是后一阶段工作开始的前提和保障, 而要使前一阶段提出的解决方案更进一步具体化就必须完成后一阶段的工作。并且要通过正式严格的技术审查和管理审查才能够说明每一阶段的结束。每一个阶段都应交出与所开发的软件完全一致的高质量的文档资料是审查的一条主要标准, 只有这样才能够使得在软件开发工程结束时保证有一个完整准确的软件配置交付使用, 从而软件的质量得到了保证, 也就是说软件可靠性得到了提高。

参考文献

[1]何巍.软件可靠性与程序结构.长春光学精密机械学院学报, 2001 (02) .

[2]景涛, 江昌海, 刘永祥, 胡德斌, 白成刚, 蔡开元, 等.软件可靠性分析、测试与评估工具——SRATE介绍.计算机工程与应用, 2005 (01) .

[3]张云岗, 刘春茂.软件测试技术浅析.技术与市场.2011 (02) .

[4]秦春燕, 姚竹亭.嵌入式系统软件测试的研究.机械管理开发.2008 (03) .

软件测试综述 第10篇

软件工程师的任务是设计软件蓝图, 再经过编码而实现软件产品。软件测试则尽力找出软件设计的失败与不足之处, 再加以纠正, 确保软件设计无差错地实现。表面看设计是建造, 而测试是破坏, 但最终的任务是要建造高质量的软件产品。

1.1 软件测试的概念

软件测试是在软件投入运行前, 对软件需求分析、设计规格说明和编码的最终复审, 是软件质量保证的关键步骤。测试的目的是以较少的用例、时间和人力找出软件设计开发全周期中各个阶段的错误以及软件中潜在的各种错误和缺陷, 以便分析错误的性质与位置而加以纠正, 以确保系统的质量。找错的活动称测试, 纠错的活动称调试。

从质量保证的角度看, 软件测试应定位于: (1) 监控软件开发过程, 是软件开发中不可缺少的一个环节; (2) 遵循为软件开发而建立的标准和过程; (3) 确保产品、程序中的不足之处能反馈给管理人员软件测试的原则。

1.2 软件测试的原则

(1) 测试前要认定被测试软件有错, 不要认为软件没有错误; (2) 要预先确定被测试软件的测试结果; (3) 要尽量避免测试自己编写的程序; (4) 测试要兼顾合理输入与不合理输入数据; (5) 测试要以软件需求规格说明书为标准; (6) 要明确找到的新错与已找到的旧错成正比; (7) 测试是相对的, 不能进行所有的测试, 要据人力物力安排测试, 并选择好测试用例与测试方法; (8) 测试用例留作测试报告与以后的反复测试用, 重新验证纠错的程序是否有错。

2 软件测试技术

2.1 测试目标

(1) 测试是为了发现程序中的错误而执行程序的过程; (2) 好案; (3) 成功的测试是发现了至今为止尚未发现的错误的测试。

2.2 测试方法

测试方法研究以最少的测试用例集合来测试出更多的程序中潜在错误。

按照测试过程中是否在实际环境中来分, 有静态分析与动态分析。

测试方法有分析方法 (包括静态分析与白盒法) 与非分析方法 (称黑盒法) 。

(1) 白盒法。白盒法是通过分析程序内部的逻辑与执行线路来设计测试用例所进行测试的方法, 白盒法也称逻辑驱动方法。这种方法按照程序内部的逻辑测试程序, 检验程序中的每条通路是否都能按预定要求正确工作, 白盒测试又称为结构测试。

白盒法的具体设计程序测试的方法有:语句覆盖、分支 (判定) 覆盖、条件覆盖、路径覆盖, 主要目的是提高测试的覆盖率。

(2) 黑盒法。黑盒法是功能驱动方法, 仅根据I/O数据条件来设计测试用例, 而不管程序的内部结构与路径如何。黑盒测试是在程序接口中进行的测试, 它只检查程序功能是否能按照规格说明书的规定正常使用, 程序是否能适当地接收输入数据产生正确的输出信息, 并且保持外部信息的完整性。黑盒测试又称为功能测试。

黑盒法的具体设计程序测试用例的方法有:等价类划分法、边界值分析法、错误推测法, 主要目的是设法以最少测试数据子集来尽可能多地测试软件程序的错误。

2.3 测试工具

(1) 负载压力测试工具。这类测试工具的主要目的是度量应用系统的可扩展性和性能, 是一种预测系统行为和性能的自动化测试工具。在实施并发负载过程中, 通过实时性能监测来确认和查找问题, 并针对所发现问题对系统性能进行优化, 确保应用的成功部署。负载压力测试工具能够对整个企业架构进行测试, 通过这些测试能最大限度地缩短测试时间、优化性能和加速应用系统的发布周期。

(2) 功能测试工具。通过自动录制、检测和回放用户的应用操作, 将被测系统的输出记录同预先给定的标准结果比较, 功能测试工具能够有效地帮助测试人员对复杂的企业级应用的不同发布版本的功能进行测试, 提高测试人员的工作效率和质量。其主要目的是检测应用程序是否能够达到预期的功能并正常运行。

(3) 白盒测试工具。白盒测试工具一般是针对代码进行测试, 测试中发现的缺陷可以定位到代码级。根据测试工具原理的不同, 又可以分为静态测试工具和动态测试工具。静态测试工具直接对代码进行分析, 不需要运行代码, 也不需要对代码编译链接和生成可执行文件。静态测试工具一般是对代码进行语法扫描, 找出不符合编码规范的地方, 根据某种质量模型评价代码的质量, 生成系统的调用关系图等。动态测试工具一般采用“插桩”的方式, 在代码生成的可执行文件中插入一些监测代码, 用来统计程序运行时的数据。它与静态测试工具最大的不同是, 动态测试工具要求被测系统实际运行。

(4) 测试管理工具。一般而言, 测试管理工具对测试需求、测试计划、测试用例、测试实施进行管理, 并且测试管理工具还包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的IT人员通过一个中央数据仓库, 在不同地方就能交互信息。

(5) 测试辅助工具。这些工具本身并不执行测试, 例如它们可以生成测试数据, 为测试提供数据准备。

2.4 测试步骤

软件系统的测试基本由单元测试、集成测试、确认测试和系统测试4个步骤组成。

(1) 单元测试。单元测试也称模块测试、逻辑测试、结构测试, 测试的方法一般采用白盒法, 以路径覆盖为最佳测试准则。单元测试在编码中就进行了, 其测试策略包括:单元测试设计测试用例要测试哪几方面的问题, 针对这几方面问题各自测试什么内容, 测试的具体步骤, 实用测试策略。

(2) 集成测试。单元测试之后便进入集成测试。尽管模拟了驱动模块和存根模块进行单元测试, 由于测试不能穷尽, 单元测试又会引入新错误, 单元测试后肯定会隐藏错误, 集成不可能一次成功, 必须经测试后才能成功。

(3) 确认测试。确认测试也称合格测试或验收测试。集成后已成为完整的软件包, 消除了接口的错误。确认测试主要由用户参加测试, 检验软件规格说明的技术标准的符合程度, 是保证软件质量的最后关键环节。

(4) 系统测试。由于软件是基于数据处理系统中的一个组成部分, 软件开发完之后要与系统中的其他部分配套运行, 比如将软件、硬件等各部件协调和通信等做综合测试。如安全测试、强度测试、性能测试等。

3 测试技巧和经验

(1) 在制定测试计划的时候, 就要考虑到测试的风险, 并选择要执行哪些测试, 并放弃哪些测试;测试计划的评审应该让开发人员参与;测试模型的制作应该尽可能贴近用户, 或者站在用户的使用立场上来测试软件, 此时应该能发现更多的问题。

(2) 由于测试发现问题, 在解决问题后还要重新测试, 因此测试的时间可能会比实际更长一些, 要识别和注意少数重要的方面, 而忽略多数次要的方面, 有时候少数的问题足以致命, 这些问题将是软件测试结果中重要性最高的错误。

(3) 错误的定位有时是很难的, 要找出必然发生的前因后果, 而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题, 解决办法之一是在错误报告中给予说明。

(4) 对错误的描述, 应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解, 其后果是可以想见的。

(5) 有时有经验的测试人员凭借直觉就可以发现一些问题, 这可称为“错误猜测”。

(6) 测试人员容易犯2种错误:一是测试人员发生判断错误, 将本没有错误的系统行为报告为错误, 或者将错误指定了过高的严重级别, 或者过高估计了问题的严重性, 这样会引起开发人员的不信任, 产生一种象“狼来了”一样的效果;二是测试人员将错误的严重性或优先级定得过低, 从而产生“测试逃逸”, 这样会造成产品质量的风险。以上两种错误应该尽量避免。

4 结束语

测试作为软件开发的一个必要的组成部分, 需要良好的组织和管理。使用软件质量规范, 编写和实现测试用例和模型, 可以有效地组织测试。测试经理要管理好团队, 很多人认为测试是枯燥乏味的事情, 而且似乎是低级的事情, 所以测试经理应该不断地激励小组成员, 为他们争取利益, 在时间进度上保证稳步前进。系统的建设最重要的结果就是获得客户的满意, 测试是保证系统质量的有力手段, 因此加大测试力度至关重要。

参考文献

[1]陈明.软件工程学[M].北京:科学出版社, 2002.

[2][美]Ron Patton.软件测试[M].周予滨, 姚静, 译.北京:机械工业出版社, 2002.

浅谈软件开发流程前期的软件测试 第11篇

【关键词】软件测试；软件缺陷管理；文档的测试和评审；软件测试流程

1.基于开发过程的测试流程

根据软件开发流程的特点，软件的开发流程可分为：产品立项、需求调研、概要设计、详细设计、编码&单元测试、集成测试、系统测试、验收测试几个阶段。

测试流程在项目立项时就与之同步启动，并且覆盖软件开发的整个流程。这就要求在进行软件测试过程中要考虑审核和评审软件开发过程中各个阶段的文档和产品。

在软件测试流程中加入考虑对软件开发流程各个阶段文档集产品的评审。那么就要对相应的评审或测试结果进行文档化，形成新的软件缺陷报告或记录。项目组长或高层人员通过对这些文档的阅读，可以清楚地知道软件在开发的各个阶段存在的问题，能将因前期设计问题出现的软件缺陷问题消除在萌芽状态，保证软件开发效率和软件质量。

软件测试的目的就是发现缺陷，而它的另一个经济目的是尽早发现缺陷，以降低修复或者售后的成本。事实上，许多统计资料表明，开发过程每前进一步，发现和修复一个缺陷的平均成本要提高10倍。在代码复查阶段，平均1-2分种能发现和修复一个缺陷，在初始测试阶段要10-20分钟。在集成测试时要花费1个小时或更多，在系统测试时要花10-40个小时。这就是为什么要在项目初期就要进行文档化和审核文档的重要目的之一，在文档阶段发现文档中需求方面和软件功能方面的缺陷，如果及时修改可以避免在编码阶段发现和修改需要的大量人力和时间，是项目能按照既定计划完成的保障。

文档化的另一个重要目的是，它是软件测试的根本依赖。无论是测试计划还是测试用例都是根据需求文档和详细设计文档编写的。如果在测试阶段修改需求文档或设计文档，那么相对的开发编码、测试计划和测试用例都要相应的进行修改，那么由此引发的人力和时间对整体项目来说都是巨大的风险。在早期的文档的评审可以有效的降低整个项目的风险的同时，也会让整个项目更加缜密。

2.软件缺陷管理

软件缺陷管理就是对软件开发过程中所发现的软件缺陷进行跟踪管理，并记录软件缺陷的状态信息，保证每个被发现的软件缺陷都能解决并关闭。软件缺陷管理是软件开发过程中项目管理流程中重要的组成部分。软件测试流程管理其在本质上就是软件缺陷管理的文档化、规范化流程。

软件缺陷管理工具就是软件测试和缺陷管理的最好帮手，软件缺陷工具的主要优点在于不用再担心在项目过程中发现的缺陷无人认领或者被忘记修改。每个缺陷从新建到被关闭的过程都是由它的作者负责推动的。那么试想需求缺陷由产品人员负责，产品功能缺陷由测试人员跟踪，由缺陷发现者主导协调好和开发人员的关系，让开发人员能更有效的对软件自身的缺陷形成有效的关注，减少开发人员在缺陷上的沟通成本，可以让项目运转的更加順畅，让缺陷解决过程中的成本得到有效的控制。软件缺陷管理工具在软件项目起到不可替代的作用，它的使用应该从项目立项就跟测试人员一起介入项目中。

3.结束语

任何软件开发组织想完全消灭软件缺陷都是不现实的，也是不可能实现的。要想开发出高质量的软件产品，除了要有严格的开发流程和开发标准外。在软件的开发过程中全程引入软件质量保障也是一种行之有效的手段。通过对软件开发流程各个阶段的文档和产品的评审和测试，形成详细的文档化结果，是保障软件产品质量和减少后期工作量的有效管理方案。随着软件规模的不断扩大，软件缺陷数量的不断增加，这个管理方案的优势就会更为显著。 [科]

【参考文献】

[1]商惠华，张春雷，吕维先.基于FPA的软件工程监理方法[J].微计算机信息，2008（21）.

[2]吕晓峰.软件工程监理的一般流程与监理要点[J].现代计算机（专业版），2004（06）.

[3]王锋，张睿，张燕.软件工程监理的实施策略[J].信息技术与信息化，2004（05）.

[4]聂林波，刘孟仁.软件缺陷分类的研究.计算机应用研究，2004（06）.

[5]徐芳.软件测试技术[M].北京：机械工业出版社，2006.

软件性能测试概述 第12篇

性能测试主要是获得模拟真实用户环境,对系统状况和性能进行预测。

1 性能测试简介[1]

对于要上线的系统,如何确定它的性能可以满足用户的需求;当系统的用户数将大幅增加时,应当如何调整系统,是增加应用服务器还是提高数据库服务器的配置,哪种方法才是最有效的。这些问题都和软件性能、软件性能测试相关。但不同的问题,在测试中关注的内容会明显的不同,为了了解这些不同的关注内容,在测试中肯定也应当采用不同的性能测试方法。

1.1 应用领域

性能测试的应用领域可以化为4个组成部分:能力验证、规划、调优、发现缺陷。

一个典型的能力验证问题会采用这样的描述方式:“某系统能否在A条件下具有B能力。”能力验证要求在已确定的环境下进行测试,在设计测试方案和用例时应根据典型场景。

“某系统能否支持未来一年内的用户的一倍增长”或是“应该如何调整系统配置,使系统能够满足增长的用户数的需要”的问题描述,通常是规划能力应用领域内的问题,是探索性测试。

性能调优是即为字面意思。需要注意的是保住每次执行时数据库具有相同的数据环境。而且,需要具有一个可用于比较的测试基准测试环境。

发现缺陷主要是采用并发测试的方法来发现系统可能存在的问题。

1.2 性能测试的方法[2]

性能测试(狭义)和负载测试是常见的类型,此外,还有压力测试、配置测试、并发测试、可靠性测试、失效恢复测试。

性能测试(Performance Testing)(狭义):在已确定的环境下运行典型的场景,验证系统系统是否达到预期的性能目标。

负载测试(Load Testing):不断增加压力,直到某个性能指标或者某种资源使用已经达到饱和状态,也称为可量性测试。目的是找到系统处理能力的极限。

压力测试(Stress Testing):测试系统在一定饱和状态下,如CPU、内存等在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误。出于这样的考虑:“如果一个系统能够在压力环境下稳定运行一段时间,那么这个系统在通常的运行条件下应该可以达到令人满意的稳定程度”,通常可以使用此方法判断系统的稳定性。

配置测试(Configuration Testing):对被测系统的软/硬件环境的不断调整,找到系统各项资源的最优分配原则。一般用于性能调优和能力规划。

并发测试(Concurrency Testing):通过模拟多个用户的并发访问,测试模块或者数据记录是否存在并发问题,例如内存泄露、线程锁和资源争用等。

可靠性测试(Reliability Testing):通过给系统加载一定的业务压力(例如资源在70%~90%的使用率)的情况下,持续运行一段时间,检查系统是否能稳定运行。通常,对一般的非关键的大型应用来说,一般让系统在峰值压力下,运行2~3天基本上就已经够了。

失效恢复测试(Failover Testing):是针对有冗余备份和负载均衡的系统设计的。

2 流程概述

性能测试通常由五个阶段组成:测试计划、脚本创建、场景定义、场景运行和结果分析,如图1所示。如果是划成六个阶段,则包含测试报告部分。

2.1 制定测试计划

了解该系统的功能,制定测试任务的优先级,预测负载的最高峰出现的情况。接着,确定测试的目标,例如“某个事物处理需要的时间”,“哪种配置能够提供最佳的性能”或者“系统扩充后,性能或可靠性是否受影响”等。最后,确定需要度量哪些性能参数,例如CPU使用率、典型业务的响应时间等。

2.2 创建脚本

以工具Load Runner为例,首先将最终用户活动捕获到Vuser自动脚本中,录制基本的用户脚本。然后通过插入事物和集合点等方法完善测试脚本,以增强脚本的灵活性。

2.3 场景定义

模拟大量用户的操作,通过配置和执行场景向服务器产生负载,验证系统的各项性能是否到达用户的要求。

2.4 测试执行

在测试执行,需要先对单个脚本单用户执行,以获得基准数据,然后在按照设定好的场景运行。在场景执行过程中,需要监视各个服务器的运行情况(具体性能计数器参见3.1性能计数器),例如响应时间、吞吐量、资源利用率等,确定系统瓶颈。

2.5 结果及分析

分析结果了解系统的性能状况并能够对性能进行提高。影响终端用户响应时间的瓶颈包括应用程序和服务器的吞吐量、终端到终端的Internet连接速度以及网络涌塞等,在运行过程中,可以监视各个服务器的运行情况。

3 性能计数器与工具介绍

3.1 性能计数器

监控指标根据性能需求确定。表1给出的是常使用监控的性能计数器。

3.2 工具介绍[3]

可以将性能测试的工具划分为三类:负载加压类、资源监控类、故障诊断类。有很多工具集成了这三类功能,例如,普遍使用的Load Runner。

主流负载性能测试工具:QA Load、Silk Performer、Load Runner以及开源的Open STA等。最为普遍使用的是Load Runner,它通过模拟实际用户的操作行为和实行实时性能监测,更快的确认和查找问题。

资源监控工具:UNIX主机用户可以直接使用topas,vmstat,iostat了解系统自身的健康工作状况;weblogic以及websphere平台可以通过自身的监控台,在上面可以了解到目前的JVM的大小、数据库连接池的使用情况和目前连接的客户端数量及请求状况等。目前的绝大多数的监控工具基本上是直接从中间件、数据库以及主机自身提供的性能数据采集接口获取性能指标,依赖于被监控平台自身的数据采集能力。

故障定位工具以及调优工具:在目前的主流测试工具厂商中,都相应地提供了对应的产品支持。比如Loadrunner模块中添加的诊断以及调优模块,Oracle自身提供的强大的诊断模块。

4 实例解析

某网站稿件管理发布系统,在上线之前,需要确定该系统性能是否达到以下需求:1)可以连续稳定运行12小时;2)CPU的使用率要低于80%,内存使用率低于75%;3)查询响应时间要低于2秒,上传稿件的时间要低于5秒;4)能够提供的最大事务处理能力为5笔/秒;5)能够支持最大50个用户并发。

分析:易知,测试性能测试做的是一个能力验证。需求1)是对系统的可靠性要求,所以需要使用可靠性测试方法;需求2)、4)、5)需要采用负载测试;需求3)在做负载测试和可靠性测试的过程即可验证。

以采用Load Runner工具为例,具体介绍测试过程[4]。

1)使用Vu Gen分别录制查询和上传稿件的脚本,并可以采用以下方法对录制的脚本进行优化

(1)插入事务,运行到该事务的开始点时,Load Runner就会开始计时,直到运行到该事务的结束点,计时结束。通过插入事务点,可以清晰的了解到每个事务操作的响应时间,以确定发生瓶颈的语句。

(2)插入集合点,插入集合点是为了衡量在加重负载的情况下服务器的性能情况。

(3)参数化脚本,为了更加真实的模拟实际环境,需要各种各样的输入,此时需要对脚本进行参数化。插入函数,Vu Gen中可以使用C语言中比较标准的函数和数据类型。

(4)插入Text/Image检查点,检查网页上是否存在指定的Text或者Image,验证Web服务器返回的网页是否正确。

2)根据实际使用情况在Controller中定义场景。(假设平时30%的用户使用的是上传稿件功能,70%使用的是查询稿件功能。)

选择Goal-Oriented Scenario为负载测试的场景类型,将“Trancations per Second”设为预定目标,值设定为5,30%的用户分配给上传稿件脚本,70%的用户分配给查询稿件脚本。选择Manual Scenario为可靠性测试的场景类型,设定15个用户执行上传稿件脚本,35个用户执行查询稿件脚本,运行时间设定为12小时。

3)首先单用户运行脚本,获得基准数据,然后按照设定的场景运行脚本,监控的CPU和内存的使用情况,以及随着用户的增加、运行时间的持续事务的响应时间。

4)Analysis分析结果

Transaction Response Time图。可以判断每个事务完成用的时间,从而可以判断出哪个事务用的时间最长,哪些事务用的时间超出预定的可接收时间。

Windows Resource图,实时地显示了Web Server系统资源的使用情况,可以把瓶颈定位到特定机器的某个部件上。

验证响应时间、CPU和内存的使用率是否符合需求,验证最大能够支持的并发用户数是否为50个。

5 结束语

在性能测试应用领域里,能力验证与规划是性能测试应用领域中相对容易的部分,如何对系统进行调优是更高阶段的技术。

摘要：随着对应用系统本身性能的关注,性能测试作为检测系统性能能否满足需求的重要手段应运而生。该文概述了性能测试应用领域和测试方法,并对测试流程和测试过程中的监控工具和性能计数器进行了简介,最后通过一个例子说明性能测试的具体操作。

关键词：性能测试方法,性能计数器,性能测试案例

参考文献

[1]柳纯录.软件评测师教程[M].北京:清华大学出版社,2005.

[2]薛冲冲,陈坚.软件测试研究[J].计算机系统应用,2010,20(2).

[3]徐进.自动化软件测试的分析[J].信息技术,2010(3).