測試流程（各有千秋）
1、測試人員參與需求評審、交互評審、視覺評審；理解需求，進行需求分析
2、測試負責人編寫測試計划，分配測試任務，評估測試周期
3、測試人員整理交互or需求疑難點，確認異常場景or特殊情況下的交互細節，最好是能划出新功能的數據流圖&流程圖
4、測試人員編寫測試點，轉化測試用例，評審測試點or測試用例
5、開發送測（提測）前，開發自行走查，產品視覺驗收，若有必要，測試可介入冒煙測試
6、送測（提測）階段，缺陷管理，發現bug，提交bug
7、博主這邊是分A1，A2，A3...階段，一般A1過新功能測試用例&主流程回歸，A2驗證bug&交叉測試&拓展測試，A3驗證bug&拓展測試
8、預發（灰發）環境驗證
9、線上環境驗證
10、版本復盤
黑盒測試相關
黑盒測試主要是為了發現以下幾類錯誤
1、是否有不正確或遺漏的功能？
2、在接口上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4、性能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？
黑盒測試優點
1.比較簡單，不需要了解程序內部的代碼及實現，因為與內部實現無關；
2.從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
3.基於軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；
4.在做軟件自動化測試時較為方便
黑盒測試缺點
1.不可能覆蓋所有的代碼，覆蓋率較低；
2.部分路徑不能測試到，不能測試程序中隱藏的錯誤；
3.自動化測試的復用性較低
黑盒測試方法
等價類、邊界值、因果圖、判定表、狀態遷移、正交實驗、場景法、錯誤推斷
自動化測試相關
自動化測試的優點
1、回歸測試更方便，由於回歸測試的額動作和用例是完全設計好，測試結果也是可以預料的，將回歸測試自動運行，可以提高測試效率，縮短回歸測試時間
2、運行更多更繁瑣的測試
3、可以執行一些手工測試困難的測試，可以通過自動化測試模擬同時有大量用戶的測試
4、測試具有一致性和可重復性，每次測試的結果和執行的內容的一致性可以得到保障，達到測試的可重復的效果
5、測試的復用性，實現在不同的測試過程中使用相同的用例
6、測試的執行可靠性，按腳本執行，后續定位復現有明確的路徑可循
7、資源利用率高，人力成本低
8、基本的、邏輯性不強的操作，性能測試、壓力測試、回歸測試，自動化測試很大優勢
自動化測試的缺點
1、手工測試比自動測試發現的缺陷更多
2、對測試的依賴性大
3、只適合回歸測試
4、手工測試編寫時間少於測試腳本編寫時間
5、手工測試可以靠人的想象力去測試， 而工具是死的
6、自動化測試可能會制約軟件開發，腳本維護會受到限制，從而制約軟件的開發
總結：自動化測試是對手工測試的一種補充，自動化測試不可能完全替代手工測試，因為很多數據的正確性、界面是否美觀、業務邏輯的滿足程度等都離不開測試人員的人工判斷
app常見測試點
1、安裝、卸載 apk上安裝與卸載，在工具上可以安裝卸載
2、兼容性測試 系統版本，安卓版本，尺寸
3、異常測試 斷網、斷電、服務器異常情況下，客戶端是否正常處理
4、在線升級測試 在線升級，升級后可以正常使用
5、易用性測試 操作簡單，符合用戶使用習慣
6、交互性測試 來電，來短信，低電量測試，拔充電線會不會影響app
7、功能測試 檢驗功能是否符合需求，涉及到UI層，接口，數據，服務端，代碼邏輯等。
8、穩定性測試 通過Monkey：命令行工具，對正在開發的應用程序進行壓測，向系統發送偽隨機的用戶事件流（按鍵輸入、觸屏輸入、手勢輸入）進行壓測
9、安全測試 是否容易被外界破解，是否存在被惡意代碼注入的風險
10、性能測試 應用測試、ROM測試、客戶端運行時設備的CPU、GPU、流量、耗電量，響應時間
11、自動化測試：robotium、Appium
12、外網場景測試 不同網絡場景，wifi、3g、4g、電信、移動、聯通、弱網場景，通過fiddler
13、中斷測試（電話接入、來短信、電量不足提示燈外部事件）
app測試和web測試的區別
| web | app | |
| 性能測試 | 響應時間... | 加上：流量、電量、CPU、GPU、內存... |
| 兼容測試 | 不同瀏覽器和瀏覽器版本 | 加上：手機的尺寸、分辨率、系統版本、安卓版本 |
| 交叉事件測試 | 在操作某個軟件的時候，來電話、來短信，電量不足提示等外部事件 | |
| 操作類型測試 | 橫屏測試，手勢測試 |
冒煙測試和回歸測試的區別
冒煙測試：新版本驗證測試，主要確認新的版本是否存在致命性bug，功能可以正常運行，不會影響下一輪測試，不要求覆蓋面有多廣，但是要保證被測對象的主功能點得到測試，還要保證所有被修改過以及修改相關的功能都是可用的，若都通過則可以進行系統測試
回歸測試：是軟件維護階段對軟件修改后進行的測試，指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤
靜態測試和動態測試的區別
靜態測試：不運行被測程序本身，通過評審文檔和閱讀代碼等方式測試軟件
動態測試：通過運行被測程序，檢查運行結果與預期結果的差異，通常使用白盒和黑盒測試從不同的角度設計測試用例來查找代碼中的錯誤
關鍵字：不運行，文檔，代碼
運行，結果差異，黑盒白盒
α、β、λ測試的區別
- α測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試。目的是評價軟件產品的FURPS（即功能、可使用性、可靠性、性能和支持）
- β測試：是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程序員或測試員完成。（文檔，客戶培訓，產品支持，可支持性）
- λ測試：是第三個階段，此時產品已經相當成熟，只需在個別地方再做進一步的優化處理即可上市發行
負載測試(Load testing)、壓力測試(stress testing)和性能測試(Performance Evaluation Test)的區別
- 性能測試：為了獲得系統在某種特定的條件下（包括特定的負載條件下）的性能指標數據
- 負載測試：模擬實際軟件系統所承受的負載條件的系統負荷，通過不斷加載（逐漸增加模擬用戶的數量）或其他加載方式來觀察不同負載下系統的響應時間和數據吞吐量、系統占用的資源（如CPU、內存），以檢驗系統的行為和特性，以發現系統可能存在的性能瓶頸、內存泄漏、不能實時同步等問題。負載測試更多地體現 了一種方法或一種技術
- 壓力測試：在強負載（大數據量、大量並發用戶等）下的測試，查看應用系統在峰值使用情況下操作行為，從而有效地發現系統的某項功能隱患、系統是否具有良好的容錯能力和可恢復能力。壓力測試分為高負載下的長時間的穩定性壓力測試和極限負載情況下導致系統崩潰的破壞性壓力測試
什么是需求文檔測試？
測試需求中是否存在邏輯矛盾以及需求在技術上是否可以實現
關鍵字：測試需求，邏輯矛盾，技術實現
什么是設計文檔測試？
測試設計是否符合全部需求以及設計是否合理
關鍵字：測試設計，符合需求，是否合理