在金融科技領域,軟件質量是業務穩定運行和客户信任的基石。隨着數字化轉型的加速,金融機構對軟件的依賴程度日益加深,傳統軟件測試方法的侷限性愈發凸顯,效率低下、覆蓋率不足等問題嚴重製約着業務的快速迭代與創新發展。而 AI 測試技術的興起,正為金融科技行業帶來一場質量保障的變革。 傳統軟件測試面臨諸多挑戰。手動測試耗費大量人力與時間,在金融業務快速發展、軟件頻繁更新的當下,難以跟上節奏。自動化測試雖有進
一、背景 在日常工作中,常需要通過各項數據指標,確保驅動版本項目進展正常推進,並通過各種形式報表數據,日常總結日報、週會進展、季度進行總結輸出歸因,分析數據變化原因,做出對應決策變化,優化運營方式,目前在梳理整理校準分析數據需要大量的時間投入、結合整體目標及當前進展,分析問題優化的後續規劃。 常見形式 人工收集 數據來源依賴於各系統平台頁面,通過人工收集校準後填寫再通過表格公式計算,或者可以通過多
大家好,我是陳哥。 有讀者留言説,他們團隊老是因為反覆出現同類Bug導致項目延期。 他們團隊沒有統一 Bug 記錄渠道,測試人員一般發現問題口頭告知或者彙總文檔發給開發。開發未記錄,有時候,迭代時就會出現開發遺忘修復的情況,同類 Bug 再次出現,導致項目二次延期。 我們都知道要重視Bug管理,但有效的Bug管理核心不僅是管Bug,更是管流程。換言之,就是用標準化流程把Bug從發現到解決的每個環節
在金融行業數字化轉型的浪潮中,軟件質量保障正經歷着一場深刻的變革。當測試工程師開始與 AI 智能體對話,傳統的測試模式正在被顛覆,一場靜悄悄的生產力革命已然開啓。 《AI4SE 行業現狀調查報告(2024 年度)》顯示,約 65.75% 的企業處於 L2(部分智能化)至 L4(高度智能化)階段,但僅 8.98% 達到高度智能化水平,這表明 AI 與軟件工程的融合仍處於規模化落地初期。然而,AI 測
大廠戰略直指AI 今年4 月底,阿里雲發佈了一則看似“業務調整”的公告,卻在軟件測試行業投下了一枚重磅信號:移動測試產品將逐步退市,直至 2026 年 6 月 1 日徹底關停。公告寫得剋制冷靜,但含義不容忽視——在移動測試這一細分領域,阿里選擇了抽身而退。這不僅是單一產品的下線,更是互聯網巨頭戰略收縮的真實寫照。 對阿里而言,關停移動測試並非權宜之計,而是深思熟慮的戰略選擇。 2
大家好,我是陳哥。 最近,看到後台有讀者問: 時間緊張導致測試不充分,這是一個高頻難題。不少團隊遇到這種情況時,要麼盲目壓縮測試範圍導致核心問題漏測,要麼硬扛時間壓力全面測試結果處處不精。 項目管理上有一種思維叫優先級思維,就是一種根據重要性和緊急性來排序事物、指導我們如何進行選擇的思維模式。 我們同樣可以把優先級思維應用到測試上,把有限時間聚焦在高風險高價值的測試點上,用精準測試替代全面
Hey,測試社區的小夥伴們!你是否感覺自己寫了多年的自動化腳本,在面對金融行業那套日益複雜的微服務、雲原生架構時,突然變得步履維艱?從移動銀行到證券交易,金融業務的快速迭代和對極致穩定性、鋼鐵安全的要求,已經將傳統的基於Selenium/Appium的測試模式逼入絕境。 為什麼?因為金融軟件天生自帶“三高”光環: 高併發: 想象一下“雙十一”或證券開盤瞬間,系統需要瞬時承受百萬甚至千萬級的交
大家好,我是陳哥。 今天,我邀請了禪道專欄作者劉軍,和我們分享一下移動應用APP開發如何搭建自動化測試框架。 希望通過這些實操經驗能給大家帶來新的啓發。 現在做移動應用開發,大家應該都深有感觸:版本不僅要快,質量還得高,這兩頭真是難兼顧。 我們團隊之前就吃了不少苦頭,發版慢、需求老變、測試時間總被壓縮,搞得團隊挺被動。 作為資深測試與研發效能IT老兵,今天我想結合自己負責的安卓APP自動化測試框
本應用基於ThinkPHP的MVC(模型-試圖-控制器)的方式來組織。在新建頁面時必須遵循該設計模式。 以下以移動端首頁為例,新建頁面步驟: 移動端首頁文件路徑: application->wap->view->first->index->index.html 模板渲染: application->wap->controller->Index.php->index() index
公司項目需要連接2個MySQL數據庫 背景介紹: 公司項目是基於fastadmin 1.4.0.20230711 開發的,裏面用到的thinkphp版本是5.0.25,項目涉及到小程序端和設備端,之前做的是兩個項目,但是部署在同一台服務器上,分別對應兩個數據庫,之前兩個項目之間的交互是通過互相調用對方接口的方式實現的,優化的時候就想通過在一個項目中連接兩個MySQL數據庫的方式,避免互相調用帶來的
在 ThinkPHP(以 5.x 為例)中引入並使用 Monolog(一款功能強大的 PHP 日誌庫),可以實現更靈活的日誌處理(如多渠道輸出、按級別拆分、格式化等)。以下是具體步驟: 一、安裝 Monolog 通過 Composer 安裝 Monolog 依賴: composer require monolog/monolog 二、封裝 Monolog 工具類 為了在 ThinkPHP 中方便
在 ThinkPHP 中,Hook(鈎子)是實現插件機制和行為擴展的核心機制,它允許開發者在不修改框架的核心代碼的情況下, 通過監聽特定事件標籤的方式實現在框架或應用的特定執行節點插入自定義邏輯,從而實現了 "面向切面編程"(AOP)的思想。 Hook的基本概念 Hook是一種事件驅動的編程模式,允許在特定的執行點觸發自定義行為。ThinkPHP中的Hook機制基於行為擴展,可以在系統運行過程中動
之前,何同學的視頻在網上活了一陣子。引發了我們思考:5G將會給我們帶來什麼。同時也回顧了4G乃至3G時代已經給我們帶來了哪些新的變革。最近,一個問題總是時不時的冒出我的腦海:前端性能優化時候還有必要? 回顧前端性能優化 然後我找到了 雅虎軍規 的 35 條 儘量減少 HTTP 請求個數——須權衡 使用 CDN(內容分發網絡) 為文件頭指定 Expires 或 Cache-Con
所謂web,即使你我素未謀面,便知志趣相投;足不出户,亦知世界之大。 最近收到一個用户提的需求場景,當JavaScript發生異常錯誤時,如果我們能記錄出錯前鼠標點擊、頁面跳轉、網絡請求,控制枱打印等信息,這樣我們便能更快速的帶您重返"失事"現場。我覺得這個想法挺好的,那就加入我們的前端監控試試呢?我實現了一套目前的解決方案:一鍵還原出錯代碼和出錯場景還原。如果你們有更好的解決方案,一定要聯繫我
所謂web,即使你我素未謀面,便知志趣相投;足不出户,亦知世界之大。 01 - 什麼是閾值報警功能 在我們前端監控系統中,雖然我們收集了用户實時訪問應用數據信息,並提供可視化界面方便用户查詢,但是作為一款監控系統,卻少了靈魂的東西,那就是自動報警功能,因為我們並不喜歡,也沒人願意時時刻刻查看監控系統。因此,我們需要自動報警。 那自動報警怎麼做呢?自動報警意味着我們事先定義好一系列規
十年磨一劍 過去十年移動互聯網的高速發展,跟日常生活息息相關的如購物、娛樂、辦公等紛紛在移動化。移動端的產品交付,怎樣才能應對激烈的競爭呢?如何在保證質量,如何提升研試效率?如何在產品上線後及時獲悉異常,及時修復呢? UC研發效能在多年摸索建設中,沉澱出一套完善的交付體系,其中尤為關鍵的質效保障環節,是靠着兩款產品在保障的——巖鼠雲設備平台、嶽鷹應用全景監控平台。 從17年開始這兩款產品已經走出U
本文首發於知乎《10分鐘徹底搞懂前端頁面性能監控》,搬運轉載請註明出處,否則追究版權責任。 前言 前端頁面性能是一個非常核心的用户體驗指標。本文介紹阿里UC 嶽鷹全景監控平台 如何設計一個通用、低侵入性、自動上報的頁面性能監控方案。主要採用的是Navigation Timing API以及sendBeacon等方法。 為什麼要監控頁面性能? 一個頁面性能差的話會大大影響用户體驗。用户打開頁面等待的
不可不知的 WEB 前端網站優化—— 雅虎 34 條軍規 不得不説現在依然適用於大部分的網站 當年雅虎推薦了一套優化網站加載速度的34條法則(包括Yslow規則22條),以下是詳細説明。 1. Minimize HTTP Requests 減少 HTTP 請求 圖片、css、script、flash 等等這些都會增加 http 請求數,減少這些元素的數量就能減少響應時間。把多個JS、CSS在可能
原文地址:https://github.com/ruizhengyu... 作為前端新人,我們常以菜鳥自居,主要是專業程度不高,還有就是自謙。其實,作為菜鳥的我們也想撕掉這類標籤,我們也努力,可還是學不好前端,是真的不適合做這行還是方法不對,沒人告訴我們?如果你覺得自己還處在菜鳥階段的迷茫區,那可以看看本篇文章,希望看完之後你能得到想要的。如果你要闡述你的想法,請在評論區留下你的文字。
關於夢迴前端 每天一個重要的知識點,以問答的形式進行反推,利用碎片時間來完成自我提升 Day1 數據類型篇 説在前面 JS是典型的弱類型(動態)語言, 意味着你不用提前聲明變量的類型,在程序運行過程中,類型會被自動確定, 也意味着你可以使用同一個變量保存不同類型的數據 請簡述Js中有哪些數據類型? Js中每一個值都屬於某一種數據類型, 根據最新的語言標準,一共有8種類型 Boolean N
Github鏈接:Nemo Metrics 輕量性能採集系統 Nemo近一年以來做了不少h5活動,,積累了不少優化開發流程經驗以及優化用户加載與性能經驗。 但是每次覆盤轉化率都不高,我們不希望任何用户流失。 用户為什麼會離開,是不是頁面報錯了? 是不是某些地區解析DNS,服務器資源/CDN資源加載慢? 大部分用户打開我們的網頁都在哪些時間區間(哪些國家/地區,哪些版本,哪些手機的用户打開用
引言 在平時工作中可能會遇到用户反饋:“哥們,你們的網站感覺很卡啊!”。這種來自用户的吐槽對前端同學可以説是直擊心靈的衝擊。此時就應該好好想想如何讓用户不再出現這樣的吐槽呢。首先就是指標化的瞭解自己的網站。 常用的衡量指標 可以結合兩張圖 第一張圖是瀏覽器加載整個頁面的時間線,第二張圖則是這個是Google力推的指標,主要從4個視覺反饋階段來描述頁面性能。 總結一下常用的性能指標
前言 計算機網絡對於程序員的重要性,想必不用多提~最近在梳理這方面的知識,由點成面,需要一個過程。 梳理了幾個點,借鑑了很多大佬的文章。(站在巨人的肩膀上!) 發出來大家一起學習進步一哈~之後會陸續梳理更新。 啊~枯燥的計算機網絡! 我用 nodejs 對下面的其中幾個點做了簡單的實踐,進一步驗證原理,加深印象和理解。 HTTP/2 帶來了什麼 HTTPS 連接到底發生了什麼 什麼是中間人攻擊
總體原則:極簡、極快、解耦 主要適用範圍:vue 單頁項目+ 文件組織規範 文件結構 原則:文件少、層級淺、資源集中、相對獨立互不影響 基本結構: . |_ node_modules |_ dist |_ src |_ assets // 公共資源 |_ img // 全局圖片 |- favicon.png |- comm