轉載自：https://blog.csdn.net/liuyuzhu111/article/details/70332272

==================================== 
很多面試中，都會問道如何測試一個介面?我嘗試著用自己現有的知識進行回答，等以後某年某月自己回來看看時自己提升了多少。

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

==================================== 
分析：這個題是一個開放性的題，答得好要涉及到全面的測試，功能測試，安全測試，效能測試以及調優等。 
這也是一個考察邏輯思維的題，透過答題能看出一個人對測試流程的掌握，測試用例的涉及角度，測試覆蓋面的廣度，測試經驗的豐富度，開發水平的功底，實戰經驗等，都能涉及到。

這也是一個考驗智商尤其是情商的題，測試過程中我們要不斷的和產品，開發進行溝通交流，反覆確認，互相支援等。也會遇到比較尷尬的溝通人物，考驗我們是如何處理協調這些關係的。

==================================== 
答題： 
1首先和產品進行詳細的需求確認，可通過需求評審會，也可通過其他方式，保證我們要獲取到一下內容：

業務難點，重點邏輯，產品高度重視的點，產品效能預估，使用場景，上線預期時間，以及未來的定位。 
這些內容為我們下一步進行設計測試計劃做鋪墊。

2找開發確認並瞭解實現邏輯，產品需求到開發程式碼實現會出現很多不一致的地方，儘可能的做一遍程式碼靜態分析，瞭解程式碼類圖，方法呼叫關係，並對私有方法、公有方法進行使用範圍的確認，從程式碼層面設計測試用例。另外，對方法呼叫和程式碼邏輯，我們不能完全保證沒有問題，還要從黑盒思想出發，設計測試用例，進行用例覆蓋等。這樣，測試用例就能具備精準設計，做到有的放矢。提升測試質量，也能提升效率，節省時間。

3具體的功能測試在case設計結束並實施後，我們還要關注安全形度。尤其對基本的sql注入，token驗證，加密驗籤等進行重點測試和關注。 
4效能方面就內容很多了，這個也根據不同人員的基礎選擇性的去說。我所說的只能是我目前水平的最好答案。也特別歡迎幫忙指正錯誤提出建議。 
a,首先，我們要做一次負載測試，使用loadrunner建議使用自動場景，從低併發數逐漸增多，慢慢達到最高併發。負載測試幫助我們瞭解介面效能的變化曲線，獲得最大使用者數，tps峰值，資源利用率，響應耗時等重要效能引數。建議多做幾次，以確保結果正確合理。之前我們提到從產品那裡得到對介面效能的預估，我們可以進行對比，如果不滿足，就要返回開發那裡，一起定位問題，進行效能調優。調優我們稍後會涉及到。

b,介面的表現滿足我們的預估後，要進一步進行壓力測試，測試服務在高負載情況下長時間極限狀態下伺服器的表現，並針對伺服器的承載能力做出評估。這個測試中我們經常遇到記憶體溢位，磁碟日誌打滿，服務宕機，網路異常等。也是我們發現問題的時候。排除問題，我們繼續向下走。

c有了前面的測試，我們還要針對資料庫進行容量測試，比如在測試導航算路的演算法中，涉及到的用例有從1公里-2000公里，不同距離對網路，記憶體，磁碟讀寫都會形成不同的衝擊，以及高併發下我們對資料庫的效能表現做出判斷，單點還是叢集？是否需要分庫分表？讀寫是否分離？後續都會面臨調優問題。

d通常，實操同事會給業務線配給不同的併發數，那麼我們就要針對不同併發數進行配置測試，確定某一配置下的效能引數，為業務線提供資料支撐。 
e當這些做完後，彆著急，我們要做一次基準測試。 
基準測試是為了後續調優和系統評測提供引數支援，針對整個系統進行的基準測試。有的場景是不允許我們進行全鏈路測試的，比如支付場景，銀行業務等。但是不妨礙我們進行基準測試。

我在做基準測試的時候，是寫了一個mq的傳送工具，mq打滿後，啟動服務，觀察模組消費mq的速度，計算耗時，獲得資料。每個模組逐一進行測試，最後會得到如下資料： 
例如： 
模組A （3000tps） 
模組B （5000tps） 
模組C (6000tps) 
資料庫 （3500tps）

由此可知，我們系統瓶頸在模組A，和資料庫。 
同時，對模組B，C，我們在下次改動後做效能測試時，就有了參照資料，效能提升了還好，下降了肯定不答應他們上線。

測試到此：允許上線。（呵呵）
==================================== 
說到效能方面，不得不說常用的監控方式和命令： 
jconsol，jvm記憶體實時展示；nmon，伺服器端記錄機器的各種引數，詳細而全面。其他不一一介紹，我們是在面試，說好要點，說清楚要點是關鍵，這裡要精不要多。 
監視記憶體我們可以檢視有無FGC，有無記憶體洩漏，記憶體洩漏可以通過觀察swap空間是否被使用能獲得。 
這裡準備了一些常見的參考（轉載了一部分內容）： 
1、處理器佇列堵塞判斷方法：如果Processor queue length大於2，而處理器利用率一直很低，則存在處理器堵塞。 
2、處理器瓶頸判斷方法： 排除記憶體因素後，如果%processor time持續大於90%，並且%interrupt time的值持續大於15%，同時網絡卡和硬碟的值比較低，可以斷定處理器負荷過重，無法滿足業務增長需要，處理器是系統瓶頸點。 
3. 監視記憶體不足的狀況，可以通過 page/sec,Available Mbytes、page read/sec、page faults/sec等計數器的指標進行監控，還可以通過使用“頁面交換”的頻率來衡量。“頁面交換”是使用稱為“頁面”的單位，將固定大小的程式碼和資料塊從RAM移動到磁碟的過程，從而釋放暫時不使用的空間，這些頁面檔案就是作業系統用來虛擬記憶體的硬碟空面。作業系統對於虛擬記憶體主要設定兩點，即記憶體頁面檔案的大小和頁面檔案存放的位置，內 存頁面檔案的大小就是設定虛擬記憶體最小和最大空間量，而頁面位置則是設定虛擬記憶體使用哪個分割槽中的硬碟空間。頻繁的頁面交換將降低系統性能，如果系統“頁交換”頻繁，說明記憶體不足。通過調優配置減少頁交換，將顯著提高系統響應速度。 
4. 通過pages/sec指標判斷是否存在記憶體問題，如果pages/sec持續高於幾百，則有可能需要增加記憶體，以減少換頁的需求，此時還應該進一步研究 頁交換活動。如果pages/sec指標過高（幾百），而硬碟資料流量不高（幾百kb/s）則可確定是記憶體不足問題，如果pages/sec指標較高（幾百），而此時硬碟資料流量也很高（幾千KB /S），則可以判定是磁碟問題。 
5.通過 available mbytes來判斷是否存在嚴重記憶體洩漏問題，如果該值很小（<4M）,則說明計算機上總的記憶體可能不足，或者某個程式始終佔用而沒有釋放記憶體，系統存在嚴重的記憶體洩漏問題。 
6.如果頁面讀取操作速率page reads/sec指標的值很低，同時%disk time和avg.disk queue length的值卻很高，則確定為磁碟瓶頸，但如果Avg.sidk queue length增加的同時page reads/sec頁面讀取速率指標並未降低，則確定為記憶體不足。

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

==================================== 
以下內容轉自（https://zhidao.baidu.com/question/215720334.html）

影響資料庫效能的主要因素有哪些？
====================================

1、1、調整資料結構的設計。這一部分在開發資訊系統之前完成，程式設計師需要考慮是否使用ORACLE資料庫的分割槽功能，對於經常訪問的資料庫表是否需要建立索引等。 
2、2、調整應用程式結構設計。這一部分也是在開發資訊系統之前完成，程式設計師在這一步需要考慮應用程式使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程式體系結構要求的資料庫資源是不同的。 
3、3、調整資料庫SQL語句。應用程式的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的效能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。 
4、4、調整伺服器記憶體分配。記憶體分配是在資訊系統執行過程中優化配置的，資料庫管理員可以根據資料庫執行狀況調整資料庫系統全域性區（SGA區）的資料緩衝區、日誌緩衝區和共享池的大小；還可以調整程式全域性區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用作業系統使用的記憶體而引起虛擬記憶體的頁面交換，這樣反而會降低系統。 
5、5、調整硬碟I/O，這一步是在資訊系統開發之前完成的。資料庫管理員可以將組成同一個表空間的資料檔案放在不同的硬碟上，做到硬碟之間I/O負載均衡。 
6、6、調整作業系統引數，例如：執行在UNIX作業系統上的ORACLE資料庫，可以調整UNIX資料緩衝池的大小，每個程序所能使用的記憶體大小等引數。 
實際上，上述資料庫優化措施之間是相互聯絡的。ORACLE資料庫效能惡化表現基本上都是使用者響應時間比較長，需要使用者長時間的等待。但效能惡化的原因卻是多種多樣的，有時是多個因素共同造成了效能惡化的結果，這就需要資料庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響資料庫效能的主要原因所在。另外，良好的資料庫管理工具對於優化資料庫效能也是很重要的。 
ORACLE資料庫效能優化工具 
常用的資料庫效能優化工具有： 
1、1、ORACLE資料庫線上資料字典，ORACLE線上資料字典能夠反映出ORACLE動態執行情況，對於調整資料庫效能是很有幫助的。 
2、2、作業系統工具，例如UNIX作業系統的vmstat，iostat等命令可以檢視到系統系統級記憶體和硬碟I/O的使用情況，這些工具對於管理員弄清出系統瓶頸出現在什麼地方有時候很有用。 
3、3、SQL語言跟蹤工具（SQL TRACE FACILITY），SQL語言跟蹤工具可以記錄SQL語句的執行情況，管理員可以使用虛擬表來調整例項，使用SQL語句跟蹤檔案調整應用程式效能。SQL語言跟蹤工具將結果輸出成一個作業系統的檔案，管理員可以使用TKPROF工具檢視這些檔案。 
4、4、ORACLE Enterprise Manager（OEM），這是一個圖形的使用者管理介面，使用者可以使用它方便地進行資料庫管理而不必記住複雜的ORACLE資料庫管理的命令。 
5、5、EXPLAIN PLAN——SQL語言優化命令，使用這個命令可以幫助程式設計師寫出高效的SQL語言。 
ORACLE資料庫的系統性能評估 
資訊系統的型別不同，需要關注的資料庫引數也是不同的。資料庫管理員需要根據自己的資訊系統的型別著重考慮不同的資料庫引數。 
1、1、線上事務處理資訊系統（OLTP），這種型別的資訊系統一般需要有大量的Insert、Update操作，典型的系統包括民航機票發售系統、銀行儲蓄系統等。OLTP系統需要保證資料庫的併發性、可靠性和終端使用者的速度，這類系統使用的ORACLE資料庫需要主要考慮下述引數： 
l l 資料庫回滾段是否足夠？ 
l l 是否需要建立ORACLE資料庫索引、聚集、雜湊？ 
l l 系統全域性區（SGA）大小是否足夠？ 
l l SQL語句是否高效？ 
2、2、資料倉庫系統（Data Warehousing），這種資訊系統的主要任務是從ORACLE的海量資料中進行查詢，得到資料之間的某些規律。資料庫管理員需要為這種型別的ORACLE資料庫著重考慮下述引數： 
l l 是否採用B*-索引或者bitmap索引？ 
l l 是否採用並行SQL查詢以提高查詢效率？ 
l l 是否採用PL/SQL函式編寫儲存過程？ 
l l 有必要的話，需要建立並行資料庫提高資料庫的查詢效率 
SQL語句的調整原則 
SQL語言是一種靈活的語言，相同的功能可以使用不同的語句來實現，但是語句的執行效率是很不相同的。程式設計師可以使用EXPLAIN PLAN語句來比較各種實現方案，並選出最優的實現方案。總得來講，程式設計師寫SQL語句需要滿足考慮如下規則： 
1、1、儘量使用索引。試比較下面兩條SQL語句： 
語句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN 
(SELECT deptno FROM emp); 
語句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS 
(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno); 
這兩條查詢語句實現的結果是相同的，但是執行語句A的時候，ORACLE會對整個emp表進行掃描，沒有使用建立在emp表上的deptno索引，執行語句B的時候，由於在子查詢中使用了聯合查詢，ORACLE只是對emp表進行的部分資料掃描，並利用了deptno列的索引，所以語句B的效率要比語句A的效率高一些。 
2、2、選擇聯合查詢的聯合次序。考慮下面的例子： 
SELECT stuff FROM taba a, tabb b, tabc c 
WHERE a.acol between :alow and :ahigh 
AND b.bcol between :blow and :bhigh 
AND c.ccol between :clow and :chigh 
AND a.key1 = b.key1 
AMD a.key2 = c.key2; 
這個SQL例子中，程式設計師首先需要選擇要查詢的主表，因為主表要進行整個表資料的掃描，所以主表應該資料量最小，所以例子中表A的acol列的範圍應該比表B和表C相應列的範圍小。 
3、3、在子查詢中慎重使用IN或者NOT IN語句，使用where (NOT) exists的效果要好的多。 
4、4、慎重使用檢視的聯合查詢，尤其是比較複雜的檢視之間的聯合查詢。一般對檢視的查詢最好都分解為對資料表的直接查詢效果要好一些。 
5、5、可以在引數檔案中設定SHARED_POOL_RESERVED_SIZE引數，這個引數在SGA共享池中保留一個連續的記憶體空間，連續的記憶體空間有益於存放大的SQL程式包。 
6、6、ORACLE公司提供的DBMS_SHARED_POOL程式可以幫助程式設計師將某些經常使用的儲存過程“釘”在SQL區中而不被換出記憶體，程式設計師對於經常使用並且佔用記憶體很多的儲存過程“釘”到記憶體中有利於提高終端使用者的響應時間。 
CPU引數的調整 
CPU是伺服器的一項重要資源，伺服器良好的工作狀態是在工作高峰時CPU的使用率在90％以上。如果空閒時間CPU使用率就在90％以上，說明伺服器缺乏CPU資源，如果工作高峰時CPU使用率仍然很低，說明伺服器CPU資源還比較富餘。 
使用操作相同命令可以看到CPU的使用情況，一般UNIX作業系統的伺服器，可以使用sar –u命令檢視CPU的使用率，NT作業系統的伺服器，可以使用NT的效能管理器來檢視CPU的使用率。 
資料庫管理員可以通過檢視vsysstat資料字典中“CPUusedbythissession”統計項得知ORACLE資料庫使用的CPU時間，檢視“OSUserlevelCPUtime”統計項得知作業系統使用者態下的CPU時間，檢視“OSSystemcallCPUtime”統計項得知作業系統系統態下的CPU時間，作業系統總的CPU時間就是使用者態和系統態時間之和，如果ORACLE資料庫使用的CPU時間佔作業系統總的CPU時間90％以上，說明伺服器CPU基本上被ORACLE資料庫使用著，這是合理，反之，說明伺服器CPU被其它程式佔用過多，ORACLE資料庫無法得到更多的CPU時間。資料庫管理員還可以通過檢視vsysstat資料字典中“CPUusedbythissession”統計項得知ORACLE資料庫使用的CPU時間，檢視“OSUserlevelCPUtime”統計項得知作業系統使用者態下的CPU時間，檢視“OSSystemcallCPUtime”統計項得知作業系統系統態下的CPU時間，作業系統總的CPU時間就是使用者態和系統態時間之和，如果ORACLE資料庫使用的CPU時間佔作業系統總的CPU時間90％以上，說明伺服器CPU基本上被ORACLE資料庫使用著，這是合理，反之，說明伺服器CPU被其它程式佔用過多，ORACLE資料庫無法得到更多的CPU時間。資料庫管理員還可以通過檢視vsesstat資料字典來獲得當前連線ORACLE資料庫各個會話佔用的CPU時間，從而得知什麼會話耗用伺服器CPU比較多。 
出現CPU資源不足的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖衝突都會引起CPU資源不足。 
1、資料庫管理員可以執行下述語句來檢視SQL語句的解析情況： 
SELECT * FROM VSYSSTATWHERENAMEIN(‘parsetimecpu′,‘parsetimeelapsed′,‘parsecount(hard)′);這裡parsetimecpu是系統服務時間，parsetimeelapsed是響應時間，使用者等待時間waitetime=parsetimeelapsed–parsetimecpu由此可以得到使用者SQL語句平均解析等待時間＝waitetime/parsecount。這個平均等待時間應該接近於0，如果平均解析等待時間過長，資料庫管理員可以通過下述語句SELECTSQLTEXT,PARSECALLS,EXECUTIONSFROMVSYSSTATWHERENAMEIN(‘parsetimecpu′,‘parsetimeelapsed′,‘parsecount(hard)′);這裡parsetimecpu是系統服務時間，parsetimeelapsed是響應時間，使用者等待時間waitetime=parsetimeelapsed–parsetimecpu由此可以得到使用者SQL語句平均解析等待時間＝waitetime/parsecount。這個平均等待時間應該接近於0，如果平均解析等待時間過長，資料庫管理員可以通過下述語句SELECTSQLTEXT,PARSECALLS,EXECUTIONSFROMVSQLAREA 
ORDER BY PARSE_CALLS; 
來發現是什麼SQL語句解析效率比較低。程式設計師可以優化這些語句，或者增加ORACLE引數SESSION_CACHED_CURSORS的值。 
2、資料庫管理員還可以通過下述語句： 
SELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM VSQLAREA;檢視低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。3、3、資料庫管理員可以通過vSQLAREA;檢視低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。3、3、資料庫管理員可以通過vsystem_event資料字典中的“latch free”統計項檢視ORACLE資料庫的衝突情況，如果沒有衝突的話，latch free查詢出來沒有結果。如果衝突太大的話，資料庫管理員可以降低spin_count引數值，來消除高的CPU使用率。 
記憶體引數的調整 
記憶體引數的調整主要是指ORACLE資料庫的系統全域性區（SGA）的調整。SGA主要由三部分構成：共享池、資料緩衝區、日誌緩衝區。 
1、 1、 共享池由兩部分構成：共享SQL區和資料字典緩衝區，共享SQL區是存放使用者SQL命令的區域，資料字典緩衝區存放資料庫執行的動態資訊。資料庫管理員通過執行下述語句： 
select (sum(pins - reloads)) / sum(pins) “Lib Cache” from vlibrarycache;來檢視共享SQL區的使用率。這個使用率應該在90％以上，否則需要增加共享池的大小。資料庫管理員還可以執行下述語句：select(sum(gets−getmisses−usage−fixed))/sum(gets)“RowCache”fromvlibrarycache;來檢視共享SQL區的使用率。這個使用率應該在90％以上，否則需要增加共享池的大小。資料庫管理員還可以執行下述語句：select(sum(gets−getmisses−usage−fixed))/sum(gets)“RowCache”fromvrowcache; 
檢視資料字典緩衝區的使用率，這個使用率也應該在90％以上，否則需要增加共享池的大小。 
2、 2、 資料緩衝區。資料庫管理員可以通過下述語句： 
SELECT name, value FROM vsysstatWHEREnameIN(‘dbblockgets′,‘consistentgets′,′physicalreads′);來檢視資料庫資料緩衝區的使用情況。查詢出來的結果可以計算出來資料緩衝區的使用命中率＝1−(physicalreads/(dbblockgets+consistentgets))。這個命中率應該在90％以上，否則需要增加資料緩衝區的大小。3、3、日誌緩衝區。資料庫管理員可以通過執行下述語句：selectname,valuefromvsysstatWHEREnameIN(‘dbblockgets′,‘consistentgets′,′physicalreads′);來檢視資料庫資料緩衝區的使用情況。查詢出來的結果可以計算出來資料緩衝區的使用命中率＝1−(physicalreads/(dbblockgets+consistentgets))。這個命中率應該在90％以上，否則需要增加資料緩衝區的大小。3、3、日誌緩衝區。資料庫管理員可以通過執行下述語句：selectname,valuefromvsysstat where name in (‘redo entries’,’redo log space requests’);檢視日誌緩衝區的使用情況。查詢出的結果可以計算出日誌緩衝區的申請失敗率： 
申請失敗率＝requests/entries，申請失敗率應該接近於0，否則說明日誌緩衝區開設太小，需要增加ORACLE資料庫的日誌緩衝區。

====================================
---------------------