---
# System prepended metadata

title: 0709_discussion

---

---

title: 0709_discussion
image: https://i3.read01.com/SIG=1n8sj6l/304f70713475676f4759.jpg

---


### 絕地救援
馬鈴薯問題

瑞士起司理論？但是沒有這個很多電影都沒辦法拍




### Mindset Ch5、7

- 接近比拿到更加好
    接近有種讓人繼續努力的感覺，拿到就只在乎成功這件事


---

### 測試

- 測試是追求正確的過程，方法的選擇仰賴資源

- 測試就是開發的一環


- 測試金字塔
![](https://i.imgur.com/LGYCDsr.png)


<!--
[https://img2018.cnblogs.com/blog/1870085/201912/1870085-20191228085704307-1745427310.png](https://img2018.cnblogs.com/blog/1870085/201912/1870085-20191228085704307-1745427310.png)
-->

盡可能接近使用者環境 (才能真正測到使用者會遇到的問題)

production, user, testing 環境

unit test, 

盡可能衝高 coverage 但不會刻意撐高

重要、異動的 

不容易去測的，可以投注其他的

靠經驗累積 衡量需不需要去做

什麼東西絕對不能調，什麼東西其實可以不用測試

微軟 / google (?) 説 我對我們家程式碼有信心 到 我完全不用測試

為何要測試

→ 成本 (降低) [把人工、很重複的部分交給測試來做]

人工 → 自動化

測試是追求正確性的過程，確保程式碼是對的

至於用什麼方法，方法的選擇全部都是要仰賴資源 (區分我要選擇哪一條路)

當你有很多人力可以測試的時候

很難抉擇 (因為資源很多，切分誰做什麼 [是一個主管很好的示範])

資源是一個非常大的條件 不要浪費人力資源在瑣碎事情上 

(例如：音質, 機器可以嗎？)

很有趣的形容：

- auto... 他是一種工程
- 手動測試... 有點像手工藝品, 音質的調整的話 不能完完全全被機器取代

etinagration 

伺服器拉音檔 ＋ 測試 → 使用者接收

面試member：

- 每個職位都會問一個問題：品質是誰負責的
- 這個你可以幫我測一下嗎 （結果一開就crash)
- 身為一個開發者，在開發的過程中，發現自己有一個很棒的測試團隊可以去測試他，你真的可以不用在意這個品質嗎。
- Quailty sense,
- 可能會被既有觀念影響，自己之前也是這樣寫，一定不會有錯，趕快交付他就可以做下一件事情
- 因為時程壓力、不可抗力的因素 而...突然忘記這件事 (keep著 quailty)


很會不花成本去解決這件事情

