TestHub puts AI case generation and multi-engine automation in one Django platform

One Django application for the whole test workflow

TestHub is described as an AI driven, full stack test management platform covering the complete testing process. The modules named in the introduction are AI requirement analysis and case generation, test case management and review, API testing, Web UI automation, Android app automation, performance testing and a data factory.

The application layer is Django 4.2 with Django REST Framework, and the front end is Vue 3 with Vite and Element Plus, with Pinia for state, Vue Router, Axios, ECharts for charts, Monaco Editor and vue-i18n for internationalisation. MySQL 8.0 is the database, and the API documentation is generated by drf-spectacular, so the backend exposes Swagger and ReDoc.

The Django project is organised as a directory of apps, and the list in the repository root reads like a map of the feature set: users, projects, testcases, testsuites, executions, reports, defects, reviews and versions for the management side, then api_testing, ui_automation, app_automation and perf_testing for the execution engines, then requirement_analysis, assistant, data_factory and llm_judge for the AI and tooling pieces. There is a core app for management commands, variable resolution and notification configuration.

This is a big product, not a library. The licence is GPL 3.0, the homepage is testhub.aisky.cloud, and the author publishes it under a Chinese testing WeChat account.

AI case generation, an assistant and a browser that reads pages

Three separate AI features are described, and they are worth separating because they have different costs and different failure modes.

Requirement analysis takes an uploaded document in PDF, Word or TXT form, extracts the business requirements and generates test cases from them. The assistant is a Dify integration that answers testing questions. And the AI smart mode is described as browser-use based intelligent browser automation, where the AI understands a page and completes the test itself, in either a text mode or a visual mode.

The model support is broad. DeepSeek, Qwen, SiliconFlow, OpenAI, Anthropic and Google Gemini are all named, and the configuration section says the API keys, base URLs and model parameters for each provider are managed in a unified configuration centre, with settings assignable per role, and roles covering case authoring, case review and Browser Use, plus a connection test for each.

The pinned dependency list backs this up. It includes browser-use 0.10.1, langchain-openai 1.1.6, the openai 2.14.0 client, anthropic 0.75.0, google-genai 1.56.0, groq 1.0.0, ollama 0.6.1, langchain-core 1.2.6 and mcp 1.25.0.

The consequence is that the platform is only as good as the provider you point it at, and each role can point somewhere different. That is a feature for a team with a policy, and a source of surprising output variance for a team without one.

Selenium and Playwright side by side, with an AI mode on top

The Web automation module supports two engines, Selenium and Playwright, across Chrome, Firefox and Edge. On top of the engines there is an element library with several locator strategies, a page object model pattern, a visual script editor, batch execution of test suites, and execution logs, screenshots and video recording.

Scheduling is done three ways: Cron expressions, a fixed interval, and a single run. The scheduling runs through APScheduler, and the run_all_scheduled_tasks management command starts the scheduler as a separate process from the web server.

The AI smart mode sits alongside the scripted mode rather than replacing it. The description is that the AI understands the page structure and completes the test task automatically, which is the browser-use integration. A team that wants deterministic selectors uses the element library, and a team that wants exploratory coverage uses the AI mode, and the platform lets both exist in the same project.

The practical risk is in the scripted path rather than the AI one. Locator strategies are the part that rots when a site changes, and a platform that stores locators centrally at least gives you one place to fix them.

Android automation runs on Airtest image recognition

The Android module is built on Airtest and image recognition rather than on the uiautomator view hierarchy, which changes the engineering model. Elements are managed as images, coordinates and regions, and the documentation mentions multi resolution adaptation, so a script written against one device screen is expected to survive a different pixel density.

It supports both local emulators and remote devices, and it locks a device during a run to avoid two jobs fighting over the same screen. Cases are composed as components plus UI Flow sequences, and there is a variable system with global, local and outputs scopes.

Execution is asynchronous through Celery, results are reported through Allure, and progress is tracked live over WebSocket. That combination is why Redis is listed as a dependency for this module specifically, and why Daphne is needed instead of the plain Django development server.

The image based approach is the trade to weigh. It is more resilient to a build that ships a canvas instead of native views, and it is far more sensitive to theme changes, animations and font differences than a selector based framework would be.

API, performance and the data factory

The API module covers HTTP and WebSocket, organised as tree collections, with environment variables and variable substitution. Test suites run in batch, with assertions and execution order configuration, request history, scheduled tasks that notify by email or webhook, and Allure reports. The v0.2.2 release note records that curl import was added to the interface tests, along with reference to the data factory and a function helper.

The performance module is Locust based, with task management, execution and metric reporting. The data factory is a set of more than 50 utilities for string handling, encoding conversion, random data, encryption and decryption, test data generation, JSON handling and Crontab expressions. Tagged data can be referenced directly from API tests and UI tests, and the use history is tracked.

The unified configuration centre, the single place where model providers, the UI execution engine, the browser, headless mode and notification channels are set, is what makes the modules feel like one product. It is also the place to look first when two people get different results from the same suite.

On the security side, authentication uses JWT with a two token mechanism, automatic refresh, a logout blacklist and replay protection, implemented with rest_framework_simplejwt and a token blacklist. The requirements pin djangorestframework_simplejwt 5.5.1 and cryptography 41.0.7.

Setting up the stack takes more than a pip install

The environment requirements are listed up front, and they are the reason this project is more than a Django app. Python 3.12 is recommended, with the note that other versions may have compatibility problems. Node.js 18 or newer is needed for the front end build. MySQL 8.0 or newer is required. Java 17 or newer is optional and only for Allure report generation. Redis 6.0 or newer is optional and needed for the Android automation WebSocket and for Celery. Browser drivers for Chrome and Firefox are needed for UI automation, and there is a management command that can download them.

The database step is explicit about the character set:

mysql -u root -p -e "CREATE DATABASE testhub CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
python manage.py makemigrations
python manage.py migrate
python manage.py createsuperuser

Two optional initialisation commands seed module data, the locator strategies for UI automation and the component pack for Android automation:

python manage.py init_locator_strategies
python manage.py load_component_pack

Without those two commands, the automation modules start with empty libraries, which is a confusing first hour if you do not read the documentation centre.

Four processes, one application

Running the platform means choosing which processes to start, and the README lists them separately.

The plain development server is HTTP only. For the Android module you need Daphne instead, which serves the ASGI application:

python manage.py runserver
daphne -b 0.0.0.0 -p 8000 backend.asgi:application
python manage.py run_all_scheduled_tasks
celery -A backend worker -l info

The front end is a separate npm project with a dev and a build script, and the four URLs to remember are the front end on port 3000, the backend API on port 8000, the API documentation at /api/docs/ and the Django admin at /admin/.

Docker is offered as an optional path with a build and push script and a compose file that starts the full stack. The environment template carries the Docker registry and namespace variables, the front end and backend ports, and the internal MySQL port, so the same .env drives both the containerised and the manual path.

Running four processes is the operational cost of the feature set, and it is the first thing to budget for.

Configuration surface, release history and licence

Everything is configured in.env, following the.env.example template. The database keys are DB_NAME, DB_USER, DB_PASSWORD, DB_HOST and DB_PORT, the Redis key is REDIS_URL, and there are separate blocks for the Docker image settings, the Django secret key and debug flag, the CORS and CSRF origins, the cookie security flags, and Aliyun SMS credentials for phone number registration.

The example values are placeholders, and some of them are wrong for production on purpose. DEBUG is True, SECRET_KEY is a placeholder, ALLOWED_HOSTS is a wildcard and the secure cookie flags are False. The comments next to each of them say what to change in production, which is a reasonable default for a template, but it does mean the file has to be edited before the application faces anything but a laptop.

On releases, version v0.4.0 from 2026-05-28 added test case management, phone number registration and H5 adaptation, V0.3.2 from 2026-03-08 added app automation and fixed the inaccurate AI sub task status marking, and v0.2.2 from 2026-02-09 added curl import and the data factory reference. The repository is not archived and the last push was on 2026-10-22, so development continues after the last tag.

The GPL 3.0 licence is the important legal detail for a test platform, because it governs what you may do with a modified version you host internally. This page offers no reading of it, and that question belongs with your own counsel.

Editorial conclusion

TestHub suits a test team that wants one web application for case management, review, API, Web, Android and performance work, and that is willing to run MySQL, Redis, browser drivers and several worker processes to keep it alive. It is a poor fit for a small team that only needs API scripting, or for a regulated environment where the AI modules and outbound model calls are not acceptable. Before adopting it, install the pinned requirements on Python 3.12, create the MySQL database with utf8mb4, seed the module data with the two management commands, and check which model provider each role is pointed at in the unified configuration centre.

Frequently asked questions

Official sources

1. chenjigang4167/testhub_platform on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases