软件测试常见问题 开发模型 PC端qq登录测试用例 BUG的相关问题 测试用例设计的常用方法

1.软件测试和软件研发的区别

软件研发：技能的要求专业度高，技能要求不广泛

软件测试：技能要求比较广泛，但是专业度不高

测试接口：soupUI postman jmeter

性能测试：loadrunner jmeter

自动化测试脚本 ： python java unittest TestNg

​ Charkes fiddler appium

2.软件测试和软件调试的区别

目的：

• 软件测试就是验证软件是否实现了它应该实现的功能

• 软件调试：软件开发人员验证软件是否实现了她想要软件是心啊的功能

角色：

• 测试：由开发人员（白盒测试）和测试人员共同完成

• 调试：由开发人员完成

阶段：

• 测试： 贯穿了整个软件开发的生命周期

• 调试：在开发阶段

• 需求–计划–设计–编码–测试–运维

软件测试在不同公司的定位

• 项目型

• 项目A 项目B 项目C

• 每一个项目都有一个团队

• 性能测试团队

• 自动化测试团队

• 安全测试团队

一个优秀的软件测试人员所具备的素质

1.综合和能力：沟通能力 编程能力 学习能力 文字描述能力

2.自动化开发能力（开发自动化脚本和工具能力）

3.编写测试用例的能力

4.探索性思维，发散思维

5.兴趣

6.责任感 压力

3. 什么是需求

需求----------实现（软件工程）----------上线使用

需求就是实现用户的期望或者满足文档（合同，标准，规范 ）所需要的条件或者权限

需求包含两个方面：一个是用户需求 一个是软件需求

用户需求：一般比较粗略概括

软件需求：软件需求是从用户需求转化而来，是用户需求的细化和具体实现细节

软件需求是测试人员进行测试工作的基本依据

4.PC端qq登录测试用例

1.qq登录的测试用例（思维导图）-------需求的测试点

5.测试用例

向被测试系统发起的一组集合，包含测试环境，测试数据，测试步骤，预期结果（重要性，优先级，操作方式，标题等）

测试用例： 标题：

测试环境：xxxx版本 PC 端 xx系统

测试数据： 用户名：xxxxxx 密码：xxxxxxx

测试步骤：1.打开邮箱的url

​ 2.输入用户名和密码

​ 3.预期结果（操作完测试步骤后的结果） 登录成功

5.1 测试用例的优点：

1.衡量需求的覆盖率；

2.复用性；

3.借鉴意义；

4.可以用于回归测试；

5.防止遗漏测试需求

6.BUG

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

当软件需求不存在，用户需求存在并且合理，软件功能和用户功能不符合，就说明是软件错误

软件测试的阶段： 整个软件开发的生命周期，需求阶段介入， 验证需求的合理性和正确性

7.开发模型

需求分析-----计划------设计------开发------测试-----运维

7.1.瀑布模型

start-----需求分析----计划----设计----编码----测试—end

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

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

7.2.螺旋模型

适合于项目庞大，风险大，不是很明确项目

特点：强调每一个迭代的测试质量和风险分析

缺点：风险管控人力物力投入很多，成本比较大

7.3增量模型，迭代模型

同一个系统的四个模块A B C D

增量模型：

第一周开发 A B 功能模块

第二周开发 C D 功能模块

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

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

特点： 抗击风险能力强

7. 4 敏捷模型

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

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

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

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

**PO product owner,**把用户需求转化成 user story

SM scrum master 项目经理，管理整个团队，负责敏捷流程顺利实施，各种会议

ST scrum team 各种技能的人组成，开发 测试 UI

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

迭代计划会议：分析用户故事，把user story分解成一个一个的任务，分配开发人员

每日站会： 昨天干了什么？ 遇到的问题？ 今天的计划？

产品演示会议：甲方、用户演示产品，PO把不足的地方做成userstory，下一次迭代改进

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

7.5 V模型

特点：

• 1.每一个阶段的独立性较强

• 2.左边每一个阶段是右边测试阶段的依据

• 3.和右边每一个测试阶段-----阶段

瀑布模型变种（缺点）
编码后才进行测试
前期的错误后期才会发现，会失去错误及时就这个机会

7.6 W模型(双V模型)

特点：
1.每一个阶段独立性强
2.测试一开始就介入
3.可以保证前期的问题及时发现和纠正
4.测试和开发并行

缺点：
1.每一个阶段都是串行的过程
2.一个阶段完了之后就进行下一个阶段
3.不支持敏捷开发

8. 软件测试的生命周期（软件测试的流程）

需求分析------ 测试计划------测试开发/设计------ 测试执行 ------测试报告

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

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

测试开发/设计：开发测试用例

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

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

9.什么是BUG

如何描述一个BUG？

（1）测试版本(代码提交的版本号) 比如git上的分支

（2）测试环境：在不同的环境问题中出现的情况不一样：web 系统； 不同浏览器； 浏览器的不同版本 ；

**APP**： IOS  安卓 鸿蒙 塞班  windows   (系统安装的版本)

（3）测试步骤 ：测试数据和执行测试的详细步骤（为了方便开发人员复现问题） 复现问题：分析问题是怎么出现的

（4）实际结果：

（5）预期结果（需求期望的结果）

（6）BUG产生时的log日志，错误截图等附件

10 .BUG的级别

（1）崩溃

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

线上（用户使用的环境） 出现崩溃级别的bug： 回到上一个可用稳定的历史版本

（2）严重

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

（3）一般

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

（4）建议（次要）

建议性的，提示信息重叠（看不清楚），界面排版不符合用户使用的习惯，颜色不符合软件使用场景

5. bug 生命周期

一个bug从无到有的各种状态

10.测试人员因为一个bug和开发人员产生冲突，该怎么做？

1.检查自己的BUG描述，是否描述清楚

2.可以从用户角度考虑，说服开发人员

3.BUG定级要有理有据，符合公司规范

4.测试人员要不断提升自己的专业技能和业务水平 权威性

5.找产品经理去讨论问题的解决方案

如何设置弱网：

Charles：设置弱网

11. 测试用例的设计方法

11.1 用例篇

1.从整体角度设计分析测试用例

​ 基于需求（软件设计文档）

​ 用户需求------产品设计开发文档------开发------测试------上线

​ 用户 产品经理

​ 业务人员

（1）验证需求的正确性和合理性

（2）分析需求，细化需求，从需求中分解出测试项，根据测试项找出功能， 进行测试用例的编写

11.2 具体的设计测试用例的方法

11.2.1 等价类

等价类就是把输入划分为若干个等价类，从每一个等价类中取出一个测试用例，如果这个测试用例能够测试通过，那么我们就是说这个测试用例代表队等价类测试通过

使用场景： 测试用例无法穷举，我们无法一一进行测试

有效等价类：符合程序规格说明的数据集合

无效等价类：不符合软件需求规格说明的数据集合

11.2.2 边界值

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

针对值的左右两个边界都要进行测试

有效等价类 无效等价类 边界值（优先级最高）

11.2. 3 因果图法

当输入很多，并且不同的额输入组合对应这不同的输出，这个时候用因果图法来分析不同输入组合和输出之间的对应关系

因果图：逻辑图 恒等 与 或 非

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

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

2.找出输入和输出之间的关系

3.画因果图

4.画判定表

5.把判定表转换成测试用例