测试——软件测试模型、缺陷

复习：

一、开发模式和测试模型

1.1 软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、设计、编码、测试、运行维护。

1.2瀑布模型（Waterfall Model）

start ——> 需求分析 ——> 计划 ——> 设计 ——> 编码 ——> 测试 ——> end

（1）瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

（2）优点： 强调开发的阶段性； 强调早期计划及需求调查； 强调产品测试。

（3）缺点： 依赖于早期进行的唯一一次需求调查，不能适应需求的变化； 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

（4）最大缺陷：瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。

1.3螺旋模型（Spiral Model）——回归测试

 

（1）渐进式开发模型（迭代式开发）。适用于规模庞大、复杂度高、风险大的项目。

（2）优点： 强调严格的全过程风险管理；强调各开发阶段的质量；提供机会检讨项目是否有价值继续下去。

（3）缺点： 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。

 

新课：

一、敏捷——快速迭代

《敏捷宣言》（http://agilemanifesto.org/）： 我们通过身体力行和帮助他人来揭示更好的软件开发方式

1.价值观（核心四点）

(1)个体与交互重于过程和工具 —— 人与人之间的沟通

(2)可用的软件重于完备的文档 —— 轻文档（核心文档必须要有）

(3)客户协作重于合同谈判 —— 客户参与（要求客户参与度高）

(4)响应变化重于遵循计划 —— 拥抱变化（在没有发布上线前乐于接受变更）

在每对比对中，后者并非全无价值，但我们更看重前者

 

2.敏捷开发有很多种方式，其中scrum是比较流行的一种。

2.1 scrum里面的角色

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

（1）其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。

（2）scrum master 负责召开各种会议，协调项目，为研发团队服务。

（3）研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

do(我要做什么) doing(我现在做什么) done(我已经做了什么)

2.2 迭代开发

与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

2.3 scrum的基本流程

（1）产品负责人负责整理user story，形成左侧的product backlog。

（2）发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。

（3）迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。

（4）每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。

（5）演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。

（6）回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

2.4 敏捷中的测试

1.测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。

2.测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试

3.敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug出现的原因。

 

二、敏捷中的测试模型

1、软件测试的V模型

 

2.软件测试的W模型

 

三、配置管理和软件测试

是否真正做过项目从对配置管理的熟悉程度来看，是最容易辨别的

1.配置管理

配置管理( Confifiguration Management)是通过对在软件生命周期不同的时间点上的软件配置进行标识，并对这些被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。

2.软件配置管理的应用

软件开发过程中会产生大量软件产品（包括文档、源代码和数据等），且这些产品之间存在关联关系。同一软件产品也会发生变更，从而产生许多版本。软件开发小组必须清晰地知道会有哪些产品、这些产品会有哪些不同的形式和版本。开发小组必须清晰地知道如何将产品的变更通知给受影响的小组。如果不能有效地了解软件产品及其变更，开发小组将很难组装这些软件产品，很难得到所需的软件产品。

3.实施配置管理的好处

实施软件配置管理(SCM)，至少能给项目团队带来如下好处。 (1)能够对项目中的文档、代码等的变化进行有效管理。 (2)能够方便地重现某个文件的历史版本。 (3)能够重新编译某个历史版本，使维护工作变得容易。 (4)能够使异地多团队开发、并行开发成为现实。 (5)从公司级看，实行统一的配置管理流程可提高项目组间人员流动时的工作效率。

4.配置管理和软件测试

测试人员是SCM中的参与者，有些公司也会把测试人员和配置管理员合二为一。如果配置管理流程不规范，或者没有遵循一定的配置管理流程进行软件测试活动，也可能导致很严重的后果。

假设开发人员修正了一个Bug，然后找测试人员过去讨论，测试人员在开发人员的机器上重新测试了一下，发现Bug没再出现了，修复了，这时候，如果测试人员把缺陷关闭了，则可能导致缺陷莫名其妙地在用户那边又出现了。其实，原因可能仅仅是开发人员把这个Bug修改的代码没有提交的到配置管理数据库中。但是作为测试人员有没有责任呢？当然有，因为测试人员也没有按照规范的配置管理流程执行测试，

测试人员应该从配置库取源代码编译后再测试，只有看到新的构建版本不再出现那个Bug，才能把缺陷库中的Bug关闭。

 

四、软件测试教程

1.软件测试的生命周期： 需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

2.软件测试&软件开发生命周期（核心内容）

（1）需求分析：确认需求范围、功能点

（2）测试计划：制定时间表（人、时间、做什么工作）、风险管理

（3）测试设计、测试开发：编写测试用例

（4）测试执行：执行测试、缺陷管理

（5）测试评估：结论（通过或不通过）、缺陷分析

3.如何描述一个bug

（1）发现问题的版本

（2）问题出现的环境

（3）错误重现的步骤

（4）预期行为的描述

（5）错误行为的描述

（6）其他

①故障的分类：功能故障、界面故障、兼容性故障

②优先级的分类

（7）不要把多个BUG放在一起

当无法确认是同一段代码造成的故障时，不要将同一段代码放在一起提交。

EXPOSE 缺陷标题：163免费邮箱注册提交失败 版本：v1.0.0.1 环境：win10+IE 严重级别：严重 操作步骤： 1.打开163网站 2.点击"免费注册邮箱" 3.输入相关信息 4.点击"提交" 实际结果： 页面提示："发送失败" 预期结果："发送成功" 附件：(上传截图)

4.bug的级别：bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

大致分为：

（1）崩溃（Blocker）

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

（2）严重（Cirtical）

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

（3）一般（Major）

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）

（4）次要（Minor）

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

 

5.bug的生命周期：每个公司、每一个工具对bug生命周期的定义都是不一致的。

（1）测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。

（2）缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。

（3）Bug的跟踪以及状态变更应该遵循一些基本原则：

①测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。

②对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。