純技術角度看自動化測試的誤區 自動化測試工具
主動化的最終宗旨是什么?
很多人認為是像工業反動一樣毀滅手工休息者，在這里等于手工測試人員。但是測試存在一個目前來看還算正確的、其余行業不多見的悖論：任何時分，你都不能準 確曉得還有多少bug，就像警察不能正確曉得還有多少賊一樣。所以主動化的最終宗旨——目前來說——是束縛盡量多的人手去進行更多的測試，除非有一種手腕 能像《多數派報告》外面的預言少女一樣預知一切的bug。由于永遠有bug，有未知的bug，所以目前不存在能掩蓋一切bug的手腕，這意味著總須要人的 參加�，F代化手腕只是增加了而不是根相對人員的需求。所以假如認為主動化任務一做完就沒活干，那你就大錯特錯了。正認為這些人閑下來，他們有空發明更難發 現的bug。這本來沒什么大不了的，但是擱在規劃階段假如過火悲觀，牛皮吹得太大的話，到前面就不輕易圓回去了。由于按上面剖析，主動化測試總有些中央是 力有不逮的，假如這些中央沒有支配壞人手時光，只要在這些中央出大問題，那你就玩完了。
是否÷怎么主動驗證?
這個問題每次復審測試規劃的時分我都會問，針對每一個提出要實行主動化的中央。每個人、每個工具議論主動化的時分都在說如何實在模仿用戶運用產品的狀況， 這很好，相對須要關切。不過我得問一句：測試的最后后果是什么?假如你答復“各種運用產品的場景已經運行過“就嘎但是止的話，你就漏掉了一大塊：最最少還 得加上“產品能任務÷不能任務“!所以模仿用戶運用產品的各種狀況，只是處理上述問題的第一局部;如何得出測試通過÷不通過的最終論斷，才是處理問題第二 局部的基本局部，還有具體缺點描寫、高低文數據搜集等沒做到呢!
所以讓機器像人一樣運用產品，并沒有處理全部問題，剩下的事件還有多少，這是須要視狀況而定的。假如只是處理了第一個問題就認為高枕無憂，那幾乎就是在賭運氣——有些時分主動驗證是小菜一碟，但很多時分不是。
令事件好轉的是，主動驗證了產品的一些指標，并不能反應產品的真本質量。有時驗證過的指標通過了，其實其余中央裸露了問題卻沒有檢討：比方說界面說沒有查 詢后果，這是希冀的，實踐上查問請求基本沒有發過來，不去檢討底下做了什么的話是發明不了這種bug的;有時驗證過的指標不通過，其實只是個小問題，大問 題須要通過別的指標裸露進去的：比方說返回后果跟預期的不一致，實踐上該有的都有，只是沒有排好次序而已，但是被標志成主要的測試用例沒有通過，把開發人員搞個雞飛狗跳。
這個話題深刻上來，那就觸及到白箱測試戰略、邏輯推演、嗅探和代碼注入以及布景捏造(environment mockup)等范疇，但我想強調的只是，假如斟酌主動化測試，主動驗證相對不是可疏忽的問題。
整合現有還是自給自足?
這個話題用于爭辯賽是最好不過的，它契合“沒有定論“這個請求 。所以我只談一下運用每種手腕時的一些不正確的假如。
“現有的工具多少經過測試，質量比本人做的更有保障“。先不在“是不是更有保障”這個話題上鉆牛角尖，咱們先關注幾個問題：全部測試規劃外面哪些局部是關 鍵，質量不好會招致致命后果的?這些局部有專人保障質量嗎?出事的時分反應時光和修復后果如何?假如這些問題的答案是“我充足理解”或許“沒問題”，那我 也贊同這個觀念(我敢打賭，答復“不清晰”或許“很不妙”的人已經跑去從新斟酌全部測試規劃了)。
“整合現有的工具省時光和人力”。相似的幾個問題：你能在這些工具中自在地調試產品的缺點嗎?整合規劃能適應產品的演化嗎?幾個月后呢?幾個版本后呢?有須要變化的話代價多少?(嘩啦啦又跑掉一大隊人了)
“自給自足好掌握”。投入產出比方何?引用的技巧牢靠嗎?假如你是開發者(之一)，他人都認為好掌握嗎?誰來測試你的自給自足后果?
“有些事件必需得自給自足“。剪裁現有工具難度如何?時光許可嗎?
其實，縱觀一切提出的問題，我想強調的一點是，主動化測試的開發跟產品開發一樣，也是須要規劃和治理的，答復這些問題也是主動化測試名目治理的一局部。
如何處理歷史遺留問題?
折騰上個版本的主動化測試框架是新人最頭疼的事件。但理解了一些事件之后，本來的事件就沒那么令人頭疼了。很多人忙于理解舊框架自身，其實世界始終在變，如今名目須要處理的問題才是癥結。無論上個版本的貨色如許光輝，只要它適宜如今的名目(的局部)才是有價值的。所以對于舊的主動化測試技巧，理解什么能用得上，而不是理解它是什么，才是須要做的事件。就似乎汽車修理工曉得怎么拆舊車零件來修新車，并不須要他曉得怎么造一輛進去或許曉得怎么修好舊的那輛。
另一個極其是“舊的不好糟蹋，繼承用“�！澳苡谩斑@個論斷是基于以前名目標狀況的，如今能不能用，值不值得用得看如今的需求。人們要理發就是個很好的例子：總不能由于頭發長進去要耗營養不好糟蹋，就一輩子都不剪吧?
文章來源于領測軟件測試網 http://www.kjueaiud.com/