测试1：测试相关概念

1.测试相关概念

---

1.1.测试概念

1.1.1.需求

符合正式文档规定的条件和权能，包括用户需求和软件需求

它们之间的的转换是：沟通

用户需求和软件需求的区别：

可否指导开发人员开发，测试人员编写测试用例

1.1.2.缺陷Bug

与正确的需求规格说明书不一致或与用户合理的指望不相同

缺陷的状态：

new、open、fixed、closed、reopen、rejected、delay

1.1.3.测试用例

向被测程序输入的一组集合，包括要素：

测试环境、测试数据、测试步骤、测试预期结果、测试版本、备注

思路：

1.对核心主要功能进行测试

2.进行异常（逆向、扩展、发散）--容错性测试

3.写功能测试以外的测试点（安全、性能、界面、易用）

存在的问题：

1.设计测试用例是费时费力的工做，比执行时间长

2.测试的覆盖率没法衡量，对新版本的重复测设很难实施

2.开发模型和测试模型

1.软件生命周期

软件生命周期是指软件的产生直到报废的生命周期。从软件产品的设想开始到软件再也不使用而结束的时间

具体包括：
问题的定义及规划，需求分析，软件设计（概要，详细），软件编码，软件测试（单元测试，集成测试，系统测试，验收测试），运行维护

2.测试生命周期

测试周期是指从测试项目计划创建到BUG提交的整个测试过程。 软件测试周期并行与软件生命周期，存在于软件生命周期的各个阶段。

参考 ：软件测试的流程

一、需求分析阶段：阅读需求、对需求进行分解、分析，主要就是对业务的学习，分析需求点，参与需求评审会议

二、测试计划阶段：主要任务就是编写测试计划、测试方案，参考软件需求规格说明书，项目整体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，总体测试策略的制定。风险评估与规避措施有一个制定。

三、测试设计、测试开发阶段：测试人员适当的了解设计，对于设计测试用例是颇有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例。

四、测试执行阶段：测试执行阶段是软件测试人员最为重要的工做阶段，根据测试用例和计划执行测试。

​ 搭建环境，执行冒烟测试（预测试）-而后进入正式测试，bug管理直到测试结束

五、测试评估阶段：执行的过程当中记录、管理缺陷，测试完成后编写测试报告，进行测试评估，确认是否能够上线

• 测试报告包含哪些内容

  测试概况--测试过程分析--缺陷分析--测试结论--测试清单

3.开发模型

3.1 瀑布模型：串行

适用：项目需求稳定，需求变动较少的项目或是以前已有的作过的产品

优势：

分步清晰，阶段性强：测试阶段单独分出来

缺陷：集成之日就是爆炸之时

（1）测试阶段靠后，发现问题的时机晚，修改为本高，风险大。

（2）测试阶段靠后，误认为测试不重要

（3）项目成果不能及时分享其它项目

（4）不能适应需求变化

瀑布模型：

把软件开发模型分为好几个阶段，包括软件计划、需求分析、设计、实现、软件测试、软件运行维护。

具备一种比较明显的分层，每一阶段的结果文档会做为下一阶段的输入，强调文档，整个周期完成的差很少了才能看到结果；

没有迭代和反馈，只能一步一步来，流程没有回头路。不能适应客户不断变化的需求，后期须要改动时成本也比较大

测试比较晚，基本上是在软件完成以后进行的测试

3.2 螺旋模型：渐进式

适用：复杂度高、风险大、规格大，作一点测一点，测试必须跟随开发。没有独立的测试时间和阶段

强调：风险，保证各个阶段的质量

缺陷点：对人员的要求比较高，投入时间多，人力成本高，进度缓慢

3.3 增量和迭代：

目的：大型项目，为减小项目的风险

增量：显著下降项目风险，逐块建造，一部分一部分的作，新版本、新加功能对软件其余功能没有影响

迭代：反复求精，先轮廓再细化，新版本、新加、删除功能对软件其余功能有影响，原来功能须要修改

3.4敏捷开发模型：快速迭代，若干小迭代

敏捷宣言4条：（敏捷开发与传统开发的区别）

（1）轻文档，对文档依赖度低，但仍是须要。强调软件的可用性

（2）强调人与人之间的沟通

（3）客户参与

（4）在正式发布以前拥抱变化，

敏捷开发有不少方式，SCRUM是比较流行的一种

特色：

（1）三种角色：产品经理、项目经理、研发团队

（2）不超过10人（5-9人）

（3）天天有站立会不超过15分钟，回答昨天作了什么，今天要作什么，有什么问题

（4）迭代时间1-4周。每次迭代产生必定的交付（会作出一点功能，即便还不完善）

流程：

po整理USER STORY --开会学习USER STORY，肯定每次迭代完成的USER STORY

----分配USER STORY，肯定完成时间--开发完成--测试中--测试完成--待发布上线--发布上线

敏捷开发：

按一个短的迭代周期工做，强调“快”，每次迭代交付一些成果，（或者说先作出一个不完美但能实现必定的功能的版本）；让客户参与进来，有新需求就，快速响应变化，迭代产生新版本，缩短软件版本的周期。

强调开发软件而不是文档。

特色：让客户参与进来，客户需求的变更和软件有些不符合需求的地方能够第一时间进行了解和改动； 缩短版本周期； 每隔一段时间（一个迭代周期），团队能够在工做方面进行检讨和改进，调整本身的行为； 强调开发软件而不是文档，提升编程人员的积极性。

敏捷测试：

以用户需求为中心，在每个迭代周期都须要进行测试，

基于自动化测试->速度快、敏捷

更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化

强调面对面的沟通、协做，强调团队的责任，不太关注对缺陷的记录与跟踪。缺陷修复的成本也较低

4. 软件测试V模型

目的：改进软件开发的效率和效果

是瀑布模型的变种

单元和集成测试：检测程序的执行是否知足设计的要求

系统测试：检测系统功能和性能的质量特性是否达到系统要求的指标

验收测试：肯定软件的实现是否知足用户需求、合同要求

局限性：测试阶段在编码以后，未在许爱u阶段就进入测试

4.2 W模型（双V）

解决V的缺点，每一个阶段都有测试工做，不必定是测试人员参与

特色：

1.测试与开发并行

2.测试的对象不只是程序，好包括需求、设计等

3.能尽早全面发现问题

局限性：测试盒开发保存一种线性的先后关系，上一阶段彻底结束，才可开始下一阶段，不能支持敏捷开发模式

V模型和W模型的比较：

V模型：把测试过程做为在需求分析、系统设计及编码以后的一个阶段，忽视了测试对需求分析，系统设计的验证，需求的知足状况一直到后期的验收测试才被验证。（应该比较多包括系统测试和验收测试）

W模型：测试的活动与软件开发同步进行，测试的对象不只仅是程序，还包括需求和设计。由于在需求阶段测试就已经介入了，后面每一阶段的开发都须要通过测试，可以尽早发现软件的缺陷，下降debug的成本

4.3 敏捷测试（解决V\W的缺陷）：

沟通、适应

文档能够写粗略，能够画思惟导图，借助自动化

3.如何描述一个缺陷

对bug的描述尽可能简短但要求清晰，对bug出现的条件进行详细的描述，包括输入的测试用例、使用的环境、有没有和其余软件同时运行，以及须要写清bug出现的位置，帮助开发更好定位。

按照用户体验（bug是否很严重的影响用户体验）、影响系统的程度进行评级。

3.1 要素（一条bug记录的组成）

测试环境、测试数据（内容）、测试步骤、预期结果、实际结果、缺陷级别、测试版本、前提条件、发生的位置

3.2 缺陷的级别（如何对一个bug评级）

3.2.1 简单版

崩溃 严重 通常 次要 建议

A B C D E

崩溃：直接形成软件不能使用，形成死机、数据丢失等

严重：功能不能使用，数据丢失。与需求严重不符，不影响其余功能测试的状况下能够继续版本测试

通常：功能没有彻底实现但不影响使用，不影响系统的稳定性

次要：界面、性能缺陷，建议类问题，文字错误等

3.2.2 详细描述

Bug的priority（）和severity（）是两个重要属性，一般人员在提交bug的时候，只定义severity，而将priority交给leader定义，一般bug管理中，severity分为四个等级blocker、critical、major、minor/trivial，而priority分为五个等级immediate、urgent、high、normal、low。 Severity：

一、blocker：即系统没法执行，崩溃，或严重资源不足，应用模块没法启动或异常退出，没法测试，形成系统不稳定。常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块没法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它致使没法测试的错误， 如服务器500错误。

二、critical：即映像系统功能或操做，主要功能存在严重缺陷，但不会映像到系统稳定性。常见的有：功能未实现，功能错误、系统刷新错误、数据通信错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。

三、major：即界面、性能缺陷、兼容性，常见的有：操做界面错误，边界条件错误，提示信息错误，长时间操做无进度提示，系统未优化，兼容性问题。

四、minor/trivial：即易用性及建议性问题。 Priority 一、immediate：即立刻解决， 二、urgent：急需解决 三、high：高度重视，有时间要立刻解决

五、low：在系统发布前解决，或确承认以不用解决。

3.3 bug的生命周期

Start--New :测试人员发现bug，提交到平台后的状态为new

New--Open:测试人员将bug提交给某个研发人员的状态为Open

Open--Regected:研发人员验证不是缺陷，将状态改成rejected，返回给测试

Open--Delay:研发人员验证是缺陷，但不影响使用，等下个版本在修改，Delay

Open--Fixed：研发人员验证是bug，进行修改

Fixed--Closed：研发人员修改完成，测试人员验证经过，就Closed改bug

Fixed--Reopen:研发人员修改后，测试人员没有验证经过，就是Reopen再到Fixed

无效的bug:

open--closed open--rejected--closed

3.4bug都有哪些周期，请你描述不一样类别的bug？

3.5 如何发现更多的缺陷

1.二八原则--人员、模块

2.逆向思惟、扩展性思惟

3.不要依赖需求和测试用例

4.测试尽早介入