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

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

课前活动

约定：

强调培训纪律和要求，定个基调

• 有问有答；
• 不懂就问；
• 思辨；
• 对自己负责；
• 赏罚分明；

预热：

Bug是什么？每人1分钟阐述。

Bug就是任何削弱产品价值的东西。

这个定义对质量的理解紧密相关，质量就是就是对某个人/些人的价值，因为这个定义揭示了质量最主要的一个方面，即质量是主观的，同样的产品对不同的人，质量可能是不同的。 ----- 《海盗派测试分析》

课程内容

一、软件测试的目的

预热问题进行互动交流，引入课程正题

二、概述

1 测试发展概述

软件测试在不断探索中寻求发展，认知上发生了哪些改变？

• 1975年“证明软件的工作是正确的”
• 1979年 “发现错误而执行的活动”
• 1983年 “测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量”
• 2002年 “测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程” ……

软件测试已经逐渐形成了自己的一套体系，拥有自己的成熟度评价方法，随着软件开发的发展敏捷开发，持续迭代等各种软件开发实践也会给软件测试带来更多的新挑战，产生更多新的测试技术和测试理念。

求真务实，不断地寻求测试技术、理念上的发展与创新。充分发挥主观能动性，拥抱变化。

2 职业发展概述

2.1 发展方向概述

软件测试在管理上的发展：测试经理、测试总监等 软件测试在技术上的发展：软件测试架构师，专项测试工程师（如 性能测试技术专家）

• 软件测试在职业发展上，基本可以分为两个方向：测试管理、测试技术；由于软件测试行业的特性-基于实践的学科，即使是测试管理方向也不存在纯粹的管理者，因为测试管理角色更应该保持对软件测试相关技术的领先性，在产品测试中不断的实践、总结、再实践、再总结才能不断提升自己；
• 软件测试“测试技术”与“测试管理”之间是可以相互转换、交叉发展的； 无论我们现在或是将来朝哪个方向发展，测试技术是不可或缺的；

2.2 测试角色与职责

产品测试负责人(测试总监)

1. 分担测试部KPI

2. 分担研发资源部KPI

3. 协调安排产品、各项目测试工作

4. 人才梯队建设、培养

5. 产品开发效率、开发质量跟进、推进

6. 上线测试，为产品正式上线铺路

7. 实测摸底，推进产品质量

项目测试负责人（测试经理)

1. 根据产品测试负责人的安排负责既定工作的安排、执行、汇报

2. 参与需求分析、设计评审

3. 制定测试计划，设计和执行测试用例，进行缺陷跟踪和软件质量分析等

4. 带领其他测试工程师执行项目测试，包括制定个人测试计划，分配测试资源，构建测试环境，执行测试，回归测试等

5. 带领团队做好测试工作，保证被测系统质量

6. 通过创新、改进，提升测试效率、质量；推动研发体系效率、质量的提升

业务测试工程师

1. 参与既定工作的计划；负责自身工作的计划、执行、汇报
2. 专研测试技术和测试设计方法
3. 精通测试流程，按照流程有效开展测试工作
4. 处理复杂问题，高效定位、协调谈判、冲突管理
5. 使用自动化工具，参与编写自动化工具
6. 团队合作，保证个人计划成功的同时，通过信息互通，经验分享，协助等方式，推动团队的成功

自动化测试工程师

1. 对自动化技术和自动化测试框架进行整合、研究和推广，提升部门自动化技能水平；
2. 参与项目自动化测试方案评审以及自动化测试结果评估；
3. 提供自动化测试技术咨询和人才培养；
4. 作为产品技术小组一员，负责产品自动化测试工作；
5. 负责部门公共系统开发；

性能测试工程师

1. 对性能测试技术和性能测试工具进行整合、研究和推广，提升部门的性能技术水平；
2. 参与项目性能测试方案评审以及产品性能评估；
3. 提供性能测试技能咨询与人才培养；
4. 作为产品技术小组一员，负责产品性能测试工作；

测试架构师

1. 对测试技能的总结、研究和推广，提升整个部门的测试技能水平；
2. 参与项目测试策略评审以及产品质量评估；
3. 推动部门测试平台化建设，加强部门测试技能沉淀；
4. 提供测试策略咨询与人员培养；
5. 作为产品技术小组一员，对产品测试负责；
6. 作为第三方对测试人员能力进行评估；
7. 了解行业发展方向，参与部门发展方向的规划；

角色的不同仅仅体现分工的不一样，并没有级别的区分。因此，角色并没有贵贱之分。每个角色的技能集都非常明确，相同角色的承担者在技能的层次上也可能存在很大的差异。随着技术和经验的积累，每种角色都可以成长出资历深厚的专家。专家和菜鸟，在某种程度上，仅仅是一种“闻道有先后”的差异。

三、软件测试的基本概念

“测试者从哪些方面（测试类型）用哪些方法（测试方法）去测试产品（质量属性）”

测试分析：测试成功的目标和标准是什么？

测试设计：这些目标和标准如何达成？

四、软件质量是什么

“正确、全面、深入的理解用户需求”是测试的基础，验证产品质量是否满足用户的需求是软件测试中一个重要的目标。

首先我们需要明确“软件产品质量模型”是什么。

“软件产品质量模型”将一个软件产品需要满足的质量划分为六大属性：功能性、可靠性、易用性、效率、可维护性、可移植性。

1 功能性

功能性是指用户在指定条件下使用软件产品时，提供满足明确和隐含要求的功能的能力。

功能性包含适合性、准确性、互操作性、安全性、功能顺从性，下面我们将以某宝为例，进行介绍：

功能性——适合性

软件产品为特定的任务和用户提供一组合适功能的能力

• 以某宝为例，软件产品应为用户提供所有和购物相关的功能，就是适合性。如商品查询、筛选、下单、支付功能等，除了这些明显的功能之外，某宝还应提供一些用户在特定场景下才可能会想到、用到的功能，如查看历史订单，查看查询记录。

功能性——准确性

软件产品提供具有所有精度的正确或相符的结果及效果的能力。

• 以某宝为例，实用查询功能，搜索“鞋子”，查询结果中应为鞋子相关商品，不会是98K，平底锅等商品。

功能性——安全性

软件产品保护信息和数据的能力，以保证未授权的用户或者系统不能阅读和修改这些信息与数据，而合法用户或者系统不会被拒绝访问。

• 以某宝为例，某宝不应包含能够被利用的安全漏掉与“用户权限”相关的内容，用户密码的需进行加密处理。

功能性——互操作性

软件产品与一个或多个特性、系统相互配合的能力。

• 以某宝为例，聚划算、天猫超市、天猫国际功能之间的相关跳转。

功能性——功能顺从性

软件产品符合和该功能相关的标准、规范、规则或特定的能力。

2 可靠性

可靠性是指用户在指定条件下使用软件产品时，软件产品维持规定的性能级别的能力。

可靠性——成熟性

软件产品为避免因软件故障而导致失效的能力。

• 成熟性可以理解为产品的功能失效的概率，以某宝为例，某宝系统运行过程中，是否会出现搜索商品无响应等方面错误，一般来讲，可以通过重启APP等方法恢复。

可靠性——容错性

软件产品在软件发生故障或者违反指定接口的情况下，维持规定的性能级别的能力。

• 以某宝为例，新增收件地址时，手机号码为空，系统是否会给出相应提示。不会因用户的任务错误输入，导致软件无响应，重启等异常。

可靠性——可恢复性

软件产品在失效发生的情况下，重建规定的性能级别并恢复受直接影响的数据的能力。

• 可以理解为软件一旦出现自身无法预期的异常，能够恢复（自动或被动）。

可靠性——可靠性顺从性

软件产品遵循与可靠性相关的标准、约定或者规定的能力

3 易用性

易用性是指用户在指定条件下使用软件产品时，产品被用户理解、学习、使用和吸引用户的能力。 简单概括：易懂、易学、易用、漂亮好看。

易用性——易理解性

软件产品使用户能够理解软件是否合适以及如何能够将软件用户特定的任务和使用环境的能力。

• 以某宝为例，易理解性是指我们能够理解页面图标有功能的映射关系，如看到“相机”图标，点开是拍照，而不是设置页面。

易用性——易学性

软件产品使用户能学习其应用的能力。

• 以某宝为例，首次使用淘宝的用户与具有多次使用经验的淘宝用户，完成一次订单的时间大致是相同的，这就是易学性的体现。易用用户快速上手，降低或者简化了用户的学习成本。

易用性——易操作性

软件产品使用户能够操作和控制它的能力。

• 以某宝为例，搜索框输入“阿迪”时，会自动联想“阿迪”相关的选项供用户筛选。

易用性——吸引性

软件产品吸引用户的能力。

易用性——易用性的依从性

软件产品遵循与易用性相关的标注、约定、风格指南或者法规的能力。

4 效率

效率是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。 通常，效率就是我们所说的性能。

效率——时间特性

在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐量（流量）的能力。

• 以某宝为例，搜索商品的请求响应时间可以理解为时间特性的一个体现。

效率——资源利用率

在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力。

• 以某宝为例，10万用户进行下单操作时，占用服务器的资源（内存、CPU等）是否合理，可以理解为资源利用率的一个体现。

效率——效率依从性

软件产品遵循与效率相关的标准或者约定的能力。

• 可以理解为淘宝应满足多少用户操作，系统资源占用率或者响应时间应控制在什么范围内的要求。

5 可维护性

可维护性是指软件产品可被修改的能力。这里的修改是指纠正改进软件产品，和软件品对环境、功能规格变化的适用性。

可维护性——可分析性

软件产品诊断软件中的缺陷，失效原因或识别待修改部分的能力。

• 以某宝为例，当系统发生严重的异常（无响应、重启），系统能够捕捉并记录这些异常信息，并且这些信息对于开发人员来讲是足够的、有价值的、能够为定位或者重现问题提供帮助的。

可维护性——可修改性

软件产品能够被修改的能力。

• 以某宝为例，可修改性可以理解为，当某宝修复缺陷时，可以通过升级、更新操作来进行缺陷修复、验证.

可维护性——稳定性

软件产品不会因为修改而造成意外结果的能力。

• 以某宝为例，稳定性可以理解为，当某宝通过更新修复缺陷时，不会引入新的问题，系统能够稳定运行。

可维护性——可测试性

软件产品已修改的部分能够被确认修复的能力。

• 以某宝为例，可测试性可以理解为，系统的所有新增、改动的功能都是可以测试的，都是可以通过测试验证功能是否正确，符合需求预期。

可维护性——可维护性的依从性

软件产品遵循与维护性相关的标注或者约定的能力

• 以某宝为例，当确认订单时，由于某种故障或异常，导致下发失败，系统会弹出相关提示信息，是可维护性的依从性的一种体现。

6 可移植性

可移植性是指软件产品从一种环境迁移到另一种环境的能力。

可移植性——适应性

软件产品无须采用额外的活动或者手段就适应不同指定环境的能力。

• 以某宝为例，适应性可以理解为，在不同电脑分辨率下，页面的布局，大小都可以正常的展示.

可移植性——可安装性

软件产品在指定环境中被安装的能力。

• 以某宝为例，可安装性可以理解为，应用否顺利的被安装在不同的操作系统上，并且可以正常运行。

可移植性——共存性

软件产品在公共环境中同于其分享（复用）公共资源的其他独立组件共存的能力。

• 以手机某宝和某猫为例，共存性可以理解为，手机某宝与某猫存在服务器上的复用（共存），这种复用不会存在资源争抢方面的问题。

可移植性——易交替性

软件产品在同样的环境下，交替另一个相同用途的制定软件产品的能力。

• 以手机某宝为例，若某天开发出手机某宝的替代品A，A能够成功替换掉某宝（注意是共存，而不是升级）

可移植性——可移植性的依从性

软件产品遵循与可移植性相关的标准或约定的能力。

五、测试类型和方法

1 软件测试类型

如果说质量属性解决的是从哪些角度去设计产品才能满足用户需求，那么测试类型解决的就是测试要从哪些角度去分析和测试产品（测试类型指的是测试需要考虑的不同角度）。

2 软件测试方法

结合上面讲的内容，我们下面回答“测试者从哪些方面（测试类型）用哪些方法（测试方法）去测试产品（质量属性）”的问题。

这里需要强调的是，测试不是越多越好，而是需要根据产品的质量目标、产品的风险分析来确定测试的重点和难点、深度和广度。

下面我们重点介绍可靠性测试中的几种测试方法，简单介绍下易用性测试方法，关于易用性测试后续会通过专题方式(可用性测试)与大家进行交流：

2.1 可靠性测试

可靠性测试测试的是产品在各种条件下维持规定的性能级别的能力。（在功能基本正确的前提下，开展可靠性测试。）

可靠性测试方法——异常值输入法

异常值输入法是一种使用系统不允许输入的数值（即异常值）作为测试输入的可靠性测试方法。

• 以某宝为例，某宝账号注册时，手机号填写为“123456”或者空时，系统会给出相应提示。

异常值输入法可以测试到系统的容错性，能够测试到系统处理各种错误输入的能力，是最基本的可靠性测试法方法。

可靠性测试方法——故障植入法

故障植入法是把系统放在有问题的环境中进行测试，主要能够测试到的质量属性是容错性和成熟性。与异常值输入法不同，异常值输入法是直接输入一个系统认为是错误的、不支持的值；而故障植入法是把系统放在有问题的环境中，但是输入依然是正常值。

• 以用户发送邮件为例，网络故障对用户来说是一个常见的故障，如断网，网络时断时续，存在丢包，在断网情况下，用户发送邮件会发送失败，系统应该有发送失败的提示，并在网络恢复的情况下能够自动重新发送邮件。

可靠性测试方法——稳定性测试法

• 产品规格指的是产品承诺的能够处理的最大容量或能力。例如某宝系统最多支持1亿用户并发下单，这就是产品规格。

稳定性测试法是在一段时间里，长时间大容量运行某种业务的一种可靠性测试法，需要特别指出的是，稳定性测试法、压力测试法、性能测试法是存在一定关系的，这个关系纽带就是产品规格。

• 稳定性测试是在低于性能值的前提下进行测试的。测试时，我们需要结合用户实际情况控制测试中的负载量，使测试结果更具准确性和可靠性。
• 压力测试是在高于性能值的前提下进行测试的。测试时，我们需要注意并不是负载超过了系统的最大处理能力，系统功能都会失效，例如，OA签到做多支持500用户并发登录，但某时550用户同时进行登录时，系统应保证550个用户中，500用户是可以正常登录，而不是所有用户都无法登录。
• 性能测试 是验证产品真是规格是否与建设书或说明书中承诺的规格一致。（不属于可靠性，此处提出仅用作方法间的比对，避免混淆）

稳定性测试法四字诀：“多、并、复、异”。

• 多：在测试中通过增加用户对功能的操作数量，才测试系统的稳定性。我们可以测试10000用户下单或者20000用户下单，更多的需要结合用户实际使用情况，来确定一段时间范围内的使用数量。
• 并：在测试中让多个用户同时来操作这个功能，由此来测试系统是否依然稳定，即并发测试。我们可以测试10000用户并发下单时，系统的稳定性。
• 复：在测试中让一个或者多个用户，反复进行登录、搜索、下单、支付等不同场景下的类似操作，以此来测试系统的稳定性。发现系统在资源申请、释放上是否存在问题。
• 异：在测试中让一个或多个用户，反复进行异常操作，验证系统是否能够持续做出合理反映。我们可以测试在某宝注册页面，持续（1天或者1周）填写手机号码为非法输入等情况下，系统稳定性。

可靠性测试方法——压力测试法

压力测试法是在一段时间内持续使用 超过系统规格的负载进行测试的一种可靠性测试方法。 我们需要明确几点：

1. 用户的业务负载并不是平均的，可能在极短时间内，出现超过负载的情况，如某宝双十一。
2. 不建议用持续超过系统规格负载的测试方法进行压力测试，只要负载足够多，系统总会被搞挂。
3. 建议使用突发形态的负载模型，进行压力测试，什么是突然形态伏在模型？假设某宝最大支持10000个用户并发提交订单，参考突然形态负载模型，我们可以设置如下负载场景，以每分钟为一个周期，在一个周期里前40秒为6000个用户同时提交订单，后20秒为12000个用户同时提交订单。持续测试1天。

2.2 易用性测试

易用性测试方法——一致性测试法

一致性测试法的测试对象是用户界面，如WEB页面、命令行等用户和产品直接进行交互的地方。 一致性测试法在测试中关注的是产品的用户界面：

• 风格、布局、元素上是否一致、统一。
• 布局的合理性、操作的合理性、提示等是否符合UI设计规范。

一致性测试法能够测试到产品在易理解和易用性依从性方面的能力，但它并不关心产品功能是否正确，所以可以直接对产品的UI设计原型进行测试，而无须等待功能全面集成后再进行。

易用性测试方法——可用性测试法

可用性测试法的测试对象也是用户界面，但在可用性测试中，我们关注的是产品提供的功能，对用户来说是否易于学习理解、易于使用，所以可用性测试需要和功能测试结合起来，以场景作为测试粒度，以用户的视角进行测试。

即可用性测试最佳的人选是又懂用户又懂测试的人，如果能力不能兼具，懂用户、会使用的人更适合。不过在实际项目中，我们往往没有选择，进行可用性测试的人往往还是功能测试人员。由本功能的功能测试人员来进行可用性测试，最大的问题就是操作上的“审美疲劳”——一个设计得再不合理的UI，作为它的功能测试者，早就“被习惯”了。所以更好的方式是在测试团队中作“交叉测试”，即你测我的、我测你的。

六、质量、风险、成本、效率的关系

保障质量，需要付出成本，但一个项目可以投入的成本是有限的，这些成本花费在哪里最划算？最容易出现bug的地方。

因此我们需要做风险分析，任何风险都有两个重要属性，即风险发生的可能性和风险发生后的影响。我们要尽可能的收集潜在风险（风险识别），并对每一种风险评估其可能性和影响的值，在综合起来排序（风险分析），针对风险最高的部分投入成本。

做好了风险分析，我们知道应该在那些方面投入成本来保障质量，但需要保障的点很多，项目时间又有限，如何提高效率呢？需要技术的革新，理念的突破，工作流程方式的优化改进来提高效率。

提高效率在一定程度上是可以降低成本的，但在另一面来看，能量守恒，为了提高效率做出的优化，势必也要投入成本来实现。

所作的一切都有个平衡点，这个平衡点就是如何取舍来保障产品质量，如何在有限的测试时间和测试资源的条件下，从无尽的测试思路中选取那些最正确的测试思路，使用合理高效的方式来进行测试，以便达到**”以尽可能少的时间、发现尽可能多的、尽可能重要的Bug“**的测试效果。

质量、风险、成本、效率之间，效率是的发力点，效率高了，时间成本才能降下来，才能做更多风险分析和控制预防的工作，才能保障质量。当然，这个循环也可能倒着转，风险评估分析出了问题，投入了大量成本，质量无法保障，问题越来越多，没有成本去优化提效，越做越难，越做越慢，项目质量崩盘。

七、面向未来的软件测试工程师应该具备的能力

• 测试开发能力

Q&A问答环节

课后练习

结合基础理论所学所想内容，预习测试分析课程，对FHTP某功能进行测试分析与设计（摸底），字数控制在XX字以内，提交word文档。

【备注】：结合预习情况和作业完成情况，分析测试分析与设计的授课重点