前言     也許身處專案組，作為測試的你在孤軍奮戰，陌生的環境，同事全是開發，領導是技術/業務經理，這時有一個系統需要你測試，沒有參與需求評審沒有需求文件更沒有測試流程，有的只是一個粗糙的原型。     這樣的背景下，會有一種絕望感嗎？我不知道，但我確實經歷了這一切，並改善了這個局面。前後共經歷兩年時間，我將會在此書寫與內部系統的恩怨情仇。     我記得大四實習時最早接觸的，是個報表系統，在完全不知道測試要幹什麼的情況下，boss給了我一個原型以及10.10.*.*的地址，哦...還有admin帳號以及登入密碼。後來陸陸續續地接觸了許多測試同事、測試領導，來來往往，從一個人的測試組最終還是回到了初始化狀態。     這篇部落格我認為也可以稱之為：“一個人的測試應該怎麼玩？”，但以此命名似乎不嚴謹，因為在我後來的瞭解，很多網際網路相關的初創公司也會出現測試獨苗的尷尬情況，對於使用者體驗以及其他非功能性測試非我所長。又或者命名為：“傳統的web系統”，思前想後還是覺得“內部系統”更加貼切。     書寫我的測試經歷，分享我看到的、我想到的，給我的兩年工作做個總結，從總結中發現該反思的點。     如果此刻點開此篇部落格的你，將要對傳統web系統進行測試工作，希望可以提供一些幫助；如果您對此不屑一顧，就請您到此為止，能被當成茶餘飯後的談資，不勝榮幸。   現狀     首先送給你的第一句話，作為測試，不必行螳臂擋車之舉，講究順勢而為，以萬變應不變，至於為什麼這麼說，我先講一講內部系統的現狀吧。     所謂的內部系統，通俗來講，就是自己開發的軟體，自己使用。     我所能瞭解到最早的測試，是一篇關於2006年左右發表的分析國內軟體測試現狀，即使現在Baidu當年的軟體測試，也能找到很多相關的討論。     花開兩朵，各表一枝，先說說早些年的軟體測試行業。     我對早些年的論壇討論加以分析和整合，甚至充入一些我的想象得出結論：在國內軟體發展起步較晚的情況下，軟體測試這個行業還處於懵懂無知的狀態，所謂的專業軟體公司，開發出軟體後bug一大堆，並不加以測試就直接交付給客戶，至於bug肯定是不會修復，反正客戶已經付過錢了。     再過幾年，有了軟體測試工程師這個職位，但測試的流程和制度並未出現，專案組內除測試之外達成了一條共識，開發把軟體寫好以後部署到測試伺服器，讓測試去點點頁面看看有沒有什麼bug，由此整個IT行業內出現了一句話“軟體測試只是點點點”。這句話影響了未來多年時間，直到17、18年軟體測試的招聘要求不斷提高，點點點這個名詞開始消聲滅跡，但仍然存在於各個角落，甚至已經被外行人給這個職業刻上了印子。     大批軟體測試從業者在思考這個行業到底有沒有前途？（為什麼我會搜這些內容，因為我也深陷在這個難題中很久，最可怕的永遠是自我懷疑。）答案是什麼？開啟招聘網看看，現在測試的薪資並不比開發低。     再說回現在的內部系統，整個測試流程形同虛設，很像點點點。最大的詬病就是“求快”，一個系統還未確定複雜度的情況下，就要先評估或制定完成時間。就好比馬拉松比賽不告訴你多少公里數，就問你一天能不能跑完，或者連問的機會都不給你。     因為快，引發的一系列問題，產品經理要快，原型和需求文件必須馬上寫完；技術經理要快，架構和資料結構以及所有開發人員的工作計劃要列好；測試要快，儘早地完成測試提交測試報告，這樣系統可以準時交付。     結果有倆，一是延期上線，理由千變萬化，不會影響測試；二是準時上線，會不會出現bug，看運氣，運氣好則平安無事，運氣不好，即便是不追究責任，作為測試的你怎麼面對專案組成員“仇恨”的目光？     至於在專案籌劃期間，對系統的要求是什麼？能用。可是能用這個詞太籠統，每個人對能用的理解都不同，有的人認為開啟瀏覽器輸入網址能登入就行，有的人認為介面要美觀，帳號輸入框要好看。     能用的下一步是什麼，功能實現。比如要給系統新增帳號，能正常新增帳號完畢後，就算功能實現嗎？萬一哪天這個帳號的使用者不在這幹了，有刪除/禁用帳號的功能嗎？就算有，能確保這個帳號不能登入系統嗎？     以此類推，可以不停的舉例，不停的延伸擴充套件，以上就是內部系統的現狀。     一句話總結，流程和標準不完善。   內部系統的功能以及如何測試     前文有提到，我定義的內部系統，是一個由目前主流語言java開發的web專案，每個系統都有對應不同的業務，但後臺管理永遠都是通用的，也許不同的產品經理對系統的設計會有所不同，我還是可以從中提取出相似的地方。     如果恰巧你所在的測試組沒有所謂的流程規範，如果恰巧你測試的系統也是我描述的一樣，那麼不妨看看我為你提供的測試點。     再次宣告，如果你的系統面對網際網路的其他使用者或使用者量龐大的情況，我提供的這些測試點肯定是不夠的，甚至可以拿來當反面教材。     內部系統的三大元素，表單、列表、篩選框。     表單，         功能描述：分為標題、表單域和按鈕，表單域，但表單域有個可怕的地方就是，輸入框或下拉框會無限的多。         測試重點：冒煙、必填項、唯一約束。         測試說明：表單測試是一件很麻煩的事，通常每個輸入框的必填、唯一、正則都是需要測試的內容，但如果測試時間有限，可以提取出高優先順序的幾項安排測試。     列表，         功能描述：從資料庫抓取的一大串陣列，通過某種排序方式展示出來。         測試重點：資料準確性、使用者許可權對應的資料展示、排序方式合理性、分頁的按鈕功能。     篩選框，         功能描述：通常伴隨列表使用。         測試重點：篩選結果正確性、篩選後對應使用者許可權、列表篩選後匯出。     內部系統的三大功能，新建/編輯、刪除/禁用，匯出。     新建/編輯，         功能描述：通常都帶有表單的功能。         測試重點：冒煙、資料關聯約束、修改後資料正確、核對資料庫。     刪除/禁用，         功能描述：通常是邏輯刪除，對應的會有個delete或id_show欄位。         測試重點：冒煙、資料關聯約束、刪除後新建、修改後資料正確、核對資料庫。     匯出，         測試重點除了篩選匯出之外，還要考慮對應資料許可權關係。     內部系統的兩個擴充套件模組，流程、報表   測試工程師的地位以及角色

    感謝在實習初期當了幾天透明人，有幸以測試工程師的職業觀察到一個沒有測試的專案組測試流程。     專案組沒有測試這個崗位之前，他們是怎麼測試的？測試這個工作大部分分擔給產品經理和開發人員，開發人員在按照需求完成一個功能後，會進行一遍自測，覺得沒問題後，把程式碼釋出到測試環境並告知產品經理。產品經理到測試環境檢視功能是否符合預期效果，提一點使用的建議，之後沒問題就可以正式釋出版本，如果後續出現bug聯絡開發人員改一下就好了。     通過以上的描述，有沒有覺得遺漏了什麼環節，對外行人來說，沒問題啊，功能開發好了，測試也過了，不就可以正式釋出了嗎？     是的，如果確實是個內部系統，複雜度不高且開發人員<=2時，這麼幹也不會有什麼影響。      但是，如果系統因程式碼出現大的問題，會影響到專案管理人員怎麼辦？如果系統複雜度和開發人員數量增加，系統還能正常使用嗎？     在沒有出現這些問題之前，很少有人會考慮到。     甚至某天出現了致命的系統bug，緊急修復後是否會考慮到測試是否完善或窮盡？   測試之路如何開展     如果你是實習生，測試組內有位中高階的測試帶領，只需要多向你的“師傅”請教問題即可，多學習可別懶散，否則實習考核的時候，“師傅”也救不了你。     如果你是實習生，測試組內只有你一個人，我會推薦你趕緊跑，什麼話都別聽，當然要先找好工作。如果找不到的話...     如果你是中高經驗的工程師或是測試負責人，以我現在的眼光和心態去思考我會這麼做？     到一家測試經驗為零的公司，首先先跟上級領導交流，言語中不光要了解當前測試環境，還要抓到一點，使用者容忍度。     比較幸運的是一個新系統從零開始，正好你加入了，這樣可以減少很多的時間和精力去了解過去的內容。     我個人認為，直接去弄一整套測試流程規範是沒有意義的，沒法落地，實行難度太大，不如從最小化開始。     有三個最容易實行的點，提測、發版、報告。     提測，         一個功能開發完成到提交測試需要一個什麼樣的步驟？         以往就是直接丟一堆功能給你，具體怎麼做，看著辦就好，         但這次可以先要求開發，提交測試需要正式發郵件，郵件內容包括：功能、程式碼分支、資料庫執行sql等資訊。         測試根據開發提供的內容，先開始一輪冒煙測試，如果因sql或其他資訊沒有提供，導致測試進行不下去，打回測試。     發版，         把系統的發版許可權交給測試，但是要做到這一步，你需要對Git、Jenkins和linux怎麼使用得心應手。         一個系統是否達到上線標準，整個專案組只有測試才是最瞭解的。     報告，         測試報告是一個向專案組表示“存在感”很重要的工作，因此在每次生產環境更新的時候，都要對本次測試的內容和過程做一份詳細的報告，         至於要如何寫一份漂亮的測試報告，就不做太多闡述。     以上三點做到後，基本上測試流程已經有了一個規範，測試的“存在感”也變得越來越明顯。     再往後可以怎麼做？     參與需求評審、完善bug生命週期、開發迴應bug的效率等等。   我遇到的那些暗坑     列表篩選後分頁；     匯入的時候，資料超過一千條；     不區分大小寫的密碼；     資料庫的欄位有空格；     增加篩選項，測篩選以及篩選+匯出；      我的期望  & 尾聲     說了這麼多，算是吐槽也算是經驗總結，再一次感謝能有耐心看到這裡。     其實很多的意外（系統的bug）都可以避免，畢竟測試的工作就是為使用者“蹚雷”，     如果還有機會規整這些測試流程，我的期望不光是測試流程和制度的規範，甚至還可以擴充套件到整個專案週期。     說一說我對未來系統的期望吧。     系統功能新增更新公告         內部系統在上線的時候，總是會存在一堆的功能不足和影響面不大的bug，比如某個列表篩選框功能沒有實現，使用者在第一次使用的時候發現這個問題，肯定在以後很長一段時間都不會再次使用這個篩選。         在登入頁面或首頁上，加上一個更新公告，對每次迭代開發的新功能以及bug修復，無論會不會有人開，起碼都代表著專案組的誠意，個別情況下還能間接展示了工作了內容。     系統上線的時間能由測試來統籌         系統何時上線，真的不應該是一兩句話就能說準的事，開發要評估開發時間，測試要評估測試時間，還要加上產品經理對接梳理需求以及伺服器準備的一些操作，這些事情都是很佔用時間。         對測試而言，測試的工作包括前期資訊收集、測試分析、測試用例、測試施行、bug跟蹤反饋以及最後的測試報告。         所以希望在未來，上線時間可以交給測試。       以上，就是我關於“內部系統”的一些見解，     部落格園ID：祝新新zxy