【软件测试】测试相关概念

一.什么是需求

1.定义

（1）用户需求

甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务

（2）软件需求

亦叫功能需求，该需求描述开发人员必须实现的功能

通常为产品经理编写的

（3）从软件测试人员角度看需求

需求是测试人员开展软件测试工作的依据。

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

业务需求—>软件功能需求点—>测试需求点—>测试用例

大多数公司在进行软件开发的时候会把用户需求转化为软件需求

用户需求为一句话，而软件需求则是一个文档（详细描述用户需求如何实现），通常是用软件需求来进行开发测试的

举个例子

2.需求存在的意义

• 从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
• 对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计

3.如何深入了解需求

账号

功能：账号正确，登陆成功；密码正确，登录成功…

兼容：…

性能：…

安全：…

密码

登录按钮

需求评审会议

二.测试用例（CASE）

1.定义

测试用例是为了实施测试而向被测试的系统提供的一组集合，测试环境，操作步骤，测试数据，测试结果等要素

这里以一个登录页面进行测试用例的说明

• 测试环境：Windows系统+chrome浏览器+本地
• 测试数据：账号+密码
• 操作步骤：输入账号,输入密码，点击登录
• 预期结果：登陆成功

2.测试用例的意义

1. 提高测试人员的工作效率，降低测试人员工作的重复性问题
2. 测试用例是建立自动化的基础

三.Bug

当且仅当规格说明书是存在的并且正确，程序与规格说明之间的不匹配才是错误

规格说明书：软件需求

1.描述Bug

1. 发现问题的版本

   开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于

   统计和分析每个版本的质量。

2. 问题出现的环境

   环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等;如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3. 错误重现的步骤

   描述问题的最短步骤

4. 预期行为的描述

   要让要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。

5. 错误行为的描述

   描述错误的现象。

6. 其他

   某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。

7. 不要把多个bug放到一起

​ 在无法确认是同一段代码造成的故障时，不要将bug放在一起提交

2.定义Bug优先级

1. Blocker（崩溃）：

   阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2. Critical（严重）：

   系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3. Major（一般）：

   功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）

4. Minor（次要）：

   界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

3.Bug生命周期

bug状态转换图

new：新发现的bug

open：确认是bug，并且认为需要进行修改，指派给开发

fixed：开发人员将bug修复结束

reopen：打回

reject：不是一个bug，拒绝

delay：延后处理

四.软件生命周期

需求分析、计划、设计、编码、测试、运行维护

1. 需求分析：分析需求是否合理，需求是否完整
2. 计划：谁来开发，谁来测试，开发多久，测试多久
3. 编码：编写代码
4. 测试：按照标准进行完成测试并完成测试报告
5. 运行维护：如果出现问题，测试人员需要协助开发定位问题并解决问题

五.开发模型

1.瀑布模型

需求分析：需求文档

设计：技术文档（涉及哪些接口，库表，mq，定时任务…）；UI视觉稿

测试：执行测试用例，提交bug，验收

• 特点：线性的
• 优点：每个阶段做什么，产出十分的清晰
• 缺点：风险往往迟至后期的测试阶段才显露，失去及早的纠正机会
• 使用的项目：小型的项目适用

2.螺旋模型

• 优点：每个阶段都会进行风险分析，避免一些线上问题的发生

• 缺点：风险分析可能出错，项目周期的时间会增长，需要人力财力的投入

• 使用项目：使用于大型项目，风险比较多

3.增量，迭代

• 增量：按顺序将每部分模块开发完成再进行下一个模块的开发，是逐块建造的概念
• 迭代：不需要等到一个模块开发完再开发下一个模块，可以开发一部分就进行下一模块的开发，反复求精的概念

4.敏捷开发

（1）敏捷宣言

1. 个体与交互重于过程和工具

   个体之间面对面沟通

2. 可用的软件重于完备的文档

   文档：开发文档，需求文档…

3. 客户协作重于合同谈判

4. 响应变化重于遵循计划

5. 在每对比对中，后者并非全无价值，但我们更看重前者。

   强调前者，但并不否认后者的价值

（2）scrume

三大角色：product owner（产品经理）,scrum master(项目经理),team(研发团队)

产品经理：收集用户需求，

项目经理：需求进行优先级划分，计划项目的开始和结束时间

每日站会：汇报工作完成进度，遇到的问题，当天的计划

研发团队：则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品

基本流程

六.测试模型

1.V模型

• 用户需求：项目经理将用户需求收集成软件需求
• 需求分析与设计：验证需求是否正确，确定编程语言，确定框架
• 概要设计：项目结构如何设计
• 详细设计：每个接口，涉及的库表，涉及的任务
• 编码：编写代码
• 单元测试：测试每一个方法，类；测试函数…
• 集成测试：将许多的方法集成到一块测试
• 系统测试：模块之间没有影响
• 验收测试：验收的人，产品，运营进行验收

（1）特点

左边是开发，右边是测试，类似于瀑布模型

（2）优点

测试被划分为许多类型

（3）缺点

测试人员介入太晚，发现问题时机晚

2.W模型（双V模型）

（1）特点

开发一个V,测试一个V

（2）优点

测试人员尽早的介入了需求

（3）缺点

测试人员和开发人员一定程度上是串行的，不能跟随变化，不适用于敏捷

七.软件测试生命周期

需求分析→测试计划→测试设计→测试开发→测试执行→测试评估

• 需求分析：需求是否完整，是否正确
• 测试计划：确定由谁测试，什么时候开始，测试哪些模块
• 测试设计：写测试用例（手工&&自动化测试用例），编写测试工具
• 测试评估：产生测试报告（测试人员，时间，开发人员，开发时间，测试用例，bug，需求文档及技术文档）
• 运行维护：在试运行项目时收集问题并反馈

八.如何开启第一次测试

1.充分理解需求

文档（产品文档+技术文档）

项目功能问题问产品，模块底层如何实现问开发

2.确定测试计划

• 测试的计划
• 测试的内容？测试用例？天数？有没有自由测试时间？
• 测试内容的开发人员，需求人员是谁
• 是否需要特殊的测试资源？资源是否满足？

3.执行测试

Bug开发修复了之后要进行验收

4.项目上线+维护

九.测试的执行和Bug管理

1.测试开始

1. 打开待测试系统
2. 打开测试管理工具，执行用例
3. 发现bug，确认不够
4. 记录bug
5. 沟通bug
6. 验证以前提交的bug
7. 确认测试完成
8. 编写测试报告

2.如何发现更多的bug

1. 软件测试存在二八原则，80%的故障集中于20%的模块
2. 开发人员存在二八原则，80%的故障集中于20%的开发人员
3. 多进行逆向思维和发散性的思维（依赖测试人员的经验）
4. 不要局限于用例和需求文档
5. 尽早介入项目，不要等到开发的差不多的时候再介入

十.产生争执怎么办

切记批判性思维：清楚-准确、切题-深刻，有意义，有逻辑性公正、全面

1. 先检查自身，是否bug描述不清楚
2. 站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。
3. BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程。
4. 提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案
5. 开发人员不接受时，不要争吵
   %的故障集中于20%的开发人员
6. 多进行逆向思维和发散性的思维（依赖测试人员的经验）
7. 不要局限于用例和需求文档
8. 尽早介入项目，不要等到开发的差不多的时候再介入

十.产生争执怎么办

切记批判性思维：清楚-准确、切题-深刻，有意义，有逻辑性公正、全面

1. 先检查自身，是否bug描述不清楚
2. 站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。
3. BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程。
4. 提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案
5. 开发人员不接受时，不要争吵