Re: [閒聊] 工作職務內容分享 - 韌體測試
補充一點....
※ 引述《littlebau (小寶)》之銘言：
: 測試工具:
: 韌體的測試工具通常都是直接對韌體溝通，因此通常都會有個Interface
: 這個interface通常會是標準公規的，或者是特殊設計的(公司機密的部分)
: 因此瞭解這個interface會是第一步。所有的tool都會base on 這部分。
: 透過這個interface，你會跟韌體溝通，要韌體做事，或得到資訊。
: 通常tool都是C語言做的，接下來要瞭解的是韌體可以做的到哪些事情
這其實不一定，有些情況會用light weight language去寫，因為速度快，
而且工具本身簡單，容易驗證。
如果要用很複雜的語言或是架構寫測試工具，那光是測試工具本身的bug
都解不完了，要怎麼去測產品的bug ?
: 他支援哪些功能，你要像操控機器人一樣，去操它，去叫它做事，
: 而很多測試的idea，則是軟韌共通的。 差別在於你要k很多這個韌體所支援的功能.
: 這些功能的意義 = 很多技術規格 + datasheet (那些存取的欄位代表什麼意義)
: 測試計畫:
: 當新功能出現的時候，你除了要更新tool讓他能夠去操控韌體去做新的動作。
: 也代表了新的測試計畫的文件需要產生。你必須從各個面向去產生一個測試計畫。
: 一個好的公司，是會review你的測試計畫的。你的測試計畫需要被team的人肯定沒有遺漏
這個很重要，很多沒有經驗的測試人員會"隨心所欲"，這樣測試出來的結果根本沒有
公信力，因為太多環節沒有考慮到，太多可能存在的問題沒有被發覺。
: Bug Report:
: 如何寫好一個Bug report是很重要的，一個有價值的Bug Report可以讓問題很快被複製
: 很快找到原因然後被解決，而且好的問題描述，可以讓meeting時更快瞭解這個問題點。
: 減少會議時間。
: 測試行程:
: EX：哪些測試需要在那個階段被完成，哪些需要被重複測試。
: 複製問題:
: 如何快速的複製問題，這是很重要的。除了複製問題，還要減少複製問題所需的時間。
: 別人要讓機器跑24小時才能複製一個問題，你若能1小時複製一個問題。那是value!
: 你若能縮小問題的範圍，這也是value。
: 改善測試計畫，除了以後這個問題可以被測試出來，cover其他有可能的部分。這是value
: 專利:
: 你往往可以想到RD想不到的，因為你是站在使用者角度去想的。
這一點很重要，應該說當局者迷吧，RD有時候會過度從設計面的角度去看產品，而忽略了
從使用者 "合理" 的角度來思考。另外，許多RD必須要非常深入瞭解架構，導致了他們
對於橫向連結的理解不夠。例如說 firewall 跟 WebGUI是由兩個人來做的，可能是介面
定好，就由兩個人分頭進行。兩個部份單獨來看是完美無誤，但是整合在一起後，很可能
會出現很多的問題。這要依靠站在比較宏觀角度的測試人員才能夠發覺。
: 結尾:
: 用RD的語言，去幫助他們解決問題，有時候你甚至會比RD還更瞭解他們的設計。
RD的工作，是依照設計，把他們心中的想法實做寫成程式來執行。
一個好的程式，他的行為會跟程式設計師的想法一致。
一個正確的程式，他的行為會跟設計一致。
但是一個正確的程式未必是一個好的程式。
作為一個測試人員，必須要很清楚"設計"是如何，然後才能知道這是否是一個正確的程式
。
很多時候，程式設計師的邏輯是有瑕疵的，測試的目的之一在找出這些邏輯的錯誤。或許
曾經當過程式設計師，更能瞭解哪些地方可能會存在問題。
: 因為一些菜RD只會build code 跟 debug他們正在看的問題。
: 韌體測試不是人人做的來，因為願意做測試的人，就是不喜歡當RD。
: 而韌體測試本身又是比較偏向RD的。可以說是半個RD。
: 很多老外在做韌體測試，他上一個工作就是RD。
: 一半RD + 一半測試上的管理 =就是韌體測試的本質。
: 而韌體測試就是活在韌體裡面。一個不是很friendly的環境。面對機器居多。
: 但比起韌體RD至少是走出機器，跟人群接觸了。不知道怎麼說，就是這種感覺。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.169.173.98
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 3 篇)：