目录

一、基本内容

二、软件开发的五大模型

1.瀑布模型

2.螺旋模型

3.增量模型

4.迭代模型

5.敏捷模型

三、敏捷模型中的模型

1.V模型

2.W模型

四、 测试用例的设计方法

五、测试分类

1.按测试对象划分

2.按照是否可以查看代码划分

3.按照开发阶段划分

4.按照实施组织划分

5.按照是否运行代码划分

6.按照是否手工划分

7.按照地域划分

六、面试问题锦囊

---

一、基本内容

软件测试：验证软件产品特性是否满足用户的需求。

软件测试的基本标准：

1. 所有的测试都应追溯到用户需求
2. 应当把“尽早地和不断的进行软件测试”作为座右铭。
3. Pareto 原则：测试发现的错误中80%很可能起源于20%的模块中。
4. 完全测试是不可能的，测试需要终止。
5. 应由独立的第三方来构造测试
6. 充分注意测试中的群集现象。
7. 尽量避免测试的随意性。
8. 兼顾合理的输入和不合理的输入数据。
9. 程序修改后要进行回归测试。
10. 应长期保留用例，直至系统废弃。

软件测试和开发的区别：

         开发广度小，专业度高；测试广度大，专业度低；

软件测试和调用的区别：

1. 目的不同   调试：确保程序做了程序员想做的；测试：确保程序解决了它应该解决的问题；
2. 参与角色不同   调试：开发人员；测试：测试人员（黑盒测试）和开发人员（单元测试/集成测试）
3. 执行的阶段不同  调试：开发阶段；测试：整个软件开发的生命周期；

一个优秀的软件测试人员具备的素质：沟通能力，快速学习的能力，开发能力，文字能力，掌握自动化测试技术，优秀的测试用例设计能力，探索性思维。

衡量软件测试结果的依据：需求

1.  需求的概念：满足用户期望或正式规定文档所具有的条件和权能，包含用户需求和软件需求。
2. 软件需求是测试人员进行测试工作的基本依据，是用户需求转换而来的，是用户需求的细化，是用户需求的具体实现和规范。
3. 为什么需求这么重要软件功能需求出发，关系到测试的覆盖率。

测试用例概念：为了实施测试而向被测试的系统提供的一组集合，这组集合包括：测试环境，测试步骤，测试数据，预期结果等要素。

软件错误（BUG）概念：当且仅当软件需求是存在且正确的，软件功能与需求之间不匹配才是错误的；

软件开发的流程：需求分析，计划，设计，编码，测试，运行维护

软件测试的生命周期（软件测试的流程）：需求分析，测试计划，测试设计和测试开发，测试执行，测试 告。

如何描述一个BUG：

1. 发现问题的版本
2. 测试环境
3. 测试步骤（错误重现步骤）
4. 预期结果
5. 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.按照实施组织划分

由一个用户（除了开发和测试人员以为的公司内部人员）在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

实际用户在实际使用环境下进行测试，不限时间，不限地点；

 

（3）第三方测试

介于开发方和用户方间的组织测试。

5.按照是否运行代码划分

（1）静态测试

静态的检查程序代码、界面或文档中可能存在的错误的过程。分析或检查源程序的设计、方法的实现、算法、内部结构、逻辑、代码风格 和 规格等来检查程序的正确性。

（2）动态测试

实际运行被测程序，输入相应的测试数据，检查实际输出结果 和 预期结果是否相符 的过程。

6.按照是否手工划分

（1）手工测试

• 优点：自动化永远无法替代探索性测试、发散思维结果的测试。手工测试的过程人为可控。
• 缺点：执行效率慢，量大易错；

（2）自动化测试

预设条件下运行系统或应用程序，评估运行结果，预先条件应包含正常条件和异常条件。

自动化测试按照测试对象划分，可以分为：接口测试、UI测试等。

• 优点：执行效率高
• 缺点：不是所有的项目都适合自动化（自动化测试不适合项目不稳定，功能频繁变动的项目）

7.按照地域划分

（1）国际化测试

开发软件的时候使用了一种工程，使得软件在适用不同国家的语言、风格、使用习惯时不用去改变软件的源码就可以实现。

（2）本地化测试

六、面试问题锦囊

1.发现一个BUG，开发人员修改了，通知测试人员验证，但是测试人员又复现了这个BUG，有可能是那些原因造成的/strong>

答：测试环境不一样；开发人员理解不到位，没有修改成功；开发人员修改后，没有提交代码，测试人员用的还是用来有问题的代码；

2.测试因为一个BUG和开发人员产生冲突怎么办/strong>

答：能让开发人员解决最多的BUG的测试人员是最优秀的测试人员。

检查自身，是否BUG描述不清楚；

站在用户的角度考虑问题，应该让开发人员了解到BUG对用户可能造成的困扰；

BUG定级有有理有据；

提高自身的技术和业务水平，不光要提出问题，最好能提出解决方案。

开发人员不接受时，不要争吵。经过多轮沟通，但是开发人员仍然不接受，可以发起BUG评审。

注：BUG评审一般是测试人员，开发人员和项目经理。

       BUG评审包括：决定如何处理BUG；分析缺陷产生的原因，找出预防的对策；

3.如何开始第一次测试/strong>

答：先做准备工作；

• 阅读所有项目有关的文件，包括需求文档、设计文档、用户手册。
• 尽可能参加各种项目会议，了解项目背景、人员组成、尽可能的了解需求和业务。
• 熟悉项目所使用的测试管理工具、配置管理工具、获取对应的地址和登录方式。
• 阅读已有的测试方案和测试案例。
• 阅读旧的BUG库，了解系统功能。
• 了解公司的规范要求，比如：测试用例编写规范、用例编写规范、用例执行规范、BUG提交规范、测试工具使用规范等。

再与测试组长确认具体的工作内容；

• 测试的计划是什么/li>
• 测试的内容是什么求的时间是什么/li>
• 我测试的内容开发人员是谁求人员是谁/li>
• 分配给我的测试内容是否需要特殊的测试资源源是否满足/li>

确认以上信息后，就可以开始测试的执行了；

• 打开待测的系统。
• 打开测试管理工具用例模块，开始执行用例。
• 发现BUG，进行复现并确认BUG的复现步骤。
• 记录BUG。
• 沟通BUG。
• 验证以前提交的BUG。
• 确认本次测试完成。
• 编写测试 告。

4.为什么要在测试前设计测试用例/strong>

答：测试用例是测试执行的依据；回归测试的时候可以复用；衡量需求的覆盖率；

自动化测试用例编写的依据；借鉴意义，后面的测试人员可以借鉴前人的测试用例；

5.java如何进行测试/strong>

答：用Junit框架测试（单元测试框架）。