昨天看了測試大俠pent翻譯的一篇文章《基于用戶體驗的性能測試》，原文名稱為《User Experience, Not Metrics》，直譯為《用戶體驗，而不是度量》，大俠翻譯的很準確，不愧為前輩。這篇文章的觀點很好，最近我正好也想談談類似的話題。

　　看壇子里多數網友都在談壓力測試，討論LoadRunner的使用，氣氛熱烈而又和諧，但我今天可能要給很多人潑一盆冷水了，“你做的壓力測試“準確”嗎？”，這里我說的

　　“準確”有兩層含義：

　　符合現實：你模擬的負載測試真的能反映實際運行的負載嗎？

　　精確：你模擬測試中采集的度量數據足夠詳細、粒度夠小嗎？

　　當然，借助于專業的壓力測試工具，只要添加足夠多的monitor，“精確”應該不難，但“符合現實”嗎？以我作為過來人的經驗，大多數的壓力測試并不準確。為什么這么說，請往下看這張圖。

　　上圖是大多數人得到的一個典型的測試結果，看上去很美，但它不符合現實情況。你的計算機、測試腳本有足夠的耐心等待，但實際用戶沒有。在這個講究效率、信息爆炸、社會高速運轉的現實世界是什么樣呢？

　　另外用戶對網站的熟悉程度、網絡速度，甚至用戶的計算機水平，都會影響用戶的操作速度，進而對實際的負載形成不同的影響。

　本文是我在“第十屆中國系統與軟件過程改進年會廣東會場”所作演講的整理稿，主要分享單元測試的一些要點、單元測試實踐的主要問題，以及如何來解決這些問題。

　　一、單元測試概述

　　1.1 什么是單元測試

　　單元測試，就是針對代碼單元的獨立測試。為什么需要單元測試呢？這是代碼的基本特性決定了的。代碼有一個基本特性，就是對數據分類處理。

　　代碼通常會有很多的判定。一個判定，就是一次分類。嵌套的判定，會使分類次數的翻倍。

　　如果我們在寫代碼的時候，有一個分類漏掉了，就會產生一個Bug；如果一個分類，雖然寫了代碼，但是處理不正確，也會產生一個Bug。一個函數要沒有錯誤，必須做到兩點：1，對數據的分類必須完整；2，每一個分類的處理必須正確。做到了這兩點，就可以說，代碼的功能邏輯是正確的。

　　那么，如何檢測代碼的功能邏輯是否正確呢？

　　調試，是臨時的，且不完整的，例如，一個函數有十種輸入，調試能覆蓋五六種就不錯了。而系統測試，并不針對某個具體的函數，不關注某個函數的功能邏輯是否正確。

　　要檢測某個函數的功能邏輯，就必須要依照分類列出數據，檢測代碼是否對每一個分類都做了處理，而且每一個分類的處理是否正確。

　　——這就是單元測試。

　　1.2 單元測試的基本方法

　　由上面的分析可以看出，單元測試的基本方法就是：依數據的分類列出輸入，執行被測試程序，然后，判斷輸出是否符合預期。

　　單元測試能達到什么樣的效果呢？那就是：無論別人怎么樣，我總是對的！

最近在執行C/S控制客戶端安裝卸載的測試，通過自己的測試經歷和網上的資料，總結以下安裝卸載測試點：

　　安裝測試：

　　1、GUI測試：安裝過程中所有的界面顯示，提示信息等是否正確

　　2、兼容性測試：在不同的操作系統，不同配置的主機上能否正常安裝

　　3、安裝路徑測試（軟件不能自動安裝的情況下）：

　　軟件默認路徑安裝（一般是當前系統盤）；

　　自定義路徑安裝：缺省路徑安裝；手動輸入路徑（包括存在的和不存在的路徑）安裝；  包含特殊字符的路徑安裝；中文路徑或者中英文路徑安裝；包含空格、下劃線等合法路徑安裝；不同硬盤格式分區（FAT16，FAT32，NTFS）路徑上安裝；網絡路徑，移動設備，虛擬機等安裝路徑安裝；小于軟件安裝所需的磁盤空間路徑上安裝等

　　4、不同安裝環境下測試：包括沒安裝過的系統；已安裝過老版本（系統正在使用，系統未使用）；已安裝最新版本；卸載后重新安裝；重復安裝；多次安裝；修改安裝；修復安裝（完好軟件和有部分文件受損的軟件）；在未達到最低硬件配置下安裝等

　　5、測試各種不同的安裝組合，并驗證各種不同組合的正確性（包括參數組合，控件執行順序組合，產品安裝組件組合，產品組件安裝順序組合）等）。如在安裝CS客戶端前先安裝服務器與CS客戶端安裝后再安裝服務器，這兩種組合，對CS客戶端的安裝是否有影響。

　　6、異常情況下安裝測試：安裝過程中取消；安裝過程中關機/斷電；系統進入待機，休眠等狀態；數據庫終止；網絡終止等

　　7、至少要在一臺筆記本上進行安裝/卸載測試，因為有很多產品在筆記本中會出現問題，尤其是系統級的產品；

　　8、安裝后測試項：安裝后是否能產生正確的目錄結構和文件，文件屬性正確；安裝后動態庫是否正確；安裝后有沒有生成多余的目錄結構，文件，注冊表信息，快捷方式等；桌面是否有快捷方式，【程序】列表是否有啟動和卸載選項，安裝目錄是否為安裝時設置的路徑，安裝后的程序能否正常啟動；安裝成功后是否會對其他常用軟件有影響等。

　　卸載測試：

　　1、GUI測試：卸載過程中界面顯示，提示信息是否正常等

　　2、兼容性測試：在不同的操作系統，不同配置的主機上能否正常卸載等

　　3、通過不同方式能否正常卸載：控制面板中卸載；安裝包卸載；程序自帶程序卸載；第三 方卸載工具卸載（360，優化大師，RevoUninstaller等）

　　4、異常情況下卸載測試：卸載過程中取消；卸載過程中關機/斷電系統進入待機，休眠等狀態；數據庫終止；網絡終止；程序在運行/暫停/終止等狀態時的卸載；多次卸載等

　　5、在可以選擇組件卸載的情況下，測試各種不同的卸載組合，并驗證各種不同組合的正確性（包括參數組合，控件執行順序組合，產品卸載組件組合，產品組件卸載順序組合等）

　　注：CS客戶端不可以選擇組件卸載

　　6、卸載后測試項：是否刪除了全部的文件：安裝目錄里的文件及文件夾，非安裝目錄（向系統其它地方添加的文件及文件夾），包括exe，dll，配置文件等；是否同步去除了快捷方式——桌面，菜單，任務欄，系統欄，控件面板，系統服務列表等；復原方面－卸載后，系統能否恢復到軟件安裝前的狀態（包含目錄結構、動態庫，注冊表，系統配置文件，驅動程序，關聯情況等）（專門的測試工具regsnap）；卸載后是否對其他的應用程序造成不正常影響（如操作系統，常用應用軟件等）等

　　有什么遺漏的，望各位同仁指出。

　1、什么情況下會使用mock技術

　　（1）需要將當前被測單元和其依賴模塊獨立開來，構造一個獨立的測試環境，不關注被測單元的依賴對象，只關注被測單元的功能邏輯

　　----------比如被測代碼中需要依賴第三方接口返回值進行邏輯處理，可能因為網絡或者其他環境因素，調用第三方經常會中斷或者失敗，無法對被測單元進行測試，這個時候就可以使用mock技術來將被測單元和依賴模塊獨立開來，使得測試可以進行下去。

　　（2）被測單元依賴的模塊尚未開發完成，而被測單元需要依賴模塊的返回值進行后續處理

　　----------比如service層的代碼中，包含對Dao層的調用，但是，DAO層代碼尚未實現

　　（3）被測單元依賴的對象較難模擬或者構造比較復雜

　　----------比如，支付寶支付的異常條件有很多，但是模擬這種異常條件很復雜或者無法模擬，比如，查詢聚劃算的訂單結果，無法在測試環境進行模擬

　　2、Mock技術分類

　　（1）手動構造mock對象

　　---------------比如，可以自己寫某個接口方法的實現，根據需要編寫返回值，測試代碼中使用該實現類對象

　　缺點：會增加代碼量，在寫mock對象代碼時，有可能引入錯誤

　　（2）使用開源代碼提供的構造mock方法

　　--------------比如easyMock，提供了對接口類的模擬，能夠通過錄制、回放、檢查三步來完成大體的測試過程，可以驗證方法的調用種類、次數、順序，可以令Mock對象返回指定的值或拋出指定異常

　　3、EasyMock使用

　　（1）引入easyMock

　　------------在maven工程中，通過pom配置依賴關系

　　------------在普通java工程中，通過添加外部包的方式

　　（2）使用easyMock過程

　　1）使用EasyMock生成Mock對象；
　　pingJiaDao = mockControl.createMock(IPingJiaDao.class);

　　2）設定Mock對象的預期行為和輸出；
　　EasyMock.expect(pingJiaDao.getGoodPingJiaRate(storeId)).andReturn(0.11);

　　3）將Mock對象切換到Replay狀態；
　　EasyMock.replay(pingJiaDao);

　　4）調用Mock對象方法進行單元測試；
　　storeService.setStoredao(pingJiaDao);
　　double rate = storeService.getStoreGoodRate(storeId);

　　5）對Mock對象的行為進行驗證。
　　EasyMock.verify(pingJiaDao);

　　4、其他easyMock功能

　　（1）特殊的mock對象：niceMock
　　（2）參數匹配器
　　（3）重置mock對象
　　（4）模擬異常拋出
　　（5）設置調用次數

　上面分析了很多測試用例顆粒度粗、細的特點，那么，常規的測試來講，如何大致定位測試用例顆粒度的粗細呢？

　　下面以單一的應用環境來體現。

　　還是要強調那句話：相同的機構也可能有不同測試目的，可能是測試不同區域或是對同一區域的不同層次的測試。

　　單一條件：

　　1、時間因素：

　　時間短、項目緊、編寫用例評審時間較短時，適合粗顆粒度用例。

　　項目周期較長時，適合細顆粒度用例。

　　比如規劃六個月的項目，計劃階段和設計階段有一個半月，測試前期進入，有足夠的時間來進行人員培訓、測試用例編寫，需要細顆粒度。如果項目是一個月，測試準備時間只有五個工作日，那么可能在第三天就要完成第一輪的測試用例評審，建議以粗顆粒度為主，覆蓋功能和體現思路。

　　2、項目人員：

　　測試人員中熟手多，思路和基礎技能扎實，或測試人員構成責任心高時，可以采用粗顆粒度用例。

　　測試人員新手多，需要再指導下進行基礎測試工作，或責任心一般時，需采用細顆粒度用例。

　　測試人員熟手和新手的區別，大家一目了然。在這里，特意把責任心作為測試用例編寫粗細的一個判別標準。實際上，測試人員的職業素質中，就有責任心一項，這種品質方面的要求因人而異——而且每個人都肯定對自己的責任心還自我感覺良好。

　　舉個例子，比如安裝測試：

　　粗的寫法：在微軟的各種操作系統下進行遍歷安裝，確認setup安裝成功。——那么責任心好的人，可能會去翻閱規格書，確認setup支持的操作系統，再依次安裝測試。責任心一般的人，可能就想當然的認為visia這種過渡版本很少人用/server 2000 不是個人用戶的菜，就直接跳過這兩種系統。

　　所以面對責任心一般的人，就必須寫成細的用例：安裝測試：A、在window XP 的 SP2 環境下安裝；B、在xp的SP3 環境下安裝；C、在win server 2000 下安裝；……。

　　3、項目質量性質

　　項目質量要求一般，或項目為過渡項目，生命周期短；項目為臨時項目時，可采用粗顆粒度用例。

　　項目質量要求高，客戶或公司對質量的定位為第一位，品牌工程項目，采用細顆粒度用例。

　　難道不是所有的項目都是高質量高要求的么？當然不是。

　　不同國家和民族的人對質量的要求是不一樣的：美國是夠用就好，德國是精益求精，中國是當場不掛就行。

　　不同產業鏈位置的公司對質量要求是不一樣的：頂級公司做完美的產品，中級公司做性價比高的產品，底層公司做廉價的產品。

　　不同定位的公司對質量的要求是不一樣的：在火車站門口的飯店吃的是客流量，在市區偏遠地方的飯店吃的是回頭客。

　　不同目的的單子對質量的要求是不一樣的：做賬拉回扣的虛項目，中標后無人使用，三年后設備升級，質量就沒有要求。做重點項目，質量要求苛刻等。

　　所以，肯定會有不同的項目質量性質。也自然有不同的測試策略和測試目的，順序導出的就是不同顆粒度的測試用例。

如何有效實現軟件的需求管理（6）

　在我們公司，獲取了一個需求以后，

　　首先，相關人員會先在DevSpec建立一個條目，添加相應的一些屬性信息，比如標題，內容描述，狀態，對應文檔，優先級，緊急程度，負責人，對應版本，對應瀏覽器，對應數據庫等等。。。

　　提交完了條目以后，由于這個條目設置了一個負責人，所以那個負責人登錄系統就可以馬上看到自己名下有這個條目，他就會馬上去處理這個需求。（可能有些人沒登錄系統去看，我們也可以設置Email或者手機短信的自動提醒功能）

　　這里提到的“負責人”，在不同的過程里，負責人都是不同的，比如“評審”階段就有專門的評審負責人，普通人無法成為評審負責人，哪些人在哪些過程里能成為負責人是可以在流程中設置的。而上面提到的提交完條目后，一般情況第一個過程就是要審核剛獲取的需求，負責人審核通過后就可以把這個需求從“審核”狀態改到“需求分析”階段了，當然負責人也會改變，“需求分析”過程的負責人就會馬上知道自己有事情干了。

　　就這樣，經過一個一個的過程，經手了一個一個的負責人，這個需求就逐漸從一個只有一個思想，到有了輪廓，再設計出里面的框架，然后最后被實現。

　　其實，大家都是這么來處理需求的，不同的是，我們通過一個工具來管理這個過程，而有些公司只是就人工來做一下。我們這么做，好處和壞處其實都有，正如之前有個客戶問，你們這么做的話，是不是每一個需求的處理效率會降低？對，的確會降低，我們承認，因為這些都是嚴格的流程，而且是在一個系統中管理，肯定沒有他們口頭直接說一下快。但是，我們考慮的是我們是在賣產品，犧牲一部分的效率來確保產品的質量，我們覺得劃得來，畢竟質量才是最重要。人家雖然速度快，但是問題也來得多，需求多的時候，這個忘做了，那個做錯了，或者相互責任推來推去的事情多著了，最終導致產品質量出問題的事情比比皆是。但是我們用了系統以后，就避免了這些事情，實踐也證明了我們這么做以后，產品質量是得到保證了的。

　　當然，產品的質量也不是簡簡單單像我說上面說的“經過一個一個的過程，經手了一個一個的負責人”就能馬上實現了，這里還會涉及到很多細節注意點了，待我一一道來。

我之前說過需求管理有幾個嚴格的要求，流程化和審核機制大家其實已經看到了，其實在某種程度上，審核是流程化的一部分，因為審核過程本身就是需求處理過程中一個過程而已，我們只要在流程中設置了這種過程，安排負責人去負責就行了，當需求進入這個過程，就自然有人會去審核了。

　　如果把上面兩個要求看成是需求管理的基礎的話，那其他幾個嚴格的要求：歡迎變更、版本控制、可跟蹤性，就可以看成是確保產品質量成功的關鍵點了。有了基礎才有可能成功，有了關鍵點才能保證成功！

　　歡迎變更：

　　歡迎變更的重要性大家應該知道了，變更其實也就是需求經常變，從某種程度上也就意味著產品的質量下降，因為這個需求你不斷變化，今天剛寫好這段代碼，明天要改成那樣，后天又要大改，誰都知道有潛在風險，而且還有與之有關聯的功能呢？你突然改了個接口參數，人家可能還不知道了。靠測試？測試人員也沒法很好解決這個問題，因為今天剛測完這個功能，明天卻大改了，但是那個測試人員雖然看到這個功能需要測試，但是他卻可能認為昨天已經測好了，是不是忘記關閉了，所以就去測其他功能了。

　　那怎么解決呢？也很簡單，當有變更的時候，

　　首先，盡量讓相關的人知道，讓開發知道，讓測試知道，讓需要我們接口的人知道，這樣子大家就都會同步就完成自己要做的事情，不會出現需要做的人卻不知道他要去做這個事的情況。在DevSpec中，我們可以采用變更自動通知功能來實現，因為在DevSpec中一個需求總是和它的開發任務和測試任務關聯在一起的，所以當需求有了變更以后，只要發送一個通知，開發人員和測試人員就能馬上看到變更，就能及時去做他們的工作了。

　　第二點就是，盡量把影響的范圍搞得清楚點，讓開發知道哪些地方可能會影響到，做的時候小心點；讓測試知道這個改動會造成哪些地方有潛在的Bug，需要重點測一下。在DevSpec中，我們會有專門的功能讓設計人員和開發人員注明影響到的地方，需要重點測的地方，而且這個功能可以設置成強制，只要有變更，設計人員和開發人員就必須注明，甚至可以要求測試人員也注明測了哪些點，可以讓設計與開發人員檢查是否有遺漏。

　　第三點就是，針對任何變更（特別對于瀑布模式那種公司），因為關系到了可能會影響質量、進度及成本，風險很大，所以對于變更的內容需要專門的評審流程，評審通過后才能開始開發。在DevSpec中，我們針對這種情況，就會經常啟用變更管理視圖，在這個視圖中，會有特別的流程對變更做評審，在次期間，這個需求是沒辦法被任何人轉到開發環節的，也避免了有些人不清楚情況，直接就把沒審核的需求直接讓開發去做了。（當然，我們現在很多產品已經是用敏捷開發的模式了，所以這個功能就用得比較少了）

　　這樣子做的話，我們還是能把質量掌握在自己的手中，也就是把公司的前途掌握在自己手中。

　　（未完待續）

　　一、民航與軟件

　　隨著全球經濟一體化的發展，民航業務將會以更加多樣化的形式出現，企業間的各種業務將會更加復雜和頻繁，民航業的競爭也越來越多地體現在運用新的科技手段之上。怎樣能將民航機構原有的計算設備和網絡系統進行改造和更新，并建立一套更加先進、穩定而又具有較大的業務擴展空間的民航業務處理系統來滿足當前及未來很長一段時期內的業務需求，提高工作效率是很多民航機構需要解決的當務之急。

　　因為民航的企業性質，決定了民航業對軟件的依賴。民航業的軟件素來以高安全、高質量、高可靠、高效率著稱。依賴于質量、成本和進度的客戶滿意度，質量則是重點支撐之一，因此軟件質量是民航業最為關心的問題之一。

　　二、軟件質量管理的重要性

　　我們都知道pmbok把項目管理劃分為9個知識領域，即范圍管理、時間管理、成本管理、質量管理、人力資源管理、溝通管理、采購管理、風險管理和綜合管理。質量管理作為9大知識領域之一，可見其重要性。

　　質量管理包括：質量計劃編制、質量保證和質量控制三個過程域。質量計劃是質量管理的第一過程域，它主要結合各個公司的質量方針，產品描述以及質量標準和規則通過收益、成本分析和流程設計等工具制定出來實施方略，其內容全面反應用戶的要求，為質量小組成員有效工作提供了指南，為項目小組成員以及項目相關人員了解在項目進行中如何實施質量保證和控制提供依據，為確保項目質量得到保障提供堅實的基礎。質量保證則是貫穿整個項目全生命周期的有計劃和有系統的活動，經常性地針對整個項目質量計劃的執行情況進行評估、檢查與改進等工作，向管理者、顧客或其他方提供信任，確保項目質量與計劃保持一致。質量控制是對階段性的成果進行檢測、驗證，為質量保證提供參考依據，它是一個PDCA循環過程。

　　通常的情況是：軟件組織的最高管理層根據組織所面臨的形勢和社會需要，制定出一定時期內組織經營活動所要達到的質量目標，然后層層落實，要求下屬各部門管理者以至每個員工根據上級制定的質量目標制定出自己工作的質量目標和相應的保證措施，形成一個質量目標體系，并把質量目標完成的情況作為各部門或個人工作績效評定的依據。然而，企業的質量目的和任務必須轉化成質量目標，各級管理者必須通過質量目標對下級進行領導并以此來保證企業質量目標的實現。簡言之，軟件質量目標管理就是通過組織的管理者和員工親自參與質量目標的制定，并在工作中實行“自我控制”以完成工作目標的一種管理制度或方法。

　　三、軟件行業質量標準

　　目前業界認同的軟件質量標準主要有兩個：CMM和ISO 9001標準。

　　CMM：

　　1986年美國卡內基？梅隆大學軟件工程研究院（SEI）應聯邦政府的要求，著手研究一種對軟件承包商過程能力進行評估的方法。1987年9月SEI發布了軟件過程能力成熟框架的大綱，在大綱中定義了軟件過程評估、軟件能力評價兩種方法及相應的問卷調查表。經過4年的實踐，SEI將其發展成軟件能力成熟模型SW-CMM （Capability Maturity Model for Software）。

　　SW-CMM描述了一個軟件組織進行軟件過程定義、項目實施與測試、過程控制與改善時必須經歷的5個漸進的成熟等級及每一成熟等級相應的關鍵過程域（key process area）和關鍵實踐（key practice）。軟件組織可以依據SW-CMM標識現有軟件過程中存在的關鍵問題，制定相應的軟件過程改善策略，使軟件組織的過程能力不斷成熟，從而提高一個軟件組織始終如一地、可預見性地生產高質量軟件產品的能力。

　　六西格瑪（Six Sigma） 　　又稱：6σ，6Sigma，6Σ

　　6σ管理法是一種統計評估法，核心是追求零缺陷生產，防范產品責任風險，降低成本，提高生產率和市場占有率，提高顧客滿意度和忠誠度。6σ管理既著眼于產品、服務質量，又關注過程的改進。“σ”是希臘文的一個字母，在統計學上用來表示標準偏差值，用以描述總體中的個體離均值的偏離程度，測量出的σ表征著諸如單位缺陷、百萬缺陷或錯誤的概率性，σ值越大，缺陷或錯誤就越少。6σ是一個目標，這個質量水平意味的是所有的過程和結果中，99.99966% 是無缺陷的，也就是說，做100萬件事情，其中只有3.4件是有缺陷的，這幾乎趨近到人類能夠達到的最為完美的境界（詳見右圖）。6σ管理關注過程，特別是企業為市場和顧客提供價值的核心過程。因為過程能力用σ來度量后，σ越大，過程的波動越小，過程以最低的成本損失、最短的時間周期、滿足顧客要求的能力就越強。6σ理論認為，大多數企業在3σ～4σ間運轉，也就是說每百萬次操作失誤在6210～66800之間，這些缺陷要求經營者以銷售額在15%～30%的資金進行事后的彌補或修正，而如果做到6σ，事后彌補的資金將降低到約為銷售額的5%。

　　為了達到6σ，首先要制定標準，在管理中隨時跟蹤考核操作與標準的偏差，不斷改進，最終達到6σ。現己形成一套使每個環節不斷改進的簡單的流程模式：界定、測量、分析、改進、控制。

　　真正流行并發展起來，是在通用電氣公司的實踐，即20世紀90年代發展起來的6σ（西格瑪）管理是在總結了全面質量管理的成功經驗，提煉了其中流程管理技巧的精華和最行之有效的方法，成為一種提高企業業績與競爭力的管理模式。該管理法在摩托羅拉、通用電氣、戴爾、惠普、西門子、索尼、東芝行眾多跨國企業的實踐證明是卓有成效的。為此，國內一些部門和機構在國內企業大力推6σ管理工作，引導企業開展6σ管理。

　Solaris小技巧，雖然不常用，但很有用。

　　1、當用telnet訪問另外一臺工作站時，回格鍵不能用，Del鍵變成了回格鍵，如何使回格鍵恢復使用？

　　用如下命令：Stty erase ^H

　　2、當用telnet登錄另外一臺工作站時，如何使登錄工作站的圖形界面顯示在本機上？

　　使用如下方法：

　　在telnet之前，先使用以下命令

　　#set |grep DIS 用于查本機終端編號，如5.0

　　#xhost +登錄機主機名或IP地址

　　在telnet之后，使用：

　　#DISPLAY=本機主機名或IP地址：本機終端編號

　　#export DISPLAY

　　3、當root口令忘記時，怎么辦？如何登錄到root？

　　辦法如下：

　　利用SOLARIS的啟動盤來啟動，然后把硬盤mount上去，修改硬盤上原etc目錄下的shadow文件， 把root下的密碼用一已知的用戶密碼代替，該密碼就成為了root用戶密碼；或者干脆刪除密碼，變成無密碼。然后重新啟動主機，用該已知的用戶密碼就可登錄root用戶。

　　步驟如下：

　　（1）把你的solaris光盤放進cdrom

　　（2）鍵入stop+a

　　（3）當出現"ok"字樣時,鍵入boot cdrom -s

　　（4）cd /tmp/root

　　（5）mkdir /tmp/root/xxx （xxx是什么鬼東西就無關緊要了）

　　（6）mount /dev/dsk/c0t0d0s0 /tmp/root/xxx （在這里c0t0d0s0是你的root盤）

　　（7）運行csh

　　（8）setenv TERM vt220

　　（9）cp /tmp/root/xxx/etc/shadow /tmp/root/xxx/shadow/shadow.bak

　　（10）vi /tmp/root/xxx/shadow,并且將root項里的password域刪除即可。

　　（11）重啟動，你就可以以無密碼的root登陸了，這時更改你的密碼。

4、如何動態改變SWAP區的大小？

　　方法是：先用mkfile建一個空文件，然后用Swap 命令即可；具體步驟，舉例說明如下：如利用/export/home磁盤片中的空間，把swap區擴大200m（當然你可以要求更大）：

　　（1）#mkdir /export/home/swap

　　#cd /export/home/swap

　　該步可以沒有，只是為了把擴充的交換區文件放在一個統一的目錄（/export/home/swap）里面。

　　（2）#mkfile SIZEm swap1.file

　　（SIZE大小根據你的需求，該例中是200；swap1.file是一個SIZEm的空文件，名稱可以隨便你自己定）

　　（3）#swap -a /export/home/swap/swap1.file

　　（把交換區擴充SIZEm）

　　（4）建立/etc/rc2.d/S99swap并將第三步的內容寫入。

　　（該步使系統重新啟動時，可以自動把擴充的交換空間加上；如果沒有該步，在系統重新啟動后，需要手工加上，否則交換空間不會擴充）。

　　5、DOS文本文件到SOLARIS下的使用問題

　　如果在DOS下編的腳本文件，在SOLARIS下使用時，需要做一下變換，方法如下：在SOLARIS下用vi編輯器打開文件，按“shift+：”鍵進入命令模式，鍵入“1，$s/^M//g”，其中 ^ 是control+V鍵，M是control+M鍵。

　　6、內部網站上的Answerbook啟動

　　用：/etc/init.d/ab2mgr start

　　7、當修改了SUN主機的PROM配置，想恢復缺省配置時

　　一個方法是直接用鍵盤敲入命令，但當輸入設備設為非鍵盤時，該方法不行，請在重新啟動機器時，按住“Stop+N”鍵，即恢復所有缺省配置。

　　8、answerbook的安裝，進入……/product目錄后，用如下命令：pkg -d .

　　9、SUN U60只能在單用戶模式下運行，如何恢復？

　　問題描述：

　　為了將工作站設為從DHCP動態分配IP，并且將主機名由"unknown"改為原名

　　修改了/etc/init.d/rootusr，將dhcpinfo后面三行（不是四行）注釋掉；

　先把要恢復的文件置于MS SQL里的DATA文件里，進入MS SQL主數據庫服務器。

　　1、我們使用默認方式建立一個供恢復使用的數據庫(如MHDYF2005)。可以在SQL Server里面建立。

　　2、停掉數據庫服務器。

　　3、將剛才生成的數據庫的日志文件MHDYF2005_log.ldf刪除，用要恢復的數據庫mdf（yu1.mdf）文件覆蓋剛才生成的數據庫數據文件MHDYF2005_data.mdf。

　　4、啟動數據庫服務器。（刷新之后）此時會看到數據庫MHDYF2005的狀態為“置疑”。這時候不要對此數據庫進行任何操作。

　　5、設置數據庫允許直接操作系統表。此操作可以在SQL Server Enterprise Manager里面選擇數據庫服務器，按右鍵，選擇“屬性”，在“服務器設置”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。 use mastergosp_configure ‘allow updates‘,1goreconfigure with overridego

　　6、設置MHDYF2005為緊急修復模式，語句如下： update sysdatabases set status=-32768 where dbid=DB_ID(‘MHDYF2005‘)

　　此時可以在SQL Server Enterprise Manager里面看到該數據庫處于“只讀置疑脫機緊急模式”可以看到數據庫里面的表，但是僅僅有系統表。

　　7、下面執行真正的恢復操作，重建數據庫日志文件 dbcc rebuild_log(‘MHDYF2005‘,‘C:Program FilesMicrosoft SQL ServerMSSQLDataMHDYF2005_log.ldf‘)

　　執行過程中，如果遇到下列提示信息： 服務器: 消息 5030，級別 16，狀態 1，行 1

　　未能排它地鎖定數據庫以執行該操作。

　　DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。

　　說明您的其他程序正在使用該數據庫，如果剛才您在F步驟中使用SQL Server Enterprise Manager打開了MHDYF2005庫的系統表，那么退出SQL Server Enterprise Manager就可以了。

　　正確執行完成的提示應該類似于：

　　警告: 數據庫 ‘MHDYF2005‘ 的日志已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重置數據庫選項，并且可能需要刪除多余的日志文件。DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。

　　此時打開在SQL Server Enterprise Manager里面會看到數據庫的狀態為“只供DBO使用”。此時可以訪問數據庫里面的用戶表了。

　　8、驗證數據庫一致性(可省略)，語句如下： dbcc checkdb(‘MHDYF2005‘)

　　一般執行結果如下：CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤（在數據庫 ‘MHDYF2005‘ 中）。DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。

　　9、設置數據庫為正常狀態，語句如下： sp_dboption ‘MHDYF2005‘,‘dbo use only‘,‘false‘

　　如果沒有出錯，那么恭喜，現在就可以正常的使用恢復后的數據庫啦。

　　10、最后一步，我們要將步驟E中設置的“允許對系統目錄直接修改”一項恢復。因為平時直接操作系統表是一件比較危險的事情。當然，我們可以在SQL Server Enterprise Manager里面恢復，也可以使用如下語句完成： sp_configure ‘allow updates‘,0goreconfigure with overridego

下面這張圖給出了nio類庫的各個類之間的關系，這樣你就能知道該怎樣移動和轉換數據了。舉例來說，如果你想把byte數組寫進文件，你得先用ByteBuffer.wrap( )方法把這個byte數組wrap成buffer，再用getChannel( )在FileOutputStream上打開一個channel，然后才能用ByteBuffer把數據寫入FileChannel。

　　注意，ByteBuffer是往channel里讀寫數據的唯一途徑，而且你只能創建這一種byte基本類型的緩沖器ByteBuffer，其余基本類型的緩沖器要用"as" 方法來獲取 。另外你不能把基本類型buffer轉換成ByteBuffer ，不過你可以用view buffer往ByteBuffer里讀寫基本類型數據 ，所以這實際上也不是什么限制了。

　　另外，視圖是一種邏輯上的概念，通過視圖操作實質上就是對ByteBuffer的操作，就像通過Iterator操作List一樣。雖然我們可以用wrap() 直接把char數組轉換成CharBuffer，但實際上它還是一個ByteBuffer，而CharBuffer只是它的view。由此可知，我們操控的對象永遠都是ByteBuffer，因為只有它才能往channel里讀寫數據 ，其他基本類型數據緩沖器原理一樣。