How Frontend Teams Tame Financial Loss Risks with Static Scans and UI Test Automation

Introduction

Asset loss (资损) refers to scenarios where a platform causes economic loss that deviates from user or customer expectations, leading to direct or indirect financial impact. As business scale grows, the magnitude of such losses expands, prompting strong emphasis on risk prevention.

Manual Preplay

Before 2019, front‑end teams relied on manual case reviews, risk grading, and rule‑based cultural reinforcement to mitigate loss during major events like Double 11. This involved extensive human effort—e.g., six days of preplay sessions with 73 cases, consuming roughly 200 person‑hours.

Front‑Back Reconciliation

To automate detection of mismatched front‑end displays and back‑end deliveries (e.g., wrong coupon type shown as a red packet), a productized reconciliation system was built with three layers:

Access Layer: Front‑end SDK unified across Web, Weex, and Mini‑App to capture key benefit data.

Data Layer: Real‑time processing via Blink, storing logs in SLS and messages in METAQ, with backend subscription for live reconciliation.

Application Layer: Subscription to reconciliation messages, real‑time alerts, and dashboard monitoring.

However, the SDK introduced integration costs and false alarms due to UI‑level data being unavailable, limiting its effectiveness.

Static Code Scanning

To address code‑level loss risks (e.g., default price values, numeric manipulation, expired copy), an AST‑based static analysis tool was created using Babel. The workflow parses source code into an AST, traverses it with custom visitor plugins, and flags risky patterns.

<code>const fs = require('fs');
const parser = require('@babel/parser');
const traverse = require('@babel/traverse').default;

// custom rule plugin
const visitor = {
  // TODO: add rules
};
const code = fs.readFileSync('your/file');
const ast = parser.parse(code);
traverse(ast, visitor);
</code>

Example rule for detecting direct default price assignment:

<code>const t = require('@babel/types');
const visitor = {
  VariableDeclarator(path) {
    const {id, init} = path.node;
    if (
      t.isIdentifier(id) &&
      isPrice(id.name) &&
      t.isNumericLiteral(init) &&
      init.value > 0
    ) {
      // matched default price assignment
    }
  }
};
</code>

Similar rules handle ES6 destructuring defaults and logical‑OR defaults, enabling automated detection of the majority of price‑related loss bugs.

UI Test Scanning

Since many loss scenarios arise from UI interactions that static analysis cannot capture, a record‑and‑replay UI testing framework was introduced. Developers provide a page URL; a proxy injects a recording script that captures network requests and user actions (touch, scroll). During release, a playback script replays these actions and compares final UI snapshots.

<code>let isPlaying = false;
async function replay() {
  isPlaying = true;
  const {touchQueue = []} = await load('recordData');
  while (isPlaying && touchQueue.length > 0) {
    const item = touchQueue.shift();
    const {action, delayTime, scrollTop} = item;
    await sleep(delayTime);
    setScrollTop(scrollTop);
    if (action !== 'scroll') {
      dispatchEvent(item);
    }
  }
}
</code>

<code>function dispatchEvent(info) {
  const {selector, action, position: {pageX, pageY}} = info;
  const element = document.querySelector(selector);
  if (!element) {
    console.warn(`element with selector ${selector} not found`);
    return;
  }
  const touchObj = new Touch({
    identifier: Date.now(),
    target: element,
    clientX: pageX,
    clientY: pageY,
    pageX,
    pageY,
    radiusX: 2.5,
    radiusY: 2.5,
    rotationAngle: 10,
    force: 0.5,
  });
  const touchEvent = new TouchEvent(action, {
    bubbles: true,
    shiftKey: true,
    cancelable: true,
    touches: [touchObj],
    targetTouches: [touchObj],
    changedTouches: [touchObj],
  });
  element.dispatchEvent(touchEvent);
}
</code>

Snapshot comparison uses SIFT similarity filtering, background removal, OCR extraction, and coordinate‑based text matching to detect UI inconsistencies. Successful cases are shown with matching snapshots; failures highlight divergent areas.

Conclusion and Outlook

The front‑end risk‑prevention workflow now consists of three layers: (1) productized static code scanning, (2) productized UI test scanning, and (3) manual preplay as a fallback. Compared to previous years, manual effort has been reduced while coverage and effectiveness have improved. Future work will target non‑H5 stacks, refine snapshot algorithms, incorporate video‑level comparison, and develop chain‑level operational safeguards.