转载声明：文章来源：https://blog.csdn.net/nhb687096/article/details/129264735

一、软件测试入门

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、编写测试用例。
（2）边界值
（3）因果图（判定表）
判定表设计测试用例的步骤：
1、确定输入条件和输出条件。
2、找出输入条件和输出条件之间的关系。
3、画判定表。
4、根据判定表编写测试用例。
（4）正交排列
正交实验设计法指从大量的实验中挑选出适量的、有代表性的点，依据“正交表”从而合理的设计出测试用例。
根据正交表设计测试用例的步骤：
1、找出因素数和水平数；
2、生成正交表；
3、根据正交表来编写测试用例；
4、补充可能存在遗漏但是非常重要的测试用例。
（5）场景设计法
一个思路引导的作用。
（6）错误猜测法
依赖测试人员的工作经验和积累。

五、测试分类

1.按照测试对象划分
（1）可靠性测试
可靠性是指系统正常运行的能力或程度。
可靠性=正常运行时间/（正常运行时间+非正常运行时间）*100%
（2）容错性测试
容错性测试是指
（3）安装卸载测试
工作中很容易遗漏安装和卸载的测试。
（4）内存泄漏测试

2.按照是否查看代码划分
（1）黑盒测试
纯功能测试，不关心具体是怎么实现的。
（2）白盒测试
关注程序的内部实现。
（3）灰盒测试
介于黑盒和白盒之间。
为什么不能让灰盒测试取代黑盒测试和白盒测试？
灰盒测试没有白盒测试那么详尽，灰盒测试没有黑盒测试覆盖产品的广度大，所以灰盒测试不能取代黑白盒测试。
哪种测试方法用的多？
黑盒测试和白盒测试测试人员都会使用到，在工作中根据具体情况来结合白盒测试和黑盒测试。通常情况下对测试人员来说使用黑盒测试相对要多一点。

3.按照开发阶段划分
（1）单元测试
对程序“最小单元”进行测试。
（2）集成测试
（3）系统测试
（4）验收测试
冒烟测试
开发人员完成开发任务之后，交给测试人员进行测试的第一步。
回归测试
对历史版本、历史功能进行测试，保证功能都是符合要求的，借助自动化来进行回归测试。