Store System Refactoring Types, Challenges, and Testing Strategies

1. Business Status

Rapid expansion of offline stores has exposed architectural flaws, hard‑coded role permissions, duplicated functionality across scenarios, and performance bottlenecks in query operations, making further development and maintenance increasingly costly.

2. Store Refactoring Types, Difficulties, and Common Efficiency Measures

Various refactoring approaches are introduced, accompanied by efficiency techniques that significantly shorten testing cycles and accelerate project delivery.

3. Different Refactoring Test Schemes

3.1. Front‑end and Back‑end Refactoring – Business Unchanged Case

Refactoring Purpose: Reduce long query times.

Refactoring Content: Rebuild front‑end filter conditions, redesign database tables with richer time and management dimensions, parallelize data assembly, and remove real‑time data fetching from non‑statistical tables.

Test Objectives: Verify query result correctness, ensure reduced query latency, and maintain high quality.

Test Difficulties: Numerous filter conditions and extensive regression coverage.

Test Plan: Compare new and old interface data, benchmark execution time in a stable sandbox, focus functional testing on front‑end filter changes, and generate comprehensive interface cases.

Test Process: Prepare cases by iterating over each query parameter, perform bulk diff comparisons using a diff platform, and use Whistle for request‑time analysis; failed cases are quickly re‑executed after code fixes.

Overall Effect: Automated case generation and diff testing saved 2 person‑days for developers and 8 person‑days for QA, dramatically shortening the delivery cycle.

3.2. Front‑end and Back‑end Refactoring – Business Changed Case

Refactoring Purpose: Meet diverse operational task requirements, improve task creation, and enable integrated task management.

Refactoring Content: Support multiple task types, migrate reporting logic and database tables, add task feedback and notifications, and ensure compatibility with existing business flows.

Test Objectives: Ensure correct publishing and feedback of new tasks and verify seamless integration with existing processes.

Test Plan: Conduct phased testing for the backend and the "Bear Store Manager" app, reducing overall project time; focus on diffing code during smoke testing, verifying delayed MQ consumption, and functional testing of front‑end features.

Test Process: Early diff of code to clarify task creation implementations, log checks for delayed MQ, and functional tests for front‑end; for legacy flows, map task state transitions and examine boundary conditions.

Overall Effect: Early diff and phased testing saved 3 person‑days for QA and reduced the overall rollout time by 3–4 days.

4. Summary

The two concrete refactoring scenarios illustrate the need to identify the refactoring type, understand technical implementation scope, prepare functional and interface test cases, adopt batch diff, traffic replay, and manual testing methods, handle legacy data compatibility, consider gray‑release strategies, and set up alert mechanisms for result mismatches.