软件测试是为了发现错误而执行程序的过程。 QQ: 12585990 MSN:sunxy5291@hotmail.com

发布新日志

  • 软件测试技术研究

    2007-05-17 10:52:49Top 3 Digest 3

    【摘要】
    软件测试是软件工程的一个重要部分。论文首先阐述了软件测试的目的、分类和工作流程,测试按照步骤分为单元测试、集成测试、确认测试和系统测试。接着详细地分析了这四种测试的方法。最后介绍了软件测试自动化的一些具体做法。
    【关键词】
    软件测试黑盒测试 白盒测试 单元测试 集成测试 确认测试 系统测试

        The Study of Software Testing Technology

    Abstract
      Software testing is an important part of software engineering. At first this article studies the purpose, classification and procedures of software testing. Then it analyzes the methods of module testing, integration testing ,validation testing and system testing respectively. At last some instances of the application of automation in software testing are presented.


    Keywords
      Software testing , black-box testing , white-box testing , module testing
      integration testing, validation testing ,system testing
     
    一、
    软件测试
    1、软件测试的目的
    软件测试是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,它是软件质量保证的关键步骤。测试要求以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷,以确保系统的质量。
     
    软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误,那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价,那么测试就应该直接针对在实际应用中会经常用到的商业假设。这里引用Grenford J. Myers在《The Art of Software Testing》一书中的观点:
      ①、
    软件测试是为了发现错误而执行程序的过程;
      ②、测试是为了证明程序有错,而不是证明程序无错误。
      ③、一个好的
    测试用例是在于它能发现至今未发现的错误;
      ④、一个成功的测试是发现了至今未发现的错误的测试。
    软件测试是一项细致并需要高度技巧的工作,稍有不慎就会顾此失彼,发生不应有的疏漏。软件工程的总目标是充分利用有限的人力和物力资源,高效率、高质量地完成测试。为了降低测试成本,选择测试用例时应注意遵守"经济性"的原则。

    2、
    软件测试的分类
    从测试的类型来看,测试分为2种:黑盒测试和白盒测试。
    黑盒测试又称为
    功能测试或数据驱动测试,把系统看成一个黑盒子,不考虑程序的内在逻辑,只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。
    白盒测试又称为结构测试和逻辑驱动测试,允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑路径进行测试。
      从测试实际的前后过程来看,
    软件测试上是由一系列的不同测试所组成,这些软件测试的步骤分为:单元测试、组装测试(集成测试)、确认测试和系统测试。
    单元测试针对每个模块进行的测试,通常在编码阶段进行,必要的时候要制作驱动模块和桩模块。集成测试在单元测试的基础上,将所有模块按照设计要求组装成为系统,必须精心计划,应提交集成测试计划、集成测试规格说明和集成测试分析报告。确认测试验证软件的功能和性能及其它特性是否与用户的要求一致,系统测试是在实际运行环境下进行一系列的测试。软件开发的过程是自顶向下的,测试则正好相反,以上这些过程就是自底向上,逐步集成的

    3、
    软件测试工作的流程:

    测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征,可以帮助项目管理者发现当前所采用的软件过程的缺陷,以便改进。同时,这种分析也能帮助我们设计出有针对性地检测方法,改善测试的有效性。

    没有发现错误的测试也是有价值的,完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。由此可见,
    软件测试工作应该贯穿于整个软件开发阶段。

    下面是
    软件测试工作的总体流程图和每个主要阶段的流程图:


    二、单元测试

    1、 什么是单元测试
    单元测试是在软件开发过程中要进行的最低级别的测试活动,测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述,单元测试应对模块内所有重要的控制路径设计测试用例,以便发现模块内部的错误。在单元测试活动中,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试多采用白盒
    测试技术,系统内多个模块可以并行地进行测试。
      在一种传统的结构化编程语言中,比如C,要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中,要进行测试的基本单元是类。对Ada语言来说,开发人员可以选择是在独立的过程和函数,还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言(4GL)的开发中,在这里基本单元被典型地划分为一个菜单或显示界面。
      单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用,单元测试必须是可重复的,无论是在软件修改,或是移植到新的运行环境的过程中。因此,所有的测试都必须在整个软件系统的生命周期中进行维护。
      经常与单元测试联系起来的另外一些开发活动包括代码走读(Code review),
    静态分析(Static analysis)和动态分析(Dynamic analysis)。静态分析就是对软件的源代码进行研读,查找错误或收集一些度量数据,并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作,来提供执行跟踪,时间分析,以及测试覆盖度方面的信息。

    2、单元测试任务 
     单元测试任务包括:1 模块接口测试;2 模块局部数据结构测试;3 模块边界条件测试;4 模块中所有独立执行通路测试;5 模块的各条错误处理通路测试。
      模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下,其他测试才有意义。测试接口正确与否应该考虑下列因素:
      1 输入的实际参数与形式参数的个数是否相同;
      2 输入的实际参数与形式参数的属性是否匹配;
      3 输入的实际参数与形式参数的量纲是否一致;
      4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同;
      5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配;
      6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致;
      7 调用预定义函数时所用参数的个数、属性和次序是否正确;
      8 是否存在与当前入口点无关的参数引用;
      9 是否修改了只读型参数;
      10 对全程变量的定义各模块是否一致;
      11是否把某些约束作为参数传递。
    如果模块内包括外部输入输出,还应该考虑下列因素:
      1 文件属性是否正确;
      2 OPEN/CLOSE语句是否正确;
      3 格式说明与输入输出语句是否匹配;
      4缓冲区大小与记录长度是否匹配;
      5文件使用前是否已经打开;
      6是否处理了文件尾;
      7是否处理了输入/输出错误;
      8输出信息中是否有文字性错误;

    检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源,应仔细设计测试用例,力求发现下面几类错误:
      1 不合适或不相容的类型说明;
      2变量无初值;
      3变量初始化或省缺值有错;
      4不正确的变量名(拼错或不正确地截断);
      5出现上溢、下溢和地址异常。
      除了局部数据结构外,如果可能,单元测试时还应该查清全局数据(例如FORTRAN的公用区)对模块的影响。
      在模块中应对每一条独立执行路径进行测试,单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的
    测试技术。计算中常见的错误包括:
      1 误解或用错了算符优先级;
      2混合类型运算;
      3变量初值错;
      4精度不够;
      5表达式符号错。
      比较判断与控制流常常紧密相关,测试用例还应致力于发现下列错误:
      1不同数据类型的对象之间进行比较;
      2错误地使用逻辑运算符或优先级;
      3因计算机表示的局限性,期望理论上相等而实际上不相等的两个量相等;
      4比较运算或变量出错;
      5循环终止条件或不可能出现;
      6迭代发散时不能退出;
      7错误地修改了循环变量。
      一个好的设计应能预见各种出错条件,并预设各种出错处理通路,出错处理通路同样需要认真测试,测试应着重检查下列问题:
      1输出的出错信息难以理解;
      2记录的错误与实际遇到的错误不相符;
      3在程序自定义的出错处理段运行之前,系统已介入;
      4异常处理不当;
      5错误陈述中未能提供足够的定位出错信息。
    边界条件测试是单元测试中最后,也是最重要的一项任务。众的周知,软件经常在边界上失效,采用边界值分析技术,针对边界值及其左、右设计测试用例,很有可能发现新的错误。

    3、单元测试的过程与环境
      一般认为单元测试应紧接在编码之后,当源程序编制完成并通过复审和编译检查,便可开始单元测试。测试用例的设计应与复审工作相结合,根据设计信息选取测试数据,将增大发现上述各类错误的可能性。在确定测试用例的同时,应给出期望结果。
      应为测试模块开发一个驱动模块(driver)和(或)若干个桩模块(stub),下图显示了一般单元测试的环境。驱动模块在大多数场合称为"主程序",它接收测试数据并将这些数据传递到被测试模块,被测试模块被调用后,"主程序"打印"进入-退出"消息。
      驱动模块和桩模块是测试使用的软件,而不是软件产品的组成部分,但它需要一定的开发费用。若驱动和桩模块比较简单,实际开销相对低些。遗憾的是,仅用简单的驱动模块和桩模块不能完成某些模块的测试任务,这些模块的单元测试只能采用下面讨论的综合测试方法。
      提高模块的内聚度可简化单元测试,如果每个模块只能完成一个,所需测试用例数目将显著减少,模块中的错误也更容易发现。




    三、集成测试的基本方法

      时常有这样的情况发生,每个模块都能单独工作,但这些模块集成在一起之后却不能正常工作。主要原因是,模块相互调用时接口会引入许多新问题。例如,数据经过接口可能丢失;一个模块对另一模块可能造成不应有的影响;几个子功能组合起来不能实现主功能;误差不断积累达到不可接受的程度;全局数据结构出现错误,等等。综合测试是组装软件的系统
    测试技术,按设计要求把通过单元测试的各个模块组装在一起之后,进行综合测试以便发现与接口有关的各种错误。 
     某设计人员习惯于把所有模块按设计要求一次全部组装起来,然后进行整体测试,这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误,为每个错误定位和纠正非常困难,并且在改正一个错误的同时又可能引入新的错误,新旧错误混杂,更难断定出错的原因和位置。与之相反的是增量式集成方法,程序一段一段地扩展,测试的范围一步一步地增大,错误易于定位和纠正,界面的测试亦可做到完全彻底。
    下面讨论两种增量式集成方法。
    1、自顶向下集成  
    自顶向下集成是构造程序结构的一种增量式方式,它从主控模块开始,按照软件的控制层次结构,以深度优先或广度优先的策略,逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起,至于选择哪一条路径作为主控制路径,这多少带有随意性,一般根据问题的特性确定。以下图为例,若选择了最左一条路径,首先将模块M1,M2,M5和M8集成在一起,再将M6集成起来,然后考虑中间和右边的路径。广度优先策略则不然,它沿控制层次结构水平地向下移动。仍以下图为例,它首先把M2、M3和M4与主控模块集成在一起,再将M5和M6 和其他模块集资集成起来。  
    自顶向下综合测试的具体步骤为:  
    1 以主控模块作为测试驱动模块,把对主控模块进行单元测试时引入的所有桩模块用实际模块替代;  2 依据所选的集成策略(深度优先或广度优先),每次只替代一个桩模块;  3 每集成一个模块立即测试一遍;  4 只有每组测试完成后,才着手替换下一个桩模块;  5 为避免引入新错误,须不断地进行回归测试(即全部或部分地重复已做过的测试)。   从第二步开始,循环执行上述步骤,直至整个程序结构构造完毕。下图中,实线表示已部分完成的结构,若采用深度优先策略,下一步将用模块M7替换桩模块S7,当然M7本身可能又带有桩模块,随后将被对应的实际模块一一替代。 
     自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验,因此较早地发现错误。缺点是在测试较高层模块时,低层处理采用桩模块替代,不能反映真实情况,重要数据不能及时回送到上层模块,因此测试并不充分。解决这个问题有几种办法,第一种是把某些测试推迟到用真实模块替代桩模块之后进行,第二种是开发能模拟真实模块的桩模块;第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法,使错误难于定位和纠正,并且失去了在组装模块时进行一些特定测试的可能性;第二种方法无疑要大大增加开销;第三种方法比较切实可行,下面专门讨论。

    2、自底向上集成  
    自底向上测试是从"原子"模块(即软件结构最低层的模块)开始组装测试,因测试到较高层模块时,所需的下层模块功能均已具备,所以不再需要桩模块。  
    自底向上综合测试的步骤分为:  
    1 把低层模块组织成实现某个子功能的模块群(cluster);  2 开发一个测试驱动模块,控制测试数据的输入和测试结果的输出;  3 对每个模块群进行测试;  4 删除测试使用的驱动模块,用较高层模块把模块群组织成为完成更大功能的新模块群。  从第一步开始循环执行上述各步骤,直至整个程序构造完毕。  下图说明了上述过程。首先"原子"模块被分为三个模块群,每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma,因此在驱动模块D1、D2去掉后,模块群1与模块群2直接与Ma接口,这时可对MaD3被去掉后,M3与模块群3直接接口,可对Mb进行集成测试,最后Ma、Mb和 Mc全部集成在一起进行测试。
       
    自底向上集成方法不用桩模块,测试用例的设计亦相对简单,但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此,在测试软件系统时,应根据软件的特点和工程的进度,选用适当的测试策略,有时混和使用两种策略更为有效,上层模块用自顶向下的方法,下层模块用自底向上的方法。
      此外,在综合测试中尤其要注意关键模块,所谓关键模块一般都具有下述一或多个特征:①对应几条需求;②具有高层控制功能;③复杂、易出错;④有特殊的性能要求。关键模块应尽早测试,并反复进行回归测试。

    四、确认测试的基本方法


    通过集成测试之后,软件已完全组装起来,接口方面的错误也已排除,确认测试即可开始。确认测试应检查软件能否按合同要求进行工作,即是否满足软件需求说明书中的确认标准。

    1. 确认测试标准  实现软件确认要通过一系列墨盒测试。确认测试同样需要制订测试计划和过程,测试计划应规定测试的种类和测试进度,测试过程则定义一些特殊的测试用例,旨在说明软件与需求是否一致。无是计划还是过程,都应该着重考虑软件是否满足合同规定的所有功能和性能,文档资料是否完整、准确人机界面和其他方面(例如,可移植性、兼容性、错误恢复能力和可维护性等)是否令用户满意。  确认测试的结果有两种可能,一种是功能和性能指标满足软件需求说明的要求,用户可以接受;另一种是软件不满足软件需求说明的要求,用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正,因此必须与用户协商,寻求一个妥善解决问题的方法。
    2. 配置复审  确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序,并且包括软件维护所必须的细节。
    3. α、β测试  事实上,软件开发人员不可能完全预见用户实际使用程序的情况。例如,用户可能错误的理解命令,或提供一些奇怪的数据组合,亦可能对设计者自认明了的输出信息迷惑不解,等等。因此,软件是否真正满足最终用户的要求,应由用户进行一系列"验收测试"。验收测试既可以是非正式的测试,也可以有计划、有系统的测试。有时,验收测试长达数周甚至数月,不断暴露错误,导致开发延期。一个软件产品,可能拥有众多用户,不可能由每个用户验收,此时多采用称为α、β测试的过程,以期发现那些似乎只有最终用户才能发现的问题。  α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品(称为α版本)进行测试,试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本,并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

    五、系统测试的基本方法

    计算机软件是基于计算机系统的一个重要组成部分,在系统测试之前,软件工程师应完成下列工作:  
    为测试软件系统的输入信息设计出错处理通路; 
    设计测试用例,模拟错误数据和软件界面可能发生的错误,记录测试结果,为系统测试提供经验和帮助;  
    参与系统测试的规划和设计,保证
    软件测试的合理性。  
    系统测试应该由若干个不同测试组成,目的是充分运行系统,验证系统各部件是否都能政党工作并完成所赋予的任务。
    下面简单讨论几类系统测试。
    1、恢复测试  恢复测试主要检查系统的容错能力。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败,然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化(reinitialization)、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性;对于人工干预的恢复系统,还需估测平均修复时间,确定其是否在可接受的范围内。
    2、安全测试  安全测试检查系统对非法侵入的防范能力。安全测试期间,测试人员假扮非法
    入侵者,采用各种办法试图突破防线。例如,①想方设法截取或破译口令;②专门定做软件破坏系统的保护机制;③故意导致系统失败,企图趁恢复之机非法进入;④试图通过浏览非保密数据,推导所需信息,等等。理论上讲,只要有足够的时间和资源,没有不可进入的系统。因此系统安全设计的准则是,使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。
    3、强度测试  强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如,①当中断的正常频率为每秒一至两个时,运行每秒产生十个中断的测试用例;②定量地增长数据输入率,检查输入子功能的反映能力;③运行需要最大存储空间(或其他资源)的测试用例;④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例,等等。
    4、
    性能测试  对于那些实时和嵌入式系统,软件部分即使满足功能要求,也未必能够满足性能要求,虽然从单元测试起,每一测试步骤都包含性能测试,但只有当系统真正集成之后,在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合,经常需要其他软硬件的配套支持。

    六、
    软件测试自动化的一些具体做法
    因为
    软件测试的工作量很大(40% 到60% 的总开发时间),而又有很大部分适于自动化,因此,测试的改进会对整个开发工作的质量、成本和周期带来非常显著的效果。  
      下面举出一些测试自动化的例子:
    1.   测试个案(test case ,或称为测试用例)的生成  
    用编程语言或更方便的剧本语言(scrīpt language 例如Perl等)写出短小的程序来产生大量的测试输入(包括输入数据与操作指令)。或同时也按一定的逻辑规律产生标准输出。输入与输出的文件名字按规定进行配对,以便控制自动化测试及结果核对的程序易于操作。  这里提到测试个案的命名问题,如果在项目的文档设计中作统一规划的话,软件产品的需求与功能的命名就应该成为后继开发过程的中间产品的命名分类依据。这样,就会为文档管理和配置管理带来很大的方便,使整个产品的开发过程变得更有条理,更符合逻辑。任何新手半途加入到开发工作中也会更容易进入状态。
    2.   测试的执行写控制  
    单元测试或集成测试可能多用单机运行。但对于系统测试或回归测试,就极有可能需要多台机在网络上同时运行。记住一个这样的原则,在开发过程中的任何时候,如果你需要等候测试的运行结果的话,那就是一个缩短开发时间的机会。对于单个的测试运行,挖潜的机会在测试的设置及开始运行和结果的对比及显示。有时候,需要反复修改程序,重新汇编和重新测试。这样,每一个循环的各种手工键入的设置与指令所花费的时间,加起来就非常可观。如果能利用make或类似的软件工具来帮助,就能节省大量的时间。 对于系统测试或回归测试这类涉及大量测试个案运行的情况,挖潜的的机会除了利用软件工具来实现自动化之外,就是怎样充分利用一切硬件资源。往往,就算是在白天的工作时间内,每台计算机的负荷都没有被充分利用。能够把大量测试个案分配到各台机器上去同时运行,就能节省大量的时间。另外,把大量的系统测试及回归测试安排到夜间及周末运行,更能提高效率。如果不购买商品化的工具的话,应当遵从正规的软件开发要求来开发出好的
    软件测试自动化工具。在实践中,许多企业自行开发的自动化工具都是利用一些现成的软件工具再加上自己写的程序而组成的。这些自己开发的工具完全是为本企业量身定做的,因此可用性非常强。同时,也能根据需要随时进行改进,而不必受制于人。在设计软件自动测试工具的时候,路径(path)控制是一个非常重要的功能。理想的使用情况是:这个工具可以在任何一个路径位置上运行,可以到任何路径位置去取得测试用例,同时也可以把测试的结果输出放到任何的路径位置上去。这样的设计,可以使不同的测试运行能够使用同一组测试用例而不至于互相干扰,也可以灵活使用硬盘的空间,并且使备份保存工作易于控制。同时,软件自动测试工具必须能够有办法方便地选择测试用例库中的全部或部分来运行,也必须能够自由地选择被测试的产品或中间产品采作为测试对象。
    3.   测试结果与标准输出的对比 
      在设计测试用例的时候,必须考虑到怎样才能够易于对此测试结果和标准输出。输出数据量的多少及数据格式对比较的速度有直接影响。而另一方面,也必须考虑到输出数据与测试用例的测试目标的逻辑对应性及易读性,这将会大大有利于分析测试所发现的不吻合,也有利于测试用例的维护。  许多时候,要写一些特殊的软件来执行测试结果与标准输出的对比工作,因为可能有部分的输出内容是不能直接对比的(比如,对运行的日期时间的记录,对运行的路径的记录,以及测试对象的版本数据等),就要用程序进行处理。
    4.   不吻合的测试结果的分析、分类、记录和通报  
    上一点所谈到的,用于对测试结果与标准输出进行对比的特殊软件,往往也同时担任对不吻合的测试结果进行分析、分类、记录和通报的任务。"分析"是找出不吻合的地方并指出错误的可能起因。"分类"包括各种统计上的分项,例如,对应的源程序的位置,错误的严重级别(提示、警告、非失效性错误、失效性错误;或别的分类方法),新发现的还是已有记录的错误,等等。"记录",是按分类存档。"通报",是主动地对测试的运行者及测试用例的"负责人"通报出错的信息。   这里提到测试用例的"负责人"的概念。是用以指定一个测试用例运行时发现的缺陷,由哪一个开发人员负责分析(有时是另外的开发人员引进的缺陷而导致的错误)及修复。在设立测试用例库时,各用例均应有指定的负责人。  最直接的通报方法是由自动测试软件发出电子邮件给测试运行者及测试用例负责人。邮件内容的详细程度可根据需要灵活决定。
    5.   总测试状况的统计,报表的产生  

    这些都是自动
    测试工具所应有的功能。目的是提高过程管理的质量,同时节省用于产生统计数据的时间。产生出来的统计报表,最好是存放到一个约定的路径位置,以便任何有关人员都知道怎样查阅。同时,可按需要用电子邮件向适当的对象(如项目经理,测试经理和质量保证经理)寄出统计报表。
  • 软件测试中有关界面测试经验总结

    2007-05-17 10:46:56Top 2 Digest 2

    1.应验证界面显示内容的完整性:

      a) 报表显示时应考虑数据显示宽度的自适应或自动换行。

      b) 所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等),必须使测试数据的记录数超过一屏/一页,以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印,界面显示是否正常;

      2.应验证界面显示内容的一致性:

      a) 如有多个系统展现同一数据源时,应保证其一致性;

      3.应验证界面显示内容的准确性:

      a) 对于报表中的所有字段值都应该有明确的定义,对于无意义的字段值,不应该显示空,应显示“--”或“/”,表示该字段值无意义。

      4.应验证界面显示内容的友好性:

      a) 对统计的数据应按用户习惯进行分类、排序。

      b) 某些重要信息在输入、修改、删除时应有“确认”提示信息;

      c) 界面内容更新后系统应提供刷新功能。

      d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;

      5.应验证界面提示信息的指导性:

      a) 在多个业务功能组成的一个业务流程中,如果各个功能之间的执行顺序有一定的制约条件,应通过界面提示用户。

      b) 用户提示信息应具有一定的指导性,在应用程序正在进行关键业务的处理时,应考虑在前台界面提示用户应用程序正在进行的处理,以及相应的处理过程,在处理结束后再提示用户处理完毕。

      c) 在某些数据输入界面,如果要求输入的数据符合某项规则,应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。

      d) 在对任何配置信息修改后,都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);

      6.应验证界面显示内容的合理性:

      a) 在对某些查询功能进行测试时,应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。

      b) 界面测试时,应考虑某一界面上按钮先后使用的顺序问题,以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。

      c) 界面测试时,应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确;

      7.界面测试时,应考虑用户使用的方便性:

      a) 在某些对数据进行处理的操作界面,应考虑用户可能对数据进行处理的频繁程度和工作量,考虑是否可以进行批量操作。

  • 测试管理的能力要求,看看自己还差多少

    2008-05-05 11:42:13Top 1 Digest 1

    低层管理者不论是作为一名执行者、还是一名领导者,都必须通过别人来完成任务。要做个“服众”的经理人,应该有意识地提高以下八项能力:
    1. 领悟能力
        做任何一件事以前,一定要先弄清楚上司希望你怎么做,然后以此为目标来把握做事的方向,这一点很重要,千万不要一知半解就开始埋头苦干,到头来力没少出、活没少干,但结果是事倍功半,甚至前功尽弃。要清楚悟透一件事,胜过草率做十件事,并且会事半功倍。
    2. 计划能力
        执行任何任务都要制定计划,把各项任务按照轻、重、缓、急列出计划表,一一分配部属来承担,自己看头看尾即可。把眼光放在部门未来的发展上,不断理清明天、后天、下周、下月,甚至明年的计划上。在计划的实施及检讨时,要预先掌握关键性问题,不能因琐碎的工作,而影响了应该做的重要工作。要清楚做好20%的重要工作,等于创造80%的业绩。
    3. 指挥能力
        无论计划如何周到,如果不能有效地加以执行,仍然无法产生预期的效果,为了使部属有共同的方向可以执行制定的计划,适当的指挥是有必要的。 指挥部属,首先要考量工作分配,要检测部属与工作的对应关系,也要考虑指挥的方式,语气不好或是目标不明确,都是不好的指挥。而好的指挥可以激发部属的意愿,而且能够提升其责任感与使命感。要清楚指挥的最高艺术,是部属能够自我指挥。
    4. 控制能力
        控制就是追踪考核,确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉,然而企业的经
    营有其十分现实的一面,有些事情不及时加以控制,就会给企业造成直接与间接的损失。但是,控制若是操之过急或是控制力度不足,同样会产生反作用:控制过严使部属口服心不服,控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制,就是让部属通过目标管理方式实现自我控制。
    5. 协调能力
        任何工作,如能照上述所说的要求,制定完善的计划、再下达适当的命令、采取必要的控制,工作理应顺利完成,但事实上,主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调,也包括与外部客户、关系单位、竞争对手之间的利益协调,任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。
    6. 授权能力
        任何人的能力都是有限的,作为高级经理人不能象业务员那样事事亲历亲为,而要明确自己的职责就是培养下属共同成长,给自己机会,更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子,也是延伸自己智力和能力的载体,要赋予下属责、权、利,下属才会有做事的责任感和成就感,要清楚一个部门的人琢磨事,肯定胜过自己一个脑袋琢磨事,这样下属得到了激励,你自己又可以放开手脚做重要的事,何乐而不为。切记成就下属,就是成就自己。
    7. 判断能力
        判断对于一个经理人来说非常重要,企业经营错综复杂,常常需要主管去了解事情的来龙去脉因果关系,从而找到问题的真正症结所在,并提出解决方案。这就要求洞察先机,未雨绸缪。要清楚这样才能化危机为转机,最后变成良机。
    8. 创新能力
        创新是衡量一个人、一个企业是否有核心竞争能力的重要标志,要提高执行力,除了要具备以上这些能力外,更重要的还要时时、事事都有强烈的创新意识,这就需要不断地学习,而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的,它要求大家把工作的过程本身当作一个系统的学习过程,不断地从工作中发现问题、研究问题、解决问题。解决问题的过程,也就是向创新迈进的过程。因此,我们做任何一件事都可以认真想一想,有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限,唯有创新,才能生存。
    领导力更需提升
        那么,怎样才能提升领导力呢?除了提高以上八项能力之外,还有最重要的两点:
    1. 学会用老板眼光看企业。
        在老板看来,管理很简单,就是两件事:一是扩大业务范围,增加业务收人;另一件事就是降低管理成本,控制运作费用。其实这两件事,最终是一件事,收入减去成本,减去费用,就是利润。所以归根到底老板是看利润的,利润要从管理中来。
    2. 从被领导中学习领导。
        在领导人看来,领导也很简单,就是两件事:一是用人,内圈用德、外圈用才,用人所长、容人所短;二是激励,解人之难、记人之功,通过正面激励,引导下属往前跑,通过负面激励,推着下属往前走。要知道,任何领导都是从做下属开始的,谁都不可能一步登天当领导。在每个人的成长过程中,你会经历大大小小许多领导,只要你用心学习,不管是好领导、还是坏领导,你都可以从正反两方面学到经验和教训,这对你将来当好领导是十分珍贵的
  • 测试人员存在的问题归纳

    2008-02-20 17:58:01Top 1 Digest 1

     


    一、根基不牢
    问题:利用等价类划分的方法,对某问题设计测试用例。

    分析:98%以上的应聘者只知道按照有效等价类和无效等价类进行划分,殊不知此种分类方法只是等价类划分的一个典型应用而已,等价类划分远非只能划分为有效和无效两类。根据种种划分依据,还可以进一步划分很多其他类别。

    问题:根据事件描述,画出对应的因果图。

    分析:标准答案中只画了“两条恒等,两条非,一个与,一个或”。如此简单的问题,上百名应聘者中竟然无一人答对,痛心啊。黑盒测试方法就那么几种,既然你已知这个名,怎么就不知道多看几眼。

    ★ 小结:

    上面提到的是软件测试的最基本的方法,作为从业测试实际工作已经有1-2年的应聘人员,未能真正领悟,实属不应该,心浮气躁,忽视了你身边最简单,也是最厉害的技能。根基不牢,怎么可能把测试做深。

    二、专业不精

    问题:音视频文件都有哪些格式,这些格式之间有什么差别?

    分析:此问题是问那些做过多媒体方面测试的,但是我们的应聘者向来都是拿来主义,别人给我什么媒体文件我就用什么做测试,而根本不管不问。“为什么MIDI文件比WAV文件小那么多?我们如何知道扩展名是.Mpeg的文件是Mpeg1格式的还是Mpeg2格式的?”,面对这些问题,应聘者默默无语,只是无奈的笑笑。不去看别人,想想自己测试涉及的专业,是否把那个行业知识搞清楚了呢?

    问题:测试脚本运行不畅如何调试?

    分析:此问题是问那些标明自己熟练掌握WinRunner、Robot、QTP等测试工具的应聘人员,但是当真正问到他们关于脚本的具体调试时,有7成以上人员表示他们只是参加测试培训时老师讲过,或者自己在网上看过相关资料,另外有2成以上人员表示他们虽然用过,但是只是简单的录制回放,根本不会自己调试。可能是迫于无奈吧,简历里面什么都不写,可能面试的机会都没有,但是简历如此夸大的来写,终归是浪费自己的面试时间和路费。

    ★ 小结:

    从事测试仅1-2年时间,要想测试也精通,专业也精通确实不易,但是不说精通,至少也该知道个60%才对的起你的测试工作。一两年时光如此荒废,静下心来反思一下,身边还有哪些技能我们应该掌握扎实一点呢。

    三、无测试体系概念,忽视理论

    问题:请说出软件测试的定义,BUG的定义。

    分析:99%的人不能说出这两个测试名词的定义,只是在给我解释测试是为了发现bug之类的片面理解,残留的几个人也说得不够准确。这两个词目前尚不能说业内已经有了成熟统一的定义,但是无论是对是错,身为测试人员已经数年,自己竟然说不出这两个词的概念,多少也说不过去啊。有些人和我说,理论名词概念不重要,我会做测试就是了。想想金庸老先生早就告诉我们,武功仅有招式是不够的,必须配合上什么心法口诀才能行。你只会测试执行的招式,却不懂测试理论的心法,怎么能够修炼成上乘的软件测试呢?

    问题:请介绍一下你们的测试流程,流程和过程有什么不同,为什么好的测试需要好的流程?

    分析:但凡做过1、2年测试的人都能给我说出他们先做什么后做什么,但是当我继续问“这是否可以叫做过程?流程和过程有什么差别”,应聘者一棒子被打晕,继续追问“为什么好的测试需要好的流程”的时候,早已经找不到东南西北了。每天公司各项制度叫你做什么你就做什么,让你怎么做你就怎么做,完全不管不顾为什么,那么自己岂不成了没头脑的工具。这样你能干的工作别人也能做,自己的优势不就没有了吗。

    ★ 小结:

    目前测试业内流传着学院派和实践派的说法,学院派的理论给人的感觉往往是好听但不实用,而实践派的知识,往往能够立即见效。所以眼下测试培训往往实践派的更受欢迎。继续引用金庸先生的观点,练武分练内气宗,练外剑宗,但是真正的高手是内外兼修。如果我们不想只做普通的测试小弟子的话,就要理论实践并重,方能有所作为。

    四、周边知识知之甚少

    问题:能给我介绍一下软件工程中的瀑布模型吗?

    分析:又是8成应聘者不会回答,都是曾在遥远的学生时代有所耳闻,现今早已忘得一干二净了。软件测试因何而生——软件危机,软件危机导致软件工程的兴起,软件工程中又包含软件测试,就好像鱼儿活在水里,如果没有软件工程这个水,哪里能够养活这软件测试的鱼,如果我们对于身边的软件工程不够了解,怎么可能在里面自由的畅游呢。

    问题:用你最熟悉的开发语言实现sum=1+2+3+…+100

    分析:保守统计7成以上的应聘者写出来的程序无法执行或者运行结果错误,更少有人能够一气呵成,而且精准。这道编程题难吗?肯定不难,那么为何答错,自己没有真正写过程序,即使写过几行,也早就是如烟往事了。做测试一定需要懂开发吗?这个问题讨论以久,当然不一定,但是如果要做好测试,做深测试,分析问题原因,提出问题解决方案,编写测试脚本或工具,哪一个又能离开软件开发呢?

    ★ 小结:

    我们学习测试也应该有个先后顺序,有步骤。掌握周边知识的紧迫程度可能不如测试知识和行业知识。但是对于我们已经从业1-2年的测试人员来说,学校里面学到的知识不应该丢,之后的发展中,周边知识的学习也应该开始了。周边知识的范畴其实很广,还包括各种其他测试理念的学习,机械工业出版社翻译的那套测试丛书就很不错,观点众多而新颖,博众家之长,集大成,向来都是大家风范。

    五、缺乏必要的责任心、细心、耐心、虚心等

    问题:请数出下图中三角形的个数(平面图,有几根弧线做干扰)

    分析:我总是问自己,这道题真有这么难吗?连中小学生都能数对的十几个三角形,到了我们这二十几岁的年轻人手中,正确率才1%,为什么?其实就是现在我们已经很少有人能够静下心来,耐心细致的去做事情了。很多应聘者告诉我她的优点就是“踏实,坐的住,正适合这繁琐的测试工作”。我需要的不是坐在那里不做事或者做错事的人,而是需要能够按时保质量完成测试工作的测试人员。

    问题:你离职的原因?

    分析:这是面试中最常见的问题了。应聘者往往也是充分准备,理由多种多样,但是看看应聘者的工作记录统计,70%应聘者平均跳槽频率是1年/次(实习情况除外),不会都那么凑巧吧,赶上什么公司倒闭,每隔一年就会想一次自己学不到东西,需要去外面看看。而在我看来,真正的原因更多的应该是希望通过跳槽提高工资,或者因为自身水平不足被公司炒鱿鱼吧。

    ★ 小结:

    我并不认为所有的人都适合做测试。非技术素质方面,这点或者那点不足够优秀也很正常,心浮气躁也可以理解。但是作为用人单位,理解归理解,却也不会用不胜任岗位,或性价比不高的人员。那么对于此类应聘者,我的忠告就是,要么你另谋高就,要么你就放低姿态,培养好你必备的素质后再谈。

    六、缺乏诚信

    这一点本应该被归在上一条素质中,但是这点的重要性我认为远超过了上一条所列各项,因此单独提出。相关表现主要体现在:

    ○ 报自己历史工薪;

    ○ 笔试题目作弊;

    ○ 编造离职原因;

    ○ 虚报学历,工作经验;

    ○ 夸大自己工作技能等。对于严重缺乏诚信的,一旦发现,其他表现再好,也无济于事了。

  • 测试管理学习

    2007-11-07 14:54:48Top 1 Digest 1

    一、单元测试怎么做,如何保证单元测试质量
    讨论意见:
    1、开发人员不会好好做单元测试
    2、有一个标准,规定千行代码的bug数,而已他们的unite test sepc我们也可以提意见,如如果case写的不充分,我们可以不接收的

    我的看法:
    1、单元测试本身非常繁琐、枯燥、乏味,无论是开发人员做还是测试人员做都是一样难坚持
    2、需要通过外部监督来保证单元测试的质量
    3、单元测试计划、单元测试大纲、单元测试规范、单元测试报告都需要进行严格的评审
    4、从测试用例上可以根据代码的情况规定每千行代码所对应的测试用例数,保证有足够的测试用例
    5、从测试报告上可以规定每千行代码所对应的缺陷数,保证单元测试发现了足够多的问题
    4、对集成测试、系统测试中发现的缺陷进行归纳总结,针对那些应该在单元测试阶段发现而没有发现的缺陷进行分析,帮助单元测试过程的改进和提高


    二、测试管理者如何和测试人员进行良好的沟通
    讨论意见:
    1、作为主管,不应该总是给下属安排任务
    2、平时聊聊天,不要天天谈工作,多位属下争取福利
    3、特别不能平白的帮她顶包~~! 工作上不懂,可以帮助她
    4、攻心为上,呵呵,你要和她说明,她不是为了你而工作,所以,其实不存在所谓的 谁服谁的问题
    5、管理的精髓在于对 “人”的管理,而不是“物件”
    6、不要轻易跟别人流露出你对下属的意见
    7、好话可以多说,坏话绝不能说,对谁都不能说,这是我的理解
    8、同事就是同事,永远不可能是朋友。
    9、同事之间,是一种竞争关系,朋友之间是要想互相理解互相帮助的
    10、很多人都认为开发和测试有矛盾,因为出发点不一致,所以矛盾难免产生,如果大家都是为了把软件做好,那么其实开发和测试应该是很好的伴侣
    11、我想知道的就是,领导跟下属是不是本身就存在一点距离的
    12、我打算今后增加为下属做职业规划这一行为

    我的看法:
    1、管理者和下属,工作和生活要严格区分开,工作时大家是合作关系(不同意是竞争关系^_^),生活时大家可以成为朋友
    2、管理者不是用来管理下属的,是为下属服务的,这个观念要转变,帮助下属把工作做好,帮助下属提高自己,帮助下属有更好的发展,这样才能和下属良好沟通
    3、工作时领导和下属肯定是有距离的,要做到赏罚分明,一视同仁
    4、对于不能和团队整体保持一致的下属,该出手时就出手,该拿掉的就拿掉
    5、建议大家看看曾仕强的中国式管理


    三、过程改进
    讨论意见:
    1、我现在做软件过程改进方面的工作。另外监管一下CM、QC、QA
    2、主要是过程改进了,因为过程改进与CM、QC、QA,RD都有关系,所以都涉及一些,但都不深
    3、很正常的,我们公司现在也是QA部,质量管理部,同时监管 SCM 和 测试部门,当然还有QA
    4、其实业务、销售为主导是没错的,开发和测试 是为了这个环节而展开的。
    5、这种东西都是长期才能见到效益的
    6、企业的首要目的应该就是盈利,这是终极目标,而其他的是中间过程。过程改进也是奔着这个目标而去
    7、总体的感觉是:质量、过程是重要的,但是优先级是不高的
    8、我认为市场销售和软件生产过程是一个整体,任何一个木片短了,企业的盈利情况就不容乐观
    9、没错,现在都在说过程改进,其实 人 的因素也很重要,甚至可以说是最本质的
    10、你有没有和你的上级领导沟通过?实施过CMM的人应该知道,过程的改进需要组织级的推动,自顶向下的改进。首先让公司最大的leader首肯这件事,不是敷衍,是亲力亲为

    我的看法:
    1、非常同意市场销售和软件生产是一个整体的说法,为了提高效率产生了分工,但要明确的是分工而不是分离,如果领导是技术出身,应该不会忽视开发和测试的,如果是市场和销售出身,就需要好的沟通了
    2、都说过程改进需要领导点头,从上向下推动,其实过程改进还是要靠QA去推动,至于从上向下,还是从下向上都不是最重要的。
    3、不要想一下子就进行大刀阔斧的过程改进,先从容易入手、见效快的地方入手,上下见到了立杆见影的效果,自然会支持,领导不会无缘无故支持一个他看不到任何效果的改进
    4、过程改进整体而言是见效慢,但也有见效快的地方,这些就是比较好的过程改进切入点


    四、如何针对测试项目考虑测试
    讨论意见:
    1、看来你们还是比较幸福的,我们公司好多项目都是突发的,没有任何可以计划
    2、更讨厌的是,我们的测试任务还会临时调度下来不得不接
    3、没有计划没有文档所进行的测试,应用在V模型上确实显得特别的捉襟见肘
    4、就是针对不同的实际情况作出的反应以及处理方法
    5、举个例子,你现在有一个测试项目需要你负责测试,第一步你会做什么呢?指定测试计划,人力,设备,等等。第二步你会做哪些工作呢?熟悉设计文档,编写test spec
    6、其实在没有文档的情况下,我比较推崇XP的结对概念,不过我把它扩大了,XP里说,结对编程,而我认为应该 “凡事皆结对”,结对测试,结对管理
    7、我们公司从代码走查中想到进行用例走查
    8、在没有文档的时候,结对工作可以弥补文档不足带来的致命后果
    9、其实你可以这样想:为什么要结对?一个人做事容易错,容易把方向搞错;两个人会好很多。当然,这不是绝对的。一个泛泛之谈
    10、那你清楚你为什么选择在第二步去熟悉设计文档,编写测试用例呢,而不是选择研究软件需求和同类型的软件功能呢

    我的看法:
    1、无论是什么项目,不管是计划好的,还是突发的,做测试都应该有计划,这个计划既可以形成文档也可以存在于人的大脑里
    2、没有文档的测试和有文档的测试没有本质的区别,只不过后者需要寻找其它的方式来了解被测的对象到底要做成什么样了
    3、突发的测试任务,对测试负责人提出了更高的要求,他需要尽快确定如何来进行测试,确定测试策略,比如时间紧迫是采取基于风险的测试策略呢还是说采取探索式的测试策略,当然不同的测试阶段有不同的测试策略选择了
    4、不管是一个人测试还是结对测试,对被测对象信息的掌握都是一样重要的,对被测对象的原型越了解越有可能测试的更好,所以大家就不要局限在是做白盒测试还是黑盒测试还是灰盒测试的概念问题上了
    5、走查是静态测试的一种形式,任何阶段都可以使用
    6、即使是做单元测试,需求文档和设计文档一样都是要看的
    7、测试时即使只有设计文档没有真正的代码也一样可以“运行”软件,那就是在纸上进行,国外进行一些设计的评审时测试工程师就经常采用这种方式,在白板上让开发人员对每一个“运行”流程进行确认
  • CVS使用速成配置 ---我给公司搭建CVS服务器就是参照这个的

    2007-08-06 17:09:10Top 1 Digest 1



    CVS服务器的安装:
    1
    。查看你的操作系统上是否安装了CVS

    #> rpm -qa|grep cvs

    如果没有安装你可以在Redhat 2张光盘上找到,另外你也可以在网上下载到最新的rpm包。很容易找,其实不存在什么linux版本。


    2
    。建立cvs用户组:


    #> groupadd cvs

    3
    。建立cvs组的cvsroot用户和所属的目录:


    #> useradd -g cvs -G cvs –d /cvsroot cvsroot

    4
    。为cvsroot用户添加密码:


    #> passwd cvsroot

    5
    。改变 /cvsroot/ 的目录属性:


    #> chmod –R 770 /cvsroot

    6
    。改变用户登陆身份:


    #> su cvsroot

    7
    。开始创建单个项目:


    #> cd /cvsroot
    #> mkdir project1
    #>mkdir project2
    8
    。开始建立仓库:


    #> cvs –d /cvsroot/project1 init
    #> cvs –d /cvsroot/project2 init
    #> chmod –R 770 ./project1/ ./project2/

    9
    。建立CVS服务启动文件,我们使用xinetd方式:


    #> [Crtl]+[d]
    切换到root用户身份

    #> cd /etc/xinetd.d
    #> vi cvspserver

    service cvspserver
    {
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server= /usr/bin/cvs
    server_args= -f --allow-root=/home2/cvsroot/project1 --allow-root=/home2/cvsroot/project2 pserver log_on_failure += USERID
    }

    注:由于xinetdserver_args长度限制,当你想运行很多的单个仓库的时候,可以这么做:


    #> vi cvspserver

    service cvspserver
    {
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server = /cvsroot/cvs.run
    log_on_failure += USERID
    }

    编写cvs.run脚本


    #> vi /cvsroot/cvs.run

    #!/bin/bash
    /usr/bin/cvs -f
    --allow-root=/cvsroot/project1
    --allow-root=/cvsroot/project2
    pserver

    #>chmod +x /cvsroot/cvs.run

    10
    。加入cvs服务:


    #>vi /etc/services

    cvspserver 2401/tcp #pserver cvs service
    cvspserver 2401/udp #pserver cvs service
    11
    。启动cvs服务:


    #> /etc/init.d/xinetd restart

    12
    。检查cvspserver服务是否已经启动:


    #> netstat -l |grep cvspserver
    应该有如下结果:


    tcp 0 0 *:cvspserver *:* LISTEN

    二。CVS服务的用户管理:


    上面我们已经建立了project1project2两个CVS仓库,下面我们分别给两个仓库建立cvs用户。


    13
    。创建可以登陆cvs服务器的用户名和密码:


    #> su cvsroot
    #> vi /cvsroot/project1/CVSROOT/passwd

    trotter:*****:cvsroot
    mimi:*****:cvsroot

    #>vi /cvsroot/project2/CVSROOT/passwd

    trotter:*****:cvsroot
    gary:*****:cvsroot

    这两个文件的意思是有trottermimigary三个cvs用户,mimi拥有project1的使用权限,gary拥有project2的使用权限,trotter拥有project1project2的使用权限。登陆后的权限是cvsroot权限。

    注意:这里的cvs用户和系统用户是不同的。


    14
    *****为密码,由以下文件生成:


    #> vi /cvsroot/passwd.pl

    #!/usr/bin/perl
    srand (time());
    my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
    my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
    my $plaintext = shift;
    my $crypttext = crypt ($plaintext, $salt);
    print "${crypttext}
    ";

    #>chmod a+x /cvsroot/passwd.pl

    15
    。如果你想生成一个密码是123456”,则:


    #> /cvsroot/passwd.pl “123456”

    回车即可得到加密密码,用其替换passwd文件中的
    *****

    16
    Okcvs现在已经全部安装完成了,如果你想让一个用户拥有project1的权限,你就在 /cvsroot/project1/CVSROOT/passwd中给他加入一个用户;如果你想让一个用户同时具有project1project2 的权限,你就给/cvsroot/project1/CVSROOT/passwd/cvsroot/project2/CVSROOT/passwd 里给他加一个用户名和密码相同的用户即可。最后,我们试用一下:


    #> cvs -d :pserver:trotter@192.168.1.200:/cvsroot/project1 login

    敲入命令回车后提示输入trotter的密码,你按照自己设置的密码输入,如果没有什么错误信息出现就是成功了(我的机器IP地址是
    192.168.1.200)




    ***CVS
    服务器建立和权限配置




    建立一个源代码库主要有以下几步:


    1)初始化cvs服务器环境。

    #cvs -d/usr/local/source init
    之后进入/usr/local/source,可以看到有一个目录CVSROOT, 下面是初始化后的CVS服务器配置文件。暂且保持不动。


    2)把cvs服务放到xinetd系统服务中。

    首先在/etc/xinetd.d目录下生成任务配置文件cvspserver,文件名称可以随便用。


    其中内容大致如下:


    service cvspserver
    {
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    protocol = tcp
    server = /usr/bin/cvs
    server_args = -f --allow-root=/usr/local/source pserver
    disable = no
    }



    其中server_args一个参数指定了源代码库路径,一个指定了服务器使用密码认证方式。

    第二,要确认/etc/services文件中,有cvspserver关键词,并分配了端口,如:cvspserver 2401/tcp

    第三,重新启动xinetd服务,cvs服务就可以用了。


    3)测试。假定cvs服务器在192.168.0.205上,系统上有一个用户cvs。登陆另一台linxu机器,执行下列命令可以完成测试:

    $export CVSROOT=:pserver:cvs@192.168.0.205:2401/usr/local/source
    $cvs login
    输入密码,没有出错提示表示登陆成功。


    如果想在一个linux系统上建多个源代码库,分别提供cvs服务。重复上面步骤就可以了。


    第一步时候要注意使用一个不同路径。

    第二步放到xinetd系统服务中稍微麻烦点。/etc/xinetd.d目录下要生成一个新的任务配置文件,例如cvspserver1,文件中service名称一定要区分第一个,例如service cvspserver1server_args做相应变动。还要在/etc/services文件中,加入新的服务端口号,例如: cvspserver1 2402/tcp。重新启动xinetd服务
    .

    第三步测试时候,可以这样设定:

    $export CVSROOT=:pserver:cvs@192.168.0.205:2402/usr/local/source1
    ......

  • 软件测试工具大全(简介)

    2007-06-08 16:44:55Top 1 Digest 1

    2007-06-08

    企业级自动化测试工具WinRunner

     

    提名理由:Mercury Interactive公司的WinRunner是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

    工业标准级负载测试工具Loadrunner

     

    提名理由:LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。

    全球测试管理系统testdirector

     

    提名理由:TestDirector 是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分,包括需求管理,测试计划,测试执行以及错误跟踪等功能,TestDirector极大地加速了测试过程。

    功能测试工具Rational Robot

     

    提名理由:IBM Rational Robot 是业界最顶尖的功能测试工具,它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上,在这里测试人员可以计划、组织、执行、管理和报告所有测试活动,包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

    单元测试工具xUnit系列

     

    提名理由:目前的最流行的单元测试工具是xUnit系列框架,常用的根据语言不同分为JUnit(java),CppUnit(C++),DUnit (Delphi ),NUnit(.net),PhpUnit(Php )等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma (《设计模式》的作者)和Kent Beck(XP(Extreme Programming)的创始人 )提供的开放源代码的JUnit。

    功能测试工具SilkTest

     

    提名理由:Borland SilkTest 2006属于软件功能测试工具,是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试,无论是程序设计新手或资深的专家都能快速建立功能测试,并分析功能错误。 

    性能测试工具WAS

     

    提名理由:Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发,专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具,您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。

    自动化白盒测试工具Jtest

     

    提名理由:Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。parasoft同时出品的还有C++ test,是一款C/C++白盒测试工具。

    功能和性能测试的工具JMeter

     

    提名理由:JMeter是Apache组织的开放源代码项目,它是功能和性能测试的工具,100%的用java实现。

    性能测试和分析工具WEBLODE

     

    提名理由:webload是RadView公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作,生成压力负载来测试web的性能。

     测试工具大全

    Author: Vince

    工具类别 工具名称 生产厂商 相关网站
    通用功能自动化测试工具 Winrunner Mercury
    Quicktest pro Mercury
    Xrunner Mercury
    QARun Compuware
    TestPartner Compuware
    WebKing Parasoft http://www.parasoft.com
    Robot IBM Rational http://www.ibm.com/cn
    Visual Test IBM Rational http://www.ibm.com/cn
    Functional Tester IBM Rational http://www.ibm.com/cn
    SilkTest Segue
    SilkTest International Segue
    e-Tester Empirix
    WebFT Radview
    TestComplete AutomatedQA
    QA Wizard Seapine
    Software EggPlant RedStone
    Test Edition Microsoft Visual Studio
    PureTest Minq
    Autotester Autotester
    Testbench400 Original Software
    TestExpert VEReCOMM
    TestRunner Qronus
    TTCN suite Telelogic http://www.telelogic.com.cn
    QC/Replay Centerline
    Web AutoTester
    eValid Software Research
    WebART OCLC
    MaxQ 开源
    WebInject 开源
    Marathon 开源
    性能测试/监控工具  LoadRunner Mercury
    SiteScope Mercury
    Topaz Mercury
    QaLoad Compuware
    PerformaSure/benchmark Quest
    Silkperformer Segue
    Silkperformer Lite Segue
    SilkCentralTM Performance Manager Segue
    e-Load Empirix
    Robot IBM Rational http://www.ibm.com/cn
    Performance Tester IBM Rational http://www.ibm.com/cn
    WebLoad RadView
    Web applicaton stress tool  Microsoft
    Application center test Microsoft
    PureLoad Minq
    Athene APR Metron
    ForeCast Facilita
    Impact/Impact for CBT Cyrano
    Berkeley Laboratory sniffer Lawrence
    Jmeter 开源
    openSTA 开源
    Siege 开源
    StressMark 开源
    DBMonster 开源
    白盒测试/代码分析工具  VcTester ezTester http://www.eztester.com
    Jtest Parasoft http://www.parasoft.com
    C++test Parasoft http://www.parasoft.com
    SOA test Parasoft http://www.parasoft.com
    .test Parasoft http://www.parasoft.com
    Codewizard Parasoft http://www.parasoft.com
    Insure++ Parasoft http://www.parasoft.com
    DataRecon Parasoft http://www.parasoft.com
    Numega devpartner studio Compuware
    DevPartnerJavaEdition Compuware
    BoundsChecker Compuware
    SmartCheck Compuware
    DBPartner Compuware
    Bean-test Empirix
    Aqtime AutomatedQA
    QESatJava AutomatedQA
    Visual Unit Unitware
    PC-lint Gimpel Software
    Macabe Macabe
    Optimizeit Suite Borland
    JProbe Suite Quest Software
    Application assurance suite Quest Software
    Sql optimizer Quest Software
    Jprofiler ej-technologies
    workbench Cyrano
    Logiscope TeleLogic http://www.telelogic.com.cn
    rulecheck TeleLogic http://www.telelogic.com.cn
    SilkPerformer Component Test Edition Segue
    Purifyplus IBM rational http://www.ibm.com/cn
    Rational Test Realtime IBM rational http://www.ibm.com/cn
    junit 开源
    cactus 开源
    Hansel 开源
    TestNG 开源
    StrutsTestCase 开源
    JFCUnit 开源
    Httpunit 开源
    Dunit 开源
    cppunit 开源 http://sourceforge.net/projects/cppunit
    Nunit 开源
    Xunit 开源
    JTR 开源
    MallocDebug Linux平台工具
    Valgrind Linux平台工具
    Kcachegrind Linux平台工具
    dmalloc Linux平台工具
    ElectricFence Linux平台工具
    LeakTracer Linux平台工具
    memprof Linux平台工具
    ccmalloc Linux平台工具
    mprof Linux平台工具
    yamd Linux平台工具
    njamd Linux平台工具
    mpatrol Linux平台工具
    嵌入式测试工具 VcTester ezTester http://www.eztester.com
    codetest Metrowerks
    Cantata/cantana++ IPL
    IceMaster Reflex Technology
    System test Reflex Technology
    scorecast DDC-I
    Testquest Testquest
    UniText ATTOL
    vectorcast Vector software
    testrunner Qronus
    Logiscope Telelogic http://www.telelogic.com.cn
    测试管理工具 TestDirector(QualityCenter) Mercury
    QADirector Compuware
    certify Worksoft
    Product manager Aimware
    SilkCentral Test Manager Segue
    Doors Telelogic http://www.telelogic.com.cn
    e-manager Empirix
    testmanager IBM Rational http://www.ibm.com/cn
    TestView Manager RadView
    Professional T-Plan
    缺陷管理工具 TestDirector(QualityCenter) Mercury
    ClearQuest IBM Rational http://www.ibm.com/cn
    TrackRecord Compuware
    TestTrack pro Seapine
    TrueTrack McCabe
    Devtrack Techexcel
    Notes IBM Lotus
    SilkCentral Issue Manager Segue
    PVCS Tracker Merant
    AR System Remedy
    URTrack LealSoft
    Butterfly Hansky
    Bugzilla 开源
    Mantis 开源
    JIRA 开源
    BugFree 开源
    配置管理工具 ClearCase IBM Rational http://www.ibm.com/cn
    PVCS Version Manager Merant
    VCS Diamond
    StarTeam Borland
    Perforce Perforce
    TRUEchange McCabe
    SYNERGY CM  Telelogic http://www.telelogic.com.cn
    VSS Microsoft
    Firefly Hansky
    CVS Subversion
    SCCS RCS
    CCC/Harvest Computer Associates

  • 软件测试面试题目汇总解答

    2007-05-29 14:21:59Top 1 Digest 1

    相信我 没错的!快点击吧
    01. 为什么要在一个团队中开展软件测试工作?
    因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。
    02. 您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?
    我曾经做过web测试,后台测试,客户端软件,其中包括功能测试,性能测试,用户体验测试。最擅长的是功能测试
    03. 您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同04. 的测试类型的区别与联系(如功能测试、性能测试……)
    测试类型有:功能测试,性能测试,界面测试。
    功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。
    性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
    界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
    区别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上,用户使用该产品的时候是否易用,是否易懂,是否规范(快捷键之类的),是否美观(能否吸引用户的注意力),是否安全(尽量在前台避免用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)?做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没问题的,然后再考虑该功能点的性能测试
    05.  请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
    黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。
    白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。
      软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误:
    1、是否有不正确或遗漏的功能?
    2、在接口上,输入是否能正确的接受?能否输出正确的结果?
    3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
    4、性能上是否能够满足要求?
    5、是否有初始化或终止性错误?
      软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查:
    1、对程序模块的所有独立的执行路径至少测试一遍。
    2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。
    3、在循环的边界和运行的界限内执行循环体。
    4、测试内部数据结构的有效性,等等。
    单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
          单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
    集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。
    系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)
           系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。
    验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
    验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。
    06. 测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?
    软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
    测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)
    07. 您认为做好测试计划工作的关键是什么?
    1. 明确测试的目标,增强测试计划的实用性
    编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
    2.坚持“5W”规则,明确内容与过程
    “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。
    3.采用评审和更新机制,保证测试计划满足实际需求
    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
    4. 分别创建测试计划与测试详细规格、测试用例
    应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
    08. 您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
    1.等价类划分
    划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
    2.边界值分析法
      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
    3.错误推测法
      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
    4.因果图方法
      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
    08.您认为做好测试用例设计工作的关键是什么?
    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题
    09. 请以您以往的实际工作为例,10. 详细的描述一次测试用例设计的完整的过程。
    就说最近的这次网站功能的测试吧
    首先:得到相关文档(需求文档和设计文档),理解需求和设计设计思想后,想好测试策略(测试计划简单点就OK了),考虑到测试环境,测试用例,测试时间等问题。
    第二步:设计测试用例,测试策略是:把网站部分的功能点测试完,然后在进行系统测试(另外个模块呢有另一个测试人员负责,可以进行联调测试),网站模块的测试基本是功能测试和界面测试(用户并发的可能性很小,所以不考虑):这次的网站的输入数据呢是使用数据库中的某张表记录,如果表中某一数据记录中新加进来的(还没有被处理的,有个标志位),网站启动后会立刻去刷那张表,得到多条数据,然后在进行处理。处理过程中,会经历3个步骤,网站才算完成了它的任务。有3个步骤呢,就可以分别对这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况(包括数据库中的数据,用户的输入等),得出了差不多50个用例。界面测试,也就是用户看的到的地方,包括发送的邮件和用户填写资料的页面展示。
    第三步:搭建测试环境(为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟了,只有有机器能空于下来做该功能测试就可以做了),因为网站本身的环境搭建和其他的系统有点不同,它需要的测试环境比较麻烦,需要web服务器(Apache,tomcat),不过这次需求呢,网站部分只用到了tomcat,所以只要有tomcat即可
    第四步:执行测试
    11. 您以往是否曾经从事过性能测试工作?如果有,12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
    是的,曾经做过网站方面的性能测试,虽然做的时间并不久(2个月吧),当时呢,是有位网站性能测试经验非常丰富的前辈带着我一起做。
    性能测试类型包括负载测试,强度测试,容量测试等
          负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
          强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。
          容量测试:确定系统可处理同时在线的最大用户数  
    在网站流量逐渐加大的情况下,开始考虑做性能测试了,首先要写好性能测试计划,根据运营数据得出流量最大的页面(如果是第一次的话,一般是首页,下载页,个人帐户页流量最大,而且以某种百分比),
    Web服务器指标指标:
    * Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数;
    * Successful Rounds:成功的请求;
    * Failed Rounds :失败的请求;
    * Successful Hits :成功的点击次数;
    * Failed Hits :失败的点击次数;
    * Hits Per Second :每秒点击次数;
    * Successful Hits Per Second :每秒成功的点击次数;
    * Failed Hits Per Second :每秒失败的点击次数;
    * Attempted Connections :尝试链接数;
    13. 您在从事性能测试工作时,14. 是否使用过一些测试工具?如果有,15. 请试述该工具的工作原理,16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
    17. 您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
    18. 在您以往的工作中,19. 一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
    20. 您以往所从事的软件测试工作中,21. 是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有,22. 请结合该工具描述软件缺陷(Bug)跟踪管理的流程。
    23. 您认为在测试人员同24. 开发人员的沟通过程中,25. 如何提高沟通的效率和改善沟通的效果?维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么?
    27. 在您以往的测试工作中,28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么?您是如何来对待这些事情的?
    31. 在即将完成这次笔试前,32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会?(可以包括软件测试、过程改进、软件开发或者与此无关的其他方面)
    33.     你对测试最大的兴趣在哪里?为什么?
    最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗列了11,12点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的1,2点我没有把握,其他点我都很有信心做好它。
    刚开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发更难,虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。
    不到一年半的测试工作中,当时的感动和热情没有减退一点(即使环境问题以及自身经验,技术的不足,做测试的你一定也能理解)。
    我觉得做测试整个过程中有2点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计上了,要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技术基础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技术知识你要知道网站内部是怎么运作的的,后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备,可能会遇到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。
    第二是发现BUG的时候了,这应该是测试人员最基本的任务了,一般按测试用例开始测试就能发现大部分的bug,还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息,补充测试用例,测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下,通过细心和耐心去发现bug了,每个用例都有可能发现bug,每个地方都有可能出错,所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了,bug都在里面发现的)。如何描述bug也很有讲究,bug在什么情况下会产生,如果条件变化一点点,就不会有这个bug,以哪些最少的操作步骤就能重现这个bug,这个bug产生的规律是什么?如果你够厉害的话,可以帮开发人员初步定位问题。
    34. 你的测试职业发展是什么?
    测试经验越多,测试能力越高。所以我的职业发展是需要时间累积的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年累积测试经验,按如何做好测试工程师的11,12点要求自己,不断的更新自己改正自己,做好测试任务。
    35. 你自认为测试的优势在哪里?
    优势在于我对测试坚定不移的信心和热情,虽然经验还不够,但测试需要的基本技能我有信心在工作中得以发挥。
    36. 你以前工作时的测试流程是什么?
    公司对测试流程没有规定如何做,但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正(自己总结,吸取同行的方法)后的流程吧。需求评审(有开发人员,产品经理,测试人员,项目经理)->需求确定(出一份确定的需求文档)->开发设计文档(开发人员在开始写代码前就能输出设计文档)->想好测试策略,写出测试用例->发给开发人员和测试经理看看(非正式的评审用例)->接到测试版本->执行测试用例(中间可能会补充用例)->提交bug(有些bug需要开发人员的确定(严重级别的,或突然发现的在测试用例范围之外的,难以重现的),有些可以直接录制进TD)->开发人员修改(可以在测试过程中快速的修改)->回归测试(可能又会发现新问题,再按流程开始跑)。
    37. 当开发人员说不38. 是BUG时,39. 你如何应付?
    开发人员说不是bug,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3方商量确定好后再看要不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果?程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场,让问题得到最后的确认。
    23.你为什么想离开目前的职务?
    因为公司运作情况并不理想,公司需要调整部门体系,公司考虑到缩减部门人员,所以大批量的裁员(有6,7个),这是我的第一份工作,对公司也有较深的感情,因为在这里我找到了职业理想(就是测试),所以公司需要精简人员,我自愿退出。虽然很舍不得,但我将会有新的发挥能力的舞台。
      24:你对我们公司了解有多少?
      25:你找工作时,最重要的考虑因素为何?
    工作的性质和内容是否能让我发挥所长,并不断成长。
    26:为什么我们应该录取你?
    您可以由我过去的工作表现所呈现的客观数据,明显地看出我全力以赴的工作态度。
      27:请谈谈你个人的最大特色。
    我的坚持度很高,事情没有做到一个令人满意的结果,绝不罢手。
    28.白箱测试和黑箱测试是什么?什么是回归测试?
        29。单元测试、集成测试、系统测试的侧重点是什么?
        30。设计用例的方法、依据有那些?
        31。一个测试工程师应具备那些素质和技能?
        32.集成测试通常都有那些策略?
        33.你用过的测试工具的主要功能、性能及其他?
        34.一个缺陷测试报告的组成
        35.基于WEB信息管理系统测试时应考虑的因素有哪些?
    36.软件测试项目从什么时候开始,?为什么?
         37.需求测试注意事项有哪些?
         38.简述一下缺陷的生命周期
         39.测试分析测试用例注意(事项)?
    你在你所在的公司是怎么开展测试工作的?是如何组织的?
    你认为理想的测试流程是什么样子?
    你是怎样工作的?
    软件测试活动的生命周期是什么?
    请画出软件测试活动的流程图?
    针对缺陷采取怎样管理措施?
    什么是测试评估?测试评估的范围是什么?
    如果能够执行完美的黑盒测试,还需要进行白盒测试吗?为什么?
    测试结束的标准是什么?
    软件验收测试除了alpha,beta测试以外,还有哪一种?
    做测试多久了?
    以前做过哪些项目?
    你们以前测试的流程是怎样的?
    <答:测试计划-测试用例设计-测试执行-测试分析报告>
    用过哪些测试工具?
    为什么选择测试这行?
    <答:它是一个新兴的行业,有发展潜力,而且很锻炼人,需要掌握更多的技能,比做开发要更难>
    为什么值得他们公司雇用?
    如果我雇用你,你能给部门带来什么贡献?
    如何从工作中看出你是个自动自觉的人
    你的工作通常能在时限内完成吗.(我想问一下就是她问这个问题的动机是什么)
    通常你对于别人批评你会有什么样的反应
    如果明知这样做不对,你还会依主管的指过去做吗
    如果你接到一个客户抱怨的电话,你确知无法解决他的问题,你会怎么处理
    你觉得什么样的人最难相处
    为什么值得他们公司雇用?
          帮助公司提高软件质量和测试部门的技术水平
    如果我雇用你,你能给部门带来什么贡献?
          分享我的测试经验和测试技能,提高测试部门技术水平
    如何从工作中看出你是个自动自觉的人
         自动自觉范围太广
          1. 工作成果
          2. 工作质量 
    你的工作通常能在时限内完成吗.(我想问一下就是她问这个问题的动机是什么)
          在有足够的资源和合理的工作量的情况下,完全可以按时完成,并能比一般人做的更好
    通常你对于别人批评你会有什么样的反应
      有错即改,无措勉之
    如果明知这样做不对,你还会依主管的指过去做吗
         在公司内部下级是否有申诉渠道?
    如果你接到一个客户抱怨的电话,你确知无法解决他的问题,你会怎么处理
        为什么抱怨?是怎么样的问题?
         如果是客服问题,提交客服部门解决
        如果是质量问题,分析原因,下一版本改进
    你觉得什么样的人最难相处
         自以为是的人
    什么叫单元测试?
    请就软件测试人员应该具备什么样的基本素质说说你的看法。
    请就如何在开发中进行软件质量控制说说你的看法
     简述软件测试的意义,以及软件测试的分类
    1、功能测试,性能测试,界面测试,安全测试(可以简单点,比如只涉及到COOKIES里的内容),压力测试(商业性质的网站) 等等,B/S软件也要根据其具体功能采用不同的测试策略。
    2、态度、责任心、自信、敏锐的观察力、良好的发散思维
    3、先设计后开发模式,加强单元测试,加强代码走查,有一套完整的白盒测试方法。关键是加强开发人员的质量意识,增进程序员向工程师水平发展。
    4、意义嘛,就自己想吧。软件测试的分类,这个很多人都按各种方法去分。无明确答案给你。
    对测试的理解——基本的测试知识,对测试是否认可? 75。
       3、谈一谈过去自己的工作——了解经历、提供进一步提问的素材,表达能力  
    测试技能
    测试设计的方法并举例说明——测试技术的使用
    测试工具——熟悉程度,能否与当前工作匹配?
    如何做计划?如何跟踪计划?——日常工作能力
    如果开发人员提供的版本不满足测试的条件,如何做?——与开发人员协作的能力
    熟悉unix系统、oracle数据库吗?——是否具备系统知识
    做过开发吗?写过哪些代码?——开发技能
    阅读英语文章,给出理解说明?——部分英语能力
    文档的意义——是否善于思考?(最简单的概念,不同层次的理解)
    假如进入我们公司,对我们哪些方面会有帮助?——讲讲自己的特长
    随便找一件物品,让其测试——测试的实际操作能力
    软件测试的方法有?
    软件测试的过程?
    有一个新的软件,假如你是测试工程师,该如何做?
    软件测试分哪两种方法?分别适合什么情况?
    2。一套完整的测试应该由哪些阶段组成?分别阐述一下各个阶段。
    3。软件测试的类型有那些?分别比较这些不同的测试类型的区别与联系。
    4。测试用例通常包括那些内容?着重阐述编制测试用例的具体做法
    5。在分别测试winform的C/S结构与测试WEB结构的软件是,应该采取什么样的方法分别测试?他们存在什么样的区别与联系?
    6。在测试winform的C/S结构软件时,发现这个软件的运行速度很慢,您会认为是什么原因?您会采取哪些方法去检查这个原因?
    7。描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程
    你在五年内的个人目标和职业目标分别是什么?
      分析这个问题是用来了解你的计划能力的,通过这个问题,面试人同时还可以知道你的目标是否符合企业对你的安排。
      错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁,我认为做太多的个人计划是荒谬可笑的,不是吗?
      评论这种回答属于令人反感的一类。首先,当有人想了解你的目标时,"将来的某个时候"这种通俗说法并不奏效。其次,认为企业很脆弱,领导者更换频繁,这种说法毫无疑问会令人反感,而且也是不合理的。最后,认为做计划可笑,看不起这个问题,而且反问面试人,这些都注定了这样的求职者最终会失败。
      正确回答从现在起的五年之内,我希望能够在一个很好的职位上待几年,而且最好有一次晋升,然后就期待着下一步。不管是向上提升,还是在企业内横向调动,对我个人来说,我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。
      评论这个问题没有回答得过分具体(那样可能会产生漏洞),而且它表明你有雄心,并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望,表明你是一个有灵活性的人。
     问题23 你怎样做出自己的职业选择?
      分析 面试人提出这个问题是为了了解求职者的动机,看看他(她)应聘这份工作是否有什么历史渊源,是否有职业规划,是不是仅仅在漫无目的地申请很多工作。
      错误回答 我一直都想在企业界工作。自孩提时代起,我就梦想自己至少也要成为大企业的副总裁。
      评论 除了难以令人相信之外,这种回答还存在一个问题:它表明求职者会对副总裁以下的职位不感兴趣。
      正确回答 在上大学四年级前的那个夏天,我决定集中精力在某一领域谋求发展。尽管我是学商业的,但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标,想清楚了自己擅长做的事情以及想从工作中得到的东西,最后我得出了一个坚定的结论,那就是这个行业是最适合我的。
      评论 这种回答表明,求职者认真地做过一些计划,缩小了自己的关注点,而且也认准了前进的方向。这种回答还表明,求职者理解个人职业规划的重要性,并且有能力做出认真的个人决策。
    1. 你都用什么测试方法
    2.怎么编写案例
    3.怎么才能够全面的测试到每一个点
    1. 你都用什么测试方法
    针对不同的产品或者系统或者模块,有不同的测试方法。总体而言有白盒测试和黑盒测试。
    2.怎么编写案例
    案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
    3.怎么才能够全面的测试到每一个点
    测试的全面性主要需要在设计测试计划的时候考虑,从测试策略,产品需求等等多个角度考虑从而定义全部的测试点。
    1、谈谈软件测试技术,以及如何提高
    2、谈谈软件测试职业发展,以及个人的打算
    3、谈谈软件测试在企业的地位,也可以结合软件生命周期来谈
    有可能清晰的思路比确切的答案更重要
    在这里,主要说下笔试和面试的问题,希望大家共同参考。
        1,一般公司里实际的软件测试流程是什么样的?你们公司又是怎样的?
        2,软件工程师要具有那些素质?
        3,你会哪些测试工具?怎么操作?
        4,你能不能说下你的3到5年的职业计划(规划)
        5,你觉得你来应聘有那些优势?
    其余的还好说,但就第4个问题,我感到不好说哦!希望大家给个意见
    第一关:首先要自我介绍,自己的性格怎么样,目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看?还有对于软件测试有什么自己的想法。为什么会想到要做这行(因为我的简历上的工作经历没有关于测试方面的)。哦,还有期望薪资。
    第二关:认为软件测试人员所要具备的基本素质,如果遇到问题会怎样处理,如果得不到研发人员的配合(就是研发说这个不是问题)你又会怎么处理?然后就是一些基本概念,比如软件测试的流程有哪些?如果我上任了,首先会怎么开始自己的工作计划。
    (前两关通过了后面这个就好过多了)
    第三关:像我介绍了一下公司的情况,告诉我主要针对什么内容的测试,会不会使用数据库。告诉我大概要做哪些内容,详细的可以上岗以后慢慢熟悉。
    大概就这么多了,这对没有经过这一关的不知道有没有帮助,仅供参考吧
    我觉得就像李波说的,关键是要给对方留下好印象:)
    面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问,这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会:
    你可以问:
    1.        贵公司近期和远期的发展目标是什么?
    2.        贵公司的主要竞争对手有哪些?
    3.        贵公司有多少开发人员有多少测试人员?
    4.        贵公司又进一步扩充测试人员的计划吗?
    5.        如果我有幸能进入贵公司的话,我有怎么样的发展?
    6.        测试人员的沟通能力很重要,贵公司有规范的沟通渠道吗?
    7.        请介绍一下贵公司的福利情况。
    8.        请问我什么时候能知道结果?

  • 软件测试之常用的功能测试方法解析

    2007-05-17 10:43:19Top 1 Digest 1

    功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。常用的测试方法如下:

      1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。

      2. 相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。

      3. 检查按钮的功能是否正确:如update, cancel, delete, save等功能是否正确。

      4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

      5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

      6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

      7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

      8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

      9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

      10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

      11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

      12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

      13. 重复提交表单:一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。

      14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

      15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

    16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

      17. 上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。

      18. 必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*

      19. 快捷键检查:是否支持常用快捷键,如Ctrl+C Ctrl+V Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。

      20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。

  • 软件测试的常识

    2007-05-08 16:33:01Top 1 Digest 1



    软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

    生产软件的最终目的是为了满足客户需求,我们以客户需求作为评判软件质量的标准,认为软件缺陷( Software Bug )的具体含义包括下面几个因素:

    •  
    软件未达到客户需求的功能和性能;

    •  
    软件超出客户需求的范围;

    •  
    软件出现客户需求不能容忍的错误;

    •  
    软件的使用未能符合客户的习惯和工作环境。

    考虑到设计等方面的因素,我们还可以认为软件缺陷还可以包括软件设计不符合规范,未能在特定的条件(资金、范围等)达到最佳等。可惜的是,我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来,认为软件测试仅限于程序提交之后。

    在目前的国内环境下,我们几乎看不到完整准确的客户需求说明书,加以客户的需求时时在变,追求完美的测试变得不太可能。因此作为一个优异的测试人员,追求软件质量的完美固然是我们的宗旨,但是明确软件测试现实与理想的差距,在软件测试中学会取舍和让步,对软件测试是有百益而无一弊的。

    下面是一些软件测试的常识,对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

    •  
    测试是不完全的(测试不完全)

    很显然,由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素,哪怕是一个极其简单的程序,要想穷尽所有逻辑路径,所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子,比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话,从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的,即便某一天我们能够穷尽该程序,只怕我们乃至我们的子孙都早已作古了。为此作为软件测试,我们一般采用等价类和边界值分析等措施来进行实际的软件测试,寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

    •  
    测试具有免疫性(软件缺陷免疫性)

    软件缺陷与病毒一样具有可怕的免疫性,测试人员对其采用的测试越多,其免疫能力就越强,寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的,则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算,软件存在 500 个缺陷时,我们查找一个软件缺陷需要 X 小时,当软件只存在 5 个错误时,我们每查找一个软件缺陷需要 100X 小时。实践证明,实际的测试过程比上面的假设更为苛刻,为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷,因此软件测试应该尽可能的多采用多种途径进行测试。

    •  
    测试是泛型概念(全程测试)

    我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话,需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷,记住软件缺陷具有生育能力。软件测试应该跨越整个软件开发流程。需求验证(自检)和设计验证(自检)也可以算作软件测试(建议称为:需求测试和设计测试)的一种。软件测试应该是一个泛型概念,涵盖整个软件生命周期,这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估(信息系统审计和软件工程监理),即测试本身也应当被测试,从而确保测试自身的可靠性和高效性。否则自身不正,难以服人。

    另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件,软件测试是提高产品质量最直接、最快捷的手段,但决不是一个根本手段。

    •  
    80-20 原则

    80%
    的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们,如果你想使软件测试有效地话,记住常常光临其高危多发地段。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

    80-20
    原则的另外一种情况是,我们在系统分析、系统设计、系统实现阶段的复审,测试工作中能够发现和避免 80% 的软件缺陷,此后的系统测试能够帮助我们找出剩余缺陷中的 80% ,最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷,却无法保证能够发现所有的软件缺陷。

    80-20 原则还能反映到软件测试的自动化方面上来,实践证明 80% 的软件缺陷可以借助人工测试而发现, 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分,因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

    •  
    为效益而测试

    为什么我们要实施软件测试,是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来,在软件测试中我们应该尽量地保持软件测试简单性,切勿将软件测试过度复杂化,拿物理学家爱因斯坦的话说就是: Keep it simple but not too simple

    • 
     缺陷的必然性

    软件测试中,由于错误的关联性,并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的,一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中,我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围,选择一个折中的方案或是从非软件的因素(比如提升硬件性能)考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

    • 
     软件测试必须有预期结果

    没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果,我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般,不少测试人员常常凭借自身的感觉去评判软件缺陷的发生,其结果往往是把似是而非的东西作为正确的结果来判断,因此常常出现误测的现象。

    •  
    软件测试的意义 - 事后分析

    软件测试的目的单单是发现缺陷这么简单吗?如果是的话,我敢保证,类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好,不知道历史的人必然会重蹈覆辙。没有对软件测试结果进行认真的分析,我们就无法了解缺陷发生的原因和应对措施,结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜,目前大多测试团队都没有意识到这一点,测试报告中缺乏测试结果分析这一环节。

    结论:

    软件测试是一个需要自觉的过程,作为一个测试人员,遇事沉着,把持尺度,从根本上应对软件测试有着正确的认识,希望本文对读者对软件测试的认识有所帮助。

  • 【转】移动App Bug——崩溃之测试用例设计

    2014-05-06 16:28:04

    我们的日常生活中对移动设备越来越多的使用意味着移动App测试这个主题已成为需要考虑的一个无法避免的问题。根据最近的调查研究,用户难以容忍有bug的移动App。

      移动App Bug的影响是用户体验差、App的商店评级下降、用户换用竞争对手的App,声誉和信誉损失、最后销售量减少,如果它是一个付费App的话。

      移动App测试与传统台式机测试相比有一定的复杂性。这些复杂性可以被分类为:
      环境(大量的设备,各种移动OSs,适应频繁OSs变化) 。
      设备(触摸式和非触摸式设备,有限的内存容量,电池耗电量) 。
      网络(不同的网络和运营商,在不好或无网络的情况下的App行为,离线支持) 。
      可用性(方向,触摸,多触摸,缩放,分页和导航的局限性,各种干扰,如来电,来电短信,闹钟,和低电量警报) 。
      所有这些手机专有的复杂性需要新的针对移动App测试的测试用例设计方案。

      最常见的移动App Bug

      为了确定最常见的移动App Bug,进行了一次研究,其结果发表在国际测试会议上[ 1 ] 。
      为了这个目的,准备了一次在线调查思考参与者的移动测试经验并发表在移动App开发和测试相关的专业社会团体内。
      有针对性的参加本次调查的主要有移动App测试人员和开发人员。结合几个结果,最常见的移动App Bug在对调查结果进行统计分析后确定。
      根据调查的结果,移动App崩溃是最常见的移动App Bug ,这是预料中的结果,因为很容易发现一个移动App崩溃。Android OS上一个写着“强制关闭错误”的弹出窗口跳上屏幕;当发生崩溃时,iOS中App屏幕突然消失消失。最坏的情况下,App崩溃可能会导致系统故障,操作 系统崩溃。

      移动App崩溃原因
      为什么移动App经常崩溃?App崩溃有几个原因:从平台或环境到开发问题。
      一些崩溃原因(排名不分先后) :
      设备碎片化:由于设备极具多样性,App在不同的设备上可能有表现不同。
      带宽限制:带宽不佳的网络对App所需的快速响应时间可能不够。
      网络的变化:不同网络间的切换可能会影响App的稳定性。
      内存管理:可用内存过低,或非授权的内存位置的使用可能会导致App失败。
      用户过多:连接数量过多可能会导致App崩溃。
      代码错误:没有经过测试的新功能,可能会导致App在生产环境中失败。
      第三方服务:广告或弹出屏幕可能会导致App崩溃。

      移动App崩溃的测试用例设计
      测试用例是移动测试最重要部分之一。
      准备和执行预先定义的针对移动App崩溃的测试用例将简化和加速移动App崩溃的测试。
      一些通用的触发移动App崩溃的测试场景,如下:
      1 验证在有不同的屏幕分辨率,操作系统和运营商的多个设备上的App行为。
      2 用新发布的操作系统版本验证App的行为。
      3 验证在如隧道,电梯等网络质量突然改变的环境中的App行为。
      4 通过手动网络从蜂窝更改到Wi-Fi ,或反过来,验证App行为。
      5 验证在没有网络的环境中的App行为。
      6 验证来电/短信和设备特定的警报(如警报和通知)时的App行为。
      7 通过改变设备的方向,以不同的视图模式,验证App行为。
      8 验证设备内存不足时的App行为。
      9 通过用测试工具施加载荷验证App行为。
      10 用不同的支持语言验证App行为。
      显然,还会有更多的导致App崩溃的App特定场景。

      结论

      在这项研究中,展示了针对移动App崩溃的通用测试案例。
      如果移动测试团队在他们的测试场景中准备并执行这些测试用例,那么早在开发周期就可以找到崩溃相关的Bug。 然后,开发团队将阐明崩溃原因,并找出一个解决所有Bug的通用方法。最后,App质量和用户满意度就会增加。

  • 企业面试经常问到的问题

    2014-04-25 17:41:39

    1、请你自我介绍一下自己好吗?
    回答提示:一般人回答这个问题过于平常,只说姓名、年龄、爱好、工作经验,这些在简历上都有。其实,企业最希望知道的是求职者能否胜任工作,包括:最强的技能、最深入研究的知识领域、个性中最积极的部分、做过的最成功的事,主要的成就等,这些都可以和学习无关,也可以和学习有关,但要突出积极的个性和做事的能力,说得合情合理企业才会相信。企业很重视一个人的礼貌,求职者要尊重考官,在回答每个问题之后都说一句“谢谢”,企业喜欢有礼貌的求职者。
    2、你觉得你个性上最大的优点是什么?
    回答提示:沉着冷静、条理清楚、立场坚定、顽强向上、乐于助人和关心他人、适应能力和幽默感、乐观和友爱。我在北大青鸟经过一到两年的培训及项目实战,加上实习工作,使我适合这份工作。
    3、说说你最大的缺点?
    回答提示:这个问题企业问的概率很大,通常不希望听到直接回答的缺点是什么等,如果求职者说自己小心眼、爱忌妒人、非常懒、脾气大、工作效率低,企业肯定不会录用你。绝对不要自作聪明地回答“我最大的缺点是过于追求完美”,有的人以为这样回答会显得自己比较出色,但事实上,他已经岌岌可危了。企业喜欢求职者从自己的优点说起,中间加一些小缺点,最后再把问题转回到优点上,突出优点的部分,企业喜欢聪明的求职者。
    4、你对薪资的要求?
    回答提示:如果你对薪酬的要求太低,那显然贬低自己的能力;如果你对薪酬的要求太高,那又会显得你分量过重,公司受用不起。一些雇主通常都事先对求聘的职位定下开支预算,因而他们第一次提出的价钱往往是他们所能给予的最高价钱,他们问你只不过想证实一下这笔钱是否足以引起你对该工作的兴趣。
    回答样本一:我对工资没有硬性要求,我相信贵公司在处理我的问题上会友善合理。我注重的是找对工作机会,所以只要条件公平,我则不会计较太多。
    回答样本二:我受过系统的软件编程的训练,不需要进行大量的培训,而且我本人也对编程特别感兴趣。因此,我希望公司能根据我的情况和市场标准的水平,给我合理的薪水。
    回答样本三:如果你必须自己说出具体数目,请不要说一个宽泛的范围,那样你将只能得到最低限度的数字。最好给出一个具体的数字,这样表明你已经对当今的人才市场作了调查,知道像自己这样学历的雇员有什么样的价值。
    5、你对加班的看法?
    回答提示:实际上好多公司问这个问题,并不证明一定要加班,只是想测试你是否愿意为公司奉献。
    回答样本:如果工作需要我会义不容辞加班,我现在单身,没有任何家庭负担,可以全身心的投入工作。但同时我也会提高工作效率,减少不必要的加班。
    6、如果通过这次面试我们录用了你,但工作一段时间却发现你根本不适合这个职位,你怎么办?
    回答提示:一段时间发现工作不适合我,有两种情况:①如果你确实热爱这个职业,那你就要不断学习,虚心向领导和同事学习业务知识和处事经验,了解这个职业的精神内涵和职业要求,力争减少差距;②你觉得这个职业可有可无,那还是趁早换个职业,去发现适合你的,你热爱的职业,那样你的发展前途也会大点,对单位和个人都有好处。
    7、谈谈你对跳槽的看法?
    回答提示:①正常的“跳槽”能促进人才合理流动,应该支持。②频繁的跳槽对单位和个人双方都不利,应该反对。
    8、工作中难以和同事、上司相处,你该怎么办?
    回答提示:①我会服从领导的指挥,配合同事的工作。②我会从自身找原因,仔细分析是不是自己工作做得不好让领导不满意,同事看不惯。还要看看是不是为人处世方面做得不好,如果是这样的话我会努力改正。③如果我找不到原因,我会找机会跟他们沟通,请他们指出我的不足,有问题就及时改正。④作为优秀的员工,应该时刻以大局为重,即使在一段时间内,领导和同事对我不理解,我也会做好本职工作,虚心向他们学习,我相信,他们会看见我在努力,总有一天会对我微笑的。
    9、你对于我们公司了解多少?
    回答提示:在去公司面试前上网查一下该公司主营业务。如回答:贵公司有意改变策略,加强与国外大厂的OEM合作,自有品牌的部分则透过海外经销商。
    10、最能概括你自己的三个词是什么?
    回答提示:我经常用的三个词是:适应能力强,有责任心和做事有始终,结合具体例子向主考官解释,
    11、你的业余爱好是什么?
    回答提示:找一些富于团体合作精神的,这里有一个真实的故事:有人被否决掉,因为他的爱好是深海潜水。主考官说:因为这是一项单人活动,我不敢肯定他能否适应团体工作。
    12、作为被面试者给我打一下分?
    回答提示:试着列出四个优点和一个非常非常非常小的缺点(可以抱怨一下设施,没有明确责任人的缺点是不会有人介意的)。
    13、你为什么要离开原来的公司?
    回答提示:①回答这个问题时一定要小心,就算在前一个工作受到再大的委屈,对公司有多少的怨言,都千万不要表现出来,尤其要避免对公司本身主管的批评,避免面试官的负面情绪及印象。建议此时最好的回答方式是将问题归咎在自己身上,例如觉得工作没有学习发展的空间,自己想在面试工作的相关产业中多加学习,或是前一份工作与自己的生涯规划不合等等,回答的答案最好是积极正面的。②我希望能获得一份更好的工作,如果机会来临,我会抓住。我觉得目前的工作,已经达到顶峰,即没有升迁机会。
    14、你欣赏哪种性格的人?
    回答提示:诚实、不死板而且容易相处的人、有“实际行动”的人。
    15、你通常如何对待别人的批评?
    回答提示:①沈默是金,不必说什么,否则情况更糟,不过我会接受建设性的批评。②我会等大家冷静下来再讨论。
    16、怎样对待自己的失败?
    回答提示:我们大家生来都不是十全十美的,我相信我有第二个机会改正我的错误。
    17、你为什么愿意到我们公司来工作?
    回答提示:对于这个问题,你要格外小心,如果你已经对该单位作了研究,你可以回答一些详细的原因,像“公司本身的高技术开发环境很吸引我。”、“我同公司出生在同样的时代,我希望能够进入一家与我共同成长的公司。”、“你们公司一直都稳定发展,在近几年来在市场上很有竞争力。”、“我认为贵公司能够给我提供一个与众不同的发展道路。”这都显示出你已经做了一些调查,也说明你对自己的未来有了较为具体的远景规划。
    18、对这项工作,你有哪些可预见的困难?
    回答提示:①不宜直接说出具体的困难,否则可能令对方怀疑应聘者不行。②可以尝试迂回战术,说出应聘者对困难所持有的态度——工作中出现一些困难是正常的,也是难免的,但是只要有坚忍不拔的毅力、良好的合作精神以及事前周密而充分的准备,任何困难都是可以克服。
    19、如果录用了你,你将怎样开展工作?
    回答提示: ①如果应聘者对于应聘的职位缺乏足够的了解,最好不要直接说出自己开展工作的具体办法。②可以尝试采用迂回战术来回答,如“首先听取领导的指示和要求,然后就有关情况进行了解和熟悉,接下来制定一份近期的工作计划并报领导批准,最后根据计划开展工作。”。
    分析:这个问题的主要目的也是了解应聘者的工作能力和计划性、条理性,而且重点想要知道细节。如果向思路中所讲的迂回战术,面试官会认为回避问题,如果引导了几次仍然是回避的话,此人绝对不会录用了。
    20、你希望与什么样的上级共事?
    回答提示:①通过应聘者对上级的“希望”可以判断出应聘者对自我要求的意识,这既上一个陷阱,又是一次机会。②最好回避对上级具体的希望,多谈对自己的要求。③如“做为刚步入社会的新人,我应该多要求自己尽快熟悉环境、适应环境,而不应该对环境提出什么要求,只要能发挥我的专长就可以了。
    分析:这个问题比较好的回答是,希望我的上级能够在工作中对我多指导,对我工作中的错误能够立即指出。总之,从上级指导这个方面谈,不会有大的纰漏。
    21、与上级意见不一时,你将怎么办?
    回答提示:①一般可以这样回答“我会给上级以必要的解释和提醒,在这种情况下,我会服从上级的意见。”②如果面试你的是总经理,而你所应聘的职位另有一位经理,且这位经理当时不在场,可以这样回答:“对于非原则性问题,我会服从上级的意见,对于涉及公司利益的重大问题,我希望能向更高层领导反映。”
    分析:这个问题的标准答案是思路①,如果用②的回答,必死无疑。你没有摸清楚改公司的内部情况,先想打小报告,这样的人没有人敢要。
    22、为什么选择我们公司?
    回答提示:曾经在报章杂志看过关于贵公司的报道,与自己所追求的理念有志一同。而贵公司在业界的成绩也是有目共睹的,而且对员工的教育训练、升迁等也都很有制度。
    分析:去面试前先做功课,了解一下该公司的背景,让对方觉得你真的很有心想得到这份工作,而不只是探探路。
    23、谈谈如何适应办公室工作的新环境?
    回答提示①办公室里每个人有各自的岗位与职责,不得擅离岗位。②根据领导指示和工作安排,制定工作计划,提前预备,并按计划完成。③多请示并及时汇报,遇到不明白的要虚心请教。④抓间隙时间,多学习,努力提高自己的政治素质和业务水平。
    24、除了本公司外,还应聘了哪些公司?
    回答提示:很奇怪,这是相当多公司会问的问题,其用意是要概略知道应徵者的求职志向,所以这并非绝对是负面答案,就算不便说出公司名称,也应回答“销售同种产品的公司”,如果应聘的其他公司是不同业界,容易让人产生无法信任的感觉。
    25、你还有什么问题要问吗?
    回答提示:企业的这个问题看上去可有可无,其实很关键,企业不喜欢说“没问题”的人,因为其很注重员工的个性和创新能力。企业不喜欢求职者问个人福利之类的问题,如果有人这样问:贵公司对新入公司的员工有没有什么培训项目,我可以参加吗?或者说贵公司的晋升机制是什么样的?企业将很欢迎,因为体现出你对学习的热情和对公司的忠诚度以及你的上进心。
    26、如果你被录用,何时可以到职?
    回答提示:大多数企业会关心就职时间,最好是回答“如果被录用的话,到职日可按公司规定上班”,但如果还未辞去上一个工作、上班时间又太近,似乎有些强人所难,因为交接至少要一个月的时间,应进一步说明原因,录取公司应该会通融的。
  • 测试的七个原则

    2014-04-22 16:06:49

    M3zfF#p31.测试是为了显示缺陷的存在,而不是证明系统不存在缺陷51Testing软件测试网't%i,E0^_&^%zk;k

    (s.\|y$Y02.穷尽测试是不可能实现的

    R#i UU.J%b] ep051Testing软件测试网~d l!~lM$\i2nZf}

    3.尽早开始测试

    gPo I9q#\-@0

    -uXo(uc ^I E04.缺陷集群性,即发现缺陷越多的部分,存在缺陷的可能性越大

    o9Ti L P^f051Testing软件测试网$Lj cS r4s7\`

    5.杀虫剂现象,即使用同样的测试用例一遍一遍的进行测试,将不能发现新的缺陷,因此测试到一定程度后需要更新测试用例51Testing软件测试网G7l^ kb+do

    x/K.D-@E eQabN06.测试活动依赖于测试对象,对不同的系统有不同的测试51Testing软件测试网#_:uH k!C#m/Pw

    a8^r/ZdZa[U07.关于零缺陷的谬误,即如果系统不可用或不能满足用户的需求,即使不存在缺陷也是没有意义的

  • 祝自己好运

    2014-04-16 10:09:40

    今天要去三星SDS面试,所以来这里复习复习最基础的东西。
  • linux基本命令(培训新人而整理)

    2007-07-04 17:48:19

    linux基本命令


    --------------------------------------------------------------------------------
    ls
    这个命令就相当于dos下的dir命令一样

    ls -a

    Linux上的文件以.开头的文件被系统视为隐藏文件,仅用ls命令是看不到他们的,而用ls -a除了显示 一般文件名外,
    连隐藏文件也会显示出来。

    ls -l(这个参数是字母L的小写,不是数字1,这个命令最常用)

    这个命令可以使用长格式显示文件内容,如果需要察看更详细的文件资料,就要用到ls -l这个指令。

    ls –F(注意,是大写的F)

    使用这个参数表示在文件的后面多添加表示文件类型的符号,例如*表示可执行,/表示目录,@表示连结文件

    cd
    这个命令是用来进出目录的,它的使用方法和在dos下没什么两样

    mkdir、rmdir
    mkdir命令用来建立新的目录,rmdir用来删除以建立的目录,这两个指令的功能同dos下的md,rd功能和用法都是基本一样的。

    cp
    这个命令相当于dos下面的copy命令,具体用法是:cp –r 源文件(source) 目的文件(target)
    参数r是指连同元文件中的子目录一同拷贝。

    rm
    这个命令是用来删除文件的,和dos下面的rm(删除一个空目录)是有区别的,大家千万要注意。rm命令常用的参数有三个: -i,-r,-f。
    比如我现在要删除一个名字为text的一个文件:rm –i 123
    系统会询问我们:“rm:remove ‘123’?y”,敲了回车以后,这个文件才会真的被删除。
    rm –r 目录名:这个操作可以连同这个目录下面的子目录都删除,功能上和rmdir相似。
    rm –f 文件名(目录名):这个操作可以进行强制删除。
    rm -rf 文件名(目录名):这个操作可以进行强制删除带有子目录的目录,一般轻易不要操作该命令。

    mv
    这个命令的功能是移动目录或文件,引申的功能是给目录或文件重命名。它的用法同dos下面的move基本相同。当使用该命令来移动目录时,他会连同该目录下面的子目录也一同移走。另外因为linux下面没有rename的命令,所以如果你想给
    一个文件或目录重命名时可以用以下方法:mv 原文件(目录)名 新的文件(目录)名。

    du,df
    du命令可以显示目前的目录所占的磁盘空间,df命令可以显示目前磁盘剩余的磁盘空间。

    cat
    这个命令是linux中非常重要的一个命令,它的功能是显示或连结一般的ascii文本文件。

    more,less
    这是两个显示一般文本文件的指令。如果一个文本文件太长了超过一个屏幕的画面,用cat来看实在是不理想,就可以试试more和less两个指令。

    clear
    这个命令是用来清除屏幕的,它不需要任何参数,和dos下面的clr具有相同的功能。

    pwd
    这个命令的作用是显示用户当前的工作路径。

    man
    Man实际上就是察看指令用法的help。

    logout
    这是退出系统的命令。

  • 测试管理最佳实践

    2007-06-20 17:04:19

    导言
            软件质量一个很重要的部分就是测试和验证软件有效性的流程。这篇文章的目的是介绍相关的概念,并提供测试管理领域常用的最佳实践。测试管理是组织和控制测试工作所需的流程和工件的实践。这篇文章探讨的是IBM® Rational® ClearQuest®, IBM® Rational® ClearCase®以及IBM® Rational® Requisite Pro®如何提高测试水平。
    导言

    目的

            很少人会反对提高软件开发质量的需求。使用软件的技术人员已经开始预估各种各样的故障和缺点,特别是在个人计算机世界里,我们认为频繁出现问题是完全正常的并且在意料之中。尽管如此,随着软件开发日趋成熟,我们开始对如何在质量方面作出必要改进有了进一步的理解。这篇文章的目的是介绍相关概念,并提供测试管理领域常用的最佳实践。

    什么是测试管理?

            软件质量一个很重要的部分就是测试和验证软件有效性的流程。测试管理是组织和控制测试工作所需的流程和工件的实践。用于测试管理的传统工具包括:

                       笔和纸
                       字处理程序
                       电子数据表

            更大的测试工作可以使用自己开发的软件测试管理解决方案,通常建立在电子数据表或数据库或者像 IBM® Rational® ClearQuest® Test Manager 或者 Mercury TestDirector 这样的商业测试管理应用软件的基础之上。

            测试管理的整体目标是允许团队在整个软件开发工作里计划、开发、执行并评估所有的测试活动。这包括调整测试工作中包含的所有工作,跟踪测试资产中的依赖关系和相互关联,并且最重要的是对质量目标进行定义、测量和跟踪。


    测试管理的各个方面

            测试管理可以被分成几个不同的阶段:组织、计划、创作、执行以及报告。这些在下面有更详细的描述。

            测试工件和资源组织是测试管理中显然必不可少的部分。这需要组织和维持测试项目的详细目录,以及用来执行测试的各类事物。这表现了团队如何跟踪测试资产中的依赖关系和相互关联。需要管理的测试资产中最普遍的类型是:

                       测试脚本
                       测试数据
                       测试软件
                       测试硬件

            测试计划是回答为什么测试、测试什么、在哪里测试和什么时间测试这些问题的全部任务设置。创建一个特定测试的原因被称作一个测试激发因素(例如,必须确定一个特定的必要条件)。为了一个项目需要被测试的内容被分成许多的测试用例。在哪里测试通过决定和记录所需的软件和硬件配置来回答。什么时间测试通过跟踪测试的迭代(或者循环,或者时间周期)来解决。

            测试创作是获得完成给定测试所需特定步骤的过程。它回答了如何测试的问题。这里是一些稍微抽象的测试用例被分成更详细的测试步骤的地方,这些步骤将变成测试脚本(要么是人工生成,要么自动生成)。

            测试执行通过将测试脚本的顺序集合成测试套件来运行这些测试。这是对如何测试这一问题的后续回答(更为准确地说,是如何管理这些测试)。

            测试报告是指如何对测试工作的不同结果进行分析和沟通。这用来决定项目测试的当前状态和应用软件或系统的质量的整体水平。

            测试工作将产生大量的信息。在这些信息里,可以提取为项目定义、度量及追踪质量目标的方法。不管使用什么沟通机制,这些质量度量方法需要被传递给其他项目作为测试度量的基础。

            测试产生的一个非常普通的数据类型是缺陷,它通常是质量度量方法的来源。缺陷不是静态的,而是随着时间在变化。此外,多种缺陷总是互相关联的。有效的缺陷跟踪对测试和开发团队来说都是十分重要的。

    测试管理中的其他因素

            除了软件和硬件测试工件和资源以外,必须管理 测试团队。测试管理必须调动致力于团队工作的所有团队成员的积极性。这需要对测试人员和工件控制 用户安全和进入许可。对于那些跨越一个或更多场所或团队的项目(这将迅速成为规范)来说,这也包括组织场所和团队协调。

            一个项目的特定测试流程对于测试管理来说意义十分明显。对于一个迭代的项目,测试管理将必须提供基础并重复地指导计划、执行和测试评估。而后,测试策略也将必须遵循测试管理框架。

    相关的软件开发规程

            虽然软件开发中所有的过程都与测试相关联,有几个与测试的关系尤为重要:

                        需求管理
                        变更管理
                        配置管理

            需求管理是大多数测试工作的先驱,提供了大量的测试动机和确认需求。一个项目特定的需求管理流程对测试管理流程有重要影响。这种关系类似于一场接力赛,第一个跑的人代表着需求管理,下一个接受接力棒的人代表测试管理。IBM® Rational® RequisitePro®是发现、记录、组织和跟踪需求说明的工具。更多的信息可以在 IBM® developerWorks® Requisitepro 资源页面上找到。

            变更管理影响软件开发的全部过程,但是被跟踪的与测试工作最相关的变更是缺陷。缺陷是测试与开发之间最常见的主要通信渠道。从缺陷得出的计算和方法也经常被用作质量度量方法。ClearQuest 是一种贯穿整个软件开发周期中用于管理诸多类型的变更和活动的强大的、高可配置的工具。更多的信息可以在 IBM® developerWorks® ClearQuest 资源页面上找到。

            配置管理对于测试管理来说很重要,因为在什么时候对哪一个要测试的版本进行跟踪对测试来说至关紧要。配置管理为测试执行控制着由测试管理跟踪的工作版本和环境。IBM® Rational® ClearCase® 是主要的配置管理工具。更多的信息可以在 IBM® developerWorks® Clearcase 资源页面上找到。


    测试管理的挑战

            总结测试管理目标的一个方法是回答下面的问题:

                      为什么我应该测试?
                      我应该测试什么?
                      我在哪里测试? 
                      我什么时候测试?
                      我如何指导测试?

            从高层次的角度来看,这可能十分简单,但是在典型的软件开发中总会出现许多障碍。下面详细描述这些挑战。

    没有足够的时间来测试

            除了某些专门的或者任务十分重要的应用程序外,很少的软件项目在开发周期里拥有充足的时间完成高水平的质量度量。通常情况是,软件工程里本来就很短的“测试周期”总是不可避免地会被耽搁。即使是最好的项目也很有可能在测试工作上面临时间限制。在测试管理中这种障碍的影响是不断变换优先级,不断转换工作以及为测试结果和质量检测方法简化数据。

    没有足够的资源来测试

            除了缺少时间外,通常在取得执行必要的测试所需的合适资源方面也面临困难。资源可能被其他工作或项目分享。虽然测试的硬件资源会带来延迟和困难,但是人力资源的缺乏可能更加难以解决。在测试管理中这种障碍的影响和时间缺乏造成的影响大致相同。

    测试团队并不是总在一个地方

            这段时期更经常的情况是测试资源可能可以获得,但是它们不在同一个地方。在各地区协调人力以降低成本已成为家常便饭,但是这造成相当多的技术障碍。在另一区域的团队如何共享工件并保持协同合作,并不会造成延迟和影响整个团队的和谐?一个项目如何能将区域分布式开发的效率发挥到极至呢?

    需求方面的难题

            虽然有许多的测试策略,但是确认需求是需要完成的最主要的、优先级最高的测试工作。做到这一点需要完整的、明确的和可测试的需求。不够完美的需求管理会导致测试工作中更大的问题。使用像 RequisitePro 这样的工具可以帮助极大地提高需求管理并促进有效需求的开发。

            对于有效的测试管理来说,必须有对于最新系统变更和业务需求的无缝接口。这种接口必须不只是针对需求的描述,也要针对优先级、状态和其他属性。此外,这需要开发需求说明的团队和执行测试的团队之间最大限度的协调分工和沟通。这种沟通必须在确保质量的所有方面进行。

    与开发保持同步

            软件质量所需的另一种团队协作存在与测试人员与开发人员之间的。除了关键缺陷之外,软件开发中总有一个惯例,那就是测试团队的工作只有测试人员关注。尽管如此,对于每一个人,特别是对开发人员来说了解当前的质量水平以及哪些已经被测试、哪些还没有被测试是十分重要的。

            为了有效地使用他们的宝贵时间,测试团队必须跟上不断变化的代码、工作版本和环境。测试管理必须精确识别要测试的工作版本和测试的合适的环境。测试错误的工作版本(或功能)会导致时间的浪费,并严重地影响项目进度。测试人员必须也了解什么缺陷是已知的,不需要重新测试的以及哪些是需要确定的。而后测试人员必须将已发现的缺陷以及促进解决方案的充分信息提供给开发人员。

    报告正确信息

            如果能够为项目传达测试状态和一些质量评定标准,测试工作只是有用的。得出报告十分简单,但是提供恰当的信息(在合适的时间,为合适的人)是更加由意义的,主要有以下的原因:

            如果只有非常少的信息,那么除了对测试团队来说减少了感知缺陷的价值外,项目涉众将不能充分了解影响质量的问题。
            如果有过多的信息,那么主要信息的意义和影响就变得模糊。
            在如何将信息与不同地方的不同角色分享上总是有技术障碍。
            报告结果的另一个需要考虑的事项是如何安排信息以及以采用什么形式(也就是说,信息是基于工具的、基于浏览器的还是基于文件的形式)。如果有技术上或者其他限制报告的安排或形式上的约束,项目涉众对于测试和质量信息的了解将被减少。数据应该以一种清晰有逻辑的设计方式呈现出来,表示适当的意义,而不是以受局限的工具或技术的方式。因此对于项目管理来说在提供宽泛的报告格式方面考虑适应性和接受力的需要是十分重要的。

    什么是质量度量?

            测试团队的一个主要目标是评估并决定质量,但是如何准确地度量质量呢?有许多的方法可以实现,而且根据系统或应用软件的类型和开发项目的特殊性分为很多不同的种类。为了避免曲解,任何一个质量度量方法都是需要清晰明确的。更重要的是,测试方法必须可以获取和保存,否则它们可能不值得花费成本或者可能是不完整或者不准确的。


    测试管理的建议

            下面是可以提高软件测试管理的一般建议。

    尽早开始测试管理活动

            虽然这一点看起来像最显而易见的建议,但是很少软件项目真正地应用这一观念。在早期开始确定测试资源很容易而且很常见,但是许多测试分析(如识别关键的、优先的测试用例)可以而且应该尽快开始。一旦用例被充分开发产生事件流,就可以得到测试程序。如果一个项目没有使用用例需求,那么仍可以从确认初始需求说明中得到测试。尽快开发测试能帮助减轻未来不可避免的时间限制。

    迭代化测试

            软件测试应该是一个反复的过程,在整个项目周期的早期生成有价值的测试工件和工作。这是遵循尽早开始测试流程的首要建议:一个迭代的测试流程应该很早就关注测试管理。测试管理通过组织迭代的各类工件和资源来指导这一点。这个基于风险的方法有助于确保以最有效的方式处理项目时间线里可能出现的变更、延迟和其他一些不可预见的障碍。

    重用测试工件

            在一个项目或多个项目里重用测试工件能够极大地提高测试团队的有效性。这样可以极大地缓解时间和资源有限造成的压力。可以重用的工件不仅包括自动操作测试对象,还包括测试程序和其他的计划信息。为了有效地重用工件,测试管理必须在组织和描述给定项目的与测试相关的各种信息方面做得很好。在创建工件时,重用总是需要一些预先计划,而且这一原则通常可以应用于测试管理。

    使用基于需求的测试

    测试可以被分成两种常用的方法:

                          确认事情按照计划进行
                          尽力找出什么使得事情停止下来

            虽然后面的探索性测试对于发现导致错误的难以预测的场景或情形来说非常重要,但是确认基本的需求可能是测试团队执行的最重要的评估。

            基于需求的测试是确认一个应用软件或系统的主要方式,它既适用于传统需求也适用于用例需求。基于需求的测试往往没有探索性测试那么主观,它也可以带来其他的益处。软件开发团队的其他部分可能质疑或者谴责探索性测试的结果,但是他们不能怀疑直接确认需求的测试。另一个好处是它可以更容易地计算所需的测试工作(与探索性测试相反,它总是受限于可以利用的时间)。

            它也可以提供各类统计数据,他们可能是有用的度量,例如测试覆盖率。测试用例是由需求产生的,并且随着事情变化对其关系的跟踪也更为重要,这是一件复杂的工作,应该通过工具进行处理。RequisitePro 和 ClearQuest 中的测试管理能力提供了满足这一需求的结果方案。

            这一流程的局限性是它信赖于一个好的系统需求和一个十分有效的合理的需求管理计划。从另一方面来说,探索性测试可能更加特殊。它很少依赖软件开发团队的其他部分,这有时会导致测试工作很少被关注在确认需求的重要任务上。虽然较好的测试工作应该将不同的方法集成起来,但是不应该忽视基于需求的测试。

    协调远程测试资源

            为了避免资源不足或者只是为充分利用人员,您应该协调可以运用的任何资源,不管它们在什么地方。这些重要的资源很可能存在于多种区域,通常在不同的地方。这需要仔细有效的协同合作使得各地区的大多数测试人员和其他人参与到测试管理中。为了使之生效可能有相当多的技术挑战,因此需要适当的处理。ClearQuest 的 MultiSite 版本的测试管理能力能够帮助简化区域分布式测试协调的复杂度。

            我应该使用 Web 客户还是自动复制的数据呢?有两种解决方案使得相距较远的参与者能够协同工作。前者简单并且相对容易,但是如果从各地进行访问,仍有网络方面的潜在约束。对于受到人员或者功能限制的远程访问来说,这是一个好的解决方案。但是,对于由许多不同地方的人组成一个测试团队的情况,您需要具有复制到本地服务器上的数据使得他们的运行速度达到最大化。这也意味着您将需要一个简单无缝的方式使得每个地方的数据自动同步。这是 ClearQuest MultiSite 对于测试管理来说十分重要的地方。

    定义并执行灵活的测试流程

            一个好的、可重复的流程能够帮您了解项目的当前状态,并通过预测了解其趋势。尽管如此,不同的项目对测试工作将有不同的特定需要,因此使得工作流程自动化的测试管理流程需要是灵活的并且可以定制的。流程应该是可重复的(为了提供预测),但是更重要的是,它必须允许改进。它必须使得修正十分容易,包括在迭代项目过程中的调整,因此它可以通过改变需要使其达到最优。

            如果不能以任何方式执行,那么定义一个指导团队成员的带有工作流程的过程意义并不大。需要怎样的力度来执行根据不同的企业和项目而有所不同。许多企业的软件项目需要遵循不同的法规,如 SOX 和 HIPPA。有些需要变更审核、项目历史和其他像电子签名等严格的遵守确认。不管您的项目测试管理需要严格地执行流程还是有更多的临时选择,您都需要一个机制来定义和执行某些事情。像 ClearQuest 这样测试管理工具是能够提供测试管理所需的所有能力。

    调整并整合开发的剩余部分

            从传统意义来看,软件测试与开发的其他部分是严格分开的。这样做部分源于保持评估公正和有更多的机会发现开发中可能没有察觉的缺陷的合理需要。这一需要在验收测试中尤为明显,因为在验收测试中最好的测试人员往往对设计和执行因素缺乏判断力。尽管如此,这种特定需要仅仅代表软件测试中的一个方面,不应该对最终要进行的软件质量开发制造障碍。

            软件测试必须与软件开发的其他部分结合起来,特别是像需求管理和变更管理这样的规程。这包括不同的流程角色和活动之间重要协作、重要信息的高级沟通以及支持这一点的集成工具。没有这些协同分工,质量将会由于缺少或误解需求、没有测试代码、没有发现缺陷和缺少关于现行软件质量水平的信息而降低。

    沟通状态

            工作的价值等取决于它被认知的程度,而工作如何被认知取决于传递给涉众的信息。好的测试管理必须提供所有相关信息的完整和正确的报告。在软件开发项目里实时状态、目标的测量方法以及结果应该提供给所有相关的团队成员。

            报告应该不仅仅只是传统意义的静态文件。假定变化是持续的,为了准确地交流信息需要有多种形式的易更新的输出。所有这些会帮助不同的项目角色在随着项目的进展对变化如何做出反应方面做出正确的决策。

            来自不同的软件规程的信息不是完全独立的。这篇文章已经提到了测试管理和其他像需求、变更和配置管理和开发这样的规程之间的重要关系。因此来自测试管理的输出可以很容易地与其他项目数据结合起来是至关重要的。当前的技术使得将所有的项目方法结合成为统一视图成为可能,这样可以确定所有项目的健康状态。工具也使得清楚地展示和评估测试、开发和其他项目工件的关系成为可能。

    关注目标和结果

            为项目确定质量目标并决定如何有效而准确的测量这些目标。测试管理是详细说明目标、用于测量这些目标的方法以及将如何收集这些数据的地方。测试中许多工作可能没有明显的完成标准。定义正在进行的流程和变更的特定输出和测量方法将更详细地说明测试工作的活动和任务。牢记测试的特定目标和测试方法不仅有助于跟踪状态和结果,还能避免最终将所需报告混在一起。

            在一个单一的、公共的知识库或数据库储存测试管理的结果以确保更加容易地对他们进行分析或使用。这也促进了工件(包括工作)的版本控制,避免出现过时或无效信息的问题。这一切将有助于项目成员了解流程并在测试工作的基础上做出决策。

    通过自动化来节约时间

            测试管理的内容有很多,而且许多工作非常耗时。为了节约时间,可以使用工具让许多工作自动化,或者至少半自动化。虽然像字处理程序和电子数据表这样的简单的工具提供了很大的灵活性,但是专门用于测试的自动化工具更加有效,更加有助于节约时间。通过自动化收益极大的工作包括:

                           跟踪需求测试和其他测试激发因素的关系
                           组织和重用测试用例
                           记录和组织测试配置 
                           计划和协调各种工作版本和应用软件的测试执行
                           计算测试覆盖率
                           各种各样的报告工作 
                           在测试管理中对适当工作的使用工具以使其自动化将极大地提高其价值和收益。
     

     

    总结

            提高软件质量的一个重要步骤是超越旧的和基于文档的方法,并促进测试管理实践。测试管理包含各种功能,包括计划、创作、执行和报告测试,以及如何使测试并与软件开发工作的其他部分结合起来。对于测试管理来说有许多令人生畏而且不可避免的挑战,如缺乏时间和资源、测试团队分布在相距较远的地方、将测试与需求和开发相结合的问题以及报告正确的信息。

            好消息是有大量的最佳实践可以有助于应对这些挑战。尽早地并重复地进行测试活动、把重点放在目标和结果上以及协调并整合开发的其他部分,将使得测试工作不会成为对软件的事后弥补工作。充分地重用测试工件、协调距离较远的测试资源、定义并执行一个灵活的测试过程以及自动化都有助于克服资源的局限。

            一个可以实现这些实践的工具是 ClearQuest 中的测试管理功能。它直接满足了许多特定的技术需要,例如:通过 ClearQuest MultiSite 与远方团队一起工作。它也为创建满足任何项目或组织需要的正确测试管理解决方案提供了一个灵活的框架。

  • cvs服务器端配置(笔记整理)2007.6.20

    2007-06-20 16:36:35

    先查看Linux服务器操作系统上是否安装了CVS
    [root@localhost /]# rpm -qa|grep cvs
    如果没有安装你可以在Redhat 第2张光盘上找到,另外你也可以在网上下载到最新的rpm包。很容易找,其实不存在什么linux版本
     
    建立cvs用户组
    [root@localhost home]# groupadd cvs

    建立cvs组的cvsroot用户和所属的目录
    [root@localhost home]# useradd -g cvs -G cvs –d /cvsroot cvsroot

    为cvsroot用户添加密码
    [root@localhost home]# passwd cvsroot

    改变 /cvsroot/ 的目录属性:
    [root@localhost home]# chmod –R 770 /cvsroot

    改变用户登陆身份
    [root@localhost home]# su cvsroot

    以下开始正式建立项目
    [root@localhost /]# cd /home/cvsroot/egov/
    [root@localhost egov]# su cvsroot
    [cvsroot@localhost ~]$ mkdir projectsxy
    [cvsroot@localhost ~]$ ls -l

    ...
    drwxrwx---  4 cvsroot cvs 4096  6月 19 14:00 OAchanp
    drwxr-xr-x  2 cvsroot cvs 4096  6月 20 15:23 projectsxy
    drwxrwx---  4 cvsroot cvs 4096  6月 19 14:12 qiyjcxx
    ...
    [cvsroot@localhost ~]$ cvs -d /home/cvsroot/egov/projectsxy/ init
    [cvsroot@localhost ~]$ chmod -R 770 projectsxy/
    [cvsroot@localhost ~]$ ls -l

    ...
    drwxrwx---  4 cvsroot cvs 4096  6月 19 14:00 OAchanp
    drwxrwx---  3 cvsroot cvs 4096  6月 20 15:24 projectsxy
    drwxrwx---  4 cvsroot cvs 4096  6月 19 14:12 qiyjcxx
    ...
    [cvsroot@localhost ~]$ cd projectsxy/
    [cvsroot@localhost projectsxy]$ ls -l

    drwxrwx---  3 cvsroot cvs 4096  6月 20 15:24 CVSROOT
    [cvsroot@localhost projectsxy]$ exit
    [root@localhost egov]# vi /etc/xinetd.d/cvspserver
    按i进入到编辑
    service cvspserver
    {
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server = /usr/bin/cvs
    server_args = -f --allow-root=/home/cvsroot/egov/test --allow-root=/home/cvsroot/egov/projectsxy pserver
    log_on_failure += USERID
    }


    ~
    ~
    ~
    ~
    -- 插入 -- 
    编辑完后Shift+:
    :wq 保存退出   

    [root@localhost egov]# cd projectsxy/
    [root@localhost projectsxy]# ls -l
    总用量 8
    drwxrwx---  3 cvsroot cvs 4096  6月 20 15:24 CVSROOT
    [root@localhost projectsxy]# cd CVSROOT/
    [root@localhost CVSROOT]# ls -l
    总用量 192
    -rwxrwx---  1 cvsroot cvs  495  6月 20 15:24 checkoutlist
    -rwxrwx---  1 cvsroot cvs  698  6月 20 15:24 checkoutlist,v
    -rwxrwx---  1 cvsroot cvs  760  6月 20 15:24 commitinfo
    -rwxrwx---  1 cvsroot cvs  963  6月 20 15:24 commitinfo,v
    -rwxrwx---  1 cvsroot cvs  991  6月 20 15:24 config
    -rwxrwx---  1 cvsroot cvs 1194  6月 20 15:24 config,v
    -rwxrwx---  1 cvsroot cvs  602  6月 20 15:24 cvswrappers
    -rwxrwx---  1 cvsroot cvs  805  6月 20 15:24 cvswrappers,v
    -rwxrwx---  1 cvsroot cvs 1025  6月 20 15:24 editinfo
    -rwxrwx---  1 cvsroot cvs 1228  6月 20 15:24 editinfo,v
    drwxrwx---  2 cvsroot cvs 4096  6月 20 15:24 Emptydir
    -rwxrwx---  1 cvsroot cvs    0  6月 20 15:24 history
    -rwxrwx---  1 cvsroot cvs 1168  6月 20 15:24 loginfo
    -rwxrwx---  1 cvsroot cvs 1371  6月 20 15:24 loginfo,v
    -rwxrwx---  1 cvsroot cvs 1151  6月 20 15:24 modules
    -rwxrwx---  1 cvsroot cvs 1354  6月 20 15:24 modules,v
    -rwxrwx---  1 cvsroot cvs  564  6月 20 15:24 notify
    -rwxrwx---  1 cvsroot cvs  767  6月 20 15:24 notify,v
    -rwxrwx---  1 cvsroot cvs  649  6月 20 15:24 rcsinfo
    -rwxrwx---  1 cvsroot cvs  852  6月 20 15:24 rcsinfo,v
    -rwxrwx---  1 cvsroot cvs  879  6月 20 15:24 taginfo
    -rwxrwx---  1 cvsroot cvs 1082  6月 20 15:24 taginfo,v
    -rwxrwx---  1 cvsroot cvs    0  6月 20 15:24 val-tags
    -rwxrwx---  1 cvsroot cvs 1026  6月 20 15:24 verifymsg
    -rwxrwx---  1 cvsroot cvs 1229  6月 20 15:24 verifymsg,v
    [root@localhost CVSROOT]# su cvsroot
    [cvsroot@localhost CVSROOT]$


    [cvsroot@localhost CVSROOT]$ vi passwd
    按i进入到编辑
    sunxiaoyong:ENSlmPaH.nb2Q:cvsroot
    ~
    ~
    ~
    ~
    -- 插入 --                                                                                                        0,1          全部

    上边密码得来是在另外打开一个窗口进行密码生成:
    [root@localhost ~]# cd /
    [root@localhost /]# /home/cvsroot/passwd.pl "sunxiaoyongprojectsxy"
    ENSlmPaH.nb2Q [root@localhost /]#    

    ......
    最后从客户机建立名称为projectsxy的项目并使用cvs客户端导入。

  • 了解学习RUP

    2007-05-18 15:54:47

      RUPRational Unified Process,统一软件开发过程统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational(Rational Rose统一建模语言的开发者)的说法,好像一个在线的指导者,它可以为所有方面和层次的程序开发提供指导方针,模版以及事例支持。 RUP和似的产品--例如面向对象软件过程(OOSP),以及OPEN Process都是理解性的软件工程工具--把开发中面向过程的方面(例如定义的阶段,技术和实践)和其他开发的组件(例如文档,模型,手册以及代码等等)整合在一个统一的框架内。

    一、六大经验

          迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上,我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化,通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险,而且每个迭代过程以可以执行版本结束,可以鼓舞开发人员。

          管理需求。确定系统的需求是一个连续的过程,开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化,用例和脚本的使用以被证明是捕获功能性需求的有效方法。

          基于组件的体系结构。组件使重用成为可能,系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性,提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构

           可视化建模。RUP往往和UML联系在一起,对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模,获取有关体系结构于组件的结构和行为信息。

          验证软件质量。在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动,而是内建于过程中的所有活动,这样可以及早发现软件中的缺陷。

          控制软件变更。迭代式开发中如果没有严格的控制和协调,整个软件开发过程很快就陷入混乱之中,RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品,隔离来自其他工作空间的变更,以此为每个开发人员建立安全的工作空间。

     

    二、统一软件开发过程RUP的二维开发模型

      RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织,是过程展开的生命周期特征,体现开发过程的动态结构,用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone);纵轴以内容来组织为自然的逻辑活动,体现开发过程的静态结构,用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。如图1:


    三、统一软件开发过程RUP核心概念

          RUP中定义了一些核心概念,如下图:


          角色:描述某个人或者一个小组的行为与职责。RUP预先定义了很多角色。
          活动:是一个有明确目的的独立工作单元。
          工件:是活动生成、创建或修改的一段信息。

    四、统一软件开发过程RUP裁剪

          RUP是一个通用的过程模板,包含了很多开发指南、制品、开发过程所涉及到的角色说明,由于它非常庞大所以对具体的开发机构和项目,用RUP时还要做裁剪,也就是要对RUP进行配置。RUP就像一个元过程,通过对RUP进行裁剪可以得到很多不同的开发过程,这些软件开发过程可以看作RUP的具体实例。RUP裁剪可以分为以下几步:

    1) 确定本项目需要哪些工作流。RUP的9个核心工作流并不总是需要的,可以取舍。

    2) 确定每个工作流需要哪些制品。

    3) 确定4个阶段之间如何演进。确定阶段间演进要以风险控制为原则,决定每个阶段要那些工作流,每个工作流执行到什么程度,制品有那些,每个制品完成到什么程度。

    4) 确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容。

    5) 规划工作流内部结构。工作流涉及角色、活动及制品,他的复杂程度与项目规模即角色多少有关。最后规划工作流的内部结构,通常用活动图的形式给出。

    五、开发过程中的各个阶段和里程碑

      RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones);每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。

    1. 初始阶段

      初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体,在较高层次上定义交互的特性。本阶段具有非常重要的意义,在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲,初始阶段可能很短。 初始阶段结束时是第一个重要的里程碑:生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。

    2. 细化阶段

      细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。为了达到该目的,必须在理解整个系统的基础上,对体系结构作出决策,包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境,包括创建开发案例,创建模板、准则并准备工具。 细化阶段结束时第二个重要的里程碑:生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻,要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

    3. 构造阶段

      在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。从某种意义上说,构建阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量。 构建阶段结束时是第三个重要的里程碑:初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻,要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。

    4. 交付阶段

      交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量的调整。在生命周期的这一点上,用户反馈应主要集中在产品调整,设置、安装和可用性问题,所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。 在交付阶段的终点是第四个里程碑:产品发布(Product Release)里程碑。此时,要确定目标是否实现,是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

    六、统一软件开发过程RUP的核心工作流(Core Workflows)

      RUP中有9个核心工作流,分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段,但应注意迭代过程中的阶段是完全不同的,这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用,在每一次迭代中以不同的重点和强度重复。

    1. 商业建模(Business Modeling)

          商业建模工作流描述了如何为新的目标组织开发一个构想,并基于这个构想在商业用例模型和商业对象模型中定义组织的过程,角色和责任。

    2. 需求(Requirements)

      需求工作流的目标是描述系统应该做什么,并使开发人员和用户就这一描述达成共识。为了达到该目标,要对需要的功能和约束进行提取、组织、文档化;最重要的是理解系统所解决问题的定义和范围。

    3. 分析和设计(Analysis & Design)

      分析和设计工作流将需求转化成未来系统的设计,为系统开发一个健壮的结构并调整设计使其与实现环境相匹配,优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象,由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem),而描述则体现了类的对象如何协同工作实现用例的功能。 设计活动以体系结构设计为中心,体系结构由若干结构视图来表达,结构视图是整个设计的抽象和简化,该视图中省略了一些细节,使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介,而且在系统的开发中能提高被创建模型的质量。

    4. 实现(Implementation)

      实现工作流的目的包括以层次化的子系统形式定义代码的组织结构;以组件的形式(源文件、二进制文件、可执行文件)实现类和对象;将开发出的组件作为单元进行测试以及集成由单个开发者(或小组)所产生的结果,使其成为可执行的系统。

    5. 测试(Test)

    测试工作流要验证对象间的交互作用,验证软件中所有组件的正确集成,检验所有的需求已被正确的实现, 识别并确  认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法,意味着在整个项目中进行测试,从而尽可能早地发现缺陷,从根本上降低了修改缺陷的成本。测试类似于三维模型,分别从可靠性、功能性和系统性能来进行。

    6. 部署(Deployment)

      部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动,包括:软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下,还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

    7. 配置和变更管理(Configuration & Change Management)

      配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体,跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

    8. 项目管理(Project Management)

      软件项目管理平衡各种可能产生冲突的目标,管理风险,克服各种约束并成功交付使用户满意的产品。其目标包括:为项目的管理提供框架,为计划、人员配备、执行和监控项目提供实用的准则,为管理风险提供框架等。

    9. 环境(Environment)

      环境工作流的目的是向软件开发组织提供软件开发环境,包括过程和工具。环境工作流集中于配置项目过程中所需要的活动,同样也支持开发项目规范的活动,提供了逐步的指导手册并介绍了如何在组织中实现过程。

    七、RUP的迭代开发模式

      RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环,产生一个可执行的产品版本,是最终产品的一个子集,它增量式地发展,从一个迭代过程到另一个迭代过程到成为最终的系统。 传统上的项目组织是顺序通过每个工作流,每个工作流只有一次,也就是我们熟悉的瀑布生命周期(见图2)。这样做的结果是到实现末期产品完成并开始测试,在分析、设计和实现阶段所遗留的隐藏问题会大量出现,项目可能要停止并开始一个漫长的错误修正周期。

     


      一种更灵活,风险更小的方法是多次通过不同的开发工作流,这样可以更好的理解需求,构造一个健壮的体系结构,并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续,通过它,软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动,还有使用这个版本所必需的其他辅助成分,如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过,这些工作流至少包括:需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目(见图3)。

     

     

    图3 RUP的迭代模型

      与传统的瀑布模型相比较,迭代过程具有以下优点:

      降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。

      降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。

      加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。

      由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。

    八、统一软件开发过程RUP的十大要素

    1. 开发前景
    2. 达成计划
    3. 标识和减小风险
    4. 分配和跟踪任务。。
    5. 检查商业理由
    6. 设计组件构架
    7. 对产品进行增量式的构建和测试
    8. 验证和评价结果
    9. 管理和控制变化
    10. 提供用户支持

    让我们逐一的审视这些要素,看一看它们什么地方适合RUP,找出它们能够成为十大要素的理由。
     
    1. 开发一个前景
          有一个清晰的前景是开发一个满足涉众真正需求的产品的关键。 前景抓住了RUP需求流程的要点:分析问题,理解涉众需求,定义系统,当需求变化时管理需求。 前景给更详细的技术需求提供了一个高层的、有时候是合同式的基础。正像这个术语隐含的那样,它是软件项目的一个清晰的、通常是高层的视图,能被过程中任何决策者或者实施者借用。它捕获了非常高层的需求和设计约束,让前景的读者能理解将要开发的系统。它还提供了项目审批流程的输入,因此就与商业理由密切相关。最后,由于前景构成了“项目是什么?”和“为什么要进行这个项目?”,所以可以把前景作为验证将来决策的方式之一。 对前景的陈述应该能回答以下问题,需要的话这些问题还可以分成更小、更详细的问题: ? 关键术语是什么?(词汇表) ? 我们尝试解决的问题是什么?(问题陈述) ? 涉众是谁?用户是谁?他们各自的需求是什么? ? 产品的特性是什么? ? 功能性需求是什么?(Use Cases) ? 非功能性需求是什么? ? 设计约束是什么?

    2. 达成计划
            “产品的质量只会和产品的计划一样好。” (2) 在RUP中,软件开发计划(SDP)综合了管理项目所需的各种信息,也许会包括一些在先启阶段开发的单独的内容。SDP必须在整个项目中被维护和更新。 SDP定义了项目时间表(包括项目计划和迭代计划)和资源需求(资源和工具),可以根据项目进度表来跟踪项目进展。同时也指导了其他过程内容(原文:process components)的计划:项目组织、需求管理计划、配置管理计划、问题解决计划、QA计划、测试计划、评估计划以及产品验收计划。

          在较简单的项目中,对这些计划的陈述可能只有一两句话。比如,配置管理计划可以简单的这样陈述:每天结束时,项目目录的内容将会被压缩成ZIP包,拷贝到一个ZIP磁盘中,加上日期和版本标签,放到中央档案柜中。 软件开发计划的格式远远没有计划活动本身以及驱动这些活动的思想重要。正如Dwight D.Eisenhower所说:“plan什么也不是,planning才是一切。” “达成计划”—和列表中第3、4、5、8条一起—抓住了RUP中项目管理流程的要点。项目管理流程包括以下活动:构思项目、评估项目规模和风险、监测与控制项目、计划和评估每个迭代和阶段。

    3. 标识和减小风险
          RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具,又作为确定迭代的基础。

    4. 分配和跟踪任务
          有一点在任何项目中都是重要的,即连续的分析来源于正在进行的活动和进化的产品的客观数据。在RUP中,定期的项目状态评估提供了讲述、交流和解决管理问题、技术问题以及项目风险的机制。团队一旦发现了这些障碍物(篱笆),他们就把所有这些问题都指定一个负责人,并指定解决日期。进度应该定期跟踪,如有必要,更新应该被发布。(原文:updates should be issued as necessary。) 这些项目“快照”突出了需要引起管理注意的问题。随着时间的变化/虽然周期可能会变化(原文:While the period may vary。),定期的评估使经理能捕获项目的历史,并且消除任何限制进度的障碍或瓶颈。

    5. 检查商业理由
          商业理由从商业的角度提供了必要的信息,以决定一个项目是否值得投资。商业理由还可以帮助开发一个实现项目前景所需的经济计划。它提供了进行项目的理由,并建立经济约束。当项目继续时,分析人员用商业理由来正确的估算投资回报率(ROI,即return on investment)。 商业理由应该给项目创建一个简短但是引人注目的理由,而不是深入研究问题的细节,以使所有项目成员容易理解和记住它。在关键里程碑处,经理应该回顾商业理由,计算实际的花费、预计的回报,决定项目是否继续进行。

    6. 设计组件构架
          在RUP中,件系统的构架是指一个系统关键部件的组织或结构,部件之间通过接口交互,而部件是由一些更小的部件和接口组成的。即主要的部分是什么?他们又是怎样结合在一起的? RUP提供了一种设计、开发、验证构架的很系统的方法。在分析和设计流程中包括以下步骤:定义候选构架、精化构架、分析行为(用例分析)、设计组件。 要陈述和讨论软件构架,你必须先创建一个构架表示方式,以便描述构架的重要方面。在RUP中,构架表示由软件构架文档捕获,它给构架提供了多个视图。每个视图都描述了某一组涉众所关心的正在进行的系统的某个方面。涉众有最终用户、设计人员、经理、系统工程师、系统管理员,等等。这个文档使系统构架师和其他项目组成员能就与构架相关的重大决策进行有效的交流。

    7. 对产品进行增量式的构建和测试
          在RUP中实现和测试流程的要点是在整个项目生命周期中增量的编码、构建、测试系统组件,在先启之后每个迭代结束时生成可执行版本。在精化阶段后期,已经有了一个可用于评估的构架原型;如有必 要,它可以包括一个用户界面原型。然后,在构建阶段的每次迭代中,组件不断的被集成到可执行、经过测试的版本中,不断地向最终产品进化。动态及时的配置管理和复审活动也是这个基本过程元素(原文:essential process element)的关键。

    8. 验证和评价结果
          顾名思义,RUP的迭代评估捕获了迭代的结果。评估决定了迭代满足评价标准的程度,还包括学到的教训和实施的过程改进。 根据项目的规模和风险以及迭代的特点,评估可以是对演示及其结果的一条简单的纪录,也可能是一个完整的、正式的测试复审记录。 这儿的关键是既关注过程问题又关注产品问题。越早发现问题,就越没有问题。(原文:The sooner you fall behind, the more time you will have to catch up.)

    9. 管理和控制变化
          RUP的配置和变更管理流程的要点是当变化发生时管理和控制项目的规模,并且贯穿整个生命周期。其目的是考虑所有的涉众需求,尽可能的满足,同时仍能及时的交付合格的产品。 用户拿到产品的第一个原型后(往往在这之前就会要求变更),他们会要求变更。重要的是,变更的提出和管理过程始终保持一致。 在RUP中,变更请求通常用于记录和跟踪缺陷和增强功能的要求,或者对产品提出的任何其他类型的变更请求。变更请求提供了相应的手段来评估一个变更的潜在影响,同时记录就这些变更所作出的决策。他们也帮助确保所有的项目组成员都能理解变更的潜在影响。

    10. 提供用户支持
          在RUP中,部署流程的要点是包装和交付产品,同时交付有助于最终用户学习、使用和维护产品的任何必要的材料。 项目组至少要给用户提供一个用户指南(也许是通过联机帮助的方式提供),可能还有一个安装指南和版本发布说明。 根据产品的复杂度,用户也许还需要相应的培训材料。最后,通过一个材料清单(BOM表,即Bill of Materials)清楚地记录应该和产品一起交付哪些材料。 关于需求 有人看了我的要素清单后,可能会非常不同意我的选择。例如,他会问,需求在哪儿呢?他们不重要吗?我会告诉他我为什么没有把它们包括进来。有时,我会问一个项目组(特别是内部项目的项目组):“你们的需求是什么?”,而得到的回答却是:“我们的确没有什么需求。” 刚开始我对此非常惊讶(我有军方的宇航开发背景)。他们怎么会没有需求呢?当我进一步询问时,我发现,对他们来说,需求意味着一套外部提出的强制性的陈述,要求他们必须怎么样,否则项目验收就不能通过。但是他们的确没有得到这样的陈述。尤其是当项目组陷入了边研究边开发的境地时,产品需求从头到尾都在演化。 因此,我接着问他们另外一个问题:“好的,那么你们的产品的前景是什么呢?”。这时他们的眼睛亮了起来。然后,我们非常顺利的就第一个要素(“开发一个前景”)中列出的问题进行了沟通,需求也自然而然的流动着(原文:and the requirements just flow naturally.)。 也许只有对于按照有明确需求的合同工作的项目组,在要素列表中加入“满足需求”才是有用的。请记住,我的清单仅仅意味着进行进一步讨论的一个起点。

    九、总结

      RUP具有很多长处:提高了团队生产力,在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面,针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导,并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构,为开发过程提供较大的通用性。但同时它也存在一些不足: RUP只是一个开发过程,并没有涵盖软件过程的全部内容,例如它缺少关于软件运行和支持等方面的内容;此外,它没有支持多项目的开发结构,这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端,但并不完美,在实际的应用中可以根据需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。

  • 测试、测试、测试--软件测试的理论和实践

    2007-05-17 11:00:55

    我们每个人,不会都是软件测试人员,但都是某些软件的用户。缺省或默认情况下,用户都会觉得买到的软件是没有问题的,一般不会去想这样的软件可能会有问题,用户只要使用这些软件来解决他们需要解决的问题就可以了。当他们发现问题的时候,甚至会感到震惊。存在的问题很多都和测试的成效有关系,一般的软件产品存在的问题确实比较少,但我觉得即使是以前买的正版的金山快译2000都有着一些显而易见的bug。如果测试不充分,那么这些问题会潜伏在软件中,等到用户发现以后,再有开发人员进行维护,改正错误的费用一般是开发阶段的40倍到60倍。

    人们对测试存在着一些误区,例如:
    1 测试是想象到可能出现的问题,然后试图验证这些问题。
    实际上能想象到的只是一部分的情况,随意性太大,还要取决于开发人员的经验,对业务的熟悉程度和他想象到的程度。
    2 让时间有富裕的员工去做一些测试
    表面上看这体现了管理的效率和灵活性,但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心,善于学习、思考和发现问题,细心有条理,总结问题,如果具备这样的优点,做其它工作同样也会很出色,因此这里还有一个要求,就是要喜欢测试这项工作。如果他是专职的,那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员,两者工作性质不同,待遇不同,地位不同,对自我实现的价值的认识也不同,这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务,或者发现了几个问题就觉得满意了,这在任何其它工作中都是不行的。
    3 测试是相对简单的工作。
    实际上并非如此,要真正做好一件事都不容易。测试也有很多相关技术和工具。而对测试的轻视问题,也许要通过痛苦的经历和结果才可能确切体会到。很多专家都在对测试的理论进行深入的探讨和研究。

    测试的基本知识

    让我们一起快速过一遍:

    什么是软件测试:在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。
    测试的目标:以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷,以确保系统的质量。
    从测试的类型来看,测试分为2种:黑盒测试白盒测试
    黑盒测试又称为功能测试或数据驱动测试,把系统看成一个黑盒子,不考虑程序的内在逻辑,只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。
    白盒测试又称为结构测试和逻辑驱动测试,允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例,对程序的逻辑路径进行测试。
    测试用例由测试输入数据以及与之对应的输出结果组成。测试用例设计的好坏直接决定了测试的效果和结果。
    从测试实际的前后过程来看,软件测试上是由一系列的不同测试所组成,这些软件测试的步骤分为:单元测试、组装测试(集成测试)、确认测试和系统测试。软件开发的过程是自顶向下的,测试则正好相反,以上这些过程就是自底向上,逐步集成的。

    单元测试(模块测试):针对每个模块进行的测试,可从程序的内部结构出发设计测试用例,多个模块可以平行地对立地测试。通常在编码阶段进行,必要的时候要制作驱动模块和桩模块。
    集成测试:在单元测试的基础上,将所有模块按照设计要求组装成为系统,必须精心计划,应提交集成测试计划、集成测试规格说明和集成测试分析报告。
    确认测试:验证软件的功能和性能及其它特性是否与用户的要求一致。
    系统测试:将软件放在整个计算机环境下,包括软硬件平台、某些支持软件、数据和人员等,在实际运行环境下进行一系列的测试。

    测试工作的文档主要有:测试计划、测试模型和用例设计或规格说明、测试分析报告等。从软件工程上说,这是属于软件配置的一部分。(我不知道,如果什么报告都没有,只是不断地摆弄执行程序,看到错误和问题就记下来,算不算真正的测试?)

    测试需要一定的技术和工具

    在用例设计过程中,可以考虑到很多方面,并且也有很多的指导方法和技术。

    黑盒测试用例设计包括:

    等价类划分:划分等价类--确立测试用例--设计用例
    边界值分析:通过分析,考虑如何确立边界情况
    错误推测法:靠经验和直觉来推测程序中可能存在的各种错误,从而有针对性地编写用例。可以列举出可能的错误和可能发生错误的地方,然后选择用例。
    因果图:通过画因果图,在图上标明约束和限制,转换成判定表,然后设计测试用例。这适合于检查程序输入条件的各种组合情况。

    功能图FD:通过形式化地表示程序的功能说明,并机械地生成功能图的测试用例。

    白盒测试用例设计包括:

    1 逻辑覆盖,以程序内在逻辑结构为基础的测试,包括以下5种类型:

    1.1 语句覆盖:每一条可执行语句至少覆盖一次;
    1.2 判定覆盖(分支覆盖):设计若干个测试用例,运行所测程序,使程序中每个判断的取真分支和取假分支至少执行一次;
    1.3 条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的每个可能取值至少执行一次;
    1.4 判定-条件覆盖:设计足够多的测试用例,运行所测程序,使程序中每个判断的每个条件的所有可能取值至少执行一次,并且每个可能的判断结果也至少执行一次;
    1.5 条件组合测试:设计足够多的测试用例,运行所测程序,使程序中每个判断的所有可能的条件取值至少执行一次;
    1.6 路径测试:设计足够多的测试用例,运行所测程序,要覆盖程序中所有可能的路径。

    2 基本路径测试

    在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。包括以下5个方面:
    2.1 程序的控制流图:描述程序控制流的一种图示方法。
    2.2 程序环境复杂性:McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界。
    2.3 导出测试用例
    2.4 准备测试用例,确保基本路径集中的每一条路径的执行
    2.5 图形矩阵:是在基本路径测试中起辅助作用的软件工具,利用它可以实现自动地确定一个基本路径集。

    程序的静态分析方法:

    1 生成各种引用表、静态错误分析

    2 人工测试:桌前检查、代码评审等

    3 软件测试工具:包括静态分析工具、动态测试工具、测试数据自动化生成工具、模块测试台、测试合成环境

    3.1 静态分析工具:语言程序的预处理器、数据库工具、错误分析器和报告生成器。直接扫描所测试的正文,对程序的数据流和控制流进行分析,然后送出测试报告。

    3.2 动态测试工具:通过选择适当的测试用例,实际运行所测程序,比较实际运行结果和预期结果,发现错误。

    3.3 测试数据自动化生成工具:包括路径测试数据生成程序、随机测试数据生成程序以及根据数据规格说明生成测试数据

    3.4 模块测试台是一种专门的测试用例描述语言,负责将输入数据传送到所测试模块中,然后将实际输出结果与在描述测试用例的语言中所表述的期望结果进行比较,发现错误。另外,也包括其它的功能:语句跟踪、动态断句、覆盖度量、用户自定义符号表、内容表和输出格式。

    3.5 测试合成环境:包括环境模拟程序,代码检查程序,测试文档生成程序,测试执行严整程序,输出比较程序,程序正确性证明程序等,以及各种调试工具。而且还有集成系统,集成了多种工具,如SADAT、Microsoft Test for Windows和PureArtria等。
     
    ***********************************************************

    测试的管理

    作为项目或产品开发的一个必要的组成部分,需要良好的组织和管理。使用软件质量规范,编写和实现测试用例和模型,可以有效地组织测试。

    一般的测试工作过程也可以是:计划-->配置(必要的软硬件资源下)-->开发(构造或配置测试工具、创建测试套件和测试方案库、准备适当的报告工具并记录测试系统如何运转)-->测试执行(进行测试、记录测试条件和问题,报告结果)。

    测试管理也可以从测试经理和测试小组2个方面去看:

    测试经理要管理好团队,很多人认为测试是枯燥乏味的事情,而且似乎低级的事情,所以测试经理应该不断地激励小组成员,为他们争取利益。在时间进度上保证稳步前进。就象赛跑,一开始就加班加点,只会导致极限的过早到来。
    作为测试经理,应该有足够的质量意识。评价质量风险的方法是“失败模式和效果分析”(Failure Mode and Effect Analysis, FMEA)。这种方法可以允许您在特定的质量风险和结果上映射需求、规范,以及项目小组假设。然后,按照风险级别进行分类,并按序排列。
    实际上如果能得到充分的资源已是很困难的了,能用好临时的测试人员也已经不错了。一般企业的主管和技术经理都并不怎么真正重视测试工作的意义和价值。也许他们认为临时的投入一次性的强力测试足以发现绝大部分问题,而实际上这对产品的长远发展,以及质量改进都没有太大好处。

    测试过程中软件功能可能进行调整和变化,测试发现问题也会导致变化,需要重新的测试。对这些变更也需要进行管理。
    另外,由于上层管理部门的不重视,必须想办法与之进行清楚而有效的沟通;同开发部门的沟通也非常重要,因为开发和测试在性质上是有些对立的,很容易在相互之间产生一些不必要的矛盾。和开发部门不同的是,一般质量或测试部门和市场或销售部门的立场倒是比较一致的,如果双方都认为高质量的产品是市场战略中重要的品牌战略,彻底的测试对于达到这样的目标来说意义重大。因此,有必要和市场部门保持协作和交流。

    测试经理可以经常问自己一些问题:

    计划做哪些测试?实际完成了哪些测试?使用了多少用例?其中多少没有通过?管理部门是否有足够的支持?他们是否向你要过测试报告?开发部门的联络是否及时?等等。如果你是测试管理人员,应该可以想到更多的问题。

    测试小组:

    测试小组有多大的规模,一般取决于项目规模、测试人员与开发人员的比例、项目经理对质量保证的认识和期望等,也取决于你的准确的测试计划。
    对一些项目来说,最好是在开始阶段就有测试人员有所介入。

    如本文一开始所提到的,在测试小组中测试人员必须具备的素质包括:有效的坦率真诚的交流的能力、清晰简明的表达能力、一定的好奇心(但不至于太强,以至于花太多精力去探究一个微小的问题),不应害怕提出尖锐问题引起麻烦,一定的责任心,
    注意力能够高度集中,是职业悲观主义者(但不是抱怨和憎恶)。

    以下是一些测试的方法和基本工具:

    测试方案、测试模型和测试用例
    测试就象是做实验一样,实验对于象我这样的理工科毕业生来说真是太熟悉不过了。做实验之前必然有实验的方案、内容和步骤,测试似乎也是同样的。另外,基于测试用例的测试和常见的随机性的测来测去也是完全不同的,尽管习惯于随机性测试的人,如果注意力集中的话,他的头脑里也是有一些测试用例的。

    关于测试实验室,进行测试工作首先要争取到尽可能好的环境。如果可能,应该建立测试实验室,实验室包括必要的装备、工具软件(包括测试工具)和各种操作系统平台,保持实验室的实用、整洁,避免他人干扰甚至破坏测试环境。

    关于测试跟踪软件,制作一个简单的测试问题跟踪软件,记录测试的结果,将测试发现的问题分类,并对测试发现的问题和模块、开发人员进行关联,有助于分析问题,并可有效记录测试的结果,形成测试报告,并从中找出一些规律性的东西来。因此测试问题跟踪软件还是有一定的价值的。

    关于测试自动化,有一定的风险。对一个稳定的系统,甚至可以自己开发自动化软件,而对于正处于快速变形中的软件开发过程,接口、主要功能和支持环境在发展变化中。为测试配置环境也要付出很多的时间。

    以下是关于测试的一些技巧和经验:

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

    由于测试发现问题,在解决问题后还要重新测试,因此测试的时间可能会比实际更长一些

    识别和注意少数重要的方面,而忽略多数次要的方面,有时候少数的问题足以致命,这些问题将是软件测试结果中重要性最高的错误。

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

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

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

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

     
    最后,我忽然想,测试实际上可以覆盖到硬件,甚至非计算机产品的测试,也许可以相互借鉴。

    还有一种很奇特的感想,这种感想使我反而有些困惑不清了。我发现对测试来说,理论和实践的距离好象非常遥远,我先看了一本软件工程的书,然后写下了前面的一半内容,然后我又匆匆翻看了一本美国人的书,叫做《测试流程管理》,然后整理出了本文后一半的内容,该书中有着比本文多得多的各方面的实践经验。歌德说过,理论是苍白的,生命之树常青。我稍稍改变一下,就变成了:理论是苍白的,实践之树常青。也许测试是一种实践性很强的工作,大学教授们一般也不可能热衷于参加测试工作吧。

  • 如何从一名测试员转型为测试管理人员

    2007-05-10 08:47:22

    如果你是测试员或是高级测试员,有志转向管理发展,那么需要加强以下内容,至少要做到几点:

    1. 测试计划的编写(要结合测试的项目,能以此来控制和确定测试所需人员,设备及时间来管理测试时间)

    2. 要熟悉BUG跟踪工具及软件测试流程.(如: TD, Bugzilla, CQ等)

    3. 要熟悉配置管理工具. (如: CVS, VSS等)

    4. 要熟悉自动化工具.(例如:WinRunner, QTP, Robot, RFT, Automation等,能结合录制完的脚本编写代

    码)

    5. 要熟悉压力及性能测试工具.(例如: LoadRunner, webload, silkperformance等,能结合相关数据,分

    析出性能瓶颈)

    6. 要熟悉或精通一门语言. (例如: Java, C++)

    7. 要熟悉数据库.(例如: Oracle, DB2, SQLServer, MySQL)

    8. 要熟悉主流操作系统. (例如: HP Unix, IBM AIX, Sun Solaris, Red Hat Linux, SuSE Linux,

    Windows)

    9. 能用英文流利的和老外交流以及往来Email.

    10. 语言表达能力强,表达问题清晰明了.

    11. 沟通能力强,能和上级/开发经理很好的达成测试相关/BUG事宜.

    12. 学习技术的能力要强,能快速上手一个新的技术.

    13. 乐于与人交流.

231/212>
Open Toolbar