聊聊软件测试那些事？？？

初始软件测试，测试流程，方法

1. 什么是软件测试
2. 测试用例
3. 阶段划分
4. 了解什么BUG?
5. 软件测试的分类
6. 功能测试划分
7. 研发管理模型
8. 项目的基本流程
9. 分享

也许，大家网上看到了这个词？这是个什么，又或者，大家早已经步入软件测试这个行业，已经在里面摸爬滚打了很多年了。越来越多人在探讨这个东西，如今的互联网公司，也越重视项目的质量。谈谈我是怎么走向这条路，记得当时是看到某知乎评论，一个叫浪晋的评论了一条，自学软件测试什么怎么学？大家可以去看看，里面的教学视频非常详细，适合小白入门。之后就根据浪哥提的建议，看完了浪哥罗列下的所有入门视频，也看了很多其他相关的视频，从B站找了很多学习视频，慢慢的走向了这一条不归路，呸呸呸，是这条good路。

什么是软件测试？

软件测试是验证软件正确地实现了一些特定功能的一系列活动，确认系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件。

软件测试，就是预期结果与实际结果之间的比较，检验之间的区别。像一个项目中，没有经过软件测试，是无法对软件的质量进行评判的。
发展过程，三个阶段分别是，也是经历了一段时间，不断的去修改

• 软件测试就是去证明软件是正确的
• 软件测试就是去证明软件是错误的
• 软件测试是保证软件的质量符合用户需求的一系列手段

测试用例

一. 测试用例可以衡量一个测试的工作，如果在产品发布上线之后，出现了重大BUG，领导就会找上门了，这时候你就要找出你之前写过的测试用例文档，证明你发现过这个BUG，并且开发也已经做了修改，我已经做了确认测试，那是你的责任就会小很多，但是，如果你真的是漏测了，那就嘿嘿嘿了。

二.测试用例的可复用性，产品已经不断迭代到非常后期，我们测试需要不断进行回归测试，因为我们不知道，新增了一个功能后，之前的功能会不会出现一个新的问题，这是我们无法推测的，所以回归测试，非常必须，但如果手工测试已经来不及了，赶不完工期，这时候就需要引入自动化测试，使用脚本，减少手工测试，大大的提高工作效率。

三. 测试用例是一个衡量标准，测试用例覆盖了所有的客户需求，覆盖功能点的100%，甚至更多。还可以反映出测试的进度，根据测试用例，去发现bug 让开发去更改，及时修复缺陷。
测试用例的基本组成
测试用例一般都是使用excel 表写的，里面需要包含以下所有的内容当然也是公司不同用例设计也会有差异。
测试编号
测试模块
测试名称
测试步骤
测试数据
前置条件
优先级
重要级
预期结果
实际结果

测试用例的评审
测试用例的评审有很多类型,对应的公司，流程也是不同的，像一些小的创业型公司，刚刚起步，也许测试用例都不需要写，直接进行测试，更别说评审了。
同行评审
小组评审
部门评审
第三方评审
项目评审
邮件评审

阶段划分

单元测试
指的是开发完成了一小个代码块了，进行测试功能有没有实现，一般情况都是由开发自测的

集成测试
当把代码块进行组合成一个个接口的时候，测试就需要对这些接口进行测试了，比如说，商城登录，当我输入用户名和密码，对应的接口需要去数据库中读取数据，看数据库中是否有之前登录的信息，如果有，就登录成功，没有，登录失败。都是需要与后台进行交互，这需要我们进行测试

系统测试
这是我们已经拿到可视化界面了，需要对其进行功能测试，比如说，UI，数据，表单值域，接口，逻辑，逆向思维等等一系列进行测试。
等到已经拿到可视化界面了，那时候基本也已经开发完成了，这个时候也就只能做功能测试，如果发现了重大bug，也已经无法进行更改

验收测试
一般是用户拿到产品，进行测试，已经到了后期，步入尾声。

了解什么BUG?

软件测试人员根据测试用例，发现bug,并进行校验，一般情况提交到禅道，由开发进行修改，测试进行确认测试，是否真的被修改，若修改成功，将这个bug进行关闭，没有修改成功，重新激活。

• 发现
• 验证
• 修改
• 关闭

禅道的使用
禅道就是一个管理项目bug的软件，这个软件公司一般是用来进行管理bug的，所有说，我们一定要学会使用它。

提交bug,我们需要填写的内容，也是叫做六要素，如果不填写，开发怎么知道是哪哪哪出了问题了，所以编写bug标题也是有门道的，如何让开发一眼看出，定位bug的位置，这就需要我们去思考的问题。

bug 的六要素，主要是说

要素名称	详细解释
编号	禅道会自动生成
名称	发现bug的具体情况
优先级	高中低
复现	bug的步骤/结果/期望
附件	可以添加一个截图，录屏
严重级别	致命/严重/一般/轻微

软件测试的分类

按方法进行划分：

黑盒测试
看不出内部结构，只能测试功能有没有实现，不能检查内部结构，功能测试就是大多数使用的是黑盒测试的这种方法，黑盒测试的代码覆盖率低。
白盒测试
根据代码，查看内部，白盒测试的方法：逻辑覆盖，路径覆盖，代码的覆盖率高，直接从根源查找问题。
灰盒测试
介于两者之间，即使用黑盒，也使用白盒，也是公司常使用的方法。

按方向划分

功能测试
性能测试
安全测试

性能测试又划分为：压力测试、并发测试
比如，模拟1000用户，同时访问该网站，多人用户一起并发，设置集合点，等着，直到1000用户，都在起跑线就位了，执行，一起登陆，进行压力测试，看服务器的各项指标的显示情况。
负载
不用一起进，一个一个进，看能入多少用户，还有一种情况也叫负载测试，同时进10个用户，看服务器的各项指标。
稳定性测试
进入网站，让他一直在网站里跑，随便做什么，看其稳定性，让用户长期待在网站，7*24小时，观察数据的情况。
做性能测试的时候，我们一般都需要使用到工具，比如说，jmeter和loadrunner,模拟大量用户，模拟更加真实的场景，实现用户访问，找到性能的瓶颈，发现问题。

其他

冒烟测试
测试之前，检测app是否具有可测性，指的是当我们一拿到产品，点都点不进去，或者说点击去直接退出，或者登录都不成功，就直接让开发修改过后再发过来做测试，打回去，冒烟测试未通过。

回归测试
当已经完成1.0的版本，客户说你帮我加个什么什么功能，然后就需要继续在原来1.0的版本是，添加新的功能2.0版本，这时候我们就要考虑，如果我们加了新功能，那原来的1.0版本会不会出现以下新的问题，或者缺陷，这些都是不可预测的，所有说，这个时候就需要我们测试做回归测试，参照之前写的测试用例，进行回归测试

α测试
内测，就是指把公司的一些员工，内部人员，开发，测试，运维，ui等等，叫过来一起测一下这个产品，使用会不会出现什么问题

β测试
拉一些用户，一起参与测试，看一下，在多人使用的情况，会不会发现一些没有发现的问题。

功能测试划分

接口测试，解释一下什么是接口，接口是开发界面与界面需要使用到接口继续交互，开发将写好的代码打包成一个接口，进行打包，比如登录页面，输入手机号和密码点击登录，跳转到首页面。接口测试我们用到的一般都是使用postman 这个工具，当然jmeter 也可以做接口测试，相比之下，postman使用更多，接口测试能发现很多我们在界面上无法看到的东西，也就是能发现更多的bug，因为我们不知道后台的数据是怎么传输的，我们发一个请求，服务器到底给我们返回个什么东西，界面是无法看到的。

UI测试，对可视化界面的测试，比如说，看这个页面内容有没有对齐，按钮的样式，页面的整体布局是否合理，符合用户的需求，错别字等，都属于UI测试的一部分。

表单值域测试，比如一些输入框，文本框都需要运用到这种测试方法

表单值域运用到的一些方法
等价类
举例，等价类又划分为有效等价类和无效等价类
有效等价类是说输入正确的数据，执行成功
无效等价类：即使说输入错误的数据
13888888888
138##q22586
边界值
比如说，页面输入，密码输入5-12位
这时候就需要考虑最小的4，5，8，12,13，等输入位数，都需要考虑进去
场景法
根据业务流程，考虑正确性和错误性
比如一个购物的流程，浏览商品----加入购物车—下单----发货-----收货这个流程
正常的话就是收获成功了
但是考虑不正常的情况就有很多种了，转动大脑，好好想想，比如说，手机没电了，断网了，物品卖光了，商品下架了，地址写错了，用户不想要了，等等一系列。。。写不完了
错误推断法
这个方法的运用，都需要具有一定的经验，能在之前已经做过类似的项目中，直接发现项目的bug,当然了，小白并不适用。
因果图
这种方法在公司很少被用到，如果想要了解的话，因果图,相对于比较复杂。
正则法
我们需要使用一些规则来控制用户输入的数据，比如说邮箱的登录，xxx.com，这时候就需要使用到正则。

数据测试
比如一些数据，需要从数据库中读取，产品仓库的件数等，当我们买了一件商品时，是否产品的数量对应的减少，从界面上，数据库都需要进行校验。

逻辑测试
业务逻辑，当用户登录以后才能查看的到自己购物车信息，考虑单一的，优惠券过期了，当库存只有30双了，你购买31双，显示库存不足。

安全测试
验证产品是否符合产品质量的标准，以发现安全隐患为目标，测试是用户不小心删除了数据，还是不法分子处心积虑构成的。
易用性测试
测试一个软件是不是好用，通常一个成功的产品，都能三步解决用户的需求
易用性包括，易理解，易操作，易学习，还有易吸引。这都是在进行易用性测试的时候需要进行考虑的因素。
兼容性测试
不同的手机型号，不同的配置环境，不同的版本，不同的浏览器看是否程序能否正常的运行，监测其结果
性能测试
看一个项目运行的怎么样，各项性能指标是否正常，比如说模拟大量用户进行同时访问，或者限定人数，进行一个个的访问，让用户长期挂在程序里，观察，性能测试中又包括，压力/并发测试，负载测试，稳定性测试

研发管理模型：

瀑布流
解释：瀑布流就是指从上往下的过程，每一个步骤之间都互相关联并且独立，优点是他们上下级分明，而缺点是不可逆，不变通。

V字形
按阶段来分的，首先进行需求分析，进行概要设计，详细设计，再由开发进行编码，之后测试再进行的测试，单元测试，集成测试，系统测试，验收测试，这也是不可逆转的，忽略了测试对概要设计和详细设计的过程。需求的满足情况一直到后期的验收测试才被验证。

W模型
这也是市面上用的比较多的一种方式，开发和测试同步一起做不同的事情，大大的增加了产品研发的效率，开发在写概要设计和详细设计，测试也需要写设计和测试报告，开发在编码，测试就已经可以做单元测试了，不过前提是你得会，哈哈，开发将写好的代码通过jenkins持续集成，测试跟着做集成测试，开发在实施部署，测试就可以做确认测试和系统测试，那是产品也就有了可视化界面了。最后进行验收测试，完成交付。

敏捷模型，是最近才出来的一种研发模型，也是在起步，但也会带来一些问题，不需要写很多文档，当出现一些问题时，维护起来很麻烦。但是可以频繁交货，与客户面对面的交流，减少了交流的时间，高效快速的设计并满足业务需求，如果用户想改变需求了，随时可以接受更改。减少了总的开发时间。
工作的形式：
及时的沟通
日报—>每个人写每天的工作情况
在公司挂一个白板，每个需要完成的任务，进度
每日站立会，站着开会，可能玩手机的时间就少了，想想都不开心啊，可能摸鱼的时间变少了。
集中办公–将一个项目小组，组织在一起，做起事来方便，效率提高

项目的基本流程

产品与客户交互，产品经理，划分根据需求，编写需求文档，评审需求文档-----产品经理画产品原型图-----开发编写概要文档，设计文档-----测试编写各种文档，项目的计划，测试安排，功能，编写测试用例----前端负责前端开发----测试进行接口测试-----发现bug----提交到软件（禅道）上-----开发修改bug-----测试进行确认测试-----不断循环-----以至于达到用户的需求，每个公司都有自己的上线标准，我们时刻都是站在客户的角度思考问题。以客户为中心，根据需求文档而不偏离中心。

分享

挺喜欢的一句话，分享给正在努力的你们，共勉
如果在本应该奋斗的年纪选择了安逸的生活，那么你就有可能会在该安逸的年龄忍受生活，世间万物，都是有因果轮回。所以别在年轻时蹉跎了岁月，而是勇往直前，无怨无悔的付出，加油。