負責人 空格 admin 是否 標準 自己 提取 基本 不同的

前言 也許身處項目組，作為測試的你在孤軍奮戰，陌生的環境，同事全是開發，領導是技術/業務經理，這時有一個系統需要你測試，沒有參與需求評審沒有需求文檔更沒有測試流程，有的只是一個粗糙的原型。 這樣的背景下，會有一種絕望感嗎？我不知道，但我確實經歷了這一切，並改善了這個局面。前後共經歷兩年時間，我將會在此書寫與內部系統的恩怨情仇。 我記得大四實習時最早接觸的，是個報表系統，在完全不知道測試要幹什麽的情況下，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

‘內部系統’怎麽測試？兩年測試的總結與反思