測試的目的是保障質量，質量是效率的前提（非常重要）
從發展的角度看公司對質量和效率的重視程度
公司在初創階段更注重效率：
公司在發展階段會越來越重視質量：
公司在成熟階段會以質量為核心：
問題：對質量要求太高會束縛公司的手腳，拖累公司發展的腳步，怎麼破？
這是必然！類似法律與自由的關係，法律必然束縛自由，真正的自由是在法律允許的範圍內無限自由
學習海爾：搞內部孵化，鼓勵員工創業
我的一些認識和總結：
如果我們因為專案經理說要趕工期，就放鬆對質量的控制，那是我們的失責。
那麼質量團隊不需要關注效率？不是的，專案管理的知識告訴我們，要考核質量團隊的內部的測試效率，而不是以研發的整體效率考核質量團隊。
這句話怎麼理解呢？研發整體效率包括專案管理效率，開發效率，測試效率，運維效率等，測試效率是其中一部分。比如乙個專案估時開發要10天，測試要5天，整體15天後上線。那麼我們該如何考核測試的效率？是不是15天後如果不能按時上線，測試團隊的績效也要扣分？如果答案是yes，那麼完了，我們可以認為專案經理已經在某種程度上放棄質量了，雖然他沒有這麼說，但是因為績效考核的原因，當面臨延期風險的時候，質量會為效率讓步。正確的答案應該是no，不能用15天後能否順利上線來考核質量團隊的效率，而是要用5天來考核質量團隊的測試效率。同樣我們不能用15天來考核開發，15天是用來考核專案經理的，10天才是開發的（當然這個專案估時模型比較簡單，實際的情況要更複雜些，如bug修復和多輪測試的情況）。道理說出來大家都懂，但在實際工作中，我們經常會遇到提測延期了，專案經理來催促質量團隊盡快完成測試的情況，美期名曰為了保證專案上線，辛苦一下（說不好聽點就是專案經理為了完成自己的考核指標，來壓榨測試的工期）。如果測試答應了，但結果卻沒能按期完成測試，有些專案經理就會把延期原因算到測試頭上，質量團隊兢兢業業的對質量負責，甘願為趕工期而加班，說不定還會落下乙個測試效率不行的話柄。
這裡面還有乙個比較tricky的情況：測試通過的標準是不再有新的嚴重程度超標的bug產生，即保證提測後不再有bug方可放行。但是情況一，如果你真的在提測後的5天時間裡乙個bug也沒有發現，同樣會引來質疑，乙個bug都沒有，怎麼還需要測試5天時間？情況二，如果你在第4天發現了乙個嚴重的bug，然後開發在第5天下班前修復完成並提交了，ok，開發在上線前完成了任務，請問測試能夠在上線前完成測試嗎？如果你說不能，那5天的測試時間是由你自己來估的啊？自己當初許下的承諾，肯定要自己來擔啊！如果是你，你會怎麼做？如果沒有其它的理由，那麼可以預見的結果就是加班，更糟糕的情況是，即使加班也不見得能夠按時完成回歸測試。通常的做法就是縮小回歸測試範圍，只回歸核心測試用例（有時候我們嘴上不會說，但實際上測試用例還是被刪減了，實際不可能也不會每修復乙個bug就做一次全回歸），而縮小回歸測試範圍有可能帶來的影響就是覆蓋度不夠，進而不能有效的保證質量。當然，實際情況需要我們必須做出取捨，我不會堅持說全回歸一定是必要的。但是做為測試人員，為了達到保證質量的目的，並且還盡可能不加班的話，就需要說服專案經理延期。這很難，專案經理最不喜歡延期了。然後更難的是，如果專案不得不延期了，如何證明理由不是因為測試效率低下？
我們需要有充足的理由和應對的策略（注意，我們這麼做並不是為了應付專案經理，而是為了專案質量）。這裡我借鑑一下在微軟做外包的經驗，說一下零bug狀態的策略（注：這裡的零bug狀態，並不是說真的乙個bug也沒有了，而是說在某乙個時間點，不再出現影響產品上線的bug）即：規定專案在某乙個時間點達到零bug狀態，只有在這個狀態達到了，才允許上線。如果在規定的時間內沒有達到零bug狀態，就需要延期，延期的時間=bug修復+一輪回歸測試時間，如果在下乙個時間點仍然沒有達到零bug狀態，就需要再次延期，如此迴圈，直到達到上線標準。（嗯，肯定有同學在想，我們小公司，那裡能和微軟比，客戶需求緊急，經不起這麼反覆延期的）這裡所強調的延期的理由是產品質量未到上線標準，並沒有特指到底是開發還是測試的原因導致了專案延期。這裡的角度是，專案管理者首先關注的是質量，而不是追責。在遇到問題影響到專案上線時，首先要判斷的是專案能不能以原現預期的質量上線，而不是先問為什麼你不能按期完成測試之類的問題。關於小公司不能接受反覆延期問題，很簡單，那就放鬆上線標準嗎，我又沒有說小公司必須都得達到微軟那樣嚴苛的上線質量要求。但是專案經理肯定不會同意這麼說的，在他們那裡，即要按期上線，又要保證質量。哈哈，這就是有意思的地方，明明知道幾個小時的加班不可能完全一輪全回歸測試，大家都不說，其實不就是默許放鬆了上線標準嗎？
這裡有乙個前提，開發應該為自己寫的**負責，無論在任何時候出現影響產品上線的bug（需求和產品設計的缺陷除外），都不應該由測試來背鍋。很多同學不明白為什麼我要在這裡強調這一點，開發也會說，我們寫出來的bug，肯定不會讓你們測試來背鍋啊。然而實際的情況是這種測試與開發相愛相殺的場景還在不斷上演，舉個例子，比如在第4天發現的嚴重bug，是開發的鍋還是測試的鍋？開發說，為什麼不是在第一輪回歸測試就發現了？而是要等到第4天？如果是第一天就發現了，我肯定能及時修復啊。測試會說，第一輪測試是ok的，在第三輪回歸時才發現，有可能是你們在修復其它bug時導致的，所以我們沒法保證第一輪就發現所有的問題。
我還真遇到過這種情況，測試在上線前一天發現了乙個bug，如果要修復這個bug再回歸，趕在第二天上線肯定來不及了，專案經理竟然質問為什麼測試不能早發現這個bug，到了最後一天才發現而影響工期？我簡直無語，如果開發在修復這個bug時又引入了其他的bug，在回歸時又被測試發現了，難道又是測試的責任？按照這樣的思路，測試在臨近上線時就不能再發現bug了，為了保證上線時間，為了維護測試的清譽，測試即使發現了bug也要往肚子裡咽。這件事情對於測試團隊絕對是乙個負向引導，在這樣的獎懲機制下，為了保上線時間，測試大部分情況下會做出妥協，簡單的回歸下部分主要測試用例，就放行了（不要製造麻煩，小問題不要上報）。這也是我所見到的小公司內普通存在的情況，這裡忍不住一聲嘆息。如果上線後不出問題還好，如果出了問題呢？測試能甩鍋嗎？甩給誰？
這裡我想表達的是，測試人員對待自己的工作要有底線，對自己測試過的產品要負責，不能因為保工期而放棄自己的底線，如果確實心裡沒底，不敢保證上線後不出問題，那麼就要爭一爭，而且要爭的有理有據，我們不是為自保而爭，而是為了產品質量而爭，大道理一定要講明白。因為無論你爭與不爭，線上出了問題總是有你的責任，為什麼不爭一下呢？
最後重審：質量是效率的前提，沒有質量的效率永遠等於0
自動化測試的目的是什麼？自動化測試能提高產品質量麼？
自動化測試的目的提高測試效率，並不直接提高產品質量。測試效率提高之後，節省出來的時間可供我們做更多的測試，而更多的測試這部分，可以提高產品質量。所以說自動化測試是間接的保障質量
總結一下，手工測試和自動化測試的重點：
手工測試：保障質量
自動化測試：提高效率
自動化不能取代人工，自動化也不會超越人，能夠自動化的東西，肯定是人的思維能夠達到的地方
提高效率=節省人力=投入更多的人力來保障質量
附：hp（惠普）大中華區總裁孫振耀退休感言
自動化測試思考 2關注質量
如何讓花了很多人力精力的自動化測試體現出應有的價值？當專案越大，自動化測試內容就變得更龐大，易維護也成為問題，總的來說，基礎性工作要做好，基本來說我個人認為要做好如下 1 讓自動化測試系統穩定 環境要穩定 用例取樣要穩定 比如某些url受網路或者http伺服器的影響等，為了減少這種影響常規目的的因素...
介面自動化測試之前，這些基礎是你需要掌握的
什麼是介面測試 測試人員通常所說的 介面測試 是針對系統各元件之間介面的一種測試，它屬於功能測試。介面能測出普通介面操作難以發現的問題。如，我們都知道系統是由前端後端組成，一些資料在前端做了校驗，後端同樣也需要校驗才能保證安全，介面操作顯然只能檢查到前端校驗這一層，只有直接面對前後端之間的該介面才能...
介面自動化和頁面自動化的測試比較
剛剛接觸了介面自動化測試,結合著頁面自動化測試的經驗，其實不管何種測試的用例，無非都是三大步 介面自動化和自動化測試其實都是乙個黑盒測試，只不過介面測試拋開了表示層，把業務層作為乙個黑盒子來測試，還不同於開發的單元測試，而頁面自動化是把表示層也包括進來了。介面測試更接近業務邏輯的處理，頁面自動化測試...