日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
搜索标题
最新来客
最新留言
我的收藏
统计信息
- 访问量: 915
- 日志数: 14
- 书签数: 6
- 建立时间: 2008-03-17
- 更新时间: 2008-10-10
RSS订阅
我的最新日志
-
测试要发现程序深层次的bug
2008-10-07
是否会内存泄露、死锁，是否有不良的sql、是否满足性能需求和安全需求以及扩展性需求和容灾需求 -
搜索引擎测试点
2008-9-03
包括关键字搜索.完全匹配.有效字符.无效字符等
1,空内容点击搜索，看其有没有LINK
2,输入过长查询数据，看其有没判断，报错
3,输入各种符号，特别是空格，看其能否正确判断
4,输入各种字符，譬如输入范围是0~9，A~Z的看输入中文是什么效果
5,输入正确数据，看其的查询后数据的完整性
6,注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方
7,在输入结束后直接按回车键,看系统处理如何,会否报错
8,反复输入相同的数据（5次以上）看是否报错
9,各国文字/字符的输入/粘贴能正确显示 退格键等操作显示正常 超过支持的最大长度有相应的提示 混合的多种语言也能正确显示
10,显示&接收；能进行下一步处理
11,其他的 包括能删除 能剪切等（我也不确定要不要包括 有点奇怪 显示语言是字符库支持的问题 而且如果是面向对象程序设计语言做的文本框 删除什么的功能也不用测了吧sdlkfj1 ）
12, 另外注意分析搜索结果.如:搜索结果的正确性,排序等.. -
搜索引擎测试技术问题
2008-9-03
基于如上复杂的系统架构，尤其是4)模式，我们在测试当中也碰到相当多棘手的技术问题
1) 海量数据是否都按预期的分词算法建立索引了呢？
2) 机器分词的效果与手工分词相差有多大呢?
3) 海量查询的返回结果是否多查了
4) 海量查询的返回结果是否漏查了
5) 海量查询的返回结果的加亮、标注如期加了？
6) 海量查询的返回结果中相关性分数计算是否正确?
7) 海量查询的返回结果积分计算是否正确了呢
8) 海量查询的返回结果积分相同时，排序的先后依据唯一么？
9) 加入即时更新模块后，每次查询结果都不同，新建的索引内容是否都反馈到查询结果里面了呢 ？
10) 海量数据时CACHE是否预期CACHE该cache的内容？
11) 海量数据时CACHE是否依照一定的过时算法令cache的内容失效呢？
12) 应用程序在32位LINUX 操作系统和64位的LINUX的索引、查询结果是否依然一样？
13) 应用程序在不同的OS 上索引、查询结果是否依然一样？
-
搜索引擎测试
2008-9-03
任何软件测试无外呼上面的两个主要步骤。一定要了解被测试对象的需求，否则，测试无从谈起。
1、找你们的开发人员，索要相关的技术文档，比如需求规格。如果没有此类文档，建议开发人员对测试人员做一个有针对性的培训，培训的内容集中在搜索引擎的设计思路上面。
2、通过与开发人员的交流，测试人员整理出相应的需求项，然后，根据需求项有针对性的设计测试用例。
1.搜索的全面性；
2.搜索结果的准确性；
3.搜索的响应时间；
4.搜索结果的显示方式；
5.搜索结果中可以使用的有效连接比例，也就是有时候可能搜索出来的连接在实际使用的时候连接不到；
6.搜索内容的日期排名方面；
-
上传文件测试点
2008-8-25
上传文件测试点
1 上传文件名测试，检查不符合文件名规范
2 上传文件名类型测试，检查不同文件类型是否支持如：.rar,.mp3,avi等
3 上传文件大小测试，检查不同文件规格大小如：0字节文件, 1kb, 200kb, 2mb, 20mb,2g等
4 上传文件容错性测试：如检查覆盖同文件操作；
5 上传文件异常情况测试：如硬盘空间不足
6 上传文件速率性能测试：检查上传不同的文件在不同的网络环境响应速度，及系统资源占用
7 上传文件安全性测试：如上传常见木马
8 上传文件易用性测试：检查上传文件操作是否让用户易于学习和理解使用等
9 上传文件特性测试：如果支持如断点续传等一些特性
10 上传文件后，检查是否与源文件一致，包含目录设置等
11 上传文件，是否能打开等 -
用例编写步骤
2008-7-27
1。接到任务不急于作而在于多思考，首先在纸上构造好业务流图
2。业务流程图构造好，快速挑选出公用的测试用例
3。构造测试用例，先写符合主路径的三种“PASS”、“ERROR”、“FAIL”
4。精化测试用例，努力为ERROR多构造1-7种假设
5。执行测试用例，增加FAIL的标准化失败的测试，但是对应减少PASS测试用例
6。进一步精化测试用例，使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10 -
设计功能和界面测试用例
2008-7-26
设计功能和界面测试用例
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,选择"帮助"->"关于"命令,应 看见相关版权和产品信息 -
用例等级划分
2008-7-26
高（Highs）：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。
中（Mediums）：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例
低（Lows）：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性，压力和性能测试。 -
需求分析—规划与设计—执行—调优—验证
2008-6-19
确定问题：首先根据测试结果确定系统是否存在问题，重点是发现系统的瓶颈。如果存在，就应该确定是什么问题，并对问题进行正确的定位。确定系统问题可从下面几个方面入手：
检查应用程序代码；调整数据库配置；调整操作系统配置；检查硬件设置
检查网络：网络负载过重会导致网络冲突和网络延迟。
同时，还要对系统的使用情况进行调查，例如：
l 是否听到了很多用户的抱怨？
l 某些操作的响应时间是否随着使用时间的增长而增长？
l CPU的使用率是否很低而I/O的使用率却很高？
l 使用过程中性能是否稳定？
确定原因
确定系统存在问题后就要仔细进行分析，进而确定引起问题的原因。确定原因很大程度上靠的是团队的经验和技术能力，涉及的知识有操作系统、数据库、网络、程序开发等许多方面。
和确定性能问题一样，确定原因仍然要广泛地搜集信息。通常要进行以下的分析：
l 问题的影响是什么：响应速度还是吞吐量，或者其他问题？
l 是大多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其他用户的操作有什么不同？
l 系统资源监控的结果是否正常，如CPU的使用是否到了极限？I/O情况如何？
l 问题是否集中在某一类模块中？
l 是客户端还是服务器出现问题？
l 系统硬件配置是否合理？
l 实际负载是否超过了系统的负载能力？
l 是否未对系统进行优化？
确定调整目标和解决方案
在分析出问题发生的原因后，测试人员和系统调整人员首先要确定调整目标，然后设计解决方案。确定调整目标的主要作用是明确何时停止系统调整，否则工作将永无尽头。
每个系统都有不同的特点，因此调整目标可能各有不同。例如，下面这些都是系统的调整目标：
l 提高系统吞吐量；
l 缩短响应时间；
l 更好地支持并发；
测试解决方案
实施解决方案后，就要对方案进行测试。可以使用以前的测试用例来进行测试，验证系统是否解决了性能问题。测试解决方案尽量要在仿真环境下进行，因为在生产环境下可能会带来破坏，除非充分估计了测试的风险，并且准备了万全的补救方案。
分析调整结果
性能调整的最后一步是分析调整结果，如果问题没有得到解决，则要重复前面的工作。在测试系统调整方案过程中，要经常分析所做的工作。如果没能准确定位问题或调整方案不正确，可能会达不到预期目标。要尽早发现这些错误，以使工作早些回到正确的轨道上来。
分析结果时主要考虑下面的问题：
l 系统调整是否达到或超出了预定目标？
l 系统是整体性能得到了改善，还是牺牲了某部分性能来解决问题的？
l 调整是否可以结束了？
-
学习笔记2—基础篇
2008-6-19
性能测试工作中首先要做好性能测试的规划与设计工作，然后再借助LoadRunner的强大功能来发现系统存在的问题
“全面性能测试模型”包含了性能测试策略制定、测试用例设计、模型使用方法三部分内容，覆盖了性能测试规划和设计的相关内容，为开展性能测试工作提供了一种可行的方案。
操作系统、数据库、中间件服务器等的参数配置是应用系统发生性能问题的重要原因。
通过分析性能测试的种种目标，不难总结出性能测试主要应用在几个领域中:
1.系统的性能瓶颈定位2.系统的参数配置3.发现一些软件算法方面的缺陷4.系统的验收测试
“全面性能测试模型”是在以上性能测试分类和总结的基础上提出来的，主要包含3部分内容：第1部分：性能测试策略模型（结合软件类型和用户特点来讨论性能测试策略制定的基本原则和方法。）第2部分：性能测试用例模型（预期指标的性能测试； 并发用户的性能测试； 疲劳强度和大数据量的性能测试；服务器性能测试； 网络性能测试。）第3部分：模型的使用方法