前言：
我們在變化中成長，假設你拒盡了變化，你就拒盡了新的美麗和新的機遇，今天一菲用親身經歷和你好好聊聊一個好的軟體測驗工程師應該做到哪些？
一.初始軟體測驗
我在沒有做測驗作業之前，如果你問我一個關于杯子的質量問題，我很會說兩個字，很好,但是現在的我就會想到很多這就是測驗人的格局我驕傲，
下面聽我絮叨一下，
還是這個問題，如果問我關于這個杯子的質量的問題，我會想到兩個大的方向：
1.質量問題包含哪些方面？即通常所說的需求是什么？
這里提兩個概念，就是==“顯性要求”和“隱性要求”，==
如顯性需求，首先應該是杯子，不是瓶子、盆子等等，用途是喝水的；隱性需求呢？那就比較籠統了，如大小、高度、容積、制作材料、溫度承受范圍，還有一些其他細節如顏色、邊角圓滑等，
2.如何去準確獲取、表現這些需求，即相關指標資料是多少？
這個時候我們就要知道它的大小、高度、容積，還有用到相關測量工具，如尺子、圓規，要知道溫度承受范圍，可能要用到溫度計等，
舉這個例子就是想告訴大家，在完成測驗作業期的整個程序當中，測驗設計執行之前，必須清晰了解它的顯性需求和隱性需求，再之后需要有對應的測驗方案和測驗方法，你還需要考慮到需要執行哪鐘型別測驗，要用到什么測驗工具等，就是我們必須知道設計測驗用例之前，對于該測驗專案上的基本點都有一個比較準確的認知，
二.功能測驗實踐
我的第一份作業接觸的專案是國稅門戶網站，所進行的測驗作業是主要是功能測驗，如測驗用例撰寫、執行，測驗報告反饋，當時對所謂的軟體生命周期都很模糊，感覺我只要做好自己的測驗任務就好了，其他的東西由上級安排就好，
但是在后面的作業當中，讓我真正接觸到了專案開發、交付的實際生產程序，簡而言之就是，作業任務是無止境的，永遠有數不盡的需求要開發、測驗，有茫茫多的Bug要跟蹤，如何在這中間保持自己清晰的定位顯得至關重要，由于在專案組中只有我一個測驗人員，那么結果就是，“測驗的事情就都是我的”，和我之前想的不一樣，應了那句話計劃該不是變化快，有或者說本來就是這樣，是我自己想的太美好，
每天我和高管的對話都是這樣子的，
1.“某某某，過來一下，這是這個版本修改的內容，大概是要在某月某日完成，你過（看）一下，”
“哦”，
2.到了測驗執行，發現問題后提交給開發同事，開發回復：“設計如此，”
“哦”，
3.快要上線了，專案經理問：“某某某，現在系統的測驗情況怎么樣，能不能上線？”
“應該差不多吧”
…
在做作業中，磕磕碰碰總結了以下經驗,不容易啊，
a、測驗的依據，需求基線一定要清楚，要盡早參與；
b、測驗要有計劃方案，要有用例設計，不能隨意的開展；
c、Bug的跟蹤，要有自己的主見、原則；
d、測驗結果的把握，要有結果分析，專案的上線，要綜合你的以上測驗程序，結合目前的情況總結報告，甚至是專案經理也要聽取你的意見，你的角色不僅是測驗，也是質量保證，
在后來的專案測驗作業中，踐行測驗主管傳遞的思想原則的同時，我并行了解相關測驗書籍、工具、技能，結合作業進行相關實踐，逐漸地我的測驗能力越來越強，
做了這么久的功能測驗之后，測驗程序中我變得更加有條理、原則、規范，但也僅是個人自覺的約束，很多程序并沒有按照軟體開發周期的標準來執行，如測驗用例、測驗報告有時候會在發布版本后才撰寫（雖然公司也通過了CMMI3），即測驗的質量保證更多的依賴個人的素質，所以品格決定了你作業的成功與否，那就是態度決定一切，
三.性能測驗實踐
測驗當然不僅有功能測驗，第一次接觸性能測驗也是在國稅門戶專案組，只不過測驗物件不是國稅門戶網站，其實那個軟體系統的具體業務我都不太清楚（慚愧），只知道是叫一戶式查詢系統，
在作業當中，我了解到同性能測驗的相關資訊，
a、系統的部署組成，相關的服務器有哪些（此時還不知道具體的網路拓撲結構），
b、相關場景的選擇依據，
c、工具的使用，腳本的錄制，
d、主要性能指標，
e、基于工具結果的簡單分析，
原諒我當時的簡單樸素，能把握的就這些了，
網報專案的相關合作方有多個，網路、防火墻、CA認證服務、核心申報等分別是不同的公司負責交付，如果測驗程序中有出現問題，往往不好定位是誰的責任，在這種情況下，了解系統的網路部署的設計結構是十分關鍵的，接下來誰開展具體的測驗場景，
四.具體的測驗場景開展
a 、熟悉了解網路拓撲圖，相關機器、服務器的物理及網路部署，為之后進行分層次測驗做好準備，
b、并發數的計算，按照計算公式C=nL/T是比較理想化的，由于專案并沒有相關措施監控，因此難以獲取到平均在線人數、操作時間等具體引數，
c、根據實際業務選擇需要測驗的業務功能場景，
d、性能測驗場景，如系統最大并發數，單個節點最大并發數，不同網路接入點最大并發數，穩定性測驗等，
e、其他指標如回應時間、資源使用，
五.確定以上方案和指標之后再進行具體的準備和執行，
a.執行程序中，肯定會出現些許問題，開始從系統最外圍即外網進行測驗，
b.如果結果不理想，那么就要定位原因，過濾出指標差的業務場景.
c.然后單獨測驗，此時相關場景加上時間戳資訊，再在各個服務器上采集日志，
d.之后為了確認真實，再更換不同服務器地址進行測驗對比不同接入點的結果，
e.最后就是拿具體的結果給對應的合作方討論分析，
整體的設計方案執行下來，花了不少的時間，
雖然這個程序比較繁瑣和曲折，但是最終是完成了原定的測驗目標，程序是艱辛的，但讓我在今后的做事方式更加有條理、按步驟、踏實、耐心，所以應了那句話，陽光總在風雨后，不經歷風雨怎能見彩虹，真香定律！
在這里推薦一個軟體測驗交流群，QQ：642830685，群中會不期的分享軟體測驗資源，測驗面試題以及行業資訊，大家可以在群中積極交流技術問題，
六.變化中成長
走過堤岸，有依依楊柳，邁入田野，是無邊麥浪，人總會經歷不同的旅途風景，在變化之間獲得不同的成長見識，
第一份作業經歷形成了我對測驗的基本認識及作業方式，接到測驗任務之后就會條件反射的設想需要開展的測驗型別，相關方案，但對于這些作業是否可以更標準化、工程化的開展還只是一個朦朧的概念，之后重新更換測驗作業，作業開始并沒有什么不同，只是測驗執行之前要求必須撰寫測驗用例，但隨著時間的推移，讓我體驗到了不一樣的氛圍，所以測驗要盡早開始，并且排除隨意性，有計劃的進行，這是軟體測驗基礎理論的原則之一，落地手工功能測驗的同時，我們在持續進行自動化功能測驗和性能測驗作業，
不管是功能自動化測驗，還是介面、系統性能測驗，我們都已實作工程化、自動化的作業方式，也踐行了軟體測驗中經常提及的測驗應該要持續進行的原則，
七.以下是個人測驗經驗中的一些觀點：
a、盡量把測驗往前推，盡早發現，降低修復成本；
b、測驗的目的不是發現Bug，而是預防Bug的發生；
c、通過各種技術手段和流程改進，逐步的解放公司內部測驗人員，讓他們把精力放在對產品的把握上，
當然，不管有多好的作業起點平臺，測驗人員的素質才是決定最終測驗質量的保證，在從原有重復的作業方式中解放后，測驗人員的綜合素質如所處行業知識、測驗思維、測驗設計方案都影響到具體的測驗結果，所以隨著大環境的轉變，傳統的功能測驗已經被自動化測驗所沖擊，但是測驗是技術為王，所以只有不斷的汲取新的知識和技能，才能讓自己充滿競爭力，不會被行業淘汰，
八.寫在最后:
軟體測驗的作業是辛苦的，每天需要執行用例、跟蹤Bug，還要與開發、產品同事做辯論，但正是因為這些默默的付出，你讓一場本該在用戶面前發生的災難，提前在自己面前發生了，怎么樣，親眼看著自己設計的專案出現了bug ,開心嗎？
在這里推薦一個軟體測驗交流群，QQ：642830685，群中會不定期的分享軟體測驗資源，測驗面試題以及行業資訊，風里雨里我在群中等你，看完后別忘舉起你可愛的小手給我點個贊，你的點贊是我持續更文的不竭動力，筆芯！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/251455.html
標籤：其他
上一篇：全方位為你剖析軟體測驗是啥？