隔行如隔山,因此來分享一下職務上的內容,讓有興趣的人,能夠知道工作內容.
拋磚引玉吧,有興趣分享其它職務的朋友,歡迎用類似的標題，回應這文章.
這會是一串對正在選擇各式各樣工作的人來說有幫助的文章。
鑒於PTT是個開放的環境,關於敏感的部分,無法在版上回應.

工作職務: 伺服器韌體測試工程師
工作年資: 六年
所需背景: 電子 資工 資訊相關科系
年薪: 我認為以一個工作5年~10年 年薪範圍約70-150萬, 一般平均約 80萬~90萬。
轉職職務:測試部門主管,SW PM, Project leader, FAE ,
Sales,行銷部門,其他各種測試單位,
工作內容:
韌體是什麼? 請google. 基本上電子產品都有韌體 (電視,手機,電腦,網路設備..etc)
工作就是要確保，伺服器上某韌體能夠在產品賣給老王的時候能夠一切正常。
韌體何其多，小弟曾經是韌體RD，曾經是測試BIOS工程師，也測試過Storage的韌體。

===在台商===

在小弟以前的公司，客戶會給測試計畫，而我們就是執行測試計畫的人。
舉例來說，請用快速開機關機10次。這就是一個測試。
而測試計畫可能有1000種測試。請在一個月內完成測試。

每天上班的固定工作

1.打開mail，看有沒有臨時交辦的事情
2.準備測試所需要的環境
3.開始測試
4.測試發生有問題的時候,根據自己的知識跟手邊的文件,判斷是不是問題
把問題透過資料庫回報給RD. 追蹤這問題解決的狀況.
必要的時候，提供更完整的資訊去讓RD複製問題，參與會議.
5.測試報告送出
6.下班

在比較資深的時候，有可能會需要協助撰寫測試計畫，極少數的狀況需要協助寫測試程式
如何讓測試能夠更順利的進行,考驗著你的專業跟事情上的處理能力。
(機台不正常，自己操作導致的問題,問題複製不出來,測試步驟有問題..etc)
在資深的狀況，可能還得帶新人。
新功能出現，要學習如何架設測試環境。

以上是大部分測試做的事情。 但是測試的目標有很多 硬體測試 撞擊測試 軟體測試
硬體測試 溫度測試 韌體測試...等等，依照產品的複雜度測試部門有的很多 有的很少
而我share的測試職位是做韌體測試。

韌體測試，需要的知識，需要知道韌體是如何運作的。
新的功能出來的時候，需要知道他背後的運作知識。
這方面會有一些業界標準的規範，跟自己公司內部自己開發的特殊功能，有自訂的規範。
熟練這些知識，是必要的。韌體並不是個友善的對象。
比如說，你要熟悉很多種規範，可以說有一堆討人厭的技術規格書
這會是入行或更進一步時的痛。
舉個簡單的技術規格的例子 : PCI
http://zh.wikipedia.org/wiki/PCI


===在某些外商===
測試工程師本身則是比較像是PM跟測試工程師的綜合體。
因為台灣有很多代工，實際執行測試的人，落在這些代工廠商身上。
工作變成是如何遙控這些代工廠還有跟公司內部的人合作
來讓你負責的部分能夠在出貨的時候品質是好的。

1.早上一來看mail,看代工廠 (ex:X海)的測試報告,還有一些臨時的事情.
2.參與bug review的會議,協助代工廠有更好的測試覆蓋率,或協助外部內部RD解決bug
3.縮小bug的範圍。
4.透過部門政策，時時掌握產品測試的狀況(比如review 哪部分測試是比較薄弱)
5.協助撰寫測試計畫 協助撰寫測試工具 (這部分看老板的分配)
你可以是專門管案子的,或專門寫測試計畫,或專門寫測試工具,還是每樣都做一點.
大部分在台灣都是專門管案子相對多。當然做越多績效越好。
6.只要你能保證這個東西有被測試好，責任制，沒事就下班了。

固定工作以外的事情就是自己增進產品知識，寫專利(如果你有idea)。
隔行如隔山，軟體測試離韌體測試可以說是差異很大。

==========依推文要求增加一些深入的描述==============

因為怕一些敏感的機密洩漏. 所以只能用比較一般的說法。而不能用實際的例子。
如果你有什麼想知道的，而我可以Share的，我可以盡量。

測試工具:
韌體的測試工具通常都是直接對韌體溝通，因此通常都會有個Interface
這個interface通常會是標準公規的，或者是特殊設計的(公司機密的部分)
因此瞭解這個interface會是第一步。所有的tool都會base on 這部分。
透過這個interface，你會跟韌體溝通，要韌體做事，或得到資訊。
通常tool都是C語言做的，接下來要瞭解的是韌體可以做的到哪些事情
他支援哪些功能，你要像操控機器人一樣，去操它，去叫它做事，
而很多測試的idea，則是軟韌共通的。 差別在於你要k很多這個韌體所支援的功能.
這些功能的意義 = 很多技術規格 + datasheet (那些存取的欄位代表什麼意義)

測試計畫:
當新功能出現的時候，你除了要更新tool讓他能夠去操控韌體去做新的動作。
也代表了新的測試計畫的文件需要產生。你必須從各個面向去產生一個測試計畫。
一個好的公司，是會review你的測試計畫的。你的測試計畫需要被team的人肯定沒有遺漏

Bug Report:
如何寫好一個Bug report是很重要的，一個有價值的Bug Report可以讓問題很快被複製
很快找到原因然後被解決，而且好的問題描述，可以讓meeting時更快瞭解這個問題點。
減少會議時間。

測試行程:
EX：哪些測試需要在那個階段被完成，哪些需要被重複測試。

複製問題:
如何快速的複製問題，這是很重要的。除了複製問題，還要減少複製問題所需的時間。
別人要讓機器跑24小時才能複製一個問題，你若能1小時複製一個問題。那是value!
你若能縮小問題的範圍，這也是value。
改善測試計畫，除了以後這個問題可以被測試出來，cover其他有可能的部分。這是value

專利:
你往往可以想到RD想不到的，因為你是站在使用者角度去想的。

結尾:
用RD的語言，去幫助他們解決問題，有時候你甚至會比RD還更瞭解他們的設計。
因為一些菜RD只會build code 跟 debug他們正在看的問題。

韌體測試不是人人做的來，因為願意做測試的人，就是不喜歡當RD。
而韌體測試本身又是比較偏向RD的。可以說是半個RD。
很多老外在做韌體測試，他上一個工作就是RD。

一半RD + 一半測試上的管理 =就是韌體測試的本質。
而韌體測試就是活在韌體裡面。一個不是很friendly的環境。面對機器居多。
但比起韌體RD至少是走出機器，跟人群接觸了。不知道怎麼說，就是這種感覺。

題外話:
離開技術，才能得到技術以外的東西。這句話某種程度讓我放心的去做我想做的事情。
而不是死守在RD這塊。我的老板，做過RD，做過行銷，做過PM，做過測試。
他也鼓勵我做想做的事情。也跟我說公司可以提供我做這些事情的機會。
工作30年，要維持30年的熱情不容易，要找到一個願意讓你發揮熱情的地方也不容易。

轉錄文章，需經本人同意，謝謝。
自然是囉,有做過的人自然比較了解.
寫測試工具的測試工程師也會懂程式面. 在韌體的世界,背後代表的就是一堆spec.
不論你要寫測試程式或韌體都要熟悉這些spec.

但只要你有寫程式的概念 + 你熟讀spec + 跟RD用RD的技術語言溝通清楚設計的內容
你不用寫程式,你依然可以紙上談兵.
不一定真的需要去寫程式 或 去做RD才能理解韌體本身的.

能夠紙上談兵 或 真的要自己做過才能懂 這是看個人資質的.
有些人就是很容易可以紙上談兵 還講的條條有理.
有些人一定要做過,才講的出一個脈絡.

※ 編輯: littlebau 來自: 123.0.194.12 (04/21 13:24)