测试人生快乐进行中。。

发布新日志

  • 软件测试过程的度量

    2008-10-31 15:24:52

    1测试度量的作用
       A:为制定测试计划时提供依据
        需要多长时间? 需要什么物质条件?  需要多少人,什么素质的人? 在规定的时间内能完成到什么程度?
        哪些模块及功能需要重点关注? 测试工作量占整个项目的比例? 测试结束后我们能达到什么样的目标 ?等等
    (
    这些数据是我们在项目启动过程中,制定测试计划,尤其在规划资源的过程中,一些必要的参考值。不同项目可能会有其特殊性,但从总体上看,他们还是有一些规律可寻的,过去的经验数据可以作为一个大概估算,如果项目经验丰富,那么可以从历史数据中找出和新项目 类似的情况,以能更为准确的完成计划。 )
      B 提高测试流程可控性
        提高测试效率和质量
        提高测试人员的成就感

    2)在测试哪个过程做度量
    (产品早期的市场评估、测试策略分析、可测试性需求分析、测试工具分析、用例设计阶段、执行阶段和 FOA 阶段)
    我们需要在测试的几个关键阶段做度量,它们分别是:用例设计阶段、执行阶段和 FOA 阶段。测试用例设计阶段包括测试方案的最终确定、测试工具的设计、测试用例编写等,测试执行阶段很明显,即我们测试的各个过程,如集成测试、系统测试、性能测试、回归测试等,也包括开发人员完成的单元测试的度量工作。 FOA 阶段是检验测试质量的第一步,通过 FOA 我们可以获得很多为产品质量做贡献的度量,这也是体现测试价值的度量。看起来几乎包括了测试过程的全部。其实这里包括的只是测试的具体工作阶段。

    3)测试度量的内容
    两种度量类型:
        A 项目度量:规模、测试工作量、测试进度、测试生产率
        B 质量度量:缺陷率(阶段)、缺陷排除率、可靠性等
    四个基本度量项:规模、工作量、进度、缺陷

    4) 测试用例设计阶段的度量
       A:规模 :测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月
        B 工作量 :文档的草稿编写工作量、评审前阅读工作量、评审工作量 、修改工作量
       C 进度 :每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率
        D 缺陷 :评审过程中出现的错误数量、缺陷数量,级别

    5)测试执行阶段的度量:
    ?
    测试用例执行率       ? 测试用例通过率
    ?
    测试用例问题发现率     ? BUG数量
    ? BUG
    级别统计         ? BUG分布统计(模块)
    ? BUG
    分布统计(阶段)     ? BUG密度
    ? BUG
    关闭率          ? 人均BUG发现效率
    ?
    测试用例执行工作量项目   ? 回归测试执行工作量
    ?
    发布文档数量        ? 发布文档缺陷数量、级别
    ?
    现场发现的BUG数量      ? 回归测试现场BUG的工作量
    ?
    版本发布过程中的验证周期  ? 版本发布过程中的验证工作量
    ?
    测试用例覆盖率       ? 功能的用户关注度
    ?
    需求变化程度  

    6)测试的度量为项目实施做的贡献

    度量项

    含义

    目的与意义

    测试生产率

    单位时间所测试的代码量、或者单位时间执行测试用例的数量

    一个团队的测试能力

    工作量变化率

    实际花费工作量相对于估计工作量的偏差百分比

    提高估计技能、避免过载分配任务

    测试进度变化率

    项目实际测试进度相对于计划进度的偏差百分比

    监控项目以便适时采取纠正措施

    工作量

    测试所做的工作小时数

    测试为整个项目贡献的工作量

    缺陷密度

    千行代码发现的缺陷数,千个功能发现的缺陷数

    用于度量被测试系统的可靠性

    测试问题的严重性

    测试发现问题的严重性分布

    用于确定目前被测试系统的可靠性

    测试用例的问题发现效率

    单个测试用例发现问题的数量

    用于度量测试用例的有效性

    测试用例覆盖率

    需求覆盖率、功能点覆盖率、代码覆盖率等

    度量测试的充分性

    问题遗漏率

    发布后市场反馈问题数/产品问题总数目

    衡量内部测试质量

    COQ

     

    为提升测试质量所付出的工作量

    COPQ

     

    为不好的质量付出的代价

    7)由谁来做度量
    8)怎样做度量?
    PDCA
    方法:
         第一步:Plan   ( 计划、设置标竿) ( 查看(1000) 评论(0) 收藏 分享 管理

  • 如何学习自动化测试(转)

    2008-09-16 17:26:44

     

    从事了几年测试工作,也着实见证了测试的发展,如今测试行业对从业者的要求是越来越高,不再仅仅局限于要求会写测试用例、会细致的执行测试、能有效的发现系统缺陷等;越来越多的企业对应聘者本身的技能要求也越来越高,招聘信息中诸如“精通VBscrīpt、Perl/Rbuy等至少一门脚本语言”、“至少熟悉一门开发语言”、“精通QTP、LR等自动化测试工具”、“有大型项目自动化实施成功经验”此类的字眼也逐渐增多。目前看来,除白盒测试内容和测试管理外,主流的方向有两个:功能自动化测试和性能测试。这就要求从业人员能够在短时间内快速的掌握这些知识,才能获取到更好的工作机会。本人是名功能自动化测试的工程师,以自己学习、工作的过程结合QTP讲讲该如何学习自动化测试

    首先,想从事自动化测试,必须先了解What/Why/How,也就是常说的去了解什么是自动化测试、为什么要进行自动化测试、该如何进行自动化测试,这类的资料在网上有很多,这里就不做重复了

    其次,需要根据项目的特点,选择合适的自动化测试工具,并了解工具的特性。以QTP为例,该如何去掌握它呢?对于初学者,大多数都是通过录制的方式来生成脚本,这个阶段应该掌握的基础知识有

    1)      QTP是如何去识别对象的,对于新手经常会出现录制的脚本回放的时候报错的现象,这个时候就应该考虑为什么呢?如果很了解QTP识别对象的原理啊,我想就能很快定位到原因了

    2)      去掌握一些QTP对象的方法,如GetROPreperty、GetTOPreperty、ChildObjects等等,对于相似的方法应该去搞清楚到底区别在哪?像GetROPreperty、GetTOPreperty有什么区别等

    3)      什么是Action参数、什么又是Test参数?两者有什么区别,又有什么联系,在同一Test和不同Test间这些参数如何工作

    4)     什么是环境变量?环境变量是如何建立和使用的,环境变量在参数传递中和action参数、test参数有什么不同

    5)     了解检查点的知识,明白什么是内置检查点,什么又是自定义检查点。并搞清楚在什么时候该如何使用检查点

    6)     掌握对象库的操作,了解对象库对于测试的意义,象是否启用智能识别对测试脚本有何影响、为什么同一对象识别起来会有_1、_2之类的后缀等都是需要去研究清楚的问题

    这几个问题都搞清楚的话,那基本就能够利用QTP生成正确的脚本了,当然以上只是部分必须掌握的内容,其实还是很多细节的设置,就需要在实际运用中去掌握了

    接下来,就可以进一步提升自己的QTP运用水平了,这个阶段就需要去学习vbs知识和如何运用描述性编程实现脚本了,同时在这个过程中还需要去学习html知识、DOM、XML、以及像excel、word等的API知识了,总的来说,这个阶段应该掌握的内容大体上包括

    1)     VBscrīpt的基础知识,熟悉常用的方法和函数,掌握文件对象的操作等

    2)     熟练掌握XML技术;excel、word等API对象,可以根据需要创建日志等

    3)     熟练掌握DOM和HTML知识,能够结合这些技术对Web页面进行解析

    4)     掌握数据库的基本操作语句,能够利用ADO对象进行数据操纵

    5)     熟练掌握正则表达式,很多时候处理对象问题相当方便

    6)     掌握如何调用dll进行工作

    7)     能够利用QTP的自动化对象模型创建出需要的运行模式

    8)     掌握WMI知识

    以上只是我考虑到的部分,并不全面,呵呵,供大家参考,当然这些技术主要是针对Web系统运行,因为我们的系统就是B/S的,呵呵。如果这些知识都能够扎实的掌握的话,个人认为,基本上能够处理自动化过程中的绝大多数问题了,这个时候你对自动化测试的技术应该是有一定积累了

    接下来就需要考虑自动化测试框架问题了。当脚本规模到了一定的程度,就会面临一些问题,如:

    1)       如何有效的管理并调度脚本

    2)     如何实现脚本运行的无人值守,测试过程中能够自动进行错误处理并进行日志记录

    3)     如何生成简介明确的测试报告

    4)     如何能够更加高效的维护测试脚本

    5)     实现框架代码和业务代码的分层、业务脚本和业务数据的分离

    这个阶段主要体现的是测试人员的测试思想,是可以脱离工具独立存在的过程。当然各个公司项目的实际情况不同,导致设计出来的思想不同,但总体上来说一般包括数据驱动和关键字驱动两种模式。后者实现的技术难度大于前者,大多数公司目前都采用的数据驱动模式。这个阶段不应局限于技术运用上,而需要从测试全局考虑,进行分层设计、模块化实现,减少代码之间的耦合

    如果以上三个方面都能够做的很好的话,那么恭喜你,你已经可以独立负责项目的自动化测试建立工作了,呵呵!

    总之,学习自动化测试需要在实际项目中进行,这样提高的会比较快,项目中运用了很多种技术,自动化实施过程会碰见各种各样的问题,是很好的学习机会,关键要善于总结、积累经验,只要能够把各个细节做好,那么你一定能够成为一名优秀的自动化测试工程师

  • Web系统测试方法(转)

    2008-09-16 15:49:59

    Web系统测试方法(网站测试-网站系统测试方法)


    随着Internet和Intranet/Extranet的快速增长,Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上,电子商务迅速增长,早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在,是因为它能提供支持所有类型内容连接的信息发布,容易为最终用户存取。

    Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科,提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则,用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前,对于web工程的研究主要是在国外开展的,国内还刚刚起步。

    在基于Web的系统开发中,如果缺乏严格的过程,我们在开发、发布、实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大。而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题。当这种情况发生时,我们对Web和Internet的信心可能会无法挽救地动摇,从而引起Web危机。并且,Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

    在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。然而,Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

    一般软件的发布周期以月或以年计算,而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期,测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

    一、功能测试

    1、链接测试
    链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。

    链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

    2、表单测试
    当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

    3、Cookies测试
    Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。

    如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。

    4、设计语言测试
    Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

    5、数据库测试
    在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

    在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。

    二、性能测试
    1、连接速度测试
    用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

    另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

    2、负载测试
    负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

    3、压力测试

    负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。
    进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。
    压力测试的区域包括表单、登陆和其他信息传输页面等。

    三、可用性测试

    1、导航测试

    导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

    在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。

    导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。


    Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

    2、图形测试


    在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

    (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

    (2)验证所有页面字体的风格是否一致。

    (3)背景颜色应该与字体颜色和前景颜色相搭配。

    (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。


    3、内容测试

    内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

    信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"。

    4、整体界面测试

    整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?
    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

    对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

    四、客户端兼容性测试

    1、平台测试

    市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。

    因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

    2、浏览器测试

    浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,Javascrīpt是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

    测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

    五、安全性测试

    Web应用系统的安全性测试区域主要有:

    (1)现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。

    (2)Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

    (3)为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

    (4)当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。

    (5)服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

    六、总结

    本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

    基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。

  • 软件测试中的网站系统测试技术要领(转)

    2008-09-16 15:46:39

    软件测试中的网站系统测试技术要领


    基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。
      本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

      随着Internet和Intranet/Extranet的快速增长,Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上,电子商务迅速增长,早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在,是因为它能提供支持所有类型内容连接的信息发布,容易为最终用户存取。

      Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科,提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则,用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前,对于web工程的研究主要是在国外开展的,国内还刚刚起步。

      在基于Web的系统开发中,如果缺乏严格的过程,我们在开发、发布、实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大。而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题。当这种情况发生时,我们对Web和Internet的信心可能会无法挽救地动摇,从而引起Web危机。并且,Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

      在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。然而,Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

      一般软件的发布周期以月或以年计算,而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期,测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

      网站测试流程、要求及测试报告

      一个网站基本完工后,需要通过下面三步测试才可以交活。

      一、 制作者测试,包括美工测试页面、程序员测试功能。在做完后第一时间内有制作者本人进行测试。

      a) 页面 包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;图片上有没有错别字;各连接是否是死连接;各栏目图片与内容是否对应等

      b) 功能 达到客户要求;数据库连接正确;各个动态生成连接正确;传递参数格式、内容正确;试填测试内容没有报错;页面显示正确

      二、 全面测试 根据交工标准和客户要求,由专人进行全面测试

      也是包括页面和程序两方面,而且要结合起来测,保证填充足够的内容后不会导致页面变形。另外要检查是否有错别字,文字内容是否有常识错误。

      三、 发布测试 网站发布到主服务器之后的测试,主要是防止环境不同导致的错误

    软件缺陷的原则

      软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等
      软件未达到产品说明书标明的功能。
      软件出现了产品说明书指明不会出现的错误。
      软件功能超出产品说明书指明范围。
      软件未达到产品说明书虽未指出但应达到的目标。
      软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。
  • 系统测试全过程(转)

    2008-09-16 15:09:50

       我一直感觉系统测试总像马拉松总是测试不完,什么时候上线,什么时候算终点。虽然提交客户了,可是对于质量仍然心里没底,对于测试的效果没有评价的依据。后来经过高人指点,终于领悟到至关重要的精髓:明确测试目标
        如果要将系统进行全面测试,那么就要有一套完整的测试阶段,每个阶段都以测试目标为标准,科学、有序地进行测试,那么测试效率也就会自然而然跟着提高。


    测试阶段分为:测试前准备、需求分析、测试计划、测试设计、测试执行、测试结果。


    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版本

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

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

我的栏目

数据统计

  • 访问量: 2968
  • 日志数: 5
  • 建立时间: 2008-09-16
  • 更新时间: 2008-10-31

RSS订阅

Open Toolbar