黑盒测试

　　黑盒测试把产品软件当成是一个黑箱子，只有出口和入口，测试过程中只要知道往黑盒中输入什么东西，知道黑盒会出来什么结果就可以了，不需要了解黑箱子里面是如果做的。

　　即测试人员不用费神去理解软件里面的具体构成和原理，只要像用户一样看待产品就可以了。

　　例如银行转账功能，不需要知道转账的具体实现代码是怎样工作的，只需要把自己想象成各种类型的用户，模拟多种转账情况看系统是否能正常转账即可。

　　但是仅仅像用户一样去测试又是不够的。如果只做黑盒测试，必然是存在一定的风险的。

　　例如某个安全性较高的软件系统，开发人员在设计程序时考虑到记录系统日志的必要性，把软件运行过程中的很多信息都记录到了客户端的系统日志中，甚至把软件客户端连接服务器端的数据库连接请求字符串也记录到系统日志中，这必然会泄漏重要的数据。

　　如果按照黑盒测试，这是程序内部的行为，用户不会直接操作数据库的连接行为，因此检查系统日志这方面的测试是不会做的，所以会形成一个隐藏BUG。

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

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

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

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

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

白盒测试

　　上面把黑盒测试比喻为中医，那么白盒测试无疑就是西医了。测试人员需要采用各种仪器设备对软件进行检测，甚至把软件摆上手术台解剖来看个究竟。

　　白盒测试是一种以理解软件内部结构和程序运行方式为基础的软件测试技术。通常需要跟踪一个输入在程序中经过了哪些函数的处理，这些处理方式是否正确。

　　如果你是初级测试人员，你可能会认为，不懂代码的根本就做不了白盒测试，其实这种观点是有一定的错误的。

　　当然，会懂代码来做白盒测试，那肯定是最好的。但是一般做白盒测试，不需要读懂每一行程序代码。

　　如果把软件当成是一个黑箱子，那么白盒测试的关键就是给测试人员戴上一副X光透视眼镜，测试人员通过该眼镜可以看清楚给软件的输入在这个黑箱子中是如何运转的。

　　如果你不太懂代码，其实有很多像医院的检测仪器一样，可以帮助了解程序的内部运转过程。

　　例如：对于一个与SQL server数据库连接的软件系统，可以简单地把程序的作用理解为：把用户输入的数据通过SQL命令请求后台数据库，数据库把请求的数据返回给程序的界面层来展示给用户。SQL server自带的工具事件探查器则可以说是一个检查SQL数据传输的精密仪器，记录软件客户端与服务器数据库之间交互的一举一动，从而让测试人员可以洞悉软件究竟做了哪些动作。

　　在测试过程中，应该综合黑盒测试和白盒测试，不管使用哪种方法，能找到BUG就是好方法。一名优秀的测试人员，应该懂得使用各种各样的测试技术和找BUG的手段。

手工测试与自动化测试

　　有些人认为做手工测试是很简单的一件事，只需要点点点；而做自动化很难的事，很多人都避之不及。

　　其实，这两种方式都是需要结合使用。自动化不可以代替手工，手工测试具体不可替代性。

　　自动化测试是对手工测试的一种补充，主要应用在回归测试。主要集中在稳定的功能上面，帮助手工测试验证稳定模块的功能。

　　对于数据的正确性，界面美观，业务逻辑等的满足程度，自动化测试是做不了的，都需要由手工来做。毕竟机器是死的，人们对是非的判断，逻辑推理能力是工具不具备的。

　　自动化优势是借助计算机的计算能力，可以重复地、不知疲惫的进行，对于数据能进行精确的，大批量的比较，而且不会出错。

　　综上我们可以知道，手工测试和自动化测试一个都不能少，而且需要有机结合，充分利用优势，测试人员提供各种方法和手段。

探索性测试

　　探索性测试最直白的解释就是同时设计测试用例和执行测试。这种方法一般是测试经验丰富的测试人员使用，因为他们具备一定的测试经验，懂得哪些容易出现问题。

　　也可以在执行测试用例的过程中发现更多测试的途径。需要具备更多的发散思维。

　　探索性测试尤其适合需求不是很明确的测试任务，或者是一名刚刚接受一项新的测试任务的测试人员使用。

单元测试

　　单元测试，即针对的是软件设计中的最小单位--程序模块进行正确性检验的测试工作。其目的在于发现每个程序模块内部可能存在的差错。

　　单元测试应该由谁来做？

　　这里就分为了两派：

　　　　一派认为应该由开发来做；

　　　　因为代码是开发人员编写出来的，开发人员应该对自己所编写的代码负责，而且开发人员对于自己的代码熟悉程度最高，所以编写起来较测试人员容易，更可以得到优质的代码。

　　　　另外一派任务应该由测试人员来做；

　　　　因为开发人员不像测试人员有敏锐的测试思维，所以测试的没有测试人员精细，所以需要测试人员来做单元测试。

　　其实，这个问题都各持己见，但是最好的办法，就是双方合作。

　　即由测试人员设计测试用例，开发人员编写测试代码，测试人员执行测试用例。

单元级别的性能测试

　　性能测试是很多公司都忽略的问题，或者是等到程序已经开发完成之后才去测试的方向。

　　性能测试结果表名系统存在严重的性能问题，相应时间迟缓，内存占用过多，不能支持大量的数据请求，在大量用户并发访问的情况下系统崩溃。

　　如果当我们做完了整个系统的功能之后在发现以上的BUG，那么再去修改程序已经非常困难了，因为如果要彻底地解决性能问题，需要重新调整系统的架构设计，大量的代码需要重构，如果需要做调整，程序员不仅会疲惫，重新编写的程序也会引发大量的不稳定和BUG。

　　所以性能测试应该是贯穿软件的整个生产过程，包括架构设计、单元编码、集成、发布。

　　性能测试应该在单元测试阶段就开始，从代码的每一行效率，到一个方法的执行效率，再到一个逻辑实现的算法的效率；从代码的效率，到存储过程的效率，都应该进行优化。单元阶段的性能测试可以从以下几个方面进行考虑：

• 代码效率评估
• 应用单元性能测试工具
• 数据库优化

　　在代码的编写中，可能一个方法不会造成很大的问题，但是积少成多，就会成为大问题。这些问题可以通过代码走查来发现。如果测试人员不熟悉代码，可以使用代码标准检查工作，例如：FxCop,.TEST等来帮助自动查找类似的问题。

　　测试人员也可以使用一些代码效率测试工具来帮助找出哪些代码或者方法在执行时需要耗费比较长的时间，例如AQTime是一款可以计算出每行代码的执行时间工具。

　　除了代码行效率测试工具外，最近还出现了一些开源的单元级别的性能测试框架，可以像使用XUnit这一类的单元测试框架一样，但不是用于测试单元代码的正确性，而是用于测试函数，方法的性能是否满足要求。

例如NTime。它可以并发得运行同一个方法多次，看能否达到预期的性能指标。例如下面的代码使用NTime框架启动2个线程，在1秒钟内并发执行MyTest方法多次：

　　[TimerHitCountTest(98,Threads = 2,Unit = TimePeriod.Second)]

　　Public void MyTest()

　　{

　　　　　　//调用被测试的方法

　　　　　　MethodToBeTest();

　　}

　　如果测试结果表明能执行超过98次，则认为该方法的性能达标。反之则不达标。

数据库性能检查

　　上面讲的都是代码层的性能测试，但是目前很多系统软件都需要应用到数据库，所以数据库往往也成为性能的瓶颈之一。那么如何发现数据库相关的性能问题呢？

　　一般引起数据库的性能问题有两个原因：一个是数据库的设计，另外一个是SQL语句。

　　　　1、数据库的分为数据库的参数配置和逻辑结构设计，如果是数据库的参数配置，是比较容易解决的。如果遇到糟糕的表结构设计，将会导致很差的性能表现。　例如没有合理地设置主键和索引，则可能导致查询速度大大降低；没有合理地选择数据类型，也可能导致排序性能降低。

　　　　2、低效的SQL语句是引起数据库性能问题的主要原因之一。其中包括程序请求的SQL语句和存储过程、函数等SQL语句。对于这些语句的优化能大幅度地提高数据库性能，因此是测试人员需要重点关注的对象。

软件的“极限考验”--压力测试

　　压力测试，就是一种验证软件系统极限能力的性能测试。

　　有的人会把压力测试跟负载测试混淆。

　　其实他们的区别在于：

　　负责测试是需要进行多次的测试和记录，来观察各种参数是如果变化的。如随着并发的虚拟用户数的增加，系统的相应时间，内存使用，CPU使用情况的变化；

　　压力测试的目的很明确，就是找到系统的极限点，在系统崩溃或与指定的性能指标不符时的点，就是软件系统的极限点。

　　注意：实际上在做性能测试是不会很严格区别这些概念的，对于测试人员来说更关心的是如何满足性能需求，如何进行性能测试。

　　 如果对于不明确的性能需求，一般采用做的是负载测试，需要逐级验证系统在每一个数据量和并发量的情况下的性能相应，再综合分析系统的性能表现形式。

大数据容量的测试

　　如果在一个购物网站，一个网页加载4秒钟，你可能选择继续逛，如果加载了40秒钟，那么你可能选择离去。

　　B/S架构的软件系统的性能问题往往是由于不能支持大量的并发用户造成的，因此在很多人眼里会认为是模拟并发量的问题，而没有考虑到大数据容量的测试。

　　大数据容量的测试是指软件系统在处理大数据量或者是加载了大批量数据时的性能表现。就比如货车装载少货物时跑得快，装载多货物时跑得慢。

　　可能刚起步的公司，承载少量的数据也能正常运行。所以需求调研后往往会忽略对若干年后系统的一个承载力，若干年后的用户肯定是越来越多的，如果等到这时候才来做优化，那将会耗费大量的人力物力，这也是为什么一些业务系统在使用了若干年后被抛弃掉的原因，不能支持现有的业务量处理能力。因此要考虑软件的大数据容量测试，尤其是对于那些会随着软件系统的持续使用而增加大量数据的业务系统。

　　在生产大批数据之前，首先要估算一下软件系统未来使用的业务数据量。当然不能凭空想象，需要做具体调研。除此之外，应该对于频繁使用的功能进行调优。

那么如何模拟大批量数据呢？

　　模拟大批量数据可以采用一些数据生产工具，如DataFactory，也可以自己编写SQL语句插入数据库表或者编写程序产生大批量数据。

　　以下是DataFactory的使用视频：https://yunpan.cn/cSdzyL5aMrmBD  访问密码 cad5

　　生成大批量数据后，接下来需要把这些数据加载到软件系统进行功能测试。在准备好数据后应该执行所有的功能，找出响应时间明显迟缓的功能操作，同时在执行功能的时候应该监视和记录客户端和服务器的内存使用情况，CPU使用情况，网络传输量和速度，数据库的性能参数等。

安全性测试

　　随着网络发展的越来越迅速，网络安全也是我们需要关注的一个点，安全性测试是一个迫切需要进行的测试，测试人员需要像黑客一样攻击软件系统，找到软件系统包含的安全漏洞。特别关注的是银行系统，电商交易，B2C网站。

网页安全漏洞检测

　　一些设计不当的网站系统可能会包含很多可以被利用的安全漏洞，这些漏洞就会给攻击者开后门，让攻击者可以进行某些恶意的活动。例如公共漏洞和披露网站CVE公布了某WEB网页的一个漏洞项，允许远程攻击者通过隐藏的表单变量“price”来修改价格信息。表单信息如下：

　　<input type = hidden name = "id" value = "auto0034">

　　<input type = hidden name = "product" value = "BMW545">

　　 <input type = hidden name = "name" value = "Expensive Car">

　　<input type = hidden name = "price"  value = "100">

利用以上的漏洞，不怀好意可以任意设定price字段的值，然后提交给该网站的后台服务器，从而可能用100美元就可以获得一部BMW545。

　注意：发现类似的安全漏洞最好的方法是进行代码审查。除了代码审查,测试人员还可以利用一些测试工具进行检查，例如，Paessler Site Inspector,Web Developer等。

SQL注入

　　SQL注入是一个经常容易被忽略的安全漏洞，但是SQL注入同时也是一种非常普遍的代码漏洞，它会导致数据库端的敏感数据泄漏，或者服务器收到黑客的攻击。例如下面代码：

　　SqlConnection sqlcon = sqlconnA;

　　//打开链接

　　sqlcon.Open();

　　//组合一条查询语句

　　SqlCommand cmd = "select count(*) from User where LoginName=' "+this.textBox1.Text +"'and Password = '"+this.testBox2.Text;

　　SqlDataAdapter adpt = new SqlDataAdater(cmd,sqlcon);

　　DataSet ds = new DataSet();

　　adpt.Fill(ds);

　　//关闭链接

　　sqlcon.Close();

　　//如果返回数据不为空，则验证通过

　　if(ds.Tables[0].Rows.Count>0)

　　{

　　　　Return true;

　　}

　　else

　　{

　　　　Return false;

　　}

　　这段代码从textBox1获取用户名，从textBox2获取密码，然后执行数据库操作。假设在textBox1输入一个已知的用户名，然后再做一些手脚，则可以不使用密码进入系统，这个字符串利用了SQL对单引号的处理方式，只要简单地组合成类似以下的字符串并输入到textBox1中即可：

　　Admin' or '1'='1'

　　上面的Admin是已知的帐号，给预期的SQL语句注入了额外的语句，实际上提交到数据库的语句如下：

　　select count(*) from user where LogonName = 'Admin' or '1' = '1' and Password = ''

　　由于1=1是恒等的，因此返回的结果肯定是真，从而干扰了用户信息的正常验证，所以绕过了密码验证登录。

　　检查是否存在SQL语句注入漏洞的最后办法是代码审查，看所有涉及SQL语句提交的地方，是否正确处理了用户输入的字符串。

缓冲区溢出

　　不仅仅互联网上的软件系统才有安全问题，个人软件系统和公司内部的软件系统也存在。这种安全不是指数据泄漏，而是会导致工作成果丢失。

　　C语言是比较容易产生缓冲区溢出漏洞的语言开发，作为测试人员应该注意检查可能造成系统崩溃的安全问题。

技巧：测试人员需要每一个用户可能输入的地方尝试不同长度的数据输入，已验证程序在各种情况下正确地处理了用户的输入数据，而不会导致异常或溢出。或者通过代码审查来发现这些问题。还可以利用一些工具来帮助检查这类问题，例如AppVerifier等。

环境测试

　　环境测试，有人叫做兼容性测试，配置测试等，是指测试软件系统在不同环境下是否仍然能正常使用。

　　软件系统往往在测试环境和开发环境下能够正常运行，但是到了用户使用的环境则可能会出现很多意想不到的事。因为不同的用户可能会使用不同的软件系统。一般会涉及到如下：

• 操作系统环境
• 软件环境
• 网络环境
• 硬件环境
• 数据环境

　　环境测试一般使用组合覆盖测试技术进行测试用例的测试。

　　例如某个软件系统需要运行在下面的环境中

　　　　操作系统 window 8.1 或 window 2008

　　　　office 版本：office 2007 或者 office2010

　　　　内存配置：1GB 或者2GB

　　如果全覆盖，则需要执行2*2*2=8项测试，如果没有足够的时间做这么多次的测试，则可以利用正交表法或成对组合覆盖等方法减少测试次数。