基础理论知识
目录
1.软件产生缺陷的原因
1.需求解释有错误
2.用户需求定义错误
3.需求记录出错误
4.设计说明有误
5.编码说明有误
6.程序代码有误
7.数据输入有误
8.测试错误
9.问题修改不正确
10.不正确的结果是由于其他的缺陷而产生
2.软件测试和缺陷修复的代价
缺陷发现的越早越好
3.软件测试的定义
狭义.测试的定义："程序测试是为了发现错误而执行程序的过程".这个定义，被业界所认可，经常被引用
广义.为了更早的发现问题，所以将测试延伸到需求评审，设计审查活动中去，也就是将"软件质量保证"的部分归为测试活动
4.如何快速融入新团队
1.查询编写测试用例
2.虚心学习
3.查阅需求文档
4.查看用户使用手册
5.查阅Bug
5.测试人员的基本素质
1.参与需求讨论，制定测试计划，确保测试能顺利执行并完成
2.负责项目的功能性测试，用户体验测试，兼容性测试以及性能测试
3.负责测试用例的编写；编写测试报告和对测试结果分析
4.与开发人员、产品经理沟通和协作，推动整个项目顺利进行
5.负责软件开发团队项目进度管理工作
6.熟悉Linux常用命令，熟悉常用数据库，熟练使用基本SQL语句
7.熟练使用Loadrunner,Jmeter等至少一种性能测试工具
6.测试流程
立项-----需求文档（需求人员）-----需求评审（开发，测试，项目经理，需求人员）-----详细设计（开发人员）-----测试用例（测试人员）-----测试用例评审（开发，测试，项目经理，需求人员）-----编码-----部署（测试人员 ）-----冒烟测试-----Bug（禅道）-----测试报告-----上线 （运维）
7.软件测试分类
黑盒测试和白盒测试
黑盒测试（Black Box - Test）指的是把被测试的软件看做一个黑盒子 ，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
白盒测试（White Box - Test）指的是把盒子打开，去研究里边源代码和程序结构
静态测试和动态测试
静态测试，是指不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程
动态测试:是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程
功能测试和性能测试
功能测试是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求。功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试
性能测试：时间性能，一般性能测试，稳定性测试，负载测试，压力测试
回归测试，冒烟测试，随机测试
回归测试是指对软件的新版本进行测试时，重复执行上一个版本测试时的用例，比如在1.0版本中，有一个bug，到了2.0版本中,再重新测试1.0中这个bug
冒烟测试指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性
随机测试是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误
单元测试，集成测试，系统测试和验收测试
单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证(白盒测试)
集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分（白盒测试，黑盒测试）
系统测试:指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。（黑盒测试）
验收测试：以用户为主的测试，软件开发人员和质量保证人员参加（黑盒测试）
8.水杯的测试用例
功能（用途）、性能（承受）、界面（观察）、安全（存在隐患）、易用（用户使用）
功能：装水，装其他液体
性能：装多少
界面：颜色，形状
安全：材质
易用：用户使用
9.软件测试的原则
1.应当把“尽早和不断地测试”作为开发者的座右铭。
2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况
3.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
5.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见
7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
10.软件的开发模式
线性模型：最常见的“瀑布模型”，基础框架，但缺点在于“集成之日就是爆炸之日”。（立项分析-需求分析-设计-编码-测试-维护）很多企业使用后使用迭代进行修改。
渐进式模型：最常见的“螺旋模型”，（需求分析-风险分析-设计、编码-测试、评审），迭代开发和增量开发模式。
11.软件生命周期模型
瀑布模型：瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件，前面一个步骤不完成，后面的步骤不能开始，否则问题会滚到下个阶段，带来更多的问题
优点：
1) 为项目提供了按阶段划分的检查点
2) 当前一阶段完成后，只需要去关注后续阶段。
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化
螺旋模型：统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析
1.软件分多个版本开发，每个版本就是一次螺旋。
2.每个版本按照这样的顺序进行：
1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）
2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）
3）实施软件开发；
4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）
3.需求不是一次获取和实现的，通过多个螺旋来完善。
4.计划也不是一次成型的，每次螺旋都需要调整。
优点：
1）设计上很灵活，可以在项目的各个阶段进行变更；
2）以小的分段来构建大型系统，使成本计算变得简单容易；(国企项目)
3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；
4）随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互；
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点：
螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。
因此，这种模型往往适应于内部的大规模软件开发。该模型建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
Ｖ模型
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
优点：
1 每一个阶段都清晰明了，便于控制开发的每一个过程。
2 既包含单元测试又包含系统测试。
缺点：
1 测试介入的比较晚，对于前期的一些缺陷无从发现和修改。
2 测试和开发串行
Ｗ模型
相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题
优点
1 测试伴随着软件的整个生命周期，例如，在需求分析结束后就可以进行需求分析测试。
2 测试于开发是并行独立进行的。
缺点
1 对有些项目，开发过程中根本没有文档产生，故W模型无法使用。
2 对于需求和设计的测试技术要求很高，实践起来很困难。