軟件測試實習日記

　　一天即將過去了，心中一定有不少感想，這時候，最關鍵的日記怎么能落下。如何把日記做到重點突出呢？以下是小編幫大家整理的軟件測試實習日記，僅供參考，大家一起來看看吧。

　　第一天

　　原本歡天喜地的盼到了周末，誰知上班第一周就因為項目進度太趕而要加班，沒有辦法，工作需要，只能無抱怨的上。想想那天第一測試，感覺很糾結，總是想這到底是不是錯誤呢，今天明顯有所改觀了。遇到不懂的就直接問測試主管或者是開發(fā)人員，或是自己看ue圖去熟悉流程。這一天我發(fā)現(xiàn)了很多bug，心里有那么點小高興。

　　這幾天的工作讓我明白了做什么事情都不是自己想象的那么簡單，必須堅持下去做，才能夠把事情做好。

　　第二天

　　X模型

　　X模型也是對V模型的改進,X模型提出針對單獨的程序片段進行相互分離的編碼和測試,此后通過頻繁的交接,通過集成最終合成為可執(zhí)行的程序。

　　X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進行測試。己通過集成測試的成品可以進行封裝并提交給用戶，也可以作為更大規(guī)模和范圍內集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，這一方式往往能幫助有經驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。造成測試的成本過高。

　　第三天

　　今天一如既往的在研究軟件測試的計劃的編寫，通過今天的學習我主要明白了編寫軟件測試的重要性和目的：

　　測試計劃是軟件測試中最重要的步驟之一，它在軟件開發(fā)的前期對軟件測試做出清晰，完整的計劃，不光對整個測試起到關鍵性的作用，而且對開發(fā)人員的開發(fā)工作，整個項目的規(guī)劃，項目經理的審查都有輔助性作用。

　　2、測試計劃的目的

　　測試計劃描述所要完成的測試，包括測試背景、測試目的、風險分析、所需資源、任務安排和進度等：

　�。�1）將需求和總體設計分解成可測試，應該測試，推遲測試和無法測試的范圍

　　（2）對每個范圍制訂測試的策略和方法

　�。�3）制訂release和停止測試的標準

　�。�4）準備測試所需要的環(huán)境

　�。�5）確定測試風險

　�。�6）確定軟件測試目標

　�。�7）確定測試所需要的資源其它相關信息

　�。�8）制訂測試進度和任務安排

　　第四天

　　今天任務是了解H模型，H模型中，軟件測試過程活動完全獨立，貫穿于整個產品的周期與其他流程并發(fā)的進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執(zhí)行階段。軟件測試可以盡早的進行，并且可以根據被測物的不同而分層次進行。

　　H模型揭示了一個原理:軟件測試是一個獨立的流程,貫穿產品整個生命周期,與其他流程并發(fā)地進行。H模型指出軟件測試要盡早準備,盡早執(zhí)行。不同的測試活動可以是按照某個次序先后進行的,但也可能是反復的,只要某個測試達到準備就緒點,測試執(zhí)行活動就可以開展

　　第五天

　　做測試已不知不覺有兩個月了�，F(xiàn)在我僅自我總結以下如何做好測試計劃工作。

　　1.明確測試的目標，增強測試計劃的實用性

　　編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結果直觀、準確。

　　2．堅持“5W”規(guī)則，明確內容與過程

　　“5W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的范圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。

　　3．采用評審和更新機制，保證測試計劃滿足實際需求

　　測試計劃寫作完成后，如果沒有經過評審，直接發(fā)送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測試執(zhí)行人員。

　　4.分別創(chuàng)建測試計劃與測試詳細規(guī)格、測試用例

　　應把詳細的測試技術指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔，把用于指導測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據庫中。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術的關系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務的具體戰(zhàn)術。

　　第六天

　　在web服務測試當中，點擊率和模擬的用戶數(shù)是能夠反映出服務壓力的大小。當壓力變大時，事務的響應時間變長，則導致點擊率會受到響應時間的影響，不會因為用戶增多，而增加。點擊率在服務器出現(xiàn)瓶頸時，壓力的增加不會增加點擊率。

　　積累期應該是測試比較輝煌的階段，在公司也有一定資歷和地位，是幕后運籌帷幄的元帥，是能夠運籌于帷幄之中，決勝于千里之外的人。這個時候應該根據實際經驗，根據公司實際情況制定章程，工作標準流程，建立自己的核心團隊，團隊要合理配備要有學習期的也要有成長期的人。其實積累期的人也會彷徨，特別當前面所做的事都基本完成后，發(fā)現(xiàn)沒有動力再次推動。我有一測試朋友他是這么處理，創(chuàng)建一個團隊后就離職然后到新單位再重新來一遍周而復始。我覺得這個時期應該需要創(chuàng)新，包括測試本身的創(chuàng)新，如引入自動化測試，量化考核上，測試框架的建立等。也可以職業(yè)進行新的規(guī)劃，如搞質量管理，有得做研發(fā)管理，做測試咨詢等。

　　第七天

　　懷揣著最初的夢想、保持著那份激情和耐心、我繼續(xù)著我軟件學習的路程。今天我開始了測試用例設計方法的學習。

　　測試用例是軟件測試的核心

　　軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發(fā)現(xiàn)軟件系統(tǒng)的缺陷，保證軟件的優(yōu)良品質，則是軟件公司探索和追求的目標。每個軟件產品或軟件開發(fā)項目都需要有一套優(yōu)秀的測試方案和測試方法。

　　測試用例的設置

　　我們早期的測試用例是按功能設置用例。后來引進了路徑分析法，按路徑設置用例。目前演變?yōu)榘垂δ�、路徑混合模式設置用例。

　　按功能測試是最簡捷的，按用例規(guī)約遍歷測試每一功能。

　　對于復雜操作的程序模塊，其各功能的實施是相互影響、緊密相關、環(huán)環(huán)相扣的，可以演變出數(shù)量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優(yōu)點是在于可以避免漏測試。

　　第八天

　　昨天對測試用例設計一般常用方法進行了學習，感覺有點迷糊，心想要是要項目實踐我會理解得更徹底。今天主要任務是了解測試用例設計的其他方法。包括錯誤推測法、因果圖法、綜合策略法。

1、錯誤推測

　　在測試程序時，人們可能根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例，這就是錯誤推測法。

　　2.因果圖

　　等價類劃分和邊界值方法分析方法都只是孤立地考慮各個輸入數(shù)據的測試功能，而沒有考慮多個輸入數(shù)據的組合引起的錯誤。

　　3.綜合策略

　　每種方法都能設計出一組有用例子，用這組例子容易發(fā)現(xiàn)某種類型的錯誤，但可能不易發(fā)現(xiàn)另一類型的錯誤。因此在實際測試中，聯(lián)合使用各種測試方法，形成綜合策略，通常先用黑盒法設計基本的測試用例，再用白盒法補充一些必要的測試用例。

　　第九天

　　對于開發(fā)來說，并不是所有的bug都需要修復的；而對于測試來說，也并不是所有的bug都是開發(fā)去解決的。處理BUG的方法并不是狹隘的將BUG修復，也包括對BUG進行刪除操作，和放棄選擇。軟件測試的確是一門技術，需要學習各種工具的使用。但真正在工作中，思考新的測試方法或引入新的工具，也是在項目空閑時候，一般大家想的最多的是關于項目本身的問題，測試方法也是平時使用的幾種而已。我覺得最重要的是態(tài)度，態(tài)度意味著責任感，責任感意味著測試人員會想盡辦法把問題找出來，才能根據項目需求發(fā)現(xiàn)合適的測試方法和具，才能在軟件測試時，全神貫注，在執(zhí)行測試用例時不斷發(fā)現(xiàn)新的用例。經驗對于測試人員是寶貴的資本，所以要經�？偨Y，往往能讓自己表達出來的才是體會最深刻的。永遠千萬不要忽略溝通。

　　第十天

　　如何設計測試用例，如何評審測試用例，最后如何管理測試用例，這都是我們測試工作中必須要去改進的問題。在之前的公司，由于團隊工作任務繁忙，我們沒有太多的時間去管理和優(yōu)化測試用例，也因此對用例方面少了太多的思考，而且雖然有對于用例的評審，但一直以來，我認為是做得不夠好的，畢竟每次評審下來，感覺效果沒有預期的那么好，主要還是沒有足夠的時間去管理，所以無法引起重視。不過，現(xiàn)在我想我需要花大量的時間來管理用例了，而且要保證有序的進行，最后輸出讓團隊中各個成員都認為滿意而且高效的測試用例。對于用例管理的根本問題，我個人認為是分類上，如何有效的維護和優(yōu)化用例，就是需要前期明確的分類規(guī)劃，根據分類的優(yōu)先級一步一步地來完成就可以了，到最后，我們也可以有效把控的測試覆蓋度。

　　當前，我們大致可以把測試用例分稱三個方面，分別是功能、UI和業(yè)務流程，從這三個角度來進行設計。

　　1、從功能的角度，功能是每個項目測試的重點，通常在測試人員得到需求文檔的時候，我們就開始設計測試用例，那么這個時候需求文檔上列出都是功能以及部分一些業(yè)務邏輯等，所以在測試用例的第一階段就是完成功能的用例設計。不過這里，肯定會讓很多人疑惑，其實功能、業(yè)務還有UI，都是有關聯(lián)的，而且很多時候無法分解的。這里后面我會舉個例子說明哈，但絕非都是可以分類，只是談談如何分解的方法，最重要的就是不要遺漏就行。

　　2、從UI的角度，UI通常是指界面測試，這個應該不難理解，但要想與功能點進行分解，也不是那么容易區(qū)分的，所以我們來直觀的說明哈。界面測試，注重樣式，外觀、整潔、擺放以及易用性，還包括用戶體驗等。

　　3、從業(yè)務的角度，這個相對來說，還比較好理解，業(yè)務通常是指一連串的動作所連接起來的流程，這個流程必須有行為和目標，或者說方向。業(yè)務通常是一個項目或者產品設計的核心，當下，越來越多的應用業(yè)務流程都是非常復雜，所以對于業(yè)務的用例設計，就是考驗一個測試人員的業(yè)務水平如何。

　　下面通過一個證券交易平臺上的買入和撤單業(yè)務，進行具體說明：

　　業(yè)務說明：買入業(yè)務包括股票代碼、當前價格、買入價格，買入股票數(shù)量、確定買入按鈕和取消按鈕;

　　撤單業(yè)務包括選擇撤單的未成交業(yè)務、撤單成功、撤單失敗以及取消撤單按鈕;

　　以上只是大致列舉了一部分。

　　功能點：買入按鈕、取消按鈕、選擇撤單、撤單按鈕和取消撤單按鈕等

　　UI界面測試：股票代碼、當前價格、買入價格、買入股票數(shù)量，所有的文本框;買入成功/失敗的提示框;撤單成功/失敗的提示框;撤單成功/失敗的業(yè)務狀態(tài)等。

　　業(yè)務測試：買入業(yè)務，從輸入買入表單的數(shù)據，到提交表單，到最后買入的表單顯示的位置，以及買入提交但未成交，可以撤單，完成撤單的業(yè)務，到撤單成功或者失敗等，這一連串的工作組合就是一個業(yè)務流程。

　　其實這里就存在一個爭議性的問題，對于買入和撤單，既可以作為功能點，也可以作為一個業(yè)務邏輯來設計，但從本質上來講，功能點注重單獨的操作，而業(yè)務流重的在是一個流程，還需要具體業(yè)務去甄別。功能點的設計更主要對這個買入和撤單的按鈕本身進行用例設計;而業(yè)務則是需要從買入和撤單之前的輸入到最后輸出這樣一個過程來設計。

　　以上也只是大概的一個簡單的說明，具體的操作還得根據自己的實際流程來執(zhí)行，畢竟測試用例的管理是一個長期的積累和沉淀的過程，好的方法都是總結出來的。對于測試來說，用例是基礎，對于回歸測試、自動化、性能等等都是根本，管理好測試用例，也就是提高測試的工作質量。

　　第十一天

　　早上從寢室出發(fā)就暗示自己要踏踏實實的學習忌浮躁。早上我早早的到公司，開始我的學習，今天我學習的主要內容是測試用例設計方法之劃分等價類法。

　�、偃绻�某個輸入條件規(guī)定了取值范圍或值的個數(shù)。則可確定一個合理的等價類(輸入值或數(shù)在此范圍內)和兩個不合理等價類(輸入值或個數(shù)小于這個范圍的最小值或大于這個范圍的最大值)。

　�、谌绻�規(guī)定了輸入數(shù)據的一組值，而且程序對不同的輸入值做不同的處理，則每個允許輸入值是一個合理等價類，此處還有一個不合理等價類(任何一個不允許的輸入值)。

　�、廴绻�規(guī)定了輸入數(shù)據必須遵循的規(guī)則，可確定一個合理等價類(符合規(guī)則)和若干個不合理等價類(從各種不同角度違反規(guī)則)。

　�、苋绻�已劃分的等價類中各元素在程序中的處理方式不同，則應將此等價類進一步劃分為更小的等價類。

　　第十二天

　　一個的軟件測試工程師要掌握的東西很多。在我個人理解中，軟件工程師應該具備最基本的兩點知識：軟件測試理論知識和一定的開發(fā)技能。

一、軟件測試理論知識

　　這個不用多說，軟件測試人員必須掌握，軟件測試如何融入整個開發(fā)的流程，什么時候介入，什么時候結束，如何搭建測試環(huán)境，如何設計測試用例。

　　二、開發(fā)技能

　　有一定開發(fā)技能的的軟件測試人員在開發(fā)人員眼中更加難得。一般的軟件測試人員特別是黑盒測試人員對開發(fā)不會很懂，與開發(fā)人員交流時存在一定的問題。為了更好的溝通交流，如果軟件測試人員有一定的開發(fā)基礎，將有效的提高測試效率和質量。

　　第十三天

　　今天需要對文化網項目進行第一輪的測試，主要是了解該項目的流程。由于這個文化網比較簡單，沒有相關的需求文檔。但有一個用戶手冊，我根據用戶手冊，在TestLink軟件上進行測試用例的設計和記錄。這一整天我渾身充滿了力量，完全沉浸在測試用設計的報告中。測試中我發(fā)現(xiàn)以下問題;如果在測試時必須考慮輸入條件的各種組合，則可能的組合數(shù)目將是天文數(shù)字，因此必須考慮采用一種適合于描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖。新功能測試，如果不寫完整的測試用例，可能也能發(fā)現(xiàn)80%的問題，但一些測試點被遺漏掉的可能性很大。

　　我覺得測試用例還是要認真地寫的，但是回歸測試確實可以優(yōu)化，不需要每個用例都測。

　　第十四天

　　這周過得可真夠累。由于公司購物網要在規(guī)定實踐發(fā)布，昨天我們主管就通知我們周六加班。我們辦公室的哥哥姐姐很不情愿的申請了加班申請。本想可以好好休息一下了，可明天還得下班啊，想想多么悲催啊！

　　周六很不情愿地從床上爬起來，一大早跑到公司，加班的公司確實比上班時間安靜多了。比較喜歡安靜的我看都這種情況，工作激情又一次被調動起來了。周六一整天我熱情滿滿的測試各個模塊的添加業(yè)務功能。在做測試時，雖然有些頭暈，但還是靜下心來完整了本天的測試工作。覺得特有成就感。從這件事情，我認識到，公司加班有時候是沒辦法的事情。我們做員工的有時候要理解，但當加班過分時，我們做員工的也要勇敢的說NO。員工既要承擔自己的任務又要適當?shù)鼐S護自己的權力。這是我這周的心得。

　　第十五天

　　最近學習了軟件測試過程模型現(xiàn)在對這幾種模型進行以下總結：

　　1.軟件測試過程模型－V模型是軟件開發(fā)瀑布模型的變種，主要反映測試活動與分析和設計的關系；

　　局限性：把測試作為編碼之后的最后一個活動，需求分析等前期產生的錯誤直到后期的驗收測試才能發(fā)現(xiàn)。

　　2.軟件測試過程模型－W模型

　　在V模型的基礎上，增加千開發(fā)階段的同步測試，形成W模型；測試與開發(fā)同步進行，有利用盡早的發(fā)現(xiàn)問題。

　　局限性：仍把開發(fā)活動看成是從需求開始到編碼結束的串行活動，只有上一階段完成后，才可以開始下一階段的活動，不能支持迭代，自發(fā)性以及變更調整。

　　3.軟件測試過程模型－H模型

　　在H模型中，軟件測試過程活動完全獨立，貫穿于整個產品的周期，與其他流程并發(fā)地進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執(zhí)行階段；軟件測試可以進行盡早的進行；軟件測試可以根據被測物的不同而分層次進行測試模型使用軟件。

　　在實際工作中應靈活地運用各種模型的優(yōu)點：

　　V模型:強調了在整個軟件項目開發(fā)中需要經歷的若干個測試級別，并與每一個開發(fā)級別對應；忽略了測試的對象不應該僅僅包括程序，沒有明確指出對需求、設計的測試。

　　W模型:補充了V模型中忽略的內容，強調了測試計劃等工作的先行和對系統(tǒng)需求和系統(tǒng)設計的測試；與V模型相同，沒有對軟件測試的流程進行說明。

　　H模型:強調測試是獨立的，只要測試準備完成，就可以執(zhí)行測試。

【軟件測試實習日記】相關文章：

軟件測試實習心得04-19

軟件測試實習心得體會04-02

面試軟件測試的問題04-07

軟件測試面試技巧04-07

軟件測試求職技巧04-09

軟件測試個人總結05-19

軟件測試實習總結報告1400字03-26

軟件測試經典面試題04-07

軟件測試的面試題04-07