前几天在测公司的外包项目（欧美）的时候，浏览器总是提示无法连接站点，于是下意识的用Ping来判断是否连通。刚开始以为是那边站点出了问题，但是其他人却能够正常访问，虽然公司内网有时不稳定，但也不至于长时间啊。由于需要亲自跑到机房重启“小锚”（路由的配置IP公司是保密的），次数多了也嫌麻烦（本人也不算很勤劳的那类人）。心想要是能有个工具来判断是否内网/外网问题，我也好偷个懒少走点冤枉路。哈哈，终于今天让我给找到了，就是dos下的命令Tracert（跟踪路由），顺便也把它给了解个透彻。

r o8x`'Dta7f,e-{E136894

 

T/ks2^O!O E136894

Tracert（跟踪路由）是路由跟踪实用程序，用于确定IP数据报访问目标所采取的路径。Tracert命令用IP生存时间(TTL)字段和ICMP错误消息来确定从一个主机到网络上其他主机的路由。

R c"|J(R![&L9i3j136894

 51Testing软件测试网KL$Ke o~/\ N

原理：51Testing软件测试网-E0Eu/O
c&[

 51Testing软件测试网3?XW"Q \rB

通过向目标发送不同IP生存时间(TTL)值的“Internet控制消息协议(ICMP)”回应数据包，Tracert诊断程序确定到目标所采取的路由。要求路径上的每个路由器在转发数据包之前至少将数据包上的TTL递减1。数据包上的TTL减为0时，路由器应该将“ICMP已超时”的消息发回源系统。

LT$m4Au136894

Tracert先发送TTL为1的回应数据包，并在随后的每次发送过程将TTL递增1，直到目标响应或TTL达到最大值，从而确定路由。通过检查中间路由器发回的“ICMP已超时”的消息确定路由。某些路由器不经询问直接丢弃TTL过期的数据包，这在Tracert实用程序中看不到。51Testing软件测试网&sNM:AJ G#bgG

Tracert命令按顺序打印出返回“ICMP已超时”消息的路径中的近端路由器接口列表。如果使用-d选项，则Tracert实用程序不在每个IP地址上查询DNS。

bw[p? Y136894

 

|'Yc Y-Bm136894

 

(}mJmW+[136894

Sample：

%XT@9P(g3P~q136894

 

m bj&@,Bb
?/o136894

数据包必须通过7个路由器才能到达主机218.1.64.33。主机的默认网关是10.10.1.252，218.1.0.0网络上的路由器也有3个，最后一个IP地址是目标地址。

W6Ku3U ?~5q$k136894

 51Testing软件测试网c&m,tQ YmL

:dX!C8Ap-H&J-HT136894

 51Testing软件测试网"@m0u
br#`U/F8H2_

 

:[.wa.q4@/c,m0{136894

Tracert命令的help：51Testing软件测试网D&O3[W:Cc/p6[ E

 

v(dn*LCU*uI136894

j"J&A"pl@136894

 

JN,M;{ ~136894

参数中文描述：51Testing软件测试网YRkW!FXl

 51Testing软件测试网H&fTcJ
v{

（1）Do not resolve addresses to hostnames.（指定不将IP地址解析到主机名称）

8rBtyM'YK136894

（2）Maximum number of hops to search for target.（指定跃点数以跟踪到称为target_name的主机的路由）

;P5G }caQsN0t136894

（3）Loose source route along host-list (IPv4-only).（指定Tracert实用程序数据包所采用路径中的路由器接口列表）51Testing软件测试网Ya w$v0aZ

（4）Wait timeout milliseconds for each reply.（等待timeout为每次回复所指定的毫秒数）51Testing软件测试网`:H7s }/]i

51Testing软件测试网?(Y@Ms2Jo

（5）target_name目标主机的名称或IP地址

!FUx2x6Ic:u}136894

|Dw"X(WZ q136894

使用经验：51Testing软件测试网n#ss2N Ct?/w {0d

 

m3a }.}q1o3S0H136894

（1）Tracert对于解决大网络问题非常有用，此时可采取几条路径到达同一个目标。51Testing软件测试网(R0C-?4L3U`3H`-bQ7X

（2）Tracert也能够确定数据包在网络上的停止位置。如果从网关处报错（网关reports:Destination net unreachable.）,这可能是路由器配置的问题，或者是目标网络不存在（错误的IP地址）。51Testing软件测试网F&x;b U
WOaD(Ai3_

（3）另外，如果需要通过网络来测试远端Web系统，一旦网络出现问题，Tracert可以很快地缩小网络故障的范围。

|Q;y(HgeF1_6s136894

 51Testing软件测试网7}-g5ip5P8n#g6?;Tp

译文
    web网站本质上带有web服务器和客户端浏览器的C/S结构的应用程序。主要考虑web页面、TCP/IP通讯、Internet链接、防火墙和运行在web页面上的一些程序（例如，applet、javascrīpt、应用程序插件），以及运行在服务器端的应用程序（例如，CGI脚本、数据库接口、日志程序、动态页面产生器，asp等）。另外，因为服务器和浏览器类型很多，不同版本差别很小，但是表现出现的结果却不同，连接速度以及日益迅速的技术和多种标准、协议。使得web测试成为一项正在不断研究的课题。其它要考虑的如下：

1、服务器上期望的负载是多少（例如，每单位时间内的点击量），在这些负载下应该具有什么样的性能（例如，服务器反应时间，数据库查询时间）。性能测试需要什么样的测试工具呢（例如，web负载测试工具，其它已经被采用的测试工具，web 自动下载工具，等等）？

2、系统用户是谁？他们使用什么样的浏览器？使用什么类型的连接速度？他们是在公司内部（这样可能有比较快的连接速度和相似的浏览器）或者外部（这可能有使用多种浏览器和连接速度）？

3、在客户端希望有什么样的性能（例如，页面显示速度？动画、applets的速度等？如何引导和运行）？

4、允许网站维护或升级吗？投入多少？

5、需要考虑安全方面（防火墙，加密、密码等）是否需要，如何做？怎么能被测试？需要连接的Internet网站可靠性有多高？对备份系统或冗余链接请求如何处理和测试？web网站管理、升级时需要考虑哪些步骤？需求、跟踪、控制页面内容、图形、链接等有什么需求？

6、需要考虑哪种HTML规范？多么严格？允许终端用户浏览器有哪些变化？

7、页面显示和/或图片占据整个页面或页面一部分有标准或需求吗？

8、内部和外部的链接能够被验证和升级吗？多久一次？

9、产品系统上能被测试吗？或者需要一个单独的测试系统？浏览器的缓存、浏览器操作设置改变、拨号上网连接以及Internet中产生的“交通堵塞”问题在测试中是否解决，这些考虑了吗？

10、服务器日志和报告内容能定制吗？它们是否被认为是系统测试的主要部分并需要测试吗？

11、CGI程序、applets、javascrīpts、ActiveX 组件等能被维护、跟踪、控制和测试吗？

原文：

How can World Wide Web sites be tested?
Web sites are essentially client/server applications - with web servers and 'browser' clients. Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascrīpt, plug-in applications), and applications that run on the server side (such as cgi scrīpts, database interfaces, logging applications, dynamic page generators, asp, etc.). Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort. Other considerations might include:

• What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?
• Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
• What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?
• Will down time for server and content maintenance/upgrades be allowed? how much?
• What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?
• How reliable are the site's Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing?
• What processes will be required to manage updates to the web site's content, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
• Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?
• Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??
• How will internal and external links be validated and updated? how often?
• Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet 'traffic congestion' problems to be accounted for in testing?
• How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?
• How are cgi programs, applets, javascrīpts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?

 

　在软件系统日益复杂的今天，性能已经成为软件质量的重要衡量标准之一，这一点尤其体现在和WEB相关的系统上。接下来介绍一些WEB性能测试中的术语，这些术语都是WEB性能测试中出现频繁的比较高的词汇，只有掌握这些基础的性能知识才可以进一步开展测试工作。这些术语主要有并发用户，并发用户数量，请求响应时间，事务响应时间，吞吐量，吞吐率，TPS，点击率，资源利用率等。

　　并发用户：并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。

　　另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。

　　可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。

　　用户并发数量：关于用户并发的数量，有2种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，但是，在线用户数量是计算并发用户数量的主要依据之一。

　　请求响应时间：指的是客户端发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被成为"TLLB"，即"Time to last byte",意思是从发起一个请求开始，到客户端接收到最后一个字节的响应时间所耗费的时间。请求响应时间过程的单位一般为"秒"或者"毫秒".

　　事务响应时间:事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数.

　　吞吐量:指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.

　TPS:每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.

　　点击率:每秒钟用户向WEB服务器提交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求.

　　资源利用率:指的是对不同的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,因此是WEB性能测试工作的重点.

　　资源利用率主要针对WEB服务器,操作系统,数据库服务器,网络等,是测试和分析瓶颈的主要参考.在WEB性能测试中,更根据需要采集相应的参数进行分析.

网站测试流程、要求及测试报告

　　一个网站基本完工后，需要通过下面三步测试才可以交活。

　　一、 制作者测试，包括美工测试页面、程序员测试功能。在做完后第一时间内有制作者本人进行测试。

　　a) 页面 包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;图片上有没有错别字;各连接是否是死连接;各栏目图片与内容是否对应等。

　　b) 功能 达到客户要求;数据库连接正确;各个动态生成连接正确;传递参数格式、内容正确;试填测试内容没有报错;页面显示正确。

 

　二、 全面测试 根据交工标准和客户要求，由专人进行全面测试

　　也是包括页面和程序两方面，而且要结合起来测，保证填充足够的内容后不会导致页面变形。另外要检查是否有错别字，文字内容是否有常识错误。

　三、 发布测试 网站发布到主服务器之后的测试，主要是防止环境不同导致的错误

    软件缺陷的原则

　　软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等。
 
　　软件未达到产品说明书标明的功能。

　　软件出现了产品说明书指明不会出现的错误。

　　软件功能超出产品说明书指明范围。
 
　　软件未达到产品说明书虽未指出但应达到的目标。

　　软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

 

软件开发生命周期包含需求、设计、编码和测试四个过程阶段,其中需求过程是第一个也是最重要的一个阶段。软件需求包括三个不同的层次:业务需求，说明了提供给客户和产品开发商的新系统的利益,反映了组织机构或客户对系统、产品高层次的目标要求，它们将在项目视图与范围文档中予以说明;用户需求，描述了用户使用系统必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明;功能需求和非功能需求，定义了开发人员必须实现的软件功能，使得用户能顺利完成他们的任务，从而满足了业务需求。

　软件需求过程包括了5个主要活动：需求获取、需求分析和确认、编写需求规格说明书、需求验证和需求管理。

　需求获取

　需求的收集、分析、细化、核实并组织的步骤，并将它编写成文档。这个活动包括了编写项目视图和范围文档、用户群分类、选择用户代表、建立核心队伍、确定使用实例、召开联合会议、分析用户工作流程、确定质量属性、检查问题报告和需求重用10个具体任务，文章将在后面进行详细的阐述。

　需求分析

　根据需求获取中得到的需求文档，分析系统实现方案。这个活动需要完成下面几个任务：
　　
　   1、绘制关联图，用于定义系统与系统外部实体间的边界和接口的简单模型；

　2、创建开发原型，当开发人员或用户不能明确某些需求时，开发一个系统原型，这样使得许多概念和可能发生的事更为直观明了；

　3、分析可行性，在允许的成本、性能要求下，分析每项需求实施的可行性，明确每项需求实现相联系的风险，包括与其它需求的冲突，涉及各类用户的利益平衡，对外界因素的依赖和技术障碍；

　4、确定需求优先级：分析方法来确定使用实例、系统特性或单项需求实现的优先级别，以优先级为基础确定产品版本将包括哪些特性或哪类需求；

　5、为需求建立模型，为需求建立图形分析模型是软件需求规格说明极好的补充说明，可以为系统需求从多个角度建模；

　6、编写数据字典，创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义；

　7、应用质量功能调配，将系统特性、属性与对客户的重要性联系起来，提供了一种分析方法以明确哪些是客户最为关注的特性。
　编写需求规格说明书

　需求开发的最终成果是客户和开发小组对将要开发的产品达成一致协议，这一协议就是通过文档化的需求规格说明书来体现。需求规格说明书包括项目视图和范围文档说明了系统的业务需求，而使用实例文档则说明了用户需求。这个活动需要完成下面几个任务：

　1、采用模版,在你的组织中要为编写软件需求规格说明书等文档定义一种标准模板,该模板为记录系统需求和各种其它与需求相关的重要信息提供了统一的结构；

　2、指明需求来源，为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要能追溯每项需求的来源，来源可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源，这些来源应该记录在需求的跟踪能力矩阵中；

　3、为每项需求注上标号，为了需求的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求，为制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号;

　4、记录业务规范，是指关于系统的操作原则，比如谁能在什么情况下采取什么动作,将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档;

　5、创建需求跟踪能力矩阵，建立一个矩阵把每项需求来源、定义与实现、测试它的设计和代码部分联系起来,这样有利于需求的管理和需求变更影响范围的评估。

　需求验证

　需求的验证是为了确保需求说明准确、完整，表达必要的质量特点,需求将要作为系统设计和最终验证的依据,因此一定要保证它的正确性。需求验证务必确保符合完整性、正确性、灵活性、必要性、无二义性、一致性、可跟踪性及可验证性这些良好特征。这个活动需要完成下面几个任务：

　1、审查需求文档，对需求文档进行正式审查是保证软件质量的有效的方法。组织一个由不同代表（如用户，分析人员，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查；

　2、依据需求编写测试用例，根据用户需求所要求的产品特性写出系统的功能测试用例作为系统测试依据；

　3、编写用户手册，在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析;

　4、确定合格的标准，需求说明中描述什么样的产品才算满足用户的要求和适合他们使用的，将合格的测试建立在使用情景描述或使用实例的基础之上。

　需求管理

　需求管理是组织、控制和文档化需求的系统方法，也是一种建立和维护用户和开发组织对于改变系统功能的协议。需求开发的结果经验证批准就定义了开发工作的需求基线,这个基线在客户和开发人员之间就构筑了一个需求约定，需求管理包括在项目进展过程中维持需求约定一致性和精确性的活动。现在很多商业化的需求管理工具都能很好的支持需求管理活动。这个活动需要完成下面几个任务：

　1、确定变更控制过程,确定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此流程;

　2、建立软件变更控制委员会(SCCB，Software Change Control Board),组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来评估和确定需求变更;

　3、进行变更影响分析,评估需求变更对项目进度、资源、工作量和项目范围以及其它需求的影响;

　4、跟踪变更影响的产品,当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计文档、源代码和测试用例，这些相关部分可能也需要修改；

　5、建立基准和控制版本,需求文档确定一个基线，这是一致性需求在特定时刻的快照，之后的需求变更就遵循变更控制过程即可;

　6、维护变更的历史记录,记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等情况;

　7、跟踪每项需求的状态,这里状态包括"确定"、"已实现"、"暂缓"、"新增"、"变更"　等。建立一个数据库，其中每一条记录记录一项需求;

　8、衡量需求稳定性,记录基线需求的数量和每周或每月的变更（添加、修改、删除）数量。

　需求获取是在问题及其最终解决方案之间架设桥梁的第一步，是软件需求过程的主体。一个项目的目的就是致力于开发正确的系统，要做到这一点就要足够详细地描述需求，也就是系统必须达到的条件或能力，使用户和开发人员在系统应该做什么，不应该做什么方面达成共识。我们都知道开发软件系统最为困难的部分就是准确说明开发什么，最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。

　获取需求就是为了解决这些问题，它必不可少的成果就是是对项目中描述的用户需求的普遍理解，一旦理解了需求，分析者、开发者和用户就能探索出描述这些需求的多种解决方案。这一阶段的工作一旦做错，将最终会给系统带来极大损害的部分，由于需求获取事物造成的对需求定义的任何改动，都将导致设计、实现和测试上的大量返工，而这时花费的资源和时间将大大超过仔细精确获取需求的时间和资源。

工作生活当中，要做到细心，功夫往往在细心之外。首先要集中精力，重视眼前，重视当下所从事的工作和事务，把手上每件事情处理圆满，才能把握生命的内核，拥有充实愉快的生活。

其次需要排除干扰，稳定情绪。每个人的心理能量都是有限的，如果过多杂务干扰，心绪烦乱，情绪不稳，我们就容易注意力涣散，就很难做到全神贯注。要真正做到细心谨慎，必然要处理好自身的各种心理困惑，保持一颗平静的心，正所谓“宁静而致远”。

做一个细心的人，关键还在于赋予自己责任感，切实用心。任何事情，都是事在人为。同样一件事，敢负责任，良苦用心，就可能成就一篇杰作，如果毫不在乎，不当回事，就可能竹篮打水一场空。只要能够负起责任，油然而生一种神圣的责任感和使命感，就有可能激发我们全部的智慧，调动我们无穷的潜力。因此从这个意义上说，细心很大程度上依赖于责任心。

最后，还需要培养兴趣，人尽其才。我们深知，一旦自己对于某事有了浓厚兴趣，常能乐此不疲，流连忘返，也就能够精心钻研、细心考量。如果缺乏兴趣，就容易心猿意马、朝三暮四，难以做到持久的静心、细心，更不可能保持足够的耐心。

细心有度

当然，过分的细心，过于严肃认真到了谨小慎微的程度，将会成为各种心理障碍，尤其是强迫症的温床。因为盲目夸大，草木皆兵，会使本来脆弱的神经难以驾驭理性，甚至面临崩溃，因而要把握好细心的“度”，做到灵活性与原则性的完美结合。

“千里之堤，溃于蚁穴”，粗心会带给我们无尽烦恼。我们应当在生活中培养细心的素质，成为生活的有心人，留住更多美好瞬间。细心作为，细心行动，就会让我们收获更多成功与效益，感受更多安全与保障。

在大家懵懵懂懂之中，踏入测试大军的那一刻起，想来都曾经看过或者说都曾经被问过：身为一个测试人员，需要具备什么素质？测试员的责任是什么？

　　在从事了n久的测试工作之后，很多人在坚守着自己当初对这个行业许下的诺言。也有些人，终日混在开发人员堆里的（这个几率很大），渐渐的就如被火烫伤过的猫一样，收回了自己的利牙和尖爪，他们和开发人员一起，“各管一片”，只是应对着某一个小小的问题。在测试中，即使发现了别的问题，也会因为这个问题跟这次测试的主要目的不同而“ 视而不见”。。

　　这样的测试到底对不对？自己以前的思维到底对不对？

　　我近来常常在思索这个问题。

　　一个成规模的测试团队，却因为其中有偶尔的几个有过编程经验，可以帮助开发人员去fix issue的人而得益。这是怎样一个团队？一个测试人员，不从如何提高自己的测试水平出发去努力，而是努力的如何去跟开发人员搞好关系（我不是说不重要），如何去游说周边的人，开发人员修改一个问题或者发布一个版本的辛苦。。这是怎样的一个团队？

　　我无语。。

　　无论如何难解。我还是坚定地认为，测试人员应该首先看清自己的责任。应该明白什么叫做测试的机会和测试的成本。应该懂得如何在发现issue的第一时间来报告和促使解决这个问题。

　　这些都是最基本的知识，确实在现实生活中，尤其在这样的开发和测试团队中最难做到的。。

　　我相信，终有一刻，终有一日，坚守的会开发结果。放弃原则的，夹缝中的人，会无处藏身。。

　　记住测试人员的责任：站在客户的角度，尽早的找出bug,并且促使其修复。

　　 好的测试工程师应具备的素质

　　+p7Eip:D UU94816人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。然而，在软件开发产业中有一种非常普遍习惯，那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。这绝对是一种目光短浅的行为，对一个系统进行有效的测试所需要的技能绝对不比进行软件开发需要的少，事实上，测试者将获得极其广泛的经验，他们将遇到许多开发者不可能遇到的问题。

　　1.沟通能力。

　　一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

　　2.移情能力。

　　和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人都具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。

　　3.技术能力。

　　就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

　　4.自信心。

　　开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

　　5.外交能力。

　　当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

　　6.幽默感。

　　在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

　　7.很强的记忆力。

　　一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

　　8.耐心。

　　一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。

　　9.怀疑精神。

　　可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

　　10.自我督促。

　　干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

　　11.洞察力。

　　一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

作为一名测试新人加入团队，大多数情况下，项目组成员都是一种热情欢迎的态度，并且主动提供力所能及的支持和帮助，如何快速熟悉项目业务和测试环境，尽快投入到实际工作中去，我谈谈个人的经验和一些看法，供同行参考：

1、寻找新公司的团队元老：

  一般来说，一个新人进入新公司，都要指定一个师傅带一段时间，这也就是我们说的测试前辈。很多时候，测试前辈都是经验非常丰富的测试高人，如何您和他相处融洽，关系不错，凭他个人丰富的业务经验，给您指点迷津，也许会比你自己摸索10倍的时间效果还好。很多的测试新手，刚进入新公司时，自高自大，眼高收低，测试前辈都不愿意交，结果到了试用期转正答辩的时候，一问三不知，被迫离开公司，被炒鱿鱼。这样的例子我看到的不下于10例，很可惜丢失了很多工作机会。

2、虚心的学习态度：

刚到一家新公司，保持谦虚的学习态度非常必要。记得我刚毕业那年，公司招聘了一个测试主管，他有4到5年的工作经验，阅历算是不简单，也是我们心目中的牛人吧。但是那个人，除了听总监的话以外，对于我们部门的其它人来说，他简直是自高自大，目中无人，根本不把部门里的其他人放到眼里，觉得部门的人都不如他。他作为一个空降兵，老员工和新员工，对他都很冷漠，碰到什么问题，需要小组成员帮忙的时候，大家都不愿意帮助他，互相推诿，并且经理也找他谈了几次话，效果不明显，结果他呆了不到2个月，估计是自己觉得很不开心，被迫离开了公司。其实，保持低姿态，谦虚的学习态度，必不可少。

3、阅读项目相关的文档：

  一般来说，新人一到公司，就会安排到项目中去。作为测试新手，快速阅读相关的“需求文档”、“详细设计文档”和“用户手册”特别关键。我们能够通过需求规格说明书等文档，快速熟悉系统相关的知识，获取编写测试文档的相关信息。如果项目已经编好了用户手册，您完全可以根据文档的步骤，一步一步傻瓜式的熟悉每项功能。只有掌握的这些文档的精髓，测试才会变得异常轻松呀。

4、快速熟悉项目相关业务知识：

刚到新公司的测试人员，如果你是跳槽到以前做过的相近行业，有丰富的经验了，那么您熟悉业务没什么大的问题。如果您换的新公司是您以前都没有接触到的行业，那你一定得努力一点，买些相关的业务知识看看非常必要。我深有体会，以前从一家“通讯公司”跳槽到做“银行系统”的公司，业务完全两样，很多业务知识都是从零开始。不过有一定的工作经验，学习起来也挺快，关键取决于个人是酷爱学习和坚强的学习毅力。

5、尽快介入了解被测试系统：

   刚跨入一家新公司，如果被测试系统已经开发的差不多了，部分功能已经OK了。你可以部署到测试环境下，尝试从直观测试的角度去尽快了解系统，尽快结合文档熟悉起来。很多的时候，通过页面操作实际的系统比看文档效果好的多，并且印象更深刻，熟悉系统更快。新加入公司的朋友不防试一试。

6、了解公司类似的相关产品：

    大多数的公司，都不可能在每个行业都非常强，基本上都是在某一个较小的领域很强势，公司主要就是研发强势相关业务的产品。所以说，相关的产品一般来说是很多的，如果要你测试的系统没有开发完毕，如果时间和条件允许，不妨先了解一下公司类似的产品，以便尽快熟悉起来。大多数情况下，公司很多的产品都是相通的，大部分的产品是在不同的客户要求下，修改了部分功能和界面而已。个人认为：了解类似的产品，也是测试新手快速熟悉产品的一条捷径。

7、尽量多参加项目的各种会议：

    每个项目，特别是在项目的启动阶段，大会小会不断，很多时候项目组成员抱怨居多，都认为很浪费时间，耽误开发进度。如果作为测试新手的您这个时候加入，那太好了，多参加这样的讨论会。大部分时间都是在讨论项目的重点和关键，如果大家意见不一致，必然要对不一致的东西展开细节讨论，您肯定是收益匪浅。特别是对业务方面的讨论，您参加几次讨论，比您看10篇需求还强，并且理解也很透彻。如果您对需求有所了解，但是部分功能模块还有问题，就可以在讨论会上随时提出来，大家一起讨论，共同解决。如果有这样的机会，切勿放弃哟。

8、阅读类似项目已有的测试用例：

   如果项目已经启动并进入了测试阶段，如果你在这个时候介入，通常情况下负责人都会给你提供整个项目或部分需要你测试的部分模块的测试用例。这些测试用例也是您快速上手测试的重要参考资料。如果还没有编写测试用例，你就介入了，那你就得重头开始，您可以阅读项目类似的测试用例，并结合以前项目的测试经验，根据公司相关的测试用例模板开始编写测试用例。如果在编写测试用例中碰到您不了解和很难处理的问题，您可以记入测试需求疑问表格，等部门开会时，提出来大家讨论。最好不要碰到一个问题就去问，经常打乱人家的思路，弄得别人嫌烦，那就不值了。

9、查看缺陷数据库中旧有的缺陷：

   一般的测试缺陷跟踪系统，都是按模块来分类软件缺陷的。如果老大给你分配了测试任务，你就可以有目的的去熟悉即将测试的模块缺陷。登录系统后，对缺陷进行筛选，尝试按测试前辈的Bug描述步骤进行操作，看看是否能够重新缺陷？这种方法能够借鉴测试同行的经验，尽快发现问题，避免测试的盲目性。一来可以拓宽您的视野，避免递交类似问题的Bug或是重复的Bug，二来还可以为您快速熟悉被测试系统添砖加瓦。

10、必须明白自己领导是谁：

   一般的员工进入公司，公司和部门领导很多，搞不清楚谁管我，碰到问题问谁？谁可以帮忙解决问题？如果真是这样那就麻烦了。部门领导臃肿的情况实在是太多了，有的公司，既有2测试经理，又有几个测试主管，还有多个项目经理和研发总监，不知道工作向谁回报，对哪个领导负责。弄得每个领导都回报，很累呀！！我的做法是：测试项目中负责领导只有一个那就是测试主管，测试主管负责安排和分配每个测试人员的工作和任务，我直接Review测试主管。如果项目中碰到有什么解决不了的问题，组内成员可以直接找我，同时我也定期加入项目参加部分测试，了解测试项目的一些进展情况，必要时还要找一些人谈心。这样，工作汇报比较简单明了，很轻松。

11、熟悉与测试相关的管理软件的使用：

  我说的这个测试相关的软件包括缺测试需求管理软件（如TestDirector或QC）、陷跟踪管理软件（如：TestTrack Pro、TestDirector等等）、版本配置管理工具软件（CVS、VSS，还是SVN等等），具体熟悉到什么程度，那就要看您的职位了。如果您是一般的工程师，那你就只了解一般的使用就够了，如果您是测试经理，您不仅要了解一般的使用，还要更深层次的了解软件的权限和项目的配置，因为您要作为该软件的Admin，碰到问题大部分都由您搞定呀，高工资不是那么好拿的呀，哈哈！！！如果作为新入职的您，连这些都不会，那你就得加把油了，不然到了测试启动阶段，你才开始熟悉管理软件，那么你觉的能够快速展开测试吗？

12、注意沟通技巧，把握请教良机：

  为了尽快熟悉项目，展开测试工作，沟通技巧必不可少。您作为新入职的测试人员，尽量了解每个开发人员开发的模块和每个开发人员的性格特点，寻找一些共同语言，拉近与开发人员的距离，让他们对您产生好感。只有这样，当您碰到问题的时候，他们才会鼎立的帮助您。如果您与开发人员关系不好，看了就觉的很讨厌，那他们肯定不会帮助您的，更不原意和您配合，当您提错Bug的时候，他们就会抓住这些Bug不放，有时候还要说您什么都不懂，这样你就很郁闷，肯定呆不长久的，只有走人的份了，呵呵。特别是开发人员很窝火的时候，您更要多一些理解和宽容，切勿火上浇油，您可以给他一些表扬，给他一些鼓励。他一听准开心死了，总觉得还是您们最了解我，把您当成自己人。这个时候，你再问开发人员问题，他也许态度就不一样了，他准会仔细的给你讲解，并且以后的什么事情，他也会百厌齐烦地帮助您的，因为他觉您最了解他们，无意识的把您当成了好朋友和哥们。还有的时候，开发人员有空过来测试部门逛逛，准备和您交流时，一定要把握机会，和开发人员开开玩笑和一些必要赞赏，也能够调节和开发人员的关系。总之，这一点做起来真的很难，如果做的好，那效果确实就不一样了。

1、软件测试规范的定义：

 

软件测试规范就对软件测试的流程过程化，并对每一个元素进行明确界定，形成完整的规范体系。软件测试规范是一个公司的测试标准，不仅是测试人员测试的准则，还是开发人员和测试人员达成的契约。一般来说，小的公司或不正规的公司都不会书写这个，它一般由测试经理来编写，估计一般的测试工程师接触较少，不太了解。

 

2、软件测试规范描述的内容：

 

软件测试规范一般来说描述的内容包括：测试目的、测试类别、测试过程、测试方法、测试用例、测试管理、测试文档、测试工具都要进行明确的描述。

 

3、一份“有效的、可行性高”的软件测试规范包括以下内容：

 

（ 1 ）、测试计划规范：

 

它包括测试计划模板的编写风格和测试计划的编写要求。如：测试进度估算、测试风险评估、测试人员安排和测试时间安排由什么来确定等等内容。

 

（ 2 ）、测试用例设计规范：

 

它包含了测试用例的模板编写和测试用例的设计要求。如：测试用例设计人员、测试执行时间、测试用例设计的优先级等等。

 

（ 3 ）、测试工具使用规范：

 

有了这个规范，测试人员就知道“项目进展”到什么程度，什么时候使用什么测试工具。个人建议：最好把测试工具配置部分的“注意事项”也罗列在里面。比如说使用LoadRunner做性能测试时，支持哪些常用的协议？使用那些脚本开发语言都写清楚。

 

（ 4 ）、缺陷跟踪系统录入规范：

 

主要是规范测试人员按照统一的要求递交缺陷到数据库。录入时，必须考虑缺陷录入的格式、录入的要素以及缺陷录入的“必填项”的要求等等内容。

 

（ 5 ）、缺陷严重等级划分规范：

 

有了缺陷严重等级的划分规范，测试人员、开发人员和其它项目组成员，对于测试缺陷就有了统一的标准，也不会因为某个缺陷由于严重等级的问题项目组成员争论半天，提高了测试效率。

 

（ 6 ）、缺陷优先等级划分规范：

 

优先等级规范的描述，有利于开发人员准确定位缺陷的优先等级标识，为开发人员修复软件缺陷和衡量产品质量提供参考。

 

（ 7 ）、缺陷分类规范：

 

让测试人员准确对全部的缺陷，按“模块”进行准确分类，方便测试部门或质量部门对缺陷数量进行统计，并对软件质量进行评估，为软件是否允许发布提供重要的参考依据。

 

（ 8 ）、缺陷状态修改规范：

 

  要求测试管理系统的管理人员，根据不同的项目角色，准确分配缺陷管理系统的使用权限。如：开发人员不应该具备Rejected、Closed、Suspended的权限；测试人员不应该有Fixed的权限；还有如优先级、严重等级和版本等重要区域，都不允许修改。

 

（ 9 ）、缺陷递交流程规范：

 

    该规范是指测试人员“递交缺陷”、“缺陷公开”和开发人员修改缺陷后递交测试人员验证的流程，最好做成流程图的形式。

 

（ 10 ）、测试报告规范：

 

它包括测试报告模板以及对测试报告编写的各种要求。如：测试报告包括的要素、测试缺陷分析的方法、分析手段以及缺陷分析应该注意的问题等等都要一一进行详细说明。

 

（ 11 ）、测试退出规范：

 

  软件测试到什么程度、满足什么条件，测试组织或测试项目就可以退出或停止。

 

（ 12 ）、软件测试类型规范：

 

它主要是介绍测试的方法，包括单元测试、集成测试、系统测试、验收测试等等测试方法。

 

（ 13 ）、开发语言测试规范：

 

比如说你要测试的系统，是使用Java开发的项目，你就要对Java的编程标准、初始化、面向对象编程、优化、javadoc注释、线程、全局静态分析等等语言基础有所了解，然后再针对性的编写相关的测试规范比较合适。

 

 

（ 14 ）、界面测试规范：

 

一般来说目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格。我们在做界面测试时，同样要根据界面风格制定相关的测试规范，包括它的易用性、规范性、合理性、独特性、美观性和帮助设施等等都要一一写入测试规范中。

 

（ 15 ）、软件测试流程规范：

 

    软件测试的流程规范一般来说包括“测试项目确认流程”、“测试执行流程”、“测试策划流程”、“问题跟踪与测试关闭”等等流程。

 

 

规范2

如何制定一份有效的，可行性高的测试规范？

书写一份有效，可行性高的规范，我觉得需要注意以下几个方面：
1. 规范在内容上要系统全面。
关于测试的方式、方法、种类、流程等等我想自然不必再赘述了。但是如何把这些方式、方法、种类、流程串接起来形成一个体系却是值得我们每一个深入思考的问题。一份规范的影响面及其适应的情况毕竟来说还是很局限的。所以，我认为，从体系框架上构建是产生有效且高可行度规范的充分条件，皮之不存毛将焉附？第二，在规范的内容上必须要相对比较全面，至少能涵盖到目前所从事的主要的测试工作。第三，系统性的表述是规范的基本要求--一般我们都是要求使用结构化的语言，框架式进行编写，务必使构成该规范的每个部分都清晰明了。

2. 内容的细分项目要求具备一定的可操作性。
所谓规范的可操作性，即是要求可量化的量化，不能量化的具体化。很多同仁定规范时，对规范所要求的工作内容不够明确，不是雾里看花，就是“空对空”。评审的人一头雾水，执行的人无所适从，当然其可操作性必然不佳。尽量要求规范中的操作步骤明确，实现目标量化或具体化（建议参考SMART原则制定）。

3. 内容中所引用的术语、行业名词必须规范且统一。
很有必要的注意事项，团队内的成员来自不同的地方，每个人对相同的测试事务所持的观点未必相同，规范的作用之一就是尽量减少差异化，以期不同人做相同事能得到一个尽可能一样的结果。所以在制定规范时使用统一的口径是很必要的，以免产生歧义和误差。

4. 制定规范一定要注意适应当前企业的实际和现状。
也许这一点才是对可行性要求的最基本的要素。之前，包括我自己在内，对规范的理解也仅限于从网络上获得一些已成形的内容，到最后发现却根本不合适。比如说，一个只有三两个人的测试团队，就要求做自动化框架体系的构建--往往不切实际是一切规范失效的最根本原因。较好的规范应该是具备可实现性的，能在一定时期内努力后，可达到的目标。

接下来，补充几点说明：
1. 做规范的基本思想就是建立标准，以教育、培训、参照、考评和持续优化，使一切事可控并习惯化，以实现生产力提升，获得企业资源配置最优化与企业利润最大化。所以，将对规范的执行纳入绩效考核体系是必然的。有效无效，可行性高还是不高，我想不是靠几个大脑想就能实现的，最后还是要由实践来检验。
2. 既然是规范，必然有其缺失错漏，所以规范的有效及可行性判断必然是需要经过循序渐进、持续优化的过程，没有一步到位。不同的团队组织，对于规范的态度是积极执行，及时响应与否将决定规范的价值。所以，我想请大家记得这句话：好的规范是整个团队、组织一步一个脚印，不断整理、总结、归纳做出来的，不是拍拍脑袋想出来的。其所谓的有效、可行性也是基于此而言--大家万勿舍本求末。

 

 

规范3

如何制定一份有效的，可行性高的测试规范？

提高测试团队工作的规范性也是保证软件质量的必要手段，所以每个公司都应该制定自己的测试规范，这份规范应该是贯穿整个软件开发周期的，也是所有开发和测试都应该遵循的，如何制定这样一份规范让大家都愿意遵其行事呢？这样的规范具体应该包含哪些内容呢？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

说实话，这题本身就没有什么太大的价值。

1、所有开发和测试都应该遵循的话规范，是很难制定出来的。开发要遵循的，是研发规范；测试要遵循的，自然是测试规范；前期的需求、规格人员，则是相应的需求、规格分析设计规范；后期的客服，又有客服规范。各个部门的具体职责，情况都是完全不同的，因此想一份规范笼统概述，要么就是大而空，没有实际价值；要么就是过于繁琐细致，以致于失去其“规”的价值。

2、如何制定测试规范？？
简单而言，结合你所在公司的实际情况，未来的发展规划，业务重点，潜在客户的客观需求，行业的可能发展方向，业界的已有通行规范来制定。
这事说起来当然很简单，但实际实行的时候，就会遇到几个问题：
1）公司的高层的重视、支持程度
如果你所在公司的领导层根本不重视测试，或者对测试没有什么想法，那么你测试规范制定得再好，再完美，也等于废纸，甚或在现在的电子化办公时代，连废纸都不如。而很不幸，在国内而言，测试的受重视程度，在绝大多数公司，都是嘴上喊得响亮，行动上拖拖拉拉，毫无效率与目标，也就是说，你没有高层的真正的实际支持，你之后所作一切，都将是白费。那么具体应该有什么样的支持？我个人从业经验而言，觉得需要以下几点：
（1）权
足够的执行权力，领导权力，约束权力，推行权力，奖惩权力，是测试规范在制定后能真正贯彻、有效切实实施的保证
（2）人
合理的，有用的，实际的人力资源，是制定、贯彻、实施、监控、监督、改进测试规范的实际保障
（3）物
包括各类软件、硬件的支持，这里包括下载、购买相应的参考标准、参考资料、注册参加某些特定的会员、对内部人员的培训等等，都属于物力上支持
当然，我说从权、人、物上获得支持，并不是制定测试规范，包括后续的贯彻、实施、监控、改进等，是无限制的支持，本身的监管和限制，也都是矛盾对立统一的，是相辅相成的。
2）情况的不明确
很多公司，在制定这样那样的规范（不局限于测试规范）时，总是想着一下子覆盖所有的情况，满足所有的条件，解决所有的问题，结果造成了大而空，细而乱的规范，最后无法执行、实施、监控、改进而形同废弃。进而导致高层领导从此对此类规范失去信心，只相信人本位管理。在制定规范之前，需要先明确当前的自身状况，问题，为什么要制定这规范，制定这规范是为了解决什么问题，预期能够解决到什么程度，可能需要投入哪些资源、成本，预期如何实施等。说实话，制定规范并不是一蹴而就的事情。
3）制定者本身的能力问题
规范的制定者本身的能力、经验、甚至资历的不足，会限制、约束、甚至直接摧毁整个规范的制定。通常而言，应该是建立一个规范制定小组，由至少一个高层领导参与（不管是直接参与，还是作为名誉参与，作用在于起到对规范制定小组或委员会的权威性的认可），所有相关部门最低限度，至少派出 1 名代表，直接相关主要部门不少于 3 名代表。代表的应选择从业经验丰富，技术全面，思维敏捷，细致的人。如情况允许，可以邀请、聘请相关的咨询、管理专家，甚至你的主要大客户的代表参与到这个规范制定小组中。

当然，仅就规范的制定而言，会遇到的问题还很多很多，以上列举的也只是常见的。顺便说一句，在规范制定时的争吵现象是不可避免的，此时通常的做法有几类，表决式，少数服从多数式，领导一票决定式，外来和尚念经式，这个一般取决于具体企业的企业文化。

3、这样的规范具体应该包含哪些内容呢？
这个，我只能先 -_-!!! 真正要说具体的内容，请 Google 或 Baidu “测试规范”关键字，然后你会获得大量的范例
具体包含的内容，简单而言，就是指导、规定、约束、限制。
指导：就是指导相应的人员如何操作，完成相应的工作，任务。
规定：就是要求相应的人员必须履行的职责。
约束：就是对相应的人员的工作中可能出现的问题的提前预防针。
限制：就是对相应的人员的禁止性措施。
其实，具体规范应该的包含内容，还是与具体公司的实际情况相挂钩的。A 公司可能完全限制人员连接 Internet， B 公司就变成有条件的限制， C 公司则完全不限制。

规范制定完成之后，具体的实施、监督、监控、监管、对实施过程中出现的问题和收集到的建议/意见的改进，才是真正的难点和麻烦之处。

本文出自shuixin128的51Testing软件测试博客，转载请保留出处及链接：http://www.51testing.com/?39517

这几天看到一些WEB通用功能的测试用例设计，我也想小试一把，看到网上也有对翻页功能的用例，感觉不是很全，我总结了一下，下面是我对翻页功能的测试用例设计，有不对的欢迎朋友们指正，不全的大家帮补哦！

翻页功能我们常碰到的一般有以下几个功能：
1、首页、上一页、下一页、尾页。
2、总页数，当前页数
3、指定跳转页
4、指定每页显示条数
当然，有一些是少于多少页，全部以数字的形式显示，多于多少页后，才出现下一页的控件。本文暂且用以上四点来做为通用的用例来设计吧。

对于1翻页链接或按钮的测试，主要要检查的测试点有：
1、有无数据时控件的显示情况
2、在首页时，首页和上一页是否能点击
3、在尾页时，下一页和尾页是否能点击
4、在非首页和非尾页时，四个按钮功能是否正确
5、翻页后，列表中的记录是否仍按照指定的排序列进行了排序
对于2总页数，当前页数，主要要检查的测试点有：
1、总页数是否等于总的记录数/指定每页条数
2、当前页数是否正确
对于3指定跳转页，主要要检查的测试点有：
1、是否能正常跳转到指定的页数
2、输入的跳转页数非法时的处理
对于4指定每页显示条数，主要要检查的测试点有：
1、是否有默认的指定每页显示条数
2、指定每页的条数后，列表显示的记录数，页数是否正确
3、输入的每页条数非法时的处理

分析完上面的测试点，应该可以进行用例的设计了。
step 1: 列表无记录 
expect: 1、四个翻页控件变灰不可点击
        2、列表有相应的无数据信息提示
        3、不可指定页数
        4、不可指定跳转页
        5、总页数显示为0
        6、当前页数显示为0

step 2: 列表的记录数<=指定的每页显示条数
expect: 1、四个翻页控件变灰不可点击
        2、总页数显示为1
        3、当前页数显示为1

step 3: 列表的记录数>指定的每页显示条数
expect: 1、默认在首页，当前页数为1              
        2、列表的数据按照指定的排序列正确排序
        3、记录数与数据库相符
        4、总页数＝记录数/指定的每页显示条数

step 4: 列表的记录数>指定的每页显示条数，在首页
expect: 1、首页变灰不可点击
        2、上一页变灰不可点击
        3、下一页可点击，从（每页指定条数＋1）条记录开始显示，当前页数+1
        4、尾页可点击，显示最后页的记录

step 5: 列表的记录数>指定的每页显示条数，在中间的某页
expect: 1、首页可点击，显示1到每页指定条数的记录
        2、上一页可点击，显示上一页的记录
        3、下一页可点击，从后一页的记录
        4、尾页可点击，显示最后页的记录
        5、列表的数据按照指定的排序列正确排序
        6、当前页数为所在页

step 6:列表的记录数>指定的每页显示条数，在尾页
expect: 1、首页可点击，显示1到每页指定条数的记录
        2、上一页可点击，显示上一页的记录
        3、下一页变灰不可点击
        4、尾页变灰不可点击
        5、列表的数据按照指定的排序列正确排序
        6、当前页数为最后一页的页数

step 7:输入每页显示条数为正整数
expect: 1、每页显示条数更新成指定的条数
        2、超过指定的条数的记录分页显示
        3、总页数更新成列表的记录数/每页显示条数

step 8:输入每页显示条数为0
expect: 1、提示“每页显示条数必须为大于1的整数”
        2、提示后每页显示条数恢复为上次生效的条数

step 9:输入每页显示条数为负数
expect: 1、提示每页显示条数必须为大于1的整数
        2、提示后每页显示条数恢复为上次生效的条数

step 10:输入每页显示条数长度超过数据库指定的长度<<<maxlen>>>
expect: 1、提示每页显示条数不能超过<<<maxlen>>>位
        2、提示后每页显示条数恢复为上次生效的条数

step 11:输入每页显示条数为字符串，如中文翻页数
expect: 1、提示每页显示条数必须为大于1的整数
        2、提示后每页显示条数恢复为上次生效的条数

step 12:输入每页显示条数为特殊字符，如％
expect: 1、提示每页显示条数必须为大于1的整数
        2、提示后每页显示条数恢复为上次生效的条数

step 13:输入每页显示条数为html字符串，如<br>
expect: 1、提示每页显示条数必须为大于1的整数
        2、提示后每页显示条数恢复为上次生效的条数

step 14:输入跳转的页数为存在的页数
expect: 1、正确跳转到指定的页数

step 15:输入跳转的页数不存在或非法值
expect: 1、跳转的页数值置为1，显示第一页的数据

以上的用例是将总页数，当前页数都揉进了翻页控件的测试用例中了。

首先，批处理文件是一个文本文件，这个文件的每一行都是一条DOS命令（大部分时候就好象我们在DOS提示符下执行的命令行一样），你可以使用DOS下的Edit或者Windows的记事本(notepad)等任何文本文件编辑工具创建和修改批处理文件。
其次，批处理文件是一种简单的程序，可以通过条件语句(if)和流程控制语句(goto)来控制命令运行的流程，在批处理中也可以使用循环语句(for)来循环执行一条命令。当然，批处理文件的编程能力与C语言等编程语句比起来是十分有限的，也是十分不规范的。批处理的程序语句就是一条条的DOS命令（包括内部命令和外部命令），而批处理的能力主要取决于你所使用的命令。
第三，每个编写好的批处理文件都相当于一个DOS的外部命令，你可以把它所在的目录放到你的DOS搜索路径(path)中来使得它可以在任意位置运行。一个良好的习惯是在硬盘上建立一个bat或者batch目录（例如C:\BATCH），然后将所有你编写的批处理文件放到该目录中，这样只要在path中设置上c:\batch，你就可以在任意位置运行所有你编写的批处理程序。
第四，在DOS和Win9x/Me系统下，C:盘根目录下的AUTOEXEC.BAT批处理文件是自动运行批处理文件，每次系统启动时会自动运行该文件，你可以将系统每次启动时都要运行的命令放入该文件中，例如设置搜索路径，调入鼠标驱动和磁盘缓存，设置系统环境变量等。下面是一个运行于Windows 98下的autoexec.bat的示例：
@ECHO OFF
PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\UCDOS;C:\DOSTools;C:\SYSTOOLS;C:\WINTOOLS;C:\BATCH
LH SMARTDRV.EXE /X
LH DOSKEY.COM /INSERT
LH CTMOUSE.EXE
SET TEMP=D:\TEMP
SET TMP=D:\TEMP
 
批处理的作用
简单的说，批处理的作用就是自动的连续执行多条命令。
这里先讲一个最简单的应用：在启动wps软件时，每次都必须执行（>前面内容表示DOS提示符）：
C:\>cd wps
C:\WPS>spdos
C:\WPS>py
C:\WPS>wbx
C:\WPS>wps
如果每次用WPS之前都这样执行一遍，您是不是觉得很麻烦呢？
好了，用批处理，就可以实现将这些麻烦的操作简单化，首先我们编写一个runwps.bat批处理文件，内容如下：
@echo off
c:
cd\wps
spdos
py
wbx
wps
cd\
以后，我们每次进入wps，只需要运行runwps这个批处理文件即可。
常用命令
echo、@、call、pause、rem(小技巧：用::代替rem)是批处理文件最常用的几个命令，我们就从他们开始学起。
echo 表示显示此命令后的字符
echo off 表示在此语句后所有运行的命令都不显示命令行本身
@与echo off相象，但它是加在每个命令行的最前面，表示运行时不显示这一行的命令行（只能影响当前行）。
call 调用另一个批处理文件（如果不用call而直接调用别的批处理文件，那么执行完那个批处理文件后将无法返回当前文件并执行当前文件的后续命令）。
pause 运行此句会暂停批处理的执行并在屏幕上显示Press any key to continue...的提示，等待用户按任意键后继续
rem 表示此命令后的字符为解释行（注释），不执行，只是给自己今后参考用的（相当于程序中的注释）。
例1：用edit编辑a.bat文件，输入下列内容后存盘为c:\a.bat，执行该批处理文件后可实现：将根目录中所有文件写入 a.txt中，启动UCDOS，进入WPS等功能。
　　批处理文件的内容为: 　　　　　　　 命令注释：
　　　　@echo off　　　　　　　　　　　不显示后续命令行及当前命令行
　　　　dir c:\*.* >a.txt　　　　　　　将c盘文件列表写入a.txt
　　　　call c:\ucdos\ucdos.bat　　　　调用ucdos
　　　　echo 你好 　　　　　　　　　　 显示"你好"
　　　　pause 　　　　　　　　　　　　 暂停,等待按键继续
　　　　rem 准备运行wps 　　　　　　　 注释：准备运行wps
　　　　cd ucdos　　　　　　　　　　　 进入ucdos目录
　　　　wps 　　　　　　　　　　　　　 运行wps　　
批处理文件的参数
批处理文件还可以像C语言的函数一样使用参数（相当于DOS命令的命令行参数），这需要用到一个参数表示符"%"。
%[1-9]表示参数，参数是指在运行批处理文件时在文件名后加的以空格（或者Tab）分隔的字符串。变量可以从%0到%9，%0表示批处理命令本身，其它参数字符串用%1到%9顺序表示。
例2：C:根目录下有一批处理文件名为f.bat，内容为：
@echo off
format %1
如果执行C:\>f a:
那么在执行f.bat时，%1就表示a:，这样format %1就相当于format a:，于是上面的命令运行时实际执行的是format a:
例3：C:根目录下一批处理文件名为t.bat，内容为:
@echo off
type %1
type %2
那么运行C:\>t a.txt b.txt
%1 : 表示a.txt
%2 : 表示b.txt>
于是上面的命令将顺序地显示a.txt和b.txt文件的内容。
 
特殊命令
if goto choice for是批处理文件中比较高级的命令，如果这几个你用得很熟练，你就是批处理文件的专家啦。
一、if 是条件语句，用来判断是否符合规定的条件，从而决定执行不同的命令。有三种格式:
1、if [not] "参数" == "字符串" 待执行的命令
参数如果等于(not表示不等，下同)指定的字符串，则条件成立，运行命令，否则运行下一句。
例：if "%1"=="a" format a:
2、if [not] exist [路径\]文件名 待执行的命令
如果有指定的文件，则条件成立，运行命令，否则运行下一句。
如: if exist c:\config.sys type c:\config.sys
表示如果存在c:\config.sys文件，则显示它的内容。
3、if errorlevel <数字> 待执行的命令
很多DOS程序在运行结束后会返回一个数字值用来表示程序运行的结果(或者状态)，通过if errorlevel命令可以判断程序的返回值，根据不同的返回值来决定执行不同的命令(返回值必须按照从大到小的顺序排列)。如果返回值等于指定的数字，则条件成立，运行命令，否则运行下一句。
如if errorlevel 2 goto x2
二、goto 批处理文件运行到这里将跳到goto所指定的标号(标号即label，标号用:后跟标准字符串来定义)处，goto语句一般与if配合使用，根据不同的条件来执行不同的命令组。
如:
goto end
:end
echo this is the end
标号用":字符串"来定义，标号所在行不被执行。
三、choice 使用此命令可以让用户输入一个字符（用于选择），从而根据用户的选择返回不同的errorlevel，然后于if errorlevel配合，根据用户的选择运行不同的命令。
注意：choice命令为DOS或者Windows系统提供的外部命令，不同版本的choice命令语法会稍有不同，请用choice /?查看用法。
choice的命令语法（该语法为Windows 2003中choice命令的语法，其它版本的choice的命令语法与此大同小异）：
CHOICE [/C choices] [/N] [/CS] [/T timeout /D choice] [/M text]
描述:
　 该工具允许用户从选择列表选择一个项目并返回所选项目的索引。
参数列表:
　/C　　choices　　　 指定要创建的选项列表。默认列表是 "YN"。
　/N　　　　　　　　　在提示符中隐藏选项列表。提示前面的消息得到显示，选项依旧处于启用状态。
　/CS　　　　　　　　允许选择分大小写的选项。在默认情况下，这个工具是不分大小写的。
　/T　　timeout　　　 做出默认选择之前，暂停的秒数。可接受的值是从 0 到 9999。如果指定了 0，就不会有暂停，默认选项
　　　　　　　　　　　会得到选择。
　/D　　choice　　　　在 nnnn 秒之后指定默认选项。字符必须在用 /C 选项指定的一组选择中; 同时，必须用 /T 指定 nnnn。
　/M　　text　　　　　指定提示之前要显示的消息。如果没有指定，工具只显示提示。
　/?　　　　　　　　　显示帮助消息。
　注意:
　ERRORLEVEL 环境变量被设置为从选择集选择的键索引。列出的第一个选择返回 1，第二个选择返回 2，等等。如果用户按的键不是有效的选择，该工具会发出警告响声。如果该工具检测到错误状态，它会返回 255 的ERRORLEVEL 值。如果用户按 Ctrl+Break 或 Ctrl+C 键，该工具会返回 0 的 ERRORLEVEL 值。在一个批程序中使用 ERRORLEVEL 参数时，将参数降序排列。
示例:
　CHOICE /?
　CHOICE /C YNC /M "确认请按 Y，否请按 N，或者取消请按 C。"
　CHOICE /T 10 /C ync /CS /D y
　CHOICE /C ab /M "选项 1 请选择 a，选项 2 请选择 b。"
　CHOICE /C ab /N /M "选项 1 请选择 a，选项 2 请选择 b。"
　
如果我运行命令：CHOICE /C YNC /M "确认请按 Y，否请按 N，或者取消请按 C。"
屏幕上会显示：
确认请按 Y，否请按 N，或者取消请按 C。 [Y,N,C]?
　
　
例：test.bat的内容如下（注意，用if errorlevel判断返回值时，要按返回值从高到低排列）:
@echo off
choice /C dme /M "defrag,mem,end"
if errorlevel 3 goto end
if errorlevel 2 goto mem
if errotlevel 1 goto defrag
:defrag
c:\dos\defrag
goto end
:mem
mem
goto end
:end
echo good bye
此批处理运行后，将显示"defrag,mem,end[D,M,E]?" ，用户可选择d m e ，然后if语句根据用户的选择作出判断，d表示执行标号为defrag的程序段，m表示执行标号为mem的程序段，e表示执行标号为end的程序段，每个程序段最后都以goto end将程序跳到end标号处，然后程序将显示good bye，批处理运行结束。
四、for 循环命令，只要条件符合，它将多次执行同一命令。
语法：
对一组文件中的每一个文件执行某个特定命令。
FOR %%variable IN (set) DO command [command-parameters]
%%variable　　　　指定一个单一字母可替换的参数。
(set)　　　　　　指定一个或一组文件。可以使用通配符。
command　　　　　指定对每个文件执行的命令。
command-parameters 为特定命令指定参数或命令行开关。
例如一个批处理文件中有一行:
for %%c in (*.bat *.txt) do type %%c
则该命令行会显示当前目录下所有以bat和txt为扩展名的文件的内容。
 
批处理示例
1. IF-EXIST
1)
首先用记事本在C:\建立一个test1.bat批处理文件，文件内容如下：
@echo off
IF EXIST \AUTOEXEC.BAT TYPE \AUTOEXEC.BAT
IF NOT EXIST \AUTOEXEC.BAT ECHO \AUTOEXEC.BAT does not exist
然后运行它：
C:\>TEST1.BAT
如果C:\存在AUTOEXEC.BAT文件，那么它的内容就会被显示出来，如果不存在，批处理就会提示你该文件不存在。
2)
接着再建立一个test2.bat文件，内容如下：
@ECHO OFF
IF EXIST \%1 TYPE \%1
IF NOT EXIST \%1 ECHO \%1 does not exist
执行:
C:\>TEST2 AUTOEXEC.BAT
该命令运行结果同上。
说明：
(1) IF EXIST 是用来测试文件是否存在的，格式为
IF EXIST [路径+文件名] 命令
(2) test2.bat文件中的%1是参数，DOS允许传递9个批参数信息给批处理文件，分别为%1~%9(%0表示test2命令本身) ，这有点象编程中的实参和形参的关系，%1是形参，AUTOEXEC.BAT是实参。
3) 更进一步的，建立一个名为TEST3.BAT的文件，内容如下：
@echo off
IF "%1" == "A" ECHO XIAO
IF "%2" == "B" ECHO TIAN
IF "%3" == "C" ECHO XIN
如果运行：
C:\>TEST3 A B C
屏幕上会显示:
XIAO
TIAN
XIN
如果运行：
C:\>TEST3 A B
屏幕上会显示
XIAO
TIAN
在这个命令执行过程中，DOS会将一个空字符串指定给参数%3。
2、IF-ERRORLEVEL
建立TEST4.BAT，内容如下：
@ECHO OFF
XCOPY C:\AUTOEXEC.BAT D:IF ERRORLEVEL 1 ECHO 文件拷贝失败
IF ERRORLEVEL 0 ECHO 成功拷贝文件
然后执行文件:
C:\>TEST4
如果文件拷贝成功，屏幕就会显示"成功拷贝文件"，否则就会显示"文件拷贝失败"。
IF ERRORLEVEL 是用来测试它的上一个DOS命令的返回值的，注意只是上一个命令的返回值，而且返回值必须依照从大到小次序顺序判断。因此下面的批处理文件是错误的：
@ECHO OFF
XCOPY C:\AUTOEXEC.BAT D:\
IF ERRORLEVEL 0 ECHO 成功拷贝文件
IF ERRORLEVEL 1 ECHO 未找到拷贝文件
IF ERRORLEVEL 2 ECHO 用户通过ctrl-c中止拷贝操作
IF ERRORLEVEL 3 ECHO 预置错误阻止文件拷贝操作
IF ERRORLEVEL 4 ECHO 拷贝过程中写盘错误
无论拷贝是否成功，后面的：
未找到拷贝文件
用户通过ctrl-c中止拷贝操作
预置错误阻止文件拷贝操作
拷贝过程中写盘错误
都将显示出来。
以下就是几个常用命令的返回值及其代表的意义：
backup
0 备份成功
1 未找到备份文件
2 文件共享冲突阻止备份完成
3 用户用ctrl-c中止备份
4 由于致命的错误使备份操作中止
diskcomp
0 盘比较相同
1 盘比较不同
2 用户通过ctrl-c中止比较操作
3 由于致命的错误使比较操作中止
4 预置错误中止比较
diskcopy
0 盘拷贝操作成功
1 非致命盘读/写错
2 用户通过ctrl-c结束拷贝操作
3 因致命的处理错误使盘拷贝中止
4 预置错误阻止拷贝操作
format
0 格式化成功
3 用户通过ctrl-c中止格式化处理
4 因致命的处理错误使格式化中止
5 在提示"proceed with format（y/n）?"下用户键入n结束
xcopy
0 成功拷贝文件
1 未找到拷贝文件
2 用户通过ctrl-c中止拷贝操作
4 预置错误阻止文件拷贝操作
5 拷贝过程中写盘错误
3、IF STRING1 == STRING2
建立TEST5.BAT，文件内容如下：
@echo off
IF "%1" == "A" formAT A:
执行：
C:\>TEST5 A
屏幕上就出现是否将A:盘格式化的内容。
注意：为了防止参数为空的情况，一般会将字符串用双引号（或者其它符号，注意不能使用保留符号）括起来。
如：if [%1]==[A] 或者 if %1*==A*
5、GOTO
建立TEST6.BAT，文件内容如下：
@ECHO OFF
IF EXIST C:\AUTOEXEC.BAT GOTO _COPY
GOTO _DONE
:_COPY
COPY C:\AUTOEXEC.BAT D:\
:_DONE
注意：
(1) 标号前是ASCII字符的冒号":"，冒号与标号之间不能有空格。
(2) 标号的命名规则与文件名的命名规则相同。
(3) DOS支持最长八位字符的标号，当无法区别两个标号时，将跳转至最近的一个标号。
6、FOR
建立C:\TEST7.BAT，文件内容如下：
@ECHO OFF
FOR %%C IN (*.BAT *.TXT *.SYS) DO TYPE %%C
运行：
C:>TEST7
执行以后，屏幕上会将C:盘根目录下所有以BAT、TXT、SYS为扩展名的文件内容显示出来（不包括隐藏文件）。

怎么样提高软件测试员自身素质培养?

　　(1) 首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。

　　(2) 善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。

　　(3) 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。

　　(4) 保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来

　　(5) 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。

　　(6) 灵活一些，聪明一点，多制造一些容易产生bug的例子。

　　(7) 在有条件的情况下，多和客户沟通，他们身上有你所需要的。

　　(8) 设身处地为客户着想，从他们的角度去测试系统。

　　(9) 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。

　　(10) 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。

　　(11) 提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。

今天记录下面两个问题的分析

1、  怎么从招聘信息分析公司对测试这个职位的了解？

2、  怎么知道所面试的公司是否适合自己？

从招聘测试的招聘信息和面谈可以了解招聘公司对测试工作的理解和态度 .

分析点 :

1)      如果招聘信息要求应聘者了解一些开发流程、测试流程、测试技术（如黑盒测试、白盒测试等等），可见这个公司了解测试这个工作岗位。

2)      在上面第一条的基础上，如果招聘信息要求应聘者熟悉测试工具的使用，可见这个公司在使用自动化技术或者有这个打算。

3)      如果招聘信息要求应聘者要有很好的沟通能力、表达能力、协调能力、适应能力、学习能力，可见这个公司的企业文化比较人文化（大家可以互相交流意见）。

4)      如果招聘信息详细描述包含了两部分：岗位名称和岗位职责，并且招聘信息描述正确、排版美观，说明简洁明了，可见这个公司人事管理规范。

面谈的时候，招聘公司是否重视测试、懂的测试这个职位，从这下面这几个方面就可以有些了解：

NO1 ：测试的领导是否做过测试工作。

很多公司管理者的技术能力是在程序员的时代得到的，这些人走上管理岗位后，如果没有持续的学习，就会根本不了解测试是怎么回事，有什么价值，在他们心目中，只有开发人员做的事情才是重要的，可见的。他们之所以招人做测试是因为软件的质量实在太差，客户的不满让他们无法忍受。面对测试狗屁不通的测试经理或者高级经理做测试工作，后果是：首先，努力得不到肯定，工作成果得不到尊重。接着，会发现成长的机会很少，因为领导既然不懂测试，也就不知道需要提高什么样的技能，既不要求你，也不支持你。你只好自己学习，而且难以获得支持和肯定。

NO2 ：测试的管理是否规范

招聘单位是否重视软件质量，从对待开发、测试的管理、执行是否规范就可以看出。测试在整个项目的介入、测试工作的评审，测试报告、对待严重 bug 的处理；对测试人员的考核、工作职责定位是否合理等等就可以了解这个公司测试大体执行情况。  

NO3 ：知己知彼

看看自己目前的能力是否能胜任所应聘的岗位，看看公司的企业文化、办公环境是否能适应，看看公司的福利待遇是否能接受了。正如 testage 论坛上关河发起的讨论“ 测试工程师希望什么样的工作环境？”嘿嘿，我的回答是：

嘿嘿，对于目前的我来说，我希望在下面这样条件的公司做测试工作：

1 、公司的开发流程是按照正规流程走：需求分析 -- 概要设计 -- 详细设计 -- 单元测试 -- 集成测试 -- 系统测试 -- 验收测试，并对每一阶段的成果物进行有效的评审。因为：把时间花在做正确的事情上才是正确有效的工作方式。

2 、公司要重视软件的质量，测试可以参与到开发的整个活动过程，进行软件开发全过程测试。因为：测试对软件开发的过程、进度，对所测试软件产生的原因（即用户需求）以及使用的场景了解（即用户为什么要这么做）越清晰，测试的工作才能是准确、有效和高效的。

3 、公司要有懂的测试工作、理解测试工作的人，特别是测试、开发的领导者。因为：对牛弹琴，牛到死了都不知道你是在干嘛，琴弹的在好都没有办法领悟和理解。

4 、公司有学习氛围、有良好的沟通环境，大家可以互相的交流自己的思想、经验和对工作成果的意见。因为：有些工作，经过交流会得出新的、更好、更合理有效的处理方法。开发人员和测试人员有效、友好的沟通工作建议和经验会使整个团队的研发水平、测试水平、工作效率、工作质量向上发展。

5 、公司对测试人员的绩效考核是正确合理的，既不能用其它工种（如：开发人员、技术支持人员）的绩效考核方式来考核测试人员的工作，绩效考核的目的是激励员工工作的积极性。

6 、公司能够长期生存，公司领导能够规划好整个公司的发展方向、测试部门领导能够很好的规划部门的发展方向。

7 、公司的生意好好的，能接很多的项目进行研发。

系统测试用例设计方法有等价类划分、边界值、判定表、因果图、状态转移图、流程分析法、正交试验法、输入域测试、输出域覆盖、异常分析法、错误猜测法

测试策略包含: 功能测试,性能测试,压力测试,容量测试,可用性测试,配置测试,GUI测试,安装测试,安全性测试,网络测试,异常测试,备份测试,文档测试,在线帮助测试,健壮性测试,稳定性测试.

有许多方法可以帮助我们明确工作思路提高工作效率，例如个人的工作习惯、团队力量、企业中有一套完整软件等，首先要明白，效率的关键在于良好的工作习惯，而不是学会一两个方法，这决非一日之功.

在我们的工作中，有很多的客户问到关于华为的面试的问题，希望我们能提供一些关于华为面试的经验，也有很多的客户建议我们能开设这样一个板块，向大家介绍如何面对知名企业的面试，我们也将相关的面试经验收集整理，供大家参阅，今天要讲的是华为的面试经验！
    面试过程中，面试官会向应聘者发问，而应聘者的回答将成为面试官考虑是否接受他的重要依据。对应聘者而言，了解这些问题背后的“猫腻”至关重要。本文对面试中经常出现的一些典型问题进行了整理，并给出相应的回答思路和参考答案。读者无需过分关注分析的细节，关键是要从这些分析中“悟”出面试的规律及回答问题的思维方式，达到“活学活用”。

    问题一：“请你自我介绍一下”

    ■思路：

    1、这是面试的必考题目。

    2、介绍内容要与个人简历相一致。

    3、表述方式上尽量口语化。

    4、要切中要害，不谈无关、无用的内容。

    5、条理要清晰，层次要分明。

    6、事先最好以文字的形式写好背熟。

    问题二：“谈谈你的家庭情况”

    ■思路：

    1、况对于了解应聘者的性格、观念、心态等有一定的作用，这是招聘单位问该问题的主要原因。

    2、简单地罗列家庭人口。

    3、宜强调温馨和睦的家庭氛围。

    4、宜强调父母对自己教育的重视。

    5、宜强调各位家庭成员的良好状况。

    6、宜强调家庭成员对自己工作的支持。

    7、宜强调自己对家庭的责任感。

    问题三：“你有什么业余爱好？”

    ■思路：

    1、业余爱好能在一定程度上反映应聘者的性格、观念、心态，这是招聘单位问该问题的主要原因。

    2、最好不要说自己没有业余爱好。

    3、不要说自己有那些庸俗的、令人感觉不好的爱好。

    4、最好不要说自己仅限于读书、听音乐、上网，否则可能令面试官怀疑应聘者性格孤僻。

    5、最好能有一些户外的业余爱好来“点缀”你的形象。

    问题四：“你最崇拜谁？”

    ■思路：

    1、最崇拜的人能在一定程度上反映应聘者的性格、观念、心态，这是面试官问该问题的主要原因。

    2、不宜说自己谁都不崇拜。

    3、不宜说崇拜自己。

    4、不宜说崇拜一个虚幻的、或是不知名的人。

    5、不宜说崇拜一个明显具有负面形象的人。

    6、所崇拜的人人最好与自己所应聘的工作能“搭”上关系。

    7、最好说出自己所崇拜的人的哪些品质、哪些思想感染着自己、鼓舞着自己。

    问题五：“你的座右铭是什么？”

    ■思路：

    1、座右铭能在一定程度上反映应聘者的性格、观念、心态，这是面试官问这个问题的主要原因。

    2、不宜说那些医引起不好联想的座右铭。

    3、不宜说那些太抽象的座右铭。

    4、不宜说太长的座右铭。

    5、座右铭最好能反映出自己某种优秀品质。

    6、参考答案——“只为成功找方法，不为失败找借口”

    问题六：“谈谈你的缺点”

    ■思路：

    1、不宜说自己没缺点。

    2、不宜把那些明显的优点说成缺点。

    3、不宜说出严重影响所应聘工作的缺点。

    4、不宜说出令人不放心、不舒服的缺点。

    5、可以说出一些对于所应聘工作“无关紧要”的缺点，甚至是一些表面上看是缺点，从工作的角度看却是优点的缺点。

    问题七：“谈一谈你的一次失败经历”

    ■思路：

    1、不宜说自己没有失败的经历。

    2、不宜把那些明显的成功说成是失败。

    3、不宜说出严重影响所应聘工作的失败经历4、所谈经历的结果应是失败的。

    5、宜说明失败之前自己曾信心白倍、尽心尽力。

    6、说明仅仅是由于外在客观原因导致失败。

    7、失败后自己很快振作起来，以更加饱满的热情

面对以后的工作。

    问题八：“你为什么选择我们公司？”

    ■思路：

    1、面试官试图从中了解你求职的动机、愿望以及对此项工作的态度。

    2、建议从行业、企业和岗位这三个角度来回答。

    3、参考答案——“我十分看好贵公司所在的行业，我认为贵公司十分重视人才，而且这项工作很适合我，相信自己一定能做好。”

    问题九：“对这项工作，你有哪些可预见的困难？”

    ■思路：

    1、不宜直接说出具体的困难，否则可能令对方怀疑应聘者不行。

    2、可以尝试迂回战术，说出应聘者对困难所持有的态度——“工作中出现一些困难是正常的，也是难免的，但是只要有坚忍不拔的毅力、良好的合作精神以及事前周密而充分的准备，任何困难都是可以克服的。”

    问题十：“如果我录用你，你将怎样开展工作”

    ■思路：

    1、如果应聘者对于应聘的职位缺乏足够的了解，最好不要直接说出自己开展工作的具体办法。

    2、可以尝试采用迂回战术来回答，如“首先听取领导的指示和要求，然后就有关情况进行了解和熟悉，接下来制定一份近期的工作计划并报领导批准，最后根据计划开展工作。”

    问题十一：“与上级意见不一是，你将怎么办？”

 ■思路：

    1、一般可以这样回答“我会给上级以必要的解释和提醒，在这种情况下，我会服从上级的意见。”

    2、如果面试你的是总经理，而你所应聘的职位另有一位经理，且这位经理当时不在场，可以这样回答：“对于非原则性问题，我会服从上级的意见，对于涉及公司利益的重大问题，我希望能向更高层领导反映。”

    问题十二：“我们为什么要录用你？”

    ■思路：

    1、应聘者最好站在招聘单位的角度来回答。

    2、招聘单位一般会录用这样的应聘者：基本符合条件、对这份共组感兴趣、有足够的信心。

    3、如“我符合贵公司的招聘条件，凭我目前掌握的技能、高度的责任感和良好的饿适应能力及学习能力 ，完全能胜任这份工作。我十分希望能为贵公司服务，如果贵公司给我这个机会，我一定能成为贵公司的栋梁！”

    问题十三：“你能为我们做什么？”

    ■思路：

    1、基本原则上“投其所好”。

    2、回答这个问题前应聘者最好能“先发制人”，了解招聘单位期待这个职位所能发挥的作用。

    3、应聘者可以根据自己的了解，结合自己在专业领域的优势来回答这个问题。

    问题十四：“你是应届毕业生，缺乏经验，如何能胜任这项工作？”

    ■思路：

    1、 如果招聘单位对应届毕业生的应聘者提出这个问题，说明招聘单位并不真正在乎“经验”，关键看应聘者怎样回答。

    2、对这个问题的回答最好要体现出应聘者的诚恳、机智、果敢及敬业。

    3、如“作为应届毕业生，在工作经验方面的确会有所欠缺，因此在读书期间我一直利用各种机会在这个行业里做兼职。我也发现，实际工作远比书本知识丰富、复杂。但我有较强的责任心、适应能力和学习能力，而且比较勤奋，所以在兼职中均能圆满完成各项工作，从中获取的经验也令我受益非浅。请贵公司放心，学校所学及兼职的工作经验使我一定能胜任这个职位。”

    问题十五：“你希望与什么样的上级共事？”

    ■思路：

    1、通过应聘者对上级的“希望”可以判断出应聘者对自我要求的意识，这既上一个陷阱，又上一次机会。

    2、最好回避对上级具体的希望，多谈对自己的要求。

    3、如“做为刚步入社会新人，我应该多要求自己尽快熟悉环境、适应环境，而不应该对环境提出什么要求，只要能发挥我的专长就可以了。”

    问题十六：“您在前一家公司的离职原因是什么？”

    ■思路：

    1、最重要的是：应聘者要使找招聘单位相信，应聘者在过往的单位的“离职原因”在此家招聘单位里不存在。

    2、避免把“离职原因”说得太详细、太具体。

    3、不能掺杂主观的负面感受，如“太幸苦”、“人际关系复杂”、“管理太混乱”、“公司不重视人才”、“公司排斥我们某某的员工”等。

    4、但也不能躲闪、回避，如“想换换环境”、“个人原因”等。

    5、不能涉及自己负面的人格特征，如不诚实、懒惰、缺乏责任感、不随和等。

    6、尽量使解释的理由为应聘者个人形象添彩。

    7、如“我离职是因为这家公司倒闭。我在公司工作了三年多，有较深的感情。从去年始，由于市场形势突变，公司的局面急转直下。到眼下这一步我觉得很遗憾，但还要面对显示，重新寻找能发挥我能力的舞台。”

    同一个面试问题并非只有一个答案，而同一个答案并不是在任何面试场合都有效，关键在于应聘者掌握了规律后，对面试的具体情况进行把握，有意识地揣摩面试官提出问题的心理背景，然后投其所好。