需求以故障單處理和夾帶優化程序提版的思考

 

在2013年7月版需求及故障測試過程當中，我遇到「需求以故障單處理」和「夾帶優化程序提版」的兩種狀況，對於這兩種狀況，處理方法具體以下：

一、需求以故障單處理的思考

原解決方案的抵質押物編號規則爲：交易日期（8位）+帳務行所（6位）+系統類型（1位）+批次號（3位）+序號（2位），該解決方案不知足業務需求。

後來通過幾番討論，解決方案的抵質押物編號規則:交易日期（8位）+帳務行所（6位）+系統類型（1位）+批次號（3位）+序號（2位），爲了加快上線投產，以故障單的流程走。

此故障單投產後，出現任務號鏈接池鏈接後未釋放，致使該鏈接池數量耗盡(任務號鏈接池數量達到500時耗盡)，形成平臺生成任務號的交易發起任務失敗。

開發人員只提供故障應急處理表，沒有提供最新需求說明書和最新需求概要設計。

測試人員對故障應急處理表的測試要點分析不透徹。

 

咱們測試人員具體處理方法以下：

一、           需求說明書和概要設計：堅持要開發人員或需求分析人員提供最新需求說明書和概要設計書。提醒測試經理不斷催開發人員提供最新需求說明書和概要設計書，直到拿到爲止。

二、           測試要點分析：測試人員不要輕視故障單。故障單或需求中存在「在數據庫中爲每一個帳務機構建立一個序列」這樣的字眼，必需要重視，此說法將會涉及到「平臺任務號鏈接池讀取序列」。

三、           要注意有使用任務號鏈接池讀取序列的測試：要分析出哪些系統交易涉及到有使用任務號鏈接池；測試方法：申請改小任務號鏈接池數量的最大值，而後發起大於最大值的交易（涉及平臺生成任務號的交易和櫃面生成任務號的交易），看看是否可以正常發起而且記帳成功。

 

面對這種狀況，我以爲測試人員須要多思考、多分析。

面對這種狀況，建議開發人員可以配合地提供最新需求說明書和概要設計給測試人員。

面對這種狀況，建議之後在任務受理時，對於需求走故障流程的這種狀況，要求項目組必須提供最新需求文檔和概要設計文檔，不然，不受理。

 

二、夾帶優化程序提版的思考

在7月版需求測試中，存在開發人員把優化程序跟不相關的BUG一塊兒提版部署的狀況。此優化程序涉及銀承自動解付的內容挺多的。

 

這種狀況，開發人員沒有列出優化程序涉及的內容，沒有發出通知告知測試人員。

開發人員沒有清楚的說明和告知，將會致使測試人員漏測這部份內容。

 

面對這種狀況，建議咱們測試人員的處理方法以下：

一、 測試經理或測試人員要注意查看部署程序說明。測試經理或測試人員要追問開發人員優化程序的具體修改內容。

二、 要重視開發人員提的優化程序，要詳細分析測試要點，補充測試用例。

 

面對這種狀況，建議開發人員的處理方法以下：

一、           列出優化程序涉及的內容，發出通知告知測試人員。

二、           若是優化程序涉及的內容太多，那堅持要求業務人員提需求解決或是走需求變動解決。