软件测试的原则都是显而易见的但是又常常被我们忽略。下面我们就来总结一下软件测试的几大原则，分别是：
原则一:测试用例中一个必须部分是对预期输出或结果进行定义
这个原则是软件开发中经常犯的错误之一。如果某个测试用例的预期结果事先没有得到定义，由于“所见即所想”的存在，某个似是而非、实际上是错误的结果可能会被解释成正确的结果。换句话说，尽管“软件测试是破坏性的”得定义是合理的，但在人们潜意识里面还是希望看到正确的结果。克服这一倾向的方法，就是通过事先精确地定义程序输出的结果。一个测试用例包括两个部分：
1）对程序输入数据的描述
2）对程序在上述输入数据下的正确输出结果的精确描述。
原则二：程序员应当避免测试自己编写的程序
自己在检查自己所写的程序很难跳脱开自己的思维方式，在心理上很有可能下意识的阻止自己找出程序的错误来。另外，由于程序员错误的理解了疑难定义或者规范导致程序出现错误，在这种情况下，程序员很可能带着同样的误解来测试自己的程序。
原则三：编写软件的组织不应当测试自己编写的软件
这个原则与原则二类似，在大多数的情况下，主要是根据给定的时间，特定成本范围内开发软件的能力来衡量编程组织或项目经理。度量时间和成本目标比较容易，而定量的衡量软件的可靠性则及其困难。即便是合理规划和实施的测试过程，也可能是被认为降低了完成进度和成本目标的可能性，因此编程组织难以可挂不能的测试自己的软件。更经济的方法是由客观的第三方来测试。
原则四：应当彻底检查每个测试的执行结果
这个原则是最显而易见的原则，即便有的错误明确的输出清单里出现，但还是有可能没有发现这个错误。在后续的测试中发现的错误，往往是前面测试遗漏的。
原则五：测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况。
在软件测试中，有个很自然的倾向，即将重点集中在有效和预期的情况上，而忽略了无效和未预料到的输入情况。而软件产品中突然暴露出的许多问题往往是以某些新的或未预料的值来运行时发现的。因此针对这些为预料到的值和无效输入的情况的测试用例似乎比那些针对有效输入情况的那些测试用例更能发现问题。
原则六：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了不应该做的”
设计测试用例的时候应该全面考虑程序方方面面，不希望程序有负作用。
原则七：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
这个问题在采用交互式系统来测试软件时最常见。如果我们精心设计的测试用例在测试结束后就消失，当软件重新需要测试，又必须重新设计测试用例，由于重新设计测试用例费时费力，人们往往避免这么做。如果程序更改导致程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的。保留测试用例，当程序其他部件发生了变更后重新执行，这就是所谓的“回归测试”
原则八：计划测试工作时不应该默许假定不会发现的错误
所谓测试，就是为发现错误而执行程序的过程。而不是“证明一个程序正确运行的过程”
原则九：程序的某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
假如程序有两个模块，模块A和模块B。模块A中已经发现了5个错误而模块B只发现了1个错误。如果模块A的测试用例并不是设计的更为严格，那么该原则告诉我们，模块A与模块B相比，存在更多错误的可能要大。为了使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。
原则十：软件测试是一项极富创造性，极具智力挑战的性的工作
测试一个大型的软件所需要的创造性很可能超过了开发该软件所需要的创造性。要充分的测试一个软件以确保所有错误不存在是不可能的。合理设计出测试用例集需要大量的创造力。