性能测试

　　性能测试涵盖的范围比较大，不过一般可以分成以下三类。

　　1、容量测试：独立测试核心功能组件的容量。例如， 可以支持多个用户并发检索？一秒种能做多少次？等等。容量测试被用来精确度量系统的极限，还可以对容量规划和系统的扩展性起辅助作用。

　　2、负载测试：侧重于系统在负载下的表现。负载应该要体现出用户所期望系统可以经受得住的流量。

　　3、压力测试：关注系统在压力下的表现。比较常用的技术是浸泡测试（soak test）；在浸泡测试中，系统会在一定的负载下持续运行一段时间，用来找出长期问题，如内存泄漏、资源泄漏等。压力测试还会覆盖故障转移和恢复，例如正在工作的集群中的一台服务器出现问题，检查是否可以做到故障转移和恢复。

　　瀑布项目直到项目接近尾声的时候才做性能测试，这个时候应用程序已经“完成了”开发，通过单元测试和功能测试。而敏捷项目则会尽快启动性能测试。

　　性能测试应该考虑以下几点：

　　1、在功能测试中设置一些性能度量，例如一个测试第一次运行要花多长时间，接下来每次又要花多久，把这些时间所占的百分比做一下比较（上升表示有问题，下降表示良好）

　　2、把一些性能测试放到系统集成持续构建中去做。

　　3、一旦一个业务过程，或是某个规模比较大的功能或接口完工，就要做性能测试。

　　4、只有在试机环境中运行的时候才签收性能测试。

　　任何测试失败都表示构建失败。

　　非功能性测试

　　非功能性测试所涵盖的范围很广，性能测试通常也属于这个话题。但是因为性能测试是企业解决方案中很重要的一部分，而且需要不同的资源和技能集，所以就被划出来单独成为一个测试阶段。非功能性测试一般都包含有这些内容：可操作性（包括监控、日志、审计/历史记录）、可靠性（包括故障转移，单个组件故障，完整故障，接口故障）以及安全性。无论瀑布项目还是敏捷项目，在这个测试阶段都会遇到重重阻碍，二者的差异不太突出。

　　非功能性测试应该考虑以下几点：

　　1、非功能性需求一般都是很难捕获的，而且即便被捕获，也很难进行度量。（例如：99.9%的无故障时间）

　　2、尽可能让所有的非功能测试都自动化执行，把它们也都放到系统集成测试环境中。

　　3、在定义测试用例的时候，让真正要监控产品环境并对其提供支持的人也参与进来。

　　4、在应用程序成为产品以后，非功能测试或监控还要继续。

　　回归测试

　　在瀑布项目中，回归测试无论从时间上还是费用上来看，都算得上是成本最高的测试阶段了。如果在项目晚期（如UAT阶段）发现了缺陷，再构建应用程序的时候，就得把所有单元测试、功能测试和用户验收测试重新运行一遍。因为大多数瀑布项目都没有自动化测试，所以回归测试的开销就很大。敏捷项目以持续构建和自动化测试来应对回归测试，使每次构建都可以进行回归测试。

　　回归测试应该考虑这一点：

　　每次迭代结束时都做一下手工测试，收集早期反馈。

　　产品校验

　　产品校验会在把产品交付给用户使用之前，审查产品环境中的应用程序，看看所有内容是否否都已经正确安装，系统的操作性如何。而有些测试还是只能到了产品环境中才能完整运行的，最好尽快将其完成。无论是瀑布项目还是敏捷项目，产品校验的方式并无二致。

　　产品校验应该考虑以下几点：

　　1、让最终用户来做产品校验测试。

　　2、趁着产品系统还没有正式上线，从这个测试阶段的早期就要尽可能多地执行自动化回归测试。

　　瀑布项目和敏捷项目的测试阶段还是很相似的，主要差异就是每个测试阶段关注的重点和执行时机。敏捷项目中有大量的自动化测试，用持续集成来减少回归测试对项目带来的影响。在瀑布项目中，如果发现应用程序的质量低下，那么在晚期再去执行前期的测试就是很常见的事情（如在UAT的时候做功能测试）。敏捷项目可以减少测试中的浪费，在早期发现问题，让团队在交付应用时增强信心。