You need to review the product increment. From what I understand from your question, it seems to me that you are mostly reviewing the work that you did to build the actual increment.

If you want to track the work, acceptance testing or integration testing should be tasks associated with a User Story. You might also have a task for development, for code review, for deploy, etc. Are you going to discuss these too at the review? Maybe the developer that did the code review should bring up a presentation slide with how many bugs she found, or maybe show a "thumbs up" or "thumbs down" image depending on the quality of the code? I'm sarcastic of course, just to drive the point further home. Such activities are unimportant for stakeholders. Of course developments should be done, code reviews performed, the work tested, integrated, deployed, etc. No need to say anything about that unless it's relevant in some way (maybe you faced some problems and the way you solved it is important or innovative, maybe you might need some decisions taken about changing the approach, or whatever).

So focus on the product increment.

As for people being left out, what the other posted answer mentions is correct: this is a non-issue. In one of my teams we had a rule that each developer should present the User Stories they worked on, just to give a further sense of accomplishment for the work, to make people more responsible, to also help them gain presentation skills, boost their confidence, etc. But more people worked on the same User Story: testers, reviewers, other developers pairing with the one doing the presentation at the review. So inevitably people were left out. They didn't mind. No harm done. But what happened and was doing harm was that a lot of time was wasted at the review meeting while people moved around the room to sit at the computer to present their own work. But we inspected and adapted. We eventually had the Product Owner present all the stories :).

So inspect and adapt. Bring this up at the Sprint Retrospective. Don't waste time trying to convince management to limit the reviews to just the product increment. They didn't ask for that. The team decided to do so. So discuss it and work it out with your team.

You need to review the product increment. From what I understand from your question, it seems to me that you are mostly reviewing the work that you did to build the actual increment.

If you want to track the work, acceptance testing or integration testing should be tasks associated with a User Story. You might also have a task for development, for code review, for deploy, etc. Are you going to discuss these too at the review? Maybe the developer that did the code review should bring up a presentation slide with how many bugs she found, or maybe show a "thumbs up" or "thumbs down" image depending on the quality of the code? I'm sarcastic of course, just to drive the point further home. Such activities are unimportant for stakeholders. Of course developments should be done, code reviews performed, the work tested, integrated, deployed, etc. No need to say anything about that unless it's relevant in some way (maybe you faced some problems and the way you solved it is important or innovative, maybe you might need some decisions taken about changing the approach, or whatever).

If such unimportant presentations end up filling the full review meeting, and there is no more time to actually inspect the product increment, then you have an even bigger problem. Feedback is needed, conversations need to hapen, and decisions need to be taken regarding the product. If these don't happen or get delayed too much, you risk building a product of less value.

So focus on the product increment.

As for people being left out, what the other posted answer mentions is correct: this is a non-issue. In one of my teams we had a rule that each developer should present the User Stories they worked on, just to give a further sense of accomplishment for the work, to make people more responsible, to also help them gain presentation skills, boost their confidence, etc. But more people worked on the same User Story: testers, reviewers, other developers pairing with the one doing the presentation at the review. So inevitably people were left out. They didn't mind. No harm done. But what happened and was doing harm was that a lot of time was wasted at the review meeting while people moved around the room to sit at the computer to present their own work. But we inspected and adapted. We eventually had the Product Owner present all the stories :).

So inspect and adapt. Bring this up at the Sprint Retrospective. Don't waste time trying to convince management to limit the reviews to just the product increment. They didn't ask for that. The team decided to do so. So discuss it and work it out with your team.