軟體測試的生命週期

生命週期:
需求分析->測試計劃->測試設計->測試開發->測試執行->測試評估
在這裡與軟體開發的週期進行類比學習,其實就是V模型.

描述bug

合格的bug包含:
1.發現問題的版本.
2.問題出現的環境(檢視專案的支援版本,測試的環境不同可能結果也會不同).
3.錯誤重現的步驟(類比測試用例的步驟).
4.預期行為的描述(需要開發人員的指導).
5.錯誤行為的描述.
6.其它:例如:功能故障,介面故障,相容性故障等.
注意:不要把多個bug放在一起(若寫一起,可能就無法定義bug出現的位置).

bug級別

在不同的公司對bug的定義級別不同.
1.Blocker(崩潰):
造成系統崩潰,宕機,死迴圈,導致資料庫丟失,與資料庫連線錯誤等.
2.Critical(嚴重):
系統主要功能部分喪失,資料庫儲存呼叫錯誤,使用者資料丟失.
3.Major(一般):
功能沒有完全實現但是不影響使用.例如:操作時間長,查詢時間長,刪除沒有確認框等.
4.Minor(次要):
建議性的問題,不影響操作功能的指向,可以優化效能的方案等.

bug生命週期

不同的公司對bug的生命週期定義不同.
下圖是一個簡單的bug的流程

New:發現的新的bug;
Open:確認是bug,並且認為需要修改,指派給相應的開發人員.
Fixed:開發人員進行修改後標識為修改狀態,等待測試人員的迴歸測試驗證.
Rejected:如果開發人員不認為是bug,拒絕修改.
Delay:延後修改.
Closed:修改狀態的bug經過測試人員的迴歸驗證通過,就關閉bug.
Reopen:如果經驗證後bug仍然存在,則需要重新開啟bug,開發人員重新修改.

無效的bug:
Open->Closed,Open->Rejected->Closed

菜鳥之測試流程:

1.閱讀所有專案有關的文件.
2.儘可能參加各種專案會議.
3.熟悉專案所有的測試管理工具,配置管理工具.
4.閱讀舊的bug庫,瞭解系統功能.
5.瞭解公司的規範要求.
7.尋找了解業務的測試人員請求指導(主動找).

發現更多的bug

1.二八原則:80%的故障可能集中於20%的模組(著重測試這塊程式碼).當然也有可能是80%的故障集中於20%的開發人員(著重對這些測試人員的程式碼盡心測試).
2.多進行逆向思維和發散性思維.
3.不要侷限於用例和需求文件.
4.儘早的瞭解專案,介入專案.