51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3277|回复: 1
打印 上一主题 下一主题

测试经验(转贴)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2005-12-2 19:16:52 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
测试经验总结

一、软件缺陷的原则:
1.软件未达到产品说明书标明的功能。
2.软件出现了产品说明书指明不会出现的错误。
3.软件功能超出产品说明书指明范围。
4.软件未达到产品说明书虽未指出但应达到的目标。
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。

二、文档测试
(一)产品说明书属性检查清单
1.完整.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?
2.准确.既定解决方案正确吗?目标明确吗?有没有错误?
3.精确,不含糊,清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗?
4.一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突?
5.贴切.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?
6.合理.在特定的预算和进度下,以现有人力,物力和资源能否实现?
7.代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码?
8.可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息?

(二)产品说明书用语检查清单
对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.
1.总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
2.当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.
3.某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.
4.等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
5.良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
6.已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.
7.如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.

三、功能测试
(一)边界条件
边界条件是指软件计划的操作界限所在的边缘条件.
如果软件测试问题包含确定的边界,那么数据类型可能是:
数值 速度 字符 地址 位置 尺寸 数量

同时,考虑这些类型的下述特征:
第一个/最后一个 最小值/最大值
开始/完成 超过/在内
空/满 最短/最长
最慢/最快 最早/最迟
最大/最小 最高/最低
相邻/最远

越界测试通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:
第一个减1/最后一个加1
开始减1/完成加1
空了再减/满了再加
慢上加慢/快上加快
最大数加1/最小数减1
最小值减1/最大值加1
刚好超过/刚好在内
短了再短/长了再长
早了更早/晚了更晚
最高加1/最低减1


另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.


(二)状态测试
建立状态转换图:
1.软件可能进入的每一种独立状态;
2.从一种状态转入另一种状态所需的输入和条件;
3.进入或退出某种状态时的设置条件及输入结果.

测试方法如下:
1.每种状态至少访问一次;
2.测试看起来最常见最普遍的状态转换;
3.测试状态之间最不常用的分支
4.测试所有错误状态及其返回值
5.测试随机状态转换

(三)竞争条件典型情形:
1.两个不同的程序同时保存或打开同一个文档
2.共享同一台打印机,通信端口或者其他外围设备
3.当软件处于读取或者修改状态时按键或者单击鼠标
4.同时关闭或者启动软件的多个实例
5.同时使用不同的程序访问一个共同数据库

一、软件缺陷的原则:
1.软件未达到产品说明书标明的功能。
2.软件出现了产品说明书指明不会出现的错误。
3.软件功能超出产品说明书指明范围。
4.软件未达到产品说明书虽未指出但应达到的目标。
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。

二、文档测试
(一)产品说明书属性检查清单
1.完整.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?
2.准确.既定解决方案正确吗?目标明确吗?有没有错误?
3.精确,不含糊,清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗?
4.一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突?
5.贴切.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?
6.合理.在特定的预算和进度下,以现有人力,物力和资源能否实现?
7.代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码?
8.可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息?

(二)产品说明书用语检查清单
对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.
1.总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
2.当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.
3.某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.
4.等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
5.良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
6.已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.
7.如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.

三、功能测试
(一)边界条件
边界条件是指软件计划的操作界限所在的边缘条件.
如果软件测试问题包含确定的边界,那么数据类型可能是:
数值 速度 字符 地址 位置 尺寸 数量

同时,考虑这些类型的下述特征:
第一个/最后一个 最小值/最大值
开始/完成 超过/在内
空/满 最短/最长
最慢/最快 最早/最迟
最大/最小 最高/最低
相邻/最远

越界测试通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:
第一个减1/最后一个加1
开始减1/完成加1
空了再减/满了再加
慢上加慢/快上加快
最大数加1/最小数减1
最小值减1/最大值加1
刚好超过/刚好在内
短了再短/长了再长
早了更早/晚了更晚
最高加1/最低减1


另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.


(二)状态测试
建立状态转换图:
1.软件可能进入的每一种独立状态;
2.从一种状态转入另一种状态所需的输入和条件;
3.进入或退出某种状态时的设置条件及输入结果.

测试方法如下:
1.每种状态至少访问一次;
2.测试看起来最常见最普遍的状态转换;
3.测试状态之间最不常用的分支
4.测试所有错误状态及其返回值
5.测试随机状态转换

(三)竞争条件典型情形:
1.两个不同的程序同时保存或打开同一个文档
2.共享同一台打印机,通信端口或者其他外围设备
3.当软件处于读取或者修改状态时按键或者单击鼠标
4.同时关闭或者启动软件的多个实例
5.同时使用不同的程序访问一个共同数据库
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1
回复

使用道具 举报

该用户从未签到

2#
发表于 2006-1-25 14:44:33 | 只看该作者
:p:p:p谢谢版主,讲的很详细,让我学到不好东西。:

[ 本帖最后由 雪儿185 于 2006-1-25 14:47 编辑 ]
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-24 06:59 , Processed in 0.067351 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表