测试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提交的整个测试过程。 软件测试周期并行与软件生命周期，存在于软件生命周期的各个阶段。

参考 ：软件测试的流程

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

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

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

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

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

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

• 测试报告包含哪些内容

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

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：

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

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

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

4、minor/trivial：即易用性及建议性问题。 Priority 1、immediate：即马上解决， 2、urgent：急需解决 3、high：高度重视，有时间要马上解决

5、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.测试尽早介入