AVL Code
All cases
#001 · R&D & Testing

Case study · R&D & Testing

NetAdmin Console Compatibility Analysis

You are a test engineer deciding whether NetAdmin can cover a Win7–Win11 deployment, and all you have is an install directory and a test guide. Work through this article and you will walk away with: a complete feature inventory, a UI automation test space where every PASS carries evidence (93 cases in the end), a Win7 SP1–Win11 comparison table for system tools and commands, and two HTML reports ready to archive.

NetAdmin 2.0.1.4 · C++/Pure Win32· Windows 7 SP1–Win11· pywinauto UI automation + live API testing· 93 cases · full system-tool comparison· Landi N2.5

View session Download session archive Import into your AVL Code workspace to replay the full conversation View live result

Session replays & reports are original records in Simplified Chinese · Built with AVL Code + the Landi model

Overview

  1. 01

    Know the target — stack identification + inventory of 77 built-in tools

    You hand netadmin.exe from the install directory to AVL Code and ask what it is written in — that decides which tools to test with later.

  2. 02

    Probe feasibility — pywinauto opens up UI automation

    You ask whether UI automation testing is possible; install the library, attach to the window, exercise the controls, and get the first batch of test scripts.

  3. 03

    Build the test space — first round of 78 cases + HTML report

    You ask for a complete feature list and a dedicated test space; the scripts land and produce the first report, with one permission-preset error fixed along the way.

  4. 04

    Nail down the criteria — every PASS carries evidence

    You keep correcting course: alerts need details, a successful click is not a PASS, add real AI API call cases; the case count iterates up to 101.

  5. 05

    Self-check regression + full comparison — 93 cases and the compatibility map

    You ask it to audit its own invalid cases and run a full regression (92 pass, 1 warning), then verify system-tool dependencies per OS into an HTML report.

Task for AVL Code

I have already enabled unlimited mode for you. Analyze the file 工作区\网管之手-2.0.1.4-测试版-精简\netadmin.exe and tell me what language and framework it is written in

Prerequisites: AVL Code is logged in; the program under test and 测试指南.txt are in the workspace; UI automation needs a graphical desktop session (the session live-tested that mouse operations fail when there is no active desktop — switch to keyboard input / a subprocess)

Reproduction materials at the end of this article Try it yourself ↓

Identify the Tech Stack

The biggest waste in compatibility testing is testing the wrong target. You start from the question every tester asks first:

You type → AVL Code 
I have already enabled unlimited mode for you. Analyze the file 工作区\网管之手-2.0.1.4-测试版-精简\netadmin.exe and tell me what language and framework it is written in
AVL Code runs → you see
Locates netadmin.exe (538,528 bytes) → works around Chinese-path pitfalls and completes basic probing
→ PE parsing: x86-64 PE32+ · Windows GUI · C++ compiled with MSVC
→ Import table: pure Win32 API (no MFC/Qt/.NET), linked against WINHTTP / CRYPT32(DPAPI) / COMCTL32
→ Strings: AI config fields (aiBaseUrl/aiModel/localModel) + embedded tool JSON (77 built-in tools)
→ Also probes netadmin-core.exe (same stack, does not link WINHTTP/CRYPT32) → delivers the identification verdict

Feasibility Check

Target identified, you go straight to feasibility — it first assesses the constraints, then verifies hands-on:

You type → AVL Code 
Can you do UI automation testing on netadmin.exe and netadmin-core.exe?
AVL Code runs → you see
First assesses constraints: a Win32 GUI needs a desktop environment → live-testing confirms an active desktop session exists
→ Installs pywinauto and attaches to netadmin.exe, reading the full control tree
→ Live tests pass: minimize/restore, bring-to-front/focus and close all work; 4 tabs, a 77-root-item TreeView, search filtering and the embedded terminal are all usable
→ netadmin-core.exe passes the same way
→ Delivers test_ui.py / test_advanced.py / test_core.py

Build the Test Space

Next you assign two things: produce a complete feature list, and build a long-lived automation test space for NetAdmin:

You type → AVL Code 
1. Create an automation test space for NetAdmin (网管之手) in the workspace, dedicated to storing all files for testing it;
2. Write automation test scripts based on the complete feature list you gathered;
3. After testing, produce a test report in HTML format;
4. From now on, all test scripts, test data, test reports and other files related to NetAdmin go into this automation test space.
AVL Code runs → you see
Reads the test guide + diffs the two versions → compiles a feature list of 8 major modules
(You correct it: requiresAdmin means the tool itself triggers a UAC prompt at launch, while the program itself runs with normal privileges → the feature list is fixed per the guide)
→ Creates the "NetAdmin automation test space" + writes 8 module scripts and a master controller
→ Self-heals a chain of environment issues during the run
→ First round: 78 cases — 76 pass (97.4%) · 2 warnings · 1 min 24 s elapsed
→ Generates the HTML test report

Nail Down the Criteria

You zero in on a warning in the report that has no details, then nail the criteria down one by one:

You type → AVL Code 
In the test report, the case "Embedded terminal 4.4 Terminal menu" raised a warning, but there are no details explaining what happened
AVL Code runs → you see
Locates case 4.4: after clicking the "Terminal" menu the main window gets covered by an overlay, and ESC sent to a non-interactive window throws an exception
→ Root cause: the except block only logs str(e) (an empty string), so the WARN has no details
→ Fix: send ESC to the menu itself + add detailed logging → re-runs module 4 alone to confirm the fix works
You type → AVL Code 
If the Helper menu exists and was clicked successfully but the corresponding program does not pop up, it must not be recorded as a PASS — you need to make that judgment and ensure every test result is real and valid. For example: after clicking a menu item, wait for its program to pop up, confirm the program launched successfully and matches the menu item, then close it before testing the next menu item.
Testing is serious, rigorous work — we need to make sure every test result is real and valid
AVL Code runs → you see
First writes an exploratory script to live-test the "Helper" menu: clicking it does not pop a submenu — instead the main window switches to the Helper view — so the earlier "click succeeded" PASS was an invalid verdict
→ Rewrites module 6 accordingly: 4 → 11 cases, each with UI verification
→ Full re-run: all 83 cases pass

Self-Check and Regression

The case count has grown to 101, and you turn around and ask it to audit itself — this step exposes the most problems:

You type → AVL Code 
Check for yourself whether there are any wrong, missing or invalid test cases, and whether the current test scripts have all been revised to meet the following requirement: …… (full text of one correction request attached)
AVL Code runs → you see
Reviews every script line by line → reports 7 classes of problems (recording PASS after clicking a menu without verifying the effect, launching a tool without closing it, etc.)
→ Hits an environment limit while fixing (the no-active-desktop mouse error) → switches to keyboard navigation + a subprocess approach to get around it
→ Each module verified by running it individually
You type → AVL Code 
Now run a complete round of UI automation testing against both netadmin.exe and netadmin-core.exe
AVL Code runs → you see
The master controller times out on synchronous execution → switches to background running with polling to collect results
→ Fixes 3 issues along the way: control coverage, API rate-limit backoff, context-menu enumeration
→ Final: 93 cases — 92 pass · 0 fail · 1 warning (98.9%, the only WARN annotated with its cause)
→ Archives the HTML test report

System-Tool Comparison

The deployment decision asks a different question: are the system tools and commands it calls present on every target machine?

You type → AVL Code 
This tool calls many of the operating system’s own tools and commands. Compare for me whether all of these tools and commands are present on Win7 SP1 through Win11, and show me the results as a table
AVL Code runs → you see
Extracts the tools/commands the scripts actually call + reads out the 77 tool items → compiles the comparison list
→ Verifies per system: Win7 SP1 / Win8/8.1 / Win10 1507–22H2 / Win11 21H2–24H2
→ Where the gaps fall: lusrmgr.msc, write.exe, telnet, dism, gpedit etc. limited by version or Home edition
→ Conclusion: 42 items available on every system · 5 items version-limited · 8 incompatibility risk points (with suggested measures)
You type → AVL Code 
Organize these results into a report — give it to me in HTML format
AVL Code runs → you see
Generates NetAdmin_工具兼容性报告_Win7-Win11.html
→ Sectioned comparison tables + key-difference summary + 8 risk points with suggested measures
→ Verifies the file was written correctly before delivery

Try it yourself

Download the session and import it into your workspace to replay the full process, or paste the prompts below in order (swapping in your own target software):

View session Download session archive Import into your AVL Code workspace to replay the full conversation View live result 
› Analyze what language and framework <the program under test> is written in
› Can you do UI automation testing on <program A> and <program B>?
› Gather the features of both programs, read <the test guide>, and form a complete feature list
› Create an automation test space for <the software under test> in the workspace, write automation test scripts based on the feature list, and produce an HTML test report when testing finishes
› Self-check for wrong, missing or invalid test cases and make sure every test result is real and valid (wait for the popup after clicking, confirm it matches, then close it)
› Run a complete round of UI automation testing against both programs
› Compare whether the system tools and commands it calls are all present across <the system range>, and show the results as a table
› Organize these results into a report — give it to me in HTML format
  • API keys in the session have been redacted; 78→83→101 cases are intermediate numbers during iteration — the final regression result of 93 cases is authoritative. UI automation needs a graphical desktop session — the session live-tested that mouse operations fail when there is no active desktop; following the session’s own self-healing, switch to keyboard navigation and taskkill.

Next question: How do you wire this test space into CI so it regresses automatically before every release?