This question is entirely too difficult for any of us to answer in detail. Not too difficult technically, but we can't get detailed in testing because we don't know the ins and outs of your design. You are the subject matter expert. You are the designer of your solution to the problem. Just reading your code won't tell us your intent, not that it matters, because we ALSO wouldn't know if your code actually aligned with your intent. All any of us will be able to give you will be broad comments and general guidelines.
I can tell you how I did testing for my big Navy project. First, I had a dedicated folder on the machine that was my in-house server. The folder was dedicated but the machine was shared with two other in-house projects. In that folder I created four sub-folders. They were DEV (for development), TEST (for testing), STAGING (for final-stage preparations), and PROD (for production). The users mapped to the PROD folder and never saw the other folders. Each folder included its own copy of the front-end file and a copy of the back-end file. (Except STAGING, which usually just used the production BE file.)
Whatever I did, I did to DEV first. Code it up, muck the displays, whatever... but it ONLY happened to DEV. Then when I was ready to actually do formal testing, I copied the FE from DEV to TEST, relinked to the TEST BE, and started testing. I developed a list of things that I always tested and then had the second list of things related only to the latest change. I.e. the list included the "always" tests and the "recent change" tests EVERY TIME. The list of recent work included testing to determine whether working on X broke something on Y that was a related form or sequence of queries. If something WAS broken, it was NEVER fixed in TEST. It was fixed in DEV and the testing process started over again.
Once the tests were complete and I had no more changes to make, I moved the copy from TEST (that was an accurate copy from DEV, because remember I didn't fix TEST, I fixed DEV). The FE went to STAGING. Here is where a split occurred in the procedures.
Most of my changes were either fixes for errors in the code or a query, or they were new features that were code-only or a new form and some code. The BE file was not usually involved in any changes. So in STAGING, I would relink the new version of the FE to the production BE. I would also update the FE's version information so that the startup code would detect whether users would be required to update. (I wasn't able, by Navy regulation, to use the auto-updater - much to my disappointment.) I would launch the STAGING copy to verify that it identified itself correctly and didn't crash. Finally, when the STAGING copy of the FE was good to go, I copied the current PROD FE to a backup folder and then moved the now-relinked FE from STAGING to PROD. Note that since the BE wasn't affected and the only changes were fixes and new features, the BE could stay "up" while all of this was going on behind the scenes. I had an "announcement" feature that would notify users of the new version and I could tell them if the "fixes" were important enough to do an update of the FE. Otherwise, failure to update just meant they didn't get the new features right away.
When the BE had to be updated, it got trickier because I had to have a list of changes to be made based on the PROD BE file. So when I knew that I was going to update the BE, I copied the PROD FE to become the new DEV BE as my starting point. This time the changes had to be made to both the FE and BE, so both of them got moved to TEST. But this time, I had to make a detailed list of changes to be made to the PROD BE file. Some of the changes could be made with DDL; others required DDL followed by an UPDATE query. This is when I needed to take the whole DB down.
Since the BE was linked by name, all I had to do was set up my "DB GOING DOWN" feature that would block people from doing anything during scheduled down time. When it was safe (i.e. no one in the DB), I renamed the BE to a place where I could make the changes necessary for the update. In this "down" period, since the BE was not where it was supposed to be, nobody could use it anyway.
The FE changes were done as described earlier. The BE changes were made in that alternate folder. (You guessed it... STAGING.) When I moved the updated FE and updated BE to PROD, I set up the internal startup checks to recognize that the users were FORCED to do the update by copying the FE file. And the FE file knew where it should NOT be when it was running, so no one was ever able to run the FE directly from PROD. They HAD to make a copy.
That was the logistics of testing. Now, the other part of this: So you have this fancy setup for testing. But WHAT/HOW do you test? The answer is that during your design phase, you made lists of what your DB had to do. You worked towards some performance or operational goal. The tests HAVE to be that your code continues to provide whatever was specified as the design goal. This is where a "design document" becomes INVALUABLE. If you implemented to a given design goal, your test is that you still achieve that goal with your new version. AND - if you are meticulous about it - you have modified the design document to include any new goals.
Now, the sad reality comes in. Entirely too many people don't have the self-discipline (or work-mandated discipline) to do anything but "shoot from the hip" - a USA idiom from our "wild West" days. In modern terms, it is when we do not work in an organized and careful manner. We just "take our best shot" at a target that we might not have defined very well. This comes back to haunt you the MOMENT you have to do any testing. Because if you weren't organized about what you updated, you won't be able to organize or design well-directed testing. Entirely too many people fail to define their goals ahead of time and then find that when it is time to do testing, they are operating in a vacuum.
Which brings us back to the question: How do we do testing? By remembering at the start of the project that you will still have testing to do at the end of the project, and thus making plans not only for the development, but ALSO for the testing of your project creation or update. Good testing starts with good design. Impossible testing is derived from having no design.
