发布新日志

  • 测试员能做多久?

    2011-06-16 14:47:11

    普通测试员,做到多大年龄就做不动了:30?40?

     

  • 如何编写测试计划(转)

    2011-01-24 16:44:25

    一.首先了解以下几个问题:

    1. 为什么要编写测试计划?

    1)领导能够根据测试计划做宏观调空,进行相应资源配置等;

    2)测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等;

    3)便于其他人员了解测试人员的工作内容,进行有关配合工作

    2. 什么时间开始编写测试计划?

    (测试需求分析前总体测试计划书/测试需求分析后详细测试计划书)

    3. 由谁来编写测试计划?

    具有丰富经验的项目测试负责人

    4. 测试计划编写6要素?(5W1H)

    1)why——为什么要进行这些测试;

    2) what—测试哪些方面,不同阶段的工作内容;

    3) when—测试不同阶段的起止时间;

    4) where—相应文档,缺陷的存放位置,测试环境等;

    5) who—项目有关人员组成,安排哪些测试人员进行测试

    6) how—如何去做,使用哪些测试工具以及测试方法进行测试。

    二.测试计划主要内容:

    1.引言

    1.1项目背景

    1.2参考资料(计划编写依据:可行性分析报告/软件需求定义/软件概要设计/软件详细设计/用户使用说明书/……)

    1.3测试术语

    1.4有关项目人员组成以及联系方式(开发人员/版本控制人员/测试人员/软、硬、结构、营销人员等)

    2.任务概述

    2.1测试范围

    2.1测试目标

    2.3广义上还包含测试需求分析/测试用例编写/测试环境搭建/测试培训/测试执行等

    3.测试策略

    3.1测试人员需求、分工

    3.2测试方法(自动化测试/手动测试;白盒测试黑盒测试;中断测试/临界测试/压力测试等)

    3.3工具引用及测试培训(内训/外训)

    3.4测试阶段计划(工作内容、人员安排、起止时间等)

    3.5测试停止及恢复条件

    3.6测试文档及缺陷提交管理等

    3.7测试环境

    4.测试资源

    4.1硬件资源需求

    4.2软件资源需求

    4.3测试环境需求

    4.4测试人员需求

    4.5其他(仪器、服务器等)

    5.风险评估

    5.1人力方面;

    5.2时间方面;

    5.3环境方面;

    5.4资源方面

    5.5部门合作方面

    6.其他内容

    除以上内容有关项外,还要包括测试计划制定者、日期、修改记录、评审人员(开发负责人/测试负责人/项目经理)等信息

    三.编写测试计划注意事项:

    1.测试计划不一定要尽善尽美,但一定要切合实际,要根据项目特点、公司实际情况来编制,不能脱离实际情况;

    2.测试计划一旦制定下来,并不就是一层不变的,世界万事万物时时刻刻都在变化,软件需求、软件开发、人员流动等都在时刻发生着变化,测试计划也要根据实际情况的变化而不断进行调整,以满足实际测试要求.

    3.测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等,不一定要太过详细.

    四.评审总结

    1.计划评审

    测试计划编写完成后,一般要对测试计划的正确性、全面性以及可行性等进行评审,评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。

    2.计划总结

    项目完成后,应该对计划的执行情况进行评审,看有哪些不合理的地方,以便为编写下一个项目测试计划做经验积累。


  • 也谈测试的核心技术(转)

    2010-08-30 11:11:00

    标签:

    维度

    测试技术

    测试工具

    覆盖率

    单元测试

    it

    分类:测试技术基础
     测试这行的客观规律总的来说是:入门容易,提升难。有些人干测试8-9年了,其针对同一个产品的测试思路和方法,与干测试只有2-3年的人看不出有什么区别。于是行业中有了一种误区,认为测试技术的提升主要集中在对性能测试工具的使用及脚本开发,自动化测试开发,测试工具开发领域。仅个人愚见:测试工具开发和自动化测试开发主要还是开发技术而不是测试技术,从没有做过测试分析,测试设计的开发人员也能胜任。如果仅狭义地认为测试技术的发展只在自动化测试框架开发或测试工具开发上,那么从逻辑上来说,任何一个开发人员都可以成为测试技术大拿。当然我想:没有人会真正这么认为。

      就其我的感受而言,开发工作有时反而会简单一些。为什么呢?开发工作的目标从一开始是非常明确的,要实现什么要做什么做到什么程度大多数情况下都是清晰的,最大的困难则是如何实现如何做到,总的来说是一个不断聚焦的过程。而测试工作的目标呢?其实很多时候,并不如开发那么明确,例如:同样一个性能指标,开发很清楚要通过实现XX算法来达到目标;而测试则需要对该性能指标先进行测试分析,再进行测试设计,可是测试分析做到什么程度却是一个发散的过程, 2小时也可以,2天也不够,这就导致了测试质量的浮动范围是非常大的,由于开发和项目经理通常对测试设计并不了解,也无法了解(测试其实是一个专业度非常高的领域),因此会导致测试部的工作质量很难在过程中真正去度量和监督。

      从哲学上来说:确定性的规律往往难度不大;不确定性的规律往往说明它是一个复杂系统。因此,我个人认为:测试技术领域最难的技术应该是测试分析和设计。从另一个角度来看,测试价值的体现最主要还是保障自己组织开发的软件在关键应用时不要出故障,给组织造成商业损失。所以,有效的测试覆盖率是最重要的测试工作目标(而不是自动化测试率),需要说明的是测试覆盖率不等于代码覆盖率。通过单元测试达到代码覆盖率100%了就能保障产品无bug其实是一个误区,因为很多组织会为了达到单元覆盖率而去开发单元测试代码,单元测试代码或单元测试设计的质量只能保障消除产品编码的问题,发现产品设计的问题则往往会很困难。而发现产品设计问题的最主要方法还得需要基于黑盒的测试分析和设计。

      如何做好测试分析和测试设计,根据我的经验和体会,建议测试分析和测试设计主要通过3个维度来做,则可以大致达到一个比较高的有效测试覆盖率:

      维度一:从用户实际使用的场景和习惯入手,开发一批测试用例;

      优点:  可以覆盖到主要基本场景;

      不足:  从事场景分析的人无法做到了解用户所有的场景,必定受参与测试分析资源限制会有场景遗漏;

      维度二:通过测试对象内部实现流程的路径及依赖关系分析入手,开发一批测试用例;

      优点:可填补维度一的部分遗漏场景,特别是异常处理和分支交互处理的场景;

      不足:分析阶段主要精力会被局限在内部流程的熟悉和分析中,从而也会遗漏真实环境中的一些偶然小概率事件;

      维度三:依赖基于经验的测试分析和设计,例如:错误猜测法或探索性测试法;

      优点: 给维度二再做一次补充测试分析和设计;

      不足: 维度三效果的质量高低取决于组织内部经验的积累量及测试人员思维的发散能力和创造性;

      总得来说:无论是功能测试还是各种专项测试,依次使用以上3个维度的测试分析和设计,基本上能覆盖到被测对象的绝大部分应用场景,充分保障产品质量,减少问题遗漏。

      因此:测试的核心技术是测试分析和测试设计的能力,它决定了后续所有测试活动的质量及效果。同时,要做好一个测试任务,掌握广泛的测试类型也是必要的核心技术,如:如何给每个测试对象做细做深压力测试,长时间测试,健壮性测试也是决定项目测试质量的关键所在。我本人不相信随便做做的压力测试设计和健壮性测试设计能够保障产品实际应用表现良好。

      测试活动的质量或者一个测试工程师技术水平如何将主要取决于:测试分析和设计的深度及系统化,以及掌握广泛的专项测试类型。

      一家之言,仅供参考,欢迎大家继续讨论。

    版权声明:本文出自架构师Jack的51Testing软件测试博客:http://www.51testing.com/?293557

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

  • 系统测试全过程(转载)

    2010-03-31 14:58:00

    我一直感觉系统测试总像马拉松总是测试不完,什么时候上线,什么时候算终点。虽然提交客户了,可是对于质量仍然心里没底,对于测试的效果没有评价的依据。后来经过高人指点,终于领悟到至关重要的精髓:明确测试目标!
        如果要将系统进行全面测试,那么就要有一套完整的测试阶段,每个阶段都以测试目标为标准,科学、有序地进行测试,那么测试效率也就会自然而然跟着提高。
    测试阶段分为:测试前准备、需求分析、测试计划、测试设计、测试执行、测试结果。
    1.测试前准备阶段
    主要是相关业务的学习。业务知识是测试的根本依据,只有业务过关了,以后才能有效的进行测试工作
    了解业务步骤:
    a、了解业务名词;
    b、对现有系统的学习:功能点、业务场景等;
    c、分析现有系统数据库,了解数据的走向。

    2.需求分析阶段
    需求是项目开发的基础,也是测试的依据。所以需求分析一定要做。但是很多公司是没有详细的需求文档的,那如何进行需求分析呢?
    此时分析数据库就是一个非常好的方法:
    a、每张表的索引和约束条件;
    b、数据的来源、走向;
    c、数据的存储、变化;
    d、数据间的关联;
    e、表与表间的关系;
    这些分析都可以为了解业务场景和之后的测试用例设计打好基础。
    3.测试计划阶段
        我们总是觉得被测试进度紧逼、计划失控、测试不完全等等状态,其实解决这些情况的最好方法就是:制定测试目标。
        在计划初期先明确测试目标,制定不同层次目标的执行标准,指导后期设计不同级别的测试用例,跟踪不同级别的缺陷修改。在测试时间较紧情况下,至少可以先把保证所有功能正常操作的最低目标版本先提交给客户,不会再有手忙脚乱,心里没底的状况。
    测试目标分为:
                最低目标
                基本目标
                较高目标
                最高目标  等级别

    可以使用表格形式来规范目标准侧,例如:

    测试目标准则表

    目标
    测试范围
    需求覆盖率

    最低目标:正常的输入+正常的处理过程,有一个正确的输出
    (明确的功能点全部列出来)
    1.功能:

    正常功能

    异常功能

    单功能   

    业务场景

    非功能:16种测试类型
    2.输入覆盖率:

    有效无效

    处理过程:基本流

              备选流

    状态变化:正常、异常

    输出

    SRS00001

    SRS00002

    SRS00003

    基本目标:对异常的输入有错误的捕获,并进行相应提示或屏蔽
    较高目标:对隐式需求进行测试
    根据公司规模不同,确定测试目标级别也可不同。一般小公司有最低标、基本目标即可,大公司可以提高目标标准,直接从基本目标开始,直至最高目标。

    4.具体的ST用例的编写以及执行
    测试用例设计的粒度一直是个讨论对象,很多时候总会强调时间很紧啊,如果时间再多点,我的用例肯定会设计的再细一些!!
    是不是设计的越细就一定越好呢,不一定,测试是无穷尽的,使用穷举方法来进行测试是不科学的。
    因为制定了测试目标,那么就应该根据测试目标,在设计测试用例时也要制定设计用例目标。

    比如:按照最低目标选择测试用例
    输入—>有效
    处理—>有效
    输出—>有效
    按照最低目标的宗旨,只要是设计出来的测试用例足以覆盖和验证系统基本功能可以正常使用,那么这些测试用例的粒度就足够细了!从而提高了设计用例效率,同时也提高了测试效率。

    5.测试之后的评估
    实现一级测试目标之后都要进行评审工作,根据评审结果进行系统版本发布。例如:

    1.保证所有需求都有测试用例
    2.保证所有功能的正常操作和正常操作有对应的测试用例          V1.0版本
    3.保证所有功能的异常校验有对应的测试用例                    V2.0版本
    4.各功能组合形成的业务流有对应的测试用例                    V3.0版本
    5.各功能或整体软件所需满足的非功能性需求有对应的测试用例    V4.0版本

    这样做既可以对代码版本进行控制,也可以应对需求变更的问题。

        也许“确定测试目标”还不能彻底解决复杂测试工作中出现的问题,但是我觉得这最起码可以让你的测试工作变得有条理;跟领导汇报工作的时候业绩和工作效率有凭可据;面对需求变更的时候有理可依!
  • 验收测试点总结(转载)

    2009-04-02 11:33:46

    一.功能测试

      1. 安装测试:

      1) 安装过程中对于缺省安装目录及任意指定的安装目录,是否都能正确安装;

      2) 若是选择安装,查看能否实现其相应的功能;

      3) 在所有能中途退出安装的位置退出安装程序后,验证此程序并未安装成功(没有程序组及程序项产生);

      4) 软件安装后,对其它已经安装的软件是否有影响;

      5) 裸机安装后,各功能点是否可用;

      6) 安装前,安装程序是否判断可用磁盘空间大小,如果不能满足安装空间要求,安装程序能否继续;

      7) 安装过程中查看 版权声明、版本信息、公司名称、LOGO等是否符合标准;

      8) 安装过程中界面显示与提示语言是否准确、友好;

      9) 重复安装时系统是否有提示、是否可以覆盖安装、是否可以升级安装、是否允许多版本共存;

      10) 是否有注册码或硬件加密狗,在没有它们(或错误)存在的情况下能否顺利安装。

      2.配置测试

      1) 是否可以按照用户手册的说明,运行于多种操作系统Windows各版本 、Unix 、Linux等);

      2) 按系统最低要求进行软件的安装配置,查看能否正常实现各种功能;

      3) 数据源等信息配置不正确时能否给出提示信息;

      4) 是否可以按照用户手册的说明,支持多种数据库

      3. 卸载测试

      1) 卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉;

      2) 卸载过程中完全删除共享文件后,看其它程序能否正常运行;

      3) 卸载后,是否对其它已经安装的软件有影响;

      4) 系统卸载后用户建立文档是否保留;

      5) 软件卸载画面上的软件名称及版本信息是否正确;

      6) 在所有能中途退出卸载的位置是否能正确退出;

      7) 卸载过程中界面显示与提示语言是否准确、友好;

      8) 卸载后安装此系统能否打开原来保存的文件,并一切运行正常;

      9) 卸载程序如果要求重新启动机器,在重启动之间是否给用户提示以保存现有的己运行的程序的资料;

      10) 是否可以选择组件进行卸载;

      11) 卸载过程中,对意外情况的处理(掉电等)。

      12) 在卸载过程中,是否有终止或者结束按钮。

      4. 运行与关闭测试

      1) 运行时是否与其它应用程序有冲突(内存冲突);

      2) 是否可以同时运行多个程序;

      3) 任务栏有无程序运行提示;

      4) 若有未保存的数据,关闭系统时是否有提示;

      5) 后台服务程序在点击关闭按钮时是否有确认提示;

      6) 运行时是否过份占用系统资源、退出时能否完成释放占用的系统资源。

      5. 服务程序的测试:

      1) 系统是否限制服务器程序启动的数量,如不限制,同一范围内启动多个服务是否对系统有影响;

      2) 服务程序能否长时间正常运行;

      3) 外界异常后,服务程序的自动恢复能力(服务器掉电、网络中断后恢复、数据库异常后恢复…);

      4) 在点击关闭按钮时是否有确认提示;

      5) 应用程序与其他程序是否兼容(能否避免内存冲突)。

     6. 系统管理(参数设置)

      1) 参数设置后,能否正确的进行应用;

      2) 设置错误参数,系统的容错能力;

      3) 修改参数,对与之相关模块的影响;

      4) 系统是否有默认的参数,A 有:默认的参数是否起到作用 ;B 没有:不设置,系统能否运行或者给出提示。

      7. 用户、权限管理

      1) 赋予一个人员相应的权限后,在界面上看此人员是否具有此权限,并以此人员身份登陆,验证权限设置是否正确(能否超出所给予的权限);

      2) 删除或修改已经登陆系统并正在进行操作的人员的权限,程序能否正确处理;

      3) 重新注册系统变更登陆身份后再登录,看程序是否能正确执行,具有权限是否正确;

      4) 在有工作组或角色管理的情况下,删除包含用户的工作组或角色,程序能否正确处理;

      5) 不同权限用户登录同一个系统,权限范围是否正确;

      6) 覆盖系统所有权限设定;

      7) 能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令);

      8) 能否添加长用户名及长口令,如果允许,新用户能否正确登录;

      9) 系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令,删除或修改后系统的实际情况;

      10) 登录用户能否修改自己的权限;

      11) 添加用户(有标识或编号):标识相同,用户名不同;标识相同,用户名相同;标识不同,用户名相同;标识不同,用户名不同;

      12) 登录用户能否修改本人(或其他人)的信息,删除本人(或其他人);

      13) 修改用户的信息(包括权限,口令,基本信息等),对其他模块的影响;

      14) 修改用户信息:修改后的用户信息和已经存在的用户信息相同;修改后的用户信息和已经存在的用户信息不同;

      15) 不给用户授权,是否允许登录;

      15) 改某些设置时,是否会影响具有上级权限及相同权限人员的设置;

      16) 系统管理员修改了某些数据,以其他人员身份登录时数据是否改变;

      17) 用户能否同时属于多个组,各个组的权限能否交叉;

      18) 删除后重新添加的用户是否具有以前的权限;更改用户各项属性(包括权限)看对权限是否有影响。

      8. 系统登录测试

      1) 使用合法用户登录系统;

      2) 用户名、口令错误或漏填时能否登陆;

      3) 系统是否容许多次非法登陆,是否有次数限制;

      4) 使用已登录账号登录系统系统能否正确处理;

      5) 使用禁用帐号登陆系统能否正确处理;

      6) 删除或修改后的用户用原用户登录;

      7) 不输入用户名和口令,重复点“确定”和“取消”按钮,是否允许登录。

      9. 注销

      1) 注销为原模块、新模块系统能否正确处理;

      2) 中止注销能否返回原模块、原用户;

      3) 注销为原用户、新用户系统能否正确处理;

      4) 使用错误的帐号、口令或无权限帐号、被禁用帐号进行注销。

      10. 修改口令

      1) 正常情况;

      2) 输入错误的原口令或新口令与确认口令不一致系统能否正确处理;

      3) 修改口令后,用原口令是否能登录(同时验证新口令是否有效);

      4) 是否能修改其它用户的口令。

      11. 右键功能

      1) 右键菜单中的功能是否与菜单(或工具栏)中对应的功能一致;

      2) 右键菜单中的功能能否正确实现;

      3) 同一菜单下的热键是否相同。

      12. 记录列表

      1) 增加重复记录、空白记录,系统能否正确处理;

      2) 修改后不保存(有保存按钮),系统能否正确处理;

      3) 删除或修改正在使用信息,系统能否正确处理;

      4) 删除级联记录的上游或下游记录,系统能否正确处理;

      5) 删除记录时是否有提示;

      6) 记录中包含的缺省系统信息能否删除和修改;

      7) 记录列表能否及时反应记录的变化;

      8) 记录变化之后系统相关信息能否及时更新;

      13. 统计、查询

      1) 对非法的时间范围系统能否正确处理;

      2) 统计查询语句包含多个与或非条件时,系统能否正确处理;

      3) 条件逻辑混乱,系统能否正确处理;

      4) 多表查询统计及单表查询统计功能是否正确实现;

      5) 分类查询、精确查询、无条件查询、组合查询能否完整列出满足条件的记录;

      6) 能否按系统默认的条件进行查询;

      7) 当统计时间段为当日、跨日、跨月、跨季、跨年度时,统计查询结果是否正确;

      8) 当某些操作被别人取消后,设置条件段为取消前、取消后、包含取消操作的一段时间;

      9) 以不同的权限登录时,统计、查询是否正确;

      10) 在查询或统计大数据量时,系统是否允许终止操作;

      11) 查询、统计按钮是否允许双击或更多的点击,系统做何反映;

      12) 查询出的数据是否允许修改。

      14. 文件操作

      a、保存

      1) 文件是否能够正确保存在在缺省位置或指定位置(本地、网络);

      2) 系统能否正确处理长文件名、特殊字符文件名保存;

      3) 文件能否保存为其它扩展名;

      4) 如应用程序对文件名区分大小写,当这些文件在导出到介质中时,系统能否正确处理;

      5) 介质空间已满时,系统是否给出提示。

      b、打开

      1) 打开文件是否正确显示上一次保存的内容;

      2) 系统能否正确处理非系统默认扩展名的文件;

      3) 文件能否被其他程序正确打开;

      4) 打开对话框中,是否有默认扩展名的文件类型;

      5) 打开对话框时,是否有默认的路径。

      c、打印输出

      1) 是否按所设置的格式打印;

      2) 是否有打印预览,能否设置打印字体,打印效果是否合乎客户要求;

      3) 打印预览的内容是否正确,内容是否能够进行拖拽操作,是否影响实际的打印;

      4) 安装或不安装打印功能模块,对其它模块是否有影响;

      5) 打印机未安装系统有无提示;

      6) 打印中途能否进行正常的打印中断,是否可以选择打印的内容。

      7) 能否进行本地或网络打印。

      d、导入、导出功能

      1) 导入的文件格式非要求时,系统如何处理;

      2) 导入、导出的有效文件能否完整正确地显示并被使用;

      3) 导出后的文件是否允许修改,如果允许,导入后能否使用;如不允许,系统有何限制;

      4) 导入,导出是否可以选择路径;

      5) 在客户端和服务器端进行导入,导出;

      6) 在客户端和客户端之间进行导入,导出;

      7) 在本地进行导入,导出;

      8) 不同文件格式的导入,导出。

      e、检入与检出

      1) 单文件、多文件检入与检出;

      2) 能否多次检入与检出;

      3) 文件检出后其它人能对其做何操作。

    二.性能测试

      具体用例不好设计,下面列出了一些有性能要求的测试点:

      1) 查询

      2) 保存

      3) 统计

      4) 刷新

      5) 显示

      6) 传输

      7) 响应

      8) 下载

      打开网络上其它介质上的文件时,可制造网络拥挤情况下的文件打开操作。主要测试点,集中在几个点上。一是数据量小的时候主要的查询统计刷新等功能点;二是数据量积累到一定程度时的查询统计刷新时间,这里的一定程度是根据实际的项目和客户需求来定的。

      三.极限压力测试

      1) 接收大数据量的数据文件时间;

      2) 大数据恢复时间;

      3) 大数据导入导出时间;

      4) 大批量录入数据时间;

      5) 大数据量的计算时间;

      6) 多客户机同时进行某一个提交操作;

      7) 采用测试工具软件;

      8) 编写测试脚本程序;

      9) 大数据量的查询统计时间。

      四. 容错测试

      1) 通过断开网线的强制性停止数据传输以及重新将网线接上,查看提示信息及对系统的影响;

      2) 系统断电,恢复后查看对系统的影响程度;

      3) 死机后,看程序如何处理;

      4) 服务器DOWN掉,客户端程序如何处理。

      五.并发测试

      1) 登录的并发操作:多人同时登录系统,使用不同或相同账号;

      2) 提交的并发操作:多人同时提交相同的工作项、不同的工作项;

      3) 对数据库操作的并发操作:多人同时从数据库中读出(或向数据库导入) 相同文件、不同文件。

    ************************

      附:一些容易出错的地方

      ************************

      一. 有关新建和修改

      1. 创建或修改的内容为已经存在的内容,系统是否有提示;

      2. 修改正在使用的数据。

      二. 删除

      1. 应有确认提示;

      2. 若删除的内容在文件或数据库中,应作实际校验;

      3. 删除正在使用的数据;

      4. 考虑删除数据的相关数据是否同时被删除;

      5. 重新使用已删除的数据。

      三.关于提示信息的验证

      有些操作系统会给出成功(有时没有成功提示)或失败的提示,一定要验证提示的正确性(尤其是一些重要操作,如修改口令),即用其它方法检查所作的操作是否真正成功或失败。

      四.关于考虑硬盘空间已满的情况

      1. 数据存储和备份;

      2. 生成文件;

      3. 拷贝文件

      五.关于修改系统时间

      对于和时间有关的业务,测试时考虑修改系统时间对系统的影响。

      六.对于响应速度慢的按钮进行连续点击;或中途取消,再继续…

      七.凡是支持并发过程的功能,一定要做并发测试(手工进行或利用工具);

      八.打印功能(能否正确打印,打印效果与预览是否一致)

      九.系统初始化

      1) 如果系统安装后需要进行初始化,初始化过程是否正确;

      2) 如果系统安装后不需要进行初始化,安装后的默认设置是否正确、适当。

      十.版权声明是否符合标准,如果有公司的logo,图标是否正确(最容易测试的地方,也是最容易被忽略的地方)

      十一.如果捆绑硬件,如果可能的话,在测试我们的软件产品前要对硬件的性能、稳定性进行严格测试。(包括大数据量的传输入等)

      十二.备份与恢复

      1) 备份与恢复过程本身的正确性;

      2) 备份内容的正确性(通过事先准备的测试数据在恢复后验证);

      3) 备份与恢复过程中对异常情况的处理(掉电、网络不通等);

      4) 在原始机上的恢复;

      5) 在非原始机上的恢复;

      6) 在裸机(只有操作系统和必要的数据库或第三方产品)上的恢复;

      7) 在一台机器上进行若干次的备份与恢复;

      8) 如果是支持多数据库的软件,备份与恢复是容易出错的地方。

      需要严格把握的错误类别:

      在整个测试过程中对每条问题都制定有错误归类,现按照问题的严重程度,把问题主要分为四类:

      A:严重影响系统运行:导致系统出现不可预料的严重错误的问题,例如:运行过程中出现页面或页面无法显示、死机等;

      B:影响系统运行:系统中重要的功能出现运行错误,例如:导致用户必须重新登录的问题,导致个别用户不可用的问题;

      C:不影响系统运行但必须修改:系统中基本的操作或功能没有实现或实现有误的问题,以及不符合常规的操作界面的问题;

      D:所提建议:不影响系统运行,对系统的可用性等提示的建议性的问题。

  • 如何写出高质量的Bug单(转)

    2009-03-11 11:16:12

    如何写出高质量的Bug单

      程序员是否经常让你在Bug单上再提供一些更多的信息?当Bug单提交后,你是否经常会再花很多时间来研究如何重现这个Bug?你是否经常听到开发人员说Bug在开发环境下无法重现?问题在于Bug单的质量不高,我们应该花更多的时间在研究如何测试系统上,而不是花更多的时间在Bug单上,本文就如何写出高质量的Bug单提出了一些建议。

      为什么要写Bug单

      当我们发现Bug后,需要通知开发人员,Bug单是一种沟通的介质,它的主要目的是让开发人员能够亲眼看到这个Bug是什么,如果不提供足够详细的说明来帮助开发人员重现Bug,那么他们就没法确定问题的根源。Bug单是一种用来说明期望结果和实际结果之间的差异以及描述bug如何重现的文档。

      发现Bug后应该做什么

      · 最好是一发现并确认了bug就立即填写Bug单,而不要等到当天测试结束再和其他bug一起填,因为那时就有可能遗漏一些要点,甚至是遗漏某个bug。

      · 花点时间分析一下造成Bug的根本原因是什么,你可能会因此发现更多的Bug,最好能把你的任何有用的证据都写到Bug单上。

      · Bug单提交之前自己再读一遍,可能会有错别字或者什么写错的地方需要重写。

      下面将谈到填写Bug单时应注意的几个地方:

      摘要(概述)

      Bug单的“摘要”部分是一个Bug单带给读者的最初印象,它在浏览大量Bug时起着非常重要的作用,每个Bug单都应该有一个能够突出重点的“摘要”,就好像做广告一样。好的摘要应该控制在50~60个字符以内(一个汉字算两个字符),而且不要夹杂任何主观色彩的文字。

      措辞

      · 要据实反应情况,不要夸大或缩小Bug的影响。

      · 有时候会发现一些令人不可思议的低级Bug,但还是要尽量使用较为委婉的词语来表述,免得伤害开发人员的自尊心。

      · 描述越简单直接越好,我们不是在写论文或散文,所以不要把Bug单搞得那么复杂难懂。

      · 要考虑到目标读者,他们可能是开发人员、测试人员、管理人员或者其他人,甚至是客户,所以要让目标读者都能看得懂Bug描述。

      重现的步骤

      · 每一步以及所有步骤组合起来应该是符合逻辑的。

      · 清晰地列出所需的前置条件。

      · 描述一般性的步骤,例如,某一步骤需要用户新建一个文件并给它命名,那就不要写“新建一个名为Mike’s File的文件”,而最好写成“新建一个测试文件TestFile”。

      · 步骤应尽量详细,例如,我们要描述通过MS WORD保存一个文档,那么有两种方式,一是说得细点儿,即“从[文件]菜单里单击[保存],……”,另一种就是说得简单点,即“保存文档”,但请记住,并非所有人都知道如何从MS WORD保存文档,或者说所有人都会使用同样的方式保存文档,所以描述的时候最好还是采用第一种方式。

      · 写完之后自己用新的测试数据或者在新的系统上按照步骤亲自执行一遍,或许能够发现Bug单里有一些是遗漏的或多余的步骤。

      测试数据

      开发人员重现Bug时可能不会访问测试环境,有些Bug可能只能用一定的测试数据才能重现,所以尽量把测试数据附在Bug单上。

      屏幕截图

      屏幕截图是Bug单里非常重要的组成部分,有时一张图能胜过千言万语,但也不能养成习惯不管有用没用的图都往上贴,或者是只贴图而缺少文字描述。附图能够使开发人员结合你的描述快速地重现Bug是最理想的:

      · 所附图片的尺寸和占用空间不要太大,尽量用jpg或gif格式,而不要用bmp格式。

      · 在图中出问题的地方标注一下,更利于开发人员快速定位。

      严重级/优先级

      · 设置Bug的严重级之前,应该全面地分析Bug的影响,如果我们认为这个Bug的优先级很高,那么应该在Bug单里说明优先级高的原因。

      · 如果Bug是由于程序版本恢复到上一版而产生的,那么不管它的严重级如何,它的优先级应该置成“高”。

      日志

      如果可以的话一定要把程序报错的日志附上,这会让开发人员比较容易进行分析和调试。很多不能重现的Bug都是因为缺少日志,开发人员就会返回去找测试人员要日志信息。如果日志文件不大的话,比如十几行,那么可以直接把日志信息粘到Bug单里,如果日志很大的话,那么最好单独粘到一个文件里,如txt格式的,然后当作Bug单的附件就可以了。

  • 【转载】伟大骡子的一生和性能测试

    2008-10-07 14:16:53

    有一个农夫决定买一匹骡子,他认为这个骡子至少得能扛动3袋大米,他才会决定买这匹骡子(用户提出的性能需求)。51Testing软件测试网7E;}-mFm\-ND2y

    %@ N6{;O@4e0他来到农贸集市上,试了好几头骡子,都不合适,最后终于有一头骡子能够比较轻松的扛动这3袋大米,而且还潇洒的走了几步(性能测试通过)。
    %r bHi*m:h051Testing软件测试网 x:Mr kvt2H.t2j`
    农夫想看看这头骡子到底能拉多少大米,于是一袋袋的往骡子身上加,加到第7袋的时候,骡子双腿打颤,卖骡子的心疼起来,立刻制止,农夫满意的买下了这头骡子。(容量测试通过)51Testing软件测试网2] ?&K `g?!~ F

    9M%g!]r dq/tXP0农夫高高兴兴地牵着这头骡子回家,而且给它扛了4袋大米(系统超负荷运行),因为他跑了太远才买到了这匹不可多得的骡子,他想看看它到底能有多强,所以农夫决定,让这匹骡子就扛着这四袋大米走回家试试看.(在超负荷情况下检验系统能正常运行多久,进入压力测试
    XW$O;Jh!w4\0
    |)x"Eb7m*A,YI+U'w0这匹骡子真的很厉害,刚开始的时候还一颠一跑的,可是家离集市有5公里,骡子越驮越费劲。快到家的时候,已经是走两步歇一步了。终于到家了。(压力测试通过)51Testing软件测试网(w5c*L {7m4e!]Wc4h"Z

    7Hwg A"Qy:^0农 夫非常自豪地叫出自己的老婆,说:“老婆子,快来看看,看我买到了一头多么厉害的骡子啊!”,老婆出来后,农夫把他和骡子在一路上的经历都告诉了老太婆, 谁知这个老太婆却说:“你真蠢,这么大老远的路,也不让骡子驮着你,竟然和这头傻骡子一样走回来!”,农夫听了,觉得非常后悔,说:“那好吧,既然在路上 它没有驮我,那就让它现在补上,也算是对我的补偿。”,骡子还没有反应过来,就看那老农夫一个箭步,跳到了骡子背上(这相当于容量测试的极限点),可怜的 骡子,无论如何也不会想到,这狠心的农夫竟然在它走了这么久之后,不但没有帮它卸掉身上的重担,更没有给它喝口水,竟然变本加厉的跳到了它那本已弯曲的背 上。可怜的骡子啊,就这么一命呜乎了!就看见那个骡子、农夫和4袋麦子一起轰然倒地。(相当于已经到了系统的最大拐点,造成了系统瘫痪,无法使用)。
  • 几种操作方法测试案例编写标准

    2008-09-03 11:00:19

    1.1查询
    1.1.1关注点

    1.
    单个条件

    2.
    组合条件

    3.
    空查询

    4.
    无效查询

    5.
    模糊查询

    6.
    精确查询

    1.1.2数据要求

    1.
    要求输入查询条件的数据涵盖:

    A.
    有效的查询条件

    B.
    无效/非法的查询条件

    2.
    要求查询输出的结果数据涵盖:

    A.
    多条记录

    B.
    一条记录

    C.
    无记录

    1.1.3提示信息错误查询的提示信息。
    1.1.4备注

    对于有输入/输出限制的查询测试用例来说,还从以下角度考虑:

    1.
    在限制之内的情况

    2.
    在限制之外的情况

    3.
    临界情况下的情况

    4.
    在特殊字符情况下的情况

    5.
    以特殊字符开始情况下的情况

    6.
    与限制情况相反的情况下的情况

    7.
    查询的记录与原记录真实性的对比

    1.2创建
    1.2.1关注点:

    1.
    权限的控制(有/无权限)

    2.
    创建成功

    3.
    创建失败

    1.2.2数据要求

    N/A

    1.2.3备注

    N/A

    1.2.4提示信息

    1.
    成功的提示信息

    2.
    失败的提示信息

    1.3保存
    1.3.1关注点:

    1.
    权限的控制

    2.
    成功的用例

    3.
    失败的用例

    1.3.2数据要求:

    N/A

    1.3.3信息对比

    与输入的一致性。

    1.3.4提示信息

    1.
    含有重复记录的提示。

    2.
    保存成功的提示。

    1.3.5 备注

    N/A

    1.4删除
    1.4.1关注点:

    1.
    成功操作情况(根据业务流程)

    2.
    失败操作情况(异常进行的业务流程)

    3.
    根据业务规定能否成批实现(能/否)

    4.
    权限控制

    1.4.2数据要求:

    1.
    允许进行该操作的业务数据

    2.
    不允许进行该操作的业务数据

    1.4.3提示信息

    1.
    删除成功时提示信息。

    2.
    不能删除时提示信息。

    1.4.4信息对比

    记录被成功删除后与原记录的对比。

    1.4.5备注

    N/A

    1.5业务处理
    1.5.1关注点:

    对于新增加的业务处理,根据业务处理的一般规则,设计用例:

    1.
    按照正常业务流程处理

    2.
    非正常业务流程处理

    3.
    突发性事故处理(如操作突然中断等)

    对于在原有基础上修改的业务处理,根据新旧不同的业务处理规则,设计用例:

    1.
    按照旧业务规则处理下的情况

    2.
    按照新业务规则处理下的情况

    对于业务按状态排列, 设计用例:

    1.
    按照正常业务,业务的排列顺序

    2.
    非正常业务流程处理,业务的排列顺序

    3.
    新增业务后,业务的排列顺序

    4.
    修改业务后,业务的排列顺序

    5.
    删除业务后,业务的排列顺序

    按照对业务的限制, 设计用例:

    1.
    同时操作业务的数量

    2.
    业务最大显示数量

    在处理业务过程中,系统死掉或断电等其他异常情况,数据的处理

    1.5.2数据要求:

    1.
    符合业务逻辑的数据

    2.
    非法数据

    1.5.3提示信息

    1.
    业务成功的提示

    2.
    业务失败的提示

    3.
    业务不能成功进行的提示


    1.5.4备注

    跨模块的业务操作发生时,考虑对涉及到的模块的影响,需要从以下角度考虑:

    1.
    正常操作对涉及到的其他模块的影响

    2.
    无效操作对涉及到的其他模块的影响

    3.
    突发性事故对涉及到的其他模块的影响

    1.6打印/传送
    1.6.1关注点:

    1.
    打印/传送的实现情况

    2.
    成功打印/传送后与打印/传送前的对比

    3.
    打印/传送的速度

    4.
    传送的容量

    5.
    数据传递的有效程度

    6.
    在打印/传送过程中,系统死掉或断电等其他异常情况,数据的处理

    1.6.2数据要求

    1.
    能进行打印/传送的业务数据

    2.
    不能进行打印/传送的业务数据

    1.6.3备注

    N/A

    1.7导入/导出
    1.7.1关注点:

    1.
    导入/导出的速度

    2.
    导入/导出的最大容量

    3.
    导入/导出后数据与原数据的对比

    4.
    在导入/导出时,系统死掉或断电等其他异常情况,数据的处理

    1.7.2数据要求

    1.
    能进行导入/导出的业务数据

    2.
    不能进行导入/导出的业务数据

    1.7.3信息提示

    1.
    成功导入/导出后的提示

    2.
    未能成功导入/导出后的提示

    1.7.4备注

    N/A

    2易操作性
    2.1关注点:

    是否符合大众的使用习惯。

    2.2数据要求

    N/A

    2.3备注

    N/A

    3界面规范
    3.1关注点:

    1.
    是否整个软件的字段的字体、大小、颜色、排列一致

    2.
    是否整个软件的字段后都有冒号(如果有,是否都属于同一种字体)

    4.
    用例编写粒度准则

    1.
    对于不作为一个完整业务流的操作,如增、删、改等,每个操作(比如增加)作为一个用例。

    2.
    对于完整的业务功能实现的操作,把实现一个业务功能的目的作为一个用例。

    3.
    对于紧密关联的业务功能,把关联的业务功能实现作为一个用例。

    4.
    对于异常情况下的操作,作为一个用例。

    5.
    对于在异常情况下的操作的数据处理,作为一个用例。

  • 软件测试的14种类型(zz)

    2008-09-03 10:59:38

    软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

    1 数据和数据库完整性测试

    数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
    数据库完整性原即:
    主码完整性:主码不能为空;
    外码完整性:外码必须等于对应的主码或者为空。
    数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。
    在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。

    比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员 工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整 性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。
    员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。


    2 白盒测试

    白盒测试是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
    2.1 静态白盒测试
    利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下:
    Function NameGet(){
    ….
    }
    这是属于不符合开发规范的错误。
    有这样一段代码:
    if (i<0) & (i>=0)

    这段代码交集为整个数轴,IF语句没有必要
    I=0;
    while(I>100){
    J=J+100;
    T=J*PI;
    }
    在循环体内没有I的增加,bug产生。

    2.2 动态白盒测试
    利用开发工具中的调式工具进行测试。比如一段代码有4个分支,输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
    看一段代码
    if(I<0){
    P1
    }else{
    P2
    }
    在调试中输入I=-1,P1程序段通过, P2程序段未通过,属于动态黑盒测试的缺陷

    3.功能测试

    功能测试指测试软件各个功能模块是否正确,逻辑是否正确。
    对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及 业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应 用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
    比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。

    4.UI测试

    UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等
    用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功 能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观, 与测试人员的喜好有关
    比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

    5.性能测试

    性能测试主要测试软件测试的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试
    5.1负载测试
    负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
    在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确 定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
    比如,在B/S结构中用户并发量测试就是属于负载测试的用户,可以使用webload工具,模拟上百人客户同时访问网站,看系统响应时间,处理速度如何?
    5.2强度测试
    强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
    实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的 缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
    比如:一个系统在内存366M下可以正常运行,但是降低到258M下不可以运行,告诉内存不足,这个系统对内存的要求就是366M。
    5.3数据库容量测试
    数据库容量测试指通过存储过程往数据库表中插入一定数量的数据,看看相关页面是否能够及时显示数据。
    数据库容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负 载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正 确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录,计算相关页面的调用时间。
    比如,在电子商务系统中,通过insert customer 往user表中插入10 000数据,看其是否可以正常显示顾客信息列表页 面,如果要求达到最多可以处理100 000个客户,但是顾客信息列表页面不能够在规定的时间内显示出来,就需要调整程序中的SQL查询语句;如果在规定 的时间内显示出来,可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
    5.4基准测试
    基准测试与已知现有的系统进行比较,主要检验是否与类似的产品具有竞争性的一种测试。
    如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据,你可以测试你这套系统,看看哪些地方比用友财务系统好,哪些地方差?以便改进自己的系统,也可为产品广告提供数据。
    5.5竞争测试
    软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。比如:一台机器上即安装您的财务系统,又安装用友财务系统。当CPU占有率下降后,看看是否能够强过用友财务系统,而是自己的系统能够正常运行?

    6. 安全性和访问控制测试

    安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问
    系统级别的安全性,包括对系统的登录或远程访问。
    6.1应用程序级别的安全性
    可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管 理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客 户的统计数据。
    比如B/S系统,不通过登入页面,直接输入URL,看其是否能够进入系统?
    6.2系统级别的安全性
    可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
    比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

    7.故障转移和恢复测试

    故障转移和恢复测试指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统是否可以正常运行,这对于电信,银行等领域的软件是十分重要的。
    故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。 
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输 出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。一定要 注意主备定时备份
    比如电信系统,突然主机程序发生死机,备份机器是否能够启动,使系统能够正常运行,从而不影响用户打电话。

    8.配置测试

    又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器 的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的 资源。(如浏览器版本,操作系统版本等)
    下面列出主要配置测试
    8.1浏览器兼容性
    测试软件在不同产商的浏览器下是否能够正确显示与运行;
    比如测试IE,Natscape浏览器下是否可以运行这套软件?
    8.2操作系统兼容性
    测试软件在不同操作系统下是否能够正确显示与运行;
    比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?
    8.3硬件兼容性
    测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用.
    比如在INTER,舒龙CPU芯片下系统是否能够正常运行?
    这样的测试必须建立测试实验室,在各种环境下进行测试。

    9.安装测试

    安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都 能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
    安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    10.多语种测试

    又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
    本地化测试还要考虑:
    l 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
    l 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。
    l 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征。

    11.文字测试

    文字测试测试软件中是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否有出入等等,包括图片文字。
    比如:“比如,请输入正确的证件号码!”何谓正确的证件号码,证件可以为身份证,驾驶证,也可为军官证,如果改为“请输入正确的身份证号码!”用户就比较容易理解了。

    12.分辨率测试

    测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    13发布测试

    主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试
    13.1说明书测试
    主要为语言检查,功能检查,图片检查
    语言检查:检查说明书语言是否正确,用词是否易于理解;
    功能检查:功能是否描述完全,或者描述了并没有的功能等;
    图片检查::检查图片是否正确
    13.2宣传材料测试
    主要测试产品中的附带的宣传材料中的语言,描述功能,图片
    13.3帮助文件测试
    帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能。
    13.4广告用语
    产品出公司前的广告材料文字,功能,图片,人性化的检查

    14 文档审核测试

    文档审核测试目前越来越引起人们的重视,软件质量不是检查出来的,而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料:
    文档审核测试主要包括需求文档测试,设计文档测试,为前置软件测试测试中的一部分。
    14.1需求文档测试
    主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;
    14.2设计文档测试
    测试设计是否符合全部需求以及设计是否合理。

    总结

    据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计,得出这样一个结论:软件缺陷在开发前期发现比在开发后期发现资金,人 力上节约90%;软件缺陷在推向市场前发现比在推出后发现资金,人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件 测试的,可以根据产品的具体情况进行组装测试不同的类型。

    参考文献
    《Rational统一过程模型》
    《软件测试》
  • 面试题目z

    2008-09-03 10:58:46

    软件测试专业网站:51Testing软件测试网W:gdo:o
    01. 为什么要在一个团队中开展软件测试工作
    u x X&Lcf'Y136894因 为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工 作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。
    CG)P:d-g:L4U13689402. 您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?软件测试专业网站:51Testing软件测试网 h DQ-_ Zk
    我曾经做过web测试,后台测试,客户端软件,其中包括功能测试性能测试,用户体验测试。最擅长的是功能测试
    G'g6k TC {Z#I"A13689403. 您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同04. 的测试类型的区别与联系(如功能测试、性能测试……)
    I]xk'e](q7p"et136894测试类型有:功能测试,性能测试,界面测试。
    L ]^e3G Ii136894功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。 软件测试专业网站:51Testing软件测试网,B:Pp Sd X'b9u
    性能测试是通过自动化测试工具模 拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作 负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供 的最大服务级别的测试。软件测试专业网站:51Testing软件测试网}.Q3G@-i0{{Y F
    界 面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。 同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实 用强大的功能都可能在用户的畏惧与放弃中付诸东流。
    ,QD-R H$d136894区 别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界 面测试更关注于用户体验上,用户使用该产品的时候是否易用,是否易懂,是否规范(快捷键之类的),是否美观(能否吸引用户的注意力),是否安全(尽量在前 台避免用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)?做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没问题 的,然后再考虑该功能点的性能测试
    QY Y&l |.}cn13689405.  请试着比较一下黑盒测试、白盒测试单元测试、集成测试、系统测试、验收测试的区别与联系。
    D^G n*~"a2~'J(c136894黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。
    NR;|Z2S*p-WcR136894白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。
    C8N6]-A7Cu&{136894   软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的 需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误:软件测试专业网站:51Testing软件测试网K\r!i*O m*~K+q9|
    1、是否有不正确或遗漏的功能?
    9c,NR8nn1368942、在接口上,输入是否能正确的接受?能否输出正确的结果?
    b&z[]^t h1368943、是否有数据结构错误或外部信息(例如数据文件)访问错误?
    0eXSd'`,i"z4@Z1368944、性能上是否能够满足要求?软件测试专业网站:51Testing软件测试网`"N]4g4E+G s;V5]\se
    5、是否有初始化或终止性错误?软件测试专业网站:51Testing软件测试网m:~c/WI \
       软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或 选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。 白盒测试主要是想对程序模块进行如下检查:
    {]J-fc%v b1368941、对程序模块的所有独立的执行路径至少测试一遍。软件测试专业网站:51Testing软件测试网9^ur+KD.n x
    2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。软件测试专业网站:51Testing软件测试网`!j&AN)M
    3、在循环的边界和运行的界限内执行循环体。
    6A)S0`0K9WTf1368944、测试内部数据结构的有效性,等等。软件测试专业网站:51Testing软件测试网n/|)V|5r&YRn2e`6U
    单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
    9y8u;?E5?)D136894      单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
    X6r8]6a%Cb136894集 成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意 义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将 您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。
    o Lk&RO m136894系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)软件测试专业网站:51Testing软件测试网 {!l2J#j C#gdI Y
           系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。软件测试专业网站:51Testing软件测试网&avk} \5{ a%J7f
    验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。软件测试专业网站:51Testing软件测试网l&K+F6Tb,C pX
    验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。
    %TL.lX"KI{13689406. 测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?
    +d&|,oZ,H+OO`"m136894软 件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助 软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中 的各种变更。软件测试专业网站:51Testing软件测试网 J:v/{7a Y.Ul
    测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)软件测试专业网站:51Testing软件测试网s;C*zD pj9S }cE
    07. 您认为做好测试计划工作的关键是什么?软件测试专业网站:51Testing软件测试网f(a _!Mt}1^)J
    1. 明确测试的目标,增强测试计划的实用性软件测试专业网站:51Testing软件测试网#C"nv N ] L
    编 写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软 件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
    N+z%wB!h9q;?tY1368942.坚持“5W”规则,明确内容与过程
    &Z({/~l7K[136894“5W” 规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规 则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的 方法和工具(How),给出测试文档和软件的存放位置(Where)。软件测试专业网站:51Testing软件测试网2\A1?+T$\8A6\'iLCZd
    3.采用评审和更新机制,保证测试计划满足实际需求
    :ln([#?q3I136894测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
    qSX:r}+}.wz*u1368944. 分别创建测试计划与测试详细规格、测试用例
    :]*{-I x mLO136894应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。 软件测试专业网站:51Testing软件测试网3xF ?+e%@.o~%Q~yW
    08. 您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。软件测试专业网站:51Testing软件测试网0P)^|-RS$C^
    1.等价类划分
    ,V n#f(oPM136894划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
    t8H;B`9W4S1368942.边界值分析法软件测试专业网站:51Testing软件测试网c'dM C _)y
      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.软件测试专业网站:51Testing软件测试网8j R!NC+[
      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.软件测试专业网站:51Testing软件测试网;K|,|yHI)SB"l
    3.错误推测法软件测试专业网站:51Testing软件测试网L!L:Z QR V9V
      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.软件测试专业网站:51Testing软件测试网z I{BuE
       错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块 中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一 行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.软件测试专业网站:51Testing软件测试网:PZj3b;s/H*W/MS
    4.因果图方法
    ;z:F@Vm%V"[N136894   前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会 产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一 种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表.  它适合于检查程序输入条件的各种组合情况. 软件测试专业网站:51Testing软件测试网(@5hV(_&R+bK[ ]
    08.您认为做好测试用例设计工作的关键是什么?
    h5M:~)~w/k.K$f136894白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果软件测试专业网站:51Testing软件测试网Pv S0U r-}&q%wU
    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题软件测试专业网站:51Testing软件测试网kMg]Y#n
    09. 请以您以往的实际工作为例,10. 详细的描述一次测试用例设计的完整的过程。软件测试专业网站:51Testing软件测试网8|X1d&D;e ^DU
    就说最近的这次网站功能的测试吧
    8~.B1{,gM3]+Pl136894首先:得到相关文档(需求文档和设计文档),理解需求和设计设计思想后,想好测试策略(测试计划简单点就OK了),考虑到测试环境,测试用例,测试时间等问题。
    t$C N-Hq,\g*i136894第 二步:设计测试用例,测试策略是:把网站部分的功能点测试完,然后在进行系统测试(另外个模块呢有另一个测试人员负责,可以进行联调测试),网站模块的测 试基本是功能测试和界面测试(用户并发的可能性很小,所以不考虑):这次的网站的输入数据呢是使用数据库中的某张表记录,如果表中某一数据记录中新加进来 的(还没有被处理的,有个标志位),网站启动后会立刻去刷那张表,得到多条数据,然后在进行处理。处理过程中,会经历3个步骤,网站才算完成了它的任务。 有3个步骤呢,就可以分别对这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况(包括数据库中的数据,用户的输入等),得出了差不多50个用例。界面 测试,也就是用户看的到的地方,包括发送的邮件和用户填写资料的页面展示。软件测试专业网站:51Testing软件测试网h8Y7ihz0X)~%v
    第 三步:搭建测试环境(为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟了,只有有机器能空于下来做该功能测试就可以做了),因为网站本身的环境搭 建和其他的系统有点不同,它需要的测试环境比较麻烦,需要web服务器(Apache,tomcat),不过这次需求呢,网站部分只用到了tomcat, 所以只要有tomcat即可
    UeI:[4r3wb cZ)r136894第四步:执行测试
    YzM;j~~LE13689411. 您以往是否曾经从事过性能测试工作?如果有,12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
    i N/KZY ?!{136894是的,曾经做过网站方面的性能测试,虽然做的时间并不久(2个月吧),当时呢,是有位网站性能测试经验非常丰富的前辈带着我一起做。软件测试专业网站:51Testing软件测试网;e(G5^ @ KM9M|
    性能测试类型包括负载测试,强度测试,容量测试等软件测试专业网站:51Testing软件测试网7@],P&[6~LFJ
          负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。软件测试专业网站:51Testing软件测试网t8b0@{1Z W Y%[
          强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。软件测试专业网站:51Testing软件测试网"C}0` z+bxr0L&^;{5c
          容量测试:确定系统可处理同时在线的最大用户数   软件测试专业网站:51Testing软件测试网'^'o&h(Yb]
    在网站流量逐渐加大的情况下,开始考虑做性能测试了,首先要写好性能测试计划,根据运营数据得出流量最大的页面(如果是第一次的话,一般是首页,下载页,个人帐户页流量最大,而且以某种百分比),软件测试专业网站:51Testing软件测试网:}uG9P?9s;wx\%F L
    Web服务器指标指标:软件测试专业网站:51Testing软件测试网I,Hio2Ffjmf
    * Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数;
    ]2I;}F2b{136894* Successful Rounds:成功的请求;
    (I8s0hN|136894* Failed Rounds :失败的请求; 软件测试专业网站:51Testing软件测试网]9Qj8E {"mvI5_ A
    * Successful Hits :成功的点击次数; 软件测试专业网站:51Testing软件测试网U*^h!ew v,@~
    * Failed Hits :失败的点击次数; 软件测试专业网站:51Testing软件测试网1D/Q~ i(pi#u5T
    * Hits Per Second :每秒点击次数;
    F(B h`/D/cOU136894* Successful Hits Per Second :每秒成功的点击次数; 软件测试专业网站:51Testing软件测试网&Z:F2wZ4]+i0QR;^
    * Failed Hits Per Second :每秒失败的点击次数; 软件测试专业网站:51Testing软件测试网~8T2A"ZL
    * Attempted Connections :尝试链接数;

    13. 您在从事性能测试工作时,14. 是否使用过一些测试工具?如果有,15. 请试述该工具的工作原理,16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。软件测试专业网站:51Testing软件测试网pm[&x6M
    17. 您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
    :d7Q)TFL H4{$m13689418. 在您以往的工作中,19. 一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
    V @ b0v(\ K a'K13689420. 您以往所从事的软件测试工作中,21. 是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有,22. 请结合该工具描述软件缺陷(Bug)跟踪管理的流程。
    &N'VW9xz-s"E13689423. 您认为在测试人员同24. 开发人员的沟通过程中,25. 如何提高沟通的效率和改善沟通的效果?维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么?
    uF+?"iv-Pj5W6u13689427. 在您以往的测试工作中,28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么?您是如何来对待这些事情的?
    7|OL;vl,Y4Bd13689431. 在即将完成这次笔试前,32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会?(可以包括软件测试、过程改进、软件开发或者与此无关的其他方面)软件测试专业网站:51Testing软件测试网(L4HlGga+Psv6f
    33.     你对测试最大的兴趣在哪里?为什么?
    '}6]Q0d'j-a?h136894最 大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗列了 11,12点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的1,2点我没有把握,其他点我都很有信心做好它。软件测试专业网站:51Testing软件测试网(H'Q G}8bc&qn!t
    刚 开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发更难, 虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。
    h8@-H3?g.s];O0O136894不到一年半的测试工作中,当时的感动和热情没有减退一点(即使环境问题以及自身经验,技术的不足,做测试的你一定也能理解)。
    :q*g(P^-li5nIZp136894我 觉得做测试整个过程中有2点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计上了, 要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技术基 础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技术知 识你要知道网站内部是怎么运作的的,后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备,可能会遇 到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。软件测试专业网站:51Testing软件测试网|+z+["?"Z3l?d]F
    第 二是发现BUG的时候了,这应该是测试人员最基本的任务了,一般按测试用例开始测试就能发现大部分的bug,还有一部分bug需要测试的过程中更了解所测 版本的情况获得更多信息,补充测试用例,测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下,通过细心和耐心去发现bug了,每个用例都 有可能发现bug,每个地方都有可能出错,所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了,bug都在里面发现的)。如何描述bug也很有 讲究,bug在什么情况下会产生,如果条件变化一点点,就不会有这个bug,以哪些最少的操作步骤就能重现这个bug,这个bug产生的规律是什么?如果 你够厉害的话,可以帮开发人员初步定位问题。
    v4W`*kd+U~etb*D13689434. 你的测试职业发展是什么?
    FK8J&Ui_136894测试经验越多,测试能力越高。所以我的职业发展是需要时间累积的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年累积测试经验,按如何做好测试工程师的11,12点要求自己,不断的更新自己改正自己,做好测试任务。
    6vW5['sb13689435. 你自认为测试的优势在哪里?
    J-XJ})v J4t%qmX136894优势在于我对测试坚定不移的信心和热情,虽然经验还不够,但测试需要的基本技能我有信心在工作中得以发挥。软件测试专业网站:51Testing软件测试网!NX]-h.o;HE:B@0{
    36. 你以前工作时的测试流程是什么?
    6O @|'sBt*f-n'v6d136894公 司对测试流程没有规定如何做,但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正(自己总结,吸取同行的方法)后的流程吧。需求评审(有开发 人员,产品经理,测试人员,项目经理)->需求确定(出一份确定的需求文档)->开发设计文档(开发人员在开始写代码前就能输出设计文档)- >想好测试策略,写出测试用例->发给开发人员和测试经理看看(非正式的评审用例)->接到测试版本->执行测试用例(中间可能 会补充用例)->提交bug(有些bug需要开发人员的确定(严重级别的,或突然发现的在测试用例范围之外的,难以重现的),有些可以直接录制进 TD)->开发人员修改(可以在测试过程中快速的修改)->回归测试(可能又会发现新问题,再按流程开始跑)。
    s;j[Y){.uuJ"{13689437. 当开发人员说不38. 是BUG时,39. 你如何应付?软件测试专业网站:51Testing软件测试网1O7~j z3k
    开 发人员说不是bug,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3方商量确定好后再看要不要 改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果?程序 员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修 改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场,让问 题得到最后的确认。
    H^q.BS[`p13689423.你为什么想离开目前的职务?
    iC_8Nq8eHh? v136894因 为公司运作情况并不理想,公司需要调整部门体系,公司考虑到缩减部门人员,所以大批量的裁员(有6,7个),这是我的第一份工作,对公司也有较深的感情, 因为在这里我找到了职业理想(就是测试),所以公司需要精简人员,我自愿退出。虽然很舍不得,但我将会有新的发挥能力的舞台。
    8R io!L4v136894  24:你对我们公司了解有多少?

      25:你找工作时,最重要的考虑因素为何?软件测试专业网站:51Testing软件测试网/O,] LW7G'})t
    工作的性质和内容是否能让我发挥所长,并不断成长。
    sK#v"s v"V AJ ua13689426:为什么我们应该录取你?
    VJQc fKB"d:[*J136894您可以由我过去的工作表现所呈现的客观数据,明显地看出我全力以赴的工作态度。软件测试专业网站:51Testing软件测试网1~jn)l7nvU|
      27:请谈谈你个人的最大特色。软件测试专业网站:51Testing软件测试网lW@.wHe _
    我的坚持度很高,事情没有做到一个令人满意的结果,绝不罢手。软件测试专业网站:51Testing软件测试网#X8h9rV ~P4N`Ms
    28.白箱测试和黑箱测试是什么?什么是回归测试?
    5E9H)d+[G/Ejb136894    29。单元测试、集成测试、系统测试的侧重点是什么?软件测试专业网站:51Testing软件测试网B] I0O0su P5i D ~
        30。设计用例的方法、依据有那些?软件测试专业网站:51Testing软件测试网-j7W D)FgU7j^1b6w
        31。一个测试工程师应具备那些素质和技能?
    u/gT#Bl4k'J136894    32.集成测试通常都有那些策略?
    YTGa0wqw&F m0E136894    33.你用过的测试工具的主要功能、性能及其他?软件测试专业网站:51Testing软件测试网y:Y4a-@t s
        34.一个缺陷测试报告的组成
    { [Qx tD%@]4bz1_136894    35.基于WEB信息管理系统测试时应考虑的因素有哪些?
    m(j!F-_s#L/Q0Y^13689436.软件测试项目从什么时候开始,?为什么?
    #@ \s4w-O7K.I h136894     37.需求测试注意事项有哪些?软件测试专业网站:51Testing软件测试网(^1Ib!@(?7D
         38.简述一下缺陷的生命周期
    +eS7]u|~#X1S136894     39.测试分析测试用例注意(事项)?软件测试专业网站:51Testing软件测试网1?^b X9[#V l]
    你在你所在的公司是怎么开展测试工作的?是如何组织的?软件测试专业网站:51Testing软件测试网U7R,M UBv-e
    你认为理想的测试流程是什么样子?
    3V5C.\#]*R {136894你是怎样工作的?软件测试专业网站:51Testing软件测试网*vH(B"n2ORP
    软件测试活动的生命周期是什么?软件测试专业网站:51Testing软件测试网 X)d'lqN'i X!KT
    请画出软件测试活动的流程图?
    Wb'^*y7yvh136894针对缺陷采取怎样管理措施?软件测试专业网站:51Testing软件测试网]1u6AJ II5?
    什么是测试评估?测试评估的范围是什么?软件测试专业网站:51Testing软件测试网R-ad2a}6q V&Y^
    如果能够执行完美的黑盒测试,还需要进行白盒测试吗?为什么?软件测试专业网站:51Testing软件测试网3i9Uk'J l#W
    测试结束的标准是什么?软件测试专业网站:51Testing软件测试网/R/B/q'c3fy'vsn)u(T
    软件验收测试除了alpha,beta测试以外,还有哪一种?
    3?h;A^9uCa;uVy136894做测试多久了?软件测试专业网站:51Testing软件测试网 F+}-T6q)Y]X
    以前做过哪些项目?
    $J(f*ALq4bk136894你们以前测试的流程是怎样的?软件测试专业网站:51Testing软件测试网0}sq1?*X7Y y
    <答:测试计划-测试用例设计-测试执行-测试分析报告>软件测试专业网站:51Testing软件测试网7Ie s9oo[O
    用过哪些测试工具?
    *@u7Ht-Tmbjo136894为什么选择测试这行?软件测试专业网站:51Testing软件测试网3k:d'v@s2a[X
    <答:它是一个新兴的行业,有发展潜力,而且很锻炼人,需要掌握更多的技能,比做开发要更难>软件测试专业网站:51Testing软件测试网 w_~Lt
    为什么值得他们公司雇用?软件测试专业网站:51Testing软件测试网 G3@3L TM7n
    如果我雇用你,你能给部门带来什么贡献?软件测试专业网站:51Testing软件测试网B{g[Du'j7S9J
    如何从工作中看出你是个自动自觉的人软件测试专业网站:51Testing软件测试网"l~k:B1\eL"|J$|
    你的工作通常能在时限内完成吗.(我想问一下就是她问这个问题的动机是什么)
    ']GCp,_)u/M136894通常你对于别人批评你会有什么样的反应软件测试专业网站:51Testing软件测试网8Iq%|#R iJ0y d)p
    如果明知这样做不对,你还会依主管的指过去做吗软件测试专业网站:51Testing软件测试网Yq~7i[p C
    如果你接到一个客户抱怨的电话,你确知无法解决他的问题,你会怎么处理软件测试专业网站:51Testing软件测试网e^;Sobhtn `Up
    你觉得什么样的人最难相处
    *C6fF\ p K[8I136894为什么值得他们公司雇用?
    [e0aBlZ3k136894      帮助公司提高软件质量和测试部门的技术水平软件测试专业网站:51Testing软件测试网/P9c{'{smh
    如果我雇用你,你能给部门带来什么贡献?
    OtC`L |;_"baN{136894      分享我的测试经验和测试技能,提高测试部门技术水平软件测试专业网站:51Testing软件测试网bp1x"x5r:Q4{ T"Sp
    如何从工作中看出你是个自动自觉的人 软件测试专业网站:51Testing软件测试网Tr hY9E l
         自动自觉范围太广
    I7f6` ky136894      1. 工作成果软件测试专业网站:51Testing软件测试网"~S/Xx9~
          2. 工作质量  
    ,\bzPg H136894你的工作通常能在时限内完成吗.(我想问一下就是她问这个问题的动机是什么)软件测试专业网站:51Testing软件测试网2Q,[f1?.V
          在有足够的资源和合理的工作量的情况下,完全可以按时完成,并能比一般人做的更好软件测试专业网站:51Testing软件测试网DHA b!P(E&] r O
    通常你对于别人批评你会有什么样的反应
    6i1}`*iQ136894  有错即改,无措勉之软件测试专业网站:51Testing软件测试网-m`)Y iH5X
    如果明知这样做不对,你还会依主管的指过去做吗软件测试专业网站:51Testing软件测试网2S rAk*EJ~
         在公司内部下级是否有申诉渠道?软件测试专业网站:51Testing软件测试网&ft5F M,C uQb1V
    如果你接到一个客户抱怨的电话,你确知无法解决他的问题,你会怎么处理软件测试专业网站:51Testing软件测试网5e!qd6g%u z
        为什么抱怨?是怎么样的问题?软件测试专业网站:51Testing软件测试网 Qd#GsB5[
         如果是客服问题,提交客服部门解决
    "l wx:I#\136894    如果是质量问题,分析原因,下一版本改进软件测试专业网站:51Testing软件测试网P FBD${9N&I'zK
    你觉得什么样的人最难相处 软件测试专业网站:51Testing软件测试网8Ee-wq"L2_T"{
         自以为是的人软件测试专业网站:51Testing软件测试网&\6C6M+a,K$qR9t3Nati(k
    什么叫单元测试?
    (b2xq'X6O136894请就软件测试人员应该具备什么样的基本素质说说你的看法。软件测试专业网站:51Testing软件测试网,tHX^7rpu.Y!U
    请就如何在开发中进行软件质量控制说说你的看法
    O9V@:`~B)C f0U&l136894 简述软件测试的意义,以及软件测试的分类

    1、功能测试,性能测试,界面测试,安全测试(可以简单点,比如只涉及到COOKIES里的内容),压力测试(商业性质的网站) 等等,B/S软件也要根据其具体功能采用不同的测试策略。
    sjY"B:sd!Y)A n6N1368942、态度、责任心、自信、敏锐的观察力、良好的发散思维软件测试专业网站:51Testing软件测试网.sz6N^*U${[] D%U5K
    3、先设计后开发模式,加强单元测试,加强代码走查,有一套完整的白盒测试方法。关键是加强开发人员的质量意识,增进程序员向工程师水平发展。软件测试专业网站:51Testing软件测试网 D7L3|jz z6KR
    4、意义嘛,就自己想吧。软件测试的分类,这个很多人都按各种方法去分。无明确答案给你。

    对测试的理解——基本的测试知识,对测试是否认可? 75。软件测试专业网站:51Testing软件测试网[o3G}vo6N
       3、谈一谈过去自己的工作——了解经历、提供进一步提问的素材,表达能力  
    F+dSGCGmB5pB4E136894测试技能 软件测试专业网站:51Testing软件测试网)GD ?7e b*Tbws
    测试设计的方法并举例说明——测试技术的使用 软件测试专业网站:51Testing软件测试网;R]S"dl t+I
    测试工具——熟悉程度,能否与当前工作匹配?
    )A xJ b,E?-\136894如何做计划?如何跟踪计划?——日常工作能力 软件测试专业网站:51Testing软件测试网.p P9snU6|8}0KUaz
    如果开发人员提供的版本不满足测试的条件,如何做?——与开发人员协作的能力
    #fw4N ? O136894熟悉unix系统、oracle数据库吗?——是否具备系统知识 软件测试专业网站:51Testing软件测试网[F:XJ_ s4@Yt
    做过开发吗?写过哪些代码?——开发技能
    mf&M g3Ch6oi136894阅读英语文章,给出理解说明?——部分英语能力 软件测试专业网站:51Testing软件测试网[;VV+|g
    文档的意义——是否善于思考?(最简单的概念,不同层次的理解)
    W0I(}$W&|[p1Mdu136894假如进入我们公司,对我们哪些方面会有帮助?——讲讲自己的特长
    I Ud ? DQ)I5n3vS.o136894随便找一件物品,让其测试——测试的实际操作能力软件测试专业网站:51Testing软件测试网A-DT#ea^ MX
    软件测试的方法有?软件测试专业网站:51Testing软件测试网uH3o V)H np(oW
    软件测试的过程?软件测试专业网站:51Testing软件测试网Q\ y*R&` g
    有一个新的软件,假如你是测试工程师,该如何做?软件测试专业网站:51Testing软件测试网o,qb?M UAJ
    软件测试分哪两种方法?分别适合什么情况? 软件测试专业网站:51Testing软件测试网3] fn6J w]{i-B C
    2。一套完整的测试应该由哪些阶段组成?分别阐述一下各个阶段。 软件测试专业网站:51Testing软件测试网S8Rp"jh)X!Si`6N
    3。软件测试的类型有那些?分别比较这些不同的测试类型的区别与联系。 软件测试专业网站:51Testing软件测试网+B;]6@ ~CX
    4。测试用例通常包括那些内容?着重阐述编制测试用例的具体做法 软件测试专业网站:51Testing软件测试网1cHXJ M
    5。在分别测试winform的C/S结构与测试WEB结构的软件是,应该采取什么样的方法分别测试?他们存在什么样的区别与联系? 软件测试专业网站:51Testing软件测试网Q}R;t1\E
    6。在测试winform的C/S结构软件时,发现这个软件的运行速度很慢,您会认为是什么原因?您会采取哪些方法去检查这个原因?
    .\eCyC_ S1368947。描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程 软件测试专业网站:51Testing软件测试网2Y#PEi @.F:W
    你在五年内的个人目标和职业目标分别是什么?
    Q#b.fWL136894  分析这个问题是用来了解你的计划能力的,通过这个问题,面试人同时还可以知道你的目标是否符合企业对你的安排。软件测试专业网站:51Testing软件测试网na\.}r&gb4K
      错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁,我认为做太多的个人计划是荒谬可笑的,不是吗?
    (y Om&zU'S;j136894   评论这种回答属于令人反感的一类。首先,当有人想了解你的目标时,"将来的某个时候"这种通俗说法并不奏效。其次,认为企业很脆弱,领导者更换频繁,这 种说法毫无疑问会令人反感,而且也是不合理的。最后,认为做计划可笑,看不起这个问题,而且反问面试人,这些都注定了这样的求职者最终会失败。软件测试专业网站:51Testing软件测试网4m(I.Oq BJ*u3^ pB3Im
      正确回答从现在起的五年之内,我希望能够在一个很好的职位上待几年,而且最好有一次晋升,然后就期待着下一步。不管是向上提升,还是在企业内横向调动,对我个人来说,我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。软件测试专业网站:51Testing软件测试网"D1kfjSnbz&I/BL3^%W
      评论这个问题没有回答得过分具体(那样可能会产生漏洞),而且它表明你有雄心,并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望,表明你是一个有灵活性的人。
    C%]M IE136894 问题23 你怎样做出自己的职业选择?软件测试专业网站:51Testing软件测试网)A9\+g6q)Y)?D0E
      分析 面试人提出这个问题是为了了解求职者的动机,看看他(她)应聘这份工作是否有什么历史渊源,是否有职业规划,是不是仅仅在漫无目的地申请很多工作。软件测试专业网站:51Testing软件测试网 d:S&]!I,~` z
      错误回答 我一直都想在企业界工作。自孩提时代起,我就梦想自己至少也要成为大企业的副总裁。
    5\MVP2Pt(`136894  评论 除了难以令人相信之外,这种回答还存在一个问题:它表明求职者会对副总裁以下的职位不感兴趣。
    &?F5Y^y!SJ)[136894   正确回答 在上大学四年级前的那个夏天,我决定集中精力在某一领域谋求发展。尽管我是学商业的,但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自 己的目标,想清楚了自己擅长做的事情以及想从工作中得到的东西,最后我得出了一个坚定的结论,那就是这个行业是最适合我的。软件测试专业网站:51Testing软件测试网L'b@!B&G5N*Su
      评论 这种回答表明,求职者认真地做过一些计划,缩小了自己的关注点,而且也认准了前进的方向。这种回答还表明,求职者理解个人职业规划的重要性,并且有能力做出认真的个人决策。
    -z5g*y|E#}1368941. 你都用什么测试方法
    C'i]QpO!F1368942.怎么编写案例
    Ct+b2v7c1368943.怎么才能够全面的测试到每一个点
    Q5i#} b#yT1368941. 你都用什么测试方法软件测试专业网站:51Testing软件测试网B.@O[S,c
    针对不同的产品或者系统或者模块,有不同的测试方法。总体而言有白盒测试和黑盒测试。
    s.j"i7Wm#Hb1368942.怎么编写案例软件测试专业网站:51Testing软件测试网@,]}5Nw [;e{
    案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
    u:B z!|%h1368943.怎么才能够全面的测试到每一个点
    qa @'g3^4x*L|136894测试的全面性主要需要在设计测试计划的时候考虑,从测试策略,产品需求等等多个角度考虑从而定义全部的测试点。
    q8cY6LX!]W1368941、谈谈软件测试技术,以及如何提高软件测试专业网站:51Testing软件测试网7~:[M6Yn2u
    2、谈谈软件测试职业发展,以及个人的打算
    nQL,O!B+o1368943、谈谈软件测试在企业的地位,也可以结合软件生命周期来谈软件测试专业网站:51Testing软件测试网9A? Hm7z U6i
    有可能清晰的思路比确切的答案更重要软件测试专业网站:51Testing软件测试网F bEfv3v-j%B
    在这里,主要说下笔试和面试的问题,希望大家共同参考。软件测试专业网站:51Testing软件测试网g$y7l6X-Gq
        1,一般公司里实际的软件测试流程是什么样的?你们公司又是怎样的?
    pm6j j iR Z136894    2,软件工程师要具有那些素质?
    4E5Xz)H@y&?~:Y136894    3,你会哪些测试工具?怎么操作?软件测试专业网站:51Testing软件测试网.B3Oj]0dQ8Q
        4,你能不能说下你的3到5年的职业计划(规划)软件测试专业网站:51Testing软件测试网G(MeA}?J{
        5,你觉得你来应聘有那些优势?软件测试专业网站:51Testing软件测试网3`{9N-a+{p0|{7gC
    其余的还好说,但就第4个问题,我感到不好说哦!希望大家给个意见软件测试专业网站:51Testing软件测试网-ug6p)nJ
    第一关:首先要自我介绍,自己的性格怎么样,目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看?还有对于软件测试有什么自己的想法。为什么会想到要做这行(因为我的简历上的工作经历没有关于测试方面的)。哦,还有期望薪资。
    ~utD5kH136894第二关:认为软件测试人员所要具备的基本素质,如果遇到问题会怎样处理,如果得不到研发人员的配合(就是研发说这个不是问题)你又会怎么处理?然后就是一些基本概念,比如软件测试的流程有哪些?如果我上任了,首先会怎么开始自己的工作计划。
    b | f4D w2f-W136894(前两关通过了后面这个就好过多了)软件测试专业网站:51Testing软件测试网}U2H GCyXw
    第三关:像我介绍了一下公司的情况,告诉我主要针对什么内容的测试,会不会使用数据库。告诉我大概要做哪些内容,详细的可以上岗以后慢慢熟悉。
    Y+KJ-r9X/k(hR0S136894大概就这么多了,这对没有经过这一关的不知道有没有帮助,仅供参考吧
    %])Yr7?#`c"NC136894我觉得就像李波说的,关键是要给对方留下好印象:)

    面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问,这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会:
    al'h0Dq1P{)Y136894你可以问:
    8?0R*lub4j$d4fN.y1368941.        贵公司近期和远期的发展目标是什么?软件测试专业网站:51Testing软件测试网sX`2h@uRt9t0m9]
    2.        贵公司的主要竞争对手有哪些?
    "P Fo*^[r1368943.        贵公司有多少开发人员有多少测试人员?
    ;u.S3C SVFvV1368944.        贵公司又进一步扩充测试人员的计划吗?
    k3_%D7j-N;qEb#hC1368945.        如果我有幸能进入贵公司的话,我有怎么样的发展?软件测试专业网站:51Testing软件测试网E8W[ j}u8QH
    6.        测试人员的沟通能力很重要,贵公司有规范的沟通渠道吗?软件测试专业网站:51Testing软件测试网eiT:{ i o0G$izp
    7.        请介绍一下贵公司的福利情况。
    0L G@:h$qQ&Xs1368948.        请问我什么时候能知道结果?

  • 软件测试中容易忽略的缺陷<转>

    2008-09-03 10:57:59



    摘要
        在系统测试和确认测试中,有些缺陷由于某些原因往往被忽略了,这就给软件留下了隐患或者危机。本文通过描述这些容易忽略的缺陷,提供一个完善测试用例和测试执行的参考。
    关键词:缺陷
    正文:
        通常软件测试会 暴露软件中的缺陷,经过修正后可以保证软件系统的功能满足需求并正确运行。但是,在系统测试和确认测试中,测试人员容易遗漏一些隐藏的缺陷。众所周知,软 件测试不可能发现所有的缺陷,而软件开发周期各个阶段仍然存在注入缺陷的可能,但是,有一些缺陷是测试中容易忽略的,也就是说,通过测试方法和用例可以充 分暴露这些缺陷,遗憾的是,它们往往被忽略或者某种原因忘记测试了,这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括:
    1、安装缺陷
        通常项目组完成代码后,发布时候安装打包是最后一个环节,而测试人员通常在测试的时候,没有仔细的测试这一部分,而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件,结果正式安装时候出现问题,引起例如控件没有注册,注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件,成数据丢失;使用绝对路径;安装顺序没有说明书
    2、配置文件
        有些文件在 ini 等配置文件中写出了管理员口令密码等信息,而且是明文的!这是一个安全隐患。另外,有些安装文件的 XML 文件,为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的测试人员,必须检查这些可以用记事本打开的文件。因为,一个稍有常识而且喜欢探索的用户,可能从中获取信息而成为不自觉的黑客。所以,配置文件可能成为软件安全方面的一个缺陷。
    3、网页安全缺陷
        现在网站开发已经注意到:登陆网站进入其内部网页后,直接拷贝网址,然后粘贴到另IE 窗口输入,可以绕过登陆直接访问。也许商业网站很关注这个问题,但是很多行业软件却很容易忽略。
        网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件,在主页面关闭的时候子页面还可以运行,这是一个明显的漏洞,而且还大大增加了错误发生的几率。
    4、判断顺序/逻辑缺陷
        对界面进行多个输入判断的时候,非常容易出现这种问题。例如判断年月顺序,判断长度,判断非空等。假如操作员仅仅满足单个条件,保存不能成功;而按界面从上之下顺序一一满足条件之后,保存是没有问题的。但是,改变一下输入的次序,校验失效。例如,一一满足条件之后,不保存,倒过来将上面的输入改成非法输入,然后保存,结果居然也能成功,这是因为原先的判断由于发生过,或者根据语句顺序只检查最后一个判断,所以没有报错。这种错误尤其在 Java scrīpt 脚本的 页面中要注意。能够保存不能保证数据正确,有可能引起系统崩溃或者后续数据错误。所以,在测试的时候,不要按照正常的顺序输入,而是要打乱步骤,看看代码 是否强健,是否在判断逻辑上没有错误。良好的代码应该经得起折腾,至少保存时会再此全部进行判断,而不只是简简单单走到判断的最后一行。
    5、调试语句和冗余信息
       维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息,会使不明真相的用户产生误以为系统发生了严重故障,从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用,其结果可想而知;而多余的按钮会误导好奇心强的用户操作,产生不必要的错误。
        同样值得关注的还有参数设置,由于没有实际数据,开发人员在调试或者单元测试的时候,习惯性的进行自我设定而忘了删除,测试人员可能会忽略掉了这部分测试,也可能导致在客户现场发生错误而影响系统发布和验收。
    6、不可重现的故障
        新参加测试的人员或者新来的开发人员总是要问,不可重现的缺陷是否需要记录,有必要吗?回答是肯定的。测试必须如实的记录发生的问题,也许不能重现,或者使非软件系统本身问题,但是,可能这些偶然性背后是有规律的,不记录这些,就不可能发现这些规律。
    7、多节点的逆向流转缺陷
        当前软件不少喜欢使用工作流来驱动。工作流的问题,就是可能出现多个流向分支。测试容易忽略的部分,就是工作流多节点的逆向流转。例如,通过不通过涉及两个分支,但是流程逆转的时候,有可能不是回到上一节点而是平级的另一个节点去了。测试要格外注意这类用例的设计。另外,有些时候默认分支在向前的时候是有默认值的,例如默认通过,那么保存的时候要提示用户是否通过,否则可能由于操作疲劳而走错了节点,引起回退。
    8、输入框缺陷
        试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候,输入框会根据长度大小自动截断输入长度。但是用鼠标,截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了,保存的时候,数据库崩溃。有些网站登陆的口令****可以拷贝下来的,只要放在剪贴板里面马上明文显示
        输入框可以说是问题最多的部分,能够引起的麻烦也很多。日期、数字、文本等等,都需要耐心的测试一下。
    9、界面布局缺陷
       曾经有一次,项目经理回来向测试部反映一个问题,客户对界面不满意。原因很简单,因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员,很容易误按。这个问题是测试人员没有意料到的,因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布
        界面布局还可能发生在窗口最大化和最小化上,有可能窗口缩小的时候没有下拉框或不匹配分辨率,对用户来讲,这个错误实在很低级。有些用户由于操作习惯,非常不喜欢腾出手使用鼠标,尤其是大量输入的界面,因此,要注意设置键盘的快捷方式。还有,按 Tab定位到下一焦点时要注意顺序,避免跳转太灵活而让操作人员感到无从适应,在界面进行维护或者修改的时候,不要忘了测试开发人员是否无意改变了这些快捷方式和跳转顺序。
    10、版本和补丁包的环境问题
        理论上讲,这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包,问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例,多用不同软件版本的机器跑一跑。测试有个定律是:你没跑过的地方,就一定会出事。经常听到开发人员抱怨,怎么我的机器没问题,你的机器就有事了呢?这不能完全靠配置管理员解决问题,环境配置项是大家最容易忽略的。
    11、用户管理缺陷
        用户管理的角色和授权需要好好研究一下,作过测试的人员都知道,有时候为了测试的方便,测试用户都是具有超级权限的用户。而且,比较容易忽略用户管理这一部分的测试。往往发往客户的时候,很多测试用户都没有删除。
        另外,有些接口的用户和口令,到软件使用寿命结束都没有更改过在一次测试中,测试人员发现,给一个用户授超级用户权限,之后更改这个用户为受限权限。使用中发现,用户居然没有真正回收权限,用户管理界面上没有任何不对。及早准备用户管理用例,不要等到测试快结束时候才想起。
    12、常识缺陷
        从逻辑或者统计学上讲,计算机是允许如此处理的,但是从常识上来讲,这些情况不可能发生。例如电话号码不可能出现小数点,终止时间不能大于开始时间等等。除此之外,常识还要结合业务特点来进行判断,因此,开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现,对用户来说,这些错误可能是很荒谬的。
        尽管我们不可能完美的测试一个软件,但是我们仍然可以改进我们的测试。每次测试结束,及时总结
  • 转载:在网站测试中如何做好安全性测试?

    2008-09-03 10:57:20



    随着网络发展的趋势,对于网站的安全性的要求也越来越高,很多网站都存在被黑客攻击的漏洞,你在网站测试中有做到安全性测试吗?你觉得安全测试应该从哪些方面来检查?

    最佳答案由“卖烧烤的鱼”提供:

    安全性测试(security testing)是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。

    注意:安全性测试并不最终证明应用程序是安全的,而是用于验证所设立策略的有效性,这些对策是基于威胁分析阶段所做的假设而选择的。


    以下是我读<<软件评测试教程>>中的Web安全性测试章节内容,并进行修改的笔记,前面看了好多朋友写的,不过不是很全,希望对大家有所帮助,建议大家还是买本<<软件评测试教程>>此书绝对物超所值^_^

    WEB安全性测试
    一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。
    1.        安全体系测试
    1)        部署与基础结构
    l        网络是否提供了安全的通信
    l        部署拓扑结构是否包括内部的防火墙
    l        部署拓扑结构中是否包括远程应用程序服务器
    l        基础结构安全性需求的限制是什么
    l        目标环境支持怎样的信任级别
    2)        输入验证
    l        如何验证输入
    A.        是否清楚入口点
    B.        是否清楚信任边界
    C.        是否验证Web页输入
    D.        是否对传递到组件或Web服务的参数进行验证
    E.        是否验证从数据库中检索的数据
    F.        是否将方法集中起来
    G.        是否依赖客户端的验证
    H.       应用程序是否易受SQL注入攻击
    I.        应用程序是否易受XSS攻击
    l        如何处理输入
    3)        身份验证
    l        是否区分公共访问和受限访问
    l        是否明确服务帐户要求
    l        如何验证调用者身份
    l        如何验证数据库的身份
    l        是否强制试用帐户管理措施
    4)        授权
    l        如何向最终用户授权
    l        如何在数据库中授权应用程序
    l        如何将访问限定于系统级资源
    5)        配置管理
    l        是否支持远程管理
    l        是否保证配置存储的安全
    l        是否隔离管理员特权
    6)        敏感数据
    l        是否存储机密信息
    l        如何存储敏感数据
    l        是否在网络中传递敏感数据
    l        是否记录敏感数据
    7)        会话管理
    l        如何交换会话标识符
    l        是否限制会话生存期
    l        如何确保会话存储状态的安全
    8)        加密
    l        为何使用特定的算法
    l        如何确保加密密钥的安全性
    9)        参数操作
    l        是否验证所有的输入参数
    l        是否在参数过程中传递敏感数据
    l        是否为了安全问题而使用HTTP头数据
    10)        异常管理
    l        是否使用结构化的异常处理
    l        是否向客户端公开了太多的信息
    11)        审核和日志记录
    l        是否明确了要审核的活动
    l        是否考虑如何流动原始调用这身份
    2.        应用及传输安全
    WEB应用系统的安全性从使用角度可以分为应用级的安全与传输级的安全,安全性测试也可以从这两方面入手。
    应用级的安全测试的主要目的是查找Web系统自身程序设计中存在的安全隐患,主要测试区域如下。
    l        注册与登陆:现在的Web应用系统基本采用先注册,后登录的方式。
    A.        必须测试有效和无效的用户名和密码
    B.        要注意是否存在大小写敏感,
    C.        可以尝试多少次的限制
    D.        是否可以不登录而直接浏览某个页面等。
    l        在线超时:Web应用系统是否有超时的限制,也就是说,用户登陆一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
    l        操作留痕:为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进入了日志文件,是否可追踪。
    l        备份与恢复:为了防范系统的意外崩溃造成的数据丢失,备份与恢复手段是一个Web系统的必备功能。备份与恢复根据Web系统对安全性的要求可以采用 多种手段,如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求,某些实时系统经常会采用双机热备或多级热备。除了对于这些备份与恢 复方式进行验证测试以外,还要评估这种备份与恢复方式是否满足Web系统的安全性需求。
    传输级的安全测试是考虑到Web系统的传输的特殊性,重点测试数据经客户端传送到服务器端可能存在的安全漏洞,以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。
    l        HTTPS和SSL测试:默认的情况下,安全HTTP(Soure HTTP)通过安全套接字SSL(Source Socket Layer)协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别,但从某种意义上来说,安全性的保证 是以损失性能为代价的。除了还要测试加密是否正确,检查信息的完整性和确认HTTPS的安全级别外,还要注意在此安全级别下,其性能是否达到要求。
    l        服务器端的脚本漏洞检查:存在于服务器端的脚本常常构成安全漏洞,这些漏洞又往往被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
    l        防火墙测试:防火墙是一种主要用于防护非法访问的路由器,在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题。这里所涉及的只是对防火墙功能、设置进行测试,以判断本Web系统的安全需求。

    另推荐安全性测试工具:
    Watchfire AppScan:商业网页漏洞扫描器(此工具好像被IBM收购了,所以推荐在第一位)
    AppScan按照应用程序开发生命周期进行安全测试,早在开发阶段就进行单元测试和安全保证。Appscan能够扫描多种常见漏洞,例如跨网站脚本、HTTP应答切开、参数篡改、隐藏值篡改、后门/调试选项和缓冲区溢出等等。


    Acunetix Web Vulnerability Scanner:商业漏洞扫描器(目前用的比较多,不过这东东N占内存)
    Acunetix WVS自动检查您的网页程序漏洞,例如SQL注入、跨网站脚本和验证页面弱密码破解。Acunetix WVS有着非常友好的用户界面,还可以生成个性化的网站安全评估报告。
  • Web功能测试工具-MAXQ

    2008-09-03 10:56:18




      MAXQ是开源的Web功能测试工具。他的特点:1)简单易学;2)是一个轻量级的Web功能测试工具;3)可以自动录制WebBrowser提交的请求 包,并随时回放;4)MAXQ应用了WebProxy代理方式,不直接录制Web的界面,避免在回放时不能识别控件而造成回放停止。
      我们知道就算是商用重量级的工具同样存在不能准确识别控件,这是困扰着GUI自动测试的技术难题.而MAXQ是一个代理Web服务的角色,不直接录制界 面,因此不存在界面控件识别问题;MAXQ录制来自前端向服务器发出的业务请求,不是录制前端界面的操作过程;MAXQ的脚本是行命令方式,回放简单快 速。
    MAXQ的基本原理:

    安装
    JDK1.4以上;展开MAXQ到预定目录下即可。
    修改配置:修改maxq.properties;指定WEB应用服务器;remote.proxy.host=192.168.3.41;remote.proxy.port=8080
    指定MAXQ代理
    local.proxy.port=8090
    修改Internet配置
    工具->Internet选项->连接->局域网设置->选择为LAN使用代理服务器,地址栏输入localhost,端口选择8090

    启动MAXQ
    MAXQ的bin目录下,运行maxq.bat
    正常时出现下界面



    录制准备
    设置一个新的录制new->standard scrīpt


    开始录制
    选择test->start recording



    Browser操作
    打开IE
    运行http://localhost,显示需要测试WEB应用


    结束录制
    选择test->stop recording贮存脚本file->save
     
    回放录制
    选择file->open(打开脚本)
    选择test->run
     
    分析测试结果
    查看测试结果界面,成功的话显示Test Ran Successfully
     
    注意事项(1)
    web界面测试
     MAXQ不是测试界面的工具,因此web的界面测试还需要人工测试或应用诸如Winrunner、Testcomplete工具自动测试。
    脚本录制
     当功能已经正确的前提下才录制脚本。
    脚本大小
     从业务上划分,通常把一个完整的业务过程作为录制脚本的对象;
    适宜关联业务流程录制;
    不要把不相关的业务录制在同一个脚本中;
    注意事项(2)
    测试检查
     需要另外加测试点检查
  • 软件测试报告写作实战案例(z)

    2008-09-03 10:55:17

    测试总结和报告

            测试人员的工作通常并不像开发人员那样能直接体现出来,让大家一目了然。开发人员做的是建设性的工作,如开发了哪些功能,写了几行代码,设计了几个类,都能直观地看到,而且,通过软件能很鲜活地演示开发人员的工作成果。
            但是测试人员的工作相对隐蔽一点,测试人员做的是破坏性的工作,并且没有很多可以直观体现测试人员贡献的东西。笔者曾经听到公司人事部的一位同事说:“你 们做测试的真好,整天坐在那里”。当然,这是外行人看内行时说的话,但是给笔者的一个启示是:测试人员需要更多地表现自己,展现自己的工作成果。
            说明:由于缺陷列表太细、太大,测试用例过于专业,很多人对其不感兴趣,因此测试报告能很好地展示自己的工作状况,测试报告是提供给很多人看的一份文档。

            下面是一个项目的测试报告的纲要:
    1 简介
    1.1 编写目的
    1.2 项目背景
    1.3 术语和缩略词
    1.4 参考资料
    2 目标及范围
    2.1 测试目的及标准
    2.2 测试范围
    3 测试过程
    3.1 测试内容
    3.2 测试时间
    3.3 测试环境
    3.4 测试方法及测试用例设计
    4 测试情况分析
    4.1 测试概要
    4.2 测试用例执行情况
    4.3 缺陷情况
    4.4 测试覆盖率分析
    4.5 产品质量情况分析
    5 测试总结
    5.1 测试资源消耗情况
    5.2 测试经验总结
    6 附件
    附件1 测试用例清单
    附件2 缺陷清单
    一、缺陷分类报告
            缺陷分类报告是测试报告的重要组成部分,可以再细分为:缺陷类型分布报告、缺陷区域分布报告和缺陷状态分布报告等。
    1.缺陷类型分布报告
            缺陷类型分布报告主要描述缺陷类型的分布情况,看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意,并分析缺陷为什么会集中在这种类型。例如, 如果缺陷主要是界面类型的,如界面提示信息不规范、界面布局凌乱等问题,那么就要讨论是否需要制定相应的界面规范,让开发人员遵循,从而防止类似问题的出 现。
    缺陷类型分布报告一般用饼图或柱状图显示。如图7.29所示,用饼图表示了几种类型的缺陷各自所占的比例。

    图  缺陷分布报告


    三、典型缺陷与Bug模式
            软件开发有设计模式,测试其实也有模式存在,需要测试人员进行总结和归纳。测试人员应从经常出现的Bug中学习,总结出Bug模式,用于指导测试。如果开发人员能关注这些Bug模式,还能起到预防错误的效果。
            要成为典型缺陷,必须满足以下条件:
            重复出现、经常出现;
            能代表某种类型的错误;
            能通过相对固定的测试方法或测试手段来发现这些错误。
            总结这些典型缺陷出现的现象,出现的原因,以及测试方法,就能成为一个Bug模式。

            说明:根据不同的开发平台、开发工具、开发语言、产品类型、采用的架构等,可以总结出不同的Bug模式,不同的Bug模式可能在不同的平台、语言、产品类型中才会出现。测试人员应该总结适合自己项目特点的Bug模式。

            提炼Bug模式的一般步骤如下:
            步骤1:分析缺陷报告,找出经常出现的Bug类型。
            步骤2:分析Bug的根源,找出Bug产生的深层次原因。
            步骤3:分析找到Bug的方法,总结如何才能每次都发现该类型的Bug。
            下面举一个例子来说明这个过程。
            首先,测试人员在分析缺陷报告时发现,有一类Bug经常出现,并且错误现象一致:执行某功能时提示Time Out。
            测试人员与程序员一起分析原因,发现这些错误都是在操作数据库时发生,发送的SQL语 句被数据库长时间执行未返回,因此提示Time Out。通过进一步地分析表明,.NET的SqlCommand的CommandTimeOut属性是用于获取或设置在终止执行命令的尝试并生成错误之前 的等待时间。等待命令执行的时间(以秒为单位)默认为30s,而数据库操作在较大数据量的情况下一般都超过这个时间,因此会提示超时的错误信息。
            这样就可以把这种类型的Bug归纳为“数据库操作超时Bug模式”。
            那么,如何才能找出这样的Bug呢?一般情况下,这类Bug基本上不会出现,只有数据量足够大时才会出现,因此需要设置大批数据,结合性能测试或压力测试来发现此类问题。也可以通过白盒的方式,查找程序在使用SqlCommand时是否合理地设置了Command TimeOut属性,这样将更有针对性地揭露上述的错误。
            至此就完成了一个Bug模式的归纳、提炼和总结,如果程序员积极地参与到该总结和分析过程中来,则可形成一个良性的反馈,当下次程序员编写相同的程序时就会避免类似的错误发生。
    四、测试中的PDCA循环
            PDCA循环是一种放之四海皆准的原则。在软件测试的过程中,也充斥着各种PDCA循环。PDCA循环是一个自我完善和改进的全闭环模型,如图7.34所示,对质量的不断提高和改进非常有效。

      PDCA循环模型



    软件测试技术
            在外行人看来,软件测试其实没什么技术可言,甚至有人认为测试无非是在摆弄一下软件的功能,只要懂得使用鼠标就足够了,这是对软件测试的一种误解。
    1.  黑盒测试与白盒测试
            很多测试人员喜欢讨论黑盒测试与白盒测试的区别,也有些测试人员感觉白盒测试很神秘,很高深,自己没有足够的开发能力是不可能进行白盒测试的。
    那么什么是黑盒测试,什么是白盒测试呢?下面对此进行简单介绍。
    1.1黑盒测试
            黑盒测试是一种把软件产品当成是一个黑箱的测试技术,这个黑箱有入口和出口,测试过程中只需要了解黑箱的输入和输出结果,不需要了解黑箱里面具体是怎样操作的。这当然很好,因为测试人员不用费神去理解软件里面的具体构成和原理,测试人员只需要像用户一样看待软件产品就行了,如图1所示。

    图1  黑盒测试方法


            例如,银行转账系统提供给用户转账的功能,则测试人员在使用黑盒测试方法时,不需要知道转账的具体实现代码是怎样工作的,只需要把自己当成用户,模拟尽可能多的转账情况来检查这个软件系统能否按要求正常实现转账功能即可。
            如果只像用户使用和操作软件一样去测试软件黑盒测试可能存在一定的风险。例如,某个安全性要求比较高的软件系统,开发人员在设计程序时考虑到记录系统日志的必要性,把软件运行过程中的很多信息都记录到了客户端的系统日志中,甚至把客户端连接服务器端的数据库连接请求字符串也记录到了系统日志中,像下面的一段字符串:

    "Data Source=192.168.100.99;Initial Catalog=AccountDB;User ID=sa;PassWord=123456;

            那么按照黑盒测试的观点,这是程序内部的行为,用户不会直接操作数据库的连接行为,因此检查系统日志方面的测试是不会做的。这明显构成了一个Bug,尤其是对于安全性要求高的软件系统,因为它暴露了后台数据库账号信息。
            有人把黑盒测试比喻成中医,做黑盒测试的测试人员应该像一位老中医一样,通过“望、闻、问、切”的方法,来判断程序是否“有病”。这比单纯的操作黑箱的方 式进了一步,这种比喻给测试人员一个启示,不要只是简单地看和听,还要积极地去问,积极地去发现、搜索相关的信息。应该综合应用中医看病的各种“技术”和 理念来达到找出软件“病症”的目的,具体作法如下:
    &61548; “望”,观察软件的行为是否正常;
    &61548; “闻”,检查输出的结果是否正确;
    &61548; “问”,输入各种信息,结合“望”、“闻”来观察软件的响应程度;
    &61548; “切”,像中医一样给软件“把脉”,敲击一下软件的某些“关节”。

    1.2白盒测试
            如果把黑盒测试比喻成中医看病,那么白盒测试无疑就是西医看病了。测试人员采用各种仪器和设备对软件进行检测,甚至把软件摆上手术台解剖来看个究竟。白盒 测试是一种以理解软件内部结构和程序运行方式为基础的软件测试技术,通常需要跟踪一个输入经过了哪些处理,这些处理方式是否正确,这个过程如图2所示。

    图2  白盒测试方法

            在很多测试人员,尤其是初级测试人员看来,白盒测试是一种只有非常了解程序代码的高级测试人员才能做的测试。熟悉代码结构和功能实现的过程当然对测试有很 大的帮助,但是从黑盒测试与白盒测试的区别可以看出,有些白盒测试是不需要测试人员懂得每一行程序代码的。
            如果把软件看成一个黑箱,那么白盒测试的关键是给测试人员戴上一副X光透视眼镜,测试人员通过这副X光透视眼镜可以看清楚输入到黑箱中的数据是怎样流转的。
            一些测试工具就像医院的检测仪器一样,可以帮助了解程序的内部运转过程。例如,对于一个与SQL Server数据库连接的软件系统,可以简单地把程序的作用理解为:把用户输入的数据通过SQL命令请求后台数据库,数据库把请求的数据返回给程序的界面 层展示给用户。可以把SQL Server自带的工具事件探查器当成是一个检查SQL数据传输的精密仪器,它可以记录软件客户端与服务器数据库之间交互的一举一动,从而让测试人员可以 洞悉软件究竟做了哪些动作。
            在测试过程中,应该综合应用黑盒测试方法和白盒测试方法,按需要采用不同的技术组合。不要用黑盒测试方法和白盒测试方法来划分自己属于哪一类测试人员,一名优秀的测试人员应该懂得各种各样的测试技术和查找Bug的手段。

  • 自动化脚本编写方法(z)

    2008-09-03 10:54:24

    摘要
            这篇文章详细描述几种自动化脚本编写方法,各自的优、缺点,同时在脚本编写的成本、编程技巧和脚本可维护性方面作出相应的评价。
    声明 
            作者在对这几种自动化脚本编写方法作出关于成本的评价时,没有参考任何自动化测试项目的成本分析文档或成本效益分析结果。建议读者基于自己的理解和考虑风险来消化利用这些信息。
    文章的编排 
            这篇文章主要分析自动化的成本,然后在描述每一种脚本编写方法时指出它的优点和缺点。 
            关于优缺点,从以下方面进行评价:

    1. 脚本的编写是否是结构化的
    2. 测试用例在什么地方定义
    3. 开发脚本的成本
    4. 需要怎样的编程技能
    5. 如何计划、设计和管理脚本
    6. 测试数据放在什么地方
    7. 脚本如何维护,维护成本
    8. 其它方面

    成本 
            测试脚本相关的成本主要由开发成本和维护成本组成。在自动化测试过程中使用不同的脚本编写方法会对成本有不同程度的影响。

    3

            “录制回放”的方法是简单的,也是脆弱的,但是它的开发成本很低,然而维护成本很高,因此总体成本也会很高。使用先进的关键字驱动测试的方法,则维护成本 会很低,但是开发成本会很高,因此总体成本也会很高。测试经理需要在这些方法中作出明智的选择,以便把总体成本尽量降低。

    编写脚本的方法 
            不同的自动化测试脚本编写方法主要有:

    1. 线性的
    2. 结构化的
    3. 共享的
    4. 数据驱动的
    5. 关键字驱动的

    线性脚本编写方法 
            线性脚本编写方法是使用简单的录制回放的方法,测试工程师使用这种方法来自动化地测试系统的流程或某些系统测试用例。它可能包含某些多余的、有时候并不需要的函数脚本。

    优缺点:

    1. 是一种非结构化的编程方式
    2. 测试用例由脚本定义
    3. 非常低的开发成本
    4. 测试人员所需要的编程方面的技巧几乎可以忽略
    5. 不需要计划、设计
    6. 测试数据在脚本中是硬编码的
    7. 脚本会很脆弱,因此维护成本会很高
    8. 没有公用的脚本,因此可能造成重复劳动

    结构化脚本编写方法 
            结构化脚本编写方法在脚本中使用结构控制。结构控制让测试员可以控制测试脚本或测试用例的流程。在脚本中,典型的结构控制是使用“if-else”, “switch”,“for”,“while”等条件状态语句来帮助实现判定、实现某些循环任务、调用其它覆盖普遍功能的函数

    优缺点:

    1. 是结构化的脚本编写方法
    2. 测试用例在脚本中定义
    3. 编程的成本要比线性脚本编写方法略为高一点
    4. 需要测试员的调整编码技巧
    5. 需要某种程度上的计划、设计
    6. 测试数据也是在脚本中被硬编码
    7. 因为相对稳定一点,所以需要相对少的脚本维护,维护成本比线性脚本编写方法的要相对低
    8. 除了编程知识外,还需要一些脚本语言的知识

    共享脚本编写方法 
            共享脚本编写方法是把代表应用程序行为的脚本在其它脚本之间共享。意味着把被测应用程序的公共的、普遍的功能的测试脚本独立出来,其它脚本对其进行调用。 这使得某些脚本按照普遍功能划分来标准化、组件化。这种脚本甚至也可以使用在被测系统之外的其它软件应用系统。

    优缺点:

    1. 脚本是结构化的
    2. 测试用例在脚本中定义
    3. 开发成本相对于结构化脚本编写方法来说要降低一些,因为减少了很多复制的劳动
    4. 需要测试员的调整代码的编程技巧
    5. 由于脚本需要模块化,所以需要更多的计划和设计
    6. 测试数据也是硬编码的
    7. 脚本维护和维护成本要比线性脚本编写方法的相对低

    数据驱动脚本编写方法 
            这种方法把数据从脚本分离出去,存储在外部的文件中。这样脚本就只是包含编程代码了。这在测试运行时要改变数据的情况下是需要的。这样脚本在测试数据改变时也不需要修改代码。有时候,测试的期待结果值也可以跟测试输入数据一起存储在数据文件中。

    优缺点:

    1. 脚本是以结构化的方式编程的
    2. 测试用例由测试数据或脚本定义
    3. 由于脚本参数化和编程成本,这种方法的开发成本跟共享脚本编写方法比较要相对高
    4. 需要测试员较高的代码调整方面的编程技巧
    5. 需要更多的计划和设计
    6. 数据独立存储在数据表或外部文件
    7. 脚本维护成本较低
    8. 推荐在需要测试正反数据的时候使用

    关键字驱动脚本编写方法 
            这种方法把检查点和执行操作的控制都维护在外部数据文件。因此测试数据和测试的操作序列控制都是在外部文件中设计好的,除了常规的脚本外,还需要额外的库来翻译数据。是数据驱动测试方法的扩展。

    优缺点:

    1. 综合了数据驱动脚本编写方法、共享脚本编写方法、结构化脚本编写方法
    2. 测试用例由数据定义
    3. 开发成本高,因为需要更多的测试计划和设计、开发方面的投入
    4. 要求测试人员有很强的编程能力
    5. 最初的计划和设计、管理成本会比较高
    6. 数据在外部文件存储
    7. 维护成本比较低
    8. 需要额外的框架或库,因此测试员需要更多的编程技巧

    评价

      1. 关于开发的成本

            随着脚本编写方法从线性到关键字驱动的改变,开发的成本不断地增加。

      1. 关于维护的成本

            随着脚本编写方法从线性到关键字驱动的改变,维护的成本在降低。

      1. 关于编程技能要求

            随着脚本编写方法从线性到关键字驱动的改变,对一个测试员的编程熟练程度的要求在增加。

      1. 关于设计和管理的需要

            随着脚本编写方法从线性到关键字驱动的改变,设计和管理自动化测试项目的要求在增加。

    参考
    Software Test Automation:Effective use of test execution tools ?(作者:Dorothy Graham、Mark Fewster)

  • 新手的困惑

    2008-03-13 16:29:49

Open Toolbar