軟件測試實習日記

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

軟件測試實習日記推薦度：
相關推薦

軟件測試實習日記

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

軟件測試實習日記

軟件測試實習日記1

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

　　以前學計算機的時候對計算機的知識一點也不感興趣，自從學了數據庫之后就對數據庫產生了強烈的興趣，對計算機的一些知識也，慢慢的產生了興趣。我喜歡設計數據庫，我喜歡想各種方法，盡量讓她達到最優的狀態，喜歡寫SQL語句，各種復雜的查詢排序等等都寫過，對事務和索引也研究了一段時間。

軟件測試實習日記2

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

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

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

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

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

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

軟件測試實習日記3

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

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

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

軟件測試實習日記4

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

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

軟件測試實習日記5

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

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

軟件測試實習日記6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

軟件測試實習日記7

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

軟件測試實習日記8

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

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

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

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

軟件測試實習日記9

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

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

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

軟件測試實習日記10

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

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

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

　　我們早期的測試用例是按功能設置用例。后來引進了路徑分析法，按路徑設置用例。目前演變為按功能、路徑混合模式設置用例。

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

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

軟件測試實習日記11

　　今天主要研究W模型

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

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

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

軟件測試實習日記12

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

　　1、V模型

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

軟件測試實習日記13

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

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

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

軟件測試實習日記14

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

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

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

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

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

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

　　3月11號

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

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

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

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