日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 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 | |||||||||
搜索标题
最新评论
统计信息
- 访问量: 1697
- 日志数: 11
- 文件数: 2
- 建立时间: 2007-10-25
- 更新时间: 2007-12-04
RSS订阅
我的最新日志
-
面试英文系列
2007-12-04
工作能力英汉对照 http://www.ywhc.net/article/info_Show.asp?ArticleID=2356
面试篇—开场白 http://www.ywhc.net/article/info_Show.asp?ArticleID=2328
面试篇—个人信息 http://www.ywhc.net/article/info_Show.asp?ArticleID=2329
面试篇—性格和爱好 http://www.ywhc.net/article/info_Show.asp?ArticleID=2330
面试篇—教育背景 http://www.ywhc.net/article/info_Show.asp?ArticleID=2331
面试篇—个人技能 http://www.ywhc.net/article/info_Show.asp?ArticleID=2332
面试篇—离职和应聘原因 http://www.ywhc.net/article/info_Show.asp?ArticleID=2333
面试篇—工作经验 http://www.ywhc.net/article/info_Show.asp?ArticleID=2334
面试篇—工作目标 http://www.ywhc.net/article/info_Show.asp?ArticleID=2335
面试篇—薪金期望 http://www.ywhc.net/article/info_Show.asp?ArticleID=2336
面试篇—面试结束 http://www.ywhc.net/article/info_Show.asp?ArticleID=2337
面试篇—表示谢意 http://www.ywhc.net/article/info_Show.asp?ArticleID=2338
面试篇—询问结果 http://www.ywhc.net/article/info_Show.asp?ArticleID=2339
面试篇—谢绝职务 http://www.ywhc.net/article/info_Show.asp?ArticleID=2340 -
LoadRunner8.0安装方法
2007-11-29
经过了尝试还有得到同事提供的信息，我终于在经过多次失败后，将LoadRunner8.0成功安装到WinXp下了。
安装过程中碰到的问题为：
1.将安装的程序拷贝到本机或者映射为网络驱动器安装（有多层目录时），安装时会一直提示某个文件找不到。安装后的程序没法用。
2.将安装不成功的LoadRunner8卸载，再次安装时，就会提示序列号非法。
问题解决要点：
必须将LoadRunner8.0安装程序映射到根目录，如果是在某个子目录下，是不行的。
可以采用以下三种方法：
1.如果服务器上安装程序(setup.exe)已经在某个共享根目录下，这直接将这个共享根目录映射为网络驱动器，如Z盘，然后运行Z盘根目录下的setup.exe即可。
2.如果服务器上安装程序所在目录不是共享根目录，则可以将整个安装包拷贝到本地，然后将这个安装包所在目录共享；从网络上访问本机，如\\127.0.0.1，将刚才共享的那个目录映射为网络驱动器，最后执行setup.exe即可。
3.可以将安装程序刻成光盘，这是比较方便的方式了。如果原来已经安装过，那么就只能重装操作系统，必须是全新重装，而不是修复或升级。这个我已经有惨痛教训的了。目前我还不知道有没有其它更好的办法。 -
测试常用的经典书籍
2007-11-22
-
软件测试常用软件集合
2007-11-21
工具名称 功能范围
WinRunner-----功能：1.插入检查点；2.检验数据；3.增强测试；4.分析结果；5.维护测试；、６.为无线应用作准备。
范围：功能测试、生成测试用例、分析测试结果、维护测试用例、回归测试。
LoadRunner-----功能：1.松创建虚拟用户； 2.创建真实的负载； 3.定位性能问题；4.分析结果以精确定位问题所在； 5.重复测试保证系统发布的高性能； 6.Enterprise Java Beans的测试； 7.支持无线应用协议； 8.支持Media Stream应用； 9.完整的企业应用环境的支持。
范围：性能测试、压力测试、模拟多用户、定位性能瓶颈。
TestDirector------功能：1．需求管理;2. 计划测试;3. 安排和执行测试;4. 缺陷管理;5. 图形化和报表输出;范围：
测试管理工具
Rational系列-------Rational Purify （测试时用，检查运行时内存错误）;
Rational Quantify（性能检测工具，查出系统瓶颈以便改进运行速度）;
Rational TestManager （测试管理）;
Robot （软件测试用，通过scrīpt自动模拟输入输出）;
LoadTest （负载测试）;
TestFactory （软件测试用）;
QACenter-----QACenter帮助所有的测试人员创建一个快速，可重用的测试过程。这些测试工具自动帮助管理测试过程，快速分析和调试程序，包括针对回归，强度，单元，并发，集成，移植，容量和负载,建立测试用例，自动执行测试和产生文档结果。
QACenter主要包括以下几个模块：
QARun：应用的功能测试工具。
QALoad：强负载下应用的性能测试工具。
QADirector：测试的组织设计和创建以及管理工具。
TrackRecord：集成的缺陷跟踪管理工具。
EcoTools：高层次的性能监测工具。
QARun----1.强大的测试脚本建立功能。2.可反复运行，进行回归测试。
3．支持更多的应用访问
QALoad------1.自动捕获实际执行过程，自动生成测试脚本。2.通过控制台（安装在Windows NT）控制各个Agent（安装在Windows和Unix），进行脚本分配。3.模拟实际操作，压力测试。
WebLoad-----Web压力测试工具
panorama，功能主要是用于白盒测试。它对分析源码和跟踪错误方面有一定独到的见解，并且采用图解的方法跟踪源码。白盒方面Compuware也非常不错 -
降低软件测试后遗漏Bug的风险
2007-11-21
尽管软件经过了测试员的测试，但是软件发布后，用户仍然会发现一些Bug，软件公司收到客户的质量抱怨，很多人士都将这一切错误怪罪到测试人员的工作疏忽，尽管这有一定的道理，但是，光让测试员自己“背黑锅”其实是有失公正的。
分析这些遗漏的Bug的特征，检查软件测试、开发、项目管理流程，可以在今后的软件项目中积累经验。
为什么软件测试后会遗漏Bug？主要来自以下四种情形：
（1）软件测试用例设计不完整，测试覆盖率不高。客户偶然执行了软件的某些操作，而这些操作没有被测试员测试到。
（2）测试员过分依赖程测试说明书，机械地执行测试。由于测试人员可能是新手，他们完全按照测试说明书执行测试，忽略了使用程序中输入变量的边界值进行测试，而用户正好使用了边界值进行操作。
（3）测试环境和用户的使用环境不一致。虽然在测试人员的测试环境中软件不会有错误，但是如果用户的使用环境与测试环境不一致，将会发现新的Bug。这在软件的离岸外包测试中经常出现。
（4）测试发现的软件Bug没有被正确处理。如果开发人员没有及时、正确地处理测试发现的Bug，忽略了一些Bug，而想当然地认为新的Build中这些Bug已经被修正了，就会带来Bug隐患。
针对以上遗漏Bug的特征，可以找出对应的防范措施，降低软件测试后遗漏Bug的风险。
（1）设计覆盖率高的测试用例。将客户最经常使用的功能写入测试用例，可以参照用户需求说明书创建测试用例。
（2）测试人员提高测试能力，既要测试输入变量的正常值，也要测试边界值和非正常值。采用等价类和边界值测试相结合的方法测试。
（3）保持测试环境和用户使用环境的一致性。用户需求说明书中通常包括软件的运行环境，测试环境应该保持一致，或者采用一些测试工具来模拟或仿真用户的使用环境。
（4）规范Bug的处理和跟踪流程。只有测试人员才有权关闭Bug跟踪数据库的Bug，开发人员只负责确认和修正Bug。在软件发布之前，确保满足发布条件，例如功能Bug全部被处理，其他Bug数量在发布条件允许范围内。
最后，由于软件测试是一种被动的软件质量保证活动，软件测试只能证明软件存在Bug，无法发现全部的Bug，而且由于测试时间、人员、成本的原因，软件测试的深度和广度都是有限的，软件测试后遗漏Bug属于预料之中。理解用户使用需求，加强测试用例设计，提高测试技术水平，优化Bug管理流程，将可以使软件测试后遗漏的Bug降低到最小程度。 -
测试提问单
2007-11-21
测试提问单
目录
一、 概述 2
1. 定义 2
2. 作用 2
3. 内容 2
二、 样例 2
1． 软件安装类测试提问单： 2
2． 菜单类测试提问单： 3
3． 页面元素类测试提问单： 3
3．1 美学方面测试提问单 3
3．2 确认正确性测试提问单 4
3．3 导航测试提问单 5
3．4 元素易用性测试提问单 5
3．5 数据完整性测试提问单 6
3．6 只读模式的测试提问单 6
3．7 通用性测试提问单 7
4． 特殊域测试提问单： 8
4．1 日期域测试提问单 8
4．2 数字域测试提问单 8
4．3 字符域的测试提问单 8
5． 报表类测试提问单 9
5．1 显示界面类测试提问单 9
5．2 操作界面类测试提问单 10
5．3 录入类测试提问单 11
5．4 出类测试提问单 11
6． 屏幕功能按钮类测试提问单 11
6．1 查询按钮的测试提问单 11
6．2 排序按钮的查询提问单 11
6．3 打印按钮的测试提问单 12
一、 概述
1. 概念
测试提问单是测试人员或者测试部门经过长期的测试实践和经验总结得出的辅助性测试资料，通过问答的形式来激发测试者对被测项目/软件的思考。
2. 作用
借助于测试提问单，不但可以对用户需求说明书的功能、性能测试提供帮助，而且便于对用户需求说明书之外的其他问题理解和测试。
有些书籍将测试提问单列入测试规程中，通过问答形式，测试者更加容易理解和测试被测项目/软件，有利于公司软件的产品化、标准化和规范化，有利于公司的企业文化建设，有利于公司测试员整体素质的提高。
3. 内容
测试提问单的内容非常广泛，涉及到功能、性能、界面元素、易用性、用户习惯和特殊域输入等，可以是对用户需求的补充或者是需求以外的延伸。因此，测试提问单一般没有标准的答案，主要根据测试经验、行业标准和使用习惯等！
二、 样例(不同行业、不同开发架构、不同需求的项目/软件会有所差别，只供参考)
1． 软件安装类测试提问单：
序号 提问内容
1 软件是否有安装程序？安装程序是否有服务器端和客户端之分？
2 软件安装对操作系统有没有要求？对显示设备、外设等有没有要求？
3 软件安装是否需要安装其他的辅助程序？能否独立运行？
4 软件安装是否包括数据库、中间件的安装？
5 软件安装支持哪些形式？安装盘安装？在线安装？
6 软件安装后是否需要重启？
7 软件安装是否支持自定义安装，能否改变安装路径？
8 软件安装是否有显示安装进度条？安装界面是否友好？
9 软件安装出错时的信息提示是否友好？
10 软件安装是否有最小化安装，典型安装和推荐安装等类型？分别适应怎样的用户？
11 软件安装后，在桌面和任务栏能否建立快捷键图标？
12 安装程序与安装手册是否一致？
13 安装程序与在线安装帮助是否一致？
14 在磁盘空间不足时，是否有提示？
15 是否可以在安装过程中中止安装？中止后是否删除已安装的程序？
16 是否可以不覆盖旧有的数据进行安装？
17 是否有卸载该软件的程序？
18 软件卸载后，是否还需要手工删除文件？
2． 菜单类测试提问单：
序号 提问内容
1 菜单支持何种形式：条形菜单、弹出式菜单、下拉菜单、T形菜单？
2 菜单功能是否正确执行？
3 菜单是否有快捷键？
4 菜单字体、大小和格式是否正确？
5 菜单功能是否随当前的窗口操作加亮或变灰？
6 菜单功能的名字是否具有自解释性？
7 菜单项是否有帮助？
8 右键快捷菜单是否采用与菜单相同的准则？
9 是否可以通过鼠标访问所有的菜单功能？
10 是否适当地列出所有的菜单功能？
11 是否根据系统功能进行合理分类，将选项进行分组？
12 菜单深度是否控制在3层以内？
13 菜单标题是否简明、有意义？
14 是否依使用频度排列？
15 是否依逻辑顺序排列？
16 是否依使用顺序排列？
17 是否根据菜单选项的含义进行分组？
18 各级菜单显示格式和操作方式是否一致？与操作习惯是否相符？3． 页面元素类测试提问单：
3．1 美学方面测试提问单
序号 提问内容
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 保证所有的会话框看上去或感觉上，具有一致性？
3． 2 确认正确性测试提问单
序号 提问内容
1 每个域中确认出现问题时，是否有恰当的提示信息？
2 是否要求用户对一个确认的错误域进行修改？
3 当域有多项检查规则时，是否可以进行覆盖测试？
4 在域中输入非法数据并确认后，是否有报错信息？
5 能否保持屏幕/窗口级的一致性（除非特殊要求外）？
6 对于数字域，检查负数能否输入？
7 对于数字域，检查最大值、最小值，以及中间值是否允许？
8 对于字符/字母域检查是否有一个特定的限制？
9 检查必输域是否必须？是否带有标记，如：*
10 必输域对应的数据能否为空值？
11 录入的查询条件不合法或无数据时，是否给出正确提示？
12 确认数据处理前，是否提示用户再次确认数据处理？
13 数据处理时，是否正确加锁？
14 数据处理过程中，若有其他用户再次数据处理，是否严格限制？
15 数据处理过程中是否将鼠标开关置为“沙漏”，结束后是否恢复为“箭头”？
16 长时间等待的过程中，是否有动态的标识进度？
17 每年12月份数据处理后，是否自动进行年数据处理？
18 是否给出数据处理成功与否的信息？若不成功， 是否给出失败原因？
3． 3 导航测试提问单
序号 提问内容
1 通过菜单能否进入应用页面？
2 通过工具条能否进入应用页面？
3 通过窗口的列表控制，能否进入应用页面？
4 通过父窗口能否进入子窗口的应用页面？
5 通过子窗口能否返回父窗口的应用页面？
6 通过浏览历史记录能否进入相应的应用页面？
7 当窗口激活时，窗口模式是否正确？
8 同时打开相同应用窗口的数量是否符合要求？是否重叠？
3． 4 元素易用性测试提问单
序号 提问内容
1 窗口中下拉表中的项目排序是否正确，一般以字母升序作为缺省情况？
2 日期输入的格式是否正确？
3 窗口中的按钮是否有适当的快捷键？
4 快捷键工作是否正常？
5 菜单中的选项是否定义了快捷键？
6 用TAB键在元素间移动的次序是否正确，一般缺省从左上到右下？
7 只读域是否不在TAB键能达到的序列中？
8 非激活域是否不在TAB键能达到的序列中？
9 用鼠标点出文本框，是否有帮助信息？
10 用鼠标点击只读域，能否进入？
11 当打开窗口时，光标/焦点是否位于第一个可输入域？
12 窗口中是否有缺省的按钮定义？
13 缺省按钮是否工作正常？
14 当错误信息确认时，焦点是否回到出错的域？
15 使用ALT+TAB组合键从一个应用到另一个应用切换时是否有冲突？
16 编辑框域Edit Box是否限制了字符的长度？
3． 5 数据完整性测试提问单
序号 提问内容
1 关闭正在编辑的窗口时，数据是否得到保存？是否有提示？
2 检查域的长度，是否没有字符被截掉？
3 检查数字域的最大值和最小值？
4 检查数字域是否正确接受负数？
5 一组单选按钮是否由一组值代表（在数据库中）？
6 数据库对数据的存储是否完整？有没有出现字符串被截，数值没有4舍5入等？
7 特定数据的格式是否正确？如日期型数据有没有“-”或“/”等分隔符；金额字段的数据有没有每三位数字自动添加“，”分隔符？
8 录入非法字符时，是否给出提示？
9 ID、编号或单据号重复时，是否给出提示？
10 数据列太长，能否调整列宽？
3． 6 只读模式的测试提问单
序号 提问内容
1 只读模式窗口和域的颜色是否正确？
2 只读模式是否合乎实际，有没有逻辑错误？
3 字段域和控制按钮是否以只读模式来表示非激活？
4 与正在操作无关的按钮是否处于只读模式？
5 从只读模式下的窗口/菜单/工具条能否进入下一级窗口？
6 从只读模式进入的窗口是否也是只读？是否有效？
7 只读模式能否进行确认或执行操作？
3． 7 通用性测试提问单
序号 提问内容
1 是否有“帮助”菜单？
2 每个菜单是否有适当的命令和选项？
3 通用按钮的命令和作用是否一致？
4 每个菜单命令是否都有热键？热键是否有冲突？
5 在下拉列表中，缺省值是否足够？有没有值因为过长而被截掉？
6 在下拉列表中，能否通过键盘上下左右键来选取？
7 ESC键是否有定义？能否在任何时候使用ESC键退出？
8 ENTER键是否有定义？作用是否跟点击“确定”效果一样？
9 字段域的标签或名字是否过于专业性，用户不易理解？
10 相同或相似的命令按钮大小、文本字体是否一致，协调？
11 每个命令按钮被点击时，是否都有明显的响应痕迹？如按钮下沉或背景色改变等？
12 每个命令按钮的命名是否与它的作用或意义相符？是否简短？
13 使用TAB键移动元素，顺序是否合理，是否易于操作？
14 显示项在屏幕上排列是否整齐？
15 各项提示信息是否字体一致？
16 显示项的注释是否明确无误？是否与项目匹配？
17 每一个打开的窗口标题是否正确？
18 当超出一屏时，是否有上下左右滚动条？
19 改变WINDOWS屏幕大小设置时，窗口是否会自动居中？
20 通过键盘移动光标时，是否会出现丢失焦点的情况？
21 通过键盘移动光标时，是否和排列的顺序一致？
22 焦点是否比较醒目？
23 显示的对齐方式是否满足以下原则:字符左对齐，数值右对齐，属性列居中？
24 光标跳到不可输入列时，显示是否为不可输入状态？复制、粘贴功能在此是否可用？
25 录入的数据超出范围是否响应？
26 窗口中的静态提示信息的意义表达是否准确(不致产生二义性)？
27 某些域是否提供初始值和默认值？是否合理？
28 在操作过程中，是否显示进度条？在等待过程中，指针是否为“沙漏”型？
4． 特殊域测试提问单：
4．1 日期域测试提问单
序号 提问内容
1 闰年日期是否正确，是否不产生错误和计算误差？
2 月份是否只能在1和12之间（包含本身）？
3 日期是否只能在1和31之间（包含本身）？
4 二月是否有28、29、30日？
5 日期的周期性计算是否正确？
6 是否有日历选择器？是否与手工输入有冲突？
4．2 数字域测试提问单
序号 提问内容
1 数字域的边界值是什么？
2 录入有效值是否提示正确并接受？
3 录入无效值是否提示错误并拒绝？
4 在数字前面带有空格的数字域是否正确接受？
5 在数字后面带有空格的数字域是否正确接受？
6 正、负值是否正确处理？
7 除零的情况是否不允许？
8 是否由于小数位或者四舍五入的问题，导致计算有误？
4．3 字符域的测试提问单
序号 提问内容
1 空格和特殊字符~#&()/是否允许？
2 有效的字符长度是否正确处理？
3 无效的字符长度是否提示错误？
4 有效的字符类型是否正确处理？
5 无效的字符类型是否提示错误？5． 报表类测试提问单：
5．1 显示界面类测试提问单
序号 提问内容
1 查询条件录入窗口(对话框)，是否以响应的方式打开？
2 查询条件录入窗口的标题是否正确？
3 查询条件录入窗口的位置和大小是否合理(居中)？
4 窗口中的控件布局是否合理，排列是否整齐？
5 查询条件录入窗口是否包含项目全选，项目不选，款台(部门、类别、商品)全选， 款台(部门、类别、商品)不选等命令按钮？
6 窗口是否允许改变大小，改变大小后窗口内控件布局是否依然合理？
7 窗口中的提示信息有无错别字，标点符号是否正确？
8 窗口中的静态提示信息的意义表达是否准确？
9 是否提供初始值和默认值？它们是否合理？
10 信息的对齐方式是否正确(居中)？
11 各类信息的显示方式是否正确？
12 各按钮和提示信息的字体是否合理？
13 当信息显示超过一屏时，是否有垂直和水平滚动条？
14 数据显示是否合理地排序？
15 可选择数据内容是否全面？
16 查询报表标题名称是否正确？字体适中？自动居中？
17 是否完整显示出了查询区间？
18 界面显示的列宽是否足够？
19 查询结果多于一页的，是否显示页号？上页按钮在当前页为第一页时，下页按钮在当前页为最后一页是否变灰？
20 改变WINDOWS屏幕大小设置时，窗口是否会自动居中？
21 屏幕上数据显示的对齐方式是否满足以下的原则:字符左对齐，数值右对齐？
22 功能按钮的排序是否满足以下规则:明细，查询，打印， 上页，下页，头部，尾部，退出？
5．2 操作界面类测试提问单
序号 提问内容
1 所有控件是否都有快捷键？是否可用全盘操作？输入框能否直接键盘定位输入？
2 TAB值顺序是否合理？
3 日期输入框”年/月/日”的上限和下限分别是什么？是否合理？
4 各SPIN输入框，上下滚动是否正常？
5 输入的内容非法能否马上识别？是否不接受？
6 输入字符串的长度限制是否正确？
7 鼠标在窗口其余部分的点击是否正常？
8 是否定义了回车键盘的默认功能？
9 通过键盘移动光标时，是否会出现丢失焦点的情况？
10 在执行其他功能后是否自动回置默认焦点？
11 是否定义了ESC的默认功能？能否在任何情况下按ESC键退出？
12 工作窗口是否按SHEET(一片一片)的方式打开？
13 单击快捷键按钮，是否出现相应功能？
14 处理过程中是否将鼠标形状置为“沙漏”，处理结束后是否置为“箭头”？
15 查询结果为空时，提示是否正确？
16 当超出一屏时，是否有上下左右移动？
17 长时间的等待过程中，是否有动态提示信息？
18 每个功能按钮下是否有确定功能 ？与按钮的提示是否一致？
19 当年结或月结后，查询当月的内容是否正常？
20 查询历史数据时，查询结果是否正常？
21 查询区间包括历史和当前时，查询结果是否正常？
22 查询去年的数据时能否恢复正确的历史环境？
23 查询的结果是否完整全面？
24 查询时是否对某些数据加锁？
25 大数据量的查询时，查询时间是否不超过30秒？
5.3 录入类测试提问单
序号 提问内容
1 录入的查询条件不合法或无数据时，是否给出正确提示？
2 是否支持组合查询、高级查询、模糊查询、精确查询？
5．4 输出类测试提问单
序号 提问内容
1 查询的结果是否正确？完整？易见？
2 查询的结果排列是否整齐有序，是否支持排序？结果是否有分组？
3 查询结果多于一页，打印时分页打印，是否提供拆页打印功能？
4 查询结果是否支持导出和压缩？支持Excel、PDF、CSV、XML？
5 输出的模板是否可以选择？是否支持自定义？
6． 常见功能测试提问单：
6．1 查询的测试提问单
序号 提问内容
1 查询的项目/条件，是否正确、全面？
2 查询的项目名称，是否符合用户习惯？
3 查询的项目排列顺序，是否与显示的排列顺序一致？
4 依次试一下，各个查询项目组成的独自比较项，查询结果是否正常？
5 对字符串内容的查询，是否正常？
6 对数字内容的查询，是否正常？
7 对代码信息是否提供正确的编码帮助，能否直接输入编码或名称，查询是否分别都正常？
8 对逻辑型的比较项目，输入是否正常？查询结果是否正常？
9 是否支持组合查询、高级查询、模糊查询、精确查询？
10 是否支持全文检索？
6．2 排序的查询提问单
序号 提问内容
1 排序项目是否正确、全面？
2 项目名称是否符合用户习惯？
3 项目的排列顺序是否与显示的排列顺序一致？
4 依次检查一下，各个排序项目组成的独自排序结果是否正确？
5 排序是否有特定要求？排序规则是否可定义？
6．3 打印的测试提问单
序号 提问内容
1 直接点击打印按钮，输出的结果是否正确？完整？有没有缺页的情况？
2 打印前，能否用右键进行设置？
3 设置时，各输入框是否可以选择全部选项？可否预览？
4 设置后，输出的结果是否正常？
5 对于超宽表格，能否提供拆页打印设置？
6 能否使用最后一次的设置进行打印？是否支持定时打印？
7 打印中，字体、纸张规格和边上的空白设置，输出的结果是否正确？
8 在WINDOWS还没有安装任何打印机的情况下，是否有提示？
9 打印时，能否自动输出到WINDOWS的默认打印上？
10 在WINDOWS安装了多台打印机的情况下，打印时能否选择输出的打印机？
sdlkfj2 sdlkfj2 sdlkfj2 (完)
以上提问的内容，包含了C/S和B/S方面的内容，但没有具体分开，大部分是本人测试实践中总结出来的，也参考了一些资料后整理得到的，希望对大家有用！
当然，内容不止这么少的，希望可以抱砖引玉，在测试过程中引起大家的思考，然后总结出更多更好的内容！ -
名词解释
2007-10-29
UI：UI即User Interface(用户界面)的简称。UI设计则是指对软件的人机交互、操作逻辑、界面美观的整体设计。好的UI设计不仅是让软件变得有个性有品味，还要让软件的操作变得舒适、简单、自由,充分体现软件的定位和特点。
-
软件测试 从零开始[强烈推荐]
2007-10-27
引言
几年前，从学校毕业后，第一份工作就是软件测试。那时候，国内的软件企业大多对软件测试还没有什么概念，书店里除了郑人杰编写的《计算机软件测试技术》之外，几乎没有其它的软件测试相关书籍，软件测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测试一无所知。不过，在正式走上工作岗位之前，公司提供了为期两周的系统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意义。现在，我继续从事软件测试的培训与咨询服务，在这个过程中，亲眼目睹了很多软件测试新手面对的困惑，他们初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。下面针对上述情况，给出若干解决办法。
• 测试准备工作
在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢？
• 向有经验的测试人员学习
如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方式固化到流程中。
如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。
• 阅读软件测试的相关书籍
现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。
• 走读缺陷跟踪库中的问题报告单
如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。
• 走读相关产品的历史测试用例
如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。
通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。
总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。
• 学习产品相关的业务知识
软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。
因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。
• 识别测试需求
识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法：
• 主动获取需求
开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。
当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析：
软件输入： 与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。
处理过程： 描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。
软件输出： 描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中，这部分内容作为测试用例的预期输出。
性能要求： 与该需求相关的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制，就是对需求的基本性能要求。
运行环境： 软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。
• 确认需求的优先级
确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。如果软件公司有规范的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？如果是这样，需求的优先级只能由测试人员完成了。
• 加入开发小组的邮件群组
测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如果公司里面有自动化办公系统，也许采用的是 Lotus Notes 系统，也许使用的是 E-mail 系统，测试人员应该加入到开发人员的邮件群组中。当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程，加入到开发邮件群组也是一个很好的习惯。
• 与开发人员为邻
建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能第一时间获得信息。无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司内部都存在部门墙，良好的人际关系是打通部门墙的手段之一。向领导建议测试人员与开发人员为邻，这很必要。
• 测试用例设计
测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：
• 测试用例的基本格式
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。
用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。
重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，
测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。
• 重用同类型项目的测试用例
如果我看得远，那是因为我站在巨人的肩上 －－牛顿。
一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。
• 利用已有的软件 Checklist
在上面一个小节中，按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试规范，比如， WEB 软件系统在系统测试过程中，会有一系列的范式，比如针对 Cookie 就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国内外的网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。
• 加强测试用例的评审
测试用例设计完毕后，最好能够增加评审过程。同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。 如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。
• 定义测试用例的执行顺序
在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。
• 测试用例执行
测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：
• 搭建软件测试环境，执行测试用例
测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。
如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。
• 测试执行过程应注意的问题
测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：
全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。
加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。
及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。
与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。
• 及时更新测试用例
测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。
总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。
• 提交一份优秀的问题报告单
软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。
软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。
硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。
测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。
输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。
日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。
根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。
• 测试结果分析
软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。 -
开篇语——发努力自己
2007-10-25
来公司工作已经六年了，这六年里，在公司的职位一变再变，从销售——技服——营销——测试——总调度——网络渠道——办公室主任——测试！又回到了测试，六年间感觉自己没有学到太多的东西，职位一直跟着公司的改革而变迁，现在我又申请回到了测试，因为我想真正的学点东西，年轻人不能如此的荒废时光。我不喜欢办公室的生活，太过轻松太过懒散，我要改变自己的生活，要为自己注入活力。从头开始吧，一切都在前面等着我……
加油，努力！！