发布新日志

  • 常见功能测试点<zhuan>

    2012-07-09 15:54:48

    以前在这里看到一篇文章说,要积累各个常用模块的测试点,然后到需要测试的时候就根据这些测试点设计测试用例,我觉得这是一个好方法,就决定总结一下。我的实际经验不多,根据我在论坛中学到的零散的东西和自己的想象,总结出以下几点,欢迎各位继续补充。
    1.        登陆
    2.        添加
    3.        查询
    4.        删除


    1.        登陆
    ①        用户名和密码都符合要求(格式上的要求)
    ②        用户名和密码都不符合要求(格式上的要求)
    ③        用户名符合要求,密码不符合要求(格式上的要求)
    ④        密码符合要求,用户名不符合要求(格式上的要求)
    ⑤        用户名或密码为空
    ⑥        数据库中不存在的用户名,不存在的密码
    ⑦        数据库中存在的用户名,错误的密码
    ⑧        数据库中不存在的用户名,存在的密码
    ⑨        输入的数据前存在空格
    ⑩        输入正确的用户名密码以后按[enter]是否能登陆

    2.        添加
    ①        要添加的数据项均合理,检查数据库中是否添加了相应的数据
    ②        留出一个必填数据为空
    ③        按照边界值等价类设计测试用例的原则设计其他输入项的测试用例
    ④        不符合要求的地方要有错误提示
    ⑤        是否支持table键
    ⑥        按enter是否能保存
    ⑦        若提示不能保存,也要察看数据库里是否多了一条数据

    3.        删除
    ①        删除一个数据库中存在的数据,然后查看数据库中是否删除
    ②        删除一个数据库中并不存在的数据,看书否有错误提示,并且数据库中没有数据被删除
    ③        输入一个格式错误的数据,看是否有错误提示,并且数据库中没有数据被删除。
    ④        输入的正确数据前加空格,看是否能正确删除数据
    ⑤        什么也不输入
    ⑥        是否指出table键
    ⑦        是否支持enter键

    4.        查询
    精确查询:
    ①        输入的查询条件为数据库中存在的数据,看是否能正确地查出相应得数据
    ②        输入正确的查询条件以前加上空格,看是否能正确地查出相应的数据
    ③        输入格式或范围不符合要求的数据,看是否有错误提示
    ④        输入数据库中不存在的数据
    ⑤        不输入任何数据
    ⑥        是否支持table键
    ⑦        是否支持enter键
    模糊查询:
    在精确查询的基础上加上以下一点
    ①        输入一些字符,看是否能查出数据库中所有的相关信息
    设计功能和界面测试用例

    设计功能和界面测试用例


    1.1 文本框、按钮等控件测试

    1.1.1 文本框的测试

    如何对文本框进行测试

     a,输入正常的字母或数字。
     b,输入已存在的文件的名称;
     c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入 256个字符,检查程序能否正确处理;
     d,输入默认值,空白,空格;
     e,若只允许输入字母,尝试输入数字;反之;尝试输入字母;
     f,利用复制,粘贴等操作强制输入程序不允许的输入数据;
     g,输入特殊字符集,例如,NUL及\n等;
     h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示;
     i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示

    在测试过程中所用到的测试方法:

     1,输入非法数据;
     2,输入默认值;
     3,输入特殊字符集;
     4,输入使缓冲区溢出的数据;
     5,输入相同的文件名;
    命令按钮控件的测试

    测试方法:

     a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口;
     b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击”确定“后系统应提示:天数不能大于31;
     c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会;
    单选按钮控件的测试

    测试方法:

     a,一组单选按钮不能同时选中,只能选中一个。
     b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后,保存到数据库的数据应该相应的分别为“男”“女”;
     c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中,不能同时为空;
    up-down控件文本框的测试

    测试方法:

     a,直接输入数字或用上下箭头控制,如,在“数目”中直接输入10,或者单击向上的箭头,使数目变为10;
     b,利用上下箭头控制数字的自动循环,如,当最多数字为253时,单击向上箭头,数目自动变为1;反之亦适用;
     c,直接输入超边界值,系统应该提示重新输入;
     d,输入默认值,空白。如,“插入”数目为默认值,点击“确定”;或,删除默认值,使内容为空,单击“确定”进行测试;
     e,输入字符。此时系统应提示输入有误。
    组合列表框的测试

    测试方法:

     a,条目内容正确,其详细条目内容可以根据需求说明确定;
     b,逐一执行列表框中每个条目的功能;
     c,检查能否向组合列表框输入数据;
    复选框的测试

    测试方法:

     a,多个复选框可以被同时选中;
     b,多个复选框可以被部分选中;
     c,多个复选框可以都不被选中;
     d,逐一执行每个复选框的功能;
    列表框控件的测试

    测试方法:

     a,条目内容正确;同组合列表框类似,根据需求说明书确定列表的各项内容正确,没有丢失或错误;
     b,列表框的内容较多时要使用滚动条;
     c,列表框允许多选时,要分别检查shift选中条目,按ctrl选中条目和直接用鼠标选中多项条目的情况;
    滚动条控件的测试

    要注意一下几点:

     a,滚动条的长度根据显示信息的长度或宽度及时变换,这样有利于用户了解显示信息的位置和百分比,如,word中浏览100页文档,浏览到50页时,滚动条位置应处于中间;
     b,拖动滚动条,检查屏幕刷新情况,并查看是否有乱码;
     c,单击滚动条;
     d,用滚轮控制滚动条;
     e,滚动条的上下按钮。
    各种控件在窗体中混和使用时的测试

     a,控件间的相互作用;
     b,tab键的顺序,一般是从上到下,从左到右;
     c,热键的使用,逐一测试;
     d,enter键和esc键的使用;
    在测试中,应遵循由简入繁的原则,先进行单个控件功能的测试,确保实现无误后,再进行多个控件的的功能组合的测试。

    ps:密码输入框测试时要特别注意进行字母大写输入的测试。

    查找替换操作
     案例演示:打开word中的"替换"对话框
     测试本功能有通过测试和失败测试两种情况
     通过测试:

     1,输入内容直接查找,或查找全部
     2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.

    失败测试:
     1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
     2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;

    替换测试大体相同.
     关于编辑操作窗口的功能测试的用例:
     1,关闭查找替换窗口.不执行任何操作,直接退出;
     2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
     3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
     4,热键, Tab键.回车键的使用.

    插入操作
     1,插入文件
     测试的情况
     a,插入文件;
     b,插入图像;
     c,在文档中插入文档本身;
     d,移除插入的源文件;
     e,更换插入的源文件的内容;

    2,链接文件
     测试方法:
     a,插入链接文件;
     b,在文档中链接文档本身;
     c,移除插入的源文件;
     d,更换插入的源文件的内容.

    3,插入对象
     要测试的内容
     a,插入程序允许的对象,如,在word中插入excel工作表;
     b,修改所插入对象的内容.插入的对象仍能正确显示;
     c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.

    编辑操作
     编辑操作包括剪切,复制,粘贴操作.

    测试剪切操作的方法
     a,对文本,文本框,图文框进行剪切;
     b,剪切图像
     c,文本图像混合剪切
     复制操作方法与剪切类似.

    测试时,主要是对粘贴操作的测试,方法是:
     a,粘贴剪切的文本,文本框及图文框;
     b,粘贴所剪切的图像;
     c,剪切后,在不同的程序中粘贴
     d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
     e,利用粘贴操作强制输入程序所不允许输入的数据.

    界面测试用例的设计方法
     1,窗体
     测试窗体的方法:
     a,窗体大小,大小要合适,控件布局合理;
     b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
     c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
     d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
     进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;

    2,控件
     测试方法:
     a,窗体或控件的字体和大小要一致;
     b,注意全角,半角混合
     c,无中英文混合.

    菜单

    进行测试时要注意
     a,选择菜单是否可以正常工作,并与实际执行内容一致;
     b,是否有错别字:
     c,快捷键是否重复;
     d,热键是否重复;
     e,快捷键与热键操作是否有效
     f,是否存在中英文混合
     g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
     h,鼠标右键快捷菜单

    特殊属性
     1,安装界面应有公司介绍或产品介绍,有公司的图标
     2,主界面及大多数界面最好有公司图标
     3,选择"帮助"->"关于"命令,应 看见相关版权和产品信息
    实际中经常用到的几个用例

    login
    1、链接地址是否正确。
    2、产生输入/输出错误时,系统是否进行检测并处理.
    3、密码输入框是否按掩码的方式显示。

    menu:
    1、各模块链接地址是否正确。
    2、鼠标无规则点击时是否会产生无法预料的结果。

    browse:
    1、浏览信息是否存在文字书写错误和语法错误。
    2、浏览信息是否和数据库中对应的字段及信息相一致。
    3、浏览页面中的链接按钮是否可以正确链接并显示。
    4、其他功能按钮按下后,数据是否按既定规约处理。

    add,modify:
    1、产生输入/输出错误时,系统是否进行检测并处理。
    2、列表框是否能够进行选择。
    3、单选组内是否有且只有一个单选钮可选。
    4、多选组内是否能够进行多数据项选择。
    5、多项列表框是否能够进行多数据项选择。
    6、控件是否存在默认输入值,若存在,默认值是否得到显示和提交.
    7、Cancel之类的按钮按下后,控件中的数据是否清空复原或按既定规约处理.
    8、Submit之类的按钮按下后,数据是否得到提交或按既定规约处理。
    9、其他页面按钮按下后,数据是否按既定规约处理。
    10、异常信息表述是否正确。

    search:
    1、输入信息中是否存在和代码中的字符产生冲突的字符,系统是否进行检测并处理。
    2、异常信息表述是否正确。
    3、查询的结果是否正确。
    4、列表框是否能够进行选择。
    5、单选组内是否有且只有一个单选钮可选。
    6、多选组内是否能够进行多数据项选择。
    7、多项列表框是否能够进行多数据项选择。
    8、 Submit之类的按钮按下后,数据是否得到提交或按既定规约处理。


    Statistic:
    1、产生的文件和数据表的计算结果是否正确。
    2、图表结果数据显示是否正确。
    3、浏览页面中的链接按钮是否可以正确链接并显示。
    4、其他功能按钮按下后,数据是否按既定规约处理。
    5、产生输入/输出错误时,系统是否进行检测并处理。
    6、列表框是否能够进行选择。
    7、单选组内是否有且只有一个单选钮可选。
    8、多选组内是否能够进行多数据项选择。
    9、多项列表框是否能够进行多数据项选择。


  • 功能测试中遇到不可重现软件缺陷的解决策略<转>

    2012-07-09 15:35:27

    测试人员提交软件缺陷报告后,最不希望看到的这些缺陷被开发人员忽略,尽管你坚信这一定是软件缺陷,而罪魁祸首就是这些缺陷不可重现!一旦出现这样的情况,测试人员会很被动,开发人员也会对测试人员有意见。这就使得关系本来就不怎么融洽的测试人员和开发人员之间的关系更加紧张;对于整个时间紧凑的项目来说,无异于是火上浇油。为了减少这种尴尬情况的出现,非常有必要分析一下软件缺陷不能重现的原因。
    1. 测试环境不一致
    从广义上来说,保证或影响软件的任何因素都是环境,例如,系统的构造版本、应用服务器的类型和版本、浏览器的语音和版本等。
    以下就是我们会遇见的错误:某个B/S(Web应用)架构的系统软件运行于IE8上,出现了JS(Java Script)脚本错误导致页面浏览异常的软件缺陷,把IE8降级到IE6或7后,此软件缺陷就自动消失了。
    2. 测试配置不一致
    程序运行都是基于一定的配置条件下进行的,包括被测系统参数设置、基础数据完整性、业务流程完整性等,比如,我们曾经在某数据库产品测试过程中,由于在安装界面中选择了非默认路径进行安装,结果导致该数据库物理备份会恢复功能出错,而对方在核对缺陷时按照默认路径进行了安装,因此缺陷总是无法重现。
    3. 内存泄露
    某些系统长期运行后出现速度慢的原因是开发人员未养成回收内存的习惯。这类错误在短期内不会出现,但当系统长期运行时就会出现,并且由此会引发一系列的问题。
    4. 数据接口不匹配
    一般只有在查看源代码后才能发现。某些类型的数据会被系统自动转换,有些数据被截断或被强制转换成另外一种数据类型时,会出现一些潜在的错误。
    基于以上测试过程中出现的软件缺陷不能重现的原因,我们提出如下一些解决策略,以更好地从源头上减少不可重现软件缺陷的出现
    1. 测试环境配置充分细致
    测试人员在测试前,严格核对系统的运行环境配置要求,并充分考虑系统在线运行后的环境变化,做好测试环境配置的全面规划,注意细节。另外可以使用Ghost对硬件或某个分区进行镜像备份。
    2. 捕获系统日志,分析异常信息
    测试人员应养成记录系统错误日志的习惯,保留系统在出错时的真实状态。比如将IE浏览器高级选项设置为“显示每个脚本错误的通知”。
    3. 监测系统状态,异常及时告警
    在实施系统测试过程中,我们必须充分关注系统运行状态的变化,一旦系统运行状态发生较大的波动,势必会对后期的业务执行带来较大的影响。因此,系统运行监测的一个重要内容是需要及时反馈系统运行异常,并提供异常报告。
    4. 测试数据翔实,易于追溯
    测试数据是软件测试的核心,很多情况下,测试人员为了缩短测试周期,在实际测试前并没有充分编写足够的测试数据,也没有记录这些测试数据的执行顺序和运行轨迹,一旦程序在某个节点出现问题,我们无法判断其产生的过程和引起这个缺陷的具体测试数据,对我们进一步分析软件缺陷产生的原因会造成一些不必要的障碍。
    正是基于此我们强调在软件测试开始前,我们必须制定完整的测试用例,辅以详细的测试数据,并明确测试数据的操作步骤和每一步的预期结果,这样,一旦软件出现问题,我们可以很快进行重现和定位。
  • 文件上传--测试用例《转》

    2012-07-09 15:32:21

    1.功能测试
    (1)选择符合要求的文件,上传--------上传成功;
    (2)上传成功的文件名称显示----------显示正常(根据需求)
    (3)查看,下载上传成功的文件--------上传的文件可查看或下载
    (4)删除上传成功的文件-------------可删除
    (5)替换上传成功的文件-------------可替换
    (6)上传文件是否支持中文名称--------根据需求而定
    (7)文件路径是否可手动输入----------根据需求而定
    (8)手动输入正确的文件路径,上传-----上传成功
    (9)手动输入错误的文件路径,上传-----提示,不能上传
     
    2.文件大小测试
    (1)符合格式,总大小稍小于限制大小的文件------上传成功
    (2)符合文件,总大小等于限制大小的文件--------上传成功
    (3)符合文件总大小稍大于限制大小的文件--------在上传初提示附件过大
    (4)小为0kb的txt文档-----------------------不能上传
     
    3.文件名称测试
    (1)文件名称过长。Win2000标准:255个字符(指在英文的字符下),如果是中文不超过127个汉字-----提示过长
    (2)文件名称达到最大长度(中文,英文或混在一起)上传后名称显示,页面排版-----------页面显示正常
    (3)文件名称中包含特殊字符-------------根据需求而定
    (4)文件名全为中文--------------------根据需求而定
    (5)文件名全为英文--------------------根据需求而定
    (6)文件名为中、英混合-----------------根据需求而定
     
    4.文件格式测试
    (1)上传正确格式-----------------上传成功
    (2)上传不允许的格式--------------提示不能上传
    (3)上传rar,zip等打包文件(多文件压缩)---------根据需求而定
     
     
    5.安全性测试
    (1)上传可执行文件(exe文件)-----------------根据需求而定
    (2)上传常见的木马文件------------------------提示不能上传
    (3)上传时服务器空间已满----------------------有提示
     
     
    6.性能测试
    (1)上传时网速很慢(限速)-----------------当超过一定时间,提示
    (2)上传过程断网--------------------------有提示是否上传成功
    (3)上传过程服务器停止工资------------------有提示是否上传成功
    (4)上传过程服务器的资源利用率---------------在正常范围
     
    7.界面测试
    (1)界面美观性、易用性(键盘和鼠标的操作、tab跳转的顺序是否正确)----------显示正常(根据需求)
    (2)按钮文字是否正确--------------正确
    (3)正确/错误提示的文字是否正确---------------正确
    (4)说明性文字是否正确-----------------------正确
     
     
    8.其他测试
    (1)有多个上传框时,上传相同名称的文件---------------根据需求而定
    (2)上传一个正在打开的文件-------------------------可以上传
    (3)文件路径是手工输入的是否限制长度----------------限制一定的长度
    (4)上传过程中是否有取消正在上传文件的功能-----------有
    (5)保存时有没有已经选择好,但没有上传的文件-----------提示上传
    ()选择好但是未上传的文件是否可以取消选择------------可以取消选择
  • 测试总结

    2009-04-28 12:07:01

    测试总结

     

    1.摆正心态

    一个好的测试工程师应具有”测试是为了破坏”的观点,捕获用户观点能力,强烈的质量追求,对细节的关注能力.应用的高风险区的判断能力以便将有限的测试针对重点环节

     

    2. 细致负责

    任何BUG其实都是必现的,测试过程中要清楚自己的操作步骤,一旦问题出现,有很清晰的思路找到必现的规律。

    接到测试任务不要马上盲目就开始进行测试工作,首先考虑所分配的模块中哪些做了改动,都关联到哪些模块,还有哪些边界的地方可能没有测试到, 再进行有目的,有预期结果性的测试,一旦发现BUG 能很快定位

    在测试过程当中应将以前曾经遇到过的类似的错误从记忆深处挖掘出来,这一能力在测试过程中的价值是无法衡量的.因为许多新出现的问题和我们已经发现的问题相差无几.

     

    3.  拓展测试思路,尝试各种不同操作

    如找边界值:很多的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此,针对各种边界情况进行测试,可以查出更多的错误.

     

       软件测试需要模拟真实用户对软件进行操作和使用,从中查找出软件的缺陷。只有通过各种方式对软件全面测试,才能尽量避免漏测

     

    查看论坛和TD中的BUG,查看过程中要注意的问题:

    怎样的操作更容易出现问题

    别人的测试思路与风格和自己有什么区别

     

    4. 不厌其烦
    工作要细心认真,具有责任感

    善于学习、思考、发现、总结问题

    具有耐心与恒心 

    及时关注软件的改动情况

    每出新版本首先要注意:该版本修改了哪些bug?增加了什么功能?需要着重验证修改bug模块及相关模块。

     

     

  • 如何对文本框……进行测试

    2009-04-20 18:36:19

     

     

    1.1 文本框、按钮等控件测试

    1.1.1 文本框的测试

    如何对文本框进行测试

     a,输入正常的字母或数字。
     b,输入已存在的文件的名称;
     c,输入超长字符。例如在名称框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入 256个字符,检查程序能否正确处理;
     d,输入默认值,空白,空格;
     e,若只允许输入字母,尝试输入数字;反之;尝试输入字母;
     f,利用复制,粘贴等操作强制输入程序不允许的输入数据;
     g,输入特殊字符集,例如,NUL\n等;
     h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示;
     i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示

    在测试过程中所用到的测试方法:

     1,输入非法数据;
     2,输入默认值;
     3,输入特殊字符集;
     4,输入使缓冲区溢出的数据;
     5,输入相同的文件名;

    命令按钮控件的测试

    测试方法:

     a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口;
     b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击确定后系统应提示:天数不能大于31
     c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会;

    单选按钮控件的测试

    测试方法:

     a,一组单选按钮不能同时选中,只能选中一个。
     b,逐一执行每个单选按钮的功能。分别选择了”“后,保存到数据库的数据应该相应的分别为”“
     c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中,不能同时为空;

    updown控件文本框的测试

    测试方法:

     a,直接输入数字或用上下箭头控制,如,在数目中直接输入10,或者单击向上的箭头,使数目变为10
     b,利用上下箭头控制数字的自动循环,如,当最多数字为253时,单击向上箭头,数目自动变为1;反之亦适用;
     c,直接输入超边界值,系统应该提示重新输入;
     d,输入默认值,空白。如,插入数目为默认值,点击确定;或,删除默认值,使内容为空,单击确定进行测试;
     e,输入字符。此时系统应提示输入有误。

    组合列表框的测试

    测试方法:

     a,条目内容正确,其详细条目内容可以根据需求说明确定;
     b,逐一执行列表框中每个条目的功能;
     c,检查能否向组合列表框输入数据;

    复选框的测试

    测试方法:

     a,多个复选框可以被同时选中;
     b,多个复选框可以被部分选中;
     c,多个复选框可以都不被选中;
     d,逐一执行每个复选框的功能;

    列表框控件的测试

    测试方法:

     a,条目内容正确;同组合列表框类似,根据需求说明书确定列表的各项内容正确,没有丢失或错误;
     b,列表框的内容较多时要使用滚动条;
     c,列表框允许多选时,要分别检查shift选中条目,按ctrl选中条目和直接用鼠标选中多项条目的情况;

    滚动条控件的测试

    要注意一下几点:

     a,滚动条的长度根据显示信息的长度或宽度及时变换,这样有利于用户了解显示信息的位置和百分比,如,word中浏览100页文档,浏览到50页时,滚动条位置应处于中间;
     b,拖动滚动条,检查屏幕刷新情况,并查看是否有乱码;
     c,单击滚动条;
     d,用滚轮控制滚动条;
     e,滚动条的上下按钮。

    各种控件在窗体中混和使用时的测试

     a,控件间的相互作用;
     b,tab键的顺序,一般是从上到下,从左到右;
     c,热键的使用,逐一测试;
     d,enter键和esc键的使用;

    在测试中,应遵循由简入繁的原则,先进行单个控件功能的测试,确保实现无误后,再进行多个控件的的功能组合的测试。

    ps:密码输入框测试时要特别注意进行字母大写输入的测试。

    查找替换操作
     案例演示:打开word中的"替换"对话框
    查看(651) 评论(3) 收藏 分享 管理

  • 2009年度上半年计算机技术与软件专业技术资格(水平)考试报名

    2009-03-12 17:42:16

    http://www.bjpta.gov.cn/news_z.asp?news_id=705

    一、报名时间
      2009年3月5日至31日
      台湾居民资格审核时间
      2009年3月19日至20日
    二、网上打印准考证时间
      2009年5月19日至21日
    三、考试时间
      2009年5月23日

     

     


     

  • 计算机系统基础知识

    2009-03-11 13:05:15

    计算机系统基础知识
       1.1 计算机系统构成及硬件基础知识
        ●计算机系统的构成
        ●处理机
        ●基本输入输出设备
        ●存储系统
       1.2 操作系统基础知识
        ●操作系统的中断控制、进程管理、线程管理
        ●处理机管理、存储管理、设备管理、文件管理、作业管理
        ●网络操作系统和嵌入式操作系统基础知识
        ●操作系统的配置
       1.3 数据库基础知识
        ●数据库基本原理
        ●数据库管理系统的功能和特征
        ●数据库语言与编程
       1.4 中间件基础知识
       1.5 计算机网络基础知识
        ●网络分类、体系结构与网络协议
        ●常用网络设备
        ●Internet基础知识及其应用
        ●网络管理
       1.6 程序设计语言知识
        ●汇编、编译、解释系统的基础知识
        ●程序设计语言的基本成分(数据、运算、控制和传输、过程(函数)调用)
        ●面向对象程序设计
        ●C语言以及C++(或Java)语言程序设计基础知识
      2.标准化基础知识
        ●标准化的概念(标准化的意义、标准化的发展、标准化机构)
        ●标准的层次(国际标准、国家标准、行业标准、企业标准)
        ●标准的类别及生命周期
      3.信息安全知识
        ●信息安全基本概念
        ●计算机病毒及防范
        ●网络入侵手段及防范
        ●加密与解密机制
      4.信息化基础知识
        ●信息化相关概念
        ●与知识产权相关的法律、法规
        ●信息网络系统、信息应用系统、信息资源系统基础知识
      5.软件工程知识
       5.1 软件工程基础
        ●软件工程概念
        ●需求分析
        ●软件系统设计
        ●软件组件设计
        ●软件编码
        ●软件测试
        ●软件维护
       5.2 软件开发方法及过程
        ●结构化开发方法
        ●面向对象开发方法
        ●瀑布模型
        ●快速原型模型
        ●螺旋模型
       5.3 软件质量管理
        ●软件质量及软件质量管理概念
        ●软件质量管理体系
        ●软件质量管理的目标、内容、方法和技术
       5.4 软件过程管理
        ●软件过程管理概念
        ●软件过程改进
        ●软件能力成熟度模型
       5.5 软件配置管理
        ●软件配置管理的意义
        ●软件配置管理的过程、方法和技术
       5.6 软件开发风险基础知识
        ●风险管理
        ●风险防范及应对
       5.7 软件工程有关的标准
        ●软件工程术语
        ●计算机软件开发规范
        ●计算机软件产品开发文件编制指南
        ●计算机软件需求规范说明编制指南
        ●计算机软件测试文件编制规范
        ●计算机软件配置管理计划规范
        ●计算机软件质量保证计划规范
        ●数据流图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定

    6.软件测试知识
       6.1 软件测试基本概念
        ●软件质量与软件测试
        ●软件测试定义
        ●软件测试目的
        ●软件测试原则
        ●软件测试对象
       6.2 软件测试过程模型
        ●V模型
        ●W模型
        ●H模型
        ●测试模型的使用
       6.3 软件测试类型
        ●单元测试、集成测试、系统测试
        ●确认测试、验收测试
        ●开发方测试、用户测试、第三方测试
        ●动态测试、静态测试
        ●白盒测试、黑盒测试、灰盒测试
       6.4 软件问题分类
        ●软件错误
        ●软件缺陷
        ●软件故障
        ●软件失效
       6.5 测试标准
        7.5.1 GB/T 16260.1—2003 软件工程 产品质量 第1部分:质量模型
        7.5.2 GB/T 18905.1—2002 软件工程 产品评价 第1部分:概述
        7.5.3 GB/T 18905.5—2002 软件工程 产品评价 第5部分:评价者用的过程
  • Web 测试的经验

    2007-04-15 21:22:34

    Web 测试的经验

     

    1. 功能测试
    1.1.链接测试
       链接是 Web 应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证 Web 应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的 URL 地址才能访问。
       链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个 Web 应用系统的所有页面开发完成之后进行链接测试。
    1.2. 表单测试
       当用户给 Web 应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。
    1.3.Cookies测试
    Cookies 通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用 Cookies 访问了某一个应用系统时, Web 服务器将发送关于用户的信息,把该信息以 Cookies 的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。
       如果 Web 应用系统使用了 Cookies ,就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用,是否按预定的时间进行保存,刷新对 Cookies 有什么影响等。
    1.4.设计语言测试
    Web 设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的 HTML 等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了 HTML 的版本问题外,不同的脚本语言,例如 Java 、 Javascrīpt 、 ActiveX 、 VBscrīpt 或 Perl 等也要进行验证。
    1.5.数据库测试
       在 Web 应用技术中,数据库起着重要的作用,数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中,最常用的数据库类型是关系型数据库,可以使用 SQL 对信息进行处理。

    在使用了数据库的 Web 应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。
    2. 性能测试
    2.1.连接速度测试
       用户连接到 Web 应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长(例如超过 5 秒钟),用户就会因没有耐心等待而离开。
       另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。
    2.2.负载测试
       负载测试是为了测量 Web 系统在某一负载级别上的性能,以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量,也可以是在线数据处理的数量。例如: Web 应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象? Web 应用系统能否处理大量用户对同一个页面的请求?
    2.3.压力测试
      负载测试应该安排在 Web 系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个 Web 系统能同时处理的请求数量将远远超出这个限度,所以,只有放在 Internet 上,接受负载测试,其结果才是正确可信的。
       进行压力测试是指实际破坏一个 Web 应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试 Web 应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到 Web 应用系统崩溃,接着当系统重新启动时获得存取权。
       压力测试的区域包括表单、登陆和其他信息传输页面等。
    3. 可用性测试
    3.1.导航测试
       导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个 Web 应用系统是否易于导航:导航是否直观? Web 系统的主要部分是否可通过主页存取? Web 系统是否需要站点地图、搜索引擎或其他的导航帮助?
       在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动,很快地扫描一个 Web 应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构,因此, Web 应用系统导航帮助要尽可能地准确。
       导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容,内容在什么地方。
    Web 应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。
    3.2.图形测试
       在 Web 应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:
       ( 1 )要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
       ( 2 )验证所有页面字体的风格是否一致。
       ( 3 )背景颜色应该与字体颜色和前景颜色相搭配。
       ( 4 )图片的大小和质量也是一个很重要的因素,一般采用 JPG 或 GIF 压缩。
    3.3.内容测试
       内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。
       信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用 Microsoft Word 的 " 拼音与语法检查 " 功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般 Web 站点中的所谓 " 相关文章列表 " 。
    3.4.整体界面测试
       整体界面是指整个 Web 应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览 Web 应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个 Web 应用系统的设计风格是否一致?
    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。
       对所有的可用性测试来说,都需要有外部人员(与 Web 应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。
    4. 客户端兼容性测试
    4.1.平台测试
       市场上有很多不同的操作系统类型,最常见的有 Windows 、 Unix 、 Macintosh 、 Linux 等。 Web 应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。
       因此,在 Web 系统发布之前,需要在各种操作系统下对 Web 系统进行兼容性测试。
    4.2.浏览器测试
       浏览器是 Web 客户端最核心的构件,来自不同厂商的浏览器对 Java ,、 Javascrīpt 、 ActiveX 、 plug-ins 或不同的 HTML 规格有不同的支持。例如, ActiveX 是 Microsoft 的产品,是为 Internet Explorer 而设计的, Javascrīpt 是 Netscape 的产品, Java 是 Sun 的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。
       测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
    5. 安全性测试
    Web 应用系统的安全性测试区域主要有:
       ( 1 )现在的 Web 应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。
       ( 2 ) Web 应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如 15 分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
       ( 3 )为了保证 Web 应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
       ( 4 )当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。
       ( 5 )服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
    6. 总结
       本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于 Web 的系统测试方法。
    基于 Web 的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于 Web 的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。

  • 功能测试用例的书写方式

    2007-04-15 21:19:39

    功能测试用例的书写方式

    功能性测试用例
    1. 测试的来源,即测试的需求
    测试用例的主要来源有:
    1) 需求说明”及相关文档

    2)相关的设计说明(概要设计,详细设计等)

    3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)

    4)已经基本成型的UI(可以有针对性地补充一些用例)

    简而言之,所有你能得到的项目文档,都尽量拿到。 从所得到的资料中,分解出若干小的“功能点”,理解“功能点”,编写相应的测试用例。

    2. 用例的组织方式

    不同的公司有不同的做法,原则上,只要方便管理和跟踪,怎么组织都可以的。

    用例可以按大的功能块组织,如查询功能模块的用例,可以组织在一起,打印模块的测试用例,可以另外组 织在一起。

    在没有专门的测试用例管理工具的情况下,用例执行后会产生2种状态:“通过”、“失败”——这样加上“未 执行”的用例的状态,共3种状态。

    即从“未执行”用例中执行一个用例后,该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。

    至于用例文件格式,可以是.DOC或.XLS(如果有专门的测试用例管理工具另当别论)。

    3. 用例与其他材料的关联方式,即如何解决用例跟踪的问题 测试用例面临的比较大的风险有:

    需求的变更、设计的修改、需求的错误和遗漏等等。

    由于用例的主要来源是需求和设计的说明,所以对用例的跟踪其实就是对需求和设计的跟踪,需求和设计的 变更势必引起测试用例的变更。

    如前所说,将分解的功能点编号,与相应的用例联系起来。例如,你可以列一个表格,列出各个(编号的)功 能点和测试用例间的关联关系。

    这样,当需求和设计发生变化时,你只需要跟踪“功能点”是否变化,是否增 加了新的功能点。

    重要和困难的是,不手头的资料和信息一定要是最新的。

    4. 一个好的用例的表述要点,即用例中应当包含的信息

    一个优秀的测试用例,应该包含以下信息:

    1) 软件或项目的名称

    2) 软件或项目的版本(内部版本号)

    3) 功能模块名

    4) 测试用例的简单描述,即该用例执行的目的或方法

    5) 测试用例的参考信息(便于跟踪和参考)

    6) 本测试用例与其他测试用例间的依赖关系

    7) 本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限

    8) 用例的编号(ID),如可以是 软件名称简写-功能块简写-NO.。

    9) 步骤号、操作步骤描述、测试数据描述

    10)预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)

    11)开发人员(必须有)和测试人员(可有可无)

    12)测试执行日期

    5. 给出一个测试用例的例子该范例已经包含一个测试用例的模板。

    项目/软件 技术出口合同网络申领系统 (企业端) 程序版本 1.0.25
    功能模块名 Login 编制人   xxx
    用例编号- TC-TEP_Login_1 编制时间   2002.10.12
    相关的用例
    功能特性 用户身份验证
    测试目的 验证是否输入合法的信息,允许合法登陆,阻止非法登陆
    预置条件 特殊规程说明 如数据库访问权限
    参考信息 需求说明中关于“登陆”的说明
    测试数据 用户名=yiyh 密码=1
    操作步骤 操作描述 数 据 期望结果 实际结果 实际结果

    测试状态

    1 输入用户名称,按“登陆”按钮。 用户名=yiyh,密码为空 显示警告信息“请输入用户名和密码!”
    2 输入密码,按“登陆”按钮。 用户名为空,密码=1 显示警告信息“请输入用户名和密码!”
    3
    输入用户名和密码,按“登陆”按钮。
    用户名=yiyh,密码=2
    显示警告信息“请输入用户名和密码!”

    4
    输入用户名和密码,按“登陆”按钮。
    用户名=xxx,密码=1
    显示警告信息“请输入用户名和密码!”
    5
    输入用户名和密码,按“登陆”按钮。
    用户名=xxx,密码=2
    显示警告信息“请输入用户名和密码!”
    6
    输入用户名和密码,按“登陆”按钮。
    用户名=空,密码=空
    显示警告信息“请输入用户名和密码!”
    7
    输入用户名和密码,按“登陆”按钮。
    用户名=yiyh,密码=1
    进入系统页面。
    8
    输入用户名和密码,按“登陆”按钮。
    用户名=Admin,密码=admin
    进入系统维护页面。
    9
    输入用户名和密码,按“登陆”按钮。
    用户名=yiyh',密码=1
    显示警告信息“请输入用户名和密码!”
    10 输入用户名和密码,按“登陆”按钮。
    用户名=yiyh,密码=1'
    显示警告信息“请输入用户名和密码!”
    11 输入用户名和密码,按“重置”按钮。 用户名=yiyh,密码=1 清空输入信息
    测试人员 开发人员 项目负责人


    备注:本用例未考虑“企业代码”的输入情况;测试用例并未涵盖所有的非法输入,如非法输入中可能会有

    “user=*,pw=*”的组合,对回车的默认操作,空格输入,对输入上溢的处理的处理(可能会跳过身份验证) 等等。

    如果你有兴趣,至少可以再补充5-10条左右的输入组合

    (当然,如果步骤超过15步,用例的易操作 性就降低,你可以再创建一个测试用例如TC-TEP_Login_2)。

  • Bug管理的一般流程

    2007-03-15 14:53:09

    Bug管理的一般流程

    文章出处:本地化测试网 作者:崔启亮 发布时间:2006-03-08

     

         软件测试的主要目的在于发现软件存在的错误(Bug),对于如何处理测试中发现的错误,

     

    将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误,才能消除软件错误,保证

     

    要发布的软件符合需求设计的目标。在实际软件测试过程中,对于每个Bug都要经过测试、确

     

    认、修复、验证等的管理过程,这是软件测试的重要环节。

     

    错误跟踪管理系统

     

        为了正确跟踪每个软件错误的处理过程,通常将软件测试发现的每个错误作为一条条记录

     

    输入制定的错误跟踪管理系统。

     

        目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件(商业软件)、

     

    Mozilla公司的Buzilla软件(免费软件),以及国内的微创公司的BMS软件,这些软件在功能

     

    上各有特点,可以根据实际情况选用。当然,也可以自己开发缺陷跟踪软件,例如基于Notes

     

    或是ClearQuese开发缺陷跟踪管理软件。

     

        作为一个缺陷跟踪管理系统,需要正确设计每个错误的包含信息的字段内容和记录错误的

     

    处理信息的全部内容。字段内容可能包括测试软件名称,测试版本号,测试人名称,测试事

     

    件,测试软件和硬件配置环境,发现软件错误的类型,错误的严重等级,详细步骤,必要的附

     

    图,测试注释。处理信息包括处理者姓名,处理时间,处理步骤,错误记录的当前状态。

     

    正确的数据库权限管理是错误跟踪管理系统的重要考虑要素,一般要保证对于添加的错误

     

    不能从数据库中删除。

     

    软件错误的状态

     

    新信息(New):测试中新报告的软件缺陷;

     

    打开 (Open):被确认并分配给相关开发人员处理;

     

    修正(Fixed):开发人员已完成修正,等待测试人员验证;

     

    拒绝(Declined):拒绝修改缺陷;

     

    延期(Deferred): 不在当前版本修复的错误,下一版修复

     

    关闭(Closed):错误已被修复;

     

    Bug管理的一般流程

     

        测试人员提交新的Bug入库,错误状态为New

     

        高级测试人员验证错误,如果确认是错误,分配给相应的开发人员,设置状态为Open。如果不是错误,则拒绝,设置为Declined状态。

     

        开发人员查询状态为OpenBug,如果不是错误,则置状态为Declined;如果是Bug则修复并置状态为Fixed。不能解决的Bug,要留下文字说明及保持BugOpen状态。

     

        对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过某种会议(评审会)通过才能认可。

     

        测试人员查询状态为FixedBug,然后验证Bug是否已解决,如解决置Bug的状态为

     

    Closed,如没有解决置状态为Reopen

     

    软件错误流程管理要点

     

        为了保证错误的正确性,需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误,书写的测试步骤是否准确,可以重复。

     

        每次对错误的处理都要保留处理信息,包括处理姓名,时间,处理方法,处理意见,Bug状态。

     

        拒绝或延期错误不能由程序员单方面决定,应该由项目经理,测试经理和设计经理共同决定。

     

        错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭错误。

     

        加强测试人员与程序员的交流,对于某些不能重复的错误,可以请测试人员补充详细的测试步骤和方法以及必要的测试用例。 

  • Bugzilla使用指南

    2007-03-15 14:43:54

    Bugzilla使用指南

     

    文章出处:不详 作者:不详 发布时间:2005-10-30

     

     


     绪言

    什么是Bugzilla

    Bugzilla是一个错误跟踪系统,用于对软件产品程序开发过程的错误跟踪。它的强大功能表现在以下几个方面:

    1.         强大的检索功能

    2.         用户可配置的通过Email公布Bug变更

    3.         历史变更记录

    4.         通过跟踪和描述处理Bug

    5.         附件管理

    6.         完备的产品分类方案和细致的安全策略

    7.         安全的审核机制

    8.         强大的后端数据库支持

    9.         WebXmlEmail和控制界面

    10.     友好的网络用户界面

    11.     丰富多样的配置设定

    12.     版本间向下兼容

    为什么使用Bugzilla

    Bugzilla是一个拥有强大功能的错误跟踪系统。它可以使我们更好的在软件开发过程中跟踪软件错误的处理过程,为开发和测试工作以及产品质量的度量提供数据支持,从而有效的保证软件产品的质量。

     

    Bugzilla使用指南

    新建一个Bugzilla账号

    1.       点击“Open a new Bugzilla account”链接,输入你的Email地址(如:XXX@office)然后点击“Create Account”。

    2.       稍候,你会收到一封邮件。邮件中包含你的登录账号(与你的Email相同)和口令,这个口令时Bugzilla系统随机生成的,你可以根据你的需要进行变更。

    3.         在页面的黄色页角中点击“Log In”链接,而后输入你的账号和口令。最后点击“Login

    产品和结构(Product and Component)

    Bug记录按产品分类,每种产品按功能拆分成几类。以Bugzilla产品为例,它由以下几部分构成:

    l          Administration

    l          Bugzilla-General

    l          Creating/Changing Bug

    l          Documentation

    l          Email

    l          Installation

    l          Query/Buglist

    l          Reporting/Charting

    l          User Accounts

    l          Changing Passwords

    l          User Interface

    Bug报告状态分类和Bug处理意见(Status and Resolution):

    1.       Bug报告状态分类(Status)

    l          待确认的(Unconfirmed)

    l          新提交的(New)

    l          已分配的(Assigned)

    l          问题未解决的(Reopened)

    l          待返测的(Resolved)

    l          待归档的(Verified)

    l          已归档的(Closed)

    2.       Bug处理意见(Resolution)

    l          已修改的(Fixed)

    l          不是问题(Nvalid)

    l          无法修改(Wontfix)

    l          以后版本解决(Later)

    l          保留(Remind)

    l          重复(Duplicate)

    l          无法重现(Worksforme)

    指定处理人(Assigned To)

    l          可以指定一个处理人

    l          如不指定处理人,则系统指定管理员为默认处理人

    超链接(URL)

    l          输入超链接地址,引导处理人找到与报告相关联的信息

    概述(Summary)

    l          概述部分“Summary”的描述,应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。

    l          如果是通用组件部分的测试,则必须将这一通用组件对应的功能名称写入概述中,以便今后查询。

    硬件平台和操作系统(Platform and OS)(0perating System)

    l          测试应用的硬件平台(Platform),通常选择“PC”

    l          测试应用的操作系统平台(OS)

    版本(Version)

    l          产生Bug的软件版本

    Bug报告优先级(Priority)

    l          分五个等级即P1-P5,P1的优先级别最高之后逐级递减

    Bug状态(Severity)

    l          Blocker,阻碍开发和/或测试工作

    l          Critical,死机,丢失数据,内存溢出

    l          Major,较大的功能缺陷

    l          Normal,普通的功能缺陷

    l          Minor,较轻的功能缺陷

    l          Trivial,产品外观上的问题或一些不影响使用的小毛病,如菜单或对话框中的文字拼写或字体问题等等

    l          Enhancement,建议或意见

    报告人(Reporter)

    l          Bug报告提交者的账号

    邮件抄送列表(CC List)

    l          Bug报告抄送对象,该项可以不填

    l          如需要抄送多人,可将邮件地址用“,”分隔

    从属关系(Bug “ID” 查看(410) 评论(0) 收藏 分享 管理

  • 软件错误跟踪处理流程

    2007-03-15 12:36:36

     
      UML软件工程组织

    软件错误跟踪处理流程

     

    作者:不详  来源:网络

     

    大型本地化软件测试需要进行充分的测试准备,需要科学的测试流程管理。为了跟踪和控制测试质量,便于管理测试发现的Bug,需要为每一个测试项目配置一个专用缺陷跟踪数据库,以便报告、查询、分类、跟踪、处理和验证错误。

    为了保证发现和报告的错误质量,需要首先由经验丰富的测试人员,在缺陷跟踪数据库中对新发现的错误进行确认,如果确实属于错误,再由错误修复工程师进行修复处理。

    1、软件错误的状态

    新错误(New):测试中新报告的软件缺陷。 更多新信息(New More Info):错误修复工程师认为报告的错误信息不完整,要求错误报告者添加更准确的错误信息。 打开 (Open):错误被确认并分配给相关错误修复工程师处理。 拒绝(Declined):拒绝修改缺陷。包括两种情况: 拒绝-不是错误(Declined-Not Bug):报告的错误不术语错误。 拒绝-重复(Declined-Duplicated):以前已经报告过这个错误,需要指出已经报告过的错误标识编号。 修正(Fixed):错误修复工程师已完成修正,等待测试人员验证。 重新打开(Reopen):没有正确修复的错误,需要进一步修复。 延期(Deferred):不在当前版本修复的错误,以后的版本修复。包括两种情况: 延期-下个版本(Deferred –Next Build):本项目的下一个新版本修复。 延期-下个主要版本(Deferred –Next Main Release):本项目不修复,本软件下一个项目的版本修复。 关闭(Closed):错误已被修复。  

     2、Bug管理的一般流程

    测试人员提交新的错误入库,错误状态为New。

    高级测试人员验证错误,如果是重复报告的错误,则设置为Declined-Duplicated状态,并指出与哪个已经报个错误重复(注明标识编号ID#)。否则,如果确认是错误,分配给相应的修复工程师,设置状态为Open。如果不是错误,则拒绝,设置为Declined-Not Bug状态。

    错误修复工程师查询状态为Open的错误,如果因为错误的信息不完全,没法重现错误,则设置状态为New More Info;如果不是错误,则设置状态为Declined-Not Bug;如果是错误则修复,设置状态为Fixed。对于当前版本不能解决,准备本项目的下一个新版本处理的错误,要留下处理注释,设置错误为Deferred –Next Build状态。如果只能在软件的下个新项目才能解决,要留下处理注释,设置错误为Deferred –Next Main Release状态。

    对于不能解决和延期解决的错误,不能由软件修复工程师自己决定,一般要通过某种会议(评审会)通过才能认可。

    测试人员查询状态为Fixed的错误,然后验证错误是否已修复,如果已经修复,设置错误的状态为Closed,如没有解决置状态为Reopen。

    下面以一个错误的处理过程为例,给出一般的处理流程图。



     3、软件错误流程管理要点

    为了保证错误的正确性,需要有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误,测试步骤是否准确、简洁、可以重复。 软件错误的确认并不总是轻而易举的事情。由于对软件设计具体要求的不了解,对测试报告的个别软件错误,可能无法确认是否属于真正的软件错误,本地化服务商需要与软件供应商交流并确认。 每次对错误的处理都要保留处理信息,包括处理者姓名,时间,处理方法,处理步骤,错误状态,处理注释等。 对错误的拒绝不能由程序员单方面决定,应该由项目经理,测试经理和设计经理共同决定。 对错误延期处理不能由本地户服务商决定,应该由软件供应商决定。 错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭错误。

     


    版权所有:UML软件工程组织

     UML
    软件工程组织

    软件错误跟踪处理流程

     

    作者:不详  来源:网络

     

    大型本地化软件测试需要进行充分的测试准备,需要科学的测试流程管理。为了跟踪和控制测试质量,便于管理测试发现的Bug,需要为每一个测试项目配置一个专用缺陷跟踪数据库,以便报告、查询、分类、跟踪、处理和验证错误。

    为了保证发现和报告的错误质量,需要首先由经验丰富的测试人员,在缺陷跟踪数据库中对新发现的错误进行确认,如果确实属于错误,再由错误修复工程师进行修复处理。

    1、软件错误的状态

    新错误(New):测试中新报告的软件缺陷。 更多新信息(New More Info):错误修复工程师认为报告的错误信息不完整,要求错误报告者添加更准确的错误信息。 打开 (Open):错误被确认并分配给相关错误修复工程师处理。 拒绝(Declined):拒绝修改缺陷。包括两种情况: 拒绝-不是错误(Declined-Not Bug):报告的错误不术语错误。 拒绝-重复(Declined-Duplicated):以前已经报告过这个错误,需要指出已经报告过的错误标识编号。 修正(Fixed):错误修复工程师已完成修正,等待测试人员验证。 重新打开(Reopen):没有正确修复的错误,需要进一步修复。 延期(Deferred):不在当前版本修复的错误,以后的版本修复。包括两种情况: 延期-下个版本(Deferred –Next Build):本项目的下一个新版本修复。 延期-下个主要版本(Deferred –Next Main Release):本项目不修复,本软件下一个项目的版本修复。 关闭(Closed):错误已被修复。  

     2、Bug管理的一般流程

    测试人员提交新的错误入库,错误状态为New。

    高级测试人员验证错误,如果是重复报告的错误,则设置为Declined-Duplicated状态,并指出与哪个已经报个错误重复(注明标识编号ID#)。否则,如果确认是错误,分配给相应的修复工程师,设置状态为Open。如果不是错误,则拒绝,设置为Declined-Not Bug状态。

    错误修复工程师查询状态为Open的错误,如果因为错误的信息不完全,没法重现错误,则设置状态为New More Info;如果不是错误,则设置状态为Declined-Not Bug;如果是错误则修复,设置状态为Fixed。对于当前版本不能解决,准备本项目的下一个新版本处理的错误,要留下处理注释,设置错误为Deferred –Next Build状态。如果只能在软件的下个新项目才能解决,要留下处理注释,设置错误为Deferred –Next Main Release状态。

    对于不能解决和延期解决的错误,不能由软件修复工程师自己决定,一般要通过某种会议(评审会)通过才能认可。

    测试人员查询状态为Fixed的错误,然后验证错误是否已修复,如果已经修复,设置错误的状态为Closed,如没有解决置状态为Reopen。

    下面以一个错误的处理过程为例,给出一般的处理流程图。



     3、软件错误流程管理要点

    为了保证错误的正确性,需要有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误,测试步骤是否准确、简洁、可以重复。 软件错误的确认并不总是轻而易举的事情。由于对软件设计具体要求的不了解,对测试报告的个别软件错误,可能无法确认是否属于真正的软件错误,本地化服务商需要与软件供应商交流并确认。 每次对错误的处理都要保留处理信息,包括处理者姓名,时间,处理方法,处理步骤,错误状态,处理注释等。 对错误的拒绝不能由程序员单方面决定,应该由项目经理,测试经理和设计经理共同决定。 对错误延期处理不能由本地户服务商决定,应该由软件供应商决定。 错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭错误。

     


    版权所有:UML软件工程组织