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

初始軟件測試

“這是一個杯子，主要用來喝水的，它的質(zhì)量應(yīng)該如何考量？”

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

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

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

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

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

功能測試實踐

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

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

“哦”。

到了測試執(zhí)行，發(fā)現(xiàn)問題后提交給開發(fā)同事，開發(fā)回復(fù)：“設(shè)計如此。”

“哦”。

快要上線了，項目經(jīng)理問：“某某某，現(xiàn)在系統(tǒng)的測試情況怎么樣，能不能上線？”

“應(yīng)該差不多吧”

。..。..

測試主管了解之后，跟我強調(diào)了幾點：

1、測試的依據(jù)，需求基線要清楚，要盡早參與；

2、測試要有計劃方案，要有用例設(shè)計，不能隨意的開展；

3、Bug的跟蹤，要有自己的主見、原則；

4、測試結(jié)果的把握，要有結(jié)果分析。項目的上線，要綜合你的以上測試過程，結(jié)合目前的情況總結(jié)報告，甚至是項目經(jīng)理也要聽取你的意見。你的角色不僅是測試，也是質(zhì)量保證。

當然，以上的情況只是測試中遇到問題的一點點，如沙漠中的一粒沙（這孩子究竟怎么過來的），但也讓我認識到測試是獨立的、重要的。

在后來的項目測試工作中，踐行測試主管傳遞的思想原則的同時，我并行了解相關(guān)測試書籍、工具、技能，結(jié)合工作進行相關(guān)實踐，逐漸地我的測試能力越來越強。

在省國稅外派了一年，之后測試過程中更加有條理、原則、規(guī)范。但也僅是個人自覺的約束，很多過程并沒有按照軟件開發(fā)周期的標準來執(zhí)行，如測試用例、測試報告有時候會在發(fā)布版本后才編寫（雖然公司也通過了CMMI3），即測試的質(zhì)量保證更多的依賴個人的素質(zhì)。并且，當時個人認為測試的業(yè)務(wù)熟練更多決定于對系統(tǒng)功能本身的熟悉和測試設(shè)計執(zhí)行的熟悉，認識到錯誤并且有意識改變是在地稅的定點聯(lián)系企業(yè)管理系統(tǒng)和電子辦稅服務(wù)廳的測試過程。

之后，進入到地稅的定點聯(lián)系企業(yè)管理系統(tǒng)項目組進行測試。當時項目已快要進入驗收階段，甲方要求的功能基本都有實現(xiàn)，但在交付時甲方卻不滿意，在一些功能的易用性和系統(tǒng)界面展示上提了很多要求，導(dǎo)致整個系統(tǒng)最后框架、原型都換了一遍，而且限定修改的時間很短（又是一個加班加點的開始），最后甚至項目負責(zé)人都換了。

總結(jié)了下，有幾個方面問題：

1、既定清晰的需求都有按要求實現(xiàn)，只不過實現(xiàn)方式不合甲方胃口，如圖表不夠豐富，只有概要，沒有詳細。

2、系統(tǒng)界面沒有統(tǒng)一的樣式，甲方不客氣的說像草稿。

3、流程沒有體現(xiàn)甲方日常工作內(nèi)容、步驟。

4、風(fēng)控系統(tǒng)很膚淺，指標不實用。

在這個測試過程中，我比較正式地參加甲方組織的各種需求討論會議，期間也認識到原始需求到需求基線其實還是有設(shè)計落實過程的，其把握的度就要看負責(zé)人或產(chǎn)品經(jīng)理的靈性了。作為測試人員，在需求評審過程中就要對比原始需求（要詳細了解具體日常工作內(nèi)容，行業(yè)特殊性等）和需求基線的不同，給予自己的意見，在測試過程中不時提醒自己。而對需求的理解是否深刻，有時候不是參加正式需求評審就能達到的，還需要深入到用戶實際的工作場景，了解實際業(yè)務(wù)和流程。而對于自己無法準確把握（風(fēng)控系統(tǒng)），用戶又無法準確提供的需求就要定好界限，實現(xiàn)到什么程度。最后，好用的軟件不僅是功能的實現(xiàn)，一個界面樣式都能讓你從頭再來。原計劃短期內(nèi)交付的項目，由于后續(xù)各種修改需求一直到了次年3月，才基本結(jié)束相關(guān)測試活動。

完成定點聯(lián)系企業(yè)管理系統(tǒng)的測試之后，我進入了電子辦稅服務(wù)廳項目組，在這里個人的業(yè)務(wù)掌握程度得到認可。首先，對核心系統(tǒng)（電子辦稅服務(wù)廳接口調(diào)用提供方）的相關(guān)業(yè)務(wù)（文書、申報等）熟悉，并與對應(yīng)系統(tǒng)的中軟項目組人員都可以打成一片（也是吸取在陜西時溝通不順的教訓(xùn)，詳細后面性能測試提到）。其次，對電子辦稅廳的需求理解充分，得益于當時的需求人員耐心引導(dǎo)（為了稅務(wù)事業(yè)，頭發(fā)都花白了的同事），最后是自己對相關(guān)系統(tǒng)的后臺數(shù)據(jù)表結(jié)構(gòu)都比較熟悉。出現(xiàn)問題之后，能快速的理清思路，定位原因。問題出現(xiàn)之后，當你有理有據(jù)的跟相關(guān)負責(zé)人溝通時，他們也會心悅誠服。在經(jīng)過一年多的團隊配合之后項目組啟動跟金三對接工作（要2個月完成，又是看星星賞月亮的好時光），項目經(jīng)理將接口聯(lián)調(diào)的任務(wù)交由我負責(zé)，也是看在我對原有兩方系統(tǒng)及人員的了解。

性能測試實踐

測試當然不僅有功能測試。第一次接觸性能測試也是在國稅門戶項目組，只不過測試對象不是國稅門戶網(wǎng)站。其實那個軟件系統(tǒng)的具體業(yè)務(wù)我都不太清楚（慚愧），只知道是叫一戶式查詢系統(tǒng)。當時雖然了解過性能測試的原理，但是具體如何開展還是有點懵逼。在測試主管的協(xié)助指導(dǎo)下（說是一步一扶都不過分），艱難完成。

在此，額外截取下當時某個業(yè)務(wù)場景測試的結(jié)果數(shù)據(jù)（沒有找到曲線圖了，發(fā)一下當時用表格記錄的數(shù)據(jù)，你沒看錯，是5并發(fā)時間95s！！！）

執(zhí)行這次測試之后，了解到同性能測試如下相關(guān)信息：

1、系統(tǒng)的部署組成，相關(guān)的服務(wù)器有哪些（此時還不知道具體的網(wǎng)絡(luò)拓撲結(jié)構(gòu)）。

2、相關(guān)場景的選擇依據(jù)。

3、工具的使用，腳本的錄制。

4、主要性能指標。

5、基于工具結(jié)果的簡單分析。

原諒我當時的簡單樸素，能把握的就這些了。

后續(xù)的項目測試過程中，也有從事性能測試相關(guān)經(jīng)歷，如稅企通項目（C/S架構(gòu)）、省國稅門戶網(wǎng)站等，但真正讓我記憶深刻并且獲益良多的是地稅的網(wǎng)上申報項目。

網(wǎng)報項目的相關(guān)合作方有多個，網(wǎng)絡(luò)、防火墻、CA認證服務(wù)、核心申報等分別是不同的公司負責(zé)交付，如果測試過程中有出現(xiàn)問題，往往不好定位是誰的責(zé)任。

在這種情況下，了解系統(tǒng)的網(wǎng)絡(luò)部署拓撲結(jié)構(gòu)尤為重要，之后才是具體的測試場景開展。

具體的測試場景開展：

1、熟悉了解網(wǎng)絡(luò)拓撲圖，相關(guān)機器、服務(wù)器的物理及網(wǎng)絡(luò)部署，為之后進行分層次測試做好準備。

2、并發(fā)數(shù)的計算，按照計算公式C=nL/T（C代表并發(fā)數(shù)，n代表平均在線人數(shù)，L代表場景操作時間，T代表場景考察時間）是比較理想化的，由于項目并沒有相關(guān)措施監(jiān)控，因此難以獲取到平均在線人數(shù)、操作時間等具體參數(shù)。這時就要結(jié)合實際系統(tǒng)使用情況考慮。如系統(tǒng)納稅人總數(shù)及申報總數(shù)，每月申報時間（1日到15日，一般最后一周或者3天為大多數(shù)），每天申報時間（上午9：00-12：00以及下午14：00-17：00）等信息去計算出每秒事務(wù)吞吐量即可得到并發(fā)數(shù)（事務(wù)吞吐量*業(yè)務(wù)場景時間）。

3、根據(jù)實際業(yè)務(wù)選擇需要測試的業(yè)務(wù)功能場景。

4、性能測試場景，如系統(tǒng)最大并發(fā)數(shù)，單個節(jié)點最大并發(fā)數(shù)，不同網(wǎng)絡(luò)接入點最大并發(fā)數(shù)，穩(wěn)定性測試等。

5、其他指標如響應(yīng)時間、資源使用。

確定以上方案和指標之后再進行具體的準備和執(zhí)行。

執(zhí)行過程中，當然不會那么順利，開始從系統(tǒng)最外圍即外網(wǎng)進行測試，結(jié)果不理想，那么就要定位原因，過濾出指標差的業(yè)務(wù)場景，然后單獨測試，此時相關(guān)場景加上時間戳信息，再在各個服務(wù)器上采集日志，之后為了確認真實，再更換不同服務(wù)器地址進行測試對比不同接入點的結(jié)果。最后再拿具體的結(jié)果給對應(yīng)的合作方討論分析。

整體的設(shè)計方案執(zhí)行下來，花了不少的時間。

具體執(zhí)行測試時，公司內(nèi)部的功能還算順利，到分層測試時就比較麻煩。第一是需要在不同的辦公地點進行（不能直接訪問IP），項目組辦公室、稅局機房、聯(lián)通機房等，還記得在機房呆過一個晚上之后，汗?jié)n都是綠的。遇到問題找合作方溝通時，響應(yīng)速度跟指標差的場景一樣--慢。當然，自己的溝通方式也是有缺點的，比如跟合作方說你的系統(tǒng)有問題，不能僅是口頭形式，要包含具體證據(jù)（報錯日志、測試結(jié)果報告等），并且定下解決時間，必要時還需要甲方在場。

但不管如何，最終是完成了原定的測試目標。過程是艱辛的，但讓我在今后的做事方式更加有條理、按步驟、踏實、耐心。

變化中成長

走過堤岸，有依依楊柳，邁入田野，是無邊麥浪。人總會經(jīng)歷不同的旅途風(fēng)景，在變化之間獲得不同的成長見識。

第一份工作經(jīng)歷形成了我對測試的基本認識及工作方式，接到測試任務(wù)之后就會條件反射的設(shè)想需要開展的測試類型，相關(guān)方案。但對于這些工作是否可以更標準化、工程化的開展還只是一個朦朧的概念。

之后重新更換測試工作，工作開始并沒有什么不同，只是測試執(zhí)行之前要求必須編寫測試用例。但隨著時間的推移，讓我體驗到了不一樣的氛圍。

測試要盡早開始，并且排除隨意性，有計劃的進行，這是軟件測試基礎(chǔ)理論的原則之一。在公瑾，軟件開發(fā)過程有比較完善的流程，期間測試人員要經(jīng)過需求評審、測試用例評審、預(yù)測試評審（提交測試前的評審，由開發(fā)演示實現(xiàn)的功能）、測試報告評審等。在需求評審之后，要有詳細的測試分析、用例，并且列入任務(wù)計劃進行監(jiān)控，用例的執(zhí)行結(jié)果也可隨時查看，了解測試進度。

落地手工功能測試的同時，我們在持續(xù)進行自動化功能測試和性能測試工作。

在很多公司看來，自動化測試是一個比較矛盾的事情，總要考量人力消耗和迭代發(fā)布版本維護原有腳本的成本。在沒有建立自動化測試體系前，只能淪為個人興趣或者形式。

我們的自動化測試工作到目前已經(jīng)走過2年時間，自動化功能測試覆蓋率達到95%以上，期間進行自動化測試的同學(xué)經(jīng)歷了從無到有，再到完整，并且常態(tài)化執(zhí)行。現(xiàn)在使用Selenium分布式運行多臺設(shè)備上的腳本，可以快速執(zhí)行完原有功能的測試用例。在業(yè)務(wù)功能越來越復(fù)雜，測試用例越來越多的情況下，功能自動化測試的地位就越明顯。

而對于性能測試，也變得相對易于開展。相關(guān)系統(tǒng)的用戶使用場景數(shù)據(jù)可以輕松獲取（比如并發(fā)數(shù)計算），測試執(zhí)行也已經(jīng)形成了一個常態(tài)化機制，不是經(jīng)過某次測試之后就不再進行，或者優(yōu)化后再次測試還需要人工再做一次。目前的接口性能測試和系統(tǒng)性能測試在確定業(yè)務(wù)場景和腳本后，具體的運行設(shè)計方案為自動每天執(zhí)行，執(zhí)行結(jié)果通過報表（不是測試工具本身的報表，而是測試結(jié)果保存到數(shù)據(jù)庫后按照要求重新整理輸出報表）展現(xiàn)，相關(guān)負責(zé)人可以通過結(jié)果進行選擇性優(yōu)化，然后再繼續(xù)測試。

不管是功能自動化測試，還是接口、系統(tǒng)性能測試，我們都已實現(xiàn)工程化、自動化的工作方式，也踐行了軟件測試中經(jīng)常提及的測試應(yīng)該要持續(xù)進行的原則。

很容易發(fā)現(xiàn)，以前是一個人在摸索中戰(zhàn)斗，不斷的爬坑的測試過程，現(xiàn)在是工程化、自動化的在持續(xù)推進優(yōu)化改進的過程。個人對體系趨勢，優(yōu)劣不言而喻。

以下是個人測試經(jīng)驗中的一些觀點：

1、盡量把測試往前推，盡早發(fā)現(xiàn)，降低修復(fù)成本；

2、測試的目的不是發(fā)現(xiàn)Bug，而是預(yù)防Bug的發(fā)生；

3、通過各種技術(shù)手段和流程改進，逐步的解放公司內(nèi)部測試人員，讓他們把精力放在對產(chǎn)品的把握上。

特別是第2、3點，已經(jīng)重新定位測試人員。而我們正在進行建設(shè)的自動化測試平臺（ATP），她減低功能自動化測試的技術(shù)門檻，整合各種類型測試工作，及時反饋測試分析結(jié)果，提高測試效率的同時，將真正釋放測試人員的能力，實現(xiàn)以上標準將不再是空談。雖然我們現(xiàn)在不能說我們的測試工作已經(jīng)達到這樣的標準，但起碼我們現(xiàn)已經(jīng)走在正確的道路上。只要方向是對的，那么就一定會到達目標。

當然，不管有多好的工作起點平臺，測試人員的素質(zhì)才是決定最終測試質(zhì)量的保證。在從原有重復(fù)的工作方式中解放后，測試人員的綜合素質(zhì)如所處行業(yè)知識、測試思維、測試設(shè)計方案都影響到具體的測試結(jié)果，這些都是工具、平臺無法取代的。

測試勉勵

IT工作是辛苦的，軟件測試當然也不例外。每天執(zhí)行用例、跟蹤Bug，還要與開發(fā)、產(chǎn)品同學(xué)爭吵PK，與人斗其樂無窮~但正是因為這些默默的付出，你讓一場本該在用戶面前發(fā)生的災(zāi)難，提前在自己面前發(fā)生了，你是否有一種救世主的感覺？你拯救了用戶，也拯救了這一軟件，避免了她被撇棄、卸載的命運。