软件测试分类、测试方法、测试模型、bug周期及其管理

功能测试

测试分类

按测试阶段划分

单元测试

• 程序的最小模块完成后，进行的测试
  • 可能是一个函数，也可能是一个类，也可能是一个界面

集成测试

• 组装测试，在单元测试的基础上，把多个模块组装到一起进行测试，终点关注模块和模块之间的接口

系统测试

• 把软件项目作为一个整体进行测试，测试的依据是需求说明书
  • 到了系统测试阶段，软件基本是完成的

验收测试

• 站到最终用户的角度来测试
  • alpha
    • 内测版本
  • betta
    • 公测版本
  • gamma
    • 接近于正式发布的版本

是否查看源代码分类

黑盒

• 只测试功能，不关注功能的具体实现方式

白盒

• 不但要关注功能，还要关注代码是如何实现的

灰盒

• 介于黑盒和白盒之间的一种测试

按是否运行分类

静态测试

• 不允许软件，静态的观察软件是否符合预期

动态测试

• 运行软件，在运行过程中测试

是否自动化

手工测试

• 通过测试工程师手工对软件进行测试

自动化测试

• 通过编写代码，通过程序自动测试软件是否有bug

其他分类

1. 冒烟测试

• 对软件最基本的流程和工作做一个粗略的测试，看最基本的流程是否能流通
• 测试拿到研发的第一个版本，一般先冒烟。

2. 回归测试

• 当修复一个bug后，把之前测试用例在新的代码下再进行测试

3. 随机测试

• 针对软件中的重要功能进行复测

4. 探索性测试

• 以便了解和学习项目，一边测试项目

软件质量模型

1. 功能性

• 功能的正确性
• 功能的安全性
• 功能的依从性

2. 可靠性

• 软件要有容错性
• 出现错误后，可以很快恢复

3. 易用性

• 软件界面是否流程
• 提示是否友好
• 用户使用功能是否得当

4. 效率

• 软件一定是要高效的

5. 维护性

6. 可移植性

• 适应不同的系统

开发模型–瀑布模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NwBKWPDf-1629001033825)(C:\Users\jss\AppData\Roaming\Typora\typora-user-images\image-20210708174401396.png)]

• 需求分析
  • 研发分析需求说明书
  • 判断需求的可实现性
• 概要设计
  • 用到具体的技术点
  • 大致模块划分
• 详细设计
  • 详细到可以为编码做支持
  • 类和类关系，类的设计
  • 函数设计
  • 各个接口的细节
  • 数据库表的关系，字段关系
• 编码
  • 依托于详细设计进行编码操作
• 软件测试
• 软件维护
  • 上线后也是需要持续维护

1. 瀑布模型的特点

• 线性模型
  • 每一步都是按顺序来执行
• 文档驱动
  • 每一步都有文档产出

2. 瀑布模型优缺点

• 优点
  • 每个阶段很清晰
  • 只需要关注后续阶段
• 缺点
  • 依赖于需求，不能适应需求的变化
  • 风险到项目后期才体现，失去早期纠正机会

3. 快速原型模型（了解）

• 一边确定需求，一边实现
• 优点
  • 避免瀑布模型的缺点，可以适应早期需求的变化
• 缺点
  • 适合小型项目

4. 螺旋模型（了解）

• 优点
  • 引入风险分析
• 缺点
  • 风险分析需要专业的知识和人员

测试过程模型

v模型

• 从研发的瀑布模型来的

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3rB0BvOJ-1629001033826)(C:\Users\jss\AppData\Roaming\Typora\typora-user-images\image-20210706204838434.png)]

• 优点
  • 包含了底层和高层的测试过程
  • 每个步骤都是文档驱动的
• 缺点
  • 和研发瀑布模型一样，不能适应需求的改变，灵活性较低

w模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-L4ZxKb6y-1629001033827)(C:\Users\jss\AppData\Roaming\Typora\typora-user-images\image-20210706205011012.png)]

• 优点
  • 测试工作伴随着整个研发周期，测试对象不只是代码，文档也需要测试
  • 更早的介入研发工作，可以尽早发现问题，及时处理
• 缺点
  • 对测试工程师要求比较高，实践起来难度比较大

测试用例

八大要素

1. 用例的编号