測試人員常用借口

• 2019 年 12 月 21 日
• 筆記

無論我們試圖建立一個網站多麼完美，我們都一定會犯一些錯誤。錯誤是不可避免的，無論多麼微小。這就是為什麼我們不能保證沒有錯誤的發布，甚至在進行了不同類型的全面測試之後，例如壓力測試，跨瀏覽器測試，響應測試等。在投入生產環境之前，請考慮流程中涉及的各種類型的測試。依然可能在上線的版本中發現問題。

出了問題，就要解決問題，不管是測試過程中發現的還是上線以後用戶回饋的。但在解決問題的過程中，測試人員需要起到積極的推動作用。當然理想很豐滿現實很骨感，有的人總是能找到各種各樣的理由逃避問題和責任。

下面分享一些測試人員經常遇到過或者使用過的各種介面，有些我自己也用過。

Chrome上沒問題，其他瀏覽器上應該也沒問題

因此，當你測試了一個網站，遇到了一些錯誤，然後將其轉發給開發團隊。他們修復了該問題，並將其轉發給您或您的測試團隊以供驗證。您仔細地對整個網站進行回歸測試，以檢查更改是否影響了任何現有功能。一切都很好，您進行了確認，因為從系統（而不是瀏覽器）測試網站時，您沒有發現任何錯誤。一旦更改生效並投入生產，客戶使用與您不同的瀏覽器便開始抱怨UI和跨瀏覽器兼容性問題。

如果該軟體在Google Chrome或任何其他瀏覽器上都能正常運行。但是請記住，就像人類對所有事物的理解不同一樣，瀏覽器也是如此。如果程式碼與一個瀏覽器兼容，則不必所有瀏覽器都以相同的方式解釋程式碼。測試人員需要確保自己的網站在所有瀏覽器上都提供一致的體驗和行為，不能忽視跨瀏覽器測試。

專註於預定的測試用例場景

測試人員最常見的借口之一：他們的工作只是遵循分配給他們的預定義測試用例。但是，測試人員必須超越專註於預定義的測試用例場景。如果執行預定義的測試用例是任何組織唯一關心的問題，那麼採用自動化測試會更好。自動化測試和手動測試應該齊頭並進。因此，預定義的測試用例最終實現了自動化，測試人員將有更多的時間提出更好的測試方案。開箱即用的思考是測試工作的一部分，必須分析當前項目的開發計劃的風險，並強調探索性測試。

部署構建和調試問題不是我的工作

已經批准了整個發行版。現在，您要做的就是等到DevOps投入生產。但是，真的必須等待嗎？如果您認為部署構建是開發人員的頭疼問題，估計要多問問自己幾遍了！您是否有能力利用可用資源來採取富有成效的行動？如果是，為什麼每次都依賴開發人員？您需要做的就是觸發構建並部署適當的措施，沒有理由等待。畢竟，您具有使您的工作更輕鬆的許可權和能力。你為什麼不能自己做？

部署是員工面臨最多失敗次數的情況之一。但是，您知道此類失敗的最大好處嗎？他們會提示您再次調試並學習新知識。如果有什麼鼓勵您提出問題或瀏覽器搜索，那將始終是您的最佳選擇。

沒有足夠的時間進行測試

沒有足夠的時間是世界上幾乎所有事物的最普遍借口！在某人無法完成某件事的那一刻，他們在這裡為自己的失敗指責。測試人員，讓我們面對現實吧。要測試的因素太多了，您將永遠沒有足夠的時間來完成這一切。沒有足夠的時間測試，這並不意味著最終會因此導致時間管理失敗。實行有效的時間管理並確定測試程式的優先順序至關重要。

我沒有測試IE，因為它已經過時了

Internet Explorer是一個兼容性解決方案。我們不支援新的Web標準，儘管許多站點運行良好，但如今開發人員基本上很少在Internet Explorer進行調試。如果考慮到測試Internet explorer瀏覽器兼容性測試的時間，很增加很多不必要的工作量。

不！如果考慮到當前用戶的屬性和潛在用戶的屬性，Internet explorer兼容性測試時必要的。

昨天測試了該功能，不需要再次測試了

如果您認為在報告BUG後就完成了工作，那是錯誤的。您可能會說您已經執行了詳細的測試，並將錯誤傳達給了開發人員。但是作為測試人員，您必須意識到報告錯誤有時會導致程式碼更改。有時，更改可能會影響以前的功能。

回歸測試是所有SDLC的最基本方面。無論花費多長時間或重複多少，其重要性都保持不變。作為一名測試人員，我了解通宵的工作以便發布及時的修補程式，短促的發布窗口會造成很大的損失。有時候，我們在回歸測試上懈怠。

因此，重要的是要檢查修改後產品是否工作良好。必須做好執行頻繁檢查的準備，並確保沒有剩餘的回歸缺陷。

我認為無法測試此功能

這是到目前為止我遇到的最荒謬的借口之一。令人驚訝的是，有許多測試人員使用它來逃避他們不了解的功能的測試。考慮一下，您測試環境中的每個功能都已經由開發團隊進行了測試（或者調試）。如果開發人員知道某個特定功能正在運行，並且能夠在沙盒環境中對其進行測試，那麼就必須有一種方法來對其進行測試！

可能是，您可能無權訪問某些功能中使用的系統。在這種情況下，您需要與開發人員合作，並要求他們向您展示該功能的工作原理以及如何對其進行測試？然後，嘗試不同的測試用例並儘可能發現BUG。

指責開發人員的程式碼

責備他人是逃避不愉快狀況的最簡單方法。軟體行業中的一些測試人員趨向於將開發人員承擔所有令人討厭的責任。畢竟，如果錯誤出在開發人員的工作上，沒有人會責怪測試人員！當您指責開發人員的問題時，那麼他很有可能會選擇回擊。

但是這種盲目推卸責任的方法是完全錯誤的，不僅對團隊有害，對自己也有害，會讓以後的合作更加困難，會讓組織在平息憤怒和理清責任上的時間大大增加從而延長發布周期。

用戶不了解程式

因此，現在甩鍋的循環已經從開發人員轉移到了用戶！

在任何情況下都不要忘記進行可用性測試。企業的所有努力都取決於用戶體驗。在可用性測試期間，請不帶任何偏見地從小白用戶的角度進行測試。

在測試環境上運行ok

這是一個借口，對測試人員而言只是合乎邏輯的，而對其他人則沒有。似乎在測試階段運行良好的應用程式不一定可以在生產中完美運行。原因可能有多種，在網站上進行測試時，經常無法獲得網站進行生產的實時流量和所有情況。

作為測試人員，應該在從測試環境提供批准之前徹底了解生產環境以及兩者的差異。

總結一下

測試人員在軟體開發生命周期中扮演著極其重要角色。為了生意興隆，必須為客戶提供滿足需求又擁有良好體驗的產品。為了確保這一點，測試人員需要測試產品並從最終用戶的角度對其進行分析。發現BUG後，他們需要將相關資訊傳達給開發團隊。然後致力於消除缺點並部署各種糾正措施。測試人員需要意識到，他們需要擺脫借口的習慣。這將有助於他們的職業發展，並促進公司的發展。相應地進行分析和測試會帶來更好的產品和出色的客戶體驗。

• 鄭重聲明：文章禁止第三方（騰訊雲除外）轉載、發表，事情原委測試窩，首頁抄我七篇原創還拉黑，你們的良心不會痛嗎