單元測試的驅動函數和樁函數
驅動模塊：模擬被測試模塊的上一級模塊，相當於被測試模塊的主程序。接受測試數據，將測試數據傳給所測模塊，輸出相應的結果。
樁模塊：模擬所測模塊調用的模塊，相當於下級模塊，接受被測模塊的數據，一般不執行功能。
測試用例內容：
用例編號、用例標題、測試模塊、重要級別、操作步驟、測試輸入、預期結果
Bug描述包括哪些：
缺陷編號、所屬用例ID、所屬模塊、所屬版本、測試者、提交日期、缺陷標題、缺陷詳細描述、缺陷嚴重程度、缺陷優先級、缺陷狀態、解決人和解決日期、驗證人和驗證日期
查詢數據庫中第10到20條數據
Select * from table where rownum<=20 minus select * from table where rownum<10;
Group by的作用：
GROUP BY 語句根據一個或多個列對結果集進行分組。會把值相同放到一個組中，最終查詢出的結果只會顯示組中一條記錄。
二、SQL優化的一些方法
1.對查詢進行優化，應儘量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應儘量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：select id from t where num=0
3.應儘量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應儘量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查詢也將導致全表掃描：
select id from t where name like ‘%abc%’
7.應儘量避免在 where 子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改爲:
select id from t where num=1002
8.應儘量避免在where子句中對字段進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如
select id from t where substring(name,1,3)=‘abc’–name以abc開頭的id
應改爲:
select id from t where name like ‘abc%’
9.不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.在使用索引字段作爲條件時，如果該索引是複合索引，那麼必須使用到該索引中的第一個字段作爲條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應儘可能的讓字段順序與索引順序相一致。
11.不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(…)
12.很多時候用 exists 代替 in 是一個好的選擇：
select num from a where num in(select num from b)用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
13.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重複時，SQL查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。
14.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，
因爲 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。
一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
15.儘量使用數字型字段，若只含數值信息的字段儘量不要設計爲字符型，這會降低查詢和連接的性能，並會增加存儲開銷。
這是因爲引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了。
16.儘可能的使用 varchar 代替 char ，因爲首先變長字段存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的字段內搜索效率顯然要高些。
17.任何地方都不要使用 select * from t ，用具體的字段列表代替“”，不要返回用不到的任何字段。
18.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
19.臨時表並不是不可使用，適當地使用它們可以使某些例程更有效，例如，當需要重複引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
20.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量log，以提高速度；如果數據量不大，爲了緩和系統表的資源，應先create table，然後insert。
21.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
22.儘量避免使用遊標，因爲遊標的效率較差，如果遊標操作的數據超過1萬行，那麼就應該考慮改寫。
23.使用基於遊標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
24.與臨時表一樣，遊標並不是不可使用。對小型數據集使用 FAST_FORWARD 遊標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。
在結果集中包括“合計”的例程通常要比使用遊標執行的速度快。如果開發時間允許，基於遊標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
25.儘量避免大事務操作，提高系統併發能力。
26.儘量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
網絡不通排除故障
- ipconfig看到自己的ip地址
- ping自己的ip如果不通可能是交換機和路由器的問題
- ping百度，如果能ping通還是上不了網則應該是瀏覽器的問題或者中毒了
- ping本地網關，如果不通應該是網卡驅動或者物理鏈路的問題
測試用例：一張紙
功能：
1.紙張的大小和需求規格說明書中的大小 是否一致
2.紙張的厚度是否和要求的一致
3.紙張的顏色是否和要求的一致‘’
4.紙張是否可以摺疊，拉伸
5.紙張的軟硬程度是否達到要求
6.紙張上的鉛筆字，能否擦乾淨
7.紙張是否易破
8.紙張遇水曬乾之後是否還能繼續使用
9.紙張的平整度是否符合要求
10.紙張的重量是否在要求以內
性能：
1.紙張能保存的最久時間
2.紙張能承受的最大壓力
3.紙張能重複使用的最大次數
4.紙張能被多大的風力吹起來
5.紙的吸水性
6.紙張在潮溼度爲XXX的環境下腐化的速度有多快
7.墨水在紙張上的乾的速度有多快
8.紙張最多的摺疊次數
9.紙張的抗皺效果和還原性
10.紙張多大的力會留下痕跡
11.紙張的透光度，以及從背面是否能夠看到正面的字
安全：
1.紙張的材料是否符合國家標準
2.紙張是否有味道
3.紙張的邊緣是否會鋒利，劃傷的可能性
4.紙張的的材料是否會與筆芯發生反應
5.紙張腐化後不會不會對環境造成危害
兼容性：
1.在不同的溫度下是否可以正常使用：高溫低溫
2.紙上面是否能用鉛筆，鋼筆，中性筆，彩鉛，油筆寫字,
3.在不同的打印機裏面的打印效果是否符合要求
界面：
1.紙張的形狀是否符合大衆的使用習慣
2.紙張的顏色是否符合要求