測試過程中遇到的合作上的問題

2022-09-16 13:00:11 字數 895 閱讀 1454

需求及專案測試過程中合作上遇到哪些問題,導致測試效率低下

產品側:

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...