需求及專案測試過程中合作上遇到哪些問題，導致測試效率低下
產品側：
1. 需求排期完畢後，產品臨時加需求
2. 需求排期完畢後，臨時改方案
3. 需求排期完畢後，產品需求範圍評估不準確臨時增加回歸量
4. 需求測試完畢準備上線，產品放棄需求了
5. 需要多方共同上線的需求，單側封板等待上線期間出現需求變更
6. 臨時所謂「緊急」需求插入，影響正常的排期；
以上行為導致浪費研發和測試資源
解決方案：測試人員提公升自己對業務的理解能力及對研發架構的熟悉度，在需求評估、設計評審中對產品需求進行查漏補缺，當產品需求不合理時，拒絕需求；需求封板後待上線期間出現需求變更後由產品側提出變更優化需求，進行二次排期；緊急需求插入時，評估其緊急度，抄送領導同意後，溝通上下游，進行排期調整，可定期統計緊急需求的個數，對產品側能力進行逆向評估。
測試側1. 本側無修改，上下游聯調未排期，臨時需要支援聯調，影響正常測試的內容進度；
2. 環境不穩定或資料需要外部協助，影響測試進度；
解決方案：需要在日常工作中增加聯調支援的工期排期；
研發側1. 不及時更新jira狀態，影響及時回歸
2. 提測後才告訴有新的改造或者合併了其他需求，需要重新評估影響範圍，增加測試工作量；
3. 給了排期時間又臨時調整，影響測試原有排期
4. 預發環境頻繁發布，發布不同步測試，影響測試進度
5. 同一時間排期改動相同的應用，導致開發和測試階段都相互干擾，需要合併分支，開發需要頻繁合**，測試增加回歸量
解決方案：定時傳送jira統計郵件，設定日清規則，指定回歸時間；各個需求間獨立分支，合併上線時預留合併測試時間，除緊急bug修復外禁止臨時增加提測內容；預發布環境劃歸測試管理；同一時間多個需求測試走test分支部署，考慮用自動化用例覆蓋部分回歸工作。
自動化測試過程中遇到的問題
在我們模擬乙個訪問瀏覽器的操作時，可能會一條case開啟一次，如果多條case就會啟動多個瀏覽器頁面，這個時候可能會產生壓力對我們的伺服器，所以我們可以去通過單例模式解決這個問題。單例模式是用來修飾類下的變數，python單例模式 只生成一次driver 保證只保留乙個瀏覽器。單例模式，是一種常用的...
面試過程中遇到的面試問題
c 常見的四種強制型別轉換有哪些？常見的型別轉換是在要轉換的型別前面加上括號和要轉換的型別。這樣就有乙個規則即像站姿結束多的自動轉換，例如int型別和float相加時，結果自動轉換為float型別。例如int a 1 char p char a 以上這種形式是c語言的形式，如果換做c 的話常用的形式...
測試過程中的問題定位與分析
出現問題之後，可以從以下方面進行分析 1.看日誌，或者程式返回的錯誤碼 如 可以通過檢視日誌來確定程式是由於什麼原因出錯的，一般都可以在日誌中找到解決的方法 看錯誤碼也可以，如檢視資料庫的錯誤碼，大概知道是哪個地方出錯。像一些，不能讀取檔案，建立檔案失敗之類的，基本上都是檔案許可權，磁碟空間，hos...