測試工程師知識點(diǎn)
測試工程師知識點(diǎn)總結(jié)
1、軟件質(zhì)量保證：標(biāo)準(zhǔn)、規(guī)范、體系、實(shí)施
2、軟件基礎(chǔ)測試(軟件開發(fā)過程，軟件的質(zhì)量保證，理解軟件測試，測試分類);軟件測試過程(軟件測試計(jì)劃，軟件測試設(shè)計(jì)，軟件測試執(zhí)行);軟件愛你測試工具(功能測試工具，性能測試工具)
3、軟件的定義：略。
4、軟件的分類：系統(tǒng)軟件、應(yīng)用軟件、Web應(yīng)用軟件、工程和科學(xué)軟件、嵌入式軟件、產(chǎn)品線軟件、人工智能軟件
5、 軟件危機(jī)的產(chǎn)生原因：客觀：軟件本身特點(diǎn)(邏輯部件，規(guī)模龐大);主觀：不正確的
開發(fā)方法(忽視需求分析，軟件開發(fā)=程序編寫，輕視軟件維護(hù))
6、軟件危機(jī)的解決途徑：組織管理(工程項(xiàng)目管理方法);技術(shù)措施(軟件開發(fā)技術(shù)與方法，軟件工具)
7、軟件工程是一匯總層次化的技術(shù)
8、軟件工程三要素：方法、工具、過程
9、軟件質(zhì)量保證的目的(SQA)：使軟件過程對于管理人員來說是可見的
10、全面質(zhì)量管理TMQ的核心思想：全員性(全員參與質(zhì)量管理);全過程性(管理好質(zhì)量形成的全過程);全面性(管理好質(zhì)量涉及到的各個(gè)要素)
11、軟件質(zhì)量保證的目標(biāo)：以獨(dú)立審查的方式，從第三方的角度監(jiān)控軟件開發(fā)任務(wù)的執(zhí)行
12、軟件質(zhì)量保證向管理者提供對軟件過程進(jìn)行全面監(jiān)控的手段，使軟件過程對于管理人員來說是可見的
13、軟件質(zhì)量保證的策略：以檢測為重，以過程管理為重，以新產(chǎn)品開發(fā)為重
14、軟件質(zhì)量保證的主要任務(wù)：SQA審計(jì)評審，SQA報(bào)告，處理不符合問題
15、軟件測試的定義：軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程
16、強(qiáng)調(diào)：測試、測試用例、測試步驟
17、軟件的生命周期：制定計(jì)劃、需求分析定義、軟件設(shè)計(jì)、程序編碼、軟件測試、軟件運(yùn)行、軟件維護(hù)、軟件停用
18、軟件測試技術(shù)分類：是否執(zhí)行(靜態(tài)測試，動(dòng)態(tài)測試);用力的設(shè)計(jì)方法(黑盒測試，白盒測試);是否采用面向?qū)ο蠹夹g(shù)(傳統(tǒng)測試，面向?qū)ο鬁y試)
19、軟件測試模型：V、W、H、X、前置模型
20、V模型：特點(diǎn)：瀑布模型的變種，反映了測試活動(dòng)與分析和設(shè)計(jì)的關(guān)系，測試策略包括底層測試和高層測試;局限性：主要針對程序進(jìn)行測試尋找錯(cuò)誤，而需求分析、系統(tǒng)設(shè)計(jì)階段隱藏的問題一直到后期的系統(tǒng)測試，驗(yàn)收測試才被發(fā)現(xiàn)，把測試的過程作為在需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)及編碼之后的一個(gè)階段
21、W模型：特點(diǎn)：W模型由兩個(gè)V字模型做成，分別代表測試與開發(fā)過程，W模型強(qiáng)調(diào)，測試伴隨著整個(gè)軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測試，測試與開發(fā)室同步進(jìn)行的，測試與開發(fā)室同步進(jìn)行的，有利于今早的發(fā)現(xiàn)問題;局限性：把軟件的開發(fā)視為需求、設(shè)計(jì)、編碼等一系列的串行活動(dòng)，軟件開發(fā)和測試保持一種線性的前后關(guān)系，需要有嚴(yán)格的指令表示上一個(gè)階段完全結(jié)束，才可以正式開始下一個(gè)階段，無法支持迭代開發(fā)模型
22、H模型：特點(diǎn)：H模型將測試活動(dòng)完全獨(dú)立出來，形成一個(gè)完全獨(dú)立的流程，貫穿于整個(gè)產(chǎn)品周期，與其他流程并發(fā)的進(jìn)行，盡早準(zhǔn)備，盡早執(zhí)行，測試準(zhǔn)備階段與測試執(zhí)行分離，有利于資源調(diào)配、減低成本，提高效率，充分體現(xiàn)測試過程的復(fù)雜性。
23、X模型：特點(diǎn)：X模型的左邊描述的是針對單獨(dú)程序片段所進(jìn)行的相互分離的編碼和測試，此后，將進(jìn)行頻繁的交換，通過集成最終合成為可執(zhí)行的程序，W模型還定位了探索性測試，這是不進(jìn)行是先計(jì)劃的特殊類型的測試，這一方式往往能幫助有經(jīng)驗(yàn)的測試人員在測試計(jì)劃之外發(fā)現(xiàn)更多的軟件錯(cuò)誤;局限性：提出了測試設(shè)計(jì)，卻沒有指出在軟件測試的各個(gè)階段都應(yīng)該進(jìn)行測試設(shè)計(jì)，過于關(guān)注低級別即程序級別的行為，而沒有抽象成一個(gè)系統(tǒng)的模型，可能對測試造成人力、物力和財(cái)力的浪費(fèi)，對測試人員的熟練程度要求比較高。
24、前置模型：特點(diǎn)：前置測試模型是將測試和開發(fā)緊密結(jié)合的模型，開發(fā)和測試相結(jié)合，對每一個(gè)交付內(nèi)容進(jìn)行測試，讓驗(yàn)收、測試和技術(shù)測試保持相互獨(dú)立，反復(fù)交替的開發(fā)和測試，引入新的測試?yán)砟睢?/p>
25、測試模型的比較：
V模型：強(qiáng)調(diào)整個(gè)軟件項(xiàng)目開發(fā)需要經(jīng)歷若干個(gè)測試級別，與開發(fā)階段對應(yīng)，沒有指出對需求、設(shè)計(jì)進(jìn)行測試
W模型：強(qiáng)調(diào)測試計(jì)劃等工作的先行和對需求和設(shè)計(jì)的測試，沒有專門針對測試流程予以說明
H模型：表現(xiàn)了測試是獨(dú)立的，每對一個(gè)測試細(xì)節(jié)都有一個(gè)獨(dú)立的操作流程，只要測試前提具備，就可測試
X模型：提出了測試設(shè)計(jì)，沒有指出在軟件測試各個(gè)階段都應(yīng)進(jìn)行測試設(shè)計(jì)
前置模型：前置測試模型將開發(fā)和測試的生命周期整合在一起，伴隨項(xiàng)目開發(fā)生命周期每個(gè)關(guān)鍵行為
26、軟件測試策略：在一定的的軟件測試標(biāo)準(zhǔn)、測試規(guī)范的指導(dǎo)下，依據(jù)測試項(xiàng)目的特定環(huán)境約束而規(guī)定的軟件測試的原則、方式、方法的集合
27、軟件測試規(guī)范：規(guī)范是對項(xiàng)目軟件的一份指導(dǎo)性文件，對軟件測試過程中所涉及到的測試?yán)碚?、測試類型、測試方法、測試標(biāo)準(zhǔn)、測試流程以及軟件產(chǎn)品開發(fā)單位所承擔(dān)的職責(zé)進(jìn)行總體規(guī)范，以有效保證軟件產(chǎn)品的質(zhì)量
28、一般從一下的軟件測試過程進(jìn)行規(guī)范：測試計(jì)劃，主要測試需求分析;測試設(shè)計(jì)，依據(jù)測試需求，分析并選擇測試用例，獲取數(shù)據(jù)、進(jìn)行批判;測試執(zhí)行：執(zhí)行測試，進(jìn)行判斷;測試總結(jié)：整理、分析護(hù)具、效果分析
29、測試文檔內(nèi)容：測試計(jì)劃，測試說明，測試報(bào)告
30、測試計(jì)劃：測試計(jì)劃描述測試活動(dòng)的范圍、方法、資源和進(jìn)度。它規(guī)定被測試的項(xiàng)、被測試的特性、應(yīng)完成的測試任務(wù)、擔(dān)任各項(xiàng)工作的人員職責(zé)以及與本計(jì)劃有關(guān)的風(fēng)險(xiǎn)等
31、測試說明：測試設(shè)計(jì)說明，測試用例說明，測試規(guī)程說明
32、測試報(bào)告：測試項(xiàng)傳遞報(bào)告，測試日志，測試時(shí)間報(bào)告，測試總結(jié)報(bào)告
34、CMM軟件能力成熟度模型
35、CMMI能力成熟度集成模型
36、軟件測試的分類：
是否被執(zhí)行：靜態(tài)測試，動(dòng)態(tài)測試
是否關(guān)注軟件結(jié)構(gòu)：白盒測試，黑盒測試
基于測試的不同階段：單元測試，集成測試，系統(tǒng)測試，驗(yàn)收測試，回歸測試，Alpha測試，Beta測試
37、靜態(tài)測試：不執(zhí)行程序代碼而尋找代碼中可能存在的錯(cuò)誤或評估程序代碼的過程
38、靜態(tài)測試的特點(diǎn)：靜態(tài)測試不必動(dòng)態(tài)的執(zhí)行程序，也就是不必進(jìn)行測試用例設(shè)計(jì)和結(jié)果判讀等工作;靜態(tài)測試可以由人手工方式進(jìn)行，充分發(fā)揮人的優(yōu)勢，行之有效;靜態(tài)測試實(shí)施不需要特別的條件，容易展開
39、靜態(tài)測試技術(shù)：人工完成(代碼審查，代碼走查，桌面檢查，技術(shù)評審);由軟件工具自動(dòng)進(jìn)行(靜態(tài)結(jié)構(gòu)分析);代碼質(zhì)量度量
40、代碼審查：工作步驟(預(yù)先作一定的準(zhǔn)備工作，然后舉行會(huì)議進(jìn)行討論)，代碼審查的內(nèi)容(檢查代碼對標(biāo)準(zhǔn)的遵循、可讀性，檢查代碼和設(shè)計(jì)的一致性，檢查代碼的邏輯表達(dá)的正確性，檢查代碼結(jié)構(gòu)的合理性)，代碼審查組(通常由四人組成，其中一人為組長，根據(jù)測試的組織方式不同，代碼審查小組組成可以調(diào)節(jié)，但組長角色不能改動(dòng))，代碼審查的步驟(準(zhǔn)備，程序閱讀，審查會(huì)，跟蹤及報(bào)告)
41、代碼走查：代碼走查的過程(與代碼審查過程相似，先把材料交給每個(gè)小組成員，讓他們認(rèn)真研究程序，然后再召開代碼走查會(huì))，代碼走查會(huì)議的內(nèi)容(用測試用例沿程序邏輯走一遍，并由測試人員講述程序執(zhí)行過程，在紙上或黑板上見識程序狀態(tài))，代碼走查組(代碼走查組以小組方式進(jìn)行，代碼走查組包括組長、秘書、測試人員、設(shè)計(jì)人員)，測試用例在代碼走查中的作用(代碼走查中，測試用例并不是關(guān)鍵，測試用例是作為換衣程序邏輯錯(cuò)誤與計(jì)算錯(cuò)誤的啟發(fā)點(diǎn))，缺點(diǎn)(代碼走查使用測試用例啟發(fā)檢測錯(cuò)誤，人們注意力會(huì)相對集中在隨測試用例游歷的程序邏輯路徑上，不如代碼審查檢查的范圍廣，錯(cuò)誤覆蓋全面)
42、桌面檢查：缺點(diǎn)(第一，由于心理上的原因，容易對自己的程序的偏愛，沒有發(fā)現(xiàn)錯(cuò)誤的欲望。第二，由于人的思維定勢，有些習(xí)慣性的錯(cuò)誤自己不易發(fā)現(xiàn)，第三，如果根本對功能理解錯(cuò)了，自己不易糾正)
43、技術(shù)評審：綜合運(yùn)用走查和審查技術(shù)，逐頁、逐節(jié)地檢查軟件開發(fā)前期需求分析和設(shè)計(jì)的文檔，對軟件的需求，設(shè)計(jì)結(jié)構(gòu)等方面提出問題
44、靜態(tài)結(jié)構(gòu)分析：(1)檢查函數(shù)的調(diào)用關(guān)系是否正確(2)是否存在孤立的函數(shù)沒有被調(diào)用(3)明確函數(shù)被調(diào)用的頻繁度，對調(diào)用頻繁的函數(shù)可以重點(diǎn)檢查
45、代碼質(zhì)量度量：Line復(fù)雜度(以代碼的行數(shù)作為計(jì)算的基準(zhǔn))，Helstead復(fù)雜度(以程序中使用到的運(yùn)算符與運(yùn)算元數(shù)量作為技術(shù)目標(biāo))，McCabe復(fù)雜度(實(shí)質(zhì)上是對程序拓?fù)浣Y(jié)構(gòu)的復(fù)雜性的度量)
46、靜態(tài)測試的內(nèi)容：需求定義、測試文檔、源代碼的靜態(tài)測試
47、動(dòng)態(tài)測試的步驟：單元測試(對軟件中的基本組成單位進(jìn)行測試，檢查基本組成單位的正確性)，集成測試(在軟件系統(tǒng)集成過程中所進(jìn)行的測試，檢查單位之間結(jié)構(gòu)是否準(zhǔn)確)，系統(tǒng)測試(對已經(jīng)集成好的軟件系統(tǒng)進(jìn)行徹底的測試，以驗(yàn)證軟件系統(tǒng)的正確性和性能等是否滿足規(guī)定)，驗(yàn)收測試(軟件投入使用之前的最后測試)，回歸測試(軟件的維護(hù)階段)
48、黑盒測試：黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動(dòng)測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個(gè)功能是否都能正常使用
49、黑盒測試測用于發(fā)現(xiàn)：是否有不正確或遺漏了的功能;在接口上，能否正確地接受輸入數(shù)據(jù)，能否正常的產(chǎn)生輸出信息;訪問外部信息是否有錯(cuò);性能上是否滿足要求;界面是否錯(cuò)誤，是否不美觀;初始化或終止錯(cuò)誤58、人工測試的優(yōu)點(diǎn)：測試用例的設(shè)計(jì)，測試人員的經(jīng)驗(yàn)和對錯(cuò)誤的判斷能力是自動(dòng)化測試不可替代的;界面和用戶體驗(yàn)測試，人類的界面審核和心理體驗(yàn)是自動(dòng)化測試不可模擬的;正確定的檢查，人們對是非的判斷、邏輯推理能力是自動(dòng)化測試不具備的;測試過程中的靈活變動(dòng)，人工可以很據(jù)需求進(jìn)行變動(dòng)，調(diào)解;支持不同場景測試，測試過程在復(fù)雜的場景下進(jìn)行測試;手工測試可以完成所有的測試
59、人工測試的缺點(diǎn)：回歸測試的工作量較大;壓力測試、性能測試效果比較差;人為因素比較大
60、自動(dòng)化測試：使用自動(dòng)化測試工具來模擬手動(dòng)測試步驟
61、自動(dòng)化測試的優(yōu)點(diǎn)：對程序的回歸測試更方便;可以運(yùn)用更多更繁瑣的測試;可以執(zhí)行一些人工測試不可能執(zhí)行的測試;更好的利用資源;測試具有一致性和可重復(fù)性;增加軟件信任度
50、黑盒測試的兩種基本方法：通過測試，失敗測試
51、黑盒測試的優(yōu)點(diǎn)：比較簡單，不需要了解程序內(nèi)部的代碼及實(shí)現(xiàn);與軟件的內(nèi)部實(shí)現(xiàn)無關(guān);從用戶角度出發(fā)，能很容易的知道用戶會(huì)用到哪些功能，會(huì)遇到哪些問題;基于軟件開發(fā)文檔，所以也能知道軟件實(shí)現(xiàn)了文檔中的那些功能;在做軟件自動(dòng)化測試時(shí)較為方便
52、黑盒測試的缺點(diǎn)：不可能覆蓋所有代碼，覆蓋率較低，大約30%;自動(dòng)化測試的復(fù)用性較低
53、白盒測試：基于代碼的測試
54、白盒測試的優(yōu)點(diǎn)：更易于定位錯(cuò)誤的原因和具體的位置
55、白盒測試的缺點(diǎn)：不能檢出程序中的設(shè)計(jì)缺陷;不能檢查是否遺漏了功能;發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯(cuò)誤
56、白盒測試的分類：靜態(tài)白盒測試，動(dòng)態(tài)白盒測試
57、人工測試：由人工按照事先對需求要分析文檔而寫好的測試用例一個(gè)一個(gè)的輸入執(zhí)行，然后觀察結(jié)果，檢測是否對應(yīng)
看了“測試工程師知識點(diǎn)”的還看了：
1.測試工作求職信
2.教師教育方面自我評價(jià)
3.大學(xué)計(jì)算機(jī)期末論文
4.上行帶寬怎么測試
5.關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)安全證書介紹