一、今天完成的事情：

1.看腾讯课堂松勤网视频进行复习。--https://ke.qq.com/user/index/index.html#/plan/cid=159919&term_id=100184508

第三节：软件测试快速入门

1）软件测试是什么？

是产品质量的保障，找出产品的缺陷，提升用户的满意度。

对象：软件（程序/文档/数据）、系统、项目、产品

分类：app、web、服务器、窗口

目的：尽早、尽多、尽快地发现产品的缺陷，提升软件质量，提升用户满意度。--软件测试工程师

          从客户角度划分：产品（QQ，微信等）、项目

          如何选择公司：做产品的公司，产品经理主导，代表客户群体，对产品更了解，自己要选有前景的产品；做项目的公司，项目周期相对短暂，有特定的群体，项目经理担任主要角色，把控项目，自己缺少对项目的沉淀。

2）软件测试如何开展？

需求（面试时可能会遇到被问某个东西怎么测试？此时应注意不是直接去考虑怎么测，而是要问清楚确切需求，有没有需求文档。没有需求就无法评判它是不是满足用户需求，用户是否满意。）-->计划（什么时候开始测、需要测哪些点、需要什么工具、需要多少人等。最好形成测试计划书）-->测试用例设计（要求：按照测试用例可以测出问题）-->测试环境搭建-->发现bug-->开发修复bug-->测试验证bug-->总结报告

3）用松勤商城举例

需求：没有需求文档时，需要自己分析，如看到前台页面，要考虑后台改变对前台的影响，不能只考虑前端显示的内容，前后端结合测试

业务背景：在线销售平台--客户端（细分APP端和web端） & 商家端

      应该有3个端：用户端、商家端、管理员（可能只有两端）

      如何判断项目有几个端：根据性质判断，性质如下

      性质：作为产品卖给别人（比如淘宝将自己作为产品打包卖给别人，商家端和管理员就是一个端）还是作为公司自有第三方平台运营（有三个端）。

UI测试点：

a.链接测试、导航测试、导航条测试

导航测试测试点：鼠标提示、正确打开内容

图片测试

内容测试

兼容性测试

测试用例（为了方便维护，可能有时不会测试细分到输入框等，只是编写测试正常、异常、特殊情况3个测试用例）

用例编号：TC-1

用例名称：验证没有登录的情况下输入正确信息松勤商城可以正常留言，并且后台可以查看

优先级：高
测试步骤：1.访问松勤商城主页

                 2.打开在线留言页面

                 3.填写正确格式的留言信息

                 4.提交留言

预期结果：1.页面提示留言成功

                 2.登录后台查看是否有留言

实际结果：网站页面丢失，留言失败，测试不通过

用例编号：TC-2 异常

用例编号：TC-3 错误推测

4）测试做完后，测试报告写什么？（测试报告是对负责项目，模块的总结报告，写几个关键点）

a.发现什么问题？

b.做了什么事情？（测试了哪些模块，哪些点）

c.是否合格？（产品质量如何，测试是否通过）

2.第一次复盘评审结束，总结有如下问题：

1）bug的级别

2）bug的生命周期，从提bug开始

3）bug的分类

4）提bug的格式

5）如何简单的判断bug应该提交给谁

1）bug的级别和3）bug的分类--https://wenku.baidu.com/view/a8e122e86294dd88d0d26b33.html

       一般来讲bug报告中，按照bug类型分、 bug级别分、bug重现能力分

      bug类型分--https://www.cnblogs.com/yangsun/p/9751581.html

      以禅道为例：

      ①代码错误

      ②设计缺陷

      ③界面优化

      ④性能问题

      ⑤配置相关

      ⑥安装部署

      ⑦安全相关

      ⑧标准规范

      ⑨测试脚本

      ⑩其他划分：功能类、界面类、性能类、易用性类、兼容性类、其他

      bug级别分--https://www.cnblogs.com/yangsun/p/9751581.html+https://wenku.baidu.com/view/a8e122e86294dd88d0d26b33.html

      致命错误（1级bug，必须优先改）：

      ①常规操作引起的系统崩溃、死机、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其他方法实现的。

      ②造成数据泄露的安全问题，比如恶意攻击造成的账户私密信息泄露

      ③涉及金钱，如支付类软件，金钱计算错误

      ④需求书中的重要功能未实现

      严重错误（2级bug），严重错误常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主    要问题：

      ①重要的功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误。

      ②重要功能不能按照常规操作实现，但可通过其他方法实现

      ③错误的波及面广，影响到其他功能正常实现

      ④非常规操作导致的程序崩溃、死机、死循环（非常规操作：用户使用软件时不会进行的操作）

      ⑤外观难以接受的缺陷（例如：直播平台的封面图片失真、压缩，完全变形）

      ⑥密码明文显示

      ⑦C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。

      一般错误（3级bug），不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷：

      ①次要功能不能正常实现

      ②操作界面错误（包括数据窗口内列名的定义，含义不一致，例如列名与列名下的内容不一致）

      ③查询错误、数据错误显示

      ④简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可以由前端判断）

      ⑤删除操作未给出提示

      ⑥打印内容、格式错误

      ⑦数据库表中有过多空的字段

      ⑧因错误操作迫使程序中断

      ⑨找不到规律的时好时坏

      ⑩数据库的表、业务结构、缺省值未加完整性等约束条件

      ⑪经过一段时间运行后，系统性能或响应时间会变慢

      ⑫重要资料，如密码未加密存放（包括配置文件中的密码），或存在其他安全隐患的

      ⑬硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才可以）

      ⑭系统兼容性差，与其他支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行测试的

      细微错误（4级bug），程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误：

      ①界面不规范

      ②辅助说明描述不清楚

      ③提示窗口文字未采用行业术语

      ④界面存在文字错误

      ⑤输入输出不规范

      ⑥长操作未给用户提示（或长操作结束后提示没有消失）

      ⑦可输入区域和只读区域没有明显的区分标志

      ⑧在功能实现方式上如果需求中没有明确的定义，而没有按常规实现，并且不比常规实现方式优越的（如用户第一位用数字或特殊字符）

      bug重现分

      一般分为：必显、偶尔、不可见、比例呈现。

      对于比例呈现，一般会在bug描述中说操作了几次，出现了几次，大致写一个概率。如果实在不好定位，就打出log文件进行分类说明。

2）bug的生命周期，从提bug开始--https://www.jobui.com/mianshiti/it/ruanjianceshi/6956/

bug的生命周期就是从发现bug开始到结束（即该bug确保不再出现）的周期。

①New：bug被测试人员发现，但是没有提交给任何开发

②Open：bug被提交给开发，由测试人员改为open。

③Rejected（拒绝修复）或duplicate（该bug被重复提交）或deferred（延期解决）

④update：开发修复了bug但是还没有提交给测试人员，由开发将状态改为Update

⑤Fixed：开发修复之后并自测通过提交给测试人员，由开发奖状态改为Fixed

⑥Close：由测试验证确实修改正确后，将状态改为Close

⑦Reopen：有测试验证仍然没有修复，则将状态改为Reopen，再次提交给开发，让其修复

4）提交bug的格式--https://www.cnblogs.com/liyongmei/p/10663001.html

发现bug后，接下来你要提交到bug管理平台，提交一个bug包含哪些内容?

bug标题--标题要清晰简洁，写明bug的描述；如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人清楚知道你所表达的意思。bug的功能模块+bug的操作+bug的结果

重现步骤--步骤一简单写下发现bug的测试过程，罗列下。能指导开发重现这个bug。附上测试数据实际结果----此项bug的结果，粘贴bug截图，日志截图，截图直接粘贴，不要添加附件，附件：日志、测试数据（文件）图片，比如上传头像，就把图片放在文件中当附件上传，开发要重现这个bug，根据你附件的图片重现。预期结果--要写清楚。

Bug的类型和严重程度--便于后续测试结果分析，bug的统计

bug测试环境--例如：什么系统；哪个版本。什么浏览器。兼容性问题、难以重现问题

附件--日志文件、文件测试数据等

5）如何简单的判断bug应该提交给谁--https://blog.csdn.net/Anita__Li/article/details/90751837

如何判断bug提交给前台还是后台

前台的bug通常是功能、界面和兼容性等有关；后台的bug与逻辑、性能和安全有关。与数据相关的错误、排序问题大多是后台问题，对于APP页面toast提示可能是后台给的，也可能是APP给的

法一：前端的bug主要分为3个类别：HTML，CSS，JavaScript三类问题：

①出现样式问题的基本都是CSS的bug

②出现文本的问题基本都是html的bug

③出现交互类的问题基本都是JavaScript的bug

法二：可以通过请求接口、传参和响应三部分来判断bug，另外，也可以在浏览器的控制台进行代码调试定位。

①请求接口URL是否正确，如果请求接口URL不正确，为前端bug

②http请求中的参数是否正确，如果不正确，为前端bug

③如果请求接口URL和参数正确，查看响应内容是否正确，如果这种情况下响应内容不正确，则为后端bug

④如果JS基础比较好的话，也可以在浏览器的控制台输入JS代码进行调试

二、明天计划的事情：

1.进行第二次复盘评审

三、遇到的问题：

1.服务器测试和窗口测试是什么？

服务器测试--https://blog.csdn.net/guyan1101/article/details/72582404

1）直接对WEB或者APP的服务端测试。

2）对更后端的数据库、缓存系统、中间件、文件系统等进行测试。

3）对服务器硬件的测试：

包括HDD，内存，CPU，主板，PCI/PCIe设备，电源等。其中也包括BIOS以及各硬件的Firmware信息等内容。

具体包括以下几个大类：

机型配置--主要测试组装硬件的基本信息。

功耗--整机运行时的功耗，包括CPU、内存、电源。

性能测试--包括CPU、内存、HDD。

可运维测试--具体指在Linux系统下通过系统指令得到一些基本信息，系统支持则涉及该机器在安装OS之后的一些特定功能及插件。

在系统整合性测试中包括：RMC远程管理模块的测试，BIOS测试，Function测试，BMC测试，Nic网口测试，performance性能测试，稳定性测试。

窗口测试--（我理解为应用程序窗口测试）

大概了解下

--http://airtest.netease.com/docs/cn/1_quick_start/4_get_started_with_Windows_test.html

--https://www.cnblogs.com/redmoon/p/11401030.html

四、收获：

1.明白软件测试概念。

2.明确软件测试的流程：需求-->计划-->测试用例设计-->测试环境搭建-->发现bug-->开发修复bug-->测试验证bug。

3.没有需求文档时注意如何分析业务需求。

4.复盘评审结束知道自己哪些重要遗漏了或者还很薄弱。

5.收获一篇软件测试类工程师简介的文章--https://www.kanzhun.com/jobs/113779/