I am making an classic 2D arcade ball game. There will be 100 levels in this game. And after the 80th level passing the level by doing some arcade stuff will be very difficult.
For example level 100 will be the most difficult level and if I can't pass this level with manual testing (I am not very skillful), how can I know without manual testing if the 100th level can be passed?
(I don't want to make an impossible level. I just want to make a very difficult level.)
My advice would be to test each obstacle independently. Since you are using a level editor, make the best out of it by manually moving the player to the obstacle in the editor and then try it. If you can pass all of the obstacles independently then your level is possible.
If you are not skilled enough you can still ask a friend or another person with more skills to do this task. You can simplify this by adding really regular checkpoint (or similar teleportation system) that you can easily navigate with some debug inputs.
Something I tend to do to test my game is create debug functions like slow motion, invincibility, or infinite ammo to test the features I just created. It could help you test your game even if you are not skilled enough. Of course you have to remove these debug functions before releasing your game haha.
Without knowing more about your game, this is the solutions I see available to you:
Get better at your game, and make sure that you can actually finish the levels by hand.
Game testers tend to become very good with the games they test, so you can find someone to test your levels. They may already be good with the type of game you're making, or they'll become good enough to make sure that the levels are either completable, or too hard.
Build an AI to play your game as a normal player could play. If the AI is not able to finish the level, then your level is not passable or you need to work on your AI more. That's very dependent on your game so this falls out of the scope of this answer. You should ask another much more precise question if you want to attempt that.
Don't manually test these too-hard-for-you levels, release the game and wait your players to complain. You'll know that the levels are too difficult or not passable.
Solutions 1 and 2 will help you decide how to sort your levels in terms of difficulty from a player point of view, while solution 3 could do it from a theoretical point of view.
Solution 4 will bring you low ratings and bad comments on the multiple plays stores where you'll release your game, but it is the fastest and the easiest.
It helps if you understand your game mechanics very well to gain an understanding of what is and is not possible.
For example, knowing the acceleration and maximum speed of your player character tells you if it is theoretically possible to move a certain distance in a certain time. You might not be able to pull it off, but if you do the math, you can calculate that it is possible if the player inputs are accurate within x ms, which you consider within the abilities of the best players.
But theoretical understanding of your game is no replacement for the one most important thing when it comes to understanding a game: get testplayers. Find many testplayers of many different skill levels. When you aren't skilled enough to beat your own game, find someone who is. When you can't find anyone who succeeds even after lots of training, then succeeding might not actually be possible.
You can't find good testplayers? Then you can take the programmer's solution and just program your own. Add a system for controlling the player-character with pre-programmed timed inputs. Then figure out a sequence of inputs which beats a level. This might be a bit tedious, but it really pays off, because now you also have an automated test suit. Whenever you make a code change, run your test suit. If it fails to complete the levels it managed to complete before, you broke something. If it still succeeds, you know your game still plays like it used to. Such automated test suits can be a great time-saver when it comes to finding bugs. For a real world example, check out the video of the test suit for the game Factorio.
