最近開始玩了一款名叫Spore的PC game.
它有趣的地方在於可以創造屬於自己的生物
(從單細胞生物開始養成演化),在浩瀚的宇宙中探險.
這樣的Game對於消磨時間真是助益匪淺阿.
於是乎,我也創造了幾個生物,就貼出來笑笑吧.
2008年10月11日 星期六
最近玩的PC game
通常宅男的生活都離不開PC game,當然我也不例外.
最近開始玩了一款名叫Spore的PC game.
它有趣的地方在於可以創造屬於自己的生物
(從單細胞生物開始養成演化),在浩瀚的宇宙中探險.
這樣的Game對於消磨時間真是助益匪淺阿.
於是乎,我也創造了幾個生物,就貼出來笑笑吧.
最近開始玩了一款名叫Spore的PC game.
它有趣的地方在於可以創造屬於自己的生物
(從單細胞生物開始養成演化),在浩瀚的宇宙中探險.
這樣的Game對於消磨時間真是助益匪淺阿.
於是乎,我也創造了幾個生物,就貼出來笑笑吧.
2008年10月10日 星期五
軟體測試的常識
今天一位前同事問我一些對於軟體測試的概念及想法,其實我只會寫程式,對於軟體測試的概念卻是等於零..所以只好上網看看一些有經驗的人的想法,恰巧看到了以下這篇文章,我認為寫的不錯,他的觀念我也能接受.重點是文章又不長,看了還不至於想睡覺^^
軟體測試的常識
作者：newsmth.org 發文時間：2005.07.18
軟體發展和使用的歷史已經留給了我們很多由於軟體缺陷而導致的巨大財力、物力損失的經驗教訓。這些經驗教訓迫使我們這些測試工程師們必須採取強有力的檢測措施來檢測未發現的隱藏的軟體缺陷。
生產軟體的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟體品質的標準，認為軟體缺陷(Software Bug)的具體含義包括下面幾個因素：
o 軟體未達到客戶需求的功能和性能；
o 軟體超出客戶需求的範圍；
o 軟體出現客戶需求不能容忍的錯誤；
o 軟體的使用未能符合客戶的習慣和工作環境。
考慮到設計等方面的因素，我們還可以認為軟體缺陷還可以包括軟體設計不符合規範，未能在特定的條件(資金、範圍等)達到最佳等。可惜的是，我們中的很多人更傾向於把軟體缺陷看成運行時出現問題上來，認為軟體測試僅限於程式提交之後。
在目前的國內環境下，我們幾乎看不到完整準確的客戶需求說明書，加以客戶的需求時時在變，追求完美的測試變得不太可能。因此作為一個優異的測試人 員，追求軟體品質的完美固然是我們的宗旨，但是明確軟體測試現實與理想的差距，在軟體測試中學會取捨和讓步，對軟體測試是有百益而無一弊的。
下面是一些軟體測試的常識，對這些常識的理解和運用將有助於我們在進行軟體測試時能夠更好的把握軟體測試的尺度。
o 測試是不完全的(測試不完全)
很顯然，由於軟體需求的不完整性、軟體邏輯路徑的組合性、輸入資料的大量性及結果多樣性等因素，哪怕是一個極其簡單的程式，要想窮盡所有邏輯路 徑，所有輸入資料和驗證所有結果是非常困難的一件事情。我們舉一個簡單的例子，比如說求兩個整數的最大公約數。其輸入資訊為兩個正整數。但是如果我們將整 個正整數域的數位進行一番測試的話，從其數目的無限性我們便可證明是這樣的測試在實際生活中是行不通的，即便某一天我們能夠窮盡該程式，只怕我們乃至我們 的子孫都早已作古了。為此作為軟體測試，我們一般採用等價類和邊界值分析等措施來進行實際的軟體測試，尋找最小用例集合成為我們精簡測試複雜性的一條必經 之道。
o 測試具有免疫性(軟體缺陷免疫性)
軟體缺陷與病毒一樣具有可怕的“免疫性”，測試人員對其採用的測試越多，其免疫能力就越強，尋找更多軟體缺陷就更加困難。由數學上的概率論我們可 以推出這一結論。假設一個50000行的程式中有500個軟體缺陷並且這些軟體錯誤分佈時均勻的，則每100行可以找到一個軟體缺陷。我們假設測試人員用 某種方法花在查找軟體缺陷的精力為X小時/100行。照此推算，軟體存在500個缺陷時，我們查找一個軟體缺陷需要X小時，當軟體只存在5個錯誤時，我們 每查找一個軟體缺陷需要100X小時。實踐證明，實際的測試過程比上面的假設更為苛刻，為此我們必須更換不同的測試方式和測試資料。該例子還說明了在軟體 測試中採用單一的方法不能高效和完全的針對所有軟體缺陷，因此軟體測試應該盡可能的多採用多種途徑進行測試。
o 測試是“泛型概念”(全程測試)
我一直反對軟體測試僅存在於程式完成之後。如果單純的只將程式設計階段後的階段稱之為軟體測試的話，需求階段和設計階段的缺陷產生的放大效應會加 大。這非常不利於保證軟體品質。需求缺陷、設計缺陷也是軟體缺陷，記住 " 軟體缺陷具有生育能力 " 。軟體測試應該跨越整個軟體發展流程。需求驗證（自檢）和設計驗證（自檢）也可以算作軟體測試（建議稱為：需求測試和設計測試）的一種。軟體測試應該是一 個泛型概念，涵蓋整個軟體生命週期，這樣才能確保週期的每個階段禁得起考驗。同時測試本身也需要有第三者進行評估（資訊系統審計和軟體工程監理），即測試 本身也應當被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。
另外還需指出的是軟體測試是提高軟體產品品質的必要條件而非充分條件，軟體測試是提高產品品質最直接、最快捷的手段，但決不是一個根本手段。
o 80-20原則
80%的軟體缺陷常常生存在軟體20%的空間裏。這個原則告訴我們，如果你想使軟體測試有效地話，記住常常光臨其高危多發“地段”。在那裏發現軟 體缺陷的可能性會大的多。這一原則對於軟體測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測 試人員卻仍在漫無目的地到處搜尋。
80-20原則的另外一種情況是，我們在系統分析、系統設計、系統實現階段的復審，測試工作中能夠發現和避免80%的軟體缺陷，此後的系統測試能 夠幫助我們找出剩餘缺陷中的80%，最後的5%的軟體缺陷可能只有在系統交付使用後用戶經過大範圍、長時間使用後才會曝露出來。因為軟體測試只能夠保證盡 可能多地發現軟體缺陷，卻無法保證能夠發現所有的軟體缺陷。
80-20原則還能反映到軟體測試的自動化方面上來，實踐證明80%的軟體缺陷可以借助人工測試而發現，20%的軟體缺陷可以借助自動化測試能夠得以發現。由於這二者間具有交叉的部分，因此尚有5%左右的軟體缺陷需要通過其他方式進行發現和修正。
o 為效益而測試
為什麼我們要實施軟體測試，是為了提高項目的品質效益最終以提高專案的總體效益。為此我們不難得出我們在實施軟體測試應該掌握的度。軟體測試應該 在軟體測試成本和軟體品質效益兩者間找到一個平衡點。這個平衡點就是我們在實施軟體測試時應該遵守的度。單方面的追求都必然損害軟體測試存在的價值和意 義。一般說來，在軟體測試中我們應該儘量地保持軟體測試簡單性，切勿將軟體測試過度複雜化，拿物理學家愛因斯坦的話說就是：Keep it simple but not too simple。
o 缺陷的必然性
軟體測試中，由於錯誤的關聯性，並不是所有的軟體缺陷都能夠得以修復。某些軟體缺陷雖然能夠得以修復但在修復的過程中我們會難免引入新的軟體缺 陷。很多軟體缺陷之間是相互矛盾的，一個矛盾的消失必然會引發另外一個矛盾的產生。比如我們在解決通用性的缺陷後往往會帶來執行效率上的缺陷。更何況在缺 陷的修復過程中，我們常常還會受時間、成本等方面的限制因此無法有效、完整地修復所有的軟體缺陷。因此評估軟體缺陷的重要度、影響範圍，選擇一個折中的方 案或是從非軟體的因素（比如提升硬體性能）考慮軟體缺陷成為我們在面對軟體缺陷時一個必須直面的事實。
o 軟體測試必須有預期結果
沒有預期結果的測試是不可理喻的。軟體缺陷是經過對比而得出來的。這正如沒有標準無法進行度量一樣。如果我們事先不知道或是無法肯定預期的結果， 我們必然無法瞭解測試正確性。這很容易然人感覺如盲人摸象一般，不少測試人員常常憑藉自身的感覺去評判軟體缺陷的發生，其結果往往是把似是而非的東西作為 正確的結果來判斷，因此常常出現誤測的現象。
o 軟體測試的意義——事後分析
軟體測試的目的單單是發現缺陷這麼簡單嗎？如果是“是”的話，我敢保證，類似的軟體缺陷在下一次新專案的軟體測試中還會發生。古語說得好，“不知 道歷史的人必然會重蹈覆轍”。沒有對軟體測試結果進行認真的分析，我們就無法瞭解缺陷發生的原因和應對措施，結果是我們不得不耗費的大量的人力和物力來再 次查找軟體缺陷。很可惜，目前大多測試團隊都沒有意識到這一點，測試報告中缺乏測試結果分析這一環節。
結論：
軟體測試是一個需要“自覺”的過程，作為一個測試人員，遇事沉著，把持尺度，從根本上應對軟體測試有著正確的認識，希望本文對讀者對軟體測試的認識有所幫助。
http://tech.ccidnet.com/pub/article/c29 ... 87_p1.html
軟體測試的常識
作者：newsmth.org 發文時間：2005.07.18
軟體發展和使用的歷史已經留給了我們很多由於軟體缺陷而導致的巨大財力、物力損失的經驗教訓。這些經驗教訓迫使我們這些測試工程師們必須採取強有力的檢測措施來檢測未發現的隱藏的軟體缺陷。
生產軟體的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟體品質的標準，認為軟體缺陷(Software Bug)的具體含義包括下面幾個因素：
o 軟體未達到客戶需求的功能和性能；
o 軟體超出客戶需求的範圍；
o 軟體出現客戶需求不能容忍的錯誤；
o 軟體的使用未能符合客戶的習慣和工作環境。
考慮到設計等方面的因素，我們還可以認為軟體缺陷還可以包括軟體設計不符合規範，未能在特定的條件(資金、範圍等)達到最佳等。可惜的是，我們中的很多人更傾向於把軟體缺陷看成運行時出現問題上來，認為軟體測試僅限於程式提交之後。
在目前的國內環境下，我們幾乎看不到完整準確的客戶需求說明書，加以客戶的需求時時在變，追求完美的測試變得不太可能。因此作為一個優異的測試人 員，追求軟體品質的完美固然是我們的宗旨，但是明確軟體測試現實與理想的差距，在軟體測試中學會取捨和讓步，對軟體測試是有百益而無一弊的。
下面是一些軟體測試的常識，對這些常識的理解和運用將有助於我們在進行軟體測試時能夠更好的把握軟體測試的尺度。
o 測試是不完全的(測試不完全)
很顯然，由於軟體需求的不完整性、軟體邏輯路徑的組合性、輸入資料的大量性及結果多樣性等因素，哪怕是一個極其簡單的程式，要想窮盡所有邏輯路 徑，所有輸入資料和驗證所有結果是非常困難的一件事情。我們舉一個簡單的例子，比如說求兩個整數的最大公約數。其輸入資訊為兩個正整數。但是如果我們將整 個正整數域的數位進行一番測試的話，從其數目的無限性我們便可證明是這樣的測試在實際生活中是行不通的，即便某一天我們能夠窮盡該程式，只怕我們乃至我們 的子孫都早已作古了。為此作為軟體測試，我們一般採用等價類和邊界值分析等措施來進行實際的軟體測試，尋找最小用例集合成為我們精簡測試複雜性的一條必經 之道。
o 測試具有免疫性(軟體缺陷免疫性)
軟體缺陷與病毒一樣具有可怕的“免疫性”，測試人員對其採用的測試越多，其免疫能力就越強，尋找更多軟體缺陷就更加困難。由數學上的概率論我們可 以推出這一結論。假設一個50000行的程式中有500個軟體缺陷並且這些軟體錯誤分佈時均勻的，則每100行可以找到一個軟體缺陷。我們假設測試人員用 某種方法花在查找軟體缺陷的精力為X小時/100行。照此推算，軟體存在500個缺陷時，我們查找一個軟體缺陷需要X小時，當軟體只存在5個錯誤時，我們 每查找一個軟體缺陷需要100X小時。實踐證明，實際的測試過程比上面的假設更為苛刻，為此我們必須更換不同的測試方式和測試資料。該例子還說明了在軟體 測試中採用單一的方法不能高效和完全的針對所有軟體缺陷，因此軟體測試應該盡可能的多採用多種途徑進行測試。
o 測試是“泛型概念”(全程測試)
我一直反對軟體測試僅存在於程式完成之後。如果單純的只將程式設計階段後的階段稱之為軟體測試的話，需求階段和設計階段的缺陷產生的放大效應會加 大。這非常不利於保證軟體品質。需求缺陷、設計缺陷也是軟體缺陷，記住 " 軟體缺陷具有生育能力 " 。軟體測試應該跨越整個軟體發展流程。需求驗證（自檢）和設計驗證（自檢）也可以算作軟體測試（建議稱為：需求測試和設計測試）的一種。軟體測試應該是一 個泛型概念，涵蓋整個軟體生命週期，這樣才能確保週期的每個階段禁得起考驗。同時測試本身也需要有第三者進行評估（資訊系統審計和軟體工程監理），即測試 本身也應當被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。
另外還需指出的是軟體測試是提高軟體產品品質的必要條件而非充分條件，軟體測試是提高產品品質最直接、最快捷的手段，但決不是一個根本手段。
o 80-20原則
80%的軟體缺陷常常生存在軟體20%的空間裏。這個原則告訴我們，如果你想使軟體測試有效地話，記住常常光臨其高危多發“地段”。在那裏發現軟 體缺陷的可能性會大的多。這一原則對於軟體測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測 試人員卻仍在漫無目的地到處搜尋。
80-20原則的另外一種情況是，我們在系統分析、系統設計、系統實現階段的復審，測試工作中能夠發現和避免80%的軟體缺陷，此後的系統測試能 夠幫助我們找出剩餘缺陷中的80%，最後的5%的軟體缺陷可能只有在系統交付使用後用戶經過大範圍、長時間使用後才會曝露出來。因為軟體測試只能夠保證盡 可能多地發現軟體缺陷，卻無法保證能夠發現所有的軟體缺陷。
80-20原則還能反映到軟體測試的自動化方面上來，實踐證明80%的軟體缺陷可以借助人工測試而發現，20%的軟體缺陷可以借助自動化測試能夠得以發現。由於這二者間具有交叉的部分，因此尚有5%左右的軟體缺陷需要通過其他方式進行發現和修正。
o 為效益而測試
為什麼我們要實施軟體測試，是為了提高項目的品質效益最終以提高專案的總體效益。為此我們不難得出我們在實施軟體測試應該掌握的度。軟體測試應該 在軟體測試成本和軟體品質效益兩者間找到一個平衡點。這個平衡點就是我們在實施軟體測試時應該遵守的度。單方面的追求都必然損害軟體測試存在的價值和意 義。一般說來，在軟體測試中我們應該儘量地保持軟體測試簡單性，切勿將軟體測試過度複雜化，拿物理學家愛因斯坦的話說就是：Keep it simple but not too simple。
o 缺陷的必然性
軟體測試中，由於錯誤的關聯性，並不是所有的軟體缺陷都能夠得以修復。某些軟體缺陷雖然能夠得以修復但在修復的過程中我們會難免引入新的軟體缺 陷。很多軟體缺陷之間是相互矛盾的，一個矛盾的消失必然會引發另外一個矛盾的產生。比如我們在解決通用性的缺陷後往往會帶來執行效率上的缺陷。更何況在缺 陷的修復過程中，我們常常還會受時間、成本等方面的限制因此無法有效、完整地修復所有的軟體缺陷。因此評估軟體缺陷的重要度、影響範圍，選擇一個折中的方 案或是從非軟體的因素（比如提升硬體性能）考慮軟體缺陷成為我們在面對軟體缺陷時一個必須直面的事實。
o 軟體測試必須有預期結果
沒有預期結果的測試是不可理喻的。軟體缺陷是經過對比而得出來的。這正如沒有標準無法進行度量一樣。如果我們事先不知道或是無法肯定預期的結果， 我們必然無法瞭解測試正確性。這很容易然人感覺如盲人摸象一般，不少測試人員常常憑藉自身的感覺去評判軟體缺陷的發生，其結果往往是把似是而非的東西作為 正確的結果來判斷，因此常常出現誤測的現象。
o 軟體測試的意義——事後分析
軟體測試的目的單單是發現缺陷這麼簡單嗎？如果是“是”的話，我敢保證，類似的軟體缺陷在下一次新專案的軟體測試中還會發生。古語說得好，“不知 道歷史的人必然會重蹈覆轍”。沒有對軟體測試結果進行認真的分析，我們就無法瞭解缺陷發生的原因和應對措施，結果是我們不得不耗費的大量的人力和物力來再 次查找軟體缺陷。很可惜，目前大多測試團隊都沒有意識到這一點，測試報告中缺乏測試結果分析這一環節。
結論：
軟體測試是一個需要“自覺”的過程，作為一個測試人員，遇事沉著，把持尺度，從根本上應對軟體測試有著正確的認識，希望本文對讀者對軟體測試的認識有所幫助。
http://tech.ccidnet.com/pub/article/c29 ... 87_p1.html
訂閱：
文章 (Atom)
