1.测试的流程
我们一般在项目进行开 立项会的时候进行产与，讨论需求并提出建议，
在立项会中定制 需求文档，由UI设计原型图，开发根据需求文档进行编码，
我们测试会根据需求文档进行编写 测试计划， 根据模块的（颗粒度）划分并编写 测试用例
以及对 用例审评会，开发结束后测试对主要功能进行冒烟测试，
执行测试用例，提交bug开发进行修改，修改成功关闭bug，
进行回归测试，在上线前进行测试总结。
说明：
立项会：产品经理 项目经理 开发人员 测试人员
需求文档：规格说明使用书
测试计划：一般由于城市组长或者是经理编写
测试用例：根据模块划分/根据测试功能/性能/自动化进行划分
用例评审会：测试人员 测试组长/项目经理 产品经理 a:组内评审 测试人员 测试组长/项目经理 产品经理 客户：b:组外评审
冒烟测试：对软件的主要功能进行测试
回归测试： 我们将修改的问题在进行测试
测试总结：一般由于测试组长或者是测试经理编写 （参与）
测试分类
测试可以分为：
1.按阶段划分
2.程序是否执行
3. 程序运行划分
阶段划分：
单元测试：单个功能的测试 （增删改查 分页 上传 下载 ）
集成测试：功能模块的测试 （多个功能功点进行总结在一起）
系统测试：多个模块合成测试 （整个软件的整体测试）
验收测试：客户以及产品经理进行 （交付前的测试）。
程序是否执行
静态测试：UI界面 业务逻辑
动态测试：连接数据之后
代码是否执行：
黑盒子 ： 纯功能测试 （手动测试。点点点）
? 功能测试
? 安装/卸载测试
? 界面测试
易用测试
? 兼容性测试
? 逻辑功能测试
? 性能测试
? 稳定性测试 monkey命令
? 压力测试
? 负载测试
一般性能测试 系统资源使用率
? 白盒子 ： 使用编程脚本进行测试 实现自动化
? 灰盒子： 介于黑和白之间
其他测试：
冒烟测试
回归测试
随机测试
测试原理：
1.应当把“尽早和不断的测试”作为开发者的座右铭。
2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如断网，断电等
3.—定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
5.制定严格的测试计划，并把测试时间安排得尽星宽松，不要希望在极短的时间内完成一个高水平的测试。
6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
开发流程
w模型：
优点
1 测试伴随着软件的整个生命周期，例如，在需求分析结束后就可以进行需求分析测试。
2 测试于开发是并行独立进行的。
缺点
1 对有些项目，开发过程中根本没有文档产生，故W模型无法使用。
2 对于需求和设计的测试技术要求很高，实践起来很困难。
螺旋模型：
开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段：制定计划、风险分析、实施工程和客户评估。螺旋模型要点：统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析。
1.软件分多个版本开发，每个版本就是一次螺旋。
2.每个版本按照这样的顺序进行：
1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）
2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）
3）实施软件开发；（图中右下象限）
4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）
3.需求不是一次获取和实现的，通过多个螺旋来完善。
4.计划也不是一次成型的，每次螺旋都需要调整。
优点：
1）设计上很灵活，可以在项目的各个阶段进行变更；
2）以小的分段来构建大型系统，使成本计算变得简单容易；(国企项目)
3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；
4）随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互；
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点：
螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。
因此，这种模型往往适应于内部的大规模软件开发。该模型建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
v性模型：
优点：
1 每一个阶段都清晰明了，便于控制开发的每一个过程。
2 既包含单元测试又包含系统测试。
缺点：
1 测试介入的比较晚，对于前期的一些缺陷无从发现和修改。
2 测试和开发串行。
测试到底归哪里？
1.测试归测试组 测试组长/测试经理
2.测试归项目组 项目经理