2020年测试部新人入职培训---测试基础

参考资料《http://172.16.111.6:8081/pages/viewpage.action?pageId=3280267》

课前活动

回顾答疑

《测试基础理论》作业完成情况总结分析，进行答疑

课程引入

介绍下测试需求分析在整个软件开发流程中的开展阶段。

RAD（Rap Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型。它通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。

课程内容

测试成功的目标和标准是什么。

一、为什么要分析需求

1 必要性

• 如果把测试活动比作软件生命周期，测试需求分析就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求，所以需求分析是整个测试活动必不可少的环节。
• 测试需求分析越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。

2 不做的后果

• 时间&资源的浪费，实现了用户不需要的功能
• 重要需求的遗漏，降低客户满意度
• 错误预估工作量，延误发布周期，可能会降低发布质量

3 测试及早介入原则

• 根据统计表明，在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%～60%。此外，IBM的一份研究结果表明，缺陷存在放大趋势。如需求阶段的一个错误可能会导致N个设计错误，因此，越是测试后期，为修复缺陷所付出的代价就会越大。因此，软件测试人员要尽早地且不断地进行软件测试，以提高软件质量，降低软件开发成本。

4 需求的分类

一般需求分为业务需求、用户需求、功能需求。

• 业务需求：业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。使用前景和范围文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档。

• 用户需求：描述的是用户的目标，或用户要求系统必须能完成的任务。比如软件的界面是否好看、功能使用是否便捷等都属于用户需求。用户需求可以认为是对业务需求的一个具体目标。比如业务需求提出了这个系统具有语音功能，那么用户需求可能就包含了语音具备的功能，比如可以喊“刘德华的电影”去搜索电影等。

• 功能需求：规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求,功能需求是去解决业务需求、用户需求的具体的解决方案，也就是我们通常说的需求说明书。对用户需求做具体的分析、提出实施方法（需求说明书通常是由软件开发方编写比如产品经理，使得用户和软件开发方都对软件的初始规定有一个共同的理解，是整个开发的基础）。同时，开发方需要对需求说明书进行评估，比如这个需求能不能做，耗费的成本是不是小于带来的收益，还有风险评估等。

二、什么是测试需求

1 简介

概述：测试需求通常是以功能需求为基础，通过对功能需求的细化和分解，形成可测试的内容。

范围：测试需求应尽可能全部覆盖已定义的业务需求，以及功能和非功能方面的需求。

目的：明确需求的范围、明确每一个功能的业务处理过程、明确不同功能点业务组合，挖掘显式需求背后的隐式需求。测试需求用于解决“测什么”的问题，即指明被测对象中什么需要测试。

2 测试需求的特征

• 测试需求必须是可核实的，即必须有一个可观察、可评测的结果，无法核实的需求不是测试需求；
• 测试需求应指明满足需求的正常前置条件，同时也要指明不满足需求时的出错条件；
• 测试需求不涉及具体的测试数据，测试数据设计是测试用例设计环节解决的课题；

3 测试需求与功能需求的关系

3.1 功能需求

系统应该做什么

举个例子：

某ATM机取款业务需求：每次取款额度在100-2000之间；取款的金额是100的倍数；每日取款总额不得超过20000，这是功能需求。 

3.2 测试需求

系统应该做什么、不应该做什么、发现系统设计中存在的问题

举个例子：

- 取款金额可选；
- 在100-2000之间且为100倍数可取；
- 小于100或大于2000不可取；
- 在100-2000之间但不是100倍数不可取；
- 取款总额必须小于等于账户余额等等；

这是测试需求。

三、如何开展测试需求分析

开展测试需求分析首先要明确的是业务需求、用户需求、功能需求以及需求的背景、场景。测试流程各环节都应与此保持一致。

测试需求分析应该事广度优先的，而不是深度优先的。测试需求分析需要层层递进，不要过度关注需求需求的细节，尤其是第一次了解一个特性时，不要一头扎进需求细节里，有非常多的疑问，花费很多时间，但依然一头雾水，这是因为没有站在更高层次上把握信息导致的。提取有价值的信息这件事要分层次进行，最终输出到测试用例时所关注的信息粒度都是非常细致的。但在需求分析阶段，谨记把握主干，忽略细节。

1 测试需求采集

测试需求采集是将软件开发需求说明书（不限于）中的具有可测试性的需求或特性提取出来，形成原始测试需求。

可测试性：指提取的需求或特性必须存在一个明确的期望结果，通过某种方法可以对期望结果进行验证是否符合文档中的要求

1.1 测试需求采集方法

通过列表的形式（Excel）对软件开发需求进行梳理，形成原始测试需求列表（SRS -- Software Requirements Specification），列表的内容可包含需求标识、原始测试需求描述、信息来源；

1. 将每一条软件需求对应的开发文档以及章节号作为软件需求标志；

2. 软件需求的简述作为原始测试需求描述；

3. 软件需求获取的来源信息作为信息来源 ；

4. （干预）提取的原始测试需求中，可能存在重复和冗余，在提取原始测试需求的过程中，可以通过以下方法整理原始测试需求：

   • “删除”：删除列表中重复的、冗余的原始测试需求描述
   • “细化”：对太简略的原始测试需求描述进行细化
   • “合并”：若有类似的原测试始需求，需要对其进行合并（或提取成公共测试项）

   

1.2 测试需求分析流程

结合上面软件需求分析流程图，我们这里着重对“需求项整理”、“测试点整理”、“输出测试需求矩阵”环节进行说明。

1.2.1 需求项整理

我们在上一小节“测试需求采集”中 简单的讲述了测试需求采集方法。不知大家是否考虑过，所有项目需求都是清晰、可视(需求说明书)的吗，如果不是又该如何？

可能会遇到哪些项目需求？

1. 有详细的需求文档：比较严谨负责的团队项目的实施是有详细的需求说明文档的，我们就可以详细阅读需求文档来进行测试点的梳理工作，对于需求中认为不明确的地方可以找项目负责人进行沟通，做到对需求整体把握和理解，利于测试更好的进行。
2. 需求文档不明确，既有文档但文档很粗糙：一般有两种方法，如果开发团队很配合，可以要求开发或者需求分析人员完善需求文档，如果因为各种原因，比如时间紧张或者开发不愿意，那么就自己去沟通对于文档中不明确的点问清楚，切忌不要含糊不清的测试，于人于己都没有好处。
3. 没有需求文档：很尴尬。。。这里提供两种方法。第一种方法，通过与项目经理、研发沟通、询问，收集、梳理、理解需求，自己写一个概要的需求描述，让大家确认（可以通过会议或mplus等方式）需求描述是否符合业务、用户、功能需求，使研发（包含项目经理）、测试对需求理解达成一致。第二种，基于用户使用场景和行业经验来去做判断它是否合理，这种方式不适应刚入职新人。

同时，我们要与项目经理或需求工程师确认功能需求的 优先级或重要程度，并对其达成一致，此为产品质量等级目标的重要依据之一。

示例：

基本上公司现在大部分项目的开发需求相对可用，只不过需要我们进行删细并，其中关于字段均存在

1.2.2 测试点整理

我们在"软件测试基础"章节中已经介绍了软件产品质量模型、测试类型和测试方法，我们按照**"车轮图"** ,结合功能需求被测对象（功能点）进行测试需求分析，就能知道我们需要从哪些方面来进行测试，从而可以得到测试点。

STEP1 抽取测试要点

对原始测试需求列表列出的每一条开发需求，形成可测试的分层描述的测试要点

• 通过分析每条开发需求描述,从输入、输出、限制约束等给出对应验证内容
• 通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据（功能交互分析），对存在功能交互的功能项，给出对应的验证内容
• 完整性，通过分解需求充分覆盖软件需求各种特性（包含隐含的特性），每个需求必须可以独立完成有意义的功能或者功能组合，可以进行单独测试，充分挖掘测试要点

STEP2 确定质量特性

对STEP1形成的每一条测试要点，对应质量模型中定义的质量需求，每条测试点，按照**“车轮图”**的软件质量子特性角度出发，确定所对应的质量子特性，同时适当反哺测试点

STEP3 确定测试类型

对STEP2所确定的质量需求，分析测试执行时需要实施的测试类型。不同质量子特性可以确定出不同的测试内容，这些测试内容可以通过不用的测试类型来实施，同时适当反哺测试点。

测试类型：功能测试、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复性测试、配置测试、兼容性测试、安装测试等等，之前课程已经有过介绍这里不再赘述。

根据子特性和测试类型、测试内容梳理对应关系

同时为了避免遗漏，根据实际工作还可根据以下进行完善和补充：

1. 开发标准、规范
2. 测试标准、规范
3. 测试案例库（测试经验）
4. 竞品同类产品分析的测试需求

关于显式需求和隐式需求

• 显性需求:—显而易见，直观的功能需求我们统一称之为用户的显性需求。
• 隐性需求：用户也不能完全清晰感受和用语言进行描述的，需要我们结合业务、用户、功能需求、对需求进行延伸性、依赖互补性等方面分析。隐性需求也叫兴奋需求，当用户的显性需求被满足时，用户一般不会兴奋或惊喜，而不被满足时，用户则会产生抱怨，比如用户在某音乐网站搜索《青花瓷》，如果搜索不到则会产生抱怨。当用户的隐性需求被满足时，用户一般会兴奋或惊喜，而不被满足时，用户却不会产生抱怨，比如用户想要听点新歌或者是来点周杰伦的歌。如果网站告诉用户：流行的歌还有《菊花台》、《牛X很忙》等等，用户立马精神崩溃：这网站太T了解我了。很显然，在这个过程中，网站激发了用户的隐性需求。
• 总结：
  • 满足用户的显性需求是底线。
  • 隐性需求是培养用户忠诚度的最好方式。

1.2.3 输出测试需求矩阵

测试需求矩阵明确了功能点与测试点的对应关系，输出测试需求矩阵，需要引入个评审环节，明确需求重要程度或优先级。

测试需求分组，在原始需求跟踪矩阵纲要下，结合质量属性、结合测试类型，补充完善，期间尽可能细化测试点、完善功能交互测试点、完善测试类型。

测试需求跟踪矩阵功能目前已经支持在FHTP线上管理

测试需求跟踪矩阵需要不断的维护：

• 软件需求一旦发生变化，应启动配置管理过程，将与软件需求变更相关的内容进行同步变更，如原始需求的增删改等，对应要重新进行内容完善，测试需求分析等工作；

• 随着测试工作进行，对测试需求的状态进行内容调整，如测试需求提测情况、测试用例设计情况，测试结果情况等。

1.3 测试需求分析评审

正确认识评审的意义和价值：

• 于个人：取其精华，取长补短，以人为鉴，自我提升；
• 于团队是一种管理手段，是工作有效开展的必要规范。

1.3.1 评审内容

完整性审查：应保证测试需求能充分覆盖软件需求的各种特性，灌输是否覆盖开发需求遗漏的、系统隐含的需求；

准确性审查：保证测试需求能够得到相关各方的一致理解，对测试需求之间没有矛盾，每条测试需求能够作为测试用例设计的依据；

1.3.2 评审过程

找到准确的人，在合适的时间，利用有效的时间段，专业完成内容的评审工作

1. 项目组人员、资深测试人员：精心挑选评审员

2. 约定时间

3. 评审时间不能过长，可以分段

4. 提前将原始需求、测试需求等材料进行发送，千万不要只发送一份测试需求列表出来，也要让参与者自行参与“测试需求分析”过程，独立研究

5. 做好会议纪要（问题、责任人、解决方案、时间），做好问题修复，做好邮件抄送，让过程闭环

1.3.3 评审方法

相互评审：交叉评审，推荐作为私下交流与学习的一种评审方式。

论查：相对耗时，以及不便于收集；异步评审方式，将评审内容发送各位评审员，收集反馈意见，现场开发比较常见，但是要保障评审员的参与度；

小组评审：日常最流行的方式；

四、做好测试分析需要哪些技能？

• 沟通
• 了解测试任务
• 产生和摒弃测试点
• 问问题
• 收集整理信息

Q&A问答

课后练习

结合食药环项目的”案件协查“功能模块，开展测试需求分析 需要实战讲师配合扮演项目经理角色，简单介绍需求，提供项目背景资料，需求文档（可挖坑），设计文档等材料。

实战讲师讲解需求，布置作业。