如何進行灰盒測試.doc

如何開展灰盒測試灰盒測試優(yōu)缺點分析 幾個基本概念 首先，把一些基本概念，簡單通俗地說一下。如果覺得俺解釋得不夠好，不夠細，可以自己去查維基百科的詞條：洋文的在“這里 ”，中文的詞條在“這里 ”（可惜中文詞條不夠全，偏偏缺了“灰盒測試”這一節(jié)）。黑盒測試通俗來說：黑盒測試不關注軟件內部的實現(xiàn)細節(jié)。他僅僅把被測試的軟件當成一個整體來處理，只關注軟件的外在表現(xiàn)，不關注內部細節(jié)。典型的黑盒測試，就是光拿著鼠標操作一下用戶界面，看看功能是否滿足要求。白盒測試白盒測試與黑盒測試相反，重點關注軟件內部的實現(xiàn)細節(jié)（比如代碼覆蓋率等）。灰盒測試如果你是從事開發(fā)或者測試的行當，應該已經聽過黑盒測試與白盒測試這2個概念。但對灰盒測試，或許比較耳生。單純從名稱上來看，灰盒測試是介于黑盒測試與白盒測試之間的一種測試方式。這種測試方式，主要用于多模塊構成的稍微復雜的軟件系統(tǒng)。在灰盒測試中，重點關注軟件系統(tǒng)的各個組成模塊之間的互動。這里所說的互動，包括模塊之間的互相調用、數(shù)據(jù)傳遞、同步/互斥、等等?；液袦y試與黑盒測試的區(qū)別如果某軟件包含多個模塊，當你使用黑盒測試時，你只要關心整個軟件系統(tǒng)的邊界，無需關心軟件系統(tǒng)內部各個模塊之間如何協(xié)作。而如果使用灰盒測試，你就需要關心模塊與模塊之間的交互。這是灰盒測試與黑盒測試的區(qū)別?；液袦y試與白盒測試的區(qū)別但是，在灰盒測試中，你還是無需關心模塊內部的實現(xiàn)細節(jié)。對于軟件系統(tǒng)的內部 模塊，灰盒測試依然把它當成一個黑盒來看待。而白盒測試則不同，還需要再深入地了解內部 模塊的實現(xiàn)細節(jié)。所以，這是灰盒測試與黑盒測試的區(qū)別。灰盒測試與單元測試的區(qū)別剛才看到有網友在評論中問到此問題，俺補充一下。 首先，在進行單元測試時，需要寫一些測試代碼（行話叫“樁代碼”，洋文叫stub）。通常測試代碼和被測試代碼通常是同種語言（比如Java的單元測試 通常也用Java來寫），且測試代碼和被測試代碼的耦合很緊密。因此，單元測試通常由開發(fā)人員來完成的，測試人員的能力未必能勝任。其次，單元測試的顆粒度會更細（會細到類一級、函數(shù)一級），而灰盒測試僅僅到模塊一級。相對于黑盒測試的優(yōu)點 灰盒測試相對黑盒測試的優(yōu)點，其實有不少，俺挑幾個重要的來說說。測試可以及早介入由于黑盒測試把整個軟件系統(tǒng)當成一個整體來測試。如果系統(tǒng)的某個關鍵模塊還沒有完工，那測試人員就無法對整個系統(tǒng)進行測試，只好閑著沒事干。而灰盒測試是針對模塊的邊界進行，模塊開發(fā)完一個就測試一個。有助于測試人員理解系統(tǒng)結構為了進行灰盒測試，測試人員首先要熟悉內部模塊之間的協(xié)作機制。在熟悉的過程中，“順便”也就對整個系統(tǒng)（及其結構）有一個初步的、宏觀的認識。這有助于測試人員發(fā)現(xiàn)一些系統(tǒng)結構方面的Bug。而對于黑盒測試來說，由于測試人員不清楚軟件系統(tǒng)的內部結構，難以發(fā)現(xiàn)一些結構性的缺陷。有助于管理層了解真實的開發(fā)進度一些復雜的大系統(tǒng)，經常會發(fā)生開發(fā)進度失控的情況。因為很多開發(fā)人員有報喜不報憂的傾向。當某個開發(fā)人員號稱自己的工作已經完成了90%，往往意味著他/她還要花同樣多的時間來完成剩下的10%。這導致負責項目管理的人，無法了解開發(fā)的真實進度。由于灰盒測試針對對每一個模塊進行，而且測試人員會從一個客觀的角度來反饋模塊的完成情況，這非常有利于管理層了解整個系統(tǒng)的真實完成情況?？梢詷嬙旄玫臏y試用例如果僅僅用黑盒的方式測試系統(tǒng)的外部邊界（通常是用戶界面），有很多軟件缺陷是不容易發(fā)現(xiàn)的。俺分別以B/S系統(tǒng)和C/S系統(tǒng)來舉例。 假設開發(fā)一個復雜的（Windows環(huán)境下的）C/S軟件。那么，這個軟件通常不會僅僅只有一個EXE文件。它可能會有若干個EXE文件以及若干個 DLL文件。假如某個DLL提供的導出函數(shù)，沒有按照約定對輸入參數(shù)進行有效性判斷（比如指針是否為空），那你用黑盒測試的方式，難以暴露出這種缺陷。而 灰盒測試就容易發(fā)現(xiàn)此類問題（具體如何發(fā)現(xiàn)，后續(xù)的帖子會細說）。假如你開發(fā)的是一個Web應用系統(tǒng)，那么，這種系統(tǒng)的服務端多半會提供若干 個Web接口用于被客戶端調用。假如某個Web接口存在安全性問題/并發(fā)性問題/健壯性問題/XX問題，你單純用黑盒測試的手段，同樣難以發(fā)現(xiàn)，而灰盒測 試就可以搞定（灰盒測試是如何搞定的，后續(xù)帖子會細說）。利于提升測試人員能力很多公司搞的黑盒測試，就是讓測試人員用鼠標（鍵盤都難得用）操作用戶界面。在這種的環(huán)境里，測試人員干的活，很多都是重復性的體力勞動，技術能力難以得到提高。而如果搞灰盒測試，測試人員就需要多懂一點技術背景知識，必要時還得寫點測試腳本，對測試人員的能力提升很有好處。相對于白盒測試的好處 灰盒測試相對白盒測試的好處，比較容易概括。簡單來說，就是白盒測試較費錢（研發(fā)成本較高）。這多出來的研發(fā)成本，體現(xiàn)在如下幾個方面。首先，招聘成本較高在人才市場上，100個應聘的測試人員中，未必能夠找到一個合適的白盒測試人員。至少從俺及周圍同事的面試經歷來看，難得碰到具備白盒測試能力的人。所以，你可能要花很長時間才能找到合適的人，時間成本浪費掉了。其次，培訓成本較高可能有同學會說，招不到就內部培養(yǎng)唄。這個說起來容易，但是培訓也是有成本的。而且周期還不短，同樣要耗費時間成本。再其次，人力成本較高物以稀為貴是一條普遍的經濟學規(guī)律。由于能搞白盒測試的家伙是稀有動物，你自然不能給他/她開太低的薪水。否則人家待不了多久就跑路了。薪水開得高了，人力成本自然也就提高了。其它的一些好處 前面拿灰盒測試分別跟黑盒/白盒進行了對比，列舉了一些優(yōu)點。還有另外一些優(yōu)點，和黑盒/白盒沒啥關系，單獨列在這里。順便強化開發(fā)文檔對于一個復雜的軟件系統(tǒng)，模塊之間的接口是很重要的，因此捏，接口文檔也是很重要滴。而開發(fā)人員不愛寫文檔/不愛更新文檔，（在軟件業(yè)內）已經是臭名昭著了。很多軟件開發(fā)到后期，模塊之間的接口文檔要么沒有，要么和代碼實現(xiàn)嚴重脫節(jié)。但是，如果引入測試人員對模塊之間的接口進行測試，就可以有效防止此種弊端。因為測試人員在測試前，首先要看模塊間的接口文檔，然后再根據(jù)接口文檔設計測試用例，最后再執(zhí)行用例。因此，一旦接口文檔和代碼實現(xiàn)不符，立馬就露餡了。順便搞搞自動化灰盒測試如果落實到位，還可以跟自動化測試相結合。從此可以大大提升測試的效率，進而大大提升軟件的質量。（如何進行自動化的灰盒測試，后面的帖子會細談）灰盒測試有啥缺點？ 當然，凡事都有優(yōu)點和缺點，灰盒測試自然也不例外。下面列舉它的主要缺點。不適用于簡單的系統(tǒng)所謂的簡單系統(tǒng)，就是簡單到總共只有一個模塊。由于灰盒測試關注于系統(tǒng)內部模塊之間的交互。如果某個系統(tǒng)簡單到只有一個模塊，那就沒必要進行灰盒測試了。對測試人員的要求比黑盒測試高從上面的介紹來看，灰盒測試要求測試人員清楚系統(tǒng)內部由哪些模塊構成，模塊之間如何協(xié)作。因此，對測試的要求就提高了。因此，會帶來一定的培訓成本。不過捏，依照俺的經驗，培訓難度不大。稍微有點基礎的測試人員，都可以在短期培訓之后勝任。不如白盒測試深入顯然，灰盒不如白盒那么深入。不過捏，考慮到灰盒測試相比白盒測試有顯著的成本優(yōu)勢，該缺點不是太明顯?？偨Y 總而言之，言而總之，灰盒測試是一個很不錯的東東，其優(yōu)點明顯而缺點容易克服。另外，俺前后在兩家公司的研發(fā)部門推行過，效果不錯的說。大伙兒值得去嘗試一下。今天光說了優(yōu)缺點對比，在管理層面和技術層面，具體該如何落實？。當你企圖推行某個東東的時候，真正的障 礙往往是管理上的，而不是技術上的。所以，今天先介紹一下，推行灰盒測試之前，需要進行哪些管理上的準備工作。管理方面的準備工作 觀念上的改變 可能是因為黑盒測試應用太廣的緣故，導致很多開發(fā)人員和測試人員認為黑盒測試就是測試的全部。由于黑盒測試關注的是軟件系統(tǒng)的外部邊界。在大多數(shù)的軟件公司里，軟件的外部邊界主要就是用戶界面。這就造成了一個誤區(qū)：把軟件測試和用戶界面測試等同起來 。如果開發(fā)人員持有這個錯誤觀念，他/她就把精力放在：如何讓軟件的界面操作正常。至于軟件的內部模塊，其接口是否正常、協(xié)同是否正常，就不太關注了。用某些開發(fā)人員的話來講，就是：“軟件只要能貌似正常地工作，就行了”。同樣的，如果測試人員持有這樣的觀念，他/她就僅僅去測試軟件的外部邊界（比如用戶界面），而毫不關心軟件內部模塊的問題。在這種誤區(qū)的影響下，最終發(fā)布出來的軟件產品，多半是“金玉其外、敗絮其中”。所以，在管理上，要通過各種方式，首先改變這種錯誤的觀念，讓開發(fā)人員和測試人員都注重內部模塊的協(xié)同問題。設計上的改變 說完觀念上的改變，再來談談設計上的改變。大部分開發(fā)人員在設計內部模塊的接口時，往往只考慮開發(fā)上的便利，而不考慮測試上的便利。結果捏，軟件開發(fā)完之后，測試人員在進行模塊接口的測試時，會非常費力，甚至無從下手。所以，俺在進行模塊接口的設計評審時，會非常強調“可測試性”的考慮。以動態(tài)庫接口為例 當你用C+開發(fā)一個動態(tài)庫時，對于動態(tài)庫的導出函數(shù)可以有兩種風格：C+風格和純C風格（extern C）。在俺負責的產品中，動態(tài)庫的接口設計通常要求用純C風格的導出函數(shù)。拋開各種高深的設計理念不談（這不是今天的重點），單純考慮“可測試性”， 純C風格的函數(shù)接口非常方便測試。很多時候，測試用一些簡單的腳本，就可以對“純C風格”的導出函數(shù)進行測試。具體如何做，下一帖會具體介紹。以Web接口為例考慮到有些網友不是搞C/S開發(fā)的（尤其不是搞C+的），可能看不懂上述例子。俺再舉一個Web接口的例子。和動態(tài)庫的接口風格類似，Web接口也有兩種常見的風格：SOAP和REST（兩者的介紹參見“這里 ”和“這里 ”）。同樣的，俺比較傾向于使用REST風格。拋開其它的優(yōu)缺點不談，單純從“可測試性”來看，REST的優(yōu)勢非常明顯更簡單、更可讀。文檔上的改變 由于灰盒測試側重于內部模塊的接口測試，因此接口文檔就顯得非常重要了。模塊的其它文檔可以省略，但是模塊的接口文檔是一定不能馬虎的。接口文檔不光是 開發(fā)人員與開發(fā)人員之間的契約，而且是開發(fā)人員與灰盒測試人員之間的契約。這玩意兒的重要性，無須多說，想必大伙兒也應該明白。由于很多開發(fā)人員不愿意/不屑于寫文檔，還有一些開發(fā)人員是在編碼完成之后，再補文檔。這些都對灰盒測試的開展很不利。如果沒有徹底改變，灰盒測試很難開展。對于接口文檔的要求，俺主要強調兩點：一個是文檔的內容，一個是完成文檔的時間點。接口文檔的內容接口文檔在內容上一定要簡潔、實用，而且要確保測試人員能看懂畢竟測試人員的技術水平不如開發(fā)人員那么高。另外，不同類型的接口，會有不同的接口文檔形式，俺會在后面的帖子里面詳細介紹。接口文檔的完成時間關于時間點，俺的做法是：在內部模塊的編碼之前，一定要先讓開發(fā)人員把接口文檔寫出來，并經過評審。這么做不光對開發(fā)有好處，對測試也很有好處。當接口文檔完成后，開發(fā)人員開始Coding的時候，測試人員也可以同步進行測試用例及測試腳本的編寫。這就盡可能地實現(xiàn)了開發(fā)工作和測試工作的并行。測試團隊的改變 前面說的設計問題和文檔問題，都是開發(fā)人員的事情，那測試人員這邊，需要做出哪些改變捏？主要的一條是人員結構的改變。以俺的經驗，在測試團隊中，要安 排1/41/3的人員全力負責灰盒測試。因此，在開展灰盒測試之前，先要通過內部培養(yǎng)或外部招聘的方式，落實有能力的測試人員，來擔此重任。前一個帖子 ，俺曾經說過，灰盒測試的培訓成本/招聘成本介于黑盒與白盒之間。那么，俺就大致說一下，對負責灰盒測試的人員，大致有哪些技能方面的要求。事先聲明：灰盒測試的技能要求，與要測試軟件密切相關；以下列出的技能要求，來自俺本人的經驗，肯定不全面，僅供參考。通用技能首先，要有初步的編程基礎：至少得懂得循環(huán)語句、判斷語句、算術表達式、邏輯表達式、函數(shù)調用等最基本的東東?？紤]到多年來，高校的計算機系一直在擴招，很多測試人員都曾經在計算機系呆過，竊以為不難達到這個水平。最好掌握一門功能較強的腳本語言。按照俺的習慣，首先推薦Python （俺還專門寫了一個Python掃盲的系列教程，在“這里 ”）；當然，Perl、Lua 也可以考慮；如果你測試的軟件僅限于Windows平臺，PowerShell 也是不錯的選擇。針對B/S軟件的技能既然是B/S系統(tǒng)，HTML的一些基本語法要了解，包括：超鏈接、form的提交等。B/S的系統(tǒng)，對Web接口的調用幾乎是免不了的。因此，要有基本的HTTP協(xié)議的常識，包括：Request/Response的區(qū)別、GET/POST的區(qū)別、知道常見的HTTP狀態(tài)碼。如果這個B/S系統(tǒng)里面，大量使用JavaScript，那最好稍微了解一下JS的語法；同樣的，如果B/S系統(tǒng)中大量使用XML，也需要具備基本的XML知識。針對C/S軟件的技能假如測試的C/S軟件大量使用動態(tài)庫。測試人員最好稍微懂一點C語言的語法，因為大多數(shù)動態(tài)庫的導出函數(shù)聲明，都是用C語言描述。假如這個C/S軟件經常使用多進程及管道，那還得了解一下標準輸入/標準輸出/管道的基本概念。數(shù)據(jù)庫相關的技能無論是B/S還是C/S，可能都會涉及到數(shù)據(jù)庫。這時候，灰盒測試的家伙就需要懂一些數(shù)據(jù)庫相關的知識，包括：基本SQL語法，用上述提到的腳本進行數(shù)據(jù)庫記錄的增刪改查。網絡相關的技能假如你測試的軟件，其內部模塊還涉及網絡通訊，那最好還要掌握一些基本的網絡知識，包括：TCP/UDP的概念、用上述提到的腳本進行簡單的SOCKET編程。結尾 以上就是開展灰盒測試之前，在管理上要進行的準備工作。本系列 的下一個帖子，俺介紹一下具體的技術實現(xiàn)。 模塊接口類型概述 關于實現(xiàn)方式 在前面的帖子 里，俺提到過基于腳本 的灰盒測試。后面聊具體的技術手段時，會側重于Python腳本（這正好可以跟俺寫的另一個系列“為什么俺推薦Python ”遙相呼應）。當然啦，為了照顧那些不用Python的同學，其它的技術手段，俺也會順帶提一下。 關于Python的版本，（截至到目前）有兩個系列：2.x版本和3.x版本。這兩種版本不但在語法上有一定的差異，而且內置的標準庫也有不同?？紤]到 目前那些使用Python的開源項目，還是用2.x版本居多，所以俺后續(xù)在介紹Python腳本實現(xiàn)時，也會側重于2.x版本。各種接口的分類 由于灰盒測試的技術實現(xiàn)，是一個比較大的話題，涉及面會比較寬。為了保持一定的條理性，避免大伙兒看著看著就迷糊了，俺打算根據(jù)模塊的接口類型（也就是模塊間的交互類型）來敘述。每種類型，單獨開一個帖子來具體介紹。根據(jù)是否跨進程來分類如果從進程的角度來看，交互雙方的模塊可能在同一個進程，也可能在不同的進程。因此，模塊間的交互可以分為“進程內”、“跨進程”兩大類（不知進程 為何物，請看這里 的介紹）。對于進程間的交互，還專門有一個洋文的縮寫IPC 。根據(jù)是否跨主機來分類如果從機器的角度看，交互的雙方可能在同一個主機，也可能在不同的主機。因此，模塊間的交互類型還可以分為“主機內”、“跨主機”兩大類?！爸鳈C間”的交互，必定也是“跨進程”的。反之則不然 。順便提一下：如果從耦合的角度來看，跨主機的交互比主機內的交互，耦合低；跨進程的交互比進程間的交互，耦合低。（不知道耦合 為何物的同學，請看這里 的介紹）由于不存在“跨主機不跨進程”的接口方式，所以上述兩種分類維度排列組合之后，有3種可能。每種俺單獨開一個帖子，請看：接口測試實戰(zhàn)跨主機的交互方式 接口測試實戰(zhàn)主機內的跨進程交互方式接口測試實戰(zhàn)進程內的交互方式 跨主機的交互方式，必然涉及到網絡（為了防止愛抬杠的同學挑刺，事先聲明：本節(jié)提及的網絡，均是基于TCP/IP網絡）。在TCP/IP協(xié)議棧的4個層次中（參見這里 ），模塊間的交互方式主要是位于上面兩層（傳輸層、應用層）。有些軟件系統(tǒng)，直接采用某種現(xiàn)成的應用層協(xié)議（比如HTTP）來進行跨主機的通訊。這時候，測試人員就只需關心該應用層協(xié)議，不用操心傳輸層是如何實現(xiàn)的。還有一些軟件系統(tǒng)，自己實現(xiàn)了某種專有的應用層協(xié)議。這種情況下，對測試人員的要求就比較高了測試人員需要大致了解傳輸層的知識以及該專有應用協(xié)議的格式。（具體請看本帖的Socket這一節(jié)）基于Web接口的交互（HTTP協(xié)議） 由于這幾年B/S系統(tǒng)大行其道，而B/S系統(tǒng)，總是離不開HTTP協(xié)議，所以俺首先來介紹它。在B/S系統(tǒng)中，服務端（也叫后端）總是會提供一些Web接口給客戶端（前端）進行調用。這種調用總是基于HTTP協(xié)議來進行（HTTP協(xié)議的介紹，請看維基百科的這里 ）。當你針對服務端進行灰盒測試，你需要模擬客戶端的各種HTTP請求（既要包括合法的請求，也要包括各種非法的、無效的請求），然后再檢驗服務端返回的響應（Response）內容。如果響應內容不符合接口文檔的約定，就表明該服務端模塊出Bug了。HTTP請求（Request），常用的主要是GET方式和POST方式。這兩者的用途及區(qū)別，維基百科上已有，俺就不浪費口水了，直接說如何進行腳本編程。使用內置的標準模塊在Python腳本中，內置了完善的模塊（urllib和urllib2），以便于你操作HTTP協(xié)議。對于簡單的使用，urllib就足夠了。比如俺想用GET方式抓取Google的主頁，只需如下3行代碼：import urllibf = urllib.urlopen(/)print f.read() 如果想往某個Web接口POST數(shù)據(jù)，并得到服務端的返回內容，只需再增加1行代碼（構造POST參數(shù)）：import urllibparams = urllib.urlencode(name1:value1, name2:value2)f = urllib.urlopen(http:/xxxx/xxxx, params)print f.read() 如果需要一些復雜點的功能（比如：操作cookie、使用帶認證的proxy），urllib2就可以派上用場了。更多的使用細節(jié)，請看洋文的官方文檔（這里 和這里 ）。使用cURL俺博客的老讀者，或許記得俺在09年初寫過的一個帖子cURL(優(yōu)秀的應用層網絡協(xié)議庫) 。 看完這個帖子，你就能領會到：cURL是一個非常牛X的網絡協(xié)議庫，支持很多種網絡協(xié)議（顯然也包括HTTP）。這么牛X的一個開源庫，自然會有不少編程 語言對其進行包裹。下面俺把cURL相關的腳本語言及其開源項目列一個表格。如果你不喜歡用Python，或許可以改用俺列舉的其它腳本語言。語言/平臺 開源項目Pythonpycurl RubyCurb PerlWWW:Curl:Easy dotNetlibcurl.NET 基于數(shù)據(jù)庫的交互 在現(xiàn)有軟件系統(tǒng)的開發(fā)過程中，操作數(shù)據(jù)庫也屬于家常便飯。因此，聊完HTTP協(xié)議之后，就得來聊一下數(shù)據(jù)庫的操作。眼下，大部分程序員都是遠程操作數(shù)據(jù)庫，所以俺把數(shù)據(jù)庫的操作也歸入“跨主機”交互方式。（其實本節(jié)的內容也適用于操作本機數(shù)據(jù)庫）在很多軟件系統(tǒng)中，軟件模塊需要從數(shù)據(jù)庫中讀取數(shù)據(jù)或者把自己生成的數(shù)據(jù)存儲到數(shù)據(jù)庫中。因此，測試人員需要通過一些測試腳本，在數(shù)據(jù)庫中制造測試數(shù)據(jù)，以作為軟件模塊的輸入；或者在軟件模塊把數(shù)據(jù)保存到數(shù)據(jù)庫之后，驗證其輸出的數(shù)據(jù)是否符合接口文檔的約定。跨數(shù)據(jù)庫的接口所謂的“跨數(shù)據(jù)庫的接口”，顧名思義，就是這種編程接口可以支持多種數(shù)據(jù)庫產品。如果你沒有其它特殊的要求（比如性能），俺建議盡量用這種方式操作數(shù)據(jù)庫。這樣的好處是，萬一哪天數(shù)據(jù)庫平臺換了，你的測試腳本可以不用大改（甚至不改）。1、ODBCODBC是一種三跨（跨數(shù)據(jù)庫、跨操作系統(tǒng)、跨編程語言）的數(shù)據(jù)庫接口。大部分知名的數(shù)據(jù)庫軟件都支持ODBC方式訪問。Python有不止一個的ODBC開源項目，可以考慮用PyODBC 或ceODBC 。2、JDBC對于搞Java開發(fā)的同學，應該很熟悉JDBC。不過很多人有一個誤解，以為只有Java才可以進行JDBC編程。其實不然！自從前幾年JVM開始效仿DotNet，支持多種編程語言之后，很多腳本語言也可以在JVM上跑起來了。比如Python（JVM上叫Jython ）、Ruby（JVM上叫JRuby ）、Groovy 。作為測試人員，你也可以利用上述腳本語言，編寫基于JDBC的數(shù)據(jù)庫測試腳本。3、ADO / ADO.NetADO / ADO.Net（以下簡稱ADO）是微軟設計的跨數(shù)據(jù)庫編程接口。既然是微軟搞得，秉承其一貫風格，自然是不跨操作系統(tǒng)的。如果你所有的測試工作都在Windows平臺上，也可以考慮用ADO來訪問數(shù)據(jù)庫。如果要用Python進行ADO編程，可以考慮用PyWin32開源項目（官網在這里 ）。它是專門針對Windows平臺的Python擴展，讓Python可以很方便地調用各種Win32的API（包括ADO的API）。你還可以使用基于dotNet平臺之上腳本語言。比如IronPython 、IronRuby 等。這些運行于DotNet之上的腳本語言，自然也就具有操作ADO的能力。特定數(shù)據(jù)庫的接口前面已經提到“跨數(shù)據(jù)庫的接口”有種種好處，那啥時候需要用特定數(shù)據(jù)庫的接口捏？有時候，你需要使用某個數(shù)據(jù)庫專有的某個特色功能，這時候，通用的數(shù)據(jù)庫接口可能就搞不定了，你就需要用該數(shù)據(jù)庫特定的編程接口來寫腳本。