測試領域中有待解決的難題們
最近人們談到測試，常常會聽到：測試其實很複雜，所以很有前途。但具體怎麼複雜卻不盡其詳。我覺得這篇我在微軟內部測試架構師站點裡讀到的，jim moore 關於測試領域中有待解決的難題的文章很有啟發。讀過之後，靜心想想，技術含量如何？好像蠻高的？呵呵，也許吧。這其中有些在微軟已經解決了，有些卻也是沒有解決的。 突然發現，測試技術對乙個公司來說好像還蠻秘密的，微軟很多內部測試工具測試框架都不產品化，雖然那些工具看起來是可以普遍運用到業界的。
《翻譯開始了》
難題可以分為這麼些類別：
質量衡量標準 (標尺)
可清晰量化的衡量產品質量
測試覆蓋率-**塊覆蓋,功能覆蓋,用例覆蓋.... 這麼多覆蓋率,每個覆蓋率,合理的目標是多少? 50%? 80% 100%
按照找到的缺陷數目,多少是被使用者找到的,多少是被內部非測試團隊找到的,多少是被測試團隊找到的,以此為衡量質量的標尺之一?
重**生的回歸性缺陷數目
補丁和service package數量,來衡量質量
我們有這麼多可以用來衡量質量的標準,那麼,哪些應該是核心的標準,最重要的普遍標準.怎麼把各個標準和質量關聯上?
制定發布的質量指標,怎樣才是正確的指標,可以指導我們決定發布還是延遲發布產品直到我們達到該指標.
怎麼定義測試效率?包括怎麼衡量s變化對測試的影響..
怎麼定義測試"完成"了?
複雜領域產品測試:
測試工具對系統本身的影響(測不准原理?):
效能測試工具本身對機器效能的影響所導致的測不准效果.
測試要素的各種組合(測試範圍龐大):
測試要素組合, 覆蓋各種可能組合,將變得龐大: 作業系統 vs. 除錯/發布 vs. 硬體配置 vs. 各種語言 vs. etc. vs. etc.
無窮無盡的使用者可能輸入.
有時間相關性的產品的測試.各種時間可能的窮舉是無限的.
整個產品範圍測試中的問題
整個產品的壓力測試
這個產品效能測試 vs. 各個開發組對自己模組所作的效能測試
整合測試.
測試集優選:
由時間和進度影響決定?
由使用者影響決定?
由平均測試用例所找到的缺陷數決定? (或者考慮其他投資回報因素而決定)
挑選測試用例覆蓋了所更改的**,依此決定?
由所要測試的**複雜度決定?
專案計畫安排:
準確估計測試所需要的時間.
測試團隊如何參與決定專案整體進度計畫.
敏捷快速迭代測試的計畫安排.
測試對專案的影響:
爭取修復缺陷– i.e. 比如要求開發組修復缺陷,而他們回答"沒人會這麼做!", 這個時候怎麼有理有據的堅持要求修復缺陷.
設計階段的測試團隊參與 – 可測試性的分析/設計.
是否該擁有對發布/不發布的決策的影響.
測試自動化:
整合測試:
整合測試中的自動化測試
除錯的責任,誰做整合測試,誰負責除錯整個產品中的問題?
整合測試應該包含哪些測試用例?
其他普遍的難題:
幾個版本發布之後,積累的測試**變得臃腫和難以維護.
設計不好的測試**,重複的測試**,各個測試自動化隊伍之間缺乏總體的設計和架構避免冗餘工作
冗餘的測試用例
留住有經驗的測試人才
測試領域中有待解決的難題們
最近人們談到測試，常常會聽到 測試其實很複雜，所以很有前途。但具體怎麼複雜卻不盡其詳。我覺得這篇我在微軟內部測試架構師站點裡讀到的，jim moore 關於測試領域中有待解決的難題的文章很有啟發。讀過之後，靜心想想，技術含量如何？好像蠻高的？呵呵，也許吧。這其中有些在微軟已經解決了，有些卻也是沒有解...
人工智慧和機器學習領域中有趣的開源專案
本文簡要介紹了10款 quora上推薦的人工智慧和機器學習領域方面的開源專案。graphlab是一種新的面向機器學習的並行框架。graphlab提供了乙個完整的平台，讓機構可以使用可擴充套件的機器學習系統建立大資料以 分析產品，該公司客戶包括zillow adobe zynga pandora bo...
領域中內聚的理解
領域中為什麼要有內聚？將關聯減至最少的設計有助於簡化物件之間的遍歷，並在某種程度上限制關係的急劇增多。但大多數業務領域中的物件都具有十分複雜的聯絡，以至於最終會形成乙個很長 很深的物件引用路徑，我們不得不在這個路徑上追蹤物件。某種程度上，這種混亂狀態反映了現實世界，因為現實世界很少有清晰的邊界。軟體...