軟體的複雜度發展到今天的程度，每個參與軟體生產的人對自己產品的質量可能多少都會有些擔心。至今還沒有理論能夠系統的預估和保證軟體產品的質量（可能永遠不會發展出這樣的理論，因為軟體作為人類思想的固定形式，對其質量的系統化保證可能已經超出了人類認識的「極限」）。
不過，多多少少會在軟體的歷史中沉澱一些有用的東西。下面的四條可能對於生產穩定的軟體有極大的幫助：
簡潔的設計
用最直白的形式作你要做的事情。看看unix和c在這方面留下的經典思想：如果不確定，就用蠻力（brutal force）。拋棄premature optimization。完美不是在你覺得不能往上增加東西的時候達到的，完美是在你覺得無法再減少東西的時候得到的。
足夠的維護
查詢軟體的缺陷，尤其是缺陷的原因，是一種碰運氣的活。不要指望乙個工作了十年的人發現某個特定缺陷的效率「一定」比乙個工作了兩年的人高。普遍來說前者的概率要高於後者，但是不可能每次都是。所以保持你的軟體維護者的數量，概率才能在大樣本空間中起作用。當足夠多的「眼球」盯著你的軟體，所有的缺陷都會像放在太陽下一樣。
主動的重構
保證你的軟體是活的。不要僅僅依靠bug-driven，乙個軟體應該自己吐故納新。
時間的沉澱
一切都需要時間。
軟體穩定性判斷的指標和標準
外部標準 1.給客戶帶來的損失 比如資料錯誤，系統宕機。把損失換成金錢，除以此系統本來可以賺的利潤，達到乙個百分比 標準1 客戶損失金額 利潤 說明 得到這個資料可能比較困難，現實有很多情形，我們可以靈活處理。一般的小問題客戶並不去計算損失，只要我們及時的把問題解決了就行了。然而我們總是要付出人力成...
軟體穩定性測試的測試點
1.對軟體多次測試，長時間執行，是否正常執行 2.長時間對軟體開啟關閉軟體和系統是否正常 3.軟體長時間執行某個業務後切換到別的不同的業務操作是否受影響 4.軟體長時間開啟但是不執行任何操作，然後檢查能否正常執行業務操作 5.軟體長時間對日常的使用者數進行操作執行，觀察系統記憶體佔用率是否越來越大，...
軟體穩定性測試的測試點
1.對軟體多次測試，長時間執行，是否正常執行 2.長時間對軟體開啟關閉軟體和系統是否正常 3.軟體長時間執行某個業務後切換到別的不同的業務操作是否受影響 4.軟體長時間開啟但是不執行任何操作，然後檢查能否正常執行業務操作 5.軟體長時間對日常的使用者數進行操作執行，觀察系統記憶體佔用率是否越來越大，...