財務團隊如何在不損害安全性的前提下測試安全的使用者流程

在金融應用中，最重要的部分——身份驗證、存取控制和安全工作流程——也是最難測試的部分。

這些並非可選項。它們定義了用戶如何與應用程式互動。

而且它們引入了一些標準測試方法有時無法很好地處理的限制。

安全是使用者體驗的一部分

金融應用程式中的登入流程不僅僅是使用者名稱和密碼。

它可能包括生物特徵認證、多因素認證、會話驗證和設備級檢查。

根據設備、作業系統和環境的不同，這些步驟的執行方式可能會有所不同。

同時，許多應用程式透過企業系統進行分發，並受制於影響其運作方式的策略。

測試需要考慮所有這些因素，而不僅僅是底層功能是否有效。

為什麼團隊簡化測試

在實務中，許多團隊會調整測試方法來應對複雜性。

• 為了加快執行速度，可能會繞過身份驗證。
• 為避免系統不穩定，安全功能可能會被停用。
• 可以使用單獨的建置版本來隔離功能。

這些決定通常是出於實際考慮。它們允許測試在不增加額外開銷的情況下進行。

但它們也會改變應用程式驗證的條件。

大量的測試工作都耗費在調查故障原因上，而不是執行測試本身。當測驗無法反映真實情況時，調查工作就變得更加困難。

託管環境 (MDM) 的作用

經常被忽視的一個領域是在託管環境中進行測試。

許多金融應用程式都是透過行動裝置管理系統（例如 Microsoft Intune 或 VMware Workspace ONE）部署的。這些系統負責執行策略、配置設備和控制存取權限。

這會影響應用程式的運作方式。

例如，可能需要憑證進行身份驗證，功能可能會根據策略受到限制，網路配置可能與標準設定不同。

在脫離此環境的情況下進行測試可能會忽略這些差異。

在許多情況下，測試平台依賴非託管設備，而這些設備無法反映這些限制。因此，僅在託管環境中才會出現的行為在發布前無法得到驗證。

測試加固型應用程式已成為一個真正的限制因素。

金融應用領域中另一個日益常見的挑戰是測試包含運行時保護或混淆的軟體。

這些保護措施旨在防止篡改、逆向工程和未經授權的訪問，在許多金融機構中，這些措施是強制性的。

問題在於它們經常會幹擾測試工具與應用程式的互動方式。

為了解決這個問題，團隊可能會停用保護措施、使用特殊版本或依賴部分驗證。但一旦移除保護措施，應用程式的運作方式就與生產環境中的運作方式截然不同。

這就引入了一種不同的風險，即與安全層相關的問題在發布前從未得到驗證。

隨著越來越多的組織將應用程式加固作為其安全策略的一部分，這正成為測試需要考慮的標準約束之一。

若要深入了解如何在實踐中應對這項挑戰，請參閱以下內容： Digital.ai 以……的方式 自動化測試與應用加固相結合：解決 DevSecOps 困境.

更務實的做法是什麼樣的

更有效的方法是使測試條件與生產條件一致。

• 身份驗證流程在使用時會執行，包括生物識別和多因素身份驗證。
• 應用程式在啟用保護措施的情況下進行測試，而不是依賴修改過的或不安全的版本，因為這些版本無法反映生產環境中的行為。
• 設備配置採用與使用者相同的策略和約束，包括 MDM 控制。
• 測試在各種設備和環境下進行，以捕捉差異性。

這並不一定會增加測試的數量，而是改變了這些測試實際代表的意義。

為什麼這有助於提高決策能力

當測試反映真實情況時，測試結果就更具實用性。

• 故障更容易解釋，因為它們發生在真實的場景中，包括安全流程和受管理的環境。
• 由於已有相關背景資訊，調查時間得以縮短。
• Release 決策可以基於與應用程式在生產環境中的運作情況相符的證據。

提高訊號品質對團隊了解故障和做出發布決策的速度有著直接的影響。

平衡安全性和可測試性

人們通常認為，測試安全應用程式需要權衡取捨。

要么保持安全但限制測試，要么通過減少安全限制來擴大測試。

實際上，這種權衡往往是由工具或環境設定的限製造成的，而不是根本性的限制。

在不損害應用程式完整性的前提下，測試安全、受管理且受保護的應用程式是可能的——但這需要一種能夠考慮到這些應用程式在生產環境中實際運作方式的方法。

???? 已經遇到這些挑戰了嗎？ 與測試專家交談 熟悉周圍環境並考慮下一步。 

???? 不確定你目前的方法是否行得通？ 就拿 移動測試準備測驗.