A better way to think about it is to test one thing at a time. Use as many asserts as necessary to test that one thing, but typically only one. Multiple asserts can be a sign that you are testing more than one thing at a time but it's not, in my opinion, a hard and fast rule. The best guide is that you don't want to create dependencies in your tests between concepts that are independent.
In your example you are actually testing 4 things, though you actually probably only need two of them since they cover the same ground. I'd suggest testing what happens when you add two positive numbers, two negative numbers, and a negative and a positive with negative and positive results. Then I'd think about mathematical properties and test commutativity and the additive identity (zero). Finally, I'd test the boundary conditions -- positive and negative overflow, etc. Note, this may or may not be comprehensive, i.e., I think I've covered the bases, but I'm not trying too hard to be exhaustive; I just want to illustrate how you'd go about thinking about what tests to write and, yes, I'd make each of these separate tests with a single assert.
For something more complex, you may have more than one assert that tests the same "thing" -- e.g., you may want to check that a row is properly inserted in the DB with a given set of inputs. I think it's perfectly acceptable to test that all columns have their proper value in a single test, rather than test each property individually. Others may differ, but I don't think that in this case you are creating any dependencies by testing that all properties have their correct values because the insert is an atomic action.