測試技術(shù)基礎(chǔ)重要知識點(軟件測試應具備哪些)
1.軟件測試應具備哪些基礎(chǔ)知識
理論上講，做軟件測試的要求有什么就要懂什么，不是什么人都可以做的。但實際上測試工程師是有初、中、高三級之分的。而初級工程師所需要的知識不多，一般只需要學過簡單的理論即可。中、高級相信需要一段過渡時期的，它們都必須以工具為主。
至于教材，可以說所有的計算機教材都是其中的一部分，就差你是什么方向的測試工作。一般來說，開始的時候，你只需要一本《軟件測試理論》入門即可。有空可以看看《測試的藝術(shù)》一書（得益網(wǎng)有得下載）。
什么數(shù)據(jù)庫\開發(fā)語言，這些與軟件測試都是什么關(guān)系？？？
至于這個問題，首先要說明，軟件測試一般可分為：單元測試、集成測試、系統(tǒng)測試、驗收測試。單元測試一方面是直接對代碼進行直讀，所以它要求必需懂得開發(fā)語言，另一方面它要寫驅(qū)動和樁，所以也要懂開發(fā)語言。（一般單元測試都是要開發(fā)人員扶助的）。而數(shù)據(jù)庫，簡單來說每當我們要驗證一條記錄的所有信息是否完整，都需要進入數(shù)據(jù)庫中查看，查看是否有漏某個字段；而從更高層次來講，它涉及到系統(tǒng)性能調(diào)優(yōu)問題。
2.測試工程師都需要掌握哪些知識
軟件測試工程師需要具備哪些技能？
1、軟件工程技能 你必須了解軟件軟件工程（設(shè)計、開發(fā)和簡單測試），應用，系統(tǒng)，自動測試編程，及操作系統(tǒng)，數(shù)據(jù)庫，網(wǎng)絡系統(tǒng)和協(xié)議的設(shè)計和使用。
2、交流技巧 如果想確定軟件缺陷，你應當能夠指出什么時候的缺陷算是缺陷。
3、組織技能 如果你在別人都頭腦發(fā)昏的時候保持清醒，你就可能是一個好的軟件測試工程師。在網(wǎng)絡時代軟件測試是一項有壓力的復雜性工作，但如果你能從這些紛繁中找到一種途徑，它就是一項回報豐厚的事業(yè)。
4、實踐技能 當一個工作需要經(jīng)驗，而你又需要一個工作去豐富你的經(jīng)驗時該怎么辦？這并不完全是一個兩難的問題，你可能采用幾種方式去獲得實際經(jīng)驗。
5、態(tài)度 除了技術(shù)水平，你需要理解和采取適當?shù)膽B(tài)度去做軟件測試。
3.軟件測試師要掌握的基礎(chǔ)知識有哪些
1）熟悉計算機基礎(chǔ)知識； （2）熟悉操作系統(tǒng)、數(shù)據(jù)庫、中間件、程序設(shè)計語言基礎(chǔ)知識； （3）熟悉計算機網(wǎng)絡基礎(chǔ)知識； （4）熟悉軟件工程知識，理解軟件開發(fā)方法及過程； （5）熟悉軟件質(zhì)量及軟件質(zhì)量管理基礎(chǔ)知識； （6）熟悉軟件測試標準； （7）掌握軟件測試技術(shù)及方法； （8）掌握軟件測試項目管理知識； （9）掌握C語言以及C++或Java語言程序設(shè)計技術(shù)； （10）了解信息化及信息安全基礎(chǔ)知識； （11）熟悉知識產(chǎn)權(quán)相關(guān)法律、法規(guī)； （12）正確閱讀并理解相關(guān)領(lǐng)域的英文資料。
通過本考試的合格人員能在掌握軟件工程與軟件測試知識的基礎(chǔ)上，運用軟件測試管理方法、軟件測試策略、軟件測試技術(shù)，獨立承擔軟件測試項目；具有工程師的實際工作能力和業(yè)務水平。
4.軟件測試師要掌握的基礎(chǔ)知識有哪些
1）熟悉計算機基礎(chǔ)知識；
(2)熟悉操作系統(tǒng)、數(shù)據(jù)庫、中間件、程序設(shè)計語言基礎(chǔ)知識；
(3)熟悉計算機網(wǎng)絡基礎(chǔ)知識；
(4)熟悉軟件工程知識，理解軟件開發(fā)方法及過程；
(5)熟悉軟件質(zhì)量及軟件質(zhì)量管理基礎(chǔ)知識；
(6)熟悉軟件測試標準；
(7)掌握軟件測試技術(shù)及方法；
(8)掌握軟件測試項目管理知識；
(9)掌握C語言以及C++或Java語言程序設(shè)計技術(shù)；
(10)了解信息化及信息安全基礎(chǔ)知識；
(11)熟悉知識產(chǎn)權(quán)相關(guān)法律、法規(guī)；
(12)正確閱讀并理解相關(guān)領(lǐng)域的英文資料。
通過本考試的合格人員能在掌握軟件工程與軟件測試知識的基礎(chǔ)上，運用軟件測試管理方法、軟件測試策略、軟件測試技術(shù)，獨立承擔軟件測試項目；具有工程師的實際工作能力和業(yè)務水平。
5.軟件測試的知識點有哪些
第一章1、軟件測試的定義：IEEE給出的定義——軟件測試是使用人工和自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清楚預期結(jié)果與實際結(jié)果之間的差別。
《軟件測試技術(shù)基礎(chǔ)》——軟件測試是為了盡快盡早地發(fā)現(xiàn)在軟件產(chǎn)品中所存在的各種軟件缺陷而展開的貫穿整個軟件開發(fā)生命周期、對軟件產(chǎn)品（包括階段性產(chǎn)品）進行驗證和確認的活動過程。2、軟件測試的目的軟件質(zhì)量：1.發(fā)現(xiàn)系統(tǒng)的錯誤2. 驗證系統(tǒng)是否滿足需求3. 為產(chǎn)品放行提供依據(jù)4. 改進開發(fā)流程對于企業(yè)來說：回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造成的隱患所帶來的商業(yè)風險。
測試的重要目的之一：發(fā)現(xiàn)軟件中的缺陷3、軟件測試對象階段性文檔（1 2 3）:1需求規(guī)格說明書 2概要設(shè)計規(guī)格說明書 3詳細設(shè)計規(guī)格說明書4源程序 5系統(tǒng)最終產(chǎn)品文檔（6 7）:6用戶手冊 7幫助文檔4、軟件質(zhì)量保證人員與軟件測試人員同：兩個崗位旨在提高軟件的質(zhì)量異：軟件測試人員SQC1關(guān)心過程的產(chǎn)物2剖析開發(fā)出的軟件質(zhì)量保證人員SQA1全面質(zhì)量管理 2過程改進5、軟件測試的原則1.所有的軟件測試都應追溯到用戶需求2.盡早地、不斷地進行測試3.嚴格執(zhí)行測試計劃4.注重測試用例的設(shè)計5.程序員應該避免測試自己的程序6.增量測試，由小到大7.注意集群現(xiàn)象（二八定理）8.完全測試是不可能的9.測試維護集群現(xiàn)象（二八定理）Pareto原則：測試發(fā)現(xiàn)的錯誤中80%很可能起源于20%的模塊中。6、測試用例IEEE標準610(1990)的定義：測試用例是一組測試輸入、執(zhí)行條件和預期結(jié)果的集合。
其目的是要滿足一個特定的目標，比如執(zhí)行一條特的程序路徑或檢驗是否符合一個特定的需求。一組測試用例包含：1、用例的編號 2、測試標題 3、用例級別 4、預置條件5、操作步驟 6、預期結(jié)果7、軟件測試環(huán)境軟件測試環(huán)境= 軟件+ 硬件+ 網(wǎng)絡+ 歷史數(shù)據(jù)8、軟件缺陷軟件從需求、設(shè)計、編碼、測試一直到交付用戶公開使用后的過程中，都可能產(chǎn)生和發(fā)現(xiàn)缺陷。
需求階段最多，運行維護時花費代價最高。9、軟件測試分類1）、按測試技術(shù)上分類（是否查看代碼）黑盒測試：在程序接口進行測試，它只是檢查程序功能是否按照規(guī)格說明書的規(guī) 定正常用。
也被稱為功能測試或數(shù)據(jù)驅(qū)動測試。白盒測試（測試代碼）：要完全了解程序結(jié)構(gòu)和處理過程，它按照程序內(nèi)部邏輯測試程序，檢驗程序中每條通路是否按預定要求正確工作。
也被稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試?；液袦y試：介于黑盒測試與白盒測試之間的測試，即要像黑盒測試那樣關(guān)注輸出對于輸入的正確性；同時也關(guān)注內(nèi)容表現(xiàn)，但這種關(guān)注不像白盒測試那樣詳細、完整，只是通過一些表征性的現(xiàn)象、事件、標志判斷內(nèi)部的運行狀態(tài)。
避免過度測試，精簡冗余用例。2）、按測試方式上分類（是否運行程序）靜態(tài)測試：是指不運行程序，對程序和文檔進行分析與檢查；靜態(tài)測試技術(shù)又稱為靜態(tài)分析技術(shù)。
6.軟件測試的基礎(chǔ)知識概要是什么
信息技術(shù)的飛速發(fā)展，使軟件產(chǎn)品應用到社會的各個領(lǐng)域，軟件產(chǎn)品的質(zhì)量自然成為人們共同關(guān)注的焦點。
不論軟件的生產(chǎn)者還是軟件的使用者，均生存在競爭的環(huán)境中，軟件開發(fā)商為了占有市場，必須把產(chǎn)品質(zhì)量作為企業(yè)的重要目標之一，以免在激烈的競爭中被淘汰出局。 用戶為了保證自己業(yè)務的順利完成，當然希望選用優(yōu)質(zhì)的軟件。
質(zhì)量不佳的軟件產(chǎn)品不僅會使開發(fā)商的維護費用和用戶的使用成本大幅增加，還可能產(chǎn)生其他的責任風險，造成公司信譽下降，繼而沖擊股票市場。在一些關(guān)鍵應用 （如民航訂票系統(tǒng)、銀行結(jié)算系統(tǒng)、證券交易系統(tǒng)、自動飛行控制軟件、軍事防御和核電站安全控制系統(tǒng)等） 中使用質(zhì)量有問題的軟件，還可能造成災難性的后果。
軟件危機曾經(jīng)是軟件界甚至整個計算機界最熱門的話題。為了解決這場危機，軟件從業(yè)人員、專家和學者做出了大量的努力。
現(xiàn)在人們已經(jīng)逐步認識到所謂的軟件危機實際上僅是一種狀況，那就是軟件中有錯誤，正是這些錯誤導致了軟件開發(fā)在成本、進度和質(zhì)量上的失控。 有錯是軟件的屬性，而且是無法改變的，因為軟件是由人來完成的，所有由人做的工作都不會是完美無缺的。
問題在于我們?nèi)绾稳ケ苊忮e誤的產(chǎn)生和消除已經(jīng)產(chǎn)生的錯誤，使程序中的錯誤密度達到盡可能低的程度。 給軟件帶來錯誤的原因很多，具體地說，主要有如下幾點： ①、交流不夠、交流上有誤解或者根本不進行交流 在應用應該做什么或不應該做什么的細節(jié)（應用的需求）不清晰的情況下進行開發(fā)。
②、軟件復雜性 圖形用戶界面（gui），客戶/服務器結(jié)構(gòu)，分布式應用，數(shù)據(jù)通信，超大型關(guān)系型數(shù)據(jù)庫以及龐大的系統(tǒng)規(guī)模，使得軟件及系統(tǒng)的復雜性呈指數(shù)增長，沒有現(xiàn)代軟件開發(fā)經(jīng)驗的人很難理解它。 ③、程序設(shè)計錯誤 向所有的人一樣，程序員也會出錯。
④、需求變化 需求變化的影響是多方面的，客戶可能不了解需求變化帶來的影響，也可能知道但又不得不那么做。需求變化的后果可能是造成系統(tǒng)的重新設(shè)計，設(shè)計人員的日程的重新安排，已經(jīng)完成的工作可能要重做或者完全拋棄，對其他項目產(chǎn)生影響，硬件需求可能要因此改變，等等。
如果有許多小的改變或者一次大的變化，項目各部分之間已知或未知的依賴性可能會相互影響而導致更多問題的出現(xiàn)，需求改變帶來的復雜性可能導致錯誤，還可能影響工程參與者的積極性。 ⑤、時間壓力 軟件項目的日程表很難做到準確，很多時候需要預計和猜測。
當最終期限迫近和關(guān)鍵時刻到來之際，錯誤也就跟著來了。 ⑥、自負人更喜歡說：'沒問題'，'這事情很容易'，'幾個小時我就能拿出來' 太多不切實際的‘沒問題’，結(jié)果只能是引入錯誤。
⑦、代碼文檔貧乏 貧乏或者差勁的文檔使得代碼維護和修改變的異常艱辛，其結(jié)果是帶來許多錯誤。 事實上，在許多機構(gòu)并不鼓勵其程序員為代碼編寫文檔，也不鼓勵程序員將代碼寫得清晰和容易理解，相反他們認為少寫文檔可以更快的進行編碼，無法理解的代碼更易于工作的保密（“寫得艱難必定讀的痛苦”）。
⑧、軟件開發(fā)工具 可視化工具，類庫，編譯器，腳本工具，等等，它們常常會將自身的錯誤帶到應用軟件中。 就象我們所知道的，沒有良好的工程化作為基礎(chǔ)，使用面向?qū)ο蟮募夹g(shù)只會使項目變得更復雜。
為了更好地解決這些問題，軟件界做出了各種各樣的努力。 人們曾經(jīng)認為更好的程序語言可以使我們擺脫這些困擾，這推動了程序設(shè)計語言的發(fā)展，更多的語言開始流行，為了使程序更易于理解開發(fā)了結(jié)構(gòu)化程序設(shè)計語言，如pl/1,pascal等；為了解決實時多任務需求開發(fā)了結(jié)構(gòu)化多任務程序設(shè)計語言，如modula,ada等；為了提高重用性開發(fā)了面向?qū)ο蟮某绦蛟O(shè)計語言，如simlasa等；為了避免產(chǎn)生不正確的需求理解，開發(fā)形式化描述語言，如hal/s等，這使得建立基于自然語言的描述成為可能，人們以形式化語言來描述需求；為了支持大型數(shù)據(jù)庫應用，開發(fā)了可視化工具，如visual studio、power builder等。
程序語言對提高軟件生產(chǎn)效率起到了一定的積極作用，但它對整個軟件質(zhì)量尤其是可靠性的影響，與其他因素相比作用較小。 可能是因為程序語言基于嚴格的語法和語義規(guī)則，人們企圖用形式化證明方法來證明程序的正確性。
將程序當作數(shù)學對象來看待，從數(shù)學意義上證明程序是正確的是可能的。 數(shù)學家對形式化證明方法最有興趣，在論文上談起來非常吸引人，但實際價值卻非常有限，因為形式化證明方法只有在代碼寫出來之后才能使用，這顯然太遲了，而且對于大的程序證明起來非常困難。
受到其他行業(yè)項目工程化的啟發(fā)，軟件工程學出現(xiàn)了，軟件開發(fā)被視為一項工程，以工程化的方法來進行規(guī)劃和管理軟件的開發(fā)。 針對需求不確定的應用，可以使用漸進和迭代類的開發(fā)模型。
還可以采用快速應用程序開發(fā)（rad）和協(xié)同應用程序開發(fā)（jad）技術(shù)，由軟件開發(fā)者和用戶代表共同參與開發(fā)軟件規(guī)范。rad和jad的基本思路是開發(fā)者和用戶共同設(shè)計系統(tǒng)中的屏幕，開發(fā)者迅速地把實現(xiàn)這些屏幕的最基本功能編寫好，然后把它們交給用戶看，然后用戶和開發(fā)者回顧這些屏幕以確認它們達到了用戶的要求，這個周期一直持續(xù)到系統(tǒng)的基本部分。
