近些年來，計算機(jī)工業(yè)的許多部分越來越強(qiáng)調(diào)軟件質(zhì)量的重要性。缺陷預(yù)防是其中一項最重要的活動，一個全球性
軟件開發(fā)的生命周期，這已直接影響到控制項目的成本和高質(zhì)量的成果。
缺陷預(yù)防涉及：
1）測試遭遇弊端。
2）缺陷分析，找出造成了這一缺陷發(fā)生原因
3）確保這些缺陷不會重演防治技術(shù)。
花費在產(chǎn)品調(diào)整上的缺陷要比花費在產(chǎn)品缺陷預(yù)防上的費用高的多。由于延誤檢測缺陷的增加，成本的確定缺陷指數(shù)增加。因此通常最明智的估量能盡早的阻止缺陷傳入產(chǎn)品之中。這些措施的成本相比在較后階段約解決這些缺陷是非常輕微的。 Syntel被定位在在第5級的過程成熟度在斯德哥爾摩環(huán)境研究所的CMM。所有實踐都定義在5級的CMM模型，被應(yīng)用在實施的每一項工程中。本文的目的是為了突出的缺陷預(yù)防和通過各種缺陷預(yù)防的活動的執(zhí)行在syntel公司討論的議題，在這個文件里包括：
● syntel的政策缺陷預(yù)防活動
● 缺陷防治數(shù)據(jù)記錄
● 缺陷的測量與分析
● 缺陷防治技術(shù)
組織政策缺陷預(yù)防活動
按該組織的政策
- 在組織水平缺陷預(yù)防的小組管理缺陷預(yù)防活動。
- 在項目一級缺陷預(yù)防協(xié)調(diào)員一名，由項目經(jīng)理管理預(yù)防活動。
- 缺陷預(yù)防小組確立了一個長遠(yuǎn)的計劃，為缺陷預(yù)防活動。
- 結(jié)果，缺陷預(yù)防的活動，是審查高級管理人員，以監(jiān)察其成效
符合該組織的政策， syntel有一個缺陷預(yù)防組，其具有代表性sepg （軟件工程過程組）。
缺陷預(yù)防小組每季計劃，其中規(guī)定了組織水平的目標(biāo)，各項活動即將進(jìn)行的，以實現(xiàn)這些目標(biāo)。它也決定以何種報告需要產(chǎn)生什么度量需要加以監(jiān)測。基于質(zhì)量管理（量化管理）董事會的投入，缺陷預(yù)防局針對具體的地方它需要集中缺陷預(yù)防的活動。當(dāng)前的目標(biāo)是缺陷預(yù)防局定于9月
2001年是5％，減少缺陷密度近一個時期以來的3個月。缺陷防治數(shù)據(jù)記錄
在項目一級，缺陷預(yù)防協(xié)調(diào)員是由項目經(jīng)理來協(xié)調(diào)缺陷預(yù)防活動項目。缺陷預(yù)防協(xié)調(diào)員，是由受過訓(xùn)練的缺陷預(yù)防組和軟件工程過程組開展缺陷預(yù)防的活動。
syntel采用同級審查過程，并據(jù)此同級審查所有可交付的程序。缺陷被查處在審查過程中，是登錄到缺損登記（附錄一）。
缺陷等級分類
1）在它們發(fā)生的階段，（要求，設(shè)計，編碼，測試等）。
2）嚴(yán)重（甲，乙，丙，丁）。每個嚴(yán)重等急被分配一個等級（A= 8 ，B= 4，C = 2D= 1 ）。
3）類型的缺陷。該缺陷被歸類為每正交缺陷分類ibm公司為8個不同的類型，分別為：f -功能，A-委派，轉(zhuǎn)讓 ，I-界面，C-校驗，B-構(gòu)建，D-文檔，G-邏輯/運算，T-定時
4）檢測機(jī)構(gòu)（內(nèi)部，像同級審查，外部由一個機(jī)構(gòu)對外向項目和客戶，像客戶機(jī)/客戶）
缺陷測量與分析
在每一個月的月末，整理記錄的缺陷和準(zhǔn)備因果分析報告。所有缺陷預(yù)防協(xié)調(diào)員開展這一活動通過各自的項目。抽樣的因果分析報告附后，在附錄二。
由于某些原因（錯誤）的缺陷得到納入該計劃。經(jīng)過分析引起這一缺陷源頭，能為缺陷的預(yù)防行動提供解決的方案。這將減少以后發(fā)生的若干缺陷。在因果分析加權(quán)缺陷將每個缺陷類型列出。缺陷預(yù)防協(xié)調(diào)員，然后決定何種類型的缺陷，需要加以分析一個根本原因。這需要不是那種其中有盡可能多的缺陷的缺陷類型。之后，針對這類缺陷，一份詳盡的根本原因分析被完成，同時開展和成因的缺陷檢測。隨后，以這種預(yù)防性行動的建議，以防止再次出現(xiàn)這種類型的缺陷。魚骨/石川圖，還可用作復(fù)雜的根本原因分析。
因果分析是做定期由缺陷預(yù)防協(xié)調(diào)員（使用帕累托圖）每月一次，其中審查，交付管理和軟件質(zhì)量保證（軟件質(zhì)量保證）。結(jié)果預(yù)防/糾正行動進(jìn)行審查，在未來幾個月的因果分析和利益記下。
除了傳達(dá)有關(guān)預(yù)防措施給項目小組，缺陷預(yù)防協(xié)調(diào)員也送因果分析報告給缺陷預(yù)防組，并討論了這一問題在每月一次的月度會議。缺陷預(yù)防組，然后通過對預(yù)防行動針對所有其他項目。如果這些行動涉及任何改變組織的標(biāo)準(zhǔn)軟件過程，他們轉(zhuǎn)達(dá)了這一進(jìn)程變革管理董事會通過正式的"過程改進(jìn)的建議" 。缺陷預(yù)防組鞏固了所收集的數(shù)據(jù)，從所有這些項目中分發(fā)預(yù)防行動建議在每月的董事局會議針對所有項目。
缺陷預(yù)防組也將準(zhǔn)備每季成本效益分析和報告調(diào)查結(jié)果向首席運營官（首席營運官）。這種分析包括：
1）過去這段時期總結(jié)
2）每個小時付出的心血
3）實際上獲得的具體的結(jié)果，在定量期而言
a）努力削減百分比
b）若干缺陷削減百分比
4）的無形利益，例如。客戶反饋，員工反饋等。
5）具體的結(jié)果，預(yù)計在未來12個月的量化計算
缺陷防治技術(shù)
缺陷預(yù)防協(xié)調(diào)員主持每月團(tuán)隊會議，他在其中介紹了調(diào)查結(jié)果的因果分析報告。引起缺陷的原因被討論同事預(yù)防方法在開發(fā)團(tuán)隊中分享。行動項目決定和責(zé)任都是固定進(jìn)行采取這些行動。在每一個項目的開始階段，或在項目啟動會議上，缺陷預(yù)防協(xié)調(diào)員負(fù)責(zé)宣傳預(yù)防行動建議在工程起始到整個項目團(tuán)隊。缺陷預(yù)防董事會每月都會審查和分析從各個項目收到的因果分析報告。所有的行動建議通過計劃和預(yù)防度量被提交，隨后缺陷預(yù)防委員會將對此計劃進(jìn)行分析。這項分析對于這個組織的水平的所有人員都很有用處。該項目可以分享信息和學(xué)習(xí)，并防止錯誤發(fā)生在其他項目。在項目組織實施的部分或全部行動的提案建議，由缺陷預(yù)防的董事會。缺陷預(yù)防董事會也可提出一些行動建議，作為試點的基礎(chǔ)。
本月刊現(xiàn)況報告（組織廣泛，缺陷因果分析報告），包括：
- 簡要介紹了重大缺陷類型報告在本月份
- 取得的主要成就和成功執(zhí)行行動中的缺陷預(yù)防
- 不完全行動建議的狀態(tài)
觀察到的好處：
1）清單，回顧有很大提高的事情。
2）重復(fù)工作已經(jīng)減少。
3）嚴(yán)重的缺陷/程式已減少。
4）培訓(xùn)計劃已見改善。
5）項目，目前正在以較低的缺陷，即使在較小的百分比經(jīng)歷資源。
結(jié)論
缺陷預(yù)防活動涉及
1）認(rèn)識機(jī)制缺陷檢測和預(yù)防。
2）知道如何搜集，分類和使用缺陷的信息。
3）申請地點吸取的教訓(xùn)。
4）根本原因分析
5）適用于缺陷預(yù)防過程。
今天
工作中碰見一件事情，讓所有人都覺得有點郁悶。
我們產(chǎn)品是一個底層的安裝框架，對上層要支持平臺軟件，再上層還要支持產(chǎn)品軟件。每個都是獨立開發(fā)，每個產(chǎn)品都定時在貨架服務(wù)器上上傳新的相對穩(wěn)定的版本，來支撐其他子域的測試和驗證，整大產(chǎn)品的主要客戶是電信運行商，規(guī)模比較的大。
我們的產(chǎn)品應(yīng)為涉及到很多個平臺（linux，solaris，windows）且每種系統(tǒng)上還有多種不同特征的版本（單機(jī)雙機(jī)多機(jī)....），一個正常的轉(zhuǎn)測試流程下來，涉及到的測試場景有10多種，平均每個測試人員要分配2-3個場景，而且不包含各種專項測試，任務(wù)量比較繁重。
一般情況的轉(zhuǎn)測試，都只使用平臺軟件來配合，不會涉及到產(chǎn)品軟件，偶爾零星的也會使用產(chǎn)品包，如果涉及到產(chǎn)品包，我們就稱之為“聯(lián)調(diào)”。進(jìn)這個項目三個月以來，只見過幾次聯(lián)調(diào)，每次都是那個幾個老員工來做。
每次轉(zhuǎn)測試的各種包，都是開發(fā)的CMO從貨架拿版本然后再轉(zhuǎn)到測試，經(jīng)由測試經(jīng)理和TSE制定好測試策略以后轉(zhuǎn)發(fā)給測試員測試，整個流程測試人員基本不會接觸到貨架，雖然一開始測試經(jīng)理一直在強(qiáng)調(diào)每個測試員都需要熟悉怎么從貨架獲取最新的版本，但是一直都沒有特別的測試要求從貨架取版本，再加上測試任務(wù)繁重，新進(jìn)的測試人員基本都不知道如何從貨架取其它域的軟件包。
這次的轉(zhuǎn)測試，是星期六早上，測試員需要花大約一天的時間來準(zhǔn)備測試環(huán)境，迭代開發(fā)的原因，轉(zhuǎn)測試流程非常緊湊。周一晨會，測試經(jīng)理宣布本次測試的所有場景都需要聯(lián)調(diào)，所有測試員都要從貨架上獲取版本。幾經(jīng)周折以后才發(fā)現(xiàn)，包括測試經(jīng)理，TSE在內(nèi)的10個人，只有3個會從貨架取平臺包，只有一個會取產(chǎn)品包。于是所有的測試進(jìn)度都停滯，等待產(chǎn)品包。偏偏不巧，產(chǎn)品的貨架包又存在不確定因素，需要和產(chǎn)品域的人溝通，而產(chǎn)品域的聯(lián)系人正巧又在開會，于是整個測試進(jìn)度從上午到晚上下班，一直停滯。
導(dǎo)致這個個時間的根本原因就是技能儲備不充分，總結(jié)一下自己對這個事件的看法以及解決辦法：
1、對于測試策略傳達(dá)不到位；
測試經(jīng)理在轉(zhuǎn)測試之后的第二天晨會才開始說明本次測試的策略，及特別注意事項，這忽略了測試人員應(yīng)對新的測試需求的學(xué)習(xí)期。
再轉(zhuǎn)測試之前的一天或者轉(zhuǎn)測試后的第一個例會上，測試經(jīng)理應(yīng)該明確的指出本次測試涉及到的場景，功能點，所需要的配套軟件，任務(wù)分配，測試周期，測試注重點。需要注意新的測試需求是否每個測試員都能理解和操作，雖然此類文檔在服務(wù)器上都有，但是每個人的理解都是不一樣的，是需要測試經(jīng)理做說明解釋。如果有三成以上的測試員對新需求不理解，需要預(yù)留時間，并組織專項培訓(xùn)。確保每個測試員都能獨立動手操作。
2、技能儲備不即時，不充分；
之前的多輪轉(zhuǎn)測試中，沒有特別檢驗過一些必備的技能，是否每個測試員都具備。
在測試的過程中對于測試員技能的儲備，是一項非常重要的工作，不能總之把希望寄托在測試員本身，必須要有一些方法來強(qiáng)制性的讓測試員對測試過程中需要用到的測試技能充分理解和運用，比如定期的組織測試員在一起討論，實現(xiàn)將測試所需技能按照優(yōu)先級羅列，要求每個員工說出自己對技能的理解和運用。只有這樣才能確保每個測試員都把基本的必備技能吃透，而不是莫林兩可。
3、測試員對于學(xué)習(xí)缺乏主動性，存在依賴思想
測試員總是這么想：我只是個測試員，按照測試經(jīng)理提出的要求做事情就是，不需要特別的去學(xué)習(xí)，就算在測試過程中遇到不懂的事情，還是可以找老員工幫忙解決。我在這里學(xué)到的業(yè)務(wù)知識，到下一個項目就完全沒用了，所以沒必要那么認(rèn)真。
如果存在這種思想，那測試員就一直是測試員，不會有提升。不可能一輩子只做一個項目，所以總會有心的開始，業(yè)務(wù)知識帶不走，但是學(xué)習(xí)知識的方式方法卻可以帶走。只有經(jīng)歷這個學(xué)習(xí)業(yè)務(wù)的過程，你才能發(fā)現(xiàn)自己適合什么樣的學(xué)習(xí)方式。如果養(yǎng)成了一個良好的學(xué)習(xí)習(xí)慣，無論做什么項目，你都會是優(yōu)秀的。還有要相信一個道理，除了自己以外誰都靠不住，因為這個世界，你能控制的就只有你自己。
以上言論屬個人想法，僅供參考。
出色的軟路由系統(tǒng)ClearOS
對于中小企業(yè)來說，有很多免費且開源的路由器和防火墻解決方案，甚至可以作為企業(yè)的選擇。這類產(chǎn)品中，很多都提供局域網(wǎng)服務(wù)，如VPN服務(wù)、熱點網(wǎng)關(guān)和通過強(qiáng)制網(wǎng)絡(luò)門戶以共享無線網(wǎng)絡(luò)。
這里，編者發(fā)現(xiàn)了一些開源且免費的路由器項目，這些產(chǎn)品適合于包括小企業(yè)、中型、甚至與思科和Juniper規(guī)模相當(dāng)?shù)钠髽I(yè)。閑言少敘，我們一起看看這七款開源且免費的Linux下的網(wǎng)絡(luò)操作系統(tǒng)。
出色的軟路由系統(tǒng)ClearOS
ClearOS是一款基于CentOS和Red Hat Enterprise Linux，主要面向中小企業(yè)和分布式環(huán)境而設(shè)計的網(wǎng)關(guān)和網(wǎng)絡(luò)服務(wù)器。ClearOS是一款出色的軟路由系統(tǒng)，具備現(xiàn)有路由系統(tǒng)的大部分功能，如DHCP，端口轉(zhuǎn)發(fā)，防火墻等。同時因為它基于Red Hat，能提供良好的功能擴(kuò)展支持。
ClearOS
ClearOS由ClearFoundation開發(fā)與支持，是開源和免費的，用戶可以從它的官網(wǎng)免費下載使用；如果是用于商業(yè)目的，ClearCenter保留收費的權(quán)利。
ClearOS Enterprise是一套服務(wù)器、網(wǎng)絡(luò)和網(wǎng)關(guān)平臺，它面向小型公司及分布式企業(yè)環(huán)境而設(shè)計。ClearOS Enterprise基于ClearOS Core，后者是Red Hat Enterprise Linux的改造。該發(fā)行靈活并且包含了大量的組件及集成服務(wù)，它們可以通過一份基于網(wǎng)頁的界面來配置。
ClearOS Enterprise中的工具有反病毒、反垃圾郵件、虛擬專用網(wǎng)、內(nèi)容過濾、帶寬管理、文件服務(wù)器、電子郵件服務(wù)、打印服務(wù)、SSL證書、網(wǎng)頁服務(wù)。ClearOS包含了一個電子集散中心，以簡化包含第三方模塊在內(nèi)的軟件安裝。該發(fā)行通過免費下載提供，并且只要免費注冊就能獲取基本操作系統(tǒng)的更新。
基于Linux的無線路由軟件DD-WRT
DD-WRT是一個基于Linux的無線路由軟件，基于GPLV2發(fā)布。DD-WRT起源于2003年，它提供了許多一般路由器的韌體所沒有的功能，例如支持XLink Kai游戲協(xié)議、基于守護(hù)進(jìn)程的服務(wù)、IPv6、無線分散式系統(tǒng)(無線網(wǎng)橋和無線中繼)、RADIUS、先進(jìn)服務(wù)質(zhì)量控制、無線輸出功率控制、超頻能力以及SD卡的硬件配置提供軟件支持。
DD-WRT是一種可用于某些無線路由器的非商業(yè)的第三方固件，功能強(qiáng)大，可以提供很多"原版"路由器不支持的功能，如調(diào)整無線發(fā)射功率等。DD-WRT固件由BrainSlayer維護(hù)，放在dd-wrt.com。從第一個版本直至V22版本都是基于Sveasoft Inc公司的Alchemy開發(fā)出來，而Alchemy又是基于以GPL發(fā)放之Linksys固件及許多其它開放源程序。由于后來人們需要向Sveasoft支付$20才能下載Alchemy固件，于是從V23開始的DD-WRT幾乎完全重寫，linux核心部分基于OpenWrt核心。
DD-WRT
從本質(zhì)上說，DD-WRT其實就是一個供無線路由器使用的嵌入版Linux，它可以在普通的家用無線路由器實現(xiàn)數(shù)千元的商用無線路由器功能，不僅如此，對于高手它甚至可以允許自行編譯程序，自由擴(kuò)展無線路由器功能。
DD-WRT的優(yōu)點確實有很多，它具有友好的Web管理/配置界面，支持多語言（包括簡體中文），可以讓無線路由器支持QoS寬帶設(shè)置、QoS L7過濾，優(yōu)化帶寬并限制最大上行、下行速度和最大連接數(shù)等，并可以封殺或者加速BT、電驢下載。支持多種客戶端連接模式，如網(wǎng)橋、中繼、客戶端等模式。支持?jǐn)?shù)種安全機(jī)制，支持客戶WPA模式、VLAN、WPA2等安全模式和機(jī)制。還支持花生殼的DDNS，方便建立個人網(wǎng)站。它甚至有改造后的直接BT下載功能。
網(wǎng)絡(luò)服務(wù)系統(tǒng)Zeroshell
Zeroshell是一款面向服務(wù)器和嵌入式設(shè)備的小型Linux發(fā)行版，其目標(biāo)是提供網(wǎng)絡(luò)服務(wù)系統(tǒng)。它可以通過自啟動運行光盤或緊湊式閃存鏡像的形式獲得，并且可以用網(wǎng)頁瀏覽器來配置。
Zeroshell
那么，總的來說Zeroshell的特性包括：負(fù)載均衡及多網(wǎng)絡(luò)連接的失效轉(zhuǎn)移，通過3G調(diào)制解調(diào)器的UMTS/HSDPA連接，用于提供安全認(rèn)證和無線網(wǎng)絡(luò)加密密鑰自動管理的RADIUS服務(wù)器，用于支持網(wǎng)頁登錄的強(qiáng)制網(wǎng)絡(luò)門戶，以及很多其他內(nèi)容。
路由操作系統(tǒng)RouterOS
RouterOS是一種路由操作系統(tǒng)，并通過該軟件將標(biāo)準(zhǔn)的PC電腦變成專業(yè)路由器，在軟件RouterOS 軟路由圖的開發(fā)和應(yīng)用上不斷的更新和發(fā)展，軟件經(jīng)歷了多次更新和改進(jìn)，使其功能在不斷增強(qiáng)和完善。特別在無線、認(rèn)證、策略路由、帶寬控制和防火墻過濾等功能上有著非常突出的功能，其極高的性價比，受到許多網(wǎng)絡(luò)人士的青睞。
RouterOS
RouterOS能將多張網(wǎng)卡組建為一個橋模式，是路由器變成一個透明的橋設(shè)備，同樣也實行三層交換的作用，MAC層的以太網(wǎng)橋、EoIP 、Prism、Atheros和RadioLAN等都是支持的。
所有802.11b和802.11a 客戶端的無線網(wǎng)卡（如station模式的無線）受802.11 的限制無法支持橋模式，但可以通過EoIP協(xié)議的橋接方式實現(xiàn)。為防止環(huán)路出現(xiàn)在網(wǎng)絡(luò)中，可以使用生成樹協(xié)議（STP） ，這個協(xié)議同樣使冗余線路成為可能。
RouterOS在應(yīng)用領(lǐng)域可以包括網(wǎng)吧、企業(yè)、小型ISP接入商、社區(qū)等地域網(wǎng)絡(luò)設(shè)備的接入，基于標(biāo)準(zhǔn)的x86構(gòu)架的PC。甚至是一臺586的PC機(jī)就可以實現(xiàn)路由功能，提高硬件性能同樣也能提高網(wǎng)絡(luò)的訪問速度和吞吐量。完全是一套低成本，高性能的路由器系統(tǒng)。
開源網(wǎng)關(guān)軟件Untangle
Untangle Gateway是一款Linux下的開源網(wǎng)關(guān)軟件，帶有可插拔的模塊以支持各種網(wǎng)絡(luò)應(yīng)用，能夠支持垃圾郵件過濾、URL阻截、網(wǎng)頁過濾、反病毒、反間諜軟件、反病毒蠕蟲、入侵阻止、虛擬專用網(wǎng)、SSL虛擬專用網(wǎng)、防火墻等多種功能。
Untangle
并且，除了一般的局域網(wǎng)服務(wù)，Untangle還免費提供隔離垃圾郵件、廣告、惡意軟件、入侵保護(hù)以及OpenVPN和強(qiáng)制網(wǎng)絡(luò)門戶等。同時，Untangle還增加網(wǎng)絡(luò)包過濾、提高惡意軟件的保，IPsec VPN以及廣域網(wǎng)平衡和故障排除等功能。
Untangle同時又是一個支持中文的開源操作系統(tǒng)，可以安裝和運行在pc機(jī)和基于X86的PC機(jī)和服務(wù)器上。它可以作為你的網(wǎng)絡(luò)路由器和防火墻提供服務(wù)，或運行于你現(xiàn)有的路由器作為一個透明網(wǎng)橋。
Linux安全發(fā)行版本Endian
Endian Firewall是一個功能齊全的Linux安全發(fā)行版本，它保護(hù)網(wǎng)絡(luò)安全并改善連接性能。
Endian操作簡單，配置主要通過web界面進(jìn)行，即刻生效。并且，Endian對硬件條件要求很低：x86兼容機(jī)、500MHz處理器、256MB內(nèi)存和4GB磁盤空間即可安裝使用。
Endian新版本
Endian可以將每一種系統(tǒng)變成一個功能齊全的安全設(shè)備，并擁有UTM的功能。基于Red Hat Enterprise Linux的Endian Firewall百分之百地源碼開放，其還包括多種功能部件，例如狀態(tài)檢測防火墻、HTTP/FTP病毒防護(hù)、內(nèi)容過濾、POP3/SMTP病毒防護(hù)、反網(wǎng)絡(luò)釣魚和反垃圾郵件工具、SSL/TLS虛擬專用網(wǎng)、入侵檢測系統(tǒng)、狀態(tài)數(shù)據(jù)包檢測防火墻、多種協(xié)議（HTTP、FTP、POP3、SMTP）的應(yīng)用程序級代理、反病毒和垃圾郵件過濾、Web通信過濾和VPN等功能。
最新版Endian添加了一個基于Web的管理控制臺、OpenVPN服務(wù)器可運行在獨立的區(qū)域中以及可正常過濾日文的垃圾郵件等。
路由系統(tǒng)Vyatta
Vyatta是一款可以幫助企業(yè)快速設(shè)置路由的路由系統(tǒng)。Vyatta的軟件基于使用可擴(kuò)展開放路由平臺(XORP)開發(fā)的代碼，此平臺從2002年開始成為一個開源路由器軟件項目。
Vyatta的代碼將經(jīng)過修改的Linux操作系統(tǒng)與XORP結(jié)合在一起。用戶可通過從該公司的網(wǎng)站下載CD映像并將其安裝在PC 硬件上來構(gòu)建Vyatta路由器。Vyatta一直與Sangoma等合作伙伴合作，后者制造用于x86 PC系統(tǒng)的T-1和T-3 WAN接口卡，Vyatta還計劃很快宣布更多的硬件合作伙伴。
Vyatta
而Vyatta同時也是一家開源技術(shù)公司，其目前的任務(wù)是將XORP(可擴(kuò)展開源路由器平臺)帶入商用領(lǐng)域，使得它成為一款企業(yè)級的開源路由器軟件。
Vyatta OFR可代替有上千個用戶的小型企業(yè)的商業(yè)路由器。Vyatta路由器代碼的開源特性可供公開審查及檢查代碼中潛在的錯誤及漏洞，這使得它比其他商業(yè)化產(chǎn)品更安全。Vyatta OFR軟件可從Vyatta公司的網(wǎng)站www.vyatta.com下載。
由于中LGWR和DBWR工作的不一致，Oracle引入了檢查點的概念，用于同步，保證數(shù)據(jù)庫的一致性。在Oracle里面，檢查點分為兩種：完全檢查點和增量檢查點。下面我們分別介紹這兩種檢查點的作用：
1、完全檢查點
在Oracle8i之前，數(shù)據(jù)庫的發(fā)生的檢查點都是完全檢查點，完全檢查點會將數(shù)據(jù)緩沖區(qū)里面所有的臟數(shù)據(jù)塊寫入相應(yīng)的數(shù)據(jù)文件中，并且同步數(shù)據(jù)文件頭和控制文件，保證數(shù)據(jù)庫的一致。完全檢查點在8i之后只有在下列兩種情況下才會發(fā)生：
（1）DBA手工執(zhí)行alter system checkpoint的命令；
（2）數(shù)據(jù)庫正常shutdown（immediate,transcational,normal）。
由于完全檢查點會將所有的臟數(shù)據(jù)庫塊寫入，巨大的IO往往會影響到數(shù)據(jù)庫的性能。因此Oracle從8i開始引入了增量檢查點的概念。
2、增量檢查點
Oracle 從8i開始引入了檢查點隊列這么一種概念，用于記錄數(shù)據(jù)庫里面當(dāng)前所有的臟數(shù)據(jù)塊的信息，DBWR 根據(jù)這個隊列而將臟數(shù)據(jù)塊寫入到數(shù)據(jù)文件中。檢查點隊列按時間先后記錄著數(shù)據(jù)庫里面臟數(shù)據(jù)塊的信息，里面的條目包含RBA（Redo Block Address，重做日志里面用于標(biāo)識檢查點期間數(shù)據(jù)塊在重做日志里面第一次發(fā)生更改的編號）和數(shù)據(jù)塊的數(shù)據(jù)文件號和塊號。在檢查點期間不論數(shù)據(jù)塊更改幾次，它在檢查點隊列里面的位置始終保持不變，檢查點隊列也只會記錄它最早的RBA，從而保證最早更改的數(shù)據(jù)塊能夠盡快寫入。當(dāng)DBWR將檢查點隊列里面的臟數(shù)據(jù)塊寫入到數(shù)據(jù)文件后，檢查點的位置也要相應(yīng)地往后移，CKPT每三秒會在控制文件中記錄檢查點的位置，以表示Instance Recovery時開始恢復(fù)的日志條目，這個概念稱為檢查點的“心跳”（heartbeat）。檢查點位置發(fā)生變更后，Oracle里面通過4個參數(shù)用于控制檢查點位置和最后的重做日志條目之間的距離。在這里面需要指出的是，多數(shù)人會將這4個參數(shù)看作控制增量檢查點發(fā)生的時間。事實上這是錯誤的，這4個參數(shù)是用于控制檢查點隊列里面的條目數(shù)量，而不是控制檢查點的發(fā)生。
（1）fast_start_io_target
該參數(shù)用于表示數(shù)據(jù)庫發(fā)生Instance Recovery的時候需要產(chǎn)生的IO總數(shù)，它通過v$filestat的AVGIOTIM來估算的。比如我們一個數(shù)據(jù)庫在發(fā)生Instance Crash后需要在10分鐘內(nèi)恢復(fù)完畢，假定OS的IO每秒為500個，那么這個數(shù)據(jù)庫發(fā)生Instance Recovery的時候大概將產(chǎn)生500*10*60=30,000次IO，也就是我們將可以把fast_start_io_target設(shè)置為 30000。
（2）fast_start_mttr_target
我們從上面可以看到fast_start_io_target 來估算檢查點位置比較麻煩。Oracle為了簡化這個概念，從9i開始引入了 fast_start_mttr_target這么一個參數(shù)，用于表示數(shù)據(jù)庫發(fā)生Instance Recovery的時間，以秒為單位。這個參數(shù)我們從字面上也比較好理解，其中的mttr是mean time to recovery的簡寫，如上例中的情況我們可以將fast_start_mttr_target設(shè)置為600。當(dāng)設(shè)置了 fast_start_mttr_target后，fast_start_io_target這個參數(shù)將不再生效，從9i后 fast_start_io_target這個參數(shù)被Oracle廢除了。
（3）log_checkpoint_timeout
該參數(shù)用于表示檢查點位置和重做日志文件末尾之間的時間間隔，以秒為單位，默認(rèn)情況下是1800秒。
（4）log_checkpoint_interval
該參數(shù)是表示檢查點位置和重做日志末尾的重做日志塊的數(shù)量，以O(shè)S塊表示。
（5）90% OF SMALLEST REDO LOG
除了以上4個初始化參數(shù)外，Oracle內(nèi)部事實上還將重做日志文件末尾前面90%的位置設(shè)為檢查點位置。在每個重做日志中，這么幾個參數(shù)指定的位置可能不盡相同，Oracle將離日志文件末尾最近的那個位置確認(rèn)為檢查點位置。
oracle 9i instance recovery
1、增量檢查點
在checkpoint queue的基礎(chǔ)上實現(xiàn)了增量檢查點，每3秒發(fā)生一次checkpoint heartbeat，記錄dbwr上次寫成功的最大RBA(redo block address)。這樣的話做instance recovery的時候就從這個rba開始，而不是從上次checkpoint scn開始，大大節(jié)省了恢復(fù)時間。
2、twice scan of redo log
在應(yīng)用redo之前，redo將會被操作兩次，第一次去掃描哪些redo record需要被應(yīng)用，因為9i在redo里添加了dbwr寫數(shù)據(jù)塊的信息，所以dbwr發(fā)生前的日志將不會被應(yīng)用。第二步就是選出需要被應(yīng)用的日志然后開始rollforward。
3、rollforward
在做instance recovery時必須先定位到redo log 然后應(yīng)用所有日志到datafile，這時候包括了committed和uncommitted的數(shù)據(jù)。當(dāng)做完rollward，數(shù)據(jù)庫就可以open了。
4、rollback
因 為rollforward產(chǎn)生了uncommitted數(shù)據(jù)，所以必須回滾這些數(shù)據(jù)。這將由smon和on-demand rollback來實現(xiàn)。smon將會掃描undo segment header去標(biāo)志所有活動事務(wù)為dead，然后會逐漸去回滾這些事務(wù)。另外on-demand rollback提供了前臺進(jìn)程進(jìn)行rollback，當(dāng)前臺進(jìn)程企圖獲得被dead事務(wù)占用row lock，這時候前臺進(jìn)程將會去undo segment取得before image去回滾這個塊，至于其他被這個dead事務(wù)lock的塊就等待smon去回滾。
另外，如果 在數(shù)據(jù)庫打開的過程中process crash導(dǎo)致transaction dead，resource不能被釋放的情況，這時候如果另一個進(jìn)程需要這些resource，那么這個進(jìn)程將會等待直到pmon清理dead process釋放出resource。
如果數(shù)據(jù)庫Crash，重新啟動，很久遠(yuǎn)以前的未提交事務(wù)并不在Redo的恢復(fù)序列中。
但是未提交事務(wù)一定在回滾段事務(wù)表上存在，并且State＝10，為活動事務(wù)。這就夠了。
數(shù)據(jù)庫啟動之后，這些事務(wù)會被SMON逐個標(biāo)記為Dead（不可能再活過來了），然后由SMON慢慢去回滾這些事務(wù)；也存在另外一種情況，后來的進(jìn)程會去讀這些未提交數(shù)據(jù)，發(fā)現(xiàn)Dead事務(wù)未提交，則主動進(jìn)行回滾。
1、一個數(shù)據(jù)塊發(fā)生更新，必然寫回滾
2、回滾段的block變化也記錄在redo中
一份未提交的數(shù)據(jù)必定在回滾中有相應(yīng)的前鏡像，任何正常的恢復(fù)都一定會把這些變化重新構(gòu)建出來。
想像一下
1、update事務(wù)1更新了block 1
2、回滾段1記錄了block1的前鏡像
3、checkpoint
4、update事務(wù)2更新了block2
5、回滾段2記錄了block2的前鏡像
6、instance crash
現(xiàn)在重啟數(shù)據(jù)庫
1、根據(jù)redo重新構(gòu)建block2
2、根據(jù)redo重新構(gòu)建回滾段2
3、database open
4、SMON用回滾段2的數(shù)據(jù)回滾block2，SMON用回滾段1的數(shù)據(jù)回滾block1
最后一步也可能是
在另外一個select檢索到block1或者block2的時候，發(fā)現(xiàn)這兩個block的數(shù)據(jù)都是未提交的，此時再回滾block1和block2。
所以，只要有相應(yīng)的回滾數(shù)據(jù)存在，無論什么時候oracle都可以找到一致的數(shù)據(jù)，oracle只需要知道這個事務(wù)是提交了的還是沒提交了的，而這點在block header ITL中有記錄。
很久沒有積累東西了，碰巧前幾天遇到一個的問題，雖然不大但是比較有意思，在這里稍微記錄一下，以后可以作為
面試題之類的考驗
其他人，想想也遠(yuǎn)比那些被我們詬病的題目要實際的多：
有表結(jié)構(gòu)如下：
| T_SOME_TABLE{ crowid varchar(36); zrmb float(7,3); zjdw float(7,3); } |
問以下兩段代碼，哪段會出現(xiàn)錯誤，為什么？
代碼片段一：
| String hqlStr="select SUM(t.zrmb) AS SUM_1,SUM(t.zjdw) AS SUM_2 from T_SOME_TABLE t where 1=1 "; List sumList=baseDao.find(hqlStr); request.setAttribute("sumList",sumList); String sum1=""; String sum2=""; ArrayList sumList=request.getAttribute("sumList")==null?null:(ArrayList)request.getAttribute("sumList"); if(null!=sumList){ for(int i=0;i<sumList.size();i++){ Object[] tempObj=(Object[])sumList.get(i); sum1=tempObj[0]==null?"0.0":tempObj[0].toString(); sum2=tempObj[1]==null?"0.0":tempObj[1].toString(); } } out.prinln("sum1:"+sum1); out.prinln("sum2:"+sum2); |
代碼片段二：
| String hqlStr="select SUM(t.zrmb) AS SUM_1 from T_SOME_TABLE t where 1=1 "; List sumList=baseDao.find(hqlStr); request.setAttribute("sumList",sumList); String sum1=""; ArrayList sumList=request.getAttribute("sumList")==null?null:(ArrayList)request.getAttribute("sumList"); if(null!=sumList){ for(int i=0;i<sumList.size();i++){ Object[] tempObj=(Object[])sumList.get(i); sum1=tempObj[0]==null?"0.0":tempObj[0].toString(); } } out.prinln("sum1:"+sum1); |
實際運行會發(fā)現(xiàn) 代碼片段2會出現(xiàn)錯誤 而代碼片段1是正常可以運行的，這里是在功能開發(fā)過程中 片段2是在片段1的基礎(chǔ)上慣性思維去實現(xiàn)的，而實際運行卻會發(fā)現(xiàn) 結(jié)果并不是想要的那樣，這個動手能力強(qiáng)的人可以實際調(diào)試一下就會很快明白里面的所以然。這里簡單說一下：
做過hibernate的人都知道 用hibernate調(diào)用sql查詢出的匯總語句，返回的結(jié)果是封裝成Object的保存到List中的，而代碼1和代碼2相比較，差別只是在字段的多少上，如果是2個以上的字段 結(jié)果是封裝成Object[]數(shù)組的，這個無可爭議，但是如果是一個字段的話List里保存的是Object，而不是Object[]數(shù)組。
這樣就可以推論這里hibernate內(nèi)部是做了處理的。
代碼2循環(huán)中應(yīng)該是：
| Object tempObj=(Object)sumList.get(i); sum1=tempObj==null?"0.0":tempObj.toString(); |
微軟產(chǎn)品開發(fā)中的“戰(zhàn)爭與和平”
沖突是微軟開發(fā)工作時的常態(tài)，每個微軟新產(chǎn)品的孕育過程概莫能外地充斥著質(zhì)疑、抗?fàn)帯⒖鄲灐㈧?#8230;…理念的交擊、智慧的沖撞讓軟件開發(fā)的各個階段都彌漫著硝煙，直至產(chǎn)品發(fā)布，然后又要邁入下一個循環(huán)。對于微軟工程師們來說，這樣的經(jīng)歷就仿佛是一次次痛苦但不乏驚喜的涅槃。
這篇博客記錄了微軟Windows Server 2008 R2*中國團(tuán)隊的一些真實經(jīng)歷與感悟，例如“暗藏殺機(jī)”的季度性產(chǎn)品評審會議；微軟工程師如何“向用戶學(xué)習(xí)”；軟件開發(fā)過程中只有對錯、沒有“權(quán)威”……
*Windows Server 2008 R2是與Windows 7同步研發(fā)、同時面世的微軟新一代服務(wù)器操作系統(tǒng)。
Windows Server 2008 R2今天在北京正式發(fā)布，由我們負(fù)責(zé)開發(fā)的Active Directory Administrative Center（活動目錄管理中心，以下簡稱“ADAC”）也將真正開始接受IT管理員們的檢驗。
為迎接這一天，我們準(zhǔn)備了非同尋常的一年半。有過重重壓力，有過混亂無序，甚至懷疑過這是否是“不可能完成的任務(wù)”。而當(dāng)Windows Server 2008 R2預(yù)發(fā)布版本問市后，美國權(quán)威IT技術(shù)信息雜志《Windows IT Po》在一篇新功能點評文章中，將ADAC評價為最受關(guān)注新功能第一名，這讓我們高興了好一陣子——我們收獲的不僅僅是一件令團(tuán)隊成員自豪的產(chǎn)品，更重要的是，我們證明了中國研發(fā)團(tuán)隊的能力。
在我們在踏上新的征程之時，謹(jǐn)以三個幕后故事來記錄我們的努力和過往那些“硝煙彌漫”的日子。
測試主管Jun的故事：從虛無縹緲到事實
Windows Server 2008 R2即將發(fā)布第一個測試版時，Jun正在美國參加一個季度性產(chǎn)品評審會議。當(dāng)時，他的測試團(tuán)隊因為對ADAC采取了與美國不一樣的測試策略，在產(chǎn)品開發(fā)前期更激進(jìn)地尋找bug，最后挖出了538個，“榮登”活動目錄整個產(chǎn)品線所有新舊產(chǎn)品bug數(shù)榜首，并幾乎與“活動目錄”其他產(chǎn)品的總bug量相當(dāng)——作為團(tuán)隊代表，如果Jun無法讓管理層信服，整個中國開發(fā)團(tuán)隊能夠在Windows Server 2008 R2發(fā)布前解決這些問題，那么這個項目很可能會被砍掉，這意味著十多位工程師一年多的努力將化為泡影。
當(dāng)Jun不厭其煩地闡述、分析，并反復(fù)強(qiáng)調(diào)ADAC一定能夠和Windows Server 2008 R2一起發(fā)布的時候，“活動目錄”產(chǎn)品線的總經(jīng)理，一位白胡子老者（真的很像圣誕老人）笑瞇瞇地轉(zhuǎn)過頭說：“你知道在英語中我如何來描述你的結(jié)論（可以和Windows Server 2008 R2 一起發(fā)布）嗎？我比較喜歡這個單詞：illusion （虛無縹緲）”。
那一刻，雖然Jun嘴上依然掛著笑容，但是陣陣?yán)浜挂言诤蟊撤浩?#8230; …在強(qiáng)迫自己冷靜之后，Jun回答道：“我們看到的不只是靜態(tài)的數(shù)據(jù)，還是一個發(fā)展的趨勢，基于bug數(shù)量遞減的速度和趨勢，我依然有信心，我們能夠完成這一產(chǎn)品。”
知道是被中國團(tuán)隊的執(zhí)著所打動，還是真的相信了Jun的“趨勢論”，總之“圣誕老人”在會后并未將這個項目從Windows Server 2008 R2里砍去。但他設(shè)置了一個非常嚴(yán)格的時間表，要求中國團(tuán)隊在相應(yīng)時間內(nèi)將bug數(shù)量降低到可控的范圍之內(nèi)。像很多故事一樣，不懈努力的結(jié)局是美好的。最終，Jun的測試團(tuán)隊因為出色的表現(xiàn)（自動化測試的穩(wěn)定性和測試的代碼覆蓋率都超過了微軟的標(biāo)準(zhǔn)）而受到了“圣誕老人“的特別肯定。
開發(fā)人員Elfe的故事：用戶是最好的老師
在產(chǎn)品開發(fā)過程中，開發(fā)、測試人員和項目經(jīng)理之間常常會有很多的爭論：爭論產(chǎn)品的某一表現(xiàn)究竟是錯誤還是本該如此的特性；受時間所限，開發(fā)人員不可能修正所有的bug，因此對于bug大家會爭論它的嚴(yán)重程度與優(yōu)先級，以決定是否需要修正。有時候?qū)嵲谑歉饔懈鞯睦恚l都說服不了誰，問題就只能暫時擱置。
當(dāng)產(chǎn)品第三個里程碑結(jié)束時，用戶體驗小組邀請了幾位IT管理員用戶，請他們在產(chǎn)品上完成擬定的幾項操作任務(wù)。用戶體驗小組架起了三個攝像頭，分別對著電腦屏幕、鼠標(biāo)與用戶的臉部，通過錄像分析用戶執(zhí)行任務(wù)的順利程度，以衡量產(chǎn)品的設(shè)計。研究結(jié)束后，用戶體驗小組給所有開發(fā)團(tuán)隊發(fā)了長長的報告，列出產(chǎn)品所有成功與失敗的地方；此外還精選了一部分錄像供大家參考。
錄像中是一張張困惑、受挫、驚奇甚至絕望的臉。有用戶在一個沒有提示的輸入框里進(jìn)行了十幾次嘗試卻無一成功；有用戶對一條簡略的出錯報告信息上天入地怎么都找不到錯誤的具體原因；有用戶成功執(zhí)行了操作卻因界面未及時刷新而停在那里苦苦等待；有用戶誤操作不可恢復(fù)地刪除了重要數(shù)據(jù)，把嘴張成O形呆坐在那里。
這些錄像就像整蠱視頻一樣，實在是搞笑。在鏡頭前，可憐的IT管理員們就像不知情的被整對象手足無措。大家看得樂呀——“這么簡單的事他們怎么就不會呢？”
但在笑過之后，大家又都臉上發(fā)燒：這可都是因為我們的錯啊。趕緊回頭找找，為什么有些問題我們在設(shè)計時沒能考慮到，為什么有些bug我們沒能發(fā)現(xiàn)，為什么有些bug我們會認(rèn)為無關(guān)緊要而不去修正。用戶是最權(quán)威的裁判，告訴了我們什么是對什么是錯。
開發(fā)人員 Elfe 感嘆：“此后每有爭論，我腦海中就會出現(xiàn)用戶那張絕望的臉。于是，慎重地從用戶角度來考慮事情，而不敢為了追求進(jìn)度推諉掩藏問題。用戶的受挫體驗，給我上了最生動的一課。”
測試人員Li的故事：不懼權(quán)威的質(zhì)疑
除了開發(fā)新一代的活動目錄管理工具外，中國團(tuán)隊還要維護(hù)一個從Windows NT4開始，被一代又一代的管理員沿用了十多年傳統(tǒng)管理工具。確保它能在Windows Server 2008 R2上穩(wěn)定運行，是一項至關(guān)重要的任務(wù)。
項目開始不久，Li就發(fā)現(xiàn)舊工具上的一個右鍵菜單項未作任何改動就莫名其妙失蹤了！檢查相關(guān)代碼后也沒有發(fā)現(xiàn)什么異常。這難道是其它小組的代碼改動所致？雖然中國團(tuán)隊只負(fù)責(zé)ADAC的開發(fā)，但是同樣有權(quán)限查閱和修改Windows的任何代碼。沒有理由說懷疑上述問題是別人導(dǎo)致的就放任不管。既然有了代碼，Li就主動請纓負(fù)責(zé)尋找問題的根源。在結(jié)合多種排錯手段后，終于把問題定位到美國團(tuán)隊負(fù)責(zé)的界面代碼中。
接下來，Li把問題描述、對應(yīng)的代碼、代碼修改前后的比較和邏輯分析發(fā)給了相應(yīng)的美國團(tuán)隊。對方很快就著手分析，一名合伙人級別的開發(fā)工程師（微軟某產(chǎn)品線或技術(shù)的首席代表）為此發(fā)信詢問更詳細(xì)的來龍去脈。他堅持認(rèn)為，根據(jù)他原先的設(shè)計，相應(yīng)的問題是不應(yīng)該出現(xiàn)的，他懷疑是我們團(tuán)隊工程師的不當(dāng)調(diào)用造成的——但Li并沒有因為對方是“權(quán)威”而放棄質(zhì)疑。他再次回信分析，最終說服了美國同事在相應(yīng)的組件中修正了錯誤，消失已久的右鍵菜單項又恢復(fù)如初了。
類似的情景，在服務(wù)器與開發(fā)工具事業(yè)部中國團(tuán)隊，在整個微軟中國研發(fā)集團(tuán)，每天都在上演且永遠(yuǎn)不會結(jié)束。驅(qū)策我們不斷克服困難、努力前行的動力是身為中國軟件工程師的責(zé)任感和以創(chuàng)新影響全球用戶的成就感。
一地雞毛——軟件項目中的人際困局
作者結(jié)合切身經(jīng)歷，展示了他之前所在團(tuán)隊軟件項目延期的種種原因，而其中印象最深刻的是各種人事紛擾乃至于勾心斗角。
六年前，畢業(yè)未久的我在一家外企工作，我所在團(tuán)隊開發(fā)的軟件項目在交付到集成測試組時因種種原因延期一周。這本身根本不是什么大事情，但其間各種人事紛擾乃至于勾心斗角卻著實令我印象深刻。
公司
我的老東家是一家大型跨國電信設(shè)備開發(fā)商，曾具有輝煌的歷史。我還記得在公司110周歲的生日慶典上，一位高管致辭說：“110年，這不是奇跡，是成績”，令人不勝欷歔。遺憾的是，公司在.com泡沫中遭遇重創(chuàng)，一蹶不振。時任CEO為求擺脫困境，打起了人力成本的主意。當(dāng)時，公司在美國雇用一名工程師的綜合人力成本接近中國的2.5倍【注：工資只是其中一小部分】。至于法國，成本比美國還要略高一些，而且不要忘了，人家可是35小時工作周。大家都是聰明人，很快就看到端詳：公司正在法國裁員，將項目轉(zhuǎn)移到中國。
令人尷尬的是，我所在的中國團(tuán)隊恰好就在與法國團(tuán)隊合作。這一項目最早完全在法國，此后幾年時間，中國團(tuán)隊大規(guī)模擴(kuò)張人手（我就是這樣進(jìn)來的），將項目模塊逐一從法國團(tuán)隊手中接過來。剛開始，法國工程師將原先的模塊移交中國之后，便轉(zhuǎn)而從事其他項目或職位，談不上什么個人損失，雙方共事可謂融洽。后來可就不是這么回事了。有一次，兩位中國工程師去巴黎接手一個項目，一位法國工程師負(fù)責(zé)培訓(xùn)，為時2~3個月。在這位法國老師兢兢業(yè)業(yè)的幫助下，兩位中國工程師成功掌握整個模塊，按期于圣誕節(jié)前夕歸國。告別巴黎時，沒有一個法國同事去跟他們寒暄話別—那位法國老師被裁掉了，他的最后一個工作日恰好就在兩位中國工程師離開的同一天，法國同事都去送他了。
到發(fā)生本文將要詳述的交付延期之時，所有模塊的開發(fā)工作都已從法國團(tuán)隊移交到中國團(tuán)隊，而集成測試雖然仍由法國團(tuán)隊負(fù)責(zé)，但從法國到中國的移交也已開始。不妨猜猜看，法國集成測試團(tuán)隊的工程師們此刻在想些什么。
團(tuán)隊
我很幸運，畢業(yè)后初入職場就遇到一位好經(jīng)理H，坦率地說，她也是我到目前為止跟隨過的幾位經(jīng)理中最好的一位。中國很多女經(jīng)理都有一個共同的特點：沒有私心。她們對于自己的晉升、提薪并無多大熱情，更愿意把心思、時間和精力花在輔導(dǎo)和培養(yǎng)自己的團(tuán)隊上面。
H因分娩而“暫時”離開我們團(tuán)隊。經(jīng)過短暫的過渡，接任我們經(jīng)理的是T，一位新近招聘的職業(yè)經(jīng)理人。他的風(fēng)格與H大為不同。僅舉一例說明。當(dāng)年向H請一天年假，她總是微笑著說：“沒問題。不影響工作吧？”T則會端起架子：“不影響工作吧？沒問題。”語序上的變化，加上語氣的差別，雖然只是細(xì)微末節(jié)，卻反映了態(tài)度的不同、對員工是否尊重。除此之外，更嚴(yán)重的是工作態(tài)度問題。現(xiàn)在我們知道，T在北京待了不到一年時間，買下兩套房、一輛車，還辦妥了到加拿大的移民和那邊的工作—而在當(dāng)時，我們這些員工僅僅只是知道，我們的經(jīng)理不太在辦公室出現(xiàn)。
在團(tuán)隊內(nèi)部，我所在的FM小組與另一個CM小組工作是緊密銜接的。但在CM小組的核心員工之間卻存有罅隙：小組長B與技術(shù)骨干S矛盾日增。怎么說呢，這兩位都是很好的同事，然而好人之間也會彼此鄙視的：S認(rèn)為B不懂技術(shù)，瞎指揮；B認(rèn)為S目空一切，難以共事。缺少一位好領(lǐng)導(dǎo)來調(diào)和，好員工也不能組成一個好團(tuán)隊。
流程
我們開發(fā)的是一個龐大的電信軟件項目—3G接入網(wǎng)網(wǎng)管系統(tǒng)，采用的開發(fā)流程仍然是傳統(tǒng)的瀑布式。簡單來說，依時間順序，一個軟件工程師（首先是各小組的小組長）需要依次參與以下幾個階段。
需求階段：跟蹤和審閱由系統(tǒng)架構(gòu)師撰寫的需求文檔，必要時要求澄清，然后預(yù)估工作量，經(jīng)理據(jù)此調(diào)整人員安排。
設(shè)計階段：分析需求文檔，完成模塊設(shè)計，據(jù)此撰寫高層設(shè)計文檔和底層設(shè)計文檔，前者以定義模塊接口為主，后者則涉及更多細(xì)節(jié)。
編碼階段：根據(jù)兩份設(shè)計文檔完成實際編碼工作。
單元測試階段：是的，你沒有看錯。根據(jù)本部門正式的、成文的流程，單元測試階段在編碼階段之后安排時間進(jìn)行。在實踐中倒是沒有這么僵化，大家盡可以測試先行，只要時間大致齊即可。
各開發(fā)團(tuán)隊在完成各自負(fù)責(zé)的一或多個模塊的單元測試之后，將代碼提交到統(tǒng)一的代碼庫，打上標(biāo)簽，然后將這些標(biāo)簽連同其他注意事項寫成文檔保存到指定目錄。其后，就是集成測試階段了—集成測試團(tuán)隊收集所有團(tuán)隊的所有標(biāo)簽，從代碼庫提出相應(yīng)的代碼進(jìn)行編譯，編譯成功后即按照事先準(zhǔn)備的測試用例進(jìn)行測試，給開發(fā)團(tuán)隊提Bug。
我參與了前面幾個版本3.X、4.0的開發(fā)，僅從技術(shù)角度而言，瀑布式開發(fā)流程工作得尚稱流暢。但工程師是要領(lǐng)工資的，軟件寫出來是要賣錢的，一套經(jīng)典的瀑布式流程走下來往往耗時幾個月甚至年余，等到軟件產(chǎn)品正式發(fā)布，用戶需求已然發(fā)生變化，這怎么趕得上趟呢。公司不是沒有意識到這一問題，但舍不得做傷筋動骨的巨變，只愿意在現(xiàn)有流程上做一些微調(diào)，效果甚微。
有一個例子很能說明問題。當(dāng)時，中國的銷售部門向總部反映，我們在中國市場遭遇到本土廠商的強(qiáng)力阻擊，要想爭奪中國市場，就必須在定制化方面下更大工夫。在大中華區(qū)乃至總部高層的大力支持下，我們部門成立了一個“快速特性”開發(fā)小組，專門根據(jù)中國客戶的需求為我們的產(chǎn)品添加相應(yīng)的特性。有一個快速特性是這樣的：本來，我們的網(wǎng)管系統(tǒng)會在電腦屏幕上顯示一臺虛擬的機(jī)器，如果某個部件壞了，代表該部件的綠燈就會變成紅燈并開始閃爍，提醒操作員注意。中國客戶看過演示后說不錯，但光紅燈閃爍還不夠，還應(yīng)該放點兒警報聲出來，不然操作員離開座位了怎么辦。我們的銷售一口答應(yīng)下來。猜猜這個特性我們做了多久才交付給客戶？三個月！這就是瀑布式流程下的“快速特性”！（當(dāng)然，中國的銷售部門和開發(fā)部門分別向國外的上司匯報，由老外負(fù)責(zé)協(xié)調(diào)中國的事情，這也是造成拖延的一個同等重要的原因。）
這樣拖拖沓沓做出來的產(chǎn)品，其銷路如何不問可知。公司應(yīng)對的辦法，就是一方面推新版本、新特性來吸引客戶，另一方面強(qiáng)調(diào)開發(fā)速度的重要。很顯然，這兩者之間存在矛盾：新特性越多，開發(fā)時間就越長，客戶不會買賬；可是如果新特性太少，跟上一版本差異不大，客戶同樣不會買賬。
作者結(jié)合切身經(jīng)歷，展示了他之前所在團(tuán)隊軟件項目延期的種種原因，而其中印象最深刻的是各種人事紛擾乃至于勾心斗角。
六年前，畢業(yè)未久的我在一家外企工作，我所在團(tuán)隊開發(fā)的軟件項目在交付到集成測試組時因種種原因延期一周。這本身根本不是什么大事情，但其間各種人事紛擾乃至于勾心斗角卻著實令我印象深刻。
公司
我的老東家是一家大型跨國電信設(shè)備開發(fā)商，曾具有輝煌的歷史。我還記得在公司110周歲的生日慶典上，一位高管致辭說：“110年，這不是奇跡，是成績”，令人不勝欷歔。遺憾的是，公司在.com泡沫中遭遇重創(chuàng)，一蹶不振。時任CEO為求擺脫困境，打起了人力成本的主意。當(dāng)時，公司在美國雇用一名工程師的綜合人力成本接近中國的2.5倍【注：工資只是其中一小部分】。至于法國，成本比美國還要略高一些，而且不要忘了，人家可是35小時工作周。大家都是聰明人，很快就看到端詳：公司正在法國裁員，將項目轉(zhuǎn)移到中國。
令人尷尬的是，我所在的中國團(tuán)隊恰好就在與法國團(tuán)隊合作。這一項目最早完全在法國，此后幾年時間，中國團(tuán)隊大規(guī)模擴(kuò)張人手（我就是這樣進(jìn)來的），將項目模塊逐一從法國團(tuán)隊手中接過來。剛開始，法國工程師將原先的模塊移交中國之后，便轉(zhuǎn)而從事其他項目或職位，談不上什么個人損失，雙方共事可謂融洽。后來可就不是這么回事了。有一次，兩位中國工程師去巴黎接手一個項目，一位法國工程師負(fù)責(zé)培訓(xùn)，為時2~3個月。在這位法國老師兢兢業(yè)業(yè)的幫助下，兩位中國工程師成功掌握整個模塊，按期于圣誕節(jié)前夕歸國。告別巴黎時，沒有一個法國同事去跟他們寒暄話別—那位法國老師被裁掉了，他的最后一個工作日恰好就在兩位中國工程師離開的同一天，法國同事都去送他了。
到發(fā)生本文將要詳述的交付延期之時，所有模塊的開發(fā)工作都已從法國團(tuán)隊移交到中國團(tuán)隊，而集成測試雖然仍由法國團(tuán)隊負(fù)責(zé)，但從法國到中國的移交也已開始。不妨猜猜看，法國集成測試團(tuán)隊的工程師們此刻在想些什么。
團(tuán)隊
我很幸運，畢業(yè)后初入職場就遇到一位好經(jīng)理H，坦率地說，她也是我到目前為止跟隨過的幾位經(jīng)理中最好的一位。中國很多女經(jīng)理都有一個共同的特點：沒有私心。她們對于自己的晉升、提薪并無多大熱情，更愿意把心思、時間和精力花在輔導(dǎo)和培養(yǎng)自己的團(tuán)隊上面。
H因分娩而“暫時”離開我們團(tuán)隊。經(jīng)過短暫的過渡，接任我們經(jīng)理的是T，一位新近招聘的職業(yè)經(jīng)理人。他的風(fēng)格與H大為不同。僅舉一例說明。當(dāng)年向H請一天年假，她總是微笑著說：“沒問題。不影響工作吧？”T則會端起架子：“不影響工作吧？沒問題。”語序上的變化，加上語氣的差別，雖然只是細(xì)微末節(jié)，卻反映了態(tài)度的不同、對員工是否尊重。除此之外，更嚴(yán)重的是工作態(tài)度問題。現(xiàn)在我們知道，T在北京待了不到一年時間，買下兩套房、一輛車，還辦妥了到加拿大的移民和那邊的工作—而在當(dāng)時，我們這些員工僅僅只是知道，我們的經(jīng)理不太在辦公室出現(xiàn)。
在團(tuán)隊內(nèi)部，我所在的FM小組與另一個CM小組工作是緊密銜接的。但在CM小組的核心員工之間卻存有罅隙：小組長B與技術(shù)骨干S矛盾日增。怎么說呢，這兩位都是很好的同事，然而好人之間也會彼此鄙視的：S認(rèn)為B不懂技術(shù)，瞎指揮；B認(rèn)為S目空一切，難以共事。缺少一位好領(lǐng)導(dǎo)來調(diào)和，好員工也不能組成一個好團(tuán)隊。
流程
我們開發(fā)的是一個龐大的電信軟件項目—3G接入網(wǎng)網(wǎng)管系統(tǒng)，采用的開發(fā)流程仍然是傳統(tǒng)的瀑布式。簡單來說，依時間順序，一個軟件工程師（首先是各小組的小組長）需要依次參與以下幾個階段。
需求階段：跟蹤和審閱由系統(tǒng)架構(gòu)師撰寫的需求文檔，必要時要求澄清，然后預(yù)估工作量，經(jīng)理據(jù)此調(diào)整人員安排。
設(shè)計階段：分析需求文檔，完成模塊設(shè)計，據(jù)此撰寫高層設(shè)計文檔和底層設(shè)計文檔，前者以定義模塊接口為主，后者則涉及更多細(xì)節(jié)。
編碼階段：根據(jù)兩份設(shè)計文檔完成實際編碼工作。
單元測試階段：是的，你沒有看錯。根據(jù)本部門正式的、成文的流程，單元測試階段在編碼階段之后安排時間進(jìn)行。在實踐中倒是沒有這么僵化，大家盡可以測試先行，只要時間大致齊即可。
各開發(fā)團(tuán)隊在完成各自負(fù)責(zé)的一或多個模塊的單元測試之后，將代碼提交到統(tǒng)一的代碼庫，打上標(biāo)簽，然后將這些標(biāo)簽連同其他注意事項寫成文檔保存到指定目錄。其后，就是集成測試階段了—集成測試團(tuán)隊收集所有團(tuán)隊的所有標(biāo)簽，從代碼庫提出相應(yīng)的代碼進(jìn)行編譯，編譯成功后即按照事先準(zhǔn)備的測試用例進(jìn)行測試，給開發(fā)團(tuán)隊提Bug。
我參與了前面幾個版本3.X、4.0的開發(fā)，僅從技術(shù)角度而言，瀑布式開發(fā)流程工作得尚稱流暢。但工程師是要領(lǐng)工資的，軟件寫出來是要賣錢的，一套經(jīng)典的瀑布式流程走下來往往耗時幾個月甚至年余，等到軟件產(chǎn)品正式發(fā)布，用戶需求已然發(fā)生變化，這怎么趕得上趟呢。公司不是沒有意識到這一問題，但舍不得做傷筋動骨的巨變，只愿意在現(xiàn)有流程上做一些微調(diào)，效果甚微。
有一個例子很能說明問題。當(dāng)時，中國的銷售部門向總部反映，我們在中國市場遭遇到本土廠商的強(qiáng)力阻擊，要想爭奪中國市場，就必須在定制化方面下更大工夫。在大中華區(qū)乃至總部高層的大力支持下，我們部門成立了一個“快速特性”開發(fā)小組，專門根據(jù)中國客戶的需求為我們的產(chǎn)品添加相應(yīng)的特性。有一個快速特性是這樣的：本來，我們的網(wǎng)管系統(tǒng)會在電腦屏幕上顯示一臺虛擬的機(jī)器，如果某個部件壞了，代表該部件的綠燈就會變成紅燈并開始閃爍，提醒操作員注意。中國客戶看過演示后說不錯，但光紅燈閃爍還不夠，還應(yīng)該放點兒警報聲出來，不然操作員離開座位了怎么辦。我們的銷售一口答應(yīng)下來。猜猜這個特性我們做了多久才交付給客戶？三個月！這就是瀑布式流程下的“快速特性”！（當(dāng)然，中國的銷售部門和開發(fā)部門分別向國外的上司匯報，由老外負(fù)責(zé)協(xié)調(diào)中國的事情，這也是造成拖延的一個同等重要的原因。）
這樣拖拖沓沓做出來的產(chǎn)品，其銷路如何不問可知。公司應(yīng)對的辦法，就是一方面推新版本、新特性來吸引客戶，另一方面強(qiáng)調(diào)開發(fā)速度的重要。很顯然，這兩者之間存在矛盾：新特性越多，開發(fā)時間就越長，客戶不會買賬；可是如果新特性太少，跟上一版本差異不大，客戶同樣不會買賬。
之前把軟件工程中的
測試部分，文檔管理部分都已經(jīng)做了一些簡單的介紹，因為都是我實際
工作中經(jīng)常接觸的，所以也算是我的一些經(jīng)驗吧，不過我也不是每個部分都接觸得很深入，總是有些地方講得不太好的，也請大家諒解，希望大家能提出寶貴經(jīng)驗，呵呵。
下面是之前講過部分的鏈接（點擊就可以訪問），如果之前沒看過我的文章的話，有空可以看看。
1、【淺談在軟件開發(fā)中的開發(fā)與測試】
2、【敏捷測試?yán)碚撘约皩嵺`】
3、【談軟件開發(fā)過程管理系統(tǒng)、版本控制系統(tǒng)及它們之間的集成】
4、【文檔管理】
但是軟件工程中除了我已經(jīng)講過的部分，其實還有幾個部分還沒講了，因為我們公司是用 TechExcel 的 DevSuite 系統(tǒng)的，所以還是借用他們的軟件工程過程圖來給大家講一下。
看下圖，之前講了知識管理（文檔管理），測試管理，開發(fā)管理（任務(wù)跟蹤），PPM，這篇文章的話，我會講一下需求管理，至于其它幾個部分，比如項目規(guī)劃管理，我還在考慮之中，因為有些知識在前面幾篇文章里已經(jīng)部分提到了，所以講起來可能就重復(fù)了。Anyway，先不管了，反正我這篇“需求管理”還是會正常寫下去，謝謝大家閱讀！
PPM
PMI對組合管理的定義為“Project Portfolio management refers to the selection and support of projects or program investments. These investments in projects and programs are guided by the organization’s strategic plan and available resources .”，即項目組合管理是指在可利用的資源和企業(yè)戰(zhàn)略計劃的指導(dǎo)下，進(jìn)行多個項目或項目群投資的選擇和支持。項目組合管理是通過項目評價選擇、多項目組合優(yōu)化，確保項目符合企業(yè)的戰(zhàn)略目標(biāo)，從而實現(xiàn)企業(yè)收益最大化。
項目和項目組合管理（PPM）是項目型組織創(chuàng)新的系統(tǒng)化管理理論和實踐，過去項目管理的理論和工具都是基于單個項目管理的，解決的問題是項目如何使干系人滿意，如何按時、在預(yù)算內(nèi)成功交付項目。對于組織級層面如何管理項目，例如如何使項目目標(biāo)與組織的業(yè)務(wù)目標(biāo)一致，如何跨項目優(yōu)化利用組織的資金和資源等，一直沒有很好的理論和方法的支持。組合（Portfolio）管理是金融領(lǐng)域的方法論，在2000年左右被引入到項目管理領(lǐng)域，嘗試解決組織級項目管理問題。
自2002年初開始，PPM方法論首先在產(chǎn)品研發(fā)管理領(lǐng)域取得了重大成功，并逐漸擴(kuò)展到IT治理和專業(yè)服務(wù)領(lǐng)域。這期間，歐美出現(xiàn)了一批非常成功的PPM獨立軟件廠商。從2005年開始，國際上PPM進(jìn)入整合階段，IBM、CA、HP、Microsoft、Oracle、藍(lán)云軟件等國際知名IT企業(yè)陸續(xù)通過收購進(jìn)入PPM領(lǐng)域。PPM是未來項目型組織，尤其是IT組織管理優(yōu)化的方向，這一點已成為業(yè)界共識。著名研究機(jī)構(gòu)Forrester Research指出：“PPM已經(jīng)成為IT企業(yè)的ERP”。
什么是軟件需求呢？為什么它需要管理呢？
軟件需求完全嚴(yán)格來解釋就是：
（1）用戶解決問題或達(dá)到目標(biāo)所需條件或權(quán)能（Capability）。
（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。
（3）一種反映上面（1）或（2）所述條件或權(quán)能的文檔說明
也許看起來有點深奧，其實簡單來說，軟件需求就是一個軟件要實現(xiàn)的功能，當(dāng)然這里所謂的“功能”可能分為兩種情況，一種是有形的，一種是無形的：
● “有形”的應(yīng)該很好理解，你實際可以用到的功能，比如在Word文檔里能把字加粗。
● “無形”的其實也好理解，雖然你平常用不到，但是還是能感受到的，比如說軟件的運行速度，穩(wěn)定性，還有比如這個軟件要達(dá)到什么目的（比如Word的目的是可以讓你處理文字信息）。
當(dāng)然，其實最終所有“無形”的需求還是需要靠一個個的“有形”的需求來實現(xiàn)，只是有些“有形“的需求即使實現(xiàn)了客戶也無法直接看到，只有設(shè)計、開發(fā)與測試才能看到它們。
那為什么要對需求進(jìn)行管理呢？
軟件需求是隨著計算機(jī)的發(fā)展而發(fā)展的，在計算機(jī)發(fā)展早期，軟件規(guī)模很小，所以當(dāng)時大家關(guān)注的是編碼，而對于需求并不怎么關(guān)注，后來隨著“軟件危機(jī)”的出現(xiàn)，誕生了軟件工程，而需求階段就是其第一階段，至此，軟件需求（也稱之為需求分析）階段開始慢慢被關(guān)注。
大家都知道，“軟件危機(jī)”的原因是落后的軟件生產(chǎn)方式無法滿足迅速增長的計算機(jī)軟件需求，軟件系統(tǒng)的規(guī)模越來越大，復(fù)雜程度越來越高，軟件可靠性問題也越來越突出，原來的個人設(shè)計、個人使用的方式不再能滿足要求，迫切需要改變軟件生產(chǎn)方式，提高軟件生產(chǎn)率，軟件危機(jī)開始爆發(fā)。
而軟件需求分析階段作為軟件工程的第一階段，需要為一個軟件的開發(fā)搭好最初的框架并且還要考慮好后面可能的修改，所以對于軟件可靠性、易用性、可擴(kuò)展性和可維護(hù)性來說，需求分析階段是及其重要的，直接關(guān)系到一個軟件是否能夠成功。
如果一個產(chǎn)品在需求分析階段沒有被設(shè)計好的話，在以后的各個階段，開發(fā)與維護(hù)的成本就會非常高，導(dǎo)致最后失敗的可能性就會非常大，著名的例子比如微軟的Vista，設(shè)計初期沒有考慮好兼容性與硬件，導(dǎo)致發(fā)布以后發(fā)現(xiàn)與其他軟件的兼容性很差，而且硬件要求又很高，很多客戶不買他們的賬，所以最后匆匆收場，趕緊推出Windows 7來，要知道Vista的開發(fā)成本估計要接近百億美金了，都還沒怎么賺錢就趕緊推出另外一個產(chǎn)品，足見其失敗了。
所以軟件需求分析階段對于軟件工程而言，已經(jīng)成為至關(guān)重要的階段，其實按照我的理解，它已經(jīng)成為軟件工程最重要的階段，記住，不是之一。（當(dāng)然，我這里說的需求分析階段是包含軟件的設(shè)計階段的）
一個軟件的成功與否，在需求分析與設(shè)計階段已經(jīng)可以基本上預(yù)見了，因為需求分析與設(shè)計階段從概念上其實已經(jīng)把這個產(chǎn)品做出來了，而之后的編碼階段只是去實現(xiàn)它，讓產(chǎn)品能真正可以去用。那這個“實現(xiàn)”階段其實相對來說就不會那么重要了，所以現(xiàn)在很多跨國公司只在總部保留設(shè)計部門，研發(fā)部門都外包出去，就是這個原因。 “蘋果”就是這樣一個公司，把需求分析與設(shè)計工作做好，讓臺灣人去把產(chǎn)品做出來，最后得到一個完美的產(chǎn)品。
既然軟件需求階段已經(jīng)變成如此重要，那對它的管理也就相應(yīng)的變得特別重要了，只有把需求設(shè)計做好了，產(chǎn)品才有可能成功，所以我們就需要對這個階段進(jìn)行有效的管理，而且是非常有效的管理！
剛才腦子里一閃而過的幾句話。想跟大家說說。
1、測試人的工資。
為什么我先談工資，看了幾天，此版塊工資的帖子是最火的，回的人多，看的人多。超過了某些測試人嘔心瀝血寫的技術(shù)文檔。
即可以這么說，有很多人在看前景的時候死死的盯著工資不放。還有些沒有進(jìn)入此行業(yè)的人也在先問工資再決定進(jìn)不進(jìn)這個行業(yè)。
這種的思想，當(dāng)然不可厚非的，生存嘛，誰不要吃飯呢，誰不想多拿點錢，找個好老婆，有個好孩子，幸福的生活呢。可是做測試，我認(rèn)為，這樣的技術(shù)工作，應(yīng)該首先關(guān)注的是技術(shù)，這才是根本。我要說，我們是高尚的測試人，是為了祖國的IT事業(yè)添磚加瓦，為IT行業(yè)的成熟做出貢獻(xiàn)，不惜一切的犧牲，這也是扯談。
可是談工資，談多久也沒人給你長的，只有從技術(shù)出發(fā)才能長，牛人工資就是高（不排除懷才不遇的現(xiàn)象）。有些人在痛恨工資不高的時候也沒有想著拿這些痛恨領(lǐng)導(dǎo)的時間來多學(xué)點東西。這就有點不可原諒了。
先看看自己的實力，再看看現(xiàn)在的市場，再來評估自己能拿多少工資，這才是正確的做法。
技術(shù)高了，做測試的你，抬起頭來，面試的時候說出自己的強(qiáng)項。總有伯樂在前面等著你。
抬起頭來第一式：練好技術(shù)，再想工資。
2、學(xué)習(xí)方法。
很多人在問學(xué)習(xí)測試從哪里開始。這個問題簡單到?jīng)]人回答上來的地步。首先要明確幾個問題。
你是不是愿意在這條路上走下去？
你有沒有自己喜歡的方向？
你有沒有了解現(xiàn)在的測試行業(yè)？
好了，下面開始談學(xué)習(xí)測試方法。測試也有很多方向的，會越來越細(xì)分。所以要給自己選擇一個方向。這個方向可以向前輩們請教一下，然后自己來選擇，沒有人能給你做得了抉斷。估計也沒有人能說出來現(xiàn)在哪個方向最后是能賺大錢的。
選擇好了，開始學(xué)習(xí)。細(xì)節(jié)的東西就不用說了，枯燥乏味一定是有的。要學(xué)會學(xué)習(xí)，不能什么就張嘴就問。
有些東西，手冊里查找就能找到的，就沒必要再問了。有些人是那種，說一句做一步的人。不會主動。那就肯定進(jìn)步不大了。
沒有人能一步步的從網(wǎng)絡(luò)上教你，當(dāng)然有某些特殊關(guān)系的除外。
當(dāng)身邊沒有人可以共同學(xué)習(xí)和討論的時候，就到網(wǎng)上轉(zhuǎn)轉(zhuǎn)。
給自己定一個計劃，至少讓自己過去的一周里，把計劃里的東西盡力做完。沒有書面的也沒關(guān)系。心里記著就行了。
有個人問我怎么學(xué)習(xí)LR，從哪看起，我說先安裝，裝完了看手冊一步步操作，不懂沒關(guān)系，做下去，以后再回來看，就明白多了。
還有，千萬別看了一段手冊就認(rèn)為自己學(xué)的很多了，結(jié)果放在那里放了幾個月，再回頭看的時候就全忘光了。
這有什么用，不如不學(xué)呢。半途而廢要是再想開始，比從頭開始要難。這是我的看法。
關(guān)注細(xì)節(jié)，在技術(shù)上就是這樣。工作中有一點沒有想到可能就會出差錯，所以學(xué)習(xí)的時候一定要踏實一點。把細(xì)節(jié)給做好，看論壇有些人就做的不好，問個問題，回一個提示，立馬就會了。這就是沒有更多的想下去，哪怕一小步。坐下來，冷靜的看幾個小時的資料，每天堅持，不出一個月，就會覺得不再是那么一無所知了。
所以，做測試的人，學(xué)習(xí)要踏實，別浮。浮在半空中，遲早是要破的。
抬起頭來第二式：抓住細(xì)節(jié)，冷靜學(xué)習(xí)。
3、測試規(guī)范。
很多人都看到當(dāng)前的測試市場有點混亂。畢竟發(fā)展的時間不是很長，現(xiàn)在的狀況是可以理解的。
那靠什么來提高規(guī)范？就是做測試的人了。慢慢的積累，一點點完善。法律不還是一點點寫出來的？現(xiàn)在不是還在完善著嗎？
規(guī)范是要有的，不然會一直亂下去。有些公司，可以說沒有什么測試計劃，經(jīng)理說，你把這個測一下，然后測試人員就做，明天說，你把那個測一下，然后還是做。可是為什么這么做？也沒有書面的文檔。也沒有時間表。這樣的現(xiàn)象就很差了。現(xiàn)在很多公司在慢慢的重視這一點。
而干活的人要怎么來要求自己呢。我們要一點點的培養(yǎng)自己的完善的測試?yán)砟睢哪睦镩_始。為什么這么做，下一步做什么，等等。
有人會說，時間緊，根本沒時間做什么規(guī)范的流程。那就要測試人慢慢的來完善這個市場了，在個人重視規(guī)范的過程中，市場的規(guī)范也會慢慢清晰起來。
抬起頭來第三式：嚴(yán)于律已，提高規(guī)范。
希望測試前景越來越好的同時，你拿的工資也越來越高。
查看Linux服務(wù)器下的內(nèi)存使用情況 ，可以使用命令free -m。注意此命令只在Linux下有效，在FreeBSD中沒有此命令。命令如下所示：
used：已經(jīng)使用的內(nèi)存數(shù)
free：空閑的內(nèi)存數(shù)
shared：多個進(jìn)程共享的內(nèi)存總額
-buffers/cache：（已用）的內(nèi)存數(shù)，即used-buffers-cached
+buffers/cache：（可用）的內(nèi)存數(shù)，即free+buffers+cached
得出結(jié)論：
可用內(nèi)存的計算公式為：
可用內(nèi)存=free+buffers+cached，即2551MB+268MB+917MB=3737MB
很久以前在筆記本上用Ubuntu8.04時就覺得Linux管理內(nèi)存的機(jī)制非常優(yōu)秀，簡而言之：Linux的內(nèi)存是拿來用的，而不是拿來看的。我與一個朋友探討Linux的使用情況時，他問我為什么Linux使用的內(nèi)存這么高。他機(jī)器上1GB的內(nèi)存free才232MB，而Windows XP才用了200MB不到的樣子。這其實是被Linux的free命令之表象迷惑了，Linux的內(nèi)存使用是很有講究的。還是舉例說明，如下的free命令所顯示的是當(dāng)前內(nèi)存的使用情況，-m的意思是用M個字節(jié)來顯示內(nèi)容，我們來一起看看。
在第一部分Mem行中有如下參數(shù)。
total：內(nèi)存總數(shù)，即1002MB
used：已經(jīng)使用的內(nèi)存數(shù)，即769MB
free：空閑的內(nèi)存數(shù)，即232MB
shared：當(dāng)前已經(jīng)廢棄不用，總是0
buffers Buffer：緩存內(nèi)存數(shù)，即62MB
cached Page：緩存內(nèi)存數(shù)，即421MB
其中，內(nèi)存總數(shù)與已使用內(nèi)存數(shù)和空閑內(nèi)存數(shù)的關(guān)系是：
total(1002M)=used(769M)+free(232M)
在第二部分內(nèi)容(-/+buffers/cache)中各參數(shù)如下所示。
(-buffers/cache)：used內(nèi)存數(shù)，即286MB(指的是第一部分Mem行中的used-buffers-cached)。
(+buffers/cache)：free內(nèi)存數(shù)，即715MB(指的是第一部分Mem行中的free+buffers+cached)。
可見-buffers/cache反映的是被程序?qū)崒嵲谠谟玫舻膬?nèi)存，而+buffers/cache反映的是可以挪用的內(nèi)存總數(shù)。
第三部分是指交換（swap）分區(qū)，大家應(yīng)該都明白，這里就不再講了。
有可能大家看了上面的解釋還是不太明白。比如：第一部分(Mem)與第二部分(-/+buffers/cache)的結(jié)果有關(guān)，used和free為什么這么奇怪？其實我們可以從兩個方面來分析。對操作系統(tǒng)來講這兩項是Mem的參數(shù)，buffers/cached都屬于被使用，所以它認(rèn)為free只有232MB；對應(yīng)用程序來講+buffers/cached等同于可用的內(nèi)存，因為buffer/cached可提高程序執(zhí)行的性能，當(dāng)程序使用內(nèi)存時，buffer/cached很快就會被使用。所以從應(yīng)用的角度來看，應(yīng)以(-/+buffers/cache)的free和used為主，即我們主要看與它相關(guān)的free和used就可以了。另外告訴大家一些常識，為了提高磁盤和內(nèi)存的存取效率，對Linux做了很多精心的設(shè)計，除了對dentry進(jìn)行緩存(用于VFS、加速文件路徑名到inode的轉(zhuǎn)換)外，還采取了兩種主要Cache方式：Buffer Cache和Page Cache。前者用于針對磁盤塊的讀寫，后者用于針對文件inode的讀寫。這些Cache能有效地縮短I/O系統(tǒng)調(diào)用(比如read、write、getdents)的時間。
在Linux中，內(nèi)存是拿來用的，不是拿來看的。而在Windows中，無論你的真實物理內(nèi)存有多少，它都會用硬盤交換文件來讀，即使是內(nèi)存還有一大部分。這也就是Windows常常提示虛擬空間不足的原因。可以想見，硬盤怎么會快過內(nèi)存，所以我們在觀察Linux的內(nèi)存使用情況時，只要沒發(fā)現(xiàn)用swap的交換空間，就不用擔(dān)心自己的內(nèi)存太少。如果常常看到swap用了很多，那么你就要考慮加物理內(nèi)存了。這也是在Linux服務(wù)器上看內(nèi)存是否夠用的標(biāo)準(zhǔn)。