黑盒测试：黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。
白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
黑 盒测试技术 ，使用最广的用例设计技术——等值分析测试=等价类划分+边界值分析测试
白盒测试技术
六种覆盖方法中，覆盖准则由弱到强依次是语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。
其中，
语句覆盖是使得程序中每个语句至少被执行一次；
判定覆盖是使得程序中的每个分支至少都通过一次；
条件覆盖是使得判定中的每个条件获得各种可能的结果；
判定/条件覆盖是使得判定中的每个条件取到各种可能的值，并使每个判定取到各种可能的结果；
条件组合覆盖是使得每个判定中条件的各种可能组合都至少出现一次；
产品修正了bug或增加了功能，生成新的版本，对这个版本进行测试，就叫做回归测试。
保证变化没有对产品原有功能造成破坏，最可靠的方式是对产品进行全面的测试。还有一个方法是只对修改部分的相关部分进行测试，这是一种折中的方法，因为进度、成本的原因，这也是经常被采用的方法，这个方法有一定的风险，因为准确的确定产品修改部分的相关部分往往很有难度，范围不好确定。具体采用哪种回归方式，要由这个产品的质量要求、人力资源、时间进度等因素来决定。
测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。
• 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
• 集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
• 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
• 系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
条件覆盖CC（Condition Coverage），设计足够多的测试用例，运行被测程序，使得每一判定语句中每个逻辑条件的可能取值至少满足一次。条件覆盖率的公式：条件覆盖率=被评价到的条件取值的数量/条件取值的总数X100%[1] 条件覆盖的缺点：只考虑到每个判定语句中的每个表达式，没有考虑到各个条件分支（或者涉及不到全部分支），即不能够满足判定覆盖.
条件组合覆盖，也称多条件覆盖MCC （Multiple Condition Coverage），设计足够多的测试用例，使得每个判定中条件的各种可能组合都至少出现一次（以数轴形式划分区域，提取交集，建立最少的测试用例）。这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。满足条件组合覆盖一定满足判定覆盖、条件覆盖、判定条件覆盖。条件组合覆盖率的公式：条件组合覆盖率=被评价到的条件取值组合的数量/条件取值组合的总数条件组合覆盖的缺点：判定语句较多时，条件组合值比较多。
语句覆盖 SC（Statement Coverage），就是设计若干个测试用例，运行被测程序，使得程序中每一可执行语句至少执行一次。这里的“若干个”，意味着使用测试用例越少越好。语句覆盖在测试中主要发现缺陷或错误语句。
判定条件覆盖CDC（Condition/ Decision Coverage），设计足够多的测试用例，使得判定中的每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果也至少出现一次。[1] 判定条件覆盖率的公式：条件判定覆盖率=被评价到的条件取值和判定分支的数量/（条件取值总数+判定分支总数）.判定条件覆盖的缺点：没有考虑单个判定对整体结果的影响，无法发现逻辑错误。
系统集成测试主要包括以下过程：
构建的确认过程。
补丁的确认过程。
系统集成测试测试组提交过程。
测试用例设计过程。
测试代码编写过程。
Bug的报告过程。
每周/每两周的构建过程。
点对点的测试过程。
组内培训过程
术语说明：
QPS = req/sec = 请求数/秒
【QPS计算PV和机器的方式】
QPS统计方式 [一般使用 http_load 进行统计]
QPS = 总请求数 / ( 进程总数 * 请求时间 )
QPS: 单个进程每秒请求服务器的成功次数
单台服务器每天PV计算
公式1：每天总PV = QPS * 3600 * 6
公式2：每天总PV = QPS * 3600 * 8
服务器计算
服务器数量 = ceil( 每天总PV / 单台服务器每天总PV )
【峰值QPS和机器计算公式】
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
问：每天300w PV 的在单台机器上，这台机器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
问：如果一台机器的QPS是58，需要几台机器来支持？
答：139 / 58 = 3
测试驱动开发，英文全称Test-Driven Development，简称 TDD ，是一种不同于传统 软件开发流程 的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。
TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
TDD的基本思路就是通过测试来推动整个开发得进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。
TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。
alpha测试都不是太正规的一种测试，它属于用户体验性测试，alpha测试是测试环境尽量真实,由软件公司内部人员模拟各类用户对即将面世的软件产品进行测试, 测试人员在一旁记录发现的问题和缺陷；对于软件项目来说,在系统测试后,有验收测试(有用户参与);对于软件产品来讲,在系统测试后,有 alpha和beta测试。
人工测试：个人复查、抽查和会审，机器测试：黑盒测试和白盒测试
【软件需求】是软件开发之前做好的，软件开发是根据这个做的，那么软件测试自然也需要参考该文件 【迭代计划】是软件的某个周期的计划，自然也需要参考 【可行性】是软件开发前做好，用于证明该计划可行的，没有必要参考