最近因為看了一本書 Lessons Learned in Software Testing，其中有一堂課說學習哲學的其中一個分支－知識論，它可以幫助測試的工作，於是就開啟了我關注「哲學」的開關，然後就產生了這篇紀錄。
首先來簡單描述一下知識論，知識論要問的是「你如何評斷這個知識是 100% 正確的」
何謂知識
在知識論中是這樣子論述的，知識是一件被相信且經過證實的事實
- 知識既是真的，又被相信是真的，是交集。圖來自於維基百科
知識並不會因為自己相信就等同於真實 就如同你相信這個系統沒有 bug，並不會因為你的相信而沒有 bug 所有不能稱為「知識」的，只能稱之為「可能的觀點」
橋可不可以過？
有一天小明與小華在散步，散步到了橋的入口，小明有去過並且知道過了橋之後，可以看見名山勝水的風景
小明說「這個橋，可以過」
小華卻說「這個橋，不能過」
在他們講話的過程中，有一群人走了過去，很不幸的，然後橋就斷了
我們可以在這個事件中得知，知識與信仰是不同的。
而小明的相信，是錯的，因為這個橋就是不安全的，如果要讓「橋是否為安全」這件事情成為一個「知識」，那我們就必須得確認「每一次過橋是安全還是不安全」，實際上也不可能完全的「有效」確認的，原因是人類尚無法「測得」宇宙所有不可見粒子(因子)。
故而信仰（英語：Faith）與相信（英語：Believe）不同，信仰是即使普遍經驗顯示是錯的，但憑著信仰與累積的「特殊經驗」或「個人經驗」等「超自然經驗」，卻「繼續相信」下次會轉變為對的，顯示出「偶發狀況」或一連串持續性地「偶發狀況」。自維基百科
知識與測試
我認為產品的知識，以知識的角度來出發理解會是如下圖，通過 測試行為 來驗證 系統實作 是否符合預期，就可以獲得 產品知識
系統實作：紅色（左邊），產品知識：黃色（交集處的圓圈），測試（預言）：藍色（右邊），交集卻不是產品知識的部分定義為：非產品知識
P.S. 我認為，測試這回事是沒有限制的，所以不應該有如圖中的外框限制，但為了方便解釋所以加了外框
但是
在軟體開發的世界中，測試所得出的「產品知識」是會因為 Release 之後讓「系統實作」的不同而導致「產品知識」有「時間性」
意思就是，此時此刻的「產品知識」在下一秒就會因為 Release 而導致變化，所以軟體會有「版本」的差異性，讓每一個「產品知識」有了「版本」的概念，就能夠對齊目前某個版本的產品狀態（雖然仍然不能 100% 確定）
在軟體測試中需要被固定住的「環境因素」非常多，只用圖中的三個名詞其實是不足的，例如：使用者的環境（網路、手機規格、電腦規格等）、資料庫已成載的資料量、伺服器因素（放置位置、雲端還是地端、規格、伺服器系統版本等）、當下伺服器的狀態（CPU 使用率、RAM 使用率、多少人同時在線上等）、程式語言版本等等狀態，都會影響到軟體測試的結果
以下開放舉例
那測試人員該怎麼做？
以橋的那個例子做延伸
測試人員能做的，就是盡自己的職責（廢話w）
在橋搭建起來之前，思考這座橋的相關問題，例如：為何需要搭建這座橋？、沒有這座橋可以用什麼替代方案解決要到對面問題？、我們要用什麼材料做這個橋？、這座橋怎麼樣才算是完成？等等…
- 為何需要搭建這座橋？－理解蓋這座橋的原因，
- 沒有這座橋可以用甚麼替代方案解決要到對面的問題？－或許蓋橋不是唯一的解決方案，有可能會有較低成本的方式解決，甚至發現不需要橋也能方便快速地抵達到對面
- 我們要用什麼材料做這個橋？－這個會決定這座橋的年齡、可乘載人數等等
- 這座橋怎麼樣才算是完成？－決定這座橋的驗收方式，讓其他蓋這座橋的人也知道 DOD （definition of done）
- …
在橋搭建起來之後，測試人員要做的就是去即將被交付的這座橋，做各種可能的「檢查」，螺絲有沒有鎖好、橋的寬度是否與當初設計相符、橋的路面上有沒有坑洞、橋的旁邊是否有圍牆、圍牆是否堅固等
測試人員在盡責的做完各種「檢查」之後，提出詳細的報告，描述著某一個時刻，橋的各種狀態已經檢查完畢沒有問題，而這樣的檢查結果報告出來之後，團隊成員就會有一定的信心，最後才將這座橋交付出來。
ＯＳ：你認為，測試範圍是有限，還是無限的？
以上是我的紀錄，感謝閱讀，歡迎大家一起討論