软件测试的goodenough原则是指_软件测试的目的与原则

原标题：软件测试的目的与原则

软件测试的目的

基于Glen Myers和Hetzel两位学者的著名测试论点，将测试的目的分为两派。

Glen Myers认为测试时为了发现错误而执行软件程序的过程。

Hetzel认为软件测试是对软件建立信心的一个过程。

对软件进行的测试越多、越充分、人们对使用该软件的信心就越强

从测试的目的出发，可以把测试分为两大类：

1.为了验证程序能正常工作的测试

3.为了验证程序不能正常工作的测试

软件测试的两面性

测试人员要验证软件程序能否正常工作需要有一定的依据，普遍的认为需求文档就是这样的依据，但是如果需求文档本身就是错误的，那么这样的依据就不可信。所以不仅仅要依据需求文档来验证程序是否正常工作，还要加入测试人员的经验判断和对软件的理解才行。

要验证程序在所有情况下都正常工作是非常难的，相对的验证程序在所有情况下不能正常工作相对容易一些，找到错误就可以证明。bug会随着项目的修改变得越来越难找。

大部分的软件测试组织在综合的运用两类测试方式，主要体现在一下方面

• 测试用例的设计分为正面和反面的测试用例，分为验证主成功场景的用例和验证扩展场景的测试用例。
• 测试的执行结合严格的测试用例执行过程以及灵活的探索性测试执行。
• 软件测试的中前期主要集中精力发现软件的错误，软件的中后期主要集中精力在验证软件的正常使用性上。
• 单元测试主要关注程序做了正确的事情，集成测试和系统测试主要关注程序的错误行为。
• 自动化测试主要专注于验证程序的正确行为，手工测试主要专注于发现软件的错误行为。

软件测试的验证与确认

1. 验证(Verification)是指在软件的生命周期的各个阶段，用下一个阶段的产品来检查是否满足上一个阶段的规格定义。如：需求——设计——编码——测试，用设计来验证需求定义的规格是否正确，编码验证设计的合理性，测试验证编码的正确性。
2. 确认(Validation)是指在软件的生命周期的各个阶段，检查每个阶段结束时的工作成果是否满足软件生命周期的初期在需求文档中定义的各项规格和要求。如：需求——设计——编码——测试，设计完成后需要通过评审来判断是否满足需求定义；编码完成后也需要通过代码审查等方式来检查编码是否满足了各项需求的规格定义；测试阶段，则通过评审测试用例、测试计划、测试报告、缺陷覆盖等材料来判断测试是否覆盖了各项需求。

软件测试的原则

• Good enough原则
• Pareto原则
• 尽可能早开展测试
• 在发现较多错误的地方投入更多的测试
• 同化效应

Good enough原则：指测试的投入跟产出要适当权衡。测试的投入少对质量不负责，测试的投入多，资源浪费。适当的加入其他的质量保证手段可以降低对测试的依赖。

Pareto原则：80-20原则，80%的bug在分析、设计、评审阶段就能发现，剩下的16需要在测试中发现，最后剩下的4%在用户的长时间使用过程才会暴露。另外对于软件的bug分布也是80-20的原理，也就是百分之八十的bug集中在核心功能上，百分之20的bug集中在扩展功能上，测试人员应当把更多的精力放在核心功能的测试上。

尽可能早开展测试：越早发现错误，修改的代价越小。

在发现较多错误的地方投入更多的测试：指缺陷的聚集效应，一般来说是与开发人员的状态或者缺陷出现的代码范围的复杂度导致的。一旦发现某个模块有bug集中出现的迹象，就应该针对这些模块做更多的测试和回归验证。

同化效应：指造成bug的免疫效果。主要体现在测试与开发长期的相处，测试会更容易赞同开发的观点；测试人员对软件的熟悉度越高越容易忽略一些看起来较小的问题。采用交叉测试能避免一些测试的盲点，充分利用不痛人员对待软件的不同视角和观点，引入新的思维来打破测试的局限。

返回搜狐，查看更多

责任编辑：