First of all, I’m very sorry for this late reply.
Regarding your problem about test analysis and distinguishing known defects from the new once. I’ve got this question before from customers I help in adopting continuous integration. Most of the times it comes from a misunderstanding of what continuous integration is and what it’s purpose is.
Continuous Integration is really a practice where everyone in the team integrates its work frequently with the system. Usually this integration happens at least once a day, leading to multiple integrations per day. Every integration is validated by a build that executes all automated tests. Whenever the build fails, this also means whenever an automated test fails, the build gets fixed within 10 min. The easiest way to fix a failing build is to just rollback the last commit.
The purpose of continuous integration is really to have an always working system, allowing you to perform production releases at any given moment in time. This means that at any given moment in time, tests have to always pass. In this case you don’t need to perform any test analysis to identify new defects from known defects. If a defect is reported by a test, you fix it, immediately. If you don’t, it means your defect is not important and as such your test is not important. In that case, you can just delete that test.
To resume, you in fact don’t need a tool to distinguish new from known defects. I think what is needed is a shift in mindset to work towards an always working system and keeping tests to be always green.
Sent from a device without keyboard. Please excuse brevity, errors and embarrassing autocorrections.