软件测试
测试的目的是为了用测试用例test case找到bug，测试用例集test suite是一组相关的测试用例。
bug可以分解为症状（Symptom）、程序错误（Fault）、根本原因（Root Cause）
测试的分类
按测试设计的方法分类
测试可以按照测试设计的方法分为黑箱（Black Box）和白箱（White Box）
黑箱是指在设计测试的过程中把软件系统当做一个黑箱，无法了解或使用系统的内部结构及知识，即从软件的行为，而不是内部结构出发来设计测试。
白箱是指在设计测试的过程中，设计者可以看到软件系统的内部结构，并利用这一点来选择测试数据及具体的测试方式。
按测试的目的分类
可以分为功能测试和非功能测试。
功能测试就是测试软件的基本功能，测试的具体种类如下：
为了测试非功能需求（Non-functional Requirement）和服务质量需求（Quality of Service Requirement），当基本功能完成之后还需要做非功能测试：
按测试的时机和作用分类
在软件开发的过程中，不少测试起着烽火台的作用，它们告诉我们软件开发的流程是否顺畅，这些测试如下：
此外，根据不同的测试方法还分为以下几种：
具体的测试方法
之前我们提过单元测试、代码覆盖率测试和回归测试，除此之外还有很多测试方法。
构建验证测试（Build Verification Test，BVT）
构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。大多数情况下，这个测试是自动进行的。
在运行BVT之前，可以运行所有的单元测试，以保证系统的单元测试和程序员的单元测试版本一致。
通过BVT的构建可以成为可测（Testable），意思是团队可以用这一版本进行各种测试，因为它的基本功能都是可用的，反之通不过BVT的构建称为失败的构建（Failed，Rejected）
如果构建测试不能通过，那么自动测试框架会针对每一个失败的测试自动生成一个Bug，一般来说，这些Bug都有最高优先级，开发人员要首先处理。面对这些bug，我们可以选择：
1、找到导致失败的原因，如果原因很简单，程序员就可以立即修改并直接提交
2、找到导致失败的修改集，把此修改集剔出此版本，修正bug后再重新提交
3、在下一个构建前修正该bug
方法1和2都可以使今天的构建成为可测的，但有时各方面相互依赖，导致只能选择方法3.
验收测试Acceptance Test
测试团队拿到一个可测的构建之后，就会按照测试计划来测试各自负责的模块和功能。测试时把支持的所有场景都列出来，然后按功能分类测试，如果测试成功，就在此场景标明成功，否则就标明失败，对场景的测试都完成后，就可以制作场景测试报告：
可以通过测试报告计算总的通过率。如果所有场景都能通过，则称构建可用，那么这一个版本就可以给用户使用了。
这样的测试就被称为验收测试，如果构建通过了这样的测试，这个构建就被团队接受了。但是注意构建可用不代表所有的功能都没问题，有些还没有定义的用户场景或者不按照规范操作的场景都有可能出现bug。
探索式测试Ad hoc Test
也被称为Exploratory Test。这种测试是指为了某个特定目的而进行的测试，且就这一次，以后一般也不会重复测试。例如按计划是进行A模块的测试，但是测试人员灵机一动测试了另一个功能B。这种比较灵活的测试方法通常可以找到许多意外的bug。
探索式的测试流程是不可重复的，不能自动化。
场景/集成/系统测试Scenario/Integration/System Test
在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，这类测试就是系统/集成测试。
场景测试是以场景为驱动的测试，考虑用户在使用软件时的流程，模拟该流程。
当一个模块稳定的时候，就可以把它集成到系统，和整个系统一起测试，我们不要过早的进行集成测试，否则会多出很多Bug。
伙伴测试Buddy Test
系统测试总是要等到适当的时机，而伙伴测试不会。当写好单元测试之后，开发人员就可以找一个测试人员作为伙伴，在签入新代码之前，开发人员做一个包含新模块的私人构建，测试人员在本地完成必要的回归、功能、继承、探索测试，发现问题直接和开发人员沟通，无需等待，解决后再正式签入代码。
这样的测试方式避免了整体系统稳定性的下降，也避免了层层会诊的成本。
效能测试Performance Test
这是为了测试一些非功能需求和服务质量需求的测试。这里主要涉及两个概念：
1、设计负载，如每秒钟承受20次请求，还可以细化请求的种类，结合各类请求的发生频率，来制定更详尽的负载目标。
2、满意的服务质量，如在2秒内返回结果，有时写的操作时间要求可以放宽一些。
效能测试有对硬件的要求，每次测试都必须在相同机器和网络环境中，这样才能避免外部随机因素干扰。
在进行效能测试的过程中，可以得到系统效能和负载的一个对应关系，此时就可以看到能维持系统正常功能的最大负载是多少，如果负载足够大，或者过分大，那就形成了另外一种测试，也就是压力测试。
压力测试Stress Test
压力测试要验证的问题是：软件在超过设计负载情况下是否能返回正常结果，没有严重的副作用或崩溃。
对于一个购物网站来说，所有请求都能在网络超时前返回，就可以认为正常，返回系统忙的提示也被认为是正常。但是如果在这个过程中导致有些请求执行了，有些没执行，或者数据丢失，那就是异常情况。
一般要模拟几十个小时的高负载才能认为系统通过测试，因为网络的负载是有时间性的。
在这个过程中可能会暴露一些问题，如内存泄露、死锁等。
内部/外部公开测试Alpha/Beta Test
Alpha Test一般是指在团队之外、公司之内进行的测试；Beta Test指把软件交给公司外部的用户进行测试。
易用性测试Usability Test
一般由可用性工程师来实行和主导。
Bug Bash
在某一天，所有测试人员，有时也会有开发人员，都放下手里的工作，大家一起找bug，然后结束时，统计并奖励找到最多和最厉害的bug的员工。
bug bash并不是乱点，而是有规划的，bug类型可以限定，可以有探索式的思路。
测试工作中的文档
在测试时，我们要制定测试计划，写测试设计说明书、测试用例、程序错误报告和测试报告：
测试设计说明书TDS
TDS主要描述：
测试用例Test Case
根据TDS来对每一个功能点测试时，需要用到测试用例，一个功能的所有测试用例称为这个功能的测试用例集。
在实际过程中，要把纷繁的情况总结成几种类型，如几种情形下的正确输入，错误输入要求提示正常等。
测试时需要注意测试边界值。
测试时可以采用Pair-wise和正交试验设计方法，也就是将可能导致bug的因素全部列出，然后两两组合的测试。研究表明，通常只有两个因素对某个bug起关键作用，因此这种方法在一定程度上是高效的。
错误报告Bug Report
主要包括以下内容：
当开发人员修复了一个缺陷并签入代码后，一个新的构建就会包含这一个修复Bug Fix。测试人员要做的就是验证修复，验证是否已经无缺陷，或者查看是否引起其他问题。
在完成测试之后，测试人员就可以关闭缺陷报告，同时记录修复历史，有时还要将此bug做成一个测试用例，保证以后测试活动都会重新检测。
测试报告Test Report
主要报告各个功能的测试结果，如多少测试用例通过、多少失败、多少未完成、发现多少测试用例之外的bug？这个报告能帮助我们从宏观上了解还有多少事情没有完成，各个功能的相对质量如何。