目录
一、基本内容
软件测试：验证软件产品特性是否满足用户的需求。
软件测试的基本标准：
- 所有的测试都应追溯到用户需求
- 应当把“尽早地和不断的进行软件测试”作为座右铭。
- Pareto 原则：测试发现的错误中80%很可能起源于20%的模块中。
- 完全测试是不可能的，测试需要终止。
- 应由独立的第三方来构造测试
- 充分注意测试中的群集现象。
- 尽量避免测试的随意性。
- 兼顾合理的输入和不合理的输入数据。
- 程序修改后要进行回归测试。
- 应长期保留用例，直至系统废弃。
软件测试和开发的区别：
? ? ? ? ?开发广度小，专业度高；测试广度大，专业度低；
软件测试和调用的区别：
- 目的不同? ?调试：确保程序做了程序员想做的；测试：确保程序解决了它应该解决的问题；
- 参与角色不同? ?调试：开发人员；测试：测试人员（黑盒测试）和开发人员（单元测试/集成测试）
- 执行的阶段不同? 调试：开发阶段；测试：整个软件开发的生命周期；
一个优秀的软件测试人员具备的素质：沟通能力，快速学习的能力，开发能力，文字能力，掌握自动化测试技术，优秀的测试用例设计能力，探索性思维。
衡量软件测试结果的依据：需求
- ?需求的概念：满足用户期望或正式规定文档所具有的条件和权能，包含用户需求和软件需求。
- 软件需求是测试人员进行测试工作的基本依据，是用户需求转换而来的，是用户需求的细化，是用户需求的具体实现和规范。
- 为什么需求这么重要？从软件功能需求出发，关系到测试的覆盖率。
测试用例概念：为了实施测试而向被测试的系统提供的一组集合，这组集合包括：测试环境，测试步骤，测试数据，预期结果等要素。
软件错误（BUG）概念：当且仅当软件需求是存在且正确的，软件功能与需求之间不匹配才是错误的；
软件开发的流程：需求分析，计划，设计，编码，测试，运行维护
软件测试的生命周期（软件测试的流程）：需求分析，测试计划，测试设计和测试开发，测试执行，测试报告。
如何描述一个BUG：
- 发现问题的版本
- 测试环境
- 测试步骤（错误重现步骤）
- 预期结果
- BUG产生的log日志、错误截图等附件
BUG的生命周期：发现BUG，提交BUG，验证BUG，关闭BUG；
软件测试的最小单位：模块
二、软件开发的五大模型
1.瀑布模型
需求分析----> 计划---->设计---->编码---->测试
重视需求分析，后期测试。
缺点：测试在编码后才介入，导致前期问题无法及时发现，失去错误及时纠正的机会。
2.螺旋模型
适用于项目庞大，前期需求不明确，风险较大的项目。
优点：抗风险能力强
3.增量模型
逐块构建，比如：画人物画，先画人的头，再画人的身体，再画四肢。
优点：抗风险能力较强
4.迭代模型
反复求精，比如：画人物画，先画整体轮廓，再细化。
优点：抗风险能力较强
5.敏捷模型
?特点：轻文档，轻流程，重目标，拥抱变化
三、敏捷模型中的模型
1.V模型
2.W模型
四、 测试用例的设计方法
基于需求设计测试用例是测试设计和开发测试用例的基础，第一步：分析测试用例，验证测试需求是否正确、完整、无二义性、并且逻辑自洽。第二部：在需求正确的基础上细化测试需求，从测试需求提炼出测试点，然后根据测试点进行测试用例的设计。
分析测试需求时，一般分为：功能测试需求? 和? 非功能测试需求；
1.功能需求测试分析：
- 系统各个功能界面的验证。
- 借助业务把功能串起来进行测试。
- 功能的一致性，交互性的测试。
- 系统的不同输入，结果输出的业务数据传输。
- 功能的错误操作，异常操作的测试。
- 功能实现用到的算法验证，有时候需要用代码评审。
- 用户操作的易用性，用户体验，往往结合功能测试同时验证。
2.非功能需求测试分析：
非功能测试需求主要涉及到性能、安全性、可靠性、兼容性、易维护性? 和??可移植性。
具体测试用例设计方法：
- 等价类：有效等价类，无效等价类；? ? ? ? ? ?
- 边界值；? ? ? ? ? ? ? ? ? ? ? ?
- 错误猜测法（用于补充测试用例，或者进行探索性测试）；
- 场景设计法（每一个功能不同的输入会触发流程走向不同的场景）；
- 因果图法；
- 正交法（选择代表性的点进行试验，减少用例数目）；
注：因果图法设计测试用例的步骤：
- 分析有可能的输入和可能的输出；
- 找出输入和输出之间的对应关系；
- 画出因果图；
- 把因果图转化为判定表；
- 把判定表对应到每一个测试用例；
五、测试分类
1.按测试对象划分
（1）界面测试（UI测试）
界面测试的内容：：：
- 验证界面内容显示的完整性、一致性、准确性、友好性；
- 验证整个界面布局和排版是否合理；
- 对界面不同控件的测试
- 界面的布局和色调是否符合当下时事的发展；
- 验证界面每一个功能的正确性（从上到下，从左到右）；
- 要进行界面的不同分辨率的测试；
- 同一个web页面下不同页面大小的测试：页面从小到大变化过程中衔接丝滑；页面的字体不模糊不消失不重影；页面的图片不消失，排版布局合理；页面的功能可以正常使用；
界面常见错误：
- 不合适的快捷键，快捷键无法使用，重复的快捷键；
- 丢失的文字；
- 截断（文字的截断，文字显示不清楚，有遮挡）；
- 没有对齐；
- 文字自动转换；
- 文字重叠；
（2）可靠性测试
可靠性=正常运行时间/(正常运行时间+非正常运行时间)
非正常：软件自身和软件所部属的环境（硬件、软件系统，网络等）有问题导致软件无法正常运行。
（3）容错性测试
容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而提高系统的可用性。
- 输入异常数据或进行异常操作，以校验系统的保护性。比如：数据级测试、校验测试、环境容错性测试、界面容错性测试；
- 灾难恢复性测试。
（4）文档测试
整个开发过程中产生的各种文档，需求文档、设计文档、功能文档、用户使用手册；
- 文档的术语；
- 文档的正确性；
- 文档的完整性；
- 文档的一致性；
- 文档的易用性；
（5）兼容性测试
兼容性测试需求是明确要测试的兼容环境，考虑软硬件的兼容。
软件兼容：
- 系统自身版本的兼容：开发后的新功能不能影响旧功能，也不能影响后序功能的开发；
- 测试与应用环境的兼容性：操作系统、应用平台、浏览器的兼容；
- 测试与第三方系统以及第三方数据的兼容性；
（6）易用性测试
易用性包含七个要素：符合标准和规范，直观性，一致性（软件有不同的选项以满足不同使用习惯的用户来完成相同的功能），灵活性，舒适性，正确性? 和 实用性。
（7）安装卸载测试
（8）安全性测试
安全性测试是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输 和 抵御黑客，病毒攻击的能力。
（9）性能测试
常见的性能问题如下：
- 资源泄漏；
- 资源瓶颈；
- 线程死锁，线程阻塞；
- 查询速度慢或效率低；
- 受外部系统影响越来越大；
- 系统运行速度越来慢；
（10）内存泄漏测试
常见的内存泄漏原因：分配完内存后忘记释放；程序写法问题；某些函数使用不正确；
2.按照是否可以查看代码划分
（1）黑盒测试
测试方法有：等价类、边界值、因果图法、场景设计法、正交法、错误猜测法；
优点：不需要了解程序内部的代码以及实现；从用户角度出发设计测试用例，很容易的知道用户会用到那些问题，锻炼测试人员的产品思维；测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的内容；
缺点：不能覆盖所有的代码；
（2）白盒测试
一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试；
测试方法有（覆盖准则由弱到强）：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖；
（3）灰黑测试
介于白盒测试和黑盒测试之间的一种测试，是基于程序内部细节有限认知上的软件调试方法。灰盒测试多用于集成测试阶段，不仅关注输入输出的正确性，同时也关注程序内部的情况。
3.按照开发阶段划分
（1）单元测试
- 测试阶段：编码后或者编码前
- 测试对象：最小模块
- 测试人员：白盒测试工程师 或 开发工程师
- 测试依据：代码和注释+详细设计文档
- 测试方法：白盒测试
- 测试内容：模块接口测试，局部数据结构测试、路径测试、错误处理测试、边界测试；
（2）集成测试
将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。
目的：检查软件单位之间的接口是否正确；
- 测试阶段：一般单元测试之后进行；
- 测试对象：模块之间的接口；
- 测试人员：黑盒测试工程师 或 开发工程师
- 测试依据：单元测试的模块 + 概要设计文档
- 测试方法：黑盒测试与白盒测试相结合（灰盒测试）
- 测试内容：模块之间的数据传输、模块之间的功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
（3）系统测试
将软件看成是一个系统的测试，包括对功能、性能以及软件运行的软硬件环境进行测试；
回归测试：修改了旧代码后，重新进行测试以确认没有引入新的错误或导致其他代码出产生错误；
冒烟测试：冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。
（4）验收测试
验收测试是部属软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称交付测试。
- 测试人员：最终用户或需求方
- 测试依据：用户需求、验收标准
- 测试方法：黑盒测试
4.按照实施组织划分
（1）测试
由一个用户（除了开发和测试人员以为的公司内部人员）在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
（2）测试
实际用户在实际使用环境下进行测试，不限时间，不限地点；
?测试 和?
测试 的区别：测试环境不同，时间集中程度不同，时间不同。?
测试 先于?
测试执行。
（3）第三方测试
介于开发方和用户方间的组织测试。
5.按照是否运行代码划分
（1）静态测试
静态的检查程序代码、界面或文档中可能存在的错误的过程。分析或检查源程序的设计、方法的实现、算法、内部结构、逻辑、代码风格 和 规格等来检查程序的正确性。
（2）动态测试
实际运行被测程序，输入相应的测试数据，检查实际输出结果 和 预期结果是否相符 的过程。
6.按照是否手工划分
（1）手工测试
- 优点：自动化永远无法替代探索性测试、发散思维结果的测试。手工测试的过程人为可控。
- 缺点：执行效率慢，量大易错；
（2）自动化测试
预设条件下运行系统或应用程序，评估运行结果，预先条件应包含正常条件和异常条件。
自动化测试按照测试对象划分，可以分为：接口测试、UI测试等。
- 优点：执行效率高
- 缺点：不是所有的项目都适合自动化（自动化测试不适合项目不稳定，功能频繁变动的项目）
7.按照地域划分
（1）国际化测试
开发软件的时候使用了一种工程，使得软件在适用不同国家的语言、风格、使用习惯时不用去改变软件的源码就可以实现。
（2）本地化测试
六、面试问题锦囊
1.发现一个BUG，开发人员修改了，通知测试人员验证，但是测试人员又复现了这个BUG，有可能是那些原因造成的？
答：测试环境不一样；开发人员理解不到位，没有修改成功；开发人员修改后，没有提交代码，测试人员用的还是用来有问题的代码；
2.测试因为一个BUG和开发人员产生冲突怎么办？
答：能让开发人员解决最多的BUG的测试人员是最优秀的测试人员。
检查自身，是否BUG描述不清楚；
站在用户的角度考虑问题，应该让开发人员了解到BUG对用户可能造成的困扰；
BUG定级有有理有据；
提高自身的技术和业务水平，不光要提出问题，最好能提出解决方案。
开发人员不接受时，不要争吵。经过多轮沟通，但是开发人员仍然不接受，可以发起BUG评审。
注：BUG评审一般是测试人员，开发人员和项目经理。
? ? ? ?BUG评审包括：决定如何处理BUG；分析缺陷产生的原因，找出预防的对策；
3.如何开始第一次测试？
答：先做准备工作；
- 阅读所有项目有关的文件，包括需求文档、设计文档、用户手册。
- 尽可能参加各种项目会议，了解项目背景、人员组成、尽可能的了解需求和业务。
- 熟悉项目所使用的测试管理工具、配置管理工具、获取对应的地址和登录方式。
- 阅读已有的测试方案和测试案例。
- 阅读旧的BUG库，了解系统功能。
- 了解公司的规范要求，比如：测试用例编写规范、用例编写规范、用例执行规范、BUG提交规范、测试工具使用规范等。
再与测试组长确认具体的工作内容；
- 测试的计划是什么？
- 测试的内容是什么？要求的时间是什么？
- 我测试的内容开发人员是谁？需求人员是谁？
- 分配给我的测试内容是否需要特殊的测试资源？资源是否满足？
确认以上信息后，就可以开始测试的执行了；
- 打开待测的系统。
- 打开测试管理工具用例模块，开始执行用例。
- 发现BUG，进行复现并确认BUG的复现步骤。
- 记录BUG。
- 沟通BUG。
- 验证以前提交的BUG。
- 确认本次测试完成。
- 编写测试报告。
4.为什么要在测试前设计测试用例?
答：测试用例是测试执行的依据；回归测试的时候可以复用；衡量需求的覆盖率；
自动化测试用例编写的依据；借鉴意义，后面的测试人员可以借鉴前人的测试用例；
5.java如何进行测试？
答：用Junit框架测试（单元测试框架）。