There are a couple different options I can think of, depending on how you want to organize your testing. Hopefully someone else can chime in with their own experience.

Option 1 (this is the one I primarily use for testing)

If your app is on a website or has a site/database backing it, one option is to create a staging site (usually a subdomain) which is effectively a 2nd copy of your entire app but with the new code you're testing. You then redirect your test users to the staging site instead of the main one. Using this method you would need to have some sort of flag indicating which users are part of the testing group. You would be able to use the same API client/secrets for both sites since you're managing the redirect on the backend. If you have webhooks enabled you would need to do the same, redirect the webhook to your staging site for users in the test group.

Option 2

Create a new app in Strava. This would require a second Strava account and you'd have to go through the app approval process for it. You would then treat the test group completely separately using your second app client/secret. The benefit of this approach is that you can completely separate the two, but it comes at a high cost of managing 2 apps, having users sign in/authorize a second app, etc...

Option 3

Create a flag or define for the new features. Wrap the new features with an if/else block so that users in the testing group see the new functionality and everyone else sees the old/existing functionality. This can be difficult and messy if you have database or other backend changes so I wouldn't recommend it for large changes. It's very useful if you're testing an isolated new feature or some simple A/B testing for something like UI changes.