轉自：https://testerhome.com/topics/9716
雷輝：ThoughtWorks高級質量保證工程師章姓，多年研發(fā)與測試經(jīng)驗灼狰，豐富的大型商業(yè)軟件的測試工作實戰(zhàn)經(jīng)驗进萄，精通自動化已烤、性能和探索式測試，以在軟件中發(fā)現(xiàn)各種隱藏Bug為樂苛坚。
我是TW一名測試人員澈缺，不敢說是老司機坪创，還算資深吧炕婶，因緣際會入了IT姐赡，做得測試這一行。其實按照大學的專業(yè)柠掂，我現(xiàn)在應該是一名杰出的銷售大師项滑，哈哈。然而涯贞，一入IT深似海枪狂，回頭已是中年身。我有多年的Java開發(fā)經(jīng)驗宋渔，后來轉為測試州疾，對開發(fā)和測試都有了解，所以今天打算從測試角度出發(fā)皇拣，為開發(fā)人員照照燈下黑严蓖。
當我們在本機自測時，通常漏測的是什么
完成一個功能卡的簡化流程是這樣的：程序員開發(fā)→自測→QA測試氧急。通常開發(fā)一張卡的工作量為1～3天颗胡，少量卡需要5天左右。從過去的數(shù)據(jù)看吩坝，從開發(fā)接手的卡毒姨，90%以上都有Bug，沒有Bug的卡比較少钉寝，要么是功能特簡單弧呐，不易出錯，要么是開發(fā)經(jīng)驗老道又細心嵌纲。
又年輕俘枫、工作年限又短的工程師們通常漏測的點在哪里呢？
1. 自測過程中沒有跑通所有的分支業(yè)務流程
有時系統(tǒng)需要和第三方的系統(tǒng)進行集成疹瘦，開發(fā)工程師對第三方系統(tǒng)不熟悉崩哩，自測過程中，有不少分支流程沒有執(zhí)行言沐，恰巧就在這里隱藏著很多Bug邓嘹。當系統(tǒng)業(yè)務過于復雜，開發(fā)只熟悉某一部分险胰，在這種情況下自測時汹押，需要放在完整的業(yè)務流程中測試，真實地去使用起便，會碰到意想不到的事情發(fā)生棚贾。我們團隊開發(fā)一個類似Jenkins的持續(xù)集成平臺窖维，最近給構建過程增加了多階段（Stage）構建的功能，用戶可以在每個Stage執(zhí)行不同的任務妙痹。
開發(fā)自測時铸史，通常都會覆蓋主流程，如：
- 多Stage正常構建怯伊；
- 多Stage構建中出現(xiàn)失敗的流程琳轿；
- 多Stage構建過程中被取消構建。
還有更多的流程分支需要測試：
示例1 ： 構建包的使用原則 耿芹。當一個Stage有過一次成功構建崭篡，即便該Stage下一次構建失敗，它之后的Stage仍然可以使用上一個Stage最后一次構建成功的包吧秕。
示例2 ： 特殊流水線 琉闪。系統(tǒng)中有多個流水線，其中發(fā)布流水線與其他流水線實現(xiàn)不同砸彬，需要單獨測試颠毙。
示例3 ： 被忽視的運行方式 。開發(fā)自測時常用手動或者自動模式進行構建拿霉，但系統(tǒng)還提供了定時運行方式吟秩，需要測試定時運行時多Stage是否構建正常。
示例4 ： 修改Stage后對構建的影響 绽淘。刪除或修改某個Stage信息涵防，是否會對構建產(chǎn)生錯誤的影響。此外需要查看在"歷史頁面"模塊沪铭，是否正確顯示對Stage修改的各個歷史版本記錄壮池。
示例5 ： 與其他模塊的關聯(lián) 。只有一個Stage時杀怠，報表可以顯示構建過程中單元測試結果椰憋。變成多個Stage后，如果每個Stage做了不同的單元測試赔退，報表還能正確顯示嗎橙依？
開發(fā)人員自測時候沒有跑通所有的業(yè)務分支流程，主要原因在于企業(yè)開發(fā)都是團隊協(xié)作硕旗，一個小組十多個人窗骑，每人日常工作中，做的功能卡比較散：今天給頁面加滾動條漆枚，明天做XML的解析创译。對功能卡的上下游使用場景難以了解得十分清楚。
這是一個困難點墙基，但換一個思路软族，將來出現(xiàn)了Bug誰來修刷喜？大多數(shù)情況還得自己去修復。到那時還是要去熟悉和了解上下游的使用場景立砸，但修復的成本就會變大很多掖疮。
開發(fā)一個功能時，多花費時間去了解上下游使用的場景仰禽，看似多投入的時間氮墨，可以有效減少Bug的出現(xiàn)，此外吐葵，還可以讓自己更了解整個產(chǎn)品的全景圖，了解每張卡給用戶產(chǎn)生的業(yè)務價值桥氏。因此温峭，認真分析功能卡的上下游場景，對產(chǎn)品質量和個人成長都很有好處字支。
2. 不熟悉用戶真實使用的場景和方式
一個小例子：開發(fā)一個系統(tǒng)對外提供的Web Service服務凤藏，當我們把這個接口的使用場景都分析到，才能做到Bug更少堕伪。
需要測試的場景包括：
- 用戶使用時會輸入錯誤數(shù)據(jù)揖庄，后臺要做校驗。否則把這臟數(shù)據(jù)插入數(shù)據(jù)庫中欠雌，會給系統(tǒng)帶來不可預知的問題蹄梢。
- 使用這個接口的用戶常常需要根據(jù)返回的HTTP Code做下一步操作，我們自己需要驗證返回的HTTP Code是否都用對了場景富俄。別把該返回401Not Found的場景用了500 HTTP ERROR禁炒。
- 接口有在外網(wǎng)使用的場景，需要在HTTP和HTTPS加密的情形下都測試霍比。
- 在外網(wǎng)使用幕袱，黑客會制造特殊的字符來做注入攻擊，系統(tǒng)對這些特殊字符有沒有過濾悠瞬？
- 服務接口會被多個第三方程序調用们豌，線程安全做好了嗎？會不會把A的數(shù)據(jù)插入到B的名下浅妆？
- 服務的響應能力應該怎樣望迎？50個并發(fā)每秒，還是200個并發(fā)每秒狂打？
做每種軟件的測試擂煞，都需要仔細分析其使用場景。
示例1 ：開發(fā)只在Chrome瀏覽器上進行了自測趴乡，而用戶使用的是除此之外的其他瀏覽器对省。瀏覽器兼容性的問題非常多蝗拿。
示例2 ：用戶使用手機軟件時，常因坐姿不同而旋轉屏幕蒿涎。自測時就需要關注屏幕旋轉對界面布局的影響哀托。
示例3 ：自測時只在界面上建了3～5個組件，而用戶可能會新建N個劳秋。在實際使用中發(fā)現(xiàn)仓手，新建組件一旦超過30個頁面，反應就會明顯變慢玻淑，存在性能問題嗽冒。
示例4 ：一個Web Service服務要被用在公網(wǎng)上，卻只在HTTP下進行自測补履，沒有在使用HTTPS加密的場景中進行測試 添坊。
……
3. 對測試數(shù)據(jù)的邊界值選擇不夠充分
大部分的Bug出現(xiàn)在邊界值附近。需要理解業(yè)務邏輯箫锤，理解輸入數(shù)據(jù)的含義贬蛙，來確定邊界值在哪里。
例如谚攒，一個醫(yī)保本允許登記0～10家醫(yī)院阳准，那0個、1馏臭、 9野蝇、10、11這些數(shù)字都是這個功能的邊界值位喂，此外還要隨機挑選1～10中的任一數(shù)字進行測試浪耘。
測試完上面的場景，還要注意的就是：
- 如果這個數(shù)字超過數(shù)字允許的最大最小值范圍塑崖，會出現(xiàn)錯誤嗎七冲？
- 超過Integer允許存儲的字節(jié)長度后，系統(tǒng)會怎么處理规婆？
- 如果超出了數(shù)字的范圍澜躺，使用文本做測試數(shù)據(jù)，后臺有正確處理嗎抒蚜？
- 換成空字符串呢掘鄙，如果這個空字符串又恰巧是NULL這個程序常用關鍵字呢？
除此之外嗡髓，那些特殊字符：引號操漠、星號、問號是否都被正確處理了呢？別小看這些引號浊伙、星號等的處理撞秋，如果沒處理好，可能會拋出HTTP 500 ERROR異常嚣鄙，還可能會暴露后臺代碼異常堆棧吻贿，給黑客提供可循的機會。
對一個英文系統(tǒng)來說哑子，它的文本處理邊界也許是所有的英文字符舅列，這時候可以輸入中文和德文字符，看會不會造成系統(tǒng)問題卧蜓。
4. 開發(fā)的功能屬于頁面的一部分時帐要，需要回歸測試整個頁面
功能開發(fā)過程中，可能會破壞以前的功能烦却。最好快速的對頁面的其他功能做回歸測試宠叼，不能只關心當前完成的部分。
5. 不夠細心
軟件界面上經(jīng)称渚簦看到按鈕布局沒有對齊、位置差幾個像素伸蚯，或者是頁面上的樹形結構展開時摩渺，垂直虛線中間有中斷的現(xiàn)象；或者是字體和系統(tǒng)其他模塊使用的字體有差異等剂邮。這些可以歸到一個字上—— 慌 摇幻。開發(fā)通常會得到UI設計稿，而UI設計稿中對字體挥萌、高度等都有細到像素級別的描述绰姻。頁面元素較多，可能是導致開發(fā)變慌的原因引瀑。
從使用上來說狂芋，把自己當做用戶，就能輕而易舉地發(fā)現(xiàn)這些不細心之處憨栽。 如果是金融和銀行軟件帜矾，出現(xiàn)此類細微錯誤，作為用戶怕是不敢把錢放進去的屑柔。重視細節(jié)才能凸顯專業(yè)屡萤。
6. 開發(fā)軟件前，缺少對同類產(chǎn)品的對比研究掸宛。
經(jīng)過對同類產(chǎn)品的詳細對比分析死陆，我們能快速發(fā)現(xiàn)自己開發(fā)的軟件有哪些不足，以及有哪些可以提升的地方唧瘾。
如何讓測試變得更有趣措译，更高效别凤？
1. 不喜歡用文字描述測試用例，此話沒毛病
我不喜歡寫測試用例瞳遍，工作中也很少寫測試用例闻妓。除非是某個功能業(yè)務比較復雜，需要用文字幫助梳理和記憶思路的時候掠械，才寫一點點測試用例由缆。
測試用例的主要問題在于，用文字描述各種邏輯分支猾蒂、界面均唉，使用的文字量大，還容易變身老版本肚菠，需要維護舔箭。好一點的方式是用BDD（我用的是Cucumber+Selenium+Java）去描述測試用例，然后用后臺的自動化代碼去把測試用例自動化起來蚊逢，這樣就不容易變成老版本了层扶。
2. 喜歡探索性的測試過程
探索性測試第一步，先選擇最簡單的Happy Path烙荷，看系統(tǒng)反饋的直觀感受镜会。這個過程中，我注意到界面上的下拉選擇框不是通用的HTML控件终抽，如果是自定義的戳表，這時就要擔心自定義控件的JavaScript代碼是否都能正常工作。
第二步昼伴，用這個下拉框選擇一個最簡單的選項匾旭，看選擇過程是否流暢（如果不流暢，先記上一筆圃郊，可能是JavaScript代碼中存在性能問題价涝，待功能測試完成后，再回頭看這里的性能）描沟。此外飒泻，檢查選中后移除選擇項的刪除等按鈕是否正常。最基本的功能測試完了吏廉，再選擇多個選項泞遗，用特殊的數(shù)據(jù)測試。
如果這個控件所在的頁面席覆，有其他HTML控件史辙，當從別的頁面跳轉到這個頁面時，有的控件的值沒有預填寫，就要測測這個自定義的控件聊倔，在同樣流程中晦毙，能否把值預填寫成功。
最后耙蔑，界面上這個控件寬度被固定见妒，就要考慮如果選擇項值是一個150個字符的合法數(shù)據(jù)，會怎么顯示甸陌。頁面布局是否會被破壞须揣？
就這樣，一步一走钱豁，通過系統(tǒng)的反饋耻卡，點燃新的測試思路，并一步步執(zhí)行測試牲尺。
在探索性測試過程中卵酪，最重要的是：測試人員要有能力根據(jù)系統(tǒng)給出的反饋，想出更多的測試路徑去驗證谤碳，或者有選擇地去重點測試某一個部分溃卡。
這種能力是建立在大量的IT認知上的，IT知識越豐富蜒简，被系統(tǒng)激發(fā)出的思路就越多塑煎。這就好比，讓一個不了解玉石的人去檢驗一塊玉石的真?zhèn)我粯映粢希挥芯邆湄S富的玉石知識后，才能練就一雙火眼金睛來讯赏。
3. 足夠了解后臺的實現(xiàn)原理
當我們足夠了解一個東西時垮兑，我們才更清楚它的薄弱環(huán)節(jié)在哪兒。做過很多開發(fā)工作漱挎，有很多開發(fā)經(jīng)驗的人系枪，拿到一個軟件，差不多就知道這個軟件的實現(xiàn)過程磕谅，以及該軟件可能出現(xiàn)問題的位置私爷。
示例1 ：一個測試Web服務返回HTTP Code的功能卡，因為返回值計算過程簡單膊夹，出錯概率不大衬浑。但由于返回有十多種值，需要寫很多分支放刨，這種情況程序員往往會漏測一兩個分支。
示例2 ：知道JSON數(shù)據(jù)的格式，就應聯(lián)想到把大括號乖菱、中括號等作為數(shù)據(jù)的一部分進行測試。
示例3 ：有緩存機制浪听，在性能測試時不用同一個關鍵字進行壓力測試，而要改變關鍵字眉菱。
示例4 ： 如果單元測試用了Mock機制迹栓，要清楚Mock往往在系統(tǒng)交接處漏測Bug，需要另外進行端到端的完整流程測試才行俭缓。這就要求我們熟知Mock的使用原理克伊。
示例5 ： 自定義的HTML組件，需要寫大量的JavaScript代碼尔崔，這里容易出錯答毫，需要著重測試，而通用的HMTL組件的測試就不用花費過多精力季春。
示例6 ： 了解測試環(huán)境的差異洗搂，比如后臺部署多臺服務器會帶來Session復制分發(fā)的問題，這就需要在多臺服務器的測試環(huán)境中载弄，測試Session復制分發(fā)是否正常耘拇。
4. 善用各種測試工具
示例 ：測試發(fā)送郵件時，需要驗證多種郵件客戶端接收后的界面排版是否正常宇攻。有這樣的工具可以幫助我們只發(fā)一封郵件惫叛，它給你顯示出各種郵件客戶端的排版。但是也不能全信它們逞刷，使用前最好自己做抽樣檢查嘉涌，看看這個工具是否真如它所說的那樣好用。
- Charles可以改變發(fā)送數(shù)據(jù)包的內容夸浅，幫助我們達到快速測試目的仑最。
- 頁面加載的性能測試，使用當?shù)氐姆掌髟L問帆喇，自動求多次請求后的平均值的工具也能幫我們節(jié)省很多時間警医。
- 優(yōu)選測試工具，可以讓測試工作事半功倍坯钦。
5. 關注整個開發(fā)流程预皇，有效減少Bug出現(xiàn)
① 在程序員開發(fā)一張卡時，首先大家會坐在一起婉刀，包括QA吟温、BA、DEV路星、UI等溯街，討論這張卡的接收條件诱桂，避免一開始寫代碼就走偏的情況。
② 開發(fā)完成后呈昔，會在本機給QA演示功能挥等，QA給出反饋，減少Bug出現(xiàn)在部署環(huán)境后才被發(fā)現(xiàn)的可能堤尾。
③ 小組的Code Review可以幫助QA減少測試工作肝劲，Code Review能及早發(fā)現(xiàn)代碼的潛在問題。
關注單元測試覆蓋率郭宝。單元測試覆蓋率不高辞槐，QA的工作會越做越累，每次新加的代碼都可能破壞之前的功能粘室。
此外榄檬，還需要關注UI自動化的運行情況，它可以彌補單元測試沒有覆蓋到的地方衔统。
6. 對于重復的手工測試鹿榜，盡量自動化它
自動化的方式包括：
- 單元測試；
- UI自動化測試（需要考慮如何寫出高可復用的代碼）锦爵；
- 接口自動化（例如使用Jmeter的BeanShell生成數(shù)據(jù)舱殿、從CSV或者數(shù)據(jù)庫中讀取數(shù)據(jù)、進行斷言等）险掀；
- 自己寫程序生成測試數(shù)據(jù)等沪袭。
以上是我的一些拙見，以作引玉之磚樟氢，歡迎大家補充和探討：bug_big_bang_in_web_testing@outlook.com冈绊。
本以為日子就在找地鼠和打地鼠的日子中流逝，直到有一天埠啃，黃勇問我焚碌，要不要一起寫書，寫關于測試的書霸妹。于是有了這本《測試囧事》，也希望本書為大家的開發(fā)和測試之路點亮了一排路燈知押。
