-
QC的备份2法(转)
peterz 发布于 2009-03-31 10:51:58
第一种
文档转自(http://netadmin.77169.com/HTML/20061026001500.html)
1.停止QC Server；
2.备份Domain repository，它囊括每个项目的大量数据（包括自动化测试数据、附件、设置和格式表单等）。要想知道某个项目所使用的数据库的名字，可以在Site Administrator的Projects标签下单击项目列表选择一个项目，右边 Project Directory会显示这个项目Domain库的路径。如果安装QC时，安装路径是默认的，那么Domain库存储在：
Windows***作系统:C:\Program Files\Common Files\Mercury Interactive\Quality Center\repository\qc
Linux/Unix***作系统:/opt/Mercury_Interactive/Quality_Center/repository/qc
如果不是采用默认路径，那么作相应变更。
3.备份数据库服务器，它囊括了其他项目数据（例如手动测试数据、缺陷、自定义数据、组测试和运行测试数据）。要想知道某个项目所使用的数据库的名字，可以在Site Administrator的Projects标签下单击项目列表选择一个项目，右边Database Name就会显示这个项目所使用的数据库名称。至于数据库的备份，请google相关信息。
4.备份Site Admin Schema，它囊括了所有QC系统管理的数据，例如用户信息，项目列表等，在<QC_HOME>\repository\qc目录下的dbcont.txt里，可以找到Site Admin schema所在的数据库名字，例如，schema_name@database_server.port.database。第二种
原文转自
http://angeletshome.spaces.live.com/blog/cns!9AE7B1EF7B0AD21!270.entry
QC的备份
QC的备份方案有好多种，比如QC联机帮助文档中给出的“Backing Up and Restoring Quality Center Projects”就是一种简便易行的方案。这里不做说明，需要的话可看文档。
这里想总结的是我的备份方案，假定：机器a安装QC1（应用服务器及数据库服务器均在机器a），机器b安装QC2（应用服务器及数据库服务器均在机器b），日常使用的机器为QC1。
预期的实现目的：
QC1上的全部工程均移植到QC2，QC1每天更新的数据自动备份到QC2，并可通过QC2正确访问QC1备份过来的工程。
实现方法：
1. 在机器b上安装QC2，应用服务器、数据库服务器均在机器b。
2. 登录QC2的SiteAdmin管理台，按照QC1站点管理中的域和项目的名称，全部新建到QC2中。注意新建这些域、工程的顺序，需要按照QC1中域、项目新建的顺序来新建到QC2中。域的顺序可按照QC1 qcsiteadmin_db数据库Domains表中Domain_id序号来新建；工程的顺序按照projects表中的id来新建。
3. 完毕后，将QC1所有工程对应的数据库数据，全部导出到QC2对应数据库中。可使用SQLServer的导入导出工具。需要自动备份的数据库，保存dts包，每天执行导出数据。
4. 将QC1的qcsiteadmin数据库中，筛选需要备份到QC2的表，进行数据导出，备份到QC2。需要备份的表：除Projects之外的所有表，均可备份到QC2，并保存dts包执行自动备份。
5. 登录QC2站点管理页面，检查各工程是否可以正确打开，项目用户是否都存在等，然后登录各工程，检查是否正常。
其他问题及注意事项：
以上第二步中，需要按domain、工程顺序来新建，是否可以通过将domains、projects表导入QC2来实现？可以，但导过来后，需要手工修改的地方：1.QC安装目录下Repository\qc\domainname\projectname\目录下的dbid.xml文件，将文件中的数据库连接参数、数据库服务器名称、repository目录位置，全部修改为QC2对应的正确信息；2.修改qcsiteadmin_db中的projects表，也修改1中的三项。
看哪种方法比较方便吧。
另外一点，若QC1和QC2中的域、工程新建时顺序不一致（对应数据库Domains表、Projects表ID不一致），那么数据备份过来后，需要手工修改的地方就更多了。所以二者序号一定要一致。
-
[论坛] QC的备份！
jiguoling 发布于 2009-05-05 21:04:22
QC的备份分以下几种情况：
- 可以运行QC站点管理中的导出功能，导出的文件为.QCP文件，在恢复的时候，可以通过对应的导入功能来完成，导入后任何设置都不会改变；
- 可以通过将数据库备份-还原的方式，恢复QC的数据库，数据库的路径为sql默认路径下的DATA目录下；
- 可以通过分离-附加的方式，恢复QC的数据库；
- 如果是平时的备份可以选择以上3种，但我建议用第一种；
- 如果QC需要重新安装的情况下，可以通过第一种，也可以通过第三种方法，其中第一种方法在导入的时候会由于数据库的一些设置不同，有时会带来导入的麻烦；第三种方法需要注意的是，将data目录下的数据备份出来，千万要保存着，在sql数据库中将data目录下的数据库全部附加到数据库中，可以和QC使用的数据库安装在sql的同一个组内，再通过将备份的data数据库中的数据导入到QC已经存在的数据库中，一定要注意数据库之间要对应好，A对应A。
-
使用LoadRunner时如何选择合适的协议
温馨香屋 发布于 2009-01-04 10:24:26
这个问题吧，问的非常好，应该是大家都比较关心的问题。当年我也一直未这个问题很困惑。我想在回答这个问题之前，先搞清楚什么是协议，为什么要选择协议。这就需要我们对通信机理有一些的了解。
首先，什么是协议？
协议无非就是一个约定，关于数据包发送的格式的约定，就是说如果大家都这样发送，那么通信就能够成功，如果大家都各按各的来，那么就没办法进行通信了。
那么接下来就是LR录制时的工作原理了，LR的录制和WR不一样，它不关心你的对象识别什么的，不关心你的什么窗口之类的，LR有一个Agent进程，来专门监控客户端和服务器之间的通信，然后用自己的函数进行录制。所以说，LR录制的时候关心的是通信，是客户端和服务器之间的数据包。说到这里，大家就比较清楚了，为什么有的时候不能录制呢？因为，协议不认识阿，导致LR截获的数据包不能解析，所以录制下来是空的。
到这里我们再来看，那我们怎么样选择协议呢？当然原则就是说，你数据包的通信协议能被LR识别。
过去流行的一种说法是，只要B/s结构的都是选择http协议，如果不是b/s那么肯定是socket，其实这种说法是比较肤浅或者比较片面的，我觉得要真正理解这个问题，必须搞清楚你所测系统的数据流采用的什么协议包装的。这个我个人觉得，最好是能去向开发人员多了解，多学习。（说到这里，我想顺便建议一点：测试人员向开发人员学习是个好习惯，多学一点底层的东西，或者对程序架构，数据流向，内部结构分析多了解一点，对自己的测试很有帮助，对自己的成长也是有帮助的），另外，个人觉得，作为一个测试人员需要多了解一些网络方面的专业知识，最好学习一些网络分析工具譬如说Sniffer等，这对测试很有帮助。
说了这么多，似乎跑题了？还是回到正题，如何选择协议。
我下面给大家推荐一些建议值，是我在某本测试专业书籍上看到了，给大家贴上来，仅供参考。我还是说，具体问题具体分析，选择协议不是一个教条的事情，而是需要研究探索并尝试。
协议选择参考：
应用类型 协议选择
1. Web网站 HTTP/HTML
2. FTP服务器 FTP
3. 邮件服务器 IMAP，POP3，SMTP
4. C/S （第一种）客户端以ADO，OLEDB方法连接后台数据库 MS SQL Server，Oracle，Sybase，DB2，Infrmix
C/S （第二种）客户端以ODBC方法连接后台数据库 ODBC
C/S （第三种）没有后台数据库 Socket
5. ERP系统 SAP Peoplesoft
6.分布式组件 COM/DACOM EJB
7.无线应用 WAP PALM
总之，只有充分了解被测系统的应用类型和技术架构，才能做出正确的选择。
-
Loadrunner IP欺骗
mexia 发布于 2008-06-24 09:26:05
Loadrunner IP欺骗
原创文章，转载注明出处：http://www.51testing.com/?41972
使用loadrunner进行IP欺骗首先要注意以下两点：
1、 本地的IP设置不能为“自动获取”，必须指定一个静态IP
如果本地是动态获取IP，在运行IP Wizard时会弹出提示：
The IP wizard does not support DHCP-enabled network cards.
Your cards are either DHCP-enabled or configured with invalid settings.
Please contact your system administrator.
此时只需要将IP地址改成静态IP地址就可以了
2、 所添加的IP只能是局域网内的网段
只能添加192段，127段，10段IP地址
好下面开始介绍如何使用IP欺骗
一、添加IP地址
第一步：
运行Mercury LoadRunner- Tools-IP Wizard
弹出的IP设置向导中的各项含义如下：
1、 create new setting 新建IP列表
当我们第一次使用IP欺骗或已经释放所添加的IP时，需要选择此项添加新的IP地址
2、 load previous setting from file 读取IP列表文件
从以前设置的IP地址列表文件中读取IP地址
3、 restore original setting 释放已设置的IP
释放已经添加的IP地址
说明：loadrunner在做IP欺骗时，真实的虚拟了IP地址，该IP地址均真实存在，可以ping通，可以建立网络链接，在不使用时必须进行释放，否则这些IP地址将一直存在。
第二步：
选择create new setting，点击“下一步”
此时出现的页面是让输入服务器的IP地址，loadrunner通过该地址更新路由表。
客户端计算机上添加新的 IP 地址后，服务器需要将该地址添加到路由表，以便能够识别返回到客户端的路由。如果服务器和客户端具有相同的子网掩码、IP 类和网络，则不需要修改服务器的路由表。
注意： 如果客户端和服务器计算机之间有一个路由器，则服务器需要识别经过该
路由器的路径。确保将以下路由添加到服务器路由表：从 Web 服务器到路由器
的路由，以及从路由器到负载生成器计算机上的所有 IP 地址的路由。
第三步：
在输入服务器地址的页面中不输入任何地址，直接点击“下一步”
进入IP添加页面
点击“add”进行添加
第四步：
在from ip 输入框中输入起始ip，在Number to输入框中输入ip地址的位数
输入正确的子网掩码
选中“verify that new ip addresses are not already used”
点击“ok”，此时IP Wizard会自动按照设置生成IP地址，并且将已经占用的IP列出
第五步：
确认可用IP地址列表内容后，点击“ok”
此时IP Wizard提示需要重新启动计算机，点击“save as”保存IP列表
点击“ok”，重新启动计算机
第六步：
计算机重新启动后，在运行行中输入：CMD，在DOS命令窗口中输入：IPCONFIG，此时便可看到虚拟的IP地址均已经被启用
二、在loadrunner中使用虚拟IP
第一步：
打开controller，在controller中，选择 Scenario-〉Enable IP Spoofer，此项设置允许使用IP欺骗。
第二步：
设计场景：
有两种方案来设计场景
1、 本地使用虚拟IP设计场景（不带负载生成器使用localhost进行测试）
在设置该类场景时，在场景中添加一个录制好的脚本，该脚本中添加如下代码便可看到虚拟用户在使用哪个IP地址进行消息发送，该场景是通过线程方式进行性能测试。
char * ip；
ip=lr_get_vuser_ip();
if (ip)
{
lr_vuser_status_message("The ip address is %s",ip);
}
else
lr_vuser_status_message("IP spoofing disabled");
在controller中执行该脚本时，查看虚拟用户运行状态，便可看到当前虚拟用户使用的哪个IP地址发送消息
2、 负载生成器使用虚拟IP设计场景
在设置该类场景时，需要添加负载生成器，建立负载生成器时输入创建的虚拟IP，每个负载生成器为一个虚拟用户组，该场景是通过进程方式进行性能测试。
如何添加负载生成器创建场景在这里就不多描述了。
但需要注意，选中Tools下的Expert mode，启动专家模式
再点击Tools下的options
在Genearl选项卡中设置已线程方式或进程方式进行性能测试，这个选项一定要与当前场景的模式相匹配，也就是说使用本地虚拟IP测试时需要选中线程方式，使用负载生成器使用虚拟IP测试时需要选中进程方式
三、使用虚拟IP测试完成后
打开IP Wizard，释放所有虚拟IP。
重新启动计算机
原创文章，转载注明出处：http://www.51testing.com/?41972
原创文章，转载注明出处：http://www.51testing.com/?41972
使用loadrunner进行IP欺骗首先要注意以下两点：
1、 本地的IP设置不能为“自动获取”，必须指定一个静态IP
如果本地是动态获取IP，在运行IP Wizard时会弹出提示：
The IP wizard does not support DHCP-enabled network cards.
Your cards are either DHCP-enabled or configured with invalid settings.
Please contact your system administrator.
此时只需要将IP地址改成静态IP地址就可以了
2、 所添加的IP只能是局域网内的网段
只能添加192段，127段，10段IP地址
好下面开始介绍如何使用IP欺骗
一、添加IP地址
第一步：
运行Mercury LoadRunner- Tools-IP Wizard
弹出的IP设置向导中的各项含义如下：
1、 create new setting 新建IP列表
当我们第一次使用IP欺骗或已经释放所添加的IP时，需要选择此项添加新的IP地址
2、 load previous setting from file 读取IP列表文件
从以前设置的IP地址列表文件中读取IP地址
3、 restore original setting 释放已设置的IP
释放已经添加的IP地址
说明：loadrunner在做IP欺骗时，真实的虚拟了IP地址，该IP地址均真实存在，可以ping通，可以建立网络链接，在不使用时必须进行释放，否则这些IP地址将一直存在。
第二步：
选择create new setting，点击“下一步”
此时出现的页面是让输入服务器的IP地址，loadrunner通过该地址更新路由表。
客户端计算机上添加新的 IP 地址后，服务器需要将该地址添加到路由表，以便能够识别返回到客户端的路由。如果服务器和客户端具有相同的子网掩码、IP 类和网络，则不需要修改服务器的路由表。
注意： 如果客户端和服务器计算机之间有一个路由器，则服务器需要识别经过该
路由器的路径。确保将以下路由添加到服务器路由表：从 Web 服务器到路由器
的路由，以及从路由器到负载生成器计算机上的所有 IP 地址的路由。
第三步：
在输入服务器地址的页面中不输入任何地址，直接点击“下一步”
进入IP添加页面
点击“add”进行添加
第四步：
在from ip 输入框中输入起始ip，在Number to输入框中输入ip地址的位数
输入正确的子网掩码
选中“verify that new ip addresses are not already used”
点击“ok”，此时IP Wizard会自动按照设置生成IP地址，并且将已经占用的IP列出
第五步：
确认可用IP地址列表内容后，点击“ok”
此时IP Wizard提示需要重新启动计算机，点击“save as”保存IP列表
点击“ok”，重新启动计算机
第六步：
计算机重新启动后，在运行行中输入：CMD，在DOS命令窗口中输入：IPCONFIG，此时便可看到虚拟的IP地址均已经被启用
二、在loadrunner中使用虚拟IP
第一步：
打开controller，在controller中，选择 Scenario-〉Enable IP Spoofer，此项设置允许使用IP欺骗。
第二步：
设计场景：
有两种方案来设计场景
1、 本地使用虚拟IP设计场景（不带负载生成器使用localhost进行测试）
在设置该类场景时，在场景中添加一个录制好的脚本，该脚本中添加如下代码便可看到虚拟用户在使用哪个IP地址进行消息发送，该场景是通过线程方式进行
-
LoadRunner性能测试指标分析
guobin_it 发布于 2008-01-21 18:35:47
LoadRunner性能测试指标
Object
Counters
Descrīption
Reference value
Memory
Available Mbytes
可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
4 MB 或更小，至少要有10%的物理内存值
Page/sec
(Input/Out)
为了解析硬页错误，从磁盘取出或写入的页数。一般如果Page/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
推荐00-20
如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题(太多的读写数据操作要访问磁盘，可考虑增加内存或优化读写数据的算法)。
该系列计数器的值比较低说明响应请求比较快， 否则可能是服务器系统内存短缺引起（也可能是缓存太大， 导致系统内存太少）。
>5越低越好
Page Fault
处理器每秒处理的错误页（包括软/硬错误）。
当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个Page Fault。如果该页在内存的其他位置，该错误被称为软错误（用Transition Fault/sec记数器衡量）；如果该页必须从硬盘上重新读取时，被称为硬错误。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。
Page Input/sec
为了解决硬错误页，从磁盘上读取的页数。
Page Output/sec
Page reads/sec
为了解决硬错误页，从磁盘上读取的次数。解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
Cache Bytes
文件系统缓存，默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
内存泄露
如果您怀疑有内存泄露，请监视 Memory\\ Available Bytes 和 Memory\\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\\Private Bytes、Process\\Working Set 和Process\\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\\Pool Nonpaged Bytes、Memory\\ Pool Nonpaged Allocs 和 Process(process_name)\\ Pool Nonpaged Bytes。
Process
Page Faults/sec
将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Private Bytes
此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
Work set
处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Processor
% Processor Time
被消耗的处理器时间数量.如果服务器专用于sql server可接受的最大上限是80% -85%.也就是常见的CPU使用率.
ProcessorQueue Length
判断CPU瓶颈,如果processor queue length显示的队列长度保持不变(>=2)并且处理器的利用率%Processor time超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.
Physical
Disk
%DiskTime
指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
正常值<10，此值过大表示耗费太多时间来访问磁盘，可考虑增加内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络连接并没有饱和)，则可能是内存泄漏。
CurrentDiskQueueLength
读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。(磁盘数1.5-2倍)
Avg.Disk Queue
Length
Avg.Disk Read
QueueLength
Avg.Disk Write
QueueLength
Disk Read/sec
Disk Write/sec
读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。
磁盘瓶颈判断公式：
每磁盘的I/O数=（读次数+（4*写次数））/磁盘个数。
如果计算出来的每磁盘的I/O数大于磁盘的处理能力，那么磁盘存在瓶颈。
Avg.DiskQueue Length正常值<0.5，此值过大表示磁盘IO太慢，要更换更快的硬盘。
-
QTP Recovery Scenario 简介
ccc11yyy 发布于 2006-12-19 17:59:24
场景恢复可以用于应对测试脚本在运行的过程中出现的异常，在预估可能出现的异常状况下，添加对应的场景恢复，可以使脚本运行的更加通畅。以下是訯TP Recovery Scenario的简单介绍，希望对初学者有所帮助。
添加一个新的场景恢复，通过菜单Tools->Recovery Scenario Manager进入，主要分为以下四个步骤。
[步骤一：Trigger]
场景恢复机制提供了四种类型的触发事件，分别用来识别：弹出对话框、对象的特殊属性值、运行错误、应用程序失败。
可以根据具体的需求来添加各个类型的恢复场景，每种类型的选项可以在添加向导中选择，如下图。
[步骤二：Recovery]
恢复的操作可以是自定义按钮操作，函数调用，关闭应用程序进程，重起机器等等，几乎涵盖了所有QTP的正常操作，按照向导进行设置，操作很方便。也可以添加多个恢复操作，且调整执行顺序，注意：重起系统总是排在最后一个。
添加操作完成，把Add another recovery operation前的按钮去掉，才可以进入下一步。
[步骤三：Post-recovery]
在Post-recovery中，又分了6个选项：
Repeat current step and continue:重复当前步骤然后继续向下
Proceed to next step：处理下一步
Proceed to next action or component iteration：处理下一个Action，或者组件的下一个循环
Proceed to next test iteration：处理该测试的下一个循环
Restart current test run：重新启动当前的测试
Stop the test run：终止测试运行这些操作的差别在具体实践中体会吧，这里就不赘述了。
[步骤四：Name]
一切都设置好以后，就给你的场景恢复起个唯一的名字吧。也可以添加一些描述方便维护工作。开始使用场景恢复，在Test->Settings->Recovery中添加设置好的恢复场景，然后选择激活方式（On every step/On error/Never）。
On every step，只要出现恢复的场景，就执行场景恢复中的动作，然后继续。
On error，在出现错误的时候，才查找是否符合待恢复的场景，如果是则执行恢复操作。
Never，无论如何，都不运行场景恢复机制。提供两个执行场景恢复的小例子：
例1 ：
[配置]
1，在Recovery Scenario Properties中，Post-Recovery Operation选择Repeat current step and continue
2，激活方式为On every step
[现象]
只要出现恢复的场景，就执行场景的动作，并且重复执行出现该场景的那条语句，然后继续。适用于重复尝试必将成功的场景，否则死循环。例2：
[配置]
1，在Recovery Scenario Properties中，Post-Recovery Operation选择Repeat current step and continue
2，激活方式为On error
[现象]
出现错误后，进入场景恢复机制，就执行场景的动作，（并没有重复执行出现该场景的那条语句，不知道为什么）直接执行下一条语句。 -
Bug Life Cycle & Guidelines （缺陷生命周期指导手册）
shiker2003 发布于 2008-08-26 15:29:05
（原文 http://www.exforsys.com/tutorials/testing/bug-life-cycle-guidelines.html）
Introduction:引言
Bug can be defined as the abnormal behavīor of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software. A bug is a specific concern about the quality of the Application under Test (AUT).
缺陷可以被定义为软件的异常行为。不存在一个缺陷的软件是不存在的。消除软件缺陷依赖于高效率的测试。一个缺陷对于在测软件来讲是不容小视的。（这句大意应该没问题，不过能力有限翻译的不好）
Bug Life Cycle: 缺陷生命周期
In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows:
在软件开发过程中，缺陷拥有自身的生命周期。缺陷在走完其生命周期最终会关闭。确定的生命周期保证了过程的标准化。缺陷在其生命周期中会处于许多不同的状态。缺陷的生命中期通过下图展示了出来：
注： 深绿色状态为测试经理设置
浅绿色状态为测试员设置
浅蓝色状态为开发人员设置
The different states of a bug can be summarized as follows:
缺陷各个不同的状态如下：
1. New 新建
2. Open 打开
3. Assign 指派
4. Test 测试
5. Verified 确认
6. Deferred 延期
7. Reopened 重新打开
8. Duplicate 重复
9. Rejected 拒绝
10. Closed 关闭Descrīption of Various Stages:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
1.新建：当缺陷被第一次递交的时候，它的状态即为“新建”。这也就是说缺陷未被确认其是否真正是一个缺陷。
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
2.打开：在测试者提交一个缺陷后，测试组长确认其确实为一个缺陷的时候他会把状态置为“打开”
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
3.分配：一旦缺陷被测试经理置为“打开”，他会把缺陷交给相应的开发人员或者开发组。这时缺陷状态变更为“分配”。
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
4.测试：当开发人员修复缺陷后，他会吧缺陷提交给测试组进行新一轮的测试。在开发人员公布已修复缺陷的程序之前，他会把缺陷状态置为“测试”。这时表明缺陷已经修复并且已经交给了测试组。
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
5.延迟的：缺陷状态被置为“延迟的”意味着缺陷将会在下一个版本中被修复。将缺陷置为“延迟的”原因有许多种。有些由于缺陷优先级不高，有些由于时间紧，有些是因为缺陷对软件不会造成太大影响。
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
6.不接受的：如果开发人员不认为其是一个缺陷，他会不接受。他会吧缺陷状态置为“不接受的”
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
7.重复提交：如果同一个缺陷被重复提交或者两个缺陷表明的意思相同，那么这个缺陷状态会被置为“重复提交”
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
8.已核实：一但缺陷被修复它就会被置为“测试”，测试员会执行测试。如果缺陷不再出现，这就证明缺陷被修复了同时其状态被置为“已核实”。
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
9.再次打开：如果缺陷被开发人员修复后仍然存在，测试人员会把缺陷状态置为“再次打开”。缺陷即将再次穿越其生命周期。
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.
10.关闭：一但缺陷被修复，测试人员会对其进行测试。如果测试人员认为缺陷不存在了，他会把缺陷状态置为“关闭”。这个状态意味着缺陷被修复，通过了测试并且核实确实如此。
-
SQL Server数据库优化方案
charmer 发布于 2007-10-31 10:00:23
查询速度慢的原因很多，常见如下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。
4、内存不足 5、网络速度慢
6、查询出的数据 量过大(可以采用多次查询，其他的方法降低数据量)
7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)
8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列
10、查询语句不好，没有优化
可以通过如下方法来优化查询 :
1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量(尺寸)越大，提高I/O越重要.
2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)
3、升级硬件
4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小，使用字节数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段
5、提高网速;
6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行 Microsoft SQL Server? 2000 时，可考虑将虚拟内存大小设置为计算机中安装 的物理内存的 1.5 倍。如果另外安装了全文检索功能，并打算运行 Microsoft 搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将 SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍(虚拟内存大小设置的一半)。
7、增加服务器 CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作Update,Insert， Delete还不能并行处理。
8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。
9、DB Server 和APPLication Server 分离;OLTP和OLAP分离
10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。(参照SQL帮助文件'分区视图')
a、在实现分区视图之前，必须先水平分区表
b、在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用 程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：
1、 查询语句的词法、语法检查
2、 将语句提交给DBMS的查询优化器
3、 优化器做代数优化和存取路径的优化
4、 由预编译模块生成查询规划
5、 然后在合适的时间提交给系统处理执行
6、 最后将执行结果返回给用户其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。
12、Commit和rollback的区别 Rollback:回滚所有的事物。 Commit:提交当前的事物. 没有必要在动态SQL里写事物，如果要写请写在外面如： begin tran exec(@s) commit trans 或者将动态SQL 写成函数或者存储过程。
13、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。
14、SQL 的注释申明对执行没有任何影响15、尽可能不使用光标，它占用大量的资源。如果需要row-by-row地执行，尽量采用非光标技术,如：在客户端循环，用临时表，Table变量，用子查询，用Case语句等等。游标可以按照它所支持的提取选项进行分类： 只进 必须按照从第一行到最后一行的顺序提取行。FETCH NEXT 是唯一允许的提取操作,也是默认方式。可滚动性可以在游标中任何地方随机提取任意行。游标的技术在SQL2000下变得功能很强大，他的目的是支持循环。有四个并发选项 READ_ONLY：不允许通过游标定位更新(Update)，且在组成结果集的行中没有锁。 OPTIMISTIC WITH valueS:乐观并发控制是事务控制理论的一个标准部分。乐观并发控制用于这样的情形，即在打开游标及更新行的间隔中，只有很小的机会让第二个用户更新某一行。当某个游标以此选项打开时，没有锁控制其中的行，这将有助于最大化其处理能力。如果用户试图修改某一行，则此行的当前值会与最后一次提取此行时获取的值进行比较。如果任何值发生改变，则服务器就会知道其他人已更新了此行，并会返回一个错误。如果值是一样的，服务器就执行修改。选择这个并发选项OPTIMISTIC WITH ROW VERSIONING:此乐观并发控制选项基于行版本控制。使用行版本控制，其中的表必须具有某种版本标识符，服务器可用它来确定该行在读入游标后是否有所更改。在 SQL Server 中，这个性能由 timestamp
数据 类型提供，它是一个二进制数字，表示数据库中更改的相对顺序。每个数据库都有一个全局当前时间戳值：@@DBTS。每次以任何方式更改带有 timestamp 列的行时，SQL Server 先在时间戳列中存储当前的 @@DBTS 值，然后增加 @@DBTS 的值。如果某 个表具有 timestamp 列，则时间戳会被记到行级。服务器就可以比较某行的当前时间戳值和上次提取时所存储的时间戳值，从而确定该行是否已更新。服务器不必比较所有列的值，只需比较 timestamp 列即可。如果应用程序 对没有 timestamp 列的表要求基于行版本控制的乐观并发，则游标默认为基于数值的乐观并发控制。 SCROLL LOCKS 这个选项实现悲观并发控制。在悲观并发控制中，在把数据库的行读入游标结果集时，应用程序将试图锁定数据库行。在使用服务器游标时，将行读入游标时会在其上放置一个更新锁。如果在事务内打开游标，则该事务更新锁将一直保持到事务被提交或回滚;当提取下一行时，将除去游标锁。如果在事务外打开游标，则提取下一行时，锁就被丢弃。因此，每当用户需要完全的悲观并发控制时，游标都应在事务内打开。更新锁将阻止任何其它任务获取更新锁或排它锁，从而阻止其它任务更新该行。然而，更新锁并不阻止共享锁，所以它不会阻止其它任务读取行，除非第二个任务也在要求带更新锁的读取。滚动锁根据在游标定义的 Select 语句中指定的锁提示，这些游标并发选项可以生成滚动锁。滚动锁在提取时在每行上获取，并保持到下次提取或者游标关闭，以先发生者为准。下次提取时，服务器为新提取中的行获取滚动锁，并释放上次提取中行的滚动锁。滚动锁独立于事务锁，并可以保持到一个提交或回滚操作之后。如果提交时关闭游标的选项为关，则 COMMIT 语句并不关闭任何打开的游标，而且滚动锁被保留到提交之后，以维护对所提取数据的隔离。所获取滚动锁的类型取决于游标并发选项和游标 Select 语句中的锁提示。锁提示 只读 乐观数值 乐观行版本控制 锁定无提示 未锁定 未锁定 未锁定 更新 NOLOCK 未锁定 未锁定未锁定 未锁定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 错误 更新 更新 更新 TABLOCKX 错误 未锁定 未锁定更新其它 未锁定 未锁定 未锁定 更新 *指定 NOLOCK 提示将使指定了该提示的表在游标内是只读的。
16、用Profiler来跟踪查询，得到查询所需的时间，找出SQL的问题 所在;用索引优化器优化索引
17、注意UNion和UNion all 的区别。UNION all好
18、注意使用DISTINCT，在没有必要时不要用，它同UNION一样会使查询变慢。重复的记录在查询里是没有问题的
19、查询时不要返回不需要的行、列
20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资源超出限制时，服务器自动取消查询,在查询之前就扼杀掉。 SET LOCKTIME设置锁的时间
21、用select top 100 / 10 Percent 来限制用户返回的行数或者SET ROWCOUNT来限制操作的行
22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因为他们不走索引全是表扫描。也不要在Where字句中的列名加函数，如Convert，substring等,如果必须用函数的时候，创建计算列再创建索引来替代.还可以变通写法：Where SUBSTRING(firstname,1,1) = 'm'改为Where firstname like 'm%'(索引扫描)，一定要将函数和列名分开。并且索引不能建得太多和太大。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能优化她，而"<>"等还是不能优化，用不到索引。
23、使用Query Analyzer，查看SQL语句的查询计划和评估分析是否是优化的SQL。一般的20%的代码占据了80%的资源，我们优化的重点是这些慢的地方。
24、如果使用了IN或者OR等时发现查询没有走索引，使用显示申明指定索引： Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男'，'女')
25、将需要查询的结果预先计算好放在表中，查询的时候再Select。这在SQL7.0以前是最重要的手段。例如医院的住院 费计算。
26、MIN() 和 MAX()能使用到合适的索引。
27、数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为Rules,Triggers, Constraint(约束如外健主健CheckUNIQUE……,数据类型的最大长度等等都是约束),Procedure.这样不仅维护工作小，编写程序质量高，并且执行的速度快。
28、如果要插入大的二进制值到Image列，使用存储过程，千万不要用内嵌Insert来插入(不知JAVA是否)。因为这样应用程序首先将二进制值转换成字符串(尺寸是它的两倍)，服务器受到字符后又将他转换成二进制值.存储过程就没有这些动作: 方法：Create procedure p_insert as insert into table(Fimage) values (@image), 在前台调用这个存储过程传入二进制参数，这样处理速度明显改善。
29、Between在某些时候比IN 速度更快,Between能够更快地根据索引找到范围。用查询优化 器可见到差别。 select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一样的。由于in会在比较多次，所以有时会慢些。30、在必要是对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。他的创建同是实际表一样。
31、不要建没有作用的事物例如产生报表时，浪费资源。只有在必要使用事物时使用它。32、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引，用UNION all执行的效率更高.多个OR的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。
33、尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.为了加快视图的查询，MsSQL增加了视图索引的功能。
34、没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION 和UNION ALL一样的道理。
select top 20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescrīption FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345',
'JCNAD00333138','JCNAD00303570','JCNAD00303569',
'JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933',
'JCNAD00254567','JCNAD00254585','JCNAD00254608',
'JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618',
'JCNAD00279196','JCNAD00268613') order by postdate desc
35、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数。
36、当用Select INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示申明语句，而不是 select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一个连接中Select * from sysobjects可以看到 Select INTO 会锁住系统表，Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它!!!这样的话如果是经常要用的临时表请使用实表，或者临时表变量。
37、一般在GROUP BY 个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By 个Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快
38、一次更新多条记录比分多次更新每次一条快,就是说批处理好
39、少用临时表，尽量用结果集和Table类性的变量来代替它,Table 类型的变量比临时表好
40、在SQL2000下，计算字段是可以索引的，需要满足的条件如下：
a、计算字段的表达是确定的
b、不能用在TEXT,Ntext，Image数据类型
c、必须配制如下选项 ANSI_NULLS = ON, ANSI_PADDINGS = ON, …….
41、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的SQL语句，是控制流语言的集合，速度当然快。反复执行的动态SQL,可以使用临时存储过程，该过程(临时表)被放在Tempdb中。以前由于SQL SERVER对复杂的数学计算不支持，所以不得不将这个工作放在其他的层上而增加网络的开销。SQL2000支持UDFs,现在支持复杂的数学计算，函数的返回值不要太大，这样的开销很大。用户自定义函数象光标一样执行的消耗大量的资源，如果返回大的结果采用存储过程
42、不要在一句话里再三的使用相同的函数，浪费资源,将结果放在变量里再调用更快
43、Select COUNT(*)的效率教低，尽量变通他的写法，而EXISTS快.同时请注意区别： select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的!!!
44、当服务器的内存够多时，配制线程数量 = 最大连接数+5，这样能发挥最大的效率;否则使用 配制线程数量<最大连接数启用SQL SERVER的线程池来解决,如果还是数量 = 最大连接数+5，严重的损害服务器的性能。
45、按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你(不经意的)某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁很难被发现
46、通过SQL Server Performance Monitor监视相应硬件的负载 Memory: Page Faults / sec计数器如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。
Process:
1、% DPC Time 指在范例间隔期间处理器用在缓延程序调用(DPC)接收和提供服务的百分比。(DPC 正在运行的为比标准间隔优先权低的间隔)。 由于 DPC 是以特权模式执行的，DPC 时间的百分比为特权时间百分比的一部分。这些时间单独计算并且不属于间隔计算总数的一部 分。这个总数显示了作为实例时间百分比的平均忙时。
2、%Processor Time计数器 如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
3、% Privileged Time 指非闲置处理器时间用于特权模式的百分比。(特权模式是为操作系统组件和操纵硬件驱动程序而设计的一种处理模式。它允许直接访问硬件和所有内存。另一种模式为用户模式，它是一种为应用程序、环境分系统和整数分系统设计的一种有限处理模式。操作系统将应用程序线程转换成特权模式以访问操作系统服务)。特权时间的 % 包括为间断和 DPC 提供服务的时间。特权时间比率高可能是由于失败设备产生的大数量的间隔而引起的。这个计数器将平均忙时作为样本时间的一部分显示。
4、% User Time表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 Physical Disk: Curretn Disk Queue Length计数器该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。 SQLServer:Cache Hit Ratio计数器该值越高越好。如果持续低于80%，应考虑增加内存。 注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。
47、分析select emp_name form employee where salary > 3000 在此语句中若salary是Float类型的，则优化器对其进行优化为Convert(float,3000)，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。同样字符和整型数据的转换。 48、查询的关联同写的顺序
select a.personMemberID, * from chineseresume a,personmember b where personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' （A = B ,B = '号码'）
select a.personMemberID, * from chineseresume a,personmember b where a.personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' and b.referenceid = 'JCNPRH39681' （A = B ,B = '号码'， A = '号码'）
select a.personMemberID, * from chineseresume a,personmember b where b.referenceid = 'JCNPRH39681' and a.personMemberID = 'JCNPRH39681' （B = '号码'， A = '号码'）
49、
(1)IF 没有输入负责人代码 THEN code1=0 code2=9999 ELSE code1=code2=负责人代码 END IF 执行SQL语句为: Select 负责人名 FROM P2000 Where 负责人代码>=:code1 AND负责人代码 <=:code2
(2)IF 没有输入负责人代码 THEN Select 负责人名 FROM P2000 ELSE code= 负责人代码 Select 负责人代码 FROM P2000 Where 负责人代码=:code END IF 第一种方法只用了一条SQL语句,第二种方法用了两条SQL语句。在没有输入负责人代码时,第二种方法显然比第一种方法执行效率高,因为它没有限制条件; 在输入了负责人代码时,第二种方法仍然比第一种方法效率高,不仅是少了一个限制条件,还因相等运算是最快的查询运算。我们写程序不要怕麻烦
50、关于JOBCN现在查询分页的新方法(如下)，用性能优化器分析性能的瓶颈，如果在I/O或者网络的速度上，如下的方法优化切实有效，如果在CPU或者内存上，用现在的方法更好。请区分如下的方法，说明索引越小越好。
begin
DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
insert into @local_variable (ReferenceID)
select top 100000 ReferenceID from chineseresume order by ReferenceID
select * from @local_variable where Fid > 40 and fid <= 60
end 和
begin
DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
insert into @local_variable (ReferenceID)
select top 100000 ReferenceID from chineseresume order by updatedate
select * from @local_variable where Fid > 40 and fid <= 60
end 的不同
begin
create table #temp (FID int identity(1,1),ReferenceID varchar(20))
insert into #temp (ReferenceID)
select top 100000 ReferenceID from chineseresume order by updatedate
select * from #temp where Fid > 40 and fid <= 60 drop table #temp
end
另附：存储过程编写经验和优化措施 From：网页教学网
一、适合读者对象：数据库开发程序员，数据库的数据量很多，涉及到对SP(存储过程)的优化的项目开发人员，对数据库有浓厚兴趣的人。
二、介绍：在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。
三、内容：
1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。
2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。 3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点：
a)SQL的使用规范：
i. 尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。
ii. 尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。
iii. 尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写;如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。
iv. 注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。
v. 不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
vi. 尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。
vii. 尽量使用“>=”，不要使用“>”。
viii. 注意一些or子句和union子句之间的替换
ix. 注意表之间连接的数据类型，避免不同类型数据之间的连接。
x. 注意存储过程中参数和数据类型的关系。
xi. 注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过200个数据页面(400k)，那么系统将会进行锁升级，页级锁会升级成表级锁。
b)索引的使用规范：
i. 索引的创建要与应用结合考虑，建议大的OLTP表不要超过6个索引。
ii. 尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引
iii. 避免对大表查询时进行table scan，必要时考虑新建索引。
iv. 在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。
v. 要注意索引的维护，周期性重建索引，重新编译存储过程。
c)tempdb的使用规范：
i. 尽量避免使用distinct、order by、group by、having、join、cumpute，因为这些语句会加重tempdb的负担。
ii. 避免频繁创建和删除临时表，减少系统表资源的消耗。
iii. 在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度;如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。
iv. 如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。
v. 如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。
vi. 慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。
d)合理的算法使用：
根据上面已提到的SQL优化技术和ASE Tuning手册中的SQL优化内容,结合实际应用,采用多种算法进行比较,以获得消耗资源最少、效率最高的方法。具体可用ASE调优命令：set statistics io on, set statistics time on , set showplan on 等。 -
通用SQL数据库查询语句精华使用简介
jfioe 发布于 2007-01-30 18:52:05
通用SQL数据库查询语句精华使用简介
一、 简单查询
简单的Transact-SQL查询只包括选择列表、FROM子句和WHERE子句。它们分别说明所查询列、查询的表或视图、以及搜索 条件等。
例如，下面的语句查询testtable表中姓名为“张三”的nickname字段和email字段。
SELECT nickname,email
FROM testtable
WHERE name='张三'
(一) 选择列表
选择列表(select_list)指出所查询列，它可以是一组列名列表、星号、表达式、变量 (包括局部变量和全局变量)等构成。
1、选择所有列
例如，下面语句显示testtable表中所有列的数据：
SELECT *
FROM testtable
2、选择部分列并指定它们的显示次序
查询结果集合 中数据的排列顺序与选择列表中所指定的列名排列顺序相同。
例如：
SELECT nickname,email
FROM testtable
3、更改列标题
在选择列表中，可重新指定列标题。定义格式为：
列标题=列名
列名 列标题
如果指定的列标题不是标准的标识符格式时，应使用引号定界符 ，例如，下列语句使用汉字显示列标题：
SELECT 昵称=nickname,电子邮件=email
FROM testtable
4、删除重复行
SELECT语句中使用ALL或DISTINCT选项来显示表中符合条件的所有行或删除其中重复的数据行，默认为ALL。使用DISTINCT选项时，对于所有重复的数据行在SELECT返回的结果集合中只保留一行。
5、限制返回的行数
使用TOP n [PERCENT]选项限制返回的数据行数，TOP n说明返回n行，而TOP n PERCENT时，说明n是表示一百分数，指定返回的行数等于总行数的百分之几。
例如：
SELECT TOP 2 *FROM testtable SELECT TOP 20 PERCENT * FROM testtable
(二)FROM子句
FROM子句指定SELECT语句查询及与查询相关的表或视图。在FROM子句中最多可指定256个表或视图，它们之间用逗号 分隔。
在FROM子句同时指定多个表或视图时，如果选择列表中存在同名列，这时应使用对象名限定这些列所属的表或视图。例如在usertable和citytable表中同时存在cityid列，在查询两个表中的cityid时应使用下面语句格式加以限定：
SELECT username,citytable.cityid
FROM usertable,citytable
WHERE usertable.cityid=citytable.cityid
在FROM子句中可用以下两种格式为表或视图指定别名 ：
表名 as 别名
表名 别名
(二) FROM子句
FROM子句指定SELECT语句查询及与查询相关的表或视图。在FROM子句中最多可指定256个表或视图，它们之间用逗号分隔。
在FROM子句同时指定多个表或视图时，如果选择列表中存在同名列，这时应使用对象名限定这些列所属的表或视图。例如在usertable和citytable表中同时存在cityid列，在查询两个表中的cityid时应使用下面语句格式加以限定：
SELECT username,citytable.cityid
FROM usertable,citytable
WHERE usertable.cityid=citytable.cityid
在FROM子句中可用以下两种格式为表或视图指定别名：
表名 as 别名
表名 别名
例如上面语句可用表的别名格式表示为：
SELECT username,b.cityid
FROM usertable a,citytable b
WHERE a.cityid=b.cityid
SELECT不仅能从表或视图中检索数据，它还能够从其它查询语句所返回的结果集合中查询数据。
例如：
SELECT a.au_fname+a.au_lname
FROM authors a,titleauthor ta
(SELECT title_id,title
FROM titles
WHERE ytd_sales>10000
) AS t
WHERE a.au_id=ta.au_id
AND ta.title_id=t.title_id
此例中，将SELECT返回的结果集合给予一别名t，然后再从中检索数据。
(三) 使用WHERE子句设置查询条件
WHERE子句设置查询条件，过滤掉不需要的数据行。例如下面语句查询年龄大于20的数据：
SELECT *
FROM usertable
WHERE age>20
WHERE子句可包括各种条件运算符 ：
比较运算符(大小比较)：>、>=、=、<、<=、<>、!>、!<
范围运算符(表达式值是否在指定的范围)：BETWEEN…AND…
NOT BETWEEN…AND…
列表运算符(判断表达式是否为列表中的指定项)：IN (项1,项2……)
NOT IN (项1,项2……)
模式匹配符(判断值是否与指定的字符通配格式相符):LIKE、NOT LIKE
空值判断符(判断表达式是否为空)：IS NULL、NOT IS NULL
逻辑运算符(用于多条件的逻辑连接)：NOT、AND、OR
1、范围运算符例：age BETWEEN 10 AND 30相当于age>=10 AND age<=30
2、列表运算符例：country IN ('Germany','China')
3、模式匹配符例：常用于模糊查找，它判断列值是否与指定的字符串格式相匹配。可用于char、varchar、text、ntext、datetime和smalldatetime等类型查询。
可使用以下通配字符：
百分号%：可匹配任意类型和长度的字符，如果是中文，请使用两个百分号即%%。
下划线_：匹配单个任意字符，它常用来限制表达式的字符长度。
方括号[]：指定一个字符、字符串或范围，要求所匹配对象为它们中的任一个。[^]：其取值也[] 相同，但它要求所匹配对象为指定字符以外的任一个字符。
例如：
限制以Publishing结尾，使用LIKE '%Publishing'
限制以A开头：LIKE '[A]%'
限制以A开头外：LIKE '[^A]%'
4、空值判断符例WHERE age IS NULL
5、逻辑运算符：优先级为NOT、AND、OR
(四)查询结果排序
使用ORDER BY子句对查询返回的结果按一列或多列排序。ORDER BY子句的语法格式为：
ORDER BY {column_name [ASC|DESC]} [,…n]
其中ASC表示升序，为默认值，DESC为降序。ORDER BY不能按ntext、text和image数据类型进行排序。
例如：
SELECT *
FROM usertable
ORDER BY age desc,userid ASC
另外，可以根据表达式进行排序。
正文] 买电脑，打800-858-0410 国内最低价，还有优惠 上一页 1 2 3
二、 联合查询
UNION运算符可以将两个或两个以上上SELECT语句的查询结果集合合并成一个结果集合显示，即执行联合查询。UNION的语法格式为：
select_statement
UNION [ALL] selectstatement
[UNION [ALL] selectstatement][…n]
其中selectstatement为待联合的SELECT查询语句。
ALL选项表示将所有行合并到结果集合中。不指定该项时，被联合查询结果集合中的重复行将只保留一行。
联合查询时，查询结果的列标题为第一个查询语句的列标题。因此，要定义列标题必须在第一个查询语句中定义。要对联合查询结果排序时，也必须使用第一查询语句中的列名、列标题或者列序号。
在使用UNION 运算符时，应保证每个联合查询语句的选择列表中有相同数量的表达式，并且每个查询选择表达式应具有相同的数据类型，或是可以自动将它们转换为相同的数据类型。在自动转换时，对于数值类型，系统将低精度的数据类型转换为高精度的数据类型。
在包括多个查询的UNION语句中，其执行顺序是自左至右，使用括号可以改变这一执行顺序。例如：
查询1 UNION (查询2 UNION 查询3)
三、连接查询
通过连接运算符可以实现多个表查询。连接是关系数据库模型的主要特点，也是它区别于其它类型数据库管理系统的一个标志。
在关系数据库管理系统中，表建立时各数据之间的关系不必确定，常把一个实体的所有信息存放在一个表中。当检索数据时，通过连接操作查询出存放在多个表中的不同实体的信息。连接操作给用户带来很大的灵活性，他们可以在任何时候增加新的数据类型。为不同实体创建新的表，尔后通过连接进行查询。
连接可以在SELECT 语句的FROM子句或WHERE子句中建立，似是而非在FROM子句中指出连接时有助于将连接操作与WHERE子句中的搜索条件区分开来。所以，在Transact-SQL中推荐使用这种方法。
SQL-92标准所定义的FROM子句的连接语法格式为：
FROM join_table join_type join_table
[ON (join_condition)]
其中join_table指出参与连接操作的表名，连接可以对同一个表操作，也可以对多表操作，对同一个表操作的连接又称做自连接。
join_type 指出连接类型，可分为三种：内连接、外连接和交叉连接。内连接(INNER JOIN)使用比较运算符进行表间某(些)列数据的比较操作，并列出这些表中与连接条件相匹配的数据行。根据所使用的比较方式不同，内连接又分为等值连接、自然连接和不等连接三种。外连接分为左外连接(LEFT OUTER JOIN或LEFT JOIN)、右外连接(RIGHT OUTER JOIN或RIGHT JOIN)和全外连接(FULL OUTER JOIN或FULL JOIN)三种。与内连接不同的是，外连接不只列出与连接条件相匹配的行，而是列出左表(左外连接时)、右表(右外连接时)或两个表(全外连接时)中所有符合搜索条件的数据行。
交叉连接(CROSS JOIN)没有WHERE 子句，它返回连接表中所有数据行的笛卡尔积，其结果集合中的数据行数等于第一个表中符合查询条件的数据行数乘以第二个表中符合查询条件的数据行数。
连接操作中的ON (join_condition) 子句指出连接条件，它由被连接表中的列和比较运算符、逻辑运算符等构成。
无论哪种连接都不能对text、ntext和image数据类型列进行直接连接，但可以对这三种列进行间接连接。例如：
SELECT p1.pub_id,p2.pub_id,p1.pr_info
FROM pub_info AS p1 INNER JOIN pub_info AS p2
ON DATALENGTH(p1.pr_info)=DATALENGTH(p2.pr_info)
(一)内连接
内连接查询操作列出与连接条件匹配的数据行，它使用比较运算符比较被连接列的列值。内连接分三种：
1、等值连接：在连接条件中使用等于号(=)运算符比较被连接列的列值，其查询结果中列出被连接表中的所有列，包括其中的重复列。
2、不等连接： 在连接条件使用除等于运算符以外的其它比较运算符比较被连接的列的列值。这些运算符包括>、>=、<=、<、!>、!<和<>。
3、自然连接：在连接条件中使用等于(=)运算符比较被连接列的列值，但它使用选择列表指出查询结果集合中所包括的列，并删除连接表中的重复列。
例，下面使用等值连接列出authors和publishers表中位于同一城市的作者和出版社：
SELECT *
FROM authors AS a INNER JOIN publishers AS p
ON a.city=p.city
又如使用自然连接，在选择列表中删除authors 和publishers 表中重复列(city和state)：
SELECT a.*,p.pub_id,p.pub_name,p.country
FROM authors AS a INNER JOIN publishers AS p
ON a.city=p.city
(二)外连接
内连接时，返回查询结果集合中的仅是符合查询条件( WHERE 搜索条件或 HAVING 条件)和连接条件的行。而采用外连接时，它返回到查询结果集合中的不仅包含符合连接条件的行，而且还包括左表(左外连接时)、右表(右外连接时)或两个边接表(全外连接)中的所有数据行。如下面使用左外连接将论坛内容和作者信息连接起来：
SELECT a.*,b.* FROM luntan LEFT JOIN usertable as b
ON a.username=b.username
下面使用全外连接将city表中的所有作者以及user表中的所有作者，以及他们所在的城市：
SELECT a.*,b.*
FROM city as a FULL OUTER JOIN user as b
ON a.username=b.username
(三)交叉连接
交叉连接不带WHERE 子句，它返回被连接的两个表所有数据行的笛卡尔积，返回到结果集合中的数据行数等于第一个表中符合查询条件的数据行数乘以第二个表中符合查询条件的数据行数。例，titles表中有6类图书，而publishers表中有8家出版社，则下列交叉连接检索到的记录数将等
于6*8=48行。
SELECT type,pub_name
FROM titles CROSS JOIN publishers
ORDER BY type -
web 测试技巧
alextowxm 发布于 2008-12-30 16:14:20
测试人员容易遗漏一些隐藏的缺陷
通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。但是，在系统测试和确认测试中，测试人员容易遗漏一些隐藏的缺陷。众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括：
1、安装缺陷
通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失;使用绝对路径;安装顺序没有说明书。
2、配置文件
有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的!这是一个安全隐患。另外，有些安装文件的 XML 文件，为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。所以，配置文件可能成为软件安全方面的一个缺陷。
3、网页安全缺陷
现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE 窗口输入，可以绕过登陆直接访问。也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。
网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。
4、判断顺序/逻辑缺陷
对界面进行多个输入判断的时候，非常容易出现这种问题。例如判断年月顺序，判断长度，判断非空等。假如操作员仅仅满足单个条件，保存不能成功;而按界面从上之下顺序一一满足条件之后，保存是没有问题的。但是，改变一下输入的次序，校验失效。例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看看代码是否强健，是否在判断逻辑上没有错误。良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。
5、调试语句和冗余信息
维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为系统发生了严重故障，从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用，其结果可想而知;而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。
同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。
6、不可重现的故障
新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗?回答是肯定的。测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。
7、多节点的逆向流转缺陷
当前软件不少喜欢使用工作流来驱动。工作流的问题，就是可能出现多个流向分支。测试容易忽略的部分，就是工作流多节点的逆向流转。例如，通过不通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外，有些时候默认分支在向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。
8、输入框缺陷
试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候，输入框会根据长度大小自动截断输入长度。但是用鼠标，截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了，保存的时候，数据库崩溃。有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。
输入框可以说是问题最多的部分，能够引起的麻烦也很多。日期、数字、文本等等，都需要耐心的测试一下。
9、界面布局缺陷
曾经有一次，项目经理回来向测试部反映一个问题，客户对界面不满意。原因很简单，因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员，很容易误按。这个问题是测试人员没有意料到的，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。
界面布局还可能发生在窗口最大化和最小化上，有可能窗口缩小的时候没有下拉框或不匹配分辨率，对用户来讲，这个错误实在很低级。有些用户由于操作习惯，非常不喜欢腾出手使用鼠标，尤其是大量输入的界面，因此，要注意设置键盘的快捷方式。还有，按 Tab定位到下一焦点时要注意顺序，避免跳转太灵活而让操作人员感到无从适应，在界面进行维护或者修改的时候，不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。
10、版本和补丁包的环境问题
理论上讲，这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包，问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例，多用不同软件版本的机器跑一跑。软件测试有个定律是：你没跑过的地方，就一定会出事。经常听到开发人员抱怨，怎么我的机器没问题，你的机器就有事了呢?这不能完全靠配置管理员解决问题，环境配置项是大家最容易忽略的。
11、用户管理缺陷
用户管理的角色和授权需要好好研究一下，作过测试的人员都知道，有时候为了测试的方便，测试用户都是具有超级权限的用户。而且，比较容易忽略用户管理这一部分的测试。往往发往客户的时候，很多测试用户都没有删除。
另外，有些接口的用户和口令，到软件使用寿命结束都没有更改过。在一次测试中，软件测试人员发现，给一个用户授超级用户权限，之后更改这个用户为受限权限。使用中发现，用户居然没有真正回收权限，用户管理界面上没有任何不对。及早准备用户管理用例，不要等到测试快结束时候才想起。
12、常识缺陷
从逻辑或者统计学上讲，计算机是允许如此处理的，但是从常识上来讲，这些情况不可能发生。例如电话号码不可能出现小数点，终止时间不能大于开始时间等等。除此之外，常识还要结合业务特点来进行判断，因此，开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现，对用户来说，这些错误可能是很荒谬的。
尽管我们不可能完美的测试一个软件，但是我们仍然可以改进我们的软件测试。每次测试结束，及时总结测试中的不足，进一步完善用例。思考一下那些容易忽略的软件缺陷，能提高对软件测试的认识，提高所在组织软件的质量。
十大负面测试用例
2008-07-09 作者：朱少民 来源：网络
负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说，正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点，正面测试就象一个毕恭毕敬的小学生，老师叫我做什么，我就做什么;而负面测试就象一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类bug的。
正面测试主要根据需求，功能说明书，设计文档等相关参考文档来执行测试，而负面测试则主要根据错误猜测，逆向思维来测试系统，一定程序上的的依赖测试人员的经验积累。
执行负面测试时，不单单要测试系统是否处理了用户的异常操作，还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。
简言之负面测试的三部曲就是：
1、检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束;
2、测试系统是否处理了用户的异常操作;
3、检查系统的错误提示是否清晰且充分。
以下是Steve Miller的《Top 10 Negative Test Cases》，概括性的提到了一些做负面测试时经常需要注意的测试。
负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的十大负面测试用例。
1、植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题，例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。
【补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格(单纯的空格和文本前后的空格)。单引号，逗号，/，<，>(对于web的应用程序)都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符，然后在处理用户的输入时套用这个函数就可以避免此类错误了。
2、必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。
【补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。
3、字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求(日期字段，数字字段，电话号码，邮编等等)的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据(数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等)
【补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)还有不符合内容要求的数据输入时系统是否正确的处理。
4、字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数(例如，first name必须是50个或更少的字符)。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。
【补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法(设置字段的长度)来处理。所以测试时需要测试限制的长度是否合理(和功能说明书或其他参考文档相一致)，对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。
5、数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围(如从10～50)，你就应该尝试输入9或51，它应该给出一个得体的信息表示失败。
6、数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,767~32,767，长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。
【补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。
不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。
7、日期边界测试。对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。
【补充】一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。
8、日期的有效性。对于日期字段，确保不允许无效的日期是很重要的(04/31/2007是一个无效的日期)。测试用例也应该检查闰年(每个第4年和第400年是一个闰年)。
9、web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。
10、性能的改变。当发布产品的最新版本时，应该有一套运行于识别屏幕(列出信息的屏幕，add/update/delete数据的屏幕等等)速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。
【补充】从第一条到第八条是我们在测试字段时常常需要做的测试，一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中，一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里，很少去做这样的比较，除了一些有针对性的性能测试。
-
Web 测试的经验
xiaoningln 发布于 2007-01-26 13:52:21
Web 测试的经验
作者：jeRRy.Lee
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 的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。 -
老徐最新总结的“项目级自动化测试流程”
cloudxu 发布于 2007-03-04 00:00:06
-
产品开发初期测试人员应该做什么？(转）
xlewy 发布于 2008-04-14 22:40:01
产品开发初期需要测试人员吗？如果需要，他们要作哪些工作？这些问题曾经被很多朋友问起。据我个人了解，很多国内中小型公司是不注重产品开发初期乃至整个开发过程中的测试工作的。例证一：有些公司认为在设计初期投入测试人员是代价高昂且无意义的，所以他们会要求产品开发的第一个周期结束后，开始设计测试用例。例证二：认为测试工程师不需要参与到制定需求中，他们只要接受就可以了。于是乎，就出现了市场部门和开发部门直接沟通项目需求，测试经理直接参考需求设计文档的状况。例证三：测试经理确实在产品开发初期参与项目需求的制定，并写出测试计划。但产品质量却是现场部署的工程师说了算。到了现场，发现这里不合用户的意，那里运行不过。为了赶时间，只好坐在用户现场直接调试。改代码的改代码，调试的调试，哪里还管着产品是否需要全面的测试，只要能运行起来，用户能用，就是胜利……
权且不说这些管理行为是否更加浪费工钱，我们应该很容易得到关于“产品开发初期测试人员该做些什么”的一致答复：测试计划在开发初期能写挺好，不写也没什么问题。测试一定要做的。但把怎样的产品交给用户是不确定的。目标就有一个，让用户用上再说——无论是对一个已经经营多年的产品，还是一个刚起步的公司……
其实，对测试的理解不是点头说，测试很重要就够了； 对测试的理解不是去声称，我们有一柜子完整的测试文档；对测试的理解也不是只关心“做与不做”，而全然不理测试的有效性。
软件测试该如何理解如何执行，是一个很大的题目。在这里，我更关心的是在项目设计初期，我们该不该忽略测试人员，而测试人员又该做些什么样的工作。
微软最新的软件开发周期（product life cycle）分为产品定义（Product Definition），产品开发（Product Development），产品服务（Product Servicing）三个阶段。为了使资源得到最有效的使用，测试人员主要参与产品开发和后期服务这两个阶段。而在产品的定义阶段，则会有选择的要求一些资深测试工程师和测试经理一起参与。他们主要负责：通过验证产品核心功能或用户使用场景，确定产品各功能的优先级；参加产品使用场景定义的评审；参加用户体验文档的评审等。
当然每个公司应该定义适合自己的开发模式。但是是否让测试工程师参与这些工作的主要目标应该是没有区别的：首先是熟悉客户需求；再来测试工程师应凭借自身经验，从测试和维护的角度来判断被细分的客户需求中，哪些是合理的，哪些是不合理的，并反馈给项目经理或市场部门，以供他们参考；最后，则要根据这些项目需求以及软件架构的文档，给出测试计划。
上面这番描述是不是看上去并不很复杂，也不重要呢？非要在项目初期做吗？最终不都是根据需求文档来写测试计划嘛……
这当然是很重要的环节。理由如下：
1． 产品的可测性严重影响了后期测试团队的工作效率以及测试的有效性。越早提出此类相关问题，越可能进入开发工程师设计范围。同时，该项指标可为项目经理提供一个与“开发难度”并列的“测试难度”——这将会影响到项目负责人对开发周期的设计。
2． 除项目经理外，测试工程师是最需要了解用户需求以及用户使用体验的角色。参与这些由产品经理，项目经理编写的文档评审，会让测试工程师们得到除了列在文档上的核心需求外更多的信息——我们必须承认，因为人的因素，文档是不可能涵盖所有信息——这将会帮助工程师们以更快的速度对产品需求有更深层次的理解。
3． 使得测试经理能够更早做出“是否需要提前编写测试工具或搭建测试平台”的决定。而这是很重要的一点。测试在开发流程中，因其所处位置，很容易因为开发团队中的突发事件导致周期被压缩。而自动化测试工具虽然可以节省人力，但相比于手工测试，开发周期较长，见效较晚。通常一个工具从开发到可以用于测试需要一周到数月不等——完全取决于工具的规模。因此，尽快确定“是否需要编写测试工具”是必要的。它可以帮助测试团队“抢回”更多的时间用于设计和调试测试工具，从而达到更好的测试效果。甚至可以避免掉因为时间不够，而拒绝采用自动化工具转为手工测试的被动局面。
理由其实还可以列出很多。但是，我觉得这几点应是最为主要的。它们能足够说明为什么测试人员需要参与产品开发初期的工作以及他们需要做些什么的问题。这里再重复一下，在开发初期测试工程师需要：确定产品的可测性，了解用户需求，确定需要引入何种测试工具或平台。
所以，在开发初期做好测试计划并不是可有可无的；用户需求不是只要工程师“买单”就可以的；不理会测试团队而埋头开发的产品，将会是一场“噩梦”，特别是当产品发布/部署的时候。
但每个公司每个项目组不需要套用一样的模式。针对不同的需求，我们应该量体裁衣，做不同的剪裁。只是核心不该有变化，目标不该有变化。就如同国内一些公司对CMM的追宠——光有形，没有神，是实在不可取的。
-
软件测试基本功之----测试用例篇[转]
andycai 发布于 2007-12-13 10:49:39
软件测试基本功之----测试用例篇
随着软件行业的快速发展，大家对软件的质量也越来越看重，关注。软件测试做为能尽可能发现软件中的BUG，减少软件成本，也在不断的高速发展，受人们关注，重视的程度也越来越大。从最初的程序员自己测试到后面独立的测试部门，测试职位的设立。以及软件测试的一整套方案，流程等。
一，测试用例的重要性
什么是测试用例？测试用例有什么作用？
测试用例：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例的作用：
1，通过一个用例来证明被测软件的某功能符合需求说明书中规定的要求，可以通过设计正反两方面的测试用例来验证
2，可以保证一个软件被测试的有效性，使测试人员知道那些功能以被测，那些功能还需要测试，从而避免漏测，重复测，提高测试效率
3，指导测试的工作，保证测试是有计划的实施，而不是随意性的测试
4，为公司留下财富，为后期软件维护提高帮助，为公司新人进来提供指导，在测试的时候可以尽量把人为因素的影响减少到最小。保障软件测试质量的稳定
5，可以做为评估测试结果的，为编写测试报告提供依据。
6，分析缺陷的标准，通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
二，测试用例的设计：
测试用例设计这部分主要是根据我自身的经验来写，可能很多不足的地方，请大家指出。（这里写的测试用例都以黑盒测试为准，不设计到白盒测试）
1，设计测试用例的模板：
我想，每个公司都应该有一套适合自己公司的测试用例模板。还是那句话，最好的并不是最适合自己的，适合自己的才是最好的。测试用例模板可以分为两部分：
1）介绍部分：可以有这些：公司名称，保密等级，编写人员，日期，审核人，版本号，测试对象的介绍，测试的范围和目的，测试环境，定义术语，参考文档，用例执行情况，测试用例设计思路等
2）测试用例部分：模块名称，测试类型，用例ID，用例目的，重要程度，测试过程分为（前提条件，测试步骤，期望结果，测试结果，测试结论）测试日期，备注。
现在打部分公司用来编写测试用例的软件应该都是EXECL和WORD（那个叫微软NB撒），感觉上，在进行模块测试和系统测试设计用例的时，用EXECL来编写比较好，方便统计，查找测试通过的，没通过的用例，EXECL统计功能很强大。但是对于验收测试用例和性能测试用例，使用WORD会好点，因为验收测试用例和性能测试用例，一般都是一个用例一页，方便打印，而进行验收测试的时候，必须要把验收测试用例打印出给客户，而且验收测试用例一般都没系统测试那边多，一般是一个功能就是一个用例。(下面有2种测试用例的模板)
2，测试用例设计的一些思路：
按照书上说的可以分为几大类：
1）等价类划分
2）边界值分析
3）错误推测
4）因果图
我认为测试用例的设计应该从深度和广度方面去想，即要考虑到被测模块所有功能，还要考虑他们的组合，以及和其它模块的组合。不单单要考虑正常情况下功能，还要考虑异常情况下软件的反应，不要仅只考虑一种测试环境下的情况，还要考虑多种环境下的情况，因为用户的环境是千变万化，不是能全部模拟出来的，只能尽可能的模拟，下面是我以前测试的一个模块：
禁用USB外接设备：
主要功能是：除了USB键盘和鼠标外，其它一切外接USB设备都不能使用。
（不知道大家能想到一些什么情况来设计测试用例），下面是我设计的一些思路：
1）正常情况下运行该功能后，看USB键盘和鼠标能否使用
2）正常情况下运行该功能后，USB键盘和鼠标拔插后能否使用
3）正常情况下运行该功能后，USB键盘和鼠标拔掉，接上外接USB设备，能否正常使用
4）正常情况下运行该功能后，USB键盘和鼠标拔掉，接上外接USB设备，插上 USB键盘和鼠标，USB键盘和鼠标能否使用，外接USB设备能否使用
5）正常情况下运行该功能后，接上外接USB设备（USB键盘和鼠标一直存在），外接设备能否使用
6）重复拔出外接USB设备，看USB设备能否使用，USB键盘和鼠标是否会影响
7）先插外接USB设备（能正常运行），再运行该功能，USB设备是否立即不能被使用
8）外接USB设备正在拷贝文件，运行该功能后，是什么反应
异常情况下该功能的反应，如运行该功能后，电脑重启，电脑死机等会导致什么后果，是否是我们期望的。
多个USB接口情况下，该功能是否正常
对于不同USB设备是否该功能都有效果：如USB的U盘，移动硬盘，MP3，USB打印机等。
该功能运行后，是否能还原。还原功能是否正常。等，上面这些，大家也应该想的到，下面这些大家是否会考虑：
1）大家都知道禁止某设备运行后，在设备管理器会显示？号或者红叉，大家会不会设计手动从设备管理器去启动被禁止的外接USB设备的用例？
2）有的USB设备需要驱动才能运行，如USB接口打印机，是否会设计驱动卸载，重新安装后的用例？
3）现在也有那种USB转换器，比如把PS/2接口转换为USB接口，那外接USB能否使用？把USB接口转换为PS/2接口，PS/2接口的设备能否使用？
4）不同操作系统下，该功能是否有效，如LINUX,UNIX,WINDOWSXP,2000,2003等。
上面这些可能可能很难想到的地方，所有设计测试用例也并不是一件容易的事，需要发散性的思维，需要大量的经验。现在看到很多人有点本末倒置了，都去追求工具自动化，其实当你设计出一个完美的用例后，测试出的效果绝对是巨大的，要不怎么会说一个好的测试用例是发现从为发现的错误呢？基本功还是需要.
上面的那些情况只 是一部分，还可以设计出很多来，大家可以一起讨论下。
三，测试用例的一些技巧：
在软件测试中，有很多被测试的软件都是C/S结构的，而软件的界面估计是从头到尾都在改变中，这都测试用例的编写，维护是一件耗时，耗力的事。下面是我个人的一些经验：
1，界面测试用例和功能方面测试用例分开写，比如在一份EXECL测试用例中，界面的就单单写界面的，如写字体，排版，快捷键等，功能就只写逻辑方面，实现方面，这样当界面修改后，修改也快点。
2，比如说在编写一个弹出提示框用例时，以前我写用例的时，把预期结果写成提示的消息,如：“登陆用户名错误”，而当这个提示消息变为“用户名错误”时，有要去修改用例，很烦的。后面我就写“弹出一个提示消息框”，这样就解决了
3，写用例时，尽量分清层次结构，比如用户登陆模块，写的时先写正常情况下登陆，再写异常情况下登陆，不要一下写正常情况下，有写异常情况，然后再写正常情况下，让人感觉很混乱。
4，写测试用例之前，最好在纸上画一个框架出来，按照什么顺序来写，比如是按照操作系统的分类先，还是按照正常，异常情况先来写，下面模板中的一级分类，二级分类就是这个效果 -
erp功能测试（转）
flyskypei 发布于 2007-09-19 16:06:30
ERP功能测试最佳实践：10个步骤确保ERP系统的可靠性文章出处：Mercury 作者： 发布时间：2006-06-01介绍
企业资源规划（ERP）软件应用为企业提供管理大规模关键业务功能的能力，包括产品规划、部件采购、库存维护、和供应商的互动交流、提供客户服务，以及订单跟踪等。有些ERP解决方案还可能包括一些财政和人力资源方面的应用模块。尽管这些应用通常不会直接生成效益，但是它们能让企业以一种有效的、切合实际的方式使用现有的客户数据，帮助合理化企业的业务活动，为企业新的和当前的客户提供高质量的服务。
ERP应用通常使用一个单一的、中央数据存储器来服务于所有的模块。因此，当这些应用产生了性能问题时，很有可能影响到使用同一存储器的所有业务领域。ERP和共享数据结构间的这种关系决定了它必须实施稳固的测试和监测程序才能确保企业关键应用的健康运行。
目录
介绍
步骤1：初始规划和收集需求
步骤2：定义测试目标和选择合适的测试
步骤3：定义目的，以满足测试目标
步骤4：发现功能测试案例
步骤5：文档记录关键的业务流程
步骤6：开发模块化的测试组件
步骤7：建立测试实验室
步骤8：掌握和利用“冒烟测试”
步骤9：执行回归测试
步骤10：分析缺陷和创建测试报告
Mercury QuickTest Professional
ERP应用的功能测试
更多信息
由于业务流程交易跨越企业中的多个部门和区域，并且涉及ERP应用本身的多个模块，因此测试ERP应用应该采用一种整体的方式。当验证这些业务流程的功能时，关键在于捕获自动化测试解决方案中的业务流程测试，用于实现快速的测试重复。由于ERP应用跨越多个业务领域，存在不可避免的复杂性，因此，对每个ERP应用以及每个应用发布版本展开功能测试是非常重要的。
每个ERP实施中都会面临的主要挑战之一就是确保应用在上线之前能满足所有的业务需求。关键在于测试和验证这些应用的运作情况是否符合设计要求。在数千个客户实施基础上，美科利已经编纂了一套最佳实践，来确保关键业务应用的功能。在下文中将详细描述10个关键步骤，使用这些步骤能为企业的关键ERP应用来设计和实施有效的功能测试程序。
步骤1：初始规划和收集需求
在任何一个环境中，功能测试的最重要阶段之一就是规划。对于ERP应用来说，这个步骤就更为重要了，因为其中涉及环境的复杂性以及推动这些应用实施的错综复杂的业务需求。不完善的规划可能导致失望的结果和不完整的测试覆盖面。经过深思熟虑的规划使您能避免一种“垃圾进，垃圾出（garbage in, garbage out）”的局面，使企业能衡量和最大化他们的测试工作，获取更多的投资回报（ROI）。
许多公司购买预先打包的ERP解决方案，希望能实现业务管理各个领域的快速整合。然而，这种被称之为“vanilla”的ERP打包方案必须经过客户定制，才能部署到它所要支持的业务中去。从逻辑上来说，收集需求是规划阶段的起点，因为开发人员通常根据需求来定制ERP应用；测试人员使用它来测试系统和客户定制项目；而最终用户使用它进行用户接受测试和终结测试。通过提前仔细地定义需求，测试人员可以规划和管理那些更加注重业务需要的测试。接着，需求可以同测试和实际测试结果（被识别的缺陷）相结合，以全面覆盖所有的功能测试。
步骤2：定义测试目的和选择合适的测试
测试人员通过创建主要的测试目的，将决定所需的特定测试类型。 测试目的、项目计划和团队结构也将从这些测试目标中形成。当功能测试一个ERP实施时，有多种不同的验证测试需要执行：
l 数据映射：由于许多ERP实施和后端大机系统紧密地集成在一起，因此测试ERP应用所显示的数据和在大机系统中被发现的数据之间的数据映射是十分关键的。很可能在大机系统中隐藏着一些陈旧的或无效的数据，这些数据会引起应用当中的问题。
l 业务流程测试：应该使用测试来验证各种业务流程是否正确运作。由于工作流对强化业务规则来说是非常重要的，因此测试应该覆盖整个整合系统中的所有导航项目和直接功能。应用的业务规则和启动项必须通过全面地测试，确保所有规则能被正确地执行。
l 权限控制系统：ERP权限控制系统决定了用户可以使用哪些信息，用户在这些信息中可以看到哪些数据。当涉及到供应链和合作伙伴入口时，将会增加安全方面的考虑。从用户界面的角度出发测试安全性可以确保严格执行验证规则。数据驱动的测试使IT人员能使用具有不同登录凭证的相同脚本去验证安全规则。
l 回归测试：每次部署一个“Code Drop”时，对位于这些程序的每个对象的功能进行回归测试是非常重要的。这其中包括测试它的存在、功能、值等等。“code drop”指的是任何一次新的ERP应用、补丁程序和/或hot fix的发布。
步骤3：定义目标，以满足测试目的
当完成所有的目的定义，选择好测试类型，接下去就要创建一系列的阶段目标来实现所定义的目的。一套最普通的初始阶段目标包括：
l 分析应用功能，并识别关键业务流程。在一个ERP应用中的关键业务流程实例就是“服务请求”的创建。
l 建立“冒烟测试”，在开发周期中快速执行该类测试。冒烟测试不应深入被测试应用的功能，而是应该测试关键的业务功能。例如，用户是否能够创建可以和“Trouble Ticket”相应的活动。
l 在每次正式发布形成后运行冒烟测试。
l 着手创建自动化测试来降低手动运行冒烟测试的成本。
实现了这些初始阶段目标之后，应该建立一套后续阶段目标。
l 分析应用，展开功能识别，这将扩大测试范围，涵盖超过75％的总的应用功能数量。（取得100％的脚本自动化测试是非常困难的，因为自动化测试工具无法进行如可用性测试这样的事宜。）
l 建立可持续运作的自动化测试，从而降低测试的工作量。
步骤4：区分功能测试案例
在区分测试案例时，关键要记住，重要的业务功能必须在应用中才能发挥作用。由于每个企业具有独特的业务需求，大多数企业即使完成了基本的或标准的实施，也无法上线。因为那些客户定制的区域必须经过彻底地测试才能保证上线时功能的稳定。ERP应用的主要优势之一就是能和现有的大机系统集成，来满足必要的业务需求。再者，因为这些集成不是标准（非客户定制）实施，它们必须经过严格地测试。
最初，要避免用各种不同的方法去测试相同的功能。开发团队经常会强调一个应用应具有完美架构，可以灵活地让用户通过不同的方式来完成他们的日常任务。关键在于要经常部署测试案例，确保需求驱动、user-path的覆盖面。初期测试应该具有一些共有的特性：
l 它们应该测试关键的业务功能。
l 它们应该测试应用的关键业务流程。
l 它们应该识别出经客户定制过的ERP应用的测试区域。
l 应用功能应该稳定，不在主要开发范围之内。
l 初期测试应该是冒烟测试的候选方式。
一旦初期自动化测试创建完成，并成功地运行后，测试目标通常会改变，测试包会扩张。这种扩张通常表现为在功能成熟之后，增加更多的测试到测试包中。还可以在应用问题区域，如和大机系统的界面中增加测试，从而对该区域展开持续地检查。
步骤5：文档记录关键的业务流程
当记录那些将要成为测试脚本的业务流程时，收集所有和测试案例相关的信息是非常重要的。每个测试案例需要具备一份和被测业务区域相关的目的说明。测试案例的目的应该是和满足一个需求或一系列需求有关。关键之处还在于，要文档记录下逻辑步骤，在整个系统中执行这些步骤可以实现测试的需求。由于使用测试案例可以衡量业务流程的成功与否，因此，文档中应该指出，需要验证哪些内容才能保证测试的成功。
除了为测试案例而展开的执行和验证操作外，还需要在测试案例中成功地执行适用的数据值。这种数据可以是来自数据库的主数据（master data）、或是能够凭空增加的用户创建输入数据、或者在脚本创建之前被置入数据库的准备数据。
步骤6：开发模块化的测试组件
创建模块化测试脚本是非常重要的。测试的模块化能够使开发人员创建单元测试（unit test），在整个系统完成之前，测试ERP应用模块和模块的定制项目。接着，被用于单元测试的模块测试会移交给QA测试人员，他们会将模块测试和测试包结合在一起，来满足特定的测试目标。美科利提供一款最新的功能测试解决方案（即“业务流程测试”），它能帮助企业管理与业务组件和端到端流程验证有关的所有测试案例。
步骤7：建立测试实验室
建议建立一个QA测试实验室，作为ERP应用的测试和调优整体战略的一个组成部分。在一个独立的测试实验室中运行测试的主要优势在于，机器配置可以达到一种理想的状态，因而减少了由于机器配置不完善而引起的各类问题。此外，当模块定制完成之后，开发人员和测试人员可以在新代码发布之前，使用该实验室来运行单元测试。
步骤8：掌握和利用“冒烟测试”
在大多数ERP应用中，不完善的发布浪费了大量的测试工作。通常，当开发团队完成一个发布版本后将移交给测试团队，接着展开为期数天的测试过程。而测试结果往往是软件的发布版本存在重大的和根本的问题，不值得再进行深入地测试。不幸地是，当开发人员着手为该发布版本增加新的功能时，测试团队已经浪费了几天的时间去发现其薄弱之处。
改变这种情况的捷径就是建立一种“冒烟测试”，它可以覆盖关键的业务功能。冒烟测试结合了手动测试和自动化测试，可以在短时间内被创建和运行（通常在1个小时之内）。运行冒烟测试可以为开发团队提供发布版本质量方面的快速信息反馈，帮助他们集中力量解决严重阻滞的问题，而不是一些新的特性。冒烟测试所利用的脚本可以从开发人员已经创建的单元测试中获取。
步骤9：执行回归测试
回归测试包应该覆盖关键的业务流程，应该在每个新的ERP应用版本发布时运行。回归测试不同于冒烟测试注重测试核心的业务功能，它能更加深入地测试应用的功能。正如前文所提到的，由供应商和任何定制所带来的应用更新都可能对应用功能和性能产生负面影响，必须在每次发布版本之后进行测试。
步骤10：分析缺陷和创建测试报告
ERP应用准备就绪的重要指标之一就是被识别的系统缺陷数量。在执行测试时，测试中产生的失误必须被跟踪和分析。一种稳固的功能测试解决方案应该能跟踪和汇报所有存在于业务流程中的缺陷。测试团队可以利用这类信息来衡量和管理缺陷是如何被优先级划分、修复、重复测试和关闭的。
用全面的报告来完整记录所有的测试流程和结果，这也是非常重要的一项工作，可以使测试团队能正确分析测试结果，同时在未来测试中重复使用测试案例和脚本。
美科利QuickTest Professional
Mercury QuickTest Professional™提供功能和回归测试自动化方面的业界最佳解决方案――可覆盖每个主要的软件应用和环境，包括来自Oracle、PeopleSoft、SAP和Sieble的ERP应用。这种新款的自动化测试解决方案采用一种关键词驱动测试的理念，能够完全简化测试的创建和维护。有了美科利QuickTest Professional的关键词驱动方式，测试自动化专家就能通过一种和关键词视图（Keyword View）相互同步的、集成的脚本和纠错环境，进入到基层测试和目标领域中去。
美科利QuickTest Professional同时满足了技术和非技术用户的需要。它使高质量应用部署的过程变得更为快捷和经济，同时风险也更小。它和Mercury Business Process Testing™（美科利业务流程测试）协同工作，使非技术型的对象专家（subject matter expert）也能参与到质量流程中。
美科利业务流程测试使对象专家无需任何编程知识，就能创建、数据驱动和执行测试自动化。它降低了自动化测试维护的经常性费用，将测试自动化和文档记录两个流程合并为一。它使对象专家和业务分析人员可以根据业务流程测试框架中所定义的业务概念来衡量应用实施的质量。
ERP应用的功能测试
通过使用美科利QuickTest Professional和美科利业务流程测试，QA团队可以开发和利用统一的、可重复的测试流程，更快、更经济和更便捷地对ERP应用就绪情况提前作出决策。当初期功能测试计划完成之后，测试团队可以使用美科利解决方案来自动验证ERP应用中所有业务交易的完整性。美科利解决方案从业务流程的角度出发，展开ERP应用测试。这些解决方案通过执行分步操作――如更新库存信息，或从供应商处定购某部分商品，就像在实际生产操作中一样来测试ERP应用。
当在测试创建阶段捕获了业务流程后，美科利QuickTest Professional和美科利业务流程测试将ERP业务相关信息与输入数据相互分离。测试人员可以根据选择列表，改变选择项和数据条目。使用同一数据对应用展开反复测试通常不会取得实际结果。要真实地验证应用的功能，测试人员需要不同的数据包来模拟多个用户的实际操作行为。美科利产品允许用户直接输入测试数据，或从一个数据库中导入数据，从而创建一个实际的、数据驱动的测试方案。通过这种方式，测试人员就能使用可变的输入数据，分析实际的ERP业务流程。
打包的ERP应用通常具有很高的复杂性。创建一个简单的记录定制可能会对其它记录或整体性能产生无法预料的影响。当更新发布（甚至是简单的定制更新），都需要对所有业务流程展开全面彻底地测试，而不仅仅是测试变更所发生的区域。这样，测试人员就能衡量更新会对应用产生的影响，确保不会引起缺陷的产生。
-
测试方案和测试计划的区别
breezeforever 发布于 2008-03-10 14:23:26
测试方案和测试计划的区别
一、测试计划：
对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。
二、测试方案：
描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。
三、测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。
四、测试方案是技术层面的文档，从技术的角度度一次测试活动进行规划。
五、测试计划要明确的内容：
1、明确测试组织的组织形式
○1测试组织和其他部门关系，责任划分。
○2测试组织内的机构和责任安排。
2、明确测试的测试对象（明确测试项，用于后面划分任务,估计工作量等）
3、完成测试的需求跟踪
4、明确测试中需要遵守的原则
○1测试通过/失败标准
○2测试挂起和回复的必要条件
5、明确测试工作任务分配是测试计划的核心
○1、进行测试任务划分
○2、进行测试工作量估计
○3、人员资源和物资源分配
○4、明确任务的时间和进度安排
○5、风险的估计和规避措施
○6、明确测试结束后应交付的测试工作产品
六、测试方案的具体内容：
○1、明确策略
○2、细化测试特性（形成测试子项）
○3、测试用例的规划
○4、测试环境的规划
○5、自动化测试框架的设计
○6、测试工具的设计和选择
七、测试方案需要在测试计划的指导下进行，测试计划提出“做啥”，而测试方案明确“咋做”。
八、详见测试计划模板和测试方案模板 -
几道经典Ｃ语言面试题(转)
zhangtieing 发布于 2006-12-31 12:59:14
一、预处理器（Preprocessor）
1. 用预处理指令#define 声明一个常数，用以表明1年中有多少秒（忽略闰年问题）
#define SECONDS_PER_YEAR (60 * 60 * 24 * 365)UL
考点：
1). #define 语法的基本知识（例如：不能以分号结束，括号的使用，等等）
2). 懂得预处理器将为你计算常数表达式的值，因此，直接写出你是如何计算一年中有多少秒而不是计算出实际的值，是更清晰而没有代价的。
3). 意识到这个表达式将使一个16位机的整型数溢出-因此要用到长整型符号L,告诉编译器这个常数是的长整型数。
4).表达式中用到UL（表示无符号长整型）
2. 写一个“标准”宏MIN，这个宏输入两个参数并返回较小的一个。
#define MIN(A,B) ((A) <= (B) ? (A) : (B))
这个测试是为下面的目的而设的：
1). 标识#define在宏中应用的基本知识。这是很重要的，因为直到嵌入(inline)操作符变为标准C的一部分，宏是方便产生嵌入代码的唯一方法，对于嵌入式系统来说，为了能达到要求的性能，嵌入代码经常是必须的方法。
2). 三重条件操作符的知识。这个操作符存在C语言中的原因是它使得编译器能产生比if-then-else更优化的代码，了解这个用法是很重要的。
3). 懂得在宏中小心地把参数用括号括起来
4).讨论下面宏的副作用，例如：当你写下面的代码时会发生什么事？
least = MIN(*p++, b);
二、数据声明（Data declarations）
用变量a给出下面的定义
a) 一个整型数（An integer）
b) 一个指向整型数的指针（A pointer to an integer）
c) 一个指向指针的的指针，它指向的指针是指向一个整型数（A pointer to a pointer to an integer）
d) 一个有10个整型数的数组（An array of 10 integers）
e) 一个有10个指针的数组，该指针是指向一个整型数的（An array of 10 pointers to integers）
f) 一个指向有10个整型数数组的指针（A pointer to an array of 10 integers）
g) 一个指向函数的指针，该函数有一个整型参数并返回一个整型数（A pointer to a function that takes an integer as an argument and returns an integer）
h) 一个有10个指针的数组，该指针指向一个函数，该函数有一个整型参数并返回一个整型数（ An array of ten pointers to functions that take an integer argument and return an integer ）
答案是：
a) int a; // An integer
b) int *a; // A pointer to an integer
c) int **a; // A pointer to a pointer to an integer
d) int a[10]; // An array of 10 integers
e) int *a[10]; // An array of 10 pointers to integers
f) int (*a)[10]; // A pointer to an array of 10 integers
g) int (*a)(int); // A pointer to a function a that takes an integer argument and returns an integer
h) int (*a[10])(int); // An array of 10 pointers to functions that take an integer argument and return an integer
三、Static
关键字static的作用是什么？
在C语言中，关键字static有三个明显的作用：
1). 在函数体，一个被声明为静态的变量在这一函数被调用过程中维持其值不变。
2). 在模块内（但在函数体外），一个被声明为静态的变量可以被模块内所用函数访问，但不能被模块外其它函数访问。它是一个本地的全局变量。
3). 在模块内，一个被声明为静态的函数只可被这一模块内的其它函数调用。那就是，这个函数被限制在声明它的模块的本地范围内使用。
四、Const
关键字const是什么含意？
1). 合理地使用关键字const可以使编译器很自然地保护那些不希望被改变的参数，防止其被无意的代码修改。简而言之，这样可以减少bug的出现。
2). 通过给优化器一些附加的信息，使用关键字const也许能产生更紧凑的代码。
3). 关键字const的作用是为给读你代码的人传达非常有用的信息，实际上，声明一个参数为常量是为了告诉了用户这个参数的应用目的。如果你曾花很多时间清理其它人留下的垃圾，你就会很快学会感谢这点多余的信息。（当然，懂得用const的程序员很少会留下的垃圾让别人来清理的。）
#include <stdio.h>using namespace std;int main(){ const char *pa; char const *pb; char ca = 'a'; char cb = 'b'; char * const pc = &ca; const char * const pd = &cb; pa = &ca; pa = &cb; pb = &ca; pb = &cb; *pc = 'd'; printf("ca = %c\n", ca); return 0;}
经过以上测试
const char *pa;
char const *pb;
上面两种定义方法一样都是 pa(pb)指向的变量的值不可改变，及*pa,*pb, 而pa,和pb本身是可变的，如：
pa = &ca; //ok
×pa = 'c' //errorchar * const pc = &ca;
pc本身是不可变的（只能在定义时初始化），但指向的变量值是可变的，如
pc = &ca; //error
*pc = 'd'; //okconst char * const pd = &cb;
pd本身是不可变的，且指向的变量也是不可变的（只能在定义时初始化）
pd = &cb; //error
*pd = 'c'; /error通过以上总结，无论怎样定义p都是一指针
如果const在*左边，表示该指针指向的变量是不可变的
如果const在*右边，表示该指针本身是不可变得
五、Volatile
关键字volatile有什么含意 并给出三个不同的例子。
一个定义为volatile的变量是说这变量可能会被意想不到地改变，这样，编译器就不会去假设这个变量的值了。精确地说就是，优化器在用到这个变量时必须每次都小心地重新读取这个变量的值，而不是使用保存在寄存器里的备份。下面是volatile变量的几个例子：
1). 并行设备的硬件寄存器（如：状态寄存器）
2). 一个中断服务子程序中会访问到的非自动变量(Non-automatic variables)
3). 多线程应用中被几个任务共享的变量
这是区分C程序员和嵌入式系统程序员的最基本的问题。嵌入式系统程序员经常同硬件、中断、RTOS等等打交道，所用这些都要求volatile变量。不懂得volatile内容将会带来灾难。
回答以下问题：
1). 一个参数既可以是const还可以是volatile吗？解释为什么。
2). 一个指针可以是volatile 吗？解释为什么。
3). 下面的函数有什么错误：
int square(volatile int *ptr) {
return *ptr * *ptr;
}
下面是答案：
1). 是的。一个例子是只读的状态寄存器。它是volatile因为它可能被意想不到地改变。它是const因为程序不应该试图去修改它。
2). 是的。尽管这并不很常见。一个例子是当一个中服务子程序修该一个指向一个buffer的指针时。
3). 这段代码的有个恶作剧。这段代码的目的是用来返指针*ptr指向值的平方，但是，由于*ptr指向一个volatile型参数，编译器将产生类似下面的代码：
int square(volatile int *ptr) {
int a,b;
a = *ptr;
b = *ptr;
return a * b;
}
由于*ptr的值可能被意想不到地该变，因此a和b可能是不同的。结果，这段代码可能返不是你所期望的平方值！正确的代码如下：
long square(volatile int *ptr) {
int a;
a = *ptr;
return a * a;
}
六、位操作（Bit manipulation）
嵌入式系统总是要用户对变量或寄存器进行位操作。给定一个整型变量a，写两段代码，第一个设置a的bit 3，第二个清除a 的bit 3。在以上两个操作中，要保持其它位不变。
解答：采用#defines 和 bit masks 操作。这是一个有极高可移植性的方法，是应该被用到的方法。最佳的解决方案如下：
#define BIT3 (0x1<<3)
static int a;
void set_bit3(void) {
a |= BIT3;
}
void clear_bit3(void) {
a &= ~BIT3;
}
一些人喜欢为设置和清除值而定义一个掩码同时定义一些说明常数，这也是可以接受的。
主要考点：说明常数、|=和&=~操作。七、访问固定的内存位置（Accessing fixed memory locations）
嵌入式系统经常具有要求程序员去访问某特定的内存位置的特点。在某工程中，要求设置一绝对地址为0x
这一问题测试你是否知道为了访问一绝对地址把一个整型数强制转换（typecast）为一指针是合法的。这一问题的实现方式随着个人风格不同而不同。典型的类似代码如下：
int *ptr;
ptr = (int *)0x
*ptr = 0xaa55;
一个较晦涩的方法是：
*(int * const)(0x
建议采用第一种方法；
八、代码例子（Code examples）
1.下面的代码输出是什么，为什么？（考查有符号类型与无符号类型之间的转换）
void foo(void) {
unsigned int a = 6;
int b = -20;
(a+b > 6) ？ puts("> 6") : puts("<= 6");
}
这个问题测试你是否懂得C语言中的整数自动转换原则；
这无符号整型问题的答案是输出是“>
原因是当表达式中存在有符号类型和无符号类型时所有的操作数都自动转换为无符号类型。 因此-20变成了一个非常大的正整数，所以该表达式计算出的结果大于6。这一点对于应当频繁用到无符号数据类型的嵌入式系统来说是丰常重要的。
2. 评价下面的代码片断：（考查是否懂得处理器字长）
unsigned int zero = 0;
unsigned int compzero = 0xFFFF;
/*1's complement of zero */
对于一个int型不是16位的处理器为说，上面的代码是不正确的。应编写如下：
unsigned int compzero = ~0;
这一问题真正能揭露出应试者是否懂得处理器字长的重要性。好的嵌入式程序员非常准确地明白硬件的细节和它的局限，然而PC机程序往往把硬件作为一个无法避免的烦恼。
九、Typedef
Typedef作用是声明一个新的类型名代替已有的类型名；
也可以用预处理器做类似的事。例如，思考一下下面的例子：
#define dPS struct s *
typedef struct s * tPS;
以上两种情况的意图都是要定义dPS 和 tPS 作为一个指向结构s指针。哪种方法更好呢？（如果有的话）为什么？
这是一个非常微妙的问题，任何人答对这个问题（正当的原因）是应当被恭喜的。答案是：typedef更好。思考下面的例子：
dPS p1,p2;
tPS p3,p4;
第一个扩展为
struct s * p1, p2;
上面的代码定义 -
“英文简历常用词汇”大全
janely 发布于 2008-01-02 21:08:42
1、个人品质常用
able 有才干的，能干的 adaptable 适应性强的
active 主动的，活跃的 agssive 有进取心的
ambitious 有雄心壮志的 amiable 和蔼可亲的
amicable 友好的 analytical 善于分析的
apprehensive 有理解力的 aspiring 有志气的，有抱负的
audacious 大胆的，有冒险精神的 capable 有能力的，有才能的
careful 办理仔细的 candid 正直的
competent 能胜任的 constructive 建设性的
cooperative 有合作精神的 creative 富创造力的
dedicated 有奉献精神的 dependable 可靠的
diplomatic 老练的，有策略的 disciplined 守纪律的
dutiful 尽职的 well--educated 受过良好教育的
efficient 有效率的 energetic 精力充沛的
expressivity 善于表达 faithful 守信的，忠诚的
frank 直率的，真诚的 generous 宽宏大量的
genteel 有教养的 gentle 有礼貌的
humorous 有 impartial 公正的
independent 有主见的 industrious 勤奋的
ingenious 有独创性的 motivated 目的明确的
intelligent 理解力强的 learned 精通某门学问的
logical 条理分明的 methodical 有方法的
modest 谦虚的 objective 客观的
precise 一丝不苟的 punctual 严守时刻的
realistic 实事求是的 responsible 负责的
sensible 明白事理的 sporting 光明正大的
steady 踏实的 systematic 有系统的
purposeful 意志坚强的 sweet-tempered 性情温和的
temperate 稳健的 tireless 孜孜不倦的
2、教育程度常用
education 学历 educational history 学历
educational background 教育程度 curriculum 课程
major 主修 minor 副修
educational highlights 课程重点部分 curriculum included 课程包括
specialized courses 专门课程 courses taken 所学课程
special training 特别训练 social practice 社会实践
part-time jobs 业余工作 summer jobs 暑期工作
vacation jobs 假期工作 refresher course 进修课程
extracurricular activities 课外活动 physical activities 活动
recreational activities 娱乐活动 academic activities 学术活动
social activities 社会活动 rewards 奖励
scholarship 奖学金 excellent League member 优秀团员
excellent leader 优秀干部 student council 学生会
off-job training 脱产培训 in-job training 在职培训
educational system 学制 academic year 学年
semester 学期（美） term 学期（英）
supervisor 论文导师 pass 及格
fail 不及格 marks 分数
examination dee 学位
post doctorate 博士后 doctor(Ph.D) 博士
master 硕士 bachelor 学士
graduate student 研究生 abroad student 留学生
abroad student 留学生 undergraduate 大学肆业生
government-supported student 公费生 commoner 自费生
extern 走读生 intern 实习生
prize fellow 奖学金生 boarder 寄宿生
graduate 毕业生 guest student 旁听生（英）
auditor 旁听生（美） day-student 走读生
3、工作经历常用
work experience 工作经历 occupational history 工作经历
professional history 职业经历 specific experience 具体经历
responsibilities 职责 second job 第二职业
achievements 工作成就，业绩 administer 管理
assist 辅助 adapted to 适应于
accomplish 完成（任务等） appointed 被认命的
adept in 善于 analyze 分析
authorized 委任的；核准的 behave 表现
break the record 打破纪录 breakthrough 关键问题的解决
control 控制 conduct 经营，处理
cost 成本；费用 create 创造
demonstrate 证明，示范 decrease 减少
design 设计 develop 开发，发挥
devise 设计，发明 direct 指导
double 加倍，翻一番 earn 获得，赚取
effect 效果，作用 eliminate 消除
enlarge 扩大 enrich 使丰富
exploit 开发（资源，产品） enliven 搞活
establish 设立（公司等）；使开业 evaluation 估价，评价
execute 实行，实施 expedite 加快；促进
generate 产生 good at 擅长于
guide 指导；操纵 improve 改进，提高
initiate 创始，开创 innovate 改革，革新
invest 投资 integrate 使结合；使一体化
justified 经证明的；合法化的 launch 开办（新企业）
maintain 保持；维修 modernize 使现代化
negotiate nominated 被提名；被认命的
overcome 克服 perfect 使完善；改善
perform 执行，履行 profit 利润
be promoted to 被提升为 be proposed as 被提名（推荐）为
realize 实现（目标）获得（利润） reconstruct 重建
recorded 记载的 refine 精练，精制
registered 已注册的 regenerate 更新，使再生
replace 接替，替换 retrieve 挽回
revenue 收益，收入 scientific 科学的，系统的
self-dependence 自力更生 serve 服务，供职
settle 解决（问题等） shorten 减低……效能
simplify 简化，精简 spread 传播，扩大
standard 标准，规格 supervises 监督，管理
supply 供给，满足 systematize 使系统化
test 试验，检验 well-trained 训练有素的
valuable 有价值的 target 目标，指标
working model 劳动模范 advanced worker 先进工作者
4、个人资料常用
name 姓名 in. 英寸
pen name 笔名 ft. 英尺
alias 别名 street 街
Mr. 先生 road 路
Miss 小姐 district 区
Ms （小姐或太太） house number 门牌
Mrs. 太太 lane 胡同，巷
age 年龄 height 身高
bloodtype 血型 weight 体重
address 地址 born 生于
permanent address 永久住址 birthday 生日
province 省 birthdate 出生日期
city 市 birthplace 出生地点
county 县 home phone 住宅
prefecture 专区 office phone
autonomous region 自治区 business phone
nationality 民族；国籍 current address 目前住
citizenship 国籍 date of birth 出生日期
native place 籍贯 postal code 邮政编码
duel citizenship 双重国籍 marital status 婚姻状况
family status 家庭状况 married 已婚
single 未婚 divorced 离异
separated 分居 number of children 子女人数
health condition 健康状况 health 健康状况
excellent （身体）极佳 short-sighted 近视
far-sighted 远视 ID card 身份证
date of availability 可到职时间 membership 会员、资格
president 会长 vice-president 副会长
director 理事 standing director 常务理事
society 学会 association 协会
secretary-general 秘书长 research society 研究会 -
TD缺陷状态控制
pupu840323 发布于 2008-12-18 12:58:53
开发人员往往在修改BUG状态时,习惯性的不做一些备注,对此测试管理的时候很不方便,所以我们需要通过TD编程使备注编写强制化,代码如下:
Function Defects_Bug_FieldCanChange(FieldName, NewValue)
On Error Resume Next
Defects_Bug_FieldCanChange = Project_DefaultRes
On Error GoTo 0
if FieldName = "BG_STATUS" then
if NewValue="Fixed" then
if Bug_Fields("BG_STATUS").Value="working" and Bug_Fields("BG_DEV_COMMENTS").IsNull=true then
Msgbox "请增加注释内容"
Defects_Bug_FieldCanChange = False
Exit Function
end if
end if
end if
End Function -
一个自定义的BUG管理流程
zte_boy 发布于 2008-05-21 17:00:27
这两天一直在忙BUG管理流程的定制，从讨论到脚本开发，忙忙碌碌，终于有了个初步的成果
1、 管理工具及平台
采用QualityCenter9.0＋SqlServer2000的Windows平台
2、 组权限设置
定义五个权限组，具有不同的权限，一个用户可以同时加入多个组
A） TEST组
提交BUG、验证BUG，测试人员最低权限组
B） TESTLEADER组
审核BUG
C） DEVE组
修复BUG
D） PROJECTMANAGE组
分配、延期、拒绝BUG等
E） MANAGE组
具体项目的设置权限，如配置组、定义实体、列表等
3、 BUG状态定义了11种BUG状态：
新建、确认、否决、打开、延期、拒绝、驳回、修复、固定、关闭、重新打开
4、 BUG状态转换图
见附件
5、 BUG详细设置
1） 新建
A－D组都具有BUG提交权限，
缺陷提交字段包括：摘要、项目、项目版本、模块、环境、检测者、检测日期、测试轮次、严重程度、可重现、状态、描述
所有字段必填，检测者默认为登陆人，只读；检测日期默认为当前日期，只读；状态默认为“新建”，只读；
缺陷详细信息界面包括：摘要、项目、项目版本、模块、环境、检测者、检测日期、测试轮次、严重程度、可重现、状态、描述、优先级、分配给、计划关闭轮次、估计修复时间、关闭于轮次、实际修复时间、关闭日期
可修改字段：项目、项目版本、模块、环境、测试轮次、严重程度、是否重现、描述
该状态下的BUG信息外只能提交人自己修改，他人无权修改，状态由TESTLEADER组权限人员修改
2） 确认
由TESTLEADER组权限人员修改，其他组成员只能修改自己所属的缺陷描述
3） 否决
由TESTLEADER组权限人员修改，终态之一，该状态下全部字段只读
4） 打开
由PROJECTMANAGE组权限人员修改，此状态下分配给、优先级、计划关闭轮次、估计修复时间字段必填
5） 延期
由PROJECTMANAGE组权限人员修改
6） 拒绝
由PROJECTMANAGE组权限人员修改，注释必填
7） 修复
由DEVE组权限人员修改，只能修改缺陷状态
8） 固定
由PROJECTMANAGE组权限人员修改，只能修改状态
9） 驳回
因描述不清由PROJECTMANAGE组权限人员修改，只能修改状态，可由由TESTLEADER组权限人员修改为“确认”，但必须填写注释
10）已关闭
由TEST组权限人员修改，此时实际关闭轮次、实际修复时间必填、实际关闭日期系统默认为当前时间，只读
11）重新打开
由TEST组权限人员修改，只能修改状态
涉及到的状态转换和权限角色很多，就不一一描述了（偷个懒），呵呵
