测试基础理论及测试用例编写
一、测试流程
1、每日工作流程
每天9：30站立会议 （工作进度透明化，问题随时有解决方案）
昨天干了什么
今天准备干什么
有什么问题
2、项目团队
项目经理 PM、前端、后端、测试、产品
3、研发部门
后端、前端、测试、产品、运维
4、直属上司
测试经理、项目经理、测试组长
5、对测试的理解
质量管理——会沟通，风险把控，过程推动
效率提升——测试技术
6、测试的要求
全流程参与
具备测试技术（自动化测试）
7、产品需求评审（自研——PRD，外包——需求设计文档）
Axure RP：产品设计文档的软件
8、测试角色
项目经理：Leader
产品：规划产品具体怎么做
开发：（后端开发、前端开发）根据产品的规划依据代码来实现它
测试：依据产品的需求文档依据开发转测的产品，来验证产品是否满足用户的需求，主要考虑的是页面的UI页面和交互
二、软件测试定义
经典定义：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程
在规定的条件下对程序进行操作
1、有时间限制
2、必须参考的文档是需求设计文档
3、每个版本都有需求边界
以发现程序错误，衡量软件质量
1.1、验证程序是否符合产品经理设计的需求文档
1.2、验证程序员编写的代码逻辑
1.3、如果是WEB产品，需要考虑主流浏览器（Chrome、FirefoxU、IE)的兼容性测试
1.4、如果是APP产品，需要考虑主流移动平台的兼容性测试（IOS、Android)
2、主要区分功能性和非功能性（不同浏览器、安全性、性能测试）
3、测试完成的标准
3.1、新功能测试通过
3.2、系统已有功能
3.3、所有BUG已解决
并非对其是否能满足设计要求进行评估的过程
逻辑、UI设计，页面，页面交互都符合最初的设计
三、软件测试原则
一般软件测试的原则是期望测试能够尽早的介入到整体研发流程，优势具体如下：
1、尽早的熟悉产品的需求，产品PRD的设计文档以及产品逻辑
2、从敏捷角度而言，文档准确性以及文档的可用性也是需要测试被验证的之一（一般测试很少这样做）
3、协助产品，站在用户的角度来思考产品设计逻辑的合理性
4、尽早进入可以更多的理清程序的逻辑
5、在具体到产品进行PRD评审的时候，能够尽快的进入具体的逻辑盒思考中，而不至于说之前不理解，可能一直游离在思考的阶段
四、软件测试目的
1、软件测试的目的
发现问题，发现至今未发现的问题，检查系统是否满足需求
测试程序执行的过程，目的在于发现错误：
一个好的测试用例在于能发现至今未发现的问题
一个成功的测试是发现了至今未发现错误的测试
软件测试的对象主要包含了：UI的⻚⾯展示，程序内部的逻辑交互，⻚⾯提示信息，UI的页面布局展示，和色调等
2、发现错误
1、程序的具体的逻辑
2、页面的交互的验证
3、浏览器的兼容性的验证
4、易用性的验证
3、工作内容
1.1 要求参与公司产品体系的所有流程和工作
1.2 参与到开发技术方案的评审和开发代码的评审
1.3 测试工作：编写测试用例，评审测试用例，测试具体的程序
1.4 上线后的产品质量监控
五、软件测试的原则
1、测试基于用户需求
被测试的产品是服务于用户的，是给用户赋能的。产品会收集用户的需求，需求评审后，大家就会达成一致的目标
2、做好软件测试计划是做好软件测试工作的关键
测试计划会明确规范每个事件点的工作内容，工作进度，工作安排和工作完成度
测试计划应包括：所测软件的功能，输⼊和输出，测试内容，各项测试的进度安排
3、尽早的开始软件测试并不断的进行软件测试
1）从产品经理发出需求开始，测试工作都已经进行了开展，梳理需求点，梳理逻辑
2）产品上线后，需要持续跟踪产品的运行情况，如果有设计不合理的，需要记录，到下个版本加入到需求里面
4、测试前必须明确定义好产品的质量标准
1）会有质量标准，达到标准就可以上线，达不到就是不能
2）在设计测试用例的时候，需要考虑到产品各个维度
5、避免测试自己的软件
场景：线上出现问题，程序员修改完成后，测试员自己进行测试，同时反馈结果是OK的，那么测试还需要吗？需要测试，因为程序员测试不代表考虑到所有的测试场景，必须经过测试进行验证
6、应充分注意测试中的集群现象
1）尽可能的覆盖以及考虑到更多的场景，但是无法做到100%的覆盖
2）测试需要持续不断的进行
7、必须检查每个实际输出结果
8、穷举测试是不可能的
解决办法：优先考虑优先级高的业务场景进行测试，优先级低的，可以在上线后再进行测试
9、测试设计决定了测试的有效性和效率
编写测试方案：测试的思路
10、注意保留测试设计和说明文档，并注意测试设计的可重用性
六、软件测试分类
1、按阶段划分
单元测试——Unit test
是针对程序最小离度的测试，它主要是应用于白盒测试
程序是由代码写的。代码里面最小单位是方法，所以单元测试是针对方法的测试
主流编程语言：C(编程单元：cunit),Python,Java,Go,Net
测试方法：白盒测试，根据不同编码由对应的测试框架，java里面是Junit和TestNG框架，Python里面是UnitTest和pytest测试框架
TDD（测试驱动开发：Test-Driven Development）：先写测试代码，再写程序代码
集成测试
服务都是通过对外提供API进行交互
是把单个模块的程序集成到一起后的测试，集成测试主要来验证各个模块集成后模块与模块之间的功能性，以及各个模块集成后的功能流程性和逻辑兼容性的测试
现代版的集成测试（API测试：接口测试）
1、现代企业都是前后端分离的模式，前后端各自完成工作后，需要联调来验证产品的完整性
2、后端与后端的联调
3、公司程序员与第三方程序员之间的联调
测试方法：黑盒测试、白盒测试、灰盒测试
系统测试
将软件系统看成是一个系统的测试，包括对功能、性能以及软件所运行的软硬件环境进行测试，时间大部分在系统测试执行阶段来验证被测程序的整体性的功能
1）系统测试现在又称为端到端的测试（and to and）
2）可以理解为产品的业务链，从开始至结束所有的流程验证测试
3）测试内容：功能、界面、可靠性（服务持续运行是否出现瘫痪）、易用性，性能、兼容性、安全性等
验收测试
验收测试是部署软件之前的最后一个测试操作，它是技术测试的最后一个阶段，也称为交付测试
验收测试流程
1）自研公司：由测试发起，产品经理来进行验收，产品经理验收测试通过后，再开始上线
2）外包：外包验收是甲方（客户）来进行验收
2、按查看代码分类
黑盒测试
把被测试的程序看成是一个黑色的盒子，看不到里面内部的结构，对应的是系统测试，他是功能测试的一种形式
测试方法：等价类、因果图、错误推测、边界值
白盒测试
被测程序看成是一个白色的盒子，能够看见程序内部的结构，对应的是单元测试
测试包含了针对程序判断逻辑，判断分⽀，判断循环，程序流程走向的测试
灰盒测试
介于白盒测试和黑盒测试之间，它对测试的要求是：能够参与开发代码的评审，以及开发代码的检查
针对程序判断逻辑，判断分支，判断循环，程序流程走向的测试。白盒测试是一种高技能的测试。对测试的技术水平要求是比较高的
3、按编写代码分类
手工测试
优点：自动化测试是无法替代人的测试的行为模式的，也无法替代探索性的测试
缺点：执行效率慢，影响测试交付的效率
自动化测试
通过编写代码（使用工具）的方式来代替模拟人的一种行为方式来对系统进行的一种测试
自动化测试又分为UI自动化测试，API自动化测试，性能自动化测试。一般性说的自动化测试大多数时候指的是UI自动化测试和API自动化测试
软件质量
描述当前软件是否好用，在当前的软件行业里我们所采用的一套标准是基于ISO组织指定的，需要我们记忆的就是软件质量的六大特性：
功能性：软件需要满足用户显式或者稳式的功能。
易用性：软件易于学习和上手使用。
可靠性：指的就是软件必须实现需求当中指明的具体功能。
效率性：类似于软件的性能。
可维护性：要求软件具有将某个功能修复之后继续使用的能力。
可移植性：当前软件可以从⼀个平台移植到另⼀个平台上去使用的能力。
三大主流平台：windows unix linux
软件测试的人工检查
队列：先进先出，堆栈：先进后出
软件开发四大主流领域
服务端测试开发、算法测试开发、大数据测试开发、移动专项测试开发
数据类型
int、字符串、float、bool：ture flase
表达式：<、=、>、&&(并且）、||（或者）、++（现有基础上加1）、--（现有的基础上减去1）
软件的分类
中间件：redis、Memcache——（缓存中间件） kafka、RabbitMQ——（MQ）
Windows常用命令
ipconfig：查询IP的地址
cmd：win+R，输入cmd，就可以打开控制台
dir：展示当前目录下的文件和文件夹
cd d:/：进入到了D盘
dir：进入到D盘目录的文件夹
pwd：查询当前的在哪个盘下
测试术语
冒烟测试
目的是确认软件基本流程正常
使用场景：开发转测后，测试要进行冒烟测试，验证被转测的软件基本流程是否正常
探索性测试
探索性强调测试⼈员的主观能动性，抛弃繁杂的测试计划和测试⽤例设计过程，强调在碰到问题时及时改变测试策略
使用场景：测试报告已经完成，要准备上线前，对产品进行探索性的测试
安全测试
目前安全测试更多的聚焦于渗透测试这部分
回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
自动回归测试将大幅降低系统测试、维护升级等阶段的成本
回归测试的场景
1）转测后，新的功能测试完成，对系统已有功能进行回归测试
2）上线前，开发对代码进行了合并，需要对系统整体的进行回归测试
3）上线后，对产品进行整体的回归测试
七、如何做软件测试需求分析
1、为什么要做需求分析
软件测试需求是设计测试用例的依据
有助于保证测试的质量和进度
软件测试需求是衡量测试覆盖率的重要指标
2、拿到需求分析测试需要做什么
了解本迭代要做什么
本迭代功能是否影响之前的功能
提出疑问点
3、软件测试需求分析步骤
列出需求文档中的具有可测性的原始需求
对每一条需求进行细化分解，形成可测试的分层描述的测试点
对形成的每一个测试点，从软件产品的质量需求来分析，确定测试执行时需要实施的测试类型
建立测试需求跟踪矩阵，对测试需求进行管理
4、测试需要分析的主要目的
获取测试点，根据测试点来编写测试用例
5、需求文档内容
1、业务逻辑以及流程图
2、页面交互
3、文字描述具体的逻辑过程
八、测试用例
1、概述
测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体
2、编写用例
1)写的非常详细，测试步骤很详细
2)思维导图的模式
3)checklist
选择的原则是什么：
和现在的团队保持一致，至少对自我的要求上，要比现在的团队做的好
3、目前公司采用的模式
敏捷模式：小步快跑的模式
2周一迭代、pm:1、test:4、前端：2 后端：5、产品：1——总人数：13
故事：有开始有结束，一般是task（任务）发布
第一周：
周一：熟悉需求，评审需求，列计划
周二：编写测试用例
周三：评审测试用例，完善测试用例
周四&周五：编写自动化测试case,等开发转测试，以及冒烟测试验证
第二周：
周一：开始第一轮的测试
周二：回归所有的bug,开始第二轮的测试
周三：开启系统测试，准备提交验收测试
周四：编写测试报告，准备上线前的工作
周五：跟踪上线后的产品情况，然后项目内部复盘
版本更新是持续改进的一个过程
pm:60%
测试负责人:40%的参考意见来自测试负责人
测试经理:40%
复盘（pm主持）：
1、哪些方面做的好
2、哪些方面做的不好，怎么改进
4、测试点分析
1、通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）
2、各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试）
3、考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，比如界面的验证，异常情况（界面、易用性、兼容性、安全性、性能）
5、测试需求相关方影响
解决方案：
1、逻辑不清晰，找开发同学多讨论
2、开发与测试意见不一致的情况下，找产品经理
3、产品的逻辑不合理，找产品经理，同时找开发同学，统一意见
4、测试⽤例是为特定的目的而设计的⼀组测试输⼊、执⾏条件和预期的结果。测试⽤例是执⾏的最⼩实体
拿到测试需求 -> 分析需求（画思维导图） -> 编写⽤例 -> 划分用例优先级
6、测试用例编写特征
一致性，覆盖率，可执行性，执行准确性，持续更新，复用性
7、测试用例组成元素
用例ID、用例名称、测试目的、测试级别、参考信息、测试环境、前提条件、测试步骤、预期结果、设计人员
练习
测试步骤需要简单易懂，清晰明了
测试用例三种表达方式
1、excel/csv 或者WEB平台编写，
特点：非常详细，步骤非常明确，缺点：写起来很慢
依据测试用例表格，列出需要测试的相关点，正常逻辑与每种异常情况都可以分为一个测试点进行描写
2、思维导图
特点：使用一句话描述测试场景 特点：结构化思维非常强，让人很明晰的可以看到编写测试人员的思维结构
3、checklist
场景一：比如早上出需求，晚上上线，那么就使用这种方式
场景二：使用该方式梳理出测试的思路
场景三：和开发单独去对一些复杂的逻辑
如：拉勾网需要搜索10K至15K的测试开发工程师招聘信息
可以在输入搜索的职位关键字后，选择薪资为10K至15K，结果展示的信息包含了10K至15K的结果数据
正常测试工作流程
评审通过后，查看评审需求描写相关测试用例，完成后需要进行测试用例评审
1、先确认是否有空的会议，按时间开会讨论测试步骤，参与人员一般有：产品经理、其他测试、开发等
2、在讲述过程中，随时会有人依据测试用例内容提出异议，任何测试中出现没有涉及到的场景或是不合理的场景都会被指出
注意事项：一般问题较小的话可以当众修改，问题较大的话，可以在先简单记录，会后自行修改
3、修改完成后可以在工作群中@参会的人员进行核实，一般测试主管会查看修改后的内容
完整流程
首先需求评审，编写测试用例，评审测试用例，开发转测，测试进行冒烟测试，正常功能和性能测试测试，验收测试（发送给产品经理验收，邮件回复），产品上线
