Before going live, use the online experience site to inspect the functionality, which can help identify real problems in advance.
Before going live, use the online demo site to verify the functionality, what can be discovered in advance is not whether the feature exists, but three types of issues that are only exposed during operation: the action path in the background is inconsistent with the team's expectations, the feature has an entry but lacks key configurations to use, and it is impossible to judge the scope of influence of batch operations. AnQiCMS provides an online demo site (demo site) and a background entry for direct login and trial use, and the acceptance should follow the task list, not just click through the menu.
What types of issues is the demo site suitable for verifying?
The first category is the process length. How many times do you need to click when publishing an article, whether categories and tags are on the same screen or split into two places, and whether to manually fill in the address after uploading pictures - these determine the daily operational burden of the editorial department, and only after going through the entire publication action can you know.
The second category is configuration dependency. Many functions are not available in the default state: AI-related capabilities need to fill in service configuration, captcha needs to apply for the site key and fill it into the background, and interface calls need to confirm the authentication method. The experience site can expose what
The third category is boundary behavior. Whether to delete documents to the recycle bin or physical deletion, whether draft links can be accessed externally, and whether the batch import fails in whole or partially stored when an error occurs. These three things are easy to slip by when read once in the document, but they will be remembered after actual verification.
Follow the task list to the backend
Suggest using six tasks instead of 'click everywhere', and each one must be completed in the experience station and record the bottleneck:
Create a new category, create two documents under it, one set as a draft; tag the document and access it once through the tag page; upload an image and confirm that it displays normally on both the list page and the detail page; modify a template and see which front-end section changes; call an AI skill and observe which fields it actually changed; delete a formal document and then restore it from the recycle bin.
These six cover the five aspects of publishing, display, template, intelligent body, and fault tolerance. Each record has three items: completion time, required preliminary configuration, and discrepancies from expectations. The acceptance conclusion should be written in a way that can be directly converted into requirements, 'Not useful' has no value, but 'It takes a few more times to publish when setting the time' has value.
Parts that can't be verified are handed over to the test instance
The positioning of the experience station is to demonstrate functions, it does not bear your data conditions. The following items must be verified in their own test instances:
Data migration. Whether the content imported from the old site will lose fields, whether the external links of pictures can still be displayed, and whether the classification levels can correspond, depends on your historical data structure.
Backup and recovery. AnQiCMS supports the backup and recovery of data and static files, but the recovery time needs to be measured based on your data volume to be effective; the numbers measured elsewhere have no meaning for your disk.
Performance and port occupancy. The default port to listen on is 8001, and the front-end reverse proxy needs to be configured separately; this layer is only exposed in real deployment.
Deployment method run it yourself.
After the function acceptance is passed, the deployment side selects a path that works according to the team environment: the Baota panel can be deployed with one click, the aaPanel environment has corresponding procedures, under LNMP it can be deployed by command, and in the Docker environment, directly pull the anqicms/anqicms image.
The judgment standard is 'whether it can be repeated.' The first deployment was successful but entirely relies on manual recording of steps, and the next time someone else changes, it has to be done again. The sign of passing the acceptance is to write the steps into a script or document, and it can be run again after clearing it on the same machine.
Two acceptance division of labor tables
| Acceptance items | Experience station | Self-built test instance |
|---|---|---|
| Background operation path | Suitable | Not necessary |
| Feature Pre-configuration | Suitable | Suitable |
| Boundary behavior and error tolerance | Suitable | Suitable |
| Historical data migration | Not applicable | it must |
| Backup and recovery time consumption | Not applicable | it must |
| Deployment and reverse proxy | Not applicable | it must |
Common questions
Can performance issues be detected in the trial station?Cannot be used as a basis. The data volume and concurrency conditions of the demonstration environment are different from your site, and you need to conduct capacity tests on your own test instance.
Should everyone in the team go through it?It is recommended that at least three people: editor, template development, and operations, each take on their own role tasks, and the pain points of the three parties are usually completely different.
Where is the back-end entry?Enter the backend address of the experience station by adding /system, the specific demonstration account can be found in the demonstration area of the official documentation, no separate environment needs to be set up for acceptance.