软件测试基础概念

1.什么是软件测试

验证软件是否满足用户的需求

2.什么是需求

满足用户的期望或者正式文档（标准，规范，合约）所需要的条件或者权能，包括用户需求和软件需求
用户需求 一般指甲方（用户）提出的需求，比如我现在想吃饭
软件需求 是由用户需求转化而来的，比如厨师要搞清楚我想吃什么东西。它是是测试人员进行测试工作的依据，也是判断程序是否符合要求的依据。

3.什么是BUG

（1）正式文档存在，并且合理的条件下，软件的功能和文档不符合，叫软件的缺陷
（2）当且仅当用户的需求存在并且合理的情况下（根据用户心情改变手机壳的颜色不算合理），如果软件功能和需求不相符，称之为bug

4.什么是测试用例

为了实施测试而向被测系统发起的一组集合，称为测试用例。测试用例一般包括测试数据，测试环境，测试步骤，预期结果等
编写测试用例时为了明确该测试用例，应予以测试用例 标题，测试模块，测试条件，重要性
以qq登录为例

测试用例：PC端qq登录测试
测试模块	登录模块
测试条件	该用户已经注册过QQ ，该电脑已安装qq
重要性	重要
测试数据	用户名，密码
测试环境	win10系统，qq应用程序，网络通畅
测试步骤	1.双击qq应用程序，2.在第一行输入qq账号，3.在第二行输入qq密码，4。点击安全登录
预期结果	登录成功，进入qq主页面

5.软件测试的生命周期

软件生命周期 是指从软件产品的设想开始到软件不再使用而结束的时间。 软件的生命周期可以分成6个阶段，即需求分析-测试计划-测试设计、测试编码-测试执行-运行维护。

• 需求阶段
  测试人员了解需求、对需求进行分解，得出测试需求

• 计划阶段
  根据需求编写测试计划/测试方案

• 设计阶段
  测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例

• 编码开发
  测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。

• 测试执行
  根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告。

• 运行维护
  测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人。

6.软件开发模型

1. 瀑布模型
   优点：

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

2. 螺旋模型
   
   优点：

• 强调严格的全过程风险管理。
• 强调各开发阶段的质量。
• 提供机会检讨项目是否有价值继续下去。
  缺点：
• 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。

3. 迭代模型
   优点：

• 降低了在一个增量上的开发风险。如果某个迭代完成后的软件不符合客户要求，那么损失只是这一个开发有误的迭代的花费。
• 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
• 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
• 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
  缺点：
• 对产品人员的节奏把控能力（定每周目标，需求优先级剖析，以及临时需求的处理）有较高要求，不然容易在每次发版的时间段，加班特别验证。

5. 敏捷开发
   
   scrum里面的角色
   scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
   其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产
   品负责。
   scrum master 负责召开各种会议，协调项目，为研发团队服务。
   研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

scrum的基本流程

• 发布计划会议：product owner负责讲解user story，对其进行估算和排序，并确定本期迭代user story
• 迭代计划会议：SM和ST对每一个story进行任务分解，形成最小任务，每个任务都有明确的负责人，并完成工时的初估计。
• 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
• 演示会议：向用户演示迭代成果，期间用户的反馈记录下来，由po整理，形成新的story。放入到下一次迭代中。
• 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，好的地方运用到下一次迭代中。

6.描述一个BUG

根据软件版本号，测试环境，操作步骤，预期结果，实际结果这几个方面定位一个bug
假定微信删除聊天记录为例

微信删除聊天记录
测试版本号	V1.0.0
测试环境	IOS2.1， iphone 6s
操作步骤	1.登录微信，2.进入聊天界面，3.选择一条聊天记录，向左滑动，点击删除
预期结果	被选择的记录消失在聊天界面中
实际结果	未删除

7.BUG的生命周期

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

8.BUG的级别

崩溃：系统无法正常运行，阻断。
表现：死循环，死机，数据库发生死锁等
解决：回退系统版本
严重：系统可以运行，但不稳定，会发生严重的后果。
表现：数据泄漏，直播画面失真，密码明文显示
一般：系统可以稳定运行，但是缺少部分功能，影响用户体验。
表现：比如说微信聊天记录无法删除，数据库查询错误
次要：系统稳定运行，属于建议性的bug，可能会稍微影响用户体验

9.软件测试模型

1.V模型

优点：后期测试的每一个阶段都对应前期的开发阶段，有明确的测试依据
缺点：不利于项目前期风险的及时发现

2.W模型

特点：测试的对象不仅仅是程序，需求和设计都要一并测试
优点：有利于前期发现项目问题，避免造成后期开发完之后才发现前期，如需求问题搞错了
缺点：阶段性较强，不利于敏捷开发