軟體測試過程的持續完善
來自：不詳
１．引言
隨著軟體技術的迅猛發展，軟體的質量愈來愈受到廣泛的重視。而測試又是保證軟體質量的重要手段。根據ieee/ansi標準，軟體測試的定義是："使用為發現錯誤所選擇的輸入和狀態的組合而執行**的過程"。這就非常明確地提出了軟體測試是以發現錯誤，檢驗是否滿足需求為目標。軟體測試在軟體生命週期中占有非常突出的重要地位，是保證軟體質量的重要手段。根據boehm的統計，軟體開發總成本中，用在測試上的開銷要佔40%到50%。軟體測試的目的就是在軟體投入生產性執行之前，盡可能多地發現軟體中的錯誤，以提高軟體的質量。現代的軟體測試不僅僅是在軟體開發完成以後來做測試工作，而是將測試滲入到軟體開發的各個階段，而且提高自動化軟體測試手段，來提高測試效率。
有些專案的主持人，認為以盡快的速度把測試之前的所有開發階段完成（實際並沒有完成），早日開始測試，以圖達到快速和高質量（因為似乎有更長的時間可用於測試）。實際的效果將會是俗語所說的"欲速則不達"。從常識就可以知道，花開發時間去繼續擴大發展前面階段引入的錯誤，得出的只能是更大量的需要耗時修正的錯誤。 因此，正確分析與利用測試的結果，我們可以非常有效地進行軟體過程改進。
2．完善測試過程策略
1． 雙效合一，不斷進步
公司的管理層和質量控制小組通常進行軟體過程的改善，並編寫出了一系列的企業的標準與規範，經過一系列的評審、培訓，然後讓開發人員去執行。但是在執行過程中常常碰到阻力，多數是來自於開發人員，除了緊張的開發工作，他們往往會抱怨又多出許多其它工作，比如按照一定的規範的文件的撰寫；制定的企業開發規範不符合企業的實際情況，標準太高，無法達到。這一種做法，費時費力不討好，大家的意見都比較大，規範定的比較完美，而且在評審時還要大家表面上都要認可，制定規範的人花費了很大的精力，對規範的評審浪費了大家的很多的時間，執行時還難以貫徹下去。這種方式肯定收效甚微。這是一種效率比較低的做法。
通常，還會有另外一種做法：降低要求，暫時拋棄各種標準與規範，採用一種簡單易行的策略，即由質量控制小組找開發人員、專案經理讓他們自我發現問題：你有什麼缺點？你將如何改進？在開發人員、專案管理人員講自己的改進措施後，讓他們確保能做到。在這種辦法中，不需要管理人員花費太多的精力進行標準的制定，改進的推動，這些工作都是由開發人員自己去做的，管理人員僅僅是起到了監督的作用，只要開發人員自己說到做到就可以了。但是，我們做了乙個嘗試，如果僅僅從開發人員的角度出發制定標準，每個人的習慣不同，開發人員往往傾向於按照平日自己的程式設計習慣制定符合自己需要的規範，這樣做的隨意性比較大，難以形成統一的、正規的文件體系結構。而且，開發人員往往利用這一點，給自己留有充分的彈性。往往自己制定的規範都有自己不同的解決辦法，這樣會造成程式設計風格的不統一。既然是規範，總得有一定的強制性，而如果單單從下而上，放權給開發人員，實施的過程中可能會發生更大的問題。
綜上所述，我們就採取了乙個折中的辦法，即，根據開發人員的要求，先擬訂乙份開發規範，然後提交給開發人員或者專案管理人員評審。允許他們提出自己的意見，如果意見合理，可以對規範實施修改。舉例來說，假設公司原來的文件體系中本身有一套程式設計規範，但是在實際開發的時候，其中的某些規則不是很實用，所以，公司就根據每個專案組所使用的開發工具和語言的不同，制定不同的程式設計標準，而這些程式設計標準的修改意見，基本上來自於開發人員，但是是經過公司的管理人員和質量控制部審核過的。
這種做法的好處就是可以主動提高公司全體員工的質量意識。對於高層管理人員而言，所有的規範都是經過他們審核批准的，他們起到監督作用；對於開發人員而言，很多規則是他們提出的，他們會自覺遵守。這樣雙管齊下，雙效合一，不僅會大大提高軟體的質量，而且不用將發現錯誤的責任全部推給測試人員，而是提前預防錯誤、減少潛在危險的發生、減輕測試人員負擔、培養開發人員良好的程式設計習慣。
2． 重視文件，需要技巧
軟體文件也稱檔案，通常指的是一些記錄的資料和資料**，它具有固定不變的形式，可被人和計算機閱讀。它和電腦程式共同構成了能完成特定功能的計算機軟體（有人把源程式也當作文件的一部分）。硬體產品和產品資料在整個生產過程中都是有形可見的，軟體生產則有很大不同，文件本身就是軟體產品。沒有文件的軟體，不稱其為軟體，更談不上軟體產品。軟體文件的編制在軟體開發工作中占有突出的地位和相當的工作量。高效率、高質量地開發、分發、管理和維護文件對於轉讓、變更、修正、擴充和使用文件，對於充分發揮軟體產品地效益有著重要的意義。
然而，在實際工作中，文件在編制和使用中存在著許多問題，有待於解決。軟體開發人員中較普遍地存在著對編制文件不感興趣的現象。從使用者方面看，他們又常常抱怨：文件售價太高、文件不夠完整、文件編寫的不好、文件已經陳舊難於使用等等。
眾所周知，文件的編寫對於開發人員來說是乙個十分頭疼的任務，本來開發周期就很緊，還要按照要求的格式撰寫文件。所以，這樣結果往往就是文件不全，或者文件過於簡單致使測試人員看不懂。甚至於，有時候專案需求早就更新了，而文件的內容依然不變。
換個角度想想看，如果文件不全，測試人員遇到不理解的地方肯定會去問相應的開發人員，那麼開發人員肯定要花費時間做解釋。如果測試人員和開發人員處在不同的工作地，這將造成十分的不便。
在軟體開發過程中，文件十分重要，書寫文件工作量也是相當大的。但是，只要掌握住技巧，還是可以緩解這令人頭疼的問題的。首先，要站在別人的角度上看待這個問題。自己是做開發當然必須十分清楚程式的流程及功能，但是其他人就不一定，包括測試人員。所以，不要排斥寫文件，先要換個角度想問題。再次，闡述基本功能，要做到重點突出。就是說，用簡單的語言把功能簡要介紹。對於其中的重點部分，要突出，要詳細。不是說語言上要十分詳細，而是理解的角度要詳細。為了讓測試人員快速理解模組的功能，最好的辦法就是：功能流程圖、資料流程圖和例子。尤其是對於那些有相當強邏輯的程式而言，資料流程圖和例子是非常好的方法，它不僅可以幫助指明資料的流向，還可以幫助測試人員理解測試用例的型別，以及結果形式。製作簡明扼要的流程圖和例子對開發人員而言是一項理清思路、省時省力的工作。而對於測試人員而言則是乙份理解程式邏輯和功能的重要文件。在開發過程的後期，可以繼續細化和完善文件。
3． 結隊程式設計，提前測試
為了提高軟體的質量，公司可以嘗試實行先結隊程式設計，這其中也貫穿著質量意識。因為組成隊的兩個開發人員輪流程式設計、輪流寫文件、互相監督、互相測試。這樣不僅可以有精力把文件寫好寫全，而且可以提前單元測試，互相監督對方養成好的程式設計習慣。最終提高工作效率。 結隊程式設計後，單元模組先由專案組配備的測試人員首先進行測試，然後質量控制部的人員按照專案計畫檢查專案是否按照預定計畫正常進行，相關文件是否撰寫，並進行整合測試。
4． 善於總結，提高效率
總結是一種非常好的學習方法，它可以節省精力、節約時間達到事半功倍的效果。在專案的開發過程中，可以將碰到的重要的技術方面的問題要及時記錄並將解決方案也記錄下來，以便於其他相關人員的參考。同樣，在測試的過程中，測試人員應該及時總結發現的錯誤並歸類，標明經常容易出錯的地方，將意見提交專案經理，審核後，制定出乙份統一標準並提供給開發人員，這樣就可以提前避免錯誤、避免重複錯誤和重複測試，提高測試效率。不僅如此，專案結束後的各項總結報告將是專案的後期維護或二次開發的寶貴參考資料。
３．結論
軟體開發作為一種複雜的智力密集型的活動，同一般產品的設計和生產過程有相當大的差別，人的因素佔的比例很大，控制也更為複雜。例如軟體的正確性無法證明、測試也很困難，如果希望通過最終的測試確保產品的質量是完全做不到的；生命週期的各個階段的轉化無法確保百分之百的正確和完整，等等。實踐證明，如果不從本公司的實際情況出發，盲目地套用一些好高騖遠的開發體系或者質量體系檔案是行不通的，所建立的體系對提高管理水平非但不能起到多大的促進作用，而且可能會對正常的開發活動起阻礙作用，引起開發人員的反感。這樣建立的體系或者難於維持下去，或者要花費寶貴的資源去維持一套無用的體系。所以，建議根據公司的實際量身定做，建立起一套符合本公司情況的切實可行的標準和規範，真正的改善軟體過程，加強測試，提高軟體質量。
軟體測試過程將如何完善？
引言 隨著軟體技術的迅猛發展，軟體的質量愈來愈受到廣泛的重視。而測試又是保證軟體質量的重要手段。根據ieee ansi標準，軟體測試的定義是 使用為發現錯誤所選擇的輸入和狀態的組合而執行 的過程 這就非常明確地提出了軟體測試是以發現錯誤，檢驗是否滿足需求為目標。軟體測試在軟體生命週期中占有非常突出的...
軟體測試過程的持續改進
隨著國內 軟體測試 行業的逐漸發展，有越來越多的軟體企業更加重視軟體測試，並已經形成了一套基本的軟體測試流程。但是軟體測試所起的作用還沒有人們期望那樣顯著，因此，就需要繼續加大投入對軟體測試的關注程度，對軟體測試過程進行持續的改進。以下是本人在 工作中的一些體會，介紹軟體測試過程中需要注重和改進的幾...
linux的常規優化 持續完善
1 linux 1 現象 日誌 現 too manay open files 或者類似資訊 原因 伺服器允許的最大控制代碼數 當前使用者允許的最大控制代碼數或者當前執行緒允許的最大控制代碼數沒有調整 解決方法 1.在 etc security limits.conf 檔案最後加上如下語句 soft ...