表格创建
CREATE TABLE Employee
(Emp_id numeric(10,0) IDENTITY,
last_name varchar(30) NOT NULL,
first_name varchar(30) NOT NULL,
age numeric(3,0)
country varchar(30) NOT NULL
city varchar(30) NULL
)

NOTES
IDENTITY，一个表里只能定义一个标识列，默认值为(1,1),插入数据时值会递增
ROWGUIDCOL， 定义该列为行全局唯一的标识列，一个表只有一个标识符列可以定义为ROWGUIDCOL

表格的删除
DROP TABLE table_name

修改表格定义
CREATE TABLE doc_exa (colum_a INT)
ALTER TABLE doc_exa ADD column_b VARCHAR(20) NULL
ALTER TABLE doc_exa ADD column_c VARCHAR(20) NULL
ALTER TABLE doc_exa DROP column_c
ALTER TABLE doc_exa CHECK CONSTRAINT column_B
ALTER TABLE doc_exa NOCHECK CONSTRAINT column_B
ENABLE TRIGGER trigger_name
ALTER TABLE doc_exa DROP column_c
DROP TABLE doc_exa

查看表属性
sp_help table_name '查看表和表中数据列有关的信息
sp_spaceused table_name '查看表格行数和表格所用的存储空间
sp_depends table_name '查看表格的这种相关性关系

表格重命名
sp_rename old_table_name,new_table_name

索引
优点：在列上建立的一种数据库对象，对表中的数据提供逻辑排序，可以提高数据的访问速度。
缺点：过多的建立索引会占据大量磁盘空间，增加系统开销

不适用
查找小表（如100行数据）中的某些数据
查找大表中绝大多数数据

适用
查找大表中有限数量的数据，使用索引是一个不错的选择

簇族索引和非簇族索引
簇族索引按照键值对进行排列，一个表只能对应一个簇族索引
非簇族索引不根据键值排序，索引结构与数据行是分开的，查找速度明显低于簇族索引

创建索引INDEX
语法
CREATE UNIQUE CLUSTERED|NOCLUSTERED INDEX index_name ON table (column)

例
CREATE TABLE emp_pay
(employeeID int NOT NULL,
base_pay money NOT NULL,
commission decimal(2,2) NOT NULL
)
CREATE UNIQUE CLUSTERED INDEX employeeID_ind ON emp_pay (employeeID)

索引删除
DROP INDEX table.index
DROP INDEX emp_pay.employeeID

DBMS
数据库管理系统(database management system)

遍历
所谓遍历(Traversal)，是指沿着某条搜索路线，依次对树中每个结点均做一次且仅做一次访问

TOP关键字
只返回前面一定数量的数据
语法
SELECT [TOP integer|TOP integer PERCENT] column_name FROM table_name
例
select top 10 * from customer
select top 10 percent * from customer

DISTINCT关键字
优点：能够从返回的结果数据集合中删除重复行，使返回结果更简洁。
缺点：须花费额外的CPU时间来执行查询数据的分类和整理，导致查询速度变慢
例
select distinct country from publishers
注意：DISTINCT关键字作用范围是整个查询列表，而不是单一的列，如同时对两列数据进行
查询时，将返回两列数据的唯一组合。

操作查询的列名
可以用AS关键字，=号来连接
例
select title_id AS '图书代号', '原价'=price,price-price*0.3 '现价' from titles

BETWEEN,IN关键字

LIKE字句模糊查询
通配符
%：任意个字符
_：单个字符
[]：方括号里列出的任意一个字符
[^]：任意一个没有在方括号列出的字符

ESCAPE转义字符
select coll
from example
where coll like 't[X[XYZ]Z]'
escape 't'

排序ORDER BY，ASC，DESC
select strore_name,city from stores order by 1 desc
1代表所处的位置

 

INSERT添加表格数据
INSERT publishers
(pub_id,pub_name,city,state)
VALUES
('9993','SANCO','WASHINGTON','WA')

UPDATE实现数据修改
语法
UPDATE table_name
set
column_name={expression|DEFAULT|NULL}
[from table_name]
where searchcondition
例
update authors set au_lname='JOE' where au_id='172-32-1176'

update authors set state='ZZ'
from (select top 10 * from authors order by au_lname) AS t1
where authors.au_id=t1.au_id

DELETE删除表中数据
DELETE [FROM] table_name WHERE search_conditions
删除所有来自CA州的作家
delete from authors where state='CA'

删除表中每一行数据
delete from authors

TRUNCATE TABLE清空表格
清空表格中所有数据，只留下一个表格定义，执行速度比delete快,不进行日志的记录，删除数据后
无法恢复。
TRUNCATE table_name

 

视图
与直接使用表相比，视图有许多优点
1.对表中需要的数据横向(select语句实现)和纵向(where子句实现)分割,有限制的显示数据，简化
浏览数据的工作
2.简化对表格的存储操作
3.设置访问许可权限，限制用户访问，保护数据，不同用户可以建立不同视图
4.为数据库重构提供一定的逻辑独立性

 

视图创建
语法
CREATE VIEW view_name
AS
SELECT Statement
[WITH CHECK OPTION]
例
create view author_view
AS
select au_id,au_fname,au_lname
from authors

删除视图
DROP VIEW view_name

修改视图
先建立了一个可以访问所有作家的视图，然后修改定义，只有华盛顿州的作家可以被查询
create view all_authors (au_fname,u_lname,address,city,zip)
AS
select au_fname,au_lname,address,city,zip
from authors

alter view all_authors (au_fname,u_lname,address,city,zip)
AS
select au_fname,au_lname,address,city,zip
from authors
where state ='WA'

视图信息浏览
sp_help author_view '浏览视图中各列列表
sp_depends '返回引用了哪些别的数据库对象
sp_helptext '检索存储在视图，触发器，存储过程中的文本

INSERT,UPDATE与表格操作一致

删除视图中数据
通过视图删除数据最终都体现为从基本表中删除数据

WITH CHECK OPTION
使用WITH CHECK OPTION可以有效地对不合理数据进行筛选，建议使用
WITH ENCRYPTION
隐藏生成视图的代码

create view wa_publishers_2
with encyption
AS
select *
from publishers
where state='WA'
with check option

视图许可权限
不同用户授予不同使用权限
通过使用select字句限制用户对某些底层基本表列的访问
通过使用where字句限制用户对某些底层基本表行的访问

整数数据类型
bit
bigbit
int
smallint
tinyint

货币数据类型
money
smallmoney

数字数据类型
decimal
numeric

浮点数据类型
real
float

日期/时间数据类型
datetime

字符数据类型
char
varchar
text

笛卡尔乘积
问题：出现在对表格连接条件的限制上
select title_id,au_fname
from titles,authors

注意：如有N个表格出现在FROM后面，定义的连接条件不得少于N-1个

JOIN  ON关键字
JOIN用于连接两个不同的表格，ON用于给出这两个表格之间的连接条件
select titles.title_id,au_fname
from titles join titleauthor
on titleauthor.title_id=titles.title_id
join authors
on authors.au_id=titleauthor.au_id
where authors.state="CA"

另一种写法
select titles.title_id,au_fname
from titles,titleauthor,authors
where titleauthor.title_id=titles.title_id
and authors.au_id=titleauthor.au_id and authors.state="CA"

表格别名的使用
目的：简化查询语句的写法
写法1
select titles.title_id,au_fname
from titles t join titleauthor ta
on ta.title_id=t.title_id
join authors a
on a.au_id=ta.au_id
where a.state="CA"
写法2
select titles.title_id,au_fname
from titles as t,titleauthor as ta,authors as a
where ta.title_id=t.title_id
and a.au_id=ta.au_id and a.state="CA"

UNION子句
可以对UNION操作的数据集结果进行排序，把ORDER BY子句放在最后的SELECT子句后面
但排序的依据是第一个SELECT列表中的列
select state
from authors
union
select state
from publishers
order by state

统计函数
sum()
avg()
min()
max()
count()
count(*)
与统计函数一起使用distinct
select avg(qty) "avg_qty",sum(qty) "sum_qty",count(distinct stor_id)
where sales

count(*)进行行数统计
select count(*)
from publishers
where state ="CA"

GROUP BY使用方法
按某一列数值进行分类，在分类的基础上进行查询，需要使用GROUP BY
select type,pub_id,avg(price) "avg_price",sum(price) "sum_price"
from title
where type in ("business","trad_cook","mod_cook")
group by type,pub_id

HAVING关键字筛选结果
select type,avg(price) "avg_price"
from titles
where price>10
order by type
having avg(price)>18

ALL关键字
GROUP BY子句中提供了All关键字，只有当select语句中，同时使用了where子句的情况下才有
意义，如使用了All关键字，所有被GROUP BY子句分类的数据集都将出现在结果集中
select type,pub_id,avg(price) "avg_price",sum(price) "sum_price"
from title
where type in ("business","trad_cook")
group by all type,pub_id
order by type

CUBE关键字
多维立方体，数据列的数据进行交叉组合产生的结果集。
select type,pub_id,avg(price) "avg_price",sum(price) "sum_price"
from title
where type in ("business","trad_cook","mod_cook")
group by type,pub_id
with cube

ROLLUP关键字
类似CUBE关键字，但能够压缩掉无意义的行
select type,pub_id,avg(price) "avg_price",sum(price) "sum_price"
from title
where type in ("business","trad_cook","mod_cook")
group by type,pub_id
with rollup

COMPUTE,COMPUTE BY
select type,price,advance
form. titles
order by type
compute sum(price),sum(advance) by type

嵌套查询中使用EXISTS关键字
select title_id,au_id
from titleauthor
where exists
(select *
from authors
where authors.au_id=titleauthor.au_id
and state="CA"
order by title_id

列清单中使用嵌套查询
select a.au_lname,t.title_id,
"Quantity Sold" = (select sum(qty) from sales where title_id=t.title_id)
from authors a,titles t,titleauthors ta
where a.state="CA"
and a.au_id=ta.au_id
and ta.title_id=t.title_id
order by a.au_lname

 

 

约束
列级约束:列级约束是行定义的一部分，只能应用爱一列上
表级约束:表级约束的定义独立于列的定义，可以应用在一个表中的多列上

浏览具体表的约束信息
sp_helpconstraint table_name

PRIMARY KEY约束
利用表中的一列或多列数据来唯一地标识一行数据，为了有效实现数据管理，
每一张表都应该有自己的主键，且只能有一个主键(PRIMARY KEY约束唯一性)

主键操作
在创建表格时，定义主键，主键是表格定义的一部分。
主键添加
修改或删除表上已经定义的主键
--主键已存在，先删除，再建立
--主键被外键引用，可以先删外键，再删主键

列级主键约束
create table test1
(
job_id smallint identity(1,1) primary key clustered,
job_desc varchar(50) not null
default
)
表级主键
create table test2
(
event_type int,
event_time datetime,
event_site char(50),
event_desc char(1024),
constraint even_key primary key (event_type,event_time)
)

查看主键信息
sp_pkey table_name

主键删除
alter table test1
drop constraint pk_test1_440b1d61

主键修改
alter table test1
add constraint pk_id primary key clustered (job_id)

UNIQUE约束
用来确保不受主键约束的列上的数据唯一性

PRIMARY KEY约束与UNIQUE约束区别
UNIQUE约束主要用在非主键的一类或多列上要求数据唯一的情况
UNIQUE约束允许在该列上存在NULL值，主键不允许
一个表上可以设置多个UNIQUE约束，而一个表上只能设置一个主键

UNIQUE约束操作
在创建表格时，定义UNIQUE约束，UNIQUE约束是表格定义的一部分。
UNIQUE约束添加
修改或删除表上已经定义的UNIQUE约束
--UNIQUE约束已存在，先删除，再建立
--UNIQUE约束可以在列级或表级上设置

create table test3
(
event_name char(20),
event_type char(20),
event_time datetime,
event_id int primary key clustered,
constraint uniq_event unique (event_type,event_time)
)

删除UNIQUE方法
添加UNIQUE方法
--同PRIMARY KEY

CHECK约束
检查数据值的合理性来实现数据的完整性
create table sales
(
saleid int identify(100000,1) not for replication,
check not for replication (saleid<=199999),
salesregion char(2),
constraint id_pk primary key (saleid)
)

表上所有约束无效
alter table authors
nocheck constraint all

FOREIGN KEY约束
用来维护两个表之间的一致性关系，外键的建立主要是通过将一个表中的主键所在列包含在另
一个表中，这些列就是另一个表的外键

 

 

局部变量
可以在一个DECLARE语句中声明多个变量
DECLARE @LastName NVARCHAR(30),
  @FirstName NVARCHAR(30),
  @State NCHAR(2)
  

局部变量赋值
SELECT语句赋值
SET语句赋值
查询功能和赋值功能不能混合使用

DECLARE @MyCounter INT
SELECT @MyCounter=20

DECLARE @row int
SET @row = (select count(*) from authors)

全局变量
用来记录SQL Server服务器活动状态的一组数据。

IF ELSE条件判断结构
BEGIN  END语句块
可以将一组SQL语句封装成一个完整的SQL语句块

if (select avg(price) from titles where type = "business")< $20

BEGIN
print "这是一些优秀的经济类书籍："
select title
from titles
where type="business"
END

else
print "平均书价超过$20."

WHILE循环结构
在满足条件的情况下，重复执行同样的语句

WHILE NOT EXISTS(SELECT price
      from titles
      WHERE price <$30)
BEGIN
UPDATE titles
SET price = price * 1.5
SELECT MAX(price) FROM titles
IF (SELECT MAX(price) FROM titles) > $50
BREAK
ELSE
CONTINUE

CASE多选择
CASE语句可以更方便地实现多重选择的情况，可以避免编写多重的IF THEN嵌套循环。
select "作者"=
 case
  when "CA" then "来自加利福尼亚"
  when "KS" then "来自堪萨斯州"
  when "MI" then "来自马萨诸塞州"
  when "IN" then "来自印第安纳州"
  when "TN" then "来自田纳西州"
  else "来自其他州"
 end
 au_fname+"."+au_name
 from authors
 order by state
 
 
游标
游标类似C语言的指针一样的语言结构，数据库执行的大多数SQL命令都是同时处理集合内部的所有
数据，有时候用户也需要对这些数据集合中的每一行进行操作。如果没有游标，这种工作不得不放
到数据前端，用高级语言实现。这将导致不必要的数据传输，从而延长执行的时间。通过游标可以在
服务器端有效地解决这个问题

事务
BEGIN TRANSACTION transaction_name
开始一个事务单元
COMMIT TRANSACTION transaction_name
完成一个事务单元
ROLLBACK TRANSACTION transaction_name
回滚一个事务单元
SAVE TRANSACTION savepoint_name
设置保存点

回滚：只有在保存点到回滚语句之间的操作被取消。
BEGIN TRANSACTION exampletrans
USE pubs
GO
UPDATE titleauthor
SET royaltype =35
FROM titleauthor,titles
WHERE royaltyper =25
AND titleauthor.title_id=titles.title_id
AND title= 'The Gourmet Microwave'
GO
SAVE TRANSACTION percentchange
UPDATE titles
SET price = price * 2
WHERE title= 'The Gourmet Microwave'
GO
ROLLBACK TRANSACTION percentchanged
PRINT "程序继续执行"
COMMIT TRANSACTION

存储过程
是一组预先编译好的Transact-SQL代码。
既可以作为数据库的对象，也可以作为一个单元被用户调用

存储过程类似其它编程语言里的过程(procedure)
存储过程可以接收参数，并以输出参数的形式返回多个参数给调用存储过程的过程或批处理
存储过程也可以容纳对数据库进行查询、修改的编程语句，也可以调用其他的存储过程
可以返回执行存储过程的状态值以反映存储过程的执行情况
存储过程不同于函数，存储过程不能在被调用的位置上返回数据，也不能被应用在语句当中
USE pubs
GO
IF EXISTS (SELECT name FROM sysobjects
     WHERE name = 'au_info' AND type='p')
DROP PROCEDURE au_info
GO
CREATE PROCEDURE author_information
AS
SELECT au_lname,au_fname,title,pub_name
FROM authors a
JOIN titleauthor ta
ON a.au_id=ta.au_id
JOIN titles t
ON t.title_id=ta.title_id
JOIN publishers p
ON t.pub_id=p.pub_id
GO

存储过程管理
查看存储过程文本信息
sp_helptext author_information

修改存储过程的名字
sp_rename author_information,authors_information

存储过程执行
EXECUTE procedure_name

删除存储过程
DROP procedure procedure_name

修改存储过程
同Create

通过存储过程传递参数

USE pubs
GO
IF EXISTS (SELECT name FROM sysobjects
     WHERE name = 'titles_sum' AND type='p')
DROP PROCEDURE titles_sum
GO

CREATE PROCEDURE titles_sum @TITLE varchar(40)='%',@sum money OUTPUT
AS
SELECT 'Title Name'=title
FROM titles
WHERE title LIKE @TITLE

SELECT @SUM = SUM(price)
FROM titles
WHERE title LIKE @TITLE
GO

　　测试是一种思维，包括情感思维和智力思维，情感思维主要体现在一句俗语：思想决定行动上（要怀疑一切），智力思维主要体现在测试用例的设计上。具有了这样的思想，就会找出更多的bug。（^_^个人认为，不代表官方立场）

　　对于一个web网站来说，主要从这么几个大的方面来进行测试：

1、 功能测试；2、 界面测试；3、 易用性测试；4、兼容性测试；5、 链接测试；6、 业务流程测试；7、 安全性测试

下面主要从以上七个方面进行叙述：

 

一、功能测试

测试用例是测试的核心，测试用例的设计是一种思维方式的体现，在用例的设计中，用的比较多的方法是边界值分析法和等价类划分法，下面主要从输入框，搜索功能，添加、修改功能，删除功能，注册、登录功能以及上传图片功能等11个方面进行总结说明。

1、输入框

输入框是测试中最容易出现bug的地方，所以在测试时，一定要多加注意。

 

 

 

2、搜索功能

（1）比较长的名称是否能查到？

（2）空格 或空

（3）名称中含有特殊字符，如：' $ % & *以及空格等

（4）关键词前面或后面有空格

（5）如果支持模糊查询，搜索名称中任意一个字符是否能搜索到

（6）输入系统中不存在与之匹配的条件

（7）两个查询条件是否为2选1，来回选择是否出现页面错误

（8）输入脚本语言,如：<script>alter(“abc”)</script>等

 

3、添加、修改功能

（1）是否支持tab键

查看(1942) 评论(15) 收藏 分享 管理

　　新年第一天到公司，没啥事情，把之前写的一篇文章写完，发布出来，比较长哦，其实还有好多东西没写，人都是比较懒啦，总之希望能给大家一些帮助吧:)

==============

　　已经不准备在这里待下去了，所以动作多了一些，这两个月认识了不少猎头，也面试了不少公司，给自己稍微总结一下，尽管自己面试过的人也有几百个了，自己这段时间被面也有点新的收获，呵呵，希望从interviewer + interviewee两方面讲讲，也能给后来的朋友一些帮助

　　首先，我们要搞清楚自己到底想去怎样的企业，是外企（美国，欧洲，印度），还是内企（民企或者国企），是搞外包的，还是有自己的产品的，是大型的企业（Top 500），还是发展潜力比较好的？一句话，搞清楚自己到底想要什么。是发展前途，还是“钱”！从HR或者interviewer的角度看，明确自己目标的人，比较受欢迎。我面试过程中，遇到好几个HR，在英文面试的时候，都会让我用英语讲一下自己的Career Plan，而英语表达，我觉得最重要的是言之有物，就是观点一定要明确，这样说的时候，别人也容易听懂，自己也容易表达。用英语表达很细腻含糊的概念是很困难的（起码对我来说是这样），而且对方的HR如果是中国人也不一定能听懂，呵呵。所以这边的意思你要有了相当清晰的认识，才容易表达自己，无论英语还是中文。

　　第二，精心修改简历。这个过程，其实是个漫长的过程，每个月，或者每当自己有所新的大的认识提高就可以更新一次简历。其实人需要经常对自己的工作做一些体悟，感悟，最好能将工作和生活中的某些事情能够从本质上统一起来，因为本身世界上道理都是相通的。自己在写简历的时候，要一边修改，一边想，面试者可能会针对你这个简历问什么样的问题，你需要用实际工作中的怎样一个具体的例子来解释这个事情。然后，同时如果有相关的感悟，这时候，在面试的时候，就可以把感悟说出来，这样，会令面试官知道你不是死学，而是活学活用，企业很喜欢这样的人。如果你认识的非常深刻，则会给面试官相当不错的印象的，因为面试官他自己可能都没你认识的深刻，呵呵！所以说，修改简历，不仅仅是改文字，而且是准备好自己的思想和语言。

　　第四，面试！第一关，一般是HR，或者猎头先跟你联系，他们目的是要把握基本的个人信息的完整性和正确性，还有个人素质的感觉。会问一些你的情况，是否真的想要换工作，为什么要换工资，然后你的技能跟他们的岗位是否匹配啊之类的信息。这时候，我个人觉得，两方面，我比较喜欢实话实说，不要说谎，做个诚实的人，心理坦荡，有底气。但是，如果你决定要说谎的话，请不要让对方拆穿你的谎言。其实我以前面试别人的时候，看到过不少人撒谎哦，虽然没拆穿，但是，对这个人印象就不好了。比如，一个家伙他没有任何测试经验，但我感觉他基础还行，准备要他，然后，他说他对测试真的非常感兴趣。我就问他，你既然说你很感兴趣，你看过什么测试方面的书么？他有点支支吾吾，我又问你做过测试方面的什么试验么？他更是支支吾吾。这样搞得就很囧了。

　　对于HR，一般好公司，HR都会问一下你的薪资需求，因为，如果你的要求太高，人家满足不了，也就不用安排后面的面试了。对于自己目前的薪资情况，也没必要撒谎，因为可能到时候要提供自己目前的工资证明的。所以，这时候，对自己要求的薪资应该有个明确的需求，没必要含含糊糊的。不过，我这次就遇到过一个本地的企业，号称是美国的企业，HR水平比较菜，不管三七二十一，就让我过去面试，我都怀疑他们给不起薪水，然后还是决定去了，想练习一下自己么，结果过去一看，压根就是差距很远，只不过是个华人开的，而且管理各方面也都很国企的感觉，面试管的素质也很差。哎，真的浪费时间。

　　第五，面试，第二关，这里说的是一般的情况下的第二关面试，因为我面试过一个top500，他们第二关是英语面试，还有一般的技术了解，然后第三关才是真正的技术面试。我们这里第二关就算是技术面试吧，一般情况下，这个技术面试，是比较简单的，大致的了解，比如linux, DB，之类的都会问到，以确保你知识的全面性。这个只要自己平时有所准备，面试之前稍微总结一下就好了。

　　第六，面试，第三关，一般，这个面试，也是技术面试，更加专业一点的，专门针对他们的技术需求的，比如就是搞自动化的，或者性能测试的。这个有一定难度。这个过程我觉得，最重要的一点就是，保持思路清晰，不要东拉西扯，或者不懂装懂（如果你要装懂，你就要确保别人不会发现你是装懂）。这个专业性的东西，自己之前一定要有自己的一套思路，比如，如果是搞性能的，最好能有自己的一套体系和方法，然后，在这里侃侃而谈，呵呵。如果这个面试也是英文的话，在面试之前，需要好好看看相关概念的英文描述，要不然到时候，可能有些语言不好表达。

　　第七，面试，第四关，如果上面技术面试都没问题了，后面，可能会遇到一个manager，主要跟你谈一下公司的情况，或者以后需要的工作，了解一下，两个人的合作方式啊之类的。呵呵，这个面试，可以说重要，也可以说不重要，如果面的好，你可以，一下子就把你未来的领导搞定。如果面试的不好，搞不好你就没机会了，其中滋味，进公司就知道了哦。

　　总结：上面啰嗦了好多，下面罗列几个面试重点问题和分析：

1	简单的谈一下自己。	观察应试者的语言是否流畅、有条理、层次分明，讲话的风度如何。
2	请你告诉我你的一次失败经历。	如果能迅速作答，则应试者反应灵敏，或可能是应试者善于总结教训。
3	你有什么优点和缺点。	应试者对自己的判断是否中肯，自信、自卑和自傲倾向如何。
4	请讲述一次让你很感动的经历。	考察应试者是否有感性。

　　其实这些问题，一般都是问刚毕业的年轻人的，工作过几年之后，基本上就不会问这么傻乎乎的问题了，呵呵。一般会问些下面的问题：

1	请谈谈你在选择工作时都考虑哪些因素？	同时可判断对方的分析能力和自知力
2	说一下你的工作经历，	了解技术背景，还有能力
3	你为什么离开前面几个公司？	看看是否稳定工作，是否有明确的职业规划

　　最后说一点，无论是否被录用，都不能让所有的面试管都对你不满意，最起码要有几个人能感觉你这个家伙还不错，只是某方面稍微有点缺憾，或者说不适合自己公司，这才能说明，你的面试基本上是成功的，要不然，真的算是失败了。我面试了几个公司，最后因为各种愿意，放弃了，但是，人家HR还是觉得跟我聊的很愉快，甚至会问，如果以后再有其他岗位机会，能否继续再合作（也许有虚假成分，呵呵），不过，很多HR根本可以不跟你说这个话，也许可以说，基本上对你这个人的素质还是认可的。你也容易从中找到自己需要改进的地方。

　　关于面试的东西，太多了，先总结这么多吧。

SQL DML 和 DDL

可以把 SQL 分为两个部分：数据操作语言 (DML) 和 数据定义语言 (DDL)。

SQL (结构化查询语言)是用于执行查询的语法。但是 SQL 语言也包含用于更新、插入和删除记录的语法。

查询和更新指令构成了 SQL 的 DML 部分：

• SELECT - 从数据库表中获取数据
• UPDATE - 更新数据库表中的数据
• DELETE - 从数据库表中删除数据
• INSERT INTO - 向数据库表中插入数据

SQL 的数据定义语言 (DDL) 部分使我们有能力创建或删除表格。我们也可以定义索引（键），规定表之间的链接，以及施加表间的约束。

SQL 中最重要的 DDL 语句:

• CREATE DATABASE - 创建新数据库
• ALTER DATABASE - 修改数据库
• CREATE TABLE - 创建新表
• ALTER TABLE - 变更（改变）数据库表
• DROP TABLE - 删除表
• CREATE INDEX - 创建索引（搜索键）
• DROP INDEX - 删除索引

 

SQL SELECT DISTINCT 语句

在表中，可能会包含重复值。这并不成问题，不过，有时您也许希望仅仅列出不同（distinct）的值。

关键词 DISTINCT 用于返回唯一不同的值。

SELECT DISTINCT Company FROM Orders

 

Update 语句

Update 语句用于修改表中的数据。

UPDATE Person SET Address = 'Zhongshan 23', City = 'Nanjing'
WHERE LastName = 'Wilson'

 

DELETE 语句

DELETE 语句用于删除表中的行。

DELETE FROM Person WHERE LastName = 'Wilson'

DELETE FROM table_name

 

TOP 子句

TOP 子句用于规定要返回的记录的数目。

对于拥有数千条记录的大型表来说，TOP 子句是非常有用的。

注释：并非所有的数据库系统都支持 TOP 子句。

SELECT TOP 2 * FROM Persons

SELECT TOP 50 PERCENT * FROM Persons

 

LIKE 操作符

LIKE 操作符用于在 WHERE 子句中搜索列中的指定模式。

SELECT * FROM Persons WHERE City LIKE 'N%'

SELECT * FROM Persons WHERE City NOT LIKE '%lon%'

 

SQL 通配符

在搜索数据库中的数据时，SQL 通配符可以替代一个或多个字符。

SQL 通配符必须与 LIKE 运算符一起使用。

在 SQL 中，可使用以下通配符：

通配符	描述
%	替代一个或多个字符
_	仅替代一个字符
[charlist]	字符列中的任何单一字符
[^charlist] 或者 [!charlist]	不在字符列中的任何单一字符

 

SELECT * FROM Persons WHERE City LIKE '%lond%'

SELECT * FROM Persons WHERE LastName LIKE 'C_r_er'

选取居住的城市以 "A" 或 "L" 或 "N" 开头的人

SELECT * FROM Persons WHERE City LIKE '[ALN]%'

不以 "A" 或 "L" 或 "N" 开头的人

SELECT * FROM Persons WHERE City LIKE '[!ALN]%'

 

IN 操作符

IN 操作符允许我们在 WHERE 子句中规定多个值。

SELECT * FROM Persons WHERE LastName IN ('Adams','Carter')

 

SQL Alias

通过使用 SQL，可以为列名称和表名称指定别名（Alias）。

SELECT po.OrderID, p.LastName, p.FirstName
FROM Persons AS p, Product_Orders AS po
WHERE p.LastName='Adams'
WHERE p.FirstName='John'

使用一个列名别名

SELECT LastName AS Family, FirstName AS Name
FROM Persons

 

SQL JOIN

除了我们在上面的例子中使用的 INNER JOIN（内连接），我们还可以其他几种连接。

下面列出了您可以使用的 JOIN 类型，以及它们之间的差异。

• JOIN: 如果表中有至少一个匹配，则返回行
• LEFT JOIN: 即使右表中没有匹配，也从左表返回所有的行
• RIGHT JOIN: 即使左表中没有匹配，也从右表返回所有的行
• FULL JOIN: 只要其中一个表中存在匹配，就返回行

SELECT Persons.LastName, Persons.FirstName, Orders.OrderNo
FROM Persons
INNER JOIN Orders
ON Persons.Id_P = Orders.Id_P
ORDER BY Persons.LastName

SELECT Persons.LastName, Persons.FirstName, Orders.OrderNo
FROM Persons
LEFT JOIN Orders
ON Persons.Id_P=Orders.Id_P
ORDER BY Persons.LastName

SELECT Persons.LastName, Persons.FirstName, Orders.OrderNo
FROM Persons
RIGHT JOIN Orders
ON Persons.Id_P=Orders.Id_P
ORDER BY Persons.LastName

目前市场主流的测试工具和管理软件，如Rational和Mercury的系列产品，大多比较昂贵。（godn_1981批注：并且更可恶的是对中文字体支持的都不太好） 商业软件的优势主要表现在其售后服务和工具本身的强大和易用性上，而作为技术基础相对较好的测试人员，也可考虑使用开源的软件，这将为公司节省一大笔开支，必要时也有更好的扩展自由度。

（一）开源测试工具——功能测试工具

Linux Test Project
http://ltp.sourceforge.net/
工具描述:
Linux Test Project是一个测试Linux内核和内核相关特性的工具集合。该工具的目的是通过把测试自动化引入到Linux内核测试，提高Linux的内核质量。
使用环境: Linux

MaxQ
http://maxq.tigris.org/
工具描述:
MaxQ是一个免费的功能测试工具。它包括一个HTTP代理工具，可以录制测试脚本，并提供回放测试过程的命令行工具。测试结果的统计图表类似于商用测试工具，比如Astra QuickTest和Empirix e-Test，这些商用工具都很昂贵。MaxQ希望能够提供一些关键的功能，比如HTTP测试录制回放功能，并支持脚本。
使用环境:
Java 1.2以上版本

WebInject
http://www.webinject.org/
工具描述:
WebInject是一个针对Web应用程序和服务的免费测试工具。 它可以通过HTTP接口测试任意一个单独的系统组件。可以作为测试框架管理功能自动化测试和回归自动化测试的测试套。

使用环境:
Windows, OS Independent, Linux

（二）开源测试工具——性能测试工具

Apache JMeter
http://jakarta.apache.org/jmeter/
工具描述:
Apache JMeter是100％的Java桌面应用程序，它被设计用来加载被测试软件功能特性、度量被测试软件的性能。设计Jmeter的初衷是测试Web应用，后来又扩充了其它的功能。Jmeter可以完成针对静态资源和动态资源（讹误女监, Servlets, Perl脚本, Java对象, 数据查询s, FTP服务等）的性能测试。Jmeter可以模拟大量的服务器负载、网络负载、软件对象负载，通过不同的加载类型全面测试软件的性能。Jmeter提供图形化的性能分析。

使用环境:
Solaris, Linux, Windows (98, NT, 2000). JDK1.4以上.

DBMonster
http://dbmonster.kernelpanic.pl/

工具描述:
DBMonster是一个生成随机数据，用来测试SQL数据库的压力测试工具。

使用环境: OS Independent

OpenSTA (Open System Testing Architecture)
http://portal.opensta.org/index.php

(godn_1981批注：不过我当年曾用同样的环境，同样的程序，用OpenSTA和LR测试出来的性能结果差距很大，不知道谁会更准一点，可能LR吧)

工具描述：

基于CORBA的分布式软件测试构架。使用OpenSTA，测试人员可以模拟大量的虚拟用户。 OpenSTA的结果分析包括虚拟用户响应时间、web服务器的资源使用情况、数据库服务器的使用情况，可以精确的度量负载测试的结果。
使用环境：OS Independent

TPTEST
http://tptest.sourceforge.net/about.php
工具描述：

TPTest的提供测试Internet连接速度的简单方法。

使用环境：

MacOS/Carbon、 Win32

Web Application Load Simulator
http://www.openware.org/loadsim/index.html

工具描述:
LoadSim是一个网络应用程序的负载模拟器。
使用环境：

JDK 1.3以上

（三）开源测试工具——缺陷管理工具

Mantis
http://mantisbt.sourceforge.net/

(godn_1981批注：强力推荐，非常好用，个人觉得从纯bug管理来说，比Td好用)

工具描述：

Mantis是一款基于WEB的软件缺陷管理工具，配置和使用都很简单，适合中小型软件开发团队，关于Mantis的介绍文章参见51testing软件测试网顾问蔡琰的文章 《使用开源软件 Mantis 实施缺陷跟踪的成功实践》

使用环境: MySQL, PHP

Bugzilla
http://www.mozilla.org/projects/bugzilla/
工具描述:
一款不错的软件缺陷管理工具。
TBC

（四）开源测试工具——测试管理工具
TestLink
http://testlink.sourceforge.net/docs/testLink.php
工具描述:
基于WEB的测试管理和执行系统。测试小组在系统中可以创建、管理、执行、跟踪测试用例，并且提供在测试计划中安排测试用例的方法。
使用环境: Apache, MySQL, PHP

Bugzilla Test Runner
http://sourceforge.net/projects/testrunner/
工具描述:
Bugzilla Test Runner基于Bugzilla缺陷管理系统的测试用例管理系统。
使用环境:
Bugzilla 2.16.3 or above

本周51testing有zhuzx问到这个问题，这个问题问的真是很帅很高深。我想这样的问题是没有标准答案的，各自按照自己的经验和实践来给出自己的看法，在此我也聊聊我的看法，仅一家之言，欢迎讨论。

说到软件缺陷预防技术吧，其实什么是缺陷预防，就是说能把缺陷消灭在萌芽状态，就是能在缺陷还没产生出来就已经被扼杀了，这也是软件测试者所追求的最高境界。一般的软件测试属于后来弥补型，产生bug之后再来修改，但是bug发现越晚，修改掉花的代价就越大，所以软件缺陷预防技术就是项目生命周期的早期消灭bug。

一般常用的缺陷预防有几个阶段，需求阶段，设计阶段，编码阶段。

第一，在需求阶段，最重要的事情是需求验证。一般验证的几个大项是，功能是否完整，是否考虑性能，有没有模糊需求，有没有考虑安全性，有没有冗余和错误的需求，需求是不是过于苛刻，需求是不是矛盾等方面。一般常用的方法是列出需求检查表，并进一步执行需求/测试 矩阵。

第二，设计阶段，这个阶段主要通过技术评审测试逻辑设计。常用比较规范的作法是建立过程/数据矩阵，也就是CRUD矩阵，把过程影射到实体，把整个程序的数据的生命周期（建立，更新，读取，删除）反映出来。

第三，编码阶段，这个阶段预防措施主要有统一编码规范，代码评审，单元测试。统一代码规范一般是开发经理统一要求，代码评审则是互相评审或者开发leader进行评审，最后最重要的则是单元测试，就是一般说的白盒测试。

再来说缺陷分析吧，很多很高深的分析技术也不很实用，我只介绍一点常用的分析方法。

1.模块的缺陷分布，一般用柱状图或饼状图，就是每一个功能模块发现bug的比例，发现bug最多的模块证明在发布以后需要更多的维护。

另外，历史数据可以参照，譬如上一个版本在哪个模块发现的bug比例对这个版本就是一个参考。如果，某个模块发现bug的比例比上个版本大幅下降，则很可能说明该模块还需要更多测试。

2.缺陷的起因分布，一般用柱状图或饼状图，一般可分为架构缺陷、功能缺陷、易用性缺陷、性能缺陷、安全性缺陷、界面文字缺陷。一般如果架构缺陷占的比例较大，则说明设计有很大问题。

3.按照不同发现人员的缺陷分布，一般用柱状图或饼状图，一般分为测试人员发现，开发人员发现，beta测试发现，外部客户发现。如果测试人员发现的bug低于某个比例，证明质量保证测试不足。

4.按照不同方式的缺陷分布 ，一般有需求审查，设计测试，代码走查，JAD，手工测试，自动化测试，白盒测试。一般来说，如果通过需求审查，设计测试，代码走查，JAD发现的bug比重很低则说明测试前期重视不够，另外，在手工测试和自动化测试之间的比例也能说明自动化测试的贡献度。

5.缺陷差额分析，就是已经发现的和已经解决的曲线关系，以时间为横轴，两者越接近说明产品质量越高

6.按照时间段的缺陷分布，一般用时间为横轴的曲线图表示，主要说明在哪个阶段发现的bug最多，对测试总结有指导意义

7.Rayleigh分析，就是俗称的零缺陷追踪法，一般截至某个时间点发现的缺陷总数和时间有一个函数关系（一个复杂的数学函数），一般用这个函数来推测经过多少天测试之后软件中大概还有多少个bug，以及交付到用户手中之后大概还能出现多少个bug。不过由于本人严重怀疑该方法的实用性，我还没用过。

一不小心，罗罗嗦嗦这么多，希望对大家有帮助，哪怕是一点点，也希望大家多探讨探讨。

 

看到有人提到这个问题，就来凑凑热闹，结合实践谈谈我的看法。

既然是说到如何编写有效的测试报告，那么我的重点就是在于有效，而不是一般的洋洋洒洒几千字的非常八股文的测试报告，有时候怎么说呢，唉，生在中国就不得不搞一些形象工程，所以，一说到报告大家的概念好像就必须是洋洋洒洒罗罗嗦嗦繁冗复杂的数千字……不过，我在这里不想谈那个“政绩报告”。偶是一个非常实用主义者。

废话少说，我们要说的是如何做有效的测试报告。

既然说到有效，我觉得要有两个特点：完整和实用，突出重点。引用一句广告词就是说“简约而不简单”，就是说要完整但又不说废话，能肥则肥，能瘦则瘦，重点部分要突出，要细说，非重点部分，一笔带过，只是为了保证一个文档的完整性。

说到一个测试报告，是对测试的过程和结果的汇总描述，所以其核心内容是两个，一个是测试结果的汇总报告，一个是测试过程的汇总总结，前者是针对所测软件本身，是给所测软件一个客观真实的评价；后者则是针对过程改进，回顾测试流程中存在的不足，加以总结改进。除了这两项核心内容之外，其他的内容都是次要的，但是为了保持文档的美观性和周全性，其他各部分还是要写写的。

具体说一般一个测试报告有如下部分构成，下面一一细说。（下面也是我在我们公司执行的模板）

1.引言

这个不用多说了，一般包括编写目的，项目背景介绍，参考资料等等，该项基本可以随便写写。（只是为了保持文档的完整性）

2.测试用例设计

对用例设计做一个简单的描述，包括测试范围阿，测试目标阿，测试重点阿等。该项基本可以随便写写。（只是为了保持文档的完整性）

3.测试环境

主要描述测试所用环境，包括硬件环境和软件环境，服务端和客户端。该项比较重要。

4.测试方法

主要描述测试过程中自己用到什么测试方法，白盒还是黑盒，哪些部分用了自动化，用多少。该项比较重要。

6.测试时间安排（执行情况）

主要描述测试过程，每个时间段都做了什么事情。该项必不可少。

7.缺陷汇总及分析

7.1缺陷总结

一般按照严重程度，功能模块进行划分。能画图就画个图吧，直观一点。该项很重要，绝不可少。

7.2缺陷分析

通过上面7.1的总结，对bug进行分析。这项是测试报告的核心所在，一般有缺陷功能模块分析，缺陷类型分析和缺陷发现阶段分析，具体更多方法参见我的另一篇博文：http://www.51testing.com/?1592/action_viewspace_itemid_85427.html  该项很重要，绝不可少。

7.3遗留问题

目前软件残存的已知问题。有些是解决不掉的问题。该项很重要，绝不可少。

7.4测试结论

基于以上分析，给被测软件一个全面客观真实的结论，功能如何，性能如何，稳定性，安全性等等给出一个评价。该项最重要，绝不可少。

8.测试过程改进

对整个测试活动进行一个总结，有哪些得失，测试方法和流程需要哪些改进，测试过程中暴露出哪些问题，有哪些好的地方值得发扬等等。该项很重要，绝不可少。

9.附录

一般附上缺陷列表以及执行过的测试用例地址等。该项基本可以随便写写。（只是为了保持文档的完整性）

上面这个只是我个人比较常用的模板，仅供参考。我觉得写文档要有模板，但模板只限于统一规范和格式（一般公司内部的文档要统一规范，要不大家各写各的就乱了），模板还有一个好处是引导思路，但是写文档不要拘泥于模板，还是要根据自己的需要，实用一点。

最后，啰嗦一句，其实测试总结报告不是仅仅为了应付测试经理或者领导，任何事情好好去做了就又是一回事，我觉得作为一个测试人员，静下心来对自己几个月的测试工作有一个深入的总结，也能够使经验得到积累，意识得到升华，何乐而不为呢？不能抱着应付的态度，总结是提高自己的必经之路。

这就是如何才“有效”！

 

 

看到了一篇WEB测试的，感觉还不错！所以就放在这里来，方便下次查看。

测试人员容易遗漏一些隐藏的缺陷

  

通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。但是，在系统测试和确认测试中，测试人员容易遗漏一些隐藏的缺陷。众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括：

 

1、安装缺陷

 

通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失;使用绝对路径;安装顺序没有说明书。

 

2、配置文件

 

有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的!这是一个安全隐患。另外，有些安装文件的 XML 文件，为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。所以，配置文件可能成为软件安全方面的一个缺陷。

 

3、网页安全缺陷

 

现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE 窗口输入，可以绕过登陆直接访问。也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。

 

网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。

 

4、判断顺序/逻辑缺陷

 

对界面进行多个输入判断的时候，非常容易出现这种问题。例如判断年月顺序，判断长度，判断非空等。假如操作员仅仅满足单个条件，保存不能成功;而按界面从上之下顺序一一满足条件之后，保存是没有问题的。但是，改变一下输入的次序，校验失效。例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看看代码是否强健，是否在判断逻辑上没有错误。良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。

 

5、调试语句和冗余信息

 

维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为系统发生了严重故障，从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用，其结果可想而知;而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。

 

同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。

 

6、不可重现的故障

 

新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗?回答是肯定的。测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。

 

7、多节点的逆向流转缺陷

 

当前软件不少喜欢使用工作流来驱动。工作流的问题，就是可能出现多个流向分支。测试容易忽略的部分，就是工作流多节点的逆向流转。例如，通过不通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外，有些时候默认分支在向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。

 

8、输入框缺陷

 

试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候，输入框会根据长度大小自动截断输入长度。但是用鼠标，截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了，保存的时候，数据库崩溃。有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。

 

输入框可以说是问题最多的部分，能够引起的麻烦也很多。日期、数字、文本等等，都需要耐心的测试一下。

 

9、界面布局缺陷

 

曾经有一次，项目经理回来向测试部反映一个问题，客户对界面不满意。原因很简单，因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员，很容易误按。这个问题是测试人员没有意料到的，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

 

界面布局还可能发生在窗口最大化和最小化上，有可能窗口缩小的时候没有下拉框或不匹配分辨率，对用户来讲，这个错误实在很低级。有些用户由于操作习惯，非常不喜欢腾出手使用鼠标，尤其是大量输入的界面，因此，要注意设置键盘的快捷方式。还有，按 Tab定位到下一焦点时要注意顺序，避免跳转太灵活而让操作人员感到无从适应，在界面进行维护或者修改的时候，不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。

 

10、版本和补丁包的环境问题

 

理论上讲，这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包，问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例，多用不同软件版本的机器跑一跑。软件测试有个定律是：你没跑过的地方，就一定会出事。经常听到开发人员抱怨，怎么我的机器没问题，你的机器就有事了呢?这不能完全靠配置管理员解决问题，环境配置项是大家最容易忽略的。

 

11、用户管理缺陷

 

用户管理的角色和授权需要好好研究一下，作过测试的人员都知道，有时候为了测试的方便，测试用户都是具有超级权限的用户。而且，比较容易忽略用户管理这一部分的测试。往往发往客户的时候，很多测试用户都没有删除。

 

另外，有些接口的用户和口令，到软件使用寿命结束都没有更改过。在一次测试中，软件测试人员发现，给一个用户授超级用户权限，之后更改这个用户为受限权限。使用中发现，用户居然没有真正回收权限，用户管理界面上没有任何不对。及早准备用户管理用例，不要等到测试快结束时候才想起。

 

12、常识缺陷

 

从逻辑或者统计学上讲，计算机是允许如此处理的，但是从常识上来讲，这些情况不可能发生。例如电话号码不可能出现小数点，终止时间不能大于开始时间等等。除此之外，常识还要结合业务特点来进行判断，因此，开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现，对用户来说，这些错误可能是很荒谬的。

 

尽管我们不可能完美的测试一个软件，但是我们仍然可以改进我们的软件测试。每次测试结束，及时总结测试中的不足，进一步完善用例。思考一下那些容易忽略的软件缺陷，能提高对软件测试的认识，提高所在组织软件的质量。

时间如指缝滑过的风，还没来得及察觉，就已流逝，不知不觉做测试工作一年多了，从没有项目经验到EM，从EM到HRS，从HRS到CRM，从CRM到CB...迷惘过，也失落过，但就在这迷惘与失落的同时，自己也在慢慢的成长……
    从ERP到软件测试：
    我以前一直过着与世无争的生活，只要能吃饱，就算天塌下来也无所谓，05年大学毕业做了一年多的ERP，包吃住2000一个月，工作很轻松，当时也很乐意做这样的工作（可那时我忽略了一件事：我，是男人）……时间如墙上的蜗牛，虽然爬的慢，可一刻都没停止过，再回头只能看到墙上的那道淡淡的白色“轨道”，某年某月（保密）与恋爱十一年的她分手了，坚贞的情感，最终抵挡不住金钱的诱惑，曾经自己的公主拜倒在别人的脚下
没有痛，因为心已麻木，没有哭，因为在雨天，有人说泪水可以泡软人的脊梁，如果你甘愿堕落，我颓废了将近2个月，又有人说泪水可以让人变的坚强，如果你不向现实低头，只要有风吹过，泪水总有干的时候，渐渐的我开始思考，渐渐的开始发现，钱对男人是多么的重要，于是我辞职了，考察了很多行业以后，我选择了软件测试，因为它的前景，也因为自己的特性，于是我向测试迈出了第一步：参加测试培训，培训的过程除了听、记、问、实践以外也没什么可说的……
    对面试班驳的记忆
        第一次面试失败原因：1、学了后面忘了前面，没有及时回顾以前的知识2、紧张是最大的障碍，记得那次问的问题很简单，但是很多平时脱口而出的知识点，这时候却怎么也想不起来，主要问了以下几部分内容：OSI七层结构、白盒和黑盒测试有什么异同，编写用例有哪些方法，软件测试生命周期，软件开发模式有哪些，如何提交缺陷，Linux常用命令有哪些，SQL语句：增、删、改、查、创建视图、创建存储过程等，软件测试需要哪些素质，你以前工作还不错，
    现在为什么选择测试，你认为你做测试工作的优势是什么？总之问了很多，不过问题都不难
    失败后，我采取的对策；买了个可随身携带的小本子，花了一下午时间总结一下面试中问过的问题，晚上又到网上查了很多面试中可能问到的问题，一一记录下来，后来又花了2天时间把所有学习中的重要知识点记录下来，再后来的2天我出现在了秦淮河边，手里拿着那个小本子（后来送朋友了）.....
        第二次面试：失败原因对待遇问题回答的失败：
    第一轮笔试，考的是开发的试卷C/C++，C占10% C++占60%，智力题30%，因为没学过C++，所以C++都是根着自己的推想答题的，C语言只有2题，一个选择题一个编程题（考了指针）智力题总共4题，比较简单都做对了，具体题目记不清了（面试结束回家等通知，回家的路上买了本C++从入门到精通）
    第二轮测试王经理面试：问了很多测试方面的问题，都是对答如流，但后来问了2个开发的问题，一个面向对象语言的，刚好看到过，回答上了，还有个是架构方面的，没回答上来，我说不好意思我不会（后来才知道，勇敢的承认自己不会要比乱回答好的多）面试的过程很愉快，面试结束后，王经理说，请稍等一下，人事部陈经理有些人事方面的问题要问一下
    第三轮人事陈经理面试：开始问了一些问题：这样做好测试，为什么选择测试行业，等等都回答的很好，最后聊到薪水的时候，陈经理问：假如我们公司录用你，你期望的月薪是多少？我说：作为一个测试新人来讲，测试经验对我来说很重要，薪水多少并不重要（犯了个巨大的错误）陈经理说：“薪水不重要，那公司不给薪水你也愿意做吗？怎么可能？”听到这句话，我知道自己失败了一半
    失败后，我采取的对策：记录下人事问的问题，修改了下对薪水问题的回答：测试经验的积累对于一个测试新人来讲无疑是最大的财富，但人要生存，又必需有经济收入，我期望的薪水就是经验财富与物质财富的平衡点：月薪***（回答的时候面带笑容，语速不能太快，最好能像和朋友聊天一样），当天又到网上查了很多面试陷阱
        第三次面试，成功的开始，成功原因对基本知识的掌握、自信、礼仪
    第一轮上机面试：参与面试的共六个人，公司直接给个系统，让我们开始测试，然后写份测试报告，时间2个小时
        这是我第一次接触真实项目的上机操作，紧张是难免的，但是很快就进入状态，首先看了下测试说明（缺陷提交规范），然后开始看需求文档，看完后，打开系统，打开需要测试模块的每个功能模块，粗略看下有哪些功能，然后进入了漫长的测试（没有用例，只能通过自己对系统的理解去测，再次说明需求理解对测试的重要性）房间里只剩下6个相对静止的人
        时间不因为我们的“静止”而静止，终于上机时间到了，把测试报告提交到指定文件夹下，当时测试说明中明确规定，以姓名_日期.TXT命名报告， 可打开文件夹，有WORD，有Execl，有的命名格式也不对
        上机结束了，大家自我感觉都很不错，当时我表现的并不好，找了23个BUG，第3，这时经理和我们讲，你们要是没什么疑问就先回去等消息吧，我把椅子还原到原来位子，因为是最后一个走，和经理说了声：**经理，谢谢您，再见，然后又和另外一位在办公室的员工说了声再见，然后随手把门轻轻的带上
        第三天，6个人中只有2个人接到电话面试通知，其中有一个是我
        又过了2天，电话面试开始了，有点紧张，但问的问题基本上都回答上来了，电话面试结束前，问了下，请问经理您贵姓，他说他姓王，我说谢谢您王经理，希望以后有机会向您学习测试经验（可以不失时机的表达一下自己对学习的渴望，语气要诚恳）
        又过了2天，接到经理打给我的电话，面试通过了，6个人只有一个通过
        成功经验：1、熟悉系统，不错发BUG，严格按要求做（当然公司有什么不合理的地方可以提建议）
                  2、礼仪、礼貌（一般比较正规的公司都会注意到这些细节）
                  3、学会总结，不要让自己在同一个地方跌倒
下面总结一下测试新人，怎样快速找出系统的不足或缺陷
        1、阅读需求文档，深入了解系统，磨刀不误砍柴工，不要还没弄清需求就开测了，（一个星期前，公司刚进一个新人，没测试经验，因为测试的模块是我负责的，所以在TD上查看了下他们发的BUG，发现好几个是需求不明确误发的）心想：原来是这个系统啊，项目实训的时候做过和这个类似的项目，于是就把实训的系统需求硬生生的搬到当前系统来，这样做的风险太大，
           因为每个系统的需求都不一样，不能生搬硬套，打个比方：假设要你制造一辆轿车，你以前制造过普桑，就把你制造普桑的技术拿去制造林肯，这样做显然不合适
           熟悉系统（一般公司都会有系统熟悉情况考核）所以请一定要认真的阅读需求文档（有的公司叫产品定义）
        2、熟悉测试用例，这是测试执行的一个导向，要想快速高效率的执行用例，必须在熟悉系统的同时，熟悉用例，熟悉每条用例覆盖的需求，这样执行起来才能事半功倍
        3、胆大心细，测试就像是一场优胜劣汰的战斗，你的动作慢了，成果就是别人的了，假设你和同事同时发现了个BUG，而你打字比较慢，结果在你提交的同时他已经提交了，那么不好意思，你的BUG只能作CLOSED_Nbug处理了，如果一定要加上一个批注，那么将是，重复提交（测试新人，备注里不建议加测试建议（即怎样修改可以避免此缺陷），因为有可能会对开发产生误导）
        4、新版本发布，第一件事，验证FIXED缺陷，然后冒下烟确保主流程畅通，然后再进行功能测试，着重测试有修改的或者与所修改模块有调用关系的模块和发现BUG比较多的模块（公司发布版本会邮件通知修改的模块与修复的BUG），未改动的模块建议做个流程测试
        5、如果版本未更新，1)建议着重进行业务逻辑方面测试，在电脑上以文档形式画出简单的业务逻辑图片，重点说明：一定要尽量考虑所有的情况，因为这样的BUG要么就没有，一旦有就是HIGH
                           2)建议进行环境测试（当然要根据需求测试相应的环境）
                           3)严格核对需求文档，防止需求遗漏
        6、严格按照缺陷提交说明提交BUG，因为这有可能涉及BUG的统计问题，（一般公司的缺陷描述：系统名称_功能模块，缺陷描述，要具体问题具体对待）
好了，今天先写这些了，都是自己的一些体会，要是有什么不对的地方，希望大家多多指正，谢谢！
最后，喊一下我的口号：学会分享，明天你就是测试大虾
       

测试人员容易遗漏一些隐藏的缺陷

  

通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。但是，在系统测试和确认测试中，测试人员容易遗漏一些隐藏的缺陷。众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括：

 

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应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中，一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里，很少去做这样的比较，除了一些有针对性的性能测试。

 

 

asc 按升序排列
desc 按降序排列
下列语句部分是Mssql语句，不可以在access中使用。
SQL分类：
DDL—数据定义语言(Create，Alter，Drop，DECLARE)
DML—数据操纵语言(Select，Delete，Update，Insert)
DCL—数据控制语言(GRANT，REVOKE，COMMIT，ROLLBACK)
首先,简要介绍基础语句：
1、说明：创建数据库
Create DATABASE database-name
2、说明：删除数据库
drop database dbname
3、说明：备份sql server
--- 创建 备份数据的 device
USE master
EXEC sp_addumpdevice 'disk', 'testBack', 'c:\mssql7backup\MyNwind_1.dat'
--- 开始 备份
BACKUP DATABASE pubs TO testBack
4、说明：创建新表
create table tabname(col1 type1 [not null] [primary key],col2 type2 [not null],..)
根据已有的表创建新表：
A：create table tab_new like tab_old (使用旧表创建新表)
B：create table tab_new as select col1,col2… from tab_old definition only
5、说明：删除新表drop table tabname
6、说明：增加一个列
Alter table tabname add column col type
注：列增加后将不能删除。DB2中列加上后数据类型也不能改变，唯一能改变的是增加varchar类型的长度。
7、说明：添加主键： Alter table tabname add primary key(col)
说明：删除主键： Alter table tabname drop primary key(col)
8、说明：创建索引：create [unique] index idxname on tabname(col….)
删除索引：drop index idxname
注：索引是不可更改的，想更改必须删除重新建。
9、说明：创建视图：create view viewname as select statement
删除视图：drop view viewname
10、说明：几个简单的基本的sql语句
选择：select * from table1 where 范围
插入：insert into table1(field1,field2) values(value1,value2)
删除：delete from table1 where 范围
更新：update table1 set field1=value1 where 范围
查找：select * from table1 where field1 like ’%value1%’ ---like的语法很精妙，查资料!
排序：select * from table1 order by field1,field2 [desc]
总数：select count as totalcount from table1
求和：select sum(field1) as sumvalue from table1
平均：select avg(field1) as avgvalue from table1
最大：select max(field1) as maxvalue from table1
最小：select min(field1) as minvalue from table1
11、说明：几个高级查询运算词
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)，不消除重复行。
注：使用运算词的几个查询结果行必须是一致的。
12、说明：使用外连接
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)

1.一位前辈工程师职业发展的忠告

——写了10点，金科玉言，句句真理！

2.做好测试工程师需要学习掌握的技能

——计算机专业知识、行业素养、个人行为素质

3.保留更新……

第一部分

软件测试策略基础
为什么要编写测试策略？测试策略就是如何进行软件测试的计划。测试策略的目标包括：

取得利益相关者（比如管理部门、开发人员、测试人员、顾客和用户等）的一致性目标；
从开始阶段对期望值进行管理；
确保“开发方向正确”；
确定所有要进行的测试类型。
1、策略与软件测试策略

（1）策略：在一定的政治路线指导下，根据具体条件而规定的斗争原则、方式和方法。<新华字典>

（2）软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

测试策略为测试提供全局分析，并确定或参考：

项目计划、风险和需求；
相关的规则、政策或指示；
所需过程、标准与模板；
支持准则；
利益相关者及其测试目标；
测试资源与评估；
测试层次与阶段；
测试环境；
各阶段的完成标准；
所需的测试文档与检查方法。
2、软件测试策略的重要性

1)任何一个完全测试或穷举测试的工作量都是巨大的，在实践上是行不通的，因此任何实际测试都不能保证被测程序中不遗漏错误或缺陷；

2)为了最大程度较少这种遗漏，同时最大限度发现可能存在的错误，在实施测试前必须确定合适的测试方法和测试策略，并以此为依据制定详细的测试案例。

3、软件测试策略的目的

是不是所有软件测试都要运用现有软件测试方法去测试呢？答案是否定的。依据软件本身性质、规模和应用场合的不同，我们将选择不同测试方案，以最少的软硬件、人力资源投入得到最佳的测试效果，这就是测试策略的目标所在。

3、软件测试策略的影响因素

软件测试策略随着软件生命周期的变化、软件测试方法、技术与工具的不同发生的变化。这就要求我们在制定测试策略时候，应该综合考虑测试策略的影响因素及其依赖关系。这些影响因素可能包括：测试项目资源因素、项目的约束和测试项目的特殊需要等。

4、软件测试策略的制定过程

（1）输入

需要的软硬件资源的详细说明；

针对测试和进度约束而需要的人力资源的角色和职责；

测试方法、测试标准和完成标准；

目标系统的功能性和技术性需求；

系统局限（即系统不能够提供的需求）等等。

（2）输出

已批准和签署的测试策略文档、测试用例、测试计划；

需要解决方案的测试项目；

（3）过程

1）确定测试的需求¤

测试需求所确定的是测试内容，即测试的具体对象。在分析测试需求时，可应用以下几条一般规则：

测试需求必须是可观测、可测评的行为。如果不能观测或测评测试需求，就无法对其进行评估，以确定需求是否已经满足。

在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求；有些补充需求将派生一个或多个测试需求，而其他补充需求（如市场需求或包装需求）将不派生任何测试需求。

测试需求可能有许多来源，其中包括用例模型、补充需求、设计需求、业务用例、与最终用户的访谈和软件构架文档等。应该对所有这些来源进行检查，以收集可用于确定测试需求的信息。

2）评估风险并确定测试优先级¤

成功的测试需要在测试工作中成功地权衡资源约束和风险等因素。为此，应该确定测试工作的优先级，以便先测试最重要、最有意义或风险最高的用例或构件。为了确定测试工作的优先级，需执行风险评估和实施概要，并将其作为确定测试优先级的基础。

3）确定测试策略¤

一个好的测试策略应该包括：实施的测试类型和测试的目标、实施测试的阶段、技术、用于评估测试结果和测试是否完成的评测和标准、对测试策略所述的测试工作存在影响的特殊事项等内容。

如何才能确定一个好的测试策略呢？我们可以从基于测试技术的测试策略、基于测试方案的测试策略两个方面来回答这个问题。

①基于测试技术的测试策略的要点

著名测试专家给出了使用各种测试方法的综合策略：

任何情况下都必须使用边界值测试方法；

必要时使用等价类划分方法补充一定数量的测试用例；

对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，看是否达到了要求；

如果程序功能规格说明中含有输入条的组合情况，则已开始可以选择因果图方法。

②基于测试方案的测试策略

对于基于测试方法的测试策略，一般来说应该考虑如下方面：

根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点；

认真研究，使用尽可能少的测试用例发现尽可能多的程序错误，避免测试过度和测试不足!

第二部分

测试策略的方法

软件测试的策略、方法和技术是多种多样的。对于软件测试技术，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试。从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。
　　1.静态方法与动态方法
　　所谓静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
　　动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。
　　2.功能测试与结构测试
　　（1）功能测试
　　功能测试是指在对程序进行的功能抽象的基础上，将程序划分成功能单元，然后在数据抽象的基础上，对每个功能单元生成测试数据进行测试。用这种方法进行测试时，被测程序被当作打不开的黑盒，因而无法了解其内部构造，因此又称为黑盒测试。
　　黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当接收输入数据而产生正确的输出信息，并且保持外部信息的完整性。
　　在功能测试中，被测软件的输入域和输出域往往是无限域，因此穷举测试通常是不可行的。必须以某种策略分析软件规格说明，从而得出测试用例集，尽可能全面而又高效地对软件进行测试。下面就说明几种功能测试的方法：
　　a.等价类划分
　　所谓等价类，就是指某个输入域的集合，集合中的每个输入对揭露程序错误来说是等效的，把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例，这就是等价类划分方法。它是功能测试的基本方法。
　　b.因果图法
　　因果图是一种形式语言，由自然语言写成的规范转换而成，这种形式语言实际上是一种使用简化记号表示数字逻辑图。因果图法是帮助人们系统地选择一组高效测试用例的方法，此外，它还能指出程序规范中的不完全性和二义性。
　　c.边值分析
　　实践证明，软件在输入、输出域的边界附近容易出现差错，边值分析是考虑边界条件而选取测试用例的一种功能测试方法。所谓边界条件，是相对于输入和输出等价类直接在其边缘上，稍高于和稍低于其边界的这些状态条件。边值分析是对等价类划分的有效补充。
　　(2)结构测试
　　结构测试是根据被测程序的内部结构设计测试用例的一类测试，又称为白盒测试。白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。其主要方法有逻辑驱动、基路测试等，主要用于软件验证。白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。白盒法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
　　与功能测试不同的是，结构测试涉及程序内部结构。尽管用户更倾向于基于程序规格说明的功能测试，但是结构测试能发现潜在的逻辑错误，而这种错误往往是功能测试发现不了的。它们各有利弊，常常结合使用。

第三部分

测试策略文档范例

　　●测试目的：
　　（1） 测试的范围，哪些功能要包括在内，哪些要排除在外
　　（2） 谁是客户和最终用户，谁就是测试结果的验收者
　　（3） 测试的次序和日程安排
　　（4） 验收的条件，成功因素，限制

　　●资源需求：
　　（1） 制定计划和运行测试需要哪些技术和经验
　　（2） 相关人员的角色和责任
　　（3） 谁将对测试工作进行全盘协调
　　（4） 谁负责测试资料管理，版本控制，错误跟踪

　　●测试环境：
　　（1） 用于测试的系统配置怎样
　　（2） 需要什么自动化工具
　　（3） 需要哪些测试数据（数据库和输入交易），如何安装
　　（4） 您如何前调系统时钟

　　●测试过程：
　　（1） 运行测试时要遵循哪些过程（设置、执行、记录）
　　（2） 测试案例如何制定，其标准格式是什么
　　（3） 测试案例定义的覆盖要求是什么
　　（4） 遇到问题如何决定其严重程度，对问题如何处理 

——以上摘自网络并整理合并

1.软件配置管理系列文章：
软件配置管理系列--什么是配置管理？
软件配置管理概念－1,介绍
软件配置管理概念－2,用户角色
软件配置管理概念－3,CM系统的概念
     软件配置管理概念－3.1 警告
     软件配置管理概念－3.2 组件概念
     软件配置管理概念－3.3 过程概念
     软件配置管理概念－3.4 结构和构建概念
     软件配置管理概念－3.5 团队概念
     软件配置管理概念－3.6 总结和图谱分析
软件配置管理概念－4,CM系统的未来
软件配置管理概念－5,结论

2.软件测试概念：
什么是软件测试？
什么是软件测试及软件测试的目的
51testing：什么是软件测试及……
究竟什么才是真正的软件测试
——讲的比较全，而且涵盖了前面三个网站的内容
软件测试测什么？
——比较实用，详细的介绍了测试具体工作概念

黑白盒的概念：
软件测试技术

3.软件测试方法：

 

4.软件测试管理：
软件外包测试管理与实践
——针对目前外包测试项目普及化管理，有所指导作用
软件测试外包管理之我见
——体系化讲解了测试外包管理需要考虑的方面

5.不断更新