天天看點

測試過程中的評審工作及關注事項

測試過程中的評審工作及關注事項

公司的軟體開發epg過程規範中對測試領域的工作及其規範做了細緻的說明,雖然是cmmi3+,不過還是有些地方隻是官樣文章,是形而上的東西,在實際工作中不具備任何的指導作用。是以我們上司覺得這個可以自己重新定義一些在測試思維上較為技術性的東西納入到測試領域的規範當中,而我負責關于使用者需求評審和系統測試用例評審的檢查點整理工作。由于使用者需求評審能夠有助于測試人員系統測試工作的開展,是以下面就使用者與需求評審所需要準備的工作、使用者需求評審時所要思考的問題、系統測試用例評審過程中所需要考慮的一些檢查點進行簡單的列舉。這些内容都是個人經驗總結,并不能應用于所有類型的系統,是以請不要拿來硬套,因為不同行業、不同類型的系統特征是不同的,我所關注的隻是我所負責的保險系列業務系統。

  使用者需求評審準備工作

  》向使用者或者ba/sa索取原始需求文檔;

  》仔細閱讀需求文檔,大緻估算系統改動;

  》向開發人員了解預計的開發工作量,并且互相印證系統改動的估算;

  》了解需求排期,預估測試所需人力,估算時需要考慮關聯影響測試;

  》了解相同和接近的版本周期内的其他需求和版本,預估測試環境和人力是否足夠,如果有可能資源不足則及時更新并且邀請測試經理參與需求評審會議。

  使用者需求評審問題清單

  》本需求提出的背景:現有功能有什麼樣的問題、由什麼市場、行業的變化所導緻?

  》本需求所要實作的目标:操作流程簡化、業務成本降低或者客戶滿意度提高等等?

  》本需求是否有前置和後續需求排期?其優先級是否合理,實作情況分别是怎樣的?

  》本需求的内容是否會與現有業務邏輯或者系統邏輯的沖突?如果有,該如何解決?

  》本需求所包含内容是否有備援:與現有某些系統功能或流程重複,造成重複開發?

  》本需求是否有足夠的資源去實作,包括測試人力、開發人力或者測試環境等資源?

  》本需求完成之後的效益是否足夠抵消其在it版本的成本投入?是否可能會出現在這個需求上“得不償失”或者說“入不敷出”的情況?

  》本需求使用者驗收測試有什麼樣的案例?對應的資料類型和資料量的需求是怎樣的?

  》本需求的uat所需要的時間應該有多少?使用者是否有足夠的測試人力投入?it應該保證的最短uat時間需要多少天?

  》uat人員是否有就此需求測試的其他特殊要求或疑問?如果有,這些要求是否合理、是否有必要、是否需要it同僚支援或者是否有變通解決方法?

  系統測試用例評審關注點

  》用例描述、操作步驟、預期結果和資料使用等資訊是否準确、完整、無歧義;

  》用例是否包含了足夠多的業務類型分支或資料場景分支;

  》用例中是否設計了操作源表包含百、萬、百萬甚至億級資料,結果集輸出包含十、百、千等不同級别的資料場景,對其性能是否可接受是否有可行的驗證方法;

  》用例是否考慮了使用者使用的頻率,若使用非常頻繁,那麼是否需要做并發測試;

  》被測功能是否為無操作界面的系統自動任務,若無操作界面,那麼用例中是否考慮了使用者測試的方法;若有界面,是否有界面規範性性檢查測試用例(cq中有界面變更項為是的需求);

  》對于查詢、報表類功能:

    >> 用例設計是否包含對查詢結果完整性、顯示格式、排序等方面的檢查;

    >> 用例是否包含足夠的必輸項和頁面控制的檢查,空值查詢的資料庫消耗是否正常;

    >> 用例對不同查詢條件的組合場景設計是否充分;

    >> 用例是否檢查了對于有導出excel等文本的情況,導出查詢是否同步修改;

    >> 報表生成過程中是否涉及背景資料的變化,即:是否涉及中間表、臨時表的使用,如有使用,那麼用例是否包含對計算過程中的中間表、臨時表的資料正确性檢查;

    >> 用例是否考慮了現有測試資料庫的資料是否滿足測試要求,是否需要造資料或者導生産資料,測試資料與使用者驗收測試是否可以共用等因素;

  》對于業務操作類功能:

    >> 被測功能中是否包含查詢功能,如果包含則參見查詢、報表類功能評審檢查點;

    >> 用例中對操作産生的資料狀态的流轉是否有清晰的說明;

    >> 用例是否包含了對可逆資料的反複正向、逆向操作結果正确性的檢查;

    >> 對于可能發生的異常,是否設計了足夠多的場景,對于發生異常之後的應用健康度是否有檢查,在異常場景中,是否包含對産生髒資料的可能性的檢查;

    >> 對于涉及eai、etl等資料同步的功能或涉及不同資料庫或資料表之間資料交換的功能,是否有對不同資料庫、資料表的字段和前背景字段類型、長度一緻性的檢查;

    >> 針對本需求的修改點,是否設計了對其關聯功能或潛在關聯影響的測試用例,關聯影響分析的依據是什麼;

    >> 對界面操作的背景日志記錄是否有檢查其完整性和正确性,是否有單獨開發監控程式的必要;

    >> 用例的優先級是怎樣的,對應功能不可用的情況下,其他測試用例的執行是否受到影響,對于這種情況是否有規避的方法;反之本測試用例是否受制于其他測試用例執行結果的正确性,如果是則又該如何解決;

    >> 用例執行的前置條件是否清楚,如:測試執行時是否需要依賴特殊外設或者硬體資源、關聯系統的版本進度和品質等;

    >> 是否需要為本用例所對應的功能建立功能點或分支,用例是否需要加入到回歸測試用例中,本測試用例是否可自動化,是否可以立即自動化,自動化腳本開發預計需要多少時間;