做了5年軟件測試了，寫寫心得

做了5年軟件測試了，寫寫心得

1.測試真的需要嗎？ 如果需要，測試的成就體現在哪裡？
軟件測試：就是代碼質量高，跟你沒關系，代碼質量差，你也看不出來。軟件測試工作效果體現在哪裡是個很大的問題。
所以很多時候軟件測試變得更官僚，精致的報告，各種chart 橫行，動不動就是測試用例 x 測試平台算笛卡爾積。而忽視了測試本身。
我見過一個ksh 腳本居然寫上了read -p ,read -p 是 bash 的用法，而ksh 沒有這樣的用法，沒人願意管這種小問題，到我這裡，我直接改腳本 pass.

2. 軟件測試是怎麼爛掉的。
a.如果老板說6月1號要release， Ok ，那麼下面的人就不會找事，在5月份的時候就不會報太多的defect 了，這樣方便developer , 也方便測試能按時完成任務，畢竟老板的意志最大。大家都心知肚明，到了6月1號該release 一定會release， 解不完的defect 會自動進入下個release 或者以fix pack 的形式發布。

b. 設計測試用例的人都是測試中的領導層，而不是動手跑測試或者需要去實現測試的人，這就給瞎指揮和亂寫測試用例埋下了伏筆。
設計測試用例的人讓領導層覺得這些設計簡直天衣無縫，覆蓋面廣，涉及了大量的穩定性和高並發測試。例如：我見過一個測試用例，要去deploy 一個virtual server, 以10線程，跑10次。要保證100個全部成功，這個測試用例從來沒有100%成功過，但是到了release 的時候，這個測試一定是通過的。作為一個測試人員，如果你的測試用例根本不切實際，那麼你的best interest 就是假裝測測，然後到了時間直接pass. 這種跟“cloud”相關的測試本身就很難，因為deploy 要設計成一個類似於原子操作或者數據庫的transaction 的類型，成功就成功，不成功則意味著要全部回滾。而deploy 一個virtual server 本身是個長流水線。

c. 測試的耦合度：代碼總是說松耦合，而測試上我見過不少人卻都喜歡用緊耦合的方式來做。例如，A做完一個測試用例的byproduct是剛好能給 B的測試設置好環境，這時候就會變成B 依賴於A， 如果A 完不成，B 就什麼都做不了。寫報告的時候這是： A 成了B 的blocking issue ， 領導會追問A 為什麼你block 了這麼長時間，什麼時候能繼續， 而忽視了其實B 什麼都沒有做。這種緊耦合其實就是坑前面的A。

3. 談談人的因素
例如要測數據庫：
那麼java 就是通過JDBC/ODBC 去調sql， 而建庫，建表在linux 上很多時候直接是sql 腳本文件直接用bash -c 去執行。
對於數據庫做備份的時候，Oracle 很多時候是調用RMAN , 而mysql的 mysqldump 足夠做線上和線下的備份。
我接觸到一些軟件測試，只會跑集成的命令，就把數據庫建好了，備份完成了，從來不考慮這些手動做的話怎麼做，只有你知道手動怎麼做，你才了解各種腳本裡面到底都做了些什麼，才可以更好的測試代碼。對於底層細節的了解才是關鍵，就像冰山，只了解水面上的10%那遠遠不夠。

4. 對於搞技術的人來說，blocking issue 一般還是因為你的技術還是不夠強。
當然這句話有點裝逼了。從操作系統來說，Linux 無非是C 和inline 匯編，Glibc 可以用IDA pro 逆向， strace 可以查看系統調用，Java 是我最不熟的。
而perl/python/php 和 各種shell 大都是明文可以直接看代碼。（當然如果只有pyc 的話我也不曉得怎麼辦），從這個角度看，軟件測試要掌握的東西有很多，才能碰到各種問題都能迎刃而解。 其實並不是這樣，人的因素其實最不可控，畢竟每個人的知識面不可能橫跨這裡所有的面，且在每個層次上都達到很高的高度。