成為一名軟體測試工程師必備的技能，除了技術還需天賦。。。
阿新 • • 發佈：2018-12-30
通用技能上：
1.基本計算機知識（作業系統，資料庫，通訊協議原理，熟悉至少一門程式語言）
2.基本軟體測試知識（各種測試理論，測試方法論，測試用例編寫，缺陷界定標準，軟體質量評估）
3.簡單專案管理知識
產品、系統認知：
1.熟悉所測產品功能，能夠將產品文件內描述的UC轉化成TC，這個最最基本
2.熟悉所測產品的一些隱藏需求或者功能（業務上的進階能力）
打個比方，支付公司上一種新的支付渠道，熟悉業務的測試人員應當可以預見到這次升級可能會對前段介面、系統賬務、各類報表等各個模組造成影響，從而一併納入測試範疇。
要知道，很多時候，即便是接入這些渠道的產品經理，也不一定會在Prd或者UC中對這些可見影響項一一列出，這需要經驗和責任心。
性格上：
1.有牛皮糖屬性的為佳，越“不要臉”越好
測試工程師，在很多公司，和研發是有業務上對立屬性的（雖然從巨集觀角度上來說，都是為了提高軟體質量服務）。測試工程師提交的BUG越多，意味著研發工程師工作質量越差，需要返工的工作量也越大，甚至會影響績效，所以測試工程師有時候很容易得罪研發部門。
一個可以相對堅持原則（比如3級BUG以上一定要改），又能拉下臉和不愉快的研發工程師保持較好關係的測試工程師，會對專案質量起到很關鍵作用。說到底，又能做事（發現BUG並督促修改），又會做人（該進的不讓，該退的絕對給面子，最大化消除部門間矛盾）的測試工程師，是十分難得的。
2.有異想天開屬性的為佳
這個只可意會，不好言傳的。在我帶過的團隊裡，的確有那種奇葩……經常會用令人匪夷所思的方式找出BUG，這是天賦。
3.會“偷懶”的為佳
這裡的偷懶不是指上班發微博聊天混日子，而是能夠利用已知資源對枯燥乏味的測試工作進行優化的同學。
說個例項：
我以前公司曾經上過一個“授信”專案，做過金融類專案的同學大家都知道。授信專案的測試用例真可以說是相當變態，隨著賬期、滯納金率、手續費率、利息率、本金、還款情況的不同，可以衍生出無比多的用例，同時每個用例進行編寫時，都要仔細根據規則計算預期結果的資金狀況，非常費力。
咱部門一個小夥子，頭一天晚上拿了PRD，第二天晚上就利用Excel寫了一個固定某些賬期下不同情況下的各項資金計算工具(有一些小BUG，無傷大雅)……大大減少了兄弟們按計算器的工作時間。這種“懶”員工，你是領導你喜歡不？
事情沒完，在實際測試的過程中，我們發現一旦研發修改了BUG，會引發其他用例的大崩潰（這類專案真悲劇，牽一髮動全身），每次版本升級我們都不得不進行全面的迴歸測試。
太坑爹了，這不是要命麼？
聰明的測試同事們又想偷懶了，他們在資料庫端寫了一個數據匹配工具，每次新跑用例就拿正確的（已儲存）資料檔案自動去比對新產生的檔案，自動返回比對結果。兄弟們再也不用每次迴歸都一行行打SQL去查資料了，棒極了。
在研發修改BUG之餘，他們自己寫了一套儲存過程，可以實現資料的自動迴歸和增量備份，再也不用每次把所有資料擦光從第一個交易日跑起了，棒極了！
1.基本計算機知識（作業系統，資料庫，通訊協議原理，熟悉至少一門程式語言）
2.基本軟體測試知識（各種測試理論，測試方法論，測試用例編寫，缺陷界定標準，軟體質量評估）
3.簡單專案管理知識
產品、系統認知：
1.熟悉所測產品功能，能夠將產品文件內描述的UC轉化成TC，這個最最基本
2.熟悉所測產品的一些隱藏需求或者功能（業務上的進階能力）
打個比方，支付公司上一種新的支付渠道，熟悉業務的測試人員應當可以預見到這次升級可能會對前段介面、系統賬務、各類報表等各個模組造成影響，從而一併納入測試範疇。
要知道，很多時候，即便是接入這些渠道的產品經理，也不一定會在Prd或者UC中對這些可見影響項一一列出，這需要經驗和責任心。
性格上：
1.有牛皮糖屬性的為佳，越“不要臉”越好
測試工程師，在很多公司，和研發是有業務上對立屬性的（雖然從巨集觀角度上來說，都是為了提高軟體質量服務）。測試工程師提交的BUG越多，意味著研發工程師工作質量越差，需要返工的工作量也越大，甚至會影響績效，所以測試工程師有時候很容易得罪研發部門。
一個可以相對堅持原則（比如3級BUG以上一定要改），又能拉下臉和不愉快的研發工程師保持較好關係的測試工程師，會對專案質量起到很關鍵作用。說到底，又能做事（發現BUG並督促修改），又會做人（該進的不讓，該退的絕對給面子，最大化消除部門間矛盾）的測試工程師，是十分難得的。
2.有異想天開屬性的為佳
這個只可意會，不好言傳的。在我帶過的團隊裡，的確有那種奇葩……經常會用令人匪夷所思的方式找出BUG，這是天賦。
3.會“偷懶”的為佳
這裡的偷懶不是指上班發微博聊天混日子，而是能夠利用已知資源對枯燥乏味的測試工作進行優化的同學。
說個例項：
我以前公司曾經上過一個“授信”專案，做過金融類專案的同學大家都知道。授信專案的測試用例真可以說是相當變態，隨著賬期、滯納金率、手續費率、利息率、本金、還款情況的不同，可以衍生出無比多的用例，同時每個用例進行編寫時，都要仔細根據規則計算預期結果的資金狀況，非常費力。
咱部門一個小夥子，頭一天晚上拿了PRD，第二天晚上就利用Excel寫了一個固定某些賬期下不同情況下的各項資金計算工具(有一些小BUG，無傷大雅)……大大減少了兄弟們按計算器的工作時間。這種“懶”員工，你是領導你喜歡不？
事情沒完，在實際測試的過程中，我們發現一旦研發修改了BUG，會引發其他用例的大崩潰（這類專案真悲劇，牽一髮動全身），每次版本升級我們都不得不進行全面的迴歸測試。
太坑爹了，這不是要命麼？
聰明的測試同事們又想偷懶了，他們在資料庫端寫了一個數據匹配工具，每次新跑用例就拿正確的（已儲存）資料檔案自動去比對新產生的檔案，自動返回比對結果。兄弟們再也不用每次迴歸都一行行打SQL去查資料了，棒極了。
在研發修改BUG之餘，他們自己寫了一套儲存過程，可以實現資料的自動迴歸和增量備份，再也不用每次把所有資料擦光從第一個交易日跑起了，棒極了！