我們在變化中成長。假設你拒絕了變化，那麼，你就拒盡了新的美麗和新的機遇。
初始軟體測試
“這是一個杯子，主要用來喝水的，它的質量應該如何考量？”
這是在進入上家公司面試時，測試主管問我的題目，相關的回答已經有點模糊，但從這個問題可以大概瞭解到，測試主管在考察我的測試思維。
功能測試實踐
“某某某，過來一下，這是這個版本修改的內容，大概是要在某月某日完成，你過（看）一下。”
“哦”。
到了測試執行，發現問題後提交給開發同事，開發回覆：“設計如此。”
“哦”。
快要上線了，專案經理問：“某某某，現在系統的測試情況怎麼樣，能不能上線？”
“應該差不多吧”
......
測試主管了解之後，跟我強調了幾點：
1、測試的依據，需求基線要清楚，要儘早參與；
2、測試要有計劃方案，要有用例設計，不能隨意的開展；
3、Bug的跟蹤，要有自己的主見、原則；
4、測試結果的把握，要有結果分析。專案的上線，要綜合你的以上測試過程，結合目前的情況總結報告，甚至是專案經理也要聽取你的意見。你的角色不僅是測試，也是質量保證。
當然，以上的情況只是測試中遇到問題的一點點，如沙漠中的一粒沙（這孩子究竟怎麼過來的），但也讓我認識到測試是獨立的、重要的。
在後來的專案測試工作中，踐行測試主管傳遞的思想原則的同時，我並行瞭解相關測試書籍、工具、技能，結合工作進行相關實踐，逐漸地我的測試能力越來越強。
在省國稅外派了一年，之後測試過程中更加有條理、原則、規範。但也僅是個人自覺的約束，很多過程並沒有按照軟體開發週期的標準來執行，如測試用例、測試報告有時候會在釋出版本後才編寫（雖然公司也通過了CMMI3），即測試的質量保證更多的依賴個人的素質。並且，當時個人認為測試的業務熟練更多決定於對系統功能本身的熟悉和測試設計執行的熟悉，認識到錯誤並且有意識改變是在地稅的定點聯絡企業管理系統和電子辦稅服務廳的測試過程。
之後，進入到地稅的定點聯絡企業管理系統專案組進行測試。當時專案已快要進入驗收階段，甲方要求的功能基本都有實現，但在交付時甲方卻不滿意，在一些功能的易用性和系統介面展示上提了很多要求，導致整個系統最後框架、原型都換了一遍，而且限定修改的時間很短（又是一個加班加點的開始），最後甚至專案負責人都換了。
總結了下，有幾個方面問題：
1、既定清晰的需求都有按要求實現，只不過實現方式不合甲方胃口，如圖表不夠豐富，只有概要，沒有詳細。
2、系統介面沒有統一的樣式，甲方不客氣的說像草稿。
3、流程沒有體現甲方日常工作內容、步驟。
4、風控系統很膚淺，指標不實用。
在這個測試過程中，我比較正式地參加甲方組織的各種需求討論會議，期間也認識到原始需求到需求基線其實還是有設計落實過程的，其把握的度就要看負責人或產品經理的靈性了。作為測試人員，在需求評審過程中就要對比原始需求（要詳細瞭解具體日常工作內容，行業特殊性等）和需求基線的不同，給予自己的意見，在測試過程中不時提醒自己。而對需求的理解是否深刻，有時候不是參加正式需求評審就能達到的，還需要深入到使用者實際的工作場景，瞭解實際業務和流程。而對於自己無法準確把握（風控系統），使用者又無法準確提供的需求就要定好界限，實現到什麼程度。最後，好用的軟體不僅是功能的實現，一個介面樣式都能讓你從頭再來。原計劃短期內交付的專案，由於後續各種修改需求一直到了次年3月，才基本結束相關測試活動。
完成定點聯絡企業管理系統的測試之後，我進入了電子辦稅服務廳專案組，在這裡個人的業務掌握程度得到認可。首先，對核心系統（電子辦稅服務廳介面呼叫提供方）的相關業務（文書、申報等）熟悉，並與對應系統的中軟專案組人員都可以打成一片（也是吸取在陝西時溝通不順的教訓，詳細後面效能測試提到）。其次，對電子辦稅廳的需求理解充分，得益於當時的需求人員耐心引導（為了稅務事業，頭髮都花白了的同事），最後是自己對相關係統的後臺資料表結構都比較熟悉。出現問題之後，能快速的理清思路，定位原因。問題出現之後，當你有理有據的跟相關負責人溝通時，他們也會心悅誠服。在經過一年多的團隊配合之後專案組啟動跟金三對接工作（要2個月完成，又是看星星賞月亮的好時光），專案經理將介面聯調的任務交由我負責，也是看在我對原有兩方系統及人員的瞭解。
效能測試實踐
測試當然不僅有功能測試。第一次接觸效能測試也是在國稅門戶專案組，只不過測試物件不是國稅入口網站。其實那個軟體系統的具體業務我都不太清楚（慚愧），只知道是叫一戶式查詢系統。當時雖然瞭解過效能測試的原理，但是具體如何開展還是有點懵逼。在測試主管的協助指導下（說是一步一扶都不過分），艱難完成。
在此，額外擷取下當時某個業務場景測試的結果資料（沒有找到曲線圖了，發一下當時用表格記錄的資料，你沒看錯，是5併發時間95s！！！）
執行這次測試之後，瞭解到同效能測試如下相關資訊：
1、系統的部署組成，相關的伺服器有哪些（此時還不知道具體的網路拓撲結構）。
2、相關場景的選擇依據。
3、工具的使用，指令碼的錄製。
4、主要效能指標。
5、基於工具結果的簡單分析。
原諒我當時的簡單樸素，能把握的就這些了。
後續的專案測試過程中，也有從事效能測試相關經歷，如稅企通專案（C/S架構）、省國稅入口網站等，但真正讓我記憶深刻並且獲益良多的是地稅的網上申報專案。
網報專案的相關合作方有多個，網路、防火牆、CA認證服務、核心申報等分別是不同的公司負責交付，如果測試過程中有出現問題，往往不好定位是誰的責任。
在這種情況下，瞭解系統的網路部署拓撲結構尤為重要，之後才是具體的測試場景開展。
具體的測試場景開展：
1、熟悉瞭解網路拓撲圖，相關機器、伺服器的物理及網路部署，為之後進行分層次測試做好準備。
2、併發數的計算，按照計算公式C=nL/T（C代表併發數，n代表平均線上人數，L代表場景操作時間，T代表場景考察時間）是比較理想化的，由於專案並沒有相關措施監控，因此難以獲取到平均線上人數、操作時間等具體引數。這時就要結合實際系統使用情況考慮。如系統納稅人總數及申報總數，每月申報時間（1日到15日，一般最後一週或者3天為大多數），每天申報時間（上午9：00-12：00以及下午14：00-17：00）等資訊去計算出每秒事務吞吐量即可得到併發數（事務吞吐量*業務場景時間）。
3、根據實際業務選擇需要測試的業務功能場景。
4、效能測試場景，如系統最大併發數，單個節點最大併發數，不同網路接入點最大併發數，穩定性測試等。
5、其他指標如響應時間、資源使用。
......
確定以上方案和指標之後再進行具體的準備和執行。
執行過程中，當然不會那麼順利，開始從系統最外圍即外網進行測試，結果不理想，那麼就要定位原因，過濾出指標差的業務場景，然後單獨測試，此時相關場景加上時間戳資訊，再在各個伺服器上採集日誌，之後為了確認真實，再更換不同伺服器地址進行測試對比不同接入點的結果。最後再拿具體的結果給對應的合作方討論分析。
整體的設計方案執行下來，花了不少的時間。
具體執行測試時，公司內部的功能還算順利，到分層測試時就比較麻煩。第一是需要在不同的辦公地點進行（不能直接訪問IP），專案組辦公室、稅局機房、聯通機房等，還記得在機房呆過一個晚上之後，汗漬都是綠的。遇到問題找合作方溝通時，響應速度跟指標差的場景一樣--慢。當然，自己的溝通方式也是有缺點的，比如跟合作方說你的系統有問題，不能僅是口頭形式，要包含具體證據（報錯日誌、測試結果報告等），並且定下解決時間，必要時還需要甲方在場。
但不管如何，最終是完成了原定的測試目標。過程是艱辛的，但讓我在今後的做事方式更加有條理、按步驟、踏實、耐心。
變化中成長
走過堤岸，有依依楊柳，邁入田野，是無邊麥浪。人總會經歷不同的旅途風景，在變化之間獲得不同的成長見識。
第一份工作經歷形成了我對測試的基本認識及工作方式，接到測試任務之後就會條件反射的設想需要開展的測試型別，相關方案。但對於這些工作是否可以更標準化、工程化的開展還只是一個朦朧的概念。
之後重新更換測試工作，工作開始並沒有什麼不同，只是測試執行之前要求必須編寫測試用例。但隨著時間的推移，讓我體驗到了不一樣的氛圍。
測試要儘早開始，並且排除隨意性，有計劃的進行，這是軟體測試基礎理論的原則之一。在公瑾，軟體開發過程有比較完善的流程，期間測試人員要經過需求評審、測試用例評審、預測試評審（提交測試前的評審，由開發演示實現的功能）、測試報告評審等。在需求評審之後，要有詳細的測試分析、用例，並且列入任務計劃進行監控，用例的執行結果也可隨時檢視，瞭解測試進度。
落地手工功能測試的同時，我們在持續進行自動化功能測試和效能測試工作。
在很多公司看來，自動化測試是一個比較矛盾的事情，總要考量人力消耗和迭代釋出版本維護原有指令碼的成本。在沒有建立自動化測試體系前，只能淪為個人興趣或者形式。
我們的自動化測試工作到目前已經走過2年時間，自動化功能測試覆蓋率達到95%以上，期間進行自動化測試的同學經歷了從無到有，再到完整，並且常態化執行。現在使用Selenium分散式執行多臺裝置上的指令碼，可以快速執行完原有功能的測試用例。在業務功能越來越複雜，測試用例越來越多的情況下，功能自動化測試的地位就越明顯。
而對於效能測試，也變得相對易於開展。相關係統的使用者使用場景資料可以輕鬆獲取（比如併發數計算），測試執行也已經形成了一個常態化機制，不是經過某次測試之後就不再進行，或者優化後再次測試還需要人工再做一次。目前的介面效能測試和系統效能測試在確定業務場景和指令碼後，具體的執行設計方案為自動每天執行，執行結果通過報表（不是測試工具本身的報表，而是測試結果儲存到資料庫後按照要求重新整理輸出報表）展現，相關負責人可以通過結果進行選擇性優化，然後再繼續測試。
不管是功能自動化測試，還是介面、系統效能測試，我們都已實現工程化、自動化的工作方式，也踐行了軟體測試中經常提及的測試應該要持續進行的原則。
很容易發現，以前是一個人在摸索中戰鬥，不斷的爬坑的測試過程，現在是工程化、自動化的在持續推進優化改進的過程。個人對體系趨勢，優劣不言而喻。
以下是個人測試經驗中的一些觀點：
1、儘量把測試往前推，儘早發現，降低修復成本；
2、測試的目的不是發現Bug，而是預防Bug的發生；
3、通過各種技術手段和流程改進，逐步的解放公司內部測試人員，讓他們把精力放在對產品的把握上。
特別是第2、3點，已經重新定位測試人員。而我們正在進行建設的自動化測試平臺（ATP），她減低功能自動化測試的技術門檻，整合各種型別測試工作，及時反饋測試分析結果，提高測試效率的同時，將真正釋放測試人員的能力，實現以上標準將不再是空談。雖然我們現在不能說我們的測試工作已經達到這樣的標準，但起碼我們現已經走在正確的道路上。只要方向是對的，那麼就一定會到達目標。
當然，不管有多好的工作起點平臺，測試人員的素質才是決定最終測試質量的保證。在從原有重複的工作方式中解放後，測試人員的綜合素質如所處行業知識、測試思維、測試設計方案都影響到具體的測試結果，這些都是工具、平臺無法取代的。
測試勉勵
IT工作是辛苦的，軟體測試當然也不例外。每天執行用例、跟蹤Bug，還要與開發、產品同學爭吵PK，與人鬥其樂無窮~但正是因為這些默默的付出，你讓一場本該在使用者面前發生的災難，提前在自己面前發生了，你是否有一種救世主的感覺？你拯救了使用者，也拯救了這一軟體，避免了她被撇棄、解除安裝的命運。
如果對軟體測試有興趣，想了解更多的測試知識，解決測試問題,以及入門指導，幫你解決測試中遇到的困惑，我們這裡有技術高手。如果你正在找工作或者剛剛學校出來，又或者已經工作但是經常覺得難點很多，覺得自己測試方面學的不夠精想要繼續學習的，想轉行怕學不會的，可以加入我的QQ群測試學習大家庭：1125760266