路尽隐香处 翩然雪海间

发布新日志

  • 软件测试名词解释

    2008-09-25 13:05:29

     

    软件缺陷----软件中含有符合下面5 条规则之一的问题称为软件缺陷:

       ◆软件未达到产品说明书标明的功能。
       ◆软件出现产品说明书指明不会出现的错误。
       ◆软件功能超出产品说明书指明的范围。
       ◆软件未达到产品说明书未指出但应达到的目标。
       ◆软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

      测试案例----测试用例的别名

      黑盒测试----指测试人员通过各种输入和观察软件的各种输出结果来发现软件的缺陷,而不关心程序具体如何实现的一种测试方法。

      静态测试----指测试不运行的部分,例如测试产品说明书,对此进行检查和审阅.

      静态白盒测试-----指在不执行的条件下有条理地仔细审查软件设计,体系结构和代码,从而找出软件缺陷的过程。有时称作结构分析。

      动态测试----通过运行和使用软件进行测试。

      探索测试----通常用于没有产品说明书的测试,这需要把软件当作产品说明书来看待,分步骤逐项探索软件特性,记录软件执行情况,详细描述功能,综合利用静态和动态技术来进行测试。

      等价区间----指测试相同目标或者暴露相同软件缺陷的一组测试用例.

      测试设计----提炼测试方法,明确指出设计包含的特性和相关测试。如果要求完成测试还明确指出测试案例和测试程序,指定特性通过/失败的规则。

      软件QA----QA= Quality Assessment 质量评价。防止软件缺陷称为软件QA。

      TQM 或者TQC 原理----TQM(全面质量管理)或者TQC(全面质量控制)。其原理是,用集中的质量评判团队来负责质量是不实际的,因为工作的人不负责质量,所以他们不会设法实现质量评判目的。要想制造高质量产品,需要创立从管理开始自上而下的质量意识,使全体成员共同承担质量责任。

      SQC----软件质量控制(SQC)是测试团队很常用的名称。该名称来源于制造行业,其中QC 检验员对生产线上的产品进行采样、检测,如果测试失败,他有权停掉生产线或者整个工厂。测试团队很少有这种授权。

      Murphy 法则---永远不会有足够的时间把事情做好,但是总有时间返工。软件开发小组需要遵循一个过程,花费一些时间,变得有条理,一开始就设法作对。

  • 软件测试基础知识复习

    2008-09-25 13:04:21

    软件开发过程及软件质量保证
    1.软件开发过程的几个主要阶段:
    1)定义。明确开发的目标,软件的需求。
    2)计划。制订软件开发所涉及到的计划。
    3)设计。设计、编码、编写文档等,完成要求的软件特性。
    4)稳定化。主要是测试和缺陷修复,确保软件的质量。
    5)安装。安装、提交完成的软件,为客户提供运行环境。
    2.几种常用的软件生命周期模型:
    1)瀑布模型。
    2)原型模型。
    3)增量模型。
    4)螺旋模型。
    软件测试人员的角度来看软件开发过程,需要注意的是:测试贯穿在整个开发过程中,而不是在某个阶段集中地做一下测试而其它阶段不用理会测试工作。

    一个软件之所以被认为为质量优秀,是它内在具备了这样一些特性:
    满足用户的需求;
    合理进度、成本、功能关系;
    具备扩展性和灵活性,能够适应一定程度的需求变化;
    能够有效地处理例外的情况;
    保持成本和性能的平衡。

    软件质量保证(Software Quality Assurance-----SQA)是为了确保软件开发过程和结果符合预期的要求而建立的系列规程,以及依照规程和计划采取的一系列活动及其结果评审。

    软件质量保证的活动主机包括:
    技术方法的就用;
    正式技术评审的实施;
    软件测试
    标准的执行;
    修改的控制;
    度量;
    记录和记录保存。

    软件错误的定义:软件错误是软件产品中存在的导致期望的运行结果和实际结果间出现差异的一系列问题,这些问题包括故障、失效、缺陷。


    软件测试
    软件测试就是为了发现软件中存在的错误而分析或执行程序的过程。具体地说,软件测试是分析程序或根据软件开发各阶段的规格说明和各程序的内部结构而精心设计出一批测试用例,并利用测试用例来运行程序,以发现程序错误的过程。

    软件测试有两个基本的功能:验证(Verification)和确认(Validation)。
    验证指保证软件正确地实现了特写功能的一系列活动。
    确认指保证最终的产品满足系统需求。
    通俗的说:验证保证产品的正确性;确认保证生产了正确的产品。

    软件测试人员应该至少具备以下两个关键领域方面的知识:
    1)
    软件测试技术;
    2)被测应用程序及其相关应用领域知识。

    理解以下的描述:
    测试能提高软件的质量,但是提高质量不能依赖测试;
    测试只能证明错误存在,不能证明错误不存在;
    测试的主要困难是不知道该如何进行有效地测试,也不知道什么时候能够放心的结束测试;
    每个程序员都应当测试自己的程序(份内事),但不能作为程序已通过测试的依据(所以项目需要独立的测试人员);
    80-20原则:80%的错误聚集在20%的模块中,经常出错的模块改错后还是会经常出错;
    测试应当循序渐进,不要企图一次性做完。"欲速则不达"。

    测试人员的目标和主要工作:
    目标:(1).基本目标是发现软件错误;
    (2).要尽可能早的找出软件错误;
    (3).必需确保找出的软件错误得以关闭。

    主要工作:
    1)规划测试任务
    2)设计测试(包括编写测试用例等等)
    3)建立一个合适的测试环境
    4)评估、获取、安装和配置自动测试工具
    5)执行测试
    6)撰写适当的测试文档

    软件测试的分类
    1.从是否需要执行被测试软件的角度分:有静态测试和动态测试。
    2.从测试是否针对软件结构和算法的角度分类分:白盒测试和黑盒测试。
    3.从测试的不同阶段分:单元测试、集成测试、系统测试和验收测试四个阶段。
    其中系统测试有:功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等等。

    针对某些功能作用的测试:
    回归测试:指错误被修正后或软件功能、环境发生变化后进行的重新测试。
    功能测试:测试软件的功能是否符合功能性需求,通常采用黑盒测试方式。
    负载测试:测试软件系统的最大负载,超出此负载软件有可能会失常。
    压力测试:与负载测试差不多,叫法不同。
    易用性测试:测试软件是否易用,主观性比较强。一般要根据用户的反馈信息来评价。
    安装与反安装测试:测试软件在"全部、部分、升级"等状况下的安装/反安装过程。
    恢复测试:测试系统从故障中恢复的能力。
    安全性测试:测试系统防止非法侵入的能力。
    兼容性测试:测试系统与其它软件、硬件兼容的能力。
    内存泄漏测试:测试软件在运行过程中是否会造成内存泄漏。
    比较测试:通过与同类产品比较,考察该产品的优点、缺点。
    Alpha测试:一种先期的用户测试,此时系统刚刚开发完成。
    Beta测试:一种后期的用户测试,此时系统已经通过内部测试,大部分错误已经改正,即将正式发行。同Alpha测试一样都由用户进行,场地不同,Alpha测试一般是把用户请到开发方的场地来测试,Beta测试是指在一个或多个用户的场所进行测试。

    测试工作的主要步骤:
    1)测试计划:测试人员要首先对需求进行分析,最终定义一个测试集合。
    2)测试设计与开发:根据软件需求、说明书完成测试用例设计并编写必要的测试驱动程序。
    3)执行测试:需要做的工作是,建立测试环境;根据前面编写的测试计划和测试用例运行测试;记录测试结果;报告软件缺陷;跟踪软件缺陷直至其被处理;分析测试结果


    PS 测试工程师职业素质
    1)责任心
    2)学习能力
    3)怀疑精神
    4)沟通能力
    5)专注力
    6)洞察力
    7)团队精神
    8)注重积累
  • 测试设计中需要考虑的测试类型

    2008-09-25 13:03:01

    黑盒测试(Black box testing) :不基于内部设计和代码的任何知识,而是基于需求和功能性。

      白盒测试(White box testing):基于一个应用代码的内部逻辑知识,测试是基于覆盖全部代码、分支、路径、条件。

      单元测试:最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做,因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好,除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。

      累积综合测试:当一个新功能增加后,对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作,或当需要时那些测试驱动器已被开发出来; 这种测试可由程序员或测试员来做。

      集成测试:一个应用系统的各个部件的联合测试,以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。

      功能测试(functional testing):用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。

      系统测试:基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件。

      端到端测试(end-to-end testing):类似于系统测试;测试级的“宏大”的端点;涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。

      健全测试:典型地是指一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如,如果一个新版软件每5分钟与系统冲突,使系统陷于泥潭,说明该软件不够“健全”,目前不具备进一步测试的条件。

      衰竭测试:软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

      接受测试:基于客户或最终用户的规格书的最终测试,或基于用户一段时间的使用后,看软件是否满足客户要求。

      负载测试:测试一个应用在重负荷下的表现,例如测试一个 Web 站点在大量的负荷下,何时系统的响应会退化或失败。

      强迫测试:在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试,如某个动作或输入大量的重复,大量数据的输入,对一个数据库系统大量的复杂查询等。

      性能测试(performance testing):在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。

      可用性测试 (usability testing) :对“用户友好性”的测试。显然这是主观的,且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

      安装/卸载测试:对软件的全部、部分或升级安装/卸载处理过程的测试。

      恢复测试(recovery testing) :测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。

      安全测试(security testing) :测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。

      兼容测试:测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。

      比较测试:与竞争伙伴的产品的比较测试,如软件的弱点、优点或实力。

      α 测试 (alpha testing):在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。

       β 测试 (beta testing) :当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。

         回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化,都重复进行测试。很难说需要进行多少次回归测试,特别是是到了开发周期的最后阶段。进行此种测试,特别适于使用自动测试工具。 

         负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况,以确定在什么情况下系统响应速度下降或是出现故障。 
  • 测试过程分析的15个常用度量元

    2008-09-25 12:59:17

     
    序号
    优先级
    度量对象
    度量元
    度量单位
    采集周期
    采集/计算方法
    分析方法
    作用
    1
    1
    用户发现的各类型的缺陷
    缺陷个数
    交付阶段
    维护阶段
    直接统计
    80-20分析:对缺陷类型按缺陷个数排序,找出客户发现的最多的20%的缺陷类型
    分析客户的关注点是什么?为什么客户能发现这些类型的缺陷,为什么我们没有测试出来?定义改进措施
    2
    1
    软件模块
    缺陷密度
    个/KLOC
    系统测试阶段
    缺陷个数/代码规模
    80-20分析:对所有模块的缺陷密度进行排序比较,找出缺陷密度最大的20%模块
    找出质量最差的模块,采取改进措施
    3
    1
    遗留的缺陷
    缺陷个数
    系统测试阶段
    上阶段遗留的缺陷个数+本阶段发现的缺陷个数-本阶段解决的缺陷个数
    和阶段出口准则对比
    里程碑评审决策的依据
    4
    1
    各级别严重程度的缺陷
    缺陷个数
    系统测试阶段
    直接统计
    和项目目标对比
    判断是否达到测试结束与产品发布准则
    5
    1
    回归测试活动
    缺陷个数
    系统测试阶段
    直接统计
    趋势线分析:横坐标为某次回归测试,纵坐标为缺陷个数,建立拟合曲线,判断收敛性
    针对每次回归测试活动,进行收敛分析,作为发布决策的依据
    6
    2
    代码走查
    代码走查的效率
    个/小时
    编码阶段
    代码走查发现的缺陷个数/代码走查的工作量
    和项目目标对比
    比较评审与测试的效率,以确定二者投入工作量的比例
    7
    2
    单元测试
    测试效率
    个/小时
    编码阶段
    单元测试发现的缺陷个数/单元测试的工作量
    和项目目标对比
    建立单元测试的性能基线,预测单元测试投入的工作量
    8
    2
    系统测试
    测试效率
    个/小时
    系统测试阶段
    缺陷个数/测试工作量
    和项目目标对比
    建立测试活动的投入产出模型,用以估计为了达到项目的质量目标而需要的测试工作量
    9
    2
    系统测试
    系统测试用例相对逻辑规模的密度
    个/功能点
    系统测试阶段
    系统测试用例个数/需求的规模
    和项目目标对比
    判断系统测试的充分性
    10
    2
    系统测试
    系统测试用例相对物理规模的密度
    个/KLOC
    系统测试阶段
    系统测试用例个数/代码规模
    和项目目标对比
    判断系统测试的充分性
    11
    3
    测试发现各类型的缺陷
    缺陷个数
    编码阶段
    系统测试阶段
    直接统计
    80-20分析:对缺陷类型按缺陷个数排序,找出最多的20%的缺陷类型
    根据类型的分布,查找错误的原因,定义编码或设计的改进措施
    12
    3
    单元测试
    缺陷密度
    个/KLOC
    编码阶段
    单元测试发现的缺陷个数/代码规模
    和项目目标对比
    建立单元测试的性能基线,用以制定项目的质量目标
    13
    3
    单元测试
    单元测试用例相对物理规模的密度
    个/KLOC
    编码阶段
    单元测试用例个数(或断言的个数)/KLOC
    和项目目标对比
    判断单元测试的充分性
    14
    3
    集成测试
    集成测试用例相对物理规模的密度
    个/KLOC
    集成阶段
    集成测试用例个数/KLOC
    和项目目标对比
    判断集成测试的充分性
    15
    3
    系统测试
    测试用例的有效性
    %
    系统测试阶段
    依据测试用例发现的缺陷个数/所有的缺陷个数
    和项目目标对比
    评价测试用例的有效性,判断是否需要提高测试
  • 软件缺陷管理基本概念

    2008-09-25 12:56:26

    认识软件缺陷,首先要了解软件缺陷的概念,其次是了解软件缺陷的详细特征,最后就是它的属性了,再高一个层次就是学习利用管理软件缺陷的工具了。
    1、首先介绍软件缺陷的概念
    软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。
    2、软件缺陷的详细特征
    a、单一准确
    b、可以再现(要求软件缺陷具有精确的步骤)
    c、完整统一
    d、短小简练
    e、特定条件
    f、补充完整
    g、不做评价
    3、软件缺陷的属性
    软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。
    下面详细介绍一下以上这些属性:
    a、缺陷标识:是标记某个缺陷的唯一标识,可以用数字序号表示;
    b、缺陷类型:功能、用户界面、文档、软件包、性能、系统\模块接口
         功能:影响了各种系统功能、逻辑的缺陷;
         用户界面:影响了用户界面、人机交互特性,包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷;
         文档:影响发布和维护,包括注释、用户手册、设计文档;
         软件包:由于软件配置库、变更管理或版本控制引起的错误;
         性能:不满足系统可测量的属性值,如执行时间、事务处理速率等;
         系统\模块接口:与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
    c、缺陷严重程度:致命(Fatal)、严重(Ceritical)、一般(Major)、较小(Minor)
        致命:系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机或者危机人身安全;
        严重:系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响;
        一般:系统的次要功能没有完全实现,但不影响用户的正常使用。例如:提示信息不太准确或用户界面差、操作时间长等一些问题;
        较小:使操作者不方便或遇到麻烦,但它不影响功能过的操作和执行,如个别不影响产品理解的错别字、文字排列不整齐等一些小问题
    d、缺陷产生可能性:总是、通常、有时、很少
         总是:总是产生这个软件缺陷,其产生的频率是100;
         通常:按照测试用例,通常情况下会产生这个软件缺陷,其产生的频率大概是80—90;
         有时:按照测试用例,有时候产生这个软件缺陷,其产生的频率大概是30—50;
         很少:按照测试用例,很少产生这个软件缺陷,其产生的频率大概是1—5.
    e、缺陷的优先级:立即解决、高优先级、正常排队、低优先级
         立即解决:缺陷导致系统几乎不能使用或者测试不能继续,需立即修复;
         高优先级:缺陷严重,影响测试,需要优先考虑;
         正常排队:缺陷需要正常排队等待修复;
         低优先级:缺陷可以再开发人员有时间的时候被纠正。
    f、缺陷状态:激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息
        激活或打开:问题还没有解决,存在源代码中,确认”提交的缺陷”,等待处理,如新报的缺陷;
        已修正或修复:已被开发人员检查、修复过的缺陷,通过单元测试,认为已经解决但还没有被测试人员验证;
        关闭或非激活:测试人员验证后,确认缺陷不存在之后的状态;
        重新打开:测试人员验证后,确认缺陷不存在之后的状态;
        推迟:这个软件缺陷可以在下一个版本中解决;
        保留:由于技术原因或第三者软件的缺陷,开发人员不能修复的缺陷;
        不能重现:开发不能再现这个软件缺陷,需要测试人员检查缺陷再现的步骤;
         需要更多信息:开发能再现这个软件缺陷,但开发人员需要一些信息,例如缺陷的日志文件、图片等。
    g、软件缺陷的起源:需求、构架、设计、编码、测试、用户
         在团建生命周期中软件缺陷占的比例:需求和构架设计阶段占54、设计阶段占25、编码阶段占15、其他占6.
    h、软件缺陷的来源:需求说明书、设计文档、系统集成接口、数据流(库)、程序代码
        需求说明书:需求说明书的错误或不清楚引起的问题;
        设计文档:设计文档描述不准确。和需求说明书不一致的问题;
        系统集成接口:系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷;
        数据流(库):由于数据字典、数据库中的错误引起的缺陷;
        程序代码:纯粹在编码中的问题所引起的缺陷。
    i、缺陷根源:测试策略,过程、工具和方法,团队\人,缺乏组织和通讯,硬件,软件,工作环境
       测试策略:错误的测试范围,误解测试目标,超越测试能力等;
       过程、工具和方法:无效的需求收集过程,果实的风险管理过程,不使用的项目管理方法,没有估算规程,无效的变更控制过程等;
       团队\人:项目团队职责交叉,缺乏培训。没有经验的项目团队,缺乏士气和动机不纯等;
       缺乏组织和通讯:缺乏用户参与,职责不明确、管理失败等;
       硬件:硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失,内存溢出等;
       软件:软件设置不对、缺乏,或操作系统错误导致无法释放资源,工具软件的错误,编译器的错误,千年虫问题等;
       工作环境:组织机构调整,预算改变,工作环境恶劣,如噪音过大。
    4、学会利用管理缺陷的工具
    例如TD、bugfree、bugzille等 

我的栏目

数据统计

  • 访问量: 2314
  • 日志数: 5
  • 建立时间: 2008-05-13
  • 更新时间: 2008-09-25

RSS订阅

Open Toolbar