我們不得不佩服馮諾依曼和早期的計算機科學家們，不只是因為計算機這個偉大產物的誕生和發展，更主要的是，這個行業中的任何分支都似乎有無盡的可能性，讓一些大牛們終其一生去探究。當然，最讓我佩服的是，無論表現上多么的豐富，無論這一行業如何的變化和發展，它的原始方式卻依舊沒有變化，早已經被早期的計算機科學所限定（事實上不是限定，而是被證明最為有效）。這就像大多數程序員都知道的一個道理，技術的發展速度越快，對那些最基本原理的理解就越為重要。事實上不僅在技術上，即便是計算機和軟件行業的管理上，依然遵循著這些計算機的科學的基本原理。這行業本身就是實業，當然也是服務行業，沒有行業背景，不尊重行業規則的管理，從嚴格的行業市場來說，是失敗的——這里自然不包括我國國企和政府部門這種有足夠預算保障的項目，當然也不包括如某些外包行業中的中國人擅長的“人”的管理。這里只是簡單的從操作系統角度上討論一下測試項目中和自動化測試中一些可以借鑒的地方。

?

　　最早的測試其實和最早的編程是一樣的——不僅在出現的時間上，在力度和思維方式上也是一樣的，因為它們本來就是一個整體。計算機發展的早期，最珍貴的是資源，并不像現在大部分的軟件開發一樣在堆積木。發明計算機的那段時期，幾乎就是不斷測試不斷調整的過程，和計算機科學的發展是一樣的。事實上一個像模像樣的操作系統基礎代碼幾千行而已。甚至早期程序員在寫代碼前必須考慮的清清楚楚，簡簡單單的代碼所帶來任何效果和影響，都要理解透徹，著手寫代碼的時候，事實上測試的思路就已經同時指定出來（最早的測試驅動開發？呵呵）。當然那時候不該叫做開發，只能叫做編程，因為還沒有達到可以工廠化生產的程度。當軟件達到了可以工業化生產的程度，代碼和工程的量級爆炸般的增長，質量參差不齊的從業人員不斷增加，才不斷的靠經驗的積累，形成了所謂的項目管理。實際的工作中，這樣的管理包括項目和人。當然，IT行業是服務行業（至少我一直這么認為），測試更是服務中的服務，也就是說，測試的根本，還是在于對項目和人的管理和提供的服務。自動化是手段，并不是目的，不管自動化的地位多高，它的根本目的沒有改變，測試是它的載體。就繞到一開始提到的，測試和開發在計算機發展的一開始，就是一個整體，現在來講，也依然說的通，只是無論了開發還是測試，都因為工廠化的發展規模龐大，所以很多時候需要各自的管理或者“小組作戰”。微軟的測試投入力度很大，很多大公司的測試投入也很大，無論技術還是人員，但是有一些公司如facebook沒有所謂的測試人員，只能說，概念上的質量保證以不同的方式和邏輯分布到了不同的地方，和項目管理一樣，無論有再多抽象的模型和流程，事實上最適合自己的測試管理，只有看自己的項目才能決定。

?

　　自動化的提出，也沒有明確的時間界線，事實上就跟“云”這個概念是一樣的，幾十年前就有這樣的思想，只是硬件的發展成就了當代的云發展。每次硬件的發展都會帶來軟件的革命，窗口，鼠標，網絡，移動，觸屏，體感，這些不只促生了軟件技術和管理發展，測試管理和自動化也同樣與時俱進。剛入行的時候，總是認為向往一些很牛的東西，當時感覺ole和com這些就已經是最早的自動化，隨著不斷的沉淀，才了解到這些也都是發展的產物。如果讓我現在說自動化的開始是什么時候，我的回答就是剛發明計算機的時候。當然也許幾年后我的答案也跟著發展，但是現在是這個。剛開始有計算機的時候，必須手工的將紙帶裝入，之后機器才能進行運行，但是處理器太珍貴了，不能讓處理器等待手工的裝入；另外，隨著硬件的發展，機器運行效率提高，手工的裝入耗時卻沒有改變，也就意味著手工操作占的時間比率越來越高，機器等待的相對時間越來越多——所以才有了分工，才有了程序來管理“裝入”，才有了程序管理任務作業，這些構成的整體，其實就是操作系統。所以自動化，也就是自動代替手工的過程，本身就是操作系統的一個目的，也就是為什么我認為自動化是在計算機發明的時候就已經產生了。

?

　　測試的目的呢？它到底是一個什么樣到角色呢？如果產品和項目的質量有標準，那就是質量保證和評估（需求），如果質量沒有標準，那就是產品和項目發展的一種手段和必需到途徑。軟件所存在的問題，無論從設計上還是從開發上，大都來自三個地方，個人問題（個人開發和設計問題），人和人之間的問題（溝通和合作），環境問題（軟件和所處環境）。我一開始提到的早期的程序員（很優秀）和他們到思維方式，能解決這三個問題中第一個和第三個的大部分問題，第二個人和人的問題也能解決一部分——如果這樣到話，那么是不是大多數的軟件問題都可以通過優秀程序員的工作解決呢？這是不現實的，因為工廠式生產中，有更多大前提，時間，預算，各種約束等，我們真正需要的，是在預算和時間到允許下，將產品交付和完成，測試和質量保證自然也要達標，而且產品的開發和測試并不是脫節的，相互約束并可以相互促進，因為本來就沒有嚴格到界限，分開只是某些時候更適合某種管理方式。所以這時候再說測試管理和自動化測試，思路相對就清晰了：給定的時間和財力預算的情況下，給項目最大程度的質量方面到支持，并盡可能驗證和改進項目開發方式和以及流程——看起來好像把什么都占了，其實確實是這樣，只是從質量和保證的角度而已。所以整體上來說，測試的價值并不在于創造，而是保證，優化和更新。至于自動化呢，當然它只是測試的一個子集（盡管如測試驅動開發和自動化架構方面會不同程度的深入到產品和項目中），自動化不是測試的目的，是測試的一種手段和途徑。如果自動化沒有在縮減預算（或者折中）的前提下提高軟件的質量，那么自動化就毫無意義，這樣的折中在不同項目中權值不高，力度當然也不盡相同，一些武器系統或者航天系統中，不允許任何一點失誤的出現，這種時候小于一定研發資金份額的測試投入都是允許的，因為一次失敗就意味著整個投入打了水漂；典型的大型超市中UNIX+oracle的系統，必須有容錯的處理，不能因為小的插曲影響整體的運作，這也就意味著允許出現預期內的錯誤，那么投入在這部分中的預算的必要性，就沒那么強了。這兩種極端的方式，當然采用自動化去測試更為方便和合理，自動化適用的范圍有多大？什么時候適用呢？

?

　　一般來說不同的公司情況不同，對測試和自動化的理解也都不相同，通常來說，自動化用在：1.反復操作的相對穩定的系統或軟件中（迭代、回歸等）；2.手工難以模擬的運行環境（壓力、負載等）；3.一些對高精度的測試結果或者手工難以獲取的數據的測試（性能、評測等）。當然這里并不包括一些輔助工具和一些環境部署方面的自動化，因為它們并非針對產品質量的，但是卻同樣屬于自動化的一部分。

?

　　事實上，測試的范疇是完全由產品決定的，自動化也是在其中盡其所用。不同的產品和項目測試的范圍大都不同，但是大概的思路都差不多——由大而小。這和自動化不同，自動化必須找到突破點走通一條路才能實施。拋開流程不說，范圍一般這樣去界定：先將產品去進行定位，然后按不同的類別去劃分，之后每一個劃分都添加對各自的測試約束，比如我現在要制作一款主題瀏覽器，暫時只有windows版本，支持xp和其之后的所有系統。首先說它是一個windows上的軟件，那么就要有安裝卸載和升級，性能方面要有各項性能指標的測試（GDI,CPU內存占用，句柄等）和壓力測試，內存泄露；作為瀏覽器，它要實現的自己的功能，這些功能太多需要細化這里不討論；當然瀏覽器是JS的宿主環境，對JS的支持也要去測試（流行的HTML5也越來越多的被測試）；用戶會使用瀏覽器進行各種登陸，所以安全性很重要，安全測試上除了用戶的個人信息外，一些敏感數據也是重點；有了用戶的數據，就需要測試容錯和健壯性，崩潰后對用戶的數據恢復等；由于支持多個windows平臺，所以平臺兼容性也是重點；現在的瀏覽器與一些硬件關系密切，需要測試對硬件的兼容和支持，比如GPU加速，無線網卡，攝像頭等（可能會涉及到不同品牌設備）；由于瀏覽器涉及到安全性，所以需要測試對現有的安全產品的兼容性，比如某山，某斯基，某星，太多某；另外，瀏覽器產品太多，必須對其進行同類產品的兼容性檢測——至少IE系列和其他主流瀏覽器都要測試；如果瀏覽器打算提供部分接口供外部網站開發人員進行網站測試，這部分接口開放之前也要進行測試（ms的com，chrome的driver等）；當然還有對操作系統的影響，windows系統很多時候會被一些軟件干的千瘡百孔，即使我們的軟件不做同樣的行為，至少需要自行的檢測或者修復；其他灰色地帶測試等等。所有的這些都是這款軟件需要做的測試。這時候的自動化呢，也要進行分而治之，因為并不會有一個大的統一測試架構，每一個范疇都可能要進行小范圍的突擊。

?

　　怎么去執行測試管理和自動化測試，同樣也可以從操作系統方面得到一起啟發。同樣，早期的計算機在使用時，需要使用者將自己的紙帶裝入，越來越多的人開始使用計算機，使得紙帶裝入和熟悉計算機的花銷加大，結果就是在硬件沒有提升的前提下，產生了分工——專門有人負責紙帶的裝入，使用者只需要將紙帶交到他手里就可以了，繼而有了所謂的流程——不同分工并且有交互，各自負責相關的部分，這時候負責紙帶裝入的人，發現了把所有的紙帶做成紙帶卷，可以減少裝入的次數提交自己的工作效率，負責寫程序的，專注于寫出更好的程序來，簡單的團隊協同工作開始形成。

?

　　軟件測試管理，很大程度上，是處理好團隊協作的事情。將測試目標分而治之，流程化到每一個小組，團隊間協同工作，不同的人撲在精通的位置上，組內相互可以做到部分backup，這樣就是一個較為理想的團隊。每個人都是一個線程，每個小組就是一個任務，避免異步產生的鎖定，提高資源共享的高效性，才能盡可能發揮團隊的戰斗力。

?

　　團隊合作中，溝通很重要。一個小小的改變，可能會影響到組內的每一個人。無論一個技術水平很高的高級SDET，還是指執行手工用例的tester，都避免不了對組織的依賴。那么一個團隊如何去做決策？反過來，依賴于每一個人。個人的想法直接快速，但是片面容易引發問題；開會投票表決會浪費很多時間，效果也不明顯。這時候，除了leader外，團隊也需要一個具有測試“架構”決策能力的骨干，做到折中和適當的舍去。有時候我們需要讓組內每個人都嘗試決策組內的一些事情，慢慢提高大家的整體能力，這和學習技術是一樣的。當然免不了一些領導不愿意看到手下人的決策能力變強，一些人也不愿意跟自己同一組的人的能力超過自己，創造合理競爭的氣氛和“每個人都是經理”的制度可以在某些程度上緩解這種情況，當然，組員們不能只對工作進行抱怨，當抱怨的同時盡可能拿出自己的建議和可行性的計劃，工作上的事情公開，將負面影響降到最低。

?

　　一些項目的規模，可能達到千人年的龐大，但是每個組的規模卻不宜過大，5個人左右為最佳，避免預定會議的麻煩，盡可能減小每個人風格不同帶來的影響，而且4、5個人的工作環境，是最佳的——大部分軟件工作者在4個人的時候，會最自然的專注到自己的工作上，交談的情況最少（很奇怪，但是研究是這樣的），氣氛也相對輕松。

?

總結

以上是生活随笔為你收集整理的操作系统角度谈测试管理和自动化测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。