软件测试基础知识记录-CSDN博客

本文链接：https://blog.csdn.net/AssassinTheD/article/details/142236365

杂谈

突然发现写博客对梳理知识和记录非常有用，所以我想多写几篇

预计的分类规划是：测试知识记录贴、Python记录贴、数据库/网络知识记录贴、k8s/Jenkins/docker项目管理、其他内容记录贴

反正我也是自己边学边总结

正文

工作几个月总结的理论知识，虽然测试的知识不会像数学一样具有绝对正确性，但至少基本概念不出大差错，于是做了一个记录，同时也方便自己查缺补漏和复习

什么是软件测试？

为了发现软件中出现的缺陷、错误、漏洞而执行程序的过程

测试的目的是什么？

验证软件是否符合需求；寻找软件中的缺陷；在用户的角度测试软件，提升软件质量；尽早地介入测试，降低项目成本。

测试有哪几个阶段？

大分类为4个，分别为单元测试、集成测试、系统测试、验收测试，但绝对不仅是4个，可以进行细分从而单拎出来表示阶段

单元测试的工作一般开发做，验证单元功能是否符合需求，测试没有代码权限不了解。

集成测试的工作就是根据接口文档进行外部接口测试，测试接口是否调用正确，请求方法、请求数据、响应数据是否符合要求；1.验证模块间的接口调用、数据是否有问题以及结构设计问题2.集成之后的功能实现是否达到要求。

系统测试就是执行测试用例验证测试场景与内部接口测试，验证系统的功能是否满足需求分析说明书/系统设计说明书的要求

其中系统测试又分为冒烟测试、功能测试（其他细分）、性能测试（其他细分）...（+软件质量模型的六个特性）

测试方法有哪些？

黑盒测试、白盒测试、灰盒测试、静态测试、动态测试

黑盒测试保证需求，测试各场景但不保证所有代码写的功能全部被测到；属于功能测试阶段

白盒测试保证代码都覆盖功能，但不保证完美符合需求；属于单元测试阶段

灰盒测试保证各个模块之间的功能实现，介于白盒和黑盒之间；属于集成测试阶段

软件研发流程

基本流程：

用户需求-概要设计-详细设计-开发编码-软件测试-系统实施-验收交付

详细版本：

前期调查-项目立项-用户需求-需求分析-需求分析评审-概要设计-概要设计评审-详细设计-详细设计评审-*(开发计划排期-开发编码-单元测试-前后端联调测试)-*(测试计划排期-编写测试用例-测试用例评审-集成测试)-开发提测-冒烟测试-功能测试第一轮-功能测试第二轮-性能测试-用户体验测试-现场实施试运行-回归测试-功能验收-交付-售后

注*(开发)与*(测试)，该部分表示并行。

软件迭代，测试主要参与流程为：详细设计评审-依据开发计划排期测试计划-编写测试用例-测试用例评审-等待开发提测-冒烟测试-功能测试-回归测试-发包

用例设计方法有哪些？

等价类、边界值、判定表，场景法、错误推断法、正交实验法、因果图

其中工作中最常用的就是等价类、边界值以及场景法。

等价类：把输入的数据分为有效等价类与无效等价类；有效等价类指的是根据需求说明书是合理且有意义的输入数据的集合，无效等价类是无意义，不合理的输入数据的集合。一条测试用例覆盖多个有效等价类，覆盖一个无效等价类（覆盖一个无效等价类不是指你只有一个异常场景）

边界值：属于等价类的补充，一般都是从等价类的边缘去寻找问题（为什么？因为开发也是人，是人就有可能会打错字）

场景法：模拟用户操作流程，一个事务的正确流程为基准，称为基本流；输入错误导致流程反复，但是依然可以完成流程为备选流；其他失败或者错误的流程称为异常流

为什么要设计测试用例？好处是什么？

因为

可以更加全面的测试了所有功能，保证覆盖率，跟踪测试进度，减少重复冗余的测试点提高测试效率。

好处

它是测试工作的依据，还可以进行复用；评估需求覆盖率、使得工作可重复；自动化测试的基础

测试用例由哪些组成？

用例编号、模块名称、用例名称、前置条件、操作步骤、预期结果、实际结果、优先级、执行人

如果是测试点，则分为用例编号、模块名称，测试点场景（一条简短的测试点需要包含用例名称、前置条件、操作步骤、预期结果的信息）、测试结论、优先级

bug的组成

分为系统开发性bug和设计缺陷bug

简单来说就是一个是开发代码写戳了或者没按需求说明书来，另一个是产品经理的功能设计有问题

bug类型、bug标题、bug详细描述、bug所属项目、bug所属模块、bug产生环境、bug优先级、bug等级、bug的操作步骤、bug实际的结果、期望的预期结果、bug状态、bug处理人、bug产生原因、bug解决方案、备注

说多几个少几个没什么大的关系，主要的几个不要忘

bug的等级

不同公司具体不同

1级致命：常规操作（正常流程）系统崩溃，流程中断，测试工作无法继续进行（冒烟测试），功能与需求严重不符合，数据泄露造成安全问题，涉及金钱计算，现场的需求以及现场bug

2级严重：关键控制点问题、功能只有部分实现，数据流校验错误；逻辑不通，性能问题，密码明文等，非常规操作（比如登录连续一直点好多次，一直登录然后退出反复操作之类的）

3级一般：通用性功能问题，字段未转义，显示缺失，界面排版出现现场不太可能出现的场景，列名与含义不一致，查询错误，没有边界值，删除没有提示

4级建议：易用性和建议性等文字错误，提示过于简短不清楚，界面不整齐，内容布局等（不纳入开发考核）

bug的生命周期？

发现-提交-确认-分配-修复-验证-关闭

测试人员发现bug，记录提交bug给开发，bug状态为待确认

开发人员确认是bug，开始修复bug，bug状态为开始解决

开发人员修复bug，bug状态为已解决

测试人员验证bug修复成功，bug状态为已验证通过，关闭

测试人员验证bug修复失败，bug状态为已验证失败，重新打开

开发人员再次修复bug，状态为已解决

测试人员再次验证直到bug修复成功

如何测试一支笔？

我看很多帖子写的都是功能细分就无了，全都是到处copy别人的，我自己感觉可以从工作角度来说明，这样应该更好点

使用对象？功能用途目标对象？特殊要求？

谁用？什么功能在什么地方用？特殊要求？

学生，签字笔，用于在干纸上签字，要求防水

小朋友，画笔，用于墙壁，要求可擦

从工作角度回答：

项目立项，需求分析，设计评审，编码，测试计划，测试方案，接口测试，功能测试，性能测试，现场联调部署，用户体验测试，上线，用户验收，维护

如果要测某个东西，我们先了解根据设计文档，了解这个东西的使用对象，外观设计，功能用途和特殊需求等，比如说这个笔，他的使用对象是学生，功能是在干纸上进行签字，外观要求黑色，通过站在用户的角度去弄清楚用户平常使用会出现什么问题，我们要确定测试的有哪些关注点和优先级，比如应该主要关注XXX，优先XXX，并编写详细的测试计划和方案，需要进行哪些测试，可以根据质量模型六个特性去细化提取测试点，编写用例，对于这只笔的用例可以通过功能性，性能、安全性、可靠性、易用性、可移植性对这个笔提取测试点，还有场景法啥的，思维可以开阔一点

功能：是否能正常写字，笔帽笔筒笔尖套尾塞是否配套，笔芯能否正常替换，出墨速度是否符合要求，出墨粗细是否符合要求，是否符合外观要求，特殊需求比如可擦

性能：功能要求10米测试不间断地写12米，最大摔落高度2米测试3米摔落，设计使用寿命100米，测试多个笔平均是多少米

安全性：材料是否符合规定，笔身是否有很锋利的地方，笔套是否设计通孔

可靠性：在温度很高和很低的地方能否正常书写，在不同的纸面或表面上能否正常书写

易用性：笔的外观是否和写字颜色一致，迅速辨别按动笔还是盖帽笔，按动或拔帽的力度

可移植性：笔盖是否笔筒是否通用，市面大部分笔盖、笔芯能否通用配套