一、所有的测试软件测试都应追溯到用户需求
这是因为软件测试的目的是使用户完成预定的任务，并满足用户的需求，而软件测试的所揭示的缺陷和错误使软件达不到用户的目标，满足不了用户的需求。
二、应当将“尽早地和不断地进行软件测试”作为软件测试者的座右铭
测试需求贯穿整个软件的生命周期，缺陷修复成本随着各个阶段的靠后而提升。从平时的醒目中已看出，需求阶段引入的bug不比设计阶段少，如何保证好需求的稳定有效已经至关重要。
三、完全测试是不可能地，测试需要终止。
即Zero Bug与Good Enough；本条给我们灌输的是一种测试执行通过的标准。显示任何测试通过不可能达到0bug。那我们就应该达到Good Enough。这条原则是一种权衡投入/产出比的原则：测试既不能不充分也能过，我们需要制定测试通过标准和测试内容，比如：遗留的bug数&严重程度，测试用例的执行率&通过率等来解决上面的问题。
四、软件测试无法显示软件潜在的缺陷。
进行测试时可以查找并报告发现的软件缺陷和错误，但是不能保证软件的缺陷和错误能全部找到，继续经一部测试可能还会找到一些，也就是说测试只能证明软件存在错误而不能证明软件没有错误。
五、充分注意测试中的集群现象。
即80-20原则；这条主要想告诉我们的就是缺陷的集群现象，发现缺陷越多的模块就需要投入更多的人力精力去测试。
六、程序员应避免检查自己的程序。
为了达到测试目的，应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试。
七、尽量避免测试的随意性。
制定严格的测试计划，并把测试时间安排的尽量宽松，有组织、有计划、有步骤的开展测试活动。
八、回归测试的关联性
回归测试的关联性一定要引起充分注意。修改一个错误而引起更多错误出现的现象并不少见。
金鑫 2010-02-22
类似的文章看过不少，不过这篇看的出你是用心实践得出的，赞
杜琳 2010-02-22
“程序员应避免检查自己的程序”，这个不太现实，很多公司没有专职的测试，都是开发兼职的。
“测试只能证明软件存在错误而不能证明软件没有错误”这句该给领导们看，不要再跑来问我为什么测试过了那么多次还有bug。
田庆希 2010-02-22
“测试只能证明软件存在错误而不能证明软件没有错误”这句该给领导们看，不
吴卓扬 2010-02-22
吴卓扬 2010-02-22
“测试只能证明软件存在错误而不能证明软件没有错误”这句该给领导们看，不
欧洁 2010-02-22
换个说法：没有bug就不是软件。
欧阳辰 2010-02-22
"所有的测试软件测试都应追溯到用户需求"是我追求的:)
楮迎春 2010-02-23
我再添上几条，锦上添花吧，摘自我翻译的一篇文章：
1 定义预期输出或结果，是测试用例的重要组成部分
2 一个开发团队应该尽量避免测试自己编写的程序
3 彻底检查每个测试结果
4 测试用例中不但要写明有效的和预期规定的输入条件，也要包括无效的及预期规定之外的输入条件
5 检查程序应该完成哪些功能，这只是测试工作的一半，测试工作的另一半是，检查程序完成了哪些不应该完成的功能
6 避免一次性的测试用例，除非该程序是一个真正的一次性项目
7 如果没有很好的对测试工作进行计划，只凭主观臆断来测试，将很难发现程序中存在的错误
王恩建 2010-02-23
苗田丽 2010-04-07
前七条是软考“软件评测师”上面写的，一字不差 ,但切实可行！
任玉鑫 2010-06-19
每个软件 总是有缺陷的 只是有些潜在的BUG没有被发现而已 我们要做的就是把它找出来
