更新時間：2023-10-29 15:09:01作者：佚名
沒想到，第一次寫博客是寫測試。
實習測試，也算預料之外中的驚喜吧，我的一開始看法是后端來著，后來認為測試也OK，總之也算我的方向吧。所以也投了測試相關職位，沒想到一次成功，還是比較不錯的公司，謝謝我轉的好運微博，O(∩_∩)O哈哈~其實前天下午也惡補了相關知識。
屁話不多，以下，是近來一個月接觸到的測試相關知識，像這些知識性的網上一大把，我也不細說了，這個都要實際去接觸就會有感悟：
測試流程：
1.需求評審：相關人員對軟件需求文檔進行評審，內容是否健全，是否有描述不清楚或矛盾的地方
2.需求剖析：需求剖析這一過程是主要確定系統必須完成什么工作，對目標系統提出完整、準確、清晰具體的要求。
3.測試計劃：依照需求計算測試所需資源（人力，設備等）、所需時間、功能點界定、如何合理分配安排資源
4.用例設計：測試用例是指導你執行測試，幫助證明軟件功能或發覺軟件缺陷的一種說明。用例設計好以后，會進行評審。
5.測試環境：軟件+硬件+網路+數據打算+測試工具
6.執行測試：開發人員遞交第一個版本，假如存在未完成的功能，開發需跟測試人員說明，之后測試人員依照測試用例的詳盡步驟，執行測試用例，發覺BUG遞交缺陷庫。
7.BUG跟蹤：開發人員遞交第二個版本，包括更改的BUG以及降低的部份功能，測試人員進行第二輪測試和回歸測試，跟蹤BUG直至關掉。重復前面的工作，通常情況下3-4個版本后BUG數目減小。
8.測試報告：測試報告是指把測試的過程和結果寫成文檔，對發覺的問題和缺陷進行剖析，為糾正軟件的存在的質量問題提供根據，同時為軟件初驗和交付打下基礎。
測試方式：從不同角度，有不同的分類
1.從是否關心軟件內部結構和具體實現的角度界定
白盒測試、黑盒測試、灰盒測試
2.從是否執行代碼角度
靜態測試、動態測試
3.從軟件開發的過程按階段界定有
單元測試、集成測試、確認測試、系統測試、驗收測試、回歸測試
ＢＵＧ的遞交：
雖然怎樣判定是否是一個優秀的bug，最重要的一個標準：開發不用尋問測試就曉得如何再現這個bug，或則才能理解這個bug，而不是看不懂這個bug。對于我來說，目前做的不夠好，應當再細致一點，萬無一失。
一個bug單包含什么要素：
1、所屬的系統
2、發現的版本
3、發現bug所屬的模塊
4、bug遞交人
5、bug的錯誤類型：代碼錯誤、界面優化、設計缺陷、配置相關、安裝布署、安全相關、性能問題等
6、bug的再現機率：必現大幾率再現小幾率再現極小幾率再現
7、bug的嚴重級別：致命嚴重通常提示
8、bug的優先級：高中低
9、bug的標題言簡意賅說明是哪些bug，而不是把測試用例名子復制一遍
10、bug單號通常系統手動生成
11、bug內容：發覺的環境、預制條件、重現步驟、預期結果、實際結果，截圖證明，bug錯誤說明，
12：附件：測試用的數據或則出錯的日志，假如須要添加上日志
遞交bug的時侯盡量把截圖附上，并對截圖進行標明，操作過程說明清楚，雖然字不如圖，描述半天不如一張圖。
數據標明：
近來做得最多的是數據標明，判定情感分類；聽上去挺簡單的，雖然平常瞧瞧評論也能反映出這是好評，中評還是差評。而且對于此次大量的數據標明，顯著有點“復雜”，由于在判定早期我們有個理念，所以會秉持界定掉其他平常中我們認為是一類的數據，逐漸團隊也會總結各類情況，就類似閱讀理解了，挺有意思的。。。
一個月以來的心得：
*對于目前我們測試，都是功能測試，點點點，雖然挺有趣的，有些bug靠自己的看法找到也不失為優美的藝術。
*對于寫測試用例，明白需求是十分重要的，這樣才能寫出比較健全有效的用例。并且實際操作中也會發覺好多須要測試的點，所以要不斷改善，就能發覺更多的bug。并且有時侯需求是在不斷變化的，一定要更上進度。
*近來主要遞交bug軟件測試學校，對于找bug，一定要把自己當作用戶，一定要存疑，一定要有要把項目做到最完美的信念。早期，我對于需求也只是通過用例，相關圖資料有個大致了解。并且在找bug中也會有好多細小的不同。例如有些功能有，然而不夠好；例如有些地方沒有提及的功能，加上是否更好？還有一些bug，更改了，而且療效不大或則目前情況看不出療效等等，這種作為初入測試的我，我曉得不能沖動行事，雖然對于業務我了解的不深，或則對于個別功能的實現以及項目的完成度不了解，造成有些bug是目前沒必要的，反倒還可能浪費開發人員的寶貴時間，所以交流就很重要，跟項目總監確定需求，跟開發人員確定數據，頁面相關問題，做到心里有數，才能做事不盲目。在了解情況之下，提bug看著不對就提（一個開死黨爺爺對我說的）。其實提bug也可以提一些建議，雖然本意都是為了項目更好。還有提bug你可以簡單剖析一下誘因，為何你認為這兒會有問題軟件測試學校，是自己理解錯誤，誤認成bug，還是開發錯誤，想清楚了，提bug的時侯就順便交待清楚，可以給開發人員提供思路。
雖然越了解測試，越發覺是個寶庫，由于測試涉及的知識太廣了，你須要向一個寶庫一樣，能夠走得更遠。