【软件测试】入门篇

🏀🏀🏀来都来了，不妨点个关注！
🎧🎧🎧博客主页：欢迎各位大佬!

什么是软件测试

最常见的理解就是：软件测试就是找bug，发现缺陷。

日常生活中，很多情况下我们也其实在做测试，比如我们新买了一台电脑，我们会对它的性能进行测试；一次考试后，对完成的题目我们会进行检查，这也是测试；新买的电视机，我们也会打开播放电视剧看看是否能播放正常这也是测试。

软件测试就是验证软件产品特性是否满足用户需求。

什么是需求

上面我们提到软件测试是为了验证软件产品是否满足用户的需求，那么什么是需求呢？

需求的概念

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。
通俗理解：比如我想吃过桥米线，我想吃煎饼果子…这都是一个个的需求。
用户需求： 可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
软件需求： 或者叫功能需求，该需求会详细的描述开发人员必须实现的软件功能。

总的来说，用户需求就是一句话，而软件需求就是一个文档（详细描写用户需求如何实现），日常工作中，我们通常是用软件需求进行软件测试。

从软件测试人员角度看需求

需求是软件测试人员开展测试工作的依据。
在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出
每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。
过程如下，业务需求—>软件功能需求点—>测试需求点—>测试用例

下面，我们以最常见的用户登录功能进行举例说明：

如何深入的了解需求

一般可以通过参加需求评审会议，查询文档，沟通深入了解需求。

测试用例的概念

什么是测试用例

测试用例就是一组集合，包含测试环境，测试数据，预期结果，操作步骤等。
下面我们用leetcode来举例，
测试环境：我们用chrome浏览器打开leetcode此时，chrome浏览器就是测试环境。
测试数据：字节输入数据。
预期结果：通过100%。
操作步骤：写代码，提交。

为什么要有测试用例

• 测试用例可以提高测试人员的工作效率/降低工作人员测试工作的重复度
• 测试用例是建立自动化的基础

bug

软件错误（bug）的概念

当程序没有实现其最终用户合理预期的功能要求时，就是软件错误（bug）。
即预期结果！=执行结果

如何描述一个bug

一个合格的bug描述应该包括以下几个部分：
1、发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2、问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤
描述问题重现的最短步骤。
4、预期行为的描述
要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。要相信：测试人员是最懂需求的。
5、错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。
6、其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
7、不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

总的来说就是对描写出现bug的步骤越详细越好。

如何描写bug的级别

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。
以下为样例：
1、Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2、Critical（严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）。
4、Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）。

注意：当出现崩溃级别的bug时，我们需要停止测试，将测试打回。

软件的生命周期

人的生命周期：出生到死亡。
通过这个例子我们可以通俗的理解软件的生命周期就是从开发到永久停服。
生命周期：需求分析、计划、编码、测试、运行维护。

开发模型

瀑布模型

特点：整个过程是线性的。
优点：每个阶段做什么，产出非常清晰，
缺点：风险往往得在最后的测试阶段暴露，后期的纠错成本较高。
适用场景：适合于小型的开发周期短的项目。

螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

优点：每个阶段都会进行风险分析，避免线上问题的出现。
缺点: 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入

增量、迭代

拿我们平常开发一个个人博客项目举例，我们通常是先完成注册登录功能，再去完成比如发布删除博客的功能，再去完成个人中心功能等等。这其实就是增量开发模型。
增量开发：先完成注册登录功能模块，再完成发布删除博客模块，再完成个人中心功能模块。（每个模块单独开发，先开发完一个模块才去开发另一个模块）
迭代开发： 开发注册登录功能模块一部分，再开发发布删除博客模块一部分，再开发个人中心功能模块一部分。（先开发模块1的一部分，再开发模块2的一部分）

敏捷

轻流程，重交互，拥抱变化。
敏捷宣言：

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。

测试模型

软件测试V模型

特点：左边是开发，右边是测试，类似于瀑布模型
优点：测试被划分为很多模型
缺点：测试人员介入太晚，发现问题的时机太晚。

测试W模型（双V模型）

特点：开发一个V，测试一个V。
优点：测试人员尽早的介入了需求。
缺点：测试和开发人员一定程度上是串行的是一种线性的关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模型。

今天的分享就到这里了，谢谢支持！