测试总结(半年的实习+试用)

一、软件安装

1.SQLServer或者Mysql，可网上寻找教程，一定要安装正确，每一个步骤严格按照标准走
2.jdk包，配置环境变量
3.VPN，方便自己居家或者公司以外的地方办公，在公用网络上建立专用网络，通过对数据包的加密和数据包目标地址的转换实现远程访问。
4.fiddler，用于测试过程中的接口抓包和开启手机代理
5.Switchhost，用于快速切换hosts；需要以管理员身份运行，管理本地主机的IP和端口
6.XMind,用于梳理测试用例的框架和测试点、影响点
7.svn,有利于测试用例的更新和查看日志，会获取到本地和提交
https://blog.csdn.net/weixin_42313773/article/details/121786576
8.录屏软件，确保无法截图说明情况的复现路径可顺利保存；有利于和开发之间的交流
9.github
安装教程：https://www.jb51.net/article/199788.htm
登陆地址：http://gitlab.beisencorp.com/users/sign_in
常用语句：
克隆：git clone …;
本地更新：git pull origin;

二、测试过程

1.确保对需求文档和设计稿的理解尽可能的覆盖全场景，需求中有疑问的点一定要和开发、产品一起沟通，需求文档的更改需走需求变更，每次及时接收新的变更。每天站会同步更新的内容。测试要不断的关注需求变更，实时更新测试用例
2.熟练使用公司专有的用例库。
需求文档存储地址、测试计划的创建地址、bug提交以及追踪地址
熟练使用f12开发者工具，快速定位前后端问题：前端：按钮，新增显示表单，点击确定新增显示列；后端：数据正确，选择某个设置可正确生效

1.企业

自研公司：自己做的产品自己内部去用
外包公司：项目外包(项目经理、开发团队、测试团队)：整个项目组，全部由外包公司出
人员外包（测试、开发）：客户需要什么人员，提供什么人员 给客户做东西——一般会在客户那边工作
方案公司：客户需要什么项目 给客户做东西——在自己公司工作

2.职业规划

管理方向：质量经理、项目经理、产品经理、HR
技术方向：讲师、架构师、测试开发、安全测试、白盒测试
其他：研发、运维、售前售后
产品(写需求文档的人)测试不分家
软件=产品

3.测试简介

所谓软件测试：就是一个过程或者一系列过程，用来确认计算机代码万乘客其应该完成的功 能，不执行其不应该有的操作。
测试的更好定义：为发现错误而执行程序的过程。(试图发现错误的破坏性的过程)有输入值即需要预期输出值。

测试用例集：测试用例的集合。
通过测试来增加程序的价值，是指提高了程序的可靠性(找出并最终修改了程序的错误)或质量。
目的：带给客户高级的用户体验。使得产品更容易被接受。已正确的实现用户需求的过程
测试对象：
①程序：功能正确
②文档：用户手册和运维手册，内容完整正确
③数据：系统配置文件，符合国家规范

4.软件测试经济学

 1.黑盒测试——数据驱动的测试；输入/输出驱动的测试
重点在于发现程序不按其规范正确运行的环境条件。(测试数据完全来源于测试规范)
‘穷举输入测试’：对所有可能的输入进行测试。
难以实现：无法测试一个程序确保其是无错的；软件测试的经济学；
有限的测试用例，最大限度的提高发现的问题的数量
 2.白盒测试——逻辑驱动的测试
检查程序内部结构
‘穷举路径测试’：程序中的每条语句至少执行一次
 3.软件测试原则
  ①测试用例中一个必须部分是对预期输出或结果的定义
输入数据描述；输入数据下的正确输出结果精确描述。
  ②程序员避免测试自己编写的程序；编写软件的组织不应当测试自己编写的软件；
  ③彻底检查每个测试的执行结果
后续测试中发现的错误，往往是前面的测试遗漏掉的
  ④测试用例的编写不仅应当根据有效和预期的输入情况；而且也应当根据无效和未预料到的输入情况
  ⑤检查程序‘未做其改做的’和‘做了其不应该做的’
  ⑥应避免测试用例用后即弃，除非软件本身是一个一次性的软件——回归测试
  ⑦计划测试工作时不应默许假定不会发现错误
  ⑧程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
残存错误与已知错误间令人惊奇的联系；错误总是倾向于聚集存在(群居性)

5.测试分类

软件质量特性：功能测试(界面)
 可靠性测试
  易用性测试
 性能测试(负载测试、压力测试、并发测试、稳定性测试)
 兼容性测试
冒烟测试(一般开发做，即开发demo：确定软件基本功能正常)、回归测试、探索性测试(随机)
(测试思维)bug、功能、主业务(关联)
质量模型：功能性、
 可靠性(eg:电脑重启)、容错性
 易用性(eg:页面布局、右下角为我的，左下角为首页)、
 效率(eg:时间问题)、性能测试
 维护性(eg:系统 面向客户 app、面向管理员 web)、缓存、后台和前台的联动：后台修改，前台联动变化
 可移植性(适应性、易安装)

6.测试工作流程

项目计划书：项目立项
1).需求评审阶段：
产品经理或项目经理给出需求文档、需求分析规格说明书：详细功能的描述。——理解
在需求宣讲之前查阅需求文档和设计稿，记录自己的困惑、问题，在宣讲过程中提出并记录结论——带着问题参与会议。
需求反讲中需记录问题，后续持续跟进问题结论。
2).测试计划阶段：
测试经理编写测试计划、范围、资源(硬件、工具、人员)、团队工作安排、评审会议、输出文档(测试计划：后期工作按照当前节点进行交付)。
时间安排要合理且到位，预留突发事件的影响。
3).测试设计阶段：
自己负责的模块进行需求分析(XMind)、测试用例(组内评审、用例修改)
首先整理自己负责story的测试框架和测试思路，覆盖的整体测试点，测试内部会议确认是否遗漏和需要补充。
用例评审——测试人员、开发、产品集体参加，评估测试用例的执行力度和覆盖程度。补充遗漏的测试点。
需要和开发人员对接，确保提测和demo的时间，以便实时的调整测试的工作进度，保证预留时间充裕，合理规划测试时间。
4).测试执行阶段：
搭建测试环境，执行测试用例(状态)，缺陷，交付——执行后的测试用例；缺陷列表(bug)。
不同阶段关注bug情况，否决的、开发的、产品的。是否需要日清，是否达到日清。
及时更新需求变更部分的测试用例以及测试过程中发现的错误的测试用例。
5).测试评估阶段：
测试报告(实际测试环境、数据的总结和分析、测试遗留缺陷处理、软件版本质量评估、后续的测试建议、测试结论)；资料统计给测试组长。——迭代总结

7.测试用例的设计

测试用例包括：
 所属用例库
 所属用例模块
 标题
 优先级
 前置条件
 操作步骤
 期望结果
 用例类型(功能、交互)

先使用黑盒测试方法设计测试用例，视情况需要使用白盒设计补充的测试用例。
 1.黑盒测试
 2.白盒测试
 3.等价类划分：有效等价类、无效等价类
 4.语句覆盖
 5.边界值分析：上点(边界上的值)；离点(刚大于边界上的值)；内点(上点之前的值)
 6.场景法
基本流——正常流(按照业务流程——模拟用户的操作流程)
(流程图——业务流程节点(路径))
备选流——错误流(程序错误的流程——模拟错误的操作流程)
 7.因果图分析：多个条件组合、不同组合有不同的输出结果’’
判定表=条件桩(条件/因子)+条件项+动作项+动作桩(结果)
 8.正交试验
有几个值，每个值的结果有几种，选择已有的正交表使用，不建议自己写。
 8.判定覆盖
 9.条件覆盖
 10.错误猜测
 11.判定/条件覆盖
 12.多重条件覆盖

设计需求本身功能点的，优先级调到P1、P2
正向思维和反向思维

 1.需求文档、原型、设计
 2.等价类、边界值、错误推测法(经验)
 3.数据的存储方式、缓存方式、消息中间件、前后端的接口以及请求数据
 4.自动化测试：逻辑重复的功能；相同功能的多种数据情况；数据快照
测试计划
 测试计划、
 所属项目、
 所属迭代、
 计划状态、
 计划阶段、
 负责人

8.Bug管理工具Jira

 项目、
 问题类型(缺陷、任务、故事、测试申请)；sprint(所属迭代)、
 模块(story)、
 测试阶段、
 概要(简洁说明问题)、
 经办人、
 优先级、
 测试bug原因分类(用例缺失、测试遗漏、需求优化、需求变更、旧有bug、兼容性问题、性能问题、改bug引起、偶现问题、编码错误、影响点未评估、测试错误、发版错误、数据问题、其他团队问题、)
 描述(环境、场景、模块、预期、实际、复现路径、截图、视频)，
 是否用户体验

9.bug根源

需求错误：需求不合理，需求遗漏
编码错误：程序代码错误
测试错误：测试过程中出错，测试场景、路径不正确
界面错误：对界面进行某种操作产生的错误
数据错误：基础数据配置错误
性能错误：性能原因
兼容：浏览器或者操作系统版本问题
发布：测试发版过程中造成的问题(配置文件、机器是否正常运行，环境版本)
设计错误：系统设计或详细设计中的错误(架构设计、界面设计)

10.P0级测试用例——主流程

一般在正式进入测试之前，开发demo前发出，邮件给到对应的开发人员，确保正确查收。

测试用例优先级
P1:核心功能点(端到端的用例覆盖点)，此部分失败则阻碍主流程的验证
eg：增删改查功能
 权限问题，不能漏权或者多加权限
 新建、提交、编辑、下载等操作
 页签的切换操作
P2：重要功能如交互、应用场景，使用频率较高的测试点
 页面翻页操作
 必填项提示
 验证码
 正向验证操作
P3：一般的系统功能
 特殊字符
 边界值、字符串
 无效等价类
 取消、确认操作
新增数据验证按钮点击是否正确，数据能不能正确增加——P1
功能类、数据正确——P2
显示类的——P3

三、测试心得

1.测试过程按照迭代计划顺利进行，评估自己负责story的时间，测试计划的创建和测试用例编写时间、测试时间都要严格把控，每天更新进度；延迟的原因和解决方案是什么，下次这种情况能否避免
2.测试过程中，需要一直和产品、开发交流，此环节必不可少，怎样有效沟通且在自己可控的时间内解决好此问题，培养自己快速定位问题的能力
3.很多时候，测试进度总会被其他业务线影响，调整心态，及时更换测试内容，或者定位关键干系人，有效解决阻碍，评估影响时间
4.测试过程中，总会有开发寻求bug复现，或者需要支持别的bug验证，自己也是在业务的学习阶段，对于自己不懂的地方一定要问清楚，沟通之后要明确沟通的结论即使自己不懂也必须确定结论，不可按照自己的理解用于对业务的本身逻辑。
5.测试人员需自信，大胆提出自己的质疑、困惑以及对业务的见解，团队整体需达成一致，才能确保测试进程不会出现方向偏离，工时浪费的情况
6.阻碍的地方，思考自己有什么办法可以解决，业务不懂的地方哪些方面需要加强；什么情况下可以寻求帮助，寻求的对象能否在最短的时间内解决自己的问题
7.在不断的学习过程中，多以产品和用户的角度去看看待模块实现的必要性和成本，交互体验，以及带来的价值。
8.提高错误定位的能力，熟悉f12工具，以及界面接口，对于表单等界面区分前后端问题。报错定位为后端：检查机器是否在线，配置包和版本是否正确，远程登录查机器配置，sql脚本是否正确。
9.测试过程中，明确测试任务边界，确保自己任务范围内的事情做到细致和极致，必须保证测试的质量。其他的影响若在自己边界范围外或者不是测试人员导致，被动承担风险和责任，不必要太在意，做好自己就好，领导会进行合理评估。
10.测试人员的心态必须要稳定，持续稳定。一切以高效解决问题为目标。