讀書筆記（google）：
1、質量不等于測試。到開發(fā)和測試不能區(qū)分彼此，就得到了質量，質量更像是一種預防行為而不是檢測。
2、質量是效率的一部分。
3、產品發(fā)布：金絲雀版本（每天一版）——>開發(fā)版本（每周一版）——>測試版本（一月一版）——>beta或發(fā)布版本（對外發(fā)布第一版，已經過所有質量考核的一個版本）
4、測試類型為：小型測試（自動化）、中型測試（自動化）、大型測試（自動化+手動測試），能自動化就不手工測試。
5、mock測試是對于某些不容易構造或者不容易獲取的對象，用一個虛擬的對象來創(chuàng)建以便測試的測試方法。
fake測試是有實際可工作的實現，但是通常有一些缺點導致不適合用于產品(基于內存的數據庫就是一個好例子)。
6、在產品初級階段強調測試是非常愚蠢的行為。
7、TE在進入產品時，需要考慮的問題：
當前軟件的薄弱點在哪里？
有沒有安全、隱私、性能、可靠性、可用性、兼容性、全球化和其他方面的問題？
主要用戶場景是否功能正常？對于不同語言環(huán)境的用戶都這樣嗎？
這個產品能與其他產品互操作嗎？
當問題發(fā)生時，是否容易診斷問題所在？
8、TE這個角色，需要敏銳的洞察力和領導力，測試重點在于真實用戶的使用方式和系統(tǒng)級別的體驗上。
9、ACC(特質、組件、能力)是測試計劃的替代方法，指導原則：簡明的列表、不必推銷、簡潔、有用的內容、漸進式描述、指導計劃者的思路、測試用例，最終達到的結果是詳細的描述測試用例怎么執(zhí)行。
特質是系統(tǒng)的形容詞，代表產品的品質和競爭，區(qū)別于競爭對手的關鍵。
組件是系統(tǒng)的名稱，構成待建系統(tǒng)的模塊，關鍵代碼塊。
能力是系統(tǒng)的動詞，代表系統(tǒng)在用戶指令下完成的動作，是可測試的。
10、風險分析的兩個要素：
發(fā)生頻率：罕見、少見、偶爾、常見
影響范圍：最小、一些、較大、最大
11、用戶故事來緩解風險，用戶有一個需求，而故事通常描述了該用戶如何使用軟件來滿足需求。
12、眾包是測試領域的新現象，一部分懂測試的高級用戶參與到測試工作中來，利用群眾的力量。
13、GTCM谷歌測試用例的管理工具，提供了一種靈活的標簽格式，任何項目可以自行定制，使得測試用例便于查找和復用。
14、Bug分析思路：優(yōu)先級分布、各個等級的平均年齡分布（和嚴重程度成反比）、Bug發(fā)現的趨勢（Bug的增加速度要小于測試人員和開發(fā)人員增加的速度）、Bug修復趨勢（Bug的修復速度要大于Bug的發(fā)現速度，否則不再進行新功能的開發(fā)）
15、追求數量而非質量，是一種低效的工作方式。
16、測試一個web頁面，上面有一個輸入框，一個計數按鈕，用于計算文本字符串中A出現的次數。
首先，提出問題而不是直接埋頭寫測試用例，明白是否區(qū)分大小寫，只能輸入英文嗎，點擊計算后文本會被清除嗎，多次連續(xù)點擊會有什么影響嗎，然后再寫測試用例
其次，考慮到界面外觀問題，文本框最多可以輸入多長字符串，多個用戶同時進行會串擾嗎，安全性數據會被記錄嗎，計算夠快嗎，能夠承載大負載嗎
17、作為一個測試工程師，要學會質疑，要求確定性的數據，不斷評估領導的指令。
18、接觸到一個新項目的正確做法
首先，站在用戶角度了解產品，以個人的賬戶和數據去使用產品，看所有的設計文檔，查看已有的bug，分析bug；
其次，積極和團隊溝通，快速融入到團隊中去，查看已有測試用例的覆蓋性、完整性；
然后，將產品分模塊，并根據bug考慮到每個模塊的風險；
最后進行測試，目標就是遺留到客戶的bug為0，利用用戶的反饋來督促bug的修復
19、分析Bug是一種技能。
20、自動化腳本需要能夠快速編寫、快速執(zhí)行、解決特定問題，因為花費大量時間編寫腳本一旦功能有變就是最大的浪費。大量的重復性工作最需要自動化測試。
21、測試工程師關注點：case、用戶故事、用戶場景、探索性測試。
22、查看設計文檔時的關注點：完整性（找出殘缺或需要特殊背景知識的地方）、正確性（語法、拼寫、標點）、一致性（圖文一致、內容沒有出入）、設計（目標、技術框架、是否復雜）、接口與協(xié)議（是否統(tǒng)一標準、是否可以自定義數據格式）、測試（可測試性、易測試性）
22、用戶故事包含了她是誰，她有什么需求以及她為什么有這樣的需求。對于一個項目可以確定好用戶角色再構建用戶場景