测试的基本原则A
在设计有效测试用例之前，测试工程师必须理解软件测试的基本原则。这里有一组测试原则：
1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。
3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6 、为了达到最佳效果，应该由独立的第三方来构造测试。“ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。
7、 不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现.
8、缺陷集群性，缺陷往往集中在特定的功能模块或代码段内。如果发现了某个区域中的一个缺陷，那么该区域很可能还存在其他缺陷。
9、测试独立性，测试团队应该尽可能地独立于开发团队，这样可以减少主观因素的影响，提高测试的有效性。
测试的基本原则B
1、应当把“尽早和不断的测试”作为开发者的座右铭
2、程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
3、设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4、一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5、对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6、制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7、回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
8、妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档，记录测试计划、测试案例、测试步骤以及测试结果对于维护和后续测试非常重要。
9.、避免个人偏见，测试人员应该客观地执行测试，避免受到个人对系统的理解或期望的影响。
10、客户视角，测试应该从最终用户的角度出发，确保软件满足其需求和期望。
