一天即將過去了，我們對人和事情也有了新的看法，讓我們今天做個總結，寫一篇日記吧。那麼寫日記需要注意哪些問題呢？下面是小編幫大家整理的軟件測試實習日記，僅供參考，大家一起來看看吧。
如何設計測試用例，如何評審測試用例，最後如何管理測試用例，這都是我們測試工作中必須要去改進的問題。在之前的公司，由於團隊工作任務繁忙，我們沒有太多的時間去管理和優化測試用例，也因此對用例方面少了太多的思考，而且雖然有對於用例的評審，但一直以來，我認爲是做得不夠好的，畢竟每次評審下來，感覺效果沒有預期的那麼好，主要還是沒有足夠的時間去管理，所以無法引起重視。不過，現在我想我需要花大量的時間來管理用例了，而且要保證有序的進行，最後輸出讓團隊中各個成員都認爲滿意而且高效的測試用例。對於用例管理的根本問題，我個人認爲是分類上，如何有效的維護和優化用例，就是需要前期明確的分類規劃，根據分類的優先級一步一步地來完成就可以了，到最後，我們也可以有效把控的測試覆蓋度。
當前，我們大致可以把測試用例分稱三個方面，分別是功能、UI和業務流程，從這三個角度來進行設計。
1、從功能的角度，功能是每個項目測試的重點，通常在測試人員得到需求文檔的時候，我們就開始設計測試用例，那麼這個時候需求文檔上列出都是功能以及部分一些業務邏輯等，所以在測試用例的第一階段就是完成功能的用例設計。不過這裏，肯定會讓很多人疑惑，其實功能、業務還有UI，都是有關聯的，而且很多時候無法分解的。這裏後面我會舉個例子說明哈，但絕非都是可以分類，只是談談如何分解的方法，最重要的就是不要遺漏就行。
2、從UI的角度，UI通常是指界面測試，這個應該不難理解，但要想與功能點進行分解，也不是那麼容易區分的，所以我們來直觀的說明哈。界面測試，注重樣式，外觀、整潔、擺放以及易用性，還包括用戶體驗等。
3、從業務的角度，這個相對來說，還比較好理解，業務通常是指一連串的動作所連接起來的流程，這個流程必須有行爲和目標，或者說方向。業務通常是一個項目或者產品設計的核心，當下，越來越多的應用業務流程都是非常複雜，所以對於業務的用例設計，就是考驗一個測試人員的業務水平如何。
下面通過一個證券交易平臺上的買入和撤單業務，進行具體說明：
業務說明：買入業務包括股票代碼、當前價格、買入價格，買入股票數量、確定買入按鈕和取消按鈕;
撤單業務包括選擇撤單的未成交業務、撤單成功、撤單失敗以及取消撤單按鈕;
以上只是大致列舉了一部分。
功能點：買入按鈕、取消按鈕、選擇撤單、撤單按鈕和取消撤單按鈕等
UI界面測試：股票代碼、當前價格、買入價格、買入股票數量，所有的文本框;買入成功/失敗的提示框;撤單成功/失敗的提示框;撤單成功/失敗的業務狀態等
業務測試：買入業務，從輸入買入表單的數據，到提交表單，到最後買入的表單顯示的位置，以及買入提交但未成交，可以撤單，完成撤單的業務，到撤單成功或者失敗等，這一連串的工作組合就是一個業務流程。
其實這裏就存在一個爭議性的問題，對於買入和撤單，既可以作爲功能點，也可以作爲一個業務邏輯來設計，但從本質上來講，功能點注重單獨的操作，而業務流重的在是一個流程，還需要具體業務去甄別。功能點的設計更主要對這個買入和撤單的按鈕本身進行用例設計;而業務則是需要從買入和撤單之前的輸入到最後輸出這樣一個過程來設計。
以上也只是大概的一個簡單的說明，具體的操作還得根據自己的實際流程來執行，畢竟測試用例的管理是一個長期的積累和沉澱的過程，好的方法都是總結出來的。對於測試來說，用例是基礎，對於迴歸測試、自動化、性能等等都是根本，管理好測試用例，也就是提高測試的工作質量。
今天主要是進行系統測試和評估測試。同時整個開發過程中我們小組也協同項目經理對各個方面進行了質量評審。從各個方面對不同的工件進行了評審，其中大部分通過了，不可避免地其中也有一些問題，但是我們採取了相應的糾正措施，保證了各個工件的質量。
學任何東西都應該認真研究，否則一知半解還不如不學；另外要注重把平時所學和實際相聯繫。熟練的專業技能是一個公司生存和發展的資本。現在主要的任務還是多學習，多積累。
做測試已不知不覺有兩個月了。現在我僅自我總結以下如何做好測試計劃工作。
1.明確測試的目標，增強測試計劃的實用性
編寫軟件測試計劃得重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計劃的價值取決於它對幫助管理測試項目，並且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確
2．堅持“5W”規則，明確內容與過程
“5W”規則指的是“What（做什麼）”、“Why（爲什麼做）”、“When（何時做）”、“Where（在哪裏）”、“How（如何做）”。利用“5W”規則創建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的範圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。
3．採用評審和更新機制，保證測試計劃滿足實際需求
測試計劃寫作完成後，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
4.分別創建測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
這周的工作任務主要是完成旅行網的第一輪測試，由於數據庫的設計不合理還有待遇寫的不夠規範導致我們系統打印不出來，後來把代碼的合理性，還有新版本的功能都做完了的上線了。
1、完成了後臺bug的修改。
2、完了管理學生的條件的查詢。
3、完成了申請打印的條件查詢。
4、票務管理新增加了一個功能代理商可以修改代理商信息。
在完成這幾個任務需要的時間我們很少了，這是由於全段時間我們對我們這個系統做過很多的修改功能，還有自己對宇整個代碼的流程也是越來熟悉，讓我更加有成就感，因爲我不會爲了一個簡單的文件而去浪費時間去學習，還有我們可以自己單獨去很多功能了，我就會覺得我們現在的待遇不行。想到這裏我們就會覺得自己的心裏不平行。
今天主要開始軟件測試模型的學習，通過學習我主要了解到軟件測試有以下幾個模型：
1、V模型
在軟件測試方面，V模型是最廣爲人知的模型，儘管很多富有實際經驗的測試人員還是不太熟悉V模型，或其他的模型。V模型已存在了很長時間，和瀑布開發模型有着一些共同的特性，由此也和瀑布模型一樣地受到了批評和質疑。V模型中的過程從左到右，描述了基本的開發過程和測試行爲。V模型的價值在於它非常明確地標明瞭測試過程行政工作計劃 中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係。侷限性：把測試作爲編碼之後的最後一個活動，需求分析等前期產生的錯誤直到後期的驗收測試才能發現.
項目經過一段時間的測試，終於快要完成了，這個星期主要是迴歸測試。就是把提過BUG的單，經過開發修改過後的系統再進行測試。迴歸全部通過，說明系統的'質量不差。測完並且編寫用戶手冊。 迴歸測試並不減少對系統新功能和特徵的測試需求，迴歸測試包應包括新功能和特徵的測試。如果迴歸測試包不能達到所需的覆蓋要求，必須補充新的測試用例使覆蓋率達到規定的要求。
有成爲一名優秀的軟件工程師必須要有嚴謹的工作態度，能夠勝任反覆性的工作。必須要懂得與人良好的溝通。描述具體問題時，應準確，最後以圖文並茂的方式展示問題。
在組織迴歸測試時需要注意兩點，首先是各測試階段發生的修改一定要在本測試階段內完成迴歸，以免將錯誤遺留到下一測試階段。其次，迴歸測試期間應對該軟件版本凍結，將回歸測試發現的問題集中修改，集中迴歸。
今天一如既往的在研究軟件測試的計劃的編寫，通過今天的學習我主要明白了編寫軟件測試的重要性和目的：
測試計劃是軟件測試中最重要的步驟之一，它在軟件開發的前期對軟件測試做出清晰，完整的計劃，不光對整個測試起到關鍵性的作用，而且對開發人員的開發工作，整個項目的規劃，項目經理的審查都有輔助性作用。
2、測試計劃的目的
測試計劃描述所要完成的測試，包括測試背景、測試目的、風險分析、所需資源、任務安排和進度等：
（1）將需求和總體設計分解成可測試，應該測試，推遲測試和無法測試的範圍
（2）對每個範圍制訂測試的策略和方法
（3）制訂release和停止測試的標準
（4）準備測試所需要的環境
（5）確定測試風險
（6）確定軟件測試目標
（7）確定測試所需要的資源其它相關信息
（8）制訂測試進度和任務安排
近段時間，開發和我們一起做性能測試，涉及一些底層的技術，也準備開年之後寫自動化的腳本，突然間發現，測試也是有意義的，不想我之前想的那麼討厭，自己在生活中做一些事情，也會按照測試的一些思想來做，有時候變得有點挑剔了，呵呵。而且測試在國內還不成熟，人才還很缺，測試也是很有前途的，自己還是喜歡測試這份工作的。而且測試需要我學的東西也很多，邏輯思維和技術含量還是很高的。唉，恍然大悟了。而且工作這麼一段時間，也現實了，在做數據庫和開發我的經驗是有限的，而我那有限的一點經驗在測試方面也是綽綽有餘了，正好爲我的測試提升一步。
以前學計算機的時候對計算機的知識一點也不感興趣，自從學了數據庫之後就對數據庫產生了強烈的興趣，對計算機的一些知識也，慢慢的產生了興趣。我喜歡設計數據庫，我喜歡想各種方法，儘量讓她達到最優的狀態，喜歡寫SQL語句，各種複雜的查詢排序等等都寫過，對事務和索引也研究了一段時間。
這周過得可真夠累。由於公司購物網要在規定實踐發佈，昨天我們主管就通知我們週六加班。我們辦公室的哥哥姐姐很不情願的申請了加班申請。本想可以好好休息一下了，可明天還得下班啊，想想多麼悲催啊！
週六很不情願地從牀上爬起來，一大早跑到公司，加班的公司確實比上班時間安靜多了。比較喜歡安靜的我看都這種情況，工作激情又一次被調動起來了。週六一整天我熱情滿滿的測試各個模塊的添加業務功能。在做測試時，雖然有些頭暈，但還是靜下心來完整了本天的測試工作。覺得特有成就感。從這件事情，我認識到，公司加班有時候是沒辦法的事情。我們做員工的有時候要理解，但當加班過分時，我們做員工的也要勇敢的說NO。員工既要承擔自己的任務又要適當地維護自己的權力。這是我這周的心得。
懷揣着最初的夢想、保持着那份激情和耐心、我繼續着我軟件學習的路程。今天我開始了測試用例設計方法的學習。
測試用例是軟件測試的核心
軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。每個軟件產品或軟件開發項目都需要有一套優秀的測試方案和測試方法。測試用例的設置
我們早期的測試用例是按功能設置用例。後來引進了路徑分析法，按路徑設置用例。目前演變爲按功能、路徑混合模式設置用例。
按功能測試是最簡捷的，按用例規約遍歷測試每一功能。
對於複雜操作的程序模塊，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在於可以避免漏測試。
今天任務是瞭解H模型，H模型中，軟件測試過程活動完全獨立，貫穿於整個產品的週期與其他流程併發的進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執行階段。軟件測試可以儘早的進行，並且可以根據被測物的不同而分層次進行。
H模型揭示了一個原理:軟件測試是一個獨立的流程,貫穿產品整個生命週期,與其他流程併發地進行。H模型指出軟件測試要儘早準備,儘早執行。不同的測試活動可以是按照某個次序先後進行的,但也可能是反覆的,只要某個測試達到準備就緒點,測試執行活動就可以開展
瞭解了各種測試用例的方法，之後又在實際項目中設計了一些測試用例，總體感覺就是：公司裏分配寫作測試用例的時間並不長，而且提供的文檔也不全面，所以寫測試用例要符合測試部門的當前現狀和項目的測試特點，綜合考慮，所以看起來有點像測試計劃的某些內容，但是對問題的細化程度不一樣。
測試用例的設計是一項複雜的測試工作，測試用例的設計方法需要考慮測試的目標，被測試軟件的特性，測試者人力資源的技術和能力，測試組織形式，測試進度、測試成本等多個方面。
確定測試用例的輸入數據確實對於測試用例非常重要，它決定着測試用例的執行效果和效率，但是確定輸入測試數據只是設計測試用例的一個步驟，而不是全部。因此，不能把測試用例的設計方法等同於測試用例數據的方法。
早上從寢室出發就暗示自己要踏踏實實的學習忌浮躁。早上我早早的到公司，開始我的學習，今天我學習的主要內容是測試用例設計方法之劃分等價類法。
①如果某個輸入條件規定了取值範圍或值的個數。則可確定一個合理的等價類(輸入值或數在此範圍內)和兩個不合理等價類(輸入值或個數小於這個範圍的最小值或大於這個範圍的最大值)。
②如果規定了輸入數據的一組值，而且程序對不同的輸入值做不同的處理，則每個允許輸入值是一個合理等價類，此處還有一個不合理等價類(任何一個不允許的輸入值)。
③如果規定了輸入數據必須遵循的規則，可確定一個合理等價類(符合規則)和若干個不合理等價類(從各種不同角度違反規則)。
④如果已劃分的等價類中各元素在程序中的處理方式不同，則應將此等價類進一步劃分爲更小的等價類。
現在對測試工作有了全新的認識，測試能力是要不斷提高的；可擴展性：具備可以進行測試工作的基本功能，在功能和性能上還需完善和補充，好在可擴展性好，還有優化的餘地。測試工作在很大程度上改變了我的思維方向，幾個月前的我對任何事物都幾乎是在沒有任何依據的情況下，盲目的樂觀自信，而現在面對事物時我習慣性的以懷疑的角度切入，正因爲懷疑，就會對事物追根刨底，對自己和自己所要處理的事物具備更強烈的責任心。所以作爲一個測試人來說懷疑是出發點，體現在測試人身上的品質就是責任心。旁觀測試組中一個個兢兢業業工作着的同事們，想到原來生病的不只我，他們病得更重，我不禁啞然失笑，一下子覺得自己病得理直氣壯了，也堅定了自己將測試工作進行到底的決心。
今天是實習的第一天，說實話，其實去的路上心裏一直都在忐忑。有點緊張有點興奮。不知道平常的日常所學所在實踐中能否用得上，也不知道實際的軟件測試上怎樣的情況。
剛到單位時，由於剛認識感覺有點悶悶的。需求測試部並沒有太多人，設有一個部門主管，兩個需求和一個運維和一個測試，帶我的是負責測試工作的劉姐。剛去報到的時候，主管帶我到各部門做了個簡單的自我介紹，大家都對我這位90後的新同事給予了熱烈的歡迎。從熱烈的掌聲中我感受到了該單位的工作氣氛比我想象的活躍多了。值得一提的是，在隔壁的設計部做自我介紹時，居然撞見了一個老鄉，聊着才知道，我們辦公室還有兩個老鄉。爲這年頭遇見老鄉不奇怪，但一下子遇見這麼多還真是難得。當時，我就想在這裏實習一定會很好，很輕鬆的。
介紹完了之後，負責人給我安排了一個座位。由於我之前沒接觸過軟件測試，對軟件測試可以說是一片空白。由於種種原因，劉姐給了我一本軟件測試基礎知識的書，工作第一天我就在座位上看了一整天書。
