测试工作绝不仅限于点点点
? ? ? 經常聽到開發對我說,天天的點點點有意思沒?多么索然無味的工作啊,誠然測試在他們眼中就是為他們服務、打雜且十分無趣的工作。和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、吞吐量等指標。
說了這麼多,其實我想說明的就是測試的工作絕對不是只有點點點,只要你愿意挖掘,肯定還有很多值得測試、推敲的地方。另外測試無止境,每次的點點點都應該有目的、有測試依據,有意義。測試是一個逐步深入的過程,也是測試人員成長的過程,請大家相信,測試工作博大精深,做最好的測試,一定非常有前途!
?
轉載于:https://www.cnblogs.com/haibaowang/articles/7447712.html
總結
以上是生活随笔為你收集整理的测试工作绝不仅限于点点点的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: aka鉴权 ims_宋月:IMS鉴权过程
- 下一篇: 如何将宿舍门变成指纹开锁?