發表文章

殺蟲劑悖論 pesticide paradox

大家應該都聽過,不斷使用某牌的殺蟲劑,最後該環境的蟲子就開始對那牌的殺蟲劑產生抗性。 殺蟲劑漸漸無效,蟲子開心的吃著火鍋唱著歌。 殺蟲劑悖論 是測試領域的一個名詞,也如同字面上的意思,產品會漸漸對不斷執行的「相同測試案例」有抗性。 同樣的一組測試案例會漸漸無法發現產品的問題。 所以測試案例需要不斷更新維護,嘗試發現其他問題。 (全文完,大家看到這邊就可以了。) 以下是幹話時間 「為什麼?難道產品是活的,還懂得怎麼搞事嗎?」聽到殺蟲劑悖論時,剛進來的 QA 實習生 A 覺得很驚訝。 「產品是死的,但 Dev 是活的。」資深的前輩 R 又說了讓人無法頓悟的話,然後喝了一口茶。 實習生 A 和前輩 R 並不重要,等一下也不會再提到他們。 為什麼會有殺蟲劑悖論的現象 假設現在有一個非常簡單的產品,這個產品做的就是輸入1個數字,然後顯示這個數字+10之後的結果。 透過一些門路,我們知道產品的 code 長這樣(因為是黑箱測試,測試的人並不知道喔): num = int(input("Input a number...")) print(num + 10) 規格書有說,不輸入就當作0的意思。 對了,這個故事不幸的是,這間公司為了縮減開銷,把 QA 都裁掉了。 現在剩下便宜大碗的實習生  aka 血汗萬用雜工 照著前人留下的測試案例來測。 我們現有的測試案例是這樣: 輸入正整數 預期結果:正整數+10 輸入負數 預期結果:負數+10 不輸入 預期結果:10 輸入小數 預期結果:小數+10 第一次測試,我們火眼金睛的實習生立刻發現,這個產品在不輸入和輸入小數時會壞掉,於是開2張單請 Dev 修: [PDADDNUM-100] Throw an error if no input [PDADDNUM-101] Throw an error if a number with a decimal point 我們的 Dev 連夜趕工修好了: num = 0 input_num = input("Input a number...") if input_num: print(float(input_num) + 10) else: print(10) 第二次測試,現在不輸入沒問題了,關了一張單(PDADDNUM-100)。 ...

手動測試與自動化測試的選擇

在聊手動測試與自動化測試的選擇之前,先聊聊手動測試和自動化測試的優缺點和適用場景。 手動測試 手動測試是指測試人員手動操作軟體應用程式,確認使用起來一切安好、一切符合規格和預期。 優點 以人類的角度使用一個軟體產品 畢竟產品最終就是要給人使用,判斷這個軟體應用的功能、流程設計是不是直覺、易懂、美觀等等。而且也能很輕易的發現介面上的問題,比方跑版、點了之後乍看好像沒有反應等。 即時的適應變化 在敏捷開發中,一個還在開發甚至是設計中的軟體功能就可能需要測試參與了,其中可能有多次的大改,自動化在這時候就是完全不適合的狀況。 進行探索性測試 發掘一些被規格書遺漏掉的部分、特殊的使用情境、一些很清奇的操作、在一些原本簡單但越來越複雜的軟體系統中,嘗試各種操作的交互。 缺點 當軟體功能穩定時,每次都以手動來執行相同的測試,較耗費人力、時間。 在測試次數極為頻繁、時程緊迫的狀況下,測試人員容易因為精神上的疲倦而導致錯誤和盲點,導致測試結果可能不可靠。 測試速度仰賴測試人員的熟練度。如果功能交給其他不熟悉的人測試,時間上可能會有巨大的差異。 適合的場景 探索性測試 (Exploratory Testing):發掘一些沒有明確定義在規格書上的行為,一些特殊場景下可能沒考慮到的問題。 可用性/易用性測試 (Usability Testing):對於界面是否直覺、美觀,文字大小、排版、顏色、聲音等測試。 臨時/隨機測試 (Ad-hoc Testing) 小型的專案 - 可能沒有自動化的時間及預算。 新的功能 - 功能還在發展初期,會經常變化等。 頻繁更動的功能 - 雖然不是發展初期的功能,但還是可能時常大幅更動。 不穩定的功能 - 可能因為測試環境資源不足、第三方服務(理想上這要做 mock)等問題,而時好時壞(多嘗試幾次可能成功或不成功)的功能。 接著來聊聊自動化。  自動化測試 自動化測試通常是指相對於手動測試,透過程式、工具來執行預先定義好的測試步驟。目的同上,為了確認一切符合預期。 優點 準確、一致的執行測試步驟 不會遺漏任一瑣碎的步驟,在被自動化涵蓋的部分,有任何非預期的細微改動都能夠發現。 能大量的重複執行、不間斷的執行 如果一天之內有多次要確認操作行為都和之前一樣的改動,自動測試能穩定的執行,確保一切如常,沒有意外的影響。 相對可靠的結果。 缺點 初期建置的成本非常...