-
数据库的测试
2008-11-11 22:24:58
数据库测试
随着软件业的迅猛发展，我们的开发也从以前的单层结构进入了三层架构甚至现在多层架构的设计，而数据库从以前一个默默无闻的后台仓库，逐渐成为了数据库系统，而数据库开发设计人员成为了炙手可热的核心人员。以前我们往往把数据库操作写在应用层，从而提高各个模块的独立性和易用性，而现在越来越多的数据库操作被作为存储过程直接放在数据库上进行执行来提高执行效率和提高安全性。
数据库开发既然在软件开发的比重逐步提高，随之而来的问题也突出。我们以前往往重视对代码的测试工作，随着流程技术的日益完善，软件质量得到了大幅度的提高，但数据库方面的测试仍然处于空白。我们从来没有真正将数据库作为一个独立的系统进行测试，而是通过对代码的测试工作间接对数据库进行一定的测试。随着数据库开发的日益升温，数据库测试也需要独立出来进行符合自身特点的测试工作。数据库开发和应用开发并没有实质上的区别，所以软件测试的方法同样适用于数据库测试
从测试过程的角度来说我们也可以把数据库测试分为
系统测试
传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证改修改是否落实到数据库上。
这个阶段我们的测试主要通过数据库设计评审来实现。
集成测试
集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说，需要考虑的是
数据项的修改操作
数据项的增加操作
数据项的删除操作
数据表增加满
数据表删除空
删除空表中的记录
数据表的并发操作
针对存储过程的接口测试
结合业务逻辑做关联表的接口测试
同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试
单元测试侧重于逻辑覆盖，相对对于复杂的代码来说，数据库开发的单元测试相对简单些，可以通过语句覆盖和走读的方式完成
系统测试相对来说比较困难，这要求有很高的数据库设计能力和丰富的数据库测试经验。而集成测试和单元测试就相对简单了。
而我们也可以从测试关注点的角度对数据库进行分类
对数据库功能的测试我们可以依赖与工具进行
DBunit
一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验
QTP
大名鼎鼎的自动测试工具，通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒。
DataFactory
一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试
数据库性能
虽然我们的硬件最近几年进步很快，但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的，如此庞大的数据量在大量并发连接操作时，我们不能像以前一样随意的使用查询，连接查询，嵌套查询，视图，这些操作如果不当会给系统带来非常巨大的压力，严重影响系统性能
性能优化分4部分
1物理存储方面
2逻辑设计方面
3数据库的参数调整
4SQL语句优化.
我们如何对性能方面进行测试呢，业界也提供了很多工具
通过数据库系统的SQL语句分析工具，我们可以分析得到数据库语句执行的瓶颈，从而优化SQL语句
Loadrunner
Swingbench（这是一个重量级别的feature，类似LR，而且非常强大，只不过专门针对oracle而已）
数据库厂商也意识到这点，例如
oracle11g已经提供了real application test，提供数据库性能测试，分析系统的应用瓶颈。
还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。
安全测试
软件日益复杂，而数据又成为了系统中重中之重的核心，从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端
自从SQL注入攻击被发现，冒失万无一失的数据库一下从后台变为了前台，而一旦数据库被攻破，整个系统也会暴露在黑客的手下，通过数据库强大的存储过程，黑客可以轻松的获得整个系统的权限。而SQL的注入看似简单缺很难防范，对于安全测试来说，如何防范系统被注入是测试的难点。
业界也有相关的数据库注入检测工具，来帮助用户对自身系统进行安全检测。
对于这点来说业界也有标准，例如ISO IEC 21827，也叫做SSECMM3.0，是CMM和ISO的集成的产物，专门针对系统安全领域的
另外一方面，数据库的健壮性，容错性和恢复能力也是我们测试的要点
我们也可以发现功能测试，性能测试，安全测试，是一个由简到繁的过程，也是数据库测试人员需要逐步掌握的技能，这也是以后公司对数据库测试人员的要求。
-
GUI测试之按钮篇
2008-10-27 14:12:01
l 在同一窗口中实现某一功能的按钮是唯一的。
l OK按钮总是在上方或者左方,而Cancel按钮总是在下方或右方。
l Cancel按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter保持一致。
l 测试按钮能否正常的实现功能，常用按钮的功能为：
l OK接受输入的数据或显示的响应信息，关掉窗口
l Cancel 不接受输入的信息，关掉窗口。取消时最好给予提示，尤其时有大量输入的窗口。
l Close 结束当前的任务，让程序继续进行；关掉数据窗口
l Help 调出程序的帮助信息
l Save 保存数据，停留在当前窗口。如过保存耗时长的话，最好显示类似沙漏，进度条之类的提示。注意验证能否重复保存。如在IE中由于网速慢而导致的重复保存。
l Add 新增记录。新增的记录必须排在首页首行。提交失败后必须保留用户已输入的内容，以便再次提交。提交时需对主要标识字段进行重复值、空值（空格）判断。
l Update/Edit 修改/编辑记录。如界面存在复选按钮，勾选多条记录进行修改时，需给予只能对一条记录进行修改，默认为第一条的提示信息。修改时加载的内容都为该记录的实际内容，而不再为默认值。修改完成后必须回到原记录所在位置，且刷新显示修改后的值。提交失败后必须保留用户已修改的内容，以便再次提交。在查询条件下修改返回后如不满足查询条件则不显示。需对主要标识字段进行重复值、空值（空格）判断。
l Delete 删除记录。在删除之前必须有确认删除的提示信息。删除成功后刷新不显示被删除的记录。删除成功后返回到原记录所在页面；而当原记录所在页不存在时，则返回上一页。当被删除的记录与其它记录存在关联时，应给予不允许删除及更明细提示等信息。针对大批量的删除应提供全选复选框，方便用户删除。
l Search 查询记录。每次查询应显示返回的结果数。每次查询应定位到首页。保留前一次的查询条件。当查询条件较多时，需配以重置按钮。当未查询到任何记录时，需给予未查找相关记录的提示信息。除用户明确要求不需要外，需提供模糊查询及组合查询功能。当查询返回的结果大于默认的一页大小时，最好采用分页或者根据系统默认或用户定义的一页显示的记录数量来分页。如有多页，需要提供首页，下一页，上一页，尾页和跳至功能。每页的记录不能重复，但也可以根据用户需要显示上一页的最后一条数据。
l Reset 重置。应回到打开窗口时的最初状态。多次点击是否还能正常显示。
l Return 返回。如果一个窗口或页面不能通过菜单，工具栏到达，而是必须通过前一个窗口完成才到达，应提供返回按钮或导航条让用户可以返回。
l 如果点击按钮后还需要用户的进一步的操作，按钮的名称应加上省略号。如Browse。。。
l OK/Cancel/Apply/Help键的排放最好遵从Windows的标准排放。
l 按钮最好都给予浮动提示，特别是图片按钮，可以避免由于网络太慢而导致的太长时间不能往下操作。
-
GUI
2008-10-27 14:10:56
GUI测试之窗口篇
窗口是Windows本身以及Windows 环境下的应用程序的基本界面单位，就是显示在屏幕上的一个矩形区域。一般来说窗口是具有标题栏、菜单/菜单栏、工具栏、工作区、状态栏、最大化、最小化按钮和滚动条的标准方框，应用程序通过它和用户进行交互。但是如果没有标题栏、状态栏、最大化、最小化按钮是不是就不叫窗口呢。其实不然，窗口的概念很广，例如按钮和对话框等也是窗口，只不过是一种特殊的窗口罢了。这里我主要将的还是标准意义上的窗口。
窗口主要有进入、移动、改变窗口大小；最大化、最小化和还原；使用滚动条和关闭窗口等操作。
因此可以通过如下来测试窗口：
l 大多数的窗口、屏幕/对话框应该有最小化，恢复和关闭按钮。
l 所有的窗口、屏幕/对话框应该有和内容相一致对应的标题。
l 只有主窗口才有标题栏图标、菜单栏、工具栏和状态栏。二级窗口不要使用菜单栏、工具栏或状态栏。
l 每一个窗口/屏幕都应有功能匹配的OK和Cancel按钮。窗口/对话框的缺省<Enter>键应该设置在OK按钮上；窗口/对话框的缺省<Esc>键应该设置在Cancel按钮上。
a.Escape键取消对话框，焦点重新定位回到父窗口先前的焦点上，
b.Alt＋F4关闭窗口，和Escape键相似，但它可以在即使没有Cancel按钮的对话框中工作
c.Alt＋Space打开窗口的菜单Restore, Move, Size, Minimize, Maximize, Close
d.Shift＋F10和右击效果一样。
e.可以用键盘上的箭头按钮实现Move和Size功能l 一个窗口每个组件的访问键必须是唯一的。
l 父窗体或主窗体的中心位置应该在对角线焦点附近;子窗体位置应该在主窗体的左上角或正中;多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
l 二级窗口最好不要显示在任务栏中，因为单击主窗口的任务栏按钮也会激活二级窗口。
l 如果子窗体的任何操作会影响了父窗体的数据时，关闭子窗体同时必须刷新父窗体的数据。
l 关闭父窗体时必须关闭所有打开的子窗体。如果由于子窗口没有关闭而无法关闭父窗口，必须给予提示信息框。在关闭提示信息框后显示必须关闭的子窗口。
l 子窗体的大小最好不要超过父窗体，且最好不要遮住父窗体的主要信息。如果存在多层嵌套窗口，每层窗口弹出时都自动往右下移动一点点，以保证不遮盖上层窗口标题为准。
l 窗口嵌套层次最好不超过3层。
l 点击窗口中的帮助按钮或F1必须带出和窗口内容相一致的帮助。
l 窗口可以被多次打开和关闭。但窗口未关闭或被其他窗口覆盖时，再次点击菜单或按钮，测试窗口是否可以被激活。
l 如果窗体可以最小化，最大化或可调整大小时，窗体上的控件也要随着窗体而缩放；对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
l 工具栏按钮应该有浮动的提示，可以根据用户的要求自己选择定制；:相同或相近功能的工具栏放在一起；:一条工具栏的长度最长不能超出屏幕宽度；工具栏的图标能直观的代表要完成的操作；系统常用的工具栏设置默认放置位置；:工具栏太多时可以考虑使用工具厢；:工具厢要具有可增减性，由用户自己根据需求定制。:工具厢的默认总宽度不要超过屏幕宽度的1/5
l 状态条要能显示用户切实需要的信息，常用的有： 目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。 状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
l 菜单和工具条应有清楚的界限，菜单和状态栏中使用统一大小的字体（通常使用5号字体）
l 菜单应采用“常用--主要--次要--工具--帮助”的位置排列。提供常用的菜单项，如“文件”、“编辑”，“查找”，“打印”等。对常用的菜单项提供快捷命令方式。快捷方式唯一。
l 主菜单数目不太多时最好为单排布置。如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。菜单深度一般要求最多控制在三层以内。
l 下拉菜单要根据菜单选项的含义进行分组，並且按照一定的规则进行排列，用横线隔开。一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
l 菜单前的图标不宜太大，与字高保持一直最好。主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
l 状态栏中的信息应该根据窗口的内容的变化而变化，如在初始状态时，系统有多少条数据，经过查询后状态栏的数据应该发生变化。
l 滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比；拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；单击滚动条和滚动条的上下按钮；用滚轮控制滚动条；
l 如果系统的模块较多，较深，经常会多级菜单，最好在窗口上加上导航条，以方便用户可以快速返回。
l 。。。。。。
-
GUI测试（转别人的总结）
2008-10-27 14:08:26
GUI测试之通用测试篇
不管是Windows的应用程序，还是Java的应用程序，或者其他语言类的应用程序，在其开放之前都应该遵从一定的GUI开发规范（这个大多SDK供应商都有）。那么测试也主要依据其进行GUI测试。虽然有些差异，但共同点还是很多的，这篇文章就是尝试着对这些共同点的一些总结。
l 在同一个应用程序中的GUI应该一致，这是最重要的，也是最基本的。
l 在视觉效果上应该和其他标准的Windows应用程序相同
l 采用标准的键集（快捷键），在同一系统中，同样的操作，特别是名称相同的操作就好使用一致的快捷键。例如浏览（Browse。。。）按钮如果在一个窗口中快捷键是Alt+B,在另一个窗口最好采用同样的快捷键，这样可以方便用户的操作，不至于让用户混淆快捷键。除非在另一个窗口有比其更重要的操作已占用了一个快捷键，否则最好不要改变。
l 应用程序启动或进入系统的第一个界面应该显示“关于系统”或有关系统相关信息的屏幕
l 一般来说，应用程序应该保持为最大化。
l 应用程序可以在Windows的任务条和状态条中显示，如需要在系统托盘中显示的，在缩写至系统托盘和用户移动光标至应用程序的图标上时，最好给予相关的信息。
l 在系统中使用统一的代表应用程序的图标。
l 所有的窗口/对话框应具有可以和其他应用程序区分开的一致外观。
l 应用程序中使用的颜色组合应该有吸引力，且风格一致，搭配合理，色彩的跳跃不要太大。避免使用深色系，特别是红色和绿色，有些客户可能是色盲
l 登录界面上要有产品信息，如标志和版本，同时包含公司图标。
l 帮助菜单的“关于”中应有版权和产品信息。
l 应用程序中应按功能将界面划分局域块，将完成相同或相近功能的按钮框起来, 并配有相应的功能说明
l 允许使用Tab键切换，且顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式；Tab不能定位在不可见的控件上；
l 在不同的分辨率下显示正常（不出现水平和垂直滚动条，无截断的组件），特别是在应用程序推荐的分辨率下显示完全正常，一般为1024*768和800*600。
l 系统中所有的文字应该没有拼写/文字错误，句子没有语法错误，最好贴近用户的使用习惯。
l 使用用户知道的术语，而不是深奥的技术术语，特别是在错误提示的消息框中，让用户可以很快的知道问题的所在，而不是揣摩错误信息的意思。尽可能的少用缩写。
l 英文系统中注意不要使用中文或其他语系字符。
l 在标识控件用途的标签文本和提示信息中，应使用半角符号。如果是指导性标签文本（如解释按钮功能的句子），则使用全角符号，并且句子应遵循中文标点符号标准。
l 在提示信息中，避免使用主语，尽可能的使用被动语态。提示信息应简洁明了，没有侵犯性词语。使用一致的大小写规则，避免全大写和复杂的符号。
l 系统使用统一的字体，不要使用需要另外安装的或操作系统特定的字体库。注意斜体和粗体的使用。
l 系统目前不提供，以后版本才提供的功能最好隐藏，同一版本不同级别的系统中的不允许使用的功能变灰，或操作提交时给予提示。
l 系统的帮助文件应该和当前的系统版本相一致
l 使用"退出"命令终止程序；使用"关闭"移走主窗口和非模式对话框；使用"取消"移走模式对话框。当关闭主窗口并不表示终止进程时，对于主窗口使用"关闭"来代替使用"退出"。例如：关闭打印机状态窗口不会取消打印任务
l 退出系统后应该彻底的关闭程序，而不要在系统托盘或任务条中继续保留系统的某个窗口。如果要保留，在退出系统时应该给予用户提示。
l 程序应该能够能够保存而恢复到用户最后退出的状态。MDI程序应该能够恢复文档窗口的大小和位置。对话框，下拉框通常应该使用最后输入的值作为默认值。
l 不同界面中的同一功能应该使用同样的图标和图片。
l 公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮，用语等应该大体一致。
-
GUI测试（转别人的总结）
2008-10-27 14:06:31
GUI测试总结GUI,GRAPHICAL USER INTERFACE的缩写,通常发音为GOO-ee。众所周之，GUI就是使用图像，输入的文字，带图标的屏幕的计算机界面，取而代之许多键盘的功能。GUI让用户可以通过图标和鼠标与他们的电脑进行交互，而不是在命令行中输入文本。第一个图形用户界面是由Xerox Palo Alto 研究中心在1970年设计的，但是直到1980年代随着苹果的Macintosh出现GUI才开始流行起来。导致其被长时间才被接受的一个原因是GUI需要相当多的CPU和质量好的显示器，而这些在以前都是相当昂贵的。现在主要的操作系统都提供了图形用户界面,如Microsoft的Windows, Apple的Mac OS和 Sun Microsystem的OpenWindows等.利用计算机的图形能力产生的程序界面使得程序更加容易被使用。良好设计的图形用户界面可以使用户从负责的命令语言中解放出来。一般来说，应用程序有以下的基本的组件（或者说是元素）：-
光标（pointer）：显示在屏幕上让用户移动以选择对象和命令的符号。通常显示为一个小的箭头。但是在文字处理的应用程序则是用象大写I一样的光标。
-
图标（icon）/图片（picture）：代表命令，文件或窗口的小图片。通过移动光标到图标上然后按下鼠标，用户可以执行预定的命令。
-
窗口（window）表单（Form），属性页（Property Sheets），Tab。
-
菜单（menu），工具栏（tool bar），状态栏（Status bar），进度栏（progress bar）
-
按钮（button）
-
对话框（dialog Box），消息框（message Box），输入对话框（input box）
-
文本框（Text Box），列表框（List Box），组合框（combo Box）、下拉列表框（Drop-down List Box）
-
复选框（Check Box），单选框（Radio box），选项框（Option box）、滑动条（Slider）、旋转按钮（Spin Button）
-
静态文字（Static tex），向导（Wizards），树（Tree）
-
……
由于图形用户界面的普及，针对GUI的测试也单独成为了软件测试的一个重点。在GUI刚开始被采用时，由于没有统一的规范，这一块的测试比较主观。但随GUI技术的成熟，组件的大量采用及重用，越来越多可以遵循的指南使得GUI测试更加客观也更加贴近用户。此时慢慢的GUI测试逐渐的和功能测试分开。广义的功能测试（和非功能测试相反），包括系统除了非功能性以外所有的测试。狭义的功能测试主要是指检验和验证系统是否实现了系统的业务需求，旨在验证系统的业务实现能力。GUI测试则主要关注应用程序上GUI组件是否符合规范或用户的操作习惯。当然GUI测试是不可以脱离功能而独立测试的，它是随着功能的实现，一个一个窗口进行校验的，也可以和功能测试一起测试。对于简单的系统可以将GUI测试和验证功能实现一起进行，但对于稍微大一些的系统，最好将其分开，这样才不至于遗漏任何一个重点。在接下来的文章中，我主要将针对GUI的元素将我的测试经验进行总结：-
GUI测试之其他组件篇
-
