淡了,散了,一点点;累了,睡了,呼呼中;懂了吗?是的

发布新日志

  • 测试计划摸板

    2007-09-10 10:39:17

     

     

     

     

    测试计划

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    修订历史记录

    版本       

    日期      

    AMD      

    修订者     

    说明     

    1.0

    XXXXXXXX

     

     

     

     

     

     

     

     

    A-添加,M-修改,D-删除)

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    目录

    1         简介... 4

    1.    1目的... 4

    1.    2背景... 4

    1.3范围... 4

    2.    测试参考文档和测试提交文档... 5

    2.1测试参考文档... 5

    2.2测试提交文档... 5

    3.测试进度... 6

    4.测试资源... 7

    4.1人力资源... 7

    4.2测试环境... 7

    4.3测试工具... 7

    5.系统风险、优先级... 8

    6.测试策略... 9

    6.1数据和数据库完整性测试... 9

    6.2接口测试... 10

    6.3集成测试... 11

    6.4功能测试... 12

    6.5用户界面测试... 13

    6.6性能评测... 14

    6.7负载测试... 15

    6.8强度测试... 16

    6.9容量测试... 17

    6.10安全性和访问控制测试... 18

    6.11故障转移和恢复测试... 19

    6.12配置测试... 21

    6.13安装测试... 22

    7.问题严重度描述... 23

    8.附录:项目任务... 24

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    1.  简介

    1.   1目的

    <项目名称>的这一“测试计划”文档有助于实现以下目标:

     

    [确定现有项目的信息和应测试的软件构件。

    列出推荐的测试需求(高级需求)。

    推荐可采用的测试策略,并对这些策略加以说明。

    确定所需的资源,并对测试的工作量进行估计。

    列出测试项目的可交付元素]

    1.   2背景

    [对测试对象(构件、应用程序、系统等)及其目标进行简要说明。需要包括的信息有:主要的功能和性能、测试对象的构架以及项目的简史。]

    1.3范围

    [描述测试的各个阶段(例如,单元测试、集成测试或系统测试),并说明本计划所针对的测试类型(如功能测试或性能测试)。

    简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。

    如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施,则列出所有这些假设。

    列出可能会影响测试设计、开发或实施的所有风险或意外事件。

    列出可能会影响测试设计、开发或实施的所有约束。]

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    2. 测试参考文档和测试提交文档

    2.1测试参考文档

    下表列出了制定测试计划时所使用的文档,并标明了各文档的可用性:

    [注:可适当地删除或添加文档项。]

    文档

    (版本/日期)

    已创建或可用

    已被接收或已经过复审

    作者或来源

  • 缺陷管理说明

    2007-09-06 17:00:08

    缺陷管理

    软件存在缺陷,但是如何有效的管理缺陷是软件能不能正常提交的一个保障,这里引入缺陷管理的一些概念和方法。

     

    1,概念

    • 缺陷生命周期

    缺陷管理需要遵循一个流程,也就是缺陷的生命周期。粗略的划分,缺陷的生存周期可以分为这么一些阶段,

     

    缺陷汇报(submitted

    缺陷确认(accepted)(TobeCorrected

    缺陷修改(Corrected

    缺陷修改确认(Validated

    不是问题(not a problem

    此外,有一些附加状态,比如,暂不修改(derogation),继承(inherit

     

    • 缺陷级别

    缺陷级别也是个很重要的概念,同时存在两种级别,一种是从测试人员角度定义的级别,另一种是从开发人员角度定义的级别,两种级别在大多数时候都是一致的。简单来讲,缺陷级别可以分为以下几种:

     

    非常低(very low

    (low)

    重要(important)

    非常重要(severe)

    同时,由于产品的决策或者设计问题,有的缺陷也会以一种建议的方式出现,这个时候,也许所汇报的缺陷根本就不是缺陷,而更多的是对于产品能够更加友好的一种建议。

     

    2,缺陷在项目和产品当中的管理异同

    由于项目和产品在用户影响方面的差异,缺陷也会在其中表现出一些不同的地方,比如说,在产品当中,用户友好性差一点,可以被当成一种建议来做,但是在项目当中,这个就成为了一种缺陷,有的时候甚至是很严重的缺陷。那么总体来讲,有那么一些不同。

    • 级别定义不同
    • 确认方式不同(产品修改确认需要的是一个官方的发布版本,但是项目的确认方式也许就是一个补丁)
    • 修改方式不同(项目的缺陷无沦巨细,都是需要在提交给用户之前修改的,但是产品的缺陷却可以延迟到下一个版本)
    • 缺陷转换(缺陷是可以由项目转换到产品,然后由产品统一控制,管理的,因为项目组的侧重点和产品组的侧重点是不一样的,很多问题在项目当中出现,但是项目组没有能力修改,那么就需要产品组予以帮助)

     

    3,却陷管理工具

    缺陷需要管理,但是如果单纯的靠纸和笔进行管理,显然是不能够满足需要的,简单来讲,却陷管理工具至少能够满足以下特点,

    • 以项目为基础的管理方式
    • 严格的用户权限管理(不同的角色应该具备不同的权限)
    • Email通知机制(当状态改变以后,相关人员能够被通知到)
    • 从不同的维度进行缺陷的统计
    • 全方位的缺陷查询
    • 项目缺陷级别可定义
    • 软件模块定义

     

    现在,有很多业界比较认可的缺陷管理工具,包括Test Director, ClearQuest等等,免费的工具有Bugzilla也很好。不妨下载一个使用版本来玩玩。:)

     

    4,却陷统计报表

    缺陷报表之所以重要是因为,报表能够为我们提供事后统计,而定期的报表也能够为我们提供项目管理的支持,我们能够根据缺陷的汇报以及分布情况来判断当前的项目进度情况,什么模块出现的缺陷最多。在项目完结的时候,缺陷报告也能够为我们提供当前的软件测试是不是已经达到了要求,是不是可以提交给客户。

    一般情况下,我们会根据以下几种情况来定义缺陷情况,

    ·         缺陷分布情况:这里对于各种不同状态的缺陷的一个快照

    1

    ·         各种级别的缺陷的分布情况

    2

    ·         缺陷发展的趋势

    3

     

    在项目完结的时候生成上面的图形,如果发现还存在打开状态的缺陷,就需要做出决策,这样的缺陷需要关闭吗?还是在下一个版本当中修改或者别的解释。总之,在提交软件产品的时候,是不能存在一个开启状态的缺陷存在的。

     

     

    4,汇报缺陷的一些建议

    缺陷汇报是缺陷制造者和缺陷发现者之间沟通的桥梁,所以,缺陷必须被描述清楚,这里,有几点建议,

    ·         详细描述操作步骤

    ·         粘贴日志信息作为附件

    ·         对于界面测试,需要把错误界面捕捉下来,作为附件粘贴上

    ·         错误修改确认的时候,需要把软件版本号加上

    ·         测试数据描述

    ·         测试先决条件描述

  • mantis

    2007-09-06 16:57:19

    mantis_1.0.8安装文件加安装说明加使用说明书

    • 上传不了,以后再和大家分享吧!
  • 简单设置保护眼睛

    2007-09-05 12:05:05

    一个朋友前一段时间因为常常加班导致眼睛过度疲劳得了干眼症,大夫建议他电脑屏幕不要用白色,因为白色对眼睛的刺激是最大的。像我们这样整天对着电脑干活的,也 应该注意一下。 其实,只要稍微设置一下,就能让你电脑上的窗口从白花花的颜色变成淡淡的绿色。
    设置方法如下: 在桌面点右键选“属性”(properties),接着点“外观”(appearance),点右下 角的“高级”(advanced),然后在“项目”(items)的下拉菜单里选“窗口” (windows),再点它右侧的下拉菜单“颜色”(color),点下方的“其它” (others),然后把“色调”(Hue)设为85,“饱和度”(Sat)设为90,“亮度” (Lum)设为205。 (产品出厂时,一般分别设为160、0、240。) 然后单击“添加到自定义颜色”(Add to custom colors),按“确定”(OK)…… 一直“确定”(OK)下去。然后屏幕上会出现一个小Windows的画面,上写“请稍 候”。 把窗口设成绿色之后,再来把IE的网页背景也变成养眼的绿色吧: 打开IE,点击“工具”(TOOLS),点最下方的“Internet选项”(INTERNET OPTIONS),点右下角的“辅助功能”(Assessibility),然后勾选第一个“不使用网 页中指定的颜色”(ignore colors specified on web pages),然后点“确定” (OK)--确定……退出。 OK啦,现在你就会发现你的屏幕已经变成淡淡的绿色了。 这个颜色会比白色柔和许多,刚开始可能你还有些不适应,但确实对我们的眼睛有好处,大家不妨试一下。

  • 测试心情

    2007-09-04 15:29:32

    工作了一段时间,感觉比较复杂,一时也说不好。只能说,测试中,团队精神真的很重要,再有就是测试领队要有一定的测试知识和经验,不然在这样的团队里可能很难把一个项目规划好,让测试所做的工作起到应该有的作用。

    呵呵,目前的环境比较的混乱。心情不是很好。不过项目的成功与否真的不是测试可以保证的,有多种原因。

    只想以后的工作环境能有改善:)一切期待中

    也希望同行的朋友们有什么好的经验和工具能够多多分享啊:)先谢谢了!

  • 我的存档

    数据统计

    • 访问量: 3030
    • 日志数: 5
    • 建立时间: 2007-09-04
    • 更新时间: 2007-09-10

    RSS订阅