测试人生......坚持到底

发布新日志

  • 数据库建表（转）

    2009-04-22 21:04:05

    sql建库建表 创建和使用约束 　日期：2005-12-4 14:41:58  来源:百当软件园 
     
    约束（Constraint）是Microsoft SQL Server 提供的自动保持数据库完整性的一种方法，定义了可输入表或表的单个列中的数据的限制条件（有关数据完整性的介绍请参见第9 章）。在SQL Server 中有5 种约束：主关键字约束（Primary Key Constraint）、外关键字约束（Foreign Key Constraint）、惟一性约束（Unique Constraint）、检查约束（Check Constraint）和缺省约束（Default Constraint）。

    7.2.1 主关键字约束
    主关键字约束指定表的一列或几列的组合的值在表中具有惟一性，即能惟一地指定一行记录。每个表中只能有一列被指定为主关键字，且IMAGE 和TEXT 类型的列不能被指定为主关键字，也不允许指定主关键字列有NULL 属性。
    定义主关键字约束的语法如下：
    CONSTRAINT constraint_name
    PRIMARY KEY [CLUSTERED | NONCLUSTERED]
    （column_name1[, column_name2,…,column_name16]）
    各参数说明如下：


    constraint_name
    指定约束的名称约束的名称。在数据库中应是惟一的。如果不指定，则系统会自动生成一个约束名。
    CLUSTERED | NONCLUSTERED
    指定索引类别，CLUSTERED 为缺省值。其具体信息请参见下一章。
    column_name
    指定组成主关键字的列名。主关键字最多由16 个列组成。
     

    例7-3： 创建一个产品信息表，以产品编号和名称为主关键字
    create table products (
    p_id char(8) not null,
    p_name char(10) not null ,
    price money default 0.01 ,
    quantity smallint null ,
    constraint pk_p_id primary key (p_id, p_name)
    ) on [primary]

    7.2.2 外关键字约束
    外关键字约束定义了表之间的关系。当一个表中的一个列或多个列的组合和其它表中的主关键字定义相同时，就可以将这些列或列的组合定义为外关键字，并设定它适合哪个表中哪些列相关联。这样，当在定义主关键字约束的表中更新列值，时其它表中有与之相关联的外关键字约束的表中的外关键字列也将被相应地做相同的更新。外关键字约束的作用还体现在，当向含有外关键字的表插入数据时，如果与之相关联的表的列中无与插入的外关键字列值相同的值时，系统会拒绝插入数据。与主关键字相同，不能使用一个定义为 TEXT 或IMAGE 数据类型的列创建外关键字。外关键字最多由16 个列组成。
    定义外关键字约束的语法如下：
    CONSTRAINT constraint_name
    FOREIGN KEY （column_name1[, column_name2,…,column_name16]）
    REFERENCES ref_table [ （ref_column1[,ref_column2,…, ref_column16] ）]
    [ ON DELETE { CASCADE | NO ACTION } ]
    [ ON UPDATE { CASCADE | NO ACTION } ] ]
    [ NOT FOR REPLICATION ]
    各参数说明如下：

    REFERENCES
    指定要建立关联的表的信息。
    ref_table
    指定要建立关联的表的名称。
    ref_column
    指定要建立关联的表中的相关列的名称。
    ON DELETE {CASCADE | NO ACTION}
    指定在删除表中数据时，对关联表所做的相关操作。在子表中有数据行与父表中的对应数据行相关联的情况下，如果指定了值CASCADE，则在删除父表数据行时会将子表中对应的数据行删除；如果指定的是NO ACTION，则SQL Server 会产生一个错误，并将父表中的删除操作回滚。NO ACTION 是缺省值。
    ON UPDATE {CASCADE | NO ACTION}
    指定在更新表中数据时，对关联表所做的相关操作。在子表中有数据行与父表中的对应数据行相关联的情况下，如果指定了值CASCADE，则在更新父表数据行时会将子表中对应的数据行更新；如果指定的是NO ACTION，则SQL Server 会产生一个错误，并将父表中的更新操作回滚。NO ACTION 是缺省值。
    NOT FOR REPLICATION
    指定列的外关键字约束在把从其它表中复制的数据插入到表中时不发生作用。
    例7-4：创建一个订货表，与前面创建的产品表相关联
    create table orders(
    order_id char(8),
    p_id char(8),
    p_name char(10) ,
    constraint pk_order_id primary key (order_id) ,
    foreign key(p_id, p_name) references products(p_id, p_name)
    ) on [primary]
    注意：临时表不能指定外关键字约束。
    7.2.3 惟一性约束
    惟一性约束指定一个或多个列的组合的值具有惟一性，以防止在列中输入重复的值。惟一性约束指定的列可以有NULL 属性。由于主关键字值是具有惟一性的，因此主关键字列不能再设定惟一性约束。惟一性约束最多由16 个列组成。
    定义惟一性约束的语法如下：
    CONSTRAINT constraint_name
    UNIQUE [CLUSTERED | NONCLUSTERED]
    （column_name1[, column_name2,…,column_name16]）

    例7-5：定义一个员工信息表，其中员工的身份证号具有惟一性。
    create table employees (
    emp_id char(8),
    emp_name char(10) ,
    emp_cardid char(18),
    constraint pk_emp_id primary key (emp_id),
    constraint uk_emp_cardid unique (emp_cardid)
    ) on [primary]

    7.2.4 检查约束
    检查约束对输入列或整个表中的值设置检查条件，以限制输入值，保证数据库的数据完整性。可以对每个列设置符合检查。
    定义检查约束的语法如下：
    CONSTRAINT constraint_name
    CHECK [NOT FOR REPLICATION]
    (logical_expression)
    各参数说明如下:
    NOT FOR REPLICATION
    指定检查约束在把从其它表中复制的数据插入到表中时不发生作用。
    logical_expression
    指定逻辑条件表达式返回值为TRUE 或FALSE。
    例7-6： 创建一个订货表其中定货量必须不小于10。
    create table orders(
    order_id char(8),
    p_id char(8),
    p_name char(10) ,
    quantity smallint,
    constraint pk_order_id primary key (order_id),
    constraint chk_quantity check (quantity>=10) ,
    ) on [primary]
    注意：对计算列不能作除检查约束外的任何约束。

    7.2.5 缺省约束
    缺省约束通过定义列的缺省值或使用数据库的缺省值对象绑定表的列，来指定列的缺省值。SQL Server 推荐使用缺省约束，而不使用定义缺省值的方式来指定列的缺省值。有关绑定缺省约束的方法请参见“数据完整性”章节。
    定义缺省约束的语法如下：
    CONSTRAINT constraint_name
    DEFAULT constant_expression [FOR column_name]
    例7-7：
    constraint de_order_quantity default 100 for order_quantity
    注意：不能在创建表时定义缺省约束，只能向已经创建好的表中添加缺省约束。


    7.2.6 列约束和表约束
    对于数据库来说，约束又分为列约束（Column Constraint）和表约束（Table Constraint）。
    列约束作为列定义的一部分只作用于此列本身。表约束作为表定义的一部分，可以作用于
    多个列。
    下面举例说明列约束与表约束的区别。
    例7-8：
    create table products (
    p_id char(8) ,
    p_name char(10) ,
    price money default 0.01 ,
    quantity smallint check (quantity>=10) , /* 列约束 */
    constraint pk_p_id primary key (p_id, p_name) /* 表约束 */

     

    查看(592) 评论(0) 收藏 分享 管理

  • 不要奴隶般的工作（墨菲）转

    2009-04-12 21:32:15

    要像奴隶般地去工作；不要相信只有汗水和艰苦奋斗才能变为富有，事实并不是这样，生活得越轻松越好。做你爱干的事，去感受它的乐趣和激动。对自己说“我将富有”吧，其实你不是在说“富有”，而是在思索内在的真正动力。但也不要以为重复地说就能富有，人的潜意识只接受“当真”的东西和坚定的信念，而不是空洞的词句。也许您不认同潜意识，但相信约瑟夫·墨菲的演讲依然会使你受益。-psytopic.com

    如果你经济上有困难，经常担心收支是否能相抵，这就意味着你还没有让你的潜意识信服，即，你总是富足有余的。你知道，有些人一周工作几小时，但挣的钱却相当惊人。

    不要像奴隶般地去工作；不要相信只有汗水和艰苦奋斗才能变为富有，事实并不是这样，生活得越轻松越好。做你爱干的事，去感受它的乐趣和激动。

    我认识一位洛杉矶的企业领导人，月收入7500美元。去年他休假9个月，做环球旅行，到全世界著名的城市去旅游观光。他对我说，他已经成功地说服他自己，他值这么多钱。

    他说他公司里的一些员工，一周只有100多美元，对业务比他懂得还多，也许让他们干总经理比他干得还好，只是他们没有野心，没有创新的想法，对潜意识的奇迹不感兴趣。

    富有是一种心理，是自我的一种内在意识。你不会因为说：“我是百万富翁，我是百万富翁”，就会成为百万富翁。但你会通过建立富有的想法，逐渐有了富有的意识。

    大多数人都不能利用自身内在的无形力量的支持。当生意不景气，股市下跌，投资受损时，他们往往感到很无奈。这种无依无靠的感觉是因为他们不知道怎样叩开潜意识的大门。他们对自身内在的无尽资源毫无所知。

    如果您对这篇文章感兴趣，相信你会对PSYTOPIC同样感兴趣，网址是Psytopic.com ，这次点击不会浪费您的时间。这是Psytopic的指纹密码：aHR0cDovL3d3dy5wc3l0b3BpYy5jb20v，您可以凭这个指纹在google搜索到我们的网站。

    一个认定自己贫穷的人总是处于贫困之中。另一个人心中常思念富有，总是什么都不缺。过贫困的日子绝非是上帝的旨意。你可以很富有，什么都不缺。

    你发自内心的话语就是力量，就能清除心中的错误想法。也许你会把你所想地说出来：“我要成为有钱的人，我要成功。”那么你就一天三四次地重复说吧。你的话语的力量是巨大的，它代表了你潜意识的内在力量。

    将你的想法和潜意识的力量结合在一起吧!在你的生活中，条件和环境都会随你的潜意识变化而变化。

    其实你不是在说“富有”，你是在思索内在的真正动力。当你说要富有时，你的意识受到了潜意识的强大支持。

    此外，当你思考富有时，你内在就充满了富有的感受。富有的感受就会产生富有。始终保持这种心态。你的潜意识像个银行，不管你存储什么，都会成倍地回报你。所以，选择富有吧!

    你必须深信财富属于你，当然并不是你说自己富有就会富有的。在过去的35年中，我常听到的一般抱怨是：“几个月来，我一直在说我要富有，我要发迹，可什么也没发生。”我发现，说这些话的人，他们的意识自己就不相信这会是真的。

    有人说他不断地在说“我要富有”，一直到他说累了为止，可情况越来越糟。但他自己知道，他说这些话时，他的意识中有另一个声音。

    当他意识中存在冲突的时候，他的潜意识却接受了相反的东西。只有当精神上没有冲突产生，所肯定的东西又非常明确时，这种肯定才起作用。潜意识只接受“当真”的东西和坚定的信念，而不是空洞的词句。

    对那些常产生思想冲突的人，可按这种方法来试一下：经常这样说，特别是在临睡觉前，“我所从事的所有感兴趣的事每时每刻，日日夜夜都给我带来喜悦。”这种陈述不会在心里引起争论，与原先潜意识中可能存在的缺钱的感受也不会冲突。

    有个商人曾一度销售不景气，他很担忧。我建议他在办公室坐下来，让心情平静下来，不断地重复说，“我的销售状况开始日趋改善了。”当他的意识和潜意识能相互合作时，现实中就会产生结果。

    不要签空白支票。当你在说“什么都用光了”，“总是不够”，“抵押出问题了”，“房子完了”等等，你就等于在签空白支票。如果你对未来充满恐惧，也等于在签空白支票，在把消极的信息带给自己。
    你的潜意识接受你的恐惧和消极的陈述，然后按照它自身规律，为你带来阻碍、拖延、匮乏和约束。

    那些感觉富有的人，财富就会来到他身旁；那些感觉贫困的人，贫困就伴随着他。你的潜意识将你对它的“存储”成倍放大。

    每天早晨醒来后，将健康、成功、平安的思想存储给它，经常思索这些概念，心里充满这些想法；这些美好的想法会在你的潜意识中找到“存储”位置，之后就会为你在现实中带来富有和成功。

    我会听到你说：“我也那样做了，可什么都没发生。”你没有结果是因为你在10分钟之后又回到了原先的消极的意识状态中，你的美好想法对潜意识的影响等于零。当一粒种子种在地里，如不挖掉的话，就会生根、成长。

    假如你说：“我买不起这东西。”你应该在“我买不起”的地方停下来，然后想一想，换一种积极的思维方式说：“我总有办法。”

    你的潜意识决不会缺少想法，它有着无限的智慧，时时刻刻都准备在你意识中出现；会以各种方式为你的“皮夹里加钱”。不管股市是涨还是跌，不管美元增值还是贬值，在你心里的这一过程总是如此，你的财富从真正意义上讲，不取决于债券、股票或银行里的钱，它们只是象征的符号而已。

    如果你能使你的潜意识深信财富是属于你的，你一生中总会富足有余的。你必将富有，不管财富是以何种方式存在。

    查看(365) 评论(0) 收藏 分享 管理

  • 死锁

    2009-03-15 20:14:03

    一 死锁产生的条件

    发生死锁的必要条件有以下四个

    互斥条件：一个数据对象一次只能被一个事物使用，即对数据库的封锁采用排

    不可抢占条件：一个数据对象只能被占用他的事物释放

    部分分配条件：一个事务已经封锁分给他的数据对象，但仍然要求封锁其他数据

    循环等待条件：允许等待其他事物释放的数据对象，系统处于加锁请求相互等待的状态。                                                  

    二  死锁的预防

    一次加锁法：

    顺序加锁法

    三 死锁诊断与解除

    可以利用的事务的信赖图的形式测试系统中是否存在死锁。

    如果已经发现死锁，dba从依赖相同的事务抽出某个事务作为牺牲品，将他撤销，解除它所有的封锁，释放此事务长有所有的数据资源，分配给其他事务，使其他事务得以继续运行下去，在解除死锁的过程中，抽取牺牲事务的标准是根据系统状态及其应用的实际情况来确定，通常采用的方法之一是选择一个处理死锁代价最小的事务，将其撤销。不重要的用户，取消其操作，释放封锁数据，恢复数据库所有的改变。

    查看(460) 评论(0) 收藏 分享 管理

  • 左连接，有链接

    2009-03-15 20:11:09


    left join    :左连接，返回左表中所有的记录以及右表中连接字段相等的记录。
    right join :右连接，返回右表中所有的记录以及左表中连接字段相等的记录。
    inner join: 内连接，又叫等值连接，只返回两个表中连接字段相等的行。
    full join:外连接，返回两个表中的行：left join + right join
    cross join:结果是笛卡尔积，就是第一个表的行数乘以第二个表的行数。
    补充说明：如果表一中的某行对应表二中的两行记录，那么结果集中会有两条记录对应，right join也同样道理。
    ----------------------------------------------------------------------------------------------------

    例子


    declare @a table(a int,b int)
    declare @b table(a int,b int)

    insert @a values(1,1)
    insert @a values(2,2)
    insert @b values(1,1)
    insert @b values(3,3)
    select * from @a
    select * from @b
    --左:
    select * from @a Aa left join @b Bb on Aa.a=Bb.a
    --右：
    select * from @a Aa right join @b Bb on Aa.a=Bb.a
    --内
    select * from @a Aa inner join @b Bb on Aa.a=Bb.a
    --外：
    select * from @a Aa full join @b Bb on Aa.a=Bb.a
    --交叉连接
    select * from @a cross join @b
     

    查看(467) 评论(1) 收藏 分享 管理

  • LoadRunner CPC Exam

    2009-02-22 21:55:47

    I flew up to Sydney yesterday for the privilege of being (as far as I know) the first non-Mercury employee to sit for the LoadRunner CPC exam in Australia.

    Feedback from people who had already taken the exam seemed to be almost universally along the lines of “there is a lot to get through. Know the subject thoroughly. You will not have time to look up documentation.” Mercury representatives said, “If you could do your LoadRunner CPS exam, then you should have no problems with the CPC.”

    I had previously completed my LoadRunner CPS and had been using LoadRunner for a long time but, even so, I found the exam extremely challenging and used every minute of the allocated time.

    The LoadRunner 7.6 CPC exam is to be completed in 1 day (8 hours). The pass mark is 70%, and a total of 134 possible points are allocated to the four exam sections as follows:

    Section A - Scripting exercises.
    60 points (45%)
    3 hours.

    Section B - LoadRunner Controller + Multiple choice questions.
    28 points (21%)
    2 hours 30 minutes.

    Section C - Multiple choice questions.
    36 points (27%)
    15 minutes.

    Section D - C programming.
    10 points (7%)
    30 minutes.

    As can be seen from the recommended completion times for each section, Mercury�s estimates are definitely on the low side (adding up to only 6 hours, 15 minutes), and the possible scores for each section do not correlate with the suggested times.

    I spent 4 hours and 30 minutes on Section A, and 45 minutes on Section D, with the rest of the time split between the two remaining sections.

    The questions in Section A build on each other. If you cannot complete the first question, you will not be able to go on with subsequent questions. Having completed the exercises from the CPS comes in handy here, as some of the questions are similar. Ensure that you are familiar with parameterisation and correlation using both recording modes (as far as I can remember, the CPS only used URL mode). Try not to make assumptions about what is required. Follow the instructions to the letter. If you miss something on an earlier question, you will probably not have time to go back, make changes to all your previous scripts and re-run them. Remember that script. execution for debugging purposes can be sped up by turning off �Animated Run� and closing the output window. Your script. execution will be CPU-bound, and these items have a large overhead.

    Section B focuses on creating and executing a scenario. There are no surprises here, but one of the key questions is based on how Mercury thinks a load test should be run, so your own experiences/prejudices may have little value. There is at least 30 minutes of execution time in this section that can be completed in parallel with Section C or D. Just remember that, as the Application Under Test will probably be running on the same machine as the controller, any compilations or searches through Acrobat files will affect the scenario results as they push CPU utilisation to 100%.

    Section C is an opportunity to pick up some easy marks. There are 36 possible points for the 32 multiple-choice questions. There are some obscure questions here that you are guaranteed to have never encountered, but all answers can be found by searching through the documentation or experimenting with LoadRunner. As with the CPC, there are some very ambiguous questions, and even a question on the features of a type of graph that unintentionally leaves the name of the graph out of the question. When in doubt, deal with ambiguity by documenting your assumptions about what the question means.

    Section D is the easiest section for guaranteed marks. You are given a script. that contains compilation, logical and functional errors and must make it run against the Application Under Test. if you have a working knowledge of C, it shouldn’t be hard to track down the compilation errors. Start with the first error and work down the list. Remember that a â�œnot writing pre_cci.ciâ� output message from the compiler can (non-obviously) push the real error off the top of the debug window. Once the compiler errors are taken care of, you must ensure that the script. meets its stated aim. This will not be hard if you can successfully complete Section A.

    Apparently the LoadRunner 7.6 CPC exam has a very high failure rate. I am not totally confident of receiving a passing grade myself. All questions were answered and all exercises were completed to the specifications, but my scripts were short on elegant solutions and clearly written code. My fingers are crossed for some generous marking.

    Update: I finally received my results, and I passed this exam comfortably.

    查看(434) 评论(0) 收藏 分享 管理

  • 数据库中的高级查询2

    2009-02-19 22:35:03

    1.UNION,EXCEPT,INTERSECT运算符
    A,UNION 运算符
    UNION 运算符通过组合其他两个结果表（例如 TABLE1 和 TABLE2）并消去表中任何重复行而派生出一个结果表。
    当 ALL 随 UNION 一起使用时（即 UNION ALL），不消除重复行。两种情况下，派生表的每一行不是来自 TABLE1 就是来自 TABLE2。
    B, EXCEPT 运算符
    EXCEPT 运算符通过包括所有在 TABLE1 中但不在 TABLE2 中的行并消除所有重复行而派生出一个结果表。
    当 ALL 随 EXCEPT 一起使用时 (EXCEPT ALL)，不消除重复行。
    C,INTERSECT 运算符
    INTERSECT 运算符通过只包括 TABLE1 和 TABLE2 中都有的行并消除所有重复行而派生出一个结果表。
    当 ALL 随 INTERSECT 一起使用时 (INTERSECT ALL)，不消除重复行。
    注：使用运算词的几个查询结果行必须是一致的。
    ----------------------------------------------------------------------------------------------------
    2.外连接
    A、left outer join：
    左外连接（左连接）：结果集几包括连接表的匹配行，也包括左连接表的所有行。
    sql: select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c
    B：right outer join:
    右外连接(右连接)：结果集既包括连接表的匹配连接行，也包括右连接表的所有行。
    C：full outer join：
    全外连接：不仅包括符号连接表的匹配行，还包括两个连接表中的所有记录。
    ----------------------------------------------------------------------------------------------------

    其次，大家来看一些不错的sql语句
    1、说明：复制表(只复制结构,源表名：a 新表名：b) (Access可用)
    法一：select * into b from a where 1<>1
    法二：select top 0 * into b from a
    2、说明：拷贝表(拷贝数据,源表名：a 目标表名：b) (Access可用)
    insert into b(a, b, c) select d,e,f from b;
    3、说明：
    跨数据库之间表的拷贝(具体数据使用绝对路径) (Access可用)
    insert into b(a, b, c) select d,e,f from b in ‘具体数据库’ where 条件
    例子：..from b in '"&Server.MapPath(".")&"\data.mdb" &"' where..

    4、说明：子查询(表名1：a 表名2：b)
    select a,b,c from a where a IN (select d from b )
    或者: select a,b,c from a where a IN (1,2,3)

    5、说明：显示文章、提交人和最后回复时间
    select a.title,a.username,b.adddate from table a,(select max(adddate) adddate from table where table.title=a.title) b

    6、说明：外连接查询(表名1：a 表名2：b)
    select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c

    7、说明：在线视图查询(表名1：a )
    select * from (SELECT a,b,c FROM a) T where t.a > 1;

    8、说明：between的用法,between限制查询数据范围时包括了边界值,not between不包括
    select * from table1 where time between time1 and time2
    select a,b,c, from table1 where a not between 数值1 and 数值2

    9、说明：in 的使用方法
    select * from table1 where a [not] in (‘值1’,’值2’,’值4’,’值6’)

    10、说明：两张关联表，删除主表中已经在副表中没有的信息
    delete from table1 where not exists ( select * from table2 where table1.field1=table2.field1 )

    11、说明：四表联查问题：
    select * from a left inner join b on a.a=b.b right inner join c on a.a=c.c inner join d on a.a=d.d where .....

    12、说明：日程安排提前五分钟提醒
    sql: select * from 日程安排 where datediff('minute',f开始时间,getdate())>5

    13、说明：一条sql 语句搞定数据库分页
    select top 10 b.* from (select top 20 主键字段,排序字段 from 表名 order by 排序字段 desc) a,
    表名 b where b.主键字段 = a.主键字段 order by a.排序字段

    14、说明：前10条记录
    select top 10 * form. table1 where 范围

    15、说明：选择在每一组b值相同的数据中对应的a最大的记录的所有信息
    (类似这样的用法可以用于论坛每月排行榜,每月热销产品分析,按科目成绩排名,等等.)
    select a,b,c from tablename ta where a=(select max(a) from tablename tb where tb.b=ta.b)

    16、说明：包括所有在 TableA 中但不在 TableB和TableC 中的行并消除所有重复行而派生出一个结果表
    (select a from tableA ) except (select a from tableB) except (select a from tableC)

    17、说明：随机取出10条数据
    select top 10 * from tablename order by newid()

    18、说明：随机选择记录
    select newid()

    19、说明：删除重复记录
    Delete from tablename where id not in (select max(id) from tablename group by col1,col2,...)

    20、说明：列出数据库里所有的表名
    select name from sysobjects where type='U'

    21、说明：列出表里的所有的
    select name from syscolumns where id=object_id('TableName')

    22、说明：列示type、vender、pcs字段，以type字段排列，case可以方便地实现多重选择，类似select 中的case。
    select type,sum(case vender when 'A' then pcs else 0 end),
    sum(case vender when 'C' then pcs else 0 end),
    sum(case vender when 'B' then pcs else 0 end)
    FROM tablename group by type

    显示结果：
    type vender pcs
    电脑 A 1
    电脑 A 1
    光盘 B 2
    光盘 A 2
    手机 B 3
    手机 C 3

    23、说明：初始化表table1

    TRUNCATE TABLE table1

    24、说明：选择从10到15的记录
    select top 5 * from (select top 15 * from table order by id asc) table_别名 order by id desc

    随机选择数据库记录的方法（使用Randomize函数，通过SQL语句实现）
    对存储在数据库中的数据来说，随机数特性能给出上面的效果，但它们可能太慢了些。
    你不能要求ASP“找个随机数”然后打印出来。实际上常见的解决方案是建立如下所示的循环：
    Randomize
    RNumber = Int(Rnd*499) +1

    While Not objRec.EOF
    If objRec("ID") = RNumber THEN
    ... 这里是执行脚本 ...
    end if
    objRec.MoveNext
    Wend

    这很容易理解。首先，你取出1到500范围之内的一个随机数（假设500就是数据库内记录的总数）。
    然后，你遍历每一记录来测试ID 的值、检查其是否匹配RNumber。满足条件的话就执行由THEN 关键字开始的那一块代码。
    假如你的RNumber 等于495，那么要循环一遍数据库花的时间可就长了。
    虽然500这个数字看起来大了些，但相比更为稳固的企业解决方案这还是个小型数据库了，后者通常在一个数据库内就包含了成千上万条记录。
    这时候不就死定了？
    采用SQL，你就可以很快地找出准确的记录并且打开一个只包含该记录的recordset，如下所示：
    Randomize
    RNumber = Int(Rnd*499) + 1

    sql = "SELECT * FROM Customers WHERE ID = " & RNumber

    set bjRec = ObjConn.Execute(SQL)
    Response.WriteRNumber & " = " & objRec("ID") & " " & objRec("c_email")

    不必写出RNumber 和ID，你只需要检查匹配情况即可。
    只要你对以上代码的工作满意，你自可按需操作“随机”记录。
    Recordset没有包含其他内容，因此你很快就能找到你需要的记录这样就大大降低了处理时间。
    --------------------------------------------------------------------------------------
    再谈随机数

    现在你下定决心要榨干Random 函数的最后一滴油，那么你可能会一次取出多条随机记录或者想采用一定随机范围内的记录。
    把上面的标准Random 示例扩展一下就可以用SQL应对上面两种情况了。
    为了取出几条随机选择的记录并存放在同一recordset内，你可以存储三个随机数，然后查询数据库获得匹配这些数字的记录：
    sql = "SELECT * FROM Customers WHERE ID = " & RNumber & " OR ID = " & RNumber2 & " OR ID = " & RNumber3

    假如你想选出10条记录（也许是每次页面装载时的10条链接的列表），
    你可以用BETWEEN 或者数学等式选出第一条记录和适当数量的递增记录。
    这一操作可以通过好几种方式来完成，但是 SELECT 语句只显示一种可能（这里的ID 是自动生成的号码）：
    sql = "SELECT * FROM Customers WHERE ID BETWEEN " & RNumber & " AND " & RNumber & "+ 9"
    注意：以上代码的执行目的不是检查数据库内是否有9条并发记录。

    随机读取若干条记录，
    测试过
    Access语法：SELECT top 10 * From 表名 ORDER BY Rnd(id)
    sql server:select top n * from 表名 order by newid()
    mysqlelect * From 表名 Order By rand() Limit n
    Access左连接语法(最近开发要用左连接,Access帮助什么都没有,网上没有Access的SQL说明,只有自己测试, 现在记下以备后查)
    语法elect table1.fd1,table1,fd2,table2.fd2 From table1 left join table2 on table1.fd1,table2.fd1 where ...
    使用SQL语句 用...代替过长的字符串显示
    语法：
    SQL数据库：
    select case when len(field)>10 then left(field,10)+'...'
    else field end as news_name,news_id from tablename
    Access数据库：SELECT iif(len(field)>2,left(field,2)+'...',field) FROM tablename;

    Conn.Execute说明
    Execute方法该方法用于执行SQL语句。根据SQL语句执行后是否返回记录集，该方法的使用格式分为以下两种：

    1．执行SQL查询语句时，将返回查询得到的记录集。
    用法为：Set 对象变量名=连接对象.Execute("SQL 查询语言")
    Execute方法调用后，会自动创建记录集对象，并将查询结果存储在该记录对象中，
    通过Set方法，将记录集赋给指定的对象保存，以后对象变量就代表了该记录集对象。

    2．执行SQL的操作性语言时，没有记录集的返回。此时用法为：
    连接对象.Execute "SQL 操作性语句" [, RecordAffected][, Option]
    ·RecordAffected 为可选项，此出可放置一个变量，SQL语句执行后，所生效的记录数会自动保存到该变量中。
    通过访问该变量，就可知道SQL语句队多少条记录进行了操作。
    ·Option 可选项，该参数的取值通常为adCMDText，它用于告诉ADO，应该将Execute方法之后的第一个字符解释为命令文本。
    通过指定该参数，可使执行更高效。

    ·BeginTrans、RollbackTrans、CommitTrans方法
    这三个方法是连接对象提供的用于事务处理的方法。BeginTrans用于开始一个事物；RollbackTrans用于回滚事务；
    CommitTrans用于提交所有的事务处理结果，即确认事务的处理。
    事务处理可以将一组操作视为一个整体，只有全部语句都成功执行后，事务处理才算成功；
    若其中有一个语句执行失败，则整个处理就算失败，并恢复到处里前的状态。
    BeginTrans和CommitTrans用于标记事务的开始和结束，在这两个之间的语句，就是作为事务处理的语句。
    判断事务处理是否成功，可通过连接对象的Error集合来实现，若Error集合的成员个数不为0，则说明有错误发生，事务处理失败。
    Error集合中的每一个Error对象，代表一个错误信息。

    查看(316) 评论(0) 收藏 分享 管理

  • 数据库中的高级查询

    2009-02-19 21:40:49

    1 在查询中使用列明

    select 列名 as ‘ 新列名' from 表名
    //合并列然后起新列名
    select 列名+列名 as 新列名

    2 查询空行

    select 列名 from 表名 where 列名 is null;

    select 列名 from 表名 where  列名 is not null；

    3 在查询中使用常量列来查询表名

    select '常量值'=新列名 from 表名

    4 查询返回限制的行数

    select top 行数 from 表名

    select top 百分数 percent  from 表名

    5查询排序

    select *  from  表名 order by 排序列  acs（desc）

    6 使用like 模糊查询

    select * from 表名 where  列名 like "模糊条件"

    7 使用between在某个范围内进行查询

    select * from 表名 where  列名 between value1 and valu2

    8 使用in在列举职内进行查询

    select * from 表名 where  列名 in();

    9聚合函数sum

    select sum(列名) from 表名；

    select avg(列名) from 表名；

    select max(列名)  from 表名;

    select min(列名) from 表名；

    select count(列名)  from 表名；

    10 使用group BY进行分组查询（有点难度）

    select 分组列名 from 表名 group by 分组列

    16、使用having子句进行分组筛选

    select 分组列名 from 表名 group by 分组列 having 条件
    17 内连接
    //在where子句中置顶连接条件
    select * from 表名1，表名2  where 表名1.列名=表名2.列名
    //在from子句使用【inner】join on 表名1. 列名=表名2.列名
    select * from 表名1 inner jion  表名2 on 表名1.列名=表名2.列名
    18 外连接
    // 左外连接
    select * from 表名1 left（ritht ） other join 表名2 表名1.列名=表名2.列名
     

     

     

     

    查看(343) 评论(0) 收藏 分享 管理

  • 如何写性能测试用例

    2009-02-18 23:51:45

    I have decided to release an early draft of this document so that others may provide feedback. Please let me know what you think.

    Writing test cases for performance testing requires a different mindset to writing functional test cases. Fortunately it is not a difficult mental leap. This article should give you enough information to get you up and running.

    First, lets set out some background and define some terms that are used in performance testing.

    • Test case â�“ a test case is the same as a use case or business process. Just as with a functional test case, it outlines test steps that should be performed, and the expected result for each step.
    • Test script. â�“ a test script. is a program created by a Performance tester that will perform. all the steps in the test case.
    • Virtual user â�“ a virtual user generally runs a single test script. Virtual users do not run test scripts using the Graphical User Interface (like a functional test case that has been automated with tools like WinRunner, QuickTest, QARun or Rational Robot); they simulate a real user by sending the same network traffic as a real user would. A single workstation can run multiple virtual users. [Would a diagram be useful here?]
    • Scenario â�“ a performance test scenario is a description of how a set of test scripts will be run. It outlines how many times an hour they will be run, how many users will run each test script, and when each test script. will be run. The aim of a scenario is to simulate real world usage of a system.

    Writing a test case for performance testing is basically writing a simple Requirements Specification for a piece of software (the test script). Just as with any specification, it should be unambiguous and as complete as possible.

    Every test case will contain the steps to be performed with the application and the expected result for each step. As a performance tester will generally not know the business processes that they will be automating, a test case should provide more detail than may be included in a functional test case intended for a tester familiar with the application.

    It is important that the test case describes a single path through the application. Adding conditional branches to handle varying application responses, such as error messages, will greatly increase script. development time and the time taken to verify that the test script. functions as expected. If a test script. encounters an error that it does not expect, it will usually just stop. If the Project Manager decides that test scripts should handle errors the same way a real user would, then information should be included on how to reproduce each error condition, and additional scripting time should be included in the project plan.

    The main reason a user may be presented with a different flow through the application is the input data that is used. Each test case will be executed with a large amount of input data. Defining data requirements is a critical part of planning for a performance test, and is the most common area to get wrong on a first attempt. It is very easy to forget that certain inputs will present the user with different options.

    The other important data issues to identify are any data dependencies and any potential problems with concurrency. Is it important that data is used in some business functions before they are used in others? And, will data modified by virtual users cause other virtual users to fail when they try to use the same data? The test tool can partition the data used by each virtual user if these requirements can be identified. It can be difficult for a performance tester to debug test script. failures with little knowledge of the application, especially if the failures only occur when multiple virtual users are running at once.

    One of the most important pieces of information a performance test is designed to discover is the response time of the system under test � both at the overall business function level and at the low level of individual steps in the test case, such as the time it takes for a search to return a result set. Any test cases provided to a performance tester should clearly define the start and end points for any transaction timings that should be included in the test results.

    It is important to remember that the test script. is only creating the network traffic that would normally be generated by the application under test. This means that any operations that happen only on the client do not get simulated and therefore do not get included in any transaction timing points. A good example would be a client application that runs on a user�s PC, and communicates with a server. Starting the client application takes 10 seconds and logging in takes 5 seconds but, since only the login is sending network traffic to the server, the transaction timing point will only measure 5 seconds.

    Operations that only happen on the client, including the time users take to enter data or spend looking at the screen is simulated with user think time � an intentional delay that is inserted into the test script. If no think time is included, virtual users will execute the steps of the test case as fast as they can, resulting in greater (and unrealistic) load on the system under test. Depending on the sophistication of the performance test tool, the user think time may be automatically excluded from the transaction timing points. Think times are generally inserted outside of any transaction timing points anyhow.

    While a functional test case will be run once from start to finish, a performance test case will be run many times (iterated) by the same virtual user in a single scenario. Information on how the test steps will be iterated should be included in the test case. For example, if a test case involves a user logging in and performing a search, and the entire test case is iterated by the virtual user; then a test scenario may be generating too many logins if the real users generally stay logged into the application. [Is there a way to break up this sentence?] A more realistic test case may have the virtual user log in once and then keep doing the same action for as long as the virtual user is run.

    When a script. is iterated, consideration should be given to the non-obvious details of how it is iterated. A good example would be a test script. simulating users using an Internet search engine. When the test script. is iterated, simulating a new search operation, should the virtual user establish a new network connection and empty their cache or should every iteration simulate the same user conducting another search?

    As all performance test tools have different default behaviours, a good performance tester should clarify this type of detail with business and technical experts. Some performance test tools make these details easier to change than others. If it is not practical to emulate all the attributes of the expected system traffic with a particular tool, then it should be noted as a limitation of the performance test effort, and a technical expert should assess the likely impact.

    Hopefully this article has provided some insight into the extra considerations that must be given when writing a performance test case, rather than a functional test case. As with any software specification, a performance test case may need to be refined as questions are raised by the performance tester.

    An example test case:
    Example performance test case 摘自http://www.myloadtest.com/

    查看(771) 评论(2) 收藏 分享 管理

  • 性能测试的调研工作之向项目经理调研

    2009-02-18 23:01:09

    一 向项目经理进行调研

    第一步 向项目经理了解性能测试工作的目标

    A工作目标

    按时完成  按质完成

    B 性能测试的性质

    诊断性质的性能测试

    调优性质的性能测试

    检测性性能测试

    一般在上线之前 必须要做的就是诊断姓性能测试，在开发和功能测试阶段要进行检测和调优性能测试。

    第二步 向项目经理了解当前的开发状态

    了解清楚当前开发状态后才能判断是否有必要对起进行性能测试，做什么类型的性能测试，

    第三步 向项目经理了解当前的版本控制状态

    版本控制的好坏对性能测试的有效性有着致命的影响。

    第四步 向项目经理来了解生产环境的基本情况

    a 网络部署 b服务器硬件部署 c操作系统部署

    d 安全性部署 e 应用平台部署 d数据库中的数据部署 e在同一个服务器上的其他程序部署

    第五步 向项目经理了解测试环境的基本信息

    第六步 向项目经理了解测试的性能指标

     

     

     

    查看(207) 评论(0) 收藏 分享 管理

  • TRUNCATE和Delete区别

    2009-02-16 21:59:17

    TRUNCATE和Delete有以下几点区别
    　　1、TRUNCATE在各种表上无论是大的还是小的都非常快。如果有ROLLBACK命令Delete将被撤销，而TRUNCATE则不会被撤销。
    　　2、TRUNCATE是一个DDL语言，向其他所有的DDL语言一样，他将被隐式提交，不能对TRUNCATE使用ROLLBACK命令。
    　　3、TRUNCATE将重新设置高水平线和所有的索引。在对整个表和索引进行完全浏览时，经过TRUNCATE操作后的表比Delete操作后的表要快得多。
    　　4、TRUNCATE不能触发任何Delete触发器。
    　　5、不能授予任何人清空他人的表的权限。
    　　6、当表被清空后表和表的索引讲重新设置成初始大小，而delete则不能。
    　　7、不能清空父表。

    TRUNCATE TABLE (schema)table_name Drop(REUSE) STORAGE
    在默认是 Drop STORAGE 当使用Drop STORAGE时将缩短表和表索引，将表收缩到最小范围，并重新设置NEXT参数。REUSE STORAGE不会缩短表或者调整NEXT参数

    在特殊情况下使用 REUSE STORAGE

    一个实际应用的典型例子：
    你用sqlldr加载一个1000万记录的数据表，但是加载了多一半的时候你发现有问题，
    这个时候你想清空表重新加载。
    那么最好 reuse storage ，这样再次加载就不需要再次寻找空闲空间了

    查看(359) 评论(0) 收藏 分享 管理

  • 细说软件测试风险级别的确定

    2009-02-15 21:39:46

    风险级别代表“如果该软件的需求（功能性）被开发人员实现以后出现了软件缺陷，那么给用户和企业带来多大的损失，损失越大，级别越高

    风险级别（A高级风险B中级风险C低级风险）

    通常情况下可用四个原则综合判断一个业务风险级别

    1 功能类型

    A高级 数据的新建、计算、验证 B中级   数据修改  C低级 数据显示

    2 业务影响

    A高级 权限合法性/经济损失/利益损失 B中级 错误信息  C低级 无

    3使用频度

    A高级 非常频繁/大量 B 中级 经常  C低级很少

    4受影响客户数量

    A高级 大量/频繁         B中级   组/群                C低级 很少

    判断

    A 两个A或着一个A两个B

    B 两个B 或一A一B

    C

     

    查看(735) 评论(0) 收藏 分享 管理

  • 如何简单理解软件测试

    2009-02-15 21:17:04

    第一：软件测试机构 的目标 “促进软件质量”

         软件开发机构保证软件质量

    第二： 软件测试到目的是发现软件缺陷

    第三：什么是软件缺陷

     A 软件没做它应该做的事情

     B软件做来它不应该做的事情

    第四 软件测试人员在第一阶段的工作任务就是要找出软件应该做到事情和不应该做的事情

     

    查看(509) 评论(0) 收藏 分享 管理

  • 软件测试部分中英文对照

    2009-02-15 21:00:47

    Acceptance testing : 验收测试
    Acceptance Testing：可接受性测试
    Accessibility test : 软体适用性测试
    actual outcome：实际结果        
    Ad hoc testing     : 随机测试
    Algorithm analysis : 算法分析
    algorithm：算法        
    Alpha testing      : α测试
    analysis：分析        
    anomaly：异常        
    application software：应用软件        
    Application under test (AUT) : 所测试的应用程序
    Architecture       : 构架
    Artifact           : 工件
    ASQ：自动化软件质量（Automated Software Quality）
    Assertion checking : 断言检查
    Association        : 关联
    Audit              : 审计
    audit trail：审计跟踪        
    Automated Testing：自动化测试

    Backus-Naur Form：BNF范式        
    baseline：基线        
    Basic Block：基本块        
    basis test set：基本测试集        
    Behaviour          : 行为
    Bench test         : 基准测试
    benchmark：标杆/指标/基准        
    Best practise      : 最佳实践
    Beta testing       : β测试
    Black Box Testing：黑盒测试        
    Blocking bug       : 阻碍性错误
    Bottom-up testing  : 自底向上测试
    boundary value coverage：边界值覆盖        
    boundary value testing：边界值测试        
    Boundary values    : 边界值
    Boundry Value Analysis：边界值分析        
    branch condition combination coverage：分支条件组合覆盖        
    branch condition combination testing：分支条件组合测试        
    branch condition coverage：分支条件覆盖        
    branch condition testing：分支条件测试
    branch condition：分支条件  
    Branch coverage    : 分支覆盖
    branch outcome：分支结果        
    branch point：分支点        
    branch testing：分支测试        
    branch：分支        
    Breadth Testing：广度测试        
    Brute force testing: 强力测试
    Buddy test         : 合伙测试
    Buffer             : 缓冲
    Bug                : 错误
    Bug bash           : 错误大扫除
    bug fix            :  错误修正
    Bug report         : 错误报告
    Bug tracking system: 错误跟踪系统
    bug：缺陷
    Build              : 工作版本（内部小版本）
    Build Verfication tests(BVTs): 版本验证测试
    Build-in           : 内置

    Capability Maturity Model (CMM):   能力成熟度模型
    Capability Maturity Model Integration (CMMI): 能力成熟度模型整合
    capture/playback tool：捕获/回放工具        
    Capture/Replay Tool：捕获/回放工具        
    CASE：计算机辅助软件工程（computer aided software engineering）
    CAST：计算机辅助测试        
    cause-effect graph：因果图        
    certification        ：证明        
    change control：变更控制        
    Change Management  :变更管理
    Change Request     :变更请求
    Character Set      : 字符集
    Check In           :检入
    Check Out          :检出
    Closeout           : 收尾
    code audit        ：代码审计        
    Code coverage      : 代码覆盖
    Code Inspection：代码检视        
    Code page          : 代码页
    Code rule          : 编码规范
    Code sytle         : 编码风格
    Code Walkthrough：代码走读        
    code-based testing：基于代码的测试        
    coding standards：编程规范        
    Common sense       : 常识
    Compatibility Testing：兼容性测试        
    complete path testing        ：完全路径测试        
    completeness：完整性        
    complexity        ：复杂性        
    Component testing     : 组件测试
    Component：组件        
    computation data use：计算数据使用        
    computer system security：计算机系统安全性        
    Concurrency user      : 并发用户
    Condition coverage    : 条件覆盖      
    condition outcome     : 条件结果        
    condition             : 条件        
    configuration control：配置控制        
    Configuration item    : 配置项
    configuration management：配置管理        
    Configuration testing : 配置测试
    conformance criterion： 一致性标准        
    Conformance Testing： 一致性测试        
    consistency        ： 一致性        
    consistency checker： 一致性检查器        
    Control flow graph    : 控制流程图
    control flow graph：控制流图        
    control flow：控制流        
    conversion testing：转换测试        
    Core team             : 核心小组
    corrective maintenance：故障检修        
    correctness        ：正确性        
    coverage        ：覆盖率        
    coverage item：覆盖项        
    crash：崩溃        
    criticality analysis：关键性分析        
    criticality：关键性        
    CRM(change request management): 变更需求管理
    Customer-focused mindset : 客户为中心的理念体系
    Cyclomatic complexity : 圈复杂度

    data corruption：数据污染        
    data definition C-use pair：数据定义C-use使用对        
    data definition P-use coverage：数据定义P-use覆盖        
    data definition P-use pair：数据定义P-use使用对        
    data definition：数据定义        
    data definition-use coverage：数据定义使用覆盖        
    data definition-use pair        ：数据定义使用对        
    data definition-use testing：数据定义使用测试        
    data dictionary：数据字典        
    Data Flow Analysis    : 数据流分析
    data flow analysis：数据流分析        
    data flow coverage：数据流覆盖        
    data flow diagram：数据流图        
    data flow testing：数据流测试        
    data integrity：数据完整性        
    data use：数据使用        
    data validation：数据确认        
    dead code：死代码        
    Debug                 : 调试
    Debugging：调试        
    Decision condition：判定条件        
    Decision coverage     : 判定覆盖
    decision coverage：判定覆盖        
    decision outcome：判定结果        
    decision table：判定表        
    decision：判定        
    Defect                : 缺陷
    defect density        : 缺陷密度
    Defect Tracking       :缺陷跟踪
    Deployment            : 部署
    Depth Testing：深度测试  
    design for sustainability :可延续性的设计      
    design of experiments：实验设计        
    design-based testing：基于设计的测试        
    Desk checking         : 桌前检查
    desk checking：桌面检查   
    Determine Usage Model : 确定应用模型   
    Determine Potential Risks : 确定潜在风险
    diagnostic：诊断        
    DIF(decimation in frequency) : 按频率抽取
    dirty testing：肮脏测试        
    disaster recovery：灾难恢复        
    DIT （decimation in time）: 按时间抽取  
    documentation testing        ：文档测试        
    domain testing：域测试        
    domain：域        
    DTP  DETAIL TEST PLAN详细确认测试计划
    Dynamic analysis      : 动态分析
    dynamic analysis：动态分析        
    Dynamic Testing：动态测试

    查看(411) 评论(0) 收藏 分享 管理

  • 功能测试流程

    2009-02-15 20:24:46

    一 可测性转化

    1. 自然语言描述   z主要从软件操作层面和应用层面来进行。在软件操作层面进行自然语言描述就是详细的描述一个最终用户怎么在软件上进行输入数据，点击按钮类操作，在软件应用层面就是最终用户软件如何解决生活上和工作上的实际问题
    2. 规则梳理  （用“如果，。。。。。那么，，，，，”语句对功能点进行梳理，使之简介明朗反映该功能点的输入和输出）将动作和输出统一称为“动作”
    3. 条件动作提炼

    二 测试需求分析

    1. 用户需求判定表 （规则梳理数量决定了判定表中逻辑数量）
    2. 测试方法生成定义 测试级别决定测试深度，同时也决定了测试方法  ，测试方法有等价类划分，边界值法，因果图法，流程图法，                                                                                                                                  
    3. 测试用例数量估算
    4. 测试工作量的估算（根据以往经验和当前工作效率进行工作目标和工作量的估算）

    三 测试用例集设计

    1. 待测特征 （=规则梳理）
    2. 方法细化 主要包括前功能和后功能以及测试数据到准备等
    3. 特征标识
    4. 通过失败准则

    四 测试用例实现

    1.  测试目的
    2. 测试数据
    3. 测试步骤
    4. 预期结果

    五测试用例执行   

                

    查看(609) 评论(0) 收藏 分享 管理

  • 什么是功能测试？

    2009-02-14 20:58:14

    提到功能测试，我们不得不先问自己什么是软件测试，软件测试是利用人工或者自动手段，来运行或测试某个系统到过程，其目的在与检验他是否满足规定到需求或弄清预期结果和实际结果之间到差别。（IEEE软件工程标准术语），

    Functional testing(功能测试)，也称为行为测试，根据产品特征，操作描述和用户方案，测试一个产品到特性和可操作行为以确定他们满足设计需求。

    查看(1072) 评论(0) 收藏 分享 管理

数据统计

  • 访问量: 7810
  • 日志数: 16
  • 建立时间: 2009-02-14
  • 更新时间: 2009-04-22

RSS订阅

Open Toolbar