軟體測試評估是指對未正式投入商業化使用的軟體進行預先的小規模試驗，又稱小試。主要是由代碼審查和合理性分析組成。
基本介紹
- 中文名：軟體測試評估
- 外文名：Software Test
- 用途：對為商業化的軟體作評估
- 對象：未正式商業化的軟體
內容簡介,軟體測試方法,黑盒測試,白盒測試,基於風險測試,基於模型測試,相關信息,
內容簡介
每個人都承認代碼審查的花銷大，而且又耗時，特別是當大家忙完成軟體項目又把它送去軟體測試部門時。對一些開發人員來說，它更是會引發更多的辦公室政治和流言蜚語。
軟體測試評估
軟體測試評估一次代碼審查可能會使代碼逐漸得到改進。如果你認為你從有效的代碼審查中只是稍微改進了一下軟體，那你需要再想一想。以下五點易忽視的原因會給你些許啟發。
軟體測試方法
黑盒測試
黑盒測試顧名思義就是將被測系統看成一個黑盒，從外界取得輸入，然後再輸出。整個測試基於需求文檔，看是否能滿足需求文檔中的所有要求。黑盒測試要求測試者在測試時不能使用與被測系統內部結構相關的知識或經驗，它適用於對系統的功能進行測試。
黑盒測試的優點有：
1）比較簡單，不需要了解程式內部的代碼及實現；
2）與軟體的內部實現無關；
3）從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
4）基於軟體開發文檔，所以也能知道軟體實現了文檔中的哪些功能；
5）在做軟體自動化測試時較為方便。
黑盒測試的缺點有：
1）不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；
2）自動化測試的復用性較低。
白盒測試
hresult play( char* pszfilename )
{
if ( null == pszfilename )
return;
if ( state_opened == currentstate )
{
playthefile();
}
return;}
讀了代碼之後可以知道，先要檢查一個字元串是否為空，然後再根據播放器當前的狀態來執行相應的動作。可以這樣設計一些測試用例：比如字元串（檔案）為空的話會出現什麼情況；如果此時播放器的狀態是檔案剛打開，會是什麼情況；如果檔案已經在播放，再調用這個函式會是什麼情況。也就是說，根據播放器內部狀態的不同，可以設計很多不同的測試用例。這些是在純粹做黑盒測試時不一定能做到的事情。
白盒測試的缺點有：
1）程式運行會有很多不同的路徑，不可能測試所有的運行路徑；
2）測試基於代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可 能會漏掉一些功能需求；
3）系統龐大時，測試開銷會非常大。
基於風險測試
基於風險的測試是指評估測試的優先權，先做高優先權的測試，如果時間或精力不夠，低優先權的測試可以暫時先不做。有如下一個圖，橫軸代表影響，豎軸代表機率，根據一個軟體的特點來確定：如果一個功能出了問題，它對整個產品的影響有多大，這個功能出問題的機率有多大？如果出問題的機率很大，出了問題對整個產品的影響也很大，那么在測試時就一定要覆蓋到。對於一個用戶很少用到的功能，出問題的機率很小，就算出了問題的影響也不是很大，那么如果時間比較緊的話，就可以考慮不測試。
基於風險測試的兩個決定因素就是：該功能出問題對用戶的影響有多大，出問題的機率有多大。其它一些影響因素還有複雜性、可用性、依賴性、可修改性等。測試人員主要根據事情的輕重緩急來決定測試工作的重點。
基於模型測試
模型實際上就是用語言把一個系統的行為描述出來，定義出它可能的各種狀態，以及它們之間的轉換關係，即狀態轉換圖。模型是系統的抽象。基於模型的測試是利用模型來生成相應的測試用例，然後根據實際結果和原先預想的結果的差異來測試系統。
相關信息
1. 開發人員若得知他們的代碼會被測試評估，他們會更加努力工作。
對代碼審查最有用的是讓編碼人知道他編寫的代碼會被審查。這就像一次內容為400級運算的期末考試。參加考試與否並不重要，因為考試的目的是學會運算。
這個道理也適用於代碼審查。電腦程式員對自己編寫的代碼總是相當自信。程式設計師之所以熬夜工作，是因為他們真正熱愛自己的其工作，而不是出於金錢或其他目的。因此，代碼審查可以直接影響開發人員的成就感。
編碼人不希望有任何針對他代碼的批評，所以一旦知道代碼將被審查，就會採取額外的努力做好工作。實際上，代碼審查通常不能發現什麼的。但是，如果知道有人要審查編碼，那么在編輯過程中程式設計師就會儘可能做好。
2. 軟體測試評估可以改進開發人員的編程技術
在你的心裡，你可能不會太在意某一特定軟體項目的成功。但是，大多數程式設計師想要改善他們的技術，這意味著向其他人學習。沒有比代碼審查更好的學習機會了。
代碼審查能幫助團隊成員從彼此的錯誤中汲取經驗，並成為更好的程式設計師。通過簡單的反饋意見，公司可以提高了其開發員的水平。開發員重視審查，因為他們知道這將幫助他們成長。當代碼審查以小組為單位進行時，整個團隊都得以提高。但更好的是，代碼質量也得到提升，並易於維護。
3. 軟體測試評估有利於導師制度，程式設計師們會學到更多
代碼審查有助於培訓新的開發人員並使他們熟悉其他同類模組。審查過程有助於促進思想交流，使代碼可重複利用。
代碼審查有一個系統的方法，可以為程式設計師分享團隊領導們的經驗提供平台。當領導重寫某些程式，使程式運行效率在3分鐘內提升50倍時，是十分令人振奮的事情!編寫其他程式時，你或許就可以找到一些新的方法或創造一種新的解決方案了。
4. 軟體測試評估可以實現優質文化的傳承
代碼審查的目的是提供巨大的機會。代碼審查讓代碼庫和編碼團隊都有機會發展一種連貫性和可靠性。它把有經驗和專業知識的團隊作為整體加以利用，程式設計師可以磨鍊他們的專業技能和經驗，同時以他們的經驗和專業知識為公司和團隊服務。這使該公司的投資得到有形的回報：愉悅的程式設計師以及工作代碼的能力和一致性不斷獲得提升。
代碼審查有助於創造一種微妙的變化，因此，管理好和做好代碼審查可以很大程度上改善軟體質量。開發人員會對審查中有出錯的數據的判定迅速給出抱怨，但我們必須改變規則，要將優質高效發展作為衡量過程的尺度而不僅是價值傳遞的里程碑。
5. 軟體測試評估可以激發團隊凝聚力
人們認為代碼審查僅僅是尋找漏洞，但它卻能把人團結在一起，它可以提供的遠遠超過你所預期的。
又很多這樣的例子在執行代碼審查時發生，但是最好的成功模式是在一個團隊成形時就開展審查。你從事某個項目的時間越長，所創建的代碼質量就越好。這是因為所有的代碼審查過程和管理在項目開始時就開始了。
6.軟體測試行業就業前景很好。
