软件测试基础
1、测试和调试的区别：
测试可以发现由于软件缺陷引起的失效。
调试是一种开发活动，用来识别引起缺陷的原因，修改代码以及验证是否是否正确地修改了软件的缺陷。
2、软件测试的定义：
使用人工或自动化手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
依据规范的软件检测过程和检测方法，按照测试计划和测试需求对被检测软件的文档、程序和数据进行测试的技术活动。
3、软件测试的目的：
1、验证软件是否满足软件开发合同或项目开发计划、系统设计文档、软件规格说明、软件设计说明等规定的软件质量要求。
2、通过测试，发现软件缺陷。
3、为软件产品的质量测量和评价提供依据。
4、软件测试的意义：
保证发布出去的产品达到了标准。
5、软件测试工程师的目标：
在最短的时间内尽可能发现多的缺陷，并保证这些缺陷得以修复。
6、软件测试原则：
1、所有的测试都应该追溯到用户需求。
2、尽早启动测试工作
3、应该在测试工作真正开始之前的较短时间内就进行测试计划。
4、Pareto法则应用于软件测试
5、测试应该从“小规模”开始，逐步转向“大规模”。
6、为了达到最佳效果，应该由独立的第三方来构造测试。
7、穷尽测试是不可能的
8、软件测试是有风险的
9、测试旨在发现存在的缺陷
10、找到的缺陷越多，就说明软件缺陷越多
11、软件测试员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试，以找出更多软件缺陷。
12、并非所有的软件缺陷都需要修复。
7、软件开发生命周期模型：
大爆炸模型
边写边改模型
瀑布模型
螺旋模型
敏捷软件开发模型
8、软件测试过程模型：
v模型：
用户需求—>需求分析—>概要设计—>详细设计—>编码—>单元测试—>集成测试—>系统测试—>验收测试
单元测试和集成测试验证程序设计，检验程序的执行是否满足软件设计的需求。
w模型：
基于测试的设计和不断测试的原则，w模型既强调了测试方案设计，也强调了测试执行
h模型：
真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量。
为了解决V模型和w模型存在的问题，有专家提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
x模型：
软件缺陷管理
1、测试人员不能报什么样的问题？
1、不能报不是问题的bug
2、不能报无法重现的bug
3、不能报重复的bug
2、软件缺陷的定义：
1、软件未达到产品说明书标准的功能
2、软件出现了产品说明书指明不会出现的错误
3、软件功能超出了产品说明书的指定范围
4、软件未达到产品说明书虽未指出但应该达到的目标
5、软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
3、缺陷产生的原因：
1、工期短，任务大
2、程序设计错误
3、文档不完整
4、沟通交流不够
5、软硬件支持不完善
6、软件的复杂性
7、需求不断变化
4、缺陷产生的原因：
1、大部分客户不懂软件开发技术，提出的需求不明确，或者提出的需求本身是矛盾的。
2、软件产品的制造商无法百分百地收集到用户所有的需求
3、在软件的需求调研和设计阶段存在的各种问题会导致用户需求被错误地理解和传递
4、用户需求随着工作或使用环境的变化，以及时间的推移也会随之改变
5、软件技术的发展落后于不断复杂的软件需求
5、无法再现的缺陷应当采取怎样的处理方法？
1、首先，应当对这样的缺陷进行详细的记录，并尽快提交给发开人员
2、其次，对于寻找难以再现的缺陷要合理地安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度。
3、最后在测试过程中对未再现缺陷予以关注
6、缺陷报告的写作准则
1、准确：每个组成部分描述准确，不要引起误解
2、清晰：每个组成部分的描述清晰，易于理解
3、简洁：只包含必不可少的部分，不包含任何多余的内容
4、完整：包含复现该缺陷的完整步骤和其他本质信息
5、一致：按照一致的格式书写全部缺陷报告
7、缺陷报告的内容有哪些？
缺陷的标题；缺陷的基本信息；测试的软硬件环境；测试的软件版本；缺陷的类型；缺陷的严重程度；缺陷的处理优先级；复现缺陷的操作步骤；缺陷的实际结果描述；期望的正确结果描述；注释文字和截的缺陷图像；
8、缺陷报告的读者对象最希望获得的信息包括以下几点：
1、易于搜索软件测试报告的缺陷；
2、报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确
3、软件开发人员希望获得缺陷的本质特征和复现步骤
4、市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。
9、编写缺陷报告的技巧：
1、组织
2、重现
3、隔离
4、归纳
5、对比
6、总结
7、精简
8、消除歧义
9、中立
10、检查
11、缺陷验证分类：
1、致命：由于程序引起的死机，机器蓝屏，非法退出；程序产生的死循环；数据通讯错误，无法实时聊天；需求没有实现
2、严重：输入非法数据，程序异常退出，但该错误可以绕过；申请号码时必填的信息不填，可以申请成功。聊天时的实时状态显示不正确。
3、一般：删除操作韦给出提示，系统操作不方便，界面错误
4、较小错误：长时间操作未给出用户进度提示，提示窗口不够友好，用了专业术语
12、缺陷管理的目的：
1、对个阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准。主要实现以下目标：
及时了解并跟踪每个被发现的缺陷
确保每个被发现的缺陷都能被处理
收集缺陷数据，并在其上进行数据分析，作为组织过程的财富
13、测试人员职责：
1、高级经理（EM）
裁决项目经理与测试组长有争议的缺陷
2、项目经理（PM）
判断是否是缺陷
负责指派缺陷给相关负责人
3、项目测试组长（TM）
决定缺陷管理方式和工具
管理缺陷状态情况
审核测试人员提交的缺陷
对测试人员的工作质量进行跟踪和评价
4、测试人员（TE）
编写测试用例
负责缺陷的提交、跟踪以分析
负责执行系统回归测试
提交周报、月报
5、项目相关开发人员（DE）
修复测试发现的缺陷
负责跟踪修复缺陷的状态
6、质量保证人员（SQA）
监控项目组缺陷管理规程执行情况
14、缺陷的状态：
1、Submitted 以提交 以提交的缺陷
2、Open 打开 确认“提交的缺陷”，等待处理
3、Rejected 以决绝 拒绝“提交的缺陷”，不需要修复或不是缺陷
4、Resolved 以解决 缺陷被修复
5、Close 已关闭 确认被修复的缺陷，将其关闭
15、缺陷的来源
1、Requirement 由于需求的问题引起的缺陷
2、Architecture 由于架构的问题引起的缺陷
3、Design 由于设计的问题引起的缺陷
4、Code 由于编码的问题引起的缺陷
5、Test 由于测试的问题引起的缺陷
6、Integration 由于集成的问题引起的缺陷
软件测试过程
1、测试计划编写的依据
需求文档，开发计划，设计计划
2、测试人员参加需求分析工作，带来的好处
1、测试工程师参与需求分析，对需求了解很深刻，减少了很多与开发人员的交互，节省了时间
2、早期确定测试用例的编写思路，为测试打好了基础
3、可以获取有些测试数据，为测试用例设计提供帮助
4、可以发现需求不合理的地方，降低了测试成本
3、如何编写测试用例
1、采取SRS模板
2、指明需求的来源
3、为每项需求注上标号
4、记录业务规范
5、创建需求跟踪能力矩阵
4、参与软件需求评审都有哪些人员？
产品经理、项目经理、测试经理、开发人员、测试人员、高级经理、qa
5、测试用例是百分百的能够覆盖需求的，但是不能百分百的发现所有的缺陷；如果我们发现的缺陷不包含测试用例的话，解决方案是更新测试用例。
6、如何针对需求变更的项目进行测试？
组织一个由项目分析承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，评估它们，并对此评估做出决策，已确定选择哪些，放弃哪些，并设置实现的优化顺序，制定目标版本。
7、项目需求变更是由pmo项目管理组织它们来把控，我们只负责变更后的需求的·测试，同时也要兼顾整体流程的测试。
8、测试计划是由测试组长和测试经理来编写的，测试人员负责执行。但是测试计划不是一成不变的，要根据产品需求不断变化来变化的；测试计划是在开发计划完成后编写，参考依据：需求文档、设计文档、开发计划
9、测试计划的定义
一个叙述了预定的测试活动的范围、途径、资源已进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。
10、软件测试计划的目的？
规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特征、要执行的测试任务、每个任务的负责人，以及与测试相关的分析。
11、测试的时间很紧迫，如何来合理安排时间测试项目？
先对项目的重要功能进行测试，能够保证项目可以畅通进行，保证项目不会出现404,500等严重页面错误，然后再对项目其他模块测试，保证项目整体没有大缺陷。
12、测试结束后输出的文档有哪些？
1、测试计划
2、测试用例
3、缺陷报告
4、测试报告
软件测试级别、类型及方法
1、单元测试
对单个的软件单元或者一组相关的软件单元所进行的测试，时代码级别的测试。比如：函数、源代码文件、类。
2、集成测试
集成测试是对组件之间的接口进行测试，以及测试应该系统内不同部分的相互作用，比如操作系统、文件系统、硬件或系统之间的接口。
一种旨在暴露接口以及集成组件/系统间交互时存在的缺陷的测试。
测试的目的是发现接口的缺陷和集成后组件协同工作时的缺陷（如果操作系统的接口，与文本系统或硬件的接口）
3、系统测试
系统测试关注的是在开发项目或程序中定义的一个完整的系统/产品的行为。
测试集成系统以验证它是否满足指定需求的过程
一个集成测试的基于风险测试，为的是确认此系统满足了特定的功能性和非功能性的需求。测试环境应尽可能与以后的目标环境保持一致。
4、系统测试基于哪几个方面？
基于需求的测试
基于业务流程的测试
用例测试
5、验收测试
验收测试通常是由使用系统的用户或客户来进行，同时系统的其他利益相关者也可能参与其中。测试软件是否达到需求说明书、开发说明书等标准。
6、Alpha测试和Beta测试
Alpha测试：潜在的客户/用户在开发场地进行的测试
Beta测试：由潜在客户/用户在他自己的环境下测试软件系统
测试目的是识别在未知的或非指定的应用环境下对系统的影响。
7、维护测试
维护测试的任务是，针对运行系统的更改，或者新的环境对运行系统的影响而进行的测试。
通常维护测试是通过一个系统的修改、移植或退役时才才进行的测试。
维护：
计划中的功能增强
纠正和应急更改
环境的变化比如计划的操作系统或数据升级
或由于新发现或暴露的操作系统漏洞而打的补丁
移植：
新环境的运行测试
对变更以后的软件运行测试
退役：
数据移植测试
存在测试（如果需要长时间的数据保存）
8、其他测试包括哪些：
负载
性能、效率
压力
可用性，用户的友好性
可靠性，稳定性
可移植性，互操作性
健壮性，可恢复性
安全性
容量
文档
配置
兼容性，数据转载
易变性
国际化/本地化
9、回归测试
对以前已经测试过·的·版本或者经过修改的程序进行重新测试，以保证修改没有引入新的错误或者由于修改发现以前未发现的错误。
10、测试类型
功能测试：测试软件项的功能特征，功能指的是系统能做什么
非功能测试：软件测试项的非功能特性，非功能指系统工作的怎样
结果测试：通过评估结果类型的覆盖，来测量测试对完整性
11、黑盒测试、白盒测试
黑盒测试：黑盒测试又称为功能测试或逻辑驱动测试，是从用户观点出发，主要以软件规格说明书为依据，对程序功能和程序接口进行的测试。
白盒测试：也称结构测试或逻辑驱动测试。检查程序中的每条通路是否都按照预定要求正确工作；需要完全了解程序结构和处理过程。
12、测试方法
1、静态测试方法
针对代码
2、动态测试方法
动态测试方法一般采取白盒测试和黑盒测试方法
13、黑盒测试的方法：
功能分解
等价类划分
边界值分析
因果图
判定表
随机测试
猜错法
正交实验法
14、什么是等价类划分？
等价类划分是一种重要的、常用的黑盒测试方法，不需要考虑程序内部结构，指需要考虑程序的输入规格即可。它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
有效等价类：指符合《需求规格说明书》，输入合理的数据集合
无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合。
15、什么是边界值
边界是针对于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特殊情况。
16、场景法
基本流：按照正确的业务流程来实现一条操作路径（模拟正确的操作流程）
备选流：导致出现错误的操作流程（模拟错误的操作流程）
17、流程分析法
流程分析法主要是针对测试场景类型属于流程测试场景的测试环境下的测试子项进行设计，是从白盒测试方法中的路径覆盖分析法借鉴过来的一种方法。
18、软件测试计划包括什么？
测试项，被测特征，测试任务，人员安排，以及任何偶发事件的风险。
软件测试流程
1、项目立项（公司高层、架构师、产品经理、总经理、总监、老板、公司的商务）
2、商务谈判（跟客户进行谈判，签订合同 —— 软件开发业务模块，报价）正式启动
3、需求分析（产品经理 —> 需求调研—>产品的初稿—>产品需求说明书—>经过开会讨论最终定稿形成完整的产品需求说明书）
4、需求评审（产品经理、项目经理、测试经理、开发人员、测试人员、ui）
5、测试计划（测试组长或者测试经理，测试计划不是一成不变的，要经过多次的迭代，比较完善测试计划需求不断进行修改和评审）
6、测试用例（测试人员，依据是产品需求说明书、设计文档、demo）测试用例不能发现所有的缺陷但是一定要覆盖所有的需求，通过评审的方式来完善测试用例
7、搭建项目环境（测试环境独立）
8、冒烟测试（我们在开始正式执行测试的时候由1-2名测试人员进行10-15分钟的冒烟测试，主要是测试业务流程是否完善、界面不要报500,404的错误），如果出现这些问题就不能正常的开展工作，反馈给主管，由主管反馈给项目经理进行修复。
9、正式执行测试（执行测试用例，发现bug，报bug）
10、确认测试（项目经理分配bug给开发进行修改）
11、回归测试（测试人员针对开发修复bug订单版本进行验证，通过关闭，不通过返回开发继续修改直到通过关闭掉缺陷）
12、测试报告
2、测试用例的特点：
可以最大限度地找出软件隐藏的缺陷
可以最高效率地找出软件缺陷
可以最大程度地满足测试覆盖需求
既不过分复杂，也不过分简单
使软件缺陷的表现可以清楚的判定
测试用例包含期望的正确结果
待查的输出结果或文件必须简单明了
不包含重复的测试用例
测试用例内容清晰、格式一致、分类组织
3、测试用例的元素
一个测试用例包含了如下部分：对一个特定的测试对象，在规定的条件或环境下（前置条件和后署部分），输入一组数据或执行操作步骤后，生成一组相对应的期望的结果。
测试目标：为什么而测试？功能、性能、可用性、兼容性、容错性、安全性等
测试对象：测试什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等。
测试环境：在哪里测试？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议等单机或网络环境。
测试前提：什么时候可以测？测试用例运行时所处的前提或条件限制。
输入数据：哪些数据？在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。
操作步骤：然后测？执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等。
4、测试用例设计准则
基于测试需求的准则。应按照测试类别的不同要求，设计测试用例。
基于测试方法的原则。应明确所采取的测试用例设计方法。
兼顾测试充分性和效率的原则。
测试执行的可再现性原则。
5、如何保证测试用例的质量？
首先，要对用户需求、服务质量要求、产品特性有深刻且全面的理解
其次，采取正确、恰当的方法进行用例设计。
再者，按照测试用例的标准格式或规范的模板来书写测试用例。
除此之外，对测试用例的检查、评审，也是一种提高测试用例质量的主要有效手段。