语句覆盖：至少每个语句执行一次，最弱的逻辑覆盖标准。
判定覆盖：每个判定的每种结果执行一次，建立判定表之后，保证每种判定结果种都包含T和F。
条件覆盖：不但每个语句要执行一次，而且判定表达式中每个条件都要取到可能的结果，建立判定表后，要保证每种条件的结果中包含T和F。
判定-条件覆盖：每个判定及每个判定中的每个条件都取到可能的结果，建立判定表后，保证每个判定结果包含T和F，且每个条件包含T和F，也就是综合了上面的判定和条件覆盖。
条件组合覆盖：每个判定中的条件的各种组合至少出现一次，也就是说，先把程序中的条件列出来，排列组合写出所有可能性，看有没有哪些值同时满足这些排列组合。
路径覆盖：每条可能的路径至少执行一次。
白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖。
黑盒测试：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法。功能测试也称黑盒测试，只考虑各个功能，不考虑整个软件内部结构及代码。
可用性测试：用户在和系统交互时对用户体验质量的度量，由用户测试。边界测试就是找到边界，然后在边界附近（两边）选点。
如何测试一个纸杯
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
找项目性能瓶颈：
CPU分析：us: 用户进程处理占用百分比，在Java应用中如果us占用过高，代表运行的应用程序消耗了大部分CPU，常见为线程一直处理可运行状态(Runnable)，并且无阻塞地执行循环，正则或复杂计算；也可能是每次请求都分配大量内存，导致频繁GC甚至频繁FullGC造成的，这时就需要依靠jvm工具查看了(jps, jmap, jstat等) 。sy: 内核线程处理占用百分比，sy值过高表示Linux花费大量时间在线程切换上，Java造成原因通常是启动大量线程，且多数线程处理不断阻塞(如IO等待，锁等待)和执行的状态变化中，造成大量上下文切换。
文件IO分析：在Linux中文件IO主要通过 pidstat, iostat分析：pidstat -d -p java_pid 1 3。在Java应用中造成文件IO消耗严重的原因，通常是多个线程进行大量写入操作（如频繁写入日志文件）。这时可以通过pidstat或iostat结合jstack线程信息，找到消耗主体程序。
网络IO分析：在分布式Java应用中，网络IO的消耗是非常值得关注的，尤其注意网卡中断是不是均匀地分配到各CPU上(cat /proc/interrupts)。Linux使用sar分析网络IO消耗情况：sar -n ALL 1 2。主要观注接包(rxpck/s)，发包(txpck/s)，接包失败(rxerr/s)，发包失败(txerr/s)，丢包(rxdrop/s)，Socket信息(tcpsck , udpsck)。由于无法观察具体进程的网络IO消耗，在网络IO消耗高时，只能线程dump，通常这些线程都在进行网络读写操作。在Java网络通信中，通常将对象序列化为字节流发送，反序列化生成对象。
内存分析：vmstat。swpd表示虚拟内存已使用的部分(kb)，free空闲物理内存，buff表示用于缓冲的内存，cache表示用于作为缓存的内存。swap下的si表示每秒从disk读到内存的数据量，so每秒从内存写入disk的数据量。swpd过高表示物理内存不够用，系统需要频繁从虚拟内存与disk交换数据，严重影响系统的性能。sar -r 2 5。通过sar工具可以看到内存占用，空闲，buff, cache的情况。当物理内存空闲时，Linux会使用一部分内存用于buffer以及cache，以提高系统运行效率。因此可认为系统可用物理内存为 kbmemfree + kbbuffers + kbcached。此外还可以使用top, pidstat -r -p [pid][interval][times]：pidstat -r -p 2448 1 5。
如何测试网站
首先，查找需求说明、网站设计等相关文档，分析测试需求。
制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试。
功能性测试可以包括，但不限于以下几个方面：链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。提交功能的测试。多媒体元素是否可以正确加载和显示。多语言支持是否能够正确显示选择的语言等。
界面测试可以包括但不限于一下几个方面：页面是否风格统一，美观。页面布局是否合理，重点内容和热点内容是否突出。控件是否正常使用。对于必须但未安装的控件，是否提供自动下载并安装的功能。文字检查。
性能测试一般从以下两个方面考虑：压力测试；负载测试；强度测试。
数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
安全性测试：基本的登录功能的检查。是否存在溢出错误，导致系统崩溃或者权限泄露。相关开发语言的常见安全性问题检查，例如SQL注入等。如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持。
兼容性测试，根据需求说明的内容，确定支持的平台组合：浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性。
开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
定期评审，对测试进行评估和总结，调整测试的内容。
UML类图：泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
软件生存周期（Software life cycle）又称为软件生命期，生存期。是指从形成开发软件概念起，所开发的软件使用以后，知道失去使用价值消亡为止的整个过程。一般来说，整个生存周期包括计划（定义）、开发、运行（维护）三个时期，每个时期又划分为若干个阶段。每个阶段有明确的任务。
周期模型（典型的几种）：
瀑布模型：
快速原型模型：快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。
迭代模型：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。在某种程度上，开发迭代是一次 完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
生命周期阶段：软件计划与可行性分析；需求分析；软件设计；编码；软件测试；运行与维护。