1、测试用例中一个必须的部分是对预期输出或结果的定义。用例必须包含的两部分：对程序的输入数据的描述（也就是如何去测）；对程序在上述输入数据下的正确输出结果的精确描述。
2、程序员应当避免测试自己编写的程序。虽然很多小公司在资源上不太允许，很多是程序员交叉测试，但是在测试上看这是不太允许的，因为程序员和测试人员看待BUG的思维就不一样，程序员希望自己写的代码BUG越少越好，从而会无形中错过一次BUG；而测试人员做的是破外性的工作（程序员可是亲爹妈呀），希望尽可能地发现BUG。还有一个重要原因是如果某BUG是因为程序员在最初的需求等方面上理解有误，疑难定义或规范，那么程序员可能带着同样的误解来测试程序，那么这个BUG将很难被发现。
3、编写软件的组织不应当测试自己编写的软件。这也就跟外包公司挂上边了。交由客观、独立的第三方来测试。原因除了同第二点的心理上的影响外，在大多数情况下，度量时间和成本目标会比较容易，而定量软件的可靠性就比较困难。当然现在很有公司有测试小组，但是从某种意义上来说，更经济的方法是由客观、独立 的第三方来测试。
4、应当彻底检查每个测试的执行结果。
5、有效\预期输入；无效\未预料输入
6、“未做其应该做的”+“做了其不该做的”=测试7、应避免测试用例用后即弃，除非软件本身就是一次性的软件。在回归测试里的作用。
8、程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。（错误总是存在于聚集存在）
9、杀虫剂悖论：缺陷具有免疫性，不可一直用同样的方法来测试。
10、测试应尽早进行(尽量在前期进行)，最好在需求阶段就开始介入。最严重 的错误不外乎是不能满足用户的需求。
11、制定严格测试计划。测试时间尽量安排宽松，除了测试质量上的满足之外，还能应对需求变更。
12、“彻底地测试”难以实现，要考虑时间、人力、财力等限制，不允许无休止测试（注意准出标准）。
13、测试只能证明缺陷存在，不能证明缺陷不存在。
14、并非所有的缺陷都需修复（主要看测试员的良好判断力）
不需要修复的原因：1）没有足够的时间
2）不算真正的缺陷
3）修复的风险太大。修复一个缺陷可能导致其他缺陷的出现。不去理睬未知软件缺陷，以避免出现未知新缺陷。
4）不值得修复。关乎商业风险决策
关于软件测试的原则还有许多，很难将其全部列出来。
