测试

测试发现bug 开发不认为是bug的时候你怎么办？

1.1、首先明确开发说不是bug的理由。

1.2、如果是需求变更， 那就找产品经理确认是否是需求变更。

1.3、如果开发说测试环境问题， 让他说明清楚测试环境问题是什么，按照他说的验证一遍， 如果确实如他所说， 关闭bug，但是不是他说的那样，继续激活bug给开发解决，确保产品质量。

1.4、如果开发说用户不存在这种使用场景， 但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理去判定。

2.测试流程:

项目发布立项会的时候测试人员进行参与需求讨论并生成<需求文档》测试会在根据需求文档编写测试计划，然后uI会根据需求文档进行设计原型图，后台开发对数据库的设计,然后后台开发通过需求文档和原型图进行编码，同时测试人员进行编写测试用例,开发编码结束后测试对主要功能进行冒烟测试，如果冒烟测试执行通过，根据编写好的测试用例进行执行，发现bug后进行

提交bug;开发进行修改bug,开发修改后的bug进行回归测试上线后需要对项目的进行<测试总结>

3.测试分类：

[if !supportLists]4. [endif]黑盒，灰盒，白盒的区别：

黑盒测试(Black Box -Test)指的是把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果

有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。

“望”：观察软件的行为是否正常。

“闻”：检查输出的结果是否正确。

“问”：输入各种信息，结合“望”，“闻”来观察软件的响应。

“切”：像中医一样给软件“把把脉”，敲击一下软件的某些“关节”

白盒测试(White Box Testing),指的是把盒子盖打开，去研究里边源代码和程序结构。

灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法

测试的思维导图

一.发红包

功能：当发送的红包个数超过最大范围是不是有提示

当余额不足时，红包发送失败

在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，

是否可以输入它们的混合搭配

输入红包钱数是不是只能输入数字在红包钱数，和红包个数的输入框中只能输入数字

红包里最多和最少可以输入的钱数  200  0.01

拼手气红包最多可以发多少个红包  100

超过最大拼手气红包的个数是否有提醒

性能：

1.弱网时抢红包，发红包时间

2.不同网速时抢红包，发红包的时间

3.发红包和收红包成功后的跳转时间

4.收发红包的耗电量

5.退款到账的时间

兼容：

1.苹果，安卓是否都可以发送红包

2.电脑端可以抢微信红包

界面：

1.发红包界面没有错别字

2.抢完红包界面没有错别字

3.发红包和收红包界面排版合理，

4.发红包和收到红包界面颜色搭配合理

安全：

1.对方微信号异地登录，是否会有提醒 2人

2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加

3.发送红包失败，余额和银行卡里的钱数不会少

4.红包发送成功，是否会收到微信支付的通知

易用性：

1.红包描述，可以通过语音输入

2.可以指纹支付也可以密码支付

二.视频播放

功能：视频资源可以正常获取，不管是服务器返回还是后台添加等

视频的封面图、页面UI等正常

若一个视频中涉及到上一个视频、下一个视频时点击后都能正常切换到相应的视频，且视频正常播放

音量大小（如静音模式下播放时无声音）

视频最大化、最小化（如切换到最大化时视频全屏播放）

兼容性： 平台兼容性：如Android、IOS

    系统兼容性：Android4.4-８.0；IOS8.0-12；谨记哦（低版本的机型问题还是蛮多的，如IOS8系统播放器问题较多，测试要引起注意）

    播放器是否与其他类型播放器兼容（需要考虑播放过程中是否和音频等相冲突）

网络：网络切换测试：WiFi-移动网；移动网-WiFi；WiFi-无网；无网-WiFi；无网-移动网

弱网测试：弱网情况下，视频播放是否有卡顿、黑屏、闪退等情况

无网进入时是否有提示info；

移动网进行播放时是否有非WiFi弹框提示；

半屏/全屏切换：视频右下角全屏按钮，点击全屏横屏播放视频；

    点击收起按钮，全屏收起回到当前页半屏播放

    两者切换播放回到当前页面时，页面展示正常（IOSXX项目曾出现页面导航错乱的问题）

横竖屏切换： 旋转模式打开后，验证页面及视频播放是否正常；

    横屏模式下播放完视频，自动切换回竖屏模式；

视频中断： 播放中快进/后退进度，能正常播放本地资源，快进不卡顿，无延迟；

    播放中切换到后台，切换到后台后暂停播放，再次进入视频为暂停状态；

    视频播放时杀掉进程，则视频播放结束

视频易用性： 界面是否方便，整洁（如视频封面图，片头，片尾，视频图像等各个界面）

    快捷键是否正确

    菜单是否正确

    图像是否清楚（在标清、高清，超清等模式下切换时视频播放正常，无卡顿黑屏闪退等问题，在切换过程中是否有加载loading的提示）

    拖拽滚动条（拖、拽功能用起来是否友好）

    是否具备播放记忆功能（即播放进度是否有记录）

    能否自动保存以前的播放列表

三.水杯

功能:

能否装水，

除了装水， 能否装其他液体。比如可乐，酒精

能装多少ML的水

杯子是否有刻度表

杯子能否泡茶，跑咖啡

杯子是否能放冰箱，做冰块

杯子的材质是什么（玻璃，塑料,黄金做的）

界面:外观好不好看。

什么颜色

杯子的形状是怎么样的。

杯子的重量是多少

杯子的图案是否合理

性能:能否装100度的开水 (泡茶)

能否装0度冰水

装满水，放几天后，是否会漏水

杯子内壁上的涂料是否容易脱落。

杯子上的颜色是否容易褪色或者脱落

风吹是否会倒，摔一次是否会摔坏，摔多次是否会摔坏

性能:能否装100度的开水 (泡茶)

能否装0度冰水

装满水，放几天后，是否会漏水

杯子内壁上的涂料是否容易脱落。

杯子上的颜色是否容易褪色或者脱落

风吹是否会倒，摔一次是否会摔坏，摔多次是否会摔坏

安全性:制作杯子的材料，是否有毒

放微波炉里转的时候，是否会熔化。

从桌子上掉到水泥地上是否会摔碎。

杯子是否容易长细菌

杯子内壁上的材料，是否会溶解到水中

装进不同液体，是否会有化学反应。

易用性:杯子是否容易烫手

杯子是否好端，好拿

杯子的水是否容易喝到

杯子是否有防滑措施

是否能接受杯子的广告内容与图案

四：电梯

功能:上升、下降、停止、开门、关门、梯内电话、灯光、指示灯

性能速度、反应时间、关门时间

压力:超载、尖锐物碰撞电梯壁

安全:停电、报警装置、轿箱停靠位置、有人扒门时的情况

可用性:按键高度、操作是否方便、舒适程度

UI:美观程度、光滑程度、形状、质感

稳定性:长时间运行情况

兼容性:不同电压是否可工作、不同类型电话是否可安装

五。朋友圈点赞

功能：多次点赞，点赞时断电，断网，点赞时来电话，信息，点赞刚刚删除的朋友圈，点赞成功

性能：点赞图标显示速度

界面：界面简单，美观

易用性：操作简单，方便

兼容性：不同系统，不同微信版本，不同手机型号，不同电脑型号

安全：内容含有诈骗信息，点赞过程给设备带来病毒

功能测试和性能测试

功能测试

是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求。

功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试。

逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车

界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容...

易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适

安装测试:

兼容性测试:硬件兼容性测试和软件兼容性测试

硬件兼容性:比如一款软件在pc机，笔记本上是否兼容

软件兼容性测试:比如一款软件在windows8和windows10上是否兼容

性能测试

时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮，到登录成功(失败)的反应时间，浏览器非常常见，ANR（Application not responding 应用程序无响应）

空间性能:软件运行时所消耗的系统资源，比如对内存和cpu的消耗

一般性能测试:软件正常运行，不向其施加任何压力的测试

稳定性测试:也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定成都。

负载测试:让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）

压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）

回归测试、冒烟测试、随机测试

回归测试

是指对软件的新版本进行测试时，重复执行上一个版本测试时的用例，比如在1.0版本中，有一个bug，到了2.0版本中,再重新测试1.0中这个bug

冒烟测试

指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。

测试小组在正式测试一个新版本之前，先指派一两个测试人员测试一下软件的主要功能，如果没有实现，则打回开发组重新开发，这样做可以节省大量的时间成本和人力成本。

随机测试

是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

单元测试

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。

总的来说，单元就是人为规定的最小的被测功能模块。

单元测试当一段代码完成之后，是由白盒测试工程师或者开发人员自行测试，比如java中执行单元测试叫做junit测试。

目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序，没有相应的单元测试计划。

单元测试方式:先静态地观察代码是否符合规范，然后动态地运行一下代码,检查运行的结果。

例如：模块接口测试

]应对通过所测模块的数据流进行测试

调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配

所测模块调用子模块时，输入子模块的参数与子模块的形式参数在个数、属性和顺序上是否匹配。

输出给标准函数的参数的个数、属性和顺序是否正确。

全局变量的定义在各个模块中是否一致。

[if !supportLists]l [endif]当模块通过外部设备进行输入/输出操作，文件属性是否正确、open和close语句是否正确，规定的I/O格式说明与I/O语句是否匹配；缓冲区容量是否与记录长度匹配，在读写之前是否打开了文件，读写之后是否关闭了文件，对I/O错误是否做了处理。

驱动模块：相当于所测模块的主程序，它接收测试数据，把这些数据传送给所测模块，最后再输出实际结果

桩模块：用以代替所测模块调用的子模块。

集成测试

集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。

]在把各个模块连接起来的时候，穿越各个模块的接口的数据时候会丢失

一个模块的功能是否会对另一个模块的功能产生不利的影响

各个子功能组装完成后，能否达到预期的父功能

全局数据结构是否有问题

单个模块产生的误差累计起来是否会放大

系统测试和验收测试

集成测试完成之后，就是系统测试和验收测试。

系统测试:指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。

系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等。

验收测试：以用户为主的测试，软件开发人员和质量保证人员参加，

测试分类占比

]软件测试的原则

尽早原则

边界和极端原则

原则

确认原则

回归关联

1.应当把“尽早和不断地测试”作为开发者的座右铭。

2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

3.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

5.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

软件生命周期模型

软件生命周期同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）[1]。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

]边做边改模型

许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：

（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

（2） 忽略需求环节，给软件开发带来很大的风险；

（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

瀑布模型

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。

瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件，前面一个步骤不完成，后面的步骤不能开始，否则问题会滚到下个阶段，带来更多的问题

优点：

为项目提供了按阶段划分的检查点

当前一阶段完成后，只需要去关注后续阶段。

缺点：

1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

4）瀑布模型的突出缺点是不适应用户需求的变化。

原型化模型

原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。

如图所示：原型严格来说不算一种软件生命周期模型，它只是一种获取需求的方法，在实际工作中该方法是相当重要的方法。

模型要点：瀑布和原型模型相结合，强调版本升级。

该模式的特点是一次性地获取全部的需求，然后做出分版本实现各需求的计划，每个版本只实现一部分需求，通过多个版本逐步实现全部需求，而每个版本可以认为是一个“小瀑布”。

该模型的好处是可以尽快让系统上线，让客户先使用部分功能，尽早实现系统的价值。

该模型比较能符合实际的情况，我们往往也是通过多个版本来逐步实现全部需求，但需求是不可能在一开始就完全确定的，实际情况是往往只能确定80%，而后期通过各版本我们还会获取更多的新需求以及需求调整。将此模型稍微调整后，可以适用于大部分的实际项目。

增量模型

增量模型也是原型化开发方法。如图所示

]螺旋模型

螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。螺旋模型的整个开发过程如图所示。

图中的螺旋线代表随着时间推进的工作进展；开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段：制

定计划、风险分析、实施工程和客户评估。螺旋模型要点：统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析。

1.软件分多个版本开发，每个版本就是一次螺旋。

2.每个版本按照这样的顺序进行：

1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）

2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）

3）实施软件开发；（图中右下象限）

4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）

3.需求不是一次获取和实现的，通过多个螺旋来完善。

4.计划也不是一次成型的，每次螺旋都需要调整。

优点：

1）设计上很灵活，可以在项目的各个阶段进行变更；

2）以小的分段来构建大型系统，使成本计算变得简单容易；(国企项目)

3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；

4）随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互；

5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点：

螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。

因此，这种模型往往适应于内部的大规模软件开发。该模型建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

Ｖ模型

V模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

V模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

1、需求分析阶段对应生成需求规格说明书，对应测试生成系统测试方案，即为系统测试准备的，该阶段已经完成了单元测试和集成测试，主要是对软件产品的功能与非功能进行测试，几乎不测试代码，所以测试方法以黑盒为主；

2、概要设计阶段对应生成概要设计说明书，对应测试生成集成测试方案，该阶段已完成单元测试，是将各个功能模块组装起来进行的测试，所以也叫组装测试。主要看模块调用是否正常，接口是否可用，数据传输是否正确等，所以用到的测试方法几乎是白盒的方法，如路径覆盖，条件组合覆盖等；

3、详细设计阶段对应生成详细设计说明书，对应测试生成单元测试方案，该阶段是开发人员编码后的第一个测试阶段，是对开发出来的单独模块进行测试，以确保每一个功能模块的功能正常，可以构建桩模块和驱动模块来回调用，方法也是以白盒为主。

4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构，黑盒则是尽可能覆盖所有的输入输出接口，包括文档等一些静态的测试。除常用的测试方法外，仍需补充大范围的随机测试，尽可能达到覆盖率100%。

V模型的缺陷及解决思路

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。

Ｗ模型

相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

敏捷开发和测试

敏捷开发

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

由于版本节奏比较快，开发与测试几乎并行，一个版本周期内会有两版在推动，也就是上图中提到的波次发布，波次发布用于尝试新加入的功能，做小范围快速的开发，验证和发布，为下个大版本的功能做实验和调研。快速发版的需求要求测试快速响应，敏捷测试模式适应项目需求。

模型优势：

工作任务划分清晰，工作效率较高

与开发和产品沟通紧密，团队协作性强

测试介入到整个项目的所有会议中，对整体版本信息情况把控全面

迅速占有市场，添加新的功能，吸引更多用户使用，提升用户体验度

模型的缺陷：

模块提交较快，测试时较有压迫感

项目规划要合理，不然测试时会出现复测的现象，加大工作量

软件质量模型

软件的功能性

适用性：

所提供的功能是用户所需要的，

用户所需要的功能软件系统是否已提供。

准确性：

软件系统提供给用户的功能是否满足用户对该功能的精确度要求。

互操作性：

软件系统和一个或多个周边系统进行信息交互的能力。

例如

不同型号的打印机与word之间的协议可能不一致，导致消息传递过程中发生错误。

▲应该将被测软件系统和周边系统的各种主流型号进行互操作性测试。

保密安全性：

软件系统保护信息和数据的能力。

Ⅰ、防止未得到授权的人或系统访问相关的信息或数据

Ⅱ、保证得到授权的人或系统能正常访问相关的信息或数据。

不同的系统对于安全性的需求差别很大

常见的安全性测试：

⑴用户验证：登录密码验证、IP地址访问限制等 sql注入

用户超时:登录超过30分钟，重新登录(安全设置，cookie过期时间30分钟)

⑵用户权限管理:验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。

⑶系统数据的保护:对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份。

加密、解密：

在计算机通讯中，采用密码技术将信息隐蔽起来，再将隐蔽后的信息传输出去，使信息在传输过程中即使被窃取或截获，窃取者也不能了解信息的内容，从而保证信息传输的安全

token

Cookie与session的区别：

1. [endif]cookie是明文传输  session的是隐藏专属

2. [endif]Cookie是存在与本机 session是存在与服务器

3. [endif]Cookie的大小是限制在4K  session大小限制在5M

1.2. [endif]软件可靠性

1.1.6. [endif]成熟性

软件系统防止内部错误扩散而导致失效的能力。

    ▲子系统、模块、单元模块的设计人员应该仔细分析和自身有接口关系的子系统、模块、单元模块，识别出这些接口上可能会传递过来的错误，然后在自己子系统、模块、单元模块内部对这些可能的错误预先进行防范，规避这些错误传递到自身而引起自身的失效。

1.1.7. [endif]容错性

软件系统防止外部接口错误扩散而导致系统失效的能力。

▲设计人员应该充分分析外部接口可能产生的错误，然后在设计上对这些错误一一予以防范，防止这些外部传入的错误波及自身而失效。

1.1.8]易恢复性

系统失效后重新恢复原有功能、性能的能力

   ①原有能力恢复的程度

   ②原有能力恢复的速度

1.1.9. [endif]可靠性依从性

遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

1.3. [endif]软件易用性

1.1.10. [endif]易理解性

用户在使用软件系统的过程中，系统交互给用户的信息是否准确、清晰、易懂，能帮助用户准确理解系统当前真实的状态，指导其进一步的操作。

1.1.11. [endif]易学性

软件系统提供相关的辅助手段，帮助用户学习使用它

的能力。

例如：是否有用户手册，用户手册是否有中文版，是否有在

线帮助，界面上控件是否有回显功能等。

1.1.12. [endif]易操作性

例如：

①Nokia手机和Moto手机在编辑短消息时的方便性差异。

②GUI界面，菜单层次不要太深

③安装软件的过程

错误：给用户大量的安装步骤，每步又有大量分支选项

（把用户当成本软件的专家）

   ▲测试时应该以非专业的角度来测试过程，往往需要α、

β测试。

1.1.13. [endif]吸引性

美观：GUI界面、手机外观等

新颖：如夏新手机来电跳舞功能

5、易用性的依从性

遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

问：性能测试的标准：

吞吐量

响应时间

资源使用率内存使用率cpu的使用率    电量的损耗  流量使用

成功率

1.4. [endif]软件效率（性能测试）

1.1.14. [endif]时间效率(2-5-10)  358

系统在各业务场景下完成用户指定的业务请求所需的响应时间。

1.1.15. [endif]资源效率

系统在各业务场景下完成用户指定的业务请求所消耗的系统资源，如CPU占有率 75%内存占有率80%、通信带宽占有率、软件内部消息包资源占有率等。

1.1.16. [endif]效率依从性

遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

1.5. [endif]软件可维护性

1.1.17. [endif]易分析性

软件系统提供辅助手段帮助开发人员分析识别缺陷、失效产生的原因，找出待修复部分的能力。（降低缺陷定位的成本）

1.1.18. [endif]易改变性

对软件缺陷的修复容易被实施（降低修复缺陷成本）

   ▲设计上封装性好、高内聚（同层次设计时，一个实体只完成一个功能）、低耦合，为未来可能的变化留有扩充余地。

1.1.19. [endif]稳定性

例如：代码中的有物理含义的数字，一定用宏代替。

1.1.20. [endif]易测试性

（降低发现缺陷的成本）

①软件可控制：

软件系统提供辅助手段帮助测试工程师控制该系统的运行，实现其测试执行步骤的能力（通过打点、改变内部状态、值等手段）

②可观察：

软件系统提供辅助手段帮助测试工程师获得充分的系统运行信息，以正确判断系统运行状态和测试执行结果的力。

a、设计单独的测试模式

b、提供单独的测试版本

    ▲测试部（一般指测试系统工程师）应该在需求分析阶段就提出可测试性需求，可测试性需求和软件产品其他需求一起纳入需求包被分析设计并实现。

5、维护性的依从性

遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

1.6. [endif]软件可移植性

1.1.21. [endif]适应性

软件系统无需做任何相应变动就能适应不同运行环境（操作系统平台、数据库平台、硬件平台等）的能力。

    ▲解决平台无关、可移植性问题的一个常用思路是构造出一个虚拟层，虚拟层将下层细节屏蔽，对上层提供统一口。

1.1.22. [endif]易安装性

主流平台全部测试用例

非主流平台10%测试用例

1.1.23. [endif]共存性

软件系统和在公共环境与其共享资源的其他系统共存的能力。

    ▲测试不仅需要关注自身特性的实现，还要关注本软件是否影响了其他软件的正常功能。

1.7. [endif]易替换性

软件系统升级能力（在线升级、打补丁升级等）

可移植性的依从性

遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

参加评审会的对用例4、评审内容

评审的内容有以下几个方面

1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

2)优先极安排是否合理。

3)是否覆盖测试需求上的所有功能点。

4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。

5)是否已经删除了冗余的用例。

6)是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。

7)是否从用户层面来设计用户使用场景和使用流程的测试用例。

8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

测试策略： 等价类划分 场景法 因果图 判定法 正交法 错误推断法

面试题：任意的测试用例都含有 用例编号 （项目名字—模块名字_用例编号）

所属模块

执行条件

测试输入（具体的执行步骤  ）

预期结果

实际结果

用例是否通过

测试人（执行测试用例的人）

版本

备注

[if !supportLists]1.1. [endif]测试用例示例

笔试题：你用到的测试方法/测试策略有哪些？

等价类划分边界值因果图场景法正交表

划分等价类并编号,下表为等价类划分的结果

边界值法

　一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错。

  比如下面代码

　　for(int i = 0;i <100; i ++)有效等价划分    -1   0    100  101  

{

　　int j = i+1;

　　System.out.println("循环第“+j+"次")//循环地做某件事情

}

　　这里的程序是循环了100次，所以会做100次;

　　如果程序员不小心，把i <100写成i <= 100，则会溢出，这时候边界值检查是一个很好的测试方法。

比如：在一个系统中，填写一个多少岁的成年人数学考了多少分（假设成年人年龄为x,0

根据上面的等价类划分法我们可知，年龄的有效等价类是0

数学成绩的,有效等价类是0<=y<=100，所以边界值就是-1，0，100，101

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。即使最简单的程序要处理的数据量也可能极大，使这些数据得以测试的技巧是，根据一些关键的原则进行等价类的划分，以合理减少测试用例，这些关键的原则是：边界条件，次边界条件、空值和无效数据。

确定边界值的方法（）

 确定边界情况（输入或输出等价类的边界）

 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

输入要求是1～ 100之间的整数，因此自然产生了1和100两个边界，我们在设计测试用例的时，要重点考虑这两个边界问题。

注明:边界值不是从每个等价类中挑一个作为代表，而是把每个等价类的边界都进行测试。

因果图法

概念:

因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

]因果图基本图形符号

恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。

非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。

或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。

与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

因果图的约束符号

E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立

I（包含）：表示三个原因中至少有一个必须成立

O（惟一）：表示两个原因中必须有一个，且仅有一个成立

R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现

M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定

因果图测试用例

例如：有一个处理单价为2.5元的盒装饮料的自动售货机软件。若投入2.5元硬币，按“可乐”、“啤酒”、或“奶茶”按钮，相应的饮料就送出来。若投入的是3元硬币，在送出饮料的同时退还5角硬币。

分析这一段说明，我们可列出原因和结果

原因(输入)：

投入2.5元硬币；

投入3元；

按“可乐”按钮；

按“啤酒”按钮；

按“奶茶”按钮。

中间状态：① 已投币；②已按钮

结果(输出)：

退还5角硬币；

送出“可乐”饮料；

送出“啤酒”饮料；

送出“奶茶”饮料；

判定表法

场景法

测试用例设计的思想

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

用例场景是通过描述流经用例的路径来确定的过程，

这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

场景1基本流

场景2基本流 备选流 1

场景3基本流 备选流 1 备选流 2

场景4基本流 备选流 3

场景5基本流 备选流 3 备选流 1

场景6基本流 备选流 3 备选流 1 备选流 2

场景7基本流 备选流 4

场景8基本流 备选流 3 备选流 4

注：为方便起见，场景5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

[if !supportLists]1.1.7. [endif]银行案例ATM:

个人标识号(PIN＝personal identification number )，用于保护智能卡免受误用的秘密标识代码。PIN 与密码类似，只有卡的所有者才知道该 PIN。只有拥有该智能卡并知道 PIN 的人才能使用该智能卡

第一次测试中，根据测试计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：

基本流-提取预设金额（100 元、200元、500元、1000元）

备选流2 - ATM内没有现金

备选流3 - ATM内现金不足

备选流4 - PIN有误

备选流5 -帐户不存在/帐户类型有误

备选流6 -帐面金额不足   

对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。

从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。

下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。

本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

软件缺陷和软件缺陷种类

7.1.软件缺陷的定义

软件缺陷，常常又被叫做Bug，从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病

等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

格蕾丝·赫柏（GraceMurrayHopper），是一位为美国海军工作的电脑专家，也是最早将人类语言

融入到电脑程序的人之一。而代表电脑程序出错的“bug”这名字，正是由赫柏所取的。1947年9月9

日，赫柏对HarvardMarkII设置好17000个继电器进行编程后，技术人员正在进行整机运行时，它突然

停止了工作。于是他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这

显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。所以在报告中，赫柏用胶条贴上飞

蛾，并把“bug”来表示“一个在电脑程序里的错误”，“Bug”这个说法一直沿用到今天。

7.2.软件缺陷的种类划分

按照软件缺陷的产生原因，可以将其划分为不同的缺陷类别：

1、功能不正常

简单地说就是所应提供的功能，在使用上并不符合产品设计规格说明书中规定的要求，或是根本无法

使用。这个错误常常会发生在测试过程的初期和中期，有许多在设计规格说明书中规定的功能无法运行，

或是运行结果达不到预期设计。最明显的例子就是在用户接口上所提供的选项及动作，使用者操作后毫无

反应。

2、软件在使用上感觉不方便

只要是不知如何使用或难以使用的软件，在产品设计上一定是出了问题。所谓好用的软件，就是使用

上尽量方便，使用户易于操作。如微软推出的软件，在用户接口及使用操作上确实是下了一番功夫。有许

多软件公司推出的软件产品，在彼此的接口上完全不同，这样其实只会增加使用者的学习难度，另一方面

也凸显了这些软件公司的集成能力不足。

3、软件的结构未做良好规划

这里主要指软件是以自顶向下方式开发，还是以自底向上方式开发。如果是以自顶向下的结构或方法

开发的软件，在功能的规划及组织上比较完整，相反以自底向上的组合式方法开发处的软件则功能较为分

散，容易出现缺陷。

4、提供的功能不充分

这个问题与功能不正常不同，这里指的是软件提供的功能在运作上正常，但对于使用者而言却不完整。

即使软件的功能运作结果符合设计规格的要求，系统测试人员在测试结果的判断上，也必须从使用者的角

度进行思考，这就是所谓的“从用户体验出发”。

5、与软件操作者的互动不良

一个好的软件必须与操作者之间可以实现正常互动。在操作者使用软件的过程中，软件必须很好地响

应。例如在浏览网页时，如果操作者在某一网页填写信息，但是输入的信息不足或有误。当点击“确定”

按钮后，网页此时提示操作者输入信息有误，却并未指出错误的哪里，操作者只好回到上一页重新填写，

或直接放弃离开。这个问题就是典型的在软件对操作互动方面未做完整的设计。

6、使用性能不佳

被测软件功能正常，但使用性能不佳，这也是一个问题。此类缺陷通常是由于开发人员采用了错误的

解决方案，或使用了不恰当的算法导致的，在实际测试中有很多缺陷都是因为采用了错误的解决方法，需

要加以注意！

7、为做好错误处理

软件除了避免出错之外，还要做好错误处理，许多软件之所以会产生错误，就是因为程序本身对于错

误和异常处理的缺失。例如被测软件读取外部的信息文件并已做了一些分类整理，但刚好所读取的外部信

息文件内容已被损毁。当程序读取这个损毁的信息文件时，程序发现问题，此时操作系统不知该如何处理

这个情况，为保护系统自身只好中断程序。由此可见设立错误和异常处理机制的重要性！

8、边界错误

缓冲区溢出问题在这几年已成为网络攻击的常用方式，而这个缺陷就属于边界错误的一种。简单来说，

程序本身无法处理超越边界所导致的错误。而这个问题，除了编程语言所提供的函数有问题之外，很多情

况下是由于开发人员在声明变量或使用边界范围时不小心引起的。

9、计算错误

只要是计算机程序，就必定包括数学计算。软件之所以会出现计算错误，大部分出错的原因是由

于采用了错误的数学运算工时或未将累加器初始化为0.

10、使用一段时间所产生的错误

这类问题是程序开始运行正常，但运行一段时间后却出现了故障。最典型的例子就是数据库的查

找功能。某些软件在刚开始使用时，所提供的信息查找功能运作良好，但在使用一段时间后发现，进行信

息查找所需的时间越来越长。经分析查明，程序采用的信息查找方式是顺序查找，随着数据库信息的增加，

查找时间自然会变长。这就需要改变解决方案了！

11、控制流程的错误

控制流程的好坏，在于开发人员对软件开发的态度及程序设计是否严谨。软件在状态间的转变是

否合理，要依据业务流程进行控制。例如，用软件安装程序解释这类问题最方便直观。用户在进行软件安

装时，输入用户名和一些信息后，软件就直接进行了安装，未提示用户变更安装路径、目的地等。这就是

软件控制流程不完整导致的错误问题。

12、在大数据量压力下所产生的错误

程序在处于大数据量状态下运行出现问题，就属于这类软件错误。大数据量压力测试对于Server

级的软件是必须进行的一项测试，因为服务器级的软件对稳定性的要求远比其它软件要高。通常连续的大

数据量压力测试是必须实施的，如让程序处理超过10万笔数据信息，再来观察程序运行的结果。

13、在不同硬件环境下产生的错误

这类问题的产生与硬件环境的不同相关。如果软件与硬件设备有直接关系，这样的问题就是数量

相当多。例如有些软件在特殊品牌的服务器上运行就会出错，这是由于不同的Server内部硬件了不同的处

理机制。

14、版本控制不良导致的错误

出现这样的问题属于项目管理的疏忽，当然测试人员未能尽忠职守也是原因之一。例如一个软件

被反映有安全上的漏洞，后来软件公司也很快将修复版本提供给用户。但在一年后他们推出新版本时，却

忘记将这个已解决的bug-fix加入到新版本中。所以对用户来说，原本的问题已经解决了，但想不到新版本

升级之后，问题又出现了。这就是由于版本控制问题，导致不同基线的merge出现误差，使得产品质量也

出现了偏差。

15、软件文档的错误

最后这类缺陷是软件文档错误。这里所提及的错误，除了软件所附带的使用手册、说明文档及其

它相关的软件文档内容错误之外，还包括软件使用接口上的错误文字和错误用语、产品需求设计PD、UISpec

等的错误。错误的软件文档内容除了降低产品质量外，最主要的问题是会误导用户！

7.3.软件缺陷的属性

1.1.14.按照严重程度分:

一般分为5个等级:

系统崩溃，严重，一般，次要，建议

1.1.15.按优先级分:

修正优先级：高，中，低

1.1.16.Bug定级示例

1级，系统崩溃

定义：严重阻碍测试和开发工作

对应优先级：最高

具体可分为：

1.功能完全没有实现

2.应用闪退/崩溃无法运行

3.应用必现安全模式，无法运行

4.其他导致功能无法测试的问题

2级，至关重要

定义：非阻碍用例执行的严重问题

对应优先级：高

具体可分为：

1.简单操作应用闪退/崩溃，卡死

2.数据丢失

3.严重影响系统，自身功能无法运行

4.严重数值计算错误

5.数据库损坏或无法保存配置

6.安全性问题（包括数据加密等）

3级，主要

定义：功能存在缺陷，但不影响应用和系统的稳定性

对应优先级：中

具体可分为：

1.内存泄露（长时间不用的对象需要被回收，不被回收占内存）

2.功能实现逻辑覆盖不全面

3.非必现，但复现概率超过50%的闪退/崩溃和安全模式

4级，一般

定义：对应用熟悉度高才能感知到的问题，对应用基本功能实现无影响

对应优先级：中

具体可分为：

1.轻微数值计算错误

2.功能实现有误，与产品文档不完全贴切

3.用户简单操作，即可明显感知的UI问题

5级，较小

定义：界面，性能缺陷

对应优先级：低

具体可分为：

1.操作界面错误（提示显示规则，刷新规则是否与文档一致）

2.边界条件显示错误

3.提示信息和界面效果展示错误（包括未给出信息、信息提示错误等）

4.复现率低于5%的闪退/崩溃和安全模式

5.插件兼容和性能未优化问题

6.非正常操作导致UI显示异常

6级，建议

定义：对于产品的意见或者建议

对应优先级：低

具体可分为：

1.对于产品设计方面的意见和建议

2.对于产品界面优化方面的意见和建议

3.对于产品需要优化增强用户体验方面的意见和建议

1.1.17.按照测试种类分:

逻辑功能类，性能类，界面类，易用性类，安装，兼容性类

按照功能模块分:

注册，登录，购物车，分类，订单，个人信息

1.1.19.软件缺陷类型

缺陷类型内容说明备注

系统缺陷1、程序死循环不能执行正常工作或重要功

2程序错误，不能执行正常能，使系统崩溃或资源不足

工作或重要功能，使系统崩溃

或资源不足

数据缺陷1数据计算错误严重的影响系统要求或基本

2数据约束错误功能的实现

3数据输入、输出错误

数据库缺陷1数据库发生死锁

2数据库的表、缺省值未加

约束条件

3数据库连接错误

4数据库的表有过多的空字

段

接口缺陷1数据通信错误

2程序接口错误

功能缺陷1功能无法实现

2功能实现错误

安全性缺陷1用户权限无法实现

2超出限制错误

3访问控制错误

4加密错误

兼容性缺陷与需求规定配置兼容性不配

合

性能缺陷1未达到预期的性能目标

2性能测试中出错，导致无

法进行测试

界面缺陷1操作界面错误

2打印内容，格式错误

3删除操作未给出提示

4长时间操作未给出提示

5界面不规范

建议1功能建议建议性的改进

2操作建议

1.1.20.按照解决方案分

按照Bug生命周期

新建，确认，解决，重新验证，关闭，重新打开

缺陷报告(Bug报告，提的Bug)

Bug的处理

性能测试是什么

基于协议模拟用户发出请求，对服务器形成一定负载，来测试服务器的性能指标是否满足要求

性能指标关注点：时间性能、空间性能

性能测试与页面无关

性能测试定义：指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

性能测试类型

[if !supportLists]1. [endif]基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考

[if !supportLists]2. [endif]负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。

[if !supportLists]3. [endif]压力测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。

[if !supportLists]4. [endif]稳定性测试（可靠性测试）：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。24X3小时

[if !supportLists]5. [endif]并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，

性能测试工具

Jmeter简介

[if !supportLists]1.1. [endif]Jmeter的基本概念

Apache JMeter是Apache组织开发的基于Java的压力测试工具。

[if !supportLists]1.2. [endif]我们为什么使用Jmeter

开源，免费，基于Java编写，可集成到其他系统可拓展各个功能插件

支持接口测试，压力（负载和压力）测试等多种功能，支持录制回放，

入门简单相较于自己编写框架活其他开源工具，有较为完善的UI界面，便于接口调试

多平台支持，可在Linux，Windows，Mac上运行

支持多协议

[if !supportLists]1.3. [endif]Jmeter的作用

[if !supportLists]1. [endif]接口测试

[if !supportLists]2. [endif]性能测试

[if !supportLists]3. [endif]压力测试

[if !supportLists]4. [endif]Web自动化测试

[if !supportLists]5. [endif]数据库测试

[if !supportLists]6. [endif]JAVA程序测试

[if !supportLists]1.4. [endif]Jmeter怎么用

Windows下Jmeter下载安装

登录http://jmeter.apache.org/download_jmeter.cgi，根据自己平台，下载对应文件

[if !supportLists]1.1. [endif]安装JAVA环境

安装JDK，配置环境变量（具体步骤不做介绍）

将下载Jmeter文件解压，打开/bin/jmeter.bat

[if !supportLists]1.2. [endif]Jmeter的目录结构

/bin目录（常用文件介绍）

examples：目录下包含Jmeter使用实例

ApacheJMeter.jar：JMeter源码包

jmeter.bat：windows下启动文件

jmeter.sh：Linux下启动文件

jmeter.log：Jmeter运行日志文件

jmeter.properties：Jmeter配置文件

jmeter-server.bat：windows下启动负载生成器服务文件

jmeter-server：Linux下启动负载生成器文件

/docs目录——Jmeter帮助文档

/extras目录——提供了对Ant的支持文件，可也用于持续集成

/lib目录——存放Jmeter依赖的jar包，同时安装插件也放于此目录

/licenses目录——软件许可文件，不用管

/printable_docs目录——Jmeter用户手册

[if !supportLists]2. [endif]使用Jmeter测试快速入门

[if !supportLists]2.1. [endif]线程组是什么

进程： 一个正在执行的程序对应一个进程

线程： 一个进程有多个执行线程

线程组： 按照线程性质对线程分组

三者关系： 一个进程有多个线程组，一个线程组有多个线程

测试计划—线程组—线程组属性中的线程数

并发执行：多个线程同时执行，特点：执行结束的顺序与开始的顺序不一致

顺序执行：按照线程的启动顺序挨个执行

默认情况下，线程组中的线程是并发执行

每一个线程都要执行组内的http请求

设置线程组顺序执行：勾选测试计划中的（独立运行每个线程组）

线程组用来模拟用户的并发访问

[if !supportLists]1.1.1. [endif]创建线程组

[if !supportLists]1.1.2. [endif]线程组主要包含三个参数：线程数、准备时长(Ramp-Up Period(in seconds))、循环次数。

[if !supportLists]1.1.3. [endif]  线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。

[if !supportLists]1.1.4. [endif]  准备时长（秒）：设置的虚拟用户数需要多长时间全部启动。如果线程数为20 ，准备时长为10 ，那么需要10秒钟启动20个线程。也就是每秒钟启动2个线程。

[if !supportLists]1.1.5. [endif]循环次数：每个线程发送请求的次数。如果线程数为20 ，循环次数为100 ，那么每个线程发送100次请求。总请求数为20*100=2000 。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。

[if !supportLists]1.1.6. [endif]. 调度器：设置线程组启动的开始时间和结束时间(配置调度器时，需要勾选循环次数为永远)

[if !supportLists]1.1.7. [endif]持续时间（秒）：测试持续时间，会覆盖结束时间

[if !supportLists]1.1.8. [endif]启动延迟（秒）：测试延迟启动时间，会覆盖启动时间

[if !supportLists]1.1.9. [endif]启动时间：测试启动时间，启动延迟会覆盖它。当启动时间已过，手动只需测试时当前时间也会覆盖它。

[if !supportLists]1.1.10. [endif]结束时间：测试结束时间，持续时间会覆盖它。

[if !supportLists]2.2. [endif]创建http请求

[if !supportLists]2.3. [endif]指定请求域名，请求路径

一个HTTP请求有着许多的配置参数，下面将详细介绍：

名称：本属性用于标识一个取样器，建议使用一个有意义的名称。

注释：对于测试没有任何作用，仅用户记录用户可读的注释信息。

服务器名称或IP ：HTTP请求发送的目标服务器名称或IP地址。

端口号：目标服务器的端口号。

方法：发送HTTP请求的方法，可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。

Content encoding ：内容的编码方式，默认值为iso8859

路径：目标URL路径(不包括服务器地址和端口)

[if !supportLists]2.4. [endif]设置对应的查看内容

[if !supportLists]2.5. [endif]查看表格信息

Sample：每个请求的序号

Start Time：每个请求开始时间

Thread Name：每个线程的名称

Label：Http请求名称

Sample Time：每个请求所花时间，单位毫秒

Status：请求状态，如果为勾则表示成功，如果为叉表示失败。

Bytes：请求的字节数

样本数目：也就是上面所说的请求个数，成功的情况下等于你设定的并发数目乘以循环次数

平均：每个线程请求的平均时间

最新样本：表示服务器响应最后一个请求的时间

偏离：服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。

[if !supportLists]2.6. [endif]查看结果树

通过察看结果树，我们可以看到每个请求的结果，其中红色的是出错的请求，绿色的为通过。

Thread Name：线程组名称

Sample Start:启动开始时间

Load time：加载时长

Latency：等待时长

Size in bytes：发送的数据总大小

Headers size in bytes：发送数据的其余部分大小

Sample Count：发送统计

Error Count：交互错误统计

Response code：返回码

Response message：返回信息

Response headers：返回的头部信息

[if !supportLists]2.7. [endif]聚合报告参数说明

lable：对应每一个http请求，显示的是http请求的Name，如百度http请求name为baidu

#Samples：表示这一次的测试中一共发出了多少请求，如上图所示，sougou和baidu的http请求每个都发出30个请求

Average：平均响应时间，指的是所有的请求的平均响应时间，如上图的30个请求的总的响应时间除以30得出的平均响应时间，默认的情况下是单个请求的平均响应时间，但当使用了“事务控制器”时，则以事物为单位显示平均响应时间

Median：中位数，也就是50%用户的响应时间

90%Line：90%用户的响应时间

Min：最小响应时间

Max：最大的响应时间

Error%：本次测试中出现错误的请求的数量/请求的总数，如上图所示，本次的测试中，sougou的http请求66.6%的请求出错，而baidu的请求则没有出错的请求

Throughput：吞吐量，默认情况下表示每秒完成的请求数，如上图所示，每秒完成的请求数分别为6.6个每秒，6.2个每秒

Recived KB/Sec：每秒从服务器端接收到的数据量，以kb为计算的单位

[if !supportLists]2.8. [endif]图形结果

样本数目：总共发送到服务器的请求数。

最新样本：代表时间的数字，是服务器响应最后一个请求的时间。

吞吐量：服务器每分钟处理的请求数。

平均值：总运行时间除以发送到服务器的请求数。

中间值：有一半的服务器响应时间低于改值而另一半高于该值。

偏离：表示服务器响应时间变化、离散程度测量值的大小。

[if !supportLists]3. [endif]Jmeter主要组件介绍

1．测试计划是使用 JMeter 进行测试的起点，它是其它 JMeter 测试元件的容器。

2．线程组：代表一定数量的并发用户，它可以用来模拟并发用户发送请求。实际的请求内容在Sampler中定义，它被线程组包含。可以在“测试计划->添加->线程组”来建立它，然后在线程组面板里有几个输入栏：线程数、Ramp-Up Period(in seconds)、循环次数，其中Ramp-Up Period(in seconds)表示在这时间内创建完所有的线程。如有8个线程，Ramp-Up = 200秒，那么线程的启动时间间隔为200/8=25秒，这样的好处是：一开始不会对服务器有太大的负载。线程组是为模拟并发负载而设计。

3、取样器（Sampler）：模拟各种请求。所有实际的测试任务都由取样器承担，存在很多种请求。如：HTTP 、ftp请求等等。

4、监听器：负责收集测试结果，同时也被告知了结果显示的方式。功能是对取样器的请求结果显示、统计一些数据（吞吐量、KB/S……）等。

6、断言：用于来判断请求响应的结果是否如用户所期望，是否正确。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。

7、定时器：负责定义请求（线程）之间的延迟间隔，模拟对服务器的连续请求。

5、逻辑控制器：允许自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。

8. 配置元件维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。

9. 前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。

Jmeter

Jmeter的安装：

[if !supportLists]1. [endif]安装jdk以及配置相对应的环境变量（jmeter3.*一下JDK8一下版本）Jmeter5.3需要jdk为8以上

[if !supportLists]2. [endif]配置jmeter的环境变量

验证：

Cmd中输入 java javac

         Jmeter -version

使用jmeter的方式  windos下使用jmeter.bat

  Linux下使用jmeter.sh  

jmeter的工具： 性能测试

负载和压力的区别：

负载测试：在一定的工作负荷下，给系统造成du的负zhi荷及系统响应的时间。

压力测试：在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响

TPS和QPS的区别：

tps可以理解为是每秒对事务的处理的能力  qps是每秒对服务器的查询能力

性能测试web端和app端测试

 

web端的性能指标：

https://www.cnblogs.com/flyr/p/5509451.html

响应时间（客户端向服务端的请求时间，服务端对数据库的请求时间，服务端将结果展现到页面的时间）

响应时间2 5 8原则   

吞吐量：指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.

TPS：每秒处理事务能力

并发数： 单用户的多次操作

多用户的单次操作

点击率:每秒钟用户向WEB服务器提 交的HTTP请求数.

资源使用率：cpu  <80%内存  <80%  io <40    网络 <30%

app端的性能指标

Jmeter

Jmeter的安装：

[if !supportLists]1. [endif]安装jdk以及配置相对应的环境变量（jmeter3.*一下JDK8一下版本）Jmeter5.3需要jdk为8以上

配置jmeter的环境变量

验证：

Cmd中输入 java javac

         Jmeter -version

使用jmeter的方式  windos下使用jmeter.bat

  Linux下使用jmeter.sh  

jmeter的工具： 性能测试

负载和压力的区别：

负载测试：在一定的工作负荷下，给系统造成du的负zhi荷及系统响应的时间。

压力测试：在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响

TPS和QPS的区别：

tps可以理解为是每秒对事务的处理的能力  qps是每秒对服务器的查询能力

性能测试web端和app端测试

 

web端的性能指标：

https://www.cnblogs.com/flyr/p/5509451.html

响应时间（客户端向服务端的请求时间，服务端对数据库的请求时间，服务端将结果展现到页面的时间）

响应时间2 5 8原则   

吞吐量：指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.

TPS：每秒处理事务能力

并发数： 单用户的多次操作

多用户的单次操作

点击率:每秒钟用户向WEB服务器提 交的HTTP请求数.

资源使用率：cpu  <80%内存  <80%  io <40    网络 <30%

app端的性能指标

App端的性能指标：

Cpu内存  流量  电量 启动时间  帧率

cpu  <80%内存  <80%

电量的损耗：

流量的损耗：

 

线程和进程区别：

接口测试：postman jmeter

接口文档中：

1.url地址   http://apis.juhe.cn/lottery/query?key=111&lottery_id=ssq

http / https

域名：apis.juhe.cn

路径：/lottery/query

请求方式：get/post

 TPC/IP OSI

次握手四次挥手：

200 -请求成功，已经正常处理完毕

301 -请求永久重定向，转移到其它URL

302 -请求临时重定向

304 -请求被重定向到客户端本地缓存

400 -客户端请求存在语法错误

401 -客户端请求没有经过授权

403 -客户端的请求被服务器拒绝，一般为客户端没有访问权限

404 -客户端请求的URL在服务端不存在

500 -服务端永久错误

Jmeter的接口测试：

1测试计划中添加线程租

2在线程租中添加http请求 在http请求中需要填入

3在线程中添加查看结果树

Jmeter的压力测试

1测试计划中添加线程租

2在线程租中添加http请求 在http请求中需要填入

D:可以使用函数助手的方式来随机生成${}参数变量

https://blog.csdn.net/qq_34659777/article/details/86005723

Jmeter的对数据库链接（对数据库进行压力测试）

测试数据的来源：

A.复用开发的原有数据 b.复用线上的真实数据c.直接使用线上数据 d.测试人员手动添加

E：产品或者是运营提供数据

在线程中添加配置原件jdbconection config

事务的特性：ACID

原子性

隔离性

一致性

持久性

Commit提交事务

Rollback事务回滚

Linux是多用户的操作系统  

Bin二进制文件

Boot核心文件或者是镜像文件

Dev外部设备

Etc    录用来存放所有的系统管理所需要的配置文件和子目录

Home  的主目录，在Linux 中，每个用户都有一个自己的目录，一般该目录名是以用户的账号命名的

Root

Tmp临时文件

Usr用户文件

Var  这个目录中存放着在不断扩充着的东西，我们习惯将那些经常被修改的目录放在这个目录下。包括各种日志文件。

ls / 显示子文件

Cd  切换目录

Pwd 显示路径

Mkdir  创建文件夹

Touch  创建文件

Rmdir   删除文件

Cp   赋值

Mv     移除/重命名

Vi     编辑

：wq    保存并退出

Tar     打tar.gz包

Rm      移除

Cat  查看

netstat -an查看端口号

ps–ef查看进程

Kill   杀死进程命令

Clear  清屏

常用文件命令如下：

https://www.runoob.com/linux/linux-file-content-manage.html

运用题：

测试环境分为2种：

Windows环境下

Linux环境下  Linux+jdk+tomcat+mysql+jenkins（持续打包）+禅道  

打包方式：web  war包

     移动端全量包灰度包bug包

Jenkins回持/定时续从git/svn上拉取代码并实现打包进行测试并生成测试报告

在linux下进行搭建 jdk

[if !supportLists]1. [endif]yum -y list java*查找所有的jdk的安装包

[if !supportLists]2. [endif]yum install -y java-1.8.0-openjdk-devel.x86_64

验证是否下载成功的java -version

[if !supportLists]3. [endif]Vi   profile编辑profile文件  并保存退出 ：wq

[if !supportLists]4. [endif]Source /etc/profile刷新配置文件

[if !supportLists]5. [endif]验证java javac如果有提醒命令出现 说明配置成功

输入java没有提醒 说明 java—home 路径有问题

输入javac没有提醒 说明 path 路径有问题

在linux下进行搭建 mysql

1.详细操作如下：

https://blog.csdn.net/lizy928/article/details/82531749

在linux下进行搭建 tomcat

[if !supportLists]1. [endif]检查看设备：

adb  devices

[if !supportLists]2. [endif]安装软件：

adb  install-r(APK路径)

-r代表如果apk已安装，重新安装apk并保留数据和缓存文件。

[if !supportLists]3. [endif]卸载软件Adb   uninstall-k<软件名>

如果加-k参数,为卸载软件但是保留配置和缓存文件

4.登录设备shell

Adb  shell

Adb  shell

这个命令将登录设备的shell.

后面加

5.查看手机内存情况

Adb  shell  dumpsys  cpuinfo

6.查看内存情况

Adb shell  getprop|findstr  dalvik本机内存的使用情况

7.查看应用内存使用情况

Adb shell  dumpsys  meminfo+包名：应用的内存使用情况

8.列出手机装的所有app的包名：

Adb  shell   pmlist  packages

9.列出系统应用的所有包名：

Adb  shell  pm list     packages -s

10.列出除了系统应用的第三方应用包名：

adb  shell   pmlist   packages -3

V——Verbose（最低，输出得最多）

D——Debug

I——Info

W——Warning

E——Error

F——Fatal

S——Silent（最高，啥也不输出）

按某级别过滤日志则会将该级别及以上的日志输出。

命令：adblogcat*:W

11.monkey盲k-pcom.tencent.mtaexample-s23--throttle2000--ignore-crashes--ignore-timeouts-v

-v-v100000>/data/local/tmp/log.txt2>&1&

1.-p后面接着的对应的包名，如果是整机测试，就不需要-ppackage_name

2.-s后面是对应的种子数，好像就是操作步骤，根据她们测试的经验，一般种子数

在23，同步她们测试的结果，一般种子的个数固定为23，和她们选择的操作步骤就是同步

的。

3.--ignore-crashes--ignore-timeouts这里是在monkey测试的过程中遇到carash或

者timeout的情况时忽略掉，一般不设置时，出现carash或者timeout时，Monkey测试会

终止。这里是防止Monkey测试终止。

4.-v指的是Monkey测试时打印log级别。

5.100000这里是指点击的次数，根据她们测试的经验，对于单个应用程序这个次

数设置在100000次就可以了；如果是整机，一般设置在500000次。

/data/local/tmp/log.txt测试的log记录在手机上/data/local/tmp/下面的log.txt里面，这个名

字可以自己写。

6.2>&1固定的写法，这个也很重要，代表的意思是中间忽略的东东的日志一并输

入到指定的文件中。

7.最后单独的一个"&"是一旦Monkey测试开始了，之后可以拔掉数据线，不会影

响Monkey测试。

8.测试所有模块monkey-s23--ignore-crashes--ignore-timeouts-v-v-v100000>

/data/local/tmp/log.txt2>&1&

12.-p<允许的包名列表>

Adb  shell  monkey  -pcom.example.login   100