Details:
We had a discussion on this very topic in our team today, some brought in a factor of 30% which I also know, but I am of the opinion that a much higher automation factor should always be achieved.
What automation factors do you work with?
Assuming we are relating to system tests, empirical data shows that the effectiveness of unit tests above 80% coverage is decreasing while the complexity significantly increase, I am not aware of any magic number for coverage.
But let's take a step back and analyze your question.
First we need to understand what coverage is. Having one test per requirement doesn't take into consideration ranges and timing for example, measuring the actual code coverage of your system tests is usually not practical and while better it still doesn't guarantee that your business logic is covered.
Next you ask about "what should", to answer that you need to know first why do you care. Do you think that higher coverage is better? why? Hard scripted Tests in general, and automated tests even more, tend to have a "pesticide effect" meaning that they are not really good at finding new issues, and while they are doing a better job finding regressions even this is quite limited to bigger problems.
The last question needed to be answered is the cost of achieving higher coverage (cost means effort, resources, time etc.), writing the first automated test is hard and costly since it requires setting up of a test infrastructure. From there the cost is usually low, especially when adding related tests using the same mechanism, think Selenium and POM- most of the tests are about manipulation and interaction with locators. But the low cost trend stops somewhere when complexity increases, the test's runtime increases or you need a sophisticated infrastructure to simulate special conditions. In a typical Pareto principle the cost of the last added percentages towards 100% will be significantly higher than the lower percentages of coverage.
Now you are probably asking what should your team do. The answer depends on the structure and way of working in you company and team. A fast pace, Agile team with a new product and few people responsible for automation can be satisfied with few valuable, fast and stable regression tests. A legacy product with a a lot of available test resources might want to achieve higher coverage, I really like the SQlite example with "Millions and millions of test cases"
Your question is very general and the answer depends on many factors such as organization rules, AUT's (Application Under Test) business, Test methodologies, type of tests you want to automate and ...
But there is one key concept in test automation named Test Pyramid introduced by Mike Cohn.
You should climb up the triangle as necessary as you want and for each step upward the percentage of test coverage becomes lower.
Dzone has a good article about Automated Testing Strategy
To add to above answer , i don't belive test automation pyramid refer to "How many test cases" but about the test coverage
THe higher you go in the pyramid less likely you will be able to hit all 100% of the branches in your code. The effort and investigation required to reach such a 100% code coverage would be tremendous and costly in higher levels of the pyramid like the UI.
So when talking about test pyramid we should talk about test scope than test numbers.
The strategy that i would follow would be:
Unit Test:
100 % branch and condition coverage:
meaning unit tests should be able to test all conditions of a component.
Integration test/API test
Validate 100 % of contract coverage , test that all contracts are tested and verified.
UI tests/ System test
100% user story coverage , ensuring all user interactions are tested and covered.
THis is why BDD becomes important in this level as it can make it easy for tracking Scenario/User story coverage and shares coverage responsibility among team than just QA
