我們在變化中成長。假設你拒盡了變化，你就拒盡了新的美麗和新的機遇。

初始軟件測試

“這是一個杯子，主要用來喝水的，它的質量應該如何考量？”

這是在進入上家公司面試時，測試主管問我的題目，相關的回答已經有點模糊，但從這個問題可以大概了解到，測試主管在考察我的測試思維。

首先，這個杯子的質量包含哪些方面？即通常所說的需求是什么？如顯性需求，首先應該是杯子，不是瓶子、罐子等，用途是喝水的；隱性需求呢？那就比較籠統了，如大小、高度、容積、制作材料、溫度承受范圍，還有一些其他細節如顏色、邊角圓滑等。

其次，如何去準確獲取、表現這些需求，即相關指標數據是多少。如要知道大小、高度、容積，得用到相關測量工具，如尺子、圓規。要知道溫度承受范圍，可能要用到溫度計等。

在完成測試工作期間，測試設計、執行之前必須清晰了解原始需求（包括隱性需求），再之后需要有對應的測試方案，需要執行哪些類型測試，要用到什么測試工具等。

很感謝當初測試主管對我測試工作的指導，不僅僅是在具體的技能培訓上，還在其他的工作當中對我測試思維的引導。

功能測試實踐

面試過后進入公司，最開始接觸的項目是國稅門戶網站，所進行的測試工作是主要是功能測試，如測試用例編寫、執行，測試報告反饋。當時對所謂的軟件生命周期都很模糊，感覺我只要做好自己的測試任務就好了，其他的東西由上級安排就好。現在想想真的好白，白癡的白。在接下來的一年時間，讓我真正接觸到了項目開發、交付的實際生產過程，簡而言之就是，工作任務是無止境的，永遠有數不盡的需求要開發、測試，有茫茫多的Bug要跟蹤。如何在這中間保持自己清晰的定位顯得至關重要。由于在項目組中只有我一個測試人員，那么結果就是，“測試的事情就都是我的”，好像很厲害的樣子。但我還只是小白啊。

“某某某，過來一下，這是這個版本修改的內容，大概是要在某月某日完成，你過（看）一下。”

“哦”。

到了測試執行，發現問題后提交給開發同事，開發回復：“設計如此。”

“哦”。

快要上線了，項目經理問：“某某某，現在系統的測試情況怎么樣，能不能上線？”

“應該差不多吧”

。..。..

測試主管了解之后，跟我強調了幾點：

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，與人斗其樂無窮~但正是因為這些默默的付出，你讓一場本該在用戶面前發生的災難，提前在自己面前發生了，你是否有一種救世主的感覺？你拯救了用戶，也拯救了這一軟件，避免了她被撇棄、卸載的命運。