如何在快速迭代的當今，測試人員在使用更少的時間的測試
對於質量保障這一塊，該采取哪些質量控制手段來保證軟件/系統質量？
總體思路是這樣的：流程控制 + 測試深度 + 測試廣度。
其中流程控制主要有：質量保障工作前置，越早發現問題修復代價越小。流程埋點，流程數據分析及改進，流程基本穩定后再着手將其系統化，以提升效率。
流程控制中的一些關鍵階段的質量保障措施如下：
提測前質量保障：需求評審 +設計評審 +代碼評審 +用例評審 +靜態代碼掃描；
測試中質量保障：分層測試 +自動化測試 +上線前checklist檢查點 +產品試用機制 +基線壓測機制；
上線后質量保障：線上驗證 + 定期自動化回歸 + 系統穩定性監控 + 線上壓測；
測試深度包括：自動化測試 + 接口測試 + 少量白盒測試 + 探索性測試；
測試廣度包括：功能 + 性能（線上壓測 + 線下基線檢測） + 安全 + 易用性 +可維護性（注釋 + 重要行為日志）。
未來測試人員技能全面化是一個趨勢。但要求測試人員既要懂產品，又要懂開發，這對於要經常趕工期的測試人員來說是非常大的挑戰。
建議是：
重點在工作中學習，在工作中提升，或者擠出一些業余時間來學習。
關於趕工期，大家普遍有這樣的觀點：因為測試時間少，大家就會趕工期，然后就拼命地去通過手工測試的方法趕工，因為手工測試來的直接哇，直接上手就測。長久看來就會發現，越這樣，未來隨着項目的增多就越需要趕工，時間就越不夠用，長此以往，形成惡性循環。
所以大家必須改變思維，解放思想，要在繁雜的工作中堅持學習。我們是否能夠擠出一點時間來嘗試新的實踐呢？如：采用靜態代碼掃描的方式將大量低級錯誤在代碼提交前就修復，采用自動化測試將一些重復的勞動用機器來代替。這些都是值得學習並實踐的。
如何在功能測試階段自動化測試思考
在功能開始階段全部實現自動化測試不現實，用例數目過多。是否可以在功能測試階段先實現冒煙用例的自動化測試，並把自動化腳本個人構建提供給開發。開發在修改完代碼后可以先個人構建成功后在提交代碼。
在冒煙用例后的的快速測試思考
是否可以對已知代碼只修改算法規則進行手動直接插入數據庫數據來驗證算法，而不用每次手動模擬用戶來創建數據？
或者專門創建UI自動化用例來每次創建數據？但是對於多場景快速迭代情況，UI用例變化很大。
如何在質量有保證前提下，使用更短測試時間內
細分測試影響點：需要和開發一期分析。本次迭代修影響到那些，重點測試。然后分析修改點相關聯的模塊，做次要測試點。
審核開發代碼：審核開發代碼也可以更清楚查看到開發有何地方為覆蓋，防止漏測