常见的黑盒测试方法

1.等价类划分法 2.边界值法  3.判定表 4.场景法 5.正交试验法

黑盒测试和白盒测试的优缺点

黑盒测试的优点有：

比较简单，不需要了解程序内部的代码及实现；

与软件的内部实现无关；

从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；

基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

在做软件自动化测试时较为方便。

黑盒测试的缺点有：

不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的 30%；

自动化测试的复用性较低。

白盒测试的优点有：

帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

白盒测试的缺点有：

程序运行会有很多不同的路径，不可能测试所有的运行路径；

测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；

系统庞大时，测试开销会非常大。

典型的软件测试模型

v模型  瀑布模型   螺旋形模型

在测试中80-20原则是指

80%的BUG出现在20%的模块中

目前Unix 操作系统提供的一个常用的文本编辑器是？

Unix常用编辑器是vi ，该编辑器还包含一般模式/命令模式，输入模式，命令行模式

软件的六大质量特性

1.功能性（往下包含子特性）

1、适合性：软件是否提供了相应的功能

2、准确性：软件提供的功能是否正确（用户需要的）

3、互操作性：产品与产品之间交互数据的能力,例如word对其他文档的支持能力

4、保密安全性：允许经过授权的用户和系统能够正常的访问相应的数据和

信息，禁止未授权的用户访问.......

5、功能性的依从性：国际/国家/行业/企业 标准规范一致性

2.可靠性：产品在规定的条件下，在规定的时间内完成规定功能的能力（往下包含子特性）

1、成熟性：软件产品为避免软件内部的错误扩散而导至系统失效的能力（主要是对内错误的隔离）,exception等的处理

2、容错性：软件防止外部接口错误扩散而导致系统失效的能力（主要是对外错误的隔离）

3、易恢复性：系统失效后，重新恢复原有的功能和性能的能力。

4、可靠性的依从性

3.易用性：在指定使用条件下，产品被理解、 学习、使用和吸引用户的能力（往下包含子特性）

1、易理解性：软件交互给用户的信息时，要清晰，准确，且要易懂，使用户能够快速理解软件。

2、易学性：软件使用户能学习其应用的能力。

3、易操作性：软件产品使用户能易于操作和控制它的能力。

4、吸引性：

5、易用性的依从性：

4.效率性：在规定台条件下，相对于所用资源的数量，软件产品可提供适当性能的能力（往下包含子特性）

1、时间特性：平均事务响应时间，吞吐率，TPS（每秒事务数）. 软件处理特定的业务请求所需要的响应时间。

2、资源利用性：CPU 内存 磁盘 IO 网络带宽 队列 共享内存. 软件处理特定的业务请求所消耗的系统资源。

3、效率依从性：

5.软件维护性："四规"， 在规定条件下，规定的时间内，使用规定的工具或方法修复规定功能的能力（往下包含子特性）

1、易分析性：分析定位问题的难易程度

2、易改变性：软件产品使指定的修改可以被实现的能力

3、稳定性：防止意外修改导致程序失效

4、易 测试性：使已修改软件能被确认的能力

5、维护性的依从性

6.软件可移植性：从一种环境迁移到另一种环境的能力（往下包含子特性）

1、适应性：适应不同平台

2、易安装性：被安装的能力

3、共存性：软件产品在公共环境中与其它软件分享公共资源共存的软件。

4、易替换性: 软件产品在同样的环境下，替代另一个相同用途的软件产品的能力。

5、可移植性的依从性：

软件缺陷产生的原因包括？

软件本身来说：

　　①需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。

       ②系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。

       ③对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。

       ④对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。

       ⑤没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。

       ⑥系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。

       ⑦由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。

       ⑧新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。

团队工作来说：

　    ① 系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。 　　②不同阶段的开发人员相互理解不一致。例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。

        ③对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。

        ④项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。

技术问题方面：

　　①算法错误：在给定条件下没能给出正确或准确的结果。

       ②语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。

       ③计算和精度问题：计算的结果没有满足所需要的精度。

       ④系统结构不合理、算法选择不科学，造成系统性能低下。

       ⑤接口参数传递不匹配，导致模块集成出现问题。

项目管理的问题

　　① 缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。

        ②系统分析时对客户的需求不清楚，或者和用户的沟通存在一些困难。

        ③开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误

       ④开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。 

       ⑤文档不完善，风险估计不足等。

jmeter测试元件的执行顺序

1.Config Elements

2.Pre Processor

3.Time

4.Sampler

5.Post Processor

6.Assertion

7.Listener

https://www.cnblogs.com/zhuzhaoli/p/10263814.html //具体介绍参考该文章

ORALCE数据库默认的监听端口号为：  1521 

MYSQL默认端口号为：1433

使用Loadrunner的步骤

 1.Virtual User Generator 创建脚本

  创建脚本，选择协议

  录制脚本

  编辑脚本

  检查修改脚本是否有误

  2。中央控制器（Controller）来调度虚拟用户

  创建Scenario，选择脚本

  设置机器虚拟用户数

  设置Schedule

  如果模拟多机测试，设置Ip Spoofer

  3。运行脚本

  分析scenario

  4.分析测试结果

什么是软件测试？

软件测试（Software Testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

软件测试的目的？

发现软件的缺陷与漏洞，对软件的质量进行评估，提升软件质量

什么是集合点？设置集合点有什么意义，loodrunner中设置集合点的函数是哪个？

集合点用以同步虚拟用户，以便恰好在同一时刻执行任务。在测试计划中，可能会要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据，从而达到测试计划中的需求。

插入集合点是为了衡量在加重负载的情况下服务器的性能情况。

添加方法：

1、其中录制脚本script view中添加：lr_rendezvous(“XXX”);

2、在录制脚本的tree view里添加：rendezvous-XXX;

性能测试中tps上不去有哪些原因？

TPS（Transaction Per Second）：每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量，一般以request/second为单位。

1、网络带宽

在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。

2、连接池

可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

（连接池的具体内容，参考博客：性能测试：连接池和线程）

3、垃圾回收机制

从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS

也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。

4、数据库配置

高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，

就会导致数据库事务处理过慢，影响到TPS。

5、通信连接机制

串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。

（协议的连接，参考博客：HTTP协议进阶：连接管理）

6、硬件资源

包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

7、压力机

比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。

8、压测脚本

还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。

提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。

9、业务逻辑

业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。

10、系统架构

比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。

响应时间与吞吐量之间的关系是什么？

响应时间的定义：响应时间是提交请求和返回该请求的响应之间使用的时间

吞吐量的定义：吞吐量是对单位时间内完成的工作量的量度

响应时间越短，单位时间内的吞吐量越大；响应时间越长，单位时间内的吞吐量越小