運(yùn)維監(jiān)控系列文章入口【運(yùn)維監(jiān)控】系列文章匯總索引最近在研究 AI BI智能數(shù)據(jù)分析 的落地實(shí)踐。敬請期待后續(xù)專題實(shí)戰(zhàn)系列《從零手把手教你搭建 AI 驅(qū)動的 BI 系統(tǒng)》將覆蓋 Text2SQL、多輪對話、語義層、權(quán)限治理、生產(chǎn)級部署全鏈路代碼可落地、坑點(diǎn)全復(fù)盤。文章目錄一、軟件測試1、軟件測試Software Testing2、缺陷Defeat3、測試用例Test Case4、測試金字塔5、測試策略6、測試左移和測試右移7、質(zhì)量度量二、軟件的測試分類1、單元測試2、集成測試3、系統(tǒng)測試4、驗(yàn)收測試5、靜態(tài)分析6、安全測試7、性能測試三、 測試用例設(shè)計入門1、等價類劃分2、邊界值法3、場景法四、測試數(shù)據(jù)的構(gòu)造和安全1、構(gòu)造測試數(shù)據(jù)1、通用文本數(shù)據(jù)構(gòu)造2、文件構(gòu)造3、圖片構(gòu)造4、高效文本操作2、測試數(shù)據(jù)的安全1、信息泄露風(fēng)險2、信息數(shù)據(jù)保護(hù)法規(guī)軟件測試是一個非常專業(yè)的工作在大多數(shù)的軟件建設(shè)組織中都會有軟件測試類的崗位或類似名稱的崗位來對交付的軟件進(jìn)行驗(yàn)證。軟件質(zhì)量不僅僅是測試人員的工作并且其也只能盡可能地找出存在的bug并不能真正解決bug。bug產(chǎn)生于需求分析、系統(tǒng)設(shè)計以及編碼甚至測試本身所以軟件質(zhì)量的提升或保證應(yīng)該由軟件產(chǎn)品參與的各個環(huán)節(jié)共同努力的結(jié)果。一般來說越早重視軟件質(zhì)量取得的價值就越大。事情一次性做對總比增加應(yīng)對措施、預(yù)防措施等一系列的挽救措施要更節(jié)省成本也更加的高效。在輸出以上觀點(diǎn)后我們接下來介紹幾個基本的概念。一、軟件測試1、軟件測試Software Testing測試是一種檢驗(yàn)產(chǎn)品質(zhì)量的活動。通常意義上的 “軟件測試” 是特定環(huán)境下檢查軟件是否存在錯誤以及能否滿足業(yè)務(wù)需求和設(shè)計的活動或過程。軟件的含義不僅僅是程序本身還包括文檔、數(shù)據(jù)和其他基礎(chǔ)設(shè)施等一切交付物。這也是越來越多的公司將測試工程師Software Test Engineer的崗位轉(zhuǎn)變?yōu)橘|(zhì)量工程師 Quality Assurance的原因。軟件開發(fā)過程中無論采用的是瀑布開發(fā)模式還是敏捷開發(fā)模式甚至起他的開發(fā)模式都會存在需求分析、系統(tǒng)設(shè)計、編碼、測試、投入生產(chǎn)上線等過程。在軟件全生命周期質(zhì)量保證的理念下基于軟件過程的測試類別被更為細(xì)致的提出來如需求測試、架構(gòu)測試、設(shè)計測試、單元測試、集成測試、用戶驗(yàn)證測試等。想要明確定義軟件的質(zhì)量對軟件質(zhì)量的度量非常重要。軟件質(zhì)量的度量指標(biāo)和方法非常多樣比如有測試用例覆蓋率、每千行代碼的缺陷率等指標(biāo)。在定義了軟件質(zhì)量的度量指標(biāo)后可根據(jù)質(zhì)量保證計劃中定義的度量指標(biāo)值和執(zhí)行結(jié)果進(jìn)行對比分析以便得出軟件質(zhì)量變化情況然后給出相應(yīng)的應(yīng)對措施和預(yù)防措施。現(xiàn)代的軟件測試提倡軟件全生命周期測試項(xiàng)目開始時測試人員就需要參與對需求的驗(yàn)證和評審即測試左移而對軟件上線后運(yùn)營期質(zhì)量提出要求則是測試右移。2、缺陷Defeat如果軟件產(chǎn)品沒有按照我們的期望運(yùn)行我們會說軟件有 Bug。Bug 的原意是 “臭蟲”這個名稱的來源是繼電器計算機(jī)中飛進(jìn)的一只飛蛾。被公認(rèn)為世界上最早一批程序員中的葛麗絲·霍普女士在 Mark II 計算機(jī)上工作時設(shè)備無法正常工作了整個團(tuán)隊(duì)都不知道怎么回事。后來經(jīng)過排查發(fā)現(xiàn)是一只飛蛾飛入設(shè)備內(nèi)部引起的故障Mark II 是一臺繼電器計算機(jī)異物的侵入會導(dǎo)致元件無法工作。葛麗絲·霍普女士在她的筆記中記錄了這個故事說明問題的根因是一個蟲子引起的 Bug 這個詞也流傳了下來。在軟件工程領(lǐng)域更多使用缺陷來描述軟件沒有按照預(yù)期運(yùn)行的現(xiàn)象。缺陷描述的不僅僅是程序編碼上的錯誤還包括需求和系統(tǒng)設(shè)計的不合理運(yùn)營期間的配置問題以及基礎(chǔ)設(shè)施故障等。缺陷的引入可能會發(fā)生在軟件生命周期的任何一個環(huán)節(jié)中使用正交缺陷分類Orthogonal Defect Classification法劃分缺陷具體如下。需求缺陷需求本身不合理或者缺乏系統(tǒng)性考慮造成的bug。設(shè)計缺陷系統(tǒng)設(shè)計時未考慮到一些場景或者在系統(tǒng)設(shè)計上不能滿足一些特定場景造成軟件在使用過程中出現(xiàn)bug。編碼缺陷由于開發(fā)者的疏忽或者其他原因造成的bug。配置缺陷在投入生產(chǎn)使用的過程中由于配置不合理或者環(huán)境發(fā)生變化造成的bug。為了更清晰地描述缺陷這個概念人們區(qū)分了以下幾個概念。缺陷Defect它是靜態(tài)的一直存在也就是我們說的Bug。錯誤Error程序執(zhí)行有缺陷的代碼或者輸入特定的數(shù)據(jù)后造成程序狀態(tài)異常。失效Failure失效是軟件不能正常運(yùn)行使用者感知到的狀態(tài)。一個軟件可能有缺陷但是不一定會帶來錯誤并被感知到失效也有可能是非缺陷造成的比如運(yùn)行環(huán)境不滿足要求等。缺陷并不一定會導(dǎo)致程序運(yùn)行錯誤由缺陷導(dǎo)致程序發(fā)生錯誤叫做缺陷的激活。缺陷往往需要在特定的條件和場景下才會被激活例如一些特別的輸入或者運(yùn)行環(huán)境發(fā)生變化。根據(jù)優(yōu)先級和嚴(yán)重性對導(dǎo)致問題的缺陷進(jìn)行分類比如將缺陷分為 4 個級別P0 致命非常嚴(yán)重的線上事故比如讓整個系統(tǒng)癱瘓需要停下手上的工作立即修復(fù)。如果不能在一定時間內(nèi)修復(fù)需要上報通過其他途徑來解決比如使用備用方案。P1 嚴(yán)重部分重要功能不可使用雖然優(yōu)先級沒有 P0 那么高但是也需要立即修復(fù)。P2 一般次要功能不可使用會給用戶帶來不便可不立即修復(fù)隨版本進(jìn)行常規(guī)發(fā)布。P3 輕微會給用戶帶來不便或者 UI、文案視情況而定上存在需要調(diào)整的內(nèi)容隨版本進(jìn)行常規(guī)發(fā)布。說明上述分類中的字母 P 是 Priority 的首字母縮寫。3、測試用例Test Case測試用例Test CaseTC是一組測試輸入和預(yù)期的集合。簡單來說就是包含測試內(nèi)容需要的輸入、預(yù)期和結(jié)果以及特定的測試環(huán)境。在不同的軟件開發(fā)模型中測試用例呈現(xiàn)的方式不同。在瀑布模型中通常會根據(jù)不同的版本來管理測試用例并持續(xù)維護(hù)使用敏捷的方式測試用例往往跟隨著用戶故事管理測試用例RUP統(tǒng)一軟件開發(fā)過程則要求測試用例可以追溯驗(yàn)證系統(tǒng)行為采用類似瀑布的方式維護(hù)測試用例但是每個迭代都需要更新并持續(xù)維護(hù)。測試用例的規(guī)格在 IEEE 標(biāo)準(zhǔn)和國標(biāo)GB/T上都有被定義過主要包含如下內(nèi)容被測試的對象對應(yīng)軟件特性或者需求。給予的條件包括輸入信息和測試環(huán)境輸入信息包含了測試數(shù)據(jù)和操作步驟執(zhí)行路徑。期望的結(jié)果包含軟件的執(zhí)行預(yù)期即期待的程序輸出。如果能嚴(yán)格和良好地基于測試用例進(jìn)行實(shí)踐可以用較小的成本覆蓋大量的測試場景并能準(zhǔn)確地讓問題重現(xiàn)。在一些團(tuán)隊(duì)會使用思維導(dǎo)圖作為測試用例但是這種形式比較難以維護(hù)。越來越多的公司會創(chuàng)建自己的測試管理平臺思維導(dǎo)圖則作為測試用例的補(bǔ)充。編寫好的測試用例需要遵守如下的原則期望的結(jié)果可判定。測試用例有明確的判定標(biāo)準(zhǔn)比如系統(tǒng)登錄成功顯示 “登錄成功” 文案以及個人信息。測試用例可重復(fù)執(zhí)行。測試用例應(yīng)該能被反復(fù)執(zhí)行并且結(jié)果保持穩(wěn)定。測試用例具有代表性。測試用例的設(shè)計應(yīng)該從典型到特殊延展并能覆蓋核心業(yè)務(wù)場景。讓測試用例具有代表性是設(shè)計測試用例的難點(diǎn)設(shè)計者需要從不同的角度選取測試場景達(dá)到最優(yōu)的測試性價比。有些公司會把正常的流程和符合預(yù)期的結(jié)果叫做正向用例把一些異常處理的場景叫做反向用例。另外最為關(guān)鍵的地方是設(shè)計測試數(shù)據(jù)時需要考慮到大量的邊界值。邊界值指的是介于正常數(shù)據(jù)和錯誤數(shù)據(jù)之間的臨界數(shù)據(jù)比如 0 是正數(shù)和整數(shù)之間的一個邊界值。用戶輸入往往難以窮盡借助邊界值作為代表性測試數(shù)據(jù)是一種常用的方式。4、測試金字塔軟件測試有很多類型測試金字塔的核心理念是不同測試類型的收益和性價比是不一樣的。通常來說基于界面的測試自動化難度高且為了能覆蓋更多的的場景并讓測試正常運(yùn)行需要準(zhǔn)備的數(shù)據(jù)量也更多相應(yīng)地投入的時間也會較多。單元測試則不太一樣測試的目標(biāo)更加精確需要準(zhǔn)備的測試數(shù)據(jù)量較少同時單元測試運(yùn)行得更快因此投入的時間較少。在 《Succeeding with Agile》書中提出了一個測試金字塔形象地描述了UI測試、服務(wù)測試和單元測試的差異。下圖是簡單的測試金字塔可以用來描述不同測試類型的執(zhí)行速度和消耗資源的情況。實(shí)際上測試金字塔中層次的劃分取決于所采用的技術(shù)棧并不拘泥于圖中所示這三層。在微服務(wù)系統(tǒng)中我們通常使用的測試金字塔可以描述為單元測試、API 測試、界面測試。測試金字塔的每一層都可以選用不同的工具來實(shí)現(xiàn)自動化。測試金字塔只是一種對測試劃分方法的模型這種模型可以有非常多的解釋和變種。在一些測試金字塔中我們可能會看到手工測試、驗(yàn)收測試等內(nèi)容也可能會有非常多層。測試金字塔主要應(yīng)用于敏捷過程的測試工作中在其他的軟件開發(fā)過程中也不同的測試模型例如 V 模型。5、測試策略測試策略描述的是一個項(xiàng)目或者產(chǎn)品如何組織測試活動以獲取最大的價值。完整的測試策略就是一個項(xiàng)目的完整測試框架涵蓋了關(guān)于質(zhì)量的各方面測試清單以及對應(yīng)的實(shí)施方式。測試策略可以是一份詳盡的文檔也可以是一個圖示或者一份簡單的檢查清單。下圖描述了敏捷團(tuán)隊(duì)活動中的測試實(shí)踐。圖中左下角使用了一個測試象限描述哪些測試應(yīng)該自動進(jìn)行中間展示的是一個四層的測試金字塔。測試金字塔中的測試實(shí)踐為單元測試、API 集成測試、端到端測試、探索式測試。注圖片來源于 https://www.bylinzi.com/2020/01/10/one-page-test-strategy。測試策略中需要包含如下內(nèi)容。測試原則所有的實(shí)踐都應(yīng)該圍繞這個原則展開比如 “項(xiàng)目組為質(zhì)量負(fù)責(zé)”。測試范圍功能特性、性能、安全、可用性、可靠性等。測試方法需求和設(shè)計評審、靜態(tài)代碼分析、單元測試、集成測試、E2E 測試、安全建模、滲透測試、探索性測試等。如果將測試策略延展還可以包括各項(xiàng)軟件質(zhì)量度量的內(nèi)容等。6、測試左移和測試右移測試左移是指在軟件進(jìn)入測試階段之前就介入測試QA測試人員在需求階段就參與并對設(shè)計階段的各項(xiàng)活動進(jìn)行評估。在需求澄清的時候就應(yīng)該參與并對需求、用戶故事等輸出進(jìn)行檢查。另外在研發(fā)人員進(jìn)入設(shè)計階段后也可以對輸出的技術(shù)方案進(jìn)行評估驗(yàn)證技術(shù)方案是否能滿足設(shè)計目標(biāo)。測試左移還可以提前準(zhǔn)備用例和測試環(huán)境調(diào)整測試方案以具備更好的測試性。測試右移是指軟件進(jìn)入運(yùn)營階段后也需要 QA 參與軟件發(fā)布后 QA 需要持續(xù)關(guān)注線上預(yù)警和監(jiān)控及時發(fā)現(xiàn)問題并嘗試在測試環(huán)境中重現(xiàn)。這樣 QA 就可以驅(qū)動研發(fā)人員在開發(fā)過程中考慮接入監(jiān)控、告警等基礎(chǔ)設(shè)施開發(fā)團(tuán)隊(duì)需要比市場、業(yè)務(wù)方以及用戶更快地發(fā)現(xiàn)問題并制定解決措施。7、質(zhì)量度量度量可以通過用量化的方法取代定性的結(jié)論來評估軟件的質(zhì)量、過程和測試有效性等作為合理決策的依據(jù)。對于人員分配、能效提升、績效考核等各個方面都有一定的意義。質(zhì)量度量的指標(biāo)研究包含以下幾個方面對于產(chǎn)品的質(zhì)量進(jìn)行度量。對于測試的有效性進(jìn)行度量。對于測試的完整性進(jìn)行度量。對于測試過程和軟件開發(fā)過程的分析和改進(jìn)。對于普通測試人員和研發(fā)人員來說不需要特別去設(shè)計這些度量指標(biāo)可以根據(jù)國際、國內(nèi)的指標(biāo)標(biāo)準(zhǔn)提取一些合適自己的指標(biāo)作為公司內(nèi)部使用的度量體系。ISO/IEC 9126 標(biāo)準(zhǔn)從功能性、可靠性、易用性、效率、可維護(hù)性、可移植性這 6 個特性進(jìn)行度量和前面對缺陷的理解類似ISO/IEC 9126 標(biāo)準(zhǔn)將這些指標(biāo)劃分為通用、內(nèi)部指標(biāo)、外部指標(biāo)。內(nèi)部指標(biāo)的含義是側(cè)重在交付前的度量不關(guān)注缺陷被激活的情況更加關(guān)注軟件的本質(zhì)問題。在國內(nèi)也有相應(yīng)的度量體系GB/T 延用了 ISO/IEC 9126 中的指標(biāo)從 6 個方面對軟件質(zhì)量進(jìn)行評估。在 《GB/T 32904—2016 軟件質(zhì)量量化評價規(guī)范》中該文檔給出了一套根據(jù)指標(biāo)計算軟件質(zhì)量的方法其中參考使用的標(biāo)準(zhǔn)體系如下圖所示。對于測試有效性和完整性的衡量可以參考一些主流軟件公司的做法比如某公司會根據(jù)千行代碼代碼規(guī)模一般不作為唯一手段為基線統(tǒng)計一些測試能力的指標(biāo)每千行用例數(shù)。每千行缺陷率。用例平均執(zhí)行時間。缺陷平均回歸次數(shù)。有效缺陷率經(jīng)過確認(rèn)特性描述不清楚導(dǎo)致的缺陷。通過度量后會根據(jù)缺陷的優(yōu)先級和嚴(yán)重程度進(jìn)行加權(quán)計算獲得每個版本的軟件質(zhì)量指數(shù)。在應(yīng)用指標(biāo)的時候還需要做出區(qū)分。由于有一些項(xiàng)目是建立在遺留系統(tǒng)之上的它的開發(fā)過程、邏輯和完全從頭開始的項(xiàng)目很不一樣。因此我們在使用這些指標(biāo)的時候可以根據(jù)項(xiàng)目的類型做出取舍。根據(jù)軟件系統(tǒng)遺留特性可以將項(xiàng)目劃分為綠地工程、棕地工程、維護(hù)性工程。綠地工程一項(xiàng)綠地工程在全新的領(lǐng)域中開發(fā)不需要考慮歷史遺留問題。綠地工程往往存在需求無法清晰描述特性有效缺陷率低缺陷修復(fù)的成本低缺陷回歸的效率高等特點(diǎn)。棕地工程此類工程中的系統(tǒng)通常是現(xiàn)有系統(tǒng)的一部分或者是其子系統(tǒng)。需要考慮與其他系統(tǒng)尤其是與歷史遺留系統(tǒng)Legacy system的集成問題。這類項(xiàng)目往往缺陷回歸次數(shù)高缺陷的修復(fù)成本很大。維護(hù)性工程指的是不再開發(fā)新功能的系統(tǒng)只完成維護(hù)性工作。二、軟件的測試分類不同維度下人們對軟件測試的分類不一致。比如根據(jù)開發(fā)過程進(jìn)行分類軟件的測試類型有單元測試、集成測試、系統(tǒng)測試和驗(yàn)收測試這些類型分別和軟件開發(fā)過程中的各個階段相適配。但是如果從被測試的對象角度來看軟件測試又可以分為靜態(tài)測試和動態(tài)測試。如果是以測試人員對代碼的了解程度來看則可以分為白盒測試、黑盒測試、灰盒測試。根據(jù)是否是自動化運(yùn)行的測試來區(qū)分又可以分為自動化測試和手工測試。還有一些其他的測試類型比如契約測試、彈珠測試、冒煙測試等。根據(jù)前面提到的測試策略和測試金字塔并參考 GB/T 的規(guī)范對一個敏捷團(tuán)隊(duì)需要進(jìn)行的測試類型進(jìn)行簡化。為了更加容易理解和記憶將其分為功能性測試和非功能性測試。功能性測試對應(yīng)的是功能性的需求針對軟件特性的業(yè)務(wù)目標(biāo)和邏輯。非功能性測試針對的是功能測試來說的即功能測試之外的要求。功能性測試單元測試。集成測試。系統(tǒng)測試。驗(yàn)收測試。非功能性測試靜態(tài)分析。安全測試。性能測試。就一般的軟件而言一個敏捷團(tuán)隊(duì)做好這 7 項(xiàng)測試就能涵蓋絕大部分測試需求。下面就這 7 類測試進(jìn)行簡單的介紹。1、單元測試單元測試Unit Testing是指對軟件中最小可測試單元進(jìn)行測試。“單元” 的粒度并沒有一個明確的界限細(xì)粒度的單元測試含義一般是對方法、類等代碼結(jié)構(gòu)進(jìn)行測試和驗(yàn)證。粗粒度的單元測試可以是對一個最小的軟件特性進(jìn)行驗(yàn)證根據(jù)設(shè)計需求文檔或者設(shè)計文檔進(jìn)行驗(yàn)證。單元測試往往處于測試金字塔的最低端。因?yàn)閱卧獪y試能透明地驗(yàn)證方法、類這一類代碼結(jié)構(gòu)因此編寫自動化運(yùn)行的測試也比較簡單。在目前的語義下單元測試默認(rèn)有自動化運(yùn)行的含義。對軟件質(zhì)量來說單元測試有非常積極的作用是測試金字塔中最重要的部分。通過單元測試可以將復(fù)雜的測試用例進(jìn)行拆解比如從較大規(guī)模的測試路徑分解成小規(guī)模的測試。且單元測試的難度相對較小測試效率也相應(yīng)較高。單元測試對環(huán)境要求低隔離性好為同時運(yùn)行多個測試用例提供了可能性。另外研發(fā)人員編寫單元測試在遇到問題時可以幫助定位缺陷。2、集成測試集成測試Integration Testing是指在單元測試的基礎(chǔ)上對一部分軟件模塊進(jìn)行組合或者在組裝后進(jìn)行的測試。在微服務(wù)時代通常來說集成測試是對一個服務(wù)的 API 進(jìn)行測試因此在很多文章和書籍中都會有 API 測試。請注意 API 這個詞的含義過于廣泛包括 RESTful API 和操作系統(tǒng)等軟件接口的概念需要根據(jù)上下文確定含義。在微服務(wù)的技術(shù)棧下通常集成測試等同于單個服務(wù)的 API 測試。隨著 DevOps 的發(fā)展持續(xù)集成的概念得到了廣泛關(guān)注。在一些大的項(xiàng)目中服務(wù)眾多且相互依賴。早期的集成測試大多是手工完成的會在集成測試時先進(jìn)行一個快速地冒煙測試Smoke Testing。冒煙測試是對軟件的基本功能進(jìn)行快速驗(yàn)證的過程。冒煙測試用來檢查主要的功能是否正常避免因?yàn)槠渲幸粋€服務(wù)異常而對整套測試環(huán)境造成中斷。在 CI/CD 發(fā)展比較好的團(tuán)隊(duì)會在服務(wù)部署到正式的測試環(huán)境前對 API 進(jìn)行自動化的測試如果測試發(fā)現(xiàn)問題會停止部署到測試環(huán)境。集成測試的依據(jù)是技術(shù)設(shè)計文檔比如 API 設(shè)計等材料。一般情況下研發(fā)人員會參與集成測試或者是在研發(fā)人員的配合下由 QA 完成集成測試。3、系統(tǒng)測試系統(tǒng)測試System Testing是指對完整的軟件產(chǎn)品進(jìn)行端到端的測試某種程度上可以等同于 E2E測試。系統(tǒng)測試需要搭建完整的環(huán)境以便在真實(shí)或者模擬系統(tǒng)的環(huán)境下對軟件進(jìn)行驗(yàn)證確認(rèn)是否達(dá)到設(shè)計目標(biāo)。需要配置的完整的軟硬件環(huán)境和基礎(chǔ)設(shè)施包括數(shù)據(jù)庫、網(wǎng)絡(luò)連接、DNS 等。系統(tǒng)測試往往是黑盒測試此測試會模擬正常的用戶在使用整個應(yīng)用程序時的各種操作。系統(tǒng)測試不僅要發(fā)現(xiàn)缺陷還應(yīng)該提出不限于需求規(guī)格范圍的反饋甚至還包括一些使用過程中的易用性、兼容性等問題。系統(tǒng)測試的依據(jù)是需求文檔包括 QA 在需求澄清階段的任何輸入。4、驗(yàn)收測試驗(yàn)收測試Acceptance Testing是指在軟件開發(fā)后期需求的提出方對軟件進(jìn)行驗(yàn)收確認(rèn)時進(jìn)行的測試。如果是軟件交付性質(zhì)的項(xiàng)目甲方往往會派出測試專家從用戶的角度進(jìn)行測試確認(rèn)是否滿足需求規(guī)格。在互聯(lián)網(wǎng)或者其他產(chǎn)品型的公司驗(yàn)收測試則是產(chǎn)品上線或者軟件發(fā)布后由業(yè)務(wù)方在生產(chǎn)環(huán)境或灰度環(huán)境下進(jìn)行驗(yàn)證。對一個在運(yùn)行中的互聯(lián)網(wǎng)產(chǎn)品來說驗(yàn)收測試需要得到特別的授權(quán)。因?yàn)樵谏a(chǎn)環(huán)境中一般會產(chǎn)生數(shù)據(jù)或者留下痕跡在有條件的情況下可以考慮清理或者隱藏這些信息。5、靜態(tài)分析軟件的靜態(tài)分析Static Analysis是指對軟件的各種結(jié)構(gòu)和成分進(jìn)行掃描提前發(fā)現(xiàn)問題它通常被作為測試的補(bǔ)充。靜態(tài)分析一般都是用自動化的工具或者平臺在日常進(jìn)行掃描和監(jiān)測的。靜態(tài)分析的目的就是通過掃描的手段發(fā)現(xiàn)代碼中的一些通用問題或者找出違反編碼、安全規(guī)范的代碼。常見的掃描工具如下。CheckstyleJava 代碼語法規(guī)則掃描。FindBugs從代碼模式上發(fā)現(xiàn)潛在問題。ArchUnit架構(gòu)規(guī)范掃描驗(yàn)證軟件包的組織合理性。OWASP Dependency-Track對依賴的第三方軟件和庫進(jìn)行檢查發(fā)現(xiàn)是否存在安全風(fēng)險。除此之外市面上還有一些其他的掃描工具比如PMD、FortifySCA 這些都屬于靜態(tài)分析的內(nèi)容。6、安全測試安全測試Security Testing是指對系統(tǒng)的安全要求進(jìn)行驗(yàn)證的一類測試。安全測試針對的是代碼執(zhí)行、命令執(zhí)行、病毒植入、端口掃描、DoS 攻擊、SQL 注入攻擊、CSRF 攻擊、XSS 攻擊、數(shù)據(jù)遍歷、越權(quán)、認(rèn)證繞過、金額篡改等安全問題的測試。由于互聯(lián)網(wǎng)項(xiàng)目會將用戶信息暴露到公網(wǎng)近些年來企業(yè)對安全測試的要求又有一定提高數(shù)據(jù)隱私、威脅建模也都被包含在安全測試的領(lǐng)域。數(shù)據(jù)隱私是指軟件系統(tǒng)在使用用戶的信息時需要滿足當(dāng)?shù)胤珊弦?guī)的要求且應(yīng)盡力保護(hù)用戶的隱私數(shù)據(jù)。威脅建模是通過一些建模工具來分析軟件會受到哪些方面的安全威脅并制定測試策略的過程。STRIDE 是常用的威脅模型它包含欺騙、篡改、否認(rèn)、信息泄露、DoS威脅、特權(quán)提升 6 個方面從這些方面可以結(jié)構(gòu)化地制定應(yīng)對措施。在一些大的團(tuán)隊(duì)中安全測試往往會由專門的安全專家進(jìn)行或者給予指導(dǎo)。沒有條件的則由研發(fā)人員和 QA 共同完成。7、性能測試性能測試Performance Testing是指針對軟件性能指標(biāo)進(jìn)行的測試。性能測試包括了軟件響應(yīng)速度和用戶容量等方面的內(nèi)容。響應(yīng)速度代表用戶使用軟件的等待時間對于一些常規(guī)操作而言等待時間過長會極大地影響用戶使用。用戶容量代表著有多少用戶能同時使用該軟件。單機(jī)軟件對用戶容量要求不高對于互聯(lián)網(wǎng)項(xiàng)目性能測試需要涵蓋容量指標(biāo)。性能測試中有一種負(fù)載測試用于通過模擬用戶遞增的方式找出系統(tǒng)的最大容量以及驗(yàn)證系統(tǒng)是否能通過增加服務(wù)的方式水平擴(kuò)容。性能測試工具包括 JMeter、AB、K6 等。JMeter、AB 都是 Apache 基金會的產(chǎn)品具有良好的使用口碑。K6 是一款新的性能測試工具能使用 JavaScript 語法編寫自動化的性能測試腳本對 Web 程序相當(dāng)友好。三、 測試用例設(shè)計入門一般將測試分為白盒測試和黑盒測試然后提供更具體的測試用例設(shè)計方法比如等價劃分、因果圖法、決策表法、邊界值分析等。測試用例設(shè)計的本質(zhì)思想是將原本需要窮舉的所有測試數(shù)據(jù)進(jìn)行科學(xué)的歸類、選擇、劃分以期用最少的測試數(shù)據(jù)就可以達(dá)到最佳的測試效果。設(shè)計測試用例遵守的基本思想是 MECE 原則它是 Mutually Exclusive,Collectively Exhaustive 的縮寫。在設(shè)計測試用例時每個用例的執(zhí)行無論是人工還是自動化都有成本那么需要盡可能的節(jié)約。相互獨(dú)立的意思是拆分的用例沒有交叉完全窮盡是說拆分的問題需要覆蓋到所有的情況。比如把測試數(shù)據(jù)用戶分為男性用戶和學(xué)生用戶這樣就發(fā)生了重疊。當(dāng)然MECE 是一種理想情況在測試過程中很難達(dá)到這種情況否則缺陷也就不會存在了。但是我們可以盡可能地參考這個原則來設(shè)計用例讓每個用例都物盡其用。1、等價類劃分等價類的劃分其實(shí)來自于數(shù)學(xué)的集合論指的是可以將輸入域的集合劃分為幾個等價子集合等價類中的元素對于揭露程序中的錯誤來說是等效的。從劃分合理的等價類中取出任意一條數(shù)據(jù)作為輸入條件均可獲得同樣的測試效果這樣就可以提高測試效率。通俗地來說在同一個等價類中只要有一條測試數(shù)據(jù)讓軟件出錯那么這個等價類中的其他數(shù)據(jù)往往也會讓軟件出錯。舉一個例子在一款支付軟件中正確的輸入是常規(guī)大小的數(shù)字輸入其他諸如 “* (” 這樣的特殊字符或字母則會給予提示。那么 輸入字母 A 和 B 就沒什么區(qū)別可以將它們視為同一個等價類中。正是因?yàn)檎_的輸入和錯誤的輸入差異非常明顯所以就形成了天然的劃分方式一般將等價類劃分為有效等價類和無效等價類。有效等價類是指對軟件來說合理、有意義的輸入數(shù)據(jù)集合。一般來說有效的等價類只需要一組即可在有些情況下可以設(shè)計多個一些團(tuán)隊(duì)稱之為正向測試Happy Path。無效的等價類是指對軟件來說不合理、無意義的輸入數(shù)據(jù)集合相對于有效等價類來說無效等價類的情況多得多需要繼續(xù)劃分。無效等價類又被叫做反向測試。等價類劃分有幾項(xiàng)固定模式可以參考如果規(guī)定了輸入數(shù)值的范圍可以設(shè)定一個有效等價類兩個無效的等價類。如果規(guī)定了輸入的數(shù)值的規(guī)則可以設(shè)定一個符合規(guī)則的等價類兩個違法規(guī)則的等價類。如果規(guī)定了輸入的數(shù)是一個整數(shù)可以參考的等價類有 0、正整數(shù)、負(fù)整數(shù)和小數(shù)等。如果規(guī)定輸入的是一個字符串可以參考的等價類有正確的字符串、空、空白字符串和超長的字符串等。下面來看一個通過等價類劃分設(shè)計測試用例的例子。支付平臺在處理用戶輸入時要求用戶輸入符合要求的金額 X有如下規(guī)則如果滿足規(guī)則輸入框校驗(yàn)通過否則提示錯誤 1. 用戶只能輸入大于 0 小于等于 1000 的金額。 2. 金額的單位是精確到兩位小數(shù)的人民幣元。經(jīng)過分析我們可以使用表 1-1 所示的等價類劃分來設(shè)計測試用例。用例等價類型X預(yù)期Case 1有效等價類0x1000,x 是整數(shù)校驗(yàn)通過Case 2有效等價類0x1000,x 是兩位小數(shù)校驗(yàn)通過Case 3有效等價類x 1000校驗(yàn)通過Case 4無效等價類x 0提示錯誤Case 5無效等價類x -1提示錯誤Case 6無效等價類x0.001提示錯誤Case 7無效等價類x張三提示錯誤Case 8無效等價類x*提示錯誤Case 9無效等價類x提示錯誤2、邊界值法邊界值分析法Boundary Value AnalysisBVA 是一種對等價類劃分做出有效補(bǔ)充的測試方法。邊界值法是建立在業(yè)界共識上的即軟件的錯誤往往出現(xiàn)在輸入輸出域的邊界上而不是輸入輸出域的內(nèi)部因此在選擇測試數(shù)據(jù)時邊界值比內(nèi)部的數(shù)據(jù)更有價值。依然使用前面的例子程序會對用戶的輸入值進(jìn)行檢查檢查的條件往往都是基于邊界值設(shè)定的。偽代碼如下if(input0||!isANumber(input)||input1000){thrownewException(input error);}通過這段代碼可以看出0、1000 都是一個典型的邊界值數(shù)字和非數(shù)字字符之間也是一個邊界因?yàn)樵谟嬎銠C(jī)內(nèi)部數(shù)字和非數(shù)字字符的編碼值不同。使用邊界值法選擇測試數(shù)據(jù)時應(yīng)當(dāng)選取剛好等于、剛好大于、剛好小于的值作為輸入。邊界值分析法有幾項(xiàng)固定模式可以參考如果規(guī)定了輸入數(shù)值的范圍可以選擇剛好等于、剛好大于、剛好小于的值。如果規(guī)定輸入的是一個集合可以選擇空集合、超出最大值的集合、一個元素的集合。使用規(guī)則的臨界條件。比如規(guī)則輸入不為空的字符串 的臨界輸入是不可見的字符串空格、制表符等。3、場景法前面介紹的幾種測試用例的設(shè)計方法都是針對單次操作的軟件往往都需要進(jìn)行多次操作。因此我們需要測試組合后的操作通過組合操作來設(shè)計測試用例即為使用場景法。軟件的流程控制都是通過事件的觸發(fā)來完成的。單個事件的測試可以用前面介紹的方法來完成多個事件則需要根據(jù)不同的順序構(gòu)建不同的事件流我們將每個事件觸發(fā)的情景稱為場景。根據(jù)事件組合而來的用例也可以稱為復(fù)合用例。執(zhí)行復(fù)合用例可以暴露大量的流程問題提高測試效果。下圖所示場景法一般包含基本流和備選流。圖中的直線表示基本流是最簡單的測試路徑曲線表示備選流是在某個特定的條件下所發(fā)生的異常行為。備選流可以從基本流的任何節(jié)點(diǎn)開始也可以回退、跳過基本流的節(jié)點(diǎn)。使用場景法的基本操作方法如下1根據(jù)業(yè)務(wù)規(guī)則畫出基本流的所有的節(jié)點(diǎn)。2考慮每一個節(jié)點(diǎn)的異常情況并畫出異常節(jié)點(diǎn)。3根據(jù)可達(dá)性這些節(jié)點(diǎn)構(gòu)成一個有向的圖。4對這個圖進(jìn)行遍歷設(shè)計用例。場景法的注意事項(xiàng)場景的劃分和選擇比較重要軟件的場景可能比較多需要從最重要的場景開始選擇。一個場景中可能有多個用戶角色需要特別注意多個角色交替操作的情況。設(shè)計場景可以參考開發(fā)文檔中的用例Use Case設(shè)計。下面是使用場景法設(shè)計測試用例的案例。需求說明如下這是一款收銀機(jī)軟件業(yè)務(wù)設(shè)定為服務(wù)員也需要讓收銀員來操作系統(tǒng)不記座位模式使用號牌收銀員可以進(jìn)行選菜、下單、退菜、打單、結(jié)賬等操作。后廚可以進(jìn)行出菜操作。如圖所示我們可以根據(jù)上述需求來設(shè)計用例并進(jìn)行測試下表給出了對應(yīng)的測試用例。表 1-2 使用用例流設(shè)計用例名稱步驟基本流1. 收銀員開始點(diǎn)餐啟動軟件后能加載菜品列表并顯示詳情。2. 收銀員選擇菜品并設(shè)定數(shù)量、口味等確認(rèn)菜品無誤后進(jìn)入下一步。3. 收銀員收到用戶費(fèi)用后進(jìn)入下單打印界面打印小票給后廚并打印賬單給客戶收銀員可以在結(jié)賬后回到點(diǎn)餐狀態(tài)為下一次點(diǎn)餐做準(zhǔn)備。4. 后廚看到小票開始做菜出菜后由后廚確認(rèn)出菜。5. 系統(tǒng)接收到確認(rèn)某個訂單的所有出菜信息后標(biāo)記訂單完成用于統(tǒng)計和收銀員對賬備選流 1 - 未結(jié)賬回退1. 收銀員開始點(diǎn)餐啟動軟件后能加載菜品列表并顯示詳情。2. 收銀員確認(rèn)菜品無誤后進(jìn)入下單打印界面。3. 收銀員可以選擇返回上一步軟件記錄之前的菜品選擇備選流 2 - 結(jié)賬后退菜顧客可能點(diǎn)單后選擇退菜軟件允許相應(yīng)的操作。1. 完成基本流的前兩個步驟。2. 從歷史訂單進(jìn)入選擇退菜操作只能選擇未出菜的菜品項(xiàng)目備選流 3 - 結(jié)賬后取消訂單顧客可能點(diǎn)單后選擇取消訂單軟件允許相應(yīng)的操作。1. 完成基本流的前兩個步驟。2. 從歷史訂單進(jìn)入選擇取消訂單操作只能選擇未發(fā)生出菜的訂單四、測試數(shù)據(jù)的構(gòu)造和安全在軟件測試的過程中往往需要構(gòu)造測試數(shù)據(jù)。有一些團(tuán)隊(duì)會直接使用生產(chǎn)環(huán)境的真實(shí)數(shù)據(jù)進(jìn)行測試實(shí)際上這種做法違反了信息安全和合規(guī)的要求需要特別注意。1、構(gòu)造測試數(shù)據(jù)下面介紹一些工具和技巧來快速、高效地構(gòu)造測試數(shù)據(jù)。1、通用文本數(shù)據(jù)構(gòu)造常見的測試數(shù)據(jù)可以通過一些開源工具來實(shí)現(xiàn)比如目前有多種語言的 Faker 庫它使用的是 Python、JavaScript 等腳本語言。JavaScript 的 Faker 版本 faker.js 可以部署并運(yùn)行在瀏覽器上進(jìn)行在線數(shù)據(jù)生成。Faker庫支持許多其他功能和提供者可以根據(jù)你的需求查閱官方文檔以獲取更多詳細(xì)信息Faker技術(shù)文檔https://faker.readthedocs.io/en/master/GitHub倉庫https://github.com/faker-js/faker2、文件構(gòu)造有時候需要構(gòu)造不同大小的文件來完成測試這可以通過網(wǎng)站fakefilegenerator.com來實(shí)現(xiàn)它可以生成所需類型和大小的文件。如果只是想要構(gòu)造空文件可以使用命令快速實(shí)現(xiàn)它可以構(gòu)造任意大小的文件。在 Linux 中 /dev/zero 文件是一個特殊的設(shè)備文件在被讀取時會提供無限的空字符?？梢酝ㄟ^ dd 命令復(fù)制 /dev/zero 文件來構(gòu)造新的文件。dd 命令的基本用法如下ddif輸入文件of輸出文件bs復(fù)制塊大小count復(fù)制次數(shù)例如如果需要生成 10 MB 大小的文件可以使用下面的命令ddif/dev/zeroofoutput.txtbs1Mcount10在 Linux 中還有一個 truncate 命令可以將文件任意縮小或拓展到指定的大小echohellotest.txt truncate-s1024test.txt3、圖片構(gòu)造當(dāng)我們需要構(gòu)造一些特定尺寸的圖片時其實(shí)不需要在網(wǎng)上到處尋找。有一些圖片占位符網(wǎng)站提供了動態(tài)生成圖片的服務(wù)通過構(gòu)造圖片鏈接可以獲得合適的圖片。例如在 placeholder.com 網(wǎng)站上可以通過構(gòu)造 URL 來生成滿足尺寸、背景、文字等不同需求的圖片。示例1瀏覽器輸入 https://via.placeholder.com/200 可自動生成一個200尺寸正方形圖。示例2瀏覽器輸入 https://via.placeholder.com/200x100 可自動生成一個200×100尺寸長方形圖。示例3瀏覽器輸入 https://via.placeholder.com/200x100/rbg 可自動生成一個200×100尺寸rgb顏色的長方形圖。示例3瀏覽器輸入 https://via.placeholder.com/400x300/rbg 可自動生成一個400×300尺寸增加“alanchan”文字的長方形圖。4、高效文本操作如果經(jīng)常需要批量處理數(shù)據(jù)時通過批量的文本操作可以大大節(jié)省我們的時間和縮小工作量。支持批量操作的編輯器非常多這里以 Sublime 為例說明批量編輯的方法。Sublime 可以使用多光標(biāo)功能批量進(jìn)行數(shù)據(jù)操作很方便以下面這段文本為例逍遙游 齊物論 養(yǎng)生主 人間世 德充符 大宗師 應(yīng)帝王如果需要去除換行并且增加引號將每個詞引用起來然后放到代碼的數(shù)組中使用那么在Sublime 編輯器中我們可以先全選再使用 快捷鍵 Ctrl Shift L獲得每行的光標(biāo)。然后使用 Ctrl 左導(dǎo)航鍵移動光標(biāo)至行首接下來就可以自由編輯了。在 Sublime 中還有一個非常有用的選中功能。如果一個文本中出現(xiàn)了多次重復(fù)的字符串那么可以選中其中一個字符串然后按下 Ctrl D 鍵這樣就可以拓展選中下一個相同的字符串也就可以快速批量編輯選中的重復(fù)字符串了。和 Ctrl D 鍵相似的一組快捷鍵是 Alt F3選中文本按下快捷鍵可以一次性選擇文本中出現(xiàn)的所有相同文本并同時進(jìn)行編輯?？梢允褂眠@種方法快速替換相同的字符串。此外換行符也可以被選中可以用于去掉批量換行符。2、測試數(shù)據(jù)的安全由于在測試過程中數(shù)據(jù)的管理沒有生產(chǎn)環(huán)境上那么嚴(yán)格因此可能存在一定的數(shù)據(jù)安全風(fēng)險尤其是在金融、銀行、軍工等重要領(lǐng)域因此我們需要注意對測試數(shù)據(jù)做一些保護(hù)和管理以及了解一些數(shù)據(jù)保護(hù)相關(guān)的法律法規(guī)。1、信息泄露風(fēng)險有一些團(tuán)隊(duì)會直接使用生產(chǎn)上的數(shù)據(jù)作為測試環(huán)境數(shù)據(jù)實(shí)際上這不是非常好的做法雖然對于一些棘手的缺陷需要使用生產(chǎn)環(huán)境的數(shù)據(jù)來重現(xiàn)但是這不應(yīng)該作為一種常態(tài)化的操作方法。生產(chǎn)數(shù)據(jù)需要和非生產(chǎn)的環(huán)境嚴(yán)格隔離并且需要采取必要的權(quán)限管理措施比如對測試數(shù)據(jù)進(jìn)行脫敏。由于數(shù)據(jù)脫敏具有特殊性因此很多公司會通過專門的部門來完成。從實(shí)現(xiàn)上來看數(shù)據(jù)脫敏又可以分為靜態(tài)脫敏和動態(tài)脫敏。靜態(tài)脫敏是指需要測試數(shù)據(jù)時才人工地從數(shù)據(jù)源獲取并處理數(shù)據(jù)而動態(tài)脫敏可以通過脫敏服務(wù)進(jìn)行數(shù)據(jù)采集然后經(jīng)過脫敏算法加工再分發(fā)給使用方。使用方不僅可以用于測試也可用于業(yè)務(wù)側(cè)的數(shù)據(jù)導(dǎo)出、報送審批、存檔等流程。2、信息數(shù)據(jù)保護(hù)法規(guī)一般可以參考的信息是相關(guān)法律法規(guī)以及行業(yè)相關(guān)監(jiān)管部門的要求。2018 年 5 月 25 日歐洲聯(lián)盟出臺《通用數(shù)據(jù)保護(hù)條例》用于歐盟內(nèi)部的數(shù)據(jù)管理?！吨腥A人民共和國個人信息保護(hù)法》是 2021 年 11 月 1 日通過的我國關(guān)于個人信息安全的首部法律。《中華人民共和國個人信息保護(hù)法》規(guī)定了個人信息處理者有義務(wù)對個人信息進(jìn)行分類、加密處理以及規(guī)定了敏感信息的范圍和處理規(guī)則。以上介紹了測試工作的基礎(chǔ)知識、測試的基本概念以及可以用于團(tuán)隊(duì)溝通的基本術(shù)語。其中測試金字塔和測試策略的使用需要在團(tuán)隊(duì)中達(dá)成一致讓團(tuán)隊(duì)為最終的質(zhì)量負(fù)責(zé)才能產(chǎn)出高質(zhì)量的軟件產(chǎn)品。對于研發(fā)人員來說測試用例的設(shè)計不需要用到過于復(fù)雜的技巧。在編寫單元測試中往往只需要使用邊界值和等價類劃分方法在編寫 API 測試時可以適當(dāng)使用場景法的方式。