精华内容
下载资源
问答
  • 容错过滤软件
    千次阅读
    2017-12-28 09:57:17

     

    论高可靠性系统中软件容错技术的应用

    摘要:

        2016年3月,我公司承担了国家某安全中心漏洞挖掘系统的开发工作,我在该项目中承担系统架构设计师的职务,主要负责系统的架构设计。该项目的主要目的是依托大数据平台从互联网流量中挖掘未知漏洞。

     

        本文以漏洞挖掘系统为例,从多个角度对系统的可靠性进行了分析,重点讨论了两种软件容错技术。针对互联网流量的需要实时捕获,在流量捕获模块中采用了双机热备技术;针对漏洞数据需要永久存储不丢失,在数据存储方面采用了RAID5机制;针对漏洞识别的准确性,在漏洞判定部分采用了N版本程序设计方法;此次之外还对采取恢复块方法、防御式程序设计及集群部署等方法。通过以上多种措施,保证了系统的可靠性。目前系统已稳定运行一年多,从而验证了该项目采用可靠性技术的正确性。

     

    正文:

           随着互联网的快速发展,网络上出现的安全问题越来越多,从互联网发展至今,已经爆发了众多的网络攻击事件,如网络蠕虫病毒感染、主机被控制、数据库被非法访问、非法电子银行转账等等。针对这些安全问题,很有必要开发一种web漏洞的发现和利用技术。2016年3月我公司承接了国家某安全中心漏洞挖掘系统的开发工作。该项目通过对互联网中的流量进行特征分析,从中提取出相关的攻击内容,并将这些内容存储到大数据平台,结合大数据分析技术,对攻击者进行跟踪分析,从而捕获出未知漏洞。通过这种漏洞挖掘技术可以极大的解决大数据,大流量背景下web攻击入侵,帮助用户做好“事中”的安全工作,协助安全厂商对互联网攻击进行针对性过滤。

     

        系统在整体架构上采用了面向服务的架构SOA。前端采用了PHP进行开发,后台流量分析工作采用运行性较教高的c语言在Linux服务器上开发,流量包存储使用了企业磁盘阵列,数据存储采用了mysql。通过将系统拆分为多个子模块,各个子模块的构建上用服务进行了封装,它们之间通过消息进行通信。经过对客户需求的分析,我将该系统拆分为了流量捕获模块(负责从互联网中捕获流量)、pcap文件存储模块(负责将互联网中的流量存储到大数据平台)、流量分析模块(负责对流量进行分析验证)、数据库模块(负责漏洞数据的存储)和web管理模块(负责下发漏洞规则和查看漏洞信息)。

     

        按照合同规定该项目开发工作必须在一年内完成,在保证系统功能及性能的基础上,对系统的可靠性提出了要求。在可靠性方面要求:1. 实时捕获流量要求系统出现故障宕机不能超过5分钟;2. 系统提取出的漏洞及对应的流量不能丢失;3. 系统对漏洞识别准确率需要达到90%以上。

     

        系统的可靠性是系统在规定时间内及规定的环境条件下,完成规定功能的能力,也就是系统无故障运行的概率。为了保证系统的可靠性,必须采取相应的容错机制。容错技术分为结构冗余、信息冗余、时间冗余等。其中结构冗余包括硬件冗余和软件冗余。信息冗余是通过校验码来实现,时间冗余通过重复多次进行相同的计算来实现。提高系统可靠性的技术主要有N版本程序设计、恢复块方法、防卫式程序设计、双机热备、集群技术及冗余设计。项目中我根据客户对系统可靠性的要求从以下几个方面进行了分析。

     

        针对系统需要实时捕获流量,流量捕获系统7*24小时正常运行。我们在流量捕获模块采用了双机热备。在系统中部署两台流量捕获系统,一台作为主流量捕获系统,一台作为备用系统,两个系统之间通过心跳线连接。当流量捕获主系统出现故障的时候,立即将流量捕获工作切换到备用系统中,实现了系统的无缝切换,从而保证系统的可靠性。针对捕获的有价值漏洞原始数据和漏洞数据不丢失,我对数据存储采取了企业磁盘阵列,采用了raid5 N+1网络存储技术,即便磁盘坏了一个,也可以进行恢复。由于每天需要处理的网络流量大约30TB,在这里我们才用了5台10TB硬盘挂载到服务器上。除硬件上采取的措施外,软件上我们也做了特别的容错技术来提高系统的可靠性。下面从软件容错的两种方法详细讨论它在可靠性的中应用。

     

           N版本程序设计

           N版本程序设计的思想是相同的需求,使用不同的人来做设计和编码。开发出几个不同的版本,各自验证正确后,通过表决器比较各个版本执行的结果。采用少数服从多少的策略,这样可以将某个偶然出现的错误屏蔽掉,这种方法实时性非常高,实现代价也比较大。一般只会用在程序模块的重要性特别高,一旦计算错误将会出现严重后果的模块。在本项目中,考虑到本项目开发人员的紧缺性,使用该方法虽然可以提高漏洞识别率,但是将增加项目成本。而客户又对漏洞判定的准确性提出了很高的要求。基于以上考虑,我将系统中特别重要的漏洞判别模块采用了该方法,在本项目针对sql注入漏洞的判别,不同的安全开发工程师都有各自不同的理解及各自的判定方法,通过将判定工作分给三名安全开发工程师进行背对背开发,开发出三个不同版本的漏洞判定程序,每个程序对漏洞判定都设定了高危(积分为5分)、风险(积分为3分)和未知(积分为1分)和安全(积分为0分)4个不同级别。当3个版本的总积分大于等于8分则认定为高危漏洞;当总积分小于4分认定为安全。通过该方法大大提高了漏洞的识别率。

     

           恢复块方法

           恢复块方法的思想是首先设计好几个备用块,选取其中一个作为主块。首先执行主块,当主块执行不合格后,再执行后备块1,后备块1执行不合格,再执行后备块2,依次类推,直到输出正确结果为止。它是一种后向恢复的策略(将系统恢复到一个正确的状态,继续执行),其特点是由于主块可能执行不合格,可能要执行多个恢复块,故实时性比较差。这种方法对验证模块的正确性要求也非常高,实现代价也比较大。在该项目中,由于系统对流量的处理要求在12小时内处理完成,对系统的实时性要求不是很高。在该项目中进行流量抓包的时候,可能捕获到异常的包,有的甚至不是一个完整的http请求,程序在处理这类异常包的时候,只对能获取五元组的数据包进行分析。在使用恢复块方法中,主块用于处理完整的http请求,并根据请求的动作和漏洞规则匹配输出正确结果;后备块1用于处理只有http请求的包,根据请求规则例如sql注入、xss跨站攻击等行为进行匹配输出,输出正确结果,后备块2用于处理只有http响应的包,根据响应的规则例如数据库账号,进行匹配输出,后备块3用于处理其他异常的包,并进行五元组统计。通过该中方法,大大提高了系统的可靠性。

     

           除了以上几个方面的考虑外,对整个系统采用了防卫式程序设计、防御式编程技术,同时也考虑了集群技术。在指定预算的情况下,针对系统的性能,对使用高性能主机和使用分布式集群进行了思考。但是考虑到系统的可扩展性及可靠性,我使用了分布式集群技术。通过使用消息队列,对流量分析模块进行了分布式部署,各个模块通过从消息队列中取出消息进行处理。通过使用该分布式集群部署流量分析模块,当其中一台服务器出现故障的时候,其他服务器还可以从消息队列中取出消息进行处理,避免了因为服务器单点故障导致系统性能及可靠性下降。除了采取以上的措施外,我们还通过加强测试,增加检查机制来保证系统的可靠性。

     

           该项目开发工作于2016年8月完工,系统上线后,我们的安全分析人员和客户使用该系统对互联网流量进行漏洞挖掘,一共产生了150种以上的web流量攻击流量特征和5个未知web漏洞。在国家某安全中心网研室的其他项目中起到了支撑作用,尤其是某变量覆盖漏洞、某文件写入漏洞,某sql注入漏洞在项目使用过程中取得了一定得效果,得到了好评。为开展互联网安全事件得防御、发现、预警和协调处置等工作提供了数据依据,更好的维护了国家公共互联网安全,保障基础信息网络和重要信息系统的安全运行。

     

           在项目开发完成进行漏洞挖掘期间,系统的运行非常好,除了常规系统维护,很少出现系统故障,满足了客户对系统的可靠性要求。该项目在保证系统可靠性方面使用了双机热备、RAID5磁盘阵列、N版本程序设计、恢复块方法、防御式程序设计及集群技术。经过验证,这些措施都十分正确的。

    更多相关内容
  • 很好用的彩票3星缩水软件,很难得的大底缩水软件,附带多个大底容错交集。
  • 大底交集过滤工具V2.04
  • 数据和计算系统如何容错

    千次阅读 2021-12-13 16:02:56
    容错是大规模数据系统和计算系统的必备功能,不能容错的分布式系统基本没有可用性。大家可能觉得高质量的系统错误率没有那么高,实质上系统的故障率总是随着系统规模和复杂程度增加。笔者读书的时候曾经听过一位参与...

    容错是大规模数据系统和计算系统的必备功能,不能容错的分布式系统基本没有可用性。大家可能觉得高质量的系统错误率没有那么高,实质上系统的故障率总是随着系统规模和复杂程度增加。笔者读书的时候曾经听过一位参与过先进飞行控制系统设计的专家讲课。这位专家有一句原话是说飞机大多是带故障飞行的。笔者很多研究无人机的师兄们都有意无意的避免坐飞机。笔者坐飞机也会再三确认购买保险 :) 这不是吓唬大家,只是为了说明容错与我们息息相关。本篇我们来聊聊系统容错的方方面面。

    1. 可靠性从哪里来

    1.1 安全、可靠与可用

    安全(safety)可靠(reliable)可用(available)是我们常用的几个词汇。安全通常指避免灾难的能力,可靠指的是无故障提供指定功能的能力,可用指的是某个时间段系统能够正常运行。安全与可靠容易区分。举个例子来说,一架飞机坏了停在地上,它是安全的,因为它不可能引发灾难,但是不可靠,因为它无法完成飞行任务。可靠和可用的区别是什么呢?再举一个例子,你把钱存在银行里,晚上银行下班了,你没法通过柜台取钱。你的资产没有问题,银行具备可靠的保管你的资产的能力,但是它的服务不是7 x 24 小时可用的。

    存储行当的人常说的黑话有DU(Data Unavailable)DL(Data Loss)DL指的是数据丢失,DU指的是数据不可用。例如一个存储阵列的机头坏了,数据仍然在硬盘里,但是访问不了,这就是DU。如果一个RAID5,硬盘同时坏掉了二块,数据丢了,那就是DL。保证数据可靠可用是数据系统的生命线,在这个基础上谈性能和功能才有意义。

    1.2 失效安全是第一原则

    系统设计应该将失效安全确定为第一原则,它指的是如果我们的系统发生故障,应该尽量避免灾难性的后果。典型的例子是电梯故障后第一时间停止不动。数据系统中常常需要去重(deduplication),如何高效的找到重复数据呢?常用的方式是计算数据的指纹,例如数据的MD5哈希值。如果哈希值不同,则认为数据不一致,如果哈希值相同,则直接比较数据确认数据本身一模一样。哈希算法原理上不能排除不同数据有同样的哈希值,但是同样的数据必定有同样的哈希值,所以用哈希值可以过滤掉不同的数据,直接比较原始数据才能确认完全的一致性。这个方法体现了失效安全的设计原则,因为哈希重复的小概率事件不会导致不同的数据被误判成相同而造成数据丢失。

    1.3 可靠性从哪里来?

    任何系统,无论硬件或软件,都可能存在故障。构成系统的组件越多,系统组件故障概率越高。如何在存在故障情况下仍然保证复杂系统的可靠性和可用性呢?答案是容错,即在系统层面屏蔽组件故障。一切容错方法的基础是冗余,即存在多个组件执行同样的功能。例如数据在多个硬盘上做RAID需要硬盘空间的冗余,服务在多台机器上做热备需要额外的机器做冗余。冗余转化为成本的增加,容错方法增加了系统无故障时的运行代价,必然带来一定的性能损耗。所有的系统设计最后都面临可靠性、性能和成本之间的权衡。我们常听到某些厂商的宣传,说他的系统性能达到物理极限,可靠性达到了几十个九,但是价格非常便宜。从原理上讲这中间可能有一项是在打消费者的马虎眼。可靠性是设计出来的,不是吹出来的。

    1.4 容错总有个限度

    冗余是可靠性的基础,那么冗余决定着系统对错误容忍的限度。用户成本总是有限的,不可能配置无限制的冗余,所以不存在无限制的容错。例如数据存三分拷贝,那么只能同时容忍三个硬盘故障。那么限度之外的可靠性怎么保证呢?靠管理。拿存储系统来说,必须有人定期巡检,监控硬盘的健康,故障硬盘及时更换,老化的硬盘主动替换。它的目的在于减少故障的概率,延长一次故障和二次故障之间的时间。实际中很多客户或者集成商,硬盘坏了不知道,或者拖延处理,结果造成冗余耗尽,数据丢失,故障演变成灾难。

    笔者曾经在某研究所实施系统,实施过程中布线需要拆掉半层楼的地板。某位老师过来帮忙,不小心把旁边友商的电源踢掉了,造成服务不可用,恢复了半天之久。友商系统采用的是三个数据拷贝的冗余,但是因为电源不够,三台机器都连接在同一个电源上,最终造成了一个单点故障。所以说再好的技术也不能弥补管理的漏洞。可靠性是技术和管理相辅相成的结果。

    图片

    2. 所有的系统都是分布式系统

    计算机系统发展到今天,大量采用了分层设计的观念。下层为上层提供服务,上层把下层系统当成一个黑盒子,只关注功能接口,忽略实现细节。分层设计的优势是不同层次的人可以独立工作。分层设计的性能不是最优的。为了提升性能,需要打开黑盒子,给上层提供更多额外的语义,将内部实现机制暴露出来,即所谓协同设计。例如操作系统开发者常常要处理刷TLB缓存,操作memory bar,关注内存顺序模型(memory model)等等。因为计算机硬件的多CPU、多核、内存和外设之间也存在复杂的交互协议,事实上构成了一个分布式系统。为了提升性能,一个CPU指令写内存时,如果内存被别的CPU锁住,它可能选择将写操作缓存到硬件buffer中,异步刷到内存。如果另一个CPU要读同一个内存的内容,这个时候要求程序员调用硬件的某个机制确保刚才的更新操作从buffer到了内存。

    图片

    上图展示了多CPU和内存在微观层面运行一个MESI协议确保缓存一致性。下图的硬件系统运行的则是更高级和复杂的基于Directory的缓存一致性协议。这些协议并不比一个典型的分布式数据系统使用的算法简单,却在在一个访存指令中完成。软件与硬件并没有特别严格的界限,软中有硬,硬中有软,软硬兼施才是王道。

    很多人将存储系统也理解成硬件盒子。事实上即便是最传统的存储系统也是由硬件和软件组成的分布式系统。这其中包括多个主机、硬件柜(JBOD)、多硬盘,且不说主机上运行复杂的存储软件,即便是JBOD和硬盘都不是纯粹的硬件,上面也运行固件(firmware),和存储软件发生复杂的交互行为。可靠性设计正是要从这个分布式系统出发考虑,通过硬件之间的冗余,传输线之间的冗余,JBOD之间的冗余,控制器软件之间的交互,最后实现一个黑盒子的整体可靠性。即便是个黑盒子,它仍然会输出某些接口给使用者,在上层应用的配合下,达到性能和可靠性的权衡。文件存储对外提供的sync语义就是一个很好的例子。如果没有sync语义,所有的写操作都要落盘后返回,性能损耗非常大。由调用者决定数据的落盘时间,实际上将确保数据可靠性的部分责任交给了用户,以换取更好的性能。

    图片

    3. 传统数据系统的容错

    传统的存储系统发明了很多容错方法,逐步演化成确保数据系统可靠和可用的常规手段。理解他们是理解系统容错的基础。

    3.1 几种典型的容错设计

    多副本应该是最早的数据容错方法,它将数据存成N份,并确保N份数据完全一致,这样可以容忍N-1份副本的丢失。它带来的问题是有效空间只有总空间的1/N,从成本上来讲很不划算。后来CMU的教授发明了RAID算法,包括RAID5RAID6RAID10等,使用户获得了空间利用率和可靠性上更多的选择。后来发展的纠删码Erasure Coding,还有说的很玄乎的网络编码,本质上都是编码方法不同。他们原理上都是数据分割成片段,把冗余数据块扩展、编码,并将其存储在不同的位置,比如磁盘、存储节点或者其它地理位置。没有绝对先进的编码方法,所有的方法只是根据需要在性能、可靠性和成本之间做权衡。

    图片

    多副本和RAID编码解决了数据的可靠性问题,没有解决数据服务的可用性问题。传统存储系统有双控制器的设计方法,即两个机头带着一个硬盘JBOD,硬盘做RAID保证数据可靠性,控制器的软件互相热备保证服务可用性。如果两个控制器都可以同时提供同一份数据的访问,那就是所谓的双活active-active,否则就是热备active-passive。双控设计解决了可用性问题,但是引入了另外的难题。

    3.2 双控是睡不醒的噩梦

    在所有关于N冗余的问题中,N=2必定是最难的,因为需要两台机器在故障发生且没有第三方仲裁的情况下达成一致(回忆一下你和你老婆或者丈夫吵架的情景 :D)。所以双控制器的存储系统是最难实现的。双控系统的控制器在检测到对方故障的时候,需要接管数据服务。因此双控必须解决所谓的脑裂( split-brain)问题,即两个控制器都认为对方死了,尝试接管服务。双控系统的核心问题就是避免两台机器访问同一份数据,造成数据损坏

    双控系统的两个控制器之间通过心跳检测对方故障。然而不幸的是,网络故障和机器故障是无法区分的。控制器A认为B已经宕机,可能只是因为A、B之间的通信故障了,B控制器仍然在读写数据,所以A认为B故障即接管服务可能造成灾难。存储软件的一个重要任务是确保数据的受控访问,避免这种情况发生。解决问题的方法是增加更多独立的心跳。所以双控制器之间借助网络、PCIE、共享硬盘等所有可能的渠道,确定对方控制器是否真的宕机。通常从第一心跳开始检测,如果第N心跳都断了,第N+1心跳还活着,那意味着网络故障,机器没有故障。然而如果所有的心跳都断了,你再次被推上赌桌,被迫做出一个决定是否接管服务。这个时候就是风险所在。当然早期的系统带有一种特殊的硬件机制,控制器可以控制彼此的电源(ipmi),如果决定对方宕机了,可以直接重启对方控制器的电源,即所谓一枪爆头。如果B实质上没有宕机,只是所有心跳都断了,A、B可能同时做决定杀死对方,谁的枪快谁赢,也有可能同归于尽。无论哪种情况,最多只有一个控制器接管服务,所以最坏情况是DU,而不是DL。从这里我们可以发现分布式系统中的一个原则:故障究竟是什么并不重要,重要的是大家一致认为故障是什么

    笔者经历过各种各样的双控系统,有些厂商连第二心跳都没有听说过,就敢于承载用户的生产数据,典型的放飞自我。很多科研院所和超算中心采用的分布式文件系统是开源的Lustre系统。Lustre不通过多副本确保可靠性,它采用的是给对象服务(OST)做双控。Lustre通常采用ZFS文件系统作为单机存储后端,控制器接管的是一个存储池(storage pool)。一旦双控失效,整个池就会毁掉。极道曾经多次友情赞助用户们恢复这类数据丢失。非专业用户要在生产环境用好Lustre,首先要有技术储备,其次得保持好运气。

    4. 分布式系统的容错

    从传统存储系统到现代的分布式系统,硬件变强,规模变大,容错却变难了。分布式计算本质上是多个节点上运行的多个进程通过消息交换协作解决一个问题。在后续部分我们统一称呼物理机器为“节点”,机器上运行的目标程序为“服务”或者“进程”。由于故障的普遍存在,一个可用的分布式系统都需要在故障发生的情况下仍然完成计算任务。与单机计算不同,容错是分布式计算的标准配置。

    4.1 书本上的理论有什么用?

    分布式系统的容错有丰富的理论和算法。有人也许会问“理论有什么用?”。理论的用处在于确定系统设计的极限是什么,指导你进行系统设计。它可以帮助你一眼看穿对方在吹牛,或者告诉你牛应该吹到什么程度为止。我们常见到一些学术论文上证明一些简单的分布式算法的正确性,觉得多此一举。其实分布式算法的难点在于其故障情况下的正确性。多机交互的时候如果出现故障,加上分布式系统运行固有的异步性,会演化出异常复杂的行为,超出人的直觉。算法必须保证在任何允许行为下的正确性。这个允许指的是故障模型,即算法正确的假定前提。

    故障情况下的算法正确性是很困难但是常被工程师们忽视的问题。Google工程师们请教Lamport,在Chubby中首次实现了PAXOS算法,是因为工程师们自己撸不出一个可以工作然后测试通过的算法吗?PAXOS是一个被理论证明正确的算法,以此为基础才能建立可靠的分布式系统。后来Stanford的大牛提出RAFT算法,实现成ETCD,其中一个目标是改进PAXOS的模块化程度和可理解性。这从一个侧面反映了分布式算法的复杂性。

    4.2 我们的故障有多良性?

    如果革命的首要问题是分清朋友和敌人,安全的首要问题是弄清楚攻击模型,那容错的首要问题是弄清楚故障模型。故障模型描述我们容忍什么样的故障,不容忍什么样的故障,也就是我们的算法假定的前提是什么。自从冯诺依曼将计算模型数学化之后,计算机算法本质上是数学的应用,所以任何计算机系统算法的正确性和效率都有一个前提。没有前提,无所不能的计算机算法只存在于我们的微信朋友圈。

    最简单也是最良性的故障类型是停止故障(fail-stop),指的是目标机器、服务、进程或者某个子系统一旦故障即停止运行。在不考虑通信故障和延迟的情况下,它意味着心跳断等同于服务挂掉,在很大程度上可以简化故障处理。但是在实际运行场景中,只有少数几种情况例如操作系统内核崩溃(panic)、进程coredump等属于这种情况。很多高质量的程序会要求服务自己模拟这种故障行为,即一旦检测到状态异常即主动停止运行。例如监控ETCD进行选举的服务在无法连接ETCD的时候直接退出,可以避免其子系统在领导改选(Leader切换)的暧昧期干坏事。笔者以前在某世界存储巨头工作时,看到大量的代码检查状态不正确就主动panic掉。当时笔者想这么关键的系统为什么要死的这么草率?殊不知第一时间避免故障传递、演变成灾难才是一个负责任的做法。不成功则成仁,在良性的分布式系统中,程序自检和自杀体现了一种社会责任

    最恶性的故障是拜占庭故障,它指的是目标可以表现任意的行为,包括但不限于故障停止、发送错误消息、计算出错、状态任意变化等等。大家可能会说,计算机都是程序行为,会这么变态吗?笔者的经验告诉大家,实际中大多数都是拜占庭故障。只有你想不到的,没有程序干不出来的。不同意的同志们想想你解决一个bug有多难。在理论上常可以把拜占庭故障理解为系统的一个对手(adversary),也就是把这个故障定义为导致你的程序运行出错的那个故障。Dijkstra说过,你永远无法证明你的程序是正确的。可见对手无处不在。

    另一类重要的故障是通信故障(以下通信故障与网络故障交替使用,代表同样的含义)。网络故障的典型情况是消息丢失,这在实际中尤其是高负载场景下是普遍存在的。通信故障是很多难题在理论上无解的重要原因。通信故障常通过消息重传,或者重试来解决。有人可能会问:“我使用TCP协议不是足够解决通信故障了吗?” 答案是否。因为TCP协议只保证你的数据包可靠传输到对方的TCP缓存,不表示你的消息被对端的应用程序正确处理了。

    4.3 我们的步调有多一致?

    容错除了和故障模型有关外,还和系统同步(synchronous)或者异步(asynchronous)特性有关系。所谓异步,指的是系统各节点间运行速率差异和消息传输延迟没有上限,包括但是不限于消息传输可以任意慢,节点之间的时钟可以任意漂移。反之,系统就是同步的。我们经常采用的心跳超时来判断故障的机制只有在同步的系统中才有意义。对一个异步的系统采用超时机制,基本属于耍流氓,超时在任何情况下都可能发生,程序不能根据超时事件做出任何正确的判断,系统可能来回震荡,无法收敛。

    那么实际中的系统是同步还是异步呢?笔者认为在计算密集型或者数据密集型的场景中,系统是异步或者半异步的。首先,由于网络丢包、负载不确定、系统资源很难做性能隔离(所谓的服务质量Qos保证),消息延迟变化范围很大。其次,最大延迟的上限可能存在,但是不能事先知道。这种情况就是程序猿们常常要调整的各种超时参数。第三,最大延迟最终可以确定,但是在性能上不能忍受,因为以此为基础的服务故障恢复时间不能满足业务需求。第二、三种情况就是所谓的半异步

    由于实际系统中大量依赖心跳超时检测故障,半异步也影响故障检测器的可靠程度。这个问题后续详细讨论。

    4.4 费多大劲可以排个顺序?

    分布式系统的一个重要问题是给系统中各个节点之间发生的事件排序。这里的顺序指的是所有节点一致认定的全局顺序。为什么要讨论这个问题呢?因为这在单机系统是一个简单问题,在分布式系统中(考虑故障)是个超级难题。单机系统中,多个事件可以通过互斥机制在小临界区串行或者分配序号获得全局顺序,虽然也是相对的效率瓶颈,但一般可以接受,也有很多优化选项。在分布式系统中,多台机器之间需要通过消息传递来确定事件的全局序,通信延迟造成的性能损失相对较大,而且分布式系统中的故障概率高,进一步加剧了问题的难度。

    为什么要给事件排序呢?因为这和维护分布式系统各节点的数据副本状态一致常用方法状态机方法有关系。假设多个节点维护同一份数据的多个副本用于容错,如果系统能够确保所有关于该数据的操作以同样的顺序应用在所有副本上,那么副本的最终状态必然一致。有一点提请同志们注意的是,状态机方法保证的是最终一致性,它不能保证任意时刻各个副本状态是一致的。这是因为不同节点应用更新操作的延迟,以及操作耗费的执行时间都有差异。除非阻塞住后续操作,等待本次操作同步应用到所有副本,否则同时一致不再有意义。在分布式系统中,阻塞的代价非常大,所以一般都选择放弃同时。最终一致性的“最终”有没有时间上限呢?同步系统中,节点间的执行速率差异和消息延迟存在上限,因此各个副本达到同样状态的时间差异也有上限。在异步系统中,原则上不存在这个上限。

    看到这里,有的同志会说,这个排序不是很简单吗?把所有操作发给一个节点(协调者),排序好后再发给其它节点不就可以了吗?是的,这是实际中可用的好办法。但是同志们别忘了,所有的分布式系统都是要容错的,因为只要规模足够大,或者时间足够长,故障是一定会发生的。首先排序的节点可能宕机。宕机是良性故障,稍微恶性一点的是协调者将排序结果发送给部分节点后挂掉了,即便选出新的协调者还需要进行一个恢复过程,重新同步副本状态。所以说问题难就难在各种故障发生的情况下仍然保证全局一致的顺序。这些故障包括但是不限于节点(拜占庭)故障、消息丢失(不同的节点收到不同的消息)、消息损坏等等。

    闻名遐迩的PAXOS算法在实际中的一个直接应用就是在分布式系统中维护一个全局一致的日志(从而维护了一个多个副本但是全局最终一致的数据库),其本质就是决定这个日志的多个副本以什么顺序应用数据操作,即决定发生在不同节点的多个操作在日志中的顺序。这是一个典型的分布式事件的排序问题。

    4.5 我们可能达成一致吗?

    一致性问题(consensus)是分布式理论中最基础的问题。我们费点心思来看看它的定义。

    系统中每个节点提出一个值,通过消息交互最终所有节点决定出同一个值,要求如下:

    1. 所有正确的节点最终总能够决定一个值(termination)

    2. 所有正确的节点决定的值必须相同(agreement)

    3. 所有正确的节点决定的值必须是被正确的节点提出来的(validity)

    看到这个定义,聪明的同志会说,这个也很简单啊,实现一个广播操作,负责给每个节点发送消息,确保所有正确的节点要么都收到某个消息要么都收不到某个消息,且所有正确节点发送的消息其它正确节点都会收到。这样每个节点把自己的提议值发给所以其它节点,最后所有节点收到的消息集合是一样的,用统一的规则计算这个消息集合必然得到同样的值。这位聪明的同志提出的这个广播操作叫做原子广播(atomic broadcast)。理论证明,原子广播和一致性问题是等价的。这句黑话的意思是说,你一旦有了consensus或者atomic broadcast其中任意一个问题的算法,简单处理就能够解决另一个问题。所以不要随随便便把难题甩给做基础服务的兄弟,它不一定能真正简化问题的解决。

    关于一致性问题有很多理论结果。理论证明,允许通信故障的系统一致性问题无解。可见沟通有多重要:)。我们的Lamport(PAXOS算法的提出者,图灵奖获得者)先生证明了同步系统中,即便在拜占庭故障假设下,仍然存在一致性问题的算法,但是要求3N+1个节点最多只有N个节点故障。悲剧的事一致性问题在异步系统中无解。不存在证明的核心技巧与通信故障情况下类似,关键的观察是基于消息传递的系统中任意节点不可能在异步系统中区分一个无限慢的消息和一个丢失的消息。假定算法存在,而算法要求有限时间的终止,因此算法的正确性绝不能依赖这个消息。这样算法在每个节点都不能依赖每次执行情况下的最后一条消息。这是因为算法的执行历史对所有其它节点都一样,只对无限慢消息的接收者不一样。最后一步一步规约到算法的正确性不能依赖任意一条消息。这样与有效性要求(validity)矛盾。有效性要求本质上规定有效的算法必须基于正确节点的建议值,因此必须是沟通后的结果。沟通万岁!

    上面这段很难理解的证明思路,说的是一个分布式系统中常见的问题,笔者称之为最后一条消息魔咒。如果假定网络不可靠,最后一条消息是否收到是无法被发送者确认的,即便消息并没有丢失。这意味着计算结果绝不能依赖最后一条消息的可靠性。一般的系统实现中,节点通过发送ack向发送者确认消息收到并处理了,如果网络不可靠,怎么知道接收者发送的ack是否丢失呢?我们看看下面的例子。

    图片

    Bob和Alice约会之所以泡汤是因为在一个通信故障的假定下追求共识(common knowledge)。所谓共识,就是要建立如下的逻辑条件:

    Bob知道 && Alice知道 && Bob知道“Alice知道” && Alice知道“Bob知道” &&

    Bob知道“Alice知道Bob知道” && Alice知道“Bob知道Alice知道” ...

    其中每一层次的知道对应于一个ack,所以要建立共识需要无限多次的ack。同志们需要注意的是这个例子中消息是否丢失并不重要,只要假定消息可能丢失,共识的正确性就要求无限多次确认,因此算法无法终止。那实际可行的约会方案是什么样的呢?

    Bob告诉Alice:“晚上六点电影院见,不来请回复,我将等到六点半”。# 请求

    如果Alice愿意,就回复行,不愿意就回复不行。# 反向确认(Negative Ack)

    Bob六点到达电影院,等到六点半,如果Alice不赴约就离开。# 超时(Timeout),解决Negative Ack

    这个方案中超时是算法终止的关键因素,反向确认(Negative Ack)只是优化性能(避免Bob傻等)。同志们现在可以理解TCP协议状态机中最后得有个Timed-Wait了吧,因为Ack的方法总得有个终止,最后必然依赖一个超时。

    理论证明,在异步系统中,如果存在通信故障,consensuscommon knowledge都不可能达成。同志们也许会问区块链为什么可以达成共识呢?区块链是基于零知识证明(zero knowledge proof)系统达成的近似共识,是概率性的。很多区块链方案中为了防止有人伪造全局账本,所有人必须不停的计算,避免有人拥有绝对算力,无论坏人是否存在。这是典型的内卷。

    4.6 现实中如何达成一致?

    既然理论证明,在异步系统中或者存在通信故障的场景下,不存在解决consensus问题的算法。但是一致性问题是一个必须解决的问题,那该怎么办呢?有些研究人员提出了基于故障检测器(failure detector)的方法。故障检测器作为系统中的一个模块,回答“这个节点或者进程有没有故障?”这类的问题。运行一致性算法的系统通过与故障检测器交互,最终达成一致。故障检测器被假定是不可靠的,即它可能犯错误。故障检测器通过下面的两个关键属性刻画:

    完备性(completeness):故障进程最终被检测为故障。

    准确性(Accuracy):正确的进程不会被认为故障。

    这两个属性描述了故障检测器的犯错误的类型和程度。可以定义多种类型的完备性和精确性。故障检测器是一个理论工具,它可以帮助阐明在什么样的完备性准确性条件下,系统可以达成一致,或者什么样的故障检测器有助于提高系统的一致性。如果有兴趣的同志研究一致性的算法,就会发现一致性的获得依赖没有故障的节点收集到一致的信息。换句话说,一致性来源于多轮次消息交换后各节点收集到的信息的一致性。如果故障检测器可以提升一致性,那一致性必然来源于故障检测器提供的某种一致性。例如:

    弱准确性(weak accuracy):存在一个正确的进程,从不会被其它正确的进程检测为故障。

    最终弱准确性(eventual weak accuracy):在足够长的时间之后,存在一个进程,不会被其它进程检测为故障。

    同志们一眼就可以看出,弱准确性或者最终弱准确性决定了系统(经过足够长的时间之后)可能找到一个可靠的进程作为协调者(coordinator)或者领导者(leader),算法可以依赖这个协调者达成一致。

    故障检测器是一个理论工具,在实际系统中有很多对应。例如某些版本的PAXOS算法依赖选举一个Leader,但是不要求其唯一性,有些版本则不需要这个Leader存在。但是算法的成功终止(Termination)等价于存在一个协调者,不会被大多数参与者(Quorum)认为故障,以完成多数表决。否则,算法虽然不会给出不一致性的结果,但是会持续震荡,无法收敛。

    4.7 CAP定理如何决定系统设计?

    很多同志可能知道所谓的CAP定理,它由加州大学的计算机科学家Eric Brewer在1998年提出来:

    分布式系统中,一致性(Consistency)、可用性(Availability)和分区容忍(Partition Tolerance)三个指标不可能同时达到。

    一致性(C)和可用性(A)大家已经熟悉了,分区(Partition)指的是什么呢?举个例子来说明,系统中存在A、B、C、D和E五个节点,A、B、C互相可以通信,D和E互相可以通信,但是A、B、C和D、E互相无法通信,这种情况就叫网络分区(Network Partition)。如果分布式系统涉及到分离很远的两个站点或者数据中心,例如A、B和C在北京,D和E在纽约,那么分区问题是个常见情况。这个容易理解。即便在同一个数据中心内,分区也是很普遍的情况。我们在设计系统的时候,通常假定分区必然存在,因此必须在一致性和可用性上做权衡。CAP定理决定了在故障发生的时候我们可能需要牺牲其中一个指标以换取另个指标。不同的系统根据实际情况需要做出不同的选择。

    存储和关键数据系统要求绝对的一致性,只能牺牲可用性。分布式存储系统牺牲可用性是什么意思呢?其实就是在一致性达成的过程中阻塞住客户端的操作,暂时把请求服务的程序Hang住。不好意思,我们再次回到了Hang这个问题:)

    当然也有系统做相反的选择。AmazonS3明确说明不保证读写一致性。之前听Amazon的CTO的一个演讲,说他们的数据系统要保证总是可写(always writable)。为什么呢?因为客户要往购物车中放东西,你必须让他的操作成功,不能跟钱有仇啊。所以选择暂时牺牲一致性来获得可用性。当然某种程度的一致性是必须保证的,即所谓最终一致性。Amazon的很多系统采用客户端参与的冲突解决机制。例如A、B、C、D和E五个节点维护同一份数据拷贝,当A、B、C和D、E分区后,两个系统独立接受用户请求,当两个分区重新连接成为一个系统,需要恢复全局一致的状态,这个时候必须解决独立运行时的冲突操作。这个过程中可能需要应用系统参与解决冲突,选择一个最终的版本。这在很多场景下是合理的。例如你在购物的时候,不间断向购物车中添加或删除商品,这个时候数据是否一致是无关紧要的。只有当付款的那一刻,你才需要确认购物清单是什么。这个时候系统可以给出两种结果,由用户选择或者编辑。这就是客户端参与解决冲突的典型例子。

    大多数系统倾向于保证一致性,因为强一致性对客户端更友好,更容易编程。最终一致性实质上是将某些确保一致性的职责交给客户端负责,以换取可用性或者性能。很多分布式系统采用所谓Quorum机制:

    假设任意一个写操作必须完成的副本数为w,任意一个读操作必须读取的副本数为r,则w+r>N。

    上述的Quorum条件w + r >= N实质上要求任意一个读和写操作必须至少有一个共同的副本共同的副本承担了确保读写一致性的指责。至于怎么选择wr取决于你的系统优化的是读还是写操作的可用性。假设你选择了w=1r=N,意味着系统分区的时候任意分区都可以写,但是读操作需要从所有节点读取(其实就是要求读操作解决冲突)。

    经典的PAXOS协议要求协调者必须获得多数(Majority)投票,否则不能达成一致。多数投票决定了任意两次协议运行之间必然有一个公共节点,确保前后表决的一致性。这意味着如果故障检测机制不能在某一刻形成一个正确多数,则一致性永远不能达成,协议无法终止,即失去可用性。因为PAXOS协议的目的是获得一致性,这个选择是顺理成章的。

    4.8 直接民主还是民主集中?

    实际中在构建分布式系统的时候,开发者可以选择诸如PAXOSRAFT或者其它算法实现一致性。实现的时候通常有两种选择:无中心节点(decentralized)的方案或者ensemble的方案。前者类似于政治生活中的直接民主,后者则相当于民主集中制度。

    无中心节点的方案要求每个节点都参与一致性协议。它的好处是不依赖于任何节点的可用性,缺点是代价较大,每一次都需要超过半数的节点投票。当系统规模变大,系统故障变多,协议运行的代价变得难于接受。所谓ensemble方案指的是首先采用一致性算法解决一个小团体(ensemble)的一致性问题,这个ensemble维护多副本数据,对外提供同步服务(例如分布式锁、原子性的检查设置compare-and-swap等),帮助其它服务达成一致。Google三件套中的ChubbyHadoop系列的Zookeeper,以及后来的ETCD服务都是采用了类似的设计思想。

    基于ensemble的方案是一个折衷,它既避免了单点故障,又以较小的代价实现了一致性,且简化了一般分布式系统的开发人员的工作。它为整个系统提供了一致性的根。一种常见的多副本运行方式是所谓的领导者-跟随者模式(leader-follower)。其中数据的多个副本通过ensemble选举出一个leader,其它的则为followerleader对外提供读写服务,并将更新传递给其它的followerfollower同步状态,与leader保持一致。如果检测到leader故障,所有副本再次通过选举产生新的leader提供服务。

    结束语

    容错性是数据系统和计算系统非常重要的功能特性,它是系统开发区别于应用开发的一个显著方面。我们常说二八原则,即百分之二十的精力通常可以完成系统百分之八十的功能,剩下的百分之二十的功能往往需要百分之八十的精力。笔者认为容错性绝对在剩下的百分之二十的范畴内。它耗费的可不单是开发者的精力,也包括他们的健康。

    展开全文
  • 提供多种文件过滤方式,可以对要操作的文件进行选择性过滤或文件名模糊匹配过滤; 提供多种自动删除备份文件和日志的方法,做到既备份了有用的数据也不浪费存储空间; 任务可以关联执行,相关任务之间可以指定其...
  • 容错和错误处理 遗留(代码 | 系统) 模块化 慕课 多层应用 性能和调优 管道和过滤器 射频卡 语义版本控制 软件架构与组织结构同步 软件架构模式 技术债 时区 UML C4型号(西蒙布朗) 人的因素 360度反馈 建筑师支持...
  • 复式遗漏扫描软件,原来babylon扫描软件的改进版。对3d,5d类型的彩票进行1-5位扫描,并根据设定容错过滤生成结果
  • 第10章 软件体系结构的分析与测试 ;第10章 软件体系结构的分析与测试 ; 概述 ; 概述 ; 顺序结构风格 ; 顺序结构风格 ; 并行管道-过滤器结构风格 ; 并行管道-过滤器结构风格 ; 并行管道-过滤器结构风格 ; 容错结构...
  • 软件体系结构风格复习总结

    千次阅读 2022-02-22 15:31:47
    1、软件体系结构风格概述 软件体系结构风格是人们从大量实际的软件案例中提炼出来可以服用的架构层面解决的方案。 2、数据流风格 2.1原理与结构 数据流风格基本构件:处理 连接件:数据流 2.2、数据流风格子风格1:...

    1、软件体系结构风格概述

    软件体系结构风格是人们从大量实际的软件案例中提炼出来可以服用的架构层面解决的方案。

    2、数据流风格

    2.1原理与结构

    数据流风格基本构件:处理
    连接件:数据流

    在这里插入图片描述

    2.2、数据流风格子风格1:管道-过滤器风格

    构件:过滤器
    连接件:管道

    工作原理: 递增的读取和消费数据流,过滤器在处理数据的时候不是收集然后再处理,而是在输入被完全消费之前,输出就产生了。
    在这里插入图片描述

    特点: 高并发,实时性。
    例子:
    1、编译器:
    在这里插入图片描述2、Unix管道
    在这里插入图片描述

    2.3、数据流风格子风格2:批处理风格

    基本构件:独立的应用程序
    连接件:某种类型的介质
    特点:并发性差,延迟高

    工作原理: 每一步处理都是独立的并且每一步都是顺序执行,只有在前一步结束后才能开始下一步的处理并且数据必须是完整的,以整体的方式来传递。
    案例:
    基于Eclipse的代码重复检测工具
    在这里插入图片描述

    2.4、管道-过滤器与批处理的比较

    相似点: 两种子风格都把任务分解成一系列固定顺序的计算单元。彼此之间都只通过数据传递交互

    不同点: 管道-过滤器风格中数据是增量式传递,并且构件的粒度较小,具有实时性,高并发的特点;而批处理风格则是采用整体传递数据的方式,构建力度较大,相应带来了高延迟,并发性差。

    2.5、数据流风格的优缺点

    优点: 由于构件之间仅仅通过数据进行交互,使得构建具有良好的隐蔽性和高内聚低耦合的特点;
    并且只需要提供适合在两个过滤器之间传送的数据,任何两个过滤器都可以被连接起来,从而支持良好的软件复用性。
    新的过滤器也可以很方便的添加到现有系统中,替换旧的过滤器,系统维护和升级相对简单;
    每个过滤器负责完成一个单独的任务,因此可以与其他任务并行执行,另外还允许对一些比如吞吐量,死锁等特性的分析。

    缺点: 通常会导致系统进程成为批处理的结构,整体性能不高,不适合交互应用,由于每一个过滤器都成参加了解析和合成数据的工作,这样就导致了系统性能下降并且增强了编写过滤器的复杂性。

    3、过程调用风格

    3.1、主程序-子过程风格

    构件:主程序,子程序
    连接件:调用-返回机制
    拓扑结构:层次化结构

    本质:将大系统分解成为若干模块,主程序调用这些模块实现完整的系统功能。

    优点: 有效地将一个比较复杂的程序系统设计任务分解成许多简单的,易于控制和处理的子任务,便于开发和维护,已被证明是成功的设计方法,可以被用于较大程序
    缺点: 程序超过10万行的时候表现并不好,程序太大,开发太慢,测试也越来越困难。可重用性较差,难以开发大型软件和图形界面的应用软件。

    3.2、面向对象风格

    构件:类和对象
    连接件:对象之间通过功能与函数调用实现交互

    原理图:
    在这里插入图片描述
    优点: 一个对象对外隐藏了自己的信息,对象将数据与操作封装在了一起。
    缺点: 首先需要管理大量的对象,难以确定合适的结构,另外若要调用另外一个对象,就必须要知道它的名称,而且随着继承引起的复杂度,会产生连锁反应。

    与之形成对立的可以参考管道-过滤器风格,过滤器无需知道其他过滤器的任何信息

    4、独立构件风格

    4.1、进程通信体系结构风格

    构件:独立的进程
    连接件:消息传递

    典型案例: 客户-服务器架构,其中服务器通常用来为一个或多个客户端提供数据服务,客户端则用来向服务器发出请求,针对这些请求服务器通过同步或异步方式进行请求响应。

    4.2、基于事件的隐式调用风格

    构件:对象或者过程
    连接件:事件-过程绑定

    原理图:
    在这里插入图片描述
    特点: 事件的触发这并不知道那些构件会被这些事件影响到,相互保持独立,这样就不能假定构件的处理顺序,甚至不知道哪些过程会被调用,并且哥哥构建彼此之间没有连接关系,各自独立存在,通过对事件的发布和注册实现关联。

    典型案例:
    MVC
    在这里插入图片描述
    事件调度策略:当事件发生时,已经向此事件注册过的过程被激发并执行,那么事件管理器该如何向这些过程分发相关的事件?

    两种策略:
    1、没有独立派遣模块的事件管理器
    在没有独立派遣模块的事件系统中,每一个模块都被成为:被观察者/观察者,每一个模块都允许其他模块向自己所能发送的某些信息表明兴趣,党某一模块发出某一事件时,它自动将这些时间发布给哪些曾经向自己注册过此事件的模块。
    在这里插入图片描述
    2、带有独立派遣模块的事件管理器
    再有独立调度模块的时间系统中,事件派遣模块负责接收到来的事件并派遣它们到其它模块,但是派遣器怎么样派遣又存在两种策略
    一种是广播式:派遣模块将事件广播到所有的模块,但只有感兴趣的模块才去取事件并触发自身的行为;
    一种是选择广播式:派遣模块将事件送到那些已经注册了的模块中。
    选择广播式又有两种策略,点对点模式:基于消息队列,发布-订阅模式
    点对点模式: 系统会配置一个队列管理器,定义一个命名的消息队列,某个应用向消息队列注册,以监听并处理被放置在队列里的事件,其他的应用连接到该队列并向其中发布事件,队列管理器管理存储这些消息,直到接收端的应用连接到队列,取回这些消息并加以处理,
    注意: 消息只能够被唯一的消费者所消费,消费之后立即从队列中删除。
    在这里插入图片描述

    发布-订阅模式: 事件发布者向“主题”发布事件,订阅者向“主题”订阅事件
    • 一个事件可以被多个订阅者消费;
    • 事件在发送给订阅者之后,并不会马上从topic中删除,topic会在事件过期之后自动将其删除。
    在这里插入图片描述
    集成案例:股票交易市场
    在这里插入图片描述
    典型案例
    调试器
    在这里插入图片描述
    工作原理:其中编译器既是监听者又是处理者,先向调试器进行注册,表示对断点事件感兴趣,调试器一旦产生断点事件,断点事件就会被送到这三个已经表明兴趣的部分,然后文本编辑器会滚动屏幕到断点处,变量监视器会刷新变量的当前值,编译器会启动编译

    事件系统优点: 能够很好地支持交互式系统,系统中的操作可以异步执行,不必同步等待执行结果,为软件复用提供了强大的支持,当需要将一个构件加入现存系统中时,只需要将它注册到系统的事件中,为系统的动态演化带来了方便,构件独立存在,当用一个构件代替另一个构件时,不会影响到其他构建的接口,对事件的并发处理将提高系统性能,另外,系统的健壮性也很好,一个构件出错不会影响其他构件。

    缺点: 分布式的控制方式使得系统的同步、验证和调试变得异常困难。
    构件放弃了对系统计算的控制。一个构件触发一个事件时,不能确定其他构件是否会影响它。而且即使它知道事件注册了哪些构件的构成,它也不能保证这些过程被调用的顺序。
    既然过程的语义必须依赖于被触发事件的上下文约束,关于正确性的推理存在问题。

    5、层次风格

    构件:各层次内部包含的构件
    连接件:层间的交互协议

    拓扑结构:分层
    拓扑约束:对相邻层间交互的约束
    规则:一般来说,一个子层只能与相邻的层进行交互,不能跨层交互。

    分层风格与主程序-子过程风格的不同:
    主程序-子过程风格 中的各个层次模块的功能具有同样的类型,主程序可以调用子程序,但是不能逆向调用,子程序只能通过上层转移来获得子子程序控制权。
    分层风格 中各层模块具有不同类型的功能,各层模块之间存在回调的情况,上层模块调用下层模块不需要上上层模块赋予控制权

    5.1、分层模式

    严格分层/松散分层
    严格分层: 严格分层系统要求严格遵循分层原则,限制一层中的构件只能与对等实体以及与它紧邻的下面一层进行交互。
    在这里插入图片描述
    严格分层优点:修改时相对简单
    缺点:效率低

    松散分层: 松散的分层应用程序放宽了此限制,它允许构件与位于它下面的任意层中的组件进行交互(注意:交互的方向依旧未变)
    在这里插入图片描述
    优点: 松散方法可以改善效率,因为系统不必将简单调用从一层转发到下一层。
    缺点: 松散方法在层之间不提供相同的隔离级别,这使得在不影响较高层的情况下换出较低层变得更困难。

    逻辑分层/物理分层
    逻辑分层: 把软件中的相关工嗯呢该和组件分成独立的逻辑分组,一般是将一组相互协作的组件分组成逻辑层,每一个逻辑层都包含许多独立的组件类型并可以分组成子层,每一个子层执行特定类型的任务。
    常见的逻辑分层:
    在这里插入图片描述
    物理分层:物理层描述的却是如何把功能和组件从物理上部署到独立服务器、计算机、网络或远程位置。
    一般情况下,一个独立运行的服务器就是一个物理层。也有几个服务器组成一个层的情况,如集群服务器就可看作是同一个层。

    逻辑层和物理层之间的映射存在如下三种情况:
    1对1,即一个逻辑层运行在一个物理层;
    1对多,即一个逻辑层运行在多个物理层;
    多对1,多个逻辑层运行在一个物理层。

    案例: 一个简单的用户信息查询程序三层逻辑架构
    在这里插入图片描述
    关于逻辑层与物理层的对应关系,目前逻辑分层是三层:表示层,业务逻辑层,数据访问层。若调用三台电脑分别运行以上三层,则物理分层也为三层,逻辑分层:物理分层=1:1

    其余几个案例也可以适当的记一下:
    DBMS中的“三级模式-两层映像”,
    ISO/OSI网络分层模型:
    在这里插入图片描述

    5.2、层次风格优缺点

    优点:
    抽象。 层次风格把系统当作一个抽象整体来看的同时,提供了足够的细节来理解每一层的角色和职责以及层之间的关系。分层使设计者可以把一个复杂系统按自上而下抽象程度递增的步骤进行分解。
    隔离。 不需要在设计阶段作有关数据类型、方法、属性和实现的假设,因为这些特性不会跨越层边界暴露。可以对单独的层进行技术升级,通过封装可以减少风险并且使得对整个系统的影响减少到最低程度。
    可扩展性。 层次系统每一层最多和上下两层交互,对任一层功能的改变,最多只影响其他两层。
    可管理性。核心关注点的分离有助于找到依赖,并将代码组织得更加易于管理。
    性能。通过把逻辑层分布到多个物理层中,可以提高可伸缩性、容错性(fault tolerance)和性能。
    可重用性。每一层提供的功能都是独立的和定义良好的。不同层之间有明确的接口,在解决一个新的问题时,使开发人员更容易地重用一个已有的层。
    可测试性。由于有了明确定义的接口,以及可以在层接口的不同实现之间实现按需切换,可测试性明显增强了。
    标准化。清晰定义并且广泛接受的抽象层次能够促进实现标准化的任务和接口开发,同样接口的不同实现能够互换使用。
    缺点:
    并不是每个系统都可以很容易地划分为分层的模式,甚至即使一个系统的逻辑结构是层次化的,出于对系统性能的考虑,系统设计师不得不把一些低级或高级的功能综合起来;
    效率的降低:
    由分层风格构成的系统,运行效率往往低于整体结构。
    在上层中的服务如果有很多依赖于最底层,则相关的数据必须通过一些中间层的若干次转化,才能传到;
    很难找到合适的、正确的层次抽象方法:
    层数太少,分层不能完全发挥这种风格的可复用性、可修改性和可移植性上的潜力。
    层数过多,则引入不必要的复杂性和层间隔离冗余以及层间传输开销。

    6、虚拟机风格

    注意,虚拟机风格又是也称为解释器风格,解释器系统的核心也是虚拟机。

    构件:虚拟机风格包括三个被动数据组件和一个主动组件,他们分别是被解释执行的程序,用于保存程序当前执行状态的数据组件,用于保存当前解释引擎状态的组件,以及虚拟机解释器引擎。也可以记作:存储区和解释引擎。
    连接件:过程调用和直接存储访问。

    6.1、解释器风格

    从功能角度划分,解释器通常由微程序和解释器引擎和存储区,从基本构建角度看,包括模拟解释引擎和存储器
    解释器风格的连接可以看做对存储区的数据访问。
    解释器有三种策略:传统解释器(纯粹的解释执行),基于字节码的解释器(先编译后解释执行),JIT编译器(西安部分编译后解释执行)

    传统解释器:
    在这里插入图片描述
    基于字节码的解释器
    在该类解释器下,源代码首先被“编译”为高度压缩和优化的字节码,但并不是真正的机器目标代码,因而与硬件平台无关;
    编译后得到的字节码然后被解释器加以解释
    在这里插入图片描述
    JIT解释器
    在运行时,JIT会把翻译过来的机器码保存起来,以备下次使用。但是JIT只会对经常执行的字节码进行编译。如循环,高频度使用的方法等,它会以整个方法为单位,一次性将整个方法的字节码编译为本地机器码,然后直接运行编译后的机器码。
    在这里插入图片描述

    6.2、基于规则的系统

    在这里插入图片描述

    构件:工作存储区,知识库,规则解释器,规则与数据元素选择器。
    连接件:对存储区的数据访问。

    核心思想:将业务逻辑中可能频繁发生变化的代码从源代码中分离出来
    优点: 降低了修改业务逻辑的成本,缩短了开发时间,将规则外部化,可在多个应用之间共享,对规则的改变将非常迅速并且具有较低的风险

    6.3、二者的不同

    解释器风格:在高级语言程序源代码和OS/硬件平台之间建立虚拟机环境;
    基于规则的系统:在自然语言/XML的规则和高级语言的程序源代码之间建立虚拟机环境。

    7、客户机/服务器风格

    在这里插入图片描述
    构件:客户机软件和服务器软件
    连接件:一系列网络协议

    在这里插入图片描述

    7.1、胖瘦客户端

    胖客户端:客户端执行大部分的数据处理操作
    特点:
    较低的服务器需求。与瘦客户端对应的服务器相比,胖客户端对应的服务器不需要达到同样高的性能(因为胖客户端自己就可以完成很多业务处理)。因此,可以使用非常便宜的服务器。
    离线工作。胖客户端通常不需要和服务器之间维持长久的连接。
    更好的多媒体性能。在网络带宽比较敏感的时候,胖客户端更擅长运行丰富的多媒体应用,例如,胖客户端非常适合于电子游戏。
    更灵活。在某些个人电脑的操作系统上,软件产品都有它们自己的本地资源。在瘦客户端环境运行这类软件可能比较困难。
    充分利用已有设备资源。现在很多人都拥有非常快速的个人电脑,他们已经不需要额外的花费就可以运行胖客户端软件了。
    更高的服务器容量。客户端执行的工作越多,服务器所需要的工作就越少,这可以增加服务器支持的用户数量。

    瘦客户端:客户端具有很少或没有业务逻辑
    特点:
    单点故障。服务器承担了大部分的业务处理,安全问题主要集中于服务器,易于维护,但服务器一旦崩溃,所有数据都会丢失。
    廉价的客户端硬件。对客户端硬件的内存、硬盘容量以及CPU等要求不高,这也降低了客户端的功耗。
    有限的显示性能。瘦客户端往往使用简单的直线、曲线和文字来优化显示性能,或通过缓存的位图数据来进行显示,很难支持复杂的交互式图形操作。

    7.2、两层C/S结构

    在这里插入图片描述

    构件:数据库服务器,客户机应用程序
    连接件:经由网络的调用返回机制或者事件机制

    优点: 适合于轻量级事务,当业务逻辑较少变化以及用户数少于100时,两层C/S架构的性能较好
    缺点:系统伸缩性差:当用户数超过100,性能急剧恶化,互操作性差:使用DBMS所提供的私有的数据编程语言来开发业务逻辑,降低了DBMS选择的灵活性,系统管理与配置成本高:当系统升级时,每个客户端都需要随之改变

    7.3、三层C/S结构

    在这里插入图片描述
    优点: 在用户数目较多的情况下,三层C/S结构将极大改善性能与灵活性(通常可支持数百个甚至更多用户);允许合理地划分三层结构的功能,使之在逻辑上保持
    相对独立性,能提高系统和软件的可维护性和可扩展性;UI、BL、DB可以分别加以复用
    允许更灵活有效地选用相应的平台和硬件系统,并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
    应用的各层可以并行开发,可以选择各自最适合的开发平台和开发语言。
    利用功能层有效地隔离开表示层与数据层,未授权的用户难以绕过功能层而非法的访问数据层,为严格的安全管理奠定了坚实的基础。
    将遗留系统移植到三层C/S下将非常容易;

    缺点:三层C/S结构各层间的通信效率若不高,即使分配给各层的硬件能力很强,其作为整体来说也达不到所要求的性能。
    设计时必须慎重考虑三层间的通信方法、通信频度及数据量,这和提高各层的独立性一样是三层C/S结构的关键问题。——分层风格的固有缺点

    7.4、B/S模式

    在这里插入图片描述

    浏览器/服务器(B/S)是三层C/S风格的一种实现方式
    优点: 基于B/S体系结构的软件,系统安装、修改和维护全在服务器端解决,系统维护成本低:
    • 客户端无任何业务逻辑,用户在使用系统时,仅仅需要一个浏览器就可运行全部的模块,真正达到了“零客户端”的功能,很容易在运行时自动升级。
    • 良好的灵活性和可扩展性:对于环境和应用条件经常变动的情况,只要对业务逻辑层实施相应的改变,就能够达到目的。
    • 较好的安全性:在这种结构中,客户应用程序不能直接访问数据,应用服务器不仅可控制哪些数据被改变和被访问,而且还可控制数据的改变和访问方式 。
    • 三层模式成为真正意义上的“瘦客户端”,从而具备了很高的稳定性、延展性和执行效率。
    • 三层模式可以将服务集中在一起管理,统一服务于户端,从而具备了良好的容错能力和负载平衡能力。

    缺点:客户端浏览器一般情况下以同步的请求/响应模式交换数据,每请求一次服务器就要刷新一次页面;
    • 受HTTP协议“基于文本的数据交换”的限制,在数据查询等响应速度上,要远远低于C/S体系结构;
    • 数据提交一般以页面为单位,数据的动态交互性不强,不利于在线事务处理(OLTP)应用;
    • 受限于HTML的表达能力,难以支持复杂GUI (如报表等)

    展开全文
  • 2021年软件测试面试题大全

    万次阅读 多人点赞 2020-11-30 15:16:59
    目录 一、面试基础题 简述测试流程: 什么是软件测试?软件测试的目的与原则 问:软件生存周期及其模型是什么? 什么是软件质量? 自动化测试脚本开发的主要步骤: 目前主要的测试用例设计方法是什么? 常见的测试用例...

    目录

     

    一、面试基础题

    简述测试流程:

    什么是软件测试?软件测试的目的与原则

    问:软件生存周期及其模型是什么?

    什么是软件质量?

    自动化测试脚本开发的主要步骤:

    目前主要的测试用例设计方法是什么?

    常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

    测试的策略有哪些?

    单元测试的策略有哪些?

    正交表测试用例设计方法的特点是什么?

    软件的安全性应从哪几个方面去测试?

    需求测试的注意事项有哪些?

    问:你在测试中发现了一个  bug ,但是开发经理认为这不是一个  bug ,你应该怎样解决。

    问:给你一个网站,你如何测试?

    问:一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压,有什么区别? ?

    软件的安全性应从哪几个方面 去测试?

    软件质量保证体系是什么 国家标准中与质量保证管理相关的几个标准是什么? ? 他们的编号和全称是什么? ?

    测试人员在软件开发过程中的任务是什么?

    在您以往的工作中,一条软件缺陷(或者叫 Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    黑盒测试和白盒测试是软件测试的两种基本方法,请分别说明各自的优点和缺点!

    什么是系统瓶颈?

    手机APP测试

    什么是并发?在lordrunner中,如何进行并发的测试?集合点失败了会怎么样?

    详细的描述一个测试活动完整的过程。

    在您以往的工作中,一条软件缺陷(或者叫  Bug )记录都包含了哪些内容?如何提交高质量的软件缺陷( Bug )记录?

     您认为在测试人员同开发人员的沟通过程中,如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员 良好的人际关系的关键是什么?

    软件测试项目从什么时候开始?为什么?

    测试结束的标准是什么?

    您是否了解以往所工作的企业的软件开发过程?如果了解,请试述一个完整的开发过程需要完成哪些工作?分别由哪些不同的角色来完成这些工作?您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?

    请你回答一下性能测试有哪些指标,对一个登录功能做性能测试,有哪些指标,怎么测出可同时处理的最大请求数量

    什么是兼容型测试?兼容性测试侧重哪些方面?

    软件测试项目从什么时候开始,?为什么?

     

    二、测试实战面试题

    我现在有个程序,发现在Windows上运行的很慢,怎么判别是程序存在问题还是软硬件系统存在问题

    一个程序有n个变量采用边界值分析可以产生几个测试用例

    请设计一个关于ATM自动取款机的测试用例。

    如何测试一个 纸杯?

    我手上这支笔,请你根据这支笔设计测试用例

    测试手机开机键 

    如何回答登录功能怎么进行测试?

    如何回答京东购物车功能怎么进行测试?

    支付流程测试

    对于有系统大量并发访问,你会如何做测试,有什么建议

    请对这个系统做出测试用例:一个系统,多个摄像头,抓拍车牌,识别车牌,上传网上,网上展示

    请你说一说PC网络故障,以及如何排除障碍

    微信红包

    微信发朋友圈点赞

    如何对淘宝搜索框进行测试

    就linux下的CP命令设计测试用例。

    请问如果用户点击微博的关注图标但是app上面没有反应,应该怎么排查这个问题

    现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:

     

    三、基础知识点

    什么是桩模块?什么是驱动模块?

    什么是扇入?什么是扇出?

    8020原则:在需求分析开始到集成测试阶段引入测试手段,能发现所有缺陷的80%,系统测试阶段发现16%,在运行维护阶段经过长时间大量运行软件后,能够发现4%。起源于经济学。

    什么是耦合?什么是内聚?

    缺陷严重程度:

    缺陷优先级:

    缺陷状态:

    简单的软件缺陷生命周期:

    复杂的软件缺陷生命周期:

    什么是在线用户数?什么是并发用户数?

    分布式软件架构分为:

    测试人员的能力:

    简述负载测试与压力测试的区别。

    软件缺陷管理工具有哪些

    弱网测试

     

    四、智力题


    一、面试基础题

    简述测试流程:

    • 1、阅读相关技术文档(如产品PRD、UI设计、产品流程图等)。
    • 2、参加需求评审会议。
    • 3、根据最终确定的需求文档编写测试计划。
    • 4、编写测试用例(等价类划分法、边界值分析法等)。
    • 5、用例评审(主要参与人员:开发、测试、产品、测试leader)。
    • 6、开发提交代码至SVN或者GIT ,配管搭建测试环境。
    • 7、执行测试用例,记录发现的问题。
    • 8、验证bug与回归测试。
    • 9、编写测试报告。
    • 10、产品上线。

    补充测试用例设计过程:
    
    根据需求得出测试需求
    
    设计测试方案,评审测试方案
    
    方案评审通过后,设计测试用例,再对测试用例进行评审

     

    什么是软件测试?软件测试的目的与原则

    使用人工或自动手段,来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

    软件测试的目的:

    • 测试是程序的执行过程,目的在于发现错误。
    • 一个成功的测试用例在于发现至今未发现的错误。
    • 一个成功的测试是发现了至今未发现的错误的测试。
    • 确保产品完成了它所承诺或公布的功能,并且用户可以访问到的功能都有明确的书面说明。
    • 确保产品满足性能和效率的要求。
    • 确保产品是健壮的和适应用户环境的。

     

    问:软件生存周期及其模型是什么?

    软件生存周期是软件开发全部过程、活动和任务的结构框架,是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。在经历需求、分析、设计、实现、部署后,软件将被使用并进入维护阶段,直到最后由于缺少维护费用而逐渐消亡。这样的一个过程,称为"生命周期模型"(Life Cycle Model)。

     

    什么是软件质量?

    软件质量:软件产品的特性可以满足用户的功能、性能需求的能力。

     

    自动化测试脚本开发的主要步骤:

    1、通过某些方式定位到我们要执行的对象、目标( Target)

    2、对这个对象进行什么操作(command)

    3、通过操作对定位到的元素赋值(value)

    4、添加断言操作

     

    目前主要的测试用例设计方法是什么?

    白盒测试:

    • 逻辑覆盖
    • 循环覆盖
    • 基本路径覆盖

    黑盒测试:

    • 边界值分析法
    • 等价类划分
    • 错误猜测法
    • 因果图法
    • 状态图法
    • 测试大纲法
    • 随机测试场景法

     

    常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

    1)等价类划分划分

    等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试。因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。

     

    2)边界值分析法

    边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设(面试题目:什么样的工作环境适合你&#from一个常见的软件测试面试题来自end#lt;结束)计测试用例,可以查出更多的错误。

     

    使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

     

    3)错误推测法

    基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。

    错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。例如,在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等,这些就是经验的总结。还有,输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

     

    4)因果图方法

    前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等。考虑输入条件之间的相互组合,可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图(逻辑模型)。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

     

    5)正交表分析法

    有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。

     

    6)场景分析方法

    指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。

     

    测试的策略有哪些?

    黑盒/白盒/灰盒,静态/动态,手工/自动,冒烟测试,回归测试,公测(Beta测试的策略)

    补充:公测是什么?还有没有其他的测试策略?测试策略和测试方法以及测试类型有什么区别?

    按测试 策略分类:
      1、静态与动态测试
      2、黑盒与白盒测试
      3、手工和自动测试
      4、冒烟测试
      5、回归测试;
      按测试阶段分类:单元测试、集成测试、系统测试;
      其他常见测试方法:1、功能测试 2、性能测试 3、压力测试 4、负载测试 5、易用性测试 6、安装测试 7、界面测试 8、配置测试 9、文档测试 10、兼容性测试 11、安全性测12、恢复测试

    α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha 测试不能由程序员或测试员完成。

    β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta 测试不能由程序员或测试员完成。

    回归测试(对软件的新版本测试时,重复执行上一个版本测试时的用例,是为了验证缺陷是否真正修复,确认修复后是否影响其它功能);

    冒烟测试:对新版本测试之前,先验证下软件的基本功能是否实现,是否具备可测性。

     

    单元测试的策略有哪些?

    逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析

     

    正交表测试用例设计方法的特点是什么?

    答:用最少的实验覆盖最多的操作,测试用例设计很少,效率高,但是很复杂;对于基本的验证功能,以及二次集成引起的缺陷,一般都能找出来;但是更深的缺陷,更复杂的缺陷,还是无能为力的;具体的环境下,正交表一般都很难做的。大多数,只在系统测试的时候使用此方法。

    补充:什么时候用系统测试,测试的每个阶段是什么,比如单元、集成、系统、公测,每个阶段需要什么技术,有什么要求

     

    软件的安全性应从哪几个方面去测试?

    • (1) 用户认证机制:如数据证书、智能卡、双重认证、安全电子交易协议
    • (2) 加密机制
    • (3) 安全防护策略:如安全日志、入侵检测、隔离防护、漏洞扫描
    • (4) 数据备份与恢复手段:存储设备、存储优化、存储保护、存储管理
    • (5) 防病毒系统

    软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

    用户认证安全的测试要考虑问题:

      • 明确区分系统中不同用户权限
      • 系统中会不会出现用户冲突
      • 系统会不会因用户的权限的改变造成混乱
      • 用户登陆密码是否是可见、可复制
      • 是否可以通过绝对途径登陆系统(拷贝用户登陆后的链接直接进入系统)
      • 用户退出系统后是否删除了所有鉴权标记,是否可以使用后退键而不通过输入口令进入系统
      • 系统网络安全的测试要考虑问题
      • 测试采取的防护措施是否正确装配好,有关系统的补丁是否打上
      • 模拟非授权攻击,看防护系统是否坚固
      • 采用成熟的网络漏洞检查工具检查系统相关漏洞(即用最专业的黑客攻击工具攻击试一下,
      • 现在最常用的是 NBSI 系列和 IPhacker IP )
      • 采用各种木马检查工具检查系统木马情况
      • 采用各种防外挂工具检查系统各组程序的外挂漏洞

    数据库安全考虑问题:

      • 系统数据是否机密(比如对银行系统,这一点就特别重要,一般的网站就没有太高要求)
      • 系统数据的完整性(我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整,对于这
      • 个系统的功能实现有了障碍)
      • 系统数据可管理性
      • 系统数据的独立性
      • 系统数据可备份和恢复能力(数据备份是否完整,可否恢复,恢复是否可以完整)

     

    α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环

    境下进行的受控测试,Alpha 测试不能由程序员或测试员完成。

    β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在

    测试现场,Beta 测试不能由程序员或测试员完成。

    需求测试的注意事项有哪些?

    •        是否使用了公司的模板
    •   文档内容是否符合规范
    •   所有的需求是分级是否清析适当?
    •   所有的需求是否具有一致性
    •   需求是否可行(即,该需求组合有解决方案)
    •   需求可否用己知的约束来实现
    •   需求是否足够(即,可以把它送到一个规范的开发组织,并有一个生产出所需要产品的合理的可能性)
    •   所有的其它需求是交叉引用是否正确
    •   用户描述是否清楚
    •   是否用客户的语言来描述需求
    •   每个需求描述是否清楚没有岐义,可以移交给一个独立的组去实现时也能理解
    •   是否所有的需求都是可验证的
    •   是否每条需求都具有独立性,即使发生了变化也不会影响其它需求
    •   性能指标是否明确
    •   非功能性需求是否得到充分表现
    •   是否完整列出适用的标准或协议
    •   标准和协议之间是否存在冲突

    问:你在测试中发现了一个  bug ,但是开发经理认为这不是一个  bug ,你应该怎样解决。

    1. 将问题提交到缺陷管理库里面进行备案。
    2. 要获取判断的依据和标准:     根据需求说明书、产品说明、设计文档等,确认实际结果是否与计划有不一致的地方,提供缺陷是否确认的直接依据;     如果没有文档依据,可以根据类似软件的一般特性来说明是否存在不一致的地方,来确认是否是缺陷;   根据用户的一般使用习惯,来确认是否是缺陷;
    3. 与设计人员、开发人员和客户代表等相关人员探讨,确认是否是缺陷;
    4. 合理的论述,向测试经理说明自己的判断的理由,注意客观、严谨,不参杂个人情绪。
    5. 等待测试经理做出最终决定,如果仍然存在争议,可以通过公司政策所提供的渠道,向上级反映,并有上级做出决定。

     

     

    问:给你一个网站,你如何测试?

    1、查找需求说明、网站设计 m 等相关文档,分析测试需求。

    2、制定测试计划,确定测试范围和测试策略,一般包括以下几个部分:

         功能性测试;界面测试;性能测试;数据库测试;安全性测试;兼容性测试

    3、设计测试用例:

         功能性测试可以包括,但不限于以下几个方面:

         链接测试。链接是否正确跳转,是否存在空页面和无效页面,是否有不正确的出错信息返回等。提交功能的测试。

         多媒体元素是否可以正确加载和显示。多语言支持是否能够正确显示选择的语言等。

         界面测试可以包括但不限于一下几个方面:

    • 页面是否风格统一,美观
    • 文字检查
    • 对于必须但为安装的空间,是否提供自动下载并安装的功能
    • 控件是否正常使用
    • 页面布局是否合理,重点内容和热点内容是否突出                                                       

     

    问:一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压,有什么区别? ?

    300 个用户在一个客户端上,会占用客户机更多的资源,而影响测试的结果。线程之间可能发生干扰,而产生一些异常。300 个用户在一个客户端上,需要更大的带宽。IP 地址的问题,可能需要使用 IP Spoof 来绕过服务器对于单一 IP 地址最大连接数的限制。所有用户在一个客户端上,不必考虑分布式管理的问题;而用户分布在不同的客户端上,需要考虑使用控制器来整体调配不同客户机上的用户。同时,还需要给予相应的权限配置和防火墙设置。

    你工作中遇到最具价值的bug,就是重大bug咯,例如app性能测试测哪些,那你就看一看性能测试的视频咯

     

    软件的安全性应从哪几个方面 去测试?

    软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

    用户认证安全的测试要考虑问题:

    • 明确区分系统中不同用户权限
    • 系统中会不会出现用户冲突
    • 系统会不会因用户的权限的改变造成混乱
    • 用户登陆密码是否是可见、可复制
    • 是否可以通过绝对途径登陆系统(拷贝用户登陆后的链接直接进入系统)
    • 用户退出系统后是否删除了所有鉴权标记,是否可以使用后退键而不通过输入口令进入系统
    • 系统网络安全的测试要考虑问题
    • 测试采取的防护措施是否正确装配好,有关系统的补丁是否打上
    • 模拟非授权攻击,看防护系统是否坚固
    • 采用成熟的网络漏洞检查工具检查系统相关漏洞(即用最专业的黑客攻击工具攻击试一下,
    • 现在最常用的是 NBSI 系列和 IPhacker IP )
    • 采用各种木马检查工具检查系统木马情况
    • 采用各种防外挂工具检查系统各组程序的外挂漏洞

    数据库安全考虑问题:

    • 系统数据是否机密(比如对银行系统,这一点就特别重要,一般的网站就没有太高要求)
    • 系统数据的完整性(我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整,对于这个系统的功能实现有了障碍)
    • 系统数据可管理性
    • 系统数据的独立性
    • 系统数据可备份和恢复能力(数据备份是否完整,可否恢复,恢复是否可以完整)

     

     

    软件质量保证体系是什么 国家标准中与质量保证管理相关的几个标准是什么? ? 他们的编号和全称是什么? ?

    SQA 由一套软件工程过程和方法组成,以保证(软件的)质量。SQA 贯穿整个软件开发过程,(它)应包括需求文档评审、代码控制、代码评审、变更管理、配置管理、版本管理和软件测试。

     

    测试人员在软件开发过程中的任务是什么?

    1、寻找 Bug;

    2、避免软件开发过程中的缺陷;

    3、衡量软件的品质;

    4、关注用户的需求。

    总的目标是:确保软件的质量。

     

    在您以往的工作中,一条软件缺陷(或者叫 Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    一条 Bug 记录最基本应包含:编号、Bug 所属模块、Bug 描述、Bug 级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等等;

    要有效的发现 Bug 需参考需求以及详细设计等前期文档设计出高效的测试用例,然后严格执行测试用例,对发现的问题要充分确认

    肯定,然后再向外发布如此才能提高提交 Bug 的质量。

     

     

    黑盒测试和白盒测试是软件测试的两种基本方法,请分别说明各自的优点和缺点!

    黑盒测试的优点有:

           比较简单,不需要了解程序内部的代码及实现;与软件的内部实现无关;从用户角度出发,能很容易的知道用户会用到哪些功能,会遇到哪些问题;基于软件开发文档,所以也能知道软件实现了文档中的哪些功能;在做软件自动化测试时较为方便。

    黑盒测试的缺点有:

           不可能覆盖所有的代码,覆盖率较低,大概只能达到总代码量的 30%;自动化测试的复用性较低。

    白盒测试的优点有:

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

    白盒测试的缺点有:

           程序运行会有很多不同的路径,不可能测试所有的运行路径;测试基于代码,只能测试开发人员做的对不对,而不能知道设计的正确与否,可能会漏掉一些功能需求;系统庞大时,测试开销会非常大。

     

     

    什么是系统瓶颈?

    参考答案:

    瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求,“特定”是指瓶颈会在某些条件下会出现,因为毕竟大多数系统在投入前。

    严格的从技术角度讲,所有的系统都会有瓶颈,因为大多数系统的资源配置不是协调的,例如CPU使用率刚好达到100%时,内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论:关键是看系统能否满足用户需求。在用户极限使用系统的情况下,系统的响应仍然正常,我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。

    因此我们测试系统瓶颈主要是实现下面两个目的:

    -发现“表面”的瓶颈。主要是模拟用户的操作,找出用户极限使用系统时的瓶颈,然后解决瓶颈,这是性能测试的基本目标。

    -发现潜在的瓶颈并解决,保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时,系统能够适应变化。满足用户目前需求的系统不是最好的,我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化,或者通过简单扩展系统就可以适应新的变化。

     

    手机APP测试

    :主要包括功能、性能测试、稳定性、兼容性、用户测试。

     

    性能测试:CPU占用/内存占用 /耗电测试 /流量消耗测试 /安装包大小 /加载时间测试 /核心功能相应时间 (①启动时间检测:检测App在终端上首次启动时间。 ②内存、CPU耗用检测:检测App在终端上运行时不同时段占用内存、CPU情况。 ③流量耗用检测:检测App在终端上运行时的网络流量消耗情况。 ④电池温度检测:检测App在终端上运行时,对终端的电池温度等性能指标的影响情况 )

     

    兼容性测试:屏幕分辨率 /网络状态,状态切换 /android版本 /安装卸载升级等 /权限设置 /与其他APP兼容性 (①安装卸载测试:测试App在指定终端上是否可正常安装、正常卸载,准确定位错误原因。 ②遍历测试:自动识别App可执行的功能,在一定时间内遍历App的不同功能界面,通过截图记录操作路径 并输出日志、定位异常现象。 ③运行稳定性测试:类似Monkey的随机性压力测试,测试App运行期的稳定性。 ④UI适配测试:测试App的UI与目标终端的屏幕是否适配,记录是否存在渲染失败、错位、黑边框、黑白屏等现象。)

     

    稳定性测试包括:服务器异常时稳定性 /外部事件影响(电话,短信等) /内存是否有溢出或者泄漏 /多线程问题 。

     

     

     

    什么是并发?在lordrunner中,如何进行并发的测试?集合点失败了会怎么样?

    参考答案:

    在同一时间点,支持多个不同的操作。

    LoadRunner中提供IP伪装,集合点,配合虚拟用户的设计,以及在多台电脑上设置,可以比较好的模拟真实的并发。

    集合点,即是多个用户在某个时刻,某个特定的环境下同时进行虚拟用户的操作的。集合点失败,则集合点的才操作就会取消,测试就不能进行。

     

     

    详细的描述一个测试活动完整的过程。

    答案:(供参考,本答案主要是瀑布模型的做法)

           项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。然后 SQA 进入项目,开始进行统计和跟踪开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。测试用例完成后,测试和开发需要进行评审。测试人员搭建环境开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现 BUG后提交给 BugZilla。开发提交第二个版本,包括 Bug Fix 以及增加了部分功能,测试人员进行测试。重复上面的工作,一般是 3-4 个版本后 BUG 数量减少,达到出货的要求。如果有客户反馈的问题,需要测试人员协助重现并重新测试。

     

    在您以往的工作中,一条软件缺陷(或者叫  Bug )记录都包含了哪些内容?如何提交高质量的软件缺陷( Bug )记录?

    在传统的 BugZilla 中,BUG 描述应该包括以下的信息和 BUG 产生对应的软件版本和模块开发的接口人员BUG 的优先级BUG 的严重程度BUG 可能属于的模块,如果不能确认,可以用开发人员来判断BUG 标题,需要清晰的描述现象BUG 描述,需要尽量给出重新 Bug 的步骤BUG 附件中能给出相关的日志和截图。高质量的 BUG 记录就是指很容易理解的 BUG 记录,所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位,因此提交高质量的软件缺陷记录需要注意对 BUG 记录的描述质量多且准确。

     

     您认为在测试人员同开发人员的沟通过程中,如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员 良好的人际关系的关键是什么?

           尽量面对面的沟通,其次是能直接通过电话沟通,如果只能通过 Email 等非及时沟通工具的话,强调必须对特性的理解深刻以及能表达清楚。运用一些测试管理工具如 TestDirector 进行管理也是较有效的方法,同时要注意在TestDirector 中对 BUG 有准确的描述。在团队中建立测试人员与开发人员良好沟通中注意以下几点:一真诚二是团队精神三是在专业上有共同语言四是要对事不对人,工作至上当然也可以通过直接指出一些小问题,而不是进入 BUG Tracking System 来增加对方的好感。

     

    软件测试项目从什么时候开始?为什么?

          软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.

     

    测试结束的标准是什么?

           从微观上来说,在测试计划中定义,比如系统在一定性能下平稳运行 72 小时,目前 BugTracking System 中,本版本中没有一般严重的 BUG,普通 BUG 的数量在 3 以下,BUG 修复率 90%以上等等参数,然后由开发经理,测试经理,项目经理共同签字认同版本 Release。如果说宏观的,则是当这个软件彻底的消失以后,测试就结束了。

     

    您是否了解以往所工作的企业的软件开发过程?如果了解,请试述一个完整的开发过程需要完成哪些工作?分别由哪些不同的角色来完成这些工作?您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?

    开发过程---需求调研(需求人员)、需求分析(需求人员)、概要设计(设计人员)、详细设计(设计人员)、编码(开发人员)测试过程---需求评审、系统测试设计、概要设计评审、集成测试设计、详细设计评审、单元测试设计、测试执行测试工作的整个过程都做过,擅长做测试设计过程决定质量,软件的过程改进正是为了提高软件的质量,将过往的种种经验和教训积累起来。

    补充

    1.明确测试的目标,增强测试计划的实用性编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确

    2.坚持“5W”规则,明确内容与过程

    “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。

    3.采用评审和更新机制,保证测试计划满足实际需求

    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。分别创建测试计划与测试详细规格、测试用例,应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。

     

    请你回答一下性能测试有哪些指标,对一个登录功能做性能测试,有哪些指标,怎么测出可同时处理的最大请求数量

    参考回答:

    性能测试常用指标:

    从外部看,主要有

    1、吞吐量:每秒钟系统能够处理的请求数,任务数

    2、响应时间:服务处理一个请求或一个任务的耗时

    3、错误率:一批请求中结果出错的请求所占比例

    从服务器的角度看,性能测试关注CPU,内存,服务器负载,网络,磁盘IO

    对登录功能做性能测试

    单用户登陆的响应界面是否符合预期

    单用户登陆时后台请求数量是否过多

    高并发场景下用户登录的响应界面是否符合预期

    高并发场景下服务端的监控指标是否符合预期

    高集合点并发场景下是否存在资源死锁和不合理的资源等待

    长时间大量用户连续登录和登出,服务器端是否存在内存泄漏

    怎么测出可同时处理的最大请求数量

    可以采用性能测试工具(WeTest服务器性能),该工具是腾讯wetest团队出品,使用起来很简单方便,但测试功能相当强大,能提供10w+以上的并发量,定位性能拐点,测出服务器模型最大并发

     

    什么是兼容型测试?兼容性测试侧重哪些方面?

    兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行,即是通常说的软件的可移植性。兼容的类型,如果细分的话,有平台的兼容,网络兼容,数据库兼容,以及数据格式的兼容。兼容测试的重点是,对兼容环境的分析。通常,是在运行软件的环境不是很确定的情况下,才需要做兼容。根据软件运行的需要,或者根据需求文档,一般能够得出用户会在什么环境下使用该软件,把这些环境整理成表单,就得出做兼容测试的兼容环境了

    兼容和配置测试的区别在于,做配置测试通常不是在Clean OS下做测试,而兼容测试多是在Clean OS环境下做的。

    补充:做兼容测试的具体步骤:在列好的软硬件环境清单做冒烟测试,还是每一步都测试。测出不兼容,怎么和开发沟通,开发面对这些不兼容需要做什么。如果修复成本很高,怎么和产品经理沟通。和谁确认表单

     

     

    软件测试项目从什么时候开始,?为什么?

    软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发

    过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费

    的成本就越大.

     

     

    二、测试实战面试题

     

    我现在有个程序,发现在Windows上运行的很慢,怎么判别是程序存在问题还是软硬件系统存在问题

    1、检查系统是否有中毒的特征

    2、检查软件/硬件的配置是否符合软件的推荐标准

    3、确认当前的系统是否独立,即没有对外提供什么消耗CPU资源的服务

    4、如果是C/S或者B/S结构的软件,需要检查是不是因为与服务器的连接有问题,或者访问有问题造成

    5、在系统没有任何负载的情况下,查看性能监视器,确认应用程序对CPU/内存的访问情况

    补充:每一步该怎么实现,需要用到什么技术

     

    一个程序有n个变量采用边界值分析可以产生几个测试用例

    4n+1

     

    请设计一个关于ATM自动取款机的测试用例。

    1)功能

    a)ATM所识别卡的类型;

    b)密码验证(身份登陆、是否为掩码、输入错误密码时是否提示,连续三次错误吞卡等);

    c)取款功能:

    i、金额多少的限制,单次最大最小提取金额、每天最大提取金额等);

    Ii、取款币种的不同,如人民币、美元、欧元等。

    d)是否提示客户操作完成后,打印相关操作信息;

    e)查询功能是否正常;

    f)转账功能是否正常;

    g)是否提示客户操作完成后,取回客户卡;

     

    2)性能

    a)是否有自动吞卡:非法客户\密码错误客户\规定时间内未完成相关操作功能的客户。(如果有,有无报警功能(保密报警))

    b)平均无故障时间,平均故障修复时间,输入密码后验证时间,出钞票时间,查询余额等待时间。

     

    3)易用性

    a)ATM各个操作功能(硬件)是否正常、易懂;

    b)ATM的界面显示是否友好;

    c)ATM是否支持英文操作;

    d)ATM是否存在异常(断电、黑客入侵)有自动保护(报警)功能;

     

    如何测试一个 纸杯?

    功能度:用水杯装水看漏不漏;水能不能被喝到

    安全性:杯子有没有毒或细菌

    可靠性:杯子从不同高度落下的损坏程度

    可移植性:杯子在不同的地方、温度等环境下是否都可以正常使用

    兼容性:杯子是否能够容纳果汁、白水、酒精、汽油等

    易用性:杯子是否烫手、是否有防滑措施、是否方便饮用

    用户文档:使用手册是否对杯子的用法、限制、使用条件等有详细描述

    疲劳测试:将杯子盛上水(案例一)放 24 小时检查泄漏时间和情况;盛上汽油(案例二)

    放 24 小时检查泄漏时间和情况等

    压力测试:用根针并在针上面不断加重量,看压强多大时会穿透

     

     

     

    我手上这支笔,请你根据这支笔设计测试用例

       首先我要测它的外观、颜色是否符合要求、所占的空间是多大、是否环保、接下来测它的质量、这支笔是否能够写字流畅、写出的自得颜色是否符合要求、能使用多长时间等

     

     

    测试手机开机键 

    功能测试:按下开机键,屏幕能否亮起

    性能测试:按下开机键,屏幕能否在规定时间内亮起

    压力测试:连续多次按下开机键,观察屏幕是否能一直亮起,到多久时间失灵

    健壮性测试:给定一个中了病毒的手机或者是淘汰许久的老机子,安歇开机键观察屏幕能否亮起

    可靠性测试:连续按下开机键有限次数,比如1万次,记录屏幕未亮起的次数

    可用性测试:开机键按下费不费力,开机键的形状设计是否贴合手指,开机键的位置设计是否方便

     

     

    如何回答登录功能怎么进行测试?

     

    首先,进行界面测试。

    查看界面上的所有元素是否齐全;

    没有输入内容时,是否有相应的提示语;

    验证码是否能够显示;

    移动鼠标,【登陆】按钮默认不能点击;

    【忘记密码】是否有个小问号“?”(其他都有);

     

    第二,进行功能测试。

    输入正确的用户名、密码、验证码,点【登陆】能登陆;

    输入正确的用户名、错误的密码、正确的验证码,提示用户名或密码错误;

    输入错误的用户名、正确的验证码,提示用户名或密码错误;

    输入正确的用户名、密码,错误的验证码,提示验证码错误;

    输入不符合规则的手机号或者邮箱应该提示错误;

    页面长时间不登陆和操作,验证码会不会过期;

    点【记住密码】,登录后退出,再次登陆是不是可以不输入密码;

    点【忘记密码】能够跳转到密码设置页面(至于是什么不用管,就是能不能跳转)

    只点击验证码图案,验证码能不能刷新;

    页面刷新,验证码图案能不能刷新;

    输入栏是否设置快速删除按钮;

    用户名和密码是否大小写敏感;

    用户名和密码前后有空格的处理;

    登陆成功,是否有记住密码功能;

    登陆失败后,不能记录密码的功能;

    新用户第一次登陆成功,是否有修改密码提示;

    用户登录过程中log中是否有个人信息明文打印;

    是否支持第三方登陆;

    刷新页面时是否会刷新验证码;

    输入密码的时候,大写键盘开启的时候要有提示信息  ;

    不同级别的用户,比如管理员用户和普通用户,登录系统后的权限是否正确;

     

    第三、业务安全测试。

    有没有登陆错误次数的限制;

    每次登陆错误之后有没有限制再次登陆的时间间隔;

    是否支持一个账号多地登陆;

    不同机型登陆,异地登陆是否有提醒  ;

    不登录的情况下,在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面;

     

    第四、兼容性测试。

    在相同浏览器的不同版本上打开登录页面,效果是否一致;在不同浏览器上打开登录页面,效果是否一致;在不同操作系统的不同浏览器打开登录页面,效果是否一致;在不同的屏幕分辨率下打开登录页面,效果是否一致;

     

    第五、代码安全性测试。

    用户输入登录信息登陆时,个人信息是不是会显示在浏览器地址栏;

    用户登陆的时候,通过抓包工具抓数据,密码是否加密;

    查看页面源代码,验证码是否直接显示在代码中;

    密码在后台储存时是否加密;

    是否可以使用登录的API发送登录请求,并绕开验证码校验;

    用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串,验证系统的返回页面;

    用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串,验证系统行为是否被篡改;

     

    第六、页面性能测试。

    单用户登录的响应时间是否小于3秒;

    通过工具向登录页发起大量请求,查看页面响应时间的变化;

    通过工具对登陆功能进行并发测试;通过工具向登录页发起大量请求,查看页面何时崩溃;

    通过工具向登录页发起大量请求,查看页面崩溃后有没有良好的提示信息;

    通过工具向登录页发起大量请求,查看页面崩溃后多长时间能够恢复服务;

    弱网,不同网速时登陆的时间,网络切换和网络延迟时登陆界面是否正常;

     

    最后、易用性测试。

    页面是否美观;

    功能是否都可以使用;

    页面速度快不快;

    页面元素加载是否耗费网络流量;

    能不能第三方登陆;

    为什么不使用手机验证码登陆;

    输入框能否可以以Tab键切换。

     

     

    如何回答京东购物车功能怎么进行测试?

     

    1.功能测试

    a)、未登录时:

    将商品加入购物车,页面跳转到登录页面,登录成功后购物车数量增加。

    b)、登录后:

    所有链接是否跳转正确;

    商品是否可以成功加入购物车;

    没有限购要求的商品,添加数量能不能超过库存数;

    购物车商品总数是否有限制;

    商品总数统计是否正确;

    全选功能是否可用;

    删除功能是否可用;

    删除功能是否有提示;

    价格总计是否正确;

    商品文字太长时是否显示完整;

    购物车中下架的商品是否有标识,是否还能支付;

    新加入购物车商品排序(添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品);

    是否支持快TAB、ENTER等快捷键;

    商品删除后商品总数是否减少;

    收藏功能是否可用;

    账号退出后,购物车添加的内容是否还在;

    购物车结算功能是否可用。

    限购商品按照规则购买完成后,还能不能再次添加购物车并购买;

    2.兼容性测试

    BS架构:不同浏览器测试,比如:IE,火狐,谷歌,360这些。

    APP:在主流的不同类型,不同分辨率,不同操作系统的手机上测试,华为,vivo,oppo等

    3.用户体验测试

    删除商品是否有提示;

    是否支持快捷键功能;

    是否有回到顶部的功能;

    商品过多时结算按钮是否可以浮动显示;

    购物车有多个商品时,能不能只对单个商品结算;

    界面布局、排版是否合理;

    文字是否显示清晰;

    不同卖家的商品是否区分明显。

    4.性能测试

    打开购物车页面要多长时间

     

     

    支付流程测试

    功能测试。

    用等价类和边界值,判断支付的金额;

    如果没有登陆能否支付,支付成功后是否可以正常跳转;

    支付方式是否支持扫码支付,第三方平台支付(支付包,云网等),语音支付,指纹支付;

    支付时是否需要身份验证,支付后有无手机短信提示,是否可以找他人代付;

    用边界值法有无支付额度限制,余额不足时有无提示,支付时是否是动态加密支付;

    待支付状态:订单是否可以正常支付;是否可以取消;有相同订单是否可以支付两次;

    是否可以扫码支付,输入错误的密码会怎样显示,有无错误次数限制;

    若支持扫码支付,二维码是否支持支付包和微信扫码,若两人同时扫描怎么处理;

    有无最小支付金额限制,无意义的支付金额0,重复支付如何处理;

    如果支付包含优惠金额,该怎么处理优惠额度;

     

    性能测试 

    弱网,无网时是否可以支付;

    退款到账时间,耗电量的多少;

    带负载情况下的响应时间和吞吐率,在某个时间段内同时访问系统的用户数量 ;

     

    压力测试

    多人同时付款;

    界面测试;

    支付界面有无错别字,排版是否合理,颜色搭配是否合理;

     

    兼容性测试

    是否可以跨平台,不同电脑机型下显示有无区别;

    安全性测试;

    若支付不成功是否原路退款,若支付成功,有无支付信息提示;

    用fiddler抓包尝试修改价格,对订单金额有无效验;

    直接输入需要权限的页面地址可用访问;

     

    接口测试

    第三方平台支付 

     

     

     

    对于有系统大量并发访问,你会如何做测试,有什么建议

    参考回答:

    如何做高并发系统的测试,一般而言,整体的测试策略是:先针对部分系统进行性能测试及压力测试,得到各部分的峰值处理性能,再模拟整体流程测试,重点测试整体业务流程以及业务预期负荷,着重测试以下几点:

    1、不同省份,不同运营商CDN节点性能,可采用典型压力测试方案

    2、核心机房BGP网络带宽,此部分重点在于测试各运行商的BGP网络可靠性,实际速率,一般采用smokeping,lxChariot等工具

    3、各类硬件设备性能,一般采用专业的网络设备测试工具

    4、各类服务器并发性能,分布式处理能力,可采用压力测试方案工具

    5、业务系统性能,采用业务系统压力测试方案

    6、数据库处理性能,这部分需要结合业务系统进行测试,以获取核心业务场景下的数据库的TPS/QPS,

    7、如果有支付功能,需要进行支付渠道接口及分流测试,此部分相对而言可能是最大的瓶颈所在,此外还涉及备份方案,容灾方案,业务降级方案的测试。

     

    请对这个系统做出测试用例:一个系统,多个摄像头,抓拍车牌,识别车牌,上传网上,网上展示

    参考回答:

    功能:

    1.每个摄像头都能抓拍车牌;

    2.每个摄像头抓拍到的车牌能正常交给系统处理;

    3.系统能够正确识别车牌;

    4.系统能够将识别出的车牌上传;

    5.上传至网络的车牌能够正常展示出来;

    一、功能测试

    1.使用正常的车牌,保持车牌静止,检查每个摄像头是否能抓拍车牌;

    2.使用类似非车牌的写有字的纸板,检查每个摄像头是否抓拍;

    3.使用正常的车牌,保持车牌较高速移动,检查每个摄像头是否能抓拍车牌;

    4.在多种情况下检查每个摄像头抓拍到的车牌能否正常交给系统处理,如临时断电、断网后能否正常将数据交给系统;

    5.使用抓拍到的正常的车牌,交由系统处理,检查系统能否识别车牌;

    6.使用非车牌的其他图片,交由系统处理,检查系统能否识别;

    7.在多种情况下检查系统能否将正常识别出的车牌进行上传,如临时断电、断网后未上传数据是否能继续上传;

    8.构造非车牌的其他内容的数据,检查系统能否将异常内容进行上传;

    9.检查上传至网络的车牌能否正常展示出来;

    10.上传非车牌的其他内容的数据,检查能否正常显示出来。

    二、性能测试

    1.同时向一个摄像头展示多个静止的车牌,检查摄像头能否抓拍到多个车牌;

    2.同时向一个摄像头展示多个较高速运动的车牌,检查摄像头能否抓拍到多个车牌;

    3.抓拍后,检查系统识别车牌的时间是否在需求要求的时间内;

    4.模拟大量抓拍照片同时交由系统处理,检查一定压力下系统能否正常识别车牌;

    5.模拟大量车牌同时上传,检查一定压力下能否上传成功。

    三、安全性测试

    1.检查是否能够通过给车牌加装饰物等方法,使摄像头无法抓拍或抓拍后系统无法正常识别车牌。

     

     

    请你说一说PC网络故障,以及如何排除障碍

    参考回答:

    (1)首先是排除接触故障,即确保你的网线是可以正常使用的。然后禁用网卡后再启用,排除偶然故障。打开网络和共享中心窗口,单击窗口左上侧“更改适配器设置”右击其中的“本地连接“或”无线网络连接”,单击快捷菜单中的“禁用”命令,即可禁用所选网络。接下来重启网络,只需右击后单击启用即可。

    (2)使用ipconfig查看计算机的上网参数

    1、单击“开始|所有程序|附件|命令提示符“,打开命令提示符窗口

    2、输入ipconfig,按Enter确认,可以看到机器的配置信息,输入ipconfig/all,可以看到IP地址和网卡物理地址等相关网络详细信息。

    (3)使用ping命令测试网络的连通性,定位故障范围

    在命令提示符窗口中输入”ping 127.0.0.1“,数据显示本机分别发送和接受了4个数据包,丢包率为零,可以判断本机网络协议工作正常,如显示”请求超时“,则表明本机网卡的安装或TCP/IP协议有问题,接下来就应该检查网卡和TCP/IP协议,卸载后重装即可。

    (4)ping本机IP

    在确认127.0.0.1地址能被ping通的情况下,继续使用ping命令测试本机的IP地址能否被ping通,如不能,说明本机的网卡驱动程序不正确,或者网卡与网线之间连接有故障,也有可能是本地的路由表面收到了破坏,此时应检查本机网卡的状态是否为已连接,网络参数是否设置正确,如果正确可是不能ping通,就应该重新安装网卡驱动程序。丢失率为零,可以判断网卡安装配置没有问题,工作正常。

    (5)ping网关

    网关地址能被ping通的话,表明本机网络连接以及正常,如果命令不成功,可能是网关设备自身存在问题,也可能是本机上网参数设置有误,检查网络参数。

     

     

    微信红包

    功能

    1.在红包钱数,和红包个数的输入框中只能输入数字

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

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

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

    4.当红包钱数超过最大范围是不是有对应的提示

    5.当发送的红包个数超过最大范围是不是有提示

    6.当余额不足时,红包发送失败

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

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

    8.输入红包钱数是不是只能输入数字

    9.红包描述里许多能有多少个字符   10个

    10.红包描述,金额,红包个数框里是否支持复制粘贴操作

    12.红包描述里的表情可以删除

    13.发送的红包别人是否可以领取

    13.1发的红包自己可不可以领取   2人

    14. 24小时内没有领取的红包是否可以退回到原来的账户

    14.1  超过24小时没有领取的红包,是否还可以领取

    15.用户是否可以多次抢一个红包

    16.发红包的人是否还可以抢红包   多人

    17.红包的金额里的小数位数是否有限制

    18.可以按返回键,取消发红包

    19. 断网时,无法抢红包

    20.可不可以自己选择支付方式

    21.余额不足时,会不会自动匹配支付方式

    22.在发红包界面能否看到以前的收发红包的记录

    23.红包记录里的信息与实际收发红包记录是否匹配

    24.支付时可以密码支付也可以指纹支付

    25.如果直接输入小数点,那么小数点之前应该有个0

    26.支付成功后,退回聊天界面

    27.发红包金额和收到的红包金额应该匹配

    28.是否可以连续多次发红包

    29.输入钱数为0,"塞钱进红包"置灰

     

    性能

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

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

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

    4.收发红包的耗电量

    5.退款到账的时间

     

    兼容

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

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

     

    界面

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

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

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

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

     

    安全

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

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

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

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

     

    易用性(有点重复)

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

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

     

     

    微信发朋友圈点赞

    参考回答:

    功能测试:

    点赞某条朋友圈,验证是否成功

    接口测试:

    点赞朋友圈,验证朋友能否收到提示信息

    性能测试

    点赞朋友圈,是否在规定时间显示结果,是否在规定时间在朋友手机上进行提示

    兼容性测试

    在不同的终端比如ipad,手机上点赞朋友圈,验证是否成功

     

     

    如何对淘宝搜索框进行测试

    参考回答:

    一, 功能测试

    1. 输入关键字,查看: 返回结果是否准确,返回的文本长度需限制

    1.1输入可查到结果的正常关键字、词、语句,检索到的内容、链接正确性;

    1.2输入不可查到结果的关键字、词、语句;

    1.3输入一些特殊的内容,如空、特殊符、标点符、极限值等,可引入等价类划分的方法等;

    2. 结果显示:标题,卖家,销售量,单行/多行,是否有图片

    3. 结果排序:价格 销量 评价 综合

    4.返回结果庞大时,限制第一页的现实量,需支持翻页

    5. 多选项搜索:关键字 品牌 产地 价格区间 是否天猫 是否全国购

    6. 是否支持模糊搜索,支持通配符的查询

    7, 网速慢的情况下的搜索

    8. 搜索结果为空的情况

    9. 未登录情况和登录情况下的搜索(登录情况下 存储用户搜索的关键字/搜索习惯)

    二.性能测试:

    1压力测试:在不同发用户数压力下的表现(评价指标如响应时间等)

    2负载测试:看极限能承载多大的用户量同时正常使用

    3稳定性测试:常规压力下能保持多久持续稳定运行

    4内存测试:有无内存泄漏现象

    5大数据量测试:如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来,看表现如何等等。

    三. 易用性:交互界面的设计是否便于、易于使用

    1依据不同的查询结果会有相关的人性化提示,查不到时告知?查到时统计条数并告知?有疑似输入条件错误时提示可能正确的输入项等等处理;

    2查询出的结果罗列有序,如按点击率或其他排序规则,确保每次查询出的结果位置按规则列示方便定位,显示字体、字号、色彩便于识别等等;

    3标题查询、全文检索、模糊查询、容错查询、多关键字组织查询(空格间格开)等实用的检索方式是否正常?

    4输入搜索条件的控件风格设计、位置摆放是否醒目便于使用者注意到,有否快照等快捷查看方式等人性化设计?

    四. 兼容性

    1WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用

    2IE/FIREFOX/GOOGLE/360/QQ等各类浏览器下及各版本条件下、各种显示分辨率条件下的应用

    3SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试

    4简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试

    5IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试

    6与各相关的监控程序的兼容性测试,如输入法、杀毒、监控、防火墙等工具同时使用

    五. 安全性

    1被删除、加密、授权的数据,不允许被SQL注入等攻击方式查出来的,是否有安全控制设计;

    2录入一些数据库查询的保留字符,如单引号、%等等,造成查询SQL拼接出的语句产生漏洞,如可以查出所有数据等等,这方面要有一些黑客攻击的思想并引入一些工具和技术,如爬网等。

    3通过白盒测试技术,检查一下在程序设计上是否存在安全方面的隐患;

    4对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制;

     

     

     

     

    就linux下的CP命令设计测试用例。

    功能

     

    拷贝的文件

    1)大小:0k, 1k, 10k, 100k, 1000k…

    2)类型:二进制文件、文本文件、mp3、avi、压缩文件…

     

    文件源目录

    1)文件中包含各种类型的文件

    2)目录深度为0,1,2,3…

     

    文件目标目录

    1)目标目录中存在与源文件同名同类型的文件

    2)目标目录中存在与源文件同名不同类型的文件

    3)目标目录中存在与源文件不同名同类型的文件

    4)目标目录中存在与源文件不同名不同类型的文件

     

    异常

     

    参数异常

    1)包含特殊字符

    2)参数长度超过限制

    3)源目录不存在

    4)目标目录不存在

     

    文件异常

    1)文件没有拷贝权限

    2)非法的文件格式和内容

     

    存储介质异常

    1)存储介质由损坏

    2)拷贝前存储介质已满

    3)拷贝中存储介质存满

     

    执行过程异常

    1)拷贝过程中删除源文件

    2)拷贝过程中删除目标文件

     

    性能

    1)拷贝大文件

    2)拷贝源目录中存在大量小文件

    3)跨文件系统拷贝

    4)跨存储介质拷贝

    5)并发执行拷贝

     

    关注性能点:拷贝完成时间,CPU,内存,磁盘IO

     

     

     

    请问如果用户点击微博的关注图标但是app上面没有反应,应该怎么排查这个问题

    • 是否手机出现故障,是否手机缓存过多造成内存不够用
    • 是否手机网络连接不稳定(弱网/无网),若是,有无网络差提示
    • 是否手机内存溢出(关注人数达上限否)
    • 是否是版本问题或者是安装包问题(更新系统,重新安装安装包)

     

    现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:

    标题:这一组只有一个记录,其内容为输出成绩报告的名字。

    试卷各题标准答案记录:每个记录均在第80个字符处标以数字"2"。该组的第一个记录的第1至第3个字符为题目编号(取值为1一999)。第10至第59个字符给出第1至第50题的答案(每个合法字符表示一个答案)。该组的第2,第3……个记录相应为第51至第100,第101至第150,…题的答案。

     

    每个学生的答卷描述:该组中每个记录的第80个字符均为数字"3"。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号,第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50,则第2,第3……纪录分别给出他的第51至第100,第101至第150……题的解答。然后是学生乙的答卷记录。

    学生人数不超过200,试题数不超过999。

    程序的输出有4个报告:

        a)按学号排列的成绩单,列出每个学生的成绩、名次。

        b)按学生成绩排序的成绩单。

        c)平均分数及标准偏差的报告。

        d)试题分析报告。按试题号排序,列出各题学生答对的百分比。

    分别考虑输入条件和输出条件,以及边界条件。给出右表所示的输入条件及相应的测试用例。

     

     

     

    三、基础知识点

    什么是桩模块?什么是驱动模块?

    桩模块:被测模块调用模块

    驱动模块 调用被测模块

     

    什么是扇入?什么是扇出?

    扇入:被调次数,扇出:调其它模块数目

     

    8020原则:在需求分析开始到集成测试阶段引入测试手段,能发现所有缺陷的80%,系统测试阶段发现16%,在运行维护阶段经过长时间大量运行软件后,能够发现4%。起源于经济学。

     

    什么是耦合?什么是内聚

    耦合:对一个软件结构内各个模块之间互连程度的度量。

    内聚:一个模块内各个元素彼此结合的紧密程度。强内聚,松耦合。

     

    缺陷严重程度

    致命(Fatal)、严重(Critical)、一般(Major)、较小(Minor)。

     

    缺陷优先级

    立即解决P1、高优先级P2、正常排队P3、低优先级P4。

     

    缺陷状态

    打开(open)、修正(fixed)、重新打开(reopen)、关闭(closed)、重复(Duplicate)、推迟(Deferred)、保留(On hold)、不修复(wontfix)。

     

    简单的软件缺陷生命周期:

    发现(new)-打开-修复-关闭。

     

    复杂的软件缺陷生命周期:

    新建-打开-Bug审查(设计需要修改/延期/关闭)-关闭。

       新建-打开-是否清楚,可再现(不能再现缺少信息返回到打开状态)-修正-关闭。

     

    什么是在线用户数?什么是并发用户数

    在线用户数:

    用户同时在一定时间段的在线数量

    并发用户数:

    某一时刻同时向服务器发送请求的用户数

     

     

    分布式软件架构分为

    B/S架构(浏览器、web版)       C/S架构:客户端(先进行安装)

     

    测试人员的能力

    搭建环境的能力(配置JDK、数据库、Tomcat/Apace、程序放相应路径下、检查配置是否成功‚数据库管理和设置ƒ程序设计C++④测试方法论⑤工具的使用能力(QC\QTP\LR\Bugfree)

     

    简述负载测试与压力测试的区别。

    参考答案:

     

    压力测试(Stress Testing)

    压力测试的主要任务就是获取系统正确运行的极限,检查系统在瞬间峰值负荷下正确执行的能力。例如,对服务器做压力测试时就可以增加并发操作的用户数量;或者不停地向服务器发送请求;或一次性向服务器发送特别大的数据等。看看服务器保持正常运行所能达到的最大状态。人们通常使用测试工具来完成压力测试,如模拟上万个用户从终端同时登录,这是压力测试中常常使用的方法。

     

    负载测试(Volume Testing)

    用于检查系统在使用大量数据的时候正确工作的能力,即检验系统的能力最高能达到什么程度。例如,对于信息检索系统,让它使用频率达到最大;对于多个终端的分时系统,让它所有的终端都开动。在使整个系统的全部资源达到“满负荷”的情形下,测试系统的承受能力。

     

    软件缺陷管理工具有哪些

    答:   QC ALM BugFree jira Mantis 禅道

     

    弱网测试

     

     

     

    四、智力题

    一,5只猫 五分钟捉5只老鼠 请问100分钟捉100只老鼠需要多少只猫?

    答案:5只

    二,圆桌,两个人,轮流放硬币,不能重叠,半径为1,某一方不能放下去,则为输。问先手赢 后手赢

    答案:先手赢,圆桌对称,先手先放,后手都可以找对称位置,除了圆心

    三,3升的杯子一个,5升的杯子一个,杯子不规则形状 问怎么得到4升的水 水无限多

    答案:略

    四,晚上有四个人过桥,一次只能过两个人,但是只有一只手电筒,四个人过桥时间分别是1,2,5,8,求最短过桥时间

    答案:甲乙,甲回,丙丁,乙回,甲乙,15分钟

    五,有十张扑克牌,每次可以只出一张,也可以只出两张,要出完有多少种出法

    答案:89 F(9)=N F(8)=P F(10)=F(8)+F(9) F(1)=1 F(2)=2

    六,井盖为什么是圆的

    答案:用料少,受压均匀,成本低

    七,两个盲人各买了一白一黑两双袜子,不小心弄混了,问他们自己怎么分成刚好每人一白一黑

    答案:袜子是连在一起的

    八, 烧一根不均匀的绳子,从头烧到尾总共需要1个小时,问如何用烧绳子的方法来确定15分钟?

    答案:烧两根,一根点两头,一根点一头,烧完,剩下的把另一投点了,烧完,看重合点

    九,海盗分金,五人,过半同意,否则喂鱼,问1方案?

    答案:45,5反对,4喂鱼,所3(100,0,0),故2(98,0,1,1),故1(97,0,1,2,0)

    十,岔路口,通往1,2,两人,一人必说谎,一人永真话,怎么去1

    答案:问一人,另一人会回答那条路去1,回答答案必假

    十一,果冻,有黄色、绿色、红色三种,闭眼抓同种颜色两个,抓取多少个,可确定有两个同色果冻?

    答案:根据抽屉原理,4个

    十二,下水道为什么是圆的

    答案:方便人员进出,井盖不容易掉落,不易如棱角磨损节约材料,保护车辆 和行人的安全

    十三,一共100个球,两人轮流拿,每人每次最多拿5个,最后一个拿的人赢;如果我先拿,怎么拿一定会赢?

    答案:每次拿的球总数控制为6;第一次拿4个;

    十四,有120g面粉,现有一个天平和一个2g的砝码以及一个7g的砝码,最少称几次可以将面粉分为70g与50g

    答案:4次,第一次120g=111g+9g  第二次111g=93g+18g  第三次93g=57g+36g  第四次50g=57g-7g  70g=7g+36g+18g+9g

    十五,扔鸡蛋不碎问题(腾讯校招面试题)?

    答案:14次

    十六,智力题:一千瓶中有一瓶毒药 十只小白鼠找出这瓶毒药

    答案:2^10=1024,小白鼠编号1-10,瓶子编号1-1000,把瓶子的编号转变为二进制数,第几位1,就给第几个小白鼠喝

     

     

     

    第二篇测试面试总结---->测试面试二

    参考资料:

     

    https://www.nowcoder.com/ta/review-test

    https://zhaiyujia.blog.csdn.net/article/details/81604085

    https://blog.csdn.net/weixin_30363263/article/details/80110247?utm_medium=distribute.pc_relevant.none-task-blog-title-2&spm=1001.2101.3001.4242

    https://my.oschina.net/u/4296112/blog/3569084

    https://bbs.huaweicloud.com/blogs/172015

    https://zhuanlan.zhihu.com/p/122493284

    https://blog.csdn.net/weixin_44264744/article/details/104948526?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3.control#%E4%B8%89%EF%BC%8C%E6%8E%A5%E5%8F%A3%E6%B5%8B%E8%AF%95Jmeter%2CFiddler

     

    展开全文
  • 软件工程期末考试题库(超全)

    万次阅读 多人点赞 2020-12-18 18:25:49
    软件工程期末考试题库 选择题 具有风险分析的软件生命周期模型是(  C   )。 A.瀑布模型      B.喷泉模型  C.螺旋模型        D.增量模型 软件工程的基本要素包括方法、工具和( A )。 ...
  • 强大的容错功能和详尽的日志、进度显示,更保证了自动备份同步的可靠性。高效稳定、占用资源少的特点,充分满足了企业级用户的需求。被广泛应用于企业数据自动备份、网站服务器、办公自动化、网吧管理等领域。不需...
  • 软件体系结构

    千次阅读 2022-02-24 11:22:45
    软件体系结构期末复习
  • Dubbo面试杀招--Dubbo集群容错负载均衡

    千次阅读 多人点赞 2020-09-24 16:57:33
    Dubbo 中的负载均衡 负载均衡其实分为硬件负载均衡和软件负载均衡,大伙儿应该对软件负载均衡比较熟悉,例如 Nginx。 而 Dubbo 也有自己的负载均衡,即 LoadBalance,前面我们提到服务提供者一般都是集群部署,这 ...
  • 软件体系结构期末考试总结

    万次阅读 多人点赞 2019-12-30 23:19:35
    今天刚考完软件体系结构,把考前的知识点总结发到群里,仅供自己参考,但是里面的内容确实有用也是面试会问到的基础,所以这门课很重要的还是,只可惜我是预习了一两天就参加考试了 对了我们的教材是《软件工程体系...
  • 软件架构设计——软件架构风格

    千次阅读 2021-10-21 14:51:32
    软件架构是具有一定形式的结构化元素,即构件的集合,包括处理构件,连接构件和数据构件。处理构件负责对数据进行加工,数据构件是被加工的信息,连接构件把架构的不同部分组合连接起来。 特点: 1、软件架构风格是...
  • 容错性测试

    千次阅读 2014-09-23 13:01:43
    容错性测试  (2009-01-30 14:30:41) 转载▼ ... 容错性测试是检查软件在异常条件下自身是否具有防护性的措施或某种灾难性恢复的手段。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。容
  •  我们提出的弹性分布式数据集(RDDs),是一个让程序员在大型集群上以容错的方式执行基于内存计算的分布式内存抽象。RDDs受启发于两类使用当前计算框架处理不高效的应用:迭代算法和交互式数据挖掘工具。这二者在...
  • 软件测试面试题汇总

    千次阅读 2022-04-14 14:22:23
    软件生存周期是软件开发全部过程、活动和任务的结构框架,是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。在经历需求、分析、设计、实现、部署后,软件将被使用并进入维护阶段,直到最后...
  • 基于 软件体系结构(第3版)考试重点和复习指南

    千次阅读 多人点赞 2021-12-04 15:20:51
    软件危机引起软件工程的研究,软件危机的加剧,人们认识到软件体系结构的重要性,并对软件体系结构开始系统地深入地研究,是提高软件生产率和解决软件问题最有希望的途径。 构件与重用的定义及他们之间的关系 构件:...
  • Storm入门与实践(4)Storm的容错机制

    千次阅读 2017-08-24 11:17:37
    按照软件设计的一般思路,这个问题的答案是“取决于实际情况”。Storm 0.7.0 版本引入了“事务拓扑”的特性,它能够保证大多数计算过程都能够满足恰好一次(exactly-once)的消息语义的容错性要求。想要了解“事务...
  • 2.10 构件与软件复用 构件(component,组件)是一个功能相对独立的具有可重用价值的软件单元。在面向对象方法中,一个构件由一组对象构成,包含了一些协作的类的集合,它们共同工作来提供一种系统功能。 2.10.1 ...
  • 三种最常用的日志分析软件

    千次阅读 2021-01-22 08:15:37
    自由开放源代码软件社区提供了适用于各种网站以及几乎所有操作系统的日志设计,下面给大家推荐三种最常用也是最好用的日志分析软件 1、Graylog 2011年在德国创建的 Graylog现在可以作为开放源码工具或商业解决方案...
  • 西电软件工程概论复习笔记(含重点标注)

    千次阅读 多人点赞 2022-04-14 17:10:37
    软件工程概论复习 有加粗的都是很重要的课后题中的对应题目。 文章目录软件工程概论复习Chapter1 Introduction1.1 什么是软件工程?1、有关软件(重点)2、有关软件工程(重点)3、什么是好的软件工程(重点)4、谁...
  • 1.下面哪项不属于软件工程方法学的要素(B) A、方法 B、模型 C、工具 D、过程 (知识点)软件工程三要素:方法、工具、过程 2.面向对象方法学具有(D)个要点。 A、1 B、2 C、3 D、4 (知识点)面向对象要点:对象...
  • 如果不小心打错了字, 是否有容错机制 是否可以显示历史搜索 是否可以使用回车键代替点击"百度一下" 可以使用扫码的方式直接登录百度 兼容性测试 是否可以在不同的浏览器上正常运行 Chrome, Firefox, IE, Edge… 是否...
  • 软件体系结构课堂笔记
  • 软件体系结构1~5章知识点整理

    千次阅读 2020-08-13 11:05:17
    目录绪论第一章 软件工程和软件设计概述第二章 软件模型和描述第三章 软件体系结构建模和UML第四章 软件设计过程第五章 软件体系结构风格 绪论 案例一:圣·玛丽亚大教堂 案例二:瑞典瓦萨战舰 由建筑体系架构——&...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,880
精华内容 6,752
热门标签
关键字:

容错过滤软件