There's no real way to answer that question from the information you've provided. Either method or a combination may be the best solution for your users.
I'd think in terms of test result data, not reports. If your data is organized into efficient tables and relationships, the reporting needs usually become much easier to meet.
And deciding whether particular data should be all in one table or in several different tables is often as much "art" as it is "science" with experienced developers disagreeing on the best approach to use.
What I am really trying to accomplish here is to move test data out of excel spreadsheets (which are form based) and into our db. Each job can have a one to many relationship with test reports, but the test reports don't really have any relational data per se within them. For the sake of organization, 1 table per type of testing would be more organized but may be harder to manage with over 15 types of tests that we do. Just looking for a little advice from anyone who has done something similar.
And that info does not change my previous advice. Either or both method might be made to work, there's no chiseled in stone answer that fits every possible configuration for what those sets of test data might be like.
Here are some questions to answer that can help guide you:
How similar are the test results in structure? The greater the similarity in test results from one test to another, the easier it is to put all of that data in a single table. On the other hand, if there are many differences, trying to fit all that data into the same record structure can be come difficult to do.
Will you need to produce reports that combine data from multiple tests into a single report? Unless you are only reporting summary values from your data, a combined table of all results offers a lot more flexibility.
And don't ignore the possibilty of a hybrid approach where you have a central combined data table for the data that is common to every test that links to related tables customized to the data sets needed for specific test types.
And one radical approach that is sometimes worth the effort is to "atomize" your test result data. If all of your data can be represented accurately as a number, a label and a unit of measure ( Max tempurature, 200 degress, celsius or Mass Gain, 2 , KG ...), then a table where you have just those three fields plus a foreign key field to match it to a table of tests can be set up to record your data. That can make for very flexible data storage, but very challenging reporting and analysis of your data.
About the only 'common' data will be shown from the related work order or customer info. The test results are all pretty widely different so I think based on what you have mentioned that separate tables would be the most organized/efficient way of doing it. Reports only show the data from certain types of tests so it's probably better to separate it out that way if another developer gets their hands on it, they can see the report layout matching the table instead of having to hunt for the data.