測試領域中有待解決的難題們

2021-04-19 23:26:22 字數 1654 閱讀 7004

最近人們談到測試,常常會聽到:測試其實很複雜,所以很有前途。但具體怎麼複雜卻不盡其詳。我覺得這篇我在微軟內部測試架構師站點裡讀到的,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...

領域中內聚的理解

領域中為什麼要有內聚?將關聯減至最少的設計有助於簡化物件之間的遍歷,並在某種程度上限制關係的急劇增多。但大多數業務領域中的物件都具有十分複雜的聯絡,以至於最終會形成乙個很長 很深的物件引用路徑,我們不得不在這個路徑上追蹤物件。某種程度上,這種混亂狀態反映了現實世界,因為現實世界很少有清晰的邊界。軟體...