共用方式為


Power BI 實作規劃:驗證內容

注意

本文是 Power BI 實作規劃系列文章的其中一篇。 此系列主要著重於 Microsoft Fabric 中的 Power BI 體驗。 如需有關此系列的簡介,請參閱 Power BI 實作規劃

本文可協助您在管理內容生命週期時驗證內容。 本文的主要目標讀者為:

  • 卓越中心 (COE) 和 BI 小組:這類小組負責監督組織中的 Power BI。 這些小組包含決定如何管理 Power BI 內容生命週期的決策者。 這些小組也包含發佈管理員 (負責處理內容發佈生命週期) 及工程視 (負責建立和管理有效使用和支援生命週期管理所需的元件)。
  • 內容建立者和內容擁有者:建立要發佈至 Fabric 入口網站以與其他人員共用內容的使用者。 這些人員負責管理所建立 Power BI 內容的生命週期。

生命週期管理包含您用於處理內容的程序和做法,涵蓋內容的建立到最終淘汰。 在生命週期管理第二個階段中,您會開發內容和管理變更,其中涉及如何開發內容及設定工作區及版本控制的重要決策。 在第三個階段中,您會驗證內容以測試內容是否已準備好進行部署。

注意

您通常會逐一查看後續開發和驗證週期中的第二和第三個階段。

驗證內容是重要階段,可確保解決方案的品質和可信度。 基於此理由,請務必先測試內容變更,再將其部署至正式執行環境。

下列影像描述 Power BI 內容的生命週期,其中醒目提示第三階段 (驗證內容)。

圖表顯示 Power BI 內容生命週期。已醒目提示第 3 階段,這是內容驗證階段。

注意

如需內容生命週期管理的概觀,請參閱本系列的第一篇文章

本文的重點在於在整個生命週期中驗證內容的重要考量和決策。 如需如何驗證內容的詳細指引,請參閱:

驗證內容包含特定決策制定或確保內容如預期般執行的動作。

當您驗證內容時,您將評估解決方案的不同層面。

您可執行不同類型的測試以驗證內容。 下列各節說明內容建立者和內容取用者如何執行測試的決策重要考量。

注意

許多小組使用源自軟體開發的測試方法,例如單元測試、整合測試和煙霧測試。 內容測試和驗證有許多同樣有效的方法。 最重要的是,您將使用最符合您需求的方式和小組工作的方式來測試內容。

決定建立者應如何驗證內容

內容建立者應該驗證自己的內容變更,確保變更的品質和功能。 測試通常發生在開發工作區,其中包含最新工作版本的解決方案。 內容建立者會先測試自己的變更,然後再將內容部署至測試工作區以進行使用者驗證。

注意

內容建立者必須先驗證自己的內容,才能提供給使用者使用。 如果提供解決方案以測試明顯問題的使用者,則會削弱對解決方案的信任。 即使在測試時,使用者仍預期看到最終產品的合理表現。 此外,功能解決方案可讓使用者專注於找出與商務領域相關的問題。

內容建立者有兩種方式可以驗證內容。

  • 手動測試:手動測試包含人員透過主觀評估或比較某些客觀測試準則以手動驗證內容。 手動測試可輕鬆執行,但受限於人為錯誤或偏差。 此外,當內容達到特定規模時,手動測試可能變得耗時費力,才能正確執行。 您可以透過兩種方式進行手動測試。
    • 獨立檢閱,其中包含測試自己的內容,例如語意模型和報表。
    • 同儕審查,其中包含主觀評估內容以嚴謹評定解決方案並提供改善建議。
  • 自動化測試:自動化測試包含預先準備的測試,在沒有人為介入的情況下自動評估。 一般而言,自動化評估會根據特定基準來檢查解決方案程式碼的組件。 自動化測試較難以執行,因此需要時間和精力進行設定。 不過,自動化測試在企業案例中至關重要,可確保大型實作和業務關鍵解決方案的品質和可信度。

下列各節說明內容建立者可執行手動測試、自動化測試和同儕審查的不同方式。

執行手動測試

您應該對所建立的內容執行自己的手動測試。 這些測試可確保您的變更如預期般運作,並達到所需的品質標準。 一般而言,手動測試包含使用和主觀評估內容或特定內容變更,以及描述和記錄結果。

以下是測試自己內容時的一些考量。

  • 事先決定並記錄測試條件和成功準則。
  • 完整測試和記錄測試結果。 不過,請確定您避免進行多餘的測試,讓您的測試做法不會減緩開發速度。
  • 為每個項目類型建立一組標準測試以改善重複性。
  • 記錄測試結果和結論。
  • 測試多次以確保您的測試結果最能反映現實,而不是隨機的可能性。
  • 使用代表實際執行環境的測試條件。

下列各節說明手動測試的其他重要考量。

手動測試語意模型

語意模型是 Fabric 和 Power BI 中解決方案的重要部分,因為這是報表、儀表板和其他用戶端工具及 Fabric 工作負載的上游來源。 因此,在部署之前,請務必先驗證語意模型。

回答下列問題,有助於驗證語意模型。

  • 資料表包含的值是否非預期、缺少、重複或不正確?
  • DAX 量值是否傳回預期的結果,而沒有長時間查詢?
  • 排程的重新整理是否成功完成,而沒有長時間重新整理?
  • 您是否觀察到因違規參考完整性而導致視覺效果、篩選條件或查詢結果中有 (空白) 結果?
  • 資料安全性 (例如 RLS 或物件層級安全性 (OLS)) 是否足以防止未經授權的人員存取模型或其資料?
  • 模型物件 (例如 DAX 量值或資料表資料行) 是否組織為顯示資料夾?

您可以使用不同的工具和方法來協助您驗證語意模型。

  • Power BI Desktop:Power BI Desktop 可讓您使用各種功能來驗證語意模型的不同層面。 可協助測試語意模型的 Power BI Desktop 功能範例包含:
    • 視覺效果畫布:使用拖放功能以測試模型功能和正確性。
    • DAX 查詢檢視:使用 DAX 查詢測試模型正確性和 DAX 程式碼,您可以儲存並稍後重複使用。
    • 查詢診斷:取得 Power Query 中評估查詢方式的診斷資訊,測試重新整理效能。
  • Fabric:Fabric 入口網站中的功能和項目可讓您在將語意模型部署至工作區之後驗證其層面。
  • 第三方工具:第三方工具可讓您透過提供更多詳細資料或有助於驗證的其他功能以驗證語意模型的其他層面。 可協助測試語意模型的第三方工具範例包含:
    • DAX Studio:透過接收 DAX 查詢時間和查詢計劃的詳細明細,測試並最佳化 DAX 程式碼的效能。
    • 表格式編輯器:透過接收 DAX 查詢評估方式和作用中評估內容的詳細明細,測試並偵錯 DAX 程式碼的正確性。

提示

您可以使用查詢診斷以從使用 Power Query 的其他項目 (例如資料流程),從而手動驗證和最佳化 Power Query 的效能。

此外,您也可以使用 DAX 查詢檢視和第三方工具 (例如 DAX Studio) 以驗證和最佳化分頁報表和計分卡的 DAX 查詢。

手動測試報表

報表是使用者與您資料互動的常見方式。 許多使用者依賴報表以進行決策制定,並採取動作來達成營運目標。 因此,在部署之前,請務必驗證報表。

回答下列問題,有助於您驗證報表。

  • 報表是否符合記錄的商務需求?
  • 是否使用正確的視覺效果類型以解決正確的問題
  • 報表頁面是否清晰簡潔,沒有過度的色彩或太多視覺效果?
  • 當篩選至縮小的資料子集時,報表是否如預期般運作?
  • 報表是否允許匯出至 Excel,如果是,是否允許擷取摘要資料或基礎資料?
  • 報表是否可用於跨報表鑽研或視覺效果個人化?

您可以使用不同的工具和方法來協助您驗證報表。

  • Power BI Desktop:Power BI Desktop 可讓您使用各種功能來驗證報表的不同層面。 可協助測試報表的 Power BI Desktop 功能範例包含:
    • 可見視覺效果:透過使用交叉分析篩選器、篩選和其他互動式元素以測試報表功能。
    • 效能分析器:透過測量視覺效果轉譯和 DAX 查詢時間來測試報表效能。 您可以從效能分析器複製視覺效果 DAX 查詢,以用於其他工具並儲存效能結果以供記錄。
    • 查詢限制模擬:透過按所部署的容量模擬限制來測試報表效能。
  • Fabric:Fabric 入口網站中的功能和項目可讓您在將報表部署至工作區之後驗證其層面。
    • 更新應用程式:在 Power BI 應用程式中散發報表時測試報表功能和安全性,並設定不同的應用程式對象以決定可檢視內容的人員。 當您使用應用程式對象,您可以預覽人員可存取的報表,並自行測試應用程式體驗。
    • 工作區或應用程式的閱讀檢視:透過以使用者身分在相同的環境中使用該功能以測試報表功能和正確性。

注意

您僅可以在 Fabric 入口網站中開發和驗證儀表板。

重要

請務必在 Power BI Desktop 及在 Fabric 入口網站中部署之後測試報表。 相較於 Fabric 工作區中的報表,視覺效果轉譯在本機電腦上的行為可能有所不同。 此外,請注意,從工作區或應用程式使用報表的使用者體驗與在 Power BI Desktop 中使用報表有明顯不同。

執行同儕審查以手動測試

手動驗證內容的另一種方式是執行同儕審查。 在同儕審查中,內容建立者會向同事提供解決方案或解決方案一部分以進行驗證。 同儕審查的目的是使用多個內容建立者的共同體驗和專業知識來改善解決方案。 您可以在手動和自動化測試期間和之後執行同儕審查。

注意

同儕審查是許多產業採用的標準方法。 此方法通常可以改善內容、產品和程序的品質。

提示

如果您是解決方案的唯一內容建立者,請考量尋找不同小組的其他內容建立者以檢閱您的解決方案,並相互進行相同的審查。

您可以透過不同方式進行同儕審查。

  • 功能檢閱:功能檢閱著重於解決方案應滿足的功能、程序或商務需求。 在功能檢閱中,檢閱者會使用解決方案,與終端使用者一樣。 這些檢閱者會記錄發現的任何缺陷或問題,以及任何可改善實作的主觀評論。
  • 技術檢閱:技術檢閱著重於解決方案的技術層面,例如資料模型化、程式碼或設計。 在技術檢閱中,檢閱者將評估實作特定功能或變更的方式,並建議替代方法或強調目前方法的潛在缺陷或風險。
  • 提取要求:當您執行原始檔控制時,您會建立提取要求 (PR) 以將您的變更合併至最新版本的解決方案。 技術擁有者會檢閱建議的變更並評估原始程式碼。 此類型的檢閱有助於確保程式碼遵循標準慣例,例如格式化 DAX 或 M 程式碼,或者識別反面模式或潛在問題程式碼。

提示

建議您先執行某種正式同儕審查和核准,變更內容才能夠移至使用者驗收測試。 這是因為品質不佳的內容可能會危害資料解決方案的信任,即使在測試期間亦是如此。 此外,同儕審查也可以為小組成員之間的共同作業和知識分享帶來益處。

完成同儕審查週期之後,您應該記錄並納入任何建議變更。 如有必要,您應該先重新提交變更供核准,然後再移至使用者測試。 一般而言,僅當有多個變更或一些要測試的複雜變更時,才需要多次反覆進行同儕審查。

自動化測試

內容建立者可以自動化測試,以便在部署之前自動執行測試。 自動化測試通常包含預先準備的測試條件,這些條件以程式設計方式執行及協調以回應特定動作,例如儲存內容或提交提取要求 (PR)。 系統會自動儲存自動化測試的結果以供日後參考和記錄使用。

自動化測試的目的在於減少驗證內容變更的時間和工作,同時改善測試一致性和結果可靠性。 當內容的自動化測試失敗時,在內容建立者解決問題之前通常無法部署。

有效的自動化測試是實作 DataOps 的關鍵環節。 DataOps 可讓小組藉由採用可改善和加速傳遞資料和分析的做法來為程序進行自動化和縮放。

重要

若要有效自動化測試,您應該建立設計良好的測試。 建立這類測試可能需要大量時間和精力。 如果您的測試條件和預期定義不明確,則自動化測試將無法驗證內容的正確層面,而自動化這些測試時對您益處不多。

提示

企業內容發佈案例中整合解決方案部署時,自動化測試能提供最多益處。 例如,您可以使用 Azure Pipelines 作為驗證管線的一部分進行自動化測試,以確保內容已準備好部署。 如需詳細資訊,請參閱階段 4:部署內容

下列各節說明自動化測試 Power BI 語意模型和報表的重要考量。

自動化測試語意模型

您可以自動化測試語意模型,即使這通常需要使用第三方工具和架構進行自訂設定。

您可以使用不同的工具和方法來自動化測試語意模型。

  • 最佳做法分析器 (BPA):最佳做法分析器可讓您指定可用於評估語意模型的規格。 您可以使用表格式編輯器來執行 BPA,藉以識別語意模型中是否有任何規則違規。 您可以使用表格式編輯器命令列介面 (CLI) 搭配 Azure DevOps (或作為其他排程程序的一部分),自動化檢查是否有 BPA 規則違規。
  • Fabric 筆記本和語意連結:Fabric 中的筆記本可讓您使用語意連結以透過程式設計方法與語意模型互動。 您可以使用筆記本以執行架構 (例如 Great Expectations (GX)) 以驗證資料。 此外,您也可以評估量值和 DAX 查詢,然後根據已知基準測試結果。
  • Power Automate:Power Automate 可讓您使用 Power BI REST API 以根據語意模型執行查詢和匯出報表。 您可以根據已知基準檢查查詢結果,然後執行下游動作,例如對內容建立者觸發警示。

提示

請考量結合語意模型的自動化測試和協調流程。 例如,您可以使用筆記本或 Power Automate,在重新整理之前,對資料來源和語意模型進行自動化測試。 如果測試失敗,您可以防止重新整理,如此也可防止重新整理錯誤或防止不正確的資料傳入商務報表。

自動化測試報表

提供有限的選項供自動化測試報表。 這些選項依賴外部工具或社群解決方案以自動驗證視覺效果或報表屬性,例如驗證報表中繼資料或模擬使用者與報表的互動。

您可以使用不同的工具和方法以自動化測試報表。

  • 報表最佳做法分析器:提供各種第三方工具以支援最佳做法分析器類似功能,透過檢查報表定義以自動化偵測報表中的問題。 支援此功能的兩個工具為 PBI ExplorerPBI Inspector
  • Power Automate Desktop:使用者介面自動化工具 (例如 Selenium for PythonPower Automate Desktop) 可讓您模擬使用者滑鼠與報表的互動。 透過定義使用者流程,您可以測試瀏覽和互動。 這些測試會在完成流程時通過;在偵測畫面上的特定字詞或影像時失敗 (例如錯誤訊息或空白視覺效果)。

決定使用者應如何驗證內容

內容通過手動測試、自動化測試和同儕審查之後,便可繼續進行使用者測試。 當使用者測試內容時,使用者可以提供主觀意見反應,說明該內容是否符合商務需求並按預期執行,包含傳回準確的結果。

使用者驗證通常會在測試工作區中執行。 當您設定測試工作區時,請考量下列事項。

  • 建立測試應用程式:如果您要使用 Power BI 應用程式發佈內容,請設定測試應用程式以讓測試使用者驗證內容。 測試應用程式應與您在正式執行環境中設定的應用程式相同。 在瀏覽測試應用程式時,請考量包含文件、訓練和意見反應表單的連結。
  • 佈建存取:從社群識別將驗證解決方案的使用者子集。 請連絡這些使用者,並在驗證此內容的時間和原因上達成一致。 然後,請確定您為使用者提供內容的存取權,並將其新增至適當的安全性角色。 與使用者共用內容或測試應用程式的連結,讓使用者能夠開始共用測試。
  • 設定排程重新整理:使用者驗證通常會持續較長的時間。 值得一提的是,在測試工作區中設定資料項目的排程重新整理,能夠讓使用者使用最新的資料進行測試。

重要

當您將內容部署至測試工作區時,必須先手動更新應用程式,使用者才能看到報表和儀表板的變更。

注意

您無法將應用程式從某個工作區部署或複製到另一個工作區。 應用程式的變更必須手動在該工作區的設定中進行。

開使用者驗證之前,您應該進行必要的準備。

  • 規劃進行使用者驗證的時間。
  • 指定使用者驗證是否限於特定期間或反覆程序的一部分。
  • 建立收集意見反應的方法,例如使用 Microsoft Forms
  • 與參與驗證規劃和預期的使用者進行溝通。
  • 組織使用者驗證的啟動作業,引導使用者使用和管理預期。
  • 進行使用者訓練以示範驗證和意見反應程序。

以下是一些協助使用者驗證內容的不同方式。

  • 觀察台測試:觀察台測試是簡短的工作階段,內容使用者可以觀察一或多個使用者在沒有指引或指示下使用內容。 在這些工作階段中,內容建立者會使用其觀察以識別解決方案的潛在缺陷、問題或改善。 這些測試在進行組織時需要很少的時間和精力並僅限於特定功能或解決方案一部分,因此非常有價值。 觀察台測試最有利於取得設計或方法的早期意見反應,例如概念證明 (POC) 的意見反應。
  • 焦點群組測試:焦點群組測試是由一同審查內容的使用者小組所組織有限工作階段。 這些焦點群組策展以選取重要的專案關係人和主題專家,藉以提供特定特性或功能的最佳意見反應。 焦點群組測試可以透過多個互動式工作階段進行。 焦點群組測試需要比觀察台測試更多的時間和精力,但可以提供更詳細的解決方案意見反應。
  • 使用者驗收測試:使用者驗收測試 (UAT) 是正式程序,其中使用者社群的一大群人驗證並提供解決方案的非同步意見反應。 UAT 需要最多時間和精力進行組織,但這是進行使用者測試的最完整方式。 測試使用者接受解決方案且解決意見反應問題之後,內容可以部署至正式執行環境工作區。

決定驗證內容的方式之後,您可以規畫如何將其部署至工作區及在工作區之間部署。

檢查清單 - 規劃驗證內容的方式時,關鍵決策和動作包括:

  • 設定和記錄測試條件:說明您要進行的測試、測試內容和執行測試的方式。
  • 決定同儕審查程序:說明除自身外驗證內容的其他人員。
  • 決定手動測試的方法:決定您將用於驗證所建立內容的工具和功能。
  • 決定是否要使用自動化測試:識別內容的規模和範圍是否合乎所設定的自動化測試。 若是如此,請確定您規劃必要時間和資源以設定和實作這些測試,以便驗證您預期的內容。
  • 將內容從開發工作區部署至測試工作區:將變更從開發工作區部署至測試工作取,讓使用者可以查看變更。 請確保您已在測試工作區中完成必要的部署後活動,例如設定和更新測試應用程式。
  • 決定使用者測試的方法:決定使用者驗證內容的方式。
  • 識別測試使用者:識別驗證內容的使用者社群人員。 針對參與程度和預期,與這些人員達成一致。
  • 收集使用者意見反應:設定工具和程序以自動收集意見反應。 例如,您可以在 Microsoft Teams 或 Microsoft Forms 中使用 Tasks 和 Planner。
  • 記錄測試結果:記錄所有內容驗證的結果,以及測試結果所產生的任何變更。 請確定此文件容易找到。
  • 規劃您的正式執行環境的部署:使用者測試結束之後,準備將內容從測試工作區部署至正式執行環境工作區。

本系列的下一篇文章中,了解如何在管理內容生命週期時部署內容。