1. 提測質量差
問題描述：第乙個提測版本差，有些均未通過冒煙測試
問題分析
a. 版本提測質量差，但基於發布時間已在，因此，在提測差時就開始測試
提測質量差的點：- 基於上每項功能的完成度都不高 - 有些功能均未實現 -
b. 新的團隊，團隊處於磨合期
c. 在提測時，對提測要求不明確，在時間點到後，匆忙提測
解決方式：
明確版本提測要求，並且開發得到了足夠的時間。
2. 版本控制
問題描述：
最初階段，每天出乙個版本，基於新版本測試，記錄每個版本上測試的功能。版本過於頻繁，質量把控不好
問題分析：
a. 基於版本提測質量差，而且每天出乙個版本，差上加差，
b. 雖然記錄每個版本上測試的功能，但仍然無法把控當前版本的質量狀況。
解決方式：暫停每天發布乙個版本
前期：將全功能版本作為下乙個版本發布目標，但由於一些功能並沒有完成，因而，全功能版本分成了好幾個階段
後期：以測試一輪週期，發布最新版本
3. 功能反覆
問題描述：在上乙個版本是ok的功能，在新版本中功能失常
功能反覆分兩點：一是大功能反覆， 二是小功能（如：某個bug）反覆
問題分析：
大功能反覆：情況主要發生成專案前期和中期
a. 功能未完成，在完善功能時，未考慮到與該功能相關的點
b. 在提測之後，發現一些問題，導致了整個模組重構，重構後導致了問題的反覆
小功能反覆：這個情況主要發生在專案中後期
a. 因為專案裡的部分開發是外援的，在專案中期時，撤出了團隊，新接手的人員，對**不熟悉，在修改bug時，經常出來顧此失彼
b. 開發小一在修改**時，動到了小二的**，導致了小二出了問題
解決方式：
對大功能反覆，是這麼處理：冒煙測試由開發來完成，冒煙通過後，再交由測試
對小功能反覆 ，沒有有效的處理方式，測試這邊可以做的是，加強測試，這個問題，在發布前夕好了很多，但問題仍然存在
4. 需求不明確，前後不一致
問題描述：需求不明確，特別在一些邊界，各端統一上
問題分析：
a. 互動文件經歷6任互動，最後一任互動只參與兩個模組的定義，現任互動對於以往互動了解不夠深入
b. 產品提測時，互動驗證不足
解決方式：
由於專案已提測，因此在整個週期裡，對於互動需求方面的疑問直接找相關人員去確認。
在後期的小版本中，我們把這類問題盡量控制在提測之前（詳見小版本裡的改進與問題）
5. 測試和開發資訊不對稱
問題描述：測試獲取到的訊息，與產品實現的方式不一致，如：有的功能定義了，但產品並未實現或實現方式與定義不一致
問題分析：
a. 在開發階段，測試並未參與討論需求，還在其他專案裡
b. 需求重新確認後，沒有及時通知測試
解決方式：
強調訊息需要通知到測試，現在階段，如果因這種型別而引起的問題，將建ticket，指派給相關人員
小版本裡的改進與問題
現存在問題：
1. 現對release版本會做rc checklist, 進行最後版本的質量控制，
但會存在一些問題，在小版本提測時，就已經存在，而冒煙測試是測不到的，在最後做checklist時，才發現
改進點：
1. 需求疑問在提測之前盡量提出，並且通知到開發，在開發階段便把該問題解決
測試在開發階段跟蹤產品進度
在寫測試用例時，就把問題丟擲。
2. 提測流程：
對功能方面的ticket，互動在提測之前便在開發機器上驗證，通過後再提測
把不符合互動預期的問題，在提測之前更改，節約了時間，避免問題在提測後才提出
另外一些測試過程中遇到的問題和溝通方式
從一開始，測試就要關注需求。
往往在討論設計時，開發和需求很容易忽略了測試成員，他們潛意識裡覺得這不關測試什麼事。可是，測試也要熟悉業務，熟悉功能，熟悉各種設計，而且測試需要站在使用者的角度來去考量他們的設計是否有不合理的地方，並提出自己的建議。這些工作，測試成員需要主動，積極參加，多提建設性意見，這樣可能會讓開發慢慢發現測試成員的重要性。 其次，溝通最頻繁應該還是關於bug的討論。下面列出幾個遇到的溝通問題，及我的解決辦法。
1、這個bug我這邊重現不了
解決辦法
bug應該簡明扼要，重點突出。
如果描述存在歧義，一定要總結並盡快改進。有時會遇到概率性的bug，要告訴開發概率是多少，盡可能多的提供重現的條件。 在復現問題時，希望能大致判斷幾個問題點，然後和測試人員溝通下，需要如何捕獲資訊，捕獲那類資訊？是不是提供debug版本進行復現，或者根據預判的點增加列印資訊版本進行復現？
2、這個不是**問題，需求這麼定義的
解決辦法
需求也是人定的，如果覺得有異議，
可以找需求人員詢問清楚，為什麼這樣定義，把自己的想法告訴他們，看他們怎麼決定。如果被需求說服了當然是最好的，如果自己還是不同意需求的看法，需求又不同意我的提議，那只能聽他的，畢竟權力在他那裡。但是我們可以保留交流的記錄，證明曾經在這裡發生過歧義。
3、這塊是別人負責的，我負責的部分沒有問題
解決辦法
解決辦法
測試人員一定比開發要敏感，對bug
的容忍度也要低一些。特別是一些不符合使用者習慣的bug
，開發總覺得無大礙。比如，乙個列表預設的寬度太小了，導致初次開啟，有一些內容被隱藏在後面，但是這個寬度可以手動調節。開發覺得問題很小，不影響功能，而且也有解決辦法，所以不認為是bug。這個時候，就要發揮測試的本事了，嘴甜一點，說說好話，態度柔和一些。因為既然是小問題，解決起來一定不難，耐心地催開發的改過來就好。催一次不行催兩次，記住態度一定要好。
5、使用者不會像你這樣操作的！
解決辦法
使用者怎麼操作，誰都預料不到。我們不可能覆蓋所有可能性，但是大多數使用者會出現的操作，
我們當然要測試。慢慢地把開發從**的世界裡帶出來，帶到使用者的世界裡，讓他換個角度思考問題，畢竟軟體開發不是為了實現功能，是要滿足使用者需求的。如果最後還是沒能說服他，第一向上級反映，第二做好溝通的記錄，將來備份在測試報告裡。 總結起來，測試在工作上要主動詢問，態度上不能輕易妥協，習慣上要善於記錄細節，方法上軟硬兼施。
軟體測試過程中的度量
在軟體測試過程中，可以將度量分為兩大類 1 衡量測試效率和測試工作量 工作量指標 例如，測試效率評價 測試進度s曲線等.2 從質量 的角度表明測試的結果 結果指標 例如，缺陷 數量 到達模式 系統崩潰和掛起的次數等.測試過程s曲線 追蹤測試過程也許是軟體測試階段管理中最重要的追蹤任務。建議的一種度量...
自動化測試過程中遇到的問題
在我們模擬乙個訪問瀏覽器的操作時，可能會一條case開啟一次，如果多條case就會啟動多個瀏覽器頁面，這個時候可能會產生壓力對我們的伺服器，所以我們可以去通過單例模式解決這個問題。單例模式是用來修飾類下的變數，python單例模式 只生成一次driver 保證只保留乙個瀏覽器。單例模式，是一種常用的...
測試過程中遇到的合作上的問題
需求及專案測試過程中合作上遇到哪些問題，導致測試效率低下 產品側 1.需求排期完畢後，產品臨時加需求 2.需求排期完畢後，臨時改方案 3.需求排期完畢後，產品需求範圍評估不準確臨時增加回歸量 4.需求測試完畢準備上線，產品放棄需求了 5.需要多方共同上線的需求，單側封板等待上線期間出現需求變更 6....