1. 响应时间

我把“响应时间”的概念确定为“对请求作出响应所需要的时间”，把响应时间作`为用户视角的软件性能的主要体现。响应时间划分为“呈现时间”和“系统响应时间”两个部分。

其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间、而“响应时间”指J2EE应用服务器从请求发出开始到客户端接受到数据所消耗的时间。性能测试一般不关注“呈现时间”，因为呈现时间很大程度上取决于客户端的表现。在这里我们没有使用很多性能测试定义中的概念——“系统响应时间”定义为“应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间”，没有使用这种标准的原因是，可以使用一些编程技巧在数据尚未完全接收完成时进行呈现来减少用户感受到的响应时间，对于HNDLZCGLXT的这个项目中，我们针对C/S系统采用前者标准，对于B/S我们依然采用后一种标准。

2. 并发用户数

我把“并发用户数”与“同时在线数”进行区别对待，我的“并发用户数”的标准是：并发用户数取决于测试对象的目标业务场景，因此，在确定这个“并发用户数” 前，必须（必要）先对用户的业务进行分解、分析出典型的业务场景（也就是用户最常使用、最关注的业务操作），然后基于场景采用某些方法（有多种计算并发用户数的数学模型与公式）获得“并发用户数”。

这样做的原因是：假设一个应用系统、最高峰有500人同时在线、但这500人却不是并发用户数、因为假设在一个时间点上、有50%的人在填写复杂的表格（填写表格动作对服务器没有任何负担、只有在“提交”动作的时候才会对服务器系统构成压力）、有40%的人在不停的从一个页面跳转到另外一个页面（不停发出请求与回应、产生服务器压力）、还有10%的人挂在线上，没有任何操作在发呆：）（没有对服务器构成压力的动作）。因此只有那40%的人真正对服务器产生了压力，从这里例子可以看出、并发用户数关心的是不但是业务并发用户数、还取决于业务逻辑、业务场景。因此我们需要本文第六部分性能测试文档4、5、6。

3. 吞吐量

我把吞吐量定义为“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力，对于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。我们在以下方面利用这个指标：

（1） 用来协助设计性能测试场景，衡量性能测试是否达到了预计的设计目标、比如J2EE应用系统的连接池、数据库事务发生频率、事务发生次数。

（2） 用来协助分析性能瓶颈、参照本文第二部分总的RBI方法。

4. 性能计数器

性能计数器式描述服务器或操作系统性能的一些数据指标、例如对WINDOWS来说使用内存数、CPU使用率、进程时间等都是常见的计数器。

对于性能计数器这个指标来说、需要考虑到的不但有硬件计数器、web服务器计数器、Weblogic服务器计数器、Servlet性能计数器、EJB2的性能计数器、JSF性能计数器、JMS性能计数器。找到这些指标是使用性能计数器的第一步、关键是找到性能瓶颈、确定系统阀值、提供优化建议才是性能计数器使用的关键。性能计数器复杂而繁多、与代码上下文环境、系统配置情况、系统架构、开发方式、使用到的规范实现、工具、类库版本都有紧密的联系、在此不作赘述。

5. 思考时间

我把思考时间确定为“休眠时间”。从业务系统的角度来说，这个时间指的是用户在惊醒操作时、每个请求之间的时间间隔、从自动化测试的角度来说、要真实的测试模拟用户操作、就必须在测试脚本中让各个操作之间等待一段时间、体现在脚本上就是在操作之间放置一个Think的函数，体现为脚本中两个请求语句之间的间隔时间、不同的测试工具提供了不同的函数或方法来实现思考时间、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。
性能测试方法论

1. SEI负载测试计划过程

目标：产生一个清晰、好理解、可验证的负载测试计划

内容：关注6个区域：目标、用户、用例、生产环境、测试环境、测试场景

工具：IBM、HP、OpenSource工具都支持。需有文档配合

2. RBI方法

目标：快速识别性能瓶颈

内容：重点测试“吞吐量”指标，因为RBI认定80%的系统性能瓶颈由吞吐量造成。

按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能

工具：IBM、HP、OpenSource工具都支持。需使用分析模块、根据Weblogic、Oracle

区别有专门的工具实现RBI。

3. 性能下降曲线分析法

目标：性能随着用户数的增加而出现下降趋势的曲线分析、查看性能下降的环境点与上

下文。确定性能阀值。

内容：通过单用户区域、性能平坦区域、压力区域、性能拐点进行监控和分析。

工具：IBM、HP、OpenSource工具都支持。IBM报表功能更强。

4. HP（LoadRuner）性能分析法

特点：侧重于该厂商的性能分析方法、主要体现在需求收集、VU脚本。

缺点：没有对测试计划阶段、测试设计阶段的具体行为、方法、目的进行描述。方法局

限于LoadRuner产品的特性上。不能通用。

5. IBM（Rational UP）软件测试方法

特点：软件产品生命周期RUP的实现、侧重于迭代测试、宽广的方法论。可适合任意

测试环境及方法、工具。

缺点：需要根据测试环境进行剪裁、难以掌握、但掌握后非常成熟、高品质。

工具：涉及到IBM Rational 测试环境的所有软件、功能强大。

6. PTGM性能测试模型

内容：一个非常适合行业用户（电力、金融、政务、制造）的性能测试过程模型。规范

化的测试模型、每个环节都做到迭代测试、每一个过程的工作产品明显可察、测

试流程、测试上下文方面很优秀。包括以下环节：前期准备、工具引入、测试计

划、测试设计与开发、测试执行与管理、测试分析。

工具：可以使用任意商业工具全新部署测试流程、不限于任何厂商工具的局限、也可以

使用部分工具即可完成整个流程、或结合自己需要基于OpenSource工具进行定

制。个人倾向使用多个产品的整合、综合使用、扬长避短。

性能测试方法

1. 性能测试

性能测试方法通过模拟生产运行的业务压力量和使用场景组合测试性能是否能够满足需要。具备三个特点：

（1） 这种方法的目的是验证系统是否具有系统宣称具有的能力。

（2） 这种方法需要事先了解被测试系统典型场景、并确定性能目标。

（3） 这种方法要求在已确定的环境下运行

使用IBM Rational Performance Tester、HP Mercury LoadRuner、OpenSTA、Apache ab、Jmeter、QALoad 、TagUnit、Java Test Runner。

2. 负载测试

负载测试用来测定系统饱和状态、确定阀值。其特点有：

（1） 这种方法的目的是找到系统处理能力的极限；通过“检测、加压、阀值”手段找到如“响应时间不超过10秒”，“服务器平均CPU利用率低于65%”等指标。

（2） 这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景、另外HP Mercury LoadRuner在使用该方法进行“加压”的时候必须选择典型场景。

（3） 这种性能测试方法一般用来了解系统的性能容量，或者是配合性能调优的时候来使用。特别是该项目的Weblogic Server和Oracle数据库的性能调优。

3. 压力测试

压力测试方法测试目标系统在一定饱和状态下，例如CPU、内存等在饱和状态下、系统能够处理的session的能力，以及系统是否会出现错误。该方法需要在系统cache调优与pool优化方面着手。该方法具备以下特点：

（1） 该方法的目的是检查系统处于压力情况下的，应用的表现。如增加VU数量、节点数量、并发用户数量等使应用系统的资源使用保持一定的水平，这种方法的主要目的是检验此时的应用表现，重点在于有无错误信息产生，系统对应用的响应时间等。

（2） 该方法通过模拟负载在实现压力。这种模拟需要考虑的层面很多、首先、模拟必须是有效的，我的经验是需要结合业务系统和软件架构来定制模拟指标、我测试过一些国内生产的压力测试工具、他们使用通用的指标来考量、造成很多信息反馈有很大的水分。需要考虑的层面如：Oracle I/O、JVM GC、Conn Pool等。

（3） 该方法还可以测试系统的稳定性。这里的技巧在于“什么样的平台定义一个多长的压力测试时间让其稳定运行才是科学的？”

4. 配置测试

配置测试方式是指在测试前、测试中、测试后三个时间段通过对被测系统的软件/硬件环境的调整，了解各个不同环境对系统性能影响的程度，从而找到系统各个资源的最优分配原则。它具备以下特点：

（1） 该方法的目的是了解各个不同的因素对系统性能影响的程度、从而判断出最值得进行的调优操作。该方法不同于与“功能测试”中涉及到的“配置测试”。

（2） 该方法存在很大的灵活性、可以在测试环节的各个时间进行、但是什么时候开始、什么时候暂停、什么时候结束才是运用这个方法的关键。同时也是HNDLZCGLXT考量性能测试服务供应商的关键。

5. 并发测试

该方法通过模拟用户的并发访问，测试多用户环境并发访问同一个应用、同一个模块或者数据记录时系统是否存在死锁或者其他性能问题。该方法特点是：

（1） 可以发现应用系统的全局性性能问题。

（2） 该方法可以在开发工作的各个环节使用可以使用多个工具的配合。如：Compuware公司的DevPartner工具、EJ-Technologie公司的J Profile工具，QUEST公司的J Probe工具等。

（3） 并发测试一般关注的问题是：

问 题 类 别

问 题 描 述

内存问题

是否有内存泄露（COM+，JAVA）

是否有太多的临时对象（JAVA）

是否有太多不合理声明的超过设计生命周期的对象

数据库问题

是否有数据库死锁

是否经常出现长事务

线程/进程问题

是否出现线程/进程同步失败

其他问题

是否出现资源争用导致的死锁

是否没有正确处理异常（如超时）导致的系统死锁

6. 可靠性测试

这里说的“可靠性测试”并不等同于“获得软件的可靠性”，软件的可靠性是一个很大的命题，这里指的可靠性测试是通过给系统加载一定的业务压力（例如：资源在80%~90%的使用率），让应用系统运行一段时间、测试系统是否稳定运行。这里有三点需要注意：

（1） 在使用该测试前需要目的系统的资源使用率已经达到70%~90%。即在这样的苛刻环境下运行该应用系统。

（2） 应用系统运行起来后，加载业务压力使应用系统资源达到90%。比如：该J2EE系统中设置的JDBC数据库连接池定义为30，那么加载业务压力使连接达到27。

（3） 应用系统运行起来后结合业务情况来设定一个运行时间。比如：电力资产系统要求MTBF（平均无故障时间）达到10000小时、那么我们可以认定该系统的运行时间至少需要达到三年重新启动一次。超过这个数字我们就可以认为“不可靠”。一般情况下对于这个要求、我们让J2EE系统在资源使用率90%~100%状态连续稳定的运行3天左右没有错误就可以认定该MTBF指标已经达到。

7. 失效恢复测试

该方法是针对有HACMP等冗余备份和Edge Server for LB等负载均衡的J2EE系统设计的。该方法考量系统失效恢复的时间、用户受到多大程度、多大范围的影响，并将其量化。该方法有以下特点：

（1） 一般的关键业务都会采用双机热备或负载均衡方式来实现。

（2） 该方法回答两个问题：当问题发生的时候“能支持多少用户访问”，“有多少功能不能使用”

（3） 需要说明的是，对于HNDLZCGLXT的这个项目来说，负载均衡需要仔细考虑其实现方式，这影响到性能的调优。可以考虑使用F5等硬件技术方式、也可以考虑使用 IBM WebSphere Edge Server等商业版本的软件技术方式。否则单纯对EJB 容器Weblgoic Server作集群没有意义。
性能测试分析方法

该部分着重于PTGM方法论

1. 能力验证

能力验证一般采用这样的描述：“该系统是否能在A条件下具备B能力？”。这里强调以下内容：

（1） 充分准备以下内容：硬件设备、软件环境、网络条件、基础数据

（2） 充分准备测试场景、典型的场景包括操作序列、并发用户数量条件、用例。

该部分包括使用到上述测试方法：性能测试方法、可靠性测试、压力测试、失效恢复测试

2. 规划性能

该分析方法关心的是“应该如何才能使系统具有我们要求的性能能力”，“应该如何调整系统配置，使系统能够满足增长的用户数的需要”等问题。这个部分常常使用到的测试方法是：负载测试、配置测试、压力测试。

3. 性能调优

一个标准的性能调优过程是：

（1） 确定基准环境、基准负载和基准性能指标。

（2） 调整系统运行环境和实现方法，执行测试。

（3） 记录测试结果、进行分析

在J2EE性能测试中有很多常见的错误，比如：对于某些建立在J2EE/EJB技术上的应用，在服务启动的时候，没有注意到测试之前首先进行一段时间的预热。这是因为JAVA语言的hot-spot技术特性决定的，这种技术允许weblogic第一次运行应用的时候将字节码编译为本地代码并执行，这样在后续的执行过程中执行过程会大大加快，但第一次由于存在一个编译过程会比较慢。如果使用这个时间来作为基准那么就容易得出错误的结论。

我对第2个过程比较擅长、具体下来包括硬件环境的调优、Weblogic调优、Oracle调优。这个过程中也是使用工具最多的测试环节。

4. 发现缺陷

这个环节中是交付给用户的主要工作成果。需要多和开发人员作沟通、多次迭代发现问题、根据用户的需求定义与缺陷的涉及范围、制定一个解决缺陷的优先级。由于软件永远有BUG这一真理，所以发现缺陷不是一次就能结束的工作。比较适合作为服务外包。持续进行。

　　1、总计架构测试

　　1）瘦客户端，业务逻辑规则多数在服务器端执行。如新闻站点、门户网站、信息发布网站等。

　　2）胖客户端，安全性要求较高、交互操作频繁、业务逻辑复杂。银行系统、网络游戏、网上办公系统等。

　　2、Web架构组成部分是否满足需求

　　成本、功能、安全性要求、容量要求、传输实时性。

　　3、服务器配置分布是否满足要求

　　Web服务器、应用服务器、数据库服务器可以分布在不同物理机器上也可以分布相同的物理机器上，一般优先考虑独立数据库服务器，Web服务器、应用服务器可以在相同的机器上。

　　4、客户端设计测试

　　1）功能设置测试：信息服务、办公自动化、Internet支持；

　　2）信息组织结构测试：线性结构、分层结构、非线性结构；

　　3）页面设计测试：

　　a) 页面一致性测试

　　b) 用户界面友好性及导航直观性测试；、

　　c) 是否适合多种浏览器；

　　d) 页文件的命名；

　　e) 页面布局技术。

　　5、服务器端设计测试

　　1）容量规划测试：点击率、延迟和流量、服务器资源；

　　2）系统安全测试：

　　a) 常识性安全策略，取消不必要的协议、控制写权限、取消服务器目录浏览属性、记录日志等；

　　b) 使用加密技术；

　　c) 构造防火墙，网络级、应用级、电路级；

　　d) 构建网络防毒体系。

　　3）数据库设计测试。

　　6、Web开发测试

　　1）源代码分析，主要是使用检查工具来完成；

　　2）链接测试，主要借助工具来完成；

　　3）框架测试：

　　a) 自动调整窗口大小；

　　b) 是否提供滚动条；

　　c) 打开新页面是否正常。

　　4）表格测试，随窗体变化自动调整大小；

　　5）图形测试：

　　a) 颜色饱和度及对比度；

　　b) 链接标识；

　　c) 图形显示是否正确。

　　7、与一般应用软件相比，Web测试有以下区别：

　　第一、Web测试的侧重点是性能、安全、易用性、兼容

　　第二、测试工具有所不同，如链接测试、表单测试、界面测试

　　8、功能测试

　　1）客户端的选择，优先测试流行的客户客户端；

　　2）客户端浏览器的配置

　　3）客户端的显示设置

　　4）内容测试

　　9、链接测试

　　1）该链接将用户带到它所说明的地方

　　2）被链接的页面是存在的

　　3）保证没有孤立页面

　　工具有WEBCHECK、LINKBOT、TESTPARTNER、XENU等

 　软件开发过程中，经常遇到这个问题，所以转载下：　
    需求变更对软件开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。
　　
　　（1）明确合同约束，建立需求基线
　　需求变更给软件开发带来的影响有目共睹，所以在与客户签订合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。
　　
　　明确和树立需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（客户参与评审），建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要力保不频繁变更。例如，对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。
　　
　　（2）建立变更审批流程

　　在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低开发效率，浪费时间。正是这种观念才使需求变更变得不可控，最终导致项目的失败。因此，小的需求变更也要经过正规的需求管理流程，否则会积少成多，积重难返。
　　
　　明确需求变更审批环节、审批人员、审批事项、审批流程。这么做的目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”，一律是无效变更不予受理。
　　
　　（3）分级管理变更，定时批量处理

　　软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到客户的成本投入收益。因此，用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。
　　
　　当遇到客户提出需求，不及时处理可能会使项目不能验收通过时，也不能一味拒绝不予开发。因此，当客户坚持变更新需求时，可以建议客户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。例如，每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目进度。针对会议结果可向客户正式提交一份需求变更计划，注明变更引起的时间、成本、工期代价和增加工作量等。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱变更不做，保大局弃小变。
　　
　　（4）安排专职人员负责变更管理

　　有时开发任务较重，开发人员容易陷入开发工作中而忽略了与客户的随时沟通。因此，需要安排一名专职的需求变更联络人员，负责与客户及时交流，跟踪和汇报需求变更完成进度和情况。同时，可以成立项目变更控制小组，负责裁定接受哪些变更，小组由项目所涉及的多方人员共同组成，应该包括客户方和开发方的决策人员在内。
　　
　　（5）确认客户是否接受变更的代价

　　要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说，如果客户认为该变更是必须的（不是其上级领导拍脑袋提出的）就会接受这些后果。通过与客户协商，这样开发团队即使没有回报，也不会招致公司和客户双方的埋怨。
　　
　　如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更。
 

　　1、必须说清楚测试报告的操作系统环境：

　　比如说XX软件运行的操作系统是什么？是Windows 98、Windows2000、WindowsXP, 还是Linux操作系统等等。很多时候，大多数的软件只能够在某个系统上存在缺陷，而在其它版本的系统上可能不存在缺陷。

　　2、测试报告结果只对发布的版本和配置库的SVN号负责：

　　也许同行们都有这种尴尬，很多测试的时候，发现了Bug，并将Bug记录到Bug跟踪系统上，结果开发人员说，自己的机器上不存在这个Bug。要求测试人员重新验证Bug是否存在。一种可能是开发人员发现测试人员递交缺陷后，修改了该缺陷，还有一种情况是版本的发布不规范，开发人员忘了递交代码到配置库，结果就发布了。所以，测试报告只对特定的版本和环境负责。

　　3、指出测试的浏览器：

　　特别是Web类似的软件，不同的浏览器，测试出来的问题不一样。同样的一种浏览器，不同的版本，测试结果报告也有时候不一样，我们部门以前碰到过IE6.0和IE7.0同样的一个功能，页面显示不太一样的现象。故，Web类似软件的测试报告，最好是说明出现问题的浏览器。

　　4、测试结论和测试建议，对于一个有效的测试报告非常关键：

　　测试结论和测试建议要求简短和准确，甚至有时候决定该版本是否可以发布，特别是测试的负责人，对被测试软件的报告一定要仔细斟酌，小心为佳。

　　5、测试用例的执行情况：

　　针对软件测试报告的几种类型，如：单元测试、集成测试、功能测试、性能测试和压力测试分别编写测试报告。编写报告时，已经执行或未执行的的用例数目。用例通过的百分比，未执行的测试用例，必须说明不能执行的原因。对于测试阻塞的测试用例，必须加以说明，最好用粗体字表明，让人一看就比较清楚。

　　6、一般都要附上缺陷列表（Buglist）：

　　某个软件的测试版本，测试中共发现了多少问题，缺陷的严重等级和优先级如何，已经关闭和Fix掉的Bug有哪些？哪些问题是该版本遗留的问题？哪些是下一个版本解决的问题？哪些是重复打开的缺陷？有了Buglist，一看就一目了然，简单并且很清晰。

　　7、测试结果的图形和数据分析情况：

　　测试报告递交一定要分清递交对象，不同类型的人，递交不同版本的测试报告。如果是递交给研发部的人员，最好要附上缺陷隔离等相关方面的解释，方便开发人员迅速定位缺陷，解决问题。如果递交对象是客户，你就详细说明客户关心的功能和常用模块是否已经实现，是否存在问题即可。如果递交的对象是公司领导和客户领导，他们根本就没有很多时间来看你的文字，主要看看测试图表，最好用缺陷管理工具，如：TestDerector和QAcenter自动生成不同的图表，并且附带上各个功能模块的缺陷情况，就可以应付了，呵呵！！

　　8、测试报告也可以附带缺陷度量的相关分析：

　　如缺陷密度呀等等之类的，增加缺陷报告的技术含量.

包括关键字搜索.完全匹配.有效字符.无效字符等

1,空内容点击搜索，看其有没有LINK
2,输入过长查询数据，看其有没判断，报错
3,输入各种符号，特别是空格，看其能否正确判断
4,输入各种字符，譬如输入范围是0~9，A~Z的看输入中文是什么效果
5,输入正确数据，看其的查询后数据的完整性
6,注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方
7,在输入结束后直接按回车键,看系统处理如何,会否报错
8,反复输入相同的数据（5次以上）看是否报错
9,各国文字/字符的输入/粘贴能正确显示 退格键等操作显示正常 超过支持的最大长度有相应的提示 混合的多种语言也能正确显示
10,显示&接收；能进行下一步处理
11,其他的 包括能删除  能剪切等（我也不确定要不要包括 有点奇怪 显示语言是字符库支持的问题 而且如果是面向对象程序设计语言做的文本框 删除什么的功能也不用测

　　开发一个软件产品，会发布多个版本，伴随着测试用例（Test case）的不断维护, 使测试用例不断完善并与产品功能、特性(features)的变化保持一致，所以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品，多个版本常常共存，为客户提供服务，这时多个版本的测试用例也是并存的，所以在新建、修改、删除测试用例时要十分小心，并有相应的规则。

　　根据产品特性和test case一致性，分下面几种情况分别处理：

　　1. 产品特性没变，只是根据Late Discovery Bug 或 Remedy Ticket 来完善 test case，只有这时候可以修改Test case, 也就意味着当前修改的test case，对目前和以前的版本都有效。

　　2. 原有产品特性发生了变化，不是new feature, 而是enhanced features（功能增强）, 这时候原有的 test case 只对先前版本（如version 1.0、2.0) 有效，而对新的版本（如 version 3.0)无效，这时绝不能修改 test case ，只能增加新的 test case，这一点很重要。原有的 test case 依然对原有版本有效（如version 1.0、2.0)。

　　3. 原有功能取消了，这时只要在新版本上使之对应的test case置为inactive（无效）。

　　4. 完全新增加的特性，大家比较清楚，增加对应的、新的测试用例。

　　这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几、十几倍的增加，可以真正保证 test case  的完整性、有效性！

性能测试（并发负载压力）测试分析－简要篇

 
      在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。

分析原则：

• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

• 查找瓶颈时按以下顺序，由易到难。

    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

• 分段排除法 很有效

分析的信息来源：

•1 根据场景运行过程中的错误提示信息

•2 根据测试结果收集到的监控指标数据

一．错误提示分析

分析实例：

1 •Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection

•Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely

分析：

•A、应用服务死掉。

（小用户时：程序上的问题。程序上处理数据库的问题）

•B、应用服务没有死

（应用服务参数设置问题）

    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％

•C、数据库的连接

(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2 Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成

•A、应用服务参数设置太大导致服务器的瓶颈

•B、页面中图片太多

•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析

1．最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

    在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

    如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：

    • 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3．服务器资源监控指标：

内存：

1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate);

进程进入不活动状态;

交换区所有磁盘的活动次数可高;

可高的全局系统CPU利用率; 

内存不够出错(out of memory errors)

处理器：

1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 

合理使用的范围在60%至70%。

2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆: 

很慢的响应时间(slow response time) 

CPU空闲时间为零(zero percent idle CPU) 

过高的用户占用CPU时间(high percent user CPU) 

过高的系统占用CPU时间(high percent system CPU) 

长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：

1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :

过高的磁盘利用率(high disk utilization) 

太长的磁盘等待队列(large disk queue length) 

等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 

太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 

过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 

太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：

SQL Server数据库：

1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。

2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 

3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：

1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率： 

select(sum(pins-reloads))/sum(pins) from v$librarycache; 

select(sum(gets-getmisses))/sum(gets) from v$rowcache; 

自由内存： select * from v$sgastat where name=’free memory’; 

2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：

select name,value from v$sysstat where name in (’db block gets’,

‘consistent gets’,'physical reads’) ;

Hit Ratio = 1-(physical reads / ( db block gets consistent gets))

3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况 ：

select name,value from v$sysstat where name = ‘redo log space requests’ ;

4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

内存排序命中率 ：

select round((100*b.value)/decode((a.value b.value), 0, 1, (a.value b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’

注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

软件测试的艺术

软件测试：
一个过程或一系列过程，用来确定计算机代码完成了其应该完成的功能，不执行其不该有的操作。
软件应该是可预测的、稳定的。
第二章 软件测试的心理学和经济学
软件测试心理学：
测试是为了发现错误而执行程序的过程。
成功的”测试：测试某段程序时发现错误，且该错误可修复或者本次测试可以最终确定再无其他可查出的错误，则被称作“成功的”测试。
不成功的”测试：未能适当地对程序进行检查或未能找出错误的测试，被称为“不成功的”测试。
几种错误的观点：
软件测试就是证明软件不存在错误的过程。此为理想状况。
软件测试就是证明“软件做了其应该做的”过程。忽略的软件做了不该做的。
软件测试更适宜被视为试图发现程序中的错误的破坏性的过程。软件做了其应该做的，未做其不应该做的。
软件测试的经济学：
黑盒测试：称为数据驱动的测试或输入/输出驱动的测试。与程序的内部机制和结构完全无关。
重点：发现程序不按其规范正确运行的环境条件。
此方法若想发现所有的错误，判定标准：“穷举输入测试”。此不可能达到。有两方面含义：一是我们无法测试一个程序以确保它是无错的；二是要考虑软件测试的经济学问题。
白盒测试：逻辑驱动测试。允许检查程序的内部结构。
重点：将程序的每一条语句至少执行一次（穷举路径测试）。存在两个问题：
程序中不同逻辑路径的数量可能达到天文数字；
即使测试到程序中的所有路径，程序仍然可能存在着错误。此有三个原因：
1．不能保证程序符合其设计规范：如将升序排列错编成降序排列。
2．可能会因为缺少某些路径而存在的问题。
3．可能不会暴露数据敏感错误。
软件测试的原则：
1．测试用例中一个必须部分是对预期输出或结果进行定义；
 一个测试用例包括两个部分：
   对程序的输入数据的描述；
对程序在上述输入数据下的正确输出结果的精确描述。
 2．程序员应当避免测试自己编写的程序；
 3．编写软件的组织不应当测试自己编写的软件；
 4．应当彻底检查每一个测试的执行结果；
 5、测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未料到的输入情况；
 6．检查程序是否“未做其应该做的”和“做了其不应该做的”；
 7．应避免测试用例用后即弃，除非软件本身是一次性软件；
保留测试用例，当程序其他部件发生更动后重新执行，就是所谓的“回归测试”。在人机交互方式的测试下，尤其会忽略这一问题。
 8．计划测试工作时不应默许假定不会发现错误；
 9、程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比；
  测试总是倾向于聚集存在，故对容易存在错误的部分进行额外的测试。
 10．软件测试是一项极富创造性、极具智力挑战性的工作。
总结：三个重要的测试原则：
 软件测试是为发现错误而执行程序的过程。
 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。
 一个成功的测试用例能够发现某个尚未发现的错误。
第三章、代码检查、走查与评审
今天，并不是所有的软件测试人员都要阅读代码，但研读程序代码是测试工作的一部分。
“人工测试”：开始于代码编码之后，基于计算机的测试开始之前使用的方法。是查找错误方面非常有效。其原因：
 错误发现越早，改正成本越低；
 程序员改正基于计算机发现的错误所犯的失误，要比改正早期发现的问题所犯的失误要更多。代码检查与走查：
两种重要的人工测试方法。
他们的共同点：要求人们组成一个小组来阅读或直观检查特定的程序。“头脑风暴会”
优点：一旦发现错误，就能在代码中精确定位，降低调试成本。查出30％～70％的逻辑设计和编码错误。
缺点：往往只能发现一些“简单”的错误。
因此代码检查/走查与基于计算机的测试是互补关系。
代码检查：
  以组为单位阅读代码，它是一系列规程和错误检查技术的集合。重点：在规程、所要填写的表格。
  一个代码检查小组由四人组成：
一人发挥协调作用（称职的程序员）：相当于质量控制工程师。无需对程序的细节很清楚；为代码检查分发材料，安排进程；在代码检查中起主导作用；记录发现的所有错误；确保所有错误随后得到改正。
代码检查有两项工作：
 程序编码人员逐条语句讲述程序的逻辑结构。
 对者历来常见的编码错误列表分析程序。
代码检查的优点：
 发现错误；
 程序员会得到编程风格、算法选择及编程技术等方面的反馈信息。
 早期发现程序中最易出错部分的方法之一。
用于代码检查的错误列表：
  代码检查过程的重要部分：就是对照一份错误列表，来检查程序是否存在常见的错误。
1． 数据引用错误
是否引用的变量未赋值或未初始化？
所有的数组引用，是否每一个下标的值都有相应维规定的界限之内？
所有的数组引用，是否每一个下标的值都是整数？
对所有的通过指针或引用变量的引用，当前引用的内存单元是否分配？即“虚调用”。
如果一个内存区域具有不同属性的别名，当通过别名进行引用时，内存区域中的数据值是否具有正确的属性？
变量的类型或属性是否与编译器所预期的一致？
在使用的计算机上，当内存分配的单元小于内存可寻址的单元大小时，是否存在直接或间接的寻址错误？
当使用指针或引用变量时，被引用的内存的属性是否与编译器所预期的一致？
假如一个数据结构在多个过程或子程序中被引用，那么每个过程或子程序对该结构的定义是否都相同？
如果字符串有索引，当对数组进行索引操作或下标引用，字符串的边界取值是否有“仅差一个”（off-by-one）的错误？
对于面向对象的语言，是否所有的继承需求都在实现类中得到了满足？
2． 数据声明错误
是否所有的变量都进行了明确的声明？
如果变量所有的属性在声明中没有明确说明，那么默认的属性能否被正确理解？
如果变量在声明语句中被初始化，那么它的初始化是否正确？
是否每个变量都被赋予了正确的长度和数据类型？
变量的初始化是否与其存储空间的类型一致？
是否存在着相似名称的变量？
3． 运算错误
是否存在不一致的数据类型的变量间运算？
是否有混合模式的运算？
是否有相同数据类型，不同字长变量间的运算？
赋值语句的目标变量的数据类型是否小于右边表达式的数据类型或结果？
在表达式的运算中是否存在表达式向上或向下溢出的情况？
除法运算中的除数是否可能为0？
如果计算机表达变量的基本方式是基于二进制的，那么运算结果是否不精确？
在特定场合，变量的值是否超过了有意义的范围？
对于包含一个以上操作符的表达式，赋值顺序和操作符的优先顺序是否正确？
整数的运算是否有使用不当的情况，尤其是除法？如：2*i/2==i ？
4． 比较错误
是否有不同数据类型的变量之间的比较运算？
是否有混合模式的比较运算，或不同长度的变量间的比较运算？
比较运算符是否正确？
每个布尔表达式所叙述的内容是否都正确？
布尔运算符的操作数是否是布尔类型的？比较运算符和布尔运算符是否错误地混在一起了？
在二进制的计算机上，是否有用二进制表示的小数或浮点数的比较运算？
对于那些包含一个以上布尔运算的表达式，赋值顺序以及运算符的优先顺序是否正确？
编译器计算布尔表达式的方式是否会对程序产生影响？
5． 控制流程错误
如果程序包含多条分支路径，索引变量的值是否会大于可能的分支数量？
是否所有的循环最终都终止了？
程序、模块或子程序是否最终都终止了？
由于实际情况没有满足循环的入口条件，循环体是否有可能从未执行过？
如果循环同时由迭代变量和一个布尔条件所控制，如果循环越界了，后果会如何？
是否存在“仅差一个”的错误，如迭代数量恰恰多一次或少一次？
如果编程语言中有语句组或代码块的概念，是否每一组语句都有一个明确的while语句，并且do语句也与其相应的语句组对应？
是否存在不能穷尽的判断？
6． 接口错误
被调用模块接收到的形参数量是否等于调用模块发送的实参数量？另外，顺序是否正确？
实参的属性是否与相应形参的属性相匹配？
实参的量纲是否与对应形参的量纲相匹配？
此模块传递给彼模块的实参数量，是否等于彼模块期望的形参数量？
此模块传递给彼模块的实参的属性，是否与彼模块相应形参的属性相匹配？
此模块传递给彼模块的实参的量纲，是否与彼模块相应形参的量纲相匹配？
如果调用了内置函数，实参的数量、属性、顺序是否正确？
如果一个模块或类有多个入口点，是否引用了与当前入口点无关的形参？
是否有子程序改变了某个原本仅为输入值的形参？
如果存在全局变量，在所有引用它们的模块中，它们的定义和属性是否相同？
常数是否以实参形式传递过？
7． 输入/ 输出错误
如果对文件明确声明过，其属性是否正确？
打开文件的语句中各项属性的设置是否正确？
格式规范是否与I/O语句中的信息相吻合？
是否有足够的可用内存空间，来保留程序将读取的文件？
是否所有的文件在使用之前都打开了？
是否所有的文件在使用之后都关闭了？
是否判断文件结束的条件，并正确处理？
对I/O出错情况处理是否正确？
任何打印或显示的文本信息中是否存在拼写或语法错误？
8． 其他检查
如果编译器建立了一个标识符交叉引用列表，那么对该列表进行检查，查看是否有变量从未引用过，或仅被引用过一次？
如果编译器建立了一个属性列表，那么对每一个变量的属性进行检查，确保没有赋予过不希望的默认属性值？
如果程序编译通过了，但计算机提供了一个或多个“警告”或“提示”信息，应对此逐一进行认真检查。“警告”：编译器对程序某些操作的正确性有所怀疑。“提示”：可能会列出没有声明的变量，或者是不利于代码优化的用法。
程序或模块是否具有足够的鲁棒性？即：它是否对其输入的合法性进行了检查？
程序是否遗漏了某一功能？
代码走查：
  代码检查和代码走查采用的错误检查技术不同，操作规程也有所不同。
  代码走查参与者：一个极富经验的程序员、一个程序设计语言专家、一个程序员新手、最终将维护程序的人员、一个来自其他不同项目的人员、一个来自该软件编程小组的程序员。
桌面检查：
  桌面检查是人工查找错误的第三种过程。由单人进行的代码检查或代码走查：由一个人阅读程序，对照错误列表检查程序，对程序推演测试数据。
  效率相当低。
同行评分：
  这种人工评审方法与程序测试并无关系，但与代码阅读的思想有关。
总结：
  开发人员通常不会考虑的一种测试形式：人工测试。主要方法：
   利用错误列表进行代码走查；
   小组代码走查；
   桌面检查；
   同行评审。
第四章、测试用例的设计
软件测试最重要的因素是设计和生成有效的测试用例。
由于时间和成本的约束，软件测试的最关键问题是：在所有可能的测试用例中，哪个子集最有可能发现最多的错误？
 随机输入测试：效率最低。
 黑盒测试方法：等价类划分、边界值分析、因果图分析、错误猜测
 白盒测试方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。
实际工作中，推荐先使用黑盒测试方法，然后视情况需要使用白盒测试方法。
白盒测试：
  关注测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。
  逻辑覆盖测试：
   语句覆盖：有很大的不足，以至于它通常没有什么用处。
判定覆盖或分支覆盖：较强一些的逻辑覆盖准则。要求编写足够的测试用例，使得每一个判断都至少有一个为真或为假的输出结果。
判断覆盖通常可以满足语句覆盖。但有三种情况例外：
 程序中不存在判断。
 程序或子程序/方法有多重入口点。
 在ON单元里的语句。
条件覆盖：比判断覆盖更强的准则。要求编写足够的测试用例确保将一个判断中的每一条件的所有可能的结果至少执行一次。包括ON单元的每一个入口点都至少调用一次。条件覆盖会使判断中的各个条件都取到两个结果“真”和“假”。
判定/条件覆盖准则：要求设计出足够的测试用例，将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。
 缺点：由于有些特定的条件会屏蔽掉其他条件，常常并不能全部都执行到。
多重条件覆盖：要求编写足够的测试用例，将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。
显然，满足多重条件覆盖，就满足了判定覆盖或分支覆盖、条件覆盖、判定/条件覆盖准则。
而且，在存在循环的情况下，多重条件覆盖所需要的测试用例的数量通常会远远小于其路径的数量。
总之，对包含每个判断只存在一种条件的程序，最简单的测试准则就是设计出足够数量的测试用例：
1、 将每个判断的所有结果都至少执行一次；
2、 将所有的程序入口都至少调用一次；
而对于包含多重条件判断的程序，则要求设计足够的测试用例，将每个判断所有可能的条件结果组合，以及所有的入口点都至少执行一次。
等价划分
 精心挑选的测试用例应具备两个特性：
1、严格控制测试用例的增加，减少为达到“合理测试”的某些即定目标而必须设计的其他测试用例的数量。即：使用较少的测试用例，体现尽可能多的不同的输入情况。
2、它覆盖了大部分其他可能的测试用例。尽量将程序的输入范围进行划分，划分为有限数量的等价类。
 等价类划分方法设计测试用例有两个步骤：
1、 确定等价类：
有效等价类：代表对程序有效的输入；
无效等价类：代表其他任何可能的不正确的输入条件。
确定等价类的指导原则：
a. 如果输入条件规定了一个取值范围，则应确定一个有效等价类，两个无效等价类。
b. 如果输入条件规定取值的个数，那么应确定出一个有效等价类和两个无效等价类。
c. 如果输入条件规定一个输入值的集合，而且有理由认为程序会对每个值进行不同的处理，那么应确定一个有效等价类和一个无效等价类。
d. 如果樽俎输入条件规定了“必须是”的情况，那么应确定一个有效等价类和一个无效等价类。
2、 生成测试用例。
使用等价类来生成测试用例。其过程：
a、 为每个等价类设置一个不同的编号；
b、 编写新的测试用例，尽可能多地覆盖那些尚未被涵盖的有效等价类，直到所有的有效等价类都被测试用例所覆盖。
c、 编写新的用例，覆盖一个且仅一个尚未被涵盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。
边界值分析
 边界条件：是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。
 边界值分析方法与等价划分方法的不同点：
1、与从等价类中挑选出任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每一个边界都经过一次测试；
2、与仅仅关注输入条件不同，还需要考虑从结果空间设计测试用例。
 设计边界值分析方法的测试用例的一些通用指南：
1、如果输入条件规定了一个输入值范围，那么应针对范围的边界设计测试用例，针对刚刚越界的情况设计无效输入测试用例。
2、如果输入条件规定了 输入值的数量，那么应针对最小数量输入值、最多数量输入值、以及比最小数量少一个，比最大数量多一个的情况设计测试用例。
3、对每个输出条件应用指南1，还要注意检查结果空间的边界，因为输入的边界并不代表是输出的边界。
4、对每个输出条件应用指南2。
5、如果程序的输入或输出是一个有序序列，则应特别注意该序列的第一个和最后一个元素。
6、此外，还要发挥聪明才智找出其他的边界条件。
 边界值分析方法和等价划分之间的重要区别：边界值分析考察正处于等价划分边界或边界附近的状态。
 边界值分析方法常常使用得不好，因为边界条件可能非常微妙，常常很难确定。
因果图
 边界值分析和等价划分的一个弱点：未对输入条件的组合进行分析。
 因果图有助于用一个系统的方法选择出高效的测试用例集，而且还可以指出规格说明的不完整性和不明确之处。其生成测试用例的过程如下：
  1、将规格说明分解为可执行的片段。
2、确定规格说明中的因果关系。“因”：一个明确的输入条件或输入条件的等价类。“果”：指一个输出条件或系统转换。一旦因果关系被确定下来，每个“因”和“果”都被赋予一个唯一的编号。
3、分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。
4、给图加上注解符合，说明由于语法或环境的限制而不能联系起来的“因”和“果”。
5、通过仔细地跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表，表中的每一列代表一个测试用例。
6、将判定表指的列转换为测试用例。
 因果图方法是一个根据条件的组合而生成测试用例的系统性的方法。它确实能产生一组有效的测试用例，但通常它不能生成全部应该被确定的有效测试用例。而且也没有充分考虑边界条件。因果图可以考虑边界条件，但这会导致因果图急剧复杂化，因此最好单独考虑边界值分析。
 因果图方法难点在于：将因果图转化为判定表。
错误猜测
 错误猜测是一项依赖于直觉的非正规的过程，因此很难描述出这种方法的规程。其基本思想：列举出可能犯的错误或错误易发情况的清单，然后依据清单来编写测试用例，检查特定的输入值中有0，或特定的输出值被强制为0的情况。另一思想：在阅读规格说明时联系程序员可能做的假设来确定测试用例。
测试策略
 因为每一种测试方法可提供一组有用的测试用例，但不能单独提供一个完整的测试用例集，因此采用测试策略来合理组合。一组合理的策略如下：
  1、如果规格说明中包含输入条件组合的情况，应首先使用因果图分析法。
  2、在任何情况下都应该使用边界值分析方法。
  3、应为输入和输出确定有效和无效等价类。
  4、使用错误猜测技术增加更多的测试用例。
5、针对上述测试用例集检查程序的逻辑结构。使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则。
 上述策略并不能保证可发现所有的错误，但实践证明是一个合理的折中方案。
第五章、模块（单元）测试
模块测试（单元测试）：是对程序中的单个子程序、或过程进行测试的过程。
这样做有三个动机：
 1、它是一种管理组合的测试元素的手段。
 2、模块测试减轻了调试的难度，利于错误定位。
 3、模块测试通过为我们提供同时测试多个模块的可能，可将并行工程引入软件测试中。
模块测试的目的：将模块的功能与定义模块的规格说明或接口规格说明进行比较。测试是为了揭示出模块与其规格说明存在着矛盾。
模块测试包括三个方面：
 1、测试用例的设计方式。
 2、模块测试及集成的顺序。
 3、对执行模块测试的建议。
测试用例设计
   需要使用两种类型的信息：模块的规格说明、模块的源代码。
   模块的规格说明：规定了模块的输入和输出参数以及模块的功能。
   模块测试方法：面向白盒测试。
模块测试的测试用例设计过程：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。
说明：多重条件覆盖准则要优于其他准则，任何逻辑覆盖准则尚不足以胜任作为生成模块测试用例的唯一手段。
增量测试
 在执行模块测试过程中，要考虑两点：
    1、如何设计一个有效的测试用例集。
    2、将模块组装成工作程序的方式。包括增量测试和非增量测试。
   两种增量测试策略：自顶向下的和自底向上的开发和测试过程。
非增量测试（崩溃（big-bang）测试）：先独立地测试每个模块，然后再将这些模块组装成完整的程序进行测试。
增量测试（集成）：先将下一步要测试的模块装到测试完成的模块集合中，然后再进行测试。
测试单独的模块需要一个特殊的驱动模块（driver module）和一个或多个桩模块（stub module）
结论：
  1、非增量测试工作量更多一些，而增量测试工作量少一些。
2、若使用增量测试，可较早地发现模块中与不匹配接口，不正确假设相关的编程错误。而非增量测试只能到最后的组装测试才能看到。
3、若使用增量测试，调试会更容易进行，更利于错误定位。
4、增量测试会将测试进行得更彻底。
5、非增量测试所占用的机器时间显得少一些。但需要更多的驱动模块和桩模块。
6、模块测试开始阶段，若使用非增量测试，会有更多的机会进行并行操作。
总之，增量测试相对更好一些。
自顶向下测试和与自底向上测试
 “自顶向下的测试”、“自顶向下的开发”、“自顶向下的设计”：前两者是同义词，但“自顶向下的设计”是一个独立的概念，其可采用自底向上的方式进行增量测试。
 自底向上的测试常常会被错误地当作非增量测试。
 自顶向下的测试：
  从程序的顶部或初始模块开始测试。
增量的唯一准则：要成为合乎条件的下一个模块，至少一个该模块的从属模块（调用它的模块）事先经过了测试。
要点：桩模块的编写、采用什么样的形式将测试用例提交给程序。
采用什么样的形式将测试用例提交给程序：测试数据是通过其一个或多个桩模块提交给模块的。如果被测模块仅仅调用桩模块一次，则需要编写多个桩模块版本，以此来提交多个测试用例。
增量的指南：
 1、如果程序中存在关键部分，则关键部分应尽早添加进去。
 2、在设计模块序列时，应将I/O模块尽可能早的添加进来。
自顶向下策略的缺陷：略。
 自底向上的测试：
  开始于程序中的终端模块。
增量的唯一准则：要成为合乎条件的下一个模块，该模块的所有从属模块（它调用的模块）事先经过了测试。
要点：驱动模块的编写。
驱动模块编写：包含有效的测试输入、调用被测模块且将输出显示出来的模块。无需编写多个版本。
增量的指南：
 如果程序中存在关键部分，则关键部分应尽早添加进去。
不足：没有早期程序框架的优点。
比较：
增量测试策略 优点 缺点
自顶向下 1、如果主要的缺陷发生在程序的顶层将非常有利。
2、一旦引入I/O功能，提交测试用例会更容易。
3、早期的程序框架可以进行演示，并可激发积极性。 1、必须开发桩模块。
2、桩模块要比最初表现的更复杂。
3、在引入I/O功能之前，向桩模块中引入测试用例比较困难。
4、创建测试环境可能很难，甚至无法实现。
5、观察测试输出很困难。
6、使人误解设计和测试可以交迭进行。
7、会导致特定模块测试的完成延后。
自底向上 1、如果主要的缺陷发生在程序的底层将非常有利。
2、测试环境比较容易建立。
3、观察测试输出比较容易。 1、必须开发驱动模块
2、直到最后一个模块添加进去，程序才形成一个整体。
执行测试
当测试用例造成模块输出的实际结果与预期结果不匹配的情况时，存在两个可能的解释：模块错误 or 预期的结果错误（测试用例不正确）。因此应对测试用例进行测试。
自动化测试工具：可以降低对驱动模块的需求；流程分析工具可以列举出程序中的路径，找出从未被执行的语句。
对预期输出进行定义是测试用例必不可少的部分。
执行测试时，应该查找程序的副作用（不该执行的操作）。
第六章、更高级别的测试
当程序无法实现其最终用户要求的合理功能时，就发生了一个软件错误。
  软件开发过程在很大程度上是沟通有关最终程序的信息、并将信息从一种形式转换到另一种形式。因此，绝大部分软件错误都可以归因为信息沟通和转换时发生的故障、差错和干扰。
  模块测试：发现程序模块与其接口规格说明之间的不一致。
  功能测试：为了证明程序未能符合其外部规格说明。
  系统测试：为了证明软件产品与其初始目标不一致。
  
集成测试：并不作为一个独立的测试步骤，而且在进行增量模块测试时，它是模块测试的隐含部分。
功能测试：
  一个试图发现程序与其外部规格说明之间存在不一致的过程。
  外部规格说明：一份从最终用户的角度对程序行为的精确描述。
  功能测试属黑盒测试。对外部规格说明进行分析以获取测试用例集。方法：等价类划分、边界值分析、因果图分析、错误猜测。
系统测试：
  最容易被错误理解，也是最困难的测试过程。并非是测试整个系统或程序功能的过程。而是将系统或程序与其初始目标进行比较。
  系统测试并不局限于系统，它是一个试图说明程序作为一个整体是如何不满足其目标的过程。如果产品没有一组书面的、可度量的目标，系统测试就无法进行。注意：不是与外部规格说明进行比较。
  系统测试有两个方面的作用：将程序与其目标和用户文档相比较、将用户文档与程序目标相比较。
能力测试：
   判断目标文档提及的每一项能力是否都确实已经实现。
  容量测试：
   为了证明程序不能处理目标文档中规定的数据容量。
  强度测试：
使程序承受高负载或强度的检验。即在很短的时间间隔内达到的数据或操作的数量峰值。
易用性测试：
  1、每个用户界面是否都根据最终用户的智力、教育背景和环境要求而进行了调整？
  2、程序的输出是否有意义、不模糊且没有计算机的杂乱信息？
  3、错误诊断是否直接，用户是否需要有一定的经历才能理解它？
4、整体的用户界面是否在语法、惯例、语义、格式、风格和缩写方面展现出了相当程度的概念完整性、基本的一致性和统一性？
  5、在准确性极为重要的环境里，输入中是否有足够的冗余信息？
  6、系统是否包含过多或不太可能用到的选项？
  7、对于所有的输入，系统是否返回了某些类型的即时确认信息？
  8、程序是否易于使用?
安全性测试：
  设计测试用例来突破程序安全检查的过程。
性能测试：
  在特定负载和配置环境下程序的响应。
存储测试：
  设计测试用例来证明程序使用的内存和辅存的容量、以及临时文件或溢出文件的大小。
配置测试：
至少应该使用每一种类型的设备，以最大和最小的配置来测试程序。如软件本身的配置可忽略掉某些组件；运行在不同的操作系统、使用不同的Web浏览器等。
兼容性/配置/转换测试：
  证明兼容性目标未被满足，转换过程并未生效。尤其是数据库升级。
安装测试：
   是系统测试的一个重要部分。对自动安装系统而言，尤为重要。
   可靠性测试：
   测试软件或系统的平均故障间隔时间（MIBF）目标或合理的功能错误目标。
   可恢复性测试：
如操作系统、数据库管理系统和远程处理系统等软件通常都有可恢复性目标，说明系统如何从程序错误、硬件失效和数据错误中恢复过来。系统测试的目标就是证明这些恢复机制不能够发挥作用。使平均恢复时间（MTTR）最小。
适应性测试：
 软件可能有适应性或可维护性的目标。这些目标可能定义了系统提供的服务辅助功能，包括存储转存程序或诊断程序、调试明显问题的平均时间、维护过程以及内部业务文档的质量等。
文档测试：
 需要检查用户文档的正确性。
过程测试：
 必须对所有已规定的人工的操作过程进行测试。
系统测试的执行：
 系统测试的关键是决定由谁来进行测试。唯一一个不能由开发机构来执行的测试。
测试工作小组：几位系统测试专家、一位最终用户代表、一位人类工程学工程师、系统的设计者。
验收测试：
通常由程序的客户或最终用户来进行。不是软件开发机构的职责。将程序的实际操作与原始合同进行对照。验收测试最好的方法是设计测试用例，尽力证明程序没有满足合同的要求。
安装测试：
 为了发现在安装过程中出现的错误。
  1．用户必须选择大量的选项。
  2．必须分配并加载文件和库。
  3．必须进行有效的硬件配置。
  4．软件可能要求网络连通，以便与其他软件连接。
此外测试用例还要检查以确认已选的选项集合互不冲突。系统的所有部件全部存在，所有的文件已经创建并包含必须内容、硬件配置妥当等。
测试的计划与控制：
 一个良好的测试计划包括：
   目标：定义每个测试阶段的目标。
   结束准则：规定每个测试阶段何时可以结束。
   进度：每个阶段的时间表。
   责任：每个阶段，应确定谁设计、编写和验证测试用例，谁来修改发现的软件错误。
  测试用例库及标准：用于确定、编写以及存储测试用例的系统方法。
   工具：需使用的测试工具。
   计算机时间：计划每个测试阶段所需的计算机时间。
   硬件配置：如何满足需求及何时满足。
  集成：定义程序如何组装在一起的方法。即：系统集成计划。
跟踪步骤：跟踪测试进行中的方方面面，包括错误易发模块的定位，以及有关进度、资源和结束准则的进展评估。
调试步骤：制定上报已发现错误、跟踪错误修改进程以及将修改部分加入系统中去的机制。
回归测试：对程序作了功能改进或进行了修改后进行，其目的是判断程序的改动是否引起了程序其他方面的退步。通常重新执行测试用例中的某些子集。
测试结束准则：
软件测试过程中最难回答的一个问题。
最常见的两个准则：
 1、用完了安排的测试时间后，测试便结束。
 2、当执行完所有测试用例都未发现错误，测试便结束。
另外三类有用的准则：
 1、根据特定的测试用例设计技术。如：
测试用例来源于：满足多重条件覆盖准则、及对模块接口规格说明进行边界值分析，所有测试用例都不成功。
测试用例来源于：因果图分析、边界值分析、错误猜测，所有测试用例都不成功。
存在三个问题：对那些无特定方法测试阶段无效；要依赖于主观度量；不同于设置一个目标再让测试人员选择最佳的实现方法。
 2、以确切的数量来描述结束测试的条件。
强化了软件测试的定义。但存在两个问题：如何获得要发现的错误数量；利用以前程序的经验来预测出数字。
独立的测试机构：
 雇用独立的公司进行软件测试。
第七章、调试
调试有两个步骤：
   1、错误定位；
   2、修改错误。
  虽然调试必不可少，但不受程序员欢迎，其原因：
   1、个人自尊会从中阻扰。
   2、热情耗尽。
   3、可能会迷失方向。
   4、必须自力更生。
暴力法调试：
  可划分为三类：
   1、利用内存信息输出来调试。
    是最缺乏效率的调试，原因：
     难以在内存区域与源程序中的变量之间建立对应关系。
     即使对于复杂度较低的程序，内存信息输出会产生数量庞大的数据，大多与调试无关。
     内存信息输出显示的是程序的静态快照，无程序的动态状态。
内存信息输出很少可以精确地在错误发生的地方产生，无法显示错误发生时程序状态。
通过分析输出的内存信息来发现问题的方法并不太多。
   2、根据一般的“在程序中插入打印语句”建议来调试。
    比内存信息输出要好一些，但仍有很多缺点：
     不是鼓励我们去思考程序中的问题，而主要是一种碰运气的方法。
     它所产生的需要分析的数据量非常庞大。
它要求我们修改程序，这些修改可能会掩盖错误、改变关键的时序关系或引入新的错误。
它可能对小型程序有效。对大型程序，成本就相当高。而且对某些程序无法使用。
3、 使用自动化的调试工具进行调试。
其工作机制类似于在程序中插入打印语句，但并不修改程序本身。
调试工具可设断点。
暴力调试法的问题：忽略了思考过程。建议在其他的方法都失效的情况下，作为我们思考过程的补充，而不是替代方法。
归纳法调试：
 步骤：
  1、确定相关数据。主要错误是未能将所有可用的数据或症状都考虑进来。
  2、组织数据。
  3、作出假设。研究线索之间的关系，利用线索结构作出关于错误原因的假设。
  4、证明假设。
演绎法调试：
  步骤：
   1、列出所有可能的原因或假设。
   2、利用数据排除可能的原因。
   3、提炼剩下的假设。
   4、证明剩下的假设。
回溯法调试：
  在小型程序中定位错误的一种有效的方法是沿着程序的逻辑结构回溯不正确的结果，直到找出程序逻辑出错的位置。
测试法调试：
  使用测试用例来调试，目的是提供有用的信息，供定位某个被怀疑的错误之用。
  此处测试用例与供测试使用的测试用例存在区别：供测试的测试用例“胖”；而供调试的测试用例“瘦”。
调试的原则：
  定位错误的原则：
   1、动脑筋：对错误症状的有关信息进行分析。
   2、如果遇到了僵局，就留到稍后解决。
   3、如果遇到了困境，就把问题描述给其他人听。
   4、仅将测试工具作为第二种手段
   5、避免使用试验法－仅将其作为最后的手段。
  修改错误的技术：
   1、存在一个缺陷的地方，很可能还存在其他缺陷。
   2、应纠正错误本身，而不仅是其症状。
   3、正确纠正错误的可能性并非100％
   4、正确修改错误的可能性随着程序规模的增加而降低。
   5、应意识改正错误会引入新错误的可能性。
   6、修改错误的过程也是临时回到设计阶段的过程。
   7、应修改源代码，而不是目标代码。
错误分析
  调试可以告诉我们软件错误的本质，关于软件错误本质的信息可以为改进将来的设计、编码和测试过程提供有价值的反馈信息。
  错误出现在什么地方？需回溯研究程序文档和项目的历史。是最有价值的问题。
  谁制造了这个错误？
  哪些做得不正确？准确地判断出错误发生的原因。
  如何避免该错误的出现？
  为什么错误没有早些发现？
  该如何更早的发现错误？
第八章、极限测试
XP的开发方法的目的是在短时间内开发高质量的程序。XP模型高度依赖模块的单元和验收测试。这种形式的测试被称为极限测试（XT）。
极限编程基础
  XP与传统的开发过程相比有不同之处：
XP避免了大规模项目的综合症。XP的策划阶段将重点放在收集应用程序需求，而不是设计程序上。
XP避免了编写不需要的功能。
XP方法将精力集中在测试上。传统开发模型建议先编码，然后才生成测试接口；而XP首先生成单元测试用例，然后才编写代码通过测试。
XP的12个核心实践可归纳为：
 1、聆听客户和其他程序员的谈话。
 2、与客户合作，开发应用程序的规格说明和测试用例。
 3、结对编码。
 4、测试代码库。
XP有两个重要的原则：
 计划：XP的计划阶段与传统开发模型不同，通常将需求收集与应用设计结合起来。XP的计划重点是确定客户的应用需求，然后设计使用场景来满足客户的应用需求。通过生成使用场景，可以深入洞悉应用程序的目的和需求。此外，在验收测试中也可用到这些场景。
 极限编程的12个实践：
实践 注释
1、计划与需求分析 a将市场和业务开发人员集中起来，共同确认每个软件特征的最大商业价值。
b 以使用场景的形式重新编写每个重要的软件特征
c程序员估计完成每个使用场景的时间
d 客户根据估计时间和商业价值选择软件的功能特征
2、小规模、递增地发布 努力增加细微的、实在的、可增值的特征、频繁发布新版本
3、系统隐喻 编程小组确认隐喻，便于建立命名规则和程序流程
4、简要设计 实现最简单的设计，使代码通过单元测试。假设变更即将发生，因此不要在设计上花太多时间，只是不停的实现。
5、连续测试 在编写模块之前就生成单元测试用例。模块只有通过单元测试之后才告完成。程序只有在通过所有的单元测试和验收测试之后才算完成。
6、重构 清理和调整代码库，单元测试有助于确保在此过程中不破坏程序的功能。应在任何重构之后重新进行所有的单元测试。
7、结对编程 两个程序员协同工作，在同一台机器开发代码库。可使代码进行实时检查，能极大地提高缺陷的发现率和纠正率。
8、代码的集体所有权 所有代码归全体程序员所有，没有哪一个程序员只致力于开发某一个代码库。
9、持续集成 每天在变更通过单元测试之后将其集成到代码库中。
10、每周工作40小时 不允许加班。重大发布前一个星期例外。
11、客户在现场 开发人员和编程小组可以随时接触客户，这样可快速、准确地解决问题，使开发不致于中断。
12、按标准编码 所有的代码看上去必须一致。设计一个系统隐喻有助于满足该原则。
XP方法目前不太接受。
极限测试：概念
  极限测试方法强调连续测试。由单元测试和验收测试组成。目标都是确定程序中的错误。
  极限单元测试
   主要测试方法。有两个简单规则：
所有代码模块在编码开始之前必须设计好单元测试用例。
在产品发布之前必须通过单元测试。
 极限测试的单元测试与前面的单元测试的最大差别：极限测试中的单元测试必须在模块编码之前就设计和生成。
 在编码之前设计单元测试的好处：
  1、获得了代码将满足其规格说明的信心
  2、在开始编码之前，就展示了代码的最终结果
  3、更好地理解了应用程序的规格说明和需求
4、可以先实现一些简单的设计，稍后再放心地重构代码以改善程序的性能，而无需担心破坏应用程序的规格说明。
 以上优点对获得对应用程序规格说明和需求的洞察和理解不应被低估。
  验收测试
   目的是判断应用程序是否满足如功能性和易用性等其他需求。
极限测试的应用
  极限测试要求使用一个独立的黑盒测试方法，消除所有的偏见。
  测试用例设计（略）
  测试驱动器及其应用（略）
 小结
  极限编程：轻量级的开发过程，强调：沟通、计划和测试。
  极限测试重点：单元测试和验收测试。
  极限测试要求开始于程序编码之前，根据程序的规格说明设计测试配件。
第九章、测试因特网应用系统
  因特网本质为C/S 结构。客户端：Web浏览器；服务器端：Web或应用服务器。
电子商务的基本结构
  
  三层结构：
   第一层：Web服务器，又称“表示层”
   第二层：“业务层”，运行应用服务器。相关功能：
    1、事务处理
    2、用户身份鉴定
    3、数据确认
    4、程序日志
   第三层：“数据层”，从数据源（一个关系数据库管理系统RDBMS）中存储和获取数据。
测试的挑战
  测试基于因特网的应用系统所遇到的挑战：
   1、用户群庞大且五花八门：
   2、业务环境
3、测试环境
4、地点
5、安全性
6、浏览器的兼容性
7、网络连通性
测试的策略（略）
  表示层的测试
  业务层的测试
  数据层的测试

这里讲的测试是指 通过系统的 正规的方法进行测试 如 软件黑盒，白盒测试。

    但其实国内很多软件被测试过的定义就是 有开发人员或者2-3个专门测试的员坐在板凳上，把软件从头到尾点一遍看看是否有错误。并且说“只要用户很难发现错误，就算测试通过了”。

    不过话说到头。软件测试的目的还只能是“只要用户很难发现错误，就算测试通过了”,任何一个公司的产品都不能保证绝对没有错误。

    我这里不是要讲测试的方法或者系统性的讨论。我是说我们是否要对所有 产品进行正规系统性测试呢。

    分以下几种情况

    1. 如果你是做 高端产品的。如开发工具，操作系统，浏览器。这个无可厚非。你不系统测试。晚上会被人套上麻袋痛打。

    2. 如果是应用软件。则 又要分2种情况。 银行或者政府软件。也是要系统性测试的。企业应用软件，如果是ERP那种，你不系统测试后果更惨。如果是小企业用的辅助软件，网站 ，如OA ,那么 很多IT公司都是由几个人进行点击测试就完了。因为老板一下子告诉你有5个项目这个月要交付给客户，换作是你 你会怎么办。

    3。做游戏软件 --- 根本不需要大测试，可以边公厕（公测），边开发，这叫发动网民一起来加班，并且不付工资。（开个玩笑。其实游戏软件的测试还是很系统性的。技术含量也是很高的。）

    4。搞互联网。 一般这样的人是经营网站。不卖。从理论上讲。自己搞互联网 。那网站抛头露面的机会多更应该系统的测试。其实不然。如果你是一个大型门户，你从开发到栏目推出可能只有5个小时。你还测试个啥。技术人员自己点点就可以了。出错了大不了自动转向到一个友好的界面上。

    5。自己接的私单。 我有个朋友就常接私单。他说单子量少的时候。也测试 不过也是自己点点。单子多的时候 根本不测试。运行一下，正常机子不死机就可以了。

    网友看了自己应该心里清楚了。软件到底要不要系统测试了。国情很重要，识实务者为俊杰。同时也要体谅辛勤劳作的程序员。软件出错不是应该的，但是绝对不是他们想要的。

1

路由器是IP网络的核心设备，其性能的好坏直接影响IP网网络规模、网络稳定性以及网络可扩展性。路由器区别于一般简单的网络互连设备，在性能测试时还应该加上路由器特有的性能测试。

　　路由器是IP网络的核心设备，其性能的好坏直接影响IP网网络规模、网络稳定性以及网络可扩展性。路由器区别于一般简单的网络互连设备，在性能测试时还应该加上路由器特有的性能测试。路由器在计算机网络中有着举足轻重的地位，是计算机网络的桥梁。通过它不仅可以连通不同的网络，还能选择数据传送的路径，并能阻隔非法的访问。路由器的配置对初学者来说，并不是件十分容易的事。

　　(一)功能测试

　　路由器功能通常可以划分为如下方面。

　　(1)接口功能：该功能用作将路由器连接到网络。可以分为局域网接口及广域网接口两种。局域网接口主要包括以太网、令牌环、令牌总线、FDDI等网络接口。广域网接口主要包括E1/T1、E3/T3、DS3、通用串行口(可转换成X.21DTE/DCE、V.35DTE/DCE、RS232DTE/DCE、RS449DTE/DCE、EIA530DTE)等网络接口。(2)通信协议功能：该功能负责处理通信协议，可以包括TCP/IP、PPP、X.25、帧中继等协议。(3)数据包转发功能：该功能主要负责按照路由表内容在各端口(包括逻辑端口)间转发数据包并且改写链路层数据包头信息。(4)路由信息维护功能：该功能负责运行路由协议，维护路由表。路由协议可包括RIP、OSPF、BGP等协议。(5)管理控制功能：路由器管理控制功能包括五个功能，SNMP代理功能，Telnet服务器功能，本地管理、远端监控和RMON功能。通过多种不同的途径对路由器进行控制管理，并且允许纪录日志。(6)安全功能：用于完成数据包过滤，地址转换，访问控制，数据加密，防火墙，地址分配等功能。

　　路由器对上述功能并非必要完全实现。但是由于路由器作为网络设备，存在最小功能集，对最小功能集所规定的功能，路由器必须支持。因为绝大多数功能测试可以由接口测试、性能测试、协议一致性测试和网管测试所函盖，所以路由器功能测试一般可以只对其他测试无法涵盖的功能作验证性测试。路由器功能测试一般采用远端测试法。

　　(二)性能测试

　　路由器是IP网络的核心设备，其性能的好坏直接影响IP网网络规模、网络稳定性以及网络可扩展性。由于IETF没有对路由器性能测试作专门规定，一般来说只能按照RFC2544( Benchmarking Methodology for Network Interconnect Devices)作测试。但路由器区别于一般简单的网络互连设备，在性能测试时还应该加上路由器特有的性能测试。例如路由表容量、路由协议收敛时间等指标。

　　路由器性能测试应当包括下列指标。

　　(1)吞吐量：测试路由器包转发的能力。通常指路由器在不丢包条件下每秒转发包的极限，一般可以采用二分法查找该极限点。(2)时延：测试路由器在吞吐量范围内从收到包到转发出该包的时间间隔。时延测试应当重复20次然后取其平均值。(3)丢包率：测试路由器在不同负荷下丢弃包占收到包的比例。不同负荷通常指从吞吐量测试到线速(线路上传输包的最高速率)，步长一般使用线速的10%。(4)背靠背帧数：测试路由器在接收到以最小包间隔传输时不丢包条件下所能处理的最大包数。该测试实际考验路由器缓存能力，如果路由器具备线速能力(吞吐量=接口媒体线速)，则该测试没有意义。(5)系统恢复时间：测试路由器在过载后恢复正常工作的时间。测试方法可以采用向路由器端口发送吞吐量110%和线速间的较小值，持续60秒后将速率下降到50%的时刻到最后一个丢包的时间间隔。如果路由器具备线速能力，则该测试没有意义。(6)系统复位：测试路由器从软件复位或关电重启到正常工作的时间间隔。正常工作指能以吞吐量转发数据。

　　在测试上述RFC2544中规定的指标时应当考虑下列因素。

　　帧格式：建议按照RFC2544所规定的帧格式测试;帧长：从最小帧长到MTU顺序递增，例如在以太网上采用64, 128, 256, 512, 1024, 1280, 1518字节;认证接收帧：排除收到的非测试帧，例如控制帧、路由更新帧等;广播帧：验证广播帧对路由器性能的影响，上述测试后在测试帧中夹杂1%广播帧再测试;管理帧：验证管理帧对路由器性能的影响，上述测试后在测试帧中夹杂每秒一个管理帧再测试;路由更新：路由更新即下一跳端口改变对性能的影响;过滤器：在设置过滤器条件下对路由器性能的影响，建议设置25个过滤条件测试;协议地址：测试路由器收到随机处于256个网络中的地址时对性能的影响;双向流量：测试路由器端口双向收发数据对性能的影响;多端口测试：考虑流量全连接分布或非全连接分布对性能的影响;多协议测试：考虑路由器同时处理多种协议对性能的影响;混合包长：除测试所建议的递增包长外，检查混合包长对路由器性能的影响，RFC2544除要求包含所有测试包长外没有对混合包长中各包长所占比例作规定。笔者建议按照实际网络中各包长的分布测试，例如在没有特殊应用要求时以太网接口上可采用60字节包50%，128字节包10%，256字节包15%，512字节包10%，1500字节包15%。除上述RFC2544建议的测试项外还建议测试如下内容。

　　①路由震荡：路由震荡对路由器转发能力的影响。路由震荡程度即每秒更新路由的数量可以依据网络条件而定。路由更新协议可采用BGP。②路由表容量：测试路由表大小。骨干网路由器通常运行BGP，路由表包含全球路由。一般来说要求超过10万条路由，建议通过采用BGP输入导出路由计数来测试。③时钟同步：在包含相应端口例如POS口的路由器上测试内钟精度以及同步能力。④协议收敛时间：测试路由变化通知到全网所用时间。该指标虽然与路由器单机性能有关，但是一般只能在网络上测试，而且会因配置改变而变化。可以在网络配置完成后通过检查该指标来衡量全网性能。测试时间应当根据具体项目以及测试目标而定。一般认为测试时间应当介于60秒到300秒之间。另外一般可以根据用户要求和测试目标作设定选择。路由器性能测试一般可采用远端测试法。

(三)一致性测试

　　路由器一致性测试通常采用“黑箱”方法，被测试设备IUT叫做“黑箱”。测试系统通过控制观察点PCO与被测试设备接口。

　　不同的测试事件是通过不同的PCO来控制和观察的，按照其应答是否遵守规范，即定时关系和数据匹配限制，测试的结果可分为通过、失败、无结果3种。路由器是一种复杂的网络互连设备，需要在各个通信层上实现多种协议。例如相应的接口的物理层和链路层协议、IP/ICMP等互联网层协议、TCP/UDP等传输层协议、Telnet/SNMP等应用层协议以及RIP/OSPF/BGP等路由协议。

　　协议一致性测试应当包含路由器所实现的所有协议。由于该测试内容繁多测试复杂，在测试中可以选择重要的协议以及所关心的内容测试。由于骨干网上路有器可能影响全球路由，所以在路由器测试中应特别重视路由协议一致性测试例如OSPF和BGP协议。由于一致性测试只能选择有限测试例测试，一般无法涵盖协议所有内容。所以即使通过测试也无法保证设备完全实现协议所有内容，所以最好的办法是在现实环境中试运行。路由器一致性测试一般采用分布式测试法或远端测试法。

　　(四)互操作测试

　　由于通信协议、路由协议非常复杂且拥有众多选项，实现同一协议的路由器并不能保证互通互操作。并且因为一致性测试能力有限，即使通过协议一致性测试也未必能保证完全实现协议。所以有必要对设备进行互操作测试。

　　互操作测试实际上是将一致性测试中所用的仪表替换成需要与之互通互操作的设备，选择一些重要且典型的互连方式配置，观察两设备是否能按照预期正常工作。

　　(五)稳定性、可靠性测试

　　由于大多数路由器需要每天24小时，每周7天连续工作，作为Internet核心设备的骨干路由器的稳定性和可靠性尤其重要。所以用户需要了解露由器的稳定性和可靠性。

　　路由器的稳定性和可靠性很难测试。一般可以通过两种途径的到：(1)厂家通过关键部件的可靠性以及备份程度计算系统可靠性;(2)用户或厂家通过大量相同产品使用中的故障率统计产品稳定性和可靠性。当然，用户也可以通过在一定时间内对试运行结果的要求来在一定程度上保证路由器的可靠性与稳定性。

　　(六)网管测试

　　网管测试一般测试网管软件对网络以及网络上设备的管理能力。由于路由器是IP网的核心设备，所以必须测试路由器对网管的支持度。如果路由器附带网管软件，可以通过使用所附带的网管软件来检查网管软件所实现的配置管理、安全管理、性能管理、计帐管理、故障管理、拓扑管理和视图管理等功能。如果路由器不附带网管软件，则应当测试路由器对SNMP协议实现的一致性以及对MIB实现的程度。由于路由器需要实现的MIB非常多，每个MIB都包含大量内容，很难对MIB实现完全测试。一般可以通过抽测重要的MIB项来检查路由器对MIB的实现情况。

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．因果图方法

　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

09. 请以您以往的实际工作为例详细的描述一次测试用例设计的完整的过程。

　　就说最近的这次网站功能的测试吧

　　首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。

　　第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对　　这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。

　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可

　　第四步：执行测试

10. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

　　是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。

性能测试类型包括负载测试，强度测试，容量测试等

　　负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

　　强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况

　　容量测试：确定系统可处理同时在线的最大用户数 

　　在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

　　Web服务器指标指标：

　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

　　* Successful Rounds：成功的请求；

　　* Failed Rounds ：失败的请求；

　　* Successful Hits ：成功的点击次数；

　　* Failed Hits ：失败的点击次数；

　　* Hits Per Second ：每秒点击次数；

　　* Successful Hits Per Second ：每秒成功的点击次数；

　　* Failed Hits Per Second ：每秒失败的点击次数；

现在准备面试软件测试的工作，既然下定决心，就从现在起将收集到的软件测试面试的所有问答陆续发到博客上，供大家参考指正，一起努力，一起进步！～

　　Mocha RTM从以下三个角度实现B/S架构系统性能的提升：

　　采集业务流程响应时间，提高用户的访问体验，最大可能的避免客户的流失

　　通过提前录制的业务流程，按照业务流程中的业务环节，实时或者定时模拟登录Web页面，并采集业务流程中各页面的响应时间，帮助互联网企业了解用户在网站的体验，在有需要时，及时进行系统优化，减少客户的流失。

　　监控各业务环节响应时间，分析业务服务瓶颈

　　IT部门通过业务流程录制工具，根据业务特点，将业务流程细分为各个业务环节，例如搜索-购买-结算等，系统分别监控各个环节的响应时间，帮助IT管理者快速分析出业务流程中，响应速度慢的瓶颈，并优化此瓶颈。

　　分析Web页面关键字，帮助互联网企业第一时间发现Web页面的不完整性。管理员输入页面上必须监控的关键字，如果关键字不出现，则该页面将定位为不可用

　　通过KPI图表，协助互联网企业，了解用户的访问体验

　　体验时间管理提供业务流程响应时间KPI分析报表，IT部门可以根据KPI报表分析出用户体验最差的业务流程或者业务环节，将协助IT部门有目的的进行系统优化，保障用户处于最佳体验。

　　Mocha RTM关键功能及亮点：

　　根据业务流程特点，灵活定制相关的业务监控流程

　　IT部门可以根据互联网站的业务特点，灵活录制不同的业务流程，并将业务流程分为不同的业务环节，根据录制的不同业务流程和业务环节进行响应时间的采集。

　　实时监控Web页面响应时间，分析用户访问体验

　　通过模拟登陆Web页面访问方式，将Web页面的返回时间进行统计和分析，即可以清楚地知道用户在登陆企业Web页面的具体响应和用户体验，将业务流程分为多个业务环节来分段监控，细化问题，分析业务服务瓶颈。

　　可以根据关键字对Web响应页面进行分析

　　用户体验时间管理不仅仅可以判断页面的响应时间，还可以根据监控的需求，分析Web页面的返回内容是否正确，如果返回页面有错误，通过告警，可以在第一时间通知管理员，并快速恢复故障。

　　URL过滤分析，帮助运维人员去除干扰，聚焦关键内容响应时间分析

　　用户体验时间管理将分析所有元素的返回时间，提供URL过滤分析功能，在过滤分析栏目中输入需要看到的关键元素响应时间，这样有利于管理人员清晰地得到自己关注的关键元素响应时间。

　　定制监控时段和监控频率

　　由于监控的不同需求，系统管理需要在登录繁忙的时候，减少监控采集次数和频率，以及响应时间的告警阈值都可以通过策略灵活的定义。

　　提供实时监控界面

　　系统管理人员不仅可以通过用户体验时间管理定时对响应时间进行采集，也可以尽可能快地点击采集按钮，对业务流程响应时间进行实时采集，达到更便捷的响应时间管理。

　　响应时间超时告警

　　一旦响应时间超过了预先定义的阈值，管理人员能第一时间被通知，并快速恢复或优化系统。

　　提供多样化和可定制的交易响应时间分析报表

　　提供多样化的报表和TOP10排名，帮助管理者分析Web页面的整体水平和具体的交易流程，尽最大可能的发现业务服务瓶颈，帮助互联网企业提高Web 页面服务水平，并最终提高互联网企业竞争力。

为了提高软件测试的效率，增进测试工作的广度和深度，越来越多的公司开始引入自动化测试。本文通过笔者对测试用例设计和表达上的一些理解，阐述如何写好功能自动化测试友好的用例，供大家参考。

自动化测试有其自身的特点，按照笔者的经验，自动化在一个项目，乃至一个公司开展的成功与否，并不是仅仅依靠QTP等工具使用者的脚本编写水平的提高就可以掌控的。而因为其他的一些因素，一旦自动化测试失去了它本身的高效、可控的特点的话，那反而是得不偿失，会增加项目的成本。

自动化测试人员进入项目的时间可能不是最早的，对需求的理解并不是在第一时间就很容易做到的。测试用例作为测试需求的载体、测试执行的依据和工作量的评估，它设计和表达的优劣直接影响到自动化测试开展的前几个阶段，如：需求学习、筛选适合自动化测试的用例以及提取公司级或项目的可重用脚本等方面的工作效率。

1.步骤和数据的分离：

好的测试用例，在执行的步骤(Step）的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：

1. 密码正确的登录

2. 密码错误的登录

3. 密码输入三次错误，卡被锁定

4. 取少于余额的款项

5. 尝试取大于余额的款项

6. 尝试取等于余额的款项（考虑手续费）

6. 取款额度大于当次的限制

7. 取款额度大于当天的限制

7. 取款次数大于限制次数

等等

不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下（此处只列出了操作的步骤，略去了系统的交互中的反馈结果）：

1. 插入卡->A:输入密码->B:按“确定”键->重复A-B

2. A:选择取款功能->B:填写取款金额->C:点击“确定取款”的按钮->D:取现金->重复A-D

因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢？

2. 单独的测试基础数据准备工作

第一个例子中的输入数据比较简单，但我们同样需要考虑的一个问题是：在测试中究竟我们输入什么样的具体数据呢？什么是”正确的密码“？什么又是”大于余额的款项“呢？

对于大的应用系统，数据之间的关系和准备过程都会很复杂，甚至也有其他外部系统导入、传输或计算出的数据。 一个比较好的做法是，将这些测试数据提前准备好，在每个阶段性测试前导入到系统中。一个比较典型的例子，假设要求你单独去测试几张复杂的财务报表，用其他的模块和外部系统，自己逐一的去创造数据，那会非常耗时耗力。这时，基础数据的准备就显得尤为重要，以此才能保证测试工作是高效的、测试结果是精确的。

如果有可能，复杂的测试基础数据最好是提前准备好的，类似这里例子中简单的 一个帐号为1234567890，密码为66666的有效银行卡，里面有人民币1000元正，等等。将这些内容预先准备好（可以用自动化工具来准备，或导出已有的数据为一个SQL的脚本），写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。

3. 测试用例的前置条件和后置条件

除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。比如准备一个初始设置条件下的IE浏览器和已安装过老版本该软件的XP系统。这些可重用的准入条件，可以考虑不作为特定用例的Step，而是把它提取出来，作为Setup Section或叫Pre-Condition。

对于后置条件或Post-condition，往往我们用它来做一些处理或恢复，比如在上面的取款例子中，如果我们要用相同的帐号重复测试，在正好取完所有金额，余额为零的情况下，可以通过一些步骤或数据库脚本重置帐号余额。同样，您为某个用例设置浏览器禁用了Cookie，执行完该用例后，是不是也是需要回复到默认设置的状态呢？

集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。

顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。

4. 常用业务操作(Knowledge Base)

对于一个大型的应用，比如银行系统，开发和测试工作是长期的，持续的一个过程，这样的系统很适合引入自动化测试。它业务逻辑复杂，测试技术性要求高，往往使用了不同厂商的工具和多种脚本语言（如Shell，Python等），也存在了很多可用的遗留脚本。

这些完成一些预定业务操作的脚本单元，是可以直接借用的。为了在公司和产品层面，管理好这些可复用的资源，一种好的方式是给它们标上号，如KB_PRJ01_Module02_XXX，集中管理起来，以后的用例中只要调用即可。

举例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试帐号向外汇款，取得响应信息，并保存结果，这可能是个复杂而底层的处理过程，对一般员工是不需要，也没有权限去深入掌握的。这时，将他们包装成一个个Shell脚本或小工具，做好使用说明和统一建档，在以后的项目测试中，只要调用就可以了。如此，可以大大提高各个有相关接口的模块的自动化测试工作效率。

软件版本知识合集|emule 限制
要了解软件，必须了解软件的一些入门知识。下面给大家讲解下软件版本号代表的知识。
该知识对软件菜鸟很有帮助，学会该知识，等于迈进了软件殿堂的初步门槛。下面跟随笔者学?

emule是什?，逐一了解各版本号的含义：

版本号划分：

V（Version）：即版本，通常用数字表示版本号。（如：EVEREST Ultimate V4.20.1188beta??

Build：用数字或日期标示版本号的异种方式。（如：VeryCD eMule V0.48a Build 071112??

SP：Service Pack，升级包????Windows XP SP 2/Vista SP 1)

授权和功能划分：

Trial：试用版，通常都有时间限制，有些试用版软件还在功能上做了一定的限制。可注册或购买成为正式版??

Unregistered：未注册??a href=http://agame.byethost16.com/147.html>emule.exe，通常没有时间限制，在功能上相对于正式版做了一定的限制。可注册或购买成为正式版??

Demo：演示版，仅仅集成了正式版中的几个功能，不能升级成正式版??

Lite：精简版??

Full：完整版??

开发阶段划分：

α（Alpha）版：内测版，内部交流或者专业测试人员测试用。Bug较多，普通用户最好不要安装??

β（Beta）版：公测版，专业爱好者大规模测试用，存在一些缺陷，该版本也不适合一般用户安装??

γ（Gamma）版：相当成熟的测试版，与即将发行的正式版相差无几??

RC版：Release Candidate候选版??a href=http://www.netcs.org.cn/posts/182>emule vista，处于Gamma阶段。从Alpha到Beta再到Gamma是改进的先后关系，但RC1、RC2往往是取舍关系??

Final：正式版??

语言划分??

SC：Simplified Chinese简体中文版??

GBK：简体中文汉字内码扩展规范版??

TC：Traditional Chinese繁体中文版??

BIG5：繁体中文大五码版??

UTF8：Unicode Transformation Format 8 bit，对现有的中文系统不是好的解决方案?

  其他不太常见的版本号

alphal 内部测试??

beta 外部测试??

demo 演示??

Enhance 增强版或者加强版 属于正式??

Free 自由??

Full version 完全??属于正式??

shareware 共享??

Release 发行??有时间限??

Upgrade 升级??

Retail 零售??

Cardware 属共享软件的一??a href=http://agame.byethost16.com/466.html>emule电驴下载，只要给作者回复一封电邮或明信片即可。（有的作者并由此提供注册码等），目前这种形式已不多见??

Plus 属增强版，不过这种大部分是在程序界面及多媒体功能上增强??

Preview 预览??

Corporation &Enterprise 企业??

Standard 标准??

Mini 迷你版也叫精简版只有最基本的功??

Premium 贵价??

Professional 专业??

Express 特别??

Deluxe 豪华??

Regged 已注册版

CN 简体中文版

CHT 繁体中文??

EN 英文??

Multilanguage 多语言??

Rip 是指从原版文件（一般是指光盘或光盘镜像文件）直接将有用的内容（核心内容）分离出??table align=center border=0 width=480 cellspacing=0 cellpadding=0>emule lowid，剔除无用的文档，例如PDF说明文件啊，视频演示啊之类的东西，也可以算做是精简版吧…但主要内容功能是一点也不能缺少的！
另：DVDrip是指将视频和音频直接从DVD光盘里以文件方式分离出来??

trail 试用版（含有某些限制，如时间、功能，注册后也有可能变为正式版??

RC 版。是 Release Candidate 的缩写，意思是发布倒计时，该版本已经完成全部功能并清除大部分的BUG。到了这个阶段只会除BUG，不会对软件做任何大的更改??

RTM 版。这基本就是最终的版本，英文是 Release To Manufactur，意思是发布到生产商??

Original Equipment Manufacturer (OEM) ：OEM软件是给电脑生产厂的版本

  Full Packaged Product (FPP)–Retail

FPP就是零售版（盒装软件），这种产品的光盘的卷标都带??quot;FPP"字样，比如英文WXP Pro的FPP版本的光盘卷标就是WXPFPP_EN，其中WX表示是Windows XP，P是Professional（H是Home），FPP表明是零售版本，EN是表明是英语。获得途径除了在商店购买之外，某些MSDN用户也可以得到??

Volume Licensing for Organizations (VLO)

团体批量许可证（大量采购授权合约），这是为团体购买而制定的一种优惠方式。这种产品的光盘的卷标都带有"VOL"字样，取"Volume"??个字母，以表明是批量，比如英文WXP Pro的VOL版本的光盘卷标就是WXPVOL_EN，其中WX表示是Windows XP，P是Professional（VOL没有Home版本），VOL表明是团体批量许可证版本，EN是表明是英语。获得途径主要是集团购买，某些MSDN用户也可以得到?

t's easy to make mistakes when testing software or planning a testing effort. Some mistakes are made so often, so repeatedly, by so many different people, that they deserve the label Classic Mistake.
在测试软件或制订测试工作计划时很容易犯一些错误。有些错误经常被许多不同的人一而再、再而三地犯，应该被列为典型错误。

Classic mistakes cluster usefully into five groups, which I've called "themes":

典型错误可以有效地分为五组，我把这些组称为“主题”。

· The Role of Testing: who does the testing team serve, and how does it do that?

· 测试的作用：谁承担测试小组的责任，如何做？

· Planning the Testing Effort: how should the whole team's work be organized?

· 制订测试工作计划：应该如何组织整个小组的工作？

· Personnel Issues: who should test?

· 人员问题：谁应该做测试？

· The Tester at Work: designing, writing, and maintaining individual tests.

· 工作中的测试员：设计、编写和维护各测试。

· Technology Rampant: quick technological fixes for hard problems.

· 过度使用技术：艰难问题的快速技术修复

I have two goals for this paper. First, it should identify the mistakes, put them in context, describe why they're mistakes, and suggest alternatives. Because the context of one mistake is usually prior mistakes, the paper is written in a narrative style rather than as a list that can be read in any order. Second, the paper should be a handy checklist of mistakes. For that reason, the classic mistakes are printed in a larger bold font when they appear in the text, and they're also summarized at the end.

本文有两个目标。第一，应当识别错误，将它们放到具体环境中，描述它们为什么是错误，并给出替代方法的建议。因为一个错误的具体环境通常是先决错误，所以本文将以叙事的方式而不是以可以按任意顺序阅读的列表方式来描述。第二，本文应该是一个便于查看的错误列表。因为这个原因，文章中出现的典型错误都以大号粗体字印刷，并在文章的结尾处汇总。

Although many of these mistakes apply to all types of software projects, my specific focus is the testing of commercial software products, not custom software or software that is safety critical or mission critical.

虽然这些错误很多都适用于所有类型的软件项目，但我的重点将放在商用软件产品的测试上，而不是定制软件或者是高度安全或关键任务的软件测试上。

This paper is essentially a series of bug reports for the testing process. You may think some of them are features, not bugs. You may disagree with the severities I assign. You may want more information to help in debugging, or want to volunteer information of your own. Any decent bug reporting system will treat the original bug report as the first part of a conversation. So should it be with this paper. Therefore, follow this link for an ongoing discussion of this topic.

本文主要是测试过程的一系列错误报告。你可能认为它们中的部分属于特性问题而不是 bug。你可能不赞成我设定的严重性级别。你可能需要更多的信息以用于帮助排除错误，或者希望提供你自己的信息。任何设计良好的错误报告系统都将原始的错误报告当作是对话的起始部分。本文也是这样，所以，可以按照链接参加这个主题的讨论。

Theme One: The Role of Testing

主题一：测试的作用

A first major mistake people make is thinking that the testing team is responsible for assuring quality. This role, often assigned to the first testing team in an organization, makes it the last defense, the barrier between the development team (accused of producing bad quality) and the customer (who must be protected from them). It's characterized by a testing team (often called the "Quality Assurance Group") that has formal authority to prevent shipment of the product. That in itself is a disheartening task: the testing team can't improve quality, only enforce a minimal level. Worse, that authority is usually more apparent than real. Discovering that, together with the perverse incentives of telling developers that quality is someone else's job, leads to testing teams and testers who are disillusioned, cynical, and view themselves as victims. We've learned from Deming and others that products are better and cheaper to produce when everyone, at every stage in development, is responsible for the quality of their work ([Deming86], [Ishikawa85]).

人们犯的第一个主要错误是认为测试小组应当负责质量保证。这个角色常常分配给组织中的第一测试小组，将它作为最后的防御，成为开发小组（被指责为产生低劣质量）和客户（必须受到保护以远离低劣质量）的一个屏障。它的特征是测试小组（常称为“质量保证组”）表面上具有阻止产品发货的权力。这本身是一个令人沮丧的任务：测试小组不能提高质量，只能强制一个最低水平。更糟糕的是，这种权力常常是看上去比实际的重要。如果发现这一点，再加上有违常理地暗示开发人员质量是别人的事情，导致测试小组和测试员感到失望、愤事嫉俗、感觉自己是受害者。我们从Deming 和其他人的工作可以得知：如果每个人都在开发的各个阶段对他们的工作质量负责，则产品会又好又便宜（[Deming86]，[Ishikawa85]）。

In practice, whatever the formal role, most organizations believe that the purpose of testing is to find bugs. This is a less pernicious definition than the previous one, but it's missing a key word. When I talk to programmers and development managers about testers, one key sentence keeps coming up: "Testers aren't finding the important bugs." Sometimes that's just griping, sometimes it's because the programmers have a skewed sense of what's important, but I regret to say that all too often it's valid criticism. Too many bug reports from testers are minor or irrelevant, and too many important bugs are missed.

实际上，不管表面上的作用是什么，大多数组织都相信测试的目的是发现 bug。这个定义的危害比前一个定义的危害要小，但是忽略了一个关键词。当我同程序员和开发经理谈到测试员的时候，不时听到一个关键的句子：测试员找不到重要的 bug。有时候这种说法只是一种抱怨，有时候是因为程序员对于什么是正确的感觉不对，但我很遗憾地说，它们经常是有效的批评。测试员的太多的bug 报告是微小的、不相关的，而有太多重要的错误都被遗漏了。

What's an important bug? Important to whom? To a first approximation, the answer must be "to customers". Almost everyone will nod their head upon hearing this definition, but do they mean it? Here's a test of your organization's maturity. Suppose your product is a system that accepts email requests for service. As soon as a request is received, it sends a reply that says "your request of 5/12/97 was accepted and its reference ID is NIC-051297-3". A tester who sends in many requests per day finds she has difficulty keeping track of which request goes with which ID. She wishes that the original request were appended to the acknowledgement. Furthermore, she realizes that some customers will also generate many requests per day, so would also appreciate this feature. Would she:

什么是重要的 bug？对谁而言是重要的？直观的估计，答案肯定是“对于客户”。听到这个定义，几乎每个人都会点头称是，但他们确实这样认为吗？这里要测试一下你们组织的成熟度。假设你们的产品是一个接受电子邮件请求服务的系统。当收到请求时，它马上发送一个“您在97年5月12日发送的请求已经受理，参考ID是NIC -051297-3”的答复。一个每天发送很多请求的测试员发现要分清楚哪个请求与哪个ID对应是非常困难的。她希望最初的请求能够附加在确认邮件的后面。并且，她意识到某些可户可能每天也会产生很多请求，所以会高度评价这个功能的。那么她将：

1. file a bug report documenting a usability problem, with the expectation that it will be assigned a reasonably high priority (because the fix is clearly useful to everyone, important to some users, and easy to do)?

写一个 bug 报告，记录一个可用性问题，希望能够分配一个合理的高优先级（因为这个修复很明显对每个人都很用，对有部分用户来说还非常重要，并且也容易修改）？

2. file a bug report with the expectation that it will be assigned "enhancement request" priority and disappear forever into the bug database?

写一个 bug 报告，希望它被分配为“功能提升请求”优先级并永远从 bug 数据库中消失？

3. file a bug report that yields a "works as designed" resolution code, perhaps with an email "nastygram" from a programmer or the development manager?

写一个 bug 报告，产生一个“按设计工作”解决码，可能还加上一个来自程序员或开发经理的“不同意”电子邮件?

4. not bother with a bug report because it would end up in cases (2) or (3)?

不打算费事去写 bug 报告，因为它将以情况(2)或(3)结束？

If usability problems are not considered valid bugs, your project defines the testing task too narrowly. Testers are restricted to checking whether the product does what was intended, not whether what was intended is useful. Customers do not care about the distinction, and testers shouldn't either.

如果可用性问题不认为是有效的 bug，那么你们的项目将测试任务定义得太狭窄了。测试员严格限制为检查产品是否按预期工作，而不管这种预期是否有效。客户不关心这个区别，测试员也不应该关心。

Testers are often the only people in the organization who use the system as heavily as an expert. They notice usability problems that experts will see. (Formal usability testing almost invariably concentrates on novice users.) Expert customers often don't report usability problems, because they've been trained to know it's not worth their time. Instead, they wait (in vain, perhaps) for a more usable product and switch to it. Testers can prevent that lost revenue.

测试员经常是组织中唯一像专家一样大量使用系统的人。他们会注意到专家会看到的可用性问题。（形式上的可用性测试几乎不可避免地集中于没有经验的用户。）专家客户常常不会报告可用性问题，因为他们已经被训练的知道不值得花时间去这样做。相反，他们（也许是徒劳地）等待下一个可用的产品然后切换过去。测试员可以避免这个损失。

While defining the purpose of testing as "finding bugs important to customers" is a step forward, it's more restrictive than I like. It means that there is no focus on an estimate of quality (and on the quality of that estimate). Consider these two situations for a product with five subsystems.

将测试的目的定义为“找到对用户重要的 bug ”是向前进了一步，但与我所喜欢定义相比仍有限制。这意味着没有集中于质量评估（以及这种评估的质量）。考虑一下测试含有五个子系统的产品的两种情况。

1. 100 bugs are found in subsystem 1 before release. (For simplicity, assume that all bugs are of the highest priority.) No bugs are found in the other subsystems. After release, no bugs are reported in subsystem 1, but 12 bugs are found in each of the other subsystems.

在发布前，在子系统1中找到了100个bug 。（为了简单起见，假设所有的 bug 都是最高级别的。）在其他子系统中没有发现 bug 。在发布后，在子系统1中没有报告 bug ，但在其他每个子系统中都报告了12个 bug 。

2. Before release, 50 bugs are found in subsystem 1. 6 bugs are found in each of the other subsystems. After release, 50 bugs are found in subsystem 1 and 6 bugs in each of the other subsystems.

在发布前，在子系统1中找到了50个 bug 。在其他每个子系统中都找到了6个 bug 。在发布后，在子系统1中报告了50个 bug ，在其他每个子系统中都报告了6个 bug。

From the "find important bugs" standpoint, the first testing effort was superior. It found 100 bugs before release, whereas the second found only 74. But I think you can make a strong case that the second effort is more useful in practical terms. Let me restate the two situations in terms of what a test manager might say before release:

从“找到重要 bug”的观点看，第1种测试情况较为理想。在发布前找到了100个 bug ，但是第2种情况中只找到74个。但我想你们可能会提出一个有力的理由认为第2中测试在实际中更有用。让我以产品发版前测试经理可能说些什么来重新描述一下两种测试情况：

1. "We have tested subsystem 1 very thoroughly, and we believe we've found almost all of the priority 1 bugs. Unfortunately, we don't know anything about the bugginess of the remaining five subsystems."

“我们全面测试了子系统1，我们相信已经找出了几乎所有优先级为1的 bug。不幸的是，我们对其他五个子系统的的 bug 一无所知。”

2. "We've tested all subsystems moderately thoroughly. Subsystem 1 is still very buggy. The other subsystems are about 1/10th as buggy, though we're sure bugs remain."

“我们比较全面地测试了所有的子系统。子系统1仍旧有不少 bug。其他子系统虽然还有 bug，但只有子系统1的 bug 的十分之一。”

This is, admittedly, an extreme example, but it demonstrates an important point. The project manager has a tough decision: would it be better to hold on to the product for more work, or should it be shipped now? Many factors - all rough estimates of possible futures - have to be weighed: Will a competitor beat us to release and tie up the market? Will dropping an unfinished feature to make it into a particular magazine's special "Java Development Environments" issue cause us to suffer in the review? Will critical customer X be more annoyed by a schedule slip or by a shaky product? Will the product be buggy enough that profits will be eaten up by support costs or, worse, a recall?

必须承认，这是一个极端的例子，但是证明了一个重要的观点。项目经理有一个艰难的决定：是延迟产品交付，再工作一段时间，还是现在就交付使用？许多因素 ——都是一些大致的评估——都必须予以权衡：竞争对手会抢先发布产品并占领市场吗？如果丢掉一个未完工的功能部件会使得某一个杂志的 “Java 开发环境” 特别期刊的评论中对我们造成损害吗？关键客户 X 对产品延期和劣质产品哪一个更感到烦恼？产品是否有很多 bug，以至于支持成本会吃掉利润，或者更糟糕的是将产品召回？

The testing team will serve the project manager better if it concentrates first on providing estimates of product bugginess (reducing uncertainty), then on finding more of the bugs that are estimated to be there. That affects test planning, the topic of the next theme.

如果测试小组首先集中于产品错误的估计（减少不确定性），然后再找到更多的错误，他们会更好地服务于项目经理。这会影响测试计划。测试计划将在下个主题中论述。

It also affects status reporting. Test managers often err by reporting bug data without putting it into context. Without context, project management tends to focus on one graph:

测试工程师笔试集粹

【1】配置管理工具：ClearCase

【2】需求管理工具：Doors。IBM放弃了原来自己的需求分析工具RequirePro,因为收购的Doors是目前市场的第一，但是带来的问题是需要整Doors产品进入Rational产品线系列

【3】测试过程管理：RQM（Rational Quality Management），新研发产品，预计今年九月上市。目前IBM公司提供了一个中间产品，为CQTM，该产品与CQ（ClearQyest）是集成在一起的。

【4】缺陷和变更管理工具：ClearQuest

【5】手工测试管理工具：新研制的产品，RMT--Rational Manunal Testing,

【6】测试环境管理：RLM

【7】自动构建工具：BuildForge（收购产品）

【8】功能测试（黑盒测试）工具：RFT--Rational Function Testing，该产品与HP QTP相比，中国用户很少

【9】性能测试工具：RPT--Rational Performance Testing

【10】白盒测试工具，分为静态测试工具RSAR（收购产品，支持C和Java）和比较有名的动态测试工具Purify Plus和支持嵌入式测试的工具RTRT

【11】Web应用安全性测试：AppScan，收购前产品名称是WatchFire，能够扫描发现黑客侵入的漏洞等，应该比较有用。

而HP公司软件测试产品线包括：(惠普公司的测试产品线是收购了测试行业的领先公司Mercury而获得的)

【1】功能测试产品：QTP

【2】性能测试工具：LoadRunner

【3】测试管理工具：QC-Quality Center

【4】测试监测工具：Opsware（收购产品，该产品以HP IT管理Openview可以形成良好地互补）

 
会计业务知识

1 怎样根据会计业务的特点书写“摘要”？
      会计凭证中有关经济业务的内容的摘要必须真实。在填写“摘要”时，既要简明，又要全面、清楚，应以说明问题为主。写物要有品名、数量、单价；写事要有过程；银行结算凭证，要注明支票号码、去向；送存款项，要注明现金、支票、汇票等。遇有冲转业务，不应只写冲转，应写明冲转某年、某月、某日、某项经济业务和凭证号码，也不能只写对方科目。要求“摘要”能够正确地、完整地反映经济活动和资金变化的来龙去脉，切忌含糊不清.

    2 什么是凭证传递？凭证传递应注意哪些事项？

     会计凭证的传递，是指会计凭证从填制或取得时起，经审核、记帐到装订保管的全过程。各单位在制定会计凭证的传递程序，规定其传递时间时，通常要考虑以下两点内容：

(1)根据各单位经济业务的特点、企业内部机构组织、人员分工情况， 以及经营管理的需要，从完善内部牵制制度的角度出发，规定各种会计凭证的联次及其流程，使经办业务的部门及其人员及时办理各种凭证手续，既符合内容牵制原则，又提高工作效率。

(2)根据有关部门和人员办理经济业务的必要时间， 同相关部门和人员协商制定会计凭证在各经办环节的停留时间，以便合理确定办理经济业务的最佳时间，及时所映、记录经济业务的发生和完成情况。

3 怎样审核记帐凭证？

   有填制好的记帐凭证，都必须经过其他会计人员认真的审核。在审核记帐凭证的过程中，如发现记帐凭证填制有误，应按照规定的方法及时加以更正。只有经过审核无误后记帐凭证，才能作为登记帐簿的依据。记帐凭证的审核主要包括以下内容：

(1)记帐凭证是否附有原始凭证，记帐凭证的经济内容是否与所附原始凭证的内容相同。

(2)应借应贷的会计科目(包括二级或明细科目)对应关系是否清晰、金额是否正确。

(3)记帐凭证中项目是否填制完整，摘要是否清楚，有关人员的签章是否齐全。

4 怎样填制记帐凭证？

会计人员填制记帐凭证要严格按照规定的格式和内容进行，除必须做到记录真实、内容完整、填制及时、书写清楚之外，还必须符合下列要求：

(1)“摘要”栏是对经济业务内容的简要说明，要求文字说明要简炼、概括， 以满足登记帐簿的要求。

(2)应当根据经济业务的内容，按照会计制度的规定，确定应借应贷的科目。 科目使用必须正确，不得任意改变、简化会计科目的名称，有关的二级或明细科目要填写齐全。

(3)记帐凭证中，应借、应贷的帐户必须保持清晰的对应关系。

(4)一张记帐凭证填制完毕，应按所使用的记帐方法，加计合计数， 以检查对应帐户的平衡关系。

(5)记帐凭证必须连续编号，以便考查且避免凭证散失。

(6)每张记帐凭证都要注明附件张数，以便于日后查对。

5 会计凭证中的数字书写要求

(1)阿拉伯数字应一个一个地写，阿拉伯金额数字前应当书写货币币种符号(如人民币符号“￥”)或者货币名称简写和货种符号。 币种符号与阿拉伯金额数字之间不得留有空白。凡在阿拉伯金额数字前面写有币种符号的，数字后面不再写货币单位(如人民币“元”)。　(2)所有以元为单位(其他货币种类为货币基本单位,下同)的阿拉伯数字，除表示单价等情况外， 一律在元位小数点后填写到角分，无角分的，角、分位可写“00”或符号“－－”，有角无分的，分位应写“0”，不得用符号“－－”代替。(3)汉字大写金额数字，一律用正楷或行书书写，如壹、贰、叁、肆、伍、 陆、柒、捌、玖、拾、佰、仟、万、亿、元、角、分、零、整(正)等易于辩认、不易涂改的字样，不得用0、一、二、三、四、五、六、七、八、九、十、另、毛等简化字代替，不得任意自造简化字。(4)大写金额数字到元或角为止的,在“元”或“角”之后应写“整”或“正”字；大写金额数字有分的，分字后面不写“整”字。(5)大写金额数字前未印有货币名称的，应当加填货币名称（如“人民币”三字），货币名称与金额数字之间不得留有空白。(6)阿拉伯金额数字中间有“0”时，大写金额要写“零”字，如人民币101.50元， 汉字大写金额应写成壹佰零壹元伍角整。阿拉伯金额数字中间连续有几个“0”时，汉字大写金额中可以只写一个“零”字，如￥1004.56， 汉字大写金额应写成壹仟零肆元伍角陆分。阿拉伯金额数字元位为“0”，或数字中间连续有几个“0”，元位也是“0”，但角位不是“0”时，汉字大写金额可只写一个“零”字，也可不写“零”字。

6 怎样计算和填写所附原始的张数？

记账凭证一般应附有原始凭证，并注明其张数。凡属收、付款业务的记账凭证都必须有附件；职工出差借款的借据必须附在记账凭证上，收回借款时应另开收据或退还经出纳(收款人)签名的借款结算联；转账业务中，属于摊提性质的经济业务应有附件。附件的张数应用阿拉伯数字填写。

记账凭证张数计算的原则是：没有经过汇总的原始凭证，按自然张数计算，有一张算一张；经过汇总的原始凭证，每一张汇总单或汇总表算一张。例如某职工填报的差旅费报销单上附有车票、船票、住宿发票等原始凭证35张，35张原始凭证在差旅费报销单上的“所附原始凭证张数”栏内已作了登记，在计算记账凭证所附原始凭证张数时，这一张差旅费报销单连同其所附的35张原始凭证一起只能算一张。财会部门编制的原始凭证汇总表所附的原始凭证，一般也作为附件的附件处理，原始凭证汇总表连同其所附的原始凭证算在一起作为一张附件填写。但是，属收、付款业务的，其附件张数的计算要作特殊情况处理，应把汇总表及所附的原始凭证或说明性质的材料均算在其张数内，有一张算一张。

当一张或几张原始凭证涉及到几张记账凭证时，可将原始凭证附在其中一张主要的记账凭证后面，并在摘要栏内注明“本凭证附件包括××号记账凭证业务”字样，在其他有关记账凭证的摘要栏内注明“原始凭证附于××号记账凭证后面”的字样。

7 怎样处理记账凭证的附件？

在实际工作中记账凭证所附的原始凭证种类繁多，为了便于日后的装订和保管，在填制记账凭证的时候应对附件进行必要的外形加工。

过宽过长的附件，应进行纵向和横向的折叠。折叠后的附件外形尺寸，不应长于或宽于记账凭证，同时还要便于翻阅；附件本身不必保留的部分可以裁掉，但不得因此影响原始凭证内容的完整；过窄过短的附件，不能直接装订时，应进行必要的加工后再粘贴于特制的原始凭证粘贴纸上，然后再装订粘贴纸。原始凭证粘贴纸的外形尺寸应与记账凭证相同，纸上可先印一个合适的方框，各种不能直接装订的原始凭证，如汽车票、地铁车票、市内公共汽车票、火车票、出租车票等，都应按类别整齐地粘贴于粘贴纸的方框之内，不得超出。粘贴时应横向进行，从右至左，并应粘在原始凭证的左边，逐张左移，后一张右边压位前一张的左边，每张附件只粘左边的0.6一1厘米长，粘牢即可。粘好以后要捏住记账凭证的左上角向下抖几下，看是否有未粘住或未粘牢的。最后还要在粘贴单的空白处分别写出每一类原始凭证的张数、单价与总金额。

如某人报销差旅费，报销单后面的粘贴单附有0.5元的市内公共汽车票20张，1元的公共汽车票12张，285元的火车票1张，869元的飞机票1张，就应分别在汽车票一类下面空白处注明0.5×20＝10元，1×12＝12元，在火车票一类下面空白处注明285×1＝285元，在飞机票一类下面空白处注明869×1＝869元。这样，万一将来原始凭证不慎失落，也很容易查明丢的是那一种票面的原始凭证，而且也为计算附件张数提供了方便。

8 怎样保管会计凭证？

保证会计凭证的安全与完整是全体财会人员的共同职责，在立卷存档之前，会计凭证的保管由财会部门负责。保管过程中应注意以下问题：

（1）会计凭证应及时传递，不得积压。记账凭证在装订成册之前，原始凭证一般是用回形针或大头针固定在记账凭证后面，在这段时间内，凡使用记账凭证的财会人员都有责任保管好原始凭证和记账凭证。使用完后要及时传递，并且要严防在传递过程中散失。

（2）凭证在装订以后存档以前，要妥善保管，防止受损、弄脏、霉烂以及鼠咬虫蛀等。

（3）对于性质相同，数量过多或各种随时需要查阅的原始凭证，如收、发料单，工资卡等，可以单独装订保管，在封面上注明记账凭证种类、日期、编号，同时在记账凭证上注明“附件另订”和原始凭证的名称及编号。

（4）各种经济合同和涉外文件等凭证，

（5）原始凭证不得外借，其他单位和个人经本单位领导批准调阅会计凭证，要填写“会计档案调阅表”，详细填写借阅会计凭证的名称、调阅日期、调阅人姓名和工作单位、调阅理由、归还日期、调阅批准人等。调阅人员一般不准将会计凭证携带外出。需复制的，要说明所复制的会计凭证名称、张数，经本单位领导同意后在本单位财会人员监督下进行，并应登记与签字。

（6）会计凭证装订成册后，应由专人负责分类保管，年终应登记归档

9 怎样设置出纳日记账？

出纳日记账是一种特殊的明细账。为了加强现金和银行存款的管理和核算，各单位通常都应当设置现金日记账和银行存款日记账，以便逐日核算和监督现金与银行存款的收入、付出和结存情况。

现金日记账和银行存款日记账的账页一般采用三栏式（表略），即借方、贷方和余额三栏，分别反映现金或银行存款和收入、付出与结存情况，并在“摘要”栏后面设置“对方科目”栏。如果收、付款凭证数量较多，为了简化记账手续，同时也为了通过现金日记账和银行存款日记账汇总登记总账，也可以采用多栏式，即在收入和付出两栏中分别按照对方科目设置若干栏目，也就是在收入栏按贷方科目设栏目，在付出栏按借方科目设栏目。采用多栏式以后，如果会计科目较多，造成篇账过大，还可以分设现金(银行存款)收入日记账和现金(银行存款)支出日记账（表略）。

必须说明的是，现金日记账和银行存款日记账必须采用订本式账簿。不得用银行对账单或者其他方法代替日记账。

10 登记会计账簿的基本要求

依据《会计基础工作规范》第六十条规定（以下简称《规范》），登记会计账簿的基本要求是：

(1)准确完整。“登记会计账簿时，应当将会计凭证日期、编号、业务内容摘要、金额和其他有关资料逐项记入账内，做到数字准确、摘要清楚、登记及时、字迹工整。”每一项会计事项，一方面要记入有关的总账，另一方面要记入该总账所属的明细账。账簿记录中的日期，应该填写记账凭证上的日期；以自制的原始凭证，如收料单、领料单等，作为记账依据的，账簿记录中的日期应按有关自制凭证上的日期填列。登记账簿要及时，但对各种账簿的登记间隔应该多长，《规范》未作统一规定。一般说来，这要看本单位所采用的具体会计核算形式而定。

(2)注明记账符号。“登记完毕后，要在记账凭证上签名或者盖章，并注明已经登账的符号，表示已经记账。”在记账凭证上设有专门的栏目供注明记账的符号，以免发生重记或漏记。

(3)文字和数字必须整洁清晰，准确无误。在登记书写时，不要滥造简化字，不得使用同音异义字，不得写怪字体；摘要文字紧靠左线；数字要写在金额栏内，不得越格错位、参差不齐；文字、数字字体大小适中，紧靠下线书写，上面要留有适当空距，一般应占格宽的1/2，以备按规定的方法改错。记录金额时，如为没有角分的整数，应分别在角分栏内写上“0”，不得省略不写，或以“一”号代替。阿拉伯数字一般可自左向右适当倾斜，以使账簿记录整齐、清晰。为防止字迹模糊，墨迹未干时不要翻动账页；夏天记账时，可在手臂下垫一块软质布或纸板等书写，以防汗浸。

(4)正常记账使用蓝黑墨水。“登记账簿要用蓝黑墨水或者碳素墨水书写，不得使用圆珠笔(银行的复写账簿除外)或者铅笔书写。”在会计的记账书写中，数字的颜色是重要的语素之一，它同数字和文字一起传达出会计信息。如同数字和文字错误会表达错误的信息，书写墨水的颜色用错了，其导致的概念混乱也不亚于数字和文字错误。

(5)特殊记账使用红墨水。“下列情况，可以用红色墨水记账：①按照红字冲账的记账凭证，冲销错误记录；②在不设借贷等栏的多栏式账页中，登记减少数；③在三栏式账户的余额栏前，如未印明余额方向的，在余额栏内登记负数余额；④根据国家统一会计制度的规定可以用红字登记的其他会计记录。”

在这几种情况下使用红色墨水记账是会计工作中的惯例。财政部会计司编辑的《会计制度补充规定及问题解答(第一辑)》，在解答“应交税金——应交增值税”明细账户的设置方法时，对使用红色墨水登记的情况作了一系列较为详尽的说明：在“进项税额”专栏中用红字登记退回所购货物应冲销的进项税额；在“已交税金”专栏中用红字登记退回多交的增值税额；在“销项税额”专栏中用红字登记退回销售货物应冲销的销项税额，以及在“出口退税”专栏中用红字登记出口货物办理退税后发生退货或者退关而补交已退的税款。

(6)顺序连续登记。“各种账簿按页次顺序连续登记，不得跳行、隔页。如果发生跳行、隔页，更不得随便更换账页和撤出账页，作废的账页也要留在账簿中，如果发生跳行、隔页，应当将空行、空页划线注销，或者注明‘此行空白’、‘此页空白’字样，并由记账人员签名或者盖章。”这对堵塞在账簿登记中可能出现的漏洞，是十分必要的防范措施。

(7)结出余额。“凡需要结出余额的账户，结出余额后，应当在‘借或贷’等栏内写明‘借’或者‘贷’等字样。没有余额的账户，应当在‘借或贷’等栏内写‘平’字，并在余额栏内用‘0’表示。现金日记账和银行存款日记账必须逐日结出余额。”一般说来，对于没有余额的账户，在余额栏内标注的‘0’应当放在“元”位。

(8)过次承前。“每一账页登记完毕结转下页时，应当结出本页合计数及余额，写在本页最后一行和下页第一行有关栏内，井在摘要栏内注明‘过次页’和‘承前页’字样；也可以将本页合计数及金额只写在下页第一行有关栏内，并在摘要栏内注明‘承前页’字样。”也就是说，“过次页”和“承前页”的方法有两种：一是在本页最后一行内结出发生额合计数及余额，然后过次页并在次页第一行承前页；二是只在次页第一行承前页写出发生额合计数及余额，不在上页最后一行结出发生额合计数及余额后过次页。

(9)登记发生错误时，必须按规定方法更正，严禁刮、擦、挖、补，或使用化学药物清除字迹。发现差错必须根据差错的具体情况采用划线更下、红字更正、补充登记等方法更正。

(10)定期打印。《规范》第六十一条对实行会计电算化的单位提出了打印上的要求：“实行会计电算化的单位，总账和明细账应当定期打印”；“发生收款和付款业务的，在输入收款凭证和付款凭证的当天必须打印出现金日记账和银行存款日记账，并与库存现金核对无误。”这是因为在以机器或其他磁性介质储存的状态下，各种资料或数据的直观性不强，而且信息处理的过程不明，不便于进行某些会计操作和进行内部或外部审计，对会计信息的安全和完整也不利。

11 根据多栏式日记账登记总账情况下的账务处理方法

在根据多栏式现金日记账和银行存款日记账登记总账的情况下，账务处理可有如下两种做法：

第一种做法：由出纳人员根据审核后的收、付款凭证逐日逐笔登记现金和银行存款的收入日记账和支出日记账，每日应将支出日记账当日支出合计数，转记入收入日记账中支出合计栏中，以结算当日账面余额。会计人员应对多栏式现金和银行存款日记账的记录加强检查监督，并负责于月末根据多栏式现金和银行存款日记账各专栏的合计数，分别登记总账有关账户。

第二种做法：另外设置现金和银行存款出纳登记簿，由出纳人员根据审核后的收、付款凭证逐日逐笔登记，以便逐笔掌握库存现金收付情况，及时同银行核对收付款项；然后将收、付款凭证交由会计人员据以逐日汇总登记多栏式现金和银行存款日记账，并于月末根据多栏式日记账登记总账。出纳登记簿与多栏式现金和银行存款日记账要相互核对。

上述第一种做法可以简化核算工作，第二种做法可以加强内部牵制。总之，采用多栏式现金和银行存款日记账可以减少收款凭证的汇总编制手续，简化总账登记工作，而且可以清晰地反映账户的对应关系，了解现金和银行存款收付款项的来龙去脉。

12 会计工作中常见的差错类型有哪些？

会计工作中，经常遇到的差错种类很多，其主要表现在：记账凭证汇总表不平，总分类账不平，各明细分类账户的余额之和不等于总分类账有关账户的余额；银行存款账户调整后的余额与银行对账单不符等。在实际工作中常见的记录错误主要有以下三种：

（1）会计原理、原则运用错误。这种错误的出现是指在会计凭证的填制、会计科目的设置、会计核算形式的选用、会计处理程序的设计等会计核算的各个环节出现不符合会计原理、原则、准则规定的错误。例如，对规定的会计科目不设，不应设立的却乱设，导致资产、负债、所有者权益不真实；对现行财务制度规定的开支范围、标准执行不严等。

（2）记账错误。主要表现为漏记、重记、错记三种。错记又表现为错记了会计科目。错记了记账方向，错用了记账墨水(蓝黑墨水误用红水，或红水误用蓝黑墨水)，错记了金额等。

（3）计算错误。主要表现为运用计算公式错误；选择计算方法错误；选定计量单位错误等等。

13 怎样查找会计核算中的错误

在日常的会计核算中，发生差错的现象时有发生。如果发现错误：一是要确认错误的金额；二是要确认错在借方还是贷方；三是根据产生差错的具体情况，分析可能产生差错的原因，采取相应的查找方法，便于缩短查找差错的时间，减少查账工作量。

查找错误的方法有很多，现将常用的几种方法介绍如下：

（1）顺查法(亦称正查法)。顺查法是按照账务处理的顺序，从原始凭证、账簿、编制会计报表全部过程进行查找的一种方法。即首先检查记账凭证是否正确，然后将记账凭证、原始凭证同有关账簿记录一笔一笔地进行核对，最后检查有关账户的发生额和余额。这种检查方法，可以发现重记、漏记、错记科目、错记金额等。这种方法的优点是查的范围大，不易遗漏；缺点是工作量大，需要的时间比较长。所以在实际工作中，一般是在采用其他方法查找不到错误的情况下采用这种方法。

（2）逆查法(亦称反查法)。这种方法与顺查法相反，是按照账务处理的顺序，从会计报表、账簿、原始凭证的过程进行查找的一种方法。即先检查各有关账户的余额是否正确，然后将有关账簿按照记录的顺序由后向前同有关记账凭证或原始凭证进行逐笔核对，最后检查有关记账凭证的填制是否正确。这种方法的优缺点与顺查法相同。所不同的，是根据实际工作的需要，对由于某种原因造成后期产生差错的可能性较大而采用的。

（3）抽查法。抽查法是对整个账簿记账记录抽取其中某部分进行局部检查的一种方法。当出现差错时，可根据具体情况分段、重点查找。将某一部分账簿记录同有关的记账凭证或原始凭证进行核对。还可以根据差错发生的位数有针对性地查找。如果差错是角、分，只要查找元以下尾数即可；如果差错是整数的千位、万位，只需查找千位、万位数即可，其他的位数就不用逐项或逐笔地查找了。这种方法的优点是范围小，可以节省时间，减少工作量。

（4）偶合法。偶合法是根据账簿记录差错中经常遇见的规律，推测与差错有关的记录而进行查找的一种方法。这种方法主要适用于漏记、重记、错记的查找。

①漏记的查找。A．总账一方漏记，在试算平衡时，借贷双方发生额不平衡，出现差错，在总账与明细账核对时，会发现某一总账所属明细账的借(或贷)方发生额合计数大于总账的借(或贷)方发生额，也出现一个差额，这两个差额正好相等。而且在总账与明细账中有与这个差额相等的发生额，这说明总账一方的借(或贷)漏记，借(或贷)方哪一方的数额小，漏记就在哪一方。B．明细账一方漏记，在总账与明细账核对时可以发现。总账已经试算平衡，但在进行总账与明细账核对时，发现某一总账借(或贷)方发生额大于其所属各明细账借(或贷)发生额之和，说明明细账一方可能漏记，可对该明细账的有关凭证进行查对。C．如果整张的记账凭证漏记，则没有明显的错误特征，只有通过顺查法或逆查法逐笔查找。

②重记的查找。A．总账一方重记。在试算平衡时，借贷双方发生额不平衡，出现差错；在总账与明细账核对时，会发现某一总账所属明细账的借(或贷)方发生额合计数小于该总账的借(或贷)方发生额，也出现一个差额，这两个差额正好相等，而且在总账与明细账中有与这个差额相等的发生额记录，说明总账借(或贷)方重记，借(或贷)方哪一方的数额大，重记就在哪一方。B．如果明细账一方重记，在总账与明细账核对时可以发现。总账已经试算平衡，与明细账核对时，某一总账借(或贷)方发生额小于其所属明细账借(或贷)方发生额之和，则可能是明细账一方重记，可对与该明细账有关的记账凭证查对。C．如果整张的记账凭证重记账，则没有明显的错误特征，只能用顺查法或逆查法逐笔查找。

③记反账的查找。记反账是指在记账时把发生额的方向弄错，将借方发生额记入贷方，或者将贷方发生额记入借方。总账一方记反账，则在试算平衡时发现借贷双方发生不平衡，出现差额。这个差额是偶数，能被2整除，所得的商数则在账簿上有记录，如果借方大于贷方，则说明将贷方错记为借方；反之，则说明将借方错记为贷方。如果明细账记反了，而总账记录正确，则总账发生额试算是正确的，可用总账与明细账核对的方法查找。

④错记账的查找。在实际工作中，错记账是指把数字写错，常见的有两种：

第一种，数字错位，即应记的位数不是前移就是后移，即小记大或大记小。例如：把千位数变成了百位数(大变小)，把1600记成160(大变小)；或把百位数变成千位数(小变大)，把3．43记成243(小变大)。如果是大变小，在试算平衡或者总账与明细账核对时，正确数字与错误数字的差额是一个正数，这个差额除以9后所得的商与账上错误的数额正好相等。查账时如果差额能够除以9，所得商恰是账上的数，可能记错了位。如果是小变大，在试算平衡或者总账与明细账核对时，正确数与错误数的差额是一个负数，这个差额除以9后所得商数再乘以10，得到的绝对数与账上错误恰好相等。查账时应遵循：差额负数除以9，商数乘以10的数账上有，可能记错了位。

第二种，错记。错记是在登记账簿过程中的数字误写。对于错记的查找，可根据由于错记而形成的差数，分别确定查找方法，查找时不仅要查找发生额，同时也要查找余额。一般情况下，同时错记而形成的差数有以下几种情况：

一、邻数颠倒。邻数颠倒是指在登记账簿时把相邻的两个数字互换了位置。如43错记34，或把34错记43。如果前大后小颠倒为后大前小，在试算平衡时，正确数与错误数的差额是一个正数，这个差额除以9后所得商数中的有效数字正好与相邻颠倒两数的差额相等，并且不大于9。可以根据这个特征在差值相同的两个邻数范围内查找。 如果前小后大颠倒为前大后小，在试算平衡或者总账与明细账核算时，正确数与错误数的差额是一负数，其他特征同上。在上述情况下，查账时，差额能除以9，有效数字不过9，可能记账数颠倒，根据差值确定查找。

例如，某企业应收账款的总账科目余额合计数应为881.34，而明细账合计数为944.34，总账与明细账不等。有关明细账的资料如下表。

　　序 号 　　　　户 名 　　　金额(万元)

　　　1 　　　　　　A 　　　　　623.45

　　　2 　　　　　　B 　　　　　103.68

　　　3 　　　　　　C 　　　　　45.79

　　　4 　　　　　　D 　　　　　81.18

　　　5 　　　　　　E 　　　　　90.24

　　合 计 　　　　　　　　　　　944.34

　　查找步骤：

第一，求正误差值：881.34—944.34＝－63万元。

第二，判断差值可否用9整除，差值63，正好可以为9整除(63万元／9＝7万元)。

第三，求差值系数：-63／9＝-7。

第四，在错误表中查找有无相邻两数相差为7的数字。差值系数为负值时，查前大后小；反之，查前小后大。经查，该表中第4行“81.18”中的“8”-“1”＝7，前大后小。可以判断为属于数字倒置的错误，即可能是18.18而误写为81.18。

第五，将第4行按18.18更正，重新加总，其合计数则为881.34，与总账一致。

二、隔位数字倒置。如：425记成524，701记成107等等，这种倒置所产生的差数的有效数字是三位以上，而且中间数字必然是9，差数以9除之所得的商数必须是两位相同的数，如22，33，34……。商数中的1个数又正好是两个隔位倒置数字之差。如802误记208元，差数是594，以9除之则商数为66，两个倒置数8与2的差也是6。于是可采用就近邻位数字倒置差错的查找方法去查找账簿记录中百位和个位两数之差为6的数字，即600与006、701与107、802与208、903与3O9四组数，便可查到隔位数字倒置差错。

采用上述方法时，要注意：一是正确选择作为对比标准的基数；二是保证对比指标口径的可比性；三是同时分析相对数和绝对数的变化，并计算其对总量的影响。

出纳人员在日常填制会计凭证和登记账簿过程中，可能出现一些差错，切忌生搬硬套，要从具体的实际工作出发，灵活运用查找的方法，有时还要几种方法结合起来并用，通过反复核实，一定会得出正确的结果.

14 什么是对账？对账的主要内容有哪些？

对账就是核对账目。按照《会计基础工作规范》的要求，各单位应当定期将会计账簿记录的有关数字与库存实物、货币资金、有价证券往来单位或个人等进行相互核对，保证账证相符、账账相符、账实相符，对账工作每年至少进行一次。就出纳工作而言，对账的主要内容是：

(1)账证核对。核对会计账簿记录与原始凭证、记账凭证的时间、凭证字号、内容、金额是否一致，记账方向是否相符。

(2)账账核对。核对不同会计账簿记录是否相符。包括：总账有关账户的余额核对；总账与明细账核对；总账与日记账核对等。

(3)账实核对。核对会计账簿记录与财产等实有数额是否相符。包括：现金日记账账面余额与现金实际库存数核对；银行存款日记账账面余额与银行对账单核对；各种应收、应付款明细账账面余额与有关债务、债权单位或者个人核对等。

15 结账的一般程序？

结账，是在把一定时期内发生的全部经济业务登记入账的基础上，计算并记录本期发生额和期末余额。《会计基础工作规范》规定的结账程序及方法是：

(1)结账前，必须将本期内所发生的各项经济业务全部登记入账。

(2)结账时，应当结出每个账户的期末余额。需要结出当月发生额的，应当在摘要栏内注明“本月合计”字样，并在下面通栏划单红线。需要结出本年累计发生额的，应当在摘要栏内注明“本年累计”字样，并在下面通栏划单红线；12月末的“本年累计”就是全年累计发生额，全年累计发生额下应当通栏划双红线，年度终了结账时，所有总账账户都应当结出全年发生额和年末余额。

(3)年度终了，要把各账户的余额结转到下一会计年度，并在摘要栏注明“结转下年”字样；在下一会计年度新建有关会计账簿的第一余额栏内填写上年结转的余额，并在摘要栏注明“上年结转”字样。