盼望着,盼望着,每个人心中都有自己的梦想,希望我在这里能够结交更多的朋友!让我们共同的生活多姿多彩

发布新日志

  • Python在测试中的应用

    2017-10-13 10:59:52

    Python在测试中的应用

    发表于:2017-10-09 15:21  作者:懒猫Nemo   来源:51Testing软件测试网采编

    字体:   | 上一篇 | 下一篇 |我要投稿 | 推荐标签: Python Selenium 自动化测试

      Python语言是一种面向对象的用途广泛的变成语言,语法清晰,可以完成许多任务,由于海量的第三方库的存在,实现的功能非常多也非常的容易。
      Python是一种动态的脚本语言,学习成本大大低于Java等编程语言,因此对于我们测试人员来说,如果需要掌握一门语言,当然Python是最好的选择;
      Python丰富的第三方库,几乎想要的功能,都能找到对应的库,而我们应用这些库的时候,只考虑怎么去使用这些库提供的API而不用考虑怎么去实现,极少出现需要二次开发的情况;
      Python开发效率很高,同样的任务大约是java的10倍,C/C++的10-20倍,当然这个统计来源于一些编程人员的感受,并不是精确的数值,但是也可以看出其开发效率之高。我们测试人员一般都会主要以手工测试为主,因此不可能全职来运用某种语言实现,因此肯定需要选择效率高的,人生苦短,我用Python;
      Python支持多种系统,linux、mac上都默认安装了Python,windows更不用说,当我们测试需要在各种平台运行脚本的时候,几乎不用考虑跨平台。
      那如果我们学会了Python,哪些方面可以应用Python来辅助我们的测试呢?显而易见并应用最广泛的当属自动化测试了。
      Python + Selenium实现web端的UI自动化:
      Selenium是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中,就像真正的用户在操作一样。支持的浏览器包括IE(7, 8, 9, 10, 11),Mozilla Firefox,Safari,Google Chrome,Opera等。这个工具的主要功能包括:测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。
      Python与Selenium结合能够很好的实现web端的UI级别的自动化。Selenium几乎能解决目前遇到的web页面中所有的定位难题,当然有些特殊的可以借助JavaScripts也可以实现。
      Python + Requests实现接口测试
      进入python requests官网看到的的第一句话是:
      Requests 唯一的一个非转基因的Python HTTP 库,人类可以安全享用。
      通过requests库提供的各种API可以非常方便的模拟HTTP请求,实现接口自动化测试。
      Python + Appium实现app自动化测试:
      Appium是一个自动化测试开源工具,支持 iOS 平台和Android 平台上的原生应用,web 应用和混合应用。
      所谓的 移动原生应用 是指那些用iOS 或者 Android SDK 写的应用。所谓的 移动 web 应用 是指使用移动浏览器访问的应用(Appium 支持 iOS 上的Safari 和 Android 上的 Chrome)。所谓的“混合应用”是指原生代码封装网页视图——原生代码和web 内容交互。比如,像 Phonegap,可以帮助开发者使用网页技术开发应用,然后用原生代码封装,这些就是混合应用。
      重要的是,Appium 是一个跨平台的工具:它允许测试人员在不同的平台(iOS,Android)使用同一套API来写自动化测试脚本,这样大大增加了iOS 和 Android 测试套件间代码的复用性。
      Appium也是多语言支持,当然也是支持python的,运用python + Appium可以实现跨平台的app UI自动化测试。
      Python编写工具辅助测试:
      Python 提供了多个图形开发界面的库,几个常用 Python GUI 库如下:
      Tkinter:
      Tkinter 模块(Tk 接口)是Python 的标准 Tk GUI 工具包的接口。Tk 和 Tkinter 可以在大多数的Unix 平台下使用,同样可以应用在Windows 和 Macintosh 系统里。Tk8.0 的后续版本可以实现本地窗口风格,并良好地运行在绝大多数平台中。
      wxPython:
      wxPython 是一款开源软件,是 Python 语言的一套优秀的GUI 图形库,允许 Python 程序员很方便的创建完整的、功能键全的GUI 用户界面。
      Python还有很多快速开发的web框架,比如Django、falsk、webpy等,通过这些框架也是能很容易快速的开发出web应用。
      通过这些GUI库、web框架,可以写出很多小工具辅助测试。
      结语:
      一旦你学会一门语言,对于日常工作中,都可以自己写点工具来解放那些繁琐重复的工作,让你有更多的时间放在更有意义的测试上。同时你也学到了很多的技术,也能让你更好的完成测试工作。
  • 测试

    2010-09-19 18:19:31

     微软在这方面是一致提倡的,按照我们国内IT业的恶习,一般都是软件主体差不多成型了,拉几个测试人员过来点点,其实这是非常不好的。微软的测试人员在项目一开始就和开发人员同步介入,在需求阶段就开始介入,进行需求评审。在开发人员开始编码的时候,测试人员就开始编写Test case,并开发一些测试工具,或者写一些配套的测试代码(不要奇怪,微软的测试人员都能写很好的代码)。微软的理念就是:预防bug比解决bug好,所以非常提倡测试尽早介入,把一部分bug消灭在需求阶段。
  • 教你如何选择Rational测试工具

    2008-10-06 12:54:27

    IBM Rational系列包括多款测试产品,他们各有侧重,又有重合。所以,常用人会疑惑功能测试该用哪一个产品合适?负载测试又该选择哪一个产品呢?本文将从产品用途、适用环境、支持协议及产品特点上,说明四款主要Rational测试工具区别和联系。

      首先我们将整个Rational测试分为四大块:功能测试、性能测试、开发测试和测试管理。 Rational测试管理工具包括Rational TestManager和Rational ClearQuest。Rational开发测试工具则包括Rational PurifyPlus、Rational Test RealTime等。功能测试和性能测试工具才是本文将主要介绍的。

      Rational功能测试工具

      Rational功能测试工具又可分为手动测试工具(Rational Manual Tester),和自动测试工具(IBM Rational Functional Tester和IBM Rational Robot)。

      IBM Rational Manual Tester

      RMT是一款手工测试的编写和执行工具,以简化手工测试的创建、执行和控制。它鼓励重用测试步骤,使多个测试可共享内容。

      RMT可在任何Windows PC上适用,支持分布式团队,但是集中维护测试和测试结果。

      RMT建立在Eclipse框架和Hyades之上,两者都是开源项目。

      RMT适用Rich Text编辑器,支持在测试步骤中附带图像和文档。支持导入现有的基于Word和Excel的手工测试。

      IBM Rational Functional Tester

      RFT是Rational测试工具中的明星产品,是一款自动化的功能测试和回归测试工具。

      RFT基于Eclipse 3.0,支持Java、Web和VS.Net WinForm产品的自动化测试

      相较于Robot的SQABasic语言,RFT生成Java或Visual Basic .Net语言的测试脚本,简单明了。可以在RFT里设置Java脚本的编译和运行环境JRE,满足测试系统需求。

      RFT并不只是简单的用户动作记录器,它提供了多个API, 完全支持测试脚本的修改和增强,定制满足特殊需求的测试小工具。

      RFT支持并行开发用途,实现测试脚本的版本控制。

      Rational性能测试工具

      Rational功能测试工具包括手动测试工具IBM Rational Performance Tester和IBM Rational Robot(Robot包括功能测试和性能测试)。

      IBM Rational Performance Tester

      RPT是Rational目前主要的性能测试工具,准确地说它是集性能测试的创建、执行和分析的性能解决方案平台。

      RPT支持HTTP、HTTPS、J2EE、Siebel和SAP等协议,可为J2EE、Sieble、SAP和基于Web的应用程序提供可扩展性和负载测试。去年新推出的Rational Performance Tester Extension for SOA Quality还提供了RPT上对SOA应用的测试,支持SOAP协议。

      RPT基于Eclipse,其架构上的优势,使RPT对协议的支持更加灵活和方便。

      RPT支持不同操作系统(Windows、Linux),不同浏览器(IE、Mozilla等)下的测试执行。

      RPT可在测试过程任意点插入自定义的Java代码,实现高级操作和诊断技术,定制灵活的测试。

      IBM Rational Robot

      Robot一款自动化测试工具,是Rational的元老级产品,可用于集中式的QA团队对基于多种C/S技术的应用程序自动执行功能测试和性能测试。

      目前,Robot对几乎所有流行的应用环境都有良好的支持和工作表现。尤其是对HTML、Java和.NET应用、Visual Basic、PowerBuilder、Delphi、Oracle表单和MFC控件(最常用在C和C++应用中)有着强大的支持。

      Robot使用SQA Basic语言对测试脚本进行编辑。SQA Basic遵循Visual Basic的语法规则,初次接触的测试人员可能会有些困惑,不过应该能够较快地理解代码的含义。SQA也可以非常灵活地进行一些高级编程,比如利用COM 对象或者访问Windows编程接口。

  • 突破自我,突破思维定势,突破昨天!一个常见的面试题

    2008-09-10 10:18:13

    给你一个软件,你测试了一个月都没有发现bug,这说明什么?你怎么办?

    看到这个题目,一时之间真不知道如何回答,因为的确没有遇到过这样的情况。我的看法是:

    1.说明软件已经没有bug了.严格说应该是说明软件中残留的bug已经很少了且是隐藏比较深的.尤其是一个经过大量使用的成熟软件,但对于一个新软件来讲,很少会遇到测试了一个月都没有发现bug的情况.

    2.说明测试用例设计的太少或不够好,需要补充新的测试用例.尤其需要补充一些覆盖无效等价类的测试用例.

    3.测试人员需要突破思维定势,打破常规.常见的情况可能是测试人员和程序员合作一段时间后,也更容易发现程序员容易犯的错误,但随着程序员对这些常犯错误的总结逐渐成熟起来,在写代码的时候,根据以前多次修改BUG的经验,已经在自觉的规避可能出错误的代码写法,从而写出的代码更规范更可靠。若测试人员还按照惯性思维去测试,当然就不太容易再发现BUG了。这时候,测试人员就应该突破思维定势,打破常规!多和别的测试人员交流,不断学习新的测试技术和方法,积极的实践!

  • 测试报告编写指南

    2008-09-09 14:35:15


    摘要
    测试报告是把测试的过程和结果写成文档,并对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。本文提供测试报告模板以及如何编写的实例指南。

    关键字

    测试报告 缺陷


    正文
        
    测试报告是测试阶段最后的文档产出物,优秀的测试经理应该具备良好的文档编写能力,一份详细的测试报告包含足够的信息,包括产品质量和测试过程的评价,测试报告基于测试中的数据采集以及对最终的测试结果分析。

    下面以通用的测试报告模板为例,详细展开对测试报告编写的具体描述。

    PART
    首页
    0.1
    页面内容:
    密级

        
    通常,测试报告供内部测试完毕后使用,因此密级为中,如果可供用户和更多的人阅读,密级为低,高密级的测试报告适合内部研发项目以及涉及保密行业和技术版权的项目。

    XXXX
    项目/系统测试报告

    报告编号

        
    可供索引的内部编号或者用户要求分布提交时的序列号

    部门经理 ______项目经理
    ______
    开发经理______测试经理
    ______
    XXX
    公司 XXXX单位 (此处包含用户单位以及研发此系统的公司)

    XXXX
    XXXX


    0.2
    格式要求:

        
    标题一般采用大体字(如一号),加粗,宋体,居中排列

    副标题采用大体小一号字(如二号)加粗,宋体,居中排列

    其他采用四号字,宋体,居中排列


    0.3
    版本控制:

    版本 作者 时间 变更摘要

    新建/变更/审核


    PART
    引言部分
    1.1
    编写目的

        
    本测试报告的具体编写目的,指出预期的读者范围。

    实例:本测试报告为XXX项目的测试报告,目的在于总结测试阶段的测试以及分析测试结果,描述系统是否符合需求(或达到XXX功能目标)。预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。

    提示:通常,用户对测试结论部分感兴趣,开发人员希望从缺陷结果以及分析得到产品开发质量的信息,项目管理者对测试执行中成本、资源和时间予与重视,而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告XXXXXX章节,你的报告读者越多,你的工作越容易被人重视,前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。

    1.2
    项目背景

        
    对项目目标和目的进行简要说明。必要时包括简史,这部分不需要脑力劳动,直接从需求或者招标文件中拷贝即可。

    1.3
    系统简介

        
    如果设计说明书有此部分,照抄。注意必要的框架图和网络拓扑图能吸引眼球。

    1.4
    术语和缩写词

        
    列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚,以便阅读时不会产生歧义。

    1.5
    参考资料

    1
    .需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。

    2
    .测试使用的国家标准、行业指标、公司规范和质量手册等等

    PART
    测试概要
    测试的概要介绍,包括测试的一些声明、测试范围、测试目的等等,主要是测试情况简介。(其他测试经理和质量人员关注部分)


    2.1
    测试用例设计

        
    简要介绍测试用例的设计方法。例如:等价类划分、边界值、因果图,以及用这类方法(3-4)

    提示:如果能够具体对设计进行说明,在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念,顺便说一句,在这里写上一些非常规的设计方法也是有利的,至少在没有看到测试结论之前就可以了解到测试经理的设计技术,重点测试部分一定要保证有两种以上不同的用例设计方法。


    2.2
    测试环境与配置

        
    简要介绍测试环境及其配置。

        
    提示:清单如下,如果系统/项目比较大,则用表格方式列出

    数据库服务器配置

    CPU

    内存:

    硬盘:可用空间大小

    操作系统:

    应用软件:

    机器网络名:

    局域网地址:

    应用服务器配置

    …….
    客户端配置

    …….
        
    对于网络设备和要求也可以使用相应的表格,对于三层架构的,可以根据网络拓扑图列出相关配置。


    2.3
    测试方法(和工具
    )
        
    简要介绍测试中采用的方法(和工具)

    提示:主要是黑盒测试,测试方法可以写上测试的重点和采用的测试模式,这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项,当使用到测试工具和相关工具时,要说明。注意要注明是自产还是厂商,版本号多少,在测试报告发布后要避免大多工具的版权问题。


    PART
    测试结果及缺陷分析
    整个测试报告中这是最激动人心的部分,这部分主要汇总各种数据并进行度量,度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。对于不需要过程度量或者相对较小的项目,例如用于验收时提交用户的测试报告、小型项目的测试报告,可省略过程方面的度量部分;而采用了CMM/ISO或者其他工程标准过程的,需要提供过程改进建议和参考的测试报告-主要用于公司内部测试改进和缺陷预防机制-则过程度量需要列出。


    3.1
    测试执行情况与记录
    描述测试资源消耗情况,记录实际数据。(测试、项目经理关注部分)


    3.1.1
    测试组织

        
    可列出简单的测试组架构图,包括:

    测试组架构 (如存在分组、用户参与等情况)

    测试经理(领导人员)

    主要测试人员

    参与测试人员


    3.1.2
    测试时间

        
    列出测试的跨度和工作量,最好区分测试文档和活动的时间。数据可供过程度量使用。

    例如 XXX子系统/子功能

    实际开始时间-实际结束时间

    总工时/总工作日

    任务 开始时间 结束时间 总计

    合计

        
    对于大系统/项目来说最终要统计资源的总投入,必要时要增加成本一栏,以便管理者清楚的知道究竟花费了多少人力去完成测试。

    测试类型 人员成本 工具设备 其他费用


    总计

        
    在数据汇总时可以统计个人的平均投入时间和总体时间、整体投入平均时间和总体时间,还可以算出每一个功能点所花费的时/人。

    用时人员 编写用例 执行测试 总计


    合计

        
    这部分用于过程度量的数据包括文档生产率和测试执行率。

    生产率人员 用例/编写时间 用例/执行时间 平均


    合计


    3.1.3
    测试版本

        
    给出测试的版本,如果是最终报告,可能要报告测试次数回归测试多少次。列出表格清单则便于知道那个子系统/子模块的测试频度,对于多次回归的子系统/子模块将引起开发者关注。


    3.2
    覆盖分析


    3.2.1
    需求覆盖

        
    需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值,通常情况下要达到100%的目标。

    需求/功能(或编号) 测试类型 是否通过 备注

    [Y][P][N][N/A]
    根据测试结果 ,按编号给出每一测试需求的通过与否结论。P表示部分通过,N/A表示不可测试或者用例不适用。实际上,需求跟踪矩阵列出了一一对应的用例情况以避免遗漏,此表作用为传达需求的测试信息以供检查和审核。

    需求覆盖率计算 Y/需求总数 ×100


    3.2.2
    测试覆盖

        
    需求/功能(或编号) 用例个数 执行总数 未执行 /漏测分析和原因


        
    实际上,测试用例已经记载了预期结果数据,测试缺陷上说明了实测结果数据和与预期结果数据的偏差;因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差,列表的目的仅在于更好的查看测试结果。

    测试覆盖率计算 执行数/用例总数 ×100


    3.2
    缺陷的统计与分析

        
    缺陷统计主要涉及到被测系统的质量,因此,这部分成为开发人员、质量人员重点关注的部分。


    3.3.1
    缺陷汇总

        
    被测系统 系统测试 回归测试 总计


    合计

    按严重程度

    严重 一般 微小

    按缺陷类型

    用户界面 一致性 功能 算法 接口 文档 用户界面 其他

    按功能分布

    功能一 功能二 功能三 功能四 功能五 功能六 功能七

    最好给出缺陷的饼状图和柱状图以便直观查看。俗话说一图胜千言,图标能够使阅读者迅速获得信息,尤其是各层面管理人员没有时间去逐项阅读文章。

    图例


    3.3.2
    缺陷分析

        
    本部分对上述缺陷和其他收集数据进行综合分析

    缺陷综合分析

    缺陷发现效率 缺陷总数/执行测试用时

    可到具体人员得出平均指标

    用例质量 缺陷总数/测试用例总数 ×100

    缺陷密度 缺陷总数/功能点总数

    缺陷密度可以得出系统各功能或各需求的缺陷分布情况,开发人员可以在此分析基础上得出那部分功能/需求缺陷最多,从而在今后开发注意避免并注意在实施时予与关注,测试经验表明,测试缺陷越多的部分,其隐藏的缺陷也越多。

    测试曲线图

    描绘被测系统每工作日/周缺陷数情况,得出缺陷走势和趋向

    重要缺陷摘要

    缺陷编号 简要描述 分析结果 备注


    3.3.3
    残留缺陷与未解决问题

    残留缺陷

    编号:BUG

    缺陷概要:该缺陷描述的事实

    原因分析:如何引起缺陷,缺陷的后果,描述造成软件局限性和其他限制性的原因

    预防和改进措施:弥补手段和长期策略

    未解决问题

    功能/测试类型:

    测试结果:与预期结果的偏差

    缺陷:具体描述

    评价:对这些问题的看法,也就是这些问题如果发出去了会造成什么样的影响


    PART
    测试结论与建议
    报告到了这个部分就是一个总结了,对上述过程、缺陷分析之后该下个结论,此部分为项目经理、部门经理以及高层经理关注,请清晰扼要的下定论。

    4.1
    测试结论

    1
    测试执行是否充分(可以增加对安全性、可靠性、可维护性和功能性描述)

    2
    对测试风险的控制措施和成效

    3
    测试目标是否完成

  • 如何做有效的测试报告。

    2008-09-09 14:31:46

    编写测试报告

    既然是说到如何编写有效的测试报告,那么我的重点就是在于有效,而不是一般的洋洋洒洒几千字的非常八股文的测试报告,有时候怎么说呢,唉,生在中国就不得不搞一些形象工程,所以,一说到报告大家的概念好像就必须是洋洋洒洒罗罗嗦嗦繁冗复杂的数千字……不过,我在这里不想谈那个政绩报告。偶是一个非常实用主义者。

    废话少说,我们要说的是如何做有效的测试报告。

    既然说到有效,我觉得要有两个特点:完整和实用,突出重点。引用一句广告词就是说简约而不简,就是说要完整但又不说废话,能肥则肥,能瘦则瘦,重点部分要突出,要细说,非重点部分,一笔带过,只是为了保证一个文档的完整性。

    说到一个测试报告,是对测试的过程和结果的汇总描述,所以其核心内容是两个,一个是测试结果的汇总报告,一个是测试过程的汇总总结,前者是针对所测软件本身,是给所测软件一个客观真实的评价;后者则是针对过程改进,回顾测试流程中存在的不足,加以总结改进。除了这两项核心内容之外,其他的内容都是次要的,但是为了保持文档的美观性和周全性,其他各部分还是要写写的。

    具体说一般一个测试报告有如下部分构成,下面一一细说。(下面也是我在我们公司执行的模板)

     

    本周51testingzhuzx问到这个问题,这个问题问的真是很帅很高深。我想这样的问题是没有标准答案的,各自按照自己的经验和实践来给出自己的看法,在此我也聊聊我的看法,仅一家之言,欢迎讨论。

    说到软件缺陷预防技术吧,其实什么是缺陷预防,就是说能把缺陷消灭在萌芽状态,就是能在缺陷还没产生出来就已经被扼杀了,这也是软件测试者所追求的最高境界。一般的软件测试属于后来弥补型,产生bug之后再来修改,但是bug发现越晚,修改掉花的代价就越大,所以软件缺陷预防技术就是项目生命周期的早期消灭bug

    般常用的缺陷预防有几个阶段,需求阶段,设计阶段,编码阶段。

    第一,在需求阶段,最重要的事情是需求验证。一般验证的几个大项是,功能是否完整,是否考虑性能,有没有模糊需求,有没有考虑安全性,有没有冗余和错误的需求,需求是不是过于苛刻,需求是不是矛盾等方面。一般常用的方法是列出需求检查表,并进一步执行需求/测试 矩阵。

    第二,设计阶段,这个阶段主要通过技术评审测试逻辑设计。常用比较规范的作法是建立过程/数据矩阵,也就是CRUD矩阵,把过程影射到实体,把整个程序的数据的生命周期(建立,更新,读取,删除)反映出来。

    第三,编码阶段,这个阶段预防措施主要有统一编码规范,代码评审,单元测试。统一代码规范一般是开发经理统一要求,代码评审则是互相评审或者开发leader进行评审,最后最重要的则是单元测试,就是一般说的白盒测试

    再来说缺陷分析吧,很多很高深的分析技术也不很实用,我只介绍一点常用的分析方法。

    1.模块的缺陷分布,一般用柱状图或饼状图,就是每一个功能模块发现bug的比例,发现bug最多的模块证明在发布以后需要更多的维护。

    另外,历史数据可以参照,譬如上一个版本在哪个模块发现的bug比例对这个版本就是一个参考。如果,某个模块发现bug的比例比上个版本大幅下降,则很可能说明该模块还需要更多测试。

    2.缺陷的起因分布,一般用柱状图或饼状图,一般可分为架构缺陷、功能缺陷、易用性缺陷、性能缺陷、安全性缺陷、界面文字缺陷。一般如果架构缺陷占的比例较大,则说明设计有很大问题。

    3.按照不同发现人员的缺陷分布,一般用柱状图或饼状图,一般分为测试人员发现,开发人员发现,beta测试发现,外部客户发现。如果测试人员发现的bug低于某个比例,证明质量保证测试不足。

    4.按照不同方式的缺陷分布 ,一般有需求审查,设计测试,代码走查,JAD,手工测试,自动化测试,白盒测试。一般来说,如果通过需求审查,设计测试,代码走查,JAD发现的bug比重很低则说明测试前期重视不够,另外,在手工测试和自动化测试之间的比例也能说明自动化测试的贡献度。

    5.缺陷差额分析,就是已经发现的和已经解决的曲线关系,以时间为横轴,两者越接近说明产品质量越高

    6.按照时间段的缺陷分布,一般用时间为横轴的曲线图表示,主要说明在哪个阶段发现的bug最多,对测试总结有指导意义

    7.Rayleigh分析,就是俗称的零缺陷追踪法,一般截至某个时间点发现的缺陷总数和时间有一个函数关系(一个复杂的数学函数),一般用这个函数来推测经过多少天测试之后软件中大概还有多少个bug,以及交付到用户手中之后大概还能出现多少个bug。不过由于本人严重怀疑该方法的实用性,我还没用过。

     

     

    如何编写有效的测试报告?以下是我的回答了解你的听众:通常情况下测试报告主要由以下几类人员查看:
    用户着重点在于测试结论部分;
    开发人员着重点在于缺陷结果以及分析得到产品质量的信息;
    项目管理者着重点在于测试中资源,时间和成本;
    高层经理着重点在于项目当前的状况与其他项目比较。

     

     

    i 摘要
    ii
    功能作用
    iii
    操作适合人群
    iv
    与硬件兼容性
    v
    运行流程
    vi
    维护措施
    vii
    报错处理

     

  • 修改版WinXP集体歇业 避免遭遇调查

    2008-08-22 20:21:49

    8月22日消息,番茄花园版Windows XP的作者被拘后,其他版本的修改版XP也都集体“歇业”,他们或关闭提供下载的网站,或删除所有自己制作的操作系统软件的下载链接,以免遭到调查。

      必须说明的是,有资料显示番茄花园利用捆绑流氓软件,可能因此存在获利。新浪科技本次调查了14种其他版本的修改XP,不能认定他们是否捆绑了流氓软件以及是否因此获利。

      在19日晚间,番茄花园作者洪磊被拘的消息还未得到确认,只限于论坛流传状态。当时,新浪科技通过尝试访问其他修改版XP的官方下载网站发现,仅有少数几家“歇业”,但大部分还能下载到修改版的软件。

      集体“歇业”

      20日,新浪科技独家披露番茄花园作者洪磊确认被拘的消息后,在业界引发了强烈的反响。22日凌晨,新浪科技再次尝试登陆这些版本的官方下载网站时发现,他们已经集体歇业,或关闭提供软件下载的官方网站,或删除所有自己制作的操作系统软件的下载链接。

      详细情况是:雨林木风版XP的官方下载地址ghost.ylmf.com已经跳转至一个导航站114la.com;电脑公司装机版的官网为东海技术论坛,目前显示“论坛改版中”,无法访问;深度版、秋无痕版、999宝藏版、罗布家园版、盛世雄风技术论坛的官方论坛可以正常访问,但不提供深度版Windows XP的下载;赢狗电脑公司专用版、永航技术版网站无法访问,其他的版本如俄罗斯破解版、上海市政府版、龙卷风纯净版、铂金花园版无官方网站,一些下载网站的部分链接,包括BT方式依然可以下载。

      总结来看,14个版本,5家无法访问,5家官方论坛可以访问,但不提供修改版XP下载,4家不通过官方网站下载方式传播,一些下载网站的部分链接可以下载。

      雨林木风版发公告声援番茄花园

      21日中午,修改版XP另外一个版本雨林木风版在其官方论坛上挂出来一条加红的公告,上面写着:“等候环境对他的事业完全有利才动手的人,将永远不会成功。”

      微软此次投诉番茄花园被一些网友视为“卸磨杀驴”,“四年来一直不投诉,到了Windows XP满大街都是了才投诉”,他们微软目前的状况真是“环境对他的事业完全有利”。因此,这一条公告被解读为雨林木风版对番茄花园默默的声援。

  • 添加Bug时,我们应该注意些什么

    2008-08-22 20:10:58

      1. 缺陷摘要(Summary)

      简单明了,便于理解

      长度一般不超过30个单词

      尽可能讲明:什么情况,导致了什么问题

      便于他人定位Bug,杜绝不重复报相同的Bug

      2. 缺陷描述(Descrīption)

      重现步骤(Actions)

      详细描述重现该问题的关键步骤

      省略无关的操作,力求做到:所有重现步骤是充分的和必要的

      容易理解的常规步骤,可以一句话带过,比如以管理员身份登录,进入后台用户管理页面

      和环境有关的问题,给出特定的条件,比如某某操作系统,某某浏览器

      实际结果(Actual Result)

      描述实际出现的错误结果

      可借助截屏来表达

      不是总能重现的Bug,给出发生频率或规律

      期待结果(Expected Result)

      可选,当Spec上没有对实现方式做详细要求时,用于测试人员表达自己的看法


      3. 截屏/附件(Attachment)

      针对文字难以表达的或UI方面的问题

      图片格式使用JPG格式;Windows画图工具的默认BMP图片太大,不建议使用

      在图片上用醒目的颜色,标出问题所在区域

      也可考虑配上简短的文字


      4. 其它

      对于多人同时测试同一模块的情况,报Bug前先检查是否已有类似的Bug (TD提供了简单的Find Similar Defects的功能)

      Bug严重程度(Severity)必须准确

      Bug优先级(Priority) 必须准确(具体请参考公司标准文档)

      填写Module/Function字段,便于Dev Manager 分配给相应的开发人员

      项目中共性的问题,纳入Common Module

      多个相同的问题,如是一个Dev负责修改的,撰写一个缺陷报告就可以,但须指出 问题发生的多个位置

      对于Reject的有争议的Bug,尽可能和Dev当面沟通

  • 今天我的空间开通啦

    2008-08-21 16:25:55

    以后可以在这里切磋测试的技术喽!!好开心那!!~~