要做好性能测试，该掌握哪些内容

WEB测试大纲

相信做测试的大部分朋友都有同感，在很多时候，我们都要面临没有文档或文档混乱，残缺的系统进行测试，而这时往往距离系统提交的时间只有几周了。那么，这时我们应该如何确定测试需求呢？先放下心中的愤懑，让我们讨论一下。

   对一个系统而言，就算是你对它一无所知，仍然可以对界面和普通功能点进行测试，比如添加，删除等。但这对一个系统而言是远远不够的，是否实现它预期的需求才是测试工作的重心。如果不是因为时间的限制和这个系统的提交不需要你负责，你要坚持你自己的意见，而不是听从所谓的功能基本都实现了。  

    首先，去发现需求。这时你要把自己想象成一个侦探。所测试的这个系统现在它要满足什么需求，并以此建立这个时间的测试需求版本。实际上，系统的开发也许已经经过了几个版本了，每个版本都有实现的需求，有些很重要，有些次之。现在，你是要尽可能的全部找出它们。

第一步：收集数据。

    1、阅读文档。如果你手头还是有一些文档，不管它的版本是多么老或者残缺不全都比没有要好，它总会给你提供一些需求的线索。也可从用户手中得到的一些用户文档或发行的媒体文件。一般用户在系统设计之初都会给当时的调研人员留下一些纸制或电子类的文档以表述他们的系统需求期望。如果你的项目经理已经遗失了这些资料，用户那里一般也有备份。但你需要一种婉转的方式去询问，以免给用户造成系统是否不能正常完成的印象。这些可以帮你对这个系统总体来说应该要满足那些重要的功能提供资料。

    2、检查系统的体系结构。找一些对这个系统体系结构比较了解的人解释给你，并告诉你为什么系统是这样的体系结构。我们常常能从定义系统能力的最高层的限制中发现一些薄弱的连接。如果你本身就有一些系统体系结构方面的知识，这方面的工作应该不是很困难。

    3、执行程序。检查程序的执行，在每一个页面中检查功能是否能够全部实现，在此可以找出它是否存在一个上一个结点和下一个结点。做上记录。然后根据页面的标题和节点之间的逻辑推理，可以大致判断出有几个业务流，它们涉及哪些相关节点。哪些页面之间存在数据联系。

    4、询问开发者。这是一个比较头痛的问题，如果开发人员正忙于赶工期，他们对你的轻视可能导致你的询问很难有所成效。所以，你要尽量的提问得仔细，问题最好用是这样或不是这样回答，以免因为他们不想对你解释太多而敷衍你。所以，你要尽可能的做好前面的工作，而不是依赖于开发人员。首先，你需要在项目经理那里得到开发人员所做的模块清单。哪些模块被几个开发人员同时操作，找出现在的负责人。然后，整理出自己所知道的模块信息，与开发人员交流。如果你对这件事感到委屈，那么至少有两个方面你需要加强，一是学会善于沟通，与开发人员相处融洽。二是努力学习，获得足够的知识与开发人员平等交谈。

    5、询问项目经理

   项目经理是一个能给你提供自己最大帮助的人，因为这个测试可能往往就是他要求的。你在那里尽可能的去找出有关系统的信息和资料。如果他不配合你，那么这个系统可能存在着某些巨大的问题导致也许根本无法交付。所以你需要花更多的时间来做工作。

   当你找到这些需求资料时，你应该没有责备过任何一个人，因为在那个时候，他们做了他们的工作，你不能去要求人们以前应该做什么。现在你拥有的优势超过了项目中的其他人，你不需要被他们的假定迷惑。你可以更客观的去看待这个系统，并且比较它和设计的初衷有什么不同。

第二部，将资料转化为系统需求。

    现在你有一些经过整理的材料，可以将它们转变为需求了。每个一个功能在不同的人那里可能有不同的说法。当你浓缩它们并定义它们这些说明的价值将变得非常清晰。我们想确定每一个说明的本质。这说明是否相关角色，特性或功能？

    首先确定你能够安排的工作时间，根据时间按主要和次要安排需求。然后可按以下步骤来整理：

    1、确定系统拥有多少角色（业务），他们负责什么样的工作，在系统中体现在那些模块中。然后画出这些角色的用例，或者他们涉及的业务。一般来说，系统很少有角色会全程做完一个业务流程。你可以先把每一个角色所做的每一个功能点列出来，然后再将它们放到一个完整的业务流中去。或者先画出整个的业务流，然后再分配给角色。最后你能得到一个完整的图，它包含整个系统所有业务流程，并且有哪些角色在某个节点上能够做哪些操作（拥有哪些权限）都非常的了然，这将是你测试的重点。

    2、确定系统管理员的工作内容，系统管理员一般对系统进行初始设置，角色定义，业务流定义等重要操作。

    3、确定系统的数据流动，包括系统的内部模块间数据流动（可结合系统角色图）和系统间的数据流动接口，在这些地方一般都比较容易出问题。

    4、确定公共部分需要测试的需求。系统中有一些部分为很多角色所共同拥有并且不涉及业务流程。将这部分内容整理，一般来说这些内容只会涉及界面和普通功能的测试，如定义系统界面风格。

    5、确定系统的使用情况。系统有多少用户，稳定运行要求至少多少时间，什么时候会出现系统使用高峰期，高峰期的特点。系统对未来几年内的用户和数据增长是否提供足够的可扩展空间。

    6、系统的安全确定。系统运行的环境要求什么样的安全级别，有什么具体要求。如：访客是否能访问到只有用户才能访问的功能；一个角色是否越权访问他不能访问的角色。系统是否存在没有指向的链接页面作为后门（这个比较难）。等等。

    7、使用该系统的用户可能的硬，软件环境，比如机器类型，操作系统，常用软件等。

    8、其他系统要求确定的需求。

    做完这些工作后，你可以开始设计你的测试用例了。也许仍然存在你不知道的情况，但你可以确定它没有表现在系统的可视范围内。

压力测试和性能的测试的区别是在于他们不同的测试目的

    压力测试是为了发现系统能支持的最大负载，他的前提是要求系统性能处在可以接受的范围内，比如经常规定的叶面3秒钟内响应；
所以一句话概括就是：在性能可以接受的前提下，测试系统可以支持的最大负载。

    性能测试是为了检查系统的反映，运行速度等性能指标，他的前提是要求在一定负载下，如检查一个网站在100人同时在线的情况下的性能指标，每个用户是否都还可以正常的完成操作等。
概括就是：在不同负载下（负载一定）时，通过一些系统参数（如反应时间等）检查系统的运行情况；
比如我们说某个网站的性能差，严格上应该说‘在N人同时在线情况下，这个站点性能很差）

压力测试和性能的测试的区别是在于他们不同的测试目的

    压力测试是为了发现系统能支持的最大负载，他的前提是要求系统性能处在可以接受的范围内，比如经常规定的叶面3秒钟内响应；
所以一句话概括就是：在性能可以接受的前提下，测试系统可以支持的最大负载。

    性能测试是为了检查系统的反映，运行速度等性能指标，他的前提是要求在一定负载下，如检查一个网站在100人同时在线的情况下的性能指标，每个用户是否都还可以正常的完成操作等。
概括就是：在不同负载下（负载一定）时，通过一些系统参数（如反应时间等）检查系统的运行情况；
比如我们说某个网站的性能差，严格上应该说‘在N人同时在线情况下，这个站点性能很差）

主动获取需求
与公司的 技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。

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

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

误区之一：软件开发完成后进行软件测试
软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。因此，软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。软件开发与软件测试应该是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。如果等到软件编码结束后才进行测试，那么，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。更严重的是如果此时发现了软件需求阶段或概要设计阶段的错误，如果要修复该类错误，将会耗费大量的时间和人力。

误区之二：软件发布后如果发现质量问题，那是软件测试人员的错
这种认识很打击软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因为从根本上讲，软件测试不可能发现全部的错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。出现软件错误，不能简单地归结为某一个人的责任，有些错误的产生可能不是技术原因，可能来自于混乱的项目管理。应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。

误区之三：软件测试要求不高，随便找个人多都行
很多人都认为软件测试就是安装和运行程序，点点鼠标，按按键盘的工作。这是由于不了解软件测试的具体技术和方法造成的。随之软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具，新流程，新测试设计方法都在不断更新，需要掌握和学习很多测试知识。所以，具有编程经验的程序员不一定是一名优秀的测试工程师。软件测试包括测试技术和管理两个方面，完全掌握这两个方面的内容，需要很多测试实践经验和不断学习精神。

误区之四：软件测试是测试人员的事情，与程序员无关　　
开发和测试是相辅相成的过程，需要软件测试人员、程序员和系统分析师等保持密切的联系，需要更多的交流和协调，以便提高测试效率。另外，对于单元测试主要应该由程序员完成，必要时测试人员可以帮助设计测试样例。对于测试中发现的软件错误，很多需要程序员通过修改编码才能修复。程序员可以通过有目的的分析软件错误的类型、数量，找出产生错误的位置和原因，以便在今后的编程中避免同样的错误，积累编程经验，提高编程能力。

误区之五：项目进度吃紧时少做些测试，时间富裕时多做测试　　
这是不重视软件测试的表现，也是软件项目过程管理混乱的表现，必然会降低软件测试的质量。一个软件项目的顺利实现需要有合理的项目进度计划，其中包括合理的测试计划，对项目实施过程中的任何问题，都要有风险分析和相应的对策，不要因为开发进度的延期而简单的缩短测试时间、人力和资源。因为缩短测试时间带来的测试不完整，对项目质量的下降引起的潜在风险，往往造成更大的浪费。克服这种现象的最好办法是加强软件过程的计划和控制，包括软件测试计划、测试设计、测试执行、测试度量和测试控制。

误区之六：软件测试是没有前途的工作，只有程序员才是软件高手　　
由于我国软件整体开发能力比较低，软件过程很不规范，很多软件项目的开发都还停留在“作坊式”和“垒鸡窝”阶段。项目的成功往往靠个别全能程序员决定，他们负责总体设计和程序详细设计，认为软件开发就是编写代码，给人的印象往往是程序员是真正的牛人，具有很高的地位和待遇。因此，在这种环境下，软件测试很不受重视，软件测试人员的地位和待遇自然就很低了，甚至软件测试变得可有可无。随着市场对软件质量的不断提高，软件测试将变得越来越重要，相应的软件测试人员的地位和待遇将会逐渐提高。在微软等软件过程比较规范的大公司，软件测试人员的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至比程序员还要高。软件测试将会成为一个具有很大发展前景的行业，软件测试大有前途，市场需要更多具有丰富测试技术和管理经验的测试人员，他们同样是软件专家。