文章目录
- [1、 简单做一下自我介绍](#1、 简单做一下自我介绍)
- 2.简要介绍一下项目/你负责的模块/选一个模块说一下你设计的用例
- 3、幂等性
- 4、软件生存周期及其模型是什么？
- 5、有哪些软件测试模型
1、 简单做一下自我介绍
我叫XXX，今年XX岁，XX人，毕业于XXXXXXX，XXX专业，毕业后就在XXXX公司任职XXXX岗位，是XXX平台业务。我的职责主要测试XXX业务，我在职期间主要负责测试XXX。以上这就是我的简短自我介绍。
2.简要介绍一下项目/你负责的模块/选一个模块说一下你设计的用例
我设计的测试用例主要从下面这些方面执行。
点击支付---> 选择支付方式 ---> 确认金额---> 输入密码 ---> 成功支付
同时使用 Postman 执行接口测试，测试各个支付渠道的支付、风控、对账、定时任务和异步任务逻辑、前端界面对比展示在旧新重写系统的一致性；测试灰度逻辑、新旧系统切换、数据库和Redis 表迁移和读写，配合服务部署和发布上线。
3、幂等性
什么是幂等性？为什要实现幂等？如何解决幂等性？如何测试幂等？
4、软件生存周期及其模型是什么？
软件生存周期(software life circle)又称软件生命期，生存期。它是指从形成软件开发概念开始，到软件投入使用，再到软件失去价值而消亡的整个过程。软件从开始开发到最终交付使用的整个过程，它包括以下几个阶段：
需求分析：确定软件的功能需求和用户需求。
设计：设计软件的结构和模块，确定软件的架构和接口。
编码：根据设计文档编写程序代码。
测试：对程序进行测试，发现并修复错误。
部署：将程序部署到目标环境中，让用户可以使用。
维护：对软件进行修复和改进，以保证其正常运行。
瀑布模型
（最经典的模型）
瀑布模型特点：
- 阶段间具有有序性和依赖性。阶段必须完成之后，才能进行下一阶段。瀑布模型提出之前，软件开发是无序化的，这就导致了开发效率低的问题，而瀑布模型的出现使得软件开发变得有序，软件的效率和质量都大大地提高。
- 推迟实现。其实真正编码之前，会进行大量的分析与设计工作。在构建大型应用时，软件的维护消耗的精力与物力远远超过开发。所以为了减少问题的产生，降低维护的代价，所以会做好分析与设计工作，推迟编码。
- 文档驱动。每一个阶段都会产生文档。这样有两个好处，第一，每个阶段结束前都会对文档进行审查，审查严格之后才会交给下一阶段，这样是质量得到了保证，也为以后维护提供了宝贵的资料。第二，每一个阶段开始前，开发人员可以参考前一阶段的文档，快速开始本阶段的工作。
瀑布模型缺点：
- 瀑布模型的缺点主要在于在实际开发中不可能不会出现问题，一旦出现问题之后，回溯到前面阶段的代价实在太大，有可能会终止项目。
- 由于产品是一次性交付给用户，如果用户的需求与实际的产品不符，同样会产生上述回溯到前面阶段代价太大的问题。
原型模型
基于用户的需求和实际产品不相符的情况，那就出现了一种模型叫做原型模型。
原型模型特点：
- 不断快速修改系统，以期尽早用户见面，用户提出意见后，又快速修改，交付给用户查看。
- 不注重维护和质量。
原型模型的缺点：
- 基于原型模型的特点，它是不可能作为最终系统交付给用户的，原型系统最终可能会被废弃，可以认为它的作用只是为了不断明确用户的请求。
- 不适合小型项目。简单来说，用原型不断修改以满足用户是需要代价的，如果是小型项目，受众不广，资金不足，只搞个原型估计就让项目夭折了。
RAD模型
基于前面两个模型，你就知道这个模型是干啥的了。我如果能集合原型模型和瀑布模型的优点，不是很好？
RAD模型的基本思想是采用大量的人力物力对软件的每个组件进行开发，然后集成成最终的产品交互给用户。
所以，RAD模型具有如下特点：
- 开发周期短。（兼具原型快速的优势）
- 产品质量高。（每个组件的开发其实就看得出来瀑布模型的影子）
但是，RAD模型就完美了吗？
不是 ，RAD模型需要大量的人力和物力，软件开发过程不止注重技术更看重管理。如果有一个小组撂挑子，说我不干了，那么整个软件的开发不就得推迟？所以，RAD模型的这一个特点就不满足之前Boehm提出的开发人员应该小而精的观点。
上面所述的模型都有一个显著的特征，即都是一次性交付给用户，这样做是具有风险的，因为技术有革新，市场有变化，当你的产品开发出来之后，可能就不符合时代的需求了。所以，又有另外的模型被相继地提出。
增量模型
增量模型的特点：
- 原型特点：由于是不开发增量，然后和客户见面，开发增量，然后和客户见面。这样就能符合客户的需求，顺应市场变化。
- RAD特点：每项工作都有相应的小组。这样就兼顾了快速的特点。
- 瀑布模型特点：这就不啰嗦了，基本每一个模型都能或多或少看到瀑布模型的影子。
- 不需要大量的人力：这里应该和前面的RAD做出区别，这里的增量并不是一次性共同开发，而是根据用户需求逐次开发，所以上一阶段个增量的开发小组仍可以接手下一个增量的开发。
- 代价低：即时开发的增量不满足用户需求，那么对一个增量进行修改，相比对整个软件进行修改的代价要小得多。
但是增量模型有缺点没有？
还是有的，我们要考虑增加一个增量时是否对原来的软件造成影响，如果影响过大，那么这个增量反而不好。
但是，采用增量模型是可取的，为了规避开发不合适的增量，那么就得在设计上花功夫，但是这种牺牲是值得的。
螺旋模型
螺旋模型的特点：
- 风险驱动：每一个阶段（看图可理解为一圈为一个阶段）都会开发一个原型来进行风险分析，当风险分析合格时才会进行下一阶段。
- 瀑布模型特点：从环内到环外，可看到瀑布模型的特点。
- 增量模型特点：每一次螺旋可看做是一次增量。
螺旋模型的缺点 ：
螺旋模型是风险驱动的，项目越大，风险越大。原型进行风险分析是需要代价的，如果砸在风险分析的钱太多，那么就可能导致项目终止。所以，螺旋模型适用于内部开发。
RUP模型
RUP的特点为迭代式增量开发，用例驱动，以体系架构为中心。
1、迭代模型
RUP可以看做是一个二维的图。
横向划分了四个阶段：初始，细化，构造，交付。
纵向是若干工作流。
2、用例驱动
用例是RUP方法论中一个非常重要的概念。简单地说，一个用例就是系统的一个功能。在系统分析和系统设计中，用例被用来将一个复杂的庞大系统分割、定义成一个个小的单元，这个小的单元就是用例。然后以每个小的单元为对象进行开发。按照RUP过程模型的描述，用例贯穿整个软件开发的生命周期。在需求分析中，客户或用户对用例进行描述，在系统分布和系统设计过程中，设计师对用例进行分析，在开发实现过程中，开发编程人员对用例进行实现，在测试过程中，测试人员对用例进行检验。
3、以架构为中心
RUP的第三大特征是它强调软件开发是以构架为中心的。构架设计(ArchitecturalDesign)是系统设计的一个重要组成部分。在构架设计过程中，设计师(Architect)必须完成对技术和运行平台的选取，整个项目的基础框架( Framework)的设计，完成对公共组件的设计，如审计( Auditing)系统、日志(Iog)系统、错误处理(Exception Handling)系统、安全(Security)系统等。设计师必须对系统的可扩展性( Extensibility)、安全性(Security)、可维护性( Maintainability)、可延拓性(Scalability)、可重用性(Reusability)和运行速度(Performance)提出可行的解决方案。
如果体系架构做得不好，迭代式开发就不好开展。
RUP的一个缺点就是整个模型比较麻烦，不好操作。
总之，针对不同的开发应用场景，应当采用合适的模型进行开发。
5、有哪些软件测试模型
软件测试和软件开发一样，也有一整套的流程和模型。
软件测试流程：
软件过程模型可分为V，W，H，X模型，重点掌握V和W模型，并了解H和X模型的要点。
V模型
缺点：
- 软件测试在编码阶段才开始，也就是说它的测试对象仍然是程序。
- 软件测试最后一个阶段才进行针对需求的验收测试，如果测试出问题，将会导致很大的代价。
- 软件测试不支持迭代，不适合需求变化的现状（其实和开发模型有关）。
W模型
W模型其实是2个V模型，理解W模型，应和V模型做比较。
优点：
- 软件测试在需求阶段就介入，对文件和程序都进行了测试（对应V模型缺点1）。
- 软件测试在需求阶段就介入，满足了软件测试应尽早参加的原则（对比V模型缺点2）。
缺点：
软件测试不支持迭代，不适合需求变化的现状（其实和开发模型有关）。
H模型
简单来说，V模型和X模型其实开发和测试是没分开的，这个模型最大的特点就是将测试与开发分离出来。那么它该怎么测试呢？只需要对开发模型的产物进行测试即可（如对上面的设计完成之后的文档进行测试）。
这类模型体现在软件测试独立的部门或是专门做测试外包的公司。
X模型
X模型最大的特点就是探索性测试。简单来说就是有经验的测试人员不完全按照特定的测试计划进行测试，而是进行探索测试。