测试篇基础概念

什么是软件测试?

软件: APP , web系统，软件产品(office)
软件测试是测试软件是否满足用户的需求。

软件测试和软件开发的区别?

首先是测试与调试的区别:

目的不同

• 测试的任务是发现程序中的缺陷;是测试人员查看软件是否实现用户的需求.
• 调试是开发人员查看自己写的代码是否实现的他想让代码实现的功能.

参与角色不同

• 测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由:开发人员执行。
• 调试由开发人员完成。

执行的阶段不同

• 测试贯穿整个软件开发生命周期.
• 调试一般在开发阶段。
  再一个就是开发要求技能少，专业度高，测试要求技能更广，深度低.

(3)优秀的测试人员应具备的素质有哪些?(你为何会选择测试这个行业?)
兴趣、责任感、压力、能力

什么是需求?

为了满足用户的期望和规定的合同(文档，标准，规范)所需要的条件和权限，称之为需求.
软件需求是用户需求转化而来的，它是经过对用户需求的验证（正确性，合理性)分析后，具体的功能实现的细节说明.

软件开发的过程：
用户需求—软件需求—开发编码—测试—运行上线

水杯的测试用例

水杯：
1.功能：
水倒容量的一半
水倒至安全刻度线以上
水倒满且流出来
水杯的容量刻度与其他水杯一致
烫手验证

2.性能：
使用的最大次数或时间
杯盖拧紧到什么程度水倒不出来
掉到地上不易损坏
保温时长
杯子的耐热性
杯子的耐寒性
长时间置放水不会漏出来
杯子上放置重物到达什么程度杯子会被损坏

3.界面：
外观是否完整，美观
大小与设计时一样（高，宽，容量，直径）
材质与设计时一样
拿着舒服

4.安全：
杯子使用材质（毒或细菌验证）
高温无毒性
低温无毒性

5.易用：
倒水方便
喝水方便
使用简单，任意操作
防滑措施

6.兼容性：
能容纳果汁，白水，酒精，汽油等。

7.震动测试：
杯子和包装（有填充物），六面震动，检查产品是否能应对恶劣的铁路/公路/航空运输。

开发模型和测试模型

软件的生命周期：软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。

瀑布模型（Waterfall Model）

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点:

• 强调开发的阶段性;
• 强调早期计划及需求调查;
• 强调产品测试。

缺点:

• 依赖于早期进行的唯一一次需求调查，不能适应需求的变化;
• 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程;
• 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

螺旋模型（Spiral Model）

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。这对于那些规模庞大、复杂度高、风险大的项目尤为适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

优点:

• 强调严格的全过程风险管理。
• 强调各开发阶段的质量。
• 提供机会检讨项目是否有价值继续下去。

缺点:

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

增量、迭代

比如说一个项目
需求:完成ABCD四个功能模块两周
增量:第一周完成AB模块第二周完成CD模块;
迭代:第一周完成ABCD四个功能模块的基础功能，第二周ABCD四个功能模块功能的升级和细化。

敏捷开发

轻文档，轻流程，重目标，重产出

敏捷开发的基本流程：

软件测试V模型

V模型最早是由Paul Rook在20世纪80年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种，明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。
局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试。

软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。
W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

软件测试的生命周期

软件（开发）的生命周期分为以下6个阶段：
需求分析—计划—设计—编码—测试—运行维护

软件测试的生命周期(软件测试的流程是什么?)

什么是BUG?

当软件需求规格说明存在并且合理，软件功能和软件需求不相符，就说明是软件错误（BUG).
如果软件需求不存在，用户需求存在并且合理,软件功能和用户需求都存在，说明是软件错误(BUG).

什么是测试用例？

测试用例（Test Case)是为了实施测试而向被测试的系统提供的一组集合，这组集合包含:测试环境、操作步骤、测试数据、预期结果等（标题、重要性、功能模块、优先级、指向方式）要素。

例：
网易邮箱注册功能测试用例
标题:邮箱注册邮箱输入项测试
测试环境:Chrome 版本90.0.4430.212 Windows10小米电脑64位。
测试数据:zhang123456@163.com
测试步骤:
(1)进入网易邮箱注册页面https://mail.163.com/register/index.htm?from=163mail&utm_ source=163mail
(2)输入邮箱地址，输入符合需求的密码和手机号码。
(3）勾选同意，点击注册
预期结果：注册成功;

如何描述一个BUG?(描述BUG的要素)

1. 测试版本
2. 测试环境
   web系统 电脑系统(Windows10 7/Mac) 哪一个浏览器(版本号)
   app 手机品牌型号,系统(Android IOS 哪一个版本)
3. 测试步骤(数据)
   具体的数据
4. 实际结果
5. 预期结果(和需求一样)
6. 其他附件(错误截图/错误日志等)
   有用的附件
   切记:不要把多个BUG放在一起.

BUG的级别：崩溃，严重，一般，次要。

当开发人员因为一个BUG和我们测试人员产生冲突时怎么办?

先检查自身的BUG描述有没有问题;
站在用户的角度去劝说开发;
BUG的定级要有理有据;
开三方会议（产品，测试，开发一起讨论BUG的解决方案)
不断提高自己的业务水平和技术能力，最好同时提出解决方案。

BUG状态的转换

状态为open的缺陷可以转换为哪几个状态？状态为Fixed的缺陷，可以转换为哪几个状态？

• 状态为open，可以转换为fixed或者delay/reject
• 状态为fixed，可以转换为closed或者reopen

缺陷的状态有哪些？

1. New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
2. Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
3. Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
4. Rejected：如果认为不是Bug，则拒绝修改。
5. Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
6. Closed：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。
7. Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

测试删除微信聊天记录功能是否正常

基本测试点：
（1）单条删除；
（2）全部删除
（3）清空聊天记录
（4）没有网络的情况下删除聊天记录
（5）弱网的情况下删除聊天记录
兼容性：
（1）测试不同的微信版本
（2）测试不同的手机系统（iOS，Android，包括不同安卓机不同品牌的机型）
性能：
删除聊天记录时的速度（单条，全部，清空）。