入门

概念

验证软件满足用户的需求。

测试分类

分为：动态测试和静态测试

软件测试和研发的区别?

(1)~软件测试和调试的区别

目的不同:
软件测试是检查软件的质量(以需求为标准)
软件调试是开发人员为了检查程序是否实现了他(开发人员)想让程序实现的功能
人员不一样:
软件测试，黑盒测试工程师，白盒测试工程师，开发人员（单元测试，或者白盒测试)、用户
软件调试，开发人员
阶段不同:软件调试，只在开发阶段
软件开发的生命周期:
软件测试:贯穿到了整个软件开发的生命周期

其中软件生命周期：需求分析-计划-设计-开发-测试-运行

(2）难易程度，技能要求

开发广度小，专业度高（ java工程师 java框架 增删改查）
测试广度大，专业度低
接口测试 postman soupui Charles
抓包fiddler Charles 测试的手段
模拟弱网工具(性能测试) jmeter
自动化测试 java Python ruby unittest TestNG安全测试 网络知识Linux tomacat 数据库

测试左右移

测试左移:需求前调研阶段和需求阶段，测试人员参加。
测试右移:产品上线后，系统监控，日志记录和分析。

概念

需求

软件开发中的需求:需求就是满足用户的期望或者合同规定的标准，规范，文档所需要的条件和权限。

bug

(1)当软件需求规格（软件需求)存在并且合理，如果软件功能和软件需求规格不相符合，我们就说是软件错误（BUG)
(2)当软件需求规格不存在的时候，用户需求存在并且软件功能和用户需求不相符，就是软件错误(BUG)。

测试用例

向被测试系统发起的一组集合，这组集合包括测试数据，测试步骤，测试平台，预期结果。
例子1
例子2
例子3
例子4

例子

一个测试人员所具备的素质

(1）软件测试这个岗位的兴趣
(2)有能力，编程能力，懂几门编程语言，沟通，团结协作(team work)
(3)责任感和承受一定的压力
思维方面’发散性思维，逆向思维

开发模型

瀑布模型

优点:各个阶段比较独立，看重需求分析和软件测试;
缺点:无法适应需求的变化;测试到编码后才介入，导致前期的缺陷无法及时发现。无法及时修正。适用的项目:适用于需求稳定的项目。

螺旋模型

适用的项目:前期需求不是很明确，并且有风险，项目比较庞大的系统开发;
优点:强调软件质量;每一次迭代进行严格的风险分析，提供讨论项目是否有必要进行下去的机会缺点:引入风险管理，会投入大量人力物力;

迭代增量模型

一个系统的四个功能，A模块、B模块、C模块、D模块，两周时间完成
迭代模型:第一周开发人员完成ABCD四个模块基础功能,第二周，在基础功能之上进行细化和完善;
增量模型:第一周，完成A模块，B模块，第二周完成C模块D模块。
迭代模型抗风险能力更强

敏捷模型

轻文档，轻流程，重目标，重质量（目标交付一个高质量可用的软件）
拥抱变化，可以适应需求的变化
scrum流程:1~4周10人以内
PO，product owner 产品经理，把客户的需求整理成user story，课表的代表方;
SM scrum master项目经理负责保证整个敏捷流程的顺利实施;
STscrum Team研发团队，目标是交付一个高质量可用的软件;
scrum流程
1，发布计划会议（PO负责讲解user story，根据user story的紧急程度排出本期要迭代的userstory，形成sprint backlog。）
2，迭代计划会议（细化user story ，分配任务，每个人需要完成什么任务以及完成的时间节点;）
3，开发过程中，每日站会（三件事，昨天做了什么，遇到什么困难，今天的计划;）
4，产品演示评审会（给用户演示完成的产品，用户会提出一定的意见，产品经理整理成新的user story 放到下一次的迭代当中;）
5，回顾会议（对本期迭代进行总结。）

软件测试v模型（瀑布模型的变种）

改进软件开发的效率和效果
优点:左边开发的每一个阶段和右边测试的每一个阶段一一对应，是右边测试每一个阶段的依据。
缺点:测试介入晚，前期的错误和风险到后期才发现，会失去及时就纠正的机会;不能适应需求变化的项目。

软件测试W模型

优点:测试阶段和开发阶段在两个独立的V模型里面，测试介入包比较早，在项目初期就介入，前期的风险可以及时被发现;
缺点:W模型每一个阶段仍然是一个串行的过程，不能适应需求变化的项目，所以无法应用到敏捷开发

基础

测试的生命周期

描述bug

bug的级别（简单的划分）

1.崩溃
系统运行阻断，严重的影响了开发人员和测试人员的工作，需要立马修复;如果出现一个线上bug的话，需要回退一个稳定的版本。
(2)严重
系统还可以运行，但是已经不稳定了，如果再运行下去，可能会产生严重的后果。比如视频画面失真。
(3）一般
系统可以稳定的运行，但是一些次要功能没有实现，可能会影响用户的体验。如查询功能有一个总是出现在分页中。
(4)次要（建议性)
没有严格体现在需求里面的;
影响用户的视觉体验，界面的文字提示内容，展示，图片的排版。要不要改和产品经理商量;

bug的生命周期

另外：测试人员提了一个BUG，开发人员已经修改了，但是测试人员测试的时候，发现这个BUG依然存在，有哪些原因?

1开发人员没修改好
2开发人员没有把代码更新到测试环境（没有提交代码)
3测试人员忘记拉取最新的代码到测试环境进行发布

测试时如何和开发人员沟通（遇到bug时）

(1）先检查自己的BUG描述是否清楚
(2）检查BUG的定级是否按照公司的标准来的
(3）站在用户的角度去说服开发
(4）不断提高自己的业务水平和技术水平
(5）和开发人员，产品经理开会商量BUG的解决方案

测试用例

好坏的判定

用例表达清楚，无二义性。。
用例可操作性强。
用例的输入与输出明确。一条用例只有一个预期结果。
用例的可维护性好。
用例对需求的覆盖率高，
暴露程序Bug的能力强力。

设计测试用例的方法

根据需求测试

先验证需求的合理性在进行设计

黑盒测试

等价类

等价类把输入（特殊情况下才考虑输出）划分成若干个等价类，从每一个等价类当中选一个测试用例进行测试，如果这个测试用例测试通过，那我们就说这个测试用例代表的等价类测试通过。
有效等价类:根据需求规格说明，有意义的输入的数据集合;
无效等价类:根据需求说明，不符合需求的

边界值

边界值:针对输入输出的边界进行测试用例的设计

因果图

用因果图法设计测试用例的步骤
(1）分析出所有的输入，输出
(2)找出输入输出之间的逻辑关系
(3)根据输入输出之间的关系画因果图
(4)根据因果图画判定表
(5）根据判定表设计测试用例

正交法

研究多因素多水平的一种实验〈(测试)方法。根据正交性，从输入组合当中选取最优的组合进行试验，分析结果，通过这些最优组合得出的试验结果来分析这个试验的结果。
因素:输入的变量
水平:变量的取值
正交表的构成:
列:因素数，变量的个数
水平数:每个变量的最大值的个数
行:L(正交表的行)=(水平数-1)*因素数+1
正交表的性质:
(1)每一列不同数据出现的次数一致
(2)任意两列不同数据的组合出现的次数一样
正交表设计测试用例的步骤:
1，确定所有的输入(变量)
2，确定每一个变量的取值的个数
3，确定因素数（正交表的列)，水平数 正交表的行
4，根据正交表的性质，把变量的值映射到表中
5，写测试用例，正交表的每一行就是一个测试用例6，补充正交表中没有的但是你认为可能出现的测试用例

场景法

根据场景法设计测试用例:把场景中的每一个功能点提出来，考虑功能点可能的不同的情况，根据这些情况去设计测试用例

错误猜测法

根据测试人员的知识，经验，直觉去判断哪一个模块会出现问题，专门针对这个模块进行测试用例的编写。作为一种补充的设计测试用例的方法，

例子

题意：




下一篇