一天的生活不知不覺間結束了，相信你有很多感悟吧，讓我們今天做個總結，寫一篇日記吧。是不是無從下筆、沒有頭緒？以下是小編整理的軟件測試實習日記，僅供參考，大家一起來看看吧。
實習的第一週
按照公司安排，分配到基站那邊熟悉設備和操作器件任務是認識基站設備RBS2206(室內宏蜂窩)的組成，請點各基站設備資產，登記載波的開啟情況，進行備用電池的放電測試，門禁系統的開啟關閉操作，空調温度的調整(一般為26度)等
由於我們隊員較多，隊長安排我們向另外兩名早來的實習生學習我們的工作地點是海珠區的中國移動的各個基站點(主要分佈在樓宇天台和地下停車場)，時間是每天早上9點鐘到下午6點，中午休息一會兒工作任務較為簡單，操作起來單調機械，需要乘坐麪包車到處去各個點奔波抱着學習和吃苦的態度，還是認真的完成任務起先進入基站都感覺好奇，認真地向隊長和隊員們請教問題有的問題都覺得太簡單，但書本上從未涉及過，還是坦誠地向別人請教
這一週的工作下來，學會了基站的各個部件的位置組成和實物外觀，結合所學書本上的知識，加深了各器件的瞭解和提高了實際動手操作能力學會了與來自不同教育背景和生活地方的同事的交流與合作，深感工作上要不恥下問和同事間要合作緊密才能很好地完成工作任務
實習的第二週
依然是在基站學習工作任務與上一週的大概相同，熟悉基站設備，備用電池的放電測試，不過開始進行故障處理和部分時間進行巡檢
工作地點仍然是海珠區的廣東移動的基站機房與室外基站，不過檢查的基站點與上一週略為不同，都第一次進入檢查時間上也一樣，雖然我們組要值夜班，考慮到我們實習生的身份，暫時不作安排
這一週的工作與之前的工作內容大致相同，其中故障處理較多，故障處理一般就是更換基站設備，如CDU，TRU(載波)，DXU等，更換設備有一套標準的流程，實踐動手不能馬虎了事還有部分巡檢，需要用OMT軟件連接設備，主要用來定位基站設備故障工作上依然單調枯燥，但不能放鬆，以免出現安全事故或工作不到位，給下一步流程的工作的同事帶來重複的麻煩
實習的第三週
基站工作結束，開始做網優相關工作，網優主要包括路測，驗收，樓宇普查，掃頻等任務，是比基站的工作複雜一點，是處理解決信號問題的主要人員
工作地點是廣州移動的業務數據中心，我所在的'組是西區，位於體育中心和珠江新城一帶，工作時間與之前一樣第一天由負責人説明工作流程和注意事項，沒有接觸到實際的網優工作，都是一些送文件和設備給同事使用的跑腿工作
這一週的工作不多，負責人的一番指導和教悔也讓我認識網優這一職位屬於幹活多薪資少的工作，需要耐心努力地學習理論和操作知識，吃苦耐勞踏實工作才能完成工作
實習的第四周
這一週才是接觸到網優的實際工作，路測，路測就是道路測試信號，由於道路上都可能佔用多個小區，甚至是越區覆蓋，是網優中分析處理問題的一個很好的學習過程
工作地點是廣州大道位於中山大道及體育東路之間的一段道路，實際上就是天河路一帶，時間是凌晨2點開始，因為剛剛進行過割接小區，所以測試一下割接後小區佔用情況數據顯示信號強度正常，只存在局部地點出現質差，割接成功
這一週的工作是和一位路測隊長學習，在測試過程中繁繁出現問題，手機電池沒電，數據線連不通，電腦鼠標不動，沒有帶上3G卡，最後測試時間縮短減少電池使用時間，回公司更換數據線，暫時沒有測試3G與2G切換情況信號測試前的設備檢查是否完好，測試軟件的熟悉準備都是測試前必須注意的問題
這周的工作主要是對我們整個系統進行檢查bug，由於我們的項目做完過程中是沒有需求文檔，很多的需求根本就不知道要做成什麼樣子，導致我們在做集成測試中會遇到各種各樣的問題。當我遇到問題的時候我們只能以我們現在需求來判斷我們原來做過的系統的功能是否完成的標準。
今天在遷移數據的時候，搞的人很煩，由於我們原來歷史數據數據太多的宂餘。導致我們現在的新系統的數據一直都説不是很完善。還有就是下午遇到我們我們推薦的題目沒有找到在數據庫裏面導致我們打印記錯本的報錯。這一些都是數據的不完善的造成的結果。
進過今天的`遇到的問題我想了很多，因為今天的發生的問題我們完成可以通過數據的判斷可以解決這些，所以以後寫代碼的時候多考慮如果沒有數據我們寫的代碼會不會報錯呢？還有就是我們寫的東西不錯在界面中報錯。
到現在為止我都工作了2個多月了，時間過的飛快，然而自己的想法也是越來越多。因為馬上就面臨到畢業的時候。一個打算就是自己趕快把自己學校的事情都搞定，還有一個想法就是自己畢業後儘量跑到沿海地方去，自己不要只要會搞技術還要學會怎麼去處理業務邏輯。這樣的自己才能成長的更快。
項目經過一段時間的測試，終於快要完成了，這個星期主要是迴歸測試。就是把提過BUG的單，經過開發修改過後的系統再進行測試。迴歸全部通過，説明系統的質量不差。測完並且編寫用户手冊。 迴歸測試並不減少對系統新功能和特徵的測試需求，迴歸測試包應包括新功能和特徵的測試。如果迴歸測試包不能達到所需的覆蓋要求，必須補充新的測試用例使覆蓋率達到規定的要求。
有成為一名優秀的軟件工程師必須要有嚴謹的工作態度，能夠勝任反覆性的.工作。必須要懂得與人良好的溝通。描述具體問題時，應準確，最後以圖文並茂的方式展示問題。
在組織迴歸測試時需要注意兩點，首先是各測試階段發生的修改一定要在本測試階段內完成迴歸，以免將錯誤遺留到下一測試階段。其次，迴歸測試期間應對該軟件版本凍結，將回歸測試發現的問題集中修改，集中迴歸。
目標在我的生活中很重要，每天給自己制定一個小目標，這樣生活就了激情這也是我保持激情的方法之一。今天我的目標是基本掌握邊界值法。
使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來。但它不是從一個等價類中任選一個例子作為代表，而是將測試邊界情況作為重點目標，選取正好等於、剛剛大於或剛剛小於邊界值的測試數據。
(1)如果輸入條件規定了值的範圍，可以選擇正好等於邊界值的數據作為合理的測試用例，同時還要選擇剛好越過邊界值的數據作為不合理的`測試用例。
(2)如果輸入條件指出了輸入數據的個數，則按最大個數、最小個數、比最小個數少1、比最大個數多1等情況分別設計測試用例。
(3)對每個輸出條件分別按照以上原則(1)或(2)確定輸出值的邊界情況。
(4)如果程序的規格説明給出的輸入或輸出域是個有序集合(如順序文件、線形表、鏈表等)，則應選取集合的第一個元素和最後一個元素作為測試用例。
3月11號
之前學習了測試用例設計的常用方法，今天計劃是學習另一種方法：正交分析法。
正交分析法：即正交分解法是將一個力沿着互相垂直的方向(x軸、y軸)進行分解的方法。
正交分解法:(1)明確研究對象(或系統);(2)瞭解運動狀態(題給出、暗示或判斷、假設);(3)進行受力分析(按順序，場力、彈力、摩擦力);(4)建立座標,對力進行正交分解(有相對運動或相對運動趨勢的特別是有加速度的，必需建一軸在這方向上,)所建立的座標原點最好是題目中大多數力的交點.(5)立方程，解之。(有時還需∑M=0，這不屬正交分解法)
正交表：次數(Runs)：簡單的説，就是次數是多少，就有多少個用例。因素數(Factors)：簡單的説，就是有多少個變量。水平數(Levels)：比如有三個變量，其中變量取值最多的是四個值，那麼水平數就是四。強度(Strength)：即變量間的相互關係，當強度為二時，只考慮變量兩兩之間的影響，如果強度為三，同考慮三個變量對結果的影響;當強度增加時，用例的個數會急劇增加
做測試已不知不覺有兩個月了。現在我僅自我總結以下如何做好測試計劃工作。
1.明確測試的目標，增強測試計劃的實用性
編寫軟件測試計劃得重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計劃的價值取決於它對幫助管理測試項目，並且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確
2．堅持“5W”規則，明確內容與過程
“5W”規則指的是“What（做什麼）”、“Why（為什麼做）”、“When（何時做）”、“Where（在哪裏）”、“How（如何做）”。利用“5W”規則創建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的`範圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。
3．採用評審和更新機制，保證測試計劃滿足實際需求
測試計劃寫作完成後，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
4.分別創建測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
前面測試計劃的學習告一段落了。從今天起我將專心軟件測試用例設計的學習。
軟件測試用例就是一個文檔，描述輸入、動作、或者時間和一個期望的結果，其目的是確定應用程序的某個特性是否正常的工作。
測試輸入
提供測試執行中的各種輸入條件。根據需求中的'輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那麼測試用例設計中會遇到很大的障礙。
操作步驟
提供測試執行過程的步驟。對於複雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出。
預期結果
提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。如果在實際測試過程中，得到的實際測試結果與預期結果不符，那麼測試不通過；反之則測試通過。
早上從寢室出發就暗示自己要踏踏實實的學習忌浮躁。早上我早早的到公司，開始我的學習，今天我學習的主要內容是測試用例設計方法之劃分等價類法。
①如果某個輸入條件規定了取值範圍或值的個數。則可確定一個合理的`等價類(輸入值或數在此範圍內)和兩個不合理等價類(輸入值或個數小於這個範圍的最小值或大於這個範圍的最大值)。
②如果規定了輸入數據的一組值，而且程序對不同的輸入值做不同的處理，則每個允許輸入值是一個合理等價類，此處還有一個不合理等價類(任何一個不允許的輸入值)。
③如果規定了輸入數據必須遵循的規則，可確定一個合理等價類(符合規則)和若干個不合理等價類(從各種不同角度違反規則)。
④如果已劃分的等價類中各元素在程序中的處理方式不同，則應將此等價類進一步劃分為更小的等價類。
今天早上起得比較早，到公司也挺早的。在路上我就計劃好了今天的主要任務是學習測試計劃編寫基本策略：
到公司打開電腦，就開始了編寫測試計劃編寫的基本策略：從學習中我瞭解到要編寫一個好的測試計劃絕非易事項目。第一點測試計劃編寫依據：項目計劃、項目計劃的評估狀態以及業務的理解。第二點測試計劃編寫的時間必須規劃好。第三點測試計劃的編寫與實施人員必須註明。第四點測試計劃的變更：測試計劃是一個發展變化的文檔，會隨着項目的發展，人員或環境的`變動而變化。第五點測試計劃的優先級別必須制定好。第六點測試計劃的評審第七點測試計劃制定過程：1、評估項目計劃和狀態2、組建測試小組3、瞭解項目風險4、制定測試計劃5、審查測試計劃第八點測試計劃應遵循以下原則：儘早開始原則、靈活變更原則、合理評審原則、簡潔易讀原則。
最近學習了軟件測試過程模型現在對這幾種模型進行以下總結：
1.軟件測試過程模型－V模型是軟件開發瀑布模型的變種，主要反映測試活動與分析和設計的關係；
侷限性：把測試作為編碼之後的最後一個活動，需求分析等前期產生的錯誤直到後期的驗收測試才能發現
2.軟件測試過程模型－W模型
在V模型的基礎上，增加千開發階段的同步測試，形成W模型；測試與開發同步進行，有利用盡早的發現問題
侷限性：仍把開發活動看成是從需求開始到編碼結束的串行活動，只有上一階段完成後，才可以開始下一階段的活動，不能支持迭代，自發性以及變更調整
3.軟件測試過程模型－H模型
在H模型中，軟件測試過程活動完全獨立，貫穿於整個產品的週期，與其他流程併發地進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執行階段；軟件測試可以進行儘早的進行；軟件測試可以根據被測物的不同而分層次進行
測試模型使用軟件
在實際工作中應靈活地運用各種模型的優點
V模型:強調了在整個軟件項目開發中需要經歷的若干個測試級別，並與每一個開發級別對應；忽略了測試的對象不應該僅僅包括程序，沒有明確指出對需求、設計的'測試
W模型:補充了V模型中忽略的內容，強調了測試計劃等工作的先行和對系統需求和系統設計的測試；與V模型相同，沒有對軟件測試的流程進行説明
H模型:強調測試是獨立的，只要測試準備完成，就可以執行測試
瞭解了各種測試用例的方法，之後又在實際項目中設計了一些測試用例，總體感覺就是：公司裏分配寫作測試用例的時間並不長，而且提供的文檔也不全面，所以寫測試用例要符合測試部門的當前現狀和項目的測試特點，綜合考慮，所以看起來有點像測試計劃的某些內容，但是對問題的細化程度不一樣。
測試用例的設計是一項複雜的.測試工作，測試用例的設計方法需要考慮測試的目標，被測試軟件的特性，測試者人力資源的技術和能力，測試組織形式，測試進度、測試成本等多個方面。
確定測試用例的輸入數據確實對於測試用例非常重要，它決定着測試用例的執行效果和效率，但是確定輸入測試數據只是設計測試用例的一個步驟，而不是全部。因此，不能把測試用例的設計方法等同於測試用例數據的方法。
在web服務測試當中，點擊率和模擬的用户數是能夠反映出服務壓力的大小。當壓力變大時，事務的響應時間變長，則導致點擊率會受到響應時間的影響，不會因為用户增多，而增加。點擊率在服務器出現瓶頸時，壓力的增加不會增加點擊率。
積累期應該是測試比較輝煌的'階段，在公司也有一定資歷和地位，是幕後運籌帷幄的元帥，是能夠運籌於帷幄之中，決勝於千里之外的人。這個時候應該根據實際經驗，根據公司實際情況制定章程，工作標準流程，建立自己的核心團隊，團隊要合理配備要有學習期的也要有成長期的人。其實積累期的人也會彷徨，特別當前面所做的事都基本完成後，發現沒有動力再次推動。我有一測試朋友他是這麼處理，創建一個團隊後就離職然後到新單位再重新來一遍周而復始。我覺得這個時期應該需要創新，包括測試本身的創新，如引入自動化測試，量化考核上，測試框架的建立等。也可以職業進行新的規劃，如搞質量管理，有得做研發管理，做測試諮詢等。
懷揣着最初的夢想、保持着那份激情和耐心、我繼續着我軟件學習的路程。今天我開始了測試用例設計方法的學習。
測試用例是軟件測試的核心
軟件測試的重要性是毋庸置疑的.。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。每個軟件產品或軟件開發項目都需要有一套優秀的測試方案和測試方法。測試用例的設置
我們早期的測試用例是按功能設置用例。後來引進了路徑分析法，按路徑設置用例。目前演變為按功能、路徑混合模式設置用例。
按功能測試是最簡捷的，按用例規約遍歷測試每一功能。
對於複雜操作的程序模塊，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在於可以避免漏測試。
今天進步點點，明天前進一大步。知識需要積累。我們切不可心浮氣粗。通過這幾天對測試用例設計方法的學習。我進行了測試用例管理的深思。
1、從功能的角度，功能是每個項目測試的重點，通常在測試人員得到需求文檔的時候，我們就開始設計測試用例，那麼這個時候需求文檔上列出都是功能以及部分一些業務邏輯等，所以在測試用例的第一階段就是完成功能的.用例設計。不過這裏，肯定會讓很多人疑惑，其實功能、業務還有UI，都是有關聯的，而且很多時候無法分解的。這裏後面我會舉個例子説明哈，但絕非都是可以分類，只是談談如何分解的方法，最重要的就是不要遺漏就行。
2、從UI的角度，UI通常是指界面測試，這個應該不難理解，但要想與功能點進行分解，也不是那麼容易區分的，所以我們來直觀的説明哈。界面測試，注重樣式，外觀、整潔、擺放以及易用性，還包括用户體驗等。
3、從業務的角度，這個相對來説，還比較好理解，業務通常是指一連串的動作所連接起來的流程，這個流程必須有行為和目標，或者説方向。業務通常是一個項目或者產品設計的核心，當下，越來越多的應用業務流程都是非常複雜，所以對於業務的用例設計，就是考驗一個測試人員的業務水平如何。
今天是實習的第一天，説實話，其實去的路上心裏一直都在忐忑。有點緊張有點興奮。不知道平常的日常所學所在實踐中能否用得上，也不知道實際的軟件測試上怎樣的情況。
剛到單位時，由於剛認識感覺有點悶悶的.。需求測試部並沒有太多人，設有一個部門主管，兩個需求和一個運維和一個測試，帶我的是負責測試工作的劉姐。剛去報到的時候，主管帶我到各部門做了個簡單的自我介紹，大家都對我這位90後的新同事給予了熱烈的歡迎。從熱烈的掌聲中我感受到了該單位的工作氣氛比我想象的活躍多了。值得一提的是，在隔壁的設計部做自我介紹時，居然撞見了一個老鄉，聊着才知道，我們辦公室還有兩個老鄉。為這年頭遇見老鄉不奇怪，但一下子遇見這麼多還真是難得。當時，我就想在這裏實習一定會很好，很輕鬆的。
介紹完了之後，負責人給我安排了一個座位。由於我之前沒接觸過軟件測試，對軟件測試可以説是一片空白。由於種種原因，劉姐給了我一本軟件測試基礎知識的書，工作第一天我就在座位上看了一整天書。
今天主要是進行系統測試和評估測試。同時整個開發過程中我們小組也協同項目經理對各個方面進行了質量評審。從各個方面對不同的工件進行了評審，其中大部分通過了，不可避免地其中也有一些問題，但是我們採取了相應的糾正措施，保證了各個工件的質量。
學任何東西都應該認真研究，否則一知半解還不如不學；另外要注重把平時所學和實際相聯繫。熟練的'專業技能是一個公司生存和發展的資本。現在主要的任務還是多學習，多積累。
學問齋