一、 探索性测试
探索性测试可以说是一种测试思维技术，最直白的定义是：同时设计测试和执行测试。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
探索性测试识别软件系统的目的，识别软件系统提供的功能，识别软件系统潜在的不稳定的区域，在探索软件系统的过程中记录关于软件的信息和问题。
并且根据场景的不同，可以分成四类：自由式探索式测试、基于场景的探索式测试、基于策略的探索式测试和基于反馈的探索式测试。
探索性测试，需由有经验的人来实施。无论是目的的把握、策略的制定、分析/设计的深入、持续探索的职能，菜鸟工程师是难以胜任的。在这点上，资深QA会体会到自身的价值所在。
探索性测试，无法单独评估软件的质量。探索性测试，是拿来和“先设计、后执行”的基于测试用例的测试方式比较而言的。尽管有很多支持者在强调探索性测试在发现缺陷上的效率优势，但是考虑到探索性测试可以达到的覆盖度和成果的不确定性，目前更多是作为经典系统性测试方式的一个补充。
二、敏捷测试
敏捷测试(Agile testing)是测试的一种，是遵循敏捷宣言的一种测试实践：
➜强调从客户的角度，即从使用系统的用户角度，来测试系统。
➜重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
➜建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性
三、回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程（策略君注：极限编程）方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
回归测试是软件测试里面的一个非常普遍的概念，考虑到软件的“易变更性”、以及回归测试的代价，大部分人可谓“深受其害”。没办法，软件的改动往往牵一发而动全身，任何一个变更都可能带来新问题；至于修复老BUG，引入新BUG的情况也不算少见。
当然，在运用层面，回归测试的策略一直是讨论的重心。一般情况下，可以归为三类：
全回归，即每次有改动，仅进行全集的测试。这个策略可谓十分昂贵，所以在没有高自动化比率的场景下，大部分项目组都非常慎重，因为机会没有一个项目具备“宽松”的人力和时间。
不回归，即只考虑修改部分的测试、其余没有直接改动的一概不理。尽管有些极端，但是也不乏采用这样策略的场景；特别是时间紧、风险较低以及代码Review较为细致的情况。
部分回归，专业的名词“基于风险的回归”，对于回归测试的范围进行“优先级”分析，采用的方法诸如：业务流分析、代码调用结构分析、业务日常使用频度分析、失败的重要性分析等等。具体的方式，下次我们另开文章讨论。
于是这当中就会引出几个现象：
如果测试面临的是存在多年的大型核心业务系统，那么回归测试的工作自然是份额很大的，那么测试人员在团队中的比例自然会高，类似于昨天推文中的测试Vs开发3:1的场景。
考虑到回归测试的重复度，它往往是自动化测试的重点。一方面，稳定的功能特性、重复的工作特性往往都更加容易自动化；另一方面，在回归测试的部分往往是比较重要、优先级比较高的。
手工的回归测试因为其“无聊性”，往往被大部分测试人员所嫌弃。但是，它却也有额外的价值。很多时候，不管是测试新人，还是团队其他岗位的新人，最快熟悉系统的方式就是手工执行回归测试。可谓锻炼新人的神器~
四、冒烟测试
这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。
在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
冒烟测试是自由测试的一种。冒烟测试(smoketest)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为SmokeTest。
在很多情况下，做SmokeTest是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。SmokeTest优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。
五、集成测试
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
集成测试在系统测试之前，单元测试完成之后系统集成的时候进行测试。集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。
六、系统测试
系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。
七、交叉测试
为防止思维被固化，审 Bug 疲劳，各位测试人员之间相互交换测试内容。
八、渗透性测试
渗透测试 (penetration test)并没有一个标准的定义，国外一些安全组织达成共识的通用说法是：渗透测试是通过模拟恶意黑客的攻击方法，来评估计算机网络系统安全的一种评估方法。这个过程包括对系统的任何弱点、技术缺陷或漏洞的主动分析，这个分析是从一个攻击者可能存在的位置来进行的，并且从这个位置有条件主动利用安全漏洞。
换句话来说，渗透测试是指渗透人员在不同的位置（比如从内网、从外网等位置）利用各种手段对某个特定网络进行测试，以期发现和挖掘系统中存在的漏洞，然后输出渗透测试报告，并提交给网络所有者。网络所有者根据渗透人员提供的渗透测试报告，可以清晰知晓系统中存在的安全隐患和问题。
我们认为渗透测试还具有的两个显著特点是：渗透测试是一个渐进的并且逐步深入的过程。渗透测试是选择不影响业务系统正常运行的攻击方法进行的测试。
.
九、单元测试
是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
