無論我們試圖建立乙個多麼完美的**，我們都一定會犯一些錯誤，錯誤是不可避免的。
我們很難保證沒有錯誤的發布。即便我們進行了不同型別的全面測試（例如壓力測試，跨瀏覽器測試，響應測試等），即便我們也考慮了流程中涉及的各種型別的測試，上線後，依然可能會發現問題。
出了問題，就要解決問題，不管是測試過程中發現的還是上線以後使用者反饋的。但在解決問題的過程中，測試人員需要起到積極的推動作用。當然理想很豐滿現實很骨感，有的人總是能找到各種各樣的理由逃避問題和責任。
下面分享一些測試人員經常遇到過或者使用過的各種藉口，有些我自己也用過。
chrome 上沒問題，其他瀏覽器上應該也沒問題因此，當你測試了乙個**，遇到了一些錯誤，然後將其**給開發團隊。他們修復了該問題，並將其**給您或您的測試團隊以供驗證。您仔細地對整個**進行回歸測試，以檢查更改是否影響了任何現有功能。一切都很好，您進行了確認，因為從系統（而不是瀏覽器）測試**時，您沒有發現任何錯誤。
可一旦更改生效並投入生產，客戶使用與您不同的瀏覽器，便開始抱怨 ui 和跨瀏覽器相容性問題。
有些測試人員有這樣一種心理：「如果該軟體在 chrome 上能正常執行，那在其他瀏覽器上應該也沒問題。」請記住，就像人類對所有事物的理解不同一樣，瀏覽器也是如此。**與乙個瀏覽器相容，不代表所有瀏覽器都會以相同的方式解釋**。測試人員需要確保自己的**在所有瀏覽器上都提供一致的體驗和行為，不能忽視跨瀏覽器測試。
專注於預定的測試用例場景
測試人員最常見的藉口之一：他們的工作只是遵循分配給他們的預定義測試用例。
但是，測試人員必須超越專注於預定義的測試用例場景。
如果執行預定義的測試用例是任何組織唯一關心的問題，那麼採用自動化測試會更好。自動化測試和手動測試應該齊頭並進。因此，預定義的測試用例最終實現了自動化，測試人員將有更多的時間提出更好的測試方案。
開箱即用的思考是測試工作的一部分，必須分析當前專案的開發計畫的風險，並強調探索性測試。
部署構建和除錯問題不是我的工作
已經批准了整個發行版。現在，您要做的就是等到 devops 投入生產。但是，真的必須等待嗎？
如果您認為部署構建是開發人員的頭疼問題，估計要多問問自己幾遍了！您是否有能力利用可用資源來採取富有成效的行動？如果是，為什麼每次都依賴開發人員？您需要做的就是觸發構建並部署適當的措施，沒有理由等待。畢竟，您具有使您的工作更輕鬆的許可權和能力。為什麼不能自己做？
部署是員工面臨最多失敗次數的情況之一。但是，您知道此類失敗的最大好處嗎？他們會提示您再次除錯並學習新知識。如果有什麼鼓勵您提出問題或瀏覽器搜尋，那將始終是您的最佳選擇。
沒有足夠的時間進行測試
沒有足夠的時間是世界上幾乎所有事物的最普遍藉口！
在某人無法完成某件事的那一刻，他們在這裡為自己的失敗指責。測試人員，讓我們面對現實吧。要測試的因素太多了，您將永遠沒有足夠的時間來完成這一切。沒有足夠的時間測試，這並不意味著最終會因此導致時間管理失敗。實行有效的時間管理並確定測試程式的優先順序至關重要。
我沒有測試 ie，因為它已經過時了
internet explorer 是乙個相容性解決方案。我們不支援新的 web 標準，儘管許多站點執行良好，但如今開發人員基本上很少在 internet explorer 進行除錯。如果考慮到測試 internet explorer 瀏覽器相容性測試的時間，很增加很多不必要的工作量。
不！如果考慮到當前使用者的屬性和潛在使用者的屬性，internet explorer 相容性測試時必要的。
昨天測試了該功能，不需要再次測試了
如果您認為在報告 bug 後就完成了工作，那是錯誤的。您可能會說您已經執行了詳細的測試，並將錯誤傳達給了開發人員。但是作為測試人員，您必須意識到報告錯誤有時會導致**更改。有時，更改可能會影響以前的功能。
回歸測試是所有 sdlc 的最基本方面。無論花費多長時間或重複多少，其重要性都保持不變。作為一名測試人員，我了解通宵的工作以便發布及時的修補程式，短促的發布視窗會造成很大的損失。有時候，我們在回歸測試上懈怠。
因此，重要的是要檢查修改後產品是否工作良好。必須做好執行頻繁檢查的準備，並確保沒有剩餘的回歸缺陷。
我認為無法測試此功能
這是到目前為止我遇到的最荒謬的藉口之一。
令人驚訝的是，有許多測試人員使用它來逃避他們不了解的功能的測試。
考慮一下，您測試環境中的每個功能都已經由開發團隊進行了測試（或者除錯）。如果開發人員知道某個特定功能正在執行，並且能夠在沙盒環境中對其進行測試，那麼就必須有一種方法來對其進行測試！
可能是，您可能無權訪問某些功能中使用的系統。在這種情況下，您需要與開發人員合作，並要求他們向您展示該功能的工作原理以及如何對其進行測試？然後，嘗試不同的測試用例並盡可能發現 bug。
指責開發人員的**
責備他人是逃避不愉快狀況的最簡單方法。
軟體行業中的一些測試人員趨向於將開發人員承擔所有令人討厭的責任。畢竟，如果錯誤出在開發人員的工作上，沒有人會責怪測試人員！當您指責開發人員的問題時，那麼他很有可能會選擇回擊。
但是這種盲目推卸責任的方法是完全錯誤的，不僅對團隊有害，對自己也有害，會讓以後的合作更加困難，會讓組織在平息憤怒和理清責任上的時間大大增加，從而延長發布週期。
使用者不了解程式
因此，現在甩鍋的迴圈已經從開發人員轉移到了使用者！
在任何情況下都不要忘記進行可用性測試。企業的所有努力都取決於使用者體驗。在可用性測試期間，請不帶任何偏見地從小白使用者的角度進行測試。
在測試環境上執行 ok
這是乙個藉口，對測試人員而言只是合乎邏輯的，而對其他人則沒有。
似乎在測試階段執行良好的應用程式不一定可以在生產中完美執行。原因可能有多種，在**上進行測試時，經常無法獲得**進行生產的實時流量和所有情況。
作為測試人員，應該在從測試環境提供批准之前徹底了解生產環境以及兩者的差異。
總結一下
測試人員在軟體開發生命週期中扮演著極其重要角色。為了生意興隆，必須為客戶提供滿足需求又擁有良好體驗的產品。為了確保這一點，測試人員需要測試產品並從終端使用者的角度對其進行分析。發現 bug 後，他們需要將相關資訊傳達給開發團隊。然後致力於消除缺點並部署各種糾正措施。
測試人員需要意識到，他們需要擺脫藉口的習慣。這將有助於他們的職業發展，並促進公司的發展。相應地進行分析和測試會帶來更好的產品和出色的客戶體驗。
軟體測試人員常用Linux指令（一）
一 系統資訊 1 顯示系統日期 date 2 顯示日曆資訊 cal 二 關機 重啟 1 關閉正在執行的linux作業系統 halt 2 重啟 reboot 三 檔案和目錄 1 切換目的 cd 1 進入home目錄 cd home 2 如果當前路徑是home目錄，想切換到home目錄的上一層根目錄 c...
測試人員git常用命令
git init 用 git init 在目錄中建立新的 git 倉庫。你可以在任何時候 任何目錄中這麼做，完全是本地化的，在本地生成.git檔案 可以直接在git bash here敲linux操作命令，檢視截圖，顯示的當前路徑下檔案 使用 git clone 拷貝乙個 git 倉庫到本地，讓自己...
測試人員要求
素質要求 對測試感興趣 興趣是最好的老師，當別人都找不到bug時，他還能找到 當別人都對重複的回歸測試感到厭倦的時候，他還是抱著探索的精神繼續測試。好奇心 對軟體的功能好奇，對軟體所能做的事情好奇，對使用這個軟體的使用者好奇，對軟體在介面背後悄悄做的事情好奇，在測試過程中能不斷產生新的想法，不斷的發...