(1)所有的测试都应追溯到用户需求。
软件测试的目标在于揭示错误。从用户角度来看，最严重的错误是那些导致程序无法满足需求的错误。
(2)应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。
应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。
(3)pareto原则：测试发现的错误中80%很可能起源于20%的模块中。
当某个功能出问题，其对用户的影响有多大?然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20%功能(优先级高)的测试会得到完全执行，而低优先级的测试(另外用户不经常用的80%功能)就不是必要的，如果时间或经费不够，就暂时不做或少做。
(4)完全测试是不可能的，测试需要终止。
测试无法显示软件潜在的缺陷，“测试只能证明软件存在错误而不能证明软件没有错误”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
(5)应由独立的第三方来构造测试。
第三方测试最大的特点在于它的专业性、独立性、客观性和公正性。对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观、科学的评价，有助于开发商认清自己产品的定位。对于行业主管部门以及软件使用者来说，由于第三方测试机构独立公正的地位，可以对被测试的软件有一个客观公正的评价，帮助用户选择合适、优秀的软件产品。
(6)充分注意测试中的群集现象。
测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。不要在某个程序段中找到几个错误就误认为该程序段就没有错误而不再测试，相反应该对错误群集的程序段进行重点测试。
(7)尽量避免测试的随意性。
测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等以及评价标准。
(8)兼顾合理的输入和不合理的输入数据。
(9)程序修改后要回归测试
修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
(10)应长期保留测试用例，直至系统废弃。
妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护等提供方便。
文章来源于领测软件测试网 https://www.ltesting.net/
