about 测试流程
一般公司测试流程
- 评审需求
- 分解需求
- 制定测试计划
- 设计测试用例
- 执行测试
- 提交bug报告
- 回归测试、验证bug
- 书写测试报告
- 经验总结
软件过程模型
- 瀑布过程模型
以文档驱动，自由度低。实际开发过程中，各部分之间都有某种程度的重叠，造成这种重叠的原因是，任何一个阶段都不可能在下一个阶段开始之前结束。
- 快速原型过程模型
先做出一个可运行的、功能简单的原型系统，交由客户试用看是否满足客户期望，并根据客户反馈进行修改增补。
优点：关注用户需求，降低由于需求不明确导致项目出错的风险。在大型项目需求分析难以一次完成时，效果尤为显著。
- 敏捷过程模型
把一个大项目划分多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。各个子项目的成果都经过测试，具备集成和可运行的特征。
适用于小块工作，能完全适应用户环境，而且对产品进行持续迭代。
- 螺旋过程模型
需要经历多次需求分析、设计、实现、测试的过程，依据前一个版本的结果构造新的版本。
这样做需要投入大量的时间精力，主要是为了规避风险、在早期构造软件的局部版本时即获得用户反馈、以及避免一次集成大量代码。
- 增量过程模型
当迭代的速度加快，每次迭代只是在前一次的基础上增加少量功能。
适用于项目后期、维护阶段。
软件测试过程模型
- V模型
V模型从左到右描述了基本的开发过程和测试行为，非常明确地标注了测试过程中存在的不同类型的测试，并且清楚地描述了这些测试阶段与开发过程期间各个阶段的对应关系。
局限性：把测试作为编码之后的一个阶段，无法尽早和不断地进行软件测试。（发现问题要早、快、多）
- W模型
开发和测试同步进行，在V模型的基础上，增加了软件开发各个阶段中应同步进行的验证和确认活动。强调测试伴随整个软件开发周期，而且测试对象不仅仅是程序，还有需求、设计等。
局限性：上一阶段完成后才能开始下一阶段。无法支持迭代，变更很难调整。
- X模型
左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后进行频繁的交接，集成为可执行的程序，再对这些程序进行测试。
变更可以在各个部分发生，并且，X模型定位了探索性测试，能帮助测试人员在测试计划之外发现更多软件错误。
但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。
- H模型
只要某个测试达到准备就绪点，测试执行活动就可以开展。
什么是bug？
从内部角度看来，bug是软件开发或维护过程中存在的错误、毛病；
从外部角度看来，bug是系统所需要实现的某种功能的失效、违背。
冒烟测试
冒烟测试是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑的起来, 可以进行后续的正式测试工作。
bug处理流程
bug管理
- 提出疑问（为什么出现问题？测试环境有没有问题等等？）
- 确认是不是bug
- 定位问题
- 提交bug报告
- 跟踪bug
- 验证bug（开发处理后，验证通过则关闭bug）
- 总结经验
bug报告包括？
| bug编号 |
| bug状态（开发是否已确定？） |
| 项目 |
| 问题部件 |
| 版本 |
| 系统、平台（eg：PC端Windows系统） |
| 重要级别 |
| 测试步骤 |
| 预期结果 |
| 实际结果 |
| 测试员、测试日期 |