软件测试基础

一.测试的必要性

所有的产品或者服务上线之前都需要进行测试

行业的现状

1.人员紧缺

2.内卷不严重 （国外：微软谷歌）开发测试比1：1，1：1.5

3.越来越重视

4.薪资越来越高

成长路线

管理方向：测试工程师——测试组长——测试经理——测试总监

技术方向：测试工程师——测试开发（测试里的开发人员）

测试人员要求

懂技术，懂代码，精通测试，懂运维

测试发展过程

证明-检测-预防-探索

二.基础概念

什么是软件测试

在软件中找BUG，发现缺陷

测试的定义

使用人工或者自动的手段来运行或者测试某个系统的过程。目的在于检验它是否满足规定的需求，弄清预期结果和实际结果的差别（IEEE协会定义）

重点：1.人工或者自动化的手段 2.过程 3.满足规定的需求 4.弄清预期结果和实际结果的差别

测试必备内功心法

MCP：Minimal Concept Principle（最小概念原则）

一.软件生命周期

** 计划阶段**

1.确定开发目标：开发一款计算器小软件

2.完成项目的可行性研究：确定软件项目能不能做？做出来之后有没有意义？

3.对项目进度进行预估和安排：找人，找时间，确定预算

4.制定实施计划

** 需求分析**

1.分析整理项目的需求项：决定项目具体有哪些功能需要开发，产品具有那些详细的特性

根据整理出来的需求项，编制需求规格说明书（SRS）：Software Requirement Specification

测试的目的

以最小的人力，物力和时间找出软件中潜在的错误和缺陷

测试的原则

证明软件中存在的缺陷。不能穷尽测试，测试应该尽早介入，28原则（80%的地方存在20%的错误），不存在缺陷谬论，妥善保存一切文档

测试的标准

国际标准：ISO25010(软件质量模型）国内标准：GBT20438(电气电子可编程电子安全相关系统功能） GBT18905（软件工程评价）

测试的基本要求

外观界面测试，易用测试（有没有反人类的地方），兼容性测试（在各大网站上运行会不会有问题），安全性能测试，性能测试，功能测试（功能是否正常运行 ）

BUG的由来

BUG：小虫子，现在指代程序中的错误

                                                       测试与开发模型

一.测试的工作流程

1.需求分析

阅读需求文档，产品文档，产品详细设计说明书，分析需求的点，参与到需求评审，快速熟悉项目

2.制定测试计划和测试方案

测试计划:测试整个项目的总体规划

测试范围：进度的安排，整体测试策略，风险评估，风险的规划

5W1H：why，when，who，what，where，how

测试方案：how

被测试目标，选取什么样的测试工具，测试的方法，测试的重点

3.设计测试用例：例：边界值，等价类

4.执行测试用例

5.评估阶段出测试报告

二.开发模式（7.7）

1.瀑布模式

计划时期-开发时期-运行时期

问题定义，可行性研究，需求分析，软件测试，编码，测试，维护

特点：1.阶段间具有顺序性和依耐性 2.推迟实现 3.质量保证的观点

特点总结：瀑布模型是文档驱动的模型，遵守这个约束可以使软件维护变得容易些，从未显著降低软件预算

优点：为项目提供了按阶段性划分的检查点，当前一阶段完成后您只需要关注后续阶段，可在迭代模型 中应用瀑布模型

缺点：不适合需求模糊或需求经常变动的系统 由于开销的逐步升级问题他不希望存在早起阶段的反馈 在用户可能需要较长等待时间来获得一个可供使用的系统也许会给用户的信任程度带来影响和打击 在一个系统完成以前它无法预测一个新系统引入一个机构的影响

2.增量模型

把瀑布模型的顺序特征与快速原型的迭代特征相符合将软件 看作一系列相互联系的增量，在开发过程的各次迭代中每项完成其中的一个增量

3.快速模型

快速分析-构造-运行-评价

特点：快速原型是建立起来的可以在计算机上运行的程序

优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，适合预先不能确切定义需求的软件系统的开发

缺点：所选用的开发技术和工具不一定符合主流的发展，快速建立起来的系统结构加上连续的修改可能会导致产品质量低下使用前提只要有一个展示性的产品原型，一定程度上可能会限制开发人员的创新

其他开发模型：1.螺旋开发模型：制定计划，风险分析，实施工程，客户评估 2.迭代开发模型 敏捷开发模型

测试模型

V模型：需求分析——概要设计——详细设计——编码——单元测试——集成测试——系统测试——验收测试

V模型和瀑布模型有相同特点，V模型中的过程从左到右描述了基本的开发过程和测试行为

优点：每一个阶段都清晰明了，便于控制开发的每一个过程，既包括单元测试有包括系统测试

缺点：测试介入较晚，对于前期的缺陷无从发现和修改测试和开发串行，总用时较长

W模型

优点：测试伴随软件的整个生命周期 例如：在需求分析结束后就可以进行需求分析测试，测试于开发是并行独立进行

缺点：对需求和测试技术要求高，适用于大中型企业

测试人员与开发的关系

1.目标相同：都是为了制造出高质量的软件

2.相辅相成

3.侧重点不同

                                           软件测试分类（7.7）

                                                               测试用例 

一.概念

  测试用例的定义

测试用例又叫做test case，是为某个特殊目标二编制的一组测试输入，执行条件以及预期结果以便测试某个程序 路径或核实是否满足某个特定需求

测试用例的特性

有效性：测试用例的能够被使用，且呗不同人员使用测试结果一致。

可复用性：良好的测试用例具有重复使用的功能，如：回归测试

易组织性：好的测试用例会分门别类地提供给测试人员参考和使用

可评估性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是产品质量好坏的测试标准

可管理性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量的好坏的测试测试标准

  测试用例的要素

测试用例的八大要素

1.测试用例编号（ST-子项名-01）：编号由字符和数字组合的字符串，用例编号具有唯一性，容易识别

2.测试项目/模块（手机登录）：测试的项目属于哪个项目或者被测试的要求，被测试的模块，被测试的单元等等

3.预置（前提）条件（手机正常使用）：执行当前测试需要的前提条件，如果前提条件不满足，则后面的测试步骤不能进行或者得不到预期结果

4.测试输入（手机号）：测试用例执行过程中需要加工的外部信息，根据测试用例的具体条件有手工输入.数据库等

5.预期输出（正常登录）：测试用例的预期输出结果包括返回值内容，界面响应结果等

6.操作步骤（输入手机号并确认）：执行当前测试用例需要经过的操作用例，需要明确的给出一个步骤的描述，测试用例执行人员可以根据步骤完成测试用例执行

7.测试用例标题（测试能否手机登录成功）：对测试用例简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点是不一样的

8.级别：对于测试用例的重要程度的区分包含以下几种

高级别：保证系统基本功能，核心业务，重要特性，实际使用频率比较高的用例

中级别：重要程度介于高和低之间的测试用例

低级别：实际使用的频率不高，对系统业务功能影响不大的模块或成功的测试用例

其他要素

1.用例的设计者：能准确找到测试用例的设计人员，对用例修改时能方便找到人员

2.用例设计日期：方便检查用例的设计进度

3.对应的开发人员：出现bug后能及时找到相应的人员进行修复

4.测试结果（实际结果）：执行用例最后执行的结果，包括：pass，fail，block

5.测试类型：功能，性能，压力等等

 测试用例的设计原则

明确性：测试人员要尽量避免测试用例存在含糊的因素，在测试过程中，测试用例的测试结果是唯一的

代表性：尽量将具有相似功能的测试用例抽象合并，功能相似的用例要合并

简洁性：测试用例简洁，可读性良好，测试过程目的明确，测试结果唯一。测试用例要用 陈述性语句一句话直指问题的核心，不要使用浮夸的修饰手法

小结

测试用例要素是为了便于我们快速的设计测试用例，因此要掌握最常用的八大要素，但是每家公司的具体要求不一样，要根据公司要求灵活添加测试的元素

点点点工程师如何变得更专业

1.知道测试是什么，不是什么。

2.知道怎么去做测试。

3.从标准和规范的角度，保证全流程软件质量，防范质量风险。