性能测试是 Web 应用系统的一项重要质量保证措施。在现实中，很多 Web 性能测试项目由于性能测试需求定义不合理或不明确，导致性能测试项目不能达到预期目标或进度超期。本文针对 Web 应用系统的技术架构和系统使用特点，探讨如何有效实施性能测试过程，并重点介绍如何分析获得合理的性能测试需求，最终对 Web 应用系统性能进行科学、准确的评估。

1 引言

基于Web服务器的应用系统由于提供浏览器界面而无须安装，大大降低了系统部署和升级成本，得以普遍应用。目前，很多企业的核心业务系统均是Web应用，但当Web应用的数据量和访问用户量日益增加，系统不得不面临性能和可靠性方面的挑战。因此，无论是Web应用系统的开发商或最终用户，都要求在上线前对系统进行性能，科学评价系统的性能，从而降低系统上线后的性能风险。

在很多性能测试项目中，由于不能合理定义系统的性能测试需求，不能建立和真实环境相符的负载模型，不能科学分析性能测试结果，导致性能测试项目持续时间很长或不能真正评价系统性能并提出性能改进措施。

本文在总结许多Web应用系统性能测试实践经验和教训的基础上，从与性能测试工具无关的角度介绍Web应用系统性能测试的方法和实施过程，以及如何定义合理的性能测试需求。

1.1 术语定义

性能测试：通过模拟大量浏览器客户端同时访问Web服务器，获得系统的性能数据。

虚拟用户：模拟浏览器向Web服务器发送请求并接收响应的一个进程或线程。

响应时间：浏览器向Web服务器提交一个请求到收到响应之间的间隔时间。

思考时间：浏览器在收到响应后到提交下一个请求之间的间隔时间。

请求成功率：Web服务器正确处理的请求数量和接收到的请求数量的比。

吞吐量：单位时间内Web服务器成功处理的HTTP页面或HTTP请求数量。

在线用户：用户通过浏览器访问登录Web应用系统后，并不退出该应用系统。通常一个Web应用服务器的在线用户对应Web应用服务器的一个Session。

并发用户数：Web服务器在一段时间内为处理浏览器请求而建立的HTTP连接数或生成的处理线程数。当所有在线用户发送HTTP请求的思考时间为零时，Web服务器的并发用户数等于在线用户数。

1.2 Web应用系统技术架构

Web应用系统的前端为浏览器，后台为Web服务器（如Apache，Microsoft Internet Information Server），浏览器和Web服务器之间的交互基于HTTP协议。HTTP协议本身是无连接的，Web服务器通过Session机制来建立一个浏览器所发出的先后连接之间的关联。通过实验证明，当浏览器客户端在首次访问Web服务器后，如果该浏览器客户端不发送后续请求，服务器维持该浏览器客户端的Session变量所消耗的系统资源非常小。

2 Web应用系统性能测试过程

标准的Web应用系统性能测试过程包括确定性能测试需求，开发性能测试脚本，定义性能测试负载模型，执行性能测试和形成性能测试报告。本章将分别介绍上述过程，并通过举例说明如何完成每一环节。

2.1 确定性能测试需求

科学定义Web应用系统性能测试需求对一个成功的性能测试非常重要。通常，Web应用系统的性能测试需求有如下两种描述方法。

2.1.1 基于在线用户的性能测试需求

该需求描述方法主要基于Web应用系统的在线用户和响应时间来度量系统性能。当Web应用系统在上线后所支持的在线用户数以及操作习惯（包括操作和请求之间的延迟）很容易获得，如企业的内部应用系统， 通常采用基于在线用户的方式来描述性能测试需求。以提供网上购物的Web应用系统为例，基于在线用户的性能测试需求可描述为：10个在线用户按正常操作速度访问网上购物系统的下定单功能，下定单交易的成功率是100%，而且90%的下定单请求响应时间不大于8秒；当90%的请求响应时间不大于用户的最大容忍时间20秒时，系统能支持50个在线用户。

2.1.2 基于吞吐量的性能测试需求

该需求描述方法主要基于Web应用系统的吞吐量和响应时间来度量系统性能。当Web应用在上线后所支持的在线用户无法确定，如基于Internet的网上购物系统，可通过每天下定单的业务量直接计算其吞吐量，从而采取基于吞吐量的方式来描述性能测试需求。以网上购物系统为例，基于吞吐量的性能测试需求可描述为：网上购物系统在每分钟内需处理10笔下定单操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。

2.2 开发性能测试脚本

在确定Web应用系统性能测试需求后，就要根据性能测试需求中确定的功能开发性能测试脚本。比如，针对前面定义的网上购物系统的性能测试需求，将开发下定单功能的性能测试脚本。

性能测试脚本是描述单个浏览器向Web服务器发送的HTTP请求序列。每个性能测试工具（如IBM Rational Performance Tester， LoadRunner）所提供的测试脚本语法是不同的。测试人员利用性能测试工具可从头手工编写测试脚本，也可以通过录制浏览器和Web服务器之间的网络通信数据而自动形成测试脚本。

任何性能测试工具都不能保证录制形成的性能测试脚本的正确性，测试人员应通过在单用户下运行性能测试脚本对其正确性进行验证。测试脚本不正确的一个重要原因就是脚本的数据关联不正确，也就是并没完全建立一个测试请求和前面的响应内容之间的关联。测试脚本HTTP请求和响应之间的数据关联是否正确的一个重要标准是单用户运行脚本，脚本能完成期望的功能。

在完成性能测试脚本的数据关联后，需要对脚本进行参数化，也就是把脚本中的某些请求数据替换成变量，变量的值来于一个独立的数据文件，从而保证在多虚拟用户运行脚本的情况下，每个虚拟用户所提交的数据是不同的。

此外，为了测试Web应用的可靠性，还需要对请求所收到的响应进行验证（比如验证响应的HTTP返回码或验证响应的内容），便于性能测试完成后统计请求成功率。

2.3 建立性能测试负载模型

性能测试负载模型定义了测试工具如何向Web应用系统提交请求，包括向Web应用系统发送请求的虚拟用户数，每个虚拟用户发送请求的速度和频率。针对前面介绍的网上购物系统的性能测试需求，在性能测试工具中定义的性能测试负载模型应包括如下信息：

虚拟用户数：性能测试不仅仅是执行一次，而且每次执行时虚拟用户数也不固定，因此在性能测试负载模型中定义的虚拟用户数将在测试执行时进行设置。

虚拟用户发送请求的思考时间和迭代次数：虚拟用户发送请求的思考时间长短是决定Web应用系统负载量的重要因素之一，而迭代次数将决定性能测试的执行持续时间。对基于在线用户的性能测试需求，将基于录制脚本时记录的思考时间，而且由于现实中不同用户访问系统的思考时间不同，可把思考时间设置为在一定范围内的随机值。对于基于吞吐量的性能测试需求，将把思考时间设置为零，此时Web应用系统的在线用户数量将等于并发用户数。同时，为了避免性能测试压力的随机性，将增加请求的迭代次数来增加测试执行持续时间，从而获得系统在稳定压力下的性能数据。

虚拟用户启动模式：在现实中，Web应用系统的用户不太可能同时做相同的操作，因此为了让Web应用系统所承担的压力随时间均匀分布，建议虚拟用户依次启动，同时也避免大量用户同时登录造成系统阻塞。以10个虚拟用户模拟下定单为例，可设置每个虚拟用户间隔30秒启动，这样10个虚拟用户可在5分钟后完成启动，并保证10个虚拟用户不会在同一时刻下定单，从而更符合实际情况。

2.4 执行性能测试

执行性能测试是指通过多次运行性能测试负载模型，获得系统的性能数据。在执行过程中，需利用测试工具、操作系统、系统软件（如Web Server或DB Server）提供的资源监控手段对资源进行监控和分析，帮助发现资源瓶颈，并在系统层面进行优化。同时，还需对应用进行性能分析，帮助定位应用代码中的性能问题，切实解决系统的性能问题。

2.5 形成性能测试报告

性能测试项目的最后阶段就是向相关人员提交性能测试报告，汇报性能测试结果。在向相关人员汇报性能测试结果时，并不是性能测试报告越丰富、性能数据越多越好。好的性能测试报告是能准确、简单地传递性能测试结论，而不需太多的技术细节。

针对基于在线用户数的性能测试需求，可通过下图总结性能测试结论。其中横轴是在线用户数，纵轴是响应时间，如40在线用户访问网上购物系统时，90%的下定单请求响应时间不超过10秒。

图一：在线用户数和响应时间时间的趋势图

针对基于吞吐量的性能测试需求，可通过下图的曲线来描述性能测试结果。以网上购物系统为例，下图描述下定单的并发用户、下定单响应时间以及吞吐量（服务器每秒处理定单笔数）之间的关系，从而快速判断系统是否能满足性能测试需求。从下图中可看出，并发用户增加，请求的响应时间也增加。服务器的吞吐量是先随并发用户数增加而增加，当吞吐量到达一定峰值后，再增加并发用户数，吞吐量会减少。原因在于当并发用户数少时，向Web服务器提交的请求量不大，服务器处理能力还有富余，所以吞吐量逐步增大；但当并发用户数超过某一值时，由于向服务器提交的请求太多，造成服务器阻塞，反而导致吞吐量减少。

图二：响应时间、吞吐量和并发用户数的趋势图

3 如何获取合理的性能测试需求

前一章介绍了Web应用系统的性能测试过程，确定性能测试需求是整个性能测试的起点和成功的重要因素。性能测试需求定义得过高，虽然确保系统上线后能满足性能需求，但可能会造成硬件资源的浪费；性能测试需求定义得过低，系统上线后可能会出现性能问题。如何通过分析系统上线后可能的用户访问行为，来获得合理的性能测试需求指标呢？

假设现有一个基于Web的办公自动化系统（简称OA系统），该系统提供公文收发和查询功能。在部署该系统前，将对该系统进行性能测试。下面将详细介绍如何分析该OA系统的使用情况，定义合理的性能测试需求。

3.1 如何获得OA系统的在线用户数量

在线用户数量是指在特定时间区间内，有多少用户访问Web应用系统（对应到Web服务器的Session数），根据系统可能访问用户数以及每个用户访问系统的时间长短来确定。

对于将要部署的OA系统，通过分析获得该系统有8000个注册用户，基本上所有的用户每天（8小时工作时间）都会访问OA系统，平均在线时间（从登录OA系统到退出OA系统之间的时间间隔，也可以是多次在线时间的合计）为12分钟，那么该OA系统的平均在线数（也就是Web应用Session变量数）为200个（8000 * 0.2 / 8），假设峰值在线用户数是平均在线用户数的3倍（该倍数可根据实际情况调整），则性能测试需求的在线用户数为600。

3.2 如何确定OA系统的性能测试用例

由于时间和资源限制，不可能对Web应用系统的所有功能进行性能测试，而是从业务的角度（如某一功能操作的用户多）和技术的角度（如某一功能虽然访问用户不多，但内部处理逻辑复杂或处理数据量大）来选择Web应用系统的特定功能作为性能测试用例。

以OA系统为例，由于所有用户都经常公文查询功能，因此确定的性能测试用例为公文查询。

3.3 如何确定OA系统的响应时间

响应时间的快慢直接影响了系统使用用户的满意度，采用平均响应时间来描述系统系统性能测试需求是不科学的，因为无法直接和客户的满意度挂钩。而且，在做性能测试，如果某一请求的响应时间过长或过短，将导致平均响应时间和实际情况偏离。

以OA系统为例，定义的响应时间需求为：90%（该百分比和要求的系统用户满意度相关）的查询请求响应时间不超过8秒（该时间可根据实际情况确定）。

3.4 如何确定OA系统的交易吞吐量

单位时间内Web应用系统需处理多少笔特定的交易可通过统计获得。以OA系统为例，假设每个用户每天（一天按8小时计算）平均会查询公文4次，那OA应用的Web服务器平均每分钟要能处理8000 * 4 / ( 60 * 8 ) = 66.67笔查询公文交易，考虑到峰值因素，要求每分钟能处理66.7 * 3=200笔查询公文交易。

3.5 OA系统性能测试需求描述

通过前面的分析，能明确定义合理的性能测试需求。OA系统性能测试需求定义如下：

基于在线用户数的性能测试需求：600个在线用户按正常操作速度访问OA系统的查询公文功能，所有查询请求的成功率是100%，而且90%的查询请求响应时间不大于8秒。

基于吞吐量的性能测试需求：OA系统在每分钟内需处理200笔查询公文操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。

4 总结

Web应用性能测试项目成功的关键不在于性能测试工具，而在于有效的性能测试分析方法和实践。只有切实掌握性能测试需求分析方法，性能测试实践经验，才能保证一个Web应用性能测试的成功。

1、测试项目：删除

　　测试方法：对已拨/已接/未接/拒接中的电话记录进行单条删除和全部删除操作，当电话记录达到最大容量时，手机自动删除最老的记录，并且保存最近的电话记录。

　　判断标准: 手动删除操作能够实现，而且当电话记录达到最大容量时，能够自动删除最老的记录，并且保存最近的电话记录。

　　2、测试项目：保存

　　测试方法：对已拨/已接/未接/拒接中的电话记录进行保存操作?

　　判断标准: 电话记录保存操作能够实现。

　　3、测试项目：呼叫

　　测试方法: 对已拨/已接/未接/拒接中的电话记录进行呼叫操作?

　　判断标准: 电话记录呼叫操作能够实现。

　　4、测试项目：发信息

　　测试方法: 对已拨/已接/未接/拒接中的电话记录进行发信息操作。

　　判断标准: 对电话记录能够实现发信息操作。。

　　5、测试项目：存储空间确认

　　测试方法: 正确显示存储空间总量，并且区分已用空间、未用空间。

　　判断标准: 能够正确显示存储空间容量。

　　6、测试项目：通话计费

　　测试方法: 在网络的支持下，是否能查询最近一次通话和总通话的通话话费；必须可以对通话话费进行清零重计费操作

　　判断标准: 在网络的支持下，可以实现通话费用的查询及清零重计费操作

　　7、测试项目：通话计时

　　测试方法: 查看手机是否能保留上次通话时间、所有呼入通话时间、所有呼出通话时间、和全部通话时间?

　　判断标准: 必须能够保留各类通话时间。通话过程中必须正确显示通话所持续的时间。

1、 测试项目：编写短信

        测试方法： 进入新短信菜单，选择输入法，进行编辑。

        判断标准：所有的输入法都能实现，必须包含智能拼音、英文、字母、数字、标点符号的输入模式，如果有笔划输入，其功能也须能实现。

        2、测试项目：发送短信

        测试方法：编辑好短信息后，按确认键，然后输入对方号码或者从电话本中选择号码，按确认键进行发送（前提条件：必须正确设置短信中心号码）。

        判断标准： 短信能够成功发送并要有保存提示或自动进入已发信箱，建议能够实现短信群发。

        3、测试项目：删除短信

        测试方法： 在收件箱中，选择某条短信，按选项菜单，选择删除项，再按确认键。

        判断标准： 能够删除所选短信。

        4、测试项目：锁定短信

        测试方法： 在收件箱或者发件箱中选取某条短信息，然后选择发送到锁定箱。

        判断标准： 发送成功后，锁定箱中必须有已经选取发送的信息；在收件箱或发件箱中将短信删除，锁定箱中相应的短信必须存在。

        5、短信设置

        (1) 测试项目：短信中心号码

        测试方法： 输入短信中心号码（例如：宁波地区的短信中心号码为：+8613800574500）。

        判断标准： 能实现输入、修改、删除和保存操作。

        (2) 测试项目：语音中心号码

        测试方法： 输入语音中心号码（需要网络申请）。

        判断标准： 能实现输入、修改、删除和保存操作。

        (3) 测试项目：状态报告

        测试方法： 进行状态报告开关设置。

        判断标准： 能够实现开关选择设置。

        (4) 测试项目：有效期限

        测试方法： 进行短信保存期限的选择。

        判断标准： 能够实现有效期限的设置并能保存。

        6、测试项目：回复短信

        测试方法：在收件箱中选择某条短信，在短信选项中选择回复，然后进行编辑，确认后发送。

        判断标准：能够实现短信的回复操作。

        7、测试项目：转发短信

        测试方法：在收件箱中选择某条短信息，在短信选项中选择转发，然后进行编辑，并输入第三方的号码或者从电话本中选择号码，按确认键进行发送。

        判断标准：能够实现短信的转发。

        8、测试项目：短信排序

        测试方法：进行短信按时间进行正排序和反排序的选择。

        判断标准：短信排序完成后必须按照所选择的排序方法进行排序。、

1、 测试项目：编写短信

        测试方法： 进入新短信菜单，选择输入法，进行编辑。

        判断标准：所有的输入法都能实现，必须包含智能拼音、英文、字母、数字、标点符号的输入模式，如果有笔划输入，其功能也须能实现。

        2、测试项目：发送短信

        测试方法：编辑好短信息后，按确认键，然后输入对方号码或者从电话本中选择号码，按确认键进行发送（前提条件：必须正确设置短信中心号码）。

        判断标准： 短信能够成功发送并要有保存提示或自动进入已发信箱，建议能够实现短信群发。

        3、测试项目：删除短信

        测试方法： 在收件箱中，选择某条短信，按选项菜单，选择删除项，再按确认键。

        判断标准： 能够删除所选短信。

        4、测试项目：锁定短信

        测试方法： 在收件箱或者发件箱中选取某条短信息，然后选择发送到锁定箱。

        判断标准： 发送成功后，锁定箱中必须有已经选取发送的信息；在收件箱或发件箱中将短信删除，锁定箱中相应的短信必须存在。

        5、短信设置

        (1) 测试项目：短信中心号码

        测试方法： 输入短信中心号码（例如：宁波地区的短信中心号码为：+8613800574500）。

        判断标准： 能实现输入、修改、删除和保存操作。

        (2) 测试项目：语音中心号码

        测试方法： 输入语音中心号码（需要网络申请）。

        判断标准： 能实现输入、修改、删除和保存操作。

        (3) 测试项目：状态报告

        测试方法： 进行状态报告开关设置。

        判断标准： 能够实现开关选择设置。

        (4) 测试项目：有效期限

        测试方法： 进行短信保存期限的选择。

        判断标准： 能够实现有效期限的设置并能保存。

        6、测试项目：回复短信

        测试方法：在收件箱中选择某条短信，在短信选项中选择回复，然后进行编辑，确认后发送。

        判断标准：能够实现短信的回复操作。

        7、测试项目：转发短信

        测试方法：在收件箱中选择某条短信息，在短信选项中选择转发，然后进行编辑，并输入第三方的号码或者从电话本中选择号码，按确认键进行发送。

        判断标准：能够实现短信的转发。

        8、测试项目：短信排序

        测试方法：进行短信按时间进行正排序和反排序的选择。

        判断标准：短信排序完成后必须按照所选择的排序方法进行排序。、

序号	测试项目		测试方法	判断标准
1	查找	按姓名查找	选择输入法，输入所要查找的号码对应姓名中的第一个、前二个、前三个至全部显示的字或字符，然后按OK键（例如：号码对应的姓名为w王小方，如果输入字符w，可以查找到以w开头的所有电话记录；如果输入w王，则可查找到以w王开头的所有记录；依次类推，如果输入w王小方，便可直接查找到相应的电话记录）。	能够查找到所有符合查找条件的电话本记录；建议支持模糊查找。
		按位置查找	数字输入法输入号码的排列号，然后按OK键	能够查找到所有符合查找条件的电话本记录。
		按群组查找	选择号码所在的群组，按OK键	能够进入相应的群组进行选择
		按号码查找	输入想要查找的号码中任意一个或一串数字，按OK键	能够查找到所有符合查找条件的电话本记录；必须支持模糊查找。
2	新建		选择保存路径：SIM卡或话机后，进行姓名、号码、群组等编辑，然后保存退出。	编辑的号码能够保存到指定的存储位置。如果SIM卡或者话机内存已满，再存入新建记录时，必须出现相应的溢出提示
3	删除		对一个电话记录或者全部电话记录进行删除操作。	将电话记录删除，全部删除时必须有相应的确认提示。
4	复制		将SIM卡中的电话记录复制到话机中，或者将话机中的记录复制到SIM卡中。	检查所复制的号码必须成功复制到指定的位置；必须保证能够实现单条复制和全部复制。
5	转移		将SIM卡和话机中的电话记录进行相互转移。	检查所转移的号码必须成功转移到指定的位置；必须保证能够实现单条转移和全部转移。
6	群组		在此菜单中，将电话记录分为不同群组，并选择相应的图标或来电铃声。	某个群组中的来电具有相应的图标或铃声。
7	本机号码		在此菜单中，编辑本话机所对应的SIM卡的姓名和号码，并进行保存。	必须能进行编辑和保存。
8	可用空间		在此菜单中，能够查询SIM卡和话机的电话存储总容量和已用空间	能够正确显示存储状态
9	快速拨号		1、选择任一数字键0～9，然后从电话本中选出所要的号码，设置好后，保存返回； 2、按1～N加＃，再按发射键可以按位置进行快速拨号(N＝1，2，3，4，……，最大可以取话机和SIM卡的存储容量之和，具体视SIM卡和手机而定)。	1、长按某数字键，能够实现号码的拨叫。 2、能够实现该方式的快速拨号。
10	固定拨号		设定固定拨号的号码，然后进行拨号（呼叫已设定的号码和其它号码）	只能拨打设定的号码，而不能成功呼叫其它号码（需要网络）
11	发信息		选定某一个电话记录，进行信息（包括SMS、EMS、MMS等）的编辑和发送	必须能实现所编辑信息的发送

总结以往进行的性能测试，虽然测试人员自始至终对测试工作都做到了认真负责，但测试报告出炉后，大家总觉得美中不足，对测试结果都心存疑虑，尤其在那些时间跨度较长、针对不同的测试对象的性能对比测试中，或多或少都存在以下几个方面的问题：

　　1. 测试准备不充分，测试目标不明确，测试计划不详细；
　　2. 缺乏测试以及针对测试对象的技术储备；
　　3. 测试环境的稳定性及前后一致性不足；
　　4. 测试数据精确性和代表性不足；
　　5. 测试描述不精练；

　　下面，我们就剖析以上问题的同时，探讨一下如何解决这些问题。

　　性能测试准备

　　这是一个经常被测试人员忽略的环节，在接到测压任务后，基于种种其它因素的考虑，测试人员往往急于进度，立即投入到具体的测试工作去了，测试、记录、分析，忙的不亦乐乎，工作进行了一半才发现，或是硬件配置不符合要求，或是网络环境不理想，甚至软件版本不对，一时弄得骑虎难下，这都是没有做好测试准备惹的祸。那么我们应该如何做好性能测试的准备工作呢？

　　做软件项目有需求调查、需要分析，我们做测试也一样。在拿到测试任务后，我们首要的任务就是分析测试任务，在开始测试前，我们至少要弄清以下几个问题：

　　a) 要测试什么或测试的对象是谁？
　　b) 要测试什么问题或我们想要弄清楚或是论证的问题？
　　c) 哪些因素会影响测试结果？
　　d) 需要怎样的测试环境？
　　e) 应该怎样测试？

　　只有在认真调查测试需求和仔细分析测试任务后，才有可能弄清以上一系例的问题，只有对测试任务非常清楚，测试目标极其明确的前提下，我们才可能制定出切实可行的测试计划。

　　明确测试目标,详尽测试计划

　　在对测试需求充分了解的基础上，制定尽可能详细的测试计划，对测试的实施是大有裨益的。测试计划的制定，大多专业的测试书籍多有详述，故本文不再鏊述。

　　测试技术准备

　　在目前的大环境下，要求测试人员在短时间撑握所有的软、硬件知识是不太现实的，但平时测试人员应抓紧对测试工具和测试理论的研究，在测试计划中，应给研究测试对象和测试工具分配充足的学习时间，只有在充分撑握测试工具，完全了解测试对象的前提下，我们才能够实施测试。建力在错误的认识上的测试，既使你再努力，结果也是背道而驰，也很难证明问题，更不用说用这样的测试报告去说服用户。

　　配置测试环境

　　只有在充分认识测试测试对象的基础上，我们才知道每一种测试对象，需要什么样的配置，才有可能配置一种相对公平、合理的测试环境（这在性能对比测压中尤其重要）。

　　考虑到其它因素，如网络锁、网速、显示分辩率，数据库权限、容量等对测试结果的影响。如条件允许，我们最好能配置几组不同的测试环境。

　　测试数据的获取和处理

　　在所有的测试中，测试数据的收集工作都是较为困难的，Gis软件更是如此，每一种软件都有它的文件格式，有的软件还有几种格式。在这种情况下，我们只能把第三方格式的数据转换成每一种被测试软件自已的格式。同时，还应对数据作一定的处理，如处理数据冗余，处理显示风格等。如在测试时会更新数据，操作前一定要备份数据。 其外，还应评估数据格式和数据量对测试的影响，如有必要，应准备多组数据。

　　最后，一定要检查测试数据的有效性，避免损坏数据对测试结果的影响。

　　如何开展性能测试

　　测试前期的准备工作纷繁复杂，做好测试准备工作，已是完成了测试工作的一大半，但要产生一份具有说服力的测试报告，还应正确把握测试的强度，保持测试的一致性，提高测试的精度。

　　判断软件的好坏，要看软件解决实际应用的能力，只有在一定的测试强度下，才能测试出各种软件资源的消耗率，软件运行的速度，软件的稳定性。通过对比在不同的测试强度下，不同软件每一个功能模块解决实际问题的能力和软件运行的效率，我们才可能判断出不同软件的每一个模块的强弱，甚至于整个软件的优劣。

　　性能测试开始后，所有参数的输入都应遵循统一的标准，无论是哪一个环节，哪怕是一点点偏差，都应立即纠正，觉不能心存侥幸。要特别注意外部环境对测试结果的影响，如果在整个测试过程中，外部境不一致，如网速、机器内存使用率不一样，就有可能导制测试结果与实际情况有出入。

　　如何总结性能测试

　　对测试的终结，实际就是对测试数据的分析和处理。我们测试工作做的再好，如最终到用户手中的是一堆杂乱无章的数据，那也是美中不足。

　　首先，我们最好从所有的测试数据中，筛选出具有代表意义的数据，做出统计图，然后和开发人员一起，认真分析数据，找出软件存在的问题，得出测试结论。大多数用户，真正需要的就是科学、客观的测试结论。

　　结论

　　各种软件性能测试，范围大小不同，强度高底有别，但只要本着认真、客观，科学的工作态度，遵循本文论述的方法，做好测试工作是不难的

1.什么是性能测试
性能测试是用来测试软件在系统中的运行时能力，特别是针对实时系统和嵌入式系统。性能测试可以在各个测试阶段进行，但进行的目的各有不同，有诊断性质的，有调优性质的，还有检测性质的。但对于一个系统真正的性能测试只有在系统集成测试阶段执行。性能测试的目的一方面是为了检验系统的性能是否符合要求，另一方面也是为产品的宣传提供有力的数据。
2.性能测试的分类
a。一般意义的性能测试
这类的性能测试一般单指响应时间的性能测试，如正常用户操作时客户端的响应时间
b。强度测试
强度测试需要在反常数量、频率或资源的方式下运行系统，以检验系统能力的最高实际限度，它要求软件必须被强制在它的设计能力的极限状态下运行。
c。软件可靠性测试
测试要需持续一夜，一周，或者几周的时间，目标是发现短序列测试遗漏的错误。这种测试经常发现的错误包括越界指针，内存泄漏，栈溢出，超过两个特性之间的错误交互等，也称长序列测试，持久测试，耐力测试。一般的软件平均无故障时间是一个最为重要的可靠性指标。
3.性能测试的方法
a。测试人员与应用交互的过程中，应该知道应用的响应是否缓慢，这些BUG是基于常识性知识的。不指出问题的所在，而只是警告问题的
存在
b。观察测试
这种测试使用某些工具给出确切的数据，如使用秒表等工具以便给出更为清晰的概念
c。第三方测试
使用专业的性能测试工具
4.性能测试策略
a。识别系统组件
        画一个网络结构图阐明应用程序的结构，包括所有的系统组件，如：客户端机器，网络，中间件，服务器等等。
b。描述系统配置
        客户端机器的配置(硬件、内存、操作系统、开发工具等)
        数据库类型，网络服务器种类
        中间件配置
        通信设备的吞吐量
c。分析使用模式
        定义系统怎样有代表性的使用，决定哪几个功能对于测试是最重要的、考虑谁用系统、各种类用户的数目、各用户的常用任务、另
外也要考虑影响系统反应时间的背景负载(所谓的背景负载就是在执行测试任务之前，运行于系统之内的进程所带来的负载)
d。确定任务分布状态
        分析任务分布决定什么时候有峰值的数据活动，确定系统最大压力产生的时间段，依据该时间段设计测试策略
        如该图显示的10点到12点，登录事务就由220增加到250，下午2点下降到210，那么10点到12点这个时间段就是一个高峰，对方案进行
        设计的时候就要考虑到这个因素。设计测试数据应尽量遵从从小到大的原则。如：
        要测试一个系统能够承受登录时的最大并发数，就要采取先假设10个，然后到20，然后到30，随着数字的增加就要减小增加的幅度，
也许是500、501、503这样一直下去。才能准确的确定真正的能够承受的最大并发数。
反面教材：
没有针对性的性能测试场景
例一：
针对各个条件的查询各自录制了一个脚本，然后又单独执行了个脚本5～10次。
结果：没有针对性，其本身目的是为了测试服务器所能承受的负载，这种测试场景完全不能达到我们当初的目的。
例二：
oracle两层数据库结构应用程序，但取数据的时候是从文件服务器而非数据库服务器读取，虽然也涉及到了数据库的一些操作。
结果：测试结果良好，但实际测试场景并不能完全反映读取数据时文件服务器的压力情况

按照产出的文档，介绍项目开发过程中的工作步骤
        1． 测试计划：这个计划，我个人觉得应该在详细设计确定后，代码开始编写的时候进行制定，因为我是“提早开始测试工作”思路的忠实fans，虽然现在项目里都只有我一个人在这么早开始工作。。。-_-///
        a)         测试计划，主要是给后面的测试工作一些指南，不能写成领导看的计划，而是要写成由做事的人看的计划
        b)        包含的内容可能有：
        i.              测试团队人员及分工（要确定当测试时出现缺陷界定、测试环境准备等问题时能找到指定的人员）
        ii.              测试开始结束时间（理想情况下，不要安排的太紧，赶工肯定会造成延期或测试不完整，可惜理想和现实的差距被规定为很大）
        iii.              测试环境配置（什么样的硬件条件，是否网络、设备等，系统在什么地址访问，访问权限、使用的测试数据等方面的预计和准备）
        iv.              测试哪些东西要说清楚，这里我建议把简单的测试大纲纳入测试计划中，一方面领导可以看到你的计划写的多详细，另一方面大纲可以很好的成为编写用例的依据
        v.              怎么测试要说明白，如只做系统测试，那就要写清楚不做集成测试，如果需要集成测试，就需要写明白集成顺序。另外如果需要进行性能、文档、等其他的测试也要在这个计划中写明，虽然一般这个计划都是针对功能测试，但是如果有其他测试，也要写出来并安排时间，相应测试的相关计划等也需要指明
        vi.              测试结束标志（要说明测试达到什么程度可以结束测试，不能等到把所有缺陷都找出来以后才结束，因为那将是一万年），允许缺陷存留在系统里，我们只需要找到留多少这个度就够了
        2． 测试用例：这个文档，主要描述具体的测试步骤，但实际应用中，至少目前我的项目里，由于时间的原因，很少有写的，就算写了的，也基本没有用到测试里，在这边的很多项目大都是直接来测，全凭我个人的经验来检查（在此感谢领导们对于我二把刀技术的信任_@_）。但是我想说其实他很重要，也许你不需要写的很详细，但是绝对需要通过这样的步骤来理顺思路，这个文档的好坏和实用程度，直接可以决定你是否能“用最少的工作（量和时间），尽早的发现尽可能多的缺陷”，写这个文档需要用到一些测试方法理论，如等价类划分、边界值、这个表那个表（汗。。。忘记了）
        3． 缺陷记录：是功能测试过程中使用频率最高的文档，用于在测试过程中记录发现的缺陷，并由开发人员作为修改缺陷的依据，以及修改后测试人员进行回测的主要依据
        a)         该文当也有助于分析开发人员存在的“错误集群”现象，总结易出错的地方，对缺陷多的部分做更深入的测试，并提醒开发人员避免缺陷
        b)        缺陷记录填写指南：
        i.              缺陷级别（即严重程度），一般由公司统一定义，为发现的缺陷进行分类，以便决定修改的缓急
        ii.              bug分类：区分发生的位置，是功能的，还是性能的，是有效性问题 还是其他问题等，与bug级别一起，用于决定bug的修改要求度
        iii.              bug状态：是标志bug的当前情况，标识是否被处置（关闭状态），
        iv.              上述这些指标一般由公司统一定义（一般标准都大同小异），也会用于项目的度量
c)        缺陷记录使用时的注意点：
        i.              描述bug要有三要素：在哪里，什么情况（前提）下，发生了什么样的问题
        ii.              可以借助截图、引用位置、模块等方式来描述bug，目的是让开发人员能够通过您的描述立刻马上能够重现bug，即使不能重现，也能让开发人员了解到错误的所在
        iii.              缺陷报告要由开发人员和测试人员共同完成，测试人员要督促开发人员填写该表以便测试后续的回测工作
        iv.              如果是在执行用例的同时填写bug报告，用例的最后一列一般可以填写用例的执行结果，如果用例发生了非期望的结果，那么就要把问题记录在缺陷记录中，此时可以在缺陷记录中引用该用例的编号
        4． 测试总结报告：用于报告和总结项目测试工作的执行结果，列举和统计相关测试数据，对比分析数据即工作中存在的问题为后续工作做出提示，并记录遗留的问题等
        a)         总结报告的还有一个功能就是告诉项目组成员该系统已经按照测试计划的要求进行了测试，并已经达到测试计划中说明的“测试结束条件”，可以证明系统已经达到测试计划所期望的质量
        b)        这份测试总结需要记录项目所有测试的结果情况，除了功能测试外，性能测试也会被包含在内。

摘要】本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。鉴于国内的软件开发、测试不规范的现状，本文为软件测试新手提供了若干个软件测试的关注点。

【关键词】软件测试、测试用例、测试需求、测试结果分析

•  测试准备工作

在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢？

•  向有经验的测试人员学习

如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方式固化到流程中。

如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。

•  阅读软件测试的相关书籍

现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。

•  走读缺陷跟踪库中的问题报告单

如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。

•  走读相关产品的历史测试用例

如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。

通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。

总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。

•  学习产品相关的业务知识

软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。

因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。

•  识别测试需求

识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法：

•  主动获取需求

开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。

当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析：

软件输入： 与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。

处理过程： 描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。

软件输出： 描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中，这部分内容作为测试用例的预期输出。

性能要求： 与该需求相关的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制，就是对需求的基本性能要求。

运行环境： 软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。

•  确认需求的优先级

确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。如果软件公司有规范的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？如果是这样，需求的优先级只能由测试人员完成了。

•  加入开发小组的邮件群组

测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如果公司里面有自动化办公系统，也许采用的是 Lotus Notes 系统，也许使用的是 E-mail 系统，测试人员应该加入到开发人员的邮件群组中。当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程，加入到开发邮件群组也是一个很好的习惯。

•  与开发人员为邻

建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能第一时间获得信息。无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司内部都存在部门墙，良好的人际关系是打通部门墙的手段之一。向领导建议测试人员与开发人员为邻，这很必要。

•  测试用例设计

测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：

•  测试用例的基本格式

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。

用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，

测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。

•  重用同类型项目的测试用例

如果我看得远，那是因为我站在巨人的肩上 －－牛顿。

一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。

•  利用已有的软件 Checklist

在上面一个小节中，按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试规范，比如， WEB 软件系统在系统测试过程中，会有一系列的范式，比如针对 Cookie 就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国内外的网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。

•  加强测试用例的评审

测试用例设计完毕后，最好能够增加评审过程。同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。 如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

•  定义测试用例的执行顺序

在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。

•  测试用例执行

测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：

•  搭建软件测试环境，执行测试用例

测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。

如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。

•  测试执行过程应注意的问题

测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：

全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。

加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。

与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

•  及时更新测试用例

测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。

总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

•  提交一份优秀的问题报告单

软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。

软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。

硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。

测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。

输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。

日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。

根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。

•  测试结果分析

软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。