在项目启动会议上，项目经理告诉大家说将在项目中采用自动化测试工具，然后指定你在下周的会议之前提交一份工具选型报告。你感到很惊讶，项目经理是从什么地方了解到自动化测试的，为什么突然对自动化测试这么着迷，你突然想起几周前某个工具厂商的销售人员曾经到公司拜访……

　　你忧心重重，难道项目经理已经掉入了所谓的自动化测试陷阱中？！

　　陷阱1：自动化测试工具是万能的！

　　到目前为止，还没有一款商业测试工具能支持从测试计划，到测试设计，再到测试执行的自动化。

　　你经常会在某些测试工具的产品推介会、演示会上看到演讲者展示测试工具的种种好处、优点，让你为自动化测试激动不已；但是他们往往不会告诉你自动化测试的难点所在，实施自动化测试的复杂度，以及所需的投入有多大。

　　你的项目经理也许就在这时候开始一步步迈向自动化测试的陷阱。

　　陷阱2：一个工具能适合所有项目

　　到目前为止，还么有一款工具可以支持所有操作系统环境。

　　你也许会被项目经理要求寻找一款可以支持所有实时嵌入式系统测试的测试工具，而你们的应用需要跑在各种操作系统环境上，包括VxWorks、Integrity、mainframe、Linux 和 Windows XP，编程语言包括Java和C++。

　　陷阱3：引入自动化测试工具后，测试人员的负担立即减轻

　　引入自动化测试工具后，并不会马上就减轻测试负担，事实上一开始往往会增加负担。

　　项目经理往往希望通过引入自动化测试工具来减轻测试负担。但是经验表明，在一个新项目中尝试实施并且有效地应用自动化测试，往往需要经过一条学习的曲线。测试的负担并不会马上减轻，但是项目经理却希望马上看到自动化测试发挥其威力，希望马上看到效果。

　　事实上，在一开始的时候，很大可能会增加测试的负担，因为测试工程师需要一段时间熟悉和掌握测试工具，而与此同时，手工测试一刻也不能停止，因此测试的负担没有减轻，反而加重了。

　　另外，自动化测试需要仔细的分析被测试应用程序，哪些部分需要和能够被自动化实现；并且需要仔细地设计和开发测试脚本。这些无疑都将加重测试的负担，尤其是在初始阶段。

　　陷阱4：引入自动化测试工具后，进度可以马上被压缩

　　上了自动化测试工具之后，整体测试进度不会马上缩短，相反，在初始阶段，往往会对进度造成一定的延误。

　　另外一个误区是，自动化测试工具能马上缩短测试时间表。但是由于测试的负担在初始阶段加重了，因此很自然地，我们不能期待进度缩短，相反，在引入自动化测试后，我们应该给初始阶段的进度表预留一些时间。一旦整个自动化测试的流程建立起来之后，我们就可以期待自动化测试给我们的进度带来积极的影响。

　　陷阱5：自动化工具是很容易使用的

　　自动化测试工具要求测试人员掌握新的技巧，通常需要额外的培训。应该制定培训计划，投入时间和成本，度过学习的曲线。

　　通常很多工具厂商都会夸大自己产品的易用性，他们会否认所谓的"学习曲线"。工具销售人员通常鼓吹所谓的"录制/回放"可以简单地记录下测试工程师的键盘和鼠标动作，然后再简单地回放出来。

　　但是，有效的自动化测试远远不仅仅是"录制/回放"那么简单。录制下来的脚本需要手工修改，以便让其可重用性和可维护性更强一点、更灵活一点，而这些都需要语言和脚本知识。因此他们需要针对工具和内建的脚本语言接受培训。

　陷阱6：所有测试都可以被自动化

　　并非所有的测试都可以被自动化。

　　自动化测试是手工测试的增强。乞求项目中的测试百分百实现自动化是不合理的。在首次引入自动化测试时，最好先验证一下，工具是否能识别出所有对象和第三方的控件。这对于基于GUI的测试工具来说非常重要，因为这类工具往往在识别一些个性化控件方面有困难，例如一些calendar、spin、grid控件，而这些控件被广泛应用在程序界面中，并且这些控件往往由第三方编写，大部分测试工具厂商未能跟上他们的发展速度。

　　测试工程师在碰到这种情况时要么放弃这部分应用了难以识别的控件的测试自动化，要么找出一些解决的办法。

　　另外，还有一些测试是基本上不可能被自动化实现的，例如，测试工程师可以实现自动化地把文档发送到打印机的过程，但是检查打印的效果（是否被正确地打印出来，有没有越过纸张打印线）这部分则必须人工进行。

　　至于哪些测试用例应该被自动化实现，可以参考下表决定：

		YES	NO
测试执行的次数	测试会被执行多次吗？
	测试会有规律地运行吗？例如经常被重用，作为回归测试的一部分或每日构建测试？
测试的关键程度	测试覆盖了软件功能的最关键部分的路径吗？
	测试覆盖了最复杂的部分吗？（通常是最容易出错的部分）
测试的代价	如果手工进行测试的话，是否不可能、非常难以执行，例如并发测试、持久性测试、性能测试、内存泄漏测试等。
	测试非常耗时吗？例如需要检查成百上千个测试结果输出。
测试的类型	测试需要组合很多输入，但是共用一个测试步骤吗？例如同一个功能，用很多不同的输入来验证。
	测试需要在多种软硬件配置环境下执行吗？
被测试应用或系统	测试是在一个稳定的应用程序上执行的吗？例如功能特性已经基本完成。
	使用兼容的技术和开放的架构

　　陷阱7：自动化能提供百分百的测试覆盖率

　　并非所有内容都可以被自动化地测试到。不可能覆盖所有可能的输入，所有可能的组合和路径。

　　自动化测试可以增加测试的广度和深度，但是仍然无法达到100%的测试覆盖率，因为没有足够的时间或资源。

　　例如一个简单的登录界面的测试，假设我们需要测试它的密码验证函数的正确性，密码长度在6到8个字符之间，每个字符可以大写或小写，至少包含一个数字，那么输入的可能组合将达到2,684,483,063,360个。

　　即使我们可以每分钟创建一个测试，也需要155年来完成全面的测试。因此，不可能穷尽所有可能的输入的测试。

　　陷阱8：测试自动化就是录制和回放

　　仅仅录制得到的不是有效的自动化脚本。

　　很多项目经理仍然把测试自动化等同于使用录制回放工具。而事实上，录制得到的脚本通常是不可重用的脚本，脚本中充满了硬编码的值，这些值应该被参数化，否则脚本仅仅适用于一个测试情况，脚本还应该加入条件判断、循环等结构，以便增强测试脚本的灵活性。

　　陷阱9：自动化的软件测试与手工的软件测试过程一样

　　自动化测试所需要的技巧与手工测试所需要的技巧是不一样的。

　　通常，你的项目经理会被那些测试工具销售们迷惑，认为自动化的软件测试就是简单地按一个录制的按钮，产生测试脚本。而事实上并没有那么简单。

　　区分自动化测试所需要的技巧与手工测试所需要的技巧是非常重要的。最重要的是，自动化测试工程师需要掌握软件开发技巧，没有接受任何培训的手工测试人员，或者没有编程背景的手工测试人员，在实施自动化测试时会碰到很多困难。

　　陷阱10：忘记了测试的最终目标：找到BUG

　　在自动化测试中，同样要注意把边界值分析、等价类分析、基于风险的测试方法、挑选最合适的测试用例等技术应用起来。

　　通常在自动化测试过程中，我们都忙着搭建自动化框架和编写测试脚本，但是我们往往忘记了测试的本来目的：找bug。

　　项目经理可能雇佣了最好的自动化开发人员来搭建框架，使用了最新最好的自动化开发技术，创建了成千上万的自动化测试脚本。但是如果BUG仍然被遗漏了，那些本该被自动化测试脚本捕捉到的BUG，结果没有被捕捉到，那么你的自动化测试仍然会被认为是失败的。

　　小结

　　正在你忧心重重，担心项目经理一步步迈向自动化测试的陷阱的时候，你看到了这篇文章，你决定拿给项目经理看看，希望他在看完这篇文章之后，对自动化测试有一个新的认识，从而把那只即将踏入陷阱的脚抽回来！

来自：http://www.51testing.com/?action_viewnews_itemid_106406.html

 

一、全球无线和移动设备制造商所面临的挑战

随着GSM、CDMA、WCDMA、CDMA2000及中国自主研发的TD-SCDMA等手机新技术的不断涌现，基于业务应用层面开发和测试比重的增加，复杂度的不断提高以及手机和传统上基于PC的应用服务的快速融合,使得手机测试的难度和工作量大大增加。同时,由于市场的竞争越来越激烈,每款手机的生命周期越来越短,手机厂商都希望领先于竞争对手将自己的新款手机投放市场以获得更多的利润,这就意味着留给手机研发和测试的时间将大大的减少. 在全球化市场中，设备制造商除按照地域性要求对终端功能进行定制外，还要满足国际移动运营商的入网测试需求，这对于国内终端设备制造商来说又是一个挑战。因此,如何在最短的时间内,最大限度地测试手机的各项功能和应用,有效的面对手机测试过程中日益增加的复杂性，并满国际移动运营商的需要，同时大幅降低手机测试的成本就成了摆在每一个手机厂商面前的一个重大课题。

二、全球无线和移动设备制造商的测试需求

为了提高最终用户体验，增加用户的忠诚度，移动运营商及移动设备制造商随着用户要求的不断提高以及通过不断的积累，都要求对移动设备在推向市场之前进行以下的测试：

l 功能性测试、压力测试、性能测试和回归测试

l 不同操作系统和硬件平台之间的兼容性测试

l 不同网络环境下的交互性测试

l 与其它厂商制造的设备之间的一致性测试

l 应用程序之间并发性测试

l 其它Non-UI测试

从此可以看出，测试工作非常复杂，并且工作量巨大。而现在很多国内的移动设备制造商还在采用手工测试，而手工测试是存在着很大的局限性的：

l 可靠性低：测试工程师在很小的手机屏幕上操作太久则容易疲倦，造成测试可靠性下降。比如，测试工程师可能会混淆‘O’和‘0’，或无意中跳过测试规范中的一页。
准确性差：比如，测试工程师难以发现包含100个字符的文本信息中的一个错误，或由于一步操作失误而不得不重新开始一个测试用例。

l 覆盖率小：手工测试难以发现出现概率较小的错误，或难以重现之前发现的错误。

l 一致性差：当测试并发事件时，需要同时操作多个终端或同时运行多个应用程序。手工操作很难控制。

l 测试过程的不可重现性。

l 测试速度较慢，无法进行7*24的工作。

因此，采用手工测试是不可能很好的在产品投向市场前的最后一关保证优良的产品质量的。

三、现有的自动化测试工具已难以适应无线和移动行业日益增长的测试需求

由于手工测试的一些弊端，很多移动终端制造商大都早已开始了自动化测试工具的开发及使用，然而传统的自动化测试工具对人员要求很高，而且还存在着操作系统，手机型号不同而导致测试用例的不可重用性。

l 需要用户具有很强的编程技巧，需要编写大量脚本(C/Tcl/Tk…)来创建测试用例。

l QA部门(组织)熟悉行业测试规范，但是一般没有自己的技术开发团队，难以完成大量的编程工作。

l 传统的自动化测试工具大多专门为某个手机平台或操作系统设计，很难应用于其它手机平台或操作系统。

l 市场上终端采用的硬件平台、操作系统以及网络制式各不相同。在传统的自动化测试工具中开发的测试用例很难在不同的终端之间进行移植。

四、TestQuest自动化测试平台 – CountDown

美国TestQuest公司作为在全球手机及移动应用测试领域的领先厂商,基于近10年来和Verizon等全球知名的移动运营商,Nokia、Motorola、Samsung、ZTE等手机厂商的合作过程中所积累的丰富经验,于2006年正式推出了第四代自动化测试平台CountDown,从而真正解决了对任何手机制式,任何操作系统以及任何硬件平台的手机进行自动化测试的难题.

l 专门为无线和移动行业设计的自动化测试平台。集成了测试开发、测试管理与测试执行功能；支持分布式研发团队之间测试资源的开发与共享。我们提供7/24的自动化测试解决方案，以帮助无线和移动设备制造商缩短产品在市场上推出的时间。

l 适用于所有类型(Windows Mobile/Symbian/Linux/Brew等开放式操作系统和专用/私有操作系统，所有硬件平台 GSM/GPRS/WCDMA/CDMA/CDMA2000/TD-SCDM等制式)的手机和手持终端设备，提供完整端到端的自动化测试解决方案。

l 自动测试过程基于UI(用户接口)/MMI(人机接口)实现：通过控制终端的键盘、旋钮和触摸屏来模拟测试工程师的双手操作；通过抓取LCD屏幕显示图像进行智能OCR识别来模拟测试工程师的双眼辨识文字或图像信息。真正实现独立于任何操作系统、任何硬件平台或任何网络制式的自动测试。

l 全图形化的开发环境，使得用户无需编写任何代码即可完成测试用例的开发、调试及运行。并且，开发完成的测试用例，无需改动或稍微改动，即可移植应用到其它类型的手机或手持终端设备。

CountDown自动化平台由TestDesigner, TestManager, TestRunner and AssetManager组成：

TestDesigner 是一个全图形化的开发环境。用户无需编写任何代码即可实现Test Case的开发、调试及运行。

TestManager 是基于 IE 浏览器开发的测试资源管理工具。帮 助用户进行测试规划、测试执行并对测试结果进行分析。

TestRunner / DAS(Device Access Software) 控制本地或远程终端运行测试任务，并将测试过程中产生的日志 (Log) 文件传送到TestManager 以生成测试报告。

AssetManager 使用 MS SQL Server 数据库统一存贮和管理测试资源，以方便各个分布式开发团队之间的资源共享。

CountDown的各个模块不但功能上相互独立，还可以根据用户的具体需求布置在不同的地理位置；真正实现了全球范围内团队间的协作开发。

 

可以真正实现：

l 测试任何类型的手机或手持终端设备

l 同时连接多个终端设备进行端到端的系统测试

l 测试资源跨平台的移植和重复使用

l 实现整个移动产业链上不同测试团队之间的开发协作

 

 

 

更多详细资料，请联系

TestQuest北京办事处：

地址：北京市朝阳区朝外大街20号联合大厦806室

邮编：100020
电话： (010)6588 7052-210

传真： (010)6588 7054

联系人：徐辉                      

E-mail: Tony.Xu@testquest.com(52RD.com)
本文来自：我爱研发网(52RD.com) 详细出处：http://www.52rd.com/S_TXT/2007_4/TXT6462.htm

随着GSM、CDMA、WCDMA、CDMA2000及我国自主研发的TD-SCDMA等手机新技术的不断涌现，基于业务应用层面开发和测试比重的增加，复杂度的不断提高以及手机和传统上基于PC的应用服务的快速融合,使得手机终端软件也越来越多，手机终端软件测试也应运而生，在这里简单的描述下手机终端软件测试的方法。

　　一、功能测试

　　手机终端软件的测试和其他PC上使用的软件的在测试方法上，或者说是测试策略上基本是一致的。软件测试贯穿于整个软件生命周期，同样也是需求评审-测试计划-测试案例/环境搭建-测试执行-测试报告输出-测试总结。

　　1.手机终端软件测试，需要测试人员，在需求阶段就介入其中，要参与需求的评审，这样才能够更透彻的了解需求，为测试案例的准备打下良好的基础。

　　2.在需求明确的情况下，测试人员就需要开始执行测试计划，搭建测试环境、准备测试案例。为确保能覆盖所有的功能点以及测试案例的高效、准备，最好是能够发起测试案例的评审，请需求人员、开发人员以及测试同行对测试案例进行评审。

　　3.当收到版本后，进入系统测试阶段，执行测试案例。

　　4.测试结束后，提交测试报告。

　　5.测试总结，其实也是测试环节中较重要的环节。测试完成后，对测试环节中好的方面和暴露出来的问题进行有效的总结，对软件测试过程进行改进，就是测试经验的积累很重要的一个过程。

　　二、性能测试

　　手机终端软件的性能测试，主要是针对手机终端软件本身的性能测试，手机终端软件的性能测试主要分为终端软件运行速度、终端软件运行资源消耗、终端功耗、终端网络流量等方面，主要运用第三方的一些工具，监控软件在运行特定业务的场景时手机资源的消耗情况。

　　三、自动化测试

　　版本较稳定的情况下运用自动化的工具来进行自动化的测试。

　　手机终端软件的自动化工具，市场上可选择的产品并不是很多，这里简单介绍一款手机终端软件的自动化测试工具是 TestQuest 的CountDown。

　　CountDown 自动化测试解决方案适用于任何手机硬件平台和所有手机操作系统，包括Windows Mobile（PPC, Smartphone）, Symbian (S60, UIQ), Linux和Brew等开放式操作系统以及专用手机操作系统，同时独立于任何手机制式和无线网络（GSM/GPRS/WCDMA, CDMA/CDMA2000, TD-SCDMA）。

　　CountDown 可以通过Host PC自动控制移动终端的键盘、旋钮和触摸屏，以模拟测试工程师的双手操作；并可自动抓取LCD显示内存中的位图文件，使用智能OCR技术来模拟测试工程师的双眼进行内容识别和逻辑判断。整个自动测试过程都是基于UI（用户接口）/ MMI（人机接口）完成，真正实现独立于任何OS、任何硬件平台和任何网络的功能测试、压力测试、回归测试、性能测试和交互性测试。TestQuest的自动测试方案可以最大程度地取代测试人员的手工操作，因此，可以大幅度地缩短用户手机测试所需要的时间，提高测试的覆盖率以及测试的准确性，在保证新品质量的前提下大幅度的缩短新产品上市的准备期。

　　CountDown 通过引入导航图（Navigation Map）的概念来简化测试用例的开发、调试、运行以及移植。通过简单的录制功能，可以方便地保存手机的关键屏幕内容以及屏幕之间的路径信息来生成导航图。所有跟手机有关的细节—如手机主题、屏幕尺寸、语言以及其它主观信息都被自动封装于导航图中。因此在导航图的基础上，无需编写任何代码即可完成测试用例的开发、调试和运行。并且，基于导航图开发的测试用例，无需改动或者稍微改动，即可移植应用到其他类型的手机。

 

来自：http://www.51testing.com/html/200902/n106050.html

“抢钱原则”——你面对飘洒满地的纸币，有100元，50元，10元，5元，2元，1元，5毛，2毛，1毛。 各种面值。大家抢钱的时候，都是先挑选100元的抢走，然后找50元的，选择的顺序很清晰，都是从面值大到面值小。这就是“抢钱”原则。

　　测试执行的时候，大家面对是一堆用例，这些用例起到的作用也是不同的，那么如何保证我们在有限的时间执行的用例是最有效的，最有价值的。

　　尤其是无法全部执行用例的时候，势必有裁剪的时候，我们需要有很好的用例执行的优选原则。

　　我们要应用抢钱原则，选择好最有价值的用例优先执行。那么，如果搞清楚什么样的用例最有价值，就OK。

　　用例价值大的用例主要有三个方面的因素：1 容易发现的故障的用例；2 用户最常用的场景；3 如果泄露，用户的生气程度大的。

　　1、容易发现故障的用例

　　1） 性能相关的用例—上游的环境受限，所以这个部分比如容易发现故障

　　2） 边界值相关用例—边界引发的故障比例最高

　　3） 开发部在集成测试最不容易做到的用例，比如场景复杂度高的

　　2、用户最常用的场景

　　1） 比如局内呼叫，做主叫，做被叫，短消息，预付费，彩铃等多是最常用的业务，这些业务如果出现问题，只有回退版本了。

　　2） 配置管理的号码分析，动态管理的查看链路状态，告警查看

　　3、如果泄露，用户生气程度大的

　　1） 比如无法拨打电话 > 可拨打，单通 > 可以正常通话，无回铃音 > 可以正常通话，回铃音有杂音

　　2） 无法出话单 > 话单内参数错误

　　如上的仅仅是一些实例，没有复杂的算法模型来排序用户行为。

　　总之：拿到用例，一定要先分析出最有价值的用例，再开始执行。如果拿到用例，平铺直叙的执行。 那咱不就成了抢钱时候先抢毛票的傻子了？

 

本文出自gracehjd的51Testing软件测试博客：http://www.51testing.com/?92844

　怎样做一个人见人爱的软件测试经理？

　　谈谈3年多的测试管理经验的心得，望大家多多指教，提出宝贵建议：

　　1.具有较好的人格魅力和亲和力：

　　真正来说做到这一点非常难。这不仅要求测试经理有宽广的胸怀，良好的沟通能力和语言表达能力，还要求测试经理具有较强的应对能力。向上能把工作汇报的让领导满意,令领导信任。能把工作任务轻松, 无异意的下发给下属, 并让他们饱含工作热情共同协作去完成测试任务。如果您能够把扭转下属的思想，把“要我测试，变成我要测试”，我想你一定很强了。如果陌生的人一见到你，通过谈话就觉的你很强，都愿意和你交朋友，那你的人格魅力一定不错了，呵呵。

　　2.最好具备较强的测试技术水平：

　　一般来说，作为测试经理，在一个测试技术性的团队里，如果你有很强的技术，并且你的技术是最棒的，下属不能够搞定的问题，你都能够做的很好，即时有时候你凶了点，团队里的成员心底里都还是很敬佩你。如果你有技术，但是技术不高，你组内的技术高手一定是你的亲密战友，这个时候唯一的出路就是凝聚团队的力量，取长补短，也能够取得较高的效率。还有一点值得注意：在分派工作的时候，找一下组内的骨干，看看是否有新的或者好的处理办法，这样一来，避免在开会的时候遇到分工或者技术上的尴尬局面。但有的测试经理具备了很强的技术，整天对团队的成员都板副面孔，那你也很难做到人见人爱。唯有为人处事比较圆滑，待人真诚中肯、随和亲切，整天都是笑脸相迎，那呆在这样的团队里工作，一定很开心。所以要做到人见人爱的测试经理，较强的测试技术水平不能够忽视。

　　3.乐意处理下属在项目中碰到的困难：

　　在带领一个团队开展测试工作的时候，当你的下属碰到困难的时候，你更多的是给下属鼓励和安慰，帮助下属分析出现问题的原因。比如说一下：“幸苦了”！“干得不错”！“慢慢来，没关系的”！下属听了也很开心的，并且以后干活可能会很卖命，因为他的工作得到了领导的认可。或许该问题你也不一定解决得了，这时候你一定要挺身而出，协调测试团队的资源尽力帮他解决问题，久而久之，你的威信就树立起来了，之后就好办事了。

　　4.勇于承担责任，把功劳推给测试团队：

　　软件测试经理，作为一个中层经理。管理者一定要想管好下属，必须“身先士卒”、“以身作则”，事事为先、严格要求自己，处处起到表率作用。示范的力量是惊人的，一旦通过表率在团队中树立起在员工中的威望。将会上下同心，大大提高团队的整体战斗力。常言到：“得人心者得天下”，做下属敬佩的领导，将使管理事半功倍。如果下属在测试项目中出现问题，上级领导怪罪下来，自己勇于承担，多检讨自己，少怪罪他人。始终用平和语气与下属沟通，最后一定要找出出现问题的真正原因。让出现问题的下属，自己过意不去，从心底里佩服你，想法补偿你。项目得到喜讯，比如：某个测试项目做的很好，领导表扬的时候，把功劳推给大家，很多时候，容易让人感动，让人佩服得“五体头地”哈哈。

　　5.对下属多一些宽容和生活关心：

　　特别是对下属不懂，自己懂得很精的地方，下属问的时候，一定要有耐心，给下属详细讲解。切忌：看不起下属。如果真是这样，你这个经理就很失败了。反正对下属，在很多地方，要多一些理解和包容，最好能和下属打成一片，当下属不认为你是领导的时候，你就真是领导了。如果做领导做到别人都当你是朋友，那你真的就成功了。

　　还有一点就是要察言观色，随时发现和了解下属的困难，不管是工作方面，还是私人方面，都要关心。比如说：某个下属买了房子，准备装修，那他一定很关心装修方面的东西。如果你懂得很多，那和他交谈时，多一些这方面的话题，他也会很开心，觉的你这个人相当热心，并且也会觉的大家有共同语言，以后当你碰到问题的时候，他一定会鼎立帮助你，因为他认为你是他最信任的知己。也可以多在生活上关心下属。比如有项目要加班什么的，有时候陪陪下属加班呀，吃个午饭宵夜呀，聊点家常呀什么的，自己买单后，公司报销，效果真的不错哟！

 

 

个人理解这个问题问的是一个优秀测试经理所应具备的素质和能力（当然啦最优秀的人也未必是人见人爱：）。

　　我认为一个好的测试经理应该具有如下几方面的素质和能力：

　　1、员工管理

　　我的管理哲学是要相信你的人并且让他们开开心心地工作，他们也会用优秀的成绩来回报你的。有人说管事不如管人，我觉得是很有道理的。细的来说应该向以下方向努力：

　　- 创造公平公正的工作环境。奖勤罚惰，鼓励创新（不要停留在口头上，要落实到制度）。很多时候不怕穷就怕比，不合适的奖惩很容易让优秀员工萌生去意。

　　- 对于员工的工作积极鼓励为主。通常人的物质需求很难被完全满足，但一句窝心的表扬或中肯的批评会让你的下属产生被尊重感。测试工作经常枯燥乏味，极具人情味的鼓励常常是最好的动力。

　　- 积极为下属着想。很多测试人员经常会为自己的将来担心。假如你能积极地去为他们设计将来就能够坚定他们的信念跟着你好好干。具体地你需要为他们做实实在在的职业规划，为他们争取更多的培训资源，不断地告诉他们的自身价值，不要光画饼。承诺的事情要兑现。对于工作认真负责的员工要尽力为他们争取合理的薪资福利，即便失败了他们也会感念你的爱护，加倍努力工作。

　　- 勇于替他们承担责任。很多时候测试经理是夹在管理层、开发组、客户、测试组之间的一块板，肩膀要够硬，要为你的人减压，成为他们的主心骨。

　　2、和老板的沟通能力

　　这是毋庸置疑的，当老板对你不满的时候你还能安心做你的测试计划么？有几点小诀窍：

　　- 定期汇报，经常让他感觉到你和你的测试组的存在。在公司里测试部门并没有受到足够的重视，常常被人忽视，要经常晒一晒你们的工作和产生的作用

　　- 经常报喜，很多公司是极端重视客户反馈的，用户的积极评价要第一时间“谦虚“地转到老板的邮箱里。如何让客户是不是地给点好评会在后面讲到

　　- 体现成长，测试团队的积极成长很容易让老板高兴。时不时地搞些技术研讨会，邀请相关经理们来听一听。但一定要精心准备，不然的话适得其反。

　　- 在报告里清晰地描述测试工作的进展，用扼要的数字让老板相信现在一切尽在你的掌控（也就是他的掌控拉）。将来也一样。对风险做清楚而充分的准备。

　　3、和开发的沟通

　　最怕看到的就是测试和开发的对立。要避免这个就需要让开发经理和开发人员知道测试存在的意义。大家都是为项目服务的。个人觉得测试经理应该具有一定的开发背景，理解测试人员的心理。要求测试组在项目前期帮助开发组理解，澄清需求，而不是一味提问题（特别是很傻的问题）。再后面可以帮助开发人员设计测试数据，走读单元测试。对于与测试相关的风险要适时提出。测试的缺陷报告要易懂易复现。测试lead应当要对测试组提交的结果把关。必要时测试经理也应当积极介入项目。对于产生的争议要尽快和开发经理或项目经理沟通，请求协调。鼓励测试组积极和开发组增加语言交流。这比冷冰冰的测试报告强的多。要是你手下mm 多质量又好的话要先恭喜一下了。

　　另外要增强自身的技术修养，要与开发人员有“共同语言“。这样交流起来就容易多了，也容易使开发人员产生尊敬。总而言之要站在项目的高度而不是测试部门的利益。有时间经常参加一下项目的会议，必要时从质量和流程的角度为开发组地过失作一些辩护。

　　4、客户关系

　　对客户没啥说的，一要积极，二要快。积极就是要有一定前瞻性，等问题出来了大家都不愉快。将问题扼杀在萌芽。举个例子如果客户对产品的测试工作有了微词，赶紧打电话给客户了解情况并提出改进意见。通常客户尤其是欧美客户会很欣赏这样的做法。等客户的抱怨信到了你老板那里大家的日子都不好过了。

　　前文提到要尽可能地向客户“讨”感谢信或表扬信。怎么弄？当然前提是工作要做好，日常沟通要到位。小技巧是为什么不换位思考，你要感谢信他们就不要么？他们就没有老板么？漂亮话是不要本钱滴

　　最后总结一下，一切以人为本，老板高兴了你就有资源，有资源了你的下属就会高兴，就会好好干活，工作质量就高，那开发也高兴，客户也高兴，客户高兴了你的测试团队就有更多的成长机会，同时老板也喜欢。这是一个非常好的良性循环。说起来容易做起来难，没有几分修为又怎能做到这样八面玲珑呢？

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自51Testing软件测试网，感谢会员sun_0910在每周一问（08-08-11）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

组里刚来了新人，刚好大家也帮忙看下，有没有带新人的时候有没有什么要改进的。

　　1、人际关系

　　这个很重要，我把这项列在了新人的今年计划上面，不光是QA内部，还有和DEV，公司QA，任何和工作相关的人的关系。 QA和DEV的关系很微妙， 所以我觉得新人如果给自己定位不对的话，很容易走歪。

　　2、态度

　　新来的MM每次问我问题都和我说谢谢，搞的我都不好意思了，但是这是对你起码的尊重。 听另外一个同事说， 他带的那个新人因为有靠山， 回答她问题变得理所当然的事情， 连谢谢都不说， 还指示他，你应该教我这个，教我那个， 那味道就不好了（同事和他的新人都是外国人……）， 所以那个新人来公司3，4个月了， 都没给她什么任务。

　　3、主动

　　我刚进公司那会， leader直接告诉我， application怎么下， test case在哪儿 (那时还没Use case呢)， 然后自己跑， 碰到问题再问。 然后我就每天把看的结果告诉他， 把问题列给他， 然后他再给我答复。 差不多2个星期就上手了吧。。不过也发现那个application上面很多bug，搞的我们leader都不好意思了呢~

　　现在我带新人， 基本就是把简单的流程演示下， 把相关的文档和test case发给他们， 照着文档跑。 然后有问题再问我。 因为我不可能把所有的东西一股脑的都传给新人， 更何况，每个人的测试思路都是不一样的。 有问题， 说明你在学习，思考， 然后才是有效的理解。 而且，我相信， 好的leader是喜欢会challenge自己的下属的。 所以， 作为新人， 要主动出击， 多问问题~

　　4、及时和Leader沟通

　　这个方面， 就不光是技术方面的了， 还包括对进公司的感受， 自己的职业发展方向的想法了， 要让leader觉得， 自己可以帮助到你， 不过说到底还是一个沟通技巧了。

　　还有一个方面就是技术上的准备， use case/requirement/test case是很重要的一块， 也是必须要看的。 剩下的一些process的东西， 我倒是觉得没必要一开始就弄的很清楚。 慢慢来， 一切都会清晰起来的， 相反， 项目上要想尽快上手， 就必须把测试相关的抓好， 并且要让leader， 你ready了。

　　事情是做出来的， bug是找出来的， 光说不练是没用的。

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自51Testing软件测试网，感谢会员poisson在每周一问（08-09-01）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

 

　软件测试的轮次多少，大多数情况取决于项目大小、开发软件质量和测试效率有关。在项目确定的情况下，谈谈我们团队的做法，希望同行继续补充指正：

　　1、让研发团队的领导重视测试：

　　测试经理作为测试部门的老大，让公司领导重视测试，明白测试给项目带了的价值，那是义不容辞的责任。如何说服公司的领导，让公司的研发总监重视，这一点非常关键。只要这一点做好了，测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队，只看重开发团队，即时测试部门发现了一大堆问题，公司领导也觉的很正常，不在乎，何谈降低测试轮次？如果公司研发领导很重视每轮的测试报告，自然开发部门不敢怠慢，代码的质量肯定要高得多，降低测试的轮次简直就是轻而易举的事情。

　　2、测试团队和开发团队的独立性：

　　国内很多的研发团队都不是很重视测试团队，很多情况下都是开发部门的经理说了算，什么时候测试？什么时候结束？都是如此，这就让测试团队的成员非常郁闷，很无赖，经常是抱怨居多。在这种情况下，多数时候，项目为了赶进度，项目经理和开发经理急了。为了尽快发现问题，只要开发了几个新功能和修复了几个 Bug，也就安排大量测试人员立马验证，这样反反复复，版本平凡发布，测试效果极差，软件质量也得不到保证。如果测试部门和开发部门独立以后，发布版本测试都必须通过沟通来解决。你说开发部门的经理“说测试就测试”的想法，说了还能算吗？呵呵！！我们公司很多时候，在测试版本不符合要求时，要送测试部门进行测试，都是开发部门的经理和项目经理给我们测试部门的老大说好话，拍马屁，老大高兴了，我们方才开始测试，否则一切按流程行事，他们也没有办法。保持部门的独立性和平等性，同样重要。

　　3、细化送测标准，建立完善的测试规范：

　　测试经理在编写测试计划的时候，就应该考虑如下的问题：开发部门开发完成到什么时候我们可以开始接受测试？如果这点测试经理不明白，后面重复测试平凡发布版本，不是什么新鲜事。目前，我们公司的做法是：测试经理编写详细的测试规范，在规范中明确规定了软件版本的送测标准（如：某个独立模块的功能点完成了多少百分比，才能够开始测试等等，都要写成一个标准）。测试规范制定完毕后，开会评审让项目经理、开发经理和测试经理达成一个一致的建议，后面测试的时候就按测试规范中的标准执行就可以了。严格把握软件的送测标准，也能够有效的减少测试的次数。

　　4、测试部门建立详尽的预测试标准：

　　如果被测试软件符合送测标准以后，开发部门才能够请求测试部门进行测试。测试部门接受到开发部门的配置表以后，在服务器上取下测试的版本，编译、部署后，安排部分项目核心人员，对部分主要的功能进行预测试，如果预测试通过了，就可以开始测试。如果预测试不通过，就打回开发部门修改好后再预测试，直到预测试通过为止。同时，我们也要制定严格的软件测试结束标准，来把好质量关，避免一味的追求减少测试轮数，而忽视质量，结果自然可想而知。建立详尽的预测试标准，这样也能够减少测试的轮数。

　　5、保持测试和开发独立的测试环境：

　　大部分的项目硬件都非常昂贵，现在很多的公司为了节省成本，开发和测试环境都在同一台机器上。开发人员就在测试机器上开发，这样混乱的测试环境，导致很多测试出来的Bug有可能不能够重现，开发人员对不成功重现的Bug就要求列为无效的Bug，弄得测试的兄弟们递交Bug都胆战心惊的。测试人员为了重新 Bug不得不另取以前的版本，重新编译后，再测试，这样做无意识又增加了测试的轮次。后来测试环境和开发环境分开了，虽然在同一台机器上，数据库都分开了，测试数据再也不会被开发人员修改了，在测试出现的问题，一般在开发那边都能够出现。后来为了保护测试组里成员的利益，我也去掉了绩效考核中“对无效的 Bug”的考核项，大家终于可以放心的提缺陷了。

　　6、重视单元测试，提高被测软件质量：

　　很多时候，测试部门和开发部门单元测试比较马虎或应付客户了事，测试的时间短，留下了很多缺陷。到了后面每轮系统测试的时候，才被发现，加之项目进度的压力，给公司也带来了较大的经济负担。加大单元测试的力度，力争尽早发现并修复缺陷，同样也是减少测试轮次的一种好方法。

本文出自51Testing软件测试网，感谢会员zhuzx在每周一问（08-08-18）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　7、重视测试用例的评审，提高测试用例的质量：

　　就目前来说，很多的公司都不是很规范。一种情况：变更了软件需求，相应的测试用例，没有及时增加，测试人员测试时，完全凭个人的理解和经验，想到哪里就测到哪里，随便测试。在这种情况下，不同的人在不同的时间测试时，就会发现并提出不同的缺陷，这样混乱的测试就导致测试轮数较多，效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高，测试用例质量较差，导致测试反复进行，也测试不出Bug。这就要求测试部门主管，加大测试用例评审的力度，力争以最少的测试用例，测试出较多的Bug。

　　8、部门员工进行模块交叉测试，避免漏测提高测试效率：

　　测试主管在安排测试的时候，也要注意“用人之长，避人之短”。测试启动阶段，要对这个系统集中培训，让测试部门的成员对整个系统达成一致意见，最好在第一轮测试时，尽可能发现较多缺陷，开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试，另外一方面也可以利用每个人不同的思维方式，很容易发现其它模块的缺陷，避免多次重复测试，提高测试人员的积极性。测试效率提高了，发现的问题多了，后面测试的轮次自然要减少。

　　9、加强项目成员的管理，定期报告发现缺陷的情况，增加督促力度：

　　加强项目成员的管理，同样能够减少版本的发布和测试的轮次。测试人员每天都编写测试日志，邮件抄送给项目部成员和公司领导报告每天测试情况，加强不同层次的领导对开发人员的督促力度。这就对应了第一条，如果公司领导不重视测试，也就无所谓。如果公司领导很重视测试结果，马上作出反应，给各个部门的经理施加压力，软件质量被重视了，自然测试版本减少。如果哪个开发人员开发的模块每天都有很多缺陷，开发人员自然很不光彩，毕竟大家都很要面子，开发人员也敢轻而易举，开发的模块功能不测试就直接扔给测试部。这也是一种有效的方法，当然也可以把缺陷的数量、严重程度作为开发人员的绩效考核标准，提高开发人员的“质量意识”，缺陷自然很少。我们公司就是这样做的，一般在2到3个版本时，就很难发现缺陷，测试人员也相互看看其它成员发现的缺陷，一旦有的测试人员发现了较多的Bug，发现缺陷很少的测试人员很急，比较有个比较吗？特别是测试半天都没发现Bug的测试人员，就经常给我讲自己测试过程中的苦衷，我也很理解他们，多给他们鼓励鼓励。

　　10、严格控制需求变更的流程，减少后期的需求变动：

　　在项目开发中，经常碰到这样的情况，客户代表中有产品部、科技部、业务部等等部门的人员，很难通过某个客户代表户讲清需求。客户代表，随着对开发系统的不断深入了解，有可能客户不断的提出新的需求，或者说是不断修改需求，所以对于需求的变更，我们一定要有一个严格的标准流程。通过开发方和客户的评审后，再编写相应需求文档，最后开始开发。很多时候，繁琐的需求变更流程和领导的多级审批签字，并且需求的变更请求，也有相关的记录，很多客户都怕承担需求变更带来风险。也让业务人员觉得变更比较麻烦，不得不放弃需求的变更。严格控制需求的变更流程，做到有效的需求变更，这也许是一种减少测试版本的方法。

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自51Testing软件测试网，感谢会员zhuzx在每周一问（08-08-18）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

由于国内软件测试行业目前的发展迅速、需求旺盛，在国内的软件测试职位晋升一般要比国外快，但因行业本身太年轻，大家对软件测试中软件测试职业的发展了解不够，从而导致许多有志在此发展的年轻人举步不前。所以下面介绍一下海外公司成熟的软件测试行业职位分布情况，我国一些在软件测试行业中处于前端的公司与之也相仿，这可以作为软件测试职业规划的参考，给新人一个导向。

　　第一阶段：(测试员)初级测试工程师

　　自身条件：初入行具备计算机专业学位或一些手工测试经验的个人。

　　具体工作：执行测试用例，记录bug，并回归测试，通过qtp等测试工具录制回归测试脚本，并执行回归测试脚本。

　　学习方向：开发测试脚本并且开始熟悉测试生存周期和测试技术。

　　第二阶段：(测试工程师)程序分析员

　　自身条件：有1~2年工作经验的测试工程师或程序员。具有初步的自动化测试能力，完善自动化测试脚本。

　　具体工作：设计和编写测试用例，编写自动测试脚本程序且担任测试编程初期的领导工作。

　　学习方向：拓展编程语言、操作系统、网络与数据库方面的技能 。

　　第三阶段：(高级测试工程师)程序分析员

　　自身条件：有3~4年经验的测试工程师或程序员。具有一定的行业业务知识，储备系统分析员的能力。

　　具体工作：帮助开发或维护测试或编程标准与过程，分析软件需求，获得测试需求。确定测试需求相应的测试方法，获得测试策略方案。参与同行的评审（软件需求，软件测试计划等），并为其它初级的测试工程师或程序员充当顾问。

　　学习方向:继续拓展编程语言、操作系统、网络与数据库方面的技能。

　　第四阶段：测试组负责人

　　自身条件：有4~6年经验的测试工程师或程序员。具有丰富的行业业务知识，具有系统分析员的能力，专长性能测试。

　　具体工作：负责管理1~3名测试工程师或程序员。集中于技能方面，担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因，为开发团队提供bug解决策略。

　　学习方向：性能测试，测试技能

　　第五阶段：（资深安全或性能测试工程师）测试/编程高级负责人

　　自身条件：有6~10年经验的测试工程师或程序员。

　　具体工作：负责管理8~10名技术人员。性能测试整体方案设计，软件系统性能问题定位和性能优化，内存优化及分析数据溢出等，分析系统的安全漏洞等。 负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。

　　学习方向：开发一些特定领域的技术专长

　　第六阶段：测试/质量保证/开发（项目）、经理

　　自身条件：有10多年的工作经验。

　　具体工作：管理8名或更多的人员参加的1个或多个项目。负责这一领域（测试/质量保证/开发）内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工

　　第七阶段：（公司级质量总监）计划经理

　　自身条件：有15年以上开发与支持（测试/质量保证）活动方面的经验。

　　具体工作：管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任。

文章来源：http://www.51testing.com/html/200901/n102073.html

　1. 软件测试一项技术性的工作，但同时也涉及到一些人类心理学和经济学的重要因素。

　　2. 错误的测试心理：

　　(1) 软件测试就是证明软件没有错误的过程；

　　(2) 软件测试就是证明软件完成了它既定功能的过程；

　　(3) 软件测试就是建立"软件做了其应该做的"信心的过程；

　　3. 软件测试的过程是为了通过发现并修正更多的缺陷来增加程序的质量和可靠性。因此，在测试伊始，就应该抱着发现更多的缺陷的目的来设计和执行测试，而并不是简单的为了证明程序能够正确运行而进行测试。

　　4.“软件测试是为了发现错误而执行程序的过程。”

　　5. 人类的行为总是具有高度的目标性，目标的确立有着重要的心理学影响。如果我们为了证明程序能够正确运行，就会在潜意识中倾向于实现这个目标，就会设计出较少导致程序失效的测试数据；相反，如果我们为了发现程序中的错误而进行测试，就会想方设法、处心积虑地去设计出“变态”的测试数据，来实现自己的“阴谋”，而这种阴谋的实现却恰恰能够给程序增加更多的价值。

　　6. 心理学研究表明：人们对于预先知道“无法实现”的工作，表现会很糟糕。因此，将软件测试定义为“验证软件中不存在错误的过程”，是无法达到和实现的(程序中不可能不存在缺陷)。

　　7. 软件测试更适宜被定义为试图发现程序中的错误的破坏性过程。一个成功的测试用例，通过诱发程序出错，而对其进行改进和修正。

　　8. 黑盒测试，又称为数据驱动或输入输出驱动的测试。测试过程中，将程序视为一个黑盒，不关心其内部结构和原理，而是将重点放到发现程序不按其规范正确运行的环境条件上。

　　9. 为了进行有效的黑盒测试，需要穷尽出所有的可能情况，并为每一种情况进行测试用例的设计，显然这是无法完成的任务。

　　10. 由于穷举所有测试用例是无法实现的，所以：一、我们不可能保证程序种不存在错误；二、测试投入的目标应该定位在通过有限的测试用例设计与执行，最大程度上提高发现错误的数量，以取得最好的测试效果。

　　11. 白盒测试又称为逻辑驱动测试，允许检查程序的内部结构。这种测试通过对程序逻辑结构进行检查，从中获取测试数据。

　　12. 在白盒测试中的穷举路径测试，如同黑和测试中的穷举输入测试一样，不可能实现。

　　13. 穷举路径测试存在的错误隐患:

　　(1) 程序设计本身不符合设计的规范。在这种情况下，即使穷尽了所有的路径测试，也依旧无法发现这种缺陷。

　　(2) 程序设计可能缺少某些必须的路径，不管你怎么测，也都不可能穷尽到未加入到代码中的路径，除非你是多啦A梦。

　　(3) 穷尽路径测试很可能无法暴露数据敏感的错误。

 

来源：http://www.51testing.com/html/200812/n101060.html

案例描述：

　　简单叙述一下问题吧：

　　公司其它部门有个项目，需要做很严格的测试，请求我们部门支持，部门就指派我负责。因为项目刚开始不久，项目经理说测试的人员目前还未定，暂时只有我一个人，所以我过来了之后就一直在埋头编写测试计划和测试用例，就像以前做过的那样。但今天早上我的主管把我叫去了，跟我说了一番话，对我触动很大。他说其它部门请我们去支持测试，是希望我们给他们带去一些更专业的测试思想和方法，而不仅仅是叫我们去给程序找BUG。我应该更多的考虑如何去做好测试，把整个过程想清楚，需要什么资源，如何安排，要大胆地向项目经理提出，而不是跟着项目的进度走，那样就根本体现不出我们部门的价值。我觉得他说得很有道理，但是说实话，我对一个项目的测试经理究竟需要考虑些什么，注意些什么，该做些什么，并不是十分清楚。所以在此提出来讨论，希望大家给我些建议，谢谢！

　　意见：

　　这么久都没有人给个好的思路讲一讲这个关于如何做项目的测试经理，也许这个问题问的太大了吧，今天有感而发，说说我的观点吧。

　　对于项目的测试经理，每个公司组织结构、项目管理模式不一样，想做好项目的测试经理，首先是要和开发负责人、项目负责人达成共识，是对于项目的软件质量理解的共识，对于速度、成本、质量这三个方面，更偏向于那一面、还是都持平。

　　当然，站在测试的角度，希望软件质量是很高的，那么站在项目的测试，做为测试，要明白能做什么？起到的作用是什么？

　　程序一旦提交到测试，进度完全是可以在测试这一方来主控了。

　　本帖的案例，我看了一下描述，目前苦恼的问题是：

　　1、领导说其它部门请我们去支持测试，是希望我们给他们带去一些更专业的测试思想和方法，而不仅仅是叫我们去给程序找BUG。

　　2、我应该更多的考虑如何去做好测试，把整个过程想清楚，需要什么资源，如何安排，要大胆地向项目经理提出，而不是跟着项目的进度走，那样就根本体现不出我们部门的价值。

　　从上面的描述可以了解到，部门领导会这么说可能是因为：

　　1、在项目测试的过程中进度没有过程控制点，具体一点就是没有具体的工作计划（什么时间，用多少人力做什么样的测试？）

　　2、程序提交测试后，什么时候能发布、可不可以发布没有个确定点；测试没有自己的主见，项目经理说测试进度怎么做就怎么走

　　要想做好项目的测试，我想需要具备下面的一些素质吧，仅供参考：

　　1、深刻了解测试的整个工作流程、也就是在项目的测试工作中需要做的测试需求、测试计划、测试用例、测试报告、bug分析

　　2、及时的收集测试过程中的问题、了解测试进度，把问题和进度反馈给项目的各方负责人

　　3、很好的沟通、协调能力，应变测试过程中发生的需求变更、bug修改进度缓慢、开发延期提交等等一系列问题

　　4、很好的承受工作压力和适应能力，做为一个测试负责人，如果不能抗得住、下面的测试执行者就会慌乱

　　5、具有发现问题寻求好的解决问题的途径

　　6、关心组员的工作表现、会换位思考等等

 

来源：http://www.51testing.com/html/200812/n100507.html

在注册表中改   :在[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\下找到你想改路径的服务,有一键名是"ImagePath",在这里修改.

手机软件测试类型及分析(原创)

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

2）UI　[用户界面验证]：　验证手机的界面、菜单等是否是与客户需求和设计保持一致，主要依据　UI spec[用户界面说明],MMI[人机交互界面]，Menu tree[菜单树]等，这些文档也是需要根据客户需求及时更新的 

3）Limit Value [极限值测试]　对应黑盒测试的边界值分析法，边界值分析法设计出的测试用例发现 bug 的能力也是最强的，一般依据极限值表设计测试用例，来指导测试。一般测试点如输入字符的个数，会议通话的个数，文档存储个数等 

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

5）Capability 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　[用户手册验证]　其重要性是不言而喻的，用户手册一定要和手机实际功能相符合，不然将会影响用户对产品的信任 

12）FAT( Full Type Approval)[全类型批准]：是GSM手机进入GSM网络必须通过的专业测试。 

 

来源：http://www.51testing.com/?80108/action_viewspace_itemid_7210.html

 

　　1 手机软件的运行环境 1.1 概述手机可以被看作袖珍的计算机。它有CPU、存储器(flash、RAM）、输入输出设备（键盘、显示屏、USB和串口）。它还有一个更重要的I/O设备， 那就是空中接口。手机通过空中接口协议（例如GSM、CDMA、PHS等）和基站通信，既可以传输语音、也可以传输数据。

　　手机的CPU一般不是独立的芯片，而是基带处理芯片的一个单元，也称作CPU核。基带处理芯片是手机的核心，它不仅包含CPU核、DSP核这些比较通用的单元，还包含通信协议处理单元。通信协议处理单元和手机协议软件一起完成空中接口要求的通信功能。

　　随着芯片技术的不断发展，越来越多的外围电路可以被集成到基带处理芯片中，例如BAP，即基带模拟处理器。这样手机才可能越做越小、越做越便宜。

　　1.2 单CPU和双CPU很多手机只有一个CPU，也就是基带处理芯片中的CPU核。在这个CPU上既要跑通信协议，又要实现用户界面（称作UI或MMI）。当然DSP会分担一些计算量繁重的工作，例如语音编解码、安全层的各种算法等。

　　在市场推动下，手机功能在不断发展。摄像头、MP3、蓝牙这些功能可以依靠硬件，对CPU的压力还不是很大，但java虚拟机、嵌入式浏览器等应用软件就会对CPU资源有较高的要求。

　　单CPU的首要任务是完成通信协议。通信协议软件有着很精确的定时要求，如果这个CPU还要兼顾很多应用软件的话，就难免吃力。于是双CPU手机应运而生。

　　顾名思义，双CPU手机就是有两个CPU的手机，一个CPU专心把通信协议做好，另一个CPU负责UI、java虚拟机、嵌入式浏览器等应用功能。两个CPU可以做在一个芯片里面，也可以分开。

　　市场上的实际情况是，很多手机设计公司（Design House）没有基带处理芯片的开发能力，他们购买国外公司的手机模块，自己在外面再加一块CPU。模块跑通信协议，自己加的CPU跑UI和应用软件，两 者通过串行口通信。很多Design House也会购买国外方案商的开发板级方案，自己做PCB、软件上改改UI和外设驱动。

　　市场上的智能手机基本上全是双CPU方案，什么Windows CE、SmartPhone、WindowsMobile、Symbian、嵌入式Linux全是运行在第二块CPU上的。这些商业操作系统无法和无线通 信协议软件集成到一块CPU上。双CPU的手机功能比较多，但它们一般体积大，耗电多，成本高。现在市场上的大部分手机还是单CPU的。

　　目前的大部分手机应用，例如Java、BREW、WAP、邮件、摄像头、闪存、MP3、蓝牙，在单CPU方案里都能实现。我认为不管3G、4G如何发展， 小巧、实用、低成本的单CPU方案总会占据较大的市场份额。微软在单CPU方案的手机市场还没有立足之地，又怎么谈的上什么引领方向呢？

　　本文主要介绍单CPU手机，大多数论述也适用于双CPU方案的通信CPU。

　　1.3 3G和4G3G和4G是指第三代、第四代无线通信技术，对手机而言，它们改进的是空中接口的效率，空中接口能以更大的带宽传送数据。通过手机无线上网的速度会更快。这和话音业务、手机应用软件没有直接的联系。

　　当然，手机的嵌入式数据业务由于更高的带宽，会产生更多的可能性。不过这些可能性的实现还是会受到手机输入慢、显示屏小等条件的制约。 2 手机软件的组成 2.1 概述手机软件和PC机软件一样从中断向量表开始，因为比较小，看上去更加清晰。中断向量表的第一个跳转指令当然是跳到复位的处理程序，后面是中断处理、错误处理的跳转指令。一上电，手机就跳转到复位的处理程序，开始检查内存、初始化C运行环境，然后创建第一个任务。这个任务会按顺序创建、启动其它任务。绝大多数手机程序都是多任务的，但也有一些小灵通的协议栈是单任务的，没有操作系统，它们的主程序轮流调用各个软件模块的处理程序，模拟多任务环境。

　　手机软件可以粗略地分成启动模块、操作系统、协议栈、数据业务、本地存储、驱动程序、用户界面和其它应用。启动模块前面已经说过了，下面简单介绍其它部分。

　　2.2 操作系统操作系统在手机软件只占很小一部分。它的主要功能就是提供多任务调度、通信机制。有的操作系统会提供动态内存分配，定时函数，但这些都不是必须的。例如需要动态内存分配的模块，可以自己管理一个内存池，这样更易于隔离模块和预测内存需求。

　　大多数手机的操作系统都是一个很小的内核，例如REX、HIOS等。高通REX的源代码连C代码加汇编也不过一千多行，编译后不过是2、3K的代码量。而一般手机软件有几百到上千个源文件、超过一百万行的代码。

　　2.3 协议栈协议栈是手机软件最复杂的部分，它的复杂性在于它和基带处理芯片的设计密切相关。只有具备芯片设计能力的企业才可能开发协议栈。协议栈会使用基带处理芯片的所有资源。

　　2.4 数据业务数据业务主要有两种：在前一种，手机相当于一个调制解调器，PC机通过手机上网，网络协议全在PC机上，手机提供数据链路。另一种就是嵌入式数据业务，手机内部包含TCP/IP/PPP等协议，有时还要实现HTTP和嵌入式浏览器。

　　2.5 本地存储手机都有本地存储功能，存储电话本、短消息、用户设定等。一般手机都有一个基于flash的文件系统。早期的手机存储是基于EEPROM的。

　　2.6 驱动程序硬件驱动一般指外设驱动，不过有的外设已经被集成到基带处理芯片中了。驱动程序包括键盘、电源管理模块、LCD、flash、RTC、串口、USB、SIM卡或UIM卡、射频驱动等。

　　2.7 用户界面用户界面（UI）又称作人机界面（MMI），它负责和用户的交互，在必要的时候调用其它模块的功能。除了手机的必备功能外，用户界面也可能包含一些相对独立的应用程序，例如日程表、游戏等。

　　2.8 其它应用其它应用包括Java虚拟机、WAP浏览器、邮件软件等，是一些比较大，又相对独立的应用模块。

　　基本上讲完了。大家肯定看得挺没意思吧。这些程序和微软的longhorn、metedata有什么关系呢？手机程序绝大部分是用C语言写的。但对于做应用软件的程序员要求具备面向对象、设计模式的思维能力，然后用C语言实现出来。

　　高通的BREW就是用C语言硬生生地模仿C++，弄出很多奇怪的宏。一般应用软件的开发不用这么死板，但对各种软件设计方法的了解还是必要的。

　　3 手机的核心技术手机的核心技术是芯片和协议栈，两者是密不可分的。芯片设计需要协议栈来验证，协议栈必须充分发挥出芯片的功能。芯片的CPU核、DSP核都可以买到现成的单元，但通信协议部分就需要自己设计了。手机比较难做好的是耗电量、恶劣信号环境的性能等。 4 第三方软件 4.1 原理 “第三方软件”这个词的含义比较宽泛。本文用它来指代不是硬编码在手机里，而是可以通过数据线或网络下载到手机上，可以装载、运行，也可以删除的软件。

　　前面讲到的软件都是完整程序的各个部分。这些部分会被放到一起编译，产生一个二进制文件，通过JTAG口（升级时可以用串口）下载到手机的flash中。手机一上电，就会从指定地址开始运行。这个地址的内容就是跳转到复位处理程序的跳转指令。哈哈，又讲回头了。

　　第三方软件是指手机可以通过数据线或者网络下载一些可执行文件到文件系统中。然后有一个装载器可以执行这些文件。这样第三方就可以开发一些应用程序，下载到手机中来扩充手机功能。

　　这些可执行文件现在主要有两种格式：java程序和BREW程序。java程序需要java虚拟机装载运行。BREW程序是一个很奇怪的东西，它实际就是用与编译手机程序相同的编译器编译出来的目标代码。这些目标代码必须是可以重新定位的，即不能包含全局和静态变量。

　　装载器将程序将执行权传给给BREW程序，一种听上去更安全的说法是调用BREW程序的入口函数。这个入口函数的位置在文件中是固定的。装载器在调用 BREW程序的入口函数时会传入一个地址。通过这个地址，BREW程序能够顺藤摸瓜，找到系统提供的各种API的地址，它通过这些API访问手机的显示、通信等功能。

　　java程序基本上是平台无关的，针对各种平台设计的java虚拟机隔离了平台的大部分特性，除了厂家特意提供的一些OEM功能。BREW程序显然是平台相关，换一个CPU，就不认识原来的目标码了。

　　4.2 其它

　　除了java、BREW外，Windows CE、SmartPhone、WindowsMobile、Symbian、嵌入式Linux这些商业操作系统当然可以提供各种创建第三方程序的方法。在这些环境写程序和在PC平台写程序很相近，基本上体会不到嵌入式编程的特点，只是屏幕小一些，输入麻烦一些。

　　这些第三方软件不是必需的。手机在3G的市场中只占了一个较小的部分，网络是大头。而第三方软件相对于手机来说，所占的份额就更小了。

　　《程序员》有一个嵌入式移动开发的专栏，总在讲这些手机第三方软件的开发手机软件只是嵌入式软件的一部分。第三方软件在嵌入式移动开发中又能占到多少比重呢?

　　5 结束语需要说明：关于以后的市场究竟以单CPU手机为主，还是以双CPU手机为主的问题，我倾向于单CPU手机，但这只是我个人观点。实际市场会怎么发展，殊难预料。

　　对于一个芯片两个CPU核的方案，从软件角度看我是很赞成的。将应用软件和协议软件分开，协议软件可以更加稳定，应用软件可以自由发展，使用大量在PC环境已经成熟的技术。

OBEX应用——文件传输部分

在手机数据传输方面基本OBEX应用分为

l 文件传输

l IrMC同步

文件传输又可以细分为以下基本操作

l 初始化连接

l 断开连接

l 设置路径

l 取得目录信息

l 创建目录

l 上传下载文件

l 删除文件或空目录

在笔者的软件当中设计了OBEX这个类，里面包含了以上所有的基本操作。另外针对M55的服务端的特殊性又设计了更名、取得磁盘空间信息、移动、拷贝文件的功能。具体请参考源代码。

下面具体讲述各个操作的细节。

l 初始化连接

初始化连接包括了使手机进入OBEX状态再到发送Connect指令的一系列过程。具体流程参考下图。

ATÆAT^SQWE=0ÆAT^SQWE=3ÆConnectÆ连接到Folder-Listing Service

其中AT^SQWE=0和AT^SQWE=3是西门子特有的隐藏的AT指令，甚至在官方的AT指令集里面都没有提到。其作用是初始化手机到OBEX模式。

发送Connect指令收到手机回复以后确定Max Packet Length等参数。最后连接到Folder-Listing Service进行文件操作。如果需要IrMC同步的话，在Connect后直接连接到IrMC Sync Service即可，手机立刻进入同步模式，所有的应用程序退出。

在笔者的程序中当中首先使用AT指令确定手机当前的工作，如果超时，尝试发送+++并等待1秒钟以便手机从不正常的OBEX状态中退出。然后在此发送AT，成功后即进行文件操作，否则引发一个错误。

l 断开连接

这里的断开连接是指从OBEX模式退出到AT状态中。在AT指令中，连续发送三个0x2B然后等待一秒钟以上即可退出数据模式进入常规AT模式。

l 设置路径

程序中使用SetPath操作设置路径。需要注意的是，可以设计两种风格的过程：一种使用绝对路径，另一种使用相对路径。

对于手机而言，经笔者实践证明，使用绝对路径要比使用相对路径方便，而且更准确，但效率上稍逊，特别是在多层目录的情况下。由于手机没有能够返回当前路径的方法，所以相对路径总难以控制，只有通过程序控制，极容易出现错误。所以建议使用绝对路径。

如果使用绝对路径，那么路径名将呈现\path1\path2这种形式。首先回到根目录，然后一级一级的到达目的。在笔者的OBEX类当中，可以看到BacktoRoot这个过程。其作用就是把当前程序路径切换到根目录以免引起混乱。

l 取得目录信息

要取得一个目录的文件信息可以用发送Get指令。该Get指令需要一个TypeHeader，其值为x-obex/folder-listing

随后服务端会返回一个xml文件，包含了整个目录的信息。例如子目录名、文件名、大小、最后修改时间。再通过xml解析后就会得到目录信息。

l 创建目录

当SetPath的Flags的Bit1设为1并且无法找到目录时，服务端会创建这个目录并进入。

请注意，再次使用SetPath并将Flags的Bit0设为1返回上层目录，否则容易引起混乱。

l 上传下载文件

使用Put和Get命令可以实现上传和下载文件。注意所有的文件操作都在SetPath所指定的目录下进行。

使用Put命令实现上传时，至少需要提供NameHeader，BodyHeader，一般还要提供LengthHeader，DateTimeHeader。大文件传输需要正确处理BodyHeader，不能超出了服务端最大所能接收的Packet的大小，否则会出现错误。

需要注意的是如果当前文件存在，那么Put命令不会覆盖已有的文件而是追加，导致错误。传输文件之前需要首先删除同名文件。

使用Get命令实现下载时，只需要提供NameHeader即可。具体例子参考上一节。

l 删除文件或空目录

使用Put命令，其NameHeader指定为文件名或目录名并将BodyHeader设置为空即可。

非空目录无法删除，会返回错误。



西门子手机还有移动、拷贝等功能，具体实现方法请参阅OBEX源代码。

 

文章来源于软件测试时代 http://www.testage.net/

 (一) OBEX介绍

一、什么是OBEX，它有什么用途？

OBEX全称为Object Exchange，中文对象交换，所以称之为对象交换协议。它在此软件当中有着核心地位，文件传输和IrMC同步都会使用到它。

OBEX协议构建在IrDA架构的上层.

OBEX协议通过简单的使用“PUT”和“GET”命令实现在不同的设备、不同的平台之间方便、高效的交换信息。支持的设备广泛，例如PC，PDA，电话，摄像头，自动答录机，计算器，数据采集器，手表等等。

OBEX协议定义了一种柔性的概念——objects。也即是对象。这些对象可以包括文件，诊断信息，电子商务卡片，银行的存款等等。Objects在这里没有高级的技术含义，而是视你的应用而定。

OBEX协议小到可作“命令和控制”功能，例如对电视机，录像机等的操作。大道可以做很复杂的操作，例如数据库的事务处理和同步。

OBEX能够具有以下几个特点：

1、 友好的应用——可实现快速开发。

2、 紧缩——可用在资源有限的小型设备上。

3、 跨平台

4、 柔性的数据支持。

5、 方便的作为其他Internet传输协议的上层协议。

6、 可扩展性——提供了对未来需求的扩充支持而不影响以存在的实现。例如可扩展安全，数据压缩等。

7、 可测试可调试。

更为具体的关于OBEX的介绍请查阅IrOBEX协议。

二、OBEX对象模型

关于Headers

对象模型回答了对象是如何在OBEX协议描述的。这个模型必须包括被传输的对象和对对象的描述。为了做到这点，OBEX定义了Headers的概念。

一个Header反映了对象的一个方面，例如名字、长度、描述文字或者对象本身。例如，一个文件对象demo.txt会包含它的名字，一个类型标示为“text”，长度和文件本身。

Headers的构成

Headers简单的由<Header ID>和<Header Value>组成，简称为<HI>和<HV>。

HI由一个字节组成，指出了Header包含的内容以及它的格式。HV包含了一个或者多个字节，其结构由HI所决定。

所有的Header都是可选的，取决于设备的类型和事务的种类。你可以使用所有的Header，或者一些，或者没有。ID可以使Header可解析以及与传输顺序无关，也可以使不支持的Header被忽略掉。

手机软件MMI的自动化测试需要手机终端和计算机进行通讯，所以通讯方式可以选择串口或者蓝牙，鉴于稳定性和易用性，设计简单程度，串口通讯是非常简单的很容易实现的。

    然后自动化测试工具选择脚本语言的问题，我们可以选择VBscrīpt，Perl，Python，比较一下，Python比较强大，Nokia的一些工具就是python做脚本的。 

    两者之间的通信机制：可以使用ATcommand进行通信，出了GSM标准支持的ATC，还要有手机专门自己的命令来支持远程终端操控手机。比如键盘控制，长按短按等。 

    手机需要暴露一些接口，比如截图，文字识别，返回图像，文字等。这样可以做自动化验证，做到无人值守。这些均需要手机来支持。比如设计手机要有这样的接口 BOOL GetPicture(int top, int bottom, int right, int left, BITMAP & bitmap); 这样通过ATC发过来命令然后手机解析一下，得到top，bottom等信息，然后得到bitmap返回。文字识别需要python来完成，char* GetStringFromPic(Point pt, const Bitmap* bitmap); 我就用C++来表示了。这样在脚本里面就可以进行比较文字了。 

    更进一步，支持录制脚本功能，比如按下某个键，串口信息，监听串口信息，这样脚本解析按下的键，然后判断在转译成脚本语言。Key（）； 

    关于手机只需要支持识别ATC参数，然后传回要的结果，我想主要是通过图片来返回，因为这是模拟人工测试的原理，我按下某个键，就会出现什么结果，这样需要返回图片即可，然后脚本客户端需要对图片进行处理，要么进行比较图片内容，要么进行文字识别进行文字对比，这样可以实现测试自动化。 

    前文已经把大致的手机需要提供的接口说了一下，再次总结一下：

1.需要手机支持GSM07.07中规定（Optional）的键盘控制的命令at+ckpd
2.需要手机支持一些特殊的ATC，比如传回手机当前图片，以便作比较。
3.自动化测试的目的：能够替代人工实现大量手工难以完成的工作，重复性较强的工作，比如一些压力测试，存五百条通讯录等，删除等，考验手机内存释放时是否有内存泄露等等。二是能够完成大量的回归测试，易于维护等特点。

思路：

选择脚本语言：由于python使用很灵活而且具有强大的文本处理能力，且易于学习等特点，可以选用python作为脚本语言和实现语言。

方式：

比如定义def CCKEY（）来完成发送CCKEY，也可以通过一个map文件来实现CCKEY--at+ckpd=\"c\"这种方式，然后用户这边只是用譬如以下的命令：

CenterKey()
Key(\"#\", 2)
LongPress(\"#\")
PressKey(\"0\")
LSK()
RSK()
NaviUp()
NaviDown()

　　再加上python的控制流程，异常处理等，可以编出强大的易于维护的脚本来。

　　手机方面的接口可以是GetImage（），然后通过脚本进行处理，这个可能需要很大的工作量，因为要么重新研究图像识别对比，文字识别等技术，要么购买组件等，即验证这一关也很难实现。

　　在初期可以考虑人工来验证一些结果，比如图片对比结果，可以使用一些技术，比如蒙板等，得到一些异状图片，用户自己审阅一下，加入明显的由异样，就Fail，这样就不能自动，可以说是半自动化了。

什么样的用例是好的用例?

　　一.质量属性

　　Quality Attributes

　　1.正确性：确保测试标题描述部分的内容正确性。

　　2.经济性：只为确定需要的目的设计相应的测试步骤

　　3.适应性：既能适应短期需要，又能考虑长远需要。

　　4.可追踪性：用例能追踪到一个具体的需求。

　　5.自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。

　　二.结构化和可测试性

　　Structure and testability

　　1.含有规范的测试标题和编号。

　　2.含有一个确定的测试某一个特定需求的目的。

　　3.含有关于测试方法的描述。

　　4.指定条件信息-环境、数据、预置的条件测试、安全入口等。

　　5.含有操作步骤和预期结果。

　　6.陈述任何辅助证据，例如截图报告并确保这些东西妥善保存。

　　7.确保测试环境的干净（即用例不会影响整个环境）。

　　8.描述时使用主动语气结构。

　　9.操作步骤不要超过15步

　　10.确保单个用例测试执行时用时不超过20分钟。

　　11.自动化脚本用例添加必要的注释，比如目的、输入和期望结果。

　　12.如果可能，建议提供可选择性的预置条件测试。

　　13.用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。

　　三.配置管理

　　Configuration management

　　1.采用命名和编号规范归档。

　　2.保存为特定的格式，文件类型。

　　3.用例版本是否与当前被测试软件版本一致（对应）。

　　4.包含用例需要的相应测试对象，如特定数据库。

　　5.存档阅读。

　　6.存档时按角色控制访问方式

 

原帖链接：http://www.51testing.com/html/200812/n98758.html

http://www.51testing.com/?action_viewnews_itemid_16618.html
http://www.51testing.com/?action_viewnews_itemid_16622.html
http://www.51testing.com/?action_viewnews_itemid_16625.html
http://www.51testing.com/?action_viewnews_itemid_16629.html