說到測試，就要先講一下測試的流程。下面我按照測試的流程，去分析和演示一下測試的方法和過程：

1、需求分析
現(xiàn)在要測試一個登錄界面，驗證頁面上所有功能的可用性，要測試的界面如下：

需求分析：

• 這是一個登錄界面，首先，需要有賬號、密碼輸入框，和登錄按鈕；
• 需要有兩種登錄方式，賬號密碼登錄和掃碼登錄；
• 既可以使用QQ號登錄，也可以用微信登錄，可以手動切換；
• 需要記住密碼功能，第二次登錄時只需選擇已登錄過的賬號，即可自動補全密碼；
• 需要自動登錄功能，雙擊快捷方式后，軟件自動完成登錄進入主程序界面；
• 需要找回密碼功能，可以找回忘記的密碼；
• 需要注冊賬號功能，可以注冊新的QQ賬號；
• 需要設置功能，里面可以設置網絡，可以設置服務器；
• 需要關閉按鈕，可以關掉登錄窗口。

2、編寫用例
測試用例是執(zhí)行測試時的依據，用例是根據需求去編寫的，每個需求可以生成一條或多條用例（因為一個需求可能包含多個操作，每個操作都可能需要進行功能的驗證）?，F(xiàn)在我以【賬號、密碼登錄】為例，演示一下賬號密碼登錄功能測試的用例。

分析賬號、密碼登錄功能，要寫用例，主要分為以下幾種情況：

1. 正確賬號、正確密碼

2. 正確賬號、錯誤密碼

3. 錯誤賬號、正確密碼

4. 錯誤賬號、錯誤密碼

5. 正確賬號、空密碼

6. 空賬號、正確密碼

用例編寫如下：

3、執(zhí)行測試
根據上面用例的描述，執(zhí)行測試操作，并記錄實際結果到用例表格里，對比實際結果和預期結果是否一致，如果不一致，則說明有bug。

如上面的用例執(zhí)行結果所示，大部分用例執(zhí)行的結果都是不通過的，只有第一條和最后一條是通過的，而且綜合分析后發(fā)現(xiàn)，登錄功能只對賬號進行了驗證，對密碼根本沒有校驗，且提示語也有缺失。

這種情況，說明功能開發(fā)的不夠完善，并不符合測試的基本條件，因為用例里面的每條都是最基本功能的驗證，最基本功能都不能通過驗證，是不能進行系統(tǒng)測試的。

我們把驗證最基本功能（主要功能）的測試，叫做冒煙測試。如果冒煙測試不通過，則需要直接打回到開發(fā)那里，由開發(fā)人員進行自測。當開發(fā)人員自測基本功能無誤后，重新提交到測試人員手里進行系統(tǒng)測試，對功能的更多細節(jié)問題進行驗證。

事實上，當我們測試到第二條時，發(fā)現(xiàn)不能驗證密碼準確性的bug，就已經說明未通過冒煙測試了，賬號密碼登錄的測試，最重要的就是驗證賬號和密碼：1、準確性，2、必填性。如果準確性都不能校驗，說明功能開發(fā)未完成（或者開發(fā)不完善），必須重新開發(fā)（或者開發(fā)者進行自測和完善）。

4、跟蹤bug
說通俗點就是時不時查看bug修復的進度，及時督促和跟進開發(fā)人員修復bug，不要拖延修復bug的時間，避免項目延期。好的測試工程師，提交的bug，可以簡單便捷、通俗易懂的將問題描述清楚，同時更好的方便開發(fā)人員定位bug。（下面我所講的都是一般的功能測試，不涉及性能、安全、自動化等更高級的測試）

通常情況下，當我們發(fā)現(xiàn)了bug之后，我們都會通過圖文或者視頻等描述，將bug復現(xiàn)的方式展現(xiàn)給開發(fā)的同事，或者將日志文件也發(fā)給同事，便于開發(fā)快速定位bug。我們以普通功能測試為例：就是將操作步驟、預期結果和實際結果詳細描述一下，告訴開發(fā)，說明問題所在即可。

當我們進行系統(tǒng)測試的時候，由于功能模塊很多，bug的數量也會比較多，如果用QQ/微信聊天的方式說明bug，或者使用文檔記錄bug的方式，并不方便測試人員跟進bug的修復進度，很可能時間久了還會導致一些提交過的bug會忘記修復和復測。因此，為了解決這個問題，市面上大多數IT公司都在使用bug管理系統(tǒng)進行bug提交和跟進。比較常見的bug管理工具有禪道、jira、tapd等等，我比較推薦的還是【禪道】！

禪道首頁

禪道提交bug的界面

使用禪道的方法，屬于另外的內容了，本文就此略過?？傊?，使用bug管理工具，可以隨時查看bug的修復進度，方便開發(fā)修復bug，同時也方便測試復測已修復的bug，可以使工作效率大大提升。

5、交叉測試
當各個模塊都進行了測試以后，就需要進行交叉測試來更好的覆蓋所有功能點，避免漏測等問題的出現(xiàn)。

所謂交叉測試，也就是交換功能測試，原本“A測試甲模塊，B測試乙模塊”，現(xiàn)在改為“A測乙，B測甲”。
我們都知道，一個人的思考，難免存在著疏漏之處，所以才有“三個臭裨將，頂個諸葛亮”之說，進行交叉測試就是為了避免漏測的，多個人測試，就能更好的覆蓋功能測試點。交叉測試其實也可以放在編寫測試用例的階段，也就是【測試用例評審】，這樣的評審，可以提前將測試用例完善，這樣在測試的階段就可以不用交叉測試了。（當然了，很多公司在實際操作時，都沒有按照標準測試流程進行操作，很多時候根本就沒有編寫測試用例和用例評審的過程，這種情況就只能靠開發(fā)工程師自己的能力來保證測試質量了）

通過在多家公司的實際測試經驗，我總結一下當前軟件測試的實際情況和面臨的問題：

1、有些公司的測試流程不完善，有些根本就沒有流程，就是胡亂安排測試的；
2、有些公司的測試是有流程的，但是也不夠重視測試，總是把未經培訓的測試放在軟件測試崗位上；
3、有些公司在招聘測試工程師時，隨波逐流，還沒把功能測試搞好，就急著想招聘自動化測試，舍本逐末；
4、有些公司在招聘測試工程師時，往往忽視工作經驗和能力，更多的是強調學歷和畢業(yè)院校等無關信息；
5、實際工作中，測試工程師常被當做雜工，什么零碎的活都讓測試去做，浪費了測試人員的很多精力；
6、測試過程中，已經測試無誤的功能，過段時間就反復出現(xiàn)相同的問題，會被說成是測試的問題（背鍋）...

我們知道，沒有完美的公司，沒有完美的領導，但是我們有更多的公司和領導，把測試重視起來，開發(fā)生成功能，而測試保證體驗。想讓公司的產品質量更加有保證，就要讓測試和開發(fā)一樣，用更好的狀態(tài)和飽滿的精神去完成測試工作。專業(yè)的人做專業(yè)的事，才能讓結果更加如人所愿！

我是John，一個小小的軟件測試工程師，希望我的文字能幫助更多的人~