软件测试理论基础（三）

1.  静态黑盒、动态黑盒、静态白盒、动态白盒

静态黑盒：

测试产品说明书。（①假设自己是客户 ②研究现有的标准和规范 ③审查和检测类似软件 ④产品说明书属性检查清单 ⑤产品说明书用语检查清单）

动态黑盒：

运行程序，输入数据，接受输出，根据需求文档或产品说明书检验结果。

(通过性测试：确认软件至少能做什么；失效性测试：蓄意攻击软件薄弱环节，考验其能力)

静态白盒（结构化分析）：

在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷。（如数据引用错误、数据声明错误、计算错误、比较错误、控制流程错误、子程序参数错误、输入\输出错误等）

动态白盒：

利用查看代码功能和实现方式得到的信息来确定哪些需要测试、哪些不需要测试、如何开展测试。（与调试的区别：动态白盒的目标是寻找bug，调试的目标是修复bug）

2.  白盒测试的原则和逻辑覆盖类型

白盒测试的原则：

①保证一个模块中的所有独立路径至少被测试一次；

②所有逻辑值均需要测试真（true）和假（false）；两种情况；

③检查程序的内部数据结构，保证其结构的有效性；

④在上下边界及可操作范围内运行所有循环。

白盒测试的逻辑覆盖类型：

语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：

①语句覆盖每条语句至少执行一次。

②判定覆盖每个判定的每个分支至少执行一次。

③条件覆盖每个判定的每个条件应取到各种可能的值。

④判定/条件覆盖同时满足判定覆盖条件覆盖。

⑤条件组合覆盖每个判定中各条件的每一种组合至少出现一次。

⑥路径覆盖使程序中每一条可能的路径至少执行一次

3.  集成测试和系统测试的区别和各自的应用场景

区别：

①对于用例的粒度，系统测试用例相对接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。 

②执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。

应用场景：

①集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。   

②系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法。

 4.  手动测试与自动化测试各自的优缺点

手工测试的缺点：重复，代价昂贵、容易出错，依赖于软件测试人员的能力等。

手工测试的优点：

①不可替代性。测试人员具有经验和对错误的猜测能力。

②可以站在用户角度。测试人员具有审美能力和心理体验。

③测试人员具有是非判断和逻辑推理能力。

自动化测试的优点：

①效率高，短时间运行更多繁琐的测试。  

②方便快捷，在程序修改频繁时，效果明显。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

③可执行手工测试困难或不可能进行的测试，如压力测试，并发测试，大量用户同时在线，可通过自动化测试模拟。

④可将测试技术人员解脱出来投入更多精力设计更好的测试用例。

⑤测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

自动化测试的缺点：

①不能取代手工测试。

②手工测试比自动测试发现的缺陷更多。

③对测试质量的依赖性极大。

④测试自动化可能会制约软件开发。自动测试更脆弱，所以维护会受到限制，从而制约软件的开发。

 5.  bug的评测

Bug的严重程度severity（）和优先级priority（）是两个重要属性，通常测试人员在提交bug的时候，只定义severity，而将priority交给leader定义，通常bug管理中，severity有四个等级，priority有五个等级。

Severity：

①blocker：即系统无法执行，崩溃，或严重资源不足，应用模块无法启动或异常退出，无法测试，造成系统不稳定。常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误，如服务器500错误。

②critical：即映像系统功能或操作，主要功能存在严重缺陷，但不会映像到系统稳定性。常见的有：功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。

③major：即界面、性能缺陷、兼容性，常见的有：操作界面错误，边界条件错误，提示信息错误，长时间操作无进度提示，系统未优化，兼容性问题。

④minor/trivial：即易用性及建议性问题。

Priority：

①immediate：即马上解决。

②urgent：急需解决

③high：高度重视，有时间要马上解决。

④normal：正常处理。

⑤low：在系统发布前解决，或确认可以不用解决。

 6.  bug状态（生命周期）

（1）New（新的）:当某个“bug”被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New。

（2）Assigned（已指派的）：new bug反馈给开发，开发确认是否为bug，如果是，开发组的负责人就将这个bug指定给某位开发处理。

（3）Open（打开的）：一旦开发人员开始处理bug的时候，就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

（4）Fixed（已修复的）：当开发处理后，将bug的状态设置为“Fixed”，等待测试组进行回归验证。

（5）Pending Reset（待在测试的）：bug被返还到测试组后，将bug设置为该状态。

（6）Reset(再测试)：测试组的负责人将bug指定给某位测试人员进行再测试。

（7）Closed（已关闭的）：如果测试人员经过再次测试之后确认bug 已经被解决。

（8）Reopen（再次打开的）：如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组。

（9）Pending Reject（拒绝中）：如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝。

（10）Rejected(被拒绝的)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

（11）Postponed\Delay（延期）：有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等。

 7.  app性能测试基本指标

①内存：让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。内存测试的几个概念：空闲状态、中等规格、满规格。使用adbshell脚本进行测试，查看Log数据。abd shell dump meminfo

空闲状态指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲；中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短。

内存测试中存在很多测试子项，清单如下：

空闲状态下的应用内存消耗；   中等规格状态下的应用内存消耗；

满规格状态下的应用内存消耗；  应用内存峰值；  应用内存泄露；

应用是否常驻内存；  压力测试后的内存使用。

②CPU：使用adbshell脚本进行测试，查看Log数据。abd shell dump meminfo

③流量：网络流量测试是针对大部分应用而言的，可能还有部分应用会关注网速、弱网之类的测试。流量监控：可以借用网易的开源工具：Emmagee

流量测试包括以下测试项： 应用首次启动流量提示； 应用后台连续运行2小时的流量值； 应用高负荷运行的流量峰值。

④电量：和竞品做对比测试，同一机型的测试机在不同时间，不同网络条件，不同功能使用的情况下分别测试电量使用情况。

测试手机安装目标APK前后待机功耗无明显差异；

常见使用场景中能够正常进入待机，待机电流在正常范围内；

长时间连续使用应用无异常耗电现象。

⑤启动速度：第一类：首次启动--应用首次启动所花费的时间；第二类：非首次启动--应用非首次启动所花费的时间；第三类：应用界面切换--应用界面内切换所花费的时间。

⑥滑动速度、界面切换速度。 ⑤⑥两者编写测试代码（AndroidInstrumentation），打桩到源码中，运行后通过log数据进行分析。

⑦与服务器交互的网络速度

关注的测试指标：

(1)连接超时：这个是App关闭的首要问题，而在移动应用中网络错误数据比例报错中最高的就是连接超时错误。

(2)崩溃： APP的崩溃，就是用户的崩溃。

(3)系统交互（电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等）在APP使用过程中，可能会遇到各种中断场景，一旦发生这些场景，APP就卡死或闪退。

(4)弱网下的运行情况：电梯里、地铁上，网络信号差时，界面卡死，同时错误提示一堆。

(5)CPU使用问题：CPU频率设置过高时会导致过热，过热导致耗电更严重，CPU频率设置过低导致手机滞后，应用处理缓慢同样会导致耗电。更多时候，用户解决CPU超载问题只能关闭甚至卸载App。

8.   web性能测试基本指标

web性能测试基本指标：页面加载时间；响应时间；并发用户数；吞吐量；错误率；网络带宽利用率；数据库响应时间；资源利用率；页面大小；缓存命中。

一个Web请求的处理包括以下步骤：①客户发送请求  ②web server接受到请求，进行处理；③web server向DB获取数据；④webserver生成用户的object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间（第三步不包括在每次请求处理中）。

(1)事务：一个事务表示一个Web请求的处理过程，一般的响应时间都是针对事务而言的。 (2)请求响应时间：从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为“TTLB”，即"time tolast byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则：

在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”；

在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”；

在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”；

超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去；

(3)事务响应时间：事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的。例如:跨行取款事务的响应时间就是由一系列的请求组成的，事务响应时间是直接衡量系统性能的参数。

(4)并发用户数：在同一时间点，与被测目标系统同时进行交互的客户端用户的数量。绝对并发: 多个用户同一时刻对服务端进行请求；相对并发: 多个用户同一时间段对服务器进行请求。

并发用户数和产品性能的关系: 理发店模型

场景:理发店(产品)有多个理发师(服务器), 越来越多的顾客(用户)过来理发

LightLoad: 师傅多客少;理发师还有空抽个烟,刷个手机;顾客来了就剪,剪完就走,体验不错;  HeavyLoad: 师傅少客多;理发师虽然忙个不停,但仍然井井有条;顾客等待的时间越来越长;  BuckleZone: 师傅少客人贼多;理发师开始安抚等待的客人维持秩序,剪发的效率下降; 顾客等待的时间指数级增长,而且没板凳坐,不满得喊理发师搬板凳。  最佳并发数: Light Load和Heavy Load的临界点,超过此节点开始影响客户的体验；  最大并发数: Heavy Load和Buckle Zone的临界点. 超过此节点理发师开始自乱阵脚。

（5）吞吐量：在一次性能测试过程中网络上传输的数据量的总和，吞吐量/传输时间=吞吐率。

 9.  web测试和app测试的不同点

系统架构方面：

web项目，一般都是b/s架构，基于浏览器的。

app项目，则是c/s的，必须要有客户端，用户需要安装客户端。

web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。

性能方面：

web页面主要会关注响应时间，app还关心流量、电量、CPU、GPU等。

兼容方面：

web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容；

app测试则要看分辨率，屏幕尺寸，还要看设备系统。

web测试是基于浏览器的所以不必考虑安装卸载。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件。

此外APP还有一些专项测试：如网络、适配性。