在進行full regression testing
之前，對以前的版本進行了
mini
測試，這種測試需要執行的
case
非常少，每人只有幾個
case
的任務量。
從7.31
號開始到
8.08
號截止，完全回歸測試的
case
已執行完畢，比計畫提前了一周時間。其間沒有加過一天班，一般都能在下午
5點以前完成當天任務。在測試開始的頭幾天，由於測試環境未完全配置好，導致測試進行得不太順利，此後有了很大改觀。
我做了什麼
對於測試以及現在的專案，我是個新手，因此主要工作是執行
case
，而且由於
id的問題，即便發現
defect
也不能由自己直接上報。
1.分析
cases
。在測試之前分析即將執行的
case
，並做一些補充和修改。
2.執行
case
。分配任務
37個，執行通過
37個，失敗
1個，另有
1個因為環境原因不能進行測試。
3.發現
defect
。在測試之前就發現
1個頁面錯誤，後經確認屬於誤保，因為測試環境是韓文，不是很理解一些文字的真正含義。後來測試新新增的功能，發現
1個。另外也發現乙個較嚴重的問題，頁面上缺失了乙個按鈕，可惜超出我們的測試範圍，讓其他
team
撿個便宜。
跑了這麼多
case
，沒有發現幾個
defect
，實在有些令人沮喪。一本經典的軟體測試書上講，乙個好的
tester
不是發現最多的
defect
的人，而是督促
developer
更正defect
最多的人。我現在還沒有許可權開
defect
，當然也沒法去督促
developer
。那麼衡量工作的原則就落在發現
defect
數量上。在任何時候，程式中始終存在
defect
，發現不了它意味著
tester
工作的失敗。發現不了
defect
或者defect
數量很少，是值得
developer
慶賀的事，但決不是
tester
該高興的事！
除了執行
case
，我還做了另一些額外的工作，比如兩次發現
daily test report
中的問題。其實我現在最想做的是，找到一種方法可以幫助發現更多的
defect
，以及改進
team
目前所採用的測試方式，提高整個
team
工作效率（如減少執行
case
之外的時間消耗）和質量（如發現更多的
defect
），盡量避免工作中人為的失誤（一些工作由人手工來做，失誤不可避免）。人為失誤包括（這些都發生在實際測試過程中）：
1.兩人跑了同乙個
case
，或者跑錯了
case。2.
team
成員間資訊溝通不夠通暢。比如當
a執行某個
case
時，發生失效並找到
defect
，應該及時通知執行類似
case
的人。還有，當
defect
被修復，也要及時通知
defect reporter
關閉defect。3.
統計case
執**況時數量上有出入，比如漏掉某些
case。4.
忘記更新
test report
的某些部分。
存在的問題
第一次執行這麼多
case
，擔心在限定期限內完不成任務，所以乙個勁地完全按照
case
描述的步驟來執行，這樣可能忽略頁面其他地方出現的錯誤。實際的測試需要執行的步驟比
case
裡描述得應該要多些。
對case
的熟悉程度不夠，制定的每天工作任務並不均衡。從這次測試中吸取到的一條經驗是，在測試的最初階段，由於測試環境未完全配置好，一些較複雜的
case
不能順利通過或者要花很多時間才能通過，此時宜先執行較簡單的
case
。以後要做的事
我們這個
team
的工作一直都不忙，最忙時要數
full regression testing
，但也不用加班。有很多的
free time
用來學習、研究自己感興趣的問題和技術，部門經理和
team leader
對此很支援。我選擇研究
odc（正交缺陷分析），目的是通過學習它，能幫助自己提高找到
defect
的經驗和技能。遺憾的是，沒有實踐
odc的機會，只能在理論上做一些研究。
上面提到了
team
在這輪測試過程中表現出來的一些工作失誤，我認為這些失誤其實都是可以避免的，方法即是採用某種
tool
來管理case
。上週和
leader
談到case management system
，得到的資訊是，自己去開發乙個
cms並不受支援，原因有二：其一，現在一些
tool
有此項功能，其二，
leader
和老員工已經很熟悉
case
，並且習慣
excel
管理case
的方式。儘管後者是低效且容易出錯的。既然能拿到
100分，為什麼要得
90呢？對此，我有兩個對策，一是學習使用一種
tool
來管理case
，二是開發個人版
cms。先提高個人的工作效率和質量，然後再影響其他人，最後推動整個
team
的改變。
我還想做的一件事，是分析以前所有發現的
defect
，總結出一些可幫助在未來的測試中找到更多
defect
。測試體會
（1）在進行full regression testing之前，我就想到，目前的產品既然已經很成熟，那麼defect可能較多出現在介面上，特別是顯眼卻常不被注意到的地方，其次是新新增的功能。從最後結果看，找到的defect可以分為三類：前面提到的兩種情況，另加受新增功能影響的原有功能。
（2）在測試的最初階段，由於測試環境未完全配置好，一些較複雜的case不能順利通過或者要花很多時間才能通過，此時宜先執行較簡單的case。
介面回歸測試
介面測試需要哪些準備 1 要有介面文件。類似於字典，知道自己要測哪些內容。介面測試分類 有了以上幾點，就可以開展介面測試了。但是介面測試分為了很多種，你要做哪個？最基礎的 介面回歸測試。以此擴充套件的 線上介面監控 安全測試 壓力測試 穩定測試等。介面回歸測試 具體步驟如下。以android手機為例...
回歸測試簡介
回歸測試是指修改了舊 後，重新進行測試以確認修改沒有引入新的錯誤或導致其他 產生錯誤。在軟體開發過程當中，一旦軟體 做了修改，就有可能引入新的問題，所以這個時候就需要把已經完成了的驗證用例重新跑一下，以確保 的修改沒有對已經驗證過的功能造成影響。我們把這乙個過程叫做回歸驗證 也有人叫 回歸 自動回歸...
名詞 回歸測試
回歸測試 回歸測試是軟體測試的一種，旨在檢驗軟體原有功能在修改後是否保持完整。回歸測試是指修改了舊 後，重新進行測試以確認修改沒有引入新的錯誤或導致其他 產生錯誤。自動回歸測試將大幅降低系統測試 維護公升級等階段的成本。回歸測試是軟體測試中的乙個十分重要且成本昂貴的過程。針對如何減少回歸測試成本，提...