iT邦幫忙

2024 iThome 鐵人賽

DAY 4
1
IT 管理

葬送的軟體測試 - 不懂不想做是會出事系列 第 4

2024 Day04 軟體測試的迷思

  • 分享至 

  • xImage
  •  

對於軟體測試, 不少人會有一些錯誤的想法, 認為軟體測試很簡單, 或者是可以找出所有問題. 以下我們就來看看大家常見的誤解是什麼:

1. 我們可以測盡所有東西

假設一個系統大約有 30 個對話盒視窗, 每個對話盒視窗大約有 5-10 個輸入要填, 假設每個輸入可以接受的數值大約1000 個以上, 這樣要測試的組合數

30 x 10 x 1000 = 300000

至少有 30 萬個以上. 但是你也知道, 可以接受的數值有些欄位不只只有 1000 個, 可能是上千萬, 這樣要測的組合數就是天文數字. 以手動測試來說, 幾乎不可能測完.

有些人會說那是不是可以自動化測試呢? 有些可以, 有些可能無法模擬, 有些需要在開發階段就提供這樣的 API. 就算自己人可以提供, 有些是第三方供應商, 你怎麼可能叫他們提供這些介面. 因此測試自動化這條路很難.

就算都是自己人, 也要他們有時間配合. 需知道光是把程式寫完就很了不起, 幾乎不太可能還有留時間來撰寫測試自動化的程式.

2. 軟體有問題是測試人員的錯

對於受測系統如果在發佈後找到問題, 很多開發人員和主管, 會把問題的矛頭指向測試人員. 認為他們失職, 為什麼會有問題沒有找到, 遺漏到客戶端.

這個就好像如果有小偷進來偷東西, 如果警察沒有抓到小偷, 就會責罵警察, 認為責任在警察身上. 可是在當下卻沒有去責怪小偷.

這種狀況應該是思考下次如何避免被偷, 或者是如何比較容易抓到小偷. 在開發時如何讓錯誤不容易發生, 或者是容易被抓到. 花時間去責罵測試人員(非問題製造者), 這並不是對的方向.

https://ithelp.ithome.com.tw/upload/images/20240806/20161809srzRLEtbCu.png
圖 4-1 往往我們把問題二分, 或是抓戰犯

3. 測試技術要求不高, 比程式設計容易

很多人覺得測試人員似乎技術能力不強, 他們才會當測試人員. 事實上不是這樣的, 有些測試人員不擅長寫程式, 但是也是有測試人員是擅長寫程式.

進行測試需要的能力是很多元, 像是安裝測試環境, 建立多元的測試資料, 思考各種出包的場景, 熟悉各式各樣的工具. 此外, 他負責的測試是針對端到端的功能, 會橫跨各個模組, 包含不同開發人員所開發的系統. 所以, 測試人員要求的是廣度.

開發人員主要的工作是把程式寫好, 他要熟悉架構設計和開發工具. 他可能不知道別人開發的是什麼功能, 也可能無法把整個受測系統安裝起來. 所以, 開發人員要求的是深度.

這是不同面向的需求, 無法讓開發人員一下具備測試人員的能力, 但是他還是有機會可以學會.

https://ithelp.ithome.com.tw/upload/images/20240806/201618094fdfQSOj5l.png
圖 4-2 開發人員要求深度, 開發人員要求廣度

4. 程式設計能力好的人, 可能可以更勝任軟體測試

剛剛前面說到, 測試人員要求的是廣度, 要學會不少東西, 這些東西開發人員是可以學會的. 但是有件東西對開發人員來說是個挑戰, 那就是需要改變開發人員的思維. 開發人員必須假設一切都可能出問題.

很多時候, 開發人員都會假設事情不會這樣, 用戶不會那樣操作, 他們不會輸入哪些數值, 系統不可能發生這樣的狀況.... 總之, 開發人員就會覺得一切不可能. 那乾脆覺得不可能有 bug 好了.

所以開發人員如果可以先改變這樣想法, 認為任何事情都可能發生, 任何地方都可能出問題, 只要有這樣的思維, 他們就有機會可以測得很好.

5. 測試沒問題就是沒有 bug 了

當測試人員告訴你測完了, 這是代表什麼意思呢? 很多經理會誤以為這就是沒有 bug了, 一切都沒問題了. 事實上不是這樣的.

測試沒問題或是做完了, 只是說測試人員原先安排的事情已經完成了, 他們有跑的測試場景, 如果有錯已經登記, 並且開發人員也修復了. 但是對於他們沒有遇過的場景, 沒有做過的測試, 他們是不知道是不是會有問題. 所以千萬不要好傻好天真, 認為測過就沒問題.

6. 測試可以 100% 自動化

前面提到有些狀況無法自動檢查, 有些狀況是需要在開發階段就考量, 開立對應的介面才好自動化. 但是還有些場景, 不是事先思考就容易解決的. 例如:

a. 錯誤的需求規格
需求和原先說的不同, 你要如何可以先做好自動化
b. 無預期的硬體錯誤
斷電, 網路線斷, 或者硬碟壞掉, 有些硬體狀況是軟體模擬不出來的
c. 基於語音/情緒/視覺的功能
這些是很主觀的, 很難用程式給出答案
d. 易用性測試
好不好用也同樣主觀的答案, 也是程式給不出答案的

7. 測試自動化可以找到所有問題

如果你寫過程式, 相信你該知道程式會怎樣執行, 這是因為你寫出這樣的程式邏輯.

但是 Bug 呢? Bug 會出現在哪邊呢? 會出現在你沒有想到的地方, 所以你的測試程式是無法事先知道, 然後就去抓到它. 如果事先會知道哪裡有錯, 那就請開發人員去修掉就好, 幹嘛還寫測試程式呢?

所以測試自動化是無法找到所有問題的.

8. 測試可以證明軟體沒有錯誤

測試進行後, 如果有找到 bug, 我們可以很確定地說這個受測軟體是有錯誤的.

但是如果測試之後沒有找到 bug 呢? 可以說受測軟體沒問題嗎?

測試後完找不到問題, 只能說你準備的測試個案沒有問題, 但是對於不在測試個案中的其他場景, 我們不知道是不是沒問題, 因為我們沒有測過.

所以測試整能證明有問題, 但是測試無法證明沒有錯誤.


上一篇
2024 Day03 軟體測試的簡介
系列文
葬送的軟體測試 - 不懂不想做是會出事4
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言