测试基础

一、什么是测试及测试的目的

1，测试：通过手工或自动化手段对被测系统进行检测的一个过程，用来检验实际结果与预期结果是否一致，是否符合需求规格要求；

2，目的：找出缺陷（BUG），提高产品质量，增加客户满意度；

二、软件的生命周期

1，需求，计划，设计，编码，测试，发布，评价，运维，下线；

三、常见的研发模型有哪些

1，瀑布模型，V模型，W模型，H模型，敏捷模型，RUP，IPD，X模型，螺旋模型；

四，软件测试的阶段

1，单元测试：CUNIT，JUNIT

2，集成测试：内部接口测试工具；JMETER：行业中通用接口测试工具，通过 EXCEL 进行传递，避开 UI 界面

3，系统测试：针对需求规格中定义的每一项需求验证是否符合要求（分别站在开发实现者和用户的角度）对系统的测试比较完整

4，验收测试：完全站在用户角度和在模拟用户环境或真实环境下进行测试，完全代表着用户来测试，由真实用户或第三方代表进行验收

五、软件测试流程

1，熟悉需求

1-1，开发提供定版需求；

2，测试需求分析

2-1，由组长或核心测试人员或交由一般测试人员完成；

2-2，根据需求进行拆分，找出其中的测试点；

2-3，根据测试点可评估出测试用例数，可以评估出测试的工作量；

3，测试计划

3-1，由测试组长来编写，明确做什么，确定目标；

3-2，主要内容：测试范围，测试团队，测试通过或失败标准，测试暂停恢复标准，测试过程安排（计划，设计，实现，执行）；

3-2-1，计划：输入输出，人力安排，时间安排，资源安排，风险评估，职责确定；

3-2-2，设计，实现，执行都是如上要求；

4，测试方案

4-1，由测试组长来编写，明确怎么做，确定细节；

4-2，主要内容：明确测试环境，测试工具，测试策略，测试设计和分析，缺陷分析；

5，测试用例

5-1，根据测试需求分析进行细化的一种文档，有指定的格式和编写规范；

5-2，一般由 EXCEL 或测试管理工具进行管理；

6，测试环境搭建和数据设备

6-1，开发已基本完成，且向测试部提交测试申请，通过后可以进入测试执行阶段；

6-2，测试组对测试用例基本已经完成编写且通过评审，即可进行测试执行阶段；

6-3，开发会提交版本到 SVN，测试再从 SVN 上取安装包，再进行环境搭建，如 WAMP；

7，测试执行

7-1，根据测试用例，对软件进行验证；

7-2，执行结果可以记录到 EXCEL 中或测试管理工具，如禅道中；

8，缺陷报告

8-1，按未解决的 BUG 的优先级排好序；

六，缺陷的处理

1，处理流程：

1-1，测试人员发现bug,提交并将 bug 状态设置为 new；

1-2，开发经理检验 bug，如果确认则将 bug 状态改为 open，并指派开发人员处理；如果有疑问，将 bug 状态改为 rejected （拒收）；

1-3，开发人员拿到 bug，根据 bug 的优先级合理安排时间进行修复，完成后将 bug 的状态改为 fixed，等待返测；

1-4，测试人员拿到修改后的 bug 进行测试，如果 OK，将 bug 的状态修改为 close，如果 bug 还存在，将 bug 的状态改为 reopen，一般会直接指定给开发人员；

2，缺陷的严重程度，从高到低分别为：

2-1，Urgent：造成系统死机，重启，崩溃的缺陷；

2-1，Veryhigh：非常严重的缺陷；

2-3，High：大的缺陷；

2-4，Low：小的缺陷

说明：每个等级（Bug Level）到底包括哪些缺陷，最好是在专门的文档中进行详细说明，使开发和测试对 bug 达成共识，性能（performance)，功能（function）

3，缺陷的优先级（priority）：主要是测试人员希望程序员对于该缺陷在什么时间内或哪个版本中解决

3-1，Urgent：立刻修改（主要是那些会影响开发或测试进度的）；

3-2，Veryhigh：本版本修改；

3-3，High：下个版本修改； 

3-4，Medivm：发布之前修改；

3-4，Low：允许存在；

4，缺陷描述（description）：把发现的步骤，使用的数据等记录下来，使程序员通过该描述可以清楚所发生的过程 ；

5，缺陷报告所包含的要素：缺陷编号（defect ID），缺陷标题（summary），缺陷的发现者（detected by），缺陷所属的模块（subject），发现缺陷的版本（detected in release）；

说明：缺陷的严重程度和优行级不一定会成正比，另外缺陷的严重程度在确定好以后一般不会再修改，但缺陷的优先级可能会因为开发的原因下调等级；

6，缺陷报告的用途：

6-1，记录bug；

6-2，对 bug 进行分类（模块，状态，严重程度，版本）；

6-3，跟踪 bug；

6-4，对 bug 进行分析统计；

7，如何识别 bug：

7-1，通过测试用例的预期结果判断--实际结果与预期结果不一样的，就是 bug；

7-2，看需求（通过缺陷的五点定义识别）；

7-3，沟通（开发，需求，用户）；

七、简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试

1，静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。  

2，动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。

3，黑盒测试一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。

4，白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。

5，α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。

6，β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。