軟件測試實習日記

時間：2022-08-02 08:49:07 實習日記我要投稿

軟件測試實習日記推薦度：
相關(guān)推薦

軟件測試實習日記

　　時間如快馬般匆匆，一天又過去了，相信大家一定感觸頗深吧，需要進行好好的總結(jié)并且記錄在日記里了。為了讓您不再為寫日記頭疼，下面是小編整理的軟件測試實習日記，歡迎大家分享。

軟件測試實習日記

軟件測試實習日記1

　　近段時間，開發(fā)和我們一起做性能測試，涉及一些底層的技術(shù)，也準備開年之后寫自動化的腳本，突然間發(fā)現(xiàn)，測試也是有意義的，不想我之前想的那么討厭，自己在生活中做一些事情，也會按照測試的一些思想來做，有時候變得有點挑剔了，呵呵。而且測試在國內(nèi)還不成熟，人才還很缺，測試也是很有前途的，自己還是喜歡測試這份工作的。而且測試需要我學的東西也很多，邏輯思維和技術(shù)含量還是很高的。唉，恍然大悟了。而且工作這么一段時間，也現(xiàn)實了，在做數(shù)據(jù)庫和開發(fā)我的'經(jīng)驗是有限的，而我那有限的一點經(jīng)驗在測試方面也是綽綽有余了，正好為我的測試提升一步。

　　以前學計算機的時候?qū)τ嬎銠C的知識一點也不感興趣，自從學了數(shù)據(jù)庫之后就對數(shù)據(jù)庫產(chǎn)生了強烈的興趣，對計算機的一些知識也，慢慢的產(chǎn)生了興趣。我喜歡設(shè)計數(shù)據(jù)庫，我喜歡想各種方法，盡量讓她達到最優(yōu)的狀態(tài)，喜歡寫SQL語句，各種復雜的查詢排序等等都寫過，對事務(wù)和索引也研究了一段時間。

軟件測試實習日記2

　　這周的工作任務(wù)主要是完成旅行網(wǎng)的第一輪測試，由于數(shù)據(jù)庫的設(shè)計不合理還有待遇寫的不夠規(guī)范導致我們系統(tǒng)打印不出來，后來把代碼的合理性，還有新版本的功能都做完了的上線了。

　　1、完成了后臺bug的'修改。

　　2、完了管理學生的條件的查詢。

　　3、完成了申請打印的條件查詢。

　　4、票務(wù)管理新增加了一個功能代理商可以修改代理商信息。

　　在完成這幾個任務(wù)需要的時間我們很少了，這是由于全段時間我們對我們這個系統(tǒng)做過很多的修改功能，還有自己對宇整個代碼的流程也是越來熟悉，讓我更加有成就感，因為我不會為了一個簡單的文件而去浪費時間去學習，還有我們可以自己單獨去很多功能了，我就會覺得我們現(xiàn)在的待遇不行。想到這里我們就會覺得自己的心里不平行。

軟件測試實習日記3

　　第二天上班，我有點不習慣早起，公司每天8:30起床�？赡苁且驗檫@是我的第一份正式的實習工作，以前都不曾這么正式的上過班，對于上班沒有過什么想法。所以第二天一大早我不慌不忙的'出發(fā)了。又由于沒平時沒在上班時間出去過，對于擠公交也沒什么概念。擠公交擠到想死。真想說，做個上班族，擠公交是一門必修課。折騰了一早上，我終于踩點到公司報到了。

　　一大早趕到辦公室，覺得桌子很臟，就在清潔阿姨那借來了抹布和水桶，把自己的衛(wèi)生搞好了，開始了一天的工作。

　　今天我又開始看軟件測試的書籍，了解到黑盒測試又稱功能測試：是對已知產(chǎn)品的功能設(shè)計規(guī)格，可以進行測試證明每個實現(xiàn)了的功能是否符合要求。白盒測試則是對已知產(chǎn)品的內(nèi)部工作的過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格是否符合設(shè)計規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。

軟件測試實習日記4

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

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

軟件測試實習日記5

　　昨天把所有的記錯本學生掌握的正確的知識點還有錯誤的知識點都統(tǒng)計出來，雖然功能已經(jīng)實現(xiàn)了，但是我們我覺得這個模塊是真的沒有做完的，因為雖然功能可以正常的顯示了，但是我們沒有測試所有的學生的顯示的結(jié)果是根據(jù)我們需求來的，今天的主要任務(wù)就是做測試，我在打印所有的學生的`記錯本的時候發(fā)現(xiàn)我在每一個學生的記錯本中打印所有學生的錯誤知識點了，這就是一個集合沒有在循環(huán)內(nèi)生成的原因。

　　所以我們以后工作都需要自己測試過所有的功能才去提交。這樣是一個好的習慣，只要這樣我們在工作提交的時候我不需要每個時候都知道我們的工作是否已經(jīng)完成了，如果不去測試而且把我們做的東西提交上去我們，我們的客戶發(fā)現(xiàn)我們的產(chǎn)品都不好，讓我們的用戶覺得這個東西不成熟，這樣我們就會失去很多的用戶。

軟件測試實習日記6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

軟件測試實習日記7

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

軟件測試實習日記8

　　這周的工作主要是對我們整個系統(tǒng)進行檢查bug，由于我們的項目做完過程中是沒有需求文檔，很多的需求根本就不知道要做成什么樣子，導致我們在做集成測試中會遇到各種各樣的問題。當我遇到問題的時候我們只能以我們現(xiàn)在需求來判斷我們原來做過的系統(tǒng)的功能是否完成的`標準。

　　今天在遷移數(shù)據(jù)的時候，搞的人很煩，由于我們原來歷史數(shù)據(jù)數(shù)據(jù)太多的冗余。導致我們現(xiàn)在的新系統(tǒng)的數(shù)據(jù)一直都說不是很完善。還有就是下午遇到我們我們推薦的題目沒有找到在數(shù)據(jù)庫里面導致我們打印記錯本的報錯。這一些都是數(shù)據(jù)的不完善的造成的結(jié)果。

　　進過今天的遇到的問題我想了很多，因為今天的發(fā)生的問題我們完成可以通過數(shù)據(jù)的判斷可以解決這些，所以以后寫代碼的時候多考慮如果沒有數(shù)據(jù)我們寫的代碼會不會報錯呢？還有就是我們寫的東西不錯在界面中報錯。

　　到現(xiàn)在為止我都工作了2個多月了，時間過的飛快，然而自己的想法也是越來越多。因為馬上就面臨到畢業(yè)的時候。一個打算就是自己趕快把自己學校的事情都搞定，還有一個想法就是自己畢業(yè)后盡量跑到沿海地方去，自己不要只要會搞技術(shù)還要學會怎么去處理業(yè)務(wù)邏輯。這樣的自己才能成長的更快。

軟件測試實習日記9

　　了解了各種測試用例的方法，之后又在實際項目中設(shè)計了一些測試用例，總體感覺就是：公司里分配寫作測試用例的時間并不長，而且提供的文檔也不全面，所以寫測試用例要符合測試部門的當前現(xiàn)狀和項目的測試特點，綜合考慮，所以看起來有點像測試計劃的某些內(nèi)容，但是對問題的細化程度不一樣。

　　測試用例的設(shè)計是一項復雜的測試工作，測試用例的設(shè)計方法需要考慮測試的'目標，被測試軟件的特性，測試者人力資源的技術(shù)和能力，測試組織形式，測試進度、測試成本等多個方面。

　　確定測試用例的輸入數(shù)據(jù)確實對于測試用例非常重要，它決定著測試用例的執(zhí)行效果和效率，但是確定輸入測試數(shù)據(jù)只是設(shè)計測試用例的一個步驟，而不是全部。因此，不能把測試用例的設(shè)計方法等同于測試用例數(shù)據(jù)的方法。

軟件測試實習日記10

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

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

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

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

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

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

軟件測試實習日記11

　　今天主要研究W模型

　　V模型的局限性在于沒有明確地說明早期的測試,無法體現(xiàn)“盡早地和不斷地進行軟件測試的原則。在V模型中增加軟件各開發(fā)階段應(yīng)同步進行的測試，演化為W模型（如下圖）。在模型中不難看出，開發(fā)是“V”，測試是與此并行的“V”�；凇氨M早地和不斷地進行軟件測試”的原則，在軟件的需求和設(shè)計階段的測試活動應(yīng)遵循IEEE1012-1998《軟件驗證與確認（V&V）》的原則。

　　W模型由Evolutif公司提出，相對于V模型，W模型更科學。W模型是V模型的'發(fā)展，強調(diào)的是測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設(shè)計同樣要測試。測試與開發(fā)是同步進行的，從而有利于盡早地發(fā)現(xiàn)問題。

　　W模型也有局限性。W模型和V模型都把軟件的開發(fā)視為需求、設(shè)計、編碼等一系列串行的活動，無法支持迭代、自發(fā)性以及變更調(diào)整。

軟件測試實習日記12

　　今天主要開始軟件測試模型的學習，通過學習我主要了解到軟件測試有以下幾個模型：

　　1、V模型

　　在軟件測試方面，V模型是最廣為人知的模型，盡管很多富有實際經(jīng)驗的測試人員還是不太熟悉V模型，或其他的模型。V模型已存在了很長時間，和瀑布開發(fā)模型有著一些共同的特性，由此也和瀑布模型一樣地受到了批評和質(zhì)疑。V模型中的過程從左到右，描述了基本的開發(fā)過程和測試行為。V模型的價值在于它非常明確地標明了測試過程行政工作計劃中存在的`不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。局限性：把測試作為編碼之后的最后一個活動，需求分析等前期產(chǎn)生的錯誤直到后期的驗收測試才能發(fā)現(xiàn).

軟件測試實習日記13

　　今天是實習的第一天，說實話，其實去的路上心里一直都在忐忑。有點緊張有點興奮。不知道平常的日常所學所在實踐中能否用得上，也不知道實際的`軟件測試上怎樣的情況。

　　剛到單位時，由于剛認識感覺有點悶悶的。需求測試部并沒有太多人，設(shè)有一個部門主管，兩個需求和一個運維和一個測試，帶我的是負責測試工作的劉姐。剛?cè)蟮降臅r候，主管帶我到各部門做了個簡單的自我介紹，大家都對我這位90后的新同事給予了熱烈的歡迎。從熱烈的掌聲中我感受到了該單位的工作氣氛比我想象的活躍多了。值得一提的是，在隔壁的設(shè)計部做自我介紹時，居然撞見了一個老鄉(xiāng)，聊著才知道，我們辦公室還有兩個老鄉(xiāng)。為這年頭遇見老鄉(xiāng)不奇怪，但一下子遇見這么多還真是難得。當時，我就想在這里實習一定會很好，很輕松的。

　　介紹完了之后，負責人給我安排了一個座位。由于我之前沒接觸過軟件測試，對軟件測試可以說是一片空白。由于種種原因，劉姐給了我一本軟件測試基礎(chǔ)知識的書，工作第一天我就在座位上看了一整天書。

軟件測試實習日記14

　　目標在我的生活中很重要，每天給自己制定一個小目標，這樣生活就了激情這也是我保持激情的方法之一。今天我的目標是基本掌握邊界值法。

　　使用邊界值分析方法設(shè)計測試用例時一般與等價類劃分結(jié)合起來。但它不是從一個等價類中任選一個例子作為代表，而是將測試邊界情況作為重點目標，選取正好等于、剛剛大于或剛剛小于邊界值的測試數(shù)據(jù)。

　　(1)如果輸入條件規(guī)定了值的范圍，可以選擇正好等于邊界值的數(shù)據(jù)作為合理的測試用例，同時還要選擇剛好越過邊界值的數(shù)據(jù)作為不合理的測試用例。

　　(2)如果輸入條件指出了輸入數(shù)據(jù)的個數(shù)，則按最大個數(shù)、最小個數(shù)、比最小個數(shù)少1、比最大個數(shù)多1等情況分別設(shè)計測試用例。

　　(3)對每個輸出條件分別按照以上原則(1)或(2)確定輸出值的邊界情況。

　　(4)如果程序的'規(guī)格說明給出的輸入或輸出域是個有序集合(如順序文件、線形表、鏈表等)，則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例。

　　3月11號

　　之前學習了測試用例設(shè)計的常用方法，今天計劃是學習另一種方法：正交分析法。

　　正交分析法：即正交分解法是將一個力沿著互相垂直的方向(x軸、y軸)進行分解的方法。

　　正交分解法:(1)明確研究對象(或系統(tǒng));(2)了解運動狀態(tài)(題給出、暗示或判斷、假設(shè));(3)進行受力分析(按順序，場力、彈力、摩擦力);(4)建立坐標,對力進行正交分解(有相對運動或相對運動趨勢的特別是有加速度的，必需建一軸在這方向上,)所建立的坐標原點最好是題目中大多數(shù)力的交點.(5)立方程，解之。(有時還需∑M=0，這不屬正交分解法)

　　正交表：次數(shù)(Runs)：簡單的說，就是次數(shù)是多少，就有多少個用例。因素數(shù)(Factors)：簡單的說，就是有多少個變量。水平數(shù)(Levels)：比如有三個變量，其中變量取值最多的是四個值，那么水平數(shù)就是四。強度(Strength)：即變量間的相互關(guān)系，當強度為二時，只考慮變量兩兩之間的影響，如果強度為三，同考慮三個變量對結(jié)果的影響;當強度增加時，用例的個數(shù)會急劇增加