Re: [閒聊] 寫系統的人最無法忍受別人唬弄

[TonyQ (沉默是金。)]

※ 引述《Ting1024 (無)》之銘言：
: → TonyQ:網站都很難反覆測試啦，而且test case也很難寫。             03/31 22:26
: → TonyQ:這是個還有發展空間的領域。                                03/31 22:26
: → derekhsu:T兄，其實這也不見得.                                   03/31 22:30
: → TonyQ:咦，樓上有沒有什麼好妙計。這問題已經苦擾我好幾年了XD      03/31 22:31
: → derekhsu:網銀有驗證碼沒錯，但難道他們沒建測試平台嗎？           03/31 22:31
: → derekhsu:測試平台的驗證碼是可以Pass的                           03/31 22:31
: → derekhsu:網站其實算很容易反覆測試的，因為網站有共同的介面       03/31 22:32
: → derekhsu:不同的程式語言開發的網站，在整合/回歸測試階段          03/31 22:33
: → derekhsu:很多自動化測試工具都能完成網站的測試，甚至AJAX         03/31 22:33
: → derekhsu:但是GUI的東西，就必須要抓到Componment                  03/31 22:34
: → derekhsu:能作到這樣的Tools都還滿貴的就是了                      03/31 22:34

        這是個值得討論的話題，我目前時間不多只能簡單帶一些意見。


        我先帶一些我討論的問題背景

        1.要達到自動化簡測 （純人工檢測不考慮）
        2.網站的內容沒有固定格式
        3.開發者（或者測試團隊）可以參與撰寫 test case


        -------------------------------------------------------------


        GUI甚至是應用程式的邏輯測試，
        其實型別檢測比較嚴謹的狀況下，unit test是比較好寫得。

        以 structs+spring+hibernate 的開發為例，
        測試 orm DAO 的working , 測試 action 的各個可能的結果頁面導向，


        js 也有 js unit可以處理，
        不過因為js牽扯到頁面資訊的效果，測起來並不容易。


        這都是比較不困難的，至少也是我曾經參與的專案有去試著進行過得。



        目前我所看過得網站自動化簡測，其實只有失聯連結檢測，
        再來就是 js unit，還有我剛說的 seleniumhq 可以模擬browser行為，
        透過操作 firefox 來達到行為單元測試。



        那難點在哪，第一就是有驗證碼的頁面會過不去，
        因為他是模擬browser行為，所以比較棘手。


        d大提到一個這個問題的常見解決方案，用測試環境造假訊息，直接讓他pass，
        不過這樣的動作因為跟真實環境比起來是相對失真，

        其實有時候在寫這些虛假訊息的時候也會 miss 掉很多該注意的事情，
        不過相對之下這的確是一個值得去做的方法啦。


        第二就是其實網站的行為很難說成功與否，
        有時候是反應比較慢，有時候效果是複雜多變的，

        有時候是與使用上的習慣不符，而不是內容上的錯誤。
        另外就是 test case 要寫多細的問題。（這所有test類的問題都會碰到。XD）


        我個人是認為 web 的功能太細了，要為他寫 Test有點不划算，
        但是不寫又常常東一包西一包的。


        我目前是比較傾向於設計並重複利用元件，因為反覆經過鍛鍊，
        自然會有比較好的表現，而且錯誤率也會比較下降。


--
其實這一塊真的是很困擾的，所以如果有比較好的作法真的是幫助很大。XD

--
    I am a person, and I am always thinking .
    Thinking in love , Thinking in life ,
    Thinking in why ,  Thinking in worth.
    I can't believe any of what ,
    I am just thinking then thinking ,
    but worst of all , most of mine is thinking not actioning...

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 220.133.218.161
推 Adonisy:推一個
推 derekhsu:所以Web的QA真的是挑戰^^
→ TonyQ:這個問題我已經想很久了，真的是想不到什麼簡單的方法......
→ derekhsu:這就跟QA的功力有關了
→ TonyQ:沒錯，另外我個人是強烈反對自寫自測，盲點太多了。
→ TonyQ:（我指的是正式的QA編制，個人寫完程式的自我測試還是要有。
推 Adonisy:自寫自測只是為了防止低級錯誤... XD
→ TonyQ:我看過有把自寫自測作為防制所有bug的公司.當時建議公司至少
→ TonyQ:請個工讀生來幫忙按按按鈕也好，主管為了節省成本結果自己跳
→ TonyQ:下去測。真不知道該說什麼。
→ TonyQ:不過這就是題外話＋抱怨文了就是了。後續應該不難想像。XD
推 chihyi1980:想不到連這種話題都能扯上一長串..XD
→ sazabijiang:而且就這個討論串的case, 這算是邏輯bug, 不易測出
→ sazabijiang:網銀後端會連結多個不同的主機系統, 溝通橋樑可能是
→ sazabijiang:MQ或者其他介面. 即使訊息都能正確往返, 如果沒有人為
→ sazabijiang:監測, 可能會得到格是正確的錯誤內容...
→ sazabijiang:舉個例子, 網銀一定會連結存款主機, 偏偏存款主機是
→ sazabijiang:被一堆周邊系統連結著, 比方說你寫個透過網銀轉帳的
→ sazabijiang:自動化測試劇本, 但是存款系統是另一個系統, 要先透過
→ sazabijiang:存款系統把錢存進去, 你在網銀才有錢可以轉出....
→ ledia:自動的 web test 工具越來越多, 就算只是比對固定操作抓個
→ ledia:工具用一用也不會花多少時間
推 luciferii:驗證值的部分，常見的不是先人工 Login一次，然後反覆利
→ luciferii:用已抓到的session cookie作後續測試嗎?
推 ledia:差不多, 就是 record and replay, 還可以程式化
推 enthos:http://www.testingfaqs.org/  (t-gui.html)
推 itsfreya:e-ATM就整個交易流程來說，如果能以自動化測試=不合格阿~
→ TonyQ:通常會去做自動化測試的不是「整套流程」.而是各子流程
→ TonyQ:ledia 有keyword嗎 XD
推 ledia:wikipedia for "web testing"  我還用過 M$ vsts 的 webtest
→ TonyQ:ok thanks a lot ^^~
→ xlk:sazabijiang說的問題在unit test能用mock類工具處理的
→ xlk:test case coverage當然是Design by contract符合80/20rule
推 itsfreya:樓樓上，我指的是交易流程。MS曾經來我們公司對某個專案
→ xlk:整合測試的自動化劇本要是涵蓋的功能模組太多時只會是場惡夢
推 itsfreya:技術簡報兼推銷vsts，但是自動化測試能用得很開心
推 itsfreya:表示網站被機器人模擬操弄越的越輕鬆阿...
→ xlk:請問樓上不合格的理由是？有什麼風險嗎？
推 itsfreya:類似e-ATM網站交易驗證的前提，就是只允許"真人"操作阿
推 netburst:沒錯 不然驗證碼早就被
→ xlk:自動化目的在檢驗系統本身，這應該是兩回事吧？確認是否真人
→ xlk:應有其它機制處理，像上述的驗證碼的子系統。
→ xlk:更正：自動化測試目的是取代系統已知行為的手動測試常態工作