Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> Android開發 >> 關於android開發 >> 做了5年軟件測試了,寫寫心得

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

編輯:關於android開發

做了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 的話我也不曉得怎麼辦),從這個角度看,軟件測試要掌握的東西有很多,才能碰到各種問題都能迎刃而解。 其實並不是這樣,人的因素其實最不可控,畢竟每個人的知識面不可能橫跨這裡所有的面,且在每個層次上都達到很高的高度。


  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved