文档介绍：软件测试的原则
第一页，共12页
原则一
测试用例中一个必需部分是对预期输出或
结果的定义。
对程序的输入数据的描述；
对程序在上述输入数据下的正确输出结果的精确描述。
第二页，共12页
原则二
程序员应当避免测试自己编写的程序
心理问题：任何作者都知道，亲自编辑或校对自己的作品确实是不好的做法。作者清楚某段文字要说明的是什么，实际表达出来的意思却南辕北辙，而自己却意识不到。对程序员而言，也存在类似的问题。
程序员从事的主要是“建设性”设计编码工作,很难让他突然以一种“破坏性”的眼光来审查程序。
由于程序员错误地理解了疑难定义或规范，导致程序中存在错误。
注意：该结论并不适合于“调试”(纠正已经的错误)；“调试”由程序的编写人员来完成会有效得多。
第三页，共12页
原则三
编写软件的组织不应当测试自己编写的软件
一个软件项目具有与个体程序员相似的心理问题，度量时间和成本目标比较容易，而定量地衡量软件的可靠性则极其困难，即使是合理规划和实施的测试过程，因此，编程组织难以客观地测试自己的软件。
第四页，共12页
原则四
应当彻底检查每个测试的执行结果
原则显而易见，常常被忽视。
换言之，后续测试中发现的错误，往往是前面的测试遗漏掉的。
第五页，共12页
原则五
测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效性和未预料到的输入情况
软件测试中一个自然的倾向，即将重点集中在有效的和预期的输入情况上，而忽略了无效和未预料到的情况。
软件产品中突然暴露出来的问题往往是当程序以某些新的或未预料到的方式运行时发现的。
第六页，共12页
原则六
检查程序是否“未做到其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
上条原则的必然结果；
避免程序的“负作用”。
第七页，共12页
原则七
应避免测试用例用后即弃，除非软件本身就是一次性的软件
采用交互性系统测试软件的常见问题：饱和宝贵投入的测试用例，在测试结束后就消失了；
保留测试用例，有利于开展“回归测试”。
第八页，共12页
原则八
计划测试工作时不应该默许假定不会发现错误
错误观念：“测试是一个证明程序正确运行的过程”
正确概论：“所谓测试，就是为发现错误而执行程序的过程”
第九页，共12页
原则九
程序某部分存在更多错误的可能性，与该部分已经发现错误的数量成正比
错误总是倾向于聚集存在；
启示：为了使测试获得最大的成效，最好对那些容易存在错误的部分进行额外的测试。
第十页，共12页