前言
也許身處專案組，作為測試的你在孤軍奮戰，陌生的環境，同事全是開發，領導是技術/業務經理，這時有乙個系統需要你測試，沒有參與需求評審沒有需求文件更沒有測試流程，有的只是乙個粗糙的原型。
這樣的背景下，會有一種絕望感嗎？我不知道，但我確實經歷了這一切，並改善了這個局面。前後共經歷兩年時間，我將會在此書寫與內部系統的恩怨情仇。
我記得大四實習時最早接觸的，是個報表系統，在完全不知道測試要幹什麼的情況下，boss給了我乙個原型以及10.10.*.*的位址，哦...還有admin帳號以及登入密碼。後來陸陸續續地接觸了許多測試同事、測試領導，來來往往，從乙個人的測試組最終還是回到了初始化狀態。
這篇部落格我認為也可以稱之為：「乙個人的測試應該怎麼玩？」，但以此命名似乎不嚴謹，因為在我後來的了解，很多網際網路相關的初創公司也會出現測試獨苗的尷尬情況，對於使用者體驗以及其他非功能性測試非我所長。又或者命名為：「傳統的web系統」，思前想後還是覺得「內部系統」更加貼切。
書寫我的測試經歷，分享我看到的、我想到的，給我的兩年工作做個總結，從總結中發現該反思的點。
如果此刻點開此篇部落格的你，將要對傳統web系統進行測試工作，希望可以提供一些幫助；如果您對此不屑一顧，就請您到此為止，能被當成茶餘飯後的談資，不勝榮幸。
現狀首先送給你的第一句話，作為測試，不必行螳臂擋車之舉，講究順勢而為，以萬變應不變，至於為什麼這麼說，我先講一講內部系統的現狀吧。
所謂的內部系統，通俗來講，就是自己開發的軟體，自己使用。
我所能了解到最早的測試，是一篇關於2023年左右發表的分析國內軟體測試現狀，即使現在baidu當年的軟體測試，也能找到很多相關的討論。
花開兩朵，各表一枝，先說說早些年的軟體測試行業。
我對早些年的論壇討論加以分析和整合，甚至充入一些我的想象得出結論：在國內軟體發展起步較晚的情況下，軟體測試這個行業還處於懵懂無知的狀態，所謂的專業軟體公司，開發出軟體後bug一大堆，並不加以測試就直接交付給客戶，至於bug肯定是不會修復，反正客戶已經付過錢了。
再過幾年，有了軟體測試工程師這個職位，但測試的流程和制度並未出現，專案組內除測試之外達成了一條共識，開發把軟體寫好以後部署到測試伺服器，讓測試去點點頁面看看有沒有什麼bug，由此整個it行業內出現了一句話「軟體測試只是點點點」。這句話影響了未來多年時間，直到17、18年軟體測試的招聘要求不斷提高，點點點這個名詞開始消聲滅跡，但仍然存在於各個角落，甚至已經被外行人給這個職業刻上了印子。
大批軟體測試從業者在思考這個行業到底有沒有前途？（為什麼我會搜這些內容，因為我也深陷在這個難題中很久，最可怕的永遠是自我懷疑。）答案是什麼？開啟招聘網看看，現在測試的薪資並不比開發低。
再說回現在的內部系統，整個測試流程形同虛設，很像點點點。最大的詬病就是「求快」，乙個系統還未確定複雜度的情況下，就要先評估或制定完成時間。就好比馬拉松比賽不告訴你多少公里數，就問你一天能不能跑完，或者連問的機會都不給你。
因為快，引發的一系列問題，產品經理要快，原型和需求文件必須馬上寫完；技術經理要快，架構和資料結構以及所有開發人員的工作計畫要列好；測試要快，盡早地完成測試提交測試報告，這樣系統可以準時交付。
結果有倆，一是延期上線，理由千變萬化，不會影響測試；二是準時上線，會不會出現bug，看運氣，運氣好則平安無事，運氣不好，即便是不追究責任，作為測試的你怎麼面對專案組成員「仇恨」的目光？
至於在專案籌畫期間，對系統的要求是什麼？能用。可是能用這個詞太籠統，每個人對能用的理解都不同，有的人認為開啟瀏覽器輸入**能登入就行，有的人認為介面要美觀，帳號輸入框要好看。
能用的下一步是什麼，功能實現。比如要給系統新增帳號，能正常新增帳號完畢後，就算功能實現嗎？萬一哪天這個帳號的使用者不在這幹了，有刪除/禁用帳號的功能嗎？就算有，能確保這個帳號不能登入系統嗎？
以此類推，可以不停的舉例，不停的延伸擴充套件，以上就是內部系統的現狀。
一句話總結，流程和標準不完善。
內部系統的功能以及如何測試
前文有提到，我定義的內部系統，是乙個由目前主流語言j**a開發的web專案，每個系統都有對應不同的業務，但後台管理永遠都是通用的，也許不同的產品經理對系統的設計會有所不同，我還是可以從中提取出相似的地方。
如果恰巧你所在的測試組沒有所謂的流程規範，如果恰巧你測試的系統也是我描述的一樣，那麼不妨看看我為你提供的測試點。
再次宣告，如果你的系統面對網際網路的其他使用者或使用者量龐大的情況，我提供的這些測試點肯定是不夠的，甚至可以拿來當反面教材。
內部系統的三大元素，表單、列表、篩選框。
表單，功能描述：分為標題、表單域和按鈕，表單域，但表單域有個可怕的地方就是，輸入框或下拉框會無限的多。
測試重點：冒煙、必填項、唯一約束。
測試說明：表單測試是一件很麻煩的事，通常每個輸入框的必填、唯
一、正則都是需要測試的內容，但如果測試時間有限，可以提取出高優先順序的幾項安排測試。
列表，功能描述：從資料庫抓取的一大串陣列，通過某種排序方式展示出來。
測試重點：資料準確性、使用者許可權對應的資料展示、排序方式合理性、分頁的按鈕功能。
篩選框，
功能描述：通常伴隨列表使用。
測試重點：篩選結果正確性、篩選後對應使用者許可權、列表篩選後匯出。
內部系統的三大功能，新建/編輯、刪除/禁用，匯出。
新建/編輯，
功能描述：通常都帶有表單的功能。
測試重點：冒煙、資料關聯約束、修改後資料正確、核對資料庫。
刪除/禁用，
功能描述：通常是邏輯刪除，對應的會有個delete或id_show欄位。
測試重點：冒煙、資料關聯約束、刪除後新建、修改後資料正確、核對資料庫。
匯出，測試重點除了篩選匯出之外，還要考慮對應資料許可權關係。
內部系統的兩個擴充套件模組，流程、報表
測試工程師的地位以及角色
感謝在實習初期當了幾天透明人，有幸以測試工程師的職業觀察到乙個沒有測試的專案組測試流程。
專案組沒有測試這個崗位之前，他們是怎麼測試的？測試這個工作大部分分擔給產品經理和開發人員，開發人員在按照需求完成乙個功能後，會進行一遍自測，覺得沒問題後，把**發布到測試環境並告知產品經理。產品經理到測試環境檢視功能是否符合預期效果，提一點使用的建議，之後沒問題就可以正式發布版本，如果後續出現bug聯絡開發人員改一下就好了。
通過以上的描述，有沒有覺得遺漏了什麼環節，對外行人來說，沒問題啊，功能開發好了，測試也過了，不就可以正式發布了嗎？
是的，如果確實是個內部系統，複雜度不高且開發人員<=2時，這麼幹也不會有什麼影響。
但是，如果系統因**出現大的問題，會影響到專案管理人員怎麼辦？如果系統複雜度和開發人員數量增加，系統還能正常使用嗎？
在沒有出現這些問題之前，很少有人會考慮到。
甚至某天出現了致命的系統bug，緊急修復後是否會考慮到測試是否完善或窮盡？
測試之路如何開展
如果你是實習生，測試組內有位中高階的測試帶領，只需要多向你的「師傅」請教問題即可，多學習可別懶散，否則實習考核的時候，「師傅」也救不了你。
如果你是實習生，測試組內只有你乙個人，我會推薦你趕緊跑，什麼話都別聽，當然要先找好工作。如果找不到的話...
如果你是中高經驗的工程師或是測試負責人，以我現在的眼光和心態去思考我會這麼做？
到一家測試經驗為零的公司，首先先跟上級領導交流，言語中不光要了解當前測試環境，還要抓到一點，使用者容忍度。
比較幸運的是乙個新系統從零開始，正好你加入了，這樣可以減少很多的時間和精力去了解過去的內容。
我個人認為，直接去弄一整套測試流程規範是沒有意義的，沒法落地，實行難度太大，不如從最小化開始。
有三個最容易實行的點，提測、發版、報告。
提測，乙個功能開發完成到提交測試需要乙個什麼樣的步驟？
以往就是直接丟一堆功能給你，具體怎麼做，看著辦就好，
但這次可以先要求開發，提交測試需要正式發郵件，郵件內容包括：功能、**分支、資料庫執行sql等資訊。
測試根據開發提供的內容，先開始一輪冒煙測試，如果因sql或其他資訊沒有提供，導致測試進行不下去，打回測試。
發版，把系統的發版許可權交給測試，但是要做到這一步，你需要對git、jenkins和linux怎麼使用得心應手。
乙個系統是否達到上線標準，整個專案組只有測試才是最了解的。
報告，測試報告是乙個向專案組表示「存在感」很重要的工作，因此在每次生產環境更新的時候，都要對本次測試的內容和過程做乙份詳細的報告，
至於要如何寫乙份漂亮的測試報告，就不做太多闡述。
以上三點做到後，基本上測試流程已經有了乙個規範，測試的「存在感」也變得越來越明顯。
再往後可以怎麼做？
參與需求評審、完善bug生命週期、開發回應bug的效率等等。
我遇到的那些暗坑
列表篩選後分頁；
匯入的時候，資料超過一千條；
不區分大小寫的密碼；
資料庫的字段有空格；
增加篩選項，測篩選以及篩選+匯出；
我的期望 & 尾聲
說了這麼多，算是吐槽也算是經驗總結，再一次感謝能有耐心看到這裡。
其實很多的意外（系統的bug）都可以避免，畢竟測試的工作就是為使用者「蹚雷」，
如果還有機會規整這些測試流程，我的期望不光是測試流程和制度的規範，甚至還可以擴充套件到整個專案週期。
說一說我對未來系統的期望吧。
系統功能新增更新公告
內部系統在上線的時候，總是會存在一堆的功能不足和影響面不大的bug，比如某個列表篩選框功能沒有實現，使用者在第一次使用的時候發現這個問題，肯定在以後很長一段時間都不會再次使用這個篩選。
在登入頁面或首頁上，加上乙個更新公告，對每次迭代開發的新功能以及bug修復，無論會不會有人開，起碼都代表著專案組的誠意，個別情況下還能間接展示了工作了內容。
系統上線的時間能由測試來統籌
系統何時上線，真的不應該是一兩句話就能說準的事，開發要評估開發時間，測試要評估測試時間，還要加上產品經理對接梳理需求以及伺服器準備的一些操作，這些事情都是很占用時間。
對測試而言，測試的工作包括前期資訊收集、測試分析、測試用例、測試施行、bug跟蹤反饋以及最後的測試報告。
所以希望在未來，上線時間可以交給測試。
以上，就是我關於「內部系統」的一些見解，
id：祝新新zxy
畢業兩年的總結
從大學畢業到現在，跨度兩年。工作兩年，間隙性的總結一下自己。回首兩年前，那些人,那些事,漸漸浮現,卻那麼遙遠，還記得那場畢業晚宴，還記得那個夜晚，和兄弟們分別的散夥飯 還記得剛離開象牙塔跨入社會年少輕狂的自己 或許我是幸運的，畢業沒有費好大的力氣就找到了工作，從事的還是自己的專業，自己喜歡的職業 p...
兩年多的總結
畢業兩年半了，也工作了兩年半。在這工作的兩年半的日日夜夜中有收穫也有失去，有甜蜜也有痛苦。這麼久以來總是沒有靜下心來好好總結自己的得與失，喜與悲。對於工作也算是勤勤懇懇，任勞任怨了，不會因為自己的工作而去怨天尤人，也沒有因為自己遇到的不快而自暴自棄。在工作中不管分配的是什麼工作，即使按照職業習慣不應...
兩年軟體測試工程師告訴你 他是怎麼做測試用例的
入行軟體測試行業2年，從事過自動化的測試和手工的功能測試。兩年來一直沒有總結過自己的工作。每當一聽人問起乙個簡單的問題，如何編寫好的測試用例?如此簡單的問題一問，仔細一想，思緒凌亂無章。這就是沒有好好思考過的原因。今天總結下自己的看法，如何編寫測試用例 1 了解軟體的原始需求 測試目的 在編寫乙個軟...