1.软件质量的定义
概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。 影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。可划分为三组，分别反应用户在使用软件产品时的三种观点。正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）
- 软件测试时软件质量保证的关键步骤。
- 但提高软件质量的途径是改进软件开啊过程的质量，而不是提高软件测试**。**
1、正确性（Correctness）：系统满足规格说明和用户目标的程度，即在预定环境下能正确地完成预期功能的程度；
2、健壮性（Robustness）：在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度；
3、效率（Efficiency）：为了完成预定的功能，系统需要的计算资源的多少；
4、完整性（Efficiency）或安全性（Security）：对未经授权的人使用软件或数据的企图，系统能够控制（禁止）的程度；
2.如何一个提高质量的Bug
存在问题
- bug表述不清，只有一句话，介绍bug是什么，然后没有其他的说明。
- 不提bug,发现问题直接告诉开发人员，在工作交流平台上不断讨论bug。
- 发现bug的场景没有保留，重现成本较高。
要把bug描述清楚：
1、唯一性。一个bug说明一个问题，如果有能力的话，一个bug说明一类问题，这一类问题一定要能判断出是一条代码错误引起。
**2、可重现。**提供这个bug的精确步骤，使开发人员容易看懂。
3、一致性。bug描述及所有信息要前后一致，不可有歧义。
4、完整性。最好能抓图，一目了然；测试环境和特定条件一定要描述清楚，许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以[软件缺陷]描述不要忽视这些看似细节但又必要的特定条件。
**5、简洁性。**通过使用关键词，可以使[软件缺陷]的标题描述短小简练，又能准确解释产生缺陷的现象。
**6、跟踪性。**也许随着版本的变化，或者测试的深入，对bug有了新的认识或者新的判断，及时补充相关信息，能够提供给开发更有用的信息。
7、客观性。[软件缺陷描述不要带有个人观点，不要对开发人员进行评价，软件缺陷报告是针对产品的。
**遇到不能重现的bug，**这些问题又不能提交bug，如果放过往往上线后出现的概率很大，问题也一般比较不可接受。所以我觉得对于重现不可重现的bug是做好测试很重要的能力。
**1、保留信息。**遇到问题，最好抓图，搜集错误日志，保留测试现场环境，一旦发现此问题不可重现，这些数据和信息将很重要。
2、提高意识。很多人在遇到这类问题时，往往觉得后来操作不可重现了，因此就忽视了。这样往往会把此类bug遗留到产品发布后。欠的帐总要还得。
**3、自我分析。**对于自己分析这类问题，其实对自己的提高是最大的。分析思路：环境问题和操作顺序。
**4、寻求帮助。**如果研发可以帮忙，并且研发是负责任的话，只有信息全，研发分析往往是最快的途径。如果研发忙或者不乐意做，也是不可厚非的。但就要寻求组内能力强的人员或者组内讨论分析，集中大家的力量往往可以事半功倍。 在我的经历中，通过上面的方法，几乎能把所有的不可重现的问题变成可重现的并且提交bug。
3.HTTP和HTTPS的区别
一、传输信息安全性不同
1、http协议：是超文本传输协议，信息是明文传输。如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。
2、https协议：是具有安全性的ssl加密传输协议，为浏览器和服务器之间的通信加密，确保数据传输的安全。
二、连接方式不同
1、http协议：http的连接很简单，是无状态的。
2、https协议：是由SSL＋HTTP协议构建的可进行加密传输、身份认证的网络协议。
三、端口不同
1、http协议：使用的端口是80。
2、https协议：使用的端口是443．
四、证书申请方式不同
1、http协议：免费申请。
2、https协议：需要到ca申请证书，一般免费证书很少，需要交费。
4.三次握手的过程
TCP三次握手
整个流程为：
- 客户端主动打开，发送连接请求报文段，将SYN标识位置为1，Sequence Number置为x（TCP规定SYN=1时不能携带数据，x为随机产生的一个值），然后进入SYN_SEND状态
- 服务器收到SYN报文段进行确认，将SYN标识位置为1，ACK置为1，Sequence Number置为y，Acknowledgment Number置为x+1，然后进入SYN_RECV状态，这个状态被称为半连接状态
- 客户端再进行一次确认，将ACK置为1（此时不用SYN），Sequence Number置为x+1，Acknowledgment Number置为y+1发向服务器，最后客户端与服务器都进入ESTABLISHED状态
为什么在第3步中客户端还要再进行一次确认呢？
这主要是为了防止已经失效的连接请求报文段突然又传回到服务端而产生错误的场景：所谓"已失效的连接请求报文段"是这样产生的。正常来说，客户端发出连接请求，但因为连接请求报文丢失而未收到确认。于是客户端再次发出一次连接请求，后来收到了确认，建立了连接。数据传输完毕后，释放了连接，客户端一共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，没有"已失效的连接请求报文段"。
现在假定一种异常情况，即客户端发出的第一个连接请求报文段并没有丢失，只是在某些网络节点长时间滞留了，以至于延误到连接释放以后的某个时间点才到达服务端。本来这个连接请求已经失效了，但是服务端收到此失效的连接请求报文段后，就误认为这是客户端又发出了一次新的连接请求。于是服务端又向客户端发出请求报文段，同意建立连接。假定不采用三次握手，那么只要服务端发出确认，连接就建立了。
由于现在客户端并没有发出连接建立的请求，因此不会理会服务端的确认，也不会向服务端发送数据，但是服务端却以为新的传输连接已经建立了，并一直等待客户端发来数据，这样服务端的许多资源就这样白白浪费了。
采用三次握手的办法可以防止上述现象的发生。比如在上述的场景下，客户端不向服务端的发出确认请求，服务端由于收不到确认，就知道客户端并没有要求建立连接。
TCP四次挥手
TCP三次握手是TCP连接建立的过程，TCP四次挥手则是TCP连接释放的过程**。**下面是TCP四次挥手的流程图：
当客户端没有数据再需要发送给服务端时，就需要释放客户端的连接，这整个过程为：
- 客户端发送一个报文给服务端（没有数据），其中FIN设置为1，Sequence Number置为u，客户端进入FIN_WAIT_1状态
- 服务端收到来自客户端的请求，发送一个ACK给客户端，Acknowledge置为u+1，同时发送Sequence Number为v，服务端年进入CLOSE_WAIT状态
- 服务端发送一个FIN给客户端，ACK置为1，Sequence置为w，Acknowledge置为u+1，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态
- 客户端收到FIN后，进入TIME_WAIT状态，接着发送一个ACK给服务端，Acknowledge置为w+1，Sequence Number置为u+1，最后客户端和服务端都进入CLOSED状态
*
为什么建链接要3次握手，断链接需要4次挥手？
-
**对于建链接的3次握手，**主要是要初始化Sequence Number 的初始值。通信的双方要互相通知对方自己的初始化的Sequence Number（缩写为ISN：Inital Sequence Number）——所以叫SYN，全称Synchronize Sequence Numbers。也就上图中的 x 和 y。这个号要作为以后的数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输的问题而乱序（TCP会用这个序号来拼接数据）。
-
**对于4次挥手，**其实你仔细看是2次，因为TCP是全双工的，所以，发送方和接收方都需要Fin和Ack。只不过，有一方是被动的，所以看上去就成了所谓的4次挥手。如果两边同时断连接，那就会就进入到CLOSING状态，然后到达TIME_WAIT状态。下图是双方同时断连接的示意图（你同样可以对照着TCP状态机看）：
使用Wireshark抓包验证TCP三次握手过程
为了加深对TCP三次握手的理解，抓包看一下TCP三次握手的过程。
抓包下来的内容为：
这里多说一句，由于wireshark抓包针对的是网卡，因此只要某张网卡上有网络访问，就会有数据包，这会导致Wireshark的抓包结果里面会有大量数据包，而大多数都不是想要的，这种情况可以使用Wireshark的过滤规则。我这里由于知道目标ip，因此使用的是"ip.src == xxx.xxx.xxx.xxx or ip.dst == xxx.xxx.xxx.xxx"这条规则只过滤特定的ip。
从抓包结果看来，整个过程符合TCP三次握手的预期：
- 客户端发送SYN给服务端
- 服务端返回SYN+ACK给客户端
- 客户端确认，返回ACK给服务端
5.如何做一个优秀的测试工程师
1.不搞清问题不撒手的决心
这是测试工程师所必备的基本素养。测试执行过程中，必然会碰到各种各样的出错或故障，有些出错是符合预期的，有些出错是人为引起的，有些是已知的缺陷，而有一些却是新缺陷。面对这么多类型的出错，我们就得耐心细致地一一确认出错的原因，排除人为错误和已知缺陷，发现新缺陷。只有保持高度的怀疑精神和充沛的精力，才能发现越来越多的新缺陷，才能证明测试的价值所在！
2.坐的住，耐得了寂寞
软件测试工作基本就是一杯茶、一枝笔，在一台电脑前面坐一天。真正喜欢测试工作的人根本不会在意这些。所以，想要成为一个优秀工程师，就得有这方面的思想准备。
3.善于沟通
与开发人员的沟通要点是，能让他在最短时间内意识到缺陷的存在，并能根据自己提供的信息，复现这些缺陷；或者在原来环境中能快速分析出缺陷产生原因。有些开发人员出于自我保护意识，容易和测试人员发生冲突。他们会认为测试人员是“麻烦制造者”。这就需要测试者能主动掌控好沟通局面，尽量避免僵局和对峙的发生。
4.善于分析问题，善于总结，逆向思维
在软件中，20%的地方可以发现80%数量的缺陷。所以我们在发现缺陷并报告后，不能把它们放在一边不管，而要不断总结，尽可能多地发现类似缺陷。
5.不断学习的精神
软件测试技术随着时间的变化也在做一些提高和改进，作为一名优秀的测试人员要善于利用书籍，网站，论坛，交流等各种途径不断提高自己的软件测试水平。
6.不怕重复的精神
测试工作一大特点就是重复，它的重复度比软件开发工作还要高。成百上千条测试案例，需要按照遍历条件一个一个地完成。有时候为了复现一个无意冒出来的错误，需要无数次重复某些步骤；更要命的是，有时候根本复现不出来。所以说，测试工作需要不怕重复的精神去支撑。
7.解业务知识
更好的了解你说测试软件的业务知识是非常重要的，对业务知识了解得越深入，越能够找出更深入，更关键，更隐蔽的软件错误。所以作为一名优秀的软件测试工程师，要多向该领域专家，同行学习，提高自己的业务知识水平。
6.性能测试，负载测试，压力测试
-
性能测试：主要是在压力测试下收集系统的各项性能指标，与预期的指标进行对比，如关注并发用户数，cpu、内存，响应时间；通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。测试软件在系统中的运行性能，度量系统与预定义目标的差距。关注点：how much和how fast
-
负载测试：性能测试的一种，对系统不断增加压力，或增加一定压力下的持续时间，知道系统的性能指标达到极限，如响应时间超过预定指标，强调压力持续时间。负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。通 过逐步增加系统负载，确定在满足性能指标的情况下，系统所能承受的最大负载量。关注点：how much
- 负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。
- 负载测试是在被测系统上不断增加压力，直到各项指标达到饱和，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。这种测试方法可以找到系统的处理极限，为系统调优提供数据。
-
压力测试（Stress Test）： 压力测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。（Spike testing：短时间的极端负载测试，Extreme testing：在过量用户下的负载测试。Hammer testing：连续执行所有能做的操作）
- 压力测试是测试系统在一定饱和状态下，强负载（大数据量、大量并发用户等）测试，例如cpu、内存等在饱和使用状态下，系统能够处理的会话能力，以及系统能否会出现错误。压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景-例如增加用户数对系统进行压力测试。压力测试的目的是为了揭露高负载下的问题，例如资源竞争、同步问题、内存泄漏等。
-
容量测试：是系统承受超额的数据容量，测试系统是否能够正常处理，通常和数据库有关。确定系统可处理同时在线的最大用户数,使系统承受超额的数据容量来发 现它是否能够正确处理。
7.数据库里面的执行的四大特性是什么
原子性：原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
一致性：如果事务执行之前数据库是一个完整的状态，那么事务结束后，无论事务是否执行成功，数据库仍然是一个完整的状态。
数据库的完整状态：当一个数据库中的所有的数据都符合数据库中所定义的所有约束，此时可以称数据库是一个完整的状态。
隔离型：多个用户并发访问数据库时，一个用户的事务不能被其他用户的事务所干扰，多个并发事务之间数据要相互隔离。
持久性：指一个事务一旦被提交，他对数据库的影响是永久性的。
8.sqrt（2）的计算结果保留十位
已知 sqrt(2)约等于 1.414，那么就可以在(1.41, 1.42)区间做二分.设l = 1.41, r = 1.42, mid = (r+l)/2
public class Main {
public static void main(String[] args) {
double l = 1.41;
double r = 1.42;
double mid = (r+l)/2;
double flag = 0.0000000001;
while(r-l > flag){
mid = (r+l)/2;
if(mid\*mid < 2)
l = mid;
else
r = mid;
}
System.out.println(mid);
}
}
9.测试里面的兼容性有那几方面
定义：兼容性测试就是测试电脑硬件之间是否有不兼容等问题或软件问题。
兼容性测试侧重哪些方面
1、向前兼容和向后兼容向前兼容是指可以使用软件的未来版本，向后兼容是指可以使用软件的以前版本。
2、不同版本之间的兼容实现测试平台和应用软件多个版本之间能够正常工作。
3、 标准和规范 高级标准是产品应当普遍遵守的。若应用程序声明与某个平台兼容，就必须接受关于该平台的标准和规范。低级标准是对产品开发细节的描述。
4、数据共享兼容数据共享兼容是指要在应用程序之间共享数据，要求支持并遵守公开的标准，允许用户与其他软件无障碍的传输数据。
扩展资料：
软件的兼容性是衡量软件好坏的一个重要指标，在具体测试中可以从以下几个方面来判断：
1、操作系统兼容性 有些软件在不同的操作系统平台上重新编译即可运行，有些软件需要重新开发或是改动较大。
2、异构数据库兼容性 这类软件要考虑其对不同数据库平台的支持能力，软件是否可直接挂接，或需提供相关的转换工具。
3、新旧数据转换 软件是否提供新旧数据转换的功能。
4、异种数据兼容性 可否完全正确地读出这些格式的文件
5、应用软件兼容性
6、硬件兼容性 硬件兼容性考察软件对运行的硬件环境有无特殊说明。
11.如何保证测试的效率
1.尽早参与到项目中
测试尽早介入项目详细了解项目的业务需求，做好测试的前期准备。如果项目测试的前期了解业务需求、了解[产品属性]和准备测试数据不充分，往往测试效率很低，测试时间变长，测试效率急剧下降。
2.合理的测试计划
首先要有一个合理的详细的测试计划：没有详细的测试计划，测试部的每个成员都在那儿盲无目的测试，何谈提高测试效率？当然测试计划也不能够太细，太细了，编写测试计划同样浪费时间，做到时可而止。最好是测试任务尽量能细化到测试的功能较为理想。
3.要做好测试文档的评审
测试负责人认真做好[测试文档，测试经理一定要认真做好[测试用例的评审，尽量使用较少的[测试用例发现较多的Bug，无疑是最佳提高效率的一种方式。很多时候，经验较少的测试人员在设计[测试用例的时候，写了很多的测试用例，测试时几乎没有发现缺陷。还有一种：比如说等价类的测试，只要具备代表性就可以了，如果写了很多测试用例，执行了半天，臃肿的测试用例，未发现任何问题，也很不值。这些主要是靠测试用例评审的时候，测试Leader去把握了。尽量做到在满足需求的情况下，精简测试用例数量，提高测试覆盖率。很多时候，测试人员写好用例就自己测试，根本没人评审，有些地方理解有偏差，测试点没测试到，导致发给客户版本被退回，给公司也会带来巨大经济损失。
4.提高测试接受的标准，减少测试版本送测次数：
大部分公司的开发人员都有一种惰性，一旦公司成了测试部，他们自己测试时，都不会那么认真，以为有了测试人员，就自己就解放了。很多时候都是调试编译通过，实际上开发人员没有做完整的自测，就拿到测试部进行测试。如果测试部门有严格的测试接受标准，一旦发现有重大问题，立即拒绝测试，送回开发人员修改。可以减少很多次反复测试，重复测试，明显提高了测试效率。
5.发挥主观能动性，积极沟通
测试工作是一项沟通要求比较高的工作，一般需要同项目经理、产品经理、开发人员、业务人员、客户沟通。很多时候，由于测试介入较晚，测试时间短，测试初期测试人员了解需求不及开发人员，为了迅速熟悉需求，需要项目组成员之间相互培训和沟通。测试人员为了利于测试工作，平时也需要主动和开发团队沟通项目的进度、项目存在的问题、项目的需求变更等等情况。与团队成员沟通得越充分、对项目的信息收集和把握得越及时、越准确，我们的测试工作才可能做得越顺利，才可能提高测试效率。我们绝不能消极等待或一味埋怨开发人员的不理解和不重视。我们首先需要正视自己、改进自己，通过自身的不断努力让开发人员，真正体会到测试的价值。同时，也需要理解并配合开发人员的工作。只有这样，才能赢得开发人员的支持。互相配合、互相促进，项目成员之间形成良性循环，彼此感情加深了、配合默契了、工作效率和工作质量也就自然提高了。
6.按照项目的性质大小不同，引入自动化测试工具和自动化测试脚本
是否引入自动化的测试工具，主要取决于测试的时间长短和测试的轮次。一般来说，测试周期较长、版本升级平凡和回归测试次数较多的项目，引用测试工具可以提高测试效率。如果测试周期较短，本来测试周期只有两三个月，开发测试脚步就要花费大量时间，引入自动化测试工具，用的次数较少，结果得不丧失，劳民伤财！
7.对测试项目前景充满信心，调整最佳心态，保持愉悦的工作心情：
一般来说，如果大家认为测试的项目没什么发展前景，当然测试也不会很卖命，测试效率不用说。如果某个测试人员碰到什么不顺心的事，当天的工作效率肯定比平常低。所以，要保证测试效率，测试负责人要察言观色，及时找不开心的下属谈心，了解并帮忙消除部分员工的[不良情绪让员工有更好的心情投入到测试工作中去。
8.提高测试人员的专业技能和工作能力：
由于测试技术的不断成熟和完善，许多的新技术陈出不穷，作为测试人员需要不断提高自己的专业技能和[工作技能。不断的给自己充电，补充测试理论知识，让自己[工作技能]力去弥补专业技能的不足。这样，你的工作同样可以做到最棒，效率自然很高。一段时间过去，回过头来一看，自己确实进步不少，没有虚度光阴呀！
362
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
