從測試的角度來重新反思我們自己的程序以及我們的程序員之路——“通過追本溯源來進行前瞻性思考”
最近比較忙,而且情緒上有些浮動,但控制的非常好。這幾天協會搞一個編程比賽,部分的題目是我出的,所以最后大家決定讓我做測試人員,對協會的比賽進行評測。我雖然已不擔任協會職務,卻毅然接受了。
首先,我了解了測試相關的概念,閱讀了《軟件測試》、《軟件測試的藝術》、《微軟的軟件測試之道》、《軟件測試經驗與教訓》等,并結合自身的測試經歷來做一些記錄,希望拋磚引玉。
雖然協會測試用不上這些,既然讓我做了,我就應當力求公正公平,準確有效。在做好這個工作的余下時間里,作了一些淺薄的思考,現在拿出來跟大家一起分享。
微軟雖然有很多不足,制作的程序漏洞不少,但不可否認,在其快速開發的進程中,將測試放在比較重要的位置,也是其獲得較多正面評價的原因之一:
微軟的組織結構:
微軟的“大公司小團隊”戰略,小團隊布局:
以下是讀書心得,摘抄:
軟件測試或系統測試大約占用50%的項目時間和超過50%的總成本。
測試是為發現錯誤而執行程序的過程。(人類的行為總是傾向于具有高度的目標性,確立一個正確的目標有利于實現這一目標,這里我們確立我們的目的是發現錯誤)
軟件測試的大多數問題都是心理學問題。
程序員應當避免測試自己的程序。
一個測試用例必須包括兩個部分:1、對程序的輸入數據的描述2、對程序在上述輸入數據下的正確輸出結果的精確描述。
黑盒測試主要將重點集中放在發現程序不按其規范正確運行的環境和條件。
白盒測試主要是對程序的邏輯結構進行檢查,從中獲取測試數據。
檢查程序是否“未做其應該做的”僅僅是測試的一半,測試的另一半是檢查程序是否“做了其不應該做的”。
程序某部分存在更多錯誤的可能性,與該部分已發現錯誤的數量成正比。
至少編寫足夠的測試用例,使得每一種可能均被測試,每個入口點都至少被調用一次。
經驗證明,考慮了邊界條件的測試用例與其他沒有考慮邊界條件的測試用例相比,具有更高的測試回報率。所謂邊界條件,是指輸入和輸出等價類中那些恰好處于邊界、或超過邊界或在邊界以下的狀態。
錯誤猜測,是一種通過舉出測試用例,找出程序漏洞的方法。
模塊(單元)測試:是對程序中的單個子程序、子程序或過程進行測試的過程。
系統測試:將系統或程序與其初始目標進行比較,包含兩方面的含義1、系統測試并不局限于系統,如果產品是一個程序,那么系統測試就是一個視圖說明程序作為一個整體是如何不滿足其目標的額過程。2、根據定義,如果產品沒有一組書面的、可度量的目標,系統測試也就無法進行。
容量測試:使程序經受大容量數據的檢驗,其目的是為了證明程序不能處理目標文檔中規定的數據容量。
強度測試:使程序承受高負載或強度的檢驗,所謂高強度是指在很短的時間間隔內達到的數據或操作的數量峰值。
易用測試:發現人為因素或易用性問題。(用戶智力、背景、輸入輸出是否簡介有效、錯誤診斷是否直接、語法風格問題、信息是否冗余不利于安全、確認信息是否需要)
安全性測試:是否達到安全目標。
可恢復性測試:故意將程序錯誤的置入某個系統中,判斷系統是否可以從中恢復。
測試結束準則:1、用完了安排的測試時間后,測試便結束2、當執行完所有的測試用例都沒有發現錯誤,測試便結束。
調試:是執行一次成功的測試之后要進行的工作。
所有的測試都是基于模型。
不要將實驗與測試混淆起來。
威脅建模:威脅模型就象功能計劃或設計文檔一樣,是一種規格說明。而最大的不同在于威脅模型的意圖是找出一個應用程序能被攻擊的所有可能的方法,然后根據概率和可能的危害來排優先級。好的威脅建模需要分析和調研技能—這兩種技能使得測試在這過程中很適用。
測試用例的設計:
在實際測試過程中的心得:
1、許多同學對于題目沒有讀的很嚴謹,在輸出上沒有嚴格按照規范,輸出錯誤是嚴格判錯的。
2、有一個非常重要的問題是,對于邊界條件沒有把握好,我設計的每一種情況的邊界情況考察2次,較多同學沒有做好這一項,可能是時間比較緊,另外就是沒有養成良好的測試和思考習慣,有的溢出、有的呈現出錯誤的結果等等。
3、對于程序輸入值,有同學沒有考慮輸入完全錯誤和輸入越界的情況。
4、還有同學圖省事,簡單的使用某些看似等價的語句,一測試,立刻原形畢露。
測試完畢后的對自己程序設計的反思:
1、要嚴格考察輸出是否滿足程序功能需求。
2、對于邊界條件一定要小心,要經過嚴密的思考,在編程中也要注意思考的邏輯與程序邏輯的等價性。
3、對于程序的輸入,嚴防各種類型的輸入。
4、每一個語句的有效性非常重要,它們的流程在某些情況下是正常的,在另一種情況下可能出現錯誤,不能簡單的等效之(有不同的觸發因素:環境變量、特殊的值)。
5、軟件測試是非常重要的一個環節,測試別人的程序,能夠提高自己的編程意識。軟件測試是非常嚴謹的,不容出錯的。
程序員有時候犯的最大錯誤,不是說寫錯了某個程序,而是當程序出錯后,簡單的調試成功,或者在外力下被迫調試成功,就再沒有對出錯的原因進行深入的分析,這樣做沒有從思想和方法上防止類似的情況發生。如果我們換一個思考的角度,通過不斷調試自己或別人的程序,從反面來思考,是否對我們的編程具有一定的“前瞻性思考”呢?
原文轉自:http://www.anti-gravitydesign.com