【摘要】 目前 OA 系统软件在软件项目中占有一定的比重，本文主要针对 OA 系统软件需求，给出相应的软件测试分析的基本思路。

    【关键字】 办公自动化系统、软件需求

·办公自动化系统的简介

  办公自动化即 Office Automation ，简称 OA 。

  目前流行的办公自动化系统多采用多层体系结构，其应用服务架构位于中间层之上，客户端通过常用的 IE 浏览器界面访问系统，具有接口统一、访问简单、易升级、易扩充的特点。

  就以上特点来说，办公自动化系统的测试可以使用 B/S 结构的测试策略来组织。

  下面我们就从软件工程过程的几个阶段 — 需求、设计、编码，分阶段地来进行分析如何针对办公自动化系统组织测试分析。

· 针对 OA 需求、设计的特点组织测试分析

  办公自动化系统擅长处理类似公告、公文等流转类型的行政办公类应用需求、设计及相对独立的个人相关资料、名片、记事等个人事务类的需求、设计。

  办公自动化系统软件的权限管理是其不同于其他应用软件的另外一个特点。系统需要为使用人员提供设置不同的权限和访问许可的功能，管理员可以通过调整各功能模块的访问权限，设置一般用户某些功能可以用，某些功能不允许用；并为员工创建、注销帐号及访问权限。提高了企业系统的资料的安全度，阻止非授权人的非法进入系统。

· 针对流转型的行政办公需求、设计

  流转型的行政办公需求、设计通常包括有：拟稿、审核、签收、会签、拟办、签批、电子签名、交办、退稿、备查、提交归档、打印、销毁等业务处理功能。在行政办公的业务流程处理中还牵涉到复杂的用户权限和访问许可的功能。

  针对这种情况，在进行测试需求分析和设计时，最好使用现成的公司体制来进行分析。这样做的好处有两个：

· 沟通方便。

  现成的公司体制中的角色和人员比每个测试人员自己单独构造虚拟的用户权限和访问许可要容易理解和容易沟通的多。

  对于测试执行过程中发现缺陷时，描述的缺陷让开发人员和测试人员沟通起来更加方便。

· 测试数据准备容易，且不易产生歧异。

  由于 OA 系统使用的对象是整个公司所有员工或者是某部门员工，如果我们使用现成的公司体制，我们只需要统一准备一套测试数据就可以满足所有测试对象的要求。

  测试人员在沟通时，不会由于构造的数据不同，而引起不必要的歧异，人为的增加测试组内部沟通的障碍。

· 针对独立型的个人事务需求和设计

  独立性的个人事务通常包括有：维护并查看个人和公共的活动日程安排，并能自动提醒所有个人的待办事项，允许用户可以查询各种信息。但个人事务通常只允许用户本人维护和查看个人的事务，不允许其他用户维护和查看。目前有的 OA 系统中甚至包括管理员在内的超级用户也不能维护和查看私人的个人事务处理情况。

  针对上面的特殊情况，在进行测试需求分析和设计时，首先要考虑统一给不同用户打上特殊标记。接下来在准备测试数据时，应避免不同用户具有相同的个人信息和相关资料的情况产生，以免在测试执行过程中测试人员陷入混乱状态，连测试人员自己都搞不清楚到底使用的是哪一个用户的信息。

· 针对 OA 编码的功能特点组织测试分析

  常见的 OA 系统功能模块主要有：行政办公、个人事务、综合信息、基础服务四个部分。

·行政办公

  行政办公通常包括收文管理、发文管理、档案管理和会议管理等模块。有的 OA 系统还包括有接待管理、办公资源管理模块。

  这四个模块是典型的流转型模块，它们都有流程定义、登记（或拟稿）、办理、拟稿、审核、签收、会签、拟办、签批、电子签名、交办、退稿、备查、提交归档、打印、销毁、归档、查询、流程跟踪、查看意见、重定位等操作过程。

  以收文管理为例，主要对公文进行登记和处理，包括内部公文和外部公文。在登记收文过程中提供了多种种方式，比如文件引入、电子公文调入、扫描和直接输入，并将登记后的收文送领导批示或阅读（批示的流程完全可以根据用户的需要自己定义，也可以使用系统管理员已经定义好的公文批示流程），处理结束后将文件进行归档。管理人员可以对收文处理全过程进行监督、催办、重定位，也可以随时进行文件流程跟踪及查看其所有领导的批示意见、批示时间。

  针对这些情况，在进行测试分析和设计时，首先按照上面提到的根据现成的公司体制进行分析和设计的测试数据，然后将各个领导是否兼职的情况区分开来。通常建议准备这样两套数据：

·领导不兼职

  领导不兼职的情况，相对较简单，即每个领导只负责一个批示。

  在执行测试过程中，还需要重点注意批示的并行和串行的情况。

· 领导兼职

  领导兼职的情况，即每个领导可能负责不同过程中多个批示，是流转型模块测试的一个难点，需要特别注意。

  跟上面的情况一样，同时也要考虑批示的并行和串行的情况。在测试执行过程中，其组合方式是否能够全面覆盖，与测试人员的经验、对模块的需求和设计熟悉程度、测试数据准备是否充分以及测试人员是否考虑周到全面等因素息息相关。

·个人事务

  个人事务通常包括：待办工作、日程安排、个人资料、个人名片、个人记事本、外出声明等模块。有的 OA 系统还包括个人邮件、及时消息模块。

  个人事务以其独立性，完成个人日常的办公工作，例如批阅各部门上报的各种公文，评阅同事交流的各种文件内容，回复或发送电子邮件，起草各类报告，查看个人的活动日程、外出等安排，系统能自动提醒待办事项。

  以个人名片为例，用户可将名片登记并进行管理查询和打印，同时可根据需要将部分名片共享，供他人使用。每个人只能看到自己的名片集及共享的名片集，通过所有由个人收集的名片以及整个单位的名片总集，可很快找出所需要联系的名片主人，并方便地通知他们参加会议或发送邮件等等。

  在进行测试分析、设计和执行中需要特别考虑：

  · 新建或修改的名片时对于输入重复的名片是否给予提示警告；

  · 新建或修改的名片时个人维护的私有名片是否能被其他人看到或使用；

  · 个人删除私有名片时是否影响到其他用户的名片；

  · 共享的名片是否可以被其他人正确查看和使用；

  · 单位的名片集修改后，是否正确影响个人的单位名片集；

  · 给需要联系的名片主人联系时，是否可以正确联系上，其联系内容是否显示正确；

·综合信息

   综合信息通常包括：建议管理、电子论坛、网上调查、电子贺卡、信息采集等模块。

以信息采集为例，信息采集可以通过各种渠道，从所有可利用的信息源收集办公需要的信息，从各种媒体采集各种相关信息后作为原始信息记录在案，经过筛选整理后编辑成各种主题的信息刊物。同时信息刊物也支持套红头转入行政办公的公文模块中。可以方便地查询、检索信息刊物及其所有原始信息内容。并对信息采用和阅读情况、次数进行统计。

  在进行测试分析、设计和执行时要重点考虑：

    · 从信息来源收集信息时，是否能正确完好的保存其原始信息的内容和格式；

    · 整理后的信息是否能正确完好的保存其原始信息的内容和格式；

    · 整理后的信息是否能正确转入公文流程中；

    · 基础服务

  基础服务包括：人员注册、部门设置、数据维护等模块。

  以数据维护为例：系统为系统的管理员提供了多项数据维护的服务。可以对一些常用的数据进行设置，包括用户登录名 / 用户密码组合方式、用户登录名 / 用户密码长度、主题词、常用意见、自动编号、存储大小、存储时间和公文格式，也可以对行政办公中所要使用的各个流转模块的流程进行预定义。

  在进行测试分析、设计和执行时要特别考虑：

    · 用户登录名 / 用户密码组合方式设置是否正确；

    · 用户登录名 / 用户密码长度设置是否正确、有效；

    · 存储大小设置是否正确、有效；对于超出设定的存储大小系统是否能正确提示；

    · 预定义的行政办公中各个流转模块是否能被正确应用；

    · 小结

  OA 系统的某些业务与其他知识管理系统相类似，但由于其鲜明的特点，目前已经自成体系。

  本文介绍的测试分析主要与 OA 特有的业务处理方法紧密联系，作为测试人员介入 OA 项目时如何有重点的进行测试分析。

  与其他 B/S 结构的系统所要进行的界面测试、边界测试、非法校验、字段限制等方法一样，在实际执行测试过程之前都需要一一进行分析，在此就不赘述了。

【摘要】
软件测试是软件工程的一个重要部分。论文首先阐述了软件测试的目的、分类和工作流程，测试按照步骤分为单元测试、集成测试、确认测试和系统测试。接着详细地分析了这四种测试的方法。最后介绍了软件测试自动化的一些具体做法。
【关键词】
软件测试黑盒测试 白盒测试 单元测试 集成测试 确认测试 系统测试

    The Study of Software Testing Technology

Abstract
  Software testing is an important part of software engineering. At first this article studies the purpose, classification and procedures of software testing. Then it analyzes the methods of module testing, integration testing ,validation testing and system testing respectively. At last some instances of the application of automation in software testing are presented.


Keywords
  Software testing , black-box testing , white-box testing , module testing
  integration testing, validation testing ,system testing
 
一、软件测试
1、软件测试的目的
软件测试是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，它是软件质量保证的关键步骤。测试要求以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量。
 软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。这里引用Grenford J. Myers在《The Art of Software Testing》一书中的观点：
　　①、软件测试是为了发现错误而执行程序的过程；
　　②、测试是为了证明程序有错，而不是证明程序无错误。
　　③、一个好的测试用例是在于它能发现至今未发现的错误；
　　④、一个成功的测试是发现了至今未发现的错误的测试。
软件测试是一项细致并需要高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试。为了降低测试成本，选择测试用例时应注意遵守"经济性"的原则。

2、软件测试的分类
从测试的类型来看，测试分为2种：黑盒测试和白盒测试。
黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。
白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。
  从测试实际的前后过程来看，软件测试上是由一系列的不同测试所组成，这些软件测试的步骤分为：单元测试、组装测试（集成测试）、确认测试和系统测试。
单元测试针对每个模块进行的测试，通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。集成测试在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。确认测试验证软件的功能和性能及其它特性是否与用户的要求一致，系统测试是在实际运行环境下进行一系列的测试。软件开发的过程是自顶向下的，测试则正好相反，以上这些过程就是自底向上，逐步集成的

3、软件测试工作的流程：

测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。由此可见，软件测试工作应该贯穿于整个软件开发阶段。

下面是软件测试工作的总体流程图和每个主要阶段的流程图：


二、单元测试

1、 什么是单元测试
单元测试是在软件开发过程中要进行的最低级别的测试活动，测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。
　　在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中，要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言(4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。
　　单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。
　　经常与单元测试联系起来的另外一些开发活动包括代码走读(Code review)，静态分析(Static analysis)和动态分析(Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

2、单元测试任务　
　单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。
　　模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：
　　1 输入的实际参数与形式参数的个数是否相同；
　　2 输入的实际参数与形式参数的属性是否匹配；
　　3 输入的实际参数与形式参数的量纲是否一致；
　　4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
　　5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
　　6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
　　7 调用预定义函数时所用参数的个数、属性和次序是否正确；
　　8 是否存在与当前入口点无关的参数引用；
　　9 是否修改了只读型参数；
　　10 对全程变量的定义各模块是否一致；
　　11是否把某些约束作为参数传递。
如果模块内包括外部输入输出，还应该考虑下列因素：
　　1 文件属性是否正确；
　　2 OPEN/CLOSE语句是否正确；
　　3 格式说明与输入输出语句是否匹配；
　　4缓冲区大小与记录长度是否匹配；
　　5文件使用前是否已经打开；
　　6是否处理了文件尾；
　　7是否处理了输入/输出错误；
　　8输出信息中是否有文字性错误；

检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
　　1 不合适或不相容的类型说明；
　　2变量无初值；
　　3变量初始化或省缺值有错；
　　4不正确的变量名（拼错或不正确地截断）；
　　5出现上溢、下溢和地址异常。
　　除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。
　　在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：
　　1 误解或用错了算符优先级；
　　2混合类型运算；
　　3变量初值错；
　　4精度不够；
　　5表达式符号错。
　　比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：
　　1不同数据类型的对象之间进行比较；
　　2错误地使用逻辑运算符或优先级；
　　3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
　　4比较运算或变量出错；
　　5循环终止条件或不可能出现；
　　6迭代发散时不能退出；
　　7错误地修改了循环变量。
　　一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：
　　1输出的出错信息难以理解；
　　2记录的错误与实际遇到的错误不相符；
　　3在程序自定义的出错处理段运行之前，系统已介入；
　　4异常处理不当；
　　5错误陈述中未能提供足够的定位出错信息。
边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。

3、单元测试的过程与环境
　　一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。
　　应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为"主程序"，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，"主程序"打印"进入-退出"消息。
　　驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。
　　提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。




三、集成测试的基本方法

  时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。　
　某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。
下面讨论两种增量式集成方法。
1、自顶向下集成　　
自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把M2、M3和M4与主控模块集成在一起，再将M5和M6 和其他模块集资集成起来。　　
自顶向下综合测试的具体步骤为：　　
1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；　　2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；　　3 每集成一个模块立即测试一遍；　　4 只有每组测试完成后，才着手替换下一个桩模块；　　5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。　　 从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。下图中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。　
　自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。

2、自底向上集成　　
自底向上测试是从"原子"模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。　　
自底向上综合测试的步骤分为：　　
1 把低层模块组织成实现某个子功能的模块群（cluster）;　　2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；　　3 对每个模块群进行测试；　　4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。　　从第一步开始循环执行上述各步骤，直至整个程序构造完毕。　　下图说明了上述过程。首先"原子"模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可对MaD3被去掉后，M3与模块群3直接接口，可对Mb进行集成测试，最后Ma、Mb和 Mc全部集成在一起进行测试。
   
自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。
　　此外，在综合测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：①对应几条需求；②具有高层控制功能；③复杂、易出错；④有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。

四、确认测试的基本方法


通过集成测试之后，软件已完全组装起来，接口方面的错误也已排除，确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

1. 确认测试标准　　实现软件确认要通过一系列墨盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。　　确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
2. 配置复审　　确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。
3. α、β测试　　事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列"验收测试"。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。　　α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

五、系统测试的基本方法

计算机软件是基于计算机系统的一个重要组成部分，在系统测试之前，软件工程师应完成下列工作：　　
为测试软件系统的输入信息设计出错处理通路；　
设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；　　
参与系统测试的规划和设计，保证软件测试的合理性。　　
系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。
下面简单讨论几类系统测试。
１、恢复测试　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
２、安全测试　　安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。
３、强度测试　　强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
４、性能测试　　对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

六、软件测试自动化的一些具体做法
因为软件测试的工作量很大（40% 到60% 的总开发时间），而又有很大部分适于自动化，因此，测试的改进会对整个开发工作的质量、成本和周期带来非常显著的效果。　　
　 下面举出一些测试自动化的例子：
1.   测试个案（test case ，或称为测试用例）的生成　　
用编程语言或更方便的剧本语言（scrīpt language 例如Perl等）写出短小的程序来产生大量的测试输入（包括输入数据与操作指令）。或同时也按一定的逻辑规律产生标准输出。输入与输出的文件名字按规定进行配对，以便控制自动化测试及结果核对的程序易于操作。　　这里提到测试个案的命名问题，如果在项目的文档设计中作统一规划的话，软件产品的需求与功能的命名就应该成为后继开发过程的中间产品的命名分类依据。这样，就会为文档管理和配置管理带来很大的方便，使整个产品的开发过程变得更有条理，更符合逻辑。任何新手半途加入到开发工作中也会更容易进入状态。
2.   测试的执行写控制　　
单元测试或集成测试可能多用单机运行。但对于系统测试或回归测试，就极有可能需要多台机在网络上同时运行。记住一个这样的原则，在开发过程中的任何时候，如果你需要等候测试的运行结果的话，那就是一个缩短开发时间的机会。对于单个的测试运行，挖潜的机会在测试的设置及开始运行和结果的对比及显示。有时候，需要反复修改程序，重新汇编和重新测试。这样，每一个循环的各种手工键入的设置与指令所花费的时间，加起来就非常可观。如果能利用make或类似的软件工具来帮助，就能节省大量的时间。 对于系统测试或回归测试这类涉及大量测试个案运行的情况，挖潜的的机会除了利用软件工具来实现自动化之外，就是怎样充分利用一切硬件资源。往往，就算是在白天的工作时间内，每台计算机的负荷都没有被充分利用。能够把大量测试个案分配到各台机器上去同时运行，就能节省大量的时间。另外，把大量的系统测试及回归测试安排到夜间及周末运行，更能提高效率。如果不购买商品化的工具的话，应当遵从正规的软件开发要求来开发出好的软件测试自动化工具。在实践中，许多企业自行开发的自动化工具都是利用一些现成的软件工具再加上自己写的程序而组成的。这些自己开发的工具完全是为本企业量身定做的，因此可用性非常强。同时，也能根据需要随时进行改进，而不必受制于人。在设计软件自动测试工具的时候，路径（path）控制是一个非常重要的功能。理想的使用情况是：这个工具可以在任何一个路径位置上运行，可以到任何路径位置去取得测试用例，同时也可以把测试的结果输出放到任何的路径位置上去。这样的设计，可以使不同的测试运行能够使用同一组测试用例而不至于互相干扰，也可以灵活使用硬盘的空间，并且使备份保存工作易于控制。同时，软件自动测试工具必须能够有办法方便地选择测试用例库中的全部或部分来运行，也必须能够自由地选择被测试的产品或中间产品采作为测试对象。
3.   测试结果与标准输出的对比　
　 在设计测试用例的时候，必须考虑到怎样才能够易于对此测试结果和标准输出。输出数据量的多少及数据格式对比较的速度有直接影响。而另一方面，也必须考虑到输出数据与测试用例的测试目标的逻辑对应性及易读性，这将会大大有利于分析测试所发现的不吻合，也有利于测试用例的维护。　　许多时候，要写一些特殊的软件来执行测试结果与标准输出的对比工作，因为可能有部分的输出内容是不能直接对比的（比如，对运行的日期时间的记录，对运行的路径的记录，以及测试对象的版本数据等），就要用程序进行处理。
4.   不吻合的测试结果的分析、分类、记录和通报　　
上一点所谈到的，用于对测试结果与标准输出进行对比的特殊软件，往往也同时担任对不吻合的测试结果进行分析、分类、记录和通报的任务。"分析"是找出不吻合的地方并指出错误的可能起因。"分类"包括各种统计上的分项，例如，对应的源程序的位置，错误的严重级别（提示、警告、非失效性错误、失效性错误；或别的分类方法），新发现的还是已有记录的错误，等等。"记录"，是按分类存档。"通报"，是主动地对测试的运行者及测试用例的"负责人"通报出错的信息。　　 这里提到测试用例的"负责人"的概念。是用以指定一个测试用例运行时发现的缺陷，由哪一个开发人员负责分析（有时是另外的开发人员引进的缺陷而导致的错误）及修复。在设立测试用例库时，各用例均应有指定的负责人。　　最直接的通报方法是由自动测试软件发出电子邮件给测试运行者及测试用例负责人。邮件内容的详细程度可根据需要灵活决定。
5.   总测试状况的统计，报表的产生　　

这些都是自动测试工具所应有的功能。目的是提高过程管理的质量，同时节省用于产生统计数据的时间。产生出来的统计报表，最好是存放到一个约定的路径位置，以便任何有关人员都知道怎样查阅。同时，可按需要用电子邮件向适当的对象（如项目经理，测试经理和质量保证经理）寄出统计报表。

20070110

sunxiaoyong
QQ: 12585990
MSN:sunxy5291@hotmail.com
SoftWareTesting Blog:http://sunxy5291.blog.xaonline.com
MSN Spaces:http://sunxy5291.spaces.live.com

thanks...

1.1 文本框、按钮等控件测试

1.1.1 文本框的测试

如何对文本框进行测试

　a,输入正常的字母或数字。
　b,输入已存在的文件的名称；
　c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
　d,输入默认值，空白，空格；
　e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；
　f,利用复制，粘贴等操作强制输入程序不允许的输入数据；
　g,输入特殊字符集，例如，NUL及\n等；
　h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
　i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

在测试过程中所用到的测试方法：

　1,输入非法数据；
　2,输入默认值；
　3,输入特殊字符集；
　4,输入使缓冲区溢出的数据；
　5,输入相同的文件名；

命令按钮控件的测试

测试方法：

　a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
　b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；
　c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；

单选按钮控件的测试

测试方法：

　a,一组单选按钮不能同时选中，只能选中一个。
　b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
　c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；

up－down控件文本框的测试

测试方法：

　a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
　b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
　c,直接输入超边界值，系统应该提示重新输入；
　d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；
　e,输入字符。此时系统应提示输入有误。

组合列表框的测试

测试方法：

　a,条目内容正确，其详细条目内容可以根据需求说明确定；
　b,逐一执行列表框中每个条目的功能；
　c,检查能否向组合列表框输入数据；

复选框的测试

测试方法：

　a,多个复选框可以被同时选中；
　b,多个复选框可以被部分选中；
　c,多个复选框可以都不被选中；
　d,逐一执行每个复选框的功能；

列表框控件的测试

测试方法：

　a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
　b,列表框的内容较多时要使用滚动条；
　c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；

滚动条控件的测试

要注意一下几点：

　a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
　b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
　c,单击滚动条；
　d,用滚轮控制滚动条；
　e,滚动条的上下按钮。

各种控件在窗体中混和使用时的测试

　a,控件间的相互作用；
　b,tab键的顺序，一般是从上到下，从左到右；
　c,热键的使用，逐一测试；
　d,enter键和esc键的使用；

在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

ps:密码输入框测试时要特别注意进行字母大写输入的测试。

查找替换操作
　案例演示:打开word中的"替换"对话框
　测试本功能有通过测试和失败测试两种情况
　通过测试:

　1,输入内容直接查找,或查找全部
　2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.

失败测试:
　1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
　2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;

替换测试大体相同.
　关于编辑操作窗口的功能测试的用例:
　1,关闭查找替换窗口.不执行任何操作,直接退出;
　2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
　3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
　4,热键, Tab键.回车键的使用.

插入操作
　1,插入文件
　测试的情况
　a,插入文件;
　b,插入图像;
　c,在文档中插入文档本身;
　d,移除插入的源文件;
　e,更换插入的源文件的内容;

2,链接文件
　测试方法:
　a,插入链接文件;
　b,在文档中链接文档本身;
　c,移除插入的源文件;
　d,更换插入的源文件的内容.

3,插入对象
　要测试的内容
　a,插入程序允许的对象,如,在word中插入excel工作表;
　b,修改所插入对象的内容.插入的对象仍能正确显示;
　c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.

编辑操作
　编辑操作包括剪切,复制,粘贴操作.

测试剪切操作的方法
　a,对文本,文本框,图文框进行剪切;
　b,剪切图像
　c,文本图像混合剪切
　复制操作方法与剪切类似.

测试时,主要是对粘贴操作的测试,方法是:
　a,粘贴剪切的文本,文本框及图文框;
　b,粘贴所剪切的图像;
　c,剪切后,在不同的程序中粘贴
　d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
　e,利用粘贴操作强制输入程序所不允许输入的数据.

界面测试用例的设计方法
　1,窗体
　测试窗体的方法:
　a,窗体大小,大小要合适,控件布局合理;
　b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
　c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
　d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
　进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;

2,控件
　测试方法:
　a,窗体或控件的字体和大小要一致;
　b,注意全角,半角混合
　c,无中英文混合.

菜单

进行测试时要注意
　a,选择菜单是否可以正常工作,并与实际执行内容一致;
　b,是否有错别字:
　c,快捷键是否重复;
　d,热键是否重复;
　e,快捷键与热键操作是否有效
　f,是否存在中英文混合
　g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
　h,鼠标右键快捷菜单

特殊属性
　1,安装界面应有公司介绍或产品介绍,有公司的图标
　2,主界面及大多数界面最好有公司图标
　3,选择"帮助"->"关于"命令,应看见相关版权和产品信息

1.应验证界面显示内容的完整性：

　　a) 报表显示时应考虑数据显示宽度的自适应或自动换行。

　　b) 所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等)，必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常;

　　2.应验证界面显示内容的一致性：

　　a) 如有多个系统展现同一数据源时，应保证其一致性;

　　3.应验证界面显示内容的准确性：

　　a) 对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“--”或“/”，表示该字段值无意义。

　　4.应验证界面显示内容的友好性：

　　a) 对统计的数据应按用户习惯进行分类、排序。

　　b) 某些重要信息在输入、修改、删除时应有“确认”提示信息;

　　c) 界面内容更新后系统应提供刷新功能。

　　d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;

　　5.应验证界面提示信息的指导性：

　　a) 在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。

　　b) 用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕。

　　c) 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。

　　d) 在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);

　　6.应验证界面显示内容的合理性：

　　a) 在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。

　　b) 界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。

　　c) 界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确;

　　7.界面测试时，应考虑用户使用的方便性：

　　a) 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。

年来了，过去的一年，或许有天灾， 或许有人祸，让你感觉不开心，   但是想想自己， 是否什么事都尽了全力？得到了你想要的东西？   是否开心豁达的面对一切，觉得生活圆圆满满？ 是否找到了你命中注定的另一半，开始甜蜜生活？   是否工作卓有成效，得到了老板的赏识和提拔？ 万事无论是否取得了成功，相信你都付出了努力。 在新的一年里，你： 好好，天天。 要好，好，赚多多的 但也别　尽量少　 弄到头发晕更别变成这样。 要多多 、 遇到喜欢的 ，别太　， 请她，送她 。 如果她主动 ，别跑掉。 爱情没有时间表，　最重要。 如果不幸，别，也不要 ，万万不能或者。 好好想想， 等待下一个来到。 不要成天， 要多吃 ，但别忘了 。 有空听听 跳跳　 ，经常去　 偶尔安静一下，发泄一番 希望能常看到你的！ 祝福你2007年 人逢盛世情无限；猪拱华门岁有余。 人增福寿年增岁；鱼满池塘猪满栏。 大圣除妖天佛路；天蓬值岁兆丰年。 巳有长风千里志；亥为二首六身形。 丰稔岁中猪领赏；新台阶上步登高。 天好地好春更好；猪多粮多福愈多。 犬过千秋留胜迹；亥年跃马奔小康。 牛马成群勤致富；猪羊满圈乐生财。

过年啦... 放假啦... 乌啦啦...

测试各个阶段定义及比较

很高兴 百度空间开通啦：http://hi.baidu.com/sunxy5291 

我同时也成为了baidu blog的测试用户，哈哈！

欢迎大家 光临我的百度空间！

 

低层管理者不论是作为一名执行者、还是一名领导者，都必须通过别人来完成任务。要做个“服众”的经理人，应该有意识地提高以下八项能力：
1. 领悟能力
    做任何一件事以前，一定要先弄清楚上司希望你怎么做，然后以此为目标来把握做事的方向，这一点很重要，千万不要一知半解就开始埋头苦干，到头来力没少出、活没少干，但结果是事倍功半，甚至前功尽弃。要清楚悟透一件事，胜过草率做十件事，并且会事半功倍。
2. 计划能力
    执行任何任务都要制定计划，把各项任务按照轻、重、缓、急列出计划表，一一分配部属来承担，自己看头看尾即可。把眼光放在部门未来的发展上，不断理清明天、后天、下周、下月，甚至明年的计划上。在计划的实施及检讨时，要预先掌握关键性问题，不能因琐碎的工作，而影响了应该做的重要工作。要清楚做好20%的重要工作，等于创造80%的业绩。
3. 指挥能力
    无论计划如何周到，如果不能有效地加以执行，仍然无法产生预期的效果，为了使部属有共同的方向可以执行制定的计划，适当的指挥是有必要的。 指挥部属，首先要考量工作分配，要检测部属与工作的对应关系，也要考虑指挥的方式，语气不好或是目标不明确，都是不好的指挥。而好的指挥可以激发部属的意愿，而且能够提升其责任感与使命感。要清楚指挥的最高艺术，是部属能够自我指挥。
4. 控制能力
    控制就是追踪考核，确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉，然而企业的经
营有其十分现实的一面，有些事情不及时加以控制，就会给企业造成直接与间接的损失。但是，控制若是操之过急或是控制力度不足，同样会产生反作用：控制过严使部属口服心不服，控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制，就是让部属通过目标管理方式实现自我控制。
5. 协调能力
    任何工作，如能照上述所说的要求，制定完善的计划、再下达适当的命令、采取必要的控制，工作理应顺利完成，但事实上，主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调，也包括与外部客户、关系单位、竞争对手之间的利益协调，任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。
6. 授权能力
    任何人的能力都是有限的，作为高级经理人不能象业务员那样事事亲历亲为，而要明确自己的职责就是培养下属共同成长，给自己机会，更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子，也是延伸自己智力和能力的载体，要赋予下属责、权、利，下属才会有做事的责任感和成就感，要清楚一个部门的人琢磨事，肯定胜过自己一个脑袋琢磨事，这样下属得到了激励，你自己又可以放开手脚做重要的事，何乐而不为。切记成就下属，就是成就自己。
7. 判断能力
    判断对于一个经理人来说非常重要，企业经营错综复杂，常常需要主管去了解事情的来龙去脉因果关系，从而找到问题的真正症结所在，并提出解决方案。这就要求洞察先机，未雨绸缪。要清楚这样才能化危机为转机，最后变成良机。
8. 创新能力
    创新是衡量一个人、一个企业是否有核心竞争能力的重要标志，要提高执行力，除了要具备以上这些能力外，更重要的还要时时、事事都有强烈的创新意识，这就需要不断地学习，而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的，它要求大家把工作的过程本身当作一个系统的学习过程，不断地从工作中发现问题、研究问题、解决问题。解决问题的过程，也就是向创新迈进的过程。因此，我们做任何一件事都可以认真想一想，有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限，唯有创新，才能生存。
领导力更需提升
    那么，怎样才能提升领导力呢？除了提高以上八项能力之外，还有最重要的两点：
1. 学会用老板眼光看企业。
    在老板看来，管理很简单，就是两件事：一是扩大业务范围，增加业务收人；另一件事就是降低管理成本，控制运作费用。其实这两件事，最终是一件事，收入减去成本，减去费用，就是利润。所以归根到底老板是看利润的，利润要从管理中来。
2. 从被领导中学习领导。
    在领导人看来，领导也很简单，就是两件事：一是用人，内圈用德、外圈用才，用人所长、容人所短；二是激励，解人之难、记人之功，通过正面激励，引导下属往前跑，通过负面激励，推着下属往前走。要知道，任何领导都是从做下属开始的，谁都不可能一步登天当领导。在每个人的成长过程中，你会经历大大小小许多领导，只要你用心学习，不管是好领导、还是坏领导，你都可以从正反两方面学到经验和教训，这对你将来当好领导是十分珍贵的

 

一、根基不牢
问题：利用等价类划分的方法，对某问题设计测试用例。

分析：98%以上的应聘者只知道按照有效等价类和无效等价类进行划分，殊不知此种分类方法只是等价类划分的一个典型应用而已，等价类划分远非只能划分为有效和无效两类。根据种种划分依据，还可以进一步划分很多其他类别。

问题：根据事件描述，画出对应的因果图。

分析：标准答案中只画了“两条恒等，两条非，一个与，一个或”。如此简单的问题，上百名应聘者中竟然无一人答对，痛心啊。黑盒测试方法就那么几种，既然你已知这个名，怎么就不知道多看几眼。

★ 小结：

上面提到的是软件测试的最基本的方法，作为从业测试实际工作已经有1-2年的应聘人员，未能真正领悟，实属不应该，心浮气躁，忽视了你身边最简单，也是最厉害的技能。根基不牢，怎么可能把测试做深。

二、专业不精

问题：音视频文件都有哪些格式，这些格式之间有什么差别？

分析：此问题是问那些做过多媒体方面测试的，但是我们的应聘者向来都是拿来主义，别人给我什么媒体文件我就用什么做测试，而根本不管不问。“为什么MIDI文件比WAV文件小那么多？我们如何知道扩展名是.Mpeg的文件是Mpeg1格式的还是Mpeg2格式的？”，面对这些问题，应聘者默默无语，只是无奈的笑笑。不去看别人，想想自己测试涉及的专业，是否把那个行业知识搞清楚了呢？

问题：测试脚本运行不畅如何调试？

分析：此问题是问那些标明自己熟练掌握WinRunner、Robot、QTP等测试工具的应聘人员，但是当真正问到他们关于脚本的具体调试时，有7成以上人员表示他们只是参加测试培训时老师讲过，或者自己在网上看过相关资料，另外有2成以上人员表示他们虽然用过，但是只是简单的录制回放，根本不会自己调试。可能是迫于无奈吧，简历里面什么都不写，可能面试的机会都没有，但是简历如此夸大的来写，终归是浪费自己的面试时间和路费。

★ 小结：

从事测试仅1-2年时间，要想测试也精通，专业也精通确实不易，但是不说精通，至少也该知道个60%才对的起你的测试工作。一两年时光如此荒废，静下心来反思一下，身边还有哪些技能我们应该掌握扎实一点呢。

三、无测试体系概念，忽视理论

问题：请说出软件测试的定义，BUG的定义。

分析：99%的人不能说出这两个测试名词的定义，只是在给我解释测试是为了发现bug之类的片面理解，残留的几个人也说得不够准确。这两个词目前尚不能说业内已经有了成熟统一的定义，但是无论是对是错，身为测试人员已经数年，自己竟然说不出这两个词的概念，多少也说不过去啊。有些人和我说，理论名词概念不重要，我会做测试就是了。想想金庸老先生早就告诉我们，武功仅有招式是不够的，必须配合上什么心法口诀才能行。你只会测试执行的招式，却不懂测试理论的心法，怎么能够修炼成上乘的软件测试呢？

问题：请介绍一下你们的测试流程，流程和过程有什么不同，为什么好的测试需要好的流程？

分析：但凡做过1、2年测试的人都能给我说出他们先做什么后做什么，但是当我继续问“这是否可以叫做过程？流程和过程有什么差别”，应聘者一棒子被打晕，继续追问“为什么好的测试需要好的流程”的时候，早已经找不到东南西北了。每天公司各项制度叫你做什么你就做什么，让你怎么做你就怎么做，完全不管不顾为什么，那么自己岂不成了没头脑的工具。这样你能干的工作别人也能做，自己的优势不就没有了吗。

★ 小结：

目前测试业内流传着学院派和实践派的说法，学院派的理论给人的感觉往往是好听但不实用，而实践派的知识，往往能够立即见效。所以眼下测试培训往往实践派的更受欢迎。继续引用金庸先生的观点，练武分练内气宗，练外剑宗，但是真正的高手是内外兼修。如果我们不想只做普通的测试小弟子的话，就要理论实践并重，方能有所作为。

四、周边知识知之甚少

问题：能给我介绍一下软件工程中的瀑布模型吗？

分析：又是8成应聘者不会回答，都是曾在遥远的学生时代有所耳闻，现今早已忘得一干二净了。软件测试因何而生——软件危机，软件危机导致软件工程的兴起，软件工程中又包含软件测试，就好像鱼儿活在水里，如果没有软件工程这个水，哪里能够养活这软件测试的鱼，如果我们对于身边的软件工程不够了解，怎么可能在里面自由的畅游呢。

问题：用你最熟悉的开发语言实现sum=1+2+3+…+100

分析：保守统计7成以上的应聘者写出来的程序无法执行或者运行结果错误，更少有人能够一气呵成，而且精准。这道编程题难吗？肯定不难，那么为何答错，自己没有真正写过程序，即使写过几行，也早就是如烟往事了。做测试一定需要懂开发吗？这个问题讨论以久，当然不一定，但是如果要做好测试，做深测试，分析问题原因，提出问题解决方案，编写测试脚本或工具，哪一个又能离开软件开发呢？

★ 小结：

我们学习测试也应该有个先后顺序，有步骤。掌握周边知识的紧迫程度可能不如测试知识和行业知识。但是对于我们已经从业1-2年的测试人员来说，学校里面学到的知识不应该丢，之后的发展中，周边知识的学习也应该开始了。周边知识的范畴其实很广，还包括各种其他测试理念的学习，机械工业出版社翻译的那套测试丛书就很不错，观点众多而新颖，博众家之长，集大成，向来都是大家风范。

五、缺乏必要的责任心、细心、耐心、虚心等

问题：请数出下图中三角形的个数（平面图，有几根弧线做干扰）

分析：我总是问自己，这道题真有这么难吗？连中小学生都能数对的十几个三角形，到了我们这二十几岁的年轻人手中，正确率才1%，为什么？其实就是现在我们已经很少有人能够静下心来，耐心细致的去做事情了。很多应聘者告诉我她的优点就是“踏实，坐的住，正适合这繁琐的测试工作”。我需要的不是坐在那里不做事或者做错事的人，而是需要能够按时保质量完成测试工作的测试人员。

问题：你离职的原因？

分析：这是面试中最常见的问题了。应聘者往往也是充分准备，理由多种多样，但是看看应聘者的工作记录统计，70%应聘者平均跳槽频率是1年/次（实习情况除外），不会都那么凑巧吧，赶上什么公司倒闭，每隔一年就会想一次自己学不到东西，需要去外面看看。而在我看来，真正的原因更多的应该是希望通过跳槽提高工资，或者因为自身水平不足被公司炒鱿鱼吧。

★ 小结：

我并不认为所有的人都适合做测试。非技术素质方面，这点或者那点不足够优秀也很正常，心浮气躁也可以理解。但是作为用人单位，理解归理解，却也不会用不胜任岗位，或性价比不高的人员。那么对于此类应聘者，我的忠告就是，要么你另谋高就，要么你就放低姿态，培养好你必备的素质后再谈。

六、缺乏诚信

这一点本应该被归在上一条素质中，但是这点的重要性我认为远超过了上一条所列各项，因此单独提出。相关表现主要体现在：

○ 报自己历史工薪；

○ 笔试题目作弊；

○ 编造离职原因；

○ 虚报学历，工作经验；

○ 夸大自己工作技能等。对于严重缺乏诚信的，一旦发现，其他表现再好，也无济于事了。

一、单元测试怎么做，如何保证单元测试质量
讨论意见：
1、开发人员不会好好做单元测试
2、有一个标准，规定千行代码的bug数，而已他们的unite test sepc我们也可以提意见，如如果case写的不充分，我们可以不接收的

我的看法：
1、单元测试本身非常繁琐、枯燥、乏味，无论是开发人员做还是测试人员做都是一样难坚持
2、需要通过外部监督来保证单元测试的质量
3、单元测试计划、单元测试大纲、单元测试规范、单元测试报告都需要进行严格的评审
4、从测试用例上可以根据代码的情况规定每千行代码所对应的测试用例数，保证有足够的测试用例
5、从测试报告上可以规定每千行代码所对应的缺陷数，保证单元测试发现了足够多的问题
4、对集成测试、系统测试中发现的缺陷进行归纳总结，针对那些应该在单元测试阶段发现而没有发现的缺陷进行分析，帮助单元测试过程的改进和提高


二、测试管理者如何和测试人员进行良好的沟通
讨论意见：
1、作为主管，不应该总是给下属安排任务
2、平时聊聊天，不要天天谈工作，多位属下争取福利
3、特别不能平白的帮她顶包~~! 工作上不懂，可以帮助她
4、攻心为上，呵呵，你要和她说明，她不是为了你而工作，所以，其实不存在所谓的 谁服谁的问题
5、管理的精髓在于对 “人”的管理，而不是“物件”
6、不要轻易跟别人流露出你对下属的意见
7、好话可以多说，坏话绝不能说，对谁都不能说，这是我的理解
8、同事就是同事，永远不可能是朋友。
9、同事之间，是一种竞争关系，朋友之间是要想互相理解互相帮助的
10、很多人都认为开发和测试有矛盾，因为出发点不一致，所以矛盾难免产生，如果大家都是为了把软件做好，那么其实开发和测试应该是很好的伴侣
11、我想知道的就是，领导跟下属是不是本身就存在一点距离的
12、我打算今后增加为下属做职业规划这一行为

我的看法：
1、管理者和下属，工作和生活要严格区分开，工作时大家是合作关系（不同意是竞争关系^_^），生活时大家可以成为朋友
2、管理者不是用来管理下属的，是为下属服务的，这个观念要转变，帮助下属把工作做好，帮助下属提高自己，帮助下属有更好的发展，这样才能和下属良好沟通
3、工作时领导和下属肯定是有距离的，要做到赏罚分明，一视同仁
4、对于不能和团队整体保持一致的下属，该出手时就出手，该拿掉的就拿掉
5、建议大家看看曾仕强的中国式管理


三、过程改进
讨论意见：
1、我现在做软件过程改进方面的工作。另外监管一下CM、QC、QA
2、主要是过程改进了，因为过程改进与CM、QC、QA，RD都有关系，所以都涉及一些，但都不深
3、很正常的，我们公司现在也是QA部，质量管理部，同时监管 SCM 和 测试部门，当然还有QA
4、其实业务、销售为主导是没错的，开发和测试 是为了这个环节而展开的。
5、这种东西都是长期才能见到效益的
6、企业的首要目的应该就是盈利，这是终极目标，而其他的是中间过程。过程改进也是奔着这个目标而去
7、总体的感觉是：质量、过程是重要的，但是优先级是不高的
8、我认为市场销售和软件生产过程是一个整体，任何一个木片短了，企业的盈利情况就不容乐观
9、没错，现在都在说过程改进，其实 人 的因素也很重要，甚至可以说是最本质的
10、你有没有和你的上级领导沟通过？实施过CMM的人应该知道，过程的改进需要组织级的推动，自顶向下的改进。首先让公司最大的leader首肯这件事，不是敷衍，是亲力亲为

我的看法：
1、非常同意市场销售和软件生产是一个整体的说法，为了提高效率产生了分工，但要明确的是分工而不是分离，如果领导是技术出身，应该不会忽视开发和测试的，如果是市场和销售出身，就需要好的沟通了
2、都说过程改进需要领导点头，从上向下推动，其实过程改进还是要靠QA去推动，至于从上向下，还是从下向上都不是最重要的。
3、不要想一下子就进行大刀阔斧的过程改进，先从容易入手、见效快的地方入手，上下见到了立杆见影的效果，自然会支持，领导不会无缘无故支持一个他看不到任何效果的改进
4、过程改进整体而言是见效慢，但也有见效快的地方，这些就是比较好的过程改进切入点


四、如何针对测试项目考虑测试
讨论意见：
1、看来你们还是比较幸福的，我们公司好多项目都是突发的，没有任何可以计划
2、更讨厌的是，我们的测试任务还会临时调度下来不得不接
3、没有计划没有文档所进行的测试，应用在V模型上确实显得特别的捉襟见肘
4、就是针对不同的实际情况作出的反应以及处理方法
5、举个例子，你现在有一个测试项目需要你负责测试，第一步你会做什么呢？指定测试计划，人力，设备，等等。第二步你会做哪些工作呢？熟悉设计文档，编写test spec
6、其实在没有文档的情况下，我比较推崇XP的结对概念，不过我把它扩大了，XP里说，结对编程，而我认为应该 “凡事皆结对”，结对测试，结对管理
7、我们公司从代码走查中想到进行用例走查
8、在没有文档的时候，结对工作可以弥补文档不足带来的致命后果
9、其实你可以这样想：为什么要结对？一个人做事容易错，容易把方向搞错；两个人会好很多。当然，这不是绝对的。一个泛泛之谈
10、那你清楚你为什么选择在第二步去熟悉设计文档，编写测试用例呢，而不是选择研究软件需求和同类型的软件功能呢

我的看法：
1、无论是什么项目，不管是计划好的，还是突发的，做测试都应该有计划，这个计划既可以形成文档也可以存在于人的大脑里
2、没有文档的测试和有文档的测试没有本质的区别，只不过后者需要寻找其它的方式来了解被测的对象到底要做成什么样了
3、突发的测试任务，对测试负责人提出了更高的要求，他需要尽快确定如何来进行测试，确定测试策略，比如时间紧迫是采取基于风险的测试策略呢还是说采取探索式的测试策略，当然不同的测试阶段有不同的测试策略选择了
4、不管是一个人测试还是结对测试，对被测对象信息的掌握都是一样重要的，对被测对象的原型越了解越有可能测试的更好，所以大家就不要局限在是做白盒测试还是黑盒测试还是灰盒测试的概念问题上了
5、走查是静态测试的一种形式，任何阶段都可以使用
6、即使是做单元测试，需求文档和设计文档一样都是要看的
7、测试时即使只有设计文档没有真正的代码也一样可以“运行”软件，那就是在纸上进行，国外进行一些设计的评审时测试工程师就经常采用这种方式，在白板上让开发人员对每一个“运行”流程进行确认

一 CVS服务器的安装：
1。查看你的操作系统上是否安装了CVS：
#> rpm -qa|grep cvs

如果没有安装你可以在Redhat 第2张光盘上找到，另外你也可以在网上下载到最新的rpm包。很容易找，其实不存在什么linux版本。

2。建立cvs用户组：

#> groupadd cvs

3。建立cvs组的cvsroot用户和所属的目录：

#> useradd -g cvs -G cvs –d /cvsroot cvsroot

4。为cvsroot用户添加密码：

#> passwd cvsroot

5。改变 /cvsroot/ 的目录属性：

#> chmod –R 770 /cvsroot

6。改变用户登陆身份：

#> su cvsroot

7。开始创建单个项目：

#> cd /cvsroot
#> mkdir project1
#>mkdir project2
8。开始建立仓库：

#> cvs –d /cvsroot/project1 init
#> cvs –d /cvsroot/project2 init
#> chmod –R 770 ./project1/ ./project2/

9。建立CVS服务启动文件，我们使用xinetd方式：

#> [Crtl]+[d] 切换到root用户身份
#> cd /etc/xinetd.d
#> vi cvspserver

service cvspserver
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server= /usr/bin/cvs
server_args= -f --allow-root=/home2/cvsroot/project1 --allow-root=/home2/cvsroot/project2 pserver log_on_failure += USERID
}

注：由于xinetd的server_args长度限制,当你想运行很多的单个仓库的时候,可以这么做：

#> vi cvspserver

service cvspserver
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /cvsroot/cvs.run
log_on_failure += USERID
}

编写cvs.run脚本

#> vi /cvsroot/cvs.run

#!/bin/bash
/usr/bin/cvs -f
--allow-root=/cvsroot/project1
--allow-root=/cvsroot/project2
pserver

#>chmod +x /cvsroot/cvs.run

10。加入cvs服务：

#>vi /etc/services

cvspserver 2401/tcp #pserver cvs service
cvspserver 2401/udp #pserver cvs service
11。启动cvs服务：

#> /etc/init.d/xinetd restart

12。检查cvspserver服务是否已经启动：

#> netstat -l |grep cvspserver
应该有如下结果：

tcp 0 0 *:cvspserver *:* LISTEN

二。CVS服务的用户管理：

上面我们已经建立了project1和project2两个CVS仓库，下面我们分别给两个仓库建立cvs用户。

13。创建可以登陆cvs服务器的用户名和密码：

#> su cvsroot
#> vi /cvsroot/project1/CVSROOT/passwd

trotter:*****:cvsroot
mimi:*****:cvsroot

#>vi /cvsroot/project2/CVSROOT/passwd

trotter:*****:cvsroot
gary:*****:cvsroot

这两个文件的意思是有trotter，mimi，gary三个cvs用户，mimi拥有project1的使用权限，gary拥有project2的使用权限，trotter拥有project1和project2的使用权限。登陆后的权限是cvsroot权限。
注意：这里的cvs用户和系统用户是不同的。

14。*****为密码，由以下文件生成：

#> vi /cvsroot/passwd.pl

#!/usr/bin/perl
srand (time());
my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
my $plaintext = shift;
my $crypttext = crypt ($plaintext, $salt);
print "${crypttext}
";

#>chmod a+x /cvsroot/passwd.pl

15。如果你想生成一个密码是“123456”，则：

#> /cvsroot/passwd.pl “123456”

回车即可得到加密密码,用其替换passwd文件中的*****

16。Ok，cvs现在已经全部安装完成了，如果你想让一个用户拥有project1的权限，你就在 /cvsroot/project1/CVSROOT/passwd中给他加入一个用户；如果你想让一个用户同时具有project1和project2 的权限，你就给/cvsroot/project1/CVSROOT/passwd和/cvsroot/project2/CVSROOT/passwd 里给他加一个用户名和密码相同的用户即可。最后，我们试用一下：

#> cvs -d :pserver:trotter@192.168.1.200:/cvsroot/project1 login

敲入命令回车后提示输入trotter的密码,你按照自己设置的密码输入,如果没有什么错误信息出现就是成功了(我的机器IP地址是192.168.1.200)




***CVS服务器建立和权限配置



建立一个源代码库主要有以下几步：

（1）初始化cvs服务器环境。
#cvs -d/usr/local/source init
之后进入/usr/local/source，可以看到有一个目录CVSROOT, 下面是初始化后的CVS服务器配置文件。暂且保持不动。

（2）把cvs服务放到xinetd系统服务中。
首先在/etc/xinetd.d目录下生成任务配置文件cvspserver，文件名称可以随便用。

其中内容大致如下：

service cvspserver
{
flags = REUSE
socket_type = stream
wait = no
user = root
protocol = tcp
server = /usr/bin/cvs
server_args = -f --allow-root=/usr/local/source pserver
disable = no
}



其中server_args一个参数指定了源代码库路径，一个指定了服务器使用密码认证方式。
第二，要确认/etc/services文件中，有cvspserver关键词，并分配了端口，如：cvspserver 2401/tcp。
第三，重新启动xinetd服务，cvs服务就可以用了。

（3）测试。假定cvs服务器在192.168.0.205上，系统上有一个用户cvs。登陆另一台linxu机器，执行下列命令可以完成测试：
$export CVSROOT=:pserver:cvs@192.168.0.205:2401/usr/local/source
$cvs login
输入密码，没有出错提示表示登陆成功。

如果想在一个linux系统上建多个源代码库，分别提供cvs服务。重复上面步骤就可以了。

第一步时候要注意使用一个不同路径。
第二步放到xinetd系统服务中稍微麻烦点。/etc/xinetd.d目录下要生成一个新的任务配置文件，例如cvspserver1，文件中service名称一定要区分第一个，例如service cvspserver1，server_args做相应变动。还要在/etc/services文件中，加入新的服务端口号，例如： cvspserver1 2402/tcp。重新启动xinetd服务.

第三步测试时候，可以这样设定：
$export CVSROOT=:pserver:cvs@192.168.0.205:2402/usr/local/source1
......

2007-06-08

01. 为什么要在一个团队中开展软件测试工作？
因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。
02. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试
03. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同04. 的测试类型的区别与联系（如功能测试、性能测试……）
测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试
05.  请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？
　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
      单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
       系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
06. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）
07. 您认为做好测试计划工作的关键是什么？
1. 明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2．坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4. 分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
08. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1．等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2．边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3．错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4．因果图方法
　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
08．您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
09. 请以您以往的实际工作为例，10. 详细的描述一次测试用例设计的完整的过程。
就说最近的这次网站功能的测试吧
首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
第四步：执行测试
11. 您以往是否曾经从事过性能测试工作？如果有，12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。
性能测试类型包括负载测试，强度测试，容量测试等
      负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
      强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。
      容量测试：确定系统可处理同时在线的最大用户数  
在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），
Web服务器指标指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
13. 您在从事性能测试工作时，14. 是否使用过一些测试工具？如果有，15. 请试述该工具的工作原理，16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
17. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
18. 在您以往的工作中，19. 一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
20. 您以往所从事的软件测试工作中，21. 是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，22. 请结合该工具描述软件缺陷（Bug）跟踪管理的流程。
23. 您认为在测试人员同24. 开发人员的沟通过程中，25. 如何提高沟通的效率和改善沟通的效果？维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么？
27. 在您以往的测试工作中，28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么？您是如何来对待这些事情的？
31. 在即将完成这次笔试前，32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）
33.     你对测试最大的兴趣在哪里？为什么？
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。
我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。
34. 你的测试职业发展是什么？
测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。
35. 你自认为测试的优势在哪里？
优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。
36. 你以前工作时的测试流程是什么？
公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。
37. 当开发人员说不38. 是BUG时，39. 你如何应付？
开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
23．你为什么想离开目前的职务？
因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。
　　24：你对我们公司了解有多少？
　　25：你找工作时，最重要的考虑因素为何？
工作的性质和内容是否能让我发挥所长，并不断成长。
26：为什么我们应该录取你？
您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。
　　27：请谈谈你个人的最大特色。
我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。
28.白箱测试和黑箱测试是什么?什么是回归测试?
    29。单元测试、集成测试、系统测试的侧重点是什么？
    30。设计用例的方法、依据有那些？
    31。一个测试工程师应具备那些素质和技能？
    32.集成测试通常都有那些策略？
    33.你用过的测试工具的主要功能、性能及其他？
    34.一个缺陷测试报告的组成
    35.基于WEB信息管理系统测试时应考虑的因素有哪些？
36.软件测试项目从什么时候开始，？为什么？
     37.需求测试注意事项有哪些？
     38.简述一下缺陷的生命周期
     39.测试分析测试用例注意（事项）？
你在你所在的公司是怎么开展测试工作的？是如何组织的？
你认为理想的测试流程是什么样子？
你是怎样工作的？
软件测试活动的生命周期是什么？
请画出软件测试活动的流程图？
针对缺陷采取怎样管理措施？
什么是测试评估？测试评估的范围是什么？
如果能够执行完美的黑盒测试，还需要进行白盒测试吗？为什么？
测试结束的标准是什么？
软件验收测试除了alpha,beta测试以外,还有哪一种?
做测试多久了？
以前做过哪些项目？
你们以前测试的流程是怎样的？
<答：测试计划－测试用例设计－测试执行－测试分析报告>
用过哪些测试工具？
为什么选择测试这行？
<答：它是一个新兴的行业，有发展潜力，而且很锻炼人，需要掌握更多的技能，比做开发要更难>
为什么值得他们公司雇用？
如果我雇用你，你能给部门带来什么贡献？
如何从工作中看出你是个自动自觉的人
你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
通常你对于别人批评你会有什么样的反应
如果明知这样做不对，你还会依主管的指过去做吗
如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
你觉得什么样的人最难相处
为什么值得他们公司雇用？
      帮助公司提高软件质量和测试部门的技术水平
如果我雇用你，你能给部门带来什么贡献？
      分享我的测试经验和测试技能，提高测试部门技术水平
如何从工作中看出你是个自动自觉的人
     自动自觉范围太广
      1. 工作成果
      2. 工作质量 
你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
      在有足够的资源和合理的工作量的情况下，完全可以按时完成，并能比一般人做的更好
通常你对于别人批评你会有什么样的反应
  有错即改，无措勉之
如果明知这样做不对，你还会依主管的指过去做吗
     在公司内部下级是否有申诉渠道？
如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
    为什么抱怨？是怎么样的问题？
     如果是客服问题，提交客服部门解决
    如果是质量问题，分析原因，下一版本改进
你觉得什么样的人最难相处
     自以为是的人
什么叫单元测试？
请就软件测试人员应该具备什么样的基本素质说说你的看法。
请就如何在开发中进行软件质量控制说说你的看法
 简述软件测试的意义，以及软件测试的分类
1、功能测试，性能测试，界面测试，安全测试（可以简单点，比如只涉及到COOKIES里的内容），压力测试（商业性质的网站） 等等，B/S软件也要根据其具体功能采用不同的测试策略。
2、态度、责任心、自信、敏锐的观察力、良好的发散思维
3、先设计后开发模式，加强单元测试，加强代码走查，有一套完整的白盒测试方法。关键是加强开发人员的质量意识，增进程序员向工程师水平发展。
4、意义嘛，就自己想吧。软件测试的分类，这个很多人都按各种方法去分。无明确答案给你。
对测试的理解——基本的测试知识，对测试是否认可？ 75。
   3、谈一谈过去自己的工作——了解经历、提供进一步提问的素材，表达能力  
测试技能
测试设计的方法并举例说明——测试技术的使用
测试工具——熟悉程度，能否与当前工作匹配？
如何做计划？如何跟踪计划？——日常工作能力
如果开发人员提供的版本不满足测试的条件，如何做？——与开发人员协作的能力
熟悉unix系统、oracle数据库吗？——是否具备系统知识
做过开发吗？写过哪些代码？——开发技能
阅读英语文章，给出理解说明？——部分英语能力
文档的意义——是否善于思考？（最简单的概念，不同层次的理解）
假如进入我们公司，对我们哪些方面会有帮助？——讲讲自己的特长
随便找一件物品，让其测试——测试的实际操作能力
软件测试的方法有？
软件测试的过程？
有一个新的软件，假如你是测试工程师，该如何做？
软件测试分哪两种方法？分别适合什么情况？
2。一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
3。软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
4。测试用例通常包括那些内容？着重阐述编制测试用例的具体做法
5。在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试？他们存在什么样的区别与联系？
6。在测试winform的C/S结构软件时，发现这个软件的运行速度很慢，您会认为是什么原因？您会采取哪些方法去检查这个原因？
7。描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程
你在五年内的个人目标和职业目标分别是什么？
　　分析这个问题是用来了解你的计划能力的，通过这个问题，面试人同时还可以知道你的目标是否符合企业对你的安排。
　　错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁，我认为做太多的个人计划是荒谬可笑的，不是吗？
　　评论这种回答属于令人反感的一类。首先，当有人想了解你的目标时，"将来的某个时候"这种通俗说法并不奏效。其次，认为企业很脆弱，领导者更换频繁，这种说法毫无疑问会令人反感，而且也是不合理的。最后，认为做计划可笑，看不起这个问题，而且反问面试人，这些都注定了这样的求职者最终会失败。
　　正确回答从现在起的五年之内，我希望能够在一个很好的职位上待几年，而且最好有一次晋升，然后就期待着下一步。不管是向上提升，还是在企业内横向调动，对我个人来说，我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。
　　评论这个问题没有回答得过分具体（那样可能会产生漏洞），而且它表明你有雄心，并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望，表明你是一个有灵活性的人。
　问题23　你怎样做出自己的职业选择？
　　分析 面试人提出这个问题是为了了解求职者的动机，看看他（她）应聘这份工作是否有什么历史渊源，是否有职业规划，是不是仅仅在漫无目的地申请很多工作。
　　错误回答 我一直都想在企业界工作。自孩提时代起，我就梦想自己至少也要成为大企业的副总裁。
　　评论 除了难以令人相信之外，这种回答还存在一个问题：它表明求职者会对副总裁以下的职位不感兴趣。
　　正确回答 在上大学四年级前的那个夏天，我决定集中精力在某一领域谋求发展。尽管我是学商业的，但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标，想清楚了自己擅长做的事情以及想从工作中得到的东西，最后我得出了一个坚定的结论，那就是这个行业是最适合我的。
　　评论 这种回答表明，求职者认真地做过一些计划，缩小了自己的关注点，而且也认准了前进的方向。这种回答还表明，求职者理解个人职业规划的重要性，并且有能力做出认真的个人决策。
1. 你都用什么测试方法
2.怎么编写案例
3.怎么才能够全面的测试到每一个点
1. 你都用什么测试方法
针对不同的产品或者系统或者模块，有不同的测试方法。总体而言有白盒测试和黑盒测试。
2.怎么编写案例
案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
3.怎么才能够全面的测试到每一个点
测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等多个角度考虑从而定义全部的测试点。
1、谈谈软件测试技术，以及如何提高
2、谈谈软件测试职业发展，以及个人的打算
3、谈谈软件测试在企业的地位，也可以结合软件生命周期来谈
有可能清晰的思路比确切的答案更重要
在这里，主要说下笔试和面试的问题，希望大家共同参考。
    1，一般公司里实际的软件测试流程是什么样的？你们公司又是怎样的？
    2，软件工程师要具有那些素质？
    3，你会哪些测试工具？怎么操作？
    4，你能不能说下你的3到5年的职业计划（规划）
    5，你觉得你来应聘有那些优势？
其余的还好说，但就第4个问题，我感到不好说哦！希望大家给个意见
第一关：首先要自我介绍，自己的性格怎么样，目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看？还有对于软件测试有什么自己的想法。为什么会想到要做这行（因为我的简历上的工作经历没有关于测试方面的）。哦，还有期望薪资。
第二关：认为软件测试人员所要具备的基本素质，如果遇到问题会怎样处理，如果得不到研发人员的配合（就是研发说这个不是问题）你又会怎么处理？然后就是一些基本概念，比如软件测试的流程有哪些？如果我上任了，首先会怎么开始自己的工作计划。
（前两关通过了后面这个就好过多了）
第三关：像我介绍了一下公司的情况，告诉我主要针对什么内容的测试，会不会使用数据库。告诉我大概要做哪些内容，详细的可以上岗以后慢慢熟悉。
大概就这么多了，这对没有经过这一关的不知道有没有帮助，仅供参考吧
我觉得就像李波说的，关键是要给对方留下好印象:)
面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问，这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会：
你可以问：
1.        贵公司近期和远期的发展目标是什么？
2.        贵公司的主要竞争对手有哪些？
3.        贵公司有多少开发人员有多少测试人员？
4.        贵公司又进一步扩充测试人员的计划吗?
5.        如果我有幸能进入贵公司的话，我有怎么样的发展？
6.        测试人员的沟通能力很重要，贵公司有规范的沟通渠道吗？
7.        请介绍一下贵公司的福利情况。
8.        请问我什么时候能知道结果？

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

　　1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

　　2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

　　3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。

　　4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

　　5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

　　6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

　　7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

　　8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

　　9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

　　10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

　　11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

　　12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

　　13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

　　14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

　　15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

　　17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

　　18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

　　19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

　　20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。

软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：

•  软件未达到客户需求的功能和性能；

•  软件超出客户需求的范围；

•  软件出现客户需求不能容忍的错误；

•  软件的使用未能符合客户的习惯和工作环境。

考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

•  测试是不完全的（测试不完全）

很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

•  测试具有免疫性（软件缺陷免疫性）

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

•  测试是 “ 泛型概念 ” （全程测试）

我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。

另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。

•  80-20 原则

80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

•  为效益而测试

为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。

•  缺陷的必然性

软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

•  软件测试必须有预期结果

没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

•  软件测试的意义 - 事后分析

软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。

结论：

软件测试是一个需要 “ 自觉 ” 的过程，作为一个测试人员，遇事沉着，把持尺度，从根本上应对软件测试有着正确的认识，希望本文对读者对软件测试的认识有所帮助。