这是pareto原则应用于软件测试，也包括性能测试，即性能测试发现的错误中的80%很可能集中在20%的程序模块中。

　　(3)穷举测试是不可能的

　　在性能测试中不可能覆盖每一个功能部分，这也意味着有性能问题的模块可能被忽略掉，这样的话，我们在设计性能测试案例时，应该采取一些策略和技巧，使用尽可能少的性能测试用例，发现尽可能多的bug。这方面内容我们将在本书的第10章中介绍。

　　在具有软件测试共性的同时，性能测试也有自身的一些特点。

　　1.性能测试不是功能测试

　　性能测试不要求也无法做到覆盖软件所有的功能，通常我们只是对系统中某些功能或模块做性能测试。一般的，我们在选择性能测试案例时需要遵循以下的原则：

　　(1)基本且常用的

　　比如，一个E-mail系统，基本且常用的功能有注册、登录、收邮件、查询邮件，用户使用这些功能的频率较高，要做性能测试。而高级查询、过滤器、邮件列表等功能被使用的次数较少，可以不做性能测试，或者进行性能测试的优先级低一些。

　　(2)对响应时间要求苛刻的

　　这样的要求经常出现在金融和电信等对实时性要求比较高的系统中。比如，从手机呼叫开始，经过基站、核心网，再到被叫手机响铃，整个系统的处理时间应该在用户能接受的范围内。另外，一个负责和手机通信的基站在发生故障或掉电后，要能很快地恢复工作状态。这些功能都对时间有着严格的要求，一定要做性能测试，当然实际运作时，电信系统上线时所做的性能测试不仅于这些功能。

　　将这些功能细分是性能测试中的事务(Transaction)。关于事务这个概念我们在后面的章节中将详细阐述。

　　2.性能测试属于系统级测试

　　从V型图可以看到，性能测试属于系统级测试。那么性能测试是基于单元测试、集成测试、功能测试等都已经完成的基础上，站在用户的角度去测试整个系统的。这包含两个含义：

　　第一，性能测试是“两头在外”，软件性能需求不仅直接来自用户，终目的也是服务于用户。通过性能测试这个过程，从上面我们讲到用户的需求和性能测试指标的对应关系，可以看出。

　　第二，性能测试开始的必要条件是软件系统已经处于一个比较稳定的状态，系统架构、主要代码、中间件等都不再有大的变化，否则会给性能测试带来很大的风险。

　　思考

　　基于以上事实，我们应该在软件流程什么阶段开始性能测试?结合自己的实际工作进行分析。

　　1.2.2 性能测试策略揭秘