基本常识类

　　1．  计算机基础知识

　　2．  计算机网络基础知识

　　3．  软件测试基本知识（软件质量，软件质量管理基础知识，软件测试概念，软件测试标准，软件测试技术及方法，软件测试项目管理）

　　4．  软件开发基本知识（软件工程知识，理解软件开发方法及过程）

技术类

　　1．  程序语言

　　C/C++，VB，VC，Java，.net，ASP，Javascrīpt等。具体要求要视公司的具体项目或产品来定。但一般以C为基本要求。

　　2．  数据库知识

　　SQL Server，Oracle，Mysql，Sybase等。一般对测试人员的要求就是要求会使用，然后熟练使用SQL语句进行查询，修改，添加，删除数据操作。

　　3．  操作系统

　　Windows，Linux（常用的RedHat，SUSE，Debian）/Unix（FreeBSD，Solaris，HP-UX，AIX，Mac）系统。

　　自动化测试工具类

　　1．  自动化测试概念/自动化测试框架

　　好多人觉得自动化测试就是使用自动化测试工具，其实各种工具只是自动化测试实施的一个有效利器，如何建立一个脱离工具的自动化测试框架远远比研究如何使用测试工具复杂，困难的多。

2．  自动化测试流程

3．  自动化测试工具的使用

　　自动化测试框架（流程）

　　GUI的功能测试自动化

　　非GUI的功能测试自动化

　　性能测试（广义的和狭义的性能测试）

　　自动化测试工具（功能测试工具，性能测试工具，缺陷管理工具，测试管理工具）

　　(HP)Mercury Interactive QuickTest Pro，WinRunner，LoadRunner，Quality Center（Test Director），SiteScope

　　Compuware QACenter（TestPartner QARun QALoad QADirector TrackRecord），DevPartner studio

　　(IBM)Rational TestSuite（Robot TestManager FunctionalTester PerformeranceTester ClearQuest ClearCase ...）

　　(Borland)Segue SilkTest SilkPerformer SCTestManager

　　其它：JUnit，NUnit，Auto It，Test Architect，OpenSTA等

实战类（工作经验）

　　1．  公司的测试流程

　　2．  公司的具体缺陷管理流程（提交bug报告，追踪bug状态）

　　3．  测试环境的搭建及管理

　　4．  测试计划，测试用例，测试报告等相关文档的编写

语言类

　　1．  英语

　　2．  日语

　　3．  。。。

性格类

　　通过30分钟至1个小时的面试，试着了解面试者的性格是否适合软件测试的工作。

　　1．  细心，关注细节

　　2．  耐心，不怕麻烦

　　3．  良好的沟通能力

　　4．  优秀的学习能力，逻辑思维强

　　5．  工作积极主动

　　6．  上进性强，永远不满足现状

        好了，言归正传，讲一下我们在测试工作中的一点体会吧，写出来一面为自己理一下思路，二也是为自己做工作的一个总结。

一、   测试之前要充分掌握业务流程

        首先，在进行系统测试之前，要知道系统的业务流程，也就是说要清楚每项业务间发生的前后顺序。只有知道了业务的先后顺序，你的测试数据才能继续在ERP系统功能间流转，否则，无法进行各项业务的全面覆盖测试。

        其次，还要明白每一项业务中的详细流程和各个环节涉及的角色，一项比较复杂的业务其详细流程往往比较多，只有了彻底掌握了这项业务，才能对当前业务环节进行全方位的测试。比如：订单管理中，销售业务员创建了一个销售订单，还要经过主管审核，方可执行订单，订单执行完毕后关闭订单。

二、   了解业务流程对应的ERP系统的功能

        对整个业务有了总体的认识，再把业务分块，在ERP中找出相应的模块与业务对应起来。只有把业务和REP功能完全对应上了，才能说有可能对ERP系统进行全面的覆盖测试。

三、   系统功能集中测试和测试方法

        找到与具体业务对应的ERP子系统，根据当前业务的流程与角色，对ERP子系统进行集中测试。测试还要讲求方法，尽量做到全覆盖测试，其中注意几点：

1）、按正常场景进行测试

        根据业务流程，按着正常的顺序，用正确的测试数据测试系统；检查系统的结果是否与预期的结果相同，如果结果相符，表示当前系统模块符合业务逻辑；否则，系统有问题，将错误信息记录到BUG报告中，及时提交开发部门。

2）、测试异常场景

        根据业务流程，输入异常的测试数据测试系统，查看系统提示哪些异常信息，并查看是否有异常判断，如果有，则表示系统做过异常考虑处理，否则表示系统漏掉了当前异常情况，需要提示开发部门，添加当前异常情况的考虑处理。

3）、特殊数据的处理

        根据业务流程，在输入测试数据时，输入边缘数据、空值等特殊字符，查看系统是否做了数据录入范围和要求的判断，如果没有，表示系统遗漏数据范围和录入要求的考虑，需要提示开发部门，添加相应数据范围和要求的处理。

        以上三方面的考虑，是比较常见而且不可遗漏的测试部分，当然，可以用测试用例来规范。如：

四、   提交BUG报告

        通过前边的测试，把得出的错误信息，以BUG报告的形式展现出来，转发给开发部门相应人员，以例开发部集中修改系统错误信息。下边说一下BUG报告的内容：错误序号、发现日期、子系统名称、二级模块名称、三级模块名称、发生页面、错误描述、发现者、是否修改状态、修改人意见、修改人、修改日期、确认人、确认日期。按着上边这几项内容，将错误信息以BUG报告的形式列表出来，转发给相应的部门修改。

五、   回归测试

        BUG修改完毕后，更新ERP系统，更新完毕后，对已往的错误信息进行二次测试，以确保错误信息的正确修改。

        通过以上五个步骤，把我们销售部当前进行的测试工作，做了一个完整的总结，这就是我们目前采用的简单的测试方法和步骤，经过我们的测试，系统性能得到了一定的提高，当然不否认系统还可能存在一些潜在的问题，这需要我们在后期维护中不断的改进。

经理、系统分析师、程序员、测试工程师、质量保证人员等。可见，软件测试工程师只是软件项目开发中的一个角色而已。

戏剧舞台上的生、旦、丑是不同的角色，其表演方式具有明显的特征，这是由于角色决定的。同样，软件测试工程师的角色，在软件项目开发中也存在如何定位和表现自身的行为和责任的问题。

此处讨论测试工程师的角色并非毫无意义。须知，角色不明，责任不清，行为就失去了参照目标，结果就可能很不理想了。轻则降低了工作质量和效率，重则被视为工作能力低下，可能要退出软将项目组的舞台了。

软件测试工程师承担的任务

角色决定工作内容和承担的任务。测试工程师的角色应该承担什么任务呢？这没有统一的答案。因为，这与软件公司的规模，软件项目管理制度，公司领导和项目经理的管理风格，以及具体软件项目自身的特点有很大关系。而且，测试工程师也有普通和高级之分。

笼统的答案列举如下：

• 设置软件测试环境，安装必要的软件工具。
• 运行软件，发现和报告软件缺陷或错误。尤其需要快速定位软件中的严重的错误。
• 对软件整体质量提出评估
• 确认软件达到某种具体标准
• 以最低的成本，最短的时间，完成高质量的测试任务
• ......


在这其中，最重要的是要明确，程序员的责任和目标。在执行任何具体测试任务前，都要在项目组内对于责任和目标达成共识，以免带来后续工作的相互推诿。


提高测试质量的要诀


另外一个值得注意的方面就是工作效率和质量，或许高级测试工程师与普通测试工程师的主要区别在于高级测试工程师可以更快地发现更多软件中的严重错误。对此，有什么可以借鉴的诀窍吗？请尝试以下方法，保证不会是您失望。

• 首先测试程序的核心功能，然后测试辅助功能。
• 首先测试功能，然后测试性能。
• 首先测试常见情况，然后测试异常情况。
• 首先测试经过变更的部分，然后测试没有变更的部分。
• 首先测试影响大的问题，然后测试影响小的问题。
• 首先测试必须测试的部分，然后测试可选或没有要求测试的部分

软件测试工程师是项目团队中的服务员

需要强调的一点是，无论你是多么高级的测试工程师，都要明白无论测试需要的工具多么复杂，测试步骤多么冗长，测试工程师在软件项目开发中始终都是扮演服务员的角色，这是由测试工作的特点决定的。任何服务都有被服务对象—客户，软件测试工程师的服务对象有哪些呢？

• 最重要的客户是软件的用户。测试工程师需要站在客户的使用和需求角度测试软件，报告问题。
• 项目经理也是客户。测试工程师需要报告测试工作进度和发现的问题，尤其是严重的问题。

• 程序员是最经常打交道的客户。为了便于程序员重复报告的错误，尽量提供良好的软件问题报告，以便程序员可以更快的修复软件错误。

• 技术文档工程师、市场开发人员和技术支持工程师也都是测试工程师的服务对象。
软件测试工程师避免犯的几个错误

前文已经指出测试工程师应该明确角色，明确任务和责任。知道哪些是自己份内的事，哪些是不属于自己的事。一定要尽最大努力完成份内的事，不要做不属于自己的事情，以免弄巧成拙。

为了更好的扮演软件测试工程师的角色，尽量避免犯下面的错误：

• 承诺完成测试的软件没有质量问题
软件测试只是保证质量的一种方法，软件测试工程师的工作不会直接提高软件质量，因为绝大多数软件错误都需要程序员修复。软件测试只能证明软件存在错误，不能保证软件没有错误，不可能找出全部软件错误。个人的能力和对质量的影响范围很小，软件质量的提高要靠软件项目团队全体成员的共同努力。　

• 承担软件的发布权利
不要因为软件中存在还没有修复的错误，而试图提出更改软件发布的计划。也不要认为已经完成了测试计划，自己决定可以发布软件。因为，改变软件发布计划可能要失去进入市场的良机和很多客户，对此造成的经济和公司市场的损失将不是测试工程师能够承担的。另外，软件发布后，如果用户发现了新的软件错误，公司领导或项目经理可能将过错加在软件测试人员的头上，因为他们同意发布软件。通常软件发布的权利由产品经理、项目经理、测试经理、市场经理共同集体讨论决定。　

• 扮演过程改进成员的角色
软件测试工程师必须报告错误，有时也要分析错误的类型、特征和产生错误的原因。但是，不要主动提出改进软件过程的具体改进措施，更不要直接干涉程序员的工作方式，以免出力不讨好，影响今后的愉快合作。软件过程改进的方法是软件质量控制部门的事情，这是他们的本职工作。

1、如何创建Test Cases

Test Cases基本要素：
        1 简明的标题（说明测试的目的）
        2 用例的优先级，测试所需时间
        3 初始化条件，如何构造测试环境
        4 执行测试的详细步骤
        5 期望Test Cases执行后的正确结果

关于测试用例的优先级别的设定：
        pri1 - 基本的功能
        pri2 - 错误的条件，界限用例（最大值，最小值...）
        pri3 - 极端的条件，边缘用例

编写Test Cases的注意事项：
        一个好的Test Cases的重要性不亚于一段好的代码，在写Case的过程中我们需要注意以下几个方面：
        1 需要有一个具有自我解释功能的标题，将测试的目的说清楚。（例如：按下“ALT+F+C”关闭“XXXX”主窗体。）
        2 足够详细准确的内容，即使是一个对所要测试的内容根本不了解的新手，也能准确的按照所写的Test Cases完成测试。
        3 拒绝重复的测试用例
        4 不要有模糊的，个性化和想当然的Test Cases（例如：用各种方法打开对话框“XXXX”）
        5 尽量提供一些于Test Cases相关的参考

当你在写完cases的时候最好带着一下几个问题检查一下你的case:
        1 你的test case的标题是否体现了该用例详细而精确的目的性
        2 你的test case对于一个新手来说是否能让他们精确的执行
        3 你的test case是否有重复
        4 你的test case中的步骤是否清晰，让人一看就能很明白的执行
        5 你定义的执行结果是否能让人很清楚的意识到他跑完这个case后是成功还是失败

2、运行Test Cases
        根据Test Cases的优先级和不同的测试阶段运行测试用例，运行时要注意Case的优先级（有必要时可以对其进行修改）和测试方式（手动测试还是自动化测试等），并最终记录测试结果。

3、记录测试结果
        记录在不同测试阶段（Test Pass 1, Regression 1, Test Pass 2…UI Freeze.. Regression 2….Final Test Pass.）运行Test Cases的结果，一般分四种结果Blocked（记录bug号和原因）、Failed（记录bug号和原因）、Not Run（记录原因）、Pass。

4、何时再修改并创建新的Test Cases
        1 测试目标一些特性的改变
        2 Test Cases的优先级发生改变
        3 代码改变
        4 发现新的Bug但用例库中没有与之相关的Test Case
        5 发现新的Bug但用例库中已经存在与之相关的Test Case

        古时云：亡羊补牢，为时未晚也。对于遗漏的bug，我们应该去透彻的分析它产生的原因，然后吸取教训，防止再次出现。这样遗漏bug的数量就会越来越少，趋于0。那么怎样的分析才是透彻的呢？我发表一下自己的观点。

        根据我的经验，总结下来有以下几点，首先从根源上说，需求的问题。需求是一切的根本，我们所做的一切都是在需求的基础上进行的，那么需求会不会有问题？当然有啦，否则要需求评审干嘛，每次需求评审，或多或少都能发现一些需求的问题，在还没有开始编码之前就把需求的bug找出来，这个是最理想的状态。显然这个不现实，但是能多发现一个不合理的地方，那就能减少很多风险。因此需求关要把好。当然要求测试人员在需求评审时就要找出需求的bug，这个是要求比较高的，需要对业务的熟悉以及对相似产品的认识。需求关把好了，那么就算踏出了成功的第一步。

        其次，要尽早与开发人员进行测试设计评审，统一对需求的认识（开发测试人员都可能存在对需求的认识不正确）。越早进行，越能够避免出现因为对需求的认识不同而导致出现的问题（最可怕的是因此产生的隐性bug），这样也能减少后期很多不必要的资源浪费。

        接下来，就是用例设计了，这方面体现了一个测试人员的真实地能力。考虑的面要广，包括:使用不同的测试方案，不同的测试数据的类型（要齐全），正常流与异常流等来覆盖所有的需求。

        然后就开始执行测试，要全面地执行测试用例，并且在测试过程中不断的添加遗漏的用例。在时间允许下，尽可能的执行。

        回归阶段，除了要回归前面发现的bug，还要重视回归那些bug相关的模块，这个教训是很多的，所以千万不能忽视。一个小小的小小的参数变动可能引起一个比较远的功能点的大bug，继而引发遗漏。所以这个是需要开发人员与测试人员去识别的。开发人员熟知代码，知道改动的地方会被哪些模块调用或者会引起哪些变化，因此开发人员需要通知测试人员测试关注点以及加强自测。在开发人员与测试人员无间隔的合作下，这种bug的遗漏会减少很多。

        发布前期，应该在保证所有的bug都fixed的前提下，把所有用例都回归一下，以免遗漏。

        最后终于发布了，发布好就可去FB了，^o^。不要在开心的情况下放松神经，所谓行百里，半九十，不能倒在最后的冲刺关头。细心细心再细心。只要一步步走下来，那么就可以把遗漏的bug数量减到最低。

        当然最好做自动化脚本，方便以后的回归。这就是我想说的，大家有意见可以跟着，共同进步。

        确认了所发现的问题是一个bug之后，按照测试步骤再执行一次，确保bug是可重现的而不是随机的。如果bug不能重现，应该尽量找到bug重现的规律，在一些比较难重现的问题可以找开发配合一起查找原因，如果还是无法重现则需要在bug report中对出现的问题描述清楚并说明出现的随机性。

        接下来就是填写bug report了，在填写bug report的时候，最重要的是bug的标题和bug描述。在bug报告中，首先用一句话对bug进行简要精确的描述作为bug的标题，让开发或项目经理一看就知道存在什么问题，比如“XX模块在压力测试2小时后出现内存泄露”。而在bug的描述中，需要使用简明准确的语言描写出现bug的测试步骤、实际的测试结果、预期的测试结果和结论；也就是说描述导致出现bug的操作步骤是怎样，由测试步骤所做的操作引起的测试结果是什么，而预期的结果应该是怎样，并由实际结果与预期结果相对比说明问题所在。比如：“在管理网页新增用户，当新增的用户登录名名称很长（例如登录名长度为输入框允许的最大长度），按‘新增’按纽新增后系统提示已经有该用户存在，而事实上该用户并不存在，建议对超长的用户名进行处理。”

        在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的流程？同一个故障是否会引起更加严重的问题？如果存在，也需要提出来让开发一并处理。

        在开发对bug进行修改之后，测试需要报着怀疑的态度认真地对问题进行验证，需要严格按照测试步骤来进行测试，检查开发是否已经正确修改了所出现的问题，以及开发对bug进行了修复之后是否会引进新的问题。不要相信开发说“已经修改好了，肯定没问题了”就不对问题进行细致的检查了，如果开发修改得不彻底，问题仍然会存在的，或者可能会由于开发在修改bug的时候忽略了另一些细节导致了新bug的出现。尽量不要在关闭bug之后，才发现这个问题还没有修改彻底；也不要出现bug关闭之后，出现了新的bug。

        测试对bug进行验证确认已经修改ok之后，关闭bug。在关闭的时候，应该对Bug最终修改结果进行简要描述，如果bug的修改引起配置或数据库或业务流程的变更，也需要在bug关闭描述中进行说明。

一、测试用例的定义
    测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。
   
二、测试用例的特征
  1.最有可能抓住错误的；
  2.不是重复的、多余的；
  3.一组相似测试用例中最有效的；
  4.既不是太简单，也不是太复杂。
 
三、测试用例组成元素
  1.用例ID；
  2.用例名称；
  3.测试目的；
  4.测试级别；
  5.参考信息；
  6.测试环境；
  7.前提条件；
  8.测试步骤；
  9.预期结果；
  10.设计人员。
 
四、测试用例设计原则
  1.测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
  2.测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
  3.测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

二、LoadRunner工具原理

  代理（Proxy）是客户端和服务器端之间的中介人，LoadRunner就是通过代理方式截获客户端和服务器之间交互的数据流。

 1）虚拟用户脚本生成器通过代理方式接收客户端发送的数据包，记录并将其转发给服务器端；接收到从服务器端返回的数据流，记录并返回给客户端。

  这样服务器端和客户端都以为在一个真实运行环境中，虚拟脚本生成器能通过这种方式截获数据流；虚拟用户脚本生成器在截获数据流后对其进行了协议层上的处理，最终用脚本函数将数据流交互过程体现为我们容易看懂的脚本语句。

2）压力生成器则是根据脚本内容，产生实际的负载，扮演产生负载的角色。

3）用户代理是运行在负载机上的进程，该进程与产生负载压力的进程或是线程协作，接受调度系统的命令，调度产生负载压力的进程或线程。

4）压力调度是根据用户的场景要求，设置各种不同脚本的虚拟用户数量，设置同步点等。

5）监控系统则可以对数据库、应用服务器、服务器的主要性能计数器进行监控。

6）压力结果分析工具是辅助测试结果分析。

1.引言

　　作为评价产品性能的重要手段，性能测试在软件测试工作中占的比重一直很大，要最终提供一份准确，权威的测试报告，测试人员的努力工作自然不可或缺，但更重要的是测试人员清晰的工作思路，简洁的测试流程和良好的测试方法。

2.目前性能测试存在的问题

　　总结以往进行的性能测试，虽然测试人员自始至终对测试工作都做到了认真负责，但测试报告出炉后，大家总觉得美中不足，对测试结果都心存疑虑，尤其在那些时间跨度较长、针对不同的测试对象的性能对比测试中，或多或少都存在以下几个方面的问题：
    1. 测试准备不充分，测试目标不明确，测试计划不详细；
    2. 缺乏测试以及针对测试对象的技术储备；
    3. 测试环境的稳定性及前后一致性不足；
    4. 测试数据精确性和代表性不足；
    5. 测试描述不精练；
　下面，我们就剖析以上问题的同时，探讨一下如何解决这些问题。

3. 性能测试准备

　　这是一个经常被测试人员忽略的环节，在接到测压任务后，基于种种其它因素的考虑，测试人员往往急于进度，立即投入到具体的测试工作去了，测试、记录、分析，忙的不亦乐乎，工作进行了一半才发现，或是硬件配置不符合要求，或是网络环境不理想，甚至软件版本不对，一时弄得骑虎难下，这都是没有做好测试准备惹的祸。
　　那么我们应该如何做好性能测试的准备工作呢？
　　做软件项目有需求调查、需要分析，我们做测试也一样。在拿到测试任务后，我们首要的任务就是分析测试任务，在开始测试前，我们至少要弄清以下几个问题：
    a) 要测试什么或测试的对象是谁？
    b) 要测试什么问题或我们想要弄清楚或是论证的问题？
    c) 哪些因素会影响测试结果？
    d) 需要怎样的测试环境？
    e) 应该怎样测试？
　　只有在认真调查测试需求和仔细分析测试任务后，才有可能弄清以上一系例的问题，只有对测试任务非常清楚，测试目标极其明确的前提下，我们才可能制定出切实可行的测试计划。明确测试目标,详尽测试计划在对测试需求充分了解的基础上，制定尽可能详细的测试计划，对测试的实施是大有裨益的。测试计划的制定，大多专业的测试书籍多有详述，故本文不再鏊述。

3.1 测试技术准备

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

3.2 配置测试环境

　　只有在充分认识测试测试对象的基础上，我们才知道每一种测试对象，需要什么样的配置，才有可能配置一种相对公平、合理的测试环境（这在性能对比测压中尤其重要）。考虑到其它因素，如网络锁、网速、显示分辩率，数据库权限、容量等对测试结果的影响。如条件允许，我们最好能配置几组不同的测试环境。

3.3 测试数据的获取和处理

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

4. 如何开展性能测试

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

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

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

5. 如何总结性能测试

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

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

6. 结论

　　各种软件性能测试，范围大小不同，强度高底有别，但只要本着认真、客观，科学的工作态度，遵循本文论述的方法，做好测试工作是不难的。本篇文章主要谈的是软件性能测试方面的问题，相信对其它方面的测试也有一定的借鉴作用。 

在拜读了段念的《软件性能测试过程详解与案例剖析》一书后，对各种性能测试类型有了豁然开朗的感觉。
网上关于性能测试类型方面一直都讨论不休并有多种见解，以下是根据书上描述和个人经验对测试侧重点做了进一步探索，不对之处请指正。

    我们所说的性能测试是一种广义上的说法，包括了以下各种不同的性能测试类型，每种测试类型都带着明确的测试目的。

性能测试（Performance Testing）
    原文摘要：性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生成性能要求。即在特定的运行条件下验证系统的能力状况。
    个人理解：主要强调在固定的软硬件环境、确定的测试业务场景下，其主要意义是获得系统的性能指标。

负载测试（Load Testing）
    原文摘要：在给定的测试环境下，通过在被测系统上不断增加压力，直到性能指标超过预定指标或某种资源使用已经达到饱和状态，目的是了解系统性能容量和处理能力极限。负载测试的主要用途是发现系统性能的拐点，寻找系统能够支持的最大用户、业务等处理能力的约束。
    个人理解：也可以理解为扩展性测试（Scalability Testing），即在固定测试环境，在其它测试角度（负载方面）不变的情况下，变化一个测试角度并持续增加压力，查看系统的性能曲线和处理极限，以及是否有性能瓶颈存在（拐点）。主要意义是从多个不同的测试角度去探测分析系统的性能变化情况，配合性能调优。测试角度可以是并发用户数、业务量、数据量等不同方面的负载。

压力测试（Stress Testing）
    原文摘要：测试系统在一定饱和状态下系统能够处理的会话能力，以及是否出现错误，一般用于稳定性测试。
个人理解：可以理解为资源的极限测试。测试关注在资源处于饱和或超负荷的情况下，系统能否正常运行，是一种在极端压力下的稳定性测试。其主要意义是通过测试调优保证系统即使在极端的压力情况下也不会出错甚至系统崩溃。
    网友补充：压力测试的目的是调查系统在其资源超负荷的情况下的表现，尤其是对系统的处理时间有什么影响。这类测试在一种需要反常数量、频率或资源的方式下执行系统。目标是通过极限测试方法，发现系统在极限或恶劣环境中自我保护能力。主要验证系统的可靠性。

配置测试（Configuration Testing）
    原文摘要：通过对被测系统的软硬件环境的调整，了解各种不同环境对性能影响的程度，从而找到系统各项资源的最有分配原则。
    个人理解：主要用于性能调优，在经过测试获得了基准测试数据后，进行环境调整（包括硬件配置、网络、操作系统、应用服务器、数据库等），再将测试结果与基准数据进行对比，判断调整是否达到最佳状态。

并发测试（Concurrency Testing）
    原文摘要：模拟并发访问，测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题。
    个人理解：测试目的并非为了获得性能指标，而是为了发现并发引起的问题。

可靠性测试（Reliability Testing）
    原文摘要：通过给系统加载一定的业务压力的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。
    个人理解：需要和压力测试区分开，两者的测试环境和测试目的不一样。压力测试强调在资源极限情况下系统是否出错，可靠性测试强调在   一定的业务压力下长时间（如24×7）运行系统，关注系统的运行情况（如资源使用率是否逐渐增加、响应是否是否越来越慢），是否有不稳定征兆。

一、性能测试流程

• 测试需求分析
• 测试计划指定与评审
• 测试用例设计与开发
• 测试执行与监控
• 分析测试结果---根据前面的测试数据来分析测试结果，为优化和调整系统提供依据。测试分析的对象是应用程序、Web服务器、数据库服务器、操作系统、硬件资源等。
• 编写性能测试报告---包括测试过程记录、测试分析结果、系统调整建议等。
• 测试经验总结。  

二、性能测试需求分析

• 需求信息的来源--客户代表、项目经理、产品经理、销售经理、需求分析员。
• 确定性能测试策略和测试目标
• 确定性能测试范围--通常把那些用户关注度或者性能风险较高的测试需求划分到测试范围内。
• 目标系统的业务分析--确定系统的核心模块；确定模块件的耦合性关系；分析系统压力点。
• 用户及场景分析

三、性能测试整理规划

• 测试环境规划：网络环境设计、操作系统环境规划、数据库环境规划、Web服务器环境规划、硬件资源环境规划。
• 测试环境维护方面的规划：一般在性能测试规划阶段明确，在性能测试计划中落实。
• 测试工具规划：选择工具主要从三个方面来考虑---了解测试工具的特性、了解工具的主要功能、了解工具的价格。
• 人力资源规划

四、性能测试计划指定

• 明确性能测试策略和测试范围
• 确定性能测试目标、方法、环境、工具
• 确定性能测试团队成员以及职责
• 确定时间进度安排   
• 确定性能测试执行标准
• 测试技能培训
• 了解性能测试中的风险

五、性能测试用例设计：三类用户场景

• 一天内不同时间段的使用场景
• 系统运行不同时期的场景
• 不同业务模式下的场景

六、性能测试各类测试用例的细节

• 确定用户使用系统情况的方法：用户现场调查和分析系统日志
• 并发用户数量设计：（极限法）--适用于系统已经投产或者目标用户群体不确定的门户网站，可以通过分析日志来进行测试，也可以使用系统已经注册的用户数量作为系统的用户数量，然后按照经验公式来估算最大并发用户数量。（用户趋势分析）--这种方法多用于系统用户数目逐渐增加的情况。（经验评估法）--这种方法适用于系统的使用用户数目相对稳定且比较明确的系统。
• 系统不同时间段场景的设计。
• 业务模式的设计。
• 大数据量测试用例的设计
• 一些特定测试用例的设计

七、性能测试实施

   主要包括搭建与维护测试环境、执行测试用例、监控测试执行场景、保存与分析测试结果等，

   性能测试与功能测试执行的区别：功能测试用例一般容易执行，单个用例耗时较短，同时绝大多数用例都要通过测试；而性能测试用例执行时则具有不确定性，有些用例执行时间可能很长（例如疲劳强度测试），有些用例则需要不断地探讨进行测试（例如测试系统的最大并发用户数），而且可能会有部分性能测试用例不能通过。

   性能测试实施分为开发与用户现场两个阶段来进行探讨。

八、进度与变更控制

    （1）性能测试引起进度变化的原因

• 开发团队解决性能缺陷的速度
• 测试过程需要的软硬件资源
• 性能测试中采用的一些新技术
• 测试工具的执行能力
• 测试范围的变化：是不可避免的，可以把它当成一种风险来应付，同时要认真分析是不是真正的变更。

    （2）如何应对性能测试中的变更：按照合理的流程规划性能测试；保证测试方案得到项目干系人的认可；学会接受合理的变更；经常召开理会处理遇到的变更。

    （3）如何控制性能测试进度：正确协调质量、进度、成本的关系；建立规范的软件开发与测试体系，逐步使软件开发与测试工作进入良性循环状态；保证项目的里程碑

    性能测试进度控制是很复杂的一项工作，尤其当性能测试工作作为系统测试的一部分来开展，更加大了控制的难度。要想控制好性能测试，首先要规划好性能测试，并且按照合理的软件管理规范来开展性能测试工作；其次还要在测试实施过程中，根据项目具体特点进行灵活的处理。

九、测试分析与经验总结

   （1）性能测试规划总结

• 测试环境规划是否合理
• 人力资源安排是否合理
• 测试工具规划是否合理

   （2）测试用例设计总结

• 测试用例可用性总结
• 用例执行效果分析
• 用例执行时间分析

   （3）测试工具与技术总结

• 测试过程的一些技术方面的总结
• 测试工具的使用经验总结

   （4）瓶颈分析方法总结

• 应用系统瓶颈分析经验
• 数据库瓶颈分析经验
• Web服务器分析

1角色和职责

1.1       质量保证人员（SQA）

²      辅助过程裁减，细化、制定项目规范；

²      制定《质量保证计划》；

²      产品检查；

²      过程审计；

²      跟踪问题处理；

²      度量和报告；

²      项目经验积累；

²      学习、研究和推广。

1.2       项目主管（SPM）

²      为SQA工作的顺利实施提供保障；

²      协调SQA与项目之间产生分歧的问题。

1.3       项目经理（PM）

²      批准《质量保证计划》；

²      为SQA工作提供支持。

1.4       开发人员（DEV）

²      参与评审《质量保证计划》；

²      按照《质量保证计划》执行活动；

²      协助SQA完成质量管理工作。

2SQA周期性工作

2.1       产品评价

SQA可以用过审计、独立测试等手段评价产品，也可以通过监督评审、测试等过程来保证产品质量，也可以从格式和规范（比如代码规范、设计规范、UML图、DFD图、ER图等）上实施检查，并尽可能地检查中间产品之间的一致性。

检查内容：工作产品和最终产品。

2.2       过程评价

主要是检查项目是否按规定的过程和计划执行活动。检查规则包括过程执行的符合性和有效性两个方面。

检查内容：包括工程和管理两类过程（有些划分为工程、管理、支持等）。管理类过程包括项目管理、质量管理和配置管理。开发类包括需求分析、设计、编码、测试、评审等过程。

2.3       跟踪问题处理

SQA应跟踪问题处理过程，直到问题解决。跟踪的问题包括日常发现的产品问题、过程问题、项目风险、评审发现的问题、测试发现的问题等。如果不能和项目组就解决方案达成一致，可向项目主管反应。

2.4       度量和报告

SQA应善于根据过程规范和经验发现项目运行中的问题，并做到紧急问题、重要问题随时汇报，其它问题周期性汇报。

SQA需要随时收集数据并保障数据的有效性、真实性。定期汇总数据、统计分析并产生度量报告。SQA应协助项目组和SEPG针对不良趋势和问题采取纠正或预防措施。

2.5       质量推进

质量推进主要包括提高全员的质量意识和推进、解释过程的执行两个方面。这项工作需要在日常工作中一点一点地、坚持不懈地实施。

3SQA非周期性工作

3.1       制定《质量保证计划》

在项目计划阶段，SQA在参考项目计划的基础上，与项目经理一起制定《质量保证计划》。质量保证计划的内容包括：QA组织结构、工作产品输出计划、计划执行的QA活动、度量计划以及计划采用的辅助工具等。《质量保证计划》要做到内容明确、可操作并及时更新。

3.2       过程制定

如果项目或组织需要制定过程规范，SQA应组织相关人员来完成过程制定工作。一般情况下，过程制定应由遵守和执行该过程的人员负责。所有制定的过程都必须经过评审，并由SQA检查执行情况。

3.3       过程改进

过程改进是一项长期的任务。SQA应注意随时发现、听取过程执行中问题和改进工作的方法，并进行阶段性的总结（比如质量报告等），以不断改进过程，提高过程能力。

3.4       学习和研究

SQA要不断学习和研究，尽量保持与领域最新的知识、方法同步，找出提高产品质量和工作效率的方法与过程。学习的内容主要包括管理领域和开发领域。管理领域包括质量管理（TQM、ISO9000、CMM、RUP、MSF、XP等）、软件度量（PSM、GQM、SPC、SixSigma）、项目管理、配置管理等。开发领域包括需求工程、设计、编码、测试等各阶段的开发和管理方法。

3.5       质量培训

项目或组织需要时，SQA需要向相关人员进行质量管理方面的培训或咨询。

1.程序员应避免测试自己编制的程序
2.测试用例的设计必须包括预期的输出结果
3.测试用例应包括有效的和期望的输入情况，也要包括无效的和不期望的输入情况
4.彻底检查每个测试结果
5.只检查程序是否做了它应该做的事仅仅完成了测试工作的一半，

  另一半则是要检查程序是否做了它不该做的事
6.避免不可重复的即兴测试，保留全部测试用例
7.一段程序中存在错误的概率与在这段程序中已发现的错误数成正比
8.测试是一项非常复杂、有创造性的挑战性任务
9.不要为了便于测试擅自修改程序
10.测试工作必须有明确的目标

工作中的学习习惯总结：
1。工作中，遇到困难/遇到不明白的地方，提出问题，找到最快解决问题的途径（分类问题记录文档/相关文档/相关书籍/帮助手册/google/同事）寻找答案，解决问题，将知识点记录到相关文档中（分类问题记录文档/学习笔记/博客空间日志），解决困难/理解不明白的地方。
2。每天记录下工作总结和经验。

技术系统学习的学习习惯总结：
1。每天坚持2个半小时进行学习
2。每天坚持写工作学习日志
3。每月写学习计划并改进学习方法

业务和系统熟悉学习方法总结：
1.在进入工作后，系统的看所有业务和系统文档，有个大致印象。
2.遇到问题时，先查询业务和系统文档，用红色字体标识出知识点，表示已经在工作中接触到了该知识点。如果没有找到答案或文档不够详细，问资深的同事或查看代码（系统知识），然后将知识点补充到业务和系统文档中（如果没有文档，则自己积累出个文档来）。
3.问题解决了，但没明白内部细节，而且任务时间有限不允许更深入的理解时，记录下解决问题的过程，等工作任务结束后，解决不明白的地方，同样将知识点补充到业务和系统文档中。
4.平时工作中，接触到的陌生的业务和系统知识点时，补充到业务和系统文档中，并用红色字体标识出。
5.定期的整理业务和系统文档，加深印象。

工作相关技术的学习方法总结：
1.找到相关技术的查询途径（联机帮助/技术官方网站/技术手册/权威技术书籍/google）
2.遇到问题时，在寻找答案过程中，不要牵连出一堆的知识点，抓住和问题紧密相关的知识点，除了顺利解决问题之外，需要彻底的弄清楚该知识点，如果时间不允许，先解决问题，并记录下未明白的知识点，在工作任务完成后，继续掌握该知识点。
3.晚上学习进行系统的学习，技术的系统学习方法总结另外总结。

技术的系统学习方法总结：
1.找一本权威的该技术书籍.先通读一遍,注重掌握关键问题，关键知识和技术,关键的方法和算法. 再细读一遍, 挑出重点,结合下面的4点学习方法进行,然后把整个的学习过程、经验心得、理解认识，写成学习笔记的方式总结.(正在试用)
2.技术手册中查询并练习函数手册中的范例。
3.调试权威技术书籍中的实例源代码。
4.自己编写相关技术的小程序。
5.阅读后台系统中包含相关知识点的源代码文件。

测试技术学习方法总结:

1.测试技术非常具有实践性,所以,我的学习方法是:首先系统的学习该测试技术权威书籍,对该测试技术有个全面的了解,其次,在测试工作中找到能使用该测试技术的地方,尝试用该测试技术进行工作,在实际工作中总结该测试技术的使用经验,以写日志的方式提炼.最后,在多次测试任务完成中,反覆查阅该技术权威书籍,达到温故而知新的目的,不断尝试改进自己实际使用的该测试技术.不断增加自己对该测试技术的经验总结.
2.测试技术的学习离不开对业务和系统知识和开发相关技术知识的熟悉,这2方面是测试技术学习的前提,但也不是前2者完全具备了才能开始测试技术的学习,可以在进行测试技术学习的同时,按需学习前2者.
3.测试技术的学习的目的是提高测试效率,不是为了学习而学习,任何测试技术的学习一定是在有工作环境可实践的情况下进行,学习效率才会高. 如果发现某个测试技术很好,但并不适合现在的测试系统使用,请暂时放弃该测试技术的学习.

别人的编程学习习惯和学习方法收集：
1.坚持每天看所测系统的源代码,直到全部看完为止。
2.看一本书时，先通读一编；再细读一编；然后洗刷式的快速反馈学习；然后把你整个的学习过程、经验心得、理解认识，写一个详细的文章；找些不错的源代码，认识别人对实现过程的思路. 一边编写自己感兴趣的小程序。
3.在论坛上提问
4.对于基本功和基础知识的学习适宜采用系统学习的方法，尽管需要系统而深入的学习但也并不是要去弄清楚各种烦琐的细节问题，而是要注重掌握关键问题，关键知识和技术，关键的方法和算法。同样是有所选择和侧重的。而对于应用技术或者自己以前不熟悉的技术的学习则适宜采用按需学习的方法，针对实际工作和应用中对该技术和知识的需求只侧重于自己需要的那个部分进行重点学习，理解，吸收和掌握,应用的需求决定了学习的内容和程度。对于与项目应用需求不是特别相关的技术细节只做概要式的领会，注意其与别的部分的整体联系就可以了，不必深究。
5.我们在学习之前必须要对要学习的东西有充分的了解，特别是从整体的角度要有一种系统观的了解。学习新技术或者新领域时，最好能找一本关于那个方向比较好的综述性质的书，先从总体架构上了解该技术的整个面貌,技术要点和流程，然后再联系自己现有的知识结构，根据自己的实际需要选择和制定合适的学习阶段，学习内容和学习计划。

　　2）项目需求及相关资源了解；
　　测试组组长（或测试经理）需要对项目的客户需求和项目本身要求进行了解，明确测试范围、测试指标、测试要点，测试所需软硬件环境等，为制定测试计划打好基础。

　　二、制定测试计划
　　主要包括测试软硬件资源，人力资源，测试指标，粗略进度，采集的度量数据，风险，约定等。网络上有很多这方面的模板资料，建议定义好测试过程中要收集的度量数据，一般包括缺陷本身的属性，例如严重程度，功能类别，发现阶段，工作量，对应用例等；各周期内（例如以周为单位）缺陷的收敛情况（发现数量，解决数量，遗留数量），阶段分布情况，缺陷存活情况等。

　　三、编制测试用例
　　1）了解项目需求（客户需求与项目需求）；
一方面为编制测试用例打好基础，另一方面可以找出需求中存在的问题。

　　2）明确公共用例；
　　找出测试需求中，在编写用例时会出现重复的需求，编写公共用例，这样回减少后期用例编写工作量，也方便后期用例的维护。

　　3）明确手动测试用例与自动化测试用例范围；
　　可以避免重复劳动，有些业务流程可以用自动化的用例来代替手动工作。

　　4）确定用例编写进度；

　　5）正式编写；

　　6）用例验证；

　　7）明确测试用例执行顺序。

　　四、实施测试
　　1）确定实施进度；

　　2）搭建测试环境；

　　3）执行测试用例，记录用例执行结果，报告缺陷；

　　4）记录度量数据；

　　5）维护测试用例。

　　五、测试总结
　　1）测试停止评估（参照测试用例执行情况，缺陷收敛情况，与测试指标偏差情况等）；

　　2）测试总结报告；

　　3）提交汇总度量数据，测试部门存档。