发布新日志

  • 测试架构师

    2008-07-01 22:53:15

    今天收到猎头的一封邮件,招聘测试架构师,感觉到该公司对测试的认识还是满有深度,表现出了对测试的重视程度.对中国公司来说真不容易.在测试经理的岗位做了一段时间,可是公司却没有认识到测试的重要,没有把测试做为一个专业,也不会去设立测试架构师,只能一声叹息.

    职位描述如下:

    测试架构师   
    职位描述:
    1、开发和设计测试框架;
    2、纵横全局的考虑产品的功能及非功能需求,设计高精的测试系统;
    3、负责研发特定的测试技术;提高整体测试效率;
    4、领导公司测试技术的发展和测试策略的方向;
    5、前瞻性的考虑未来的版本的测试策略和技术;
    6、计划/设计测试平台,关注着产品的测试过程;
    7、具备测试技术、测试方法学上雄厚的知识。

  • 故障主题及故障描述

    2008-06-06 10:47:15

    故障主题必须具备的信息

    A)  故障现象

    说明:简要概括地描述故障现象。

    如有可能,还应该描述是在什么操作条件下引起来的。

    总之,简洁是应该的,但不能过分追求简洁。

    故障主题长度限定在1060个字之间。如果不符合,则提交故障单时会弹出如图2所示提示。

    故障主题选择填写的内容

    A)故障导致的严重后果。

    故障主题描述的用词及语气的要求

    A)  是针对单一故障的描述,如果不能确定多个故障现象是一个原因引起,则多个故障现象分开描述为多个故障。

    B)  简洁

    C)  切中要害

    D)  准确

    E)  客观 

    故障主题描述的注意事项

    A)  不能有错别字,要语句通顺,大小写要符合惯例,而且要统一。

    B)  避免使用不确定的词语

    C)  避免描述不准确

    避免带主观色彩的描述

    现象描述

    故障现象描述必须具备的信息

    对于故障现象,一般用文字描述,如果需要,可以附加日志文件、调试信息等附件。

    A)  故障现象

    说明:详细描述故障的现象。

    B)  故障是否可以复现或者故障发生的频率

    说明:描述该故障是否可以复现。可以从以下三个推荐描述中选择一个。

    1,故障可以复现。

    2,故障不能每次复现,发生概率大概是50%左右(概率的数字由故障提交人根据估计的故障发生概率填写)。

    3,故障只发生一次。 

    C)  故障复现步骤

    说明:如果故障可以复现,描述复现步骤。 

    D)  故障对系统造成的影响或者后果

    说明:说明该故障对系统的影响或者可能的后果,比如该故障造成一个基站下的所有用户不能使用数据业务。或者某个OMCR服务器下连接的OMCR客户端无法进行性能数据查询等。 

    E)  故障隔离信息

    说明:指测试人员用来确认错误是一个真正的问题,并识别那些影响错误表现的因素而收集的结果和信息,比如:“加载bmp格式地图时故障发生,加载jpg格式地图时故障不发生。”

    F)  附件

    说明:有时文字说明不能提供关于故障的完备信息,需要通过附件来补充信息。比如调试信息,日志信息,信令跟踪文件,屏幕截图等。对于附件文件名,也应该像故障主题一样,有些描述性的语言,不要就是test1.txt之类的。对于附件过大的,要进行压缩后再提交。

     

    故障现象描述选择填写的信息

    A)  和开发人员交流的情况

    说明:描述和开发人员就本故障的交流情况。

     

    故障现象描述的用词及语气的要求

    A)  切中要害

    B)  准确

    C)  客观

     

    故障现象描述的注意事项

    A)  不能有错别字,大小写要符合惯例,而且要统一。

    B)  避免使用不确定的词语

    C)  避免描述信息不足

    D)  避免描述不准确

    E)  避免带主观色彩的描述,在描述软件缺陷时不做评价

    F)  复现步骤清晰,

    G)  尽可能提供隔离信息,有助于故障定位。

     

    可能原因/建议

    如果初步定位了故障,可以在这里描述可能发生故障的原因。如果了解如何修改或者处理该故障,可以在这里描述建议。

    如果造成故障产生的原因是和开发人员一起定位的,还要加上开发人员的解释信息以及得到开发人员的确认信息。

  • 如何编写测试规程

    2008-05-23 17:33:41

    如何编写测试规程

    1          前言

        影响软件测试的因素很多,例如软件本身的复杂程度、研发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等等。因为有些因素是客观存在的,无法避免。有些因素则是波动的、不稳定的,例如研发队伍是流动的,有经验的走了,新人不断补充进来;一个具体的人工作也受情绪等因素影响;模块测试人员更换等等。如何保障软件测试质量的稳定?有了完善的测试规程,无论是谁来测试,参照测试规程实施,都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试规程考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。

        因此测试规程的设计和编制是软件测试中最重要的活动之一。测试规程是测试工作的指导,是软件测试的必须遵守的准则,更是软件测试质量稳定的根本保障之一。

    2          测试规程编写依据

    整个测试过程中的测试依据主要是系统的需求规格说明书、各种规范、标准和协议等。在整个测试过程中,首先需要对需求规格进行充分的分析,分解出各种类型的需求(功能性需求、性能要求、其他需求等),在此基础之上才可以开始测试设计工作。对需求的分解依赖于测试设计人员对系统和文档的理解,不但需要测试设计人员具有庖丁解牛般的技术和经验,更需要具有前瞻性、系统和全面的理念,分解出已有的功能和需要,同时发掘出应该具有却未在文档中体现的功能。对各个功能点的功能、性能、交互性、安全性、可靠性等要求进行规程编写,尽可能的增大测试规程的覆盖。

    3          测试规程编写内容

           测试规程指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试项名称、测试目的、预置条件、测试步骤、通过准则和测试用例。

    1)测试项名称用于描述规程所需测试的功能特性。

    2)测试目的用于描述规程测试所实现的目的。

    3)预置条件用于描述展开测试所需搭建的测试环境(包括硬件和软件)及其参数设置。

    4)测试步骤用于描述进行测试的所采取的方法、工具、实现测试目的活动步骤。概述了如何去测试所测功能特性,体现了测试设计人员的测试思路。

    5)通过准则用于描述判别测试步骤输出结果是否正确和判定功能特性是否通过测试的标准。在正常情况和众多异常情况下,所测功能特性是否符合需求、限制条件、取值范围、规范、标准和协议,所涉及到的需求、限制条件、取值范围、规范、标准和协议需要列出,方便比对,“xxx正确”之类的含糊语句是无法衡量功能特性是否正确的。通过准则必须针对测试目的和测试步骤而发,不能泛泛而谈。通过准则体现了测试设计人员对功能特性的理解。

    6)测试用例详细描述了输入参数、预期结果。测试用例可以分为基本事件、备选事件和异常事件。基本事件的测试用例应包含所有需要实现的需求功能,覆盖率达100%。备选事件和异常事件的测试用例可以采用黑盒和白盒测试用例设计技术。

    4          测试规程编写方法

           面对一个功能模块,在编写测试规程条目的时候,可以从以下几个方面考虑:

    4.1         用户角度

    直接面对用户的是软件界面,所以对于拥有界面的功能,在测试规程的设计上就必须从用户的角度或需求上出发,测试规程的测试步骤或者通过准则可以参考以下原则:

    1)易用性与合理性:指检查为实现界面相关功能而设计的控件组合、操作流程是否合理、提示信息是否充分和是否易于用户使用;

    2)规范性:指检查界面的控件是否遵循windows界面设计规范,界面布局是否美观协调,是否与公司风格、相关产品风格统一,界面是否有错别字存在等;

    3)容错性:指测试界面是否对不合理的输入有容错处理,主要是输入应用可接受范围之外、错误数据类型及其违反约束关系的内容,考虑输出的合法性。

    4)资源:指测试界面对系统资源的使用是否合理,在载入、运行和退出时是否能够合理使用和释放系统资源等;

    5)安全性:指只有规格规定的操作权限才可以访问系统,其他不符合规格的操作权限不能够访问系统;

    6)国际化:指在不同语言支持的操作环境下,按照要求的语言显示或提示(包括图像、图片上的文字),文字的用词适应本地化规范。

    4.2         功能实现角度

                功能一般都是通过一系列流程和接口实现的,流程包括正常流程和异常流程,接口包括

    内部接口和外部接口,其他功能模块和所测功能模块之间存在互相影响,这都是在编写测

    试规程需要考虑的。对功能实现的角度,可以从以下几个方面考虑规程编写:

    1)功能流程的覆盖

    依据需求和设计文档,规程必须能够覆盖到所测功能的所有正常流程,以验证功能的一系列流程是否都能实现。充分考虑所涉及的异常流程,异常流程通常是正常流程发生故障时程序的处理流程,要测试程序的异常处理是否正确或者是否有相应的异常处理,保证程序的健壮性。

    2)不同功能的组合

    由于功能模块之间存在接口,功能模块的工作状态变化会影响其他功能模块的运行,所以需要关注与所测功能相关的功能组合起来的实现情况。 譬如配置告警关系,性能告警关系,前后台关系,模块间的协议一致性和协议的互通性。

    3)不同功能之间的冲突

    功能的运行都需要一定资源,当资源稀缺时,功能间就存在冲突情况,比如:共享资源访问等。在测试规程编写时,需要考虑功能模块之间可能存在冲突的情况。

    4.3         功能应用角度

    在实验室环境功能运行正常,并不代表在实际环境也运行正常。应模拟实际应用环境,

    对功能模块的性能、可靠性等进行的测试。这部分也是规程编写的重要方面。

    4.3.1          性能测试

    性能测试包括接口性能测试,并发性能测试、负载测试、压力测试、强度测试、破坏性测试。性能测试的主要指标有负载量、并发量、响应时间、吞吐量等,比较重要的准备工作是负载生成,测试过程中需要监视资源,这些都是需要在测试规程中体现的。

    接口性能测试指模块间接口瓶颈测试,对大数据量的处理速度和响应时间。

    并发性能测试是评估在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程,譬如多用户、多终端、多模块等并发情况下功能运行测试;

    压力测试是在资源情况低的情况下,运行功能,找出因资源不足或资源争用而导致的错误。压力测试的目的就是“如何能够把系统折腾到什么程度而又不会出错”,压力测试需要反复数量、频率或资源需要很高的方式下执行,常用手段有:

    a)当平均每秒出现一个告警或中断的情况下,不断增加告警或中断出现频率;

    b) 把每次输入的数据量提高一个数量级;

    c)执行需要最大内存或占用最大资源的方案;

    d)使用会引起最大的系统额外开销的用例;

    e)设法超出系统的限制。

    破坏性测试重点关注超出系统正常负荷N倍情况下,错误出现状态和出现比率以及错误的恢复能力。

    4.3.2          可靠性、稳定性测试

    一定负荷的长期使用环境下,系统和功能的可靠性、稳定性。其目标是一个功能和系统在风险限度内是否接受或拒绝。

    4.4         系统应用角度

           当编写涉及到系统应用的测试规程时,系统的兼容性、安装升级和恢复性也是需要考虑的。

    4.4.1          系统兼容性测试

    系统中软件与各种硬件设备兼容性,与操作系统兼容性、与支撑软件的兼容性。兼容性测试是指系统的适应能力测试,可分为环境兼容测试和版本兼容测试。环境兼容性测试主要对系统进行不同应用环境的适应性测试;版本兼容性测试主要对系统的不同软件版本进行同一运行环境的适应性测试。

    4.4.2          系统安装升级测试

    安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如,正常情况下,第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。还有一个目的是核实软件在安装后可立即正常运行。

    4.4.3          恢复性测试

    要求系统是容错的,当错误发生时候,必须在一定时间从错误恢复过来,继续运行。恢复测试要通过各种手段,让系统强制的发生故障,然后来验证系统是否正常检测到错误,并且能够恢复正常运行。检查内容一般包括:

        1)如果系统是自动恢复的,重新初始化,检查点,恢复的数据,重起动都应该正确验证。

    2)如果要手动恢复,要验证修复的平均时间和复杂程度是否可以接受。

    5          测试用例编写方法

           测试用例是按一定顺序执行的与测试目标相关的一系列测试,是软件测试的主要手段,通过对测试用例的积累和重用,可以有效的降低质量成本。测试用例内容包括输入参数和预期结果,下面阐述了测试用例的设计原则和方法,使我们了解如何去确定输入参数和预期结果。

    5.1         测试用例的设计原则

    1.针对性:用例设计必须有明确的测试目标;

    2.经济性:测试用例避免使用不必要的步骤和资源;

    3.可复用性:尽可能在类似的情况下可以重复使用;

    4.可追踪性:测试用例必须可以追溯到需求;

    5.恰当性:对测试环境和测试执行人员的要求恰当;

    6.完整性:要考虑到测试中可能发现的各种情况;

    7.不依赖性:与用例设计人员无关,任何测试执行人都可以看懂。

    5.2         测试用例设计方法

    5.2.1          黑盒测试用例设计

    黑盒是把测试对象看成一个黑盒子,无需考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明,所以又叫功能测试或数据驱动测试。黑盒测试方法是在程序接口上测试,主要是为了发现以下错误:

    1)是否有不正确和遗漏的功能;

    2)在接口上,输入能否正确地接受?能否输出正确地结果?

    3)是否有数据结构错误或外部信息(例如数据文件)访问错误

    4)性能上是否能够满足要求

    5)是否有初始化或终止性错误。

     黑盒法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。黑盒测试方法主要有等价类划分、边值分析、因果图等。等价类划分方法和边界值分析方法都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等。因果图方法适合于测试输入条件的各种组合情况,是一种适合于描述对于多种条件的组合,相应产生多个动作的测试用例设计方法。

    5.2.1.1         等价类划分

    等价类划分的办法是把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据当作测试用例。在确立了等价类后,可建立等价类表,列出所有划分出的等价类,设计测试用例时尽可能覆盖所有的有效等价类和无效等价类。譬如输入字符必须是字母开头后跟字母或数字,长度不超过8的字符串,等价类划分如下表

    输入条件

    有效等价类

    无效等价类

    第一个字符

    字母

    非字母

    字符数

    1-8

    0个,>8

    字符组成

    全字母,字母和数字

    非字母数字字符,保留字

    5.2.1.2         边界值分析

    边界值分析是等价类方法的补充,设计测试用例时,首先确定边界,选取正好等于、刚刚大于和刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。譬如某输入文件可包含1255个记录,……”,则测试用例可取1255,还应取0256等。

    5.2.1.3         因果图

    因果图方法主要步骤如下:

    1)根据设计文档,确定哪些是原因(输入条件或输入条件的等价类),哪些是结果(输出条件);

    2)分析设计文档,找出原因与结果之间,原因与原因之间有哪些关系,画出因果图;

    3)由于语法或环境限制,有些原因与原因之间,原因和结果之间的组合情况无法出现,需要标记出这些约束和限制条件;

    4)把因果图转换为判定表;

    5)把判定表的每一列拿出来作为依据,涉及测试用例。

    举例:输入两个参数,第一个参数必须是AB,第二参数必须是数字,根据这两个参数修改属性,但如果第一个参数不正确,则给出信息L,如果第二个参数不是数字,则给出信息M

    原因: 1—第一个参数是A 2—第一个参数是B 3—第二个参数是数字

    结果: 21—修改属性;22 —给出信息L  23—给出信息M

    因果图

    说明:11为中间节点;原因1和原因2不可能同时选择,因此在因果图上施加约束

    根据因果图建立如下判定表:

     

       1    

       2  

       3 

      4

       5

       6

       7

       8

     

    查看(5940) 评论(0) 收藏 分享 管理

  • 终于开博了,加强学习

    2008-05-10 21:03:16

    暂无
  • 数据统计

    • 访问量: 8453
    • 日志数: 4
    • 建立时间: 2008-05-10
    • 更新时间: 2008-07-01

    RSS订阅