软件测试与开发全流程解析

一，测试和调试的区别

|------|-------------------|---------------------------------------------------|
| 维度 | 调试 | 测试 |
| 目的 | 调试的任务是定位并解决程序中的问题 | 测试的任务是发现程序中的缺陷，验证软件的特性是否符合用户需求 |
| 参与角色 | 主要由开发人员完成 | 测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成，单元/集成测试主要由开发人员执行 |
| 执行阶段 | 开发阶段 | 测试贯穿整个软件开发生命周期 |

二，认识需求

需要主要可以分为两部分：一部分是用户需求 ，一部分是软件需求

注意：用户需求不能作为测试和开发的工作依据，针对用户需求，产品经理需要对用户需求进行需求分析（技术可行性，市场可行性，成本投入和收益占比等）然后才变为软件需求。

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是最终端用户使用产品时必须完成的任务。一般比较简略，通常为一句话
软件需求：该需求详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据

三，开发模型

3.1 开发模型的概念

开发模型实际上指开发一款软件/功能需要具备的开发流程。规范的流程是在时代的演变下逐渐成型，而不是一开始就有规范的开发流程

3.2 软件的生命周期

需求分析 ------ 计划 ------ 设计------ 编码 ------ 测试 ------ 运行维护

3.3 常见的开发模型

3.3.1 瀑布模型

瀑布模型特点：在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每⼀个阶段都只执行一次，因此是线性顺序进行的软件开发模式
但是瀑布模型的缺陷也十分明显：
1.测试后置
a）前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会
b)必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给用户（产品质量差）
2.周期太长，产品很久才能被看到和使用，可能导致需求/功能过时
瀑布模型适用：需求固定的小项目

3.3.2 螺旋模型

⼀般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代
**特点：**螺旋模型在各个阶段引入了原型和风险分析（及时处理各阶段遗留问题，避免把问题遗留到后面导致大规模返工）
缺点：
1.项目中可能存在的风险性与风险管理人员的技术水平有直接关系
2.需求人员，资金，时间的增加和投入，会导致项目成本太高

3.3.3 增量模型，迭代模型

将大需求拆分成若干个小需求，每个小需求独立开发上线。随着互联网的发展，这两个模型是配合使用的

增量是逐块建造的概念，迭代是反复求精的概念

适用：大型项目，目标不明确

3.3.4 敏捷模型

敏捷模型主要旨在帮助项目快速适应变更请求。因此，敏捷模型的主要目的是促进项目的快速完成。
在敏捷模型中，需求被分解成许多可以增量开发的小部分。敏捷模型采用迭代开发。每个增量部分都是在迭代中开发的。每次迭代都旨在小而易于管理，并且只能在几周内完成。一次为客户计划、开发和部署⼀个迭代。没有制定⻓期计划。

敏捷模型的四个特点：轻文档，轻流程，重目标，重产出

Scrum是敏捷模型的一种，又称为迭代式增量软件开发模型。轻文档，快迭代

在Scrum模型中，主要有三个角色（产品经理，项目经理，研发团队）和五个重要会议（发布计划会议，迭代计划会议，每日例会，演示会议，回顾会议）

3.4 测试模型

3.4.1 v模型

缺点：仅仅把测试作为在编码后的一个阶段，未在需求阶段就介入测试。缺点同上瀑布模型

3.4.2 w模型（双v模型）

缺点：

1.需求，设计，编码等活动被视为串行的

2.测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一阶段工作

3.重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，w模型并不能解除测试管理面临的困惑

特点：测试的对象不仅是程序，需求，设计等同样要测试，测试与开发是同步进行的

四，BUG

4.1 软件测试的生命周期

软件测试贯穿于软件的整个生命周期， 软件测试的生命周期是指测试流程，这个流程是按照一定顺序执行的一系列特定的步骤，去保证产品质量符合需求。在软件测试生命周期流程中，每个活动都按照计划的系统的执行。每个阶段有不同的目标和交付产物

4.2 bug的概念

定义：⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误。
但准确的来说：

当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
当需求规格说明书没有提到的功能，判断标准以最终⽤⼾为准：当程序没有实现其最终用户合理
预期的功能要求时，就是软件错误

4.3 描述bug的要素

描述bug的基本要素**：问题出现的版本，问题出现的环境，问题出现的步骤，预期结果，实际结果**

4.4 bug的级别

bug级别一般分为：崩溃，严重，一般，次要

4.5 bug的生命周期

new：发现新的bug，未经评审决定是否指派给开发人员修改
open：确认是bug，并且认为需要进行修改，指派给相应的开发人员
fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试
rejected：如果认为不是bug，就拒绝修改
delay：如果认为暂时不需要修改或暂时不能修改，则延后修改
closed：修改状态的bug经测试人员的回归测试验证通过，关闭bug
reopen：如果经验证bug仍然存在，则需重新打开bug，开发人员重新修改

无效的bug：open > closed open - rejected - closed

五，用例篇

5.1 测试用例

测试用例（Test Case）是为了实施测试而向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素
为什么需要测试⽤例呢，不写测试⽤例可以进⾏测试吗？
测试中可能会遇到很多问题，诸如：不知道是否较全⾯的测试了所有功能；测试的覆盖率⽆法衡量；对新版本的重复测试很难实施（即回归测试⽆法仅通过⼈⼯测试的⽅式进⾏历史功能的回归）；存在⼤量冗余测试影响测试效率。测试用例的出现就是解决这些问题

5.2 设计测试用例

原则一：测试用例中一个必须的部分是对预期结果或输出进行定义

原则二：a）测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况

b）检查程序是否"未做其应该做的"仅是成功的一半，测试的另一半是检查程序是否"做了其不应该做的"

c）计划测试工作时不应默许假定不会发现错误

举个栗子：对门锁设计测试用例

设计测试用例时可按：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试

**功能测试：**从产品的功能角度出发，验证产品功能的正确性（功能没问题不代表性能没问题）

**界面测试：**肉眼可见的都叫界面，界面上所有元素都需要测试元素（大小，颜色，形状，材质）

**性能测试：**通常都是一些极端的情况

**兼容性测试：**浏览器的兼容性，不同版本（软件，系统）数据兼容性

**易用性测试：**具备简单易上手的属性

**安全测试：**接口请求参数，响应数据要考虑到数据的安全性，数据存储也要考虑到数据的安全性（越权：垂直越权，水平越权）

这里还有一个弱网测试，进行弱网测试需要借助如Fiddler等工具构造弱网环境

弱网测试的目的尽可能保证用户体验，包括：

1，页面响应时间是否可以接受，关注包括热启动，冷启动时间，页面切换，前后台切换，首字时间，首屏时间等；

2，页面呈现是否完成一致

3，超时文案是否符合定义，异常信息是否显示正常

4，是否有超时重连

5，安全角度：是否有登录ip更换频繁，单点登录异常等

6，大流量事件风险：是否在弱网下进行更新apk包，下载文件等大流量动作

5.3 设计测试用例的方法

5.3.1 基于需求的设计方法

基于需求的设计⽅法也是总的设计测试⽤例的⽅法，在⼯作中，我们需要参考需求文档/产品规格说明书来设计测试⽤例。
测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进⼀步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。

5.3.2 具体的设计方法

5.3.2.1等价类：

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出⼀个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题

等价类又分为：有效等价类和无效等价类

**有效等价类：**对于程序的规格说明书是合理的、有意义的输⼊数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能

**无效等价类：**根据需求说明书，不满足需求的集合

举个栗子：直接受山竹，桃子，榴莲三种水果

有效等价类：山竹，桃子，榴莲 ------三种具体的测试点都要覆盖到

无效等价类：葡萄，草莓，苹果 ------非山竹，桃子，榴莲这三种水果

5.3.2.2 边界值

边界值( 边界值即给定返回的最左边和最右边的数据**)分析法就是对输⼊或输出的边界值进行测试的⼀种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。**
边界值包含：边界值+次边界值
选择此边界值要根据边界值的有效无效来设计：
1）若边界值为有效的数据，则此边界值为无效的边界
2）若边界值为无效的数据，则此边界值为有效的边界

举两个栗子：
1）有效范围： $6,15$
边界值： 6 15（有效）
次边界值：5 16（无效）
2）有效范围：（6，15）
边界值： 6 15（无效）
次边界值：7 14（有效）

5.3.2.3 正交法

正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的⼀种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是⼀种基于正交表的、高效率、快速、经济的试验。
正交法的目的是为了减少用例数目，用尽量少的用例覆盖输入的两两组合

5.3.2.4 判定表

根据判定表法设计测试用例的步骤：

确认需求中输⼊条件和输出条件
找出输⼊条件和输出条件之间的关系
画判定表
根据判定表编写测试用例

5.3.2.5 错误猜测

错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从而针对性地设计测试⽤例的方法。这个⽅法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个⼈的经验和直觉。错误推测法和目前流行的"探索式测试⽅法"的基本思想⼀致，这类⽅法在敏捷开发模式下的投入产出比很高，被广泛应用于测试。

六，小结

本来准备把测试的分类一起介绍了的，但是感觉这样内容一下子太多了，还是留着下一章吧。我感觉好心碎啊，本来准备专心复习六级的，但是这几天一点都写不进去，算了算了谁让我有超绝好心态呢。这章不算复杂但是需要注意的小点还是有挺多的，我要去百度当测开，我一定要去百度当测开，啊啊啊。加油吧老铁们。因为我现在想找测开实习就开始写测试篇博客了，javaee部分后面会穿插着一起写哦，暑假还会开始持续更新算法题哦，大家敬请期待