软件测试的目的
说到软件测试，很多人都引用Grenford J.Myers在《The Art of Software Testing》一书中的观点∶
①软件测试是为了发现错误而执行程序的过程
② 测试是为了证明程序有错，而不是证明程序无错
③一个好的测试用例在于发现至今未发现的错误
④一个成功的测试是发现了至今未发现的错误
这种观点可以提醒人们测试要以查找错误为中心而不是为了演示软件的正确功能
也准确说出了什么是好的测试用例、什么是成功的测试
若只看字面意思，有可能会产生误导，以为发现错误是唯一目的
实际上，软件测试的目的包含很多内容
GB/T 14632—2008对软件测试目的有较好的定义∶
软件测试的目的是验证软件是否满足软件开发合同或项目开发计划、系统设计文档、软件需求规格说明、软件设计说明和软件产品说明等规定的软件质量要求
通过测试发现软件缺陷，为软件产品的质量测量和评价提供依据
通过这个定义，可看到软件测试的目的包含很多方面
不仅仅是发现软件的缺陷，还要验证软件是否满足软件开发合同或项目开发计划、系统设计文档、软件需求规格说明、软件设计说明和软件产品说明等规定的软件质量要求
这就说明，软件测试要从项目一开始就要介入随着项目的进行，对开发计划、设计文档、规格说明等都要介入，都要去测试软件和各项文档中的描述是否一致。
最后，软件测试还要为软件产品的质量测量和评价提供依据，这也就是为什么我们学习软件测试必须要先了解软件开发的相关知识了
软件测试的原则
软件测试经过不断发展，人们摸索出了很多测试的基本原则用来指导软件测试工作。
测试的基本原则有助于测试人员进行高质量的测试，能让测试人员用最少的人力、物力，与用最少的代价发现缺陷，是测试人员的测试指南。
以下是测试的几个常用原则。
（1）所有的软件测试都应追溯到用户需求
从客户角度看，最严重的错误就是软件最终呈现的效果不是最初想要的，这样的软件就是失败的。
从项目结项验收角度看，，开发的软件最终都要交付用户使用，得到用户认可的才是好产品，才能顺利通过验收。
所以测试的最根本依据还是用户的需求，一旦发现问题.就要及时地与开发人员以及客户沟通，尽早解决问题。
（2）尽早启动测试工作
由于软件的复杂性、抽象性以及与客户沟通等原因，导致在软件生命周期的各个阶段都有可能产生缺陷。
因此，不应该把软件测试作为项目开发的某一独立阶段的工作，应当贯穿到软件生命周期的各个阶段。
从软件测试的目的中也可以看到，测试从最初的项目立项、合同签订阶段就应该介入，并随着项目进行，分阶段地完成不同的测试任务，直到软件交付客户。
有研究表明"80%以上的产品缺陷是在产品开发过程中的需求定义阶段引入的。
如果需求得到了准确的验证.则可以消除80%的返工问题，节省总项目投入费用的45%"。
可见问题发现得越早，解决问题所花费的代价就越小;发现的越晚，解决问题所花费的代价越大，有时候会以几何级数增加，这是一个公认的道理这是一个公认的道理。
图2 1大体展示了在开发的不同阶段发现缺陷后修复的费用，从图中可以很清楚地看到，在需求阶段发现缺陷，修复的代价很小，但在交付给客户实际使用后发现缺陷，有可能付出的代价是当初开发成本的1000倍，这还只是人力物力的成本，不包括企业信誉、口碑等隐形的损失。
所以应当把"尽早地启动测试工作"作为软件测试者的座右铭。
（3）穷尽测试是不可能的
每个软件测试员都希望能进行完全的测试，找出软件的所有错误，并使软件趋于完美，这种想法是非常好的.但是实现它是不可能的。
哪怕是最简单的程序，由于时间和技术的限制，对大量的输入数据，不可能运行每一种组合，而且前一项的结果有可能是后一项的输入，这样的操作的组合数无疑是天文数字
有时还需要人工的操作，更无可能
下面举一个简单的例子来进一步证明穷尽测试是不可能的
该程序有5条独立路径，含一个循环，最大循环数字为20。
具体分析一下，第0次循环，有5条独立路径;第1次循环，在0次循环的基础上要做到完全测试需要5²条独立路径
以此类推，第20次循环，需要52条独立路径。
也就是说，这个程序的所有独立路径数是51+5²+53…+521≈1014（100万亿），假设每个测试用例（考虑、执行验证结果）5min，则共需测试时间10亿年。
从这个结果不难看出，这么一个简单的程序，做到完全测试就需要花费这么久，何况现在大数据时代的复杂程序和海量数据了。
如果决定不去测试所有的情况，那么我们就面临了很大的风险。
如果时间不够，无法进行充分的测试怎么办?
使用风险分析，确定测试的重点和优先级，控制测试的开销（时间、成本、资源）。
风险分析需要判断技能、常识、感觉和经验。
（4）遵循Good enough原则
既然穷尽测试不可能，那在测试时，就要有选择地去测试，这时就需要使用风险分析，确定测试的重点。
软件测试员要学会的一个关键思想是，如何把数量巨大的可能测试减少到可以控制的范围，以及如何针对风险做出明智的抉择，哪些测试重要，哪些不重要。
测试人员的目标就是找到最优的测试量，找到最佳的平衡点既不要做过多测试也，不做不充分的测试，这就是Good enough原则，它是一种权衡投入/产出比的原则。
展示了遗漏软件缺陷数目和测试费用的关系。
解决办法是通过需求分析和风险分析（时间、费用、资源）找到测试重点
制定最低测试通过标准和测试内容，然后具体问题具体分析。
（5）Pareto法则应用于软件测试
Pareto（帕累托）法则是由意大利经济学家帕累托提出的，又称为二八效率法则或二八定律。该法则认为∶原因和结果、投入和产出努力和报酬之间本来存在着无法解释的不平衡，一般80%的结果或产出，是由20%的原因或投入产生的。
应用到软件测试中则说明80%的软件缺陷会集中在20%的关键核心业务模块中，这就是缺陷群集现象。
一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免.80%的缺陷
而系统测试又能找出其余缺陷中的80%
最后的4%的缺陷可能只有在用户的大范围、长时间使用后才会暴露出来
所以测试中，在有限的时间里，要抓住主要模块
如果在测试中发现某些模块出现错误的次数比其他模块多，就需警惕，需要投入更多的人力和精力去测试这些模块，从而提高总体测试效率。
做好测试需求分析和测试计划，分清测试重点
尽早测试
持续测试
（6）避免"杀虫剂怪事"现象产生
杀虫剂怪事本来指的是一种药物使用久了，虫子就会产生抗药性，免疫力增强了。
在软件测试中，Boris Beizer曾描述了缺陷的"杀虫剂怪事"现象，即同样的测试用例使用久了，发现缺陷的能力会越来越差。
一般来说每修复3~4个缺陷就可能产生一个新的缺陷，如果测试人员还使用原来的测试用例来测试已经修复缺陷的程序，很可能检测不出这个新的缺陷，也就是说这个缺陷的免疫力就增强了。
这个问题主要是在测试已经修复缺陷的程序中出现的
要解决这个问题，测试人员就要注意修复缺陷所产生的波及面，关联的都是哪些地方，不要因为多次对同一个模块做测试就形成了思维定式，要把每次测试都作为新的测试，要有发散思维，不断地对测试用例进行修改和评审
软件测试是一项系统工程，是有组织、有计划、有步骤的活动
因此，在测试时，要遵循测试的基本原则，制订合理的测试计划
（7）测试旨在发现存在的缺陷
软件测试可以报告软件缺陷存在，却不能报告软件缺陷不存在
既使在测试过程未发现软件的失效，也不能证明被测软件没有错误
（8）为了保证测试的有效性和高效性，测试必须是破坏性、系统化的
充分、有效、系统的测试可以减少软件中未被发现缺陷的可能性
测试既要验证软件的正确性，更要通过破坏软件，发现缺陷的不正确性
（9）找到的软件缺陷越多，说明软件隐含的缺陷越多
缺陷具有群集效应
应该在发现缺陷的地方继续找找
（10）并非所有软件缺陷都要修复
没有足够的时间
不算真正的软件缺陷
修复的风险太大
不值得修复
（11）使用木桶原理
木桶原理在软件产品生产方面就是全面质量管理（QTM）的概念
团队合作
（12）前进两步，后退一步
测试中的一个基本问题是-—缺陷修复总会以（20-50）%的机率引入新的缺陷
每次修复之后，必须做确认测试和回归测试。
再测试/确认测试
测试人员提交缺陷，开发人员修复缺陷以后，测试人员需要重新测试，验
证之前的提交的缺陷是否真正修复
回归测试
测试人员提交缺陷，开发人员修复缺陷以后，测试人员需要重新测试，确保对程序修改改没有给软件其他未改变部分带来新的缺陷。
软件修改或者环境变更后，必须进行回归测试。
（13）软件测试是一个迭代的过程
无论项目采用何种开发模型，测试人员总是一个版本接一个版本地测试，其测试活动总是迭代向前的
测试版本1→提交缺陷→修复缺陷→测试版本2→提交新缺陷→修复新缺陷→测试版本3
(14) 优秀的软件测试工程师品质
态度
√ 有责任心
√ 破坏的态度
√ 对事不对人
三心二意
√细心、信心、耐心
√团队合作的沟通意识、时刻保持怀疑的态度（即缺陷预防意识）
具备一定的开发技能
√ 了解开发原理
√ 便于与开发沟通
习惯打破砂锅问到底（善于思考）
(15) 改善测试员和其他小组成员之间的沟通和相互关系的方法
以合作而不是争斗的方式开始项目
√时时提醒项目的每位成员∶共同目标是追求高质量的产品。
对产品中发现的问题以中性的和以事实为依据的方式来沟通
√不要指责引入这个问题的小组成员或个人。比如，客观而实际地编写缺陷报告和评审发现的问题换位思考
√ 尽量理解其他成员的感受，以及他们为什么会有这种反应。
有效沟通
√ 开发与测试具有不同的思维方式，确信其他成员已经理解你的描述，反之亦然。
提高开发技能
(16) 如果测试提交的缺陷开发人员不认可，该怎么办?
首先分析或与开发沟通开发不认可的原因。
如果拒绝原因是提交的不是缺陷，而且自己分析后，的确不是缺陷，则应该注意以后再做测试时要做好复现，认真研读需求，提高自己找缺陷的能力。
如果拒绝原因是提交的不是缺陷 但自己分析时认为缺陷应该是存在的，则再次研读需求并做好复现，拿出确实是缺陷的证据，然后与开发沟通。
如果拒绝原因是认可缺陷，但不予修复，如果自己觉得必须修复，则拿出充分理由和证据和不修复的不利影响和影响范围，再与开发沟通。
(17) 如何解决开发和测试的矛盾?
（1）以沟通和合作的方式开展工作
（2）提高开发技能
（3）换位思考
（4）进行有效沟通
(18) 测试团队中都有哪些角色?
各负责什么任务?
各有多少人?
测试负责人∶制定测试计划，监督安排任务，进行测试总结 1
测试工程师∶进行测试需求分析、设计用例、搭建环境、执行用例、提交并跟踪缺陷 3
技术支持∶负责环境维护 1
配置管理员∶维护版本架构，维护版本库，文档配置 1
质量保证人员∶负责软件质量方面的工作 1
