Here's some tips to help you get started:

1) Don't use trigger logic in triggers. A better solution is to call utility classes from your triggers. It looks like this:

trigger X on Y (events) {
  Y_Utility.handleTriggerEvent(Trigger.old, Trigger.new);
}

This lets you isolate the actual logic within classes that can be tested independently. For bonus points, you can bypass the trigger itself when running a DML-level test (in order to make sure the trigger gets the required 1% coverage). Such a trigger can look like this:

trigger X on Y (events) {
 if(!Test.isRunningTest())
   Y_Utility.handleTriggerEvent(Trigger.old, Trigger.new);
}

This design lets you shortcut the normal flow so you can set the system into a known test state with as few calls as possible.

2) Use caching to improve performance. Static variables persist across sub-transactions within a transaction, so you can actually "cheat" by introducing logic that can cheat the system. Combined with the previous tip, you can sometimes simulate entire databases in memory without needing to resort to other methods. For example, let's say that you load accounts in most of your functions. At the risk of a small penalty performance, you can reduce the number of query calls by storing the result the first time it is queried. A simple method looks like this:

public with sharing class Cache {
    static Map<Id, SObject> records = new Map<Id, SObject>();
    static Map<SobjectType, Type> types = new Map<SobjectType, Type> {
        Account.SobjectType => AccountQuery.Class
    };
    abstract class SObjectQuery {
        abstract SObject[] results(Set<Id> ids);
    }
    class AccountQuery extends SObjectQuery {
        override SObject[] results(Set<Id> ids) { return [SELECT Id, Name, Industry FROM Account WHERE Id IN :ids]; }
    }

    SObject[] load(Set<Id> recordIds) {
        SObject[] results = new SObject[0];
        Set<Id> missingIds = new Set<Id>(recordIds);
        missingIds.removeAll(records.keySet());
        while(!missingIds.isEmpty()) {
            Id[] tempIds = new List<Id>(missingIds);
            records.putAll(
              types.get(tempids[0].getSObjectType()).results(tempIds));
            missingIds.removeAll(records.keyset());
        }
        for(Id recordId: recordIds) {
            results.add(records.get(recordId);
        }
        return results;
    }
    
}

Using this design consistently results in fewer queries, etc, because records are only queried once. Even better performance gains are possible, but that's really outside the scope of this response (but it's fun, no?). Just remember that a cache can grow stale, so you might need a way to periodically purge records within a transaction if you know that a certain piece of code will update data that should already be in the cache (watch out for caching errors, they can cause unexpected behavior).

3) Use Test.startTest to double your limits. Make sure you're using this function to your advantage.

4) Test.loadData. You can load data with this method. It can save you execution time and possibly DML statements (need to test that part).

5) Test individual units as much as practical without using DML statements. This ties back into the first point-- if you can get to a stable point in as few queries/statements as possible, you'll have more time/queries to test the actual logic.