测试的流程

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 对于需求和设计的测试技术要求很高，实践起来很困难。

v性模型：

优点：
1 每一个阶段都清晰明了，便于控制开发的每一个过程。
2 既包含单元测试又包含系统测试。
缺点：
1 测试介入的比较晚，对于前期的一些缺陷无从发现和修改。
2 测试和开发串行。

测试到底归哪里？
1.测试归测试组 测试组长/测试经理
2.测试归项目组 项目经理