經常聽到開發對我說，天天的點點點有意思沒？多么索然無味的工作啊，誠然測試在他們眼中就是為他們服務、打雜且十分無趣的工作。和IT圈外的同學、朋友聊起自己的工作，往往一說自己是測試，無形中也會被大家輕視，總有人會問你，為啥干測試啊，怎么不干開發呢？不可置否，在他們心中，你肯定是因為能力不足，無法勝任開發的工作，退而求其次，只能干著平凡、索然無味的測試工作。
? ? ?可以這樣說，無論是開發的說辭還是朋友們的質疑，這些都不是重點。重要的是你自己難道也認為測試的工作就是單純的點點點嗎？如果你這么認為了，好吧那我奉勸您趕快轉行，因為你在浪費自己的光陰，一寸光陰一寸金啊，不必在軟件測試這條路上走下去了。因為你的目標和思想已經固化、停滯不前了。如果你不同意開發的說法，那我恭喜你，聽我給你分析分析測試到底是不是只是點點點的工作。
? ? 為了描述的更加形象生動，我這里給自己設定一個測試背景，這個背景大家都非常熟悉。就是如下所示的QQ登陸界面。

假設現在你的工作就是測試QQ的登陸功能。你該如何做？
1、充分閱讀需求說明書，開發的設計文檔，理解項目背景，熟練掌握開發的設計方案。
這里注意一個問題，現在是提倡敏捷測試的時代，有時候需求來了只是郵件、口頭描述形式。此時我們要快速介入測試，肯定需要通過各個途徑來了解需求，最直觀最快速的方法肯定是有效的溝通。溝通里面還有一個重要的點：那就是學會問題。如果是我我會快速弄清楚以下問題，然后著手測試：
（1）產品和特性是由哪個開發具體負責的。（把功能與開發人員進行映射，方便后續問問題）。
（2）開發團隊的規模如何，開發人員的經驗分布怎樣？肯定有人會問了解這個有什么用呢？，當然有用，軟件是由人開發的，開發者的經驗決定他的技術水平，舉個簡單的例子：1個具有開發工作10年經驗的開發和一個剛剛參加工作半年的開發，同時開發一個功能。你拿到后從心里面更傾向于誰？
（3）同開發溝通清楚哪部分內容實在原有某某功能上改進的，哪些功能是重新開發的，這又說明兩個問題：如果是在某個功能的基礎上進行開發的，那么風險評估就會小些，技術比較成熟。
如果是新開發的內容，那么就可能采取了新技術，那么此時的風險肯定會超出預期，需要我們仔細測試。
（4）開發人員是否已經進行了自測，自測的覆蓋率如何，自測過程中遇到什么問題？了解這個可以叫我們開拓視野，遇到類似的功能時也關注下是否還存在未修改的點。
（5）還有沒有未解決的開發問題，以及未提測的開發流程。好些開發提測軟件功能的時候，把測試點說的非常粗，其中有部分有可能就沒有開發，但是不明確指出，這時就需要我們通過溝通快速獲取。
（6）最后才是應該耐心向開發請教軟件具體功能實現的過程。實現不合理的及時和需求碰頭。
2、在充分理解業務場景的基礎上，編寫測試用例。
3、溝通項目預期上線的進度，排好測試計劃。注意一定要預留出至少兩天的富裕時間，以防止突然修改需求造成的措手不及。
4、執行測試用例。我把可能大家普遍想到的功能點羅列一下，包含以下部分：
（1）錄入框（inputtext）支持的長度
（2）錄入框支持的錄入格式有哪些（主要是字母區分大小寫、數字、特殊符號）
（3）QQ號碼錄入正確，密碼錄入不正確，軟件功能如何響應。
（4）QQ號碼不正確，密碼錄入正確，軟件功能如何響應。
（5）QQ號碼和密碼錄入的一致，軟件功能如何響應。
（6）勾選自動登錄
（7）勾選記住密碼、再次登錄。
? ? ? ?等等這些基本的流程測試完畢，請問測試工作就這麼結束了嗎？如果閱讀的你認為是，那我只能說很遺憾，其實我們到此為止，不留情面的說相當于什么都沒做。請看我們還需要測試什么？
（1）驗證QQ號碼和密碼錄入框是否有SQL注入風險（擴展到安全測試了，這里要說的東西太多了，不多說）。
（2）不同的QQ號碼是否可以使用同一個密碼（探索性測試）；
（3）QQ號碼不錄入，只錄入密碼，點擊登錄按鈕。
（4）QQ號碼錄入，不錄入密碼，點擊登錄按鈕。
（5）QQ號碼、密碼都不錄入，點擊登錄按鈕。
（6）QQ號碼與密碼不匹配錄入，點擊登錄按鈕。
（7）驗證新注冊成功的用戶和歷史已經注冊過的用戶登陸過程進行比較。保證歷史數據無誤。
? ? ?到這里是不是又有人覺得測試已經完備了呢？答案是否定的？為什么這么說？因為你執行完上述兩部分的測試工作，只能說簡單的覆蓋了前端（即客戶端的工作），顯然地，數據庫、服務端也還有著對應的測試工作。
數據庫：
（1）正確且匹配的QQ號、密碼是不是已經正確存儲。
（2）不正確的QQ號或者密碼，再或者QQ號與密碼不匹配時，是不是不存儲。
（3）存儲的QQ號和密碼是不是已經做了加密處理。（出于客戶安全性的考慮）
（4）數據庫表的命名是否規范，字段命名是否規范，類型是否與前端一致，長度是不是與前端一致。
（5）前端登陸成功與后端數據庫存儲是不是處在同一個事務中。這個可以這樣理解：如果我們在登陸QQ的過程中，突然網絡出現異常，那么此時我們希望數據庫如何處理呢？
? ? ? 假設不在同一個事務中，那么如果存儲此次登陸過程，則在網絡恢復后，用戶在登陸將會報重復登陸錯誤。如果處在同一個事務中，那么登陸失敗后，數據庫不會更新記錄任何本次登陸信息，已經存儲的表進行回滾，直到登陸的初始狀態。很顯然地，需要我們根據實際需求具體分析，得出采取哪種方式。
服務器端：
進行性能測試針對多個不同的用戶同時登陸時，確認會不會對服務器產生壓力，并且通過響應時間、TPS、內存、網絡等性能指標驗證系統是不是滿足要求。看，我們從一開始的功能測試一路測試，一路探索。慢慢的深入到了性能測試。測試的流程如下：

其中功能測試我們分為：基本流程、異常流程、探索流程進行
? ? ? ?安全測試我們著重：關注最可能發生的SQL注入風險（取最高級別的測試用例）
? ? ? ?性能測試我們關注：網絡、并發、內存、CPU、TPS、吞吐量等指標。
說了這麼多，其實我想說明的就是測試的工作絕對不是只有點點點，只要你愿意挖掘，肯定還有很多值得測試、推敲的地方。另外測試無止境，每次的點點點都應該有目的、有測試依據，有意義。測試是一個逐步深入的過程，也是測試人員成長的過程，請大家相信，測試工作博大精深，做最好的測試，一定非常有前途！

總結

以上是生活随笔為你收集整理的测试就是点点点？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。