文章目录

• 一、基础概念
• • 1、什么是软件测试
  • 2、软件测试的目的
  • 3、软件测试的原则
  • 4、软件测试的分类
  • • 4.1 按照开发阶段分类
    • 4.2 按照软件特性分类
    • 4.3 按照测试技术分类
    • 4.4 按照测试运行主体分类
    • 4.5 按照代码运行分类
    • 4.6 其他测试
  • 5、为什么想做测试
  • 6、怎么看待软件测试的潜力和挑战
  • 7、软件测试的核心竞争力是什么
  • 8、自动化测试与手动的优缺点
  • 9、软件测试要学什么
  • 10、测试项目的具体工作是什么
  • 11、测试的基本流程
  • 12、测试计划包含哪些内容
  • 13、测试 告包含那些内容
• 二、软件开发模型
• • 1、瀑布模型
  • 2、螺旋模型
  • 3、敏捷开发模型
  • 4.其他模型
• 三、软件测试模型
• • 1、V模型
  • 2、W模型
  • 3、H模型
• 四、按照开发阶段进行测试
• • 1、单元测试
  • 2、集成测试
  • 3、确认测试
  • 4、系统测试
  • 4、回归测试
  • 5、验收测试
  • 6、集成测试和系统测试的区别以及应用场景

一、基础概念

1、什么是软件测试

软件测试就是在软件的开发过程中，根据需求规格说明设计测试用例，手工或者利用测试工具有计划的执行程序，以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，并追踪和验证这些bug，保证bug被修复的过程。

测试是软件开发中不可或缺的一环，测试通过经济，高效的方法，捕捉软件中的错误，从而达到保重软件内在质量的目的。

自动化测试有时候还需要根据不同的测试需要编写不同的测试工具，设计和维护测试系统。

测试是为了证明程序有错，而不是为了证明程序无错。

测试不仅需要正向思维，还需要反向思维。

2、软件测试的目的

1）通过修正错误和缺陷可以提高软件质量，避免软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

2）利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的开发和测试中重复同样的的错误。

3）采用更加高效的测试管理手段提高软测的效率和软件产品的质量。

3、软件测试的原则

1)所有的软件测试应该溯源到用户的需求

2)尽早的将软件测试贯穿到软件开发的全过程中

3)完全测试是不可能，测试需要中止

4)测试无法保证软件中完全没有缺陷

5)充分注意测试中错误集群现象

6)应避免自己检测自己的程序

7)应避免测试的随意性

4、软件测试的分类

4.1 按照开发阶段分类

• 单元测试、集成测试、系统测试、验收测试

4.2 按照软件特性分类

1）功能测试

功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。测试时按照科学方法设计的测试用例执行测试，在优先保证测试用例执行完全的前提下，再根据对业务的了解和经验性的判断进行探索性测试。

2）性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

3）界面测试

界面测试简称UI测试，界面为用户与软件交互最直接的层，所以更注重用户的体验性，主要从用户的感官、交互、浏览、情感和体验出发。具体测试用户界面的功能模块布局是否合理，整体风格是否统一，各个控件的放置位置是否符合客户使用习惯，是否符合操作便捷，导航是否简单易懂，界面中文字是否正确，命名是否统一，页面美观，文字、图片组合是否完美等等。测试时可以按照最终用户具体的需求，以及通用的用户体验原则进行测试list的编写，然后测试人员根据list执行。

4）兼容测试

兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的 络等环境中是否能够很友好的运行的测试。通常兼容性测试为软件在不同浏览器、操作系统和分辨率下的兼容测试。测试时测试人员按照软件的具体兼容性需求进行测试。

5）易用性测试

考察评定软件的易学易用性，各个功能是否易于完成，软件界面是否友好等方面进行测试。测试时可以根据用户需求，以及同类行业软件对易用性的通用原则列出测试list，然后测试人员根据list执行。

4.3 按照测试技术分类

• 黑盒测试
• 白盒测试
• 灰盒测试

4.4 按照测试运行主体分类

• 手工测试（功能测试）：点点点
• 自动化测试：利用测试工具或者写代码的方式测试

4.5 按照代码运行分类

• 静态测试、动态测试

4.6 其他测试

• 回归测试、冒烟测试、随机测试、猴子测试

5、为什么想做测试

1）逻辑性还可以，可以理性分析问题、思考比较全面，有耐心。

软件测试在前期需要分析需求文档和各种项目需求书，制定测试计划，设计测试用例，后期执行测试用例的时候需要判断逻辑的正确性、对可行性逻辑分析、

2）有团队协作能力、善于沟通

做软件测试需要和技术人员、产品人员、上下级沟通，和组员配合完成测试任务，配合开发人员重现缺陷。

3）有责任
要敢承担责任，敢坚持自己的意见

缺陷洞察能力，一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；

4）专业技术能力，

掌握测试基础知识、计算机 络、数据库等基础知识，熟练运用测试工具

5）学习能力，适应性强，抗压

6、怎么看待软件测试的潜力和挑战

软件测试是正在快速发展，充满挑战的领域。尽管现在许多自动化测试软件的出现使得传统手工测试的方式被代替，但自动化测试工具的开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项测试中仍然需要大量具有专业技能与专业素养的测试人员，并且随着云计算、物联 、大数据的发展，传统的测试技术可能不再适用，测试人员也因此面临着挑战，需要深入了解新场景并针对不同场景尝试新的测试方法，同时敏捷测试、Devops的出现也显示了软件测试的潜力。

7、软件测试的核心竞争力是什么

测试人员的核心竞争力在于提早发现问题，并能够发现别人无法发现的问题。
1、早发现问题：问题发现的越早，解决的成本越低。如果一个需求在还未实现的时候就能发现需求的漏洞，那么这种问题的价值是最高的。
2、发现别人无法发现的问题：所有人都能发现的问题，你发现了，那就证明你是可以被替代的。别人发现不了，而你可以发现，那么你就是无法被替代。

8、自动化测试与手动的优缺点

手工测试缺点：

• 1、重复的手工回归测试，代价昂贵、容易出错。
• 2、依赖于软件测试人员的能力。

手工测试优点：

• 1、测试人员具有经验和对错误的猜测能力。
• 2、测试人员具有审美能力和心理体验。
• 3、测试人员具有是非判断和逻辑推理能力。

自动化测试优点：

• 1、可以对程序的新版本自动执行回归测试，看以前发生在旧版本中的错误和缺陷是否在新版本中出现。用自动化的方式做回归测试，可以极大提高测试效率，缩短回归测试时间。

• 2、更好地利用资源，节省时间和人力。利用自动化测试去做一些繁琐且重复的测试，测试人员就可以去设计更好的测试用例，或者去做那些不适合自动测试的测试，可以提高测试的效率。

• 3、自动化测试可以执行一些手工测试困难或不可能进行的测试，比如压力测试、并发测试。

• 4、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，也就不存在执行过程中由于人为因素出现错误，因此一旦测试通过，就会提高用户对于软件的信任度。

• 5、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

自动化测试缺点：

• 1、不能取代手工测试， 手工测试比自动测试发现的缺陷更多

• 2、对测试质量的依赖性极大

• 3、测试自动化不能提高有效性

• 4、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。

• 5、 工具本身并无想像力

自动化测试流程：

• 首先判断这个项目是不是和推广自动化测试
• 然后对项目做需求分析，制订测试计划
• 搭建自动化测试框架
• 设计测试用例
• 执行测试
• 评估

9、软件测试要学什么

一、功能测试

计算机基础，软件生命周期、开发模型、测试模型。软件测试概念，软件测试方法及分类、热门领域测试技巧。Linux系统，数据库的定义及基本概念，MySQL、Oracle。搭建功能测试实战环境，Linux环境下B/S结构产品测试项目等内容。

二、自动化测试

Python，自动化测试分类及自动化适用的项目。Selenium，使用Selenium对 站的核心功能进行自动化测试。Appium，Monkey，使用Appium对APP核心功能进行测试验证，对APP功能进行评估等内容。

三、接口测试

接口测试，Postman安装使用，Fiddler安装使用，Web和手机抓包，基本设置方法。Jmeter，搭建接口测试环境，分析业务流程，设计测试用例，使用Jmeter执行测试用例。Web安全核心理论、Web漏洞及防御、渗透测试、SQL注入、XSS跨站脚本、AppScan等内容。

四、性能测试

性能测试，VuGen，Controller，Analysis，性能测试调优，数据库调优，性能测试指标，Jmeter在性能测试中的应用。搭建测试环境，编写测试计划和测试用例，设置和运行场景，监控和收集数据，写分析 告，项目综合评审等内容

需要的知识：
软件测试基础理论知识，如黑盒测试、白盒测试等；
考编程语言基础，如C/C++、java、python等；
自动化测试工具，如Selenium、Appium、Robotium等；
计算机基础知识，如数据库、Linux、计算机 络等；
测试框架，如JUnit等。

10、测试项目的具体工作是什么

搭建测试环境

撰写测试用例

执行测试用例

写测试计划，测试 告

测试，并提交BUG表单

跟踪bug修改情况

执行自动化测试，编写脚本，执行，分析， 告

进行性能测试，压力测试等其他测试，执行，分析，调优， 告

11、测试的基本流程

• 获取测试需求
• 编写测试计划
• 制订测试方案
• 设计和开发测试用例
• 执行测试
• 提交缺陷
• 测试分析和评审
• 测试总结
• 准备下一版本测试

需求的覆盖程度 = 被测试用例覆盖的需求数/需求总点数

12、测试计划包含哪些内容

软件测试计划中应该包括什么内容/p>

测试计划的内容会因不同的项目以及项目的大小而有所不同，一般而言在测试计划中应该清晰描述以下内容：

1、 测试目标：

• 对测试目标进行简要的描述。

2、 测试概要：

• 摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。

3、 测试范围：

• 测试软件需测试的范围和优先级，
• 哪些需要重点测试、哪些无需测试或无法测试或推迟测试。

4、 重点事项：

• 列出需要测试的软件的所有的主要功能和测试重点，
• 这部分应该能和测试案例设计相对应和互相检查。

5、 质量目标：

• 制定测试软件的产品质量目标和软件测试目标。

6、 资源需求：

• 进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。

7、 人员组织：

• 需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。

8、 测试策略：

• 制定测试整体策略、所使用的测试技术和方法。

9、 发布提交：

• 在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。

10、 测试进度和任务人员安排：

• 将测试的计划合理的分配到不同的测试人员，并注意先后顺序
• 如果开发的Release不确定，可以给出测试的时间段
• 对于长期大型的测试计划，可以使用里程碑来表示进度的变化。

11、 测试开始/完成/延迟/继续的标准：

• 制定测试开始和完成的标准；
• 某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。

12、 风险分析：

• 需要考虑测试计划中可能的风险和解决方法。

13、测试 告包含那些内容

【测试新人必备】测试 告如何编写/p>

• 根据上述测试范围测试点进行测试用例的设计。主要采用黑盒用例设计方法等价类划分法、边界值分析法、错误推测法、场景法。

1）功能测试：

• 确保测试对象的功能正常，
• 其中包括业务流程、数据处理、边界值等功能。

2）用户界面 (UI) 测试：

• 核实用户与软件之间的交互，
• 确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能，
• 确保 UI 中的对象按照预期的方式运行
• 确保各个窗口风格（包括颜色、字体、提示信息、图标、等等）都与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯

3）流程测试：

• 核实实际业务流程在系统中的完整正确实现。
• 应确保各业务流程内部数据流转及流程之间接口数据的正确，确保角色权限对流程的操作的限制的正确性

4）安全性测试：

• 确保用户、管理员的密码管理安全、应用程序级别与系统级别的安全的安全性

5）兼容性测试：

• 确保系统在各种不同版本不同类项浏览器下均能正常实现其功能

3.1 测试执行情况与记录

特点：

• 瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以制定精确的计划和进度。

• 测试对象非常明确，即程序。

• 在瀑布模型中，测试被认为是在软件开发过程的后期阶段进行的“一次性”活动，这带来一个巨大的缺点，因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。

• 强调时间顺序的严格执行，前阶段不完成，后阶段不开始

• 不适应用户需求的变化

• 线性开发，用户等到整个过程的末期才能见到开发成果，从而增加了开发风险

2、螺旋模型

引入了风险分析

测试驱动开发

4.其他模型

迭代模型：

• 强调开发的深入；初级版本稳定可运行

增量模型：

• 把软件分割成独立的模块，分批次的完成与交付。

• 打破了原有的软件结构和框架，可能带来一定的风险

• 一般与迭代模型一起用

快速原型模型：

• 就是一个模型，可以模拟操作，简单运行

• Axure，制作原型

三、软件测试模型

1、V模型

• W 模型从 V 模型演化过来，实际上开发是 V，测试是并行的 V，测试与开发 同步进行，有利于尽早地全面的发现问题。
• 测试伴随整个软件开发周期。
• 测试的对象不仅仅是程序，需求、设计等同样要测试。

缺点：

• W 模型中，需求、设计、编码等活动被视为串行的，同时测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。

3、H模型

特点：

• 它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。测试贯穿产品整个生命周期，与其他流程并发地进行。
• 软件测试不仅仅指测试的执行，还包括很多其他的活动（计划、需求分析、用例设计、环境搭建、提交缺陷、评估总结等）。
• 当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
• 软件测试要尽早准备，尽早执行。
• 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

测试和开发需要怎么结合才能使软件的质量得到更好的保障

参考回答：

测试和开发应该按照W模型的方式进行结合，测试和开发同步进行，能够尽早发现软件缺陷，降低软件开发的成本。

在V模型中，测试过程被加在开发过程的后半部分，单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。

V模型的缺陷在于仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，因此需求阶段的缺陷很可能一直到后期的验收测试才被发现，此时进行弥补将耗费大量人力物力资源。

相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

W模型中测试的活动与软件开发同步进行，测试的对象不仅仅是程序，还包括需求和设计，因此能够尽早发现软件缺陷，降低软件开发的成本。

四、按照开发阶段进行测试

1、单元测试

完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。

意义以及是否可行：

• 单元测试可以有效地测试某个程序模块的行为，是未来重构代码的信心保证。事前可以保证质量，事后可以快速复现问题，并在修改代码后做回归自测。

• 可行性考虑的是要用一些可行的方法做到关键的代码可测试，如通过边界条件、等价类划分、错误、因果，设计测试用例要覆盖常用的输入组合、边界条件和异常。

如何进行单元测试：

１、创建单元测试，创建单元测试大致可以分为两类：

• 整体测试，整体测试是在类名称上右击鼠标，在下拉菜单中点击创建单元测试选项。这样就可以为整个类创建单元测试了，这时他会为整个类可以被测试的内容全部添加测试方法。开发人员直接在这些自动生成的测试方法中添加单元测试代码就可以了。

• 单独测试，如果只想单独对某个方法、属性、字段进行测试，则可以将鼠标焦点放在这个待测试的项目名称之上，然后点击鼠标右键，在右键菜单中选择创建单元测试选项。这样就可以单独为某个方法创建单元测试了。

2、运行单元测试

3、查看测试结果

2、集成测试

集成测试指的是通过测试发现与模块接口有关的问题。

目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。

• 自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。

• 自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。

3、确认测试

也称为冒烟测试，一般不作为正式的测试环节，通过了确认测试的软件才具备了进入系统测试的资格。

• 确认（validation）：通过检查和提供客观证据来证实特定目的的功能或者应用是否已经实现。

• 验证（verification）：通过检查和提供客观证据来证实指定的需求是否满足

• 先确认是否有，在验证是否满足需求。

4、系统测试

系统测试是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。

系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。

系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。

因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。

系统测试能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此系统测试是很重要的测试。

4、回归测试

回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。

理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。

回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

5、验收测试

验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

验收测试包括Alpha测试和Beta测试。

• Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。开发者对用户的指导下进行测试，开发者负责记录发现的错误和使用中遇到的问题

• Beta测试：在开发者不能控制的环境中的真实应用，由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，由用户记录测试中遇到的问题并 告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。

验收测试合格通过的准则是：

• 1）软件需求分析说明书中所定义的功能全部实现，性能指标全部达到要求。
• 2）所有测试项中没有残余的一级、二级、三级错误
• 3）立项审批表、需求分析文档、设计文档和编码实现一致
• 4）验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析 告）

6、集成测试和系统测试的区别以及应用场景

区别：

• 1、计划和用例编制的先后顺序：

从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。

• 2、用例的粒度：

系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。

• 3、执行测试的顺序：

先执行集成测试，待集成测试出的问题修复之后，再做系统测试。

应用场景：

集成测试：

• 完成单元测试后，各模块联调测试；

• 集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；

• 可以是整个产品的集成测试，也可以是大模块的集成测试；

• 集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。

• 集成测试对测试人员的编写脚本能力要求比较高。

• 测试方法一般选用黑盒测试和白盒测试相结合。

系统测试：

• 针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。
• 系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。
• 做系统测试要严格按照《需求规格说明书》，以它为标准。
• 测试方法一般都使用黑盒测试法。