软件测试目的与原则
软件测试与软件信心关系
目前大多数人对软件测试目的的理解基于Glen Myers和Hetzel两位学者的测试论点。
Glen Myers认为软件测试是为了发现错误而执行软件程序的过程；
Hetzel认为测试是对软件建立信心的一个过程，测试是评估软件或者系统的品质或者能力的一种积极行为，是对软件质量的度量；
软件测试的两面性：
<1为了验证程序能正常工作的测试；
<2为了证明程序不能正常工作的测试；
测试思路：
<1 测试用例的设计分正面和反面，分为验证主成功场和验证扩展场景；
<2 测试的执行结合严格的测试用例执行过程以及灵活的探索性测试执行；
<3 测试中前期集中精力发现软件的错误，中后期主要集中精力在验证软件正常使用上；
<4 单元测试主要关注程序做了正确事情，集成测试和系统测试主要关注程序的错误
<5 自动化测试主要专注验证程序的正确行为，手工测试专注于发现软件的错误行为；
软件测试的验证与确认
软件测试的目的可以从验证和确认两方面理解：
验证：在软件生命周期各个阶段，检查当前阶段的产品是否满足上一个阶段的规格定义；
确认：在软件生命周期的各个阶段，检查每个阶段结束时的工作成果是否满足软件生命周期的初期在需求文档中定义的各项规格和要求；
软件测试应遵循的原则
Good enough
测试投入跟产出要适当权衡，测试不够充分是对质量不负责任的表现，但是投入过多的测试，则会造成资源的浪费。
随着测试的投入，测试的产出基本上是增加的，但是当测试投入到一定比例后，测试效果并不会有非常明显的增强。
零缺陷是理想的追求，而Good enough则是显示的追求，不盲目追求最佳的测试效果而投入过多的测试资源，应该根据项目实际要求和产品的质量要求来考虑测试的投入。
适当加入其他的质量保证手段，例如代码评审、同行评审、需求评审、设计评审等，可以有效降低对测试的依赖，并且确保软件缺陷尽早发现，从而降低总体质量成本。
Pareto原则
在测试中80-20原则是指80%的Bug在分析、设计、评审阶段就能被发现和修正，剩下的16%则需要又系统的软件测试来发现，最后剩下的4%左右的Bug只有在用户长时间的使用过程中才能暴露出来。
尽可能早开展测试
越早发现错误，修改的代价越小；越迟发现错误，修复软件需要付出的代价就越高。
在出现较多错误的地方投入更多的测试
软件缺陷的集聚通常是由缺陷出现的阶段时间程序员的开发状态或者缺陷出现的代码范围的负责度导致的。
同化效应
测试人员在同一个项目呆的时间越久，越可能忽略一些明显的问题。
测试人员与开发人员一起工作在某个项目中一段较长时间后，容易收到开发人员对待软件的观点影响，变得容易赞同开发人员的观点。
测试人员对软件的熟悉程度越高，越容易忽略一些看起来较小的问题。
持续测试
持续测试，并要尽量避免测试的随意性。