3.2.2 第1步:需求分析

在任何性能测试中,第一步应该是准备好以下的任务。

从所有利益相关者那里收集或询问各种性能需求(详细说明)。这个在第2章中谈到过。为了成功创建一个项目计划或者工作说明书(SOW)都会用到这些信息。

在弄清楚其他要求之前,最起码您要同意并认可以下需求。

注释

这通常被称为范畴界定。

·为性能测试设定一个截止日期,包括已经计划好的时间安排。

·决定用外部资源还是用内部资源来执行测试。这更大程度上依赖于时间进度和自身是否拥有相应的技能。

·要有一项测试环境设计方案。记着,测试环境应该尽量接近你所能取得的真实环境,创建测试环境所耗费的时间可能会比预计的要长。

·确保在每一个测试周期中,都会把代码冻结并应用于测试环境。

·确保测试环境不会受到其他用户活动的影响。当执行性能测试的时候保障其他用户不能使用测试环境。否则,会对测试执行和测试结果造成影响。

·确定所有性能测试目标,并征求整个测试团队和测试相关人员的同意。这意味着要求整个测试团队和测试相关人员在软件的性能测试目标上达成一致。具体方法请参见第2章。

·确认软件的关键事务,并记录在案,以备录制。这是非常重要的过程。否则性能测试会面临失效的风险。

·确定事务的哪一个部分需要特别监视(比如登录或者搜索用时)。这会在第三部用于“检查点(Checkpoint)”。

·检查您所选择的事务的输入、目标、运行时数据的需求。这很重要,能够保证事务精确地录制,目标数据库在规模和内容确实得到更新。正如第2章所阐述的一样,数据对于性能测试来说十分重要。您要保证能在性能测试项目的时间框架内获取足够的准确的数据。您可能有必要参考一下某些自动化数据管理器,还有,别忘了考虑数据的安全和保密。

·验证性能测试的数目、类型、事务内容以及虚拟用户的配置。还要为每一个测试事务配置思考时间、步进以及负载生成策略。

·验证并记录服务器,应用服务器以及KPI(关键性能指标)。您必须尽可能全面地监视软件环境,以保证有可用的信息来验证并解决发生的问题。

·验证性能测试结果,并生成性能测试结果与测试目标对比的报告。最好能准备一份此类报告的文档模板。

·定义在性能测试周期中向开发人员或软件厂商提交测试环节发现的性能缺陷的步骤。这是很重要的,但是却经常被人忽视。尽管您尽了最大的努力,但是您还是发现了与主要程序相关的问题怎么办呢?您需要在自己的测试计划中嵌入意外事件处理机制,以应对这种可能性。也许还要在缺陷提交阶段加入离岸资源(即外包资源)有关的复杂性。

如果您的计划是进行内部性能测试,那么您还要满足一下几点关于测试团队的要求:

·团队成员以及汇报制度。您是否有一个专门的性能测试团队呢?这种团队经常是仓促中随便地找几个功能测试人员和其他任何可以找到的“倒霉蛋”。公正的说,如果您只有间歇的需求需要进行性能测试,那么很难断定这种团队是否是个专门的团队。然而,对于大型的公司来说,确实应该考虑组建一支由内部的测试专家组成的核心团队。

最起码要确保您有一位项目经理和足够的性能测试工程师。即使是大型的性能测试项目也不过就是需要一名项目经理和一组执行人员而已。图3-1展示了一个团队结构模型以及他与客户的联系。

·准备好性能测试中需要用到的测试工具和资源。以满足这个团队进行有效性能测试所有需求。

·确保所有成员都接受了关于所用测试工具的相关培训。很多公司之所以要将自动化性能测试项目外包出去,其主要原因就是他们缺乏使用测试工具的经验。

如果满足了上述要求,您可以继续以下活动:

·制定一个包含资源、时间点以及基于这些需求的里程碑的总体规划。

·制定一个详细的性能测试计划,包括所有相关的时间点、测试场景和测试用例、负载量,以及环境信息等。

·确保你的计划中包含风险评估,例如与时间进度偏差,性能目标未实现等,以防止实际测试与计划的偏离。

3.2.2 第1步:需求分析 - 图1

图 3-1 性能测试团队组织结构实例

技巧

如果在性能测试执行过程中发现了软件问题,您要确保计划中为额外测试环节和缺陷解决方案预备了意外事件处理机制。这种预防机制经常被人忽视。

如果完成了这些活动,那么您就可以继续其他步骤了。所有提到的事情不一定都会满足您具体的测试需求,但是事情的顺序是很重要的。

技巧

附录E中提供了一个基于微软项目的测试项目计划。