轉(zhuǎn)自：https://testerhome.com/topics/12551

有時候覺得可能自己為了自動化而自動化忽略了基礎或者盲目追求編碼粉怕，在測試的路上走偏了驾诈，但現(xiàn)在測試生態(tài)圈要的不就是這樣嗎陋桂？

前提是先做好功能廉油，再去做自動化，再去做其他。

天下測試这敬，唯用例設計不破，唯缺陷報告不破＝抖洹４尥俊！

回歸測試的初心和本質(zhì)始衅。

不論你是什么時候開始接觸測試這個行業(yè)的冷蚂，你首先聽說的應該是功能測試。通過一些測試手段來驗證開發(fā)做出的代碼是否符合產(chǎn)品的需求汛闸？當然你也有自己對功能測試的理解蝙茶，但是最近兩年感覺功能測試好像不太受歡迎，同時不少同學真的是功能測試都沒有做好诸老，就去嘗試自動化測試隆夯，測試開發(fā)什么的，結果是越學越迷茫别伏，這是為什么呢蹄衷？究其原因是，你功能測試還沒有學好呢厘肮！我們通常認為的功能測試是根據(jù)需求愧口，采取如下測試流程：需求分析，用例編寫类茂，用例評審耍属，提測驗證，Bug回歸驗證巩检，上線與線上回歸等來進行測試厚骗。如此日復一日，年復一年兢哭，響應了很多需求领舰，可是想換工作的時候卻得不到認可,大家想想是不是這種情況？下面我就以一個功能測試人員如何進行工作厦瓢，來介紹一下功能測試應該用到的知識及相關的提升建議提揍。

一， 需求分析煮仇，發(fā)揮主動性正常的需求在產(chǎn)出的時候劳跃，產(chǎn)品是要分析這個需求的價值，影響范圍和實現(xiàn)代價的浙垫∨俾兀可是現(xiàn)在很多情況是郑诺，需求來了就組織評審，然后開發(fā)測試與上線杉武。產(chǎn)品主導型的開發(fā)模式非常常見辙诞，作為測試我們無法主導需求和項目。在需求評審的時候轻抱，作為一個測試人員必須了解這次需求的內(nèi)容飞涂，影響到哪些現(xiàn)有的功能，涉及到的操作系統(tǒng)或是類別等祈搜，然后準確的評估出工作量较店，防止因評估不足造成后期測試不充分。再者容燕，關注開發(fā)和產(chǎn)品的討論梁呈，如果開發(fā)說哪一部分比較難實現(xiàn)，最后如何實現(xiàn)蘸秘？其中做出的變動和難點就是測試的時候必須重點關注的部分官卡。不能因為這些暫時和你沒有關系就不去關注，后期會帶來麻煩醋虏。第三寻咒，需求評審結束后，要求產(chǎn)品更新此次評審過程中的所有改動部分灰粮，同時給出方案確保產(chǎn)品的任何改動都及時更新仔涩。第四忍坷，根據(jù)產(chǎn)品需求粘舟，設計測試方案及時間安排，此時可以粗粒度考慮佩研，時間上要合理柑肴；同時與在會人員進行探討。

二旬薯， 用例設計與評審晰骑，做到不遺不漏測試用例是每個測試人員工作過程中必須要完成的工作，不管你是用Excel,還是用FreeMind來寫绊序，在測試工作中一是用來指導測試工作硕舆，而且是相關業(yè)務的一個文檔沉淀≈韫可能你不太在意測試用例的編寫抚官，可是在我以往面試的經(jīng)驗中，有超過一半的人寫的測試用例是不達標的阶捆。很多人寫用例是用書本上的方法凌节，什么邊界值法钦听，條件覆蓋法等等，其實我們更應該關注用戶倍奢，從用戶的角度來寫用例才對朴上。測試用例必須具備的測試用例名，執(zhí)行步驟卒煞，預期結果這三點是必須要寫清楚的痪宰。再者就是測試方案選擇必須全面，作為功能測試人員你可能不會編寫自動化測試腳本畔裕，不會性能測試酵镜，安全測試，但是你必須能根據(jù)需求想到要實施哪方面的測試柴钻。如面試的時候給你一個場景：一個全新的App要發(fā)版淮韭，如果讓你來測試，你能想到哪些測試方案贴届？如果你只能想到如何去測試app的功能的話靠粪，那你作為功能測試人員就是考慮不全面。此時的App的功能毫蚓，App的性能占键，數(shù)據(jù)傳輸?shù)陌踩裕涌诨蚍盏墓δ軠y試元潘，接口或服務的自動化測試與監(jiān)控畔乙，接口或服務的性能測試，底層數(shù)據(jù)的存儲與容災情況都必須考慮在內(nèi)翩概。設計用例的時候要設計兩類牲距， 一類是開發(fā)自測和驗收提測試標準的冒煙測試用例，一類是針對需求的全面測試用例钥庇。寫完用例要主動聯(lián)系相關人員進行用例評審牍鞠，強調(diào)開發(fā)自測，在評審過程是及時修改不合適的用例评姨。

三难述， 測試流程，注重項目控制其實項目的流程控制在需求開始的時候就應該重視起來吐句，只是很多時候我們沒有意識到這是測試的工作胁后，有的是產(chǎn)品來控制，有的是專門的項目經(jīng)理來控制嗦枢。測試人員是一線的工作人員攀芯，不管你工作了多久，必須有關注整體項目的意識净宵。如果你不關注項目進度敲才，什么時候提測你什么時候開始測試裹纳，在測試過程中你就會遇到測試的內(nèi)容和最初的需求不一致，增加新的內(nèi)容從而增加工作量紧武，或是產(chǎn)品和開發(fā)一起來壓縮測試時間的情況剃氧，到時你想不加班都難。需求一旦明確了由你來負責的時候阻星，就要時刻按排期來關注項目的情況朋鞍。中間變更需求的時候，要評估是否影響項目進度妥箕，如果影響了重新進行排期滥酥。如果開發(fā)提測試晚了，是否影響上線時間畦幢，如果可能會影響坎吻，馬上就要給相關的人員發(fā)預警郵件，通知大家詳細的情況宇葱。同時在測試過程中瘦真，發(fā)現(xiàn)了bug必須詳細描述問題，不管是jira,禪道或是其他的bug管理方式黍瞧，一個bug要寫清楚以下幾點：Bug問題描述诸尽，bug重現(xiàn)步驟，是否有前置條件印颤，預期結果您机，實際結果，以方便開發(fā)去進行修改年局。同時給bug準確分級际看，實時跟蹤進度，保證項目按期完成某宪。

四仿村， 上線回歸與項目總結一個需求上線完成后锐朴，要及時進行線上回歸兴喂，如果有必須提醒相關的人員進行自動化線上回歸或是監(jiān)控工作。同時必須回歸我們在需求評審的時候考慮到的可能影響到的原有的功能焚志，以確保新功能的完全上線成功衣迷。而作為功能測試人員，在一個項目完成后酱酬，不管公司有沒有要求壶谒，要對項目做相應的文字總結∩殴粒總結整個項目過程中遇到的問題汗菜，最后的解決辦法或是當時討論的處理辦法让禀，有哪些需要注意的問題？有什么可以借鑒的方案或是改進策略陨界？項目中有沒有通用性的問題等等巡揍。如果公司有相應的項目總結方案，那測試的時候就要多關注一些數(shù)據(jù)菌瘪，如冒煙測試是否一次通過腮敌，Bug數(shù)及不同級別的bug數(shù)，參與開發(fā)人員對應的Bug數(shù)俏扩，提測試次數(shù)糜工，上線次數(shù)等等。而后借助于第三方工具進行圖表化相應的數(shù)據(jù)录淡，然后相關問題的總結捌木，改進方案都需要進行詳細的總結。

五嫉戚， 能力的總結和沉淀在我們找工作的時候钮莲，很多做功能測試多年的同學一般很難通過面試，這里面的原因究竟是什么彼水？其實最核心的原因是崔拥，你不具備相應工作年限應該具備的能力。測試工具的使用：在你以往的工作經(jīng)驗中凤覆，有沒有總結過什么樣的需求或是項目應該使用什么樣的測試工具链瓦，而不是僅僅使用公司提供或是指定的工具？有沒有分析過同類的工具的優(yōu)缺點盯桦？如果一個類似的全新的產(chǎn)品慈俯，你能否圍繞著工作需求，準備相應的測試工具來輔助測試拥峦？什么樣的測試工具在測試項目的時候可能存在問題贴膘，問題的解決辦法是什么？問題的總結：在測試工作中總結部署環(huán)境出現(xiàn)502或是404產(chǎn)生的原因及解決辦法略号？產(chǎn)品的哪兒塊功能容易出現(xiàn)問題刑峡，或是開發(fā)怎么實現(xiàn)相應的功能可能出現(xiàn)問題？產(chǎn)品的功能模塊之間是如何工作的玄柠，修改部分功能后可能會對其他模塊產(chǎn)生影響突梦？哪個版本的編譯器打包的產(chǎn)品容易在哪些方面出現(xiàn)問題？等等相應的問題總結有沒有做羽利，如果做了宫患，在接到相應的需求后就能快速的評估測試范圍，選擇測試方案这弧，規(guī)劃測試時間等娃闲。技術的沉淀：技術不僅僅指的是編碼能力虚汛，像平時我們部署環(huán)境出現(xiàn)問題后，最后的解決方案的總結皇帮；測試過程中日志出現(xiàn)空指針的排查熊响；項目測試過程中遇到的問題及解決方案州刽；一些常見問題的排查及解決方案等等。要在工作中善于積累，從而指導自己的工作或是為同事提供解決問題的思路與辦法亚兄。

時常問自己一句話：離開現(xiàn)有的平臺恕曲，我還有什么谴轮？這個才是你的資本醇滥，對公司業(yè)務的熟悉，公司現(xiàn)在工具的使用等等礼预，對你來說是沒有任何優(yōu)勢可言的眠砾。而對同類業(yè)務流程的掌握，項目的整體把控托酸，快速了解業(yè)務并能根據(jù)需求選擇測試方案褒颈，引進現(xiàn)有的測試工具提高測試效率，測試過程中遇到問題的預判和解決辦法等才是功能測試人員必須具備的能力励堡。這些方面你做到了嗎谷丸？業(yè)務專家也是不想做編碼的測試人員一個很好的選擇，不要整天抱怨功能測試如何如何应结，要充分認清行業(yè)現(xiàn)狀和自己的優(yōu)缺點刨疼，做好職業(yè)規(guī)劃。