软件测试最最最基础，你需要知道的1234点

Posted 2022-11-25 小猪媛不圆

认识、概念、基础、用例

• 一、认识
• • 1. 什么是软件测试？
  • 2. 软件测试和研发的区别？
  • 3. 一个优秀的测试人员需要具备什么素质？
• 二、概念
• • 1. 什么是需求？
  • 2. 什么是BUG？
  • 3. 什么是测试用例？
  • 4. 开发的五个模型
  • 5. 测试的两个模型
• 三、基础
• • 1. 软件测试的生命周期？
  • 2. 如何描述一个BUG？
  • 3. BUG的级别
  • 4. BUG的生命周期
  • 5. 如果因为一个BUG和发开人员发生冲突了怎么办？
• 四、用例
• • 1. 等价类
  • 2. 边界值
  • 3. 因果图
  • 4. 正交设计法
  • 5. 场景法
  • 6. 错误猜测法

一、认识

1. 什么是软件测试？

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

2. 软件测试和研发的区别？

1. 目的不同：软件测试是检查软件的质量（以需求为标准） 软件调试是开发人员为了检查程序是否实现了他（开发人员）想让程序实现的功能
2. 人员不同：软件测试：黑盒测试工程师，白盒测试工程师，开发人员（单元测试或者白盒测试）；软件调试：开发人员
3. 阶段不同：软件调试，只在开发阶段;软件测试，贯穿了整个开发的生命周期
4. 难易程度，技能要求；开发广度小，专业度高；测试广度大，专业度低

软件开发的生命周期：需求分析——计划——设计——开发——测试——运行

测试左移：需求前调研阶段和需求阶段，测试人员参加
测试右移：产品上线后，系统监控，日志记录和分享

3. 一个优秀的测试人员需要具备什么素质？

踏实细心,良好的沟通能力,要有好奇心,责任心

具体可参考本文章：原文链接

二、概念

1. 什么是需求？

软件开发中的需求：需求就是满足用户的期望或者合同规定的标准、规范、文档所需要的条件和权限

• 用户需求：用户想要软件实现功能 BOSS/实际用户（反馈和要求）/公司的业务人员（针对公司内部系统）非常简单，没有实现的细节
• 软件的需求：用户需求的具体细化，是用户需求具体的实现细节，开发人员要根据软件需求进行软件开发

2. 什么是BUG？

• 当软件需求规格（软件需求）存在并且合理，如果软件功能和软件需求规格不相符合，我们就说软件错误（BUG）
• 当软件需求规格不存在的时候，用户需求存在并且合理，软件功能和用户需求不相符，就是软件错误（bug）

3. 什么是测试用例？

向被测试系统发起的一组集合，这组集合包括测试数据，测试步骤，测试平台，预期结果

4. 开发的五个模型

1. 瀑布模型
   

• 优点，各个阶段比较独立，看重需求分析和软件测试；
• 缺点：无法适应需求的变化，测试到编码后才介入，导致前期的缺陷无法及时发现，无法及时修正。
• 适用的项目：适用于需求稳定的项目

2. 螺旋模型
   

• 优点，强调软件质量，每一次迭代进行严格的风险分析，提供讨论项目是否有必要进行下去的机会；
• 缺点，引入风险管理，会投入大量人力物力
• 适用的项目：前期需求不是很明确，并且有风险，项目比较庞大的系统开发

3. 迭代、增量模型
   一个系统的四个功能，ABCD四模块，两周完成
   迭代模型：第一周开发人员完成ABCD四个模块的基础功能，第二周，在基础功能之上进行细化和完善
   增量模型：第一周，完成AB模块，第二周，完成CD模块

4. 敏捷开发模型
   
   特点：轻文档、轻流程、重目标、重产出、拥抱需求变化
   Scurm流程：

角色：po(product owner) SM(Scrum Manager) ST(Scrum Team)

• 发布计划会议：PO整理需求，形成user Story,所有的user Story 会形成product backlog , 对user story 进行排序，选出这一次迭代需要做的 US

• 迭代计划会议： SM ST细化需求，分配任务，具体到任务完成的具体时间

• 开发过程中的每日站会：三件事，昨天做了什么，今天的计划，以及遇到的问题；

• 产品演示会议：客户会根据演示结果提出一些修改意见，由产品经理记录，整理成 user story，放到下一期迭代

• 回顾会议：总结

5. 测试的两个模型

1. V模型
   

• 优点：左边的每一个阶段和右边每一个阶段一一对应，左边的每一个阶段是右边每一个测试阶段的依据
• 缺点：测试介入晚，会失去前期错误及时纠正的机会

2. W模型
   

• 优点：测试介入比较早，前期风险可以及时发现，及时纠正
• 缺点：每一个阶段是一个单一串行过程，不能适应需求的变化，无法应用到敏捷开发

三、基础

1. 软件测试的生命周期？

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

• 需求分析：对需求进行验证和细化，为后续的写测试用例做准备
• 测试计划：时间，人员，工具
• 测试设计/开发：根据需求写测试用例
• 测试执行：软件基本开发完成，测试人员执行测试用例，发现BUG，并且记录BUG
• 测试评估：把本次迭代的测试情况形成测试报告。总共有多少测试用例，产生、修改、遗留的BUG

2. 如何描述一个BUG？

（1）发现BUG的版本（代码所在的版本号）
（2）测试平台 （浏览器 Chrome FireFox IE edge 360）
（3）测试步骤、测试数据
（4）测试实际结果
（5）测试预期结果
（6）附件：错误截图，log日志

3. BUG的级别

（1）崩溃：系统无法正常运行，已经严重阻碍了开发人员或者测试人员的工作。如果线上出现这种情况，立马回退版本到一个系统稳定的状态
（2）严重：系统还可以运行，但是已经不稳定了，如果继续运行下去，会产生严重的后果
（3）一般：系统可以稳定的运行，但是会影响用户的操作
（4）次要（建议性的）：建议性的BUG，页面问题，排版问题，字体大小，弹出框但是没有确定按钮，图片显示

4. BUG的生命周期

测试人员提了一个BUG，开发人员修复了，但是测试人员回归的时候发现这个BUG依然存在，可能是什么原因导致的？

• 原因（1）：可能是因为开发人员没有修复正确
• 原因（2）：测试人员没有拉取最新的代码进行发布测试

5. 如果因为一个BUG和发开人员发生冲突了怎么办？

（1）先检查自身，看BUG的描述是否清楚
（2）从用户的角度去劝说开发人员
（3）BUG定级要有理有据
（4）不断提高自己的业务水平和技术水平
（5）可以和产品经理商量开BUG评审，讨论这个BUG有没有修改的必要以及他的解决方案

四、用例

根据需求写测试用例，首先要保证需求的合理性和正确性，要先验证需求；分析需求，把大需求细化成小需求，根据每一个小需求提炼出功能点，根据每一个功能点发散的考虑它的测试用例，去写测试用例（用具体的设计测试用例的方法）

1. 等价类

• 测试用例无法穷举的情况,把输入分成若干个等价类，每一个等价类当中选一个测试用例进行测试，如果这个测试用例测试通过，我们就是这个测试用例代表的等价类测试通过

2. 边界值

• 对输入输出的边界进行测试用例的设计,设计测试用例的时候会把等价类和边界值结合在一起进行测试用例的设计

3. 因果图

输入有多个，不同的输入组合有不同的输出，可以用因果图法来设计测试用例
因果图：一个逻辑图，恒等，与，或，非

如何用因果图法设计测试用例？

①找出所有的输入和输出
②确定不同的输入组合和输出之间的关系
③用因果图来表示输入和输出之间的关系
④根据因果图画判定表
⑤根据判定表写测试用例

4. 正交设计法

研究多因素多水平的一种测试用例的设计方法
根据正交性，在所有的实验组合中找到最优的组合进行测试，通过对这些最优组合的解来分析验证整个实验整体的结果。

经济、高效
因素：输入
水平：输入的取值
列：因素数（C），输入的个数
水平数：每一个因素的取值的最大个数（T）
行：L = （水平数-1）*因素数+1

正交表的性质：
①每一列中各数据出现的次数一样多
②不同的两列不同的数据组合出现的次数一样多

根据正交表设计法设计测试用例的步骤：
①确定因数（输入）②确定每一个因素的水平③找出因素数和水平数④根据因素数和水平数确定正交表的行和列⑤根据正交表的性质去填充正交表里的数据⑥根据正交表的每一行设计测试用例⑦补充正交表里面没有的，但是你认为可能的测试用例

5. 场景法

把各个孤立的功能点按照一定的策略组合起来，形成一个应用场景
总结：找出场景当中的每一个功能点，根据每一个功能点的正常和异常的情况去设计测试用例

6. 错误猜测法

根据测试人员的知识、经验去推断可能会出现问题的功能模块，有针对性的去设计测试用例
补充的设计测试用例的方法，测试人员可以用其他设计测试用例的方法设计需求的测试用例，用错误猜测法作为一种补充的方式