Re: [請益] 各位公司都怎麼去做軟體測試的阿？

看板Soft_Job作者TonyQ (自立而後立人。)時間14年前 (2012/01/09 00:35)推噓0(0推 0噓 24→)

留言24則, 3人參與討論串6/8 (看更多)

寫一下幾點對測試的看法（特別注意，測試只是QA的一環...）請先參考 #1DqFRBDw (Soft_Job) [ptt.cc] [轉錄] 開發人員的測試悖論這整串都蠻有參考價值的基本上測試本身是一個很大的主題，從組織上：測試跟 RD 權力位階怎麼分配？管理上：測試何時進行由誰進行測試用的 use-case 由誰擬定方法上：不同語言/平台/環境有不同測試工具，也有不同的限制。所以測試是很難一篇文章涵蓋周全的東西。 ----------------------------------- 以下這邊算是我個人的經驗談，沒什麼學術佐證也不保證對，就是談談。測試人員跟開發人員怎麼合作是一個大哉問。有的單位是開發人員完全不管code會不會動，寫完直接扔給QA確認，一個一個bug解。有的單位是開發人員自己要想辦法找出所有 bug ，出到QA那邊被找到bug要扣績效。這些合作模式哪個是對的並沒有定論，每個模式下也可以延伸出不同生態。我採取的看法是開發者需要負擔一部分的測試責任，而 QA 則也負擔另一部份的測試責任。我自己認為應該由開發者進行的測試應該是 1.開發人員自己要對自己的 code 有經由測試而獲得的基本信心，就是你送code出去時至少要有六成以上的把握，不能看都不看就扔出去。對 unit test 等測試工具要有基本的概念，能在不妨礙開發進度又評估能因此節省時間的狀況下，使用測試工具進行基本的自動化測試。自動化測試跟人腦測試最大的優點在於電腦效率比較好，而且他不會一時恍神就出鎚，可以很忠實的呈現結果，不因狀態而影響。但缺點是太一板一眼，有些bug還是要自己點過才看的出來。對RD 開發過程我覺得，主要是手工為主，測試工具為輔，不要為了測試而測試，確實掌握測試工具並且能節省時間再用。像一些複雜難以用腦袋反覆驗證，但卻需要一直修改、調整的邏輯，寫成 unit test 塞入許多 input/output 測資，每次修正後加以驗證，避免人腦一直進行不必要的驗算，就是有賺的。 getter/setter 這種單純的設值操作，就不是那麼有必要寫 unit test，因為cp 值太低。 2.測試不一定是用來找出所有 bug 的，有時是盡可能避免「已知」的bug再冒出來。或者避免違反基本原則的設計出現。不要想要透過測試涵蓋所有可能出錯的案例，基本上那幾乎是不可能的，而且很多時候很難定義什麼是對跟錯。大多時候你還是需要倚賴工程師或人的判斷 3.測試測的是「邏輯」，不是「真正複雜環境產出的結果」舉個例子，通常扯到 dao 的測試，我們不一定會用真的 DB 進行測試，而會用 Mock object 假設 db 運作正常，回傳正常的物件。這時候就會有人說，那我沒跑真正的 db ，我怎麼知道它會對？跑db 可以用別的測試案例，但這裡你並不是要測所有條件都滿足的狀況下，而是在給訂某些已知條件前提下，他是否如你所想的運作。（當然，有時候會給錯已知條件，這就考驗設計者的功力...）真正跑在類似真正的伺服器的環境的，我們稱之為整合測試。 (integration test) 這通常不是 RD 等級測的東西，因為環境相當的複雜，適合交由專門的角色處理，在 RD 角色來看，盡可能讓條件跟邏輯單純化，才能夠有比較好的效益跟產出。筆電沒電，先寫到這裡當作拋磚引玉好了...... 歡迎論戰/回應，我自認只算測試入門，看看笑笑，有問題幫忙釘正一下。:P -- Life's a struggle but beautiful. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 111.80.197.64 ※ 編輯: TonyQ 來自: 111.80.197.64 (01/09 00:37)

→

Lordaeron

01/09 00:45, , 1^F

01/09 00:45, 1^F

→

Lordaeron

01/09 00:45, , 2^F

01/09 00:45, 2^F

→

Lordaeron

01/09 00:46, , 3^F

01/09 00:46, 3^F