软件测试基础

小王不迷糊

已于 2023-03-04 22:24:48 修改

阅读量842

点赞数

分类专栏：软件测试文章标签：压力测试单元测试测试工具

于 2023-02-19 21:47:29 首次发布

本文链接：https://blog.csdn.net/qq_45283185/article/details/128141843

版权

软件测试专栏收录该内容

4 篇文章 0 订阅

订阅专栏

文章目录

前言
一、软件测试入门
二、软件测试基础
三、Bug
四、测试用例
五、测试分类

前言

记录软件测试的基础知识以及一些测试工具的使用。

一、软件测试入门

1.什么是软件测试？

软件测试就是验证软件产品特性是否满足用户的需求。（举例）

2.测试和开发的区别

开发广度小，专业度高
测试广度大，专业度低一点

3.调试和测试的区别

目的不同：调式是发现问题并且解决问题；测试时发现问题。
角色不同：调试是开发人员来执行；测试是测试人员、开发人员等。
阶段不同：调试主要在编码阶段；测试贯穿于软件的整个生命周期。

4.一些常问面试题

（1）走测试岗位为什么还要学习开发知识？
1）测试人员也需要进行代码编写；
2）学习开发知识是为了更好的提高测试质量。
（2）为什么不走开发岗位而走测试岗位？
1）个人兴趣爱好；
2）对测试的理解；
3）走测试岗位还要学习开发知识；
（3）软件测试的岗位有哪些？（软件测试工程师、测试开发工程师、性能测试工程师）
1）软件测试工程师
2）软件测试开发工程师（开发指开发效能工具，提升测试质量和效率）

5.测试人员需要具备的素质

（1）综合能力：（表达、文字、开发、快速学习）
（2）优秀的测试用例设计能力
（3）掌握自动化测试技术
（4）探索性思维
（5）兴趣（责任和压力）
需要测试人员具备良好的产品思维。

二、软件测试基础

1.需求

（1）用户需求：可简单理解为甲方的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。
（2）软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
开发人员和测试人员的直接工作依据就是软件需求。

2.测试用例

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合主要包含：测试环境、操作步骤、测试数据、预期结果等。

3.Bug

当且仅当规格说明（需求文档/产品规格说明书）是存在的并且正确，程序与规格说明之间的不匹配才是错误。需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

4.软件的生命周期

产品/软件的生命周期：需求分析->计划->设计->编码->测试->运行维护
（1）需求分析：例如市场分析、投入和收益的占比、技术上的实现；
（2）计划：计划项目什么时候开始，什么时候结束，耗时多久；
（3）设计：将一个大的需求拆分成一个个具体可实施的任务，进行技术设计（设计哪些接口，采用什么框架，采用哪些技术等）；
（4）编码：开发人员参考需求文档和技术文档等等来进行代码开发；
（5）测试：测试人员参考测试用例来设；
（6）运行维护：修复性维护，对项目中没有发现的问题要及时进行修复；完善性维护，对功能进行完善；预防性维护，为了避免产品在线上运行期间出现意想不到的问题，需要进行一些预防的手段。

软件测试的生命周期：需求分析->测试计划->测试设计与开发->测试执行->测试评估
（1）需求分析：测试人员从用户角度思考问题：软件需求是否合理；技术角度思考问题：技术上是否可行，是否还有优化空间；测试的角度思考问题：是否存在业务逻辑冗余/冲突。
（2）测试计划：开始/结束测试时间，耗时多久。
（3）测试设计与开发：写测试文档，明确标注使用到的测试方法，测试工具，测试形式等；参考需求文档、技术文档等编写测试用例。
（4）测试执行：充分利用测试用例和其他工具对项目尽可能做到全方面的覆盖测试。
（5）测试评估：评估产品是否存在其他的质量问题功能演示。

5.开发模型

（1）瀑布模型
在这里插入图片描述
特点：
1.线性结构，每个阶段只执行一次。
2.是其他模型的基础框架。

缺点：
1.测试置后。（前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去及早修复的机会；必须留有足够的时间给测试活动，否则导致测试不充分，把缺陷暴露给用户）
2.周期太长，产品很迟才能够被看到和使用。

适用场景：需求固定的小项目。

（2）螺旋模型
特点：螺旋模型中增加了风险分析和原型。

缺点：
1.项目中可能存在的风险性与风险管理人员技术水平有直接关系。
2.需要人员、资金、时间的增加和投入可能导致项目的成本太高。

适用场景：规模庞大、复杂度高、风险大的项目。

（3）增量模型和迭代模型
增量模型里把大的需求划分成一个个可以独立开发上线的功能。而迭代模型则是先开发基础版本，然后再在基础版本上不断地进行功能的完善。

（4）敏捷模型
1.scrum模型–三个角色五个会议
1）三个角色：产品经理、项目经理、研发团队组成。
2）五个重要会议：
发布计划会议：产品经理从需求池中拿出需求进行发布计划会议，最终确定本次迭代要完成的需求。
迭代计划会议：进行任务拆分，确定责任人，工时的评估。
每日会议：每天进行的会议，明确昨天做了什么，今天要做什么，当前遇到的问题，了解当前的项目进度。每日会议结束需要给出“可交付软件”。
演示会议：产出用户需求，如果产出用户需求则将其放到需求池中。
回顾会议：总结当前迭代周期的不足，并在下一次迭代进行优化。
特点：轻流程、轻文档、重目标、重产出。
在这里插入图片描述

（5）测试模型
V模型
特点：
1.测试过程中存在的不同类型的测试。
2.测试阶段的参考标准以前面对应阶段为准。
缺点：测试后置

W模型（双V模型）
1.有一个开发模型和测试模型
2.前面一个阶段完成，才能进行下一个阶段
特点：W模型重流程，不能迎接变化，不适用于敏捷模型。
优点：测试阶段从需求就开始介入。

三、Bug

1.如何创建bug

创建bug的要素：问题出现的版本、问题出现的环境、出现步骤、预期结果、实际结果。

2.Bug的级别

崩溃、严重、一般、次要（工作中按照公司要求）。

3.Bug的生命周期

测试人员在执行测试的过程中，如有发现Bug，需要在对应的Bug管理平台来创建Bug。
（1）New：测试人员创建一个Bug。
（2）Open：开发人员要去确认是否是Bug，是Bug状态就改为open。
（3）Fixed：开发人员在修复完成之后将Bug状态改为Fixed。
（4）Rejected：开发人员确认不是Bug，状态就改为Rejected。
（5）Delay：确实是Bug之后，如果Bug优先级比较低且开发人员不能立即修复Bug，状态就改为Delay。
（6）Closed：Bug确认修复完成，测试人员将Bug改为closed。
（7）Reopen：Bug确认修复未完成，测试人员将Bug状态改为Reopen。
在这里插入图片描述

不管Bug到哪个分支，最终都要走到终态。

4.跟开发产生争执怎么办

（1）多反思自己，是不是Bug创建的时候描述不太清除。
（2）开发人员对Bug级别不认可，Bug定级一定要有理有据。测试人员需要明确企业Bug定级规范，拿着规范跟开发人员沟通。
（3）合理友好的进行沟通，站在用户的角度反问：如果你是用户，你能接受这种功能吗？
（4）提高自身技术水平，不仅能够发现问题，最好也能够提出解决方案，供开发参考。
（5）如果确实是Bug，友好沟通已经不能解决问题，不要争吵，可以召开Bug评审。

四、测试用例

1.测试用例的万能公式

功能测试+性能测试+界面测试+兼容性测试+易用测试+安全测试
举例：（1）水杯的测试用例。
在这里插入图片描述
（2）登录页面测试用例

2.设计测试用例的方法

基于需求的设计方法

（1）等价类

依据需求输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少
的测试用例达到尽量多的功能覆盖，解决不能穷举测试的问题。
有效等价类：针对需求文档的要求是有意义的集合。
无效等价类：针对需求文档的要求是没有意义的集合。
步骤：
1、确认有效等价类和无效等价类。
2、编写测试用例。