質量監(jiān)控的范圍和概念
1用戶體驗是否舒服：
以用戶的角度對產(chǎn)品進行使用潮针，以找到不合理震庭，體驗差的功能點
2產(chǎn)品設計是否符合：
以產(chǎn)品的角度對產(chǎn)品設計的完整性進行檢驗
3性能狀況是否穩(wěn)定：
以系統(tǒng)運維的角度找到產(chǎn)品性能的瓶頸
4邏輯設計是否存在漏洞：
以開發(fā)人員的角度檢測產(chǎn)品的邏輯合理性
5 系統(tǒng)安全，數(shù)據(jù)安全是否有保障：
以不法分子疫粥，黑客的角度對產(chǎn)品進行攻擊，以檢測產(chǎn)品的安全性
測試用例設計方法：
軟測行內共識的設計方法不再贅述，轉帖一篇文章小白們可以自己去看：
已有的常規(guī)方法我們可以照搬照用瑟啃，但是從質量管理的整體性來說，它僅僅是功能邏輯維度揩尸，主要參照物是產(chǎn)品設計文檔蛹屿，所以我要補充的是另外的幾個維度。
所以包含上述方法在內做個補充：
產(chǎn)品邏輯維度：
等價類岩榆，邊界值错负，錯誤推測，判定表法勇边，正交實驗
文字邏輯維度：
主語犹撒，謂語，賓語粒褒，定語油航，狀語，補語為邏輯描述的基本要素怀浆。
其中谊囚，主語，賓語通常是用戶和客戶端的關系执赡，謂語可以理解為動作镰踏，定語狀語為限制條件，補語為補充條件沙合。
首先是正常語句奠伪，其次逐級否定，最后是逐級反義。（有關這個方法本人已經(jīng)用程序實現(xiàn)绊率，可以自動化生成）
UI維度
通常由UI設計師進行檢查谨敛，但是也有可能需要測試人員進行檢查。人工檢測包括字體滤否，字號脸狸，色值，布局藐俺。
寫過UI自動化的都知道炊甲，UI自動化的主要原理是頁面元素的的識別和命令賦予。
所以大致我們把它分為以下幾個設計方法：
1欲芹、文本框：字符類型卿啡，空，等價類菱父，邊界值颈娜，特殊字符,編程語言關鍵字，sql關鍵字浙宜。
字符類型的限制走的是if和else,空值走的是null的判斷官辽，等價類邊界值走的也是if邏輯，特殊字符主要是考驗數(shù)據(jù)庫的兼容性梆奈，編程語言和sql關鍵字考驗的是程序安全野崇，避免報錯信息出現(xiàn)代碼片段，sql語句亩钟。
2乓梨、復選框：數(shù)據(jù)來源，長度清酥，數(shù)據(jù)量
其中需要注意上下左右是否超出頁面范圍扶镀，數(shù)據(jù)量考驗的是響應時間和頁面內存。
3焰轻、列表：數(shù)據(jù)來源臭觉，數(shù)據(jù)量，翻頁
這里說一下翻頁辱志，翻頁主要驗證的是sql是否有問題蝠筑，數(shù)據(jù)是否重復，limit銜接處是否有重復揩懒。
4什乙、按鈕：單擊，雙擊已球，長按臣镣，長按移開辅愿，多點觸發(fā)
重點說一下不符合產(chǎn)品設計操作的手勢，比如單擊按鈕雙擊是否造成重復命令忆某，頁面重疊点待，請求重復（數(shù)據(jù)安全）。多點觸發(fā)后是否出現(xiàn)重復頁面和矛盾請求弃舒。這里面的形成的異常測試癞埠，最嚴重的后果就是產(chǎn)生垃圾數(shù)據(jù)。
5棒坏、頁面跳轉：中斷燕差，返回遭笋。
主要監(jiān)測的是緩存是否正確坝冕，或者無效頁面是否創(chuàng)建垃圾數(shù)據(jù)。
6瓦呼、多媒體：圖片喂窟，語音，視頻央串。正常查看磨澡，放大，音量质和，暫停稳摄，快進等常規(guī)性驗證。
設備維度
1饲宿、設備按鍵：比如安卓手機：back鍵厦酬，menu鍵，home鍵瘫想。截圖仗阅，錄屏，旋轉屏国夜，耳機减噪，音量，鎖屏车吹，左右滑動筹裕。電腦鍵盤：回車，方向page,home,end,backspace,insert,delete,printscr等是否符合用戶習慣窄驹，尤其產(chǎn)品文檔不太可能涉及這些細節(jié)時朝卒，這里應該遵循用戶習慣。
2馒吴、附件上傳或下載：文件格式扎运，下載方式瑟曲。
3、系統(tǒng)安全攔截：應該使用主流的殺毒軟件豪治，系統(tǒng)管家等對app或者網(wǎng)頁進行檢測洞拨，一方面如果確實有帶著病毒或者廣告的三方庫或者框架，也能及時找出负拟，避免發(fā)布上線后因為類似原因造成損失烦衣。
4、內存管理：程序本身的運行需要占用一定的內存空間掩浙，如果涉及到本地存儲花吟，分為兩個方向。第一個方向是厨姚，驗證程序本身申請的內存大小的邊界衅澈。第二是驗證或計算設備本身的內存多久可以占滿。通過程序本身或者系統(tǒng)管家類軟件能否清理谬墙。
5今布、網(wǎng)絡:包括有線，wifi拭抬，2g,3g,4g,5g...網(wǎng)絡下的超時表現(xiàn)部默，網(wǎng)絡切換表現(xiàn)。
6造虎、三方服務：比如音頻播放器傅蹂，視頻播放器，特定格式的編輯器算凿，查看器份蝴，瀏覽器，多媒體輸入/輸出設備的兼容系澎媒。三方服務是否能夠有效支撐搞乏，是否存在漏洞。如云服務戒努，地圖请敦，聊天，輸入法储玫，各類前后端框架是否對我方程序有不合理限制侍筛。
7、系統(tǒng)：系統(tǒng)版本撒穷，內核版本匣椰，蘋果，安卓端礼，windows禽笑，安卓定制化系統(tǒng)（如小米入录，華為，三星佳镜，OPPO僚稿，可參考市場占有率酌情選擇），瀏覽器類型及版本（IE蟀伸，谷歌蚀同，360，火狐等）啊掏，兼容性測試的抽樣選型蠢络，以產(chǎn)品要求為主，或者以用戶量為主迟蜜。
接口維度
包括調用是否正確刹孔，是否有次數(shù)限制，參數(shù)類型限制小泉，響應時間芦疏，并發(fā)冕杠，穩(wěn)定性微姊。
存儲維度
包含數(shù)據(jù)庫，緩存服務分预，隊列服務兢交，搜索引擎。存儲是否有字段缺失笼痹，獲取是否準確配喳。高可用，并發(fā)凳干，穩(wěn)定性晴裹。
性能維度
性能維度其實在上面已經(jīng)涉及到了。但是這里也單獨說一下救赐。他包含客戶端和服務端兩個方面涧团。客戶端主要是內存上的抗壓力经磅。服務端主要是并發(fā)請求的抗壓力泌绣。同時兩端都需要進行穩(wěn)定性測試。
安全維度
攻擊预厌，竊取等方式手段有多種多樣阿迈。用戶資料主要存儲于數(shù)據(jù)庫和緩存服務器，或者是搜索引擎內轧叽。測試人員會嘗試輸入程序的“關鍵字”苗沧，那么程序在exception處理上刊棕，應該避免將數(shù)據(jù)庫相關的語句，微服務的名稱暴露出來待逞。抓包攔截也是主要攻擊手段之一鞠绰，我們的用戶拿著手機東北西走，很有可能進入被監(jiān)控的無線網(wǎng)絡內飒焦，如果接口內包含用戶的賬號密碼蜈膨，電話地址等，是很有可能被攔截竊取的牺荠。所以返代理機制需要考慮增加翁巍，被監(jiān)控時應予以提醒。惡意壓力請求是最為常見的休雌，我們應該在關鍵的地方做攔截灶壶，比如IP攔截，同一用戶單位時間請求量的攔截杈曲，請求間隔時間限制驰凛。對于數(shù)據(jù)的格式的嚴謹性需要增強，有必要的話應該加入加密字段担扑，避免因為用戶涉及黃色恰响，暴力，低俗涌献，政治敏感信息牽連我方胚宦。
另外反編譯技術可以獲取到源代碼，所以必要的版本判斷需要增強燕垃，應該在檢測被篡改的客戶端發(fā)來的請求枢劝，要求其更新，否則不予處理卜壕。還有一種內存監(jiān)控修改的方式您旁，來跳轉到不該進入的頁面或狀態(tài)。
自動化維度
ui自動化的設計轴捎，通常以頁面為類鹤盒，按鈕為方法，并且命名一個頁面為基礎頁面轮蜕。校驗結果也是頁面元素昨悼。對象化調用的設計，混合api自動化快速制作需要的數(shù)據(jù)跃洛。
api自動化的設計率触，通常以后端服務為類，接口為方法汇竭。校驗結果包含固定響應葱蝗，特殊響應穴张，以及混合存儲查詢來驗證寫入的正確性。
性能測試的設計两曼，以ui或api為基礎皂甘，它的關注點是性能狀態(tài)。
監(jiān)控的設計悼凑，以ui或api為基礎偿枕，把較為重要的部分進行心跳式調用，一旦發(fā)現(xiàn)crash或者500的情況要及時的通過郵件等方式發(fā)布警報户辫。這個心跳間隔可以是任何時長渐夸。
代碼維度
代碼邏輯不僅是遵循業(yè)務邏輯那么簡單，最重要的是處理異常渔欢。例如墓塌，字符類型的轉化是否完整。多個if應該每個都要跑到奥额。exception/catch是否能補貨特定異常苫幢，是否能出現(xiàn)其它異常。如果我們的測試執(zhí)行垫挨，沒有走遍每一個ifelse,每一個trycatch韩肝，那么對于程序的完整性測試就沒有做到涂乌。如果函數(shù)寫得很粗糙赔硫，那么就會有很多的情況它無法處理，在代碼維度上，通常是很難進行測試的帚屉。為什么呢，因為專職的開發(fā)工程師漾峡，是專精一門開發(fā)語言的攻旦，而測試通常掌握的都是腳本語言，有很多比較重的開發(fā)語言是不會的生逸，即便是會了一門兩門牢屋，那么可能換了工作環(huán)境了，你會的東西就用不到了槽袄，有的仁兄就說了烙无，我能給開發(fā)檢查代碼，我還干什么測試呢遍尺。所以很多時候我們需要借助框架截酷，借助工具去實現(xiàn)，去告訴我們代碼覆蓋率乾戏，哪些地方我們沒有測試到迂苛，由檢測程序來告訴我們三热。同時作為一名優(yōu)秀的測試人員，應該培養(yǎng)讀代碼的能力三幻，重要的溝通能力就漾，起碼做到，寫雖然寫不出來念搬，但是你讓我看抑堡，我能看明白代碼的意義，語言都是想通的朗徊，只是各有各的規(guī)范而已夷野。
總結
當然，我們都知道荣倾。測試工程師也是有相應的級別劃分的悯搔。測試用例的設計本質，是為了給質量保障提供有依據(jù)的參照物舌仍。而通常設計測試用例的工作妒貌，由中級及以下工程師負責。而有一些維度盡管想到了也不知道如何進行铸豁。所以通常我們會把測試用例精確到UI維度灌曙。其它維度分別規(guī)劃在自動化測試設，性能測試設計节芥，以及安全測試設計在刺，在后三個測試設計內，其實也不能稱之為通常意義的測試用例了头镊。目前測試團隊通常有兩種模式蚣驼，一種是以敏捷開發(fā)衍生的全站式的測試工程師，一個功能模塊下的任務歸一個人負責到底相艇，這個時候就適合做一個多維度的測試用例颖杏，從頭到尾做好保障。另外一種團隊模式是功能測試和測試開發(fā)分離的模式坛芽，功能測試僅負責到UI層面留储，而其它維度交給專職的測試開發(fā)工程師進行測試。無論哪一種執(zhí)行方式都應該進行全方位的質量保障咙轩，如果有缺失获讳，就會有隱患。尤其是用戶量較大的知名企業(yè)活喊，多少黑客和工作室再盯著丐膝，甚至國外的間諜都在打你們的主意，一不留神損失的不光是企業(yè)，甚至是國家尤误。
后續(xù)
對于各個維度可以展開討論心得侠畔。而一個標準化的測試用例編寫平臺是必要的，因為我們不可能記住每一個測試設計方法损晤，需要一個標準化模板去做软棺，起碼在編寫用例的過程當中給予相關的提示提醒。有機會的話尤勋，我會把更多的細節(jié)記錄下來分享給朋友們喘落，同時希望朋友們多多提供業(yè)內好的東西，大家共同學習最冰。
