1、测试的概念及目的：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
软件测试的主要工作内容是验证和确定
软件测试的目的：
测试是程序的执行过程，目的在于发现错误
一个成功的测试用例在于发现至今未发现的错误
一个成功的测试是发现了至今未发现的错误的测试
确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。
确保产品满足性能和效率的要求
确保产品是健壮的和适应用户环境的
软件测试的原则：
测试用例中一个必须部分是对预期输出或接过进行定义
程序员应避免测试自己编写的程序
编写软件的组织不应当测试自己编写的软件
应当彻底检查每个测试的执行结果
测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
检擦程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
应避免测试用例用后即弃，除非软件本身就是个一次性的软件
计划测试工作时不应默许假定不会发现错误
程序某部分存在更多错误的可能性，与该部分已经发现错误的数量成正比
软件测试是一项极富创造性，极具智力的挑战性的工作
2、测试分类
根据阶段分类：
单元测试、集成测试、系统测试、验收测试
单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。
集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。
系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。
验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。
按是否看代码
白盒测试、黑盒测试、灰盒测试
3、黑盒测试设计方法、
等边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法、正交实验法
4、白盒测试设计方法
语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖
5、测试人员在软件开发过程中的任务是什么？
1、尽可能早的找出系统中的Bug；
2、避免软件开发过程中缺陷的出现；
3、衡量软件的品质，保证系统的质量；
4、关注用户的需求，并保证系统符合用户需求。
总的目标是：确保软件的质量。
6、测试用例构成
用例编号 测试项目 测试标题 重要级别 预置条件 输入数据 执行步骤 预期结果
7、如何对网站进行端到端的测试？
需求分析——指定测试计划——设计测试用例——开展测试
首先，查找需求说明、网站设计等相关文档，分析测试需求。
制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
设计测试用例：
功能性测试可以包括，但不限于以下几个方面：
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。
提交功能的测试。
多媒体元素是否可以正确加载和显示。
多语言支持是否能够正确显示选择的语言等。
界面测试可以包括但不限于一下几个方面：
页面是否风格统一，美观
页面布局是否合理，重点内容和热点内容是否突出
控件是否正常使用
对于必须但未安装的控件，是否提供自动下载并安装的功能
文字检查
性能测试一般从以下两个方面考虑：
压力测试；负载测试；强度测试
数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
安全性测试：
基本的登录功能的检查
是否存在溢出错误，导致系统崩溃或者权限泄露
相关开发语言的常见安全性问题检查，例如SQL注入等
如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持
兼容性测试，根据需求说明的内容，确定支持的平台组合：
浏览器的兼容性；
操作系统的兼容性；
软件平台的兼容性；
数据库的兼容性
开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
定期评审，对测试进行评估和总结，调整测试的内容
8、软件生存周期及其模型是什么？
软件生存周期（Software life cycle）又称为软件生命期，生存期。是指从形成开发软件概念起，所开发的软件使用以后，知道失去使用价值消亡为止的整个过程。一般来说，整个生存周期包括计划（定义）、开发、运行（维护）三个时期，每个时期又划分为若干个阶段。每个阶段有明确的任务。
周期模型（典型的几种）：
瀑布模型
快速原型模型：快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。
迭代模型：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。在某种程度上，开发迭代是一次 完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次 的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
生命周期阶段：
软件计划与可行性分析
需求分析
软件设计
编码
软件测试
运行与维护
9、什么是软件质量？
概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述 的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。 影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。可划分为三组，分别反应用户在使用软件产品时的三种观点。正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）。
10、软件产品质量特性是什么?
功能性：适应性、准确性、互操作性、依从性、安全性。
可靠性：成熟性、容错性、易恢复性。
可使用性：易理解性、易学习性、易操作性。
效率：时间特性、资源特性。
可维护性：易分析性、易变更性、稳定性、易测试性。
可移植性： 适应性、易安装性、遵循性、易替换性
11、软件验收测试的合格通过准则
软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
所有测试项没有残余的一级二级三级的错误。
立项审批表、需求分析文档、设计文档和编码实现一致。
验收测试工件齐全（测试计划，测试用例，测试日志，测试通知单，测试分析报告）
12、软件验收测试包括
正式验收测试
非正式验收测试：包括α测s试和【由用户、测试人员、开发人员共同参与的内部测试】、β测试【内侧后的公测，即完全交给最终用户的测试】
13、系统测试的策略
功能测试、性能测试、压力测试、容量测试、安全性测试、可用性测试、GUI测试、安装测试、配置测试、异常测试、备份测试、健壮性测试、文档测试、在线帮助测试、网络测试、稳定性测试
14、设计系统测试计划需要参考的项目文档
软件测试计划
软件需求规范
迭代计划
15、系统集成测试主要包括以下过程：
1. 构建的确认过程。
2. 补丁的确认过程。
3. 系统集成测试测试组提交过程。
4. 测试用例设计过程。
5. 测试代码编写过程。
6. Bug的报告过程。
7. 每周/每两周的构建过程。
8. 点对点的测试过程。
9. 组内培训过程
16、性能测试类型包括负载测试，强度测试，容量测试。
负载测试- 【在一定的工作负荷下，系统的负荷及响应时间】核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。
强度测试- 【在一定的工作负荷下，在较长时间跨度内系统连续运行给系统性能所造成的影响】核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。
容量测试- 核实测试用户同时使用软件程序的最大数量。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据表容量。容量测试的目的是通过测试预先分析出反应软件应用特征的某项指标的极限值（如最大并发用户数、数据库记录数），系统在其极限值状态在没有出现任何软件故障或还能保持主要功能正常运行。
17、典型的软件开发模型
瀑布模型：
计划 → 需求分析 → 设计 → 编码 → 测试 → 运行维护
特点：①软件开发的各项活动严格按照线性方式进行。
②当前活动接受上一项活动的工作结果。
③当前活动的工作结果需要进行验证。
缺点：①由于开发模型是线性的，增加了开发的风险。
②早期的错误可能要等到开发后期的阶段才能发现。
原型模型：
根据用户的主要需求，建立一个软件原型，然后让用户进行评价，然后根据用户的评价和提出的更多的需求来开发出相应的软件产品。客户与开发公司紧密联系，开发周期长。开发会受到需求变更的影响。
特征：①实现客户与系统的交互。
② 进一步细化待开发软件需求。
③开发人员可以确定客户的真正需求是什么。
螺旋模型：
制定计划 → 风险分析 → 实施工程（需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试） → 客户评估
特点：①螺旋模型是将瀑布模型与快速原型模型结合起来。
②强调了其他模型所忽视的风险分析。
③每一次螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评估。
缺点：①强调风险分析，但要求许多客户接受并相信这种分析，是不容易的。
敏捷开发模型：
特点：①短周期开发。
②增量开发。
③ 由程序员和测试人员编写的自动化测试来监控开发进度。
④通过口头沟通、测试和源代码来交流系统的结构和意图。
⑤编写代码之前先写测试代码。也叫做测试先行。
缺点： ①团队的组建较难，人员素质要求较高。
②对测试员要求完全掌握各种脚本语言编程，会单元测试。
增量模型：
瀑布模型和快速模型都是一次性把软件提交给客户的，而增量模型是分批的把软件提交给客户的，但也要担一定的风险，就是最后合在一起未必能成功。把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件
18、自顶向下测试
目的：从顶层控制（主控模块）开始，采用同设计顺序一样的思路对被测系统进行测试，来验证系统的稳定性。
定义：自顶向下的集成测试就是按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试
总结特点：从上到下（分层），从左到右（排序）
这句话可以这样理解先从整体上从上到下排列
第一层有：M1
第二层有：M3，M4，M2
第三层有：M6，M5
第四层有：M7
然后再从每层进行细分，从左到右排列
第一层排序后：M1
第二层排序后：M2，M3，M4
第三层排序后：M5，M6
第四层排序后：M7
再整合起来，自顶向下测试方法（广度优先）就出来了：M1，M2，M3，M4，M5，M6，M7
原文：https://blog.csdn.net/fbvukn/article/details/85853826
19、自底向上测试方法
目的：从依赖性最小的底层模块开始，按照层次结构图，逐层向上集成，验证系统的稳定性。
定义：自底向上集成是从系统层次结构图的最底层模块开始进行组装和集成测试的方式。对于某一个层次的特定模块，因为它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在测试过程中，如果想要从子模块得到信息可以通过直接运行子模块得到。也就是说，在集成测试的过程中只需要开发相应的驱动模块就可以了。
20、自顶向下测试和自底向上测试方法比较：
自顶向下测试：
优点：
1、如果主要的缺陷发生在程序的顶层将非常有利
2、一旦引入I/O功能，提交测试或更容易
3、早期的程序框架可以进行演示，并可激发积极性
缺点：
1、必须开发桩模块
2、桩模块要比最初表现的更复杂
3、在引入I/O功能之前，向桩模块中引入测试用例比较困难
4、创建测试环境可能很困难，甚至无法实现
5、观察测试输出很困难
6、使人误解设计和测试可以交迭进行
7、会导致特定模块测试的完成延后
自底向上测试
1、如果主要的缺陷发生在程序的底层将非常有利
2、测试环境比较容易建立
3、观察测试输出比较容易
缺点：
1、必须开发驱动模块
2、直到最后一个模块添加进去，程序从才形成一个整体
执行测试：
当测试用例造成模块输出的实际结果与预期结果不匹配的情况时，可能存在：要么该模块存在错误，要么预期结不正确（测试用例不正确）。为了将这种混乱降低到最小程度，应在测试执行之前对测试用例集进行审核或检查（即对测试用例进行测试）。
---------------------
作者：ValDC_Morning
来源：CSDN
原文：https://blog.csdn.net/ValDC_Morning/article/details/78750328
版权声明：本文为博主原创文章，转载请附上博文链接！
