perf Profiler for GNU / Linux with performance calculation. https://perf.wiki.kernel.org/index.php/Main_Page
gdb GNU debugger that allows you to "spy" what is happening inside the program during its execution. https://www.gnu.org/software/gdb/
flame graph A graphical profiler. http://www.brendangregg.com/flamegraphs.html
strace Used to diagnose and debug programs under GNU / Linux https://strace.io/
There at at least three options:
If you have possibility to change values in that list by making something in the application just try it
If not - perhaps you have possibility to add something to the list
If not - maybe you have to the database and can change the data
If not - ask someone - maybe administrator can make some changes in database for a short time - just to make some test.
Take into account that changing in application and in database may not look the same - when you change in application everything should work, changing in database may require some other actions (triggers, procedures) or time (some things may be refreshed during night or in other schedule).
UAT, ime, should include the complete steps that the actual end user of the app would perform according to your scenarios, from start to finish, and also including expected and actual results in the tcs, e.g.
step 1. open browser/browser is launched, step 2. go to www.blah.com/blah.com is loaded, step 3. click on login field (if you need to get specific) and enter username/field is selected and username is entered.....all the way to the end path you need to test.
You should have performed your functional tests before running UAT cases so you don't necessarily have to validate each field in UAT tcs but make sure you or your team is smoke/functional testing before UAT.
I also agree with the previous poster regarding splitting up your test cases into specific parts which of course depends on what you're doing exactly. TC1_Navigate to Page TC2_Login TC3 Fill PersonalInfo(Or by form section) TC4_Fill IncomeInfo...blahblah.
For each tc after the first one, you can continue from the last tc's step, you don't have to start each test case after #1 from "open browser", and include all the tests together as one test set which will be comprised of the multiple testcases.
In my opinion: A test scenario is functionality that can be tested. Something that the user may want to do with your system and you want to verify. A scenario can have one or more test case. A test case is a formal definition of a test. It defines prerequisites, an action, and the expected result. A test suite is a set of test cases which are logically connected. Eg: test cases which test the same functionality of an app. A test plan is plan how you want to execute your tests to reach your desired test coverage. It's a project document and deals with questions like: which suites should be run in all development iterations. Which should be run on releases. Who is responsible for functional testing, who is for non-functional tests. What kind of resources are needed. When will be the different tests executed...