软件测试的基本概念

一、软件测试的基本概念

1. 软件测试的概念（什么是软件测试？）

软件测试是软件测试人员验证软件是否满足用户的需求（软件测试是满足与不满足用户需求的数据都需要测试）。

2. 什么是需求？

满足用户期望（用户需求）和满足合同（软件需求）（文档、规则、标准等）的规定所需要的条件和权限

软件需求是用户需求转化而来的，它是用户需求的细化，是用户需求的具体实现细节和规范。

需求是软件测试的依据

验证需求保证需求正确可实现（可操作）从需求中提炼出一个个的测试项。

3. 什么是测试用例（测什么、怎么测）

测试用例是为了实施测试而向被测试系统发起的一组集合，包含测试环境（硬件环境和软件环境）、测试数据、测试步骤、预期结果等。

4. 什么是BUG（软件错误）？

当且仅当，程序规格说明书（软件需求）存在且合理，如果软件功能和软件规格说明书不符合，则说明软件错误。

当软件需求不存在，用户需求存在且合理，软件功能和用户需求不想符合，则说明软件错误。

5. 如何描述一个BUG？

（1）测试的版本

（2）测试的环境

在不同的测试环境，问题出现的情况不一样。环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

（3）测试数据

（4）测试步骤

测试数据和执行步骤方便开发人员复现问题

（5）实际结果（错误结果）

（6）预期结果

需求期望的结果

（7）BUG产生的日志或错误截图等附件

6. 软件测试的生命周期

需求分析：分析需求，验证需求的正确性，合理性。细化需求，根据需求提炼测试点

测试计划：确定测试范围，目的，目标，测试人员，测试工具，时间，测试环境等

测试设计：开发测试用例

测试执行：开发人员已经提交代码，执行测试用例，提交BUG

测试报告：本次迭代的测试情况进行分析和总结，写了多少测试用例执行了多少，发现了多少BUG，修改了多少，剩余BUG的解决方案，测试的覆盖率。

7.BUG的级别（可能不同）

（1）崩溃

系统崩溃不能运行(死循环，数据库死锁，资源分配不均，黑屏，闪退，阻塞等）

处理方式：线上（用户使用的环境）出现崩溃级别的BUG，回退到上一个可稳定使用的历史版本

（2）严重

服务器可以用但是不稳定，继续使用会产生严重错误，一级菜单错误，数据库插入用户数据错误，威胁到用户的安全

（3）一般

系统可以稳定运行，次要的功能没有实现，提示语不完善，弹出框没有关闭按钮等，不影响用户的使用

（4）建议（次要）

建议性的，提示信息重叠（看不清楚），界面排版不符合用户使用习惯，颜色不符合软件的使用场景。如，过年期间应该设置红色等。

二、开发模型（五个）

1. 瀑布模型 有去无回 串行

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。

特点：阶段性强，每一个阶段比较独立，看重前期的需求分析和后期的测试。

缺点：测试在编码后介入，导致前期的问题后期才发现，失去错误补救的机会。

2. 螺旋模型

适合于项目庞大，复杂度高，风险大，软件开发初期需求不是很明确。

优点：强调严格的全过程风险管理，和各开发阶段的质量。提供机会检讨项目是否有加之继续进行

缺点：引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技术水平提出了很高的要求，这需要人员、资金和时间的投入，成本较大。

3. 增量模型和迭代模型

增量模型是逐块建造的概念，而迭代模型是反复求精的概念

例如：同一系统的四个模块A,B,C,D用两周时间开发

增量模型：第一周开发A,B功能模块

第二周开发C,D功能模块

增量开发能显著降低项目的风险

迭代模型：第一周开发A,B,C,D的基础功能

第二周再在第一周的基础上完成其他的功能

4. 敏捷模型

敏捷宣言：个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

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

特点：轻文档、轻流程、重目标、重产出，拥抱变化

4.1.scrum的基本流程

产品负责人负责整理user story ,形成product backlog

发布计划会议：产品经理（“po”）将收集的需求形成userstory，讲解，排出本次迭代需要进行开发的userstory形成sprint backlog

迭代计划会议：分析userstory 把userstory 分解成一个个的任务，分配给开发人员，制定开发计划

每日例会：每天scurm master（“sm”项目经理）召集站立会议，团队成员回答昨天管理什么今天计划做什么，又什么问题

产品演示会议：为甲方/用户演示产品，把不足的地方由po收集整理形成新的user story

回顾会议：回顾整个迭代过程，把不足的地方找出，在下一次迭代过程中改进，优化迭代流程

三、测试模型（两个）

1. V模型（瀑布模型的变种）

左边是右边的测试依据

特点：每一个阶段独立性强，左边每一个阶段是右边测试的依据

缺点：测试介入晚，编码后才开始导致前期问题后期才发现，失去了最好的解决时间，不支持需求的改变

2.W模型（双V模型）

特点：每一个阶段独立性强，测试与开发并行，可以保证前期问题及时发现和纠正

缺点:需求、设计、编码等活动被视为串行的，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作，无法支持敏捷开发模型。

四、测试用例

1. 为什么要在测试前设计测试用例？

测试用例是测试执行的依据

可以复用（回归测试）

衡量需求的覆盖率

自动化测试的依据

借鉴意义，后续测试人员可以借鉴前人写的东西

2. 测试用例的设计方法

基于需求进行测试用例的设计

1>功能需求

从界面考虑，验证界面的功能（UI设计稿）

从业务角度考虑，把功能串起来进行测试

功能之间的交互性、一致性（分角色测试）

一个功能的多个输入（不同的输出）

功能的错误操作、异常操作的测试（属于负面测试）

功能的易用性、体验性的测试

功能是实现用到的算法验证，有时需要用代码评审

2>非功能需求

在功能的基础上做一些限制，满足特定场景的需求，让用户有更还的体验。每一个应用软件系统对非功能性的要求是不同的

兼容性、性能、安全性、可靠性、易用性、易维护性和可移植性等

3.六大设计测试用力的方法

3.1等价类

根据输入（特定情况下考虑输出），把输入划分成若干个等价类，从每一个等价类中取一个测试用例进行测试，如果这个测试用例通过，我们就说这个测试代表的等价类测试通过。

符合需求规格说明书的数据称为有效等价类

不符合需求规格说明书的数据称为无效等价类

3.2边界值

对输入输出的边界针对性的进行测试用例的设计

3.3错误猜测法

测试人员依据自己的经验知识和个人直觉判断软件哪一块有问题，针对性的设计测试用例，适合于补充测试用例，或者进行探索性测试的时候。

3.4场景法

把一个个孤立的功能串起来形成一个场景，每一个功能不同的输入会触发流程走向不同的场景，根据这些不同功能的不同输入触发形成的场景进行测试用例的设计。

3.5因果图法

因果图是一种逻辑图，恒等、与、或、非。根据因果图去分析和设计测试用例。

3.5.1因果图的几种关系

恒等：输入为真，输出为真

与：当输入条件多个，多个条件都为真的情况下，输出才为真

或：当输入条件为多个，其中有一个条件为真，输出为真

非:输入为真，输出为假；输入为假，输出为真 ~取反

3.5.2用因果图法设计测试用例步骤

a.分析所有的输入和输出

b.找出输入和输出之间的逻辑关系

c.根据输入和输出画出因果图

d.根据因果图画出判定表

e.根据判定表设计测试用例

3.6正交法

根据正交性，从大量的实验数据中，选取最优的数据组合，根据最优的数据组合的结果衡量整个测试的输出结果。