By bulk testing if you mean testing triggers (and corresponding handler classes) ability to process more than one record in the transaction then ...
- You can add more rows in your static resources and insert them into the test context using
Test.loadData(). There's an interesting undocumented feature (at least last I looked) to make creating relationships easier if you don't have external IDs.
- If for some reason it doesn't make sense to use static resources, the testmethod can execute a loop to mass generate many Sobjects that you subsequently insert. See also the @TestSetup annotation where you can have a test factory that is reusable across several testmethods in a test class
- As inserting many objects will cause triggers to run, be sure to wrap your actual testing of the classes with
Test.stopTest() as the former call will reset governor limits.
- Static resources are also a great way of mocking input CSV files or inbound emails that you might be parsing or inbound XML or REST JSON. Here, you wouldn't use
Test.loadData() but instead query the static resource directly.
And the obligatory SFSE disclaimer,
coverage != testing - you need to do asserts to verify your code
And the next obligatory SFSE disclaimer - avoid
SeeAllData=true (in my book at almost all costs) as use of it can lead to deployment errors in your near or distant future - and such errors are very hard to identify. Mock your test data.