龐大到不可思議的壓力測試系統。
在實驗室中，我見到了我所見過的最大的壓力測試系統。這個系統整整擺滿了三排鐵架子，幾乎占了整個實驗室的四分之一的位置。架子上除了幾臺用于日志數據分析的服務器以外，剩下的全都是各種各樣的手機或者嵌入式系統。架子上沒有測試驅動服務器，因為測試驅動服務是通過網絡由中心測試驅動服務器提供的，這種服務是所有測試系統共享的。這些設備自動化的從中心測試驅動服務器得到壓力測試用例集，并自動運行13小時左右的壓力測試，與此同步的是產生的日志數據將通過中心測試驅動服務器傳輸給日志分析服務器用于錯誤分析。當測試結束或者有不可恢復的程序錯誤或者系統錯誤出現時，測試設備將停止測試，并由中心測試驅動服務器撲捉這種事件，在經過適當的記錄和處理后測試設備將被重置，并且準備進行下一次壓力測試。這樣龐大的壓力測試系統令我產生了疑問——為什么我們需要如此大力度的壓力測試？花費如此多的人力物力是否值得？
我從美國同事那里得到的答案是這樣的。其實開始的時候并沒有這樣龐大的壓力測試系統。和許多其他項目的壓力測試類似，針對射頻驅動程序的壓力測試也只是在一兩種嵌入式系統上進行，而且根本沒有手機參與其中。但是，從后來的用戶反饋中發現，在很多手機和嵌入式系統上都存在著長時間反復使用電話功能后電話短信功能失靈的現象，而在已有的壓力測試過程中并沒有發現類似的問題。來自OEM的壓力越來越大，OEM的反饋表明這個問題增加了他們通過入網測試時的難度，使得研發成本增加了很多，與此同時，客戶服務部門也在抱怨此類問題加重了他們的日常工作。問題已經變得很嚴重了，于是這個測試小組做了一個決定，擴大壓力測試的范圍、頻度和力度。從此，很多手機和嵌入式系統就逐步的加入了這個壓力測試系統。另外，原先的系統中是沒有日志數據分析服務器的，但是隨著測試設備的日益增多，在海量的日志數據中捕捉出錯信息的工作也變得越來越繁重，測試小組無法再提供更多的人力用于分析這些日志數據。于是又有人提議架設一臺能夠用于分析日志數據的服務器，程序由測試開發工程師設計和編寫，并負責日常維護。后來，隨著測試設備的繼續增加，一臺服務器不能滿足其要求了，于是又增加了幾臺，直到今天的規模。在這個系統投入軟件測試后的一段時間內，很多非常難于發現的bug浮出了水面，在修正了這些bug后先前提到的問題就基本絕跡了。
很明顯，建立如此龐大的壓力測試系統的真正原因是OEM和客戶服務部門由于驅動程序穩定性差而產生的巨大費用造成的。從軟件測試原理本身或者測試小組對于產品質量的理解出發并不能支持建立這樣大的壓力測試系統，所以說這個測試系統是商業利益驅動的。
非常簡單的性能測試。
在實驗室中另一個讓我感到驚奇的是實驗室中沒有用于測試射頻驅動程序性能的任何設備，而就在這個實驗室的另外兩個架子上卻擺滿了用于測試另一個模塊的性能測試系統。這在驅動程序的測試實踐中實在是不多見的。很難想象，一個驅動程序沒有自動化的性能測試系統對其進行軟件測試。
對于這個問題，美國同事的解釋是：的確沒有自動化的性能測試系統，但是性能測試在每個milestone結束時會由測試小組中的一名測試開發工程師手動完成。如此處理的主要原因是，從以往的測試數據看來，驅動程序不是其所在的功能調用棧中的性能瓶頸，并且射頻驅動程序的性能明顯比瓶頸的性能高很多。所以在沒有很大的結構變動的情況下，性能通常不會成為嚴重影響程序質量的因素，所以性能測試就如此簡單了。當然，如果射頻驅動程序是整個功能調用棧的性能瓶頸的話，結果就會大不相同了。
很明顯，簡化性能測試的真正原因是對非瓶頸模塊的性能測試和優化不會對功能調用棧整體的性能產生貢獻，當然這樣的投入也幾乎不會有大的商業價值的產出，所以，簡化性能測試并維持一個最基本的性能測試便是最佳的選擇。
其實，從更高的角度觀察，整個軟件產業都是商業性的，所以作為其重要組成部分的軟件測試也必然帶有商業性，但這恰恰是不容易發現的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
