对测试需求进行分解需要反复检查并理解各种信息，和用户交流，理解他们的要求。可以按照以下步骤执行。

　　1、确定软件提供的主要任务。

　　2、对每个任务，确定完成该任务所要进行的工作。

　　3、确定从数据库信息引出的计算结果。

　　4、对于对时间有要求的交易，确定所要的时间和条件。

　　5、确定会产生重大意外的压力测试，包括内存、硬盘空间、高的交易率。

　　6、确定应用需要处理的数据量。

　　7、确定需要的软件和硬件配置。

　　8、确定其他与应用软件没有直接关系的商业交易。

　　9、确定安装过程。

　　10、确定没有隐含在功能测试中的用户界面要求。

　　需求分析问题：　

　　1.刚开始最好不要上来就跟客户谈，某个性能点需要什么样的指标，比如支持多少人同时登陆，等等。一上来最主要的事情是了解整个系统的作用，用户，部署的方式，约束，上线时间，等等，目的是让自己能慢慢的站在客户角度来看待这个系统，通过自己的知识，想客户所想，忧客户所忧，因为我们的目的就是要让客户满意么。
　　注意性能测试场景选择的原则：
　　a.重要的（业务上）,
　　b.重复的（最常用的模块）,
　　c.重量级的（消耗大量系统资源的）
　　具体性能指标分为几类类：
　　a.系统容量（数据容量、用户量、并发用户量）,
　　b.系统并发度指标（注册用户、在线用户、并发用户），
　　c.响应度指标（正常压力下响应能力、峰值压力下的响应能力，以及异常压力下的响应能力）

　　2.理解整个系统及其实现之后，再列出自己分析得到的性能需求点。

　　3.询问客户的具体性能需求，共同分析，是否测试，测试的优先级。

　　4.写出性能测试计划和用例，并要得到客户认可。

　　性能测试策略：

　　1.单一性能点，多用户测试。测试过程可以隔离测试性能场景，先单独测试加压每种性能需求点，比如用户登陆，可以单独模拟此需求，建立比如50人并发登陆的场景。但此种场景并非是用户实际使用情况，不可能有个系统大家只是在拼命的登陆，而不作其他事情。但是，如果在做别的事情，那么同时再有50人并发登陆的话，那这个登陆时间会大大的延长的。所以此场景的设计仅仅为了检查这一个模块的性能水平。

　　2.隔离之后，再逐步建立混合的性能场景。比如登陆的同时有人在浏览、查询、写入系统。但是此时只加载20%的负载。这一步主要是一个集成测试，考虑各个功能模块之间是否有影响，是否有对某些资源的抢夺等问题。同时找出Top Time Transaction

　　3.如果上一步没问题了，这次就加压100%，看看在真正我们规定的要求下，系统各项性能指标如何，同时对本次测试结果作为Base Line，用来性能调优之后的比较。

 对于应用系统的性能测试，测试模型的建立至关重要，性能测试模型要以实际生产环境为标准搭建，只有模型符合实际的生产环境，性能测试的结果才能真实有效的反映将来上线的生产环境的实际性能情况。根据长期测试关键核心业务系统的经验，应用系统系统的性能测试模型分析应当按照下面几个步骤来实施：

　　业务模型建立
　　全面分析应用系统系统上线后所面临的性能压力的来源和类别，并且通过分析历史交易数据来确定各种性能在整个系统压力所占比例。例如确定前台应用子系统的业务类别和并发比例，后台批处理业务的数据规模和类别等。最终目的是建立一个能够逼真模拟应用系统系统实际运行场景的业务模型。

　　测试数据模型建立
　　根据业务模型准备测试数据和基础数据，确保系统数据库中数据容量和真实性符合实际运行情况。

　　监控模型建立
　　性能测试的目的不仅仅是获得关键业务的性能指标，同时也要通过性能测试监控主机、数据库、中间件的各个性能指标，从而发现性能瓶颈，为进一步的性能调优提供准确的参考数据。

　　测试模型建立
　　对应用系统系统的测试，因该采取基准测试、单业务负载测试、混合负载测试的顺序来执行。这样做的好处，在单业务负载测试是就可以发现各个系统本身的性能缺陷，而混合负责测试时将重点检查各个业务相互影响导致的性能缺陷。

　　执行模型建立
　　应用系统系统的性能测试必须要局方客户、系统开发商、第三方测试服务商紧密配合，才能保证整个测试工作的成功。因此，只有建立一套规范的性能测试流程，明确各个角色的工作职责，才能使性能测试工作有序、高效的开展。

　　风险模型建立
　　由于性能测试的特殊性，因此在整个测试过程中，会遇到很多导致整个性能测试失败的风险。丰富性能测试经验是必须的，能够提前分析可能遇到的各种风险并制定相应的规避措施。这样才能将性能测试的风险降到最低，最终圆满完成应用系统系统的上线性能验收测试。

 

上来吼一声, 折磨了一个礼拜的WEBLOGIC集群部署今天终于搞定!

LoadRunner常见测试结果分析

   在测试过程中，可能会出现以下常见的几种测试情况：

　　一、当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降这种情形表明：

　　* 从事务响应时间曲线图持续上升表明系统的处理能力在下降，事务的响应时间变长；

　　* 持续平衡表明并发用户数达到一定数量，在多也可能接受不了，再有请求数，就等待；

　　* 当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。

　　如果系统没有这种下降机制，响应时间越来越长，直到系统瘫痪。

　　从以上的结果分析可发现是由以下的原因引起：

　　1. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；

　　2. 内存泄露；

　　二、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常；

　　表明系统中可能产生资源争用情况；

　　引起原因：

　　开发人员注意资源调配问题。

　　三、 所有的事务响应时间、cpu等都很正常，业务出现失败情况；

　　引起原因：

　　数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；

　　当数据量大时，就会出现数据错乱情况。

命苦啊半夜起来跟老美唠嗑, 星期五的都周末了,干了一周累死累活的, 金融危机还小心翼翼生怕一不小心被人给K了, 搞得今天半夜里还跟人家SAY HELLO, 兜着小心, 我容易么我!

什么样的用例是好的用例?

　　一.质量属性

　　Quality Attributes

　　1.正确性：确保测试标题描述部分的内容正确性。

　　2.经济性：只为确定需要的目的设计相应的测试步骤

　　3.适应性：既能适应短期需要，又能考虑长远需要。

　　4.可追踪性：用例能追踪到一个具体的需求。

　　5.自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。

　　二.结构化和可测试性

　　Structure and testability

　　1.含有规范的测试标题和编号。

　　2.含有一个确定的测试某一个特定需求的目的。

　　3.含有关于测试方法的描述。

　　4.指定条件信息-环境、数据、预置的条件测试、安全入口等。

　　5.含有操作步骤和预期结果。

　　6.陈述任何辅助证据，例如截图报告并确保这些东西妥善保存。

　　7.确保测试环境的干净（即用例不会影响整个环境）。

　　8.描述时使用主动语气结构。

　　9.操作步骤不要超过15步

　　10.确保单个用例测试执行时用时不超过20分钟。

　　11.自动化脚本用例添加必要的注释，比如目的、输入和期望结果。

　　12.如果可能，建议提供可选择性的预置条件测试。

　　13.用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。

　　三.配置管理

　　Configuration management

　　1.采用命名和编号规范归档。

　　2.保存为特定的格式，文件类型。

　　3.用例版本是否与当前被测试软件版本一致（对应）。

　　4.包含用例需要的相应测试对象，如特定数据库。

　　5.存档阅读。

　　6.存档时按角色控制访问方式

　Transactions（用户事务分析）：用户事务分析是站在用户角度进行的基础性能分析

　　1、Transation Sunmmary（事务综述）

　　对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。

　　2、Average Transaciton Response Time（事务平均响应时间）

　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。

　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。

　　3、Transactions per Second（每秒通过事务数/TPS）

　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。

　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。

　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

　　4、Total Transactions per Second（每秒通过事务总数）

　　“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。

　　5、Transaction Performance Sunmmary（事务性能摘要）

　　“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。

　　重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。

　　6、Transaction Response Time Under Load（事务响应时间与负载）

　　“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。

　　7、Transaction Response Time(Percentile)（事务响应时间(百分比)）

　　“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。

　　8、Transaction Response Time(Distribution)（事务响应时间(分布)）

　　“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。

　　Web Resources（Web资源分析）：Web资源分析是从服务器入手对Web服务器的性能分析

　　1、Hits per Second（每秒点击次数）

　　“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。

　　通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

2、Throughput（吞吐率）

　　“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。

　　可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

　　“吞吐率”图和“点击率”图的区别：

　　“吞吐率”图，是每秒服务器处理的HTTP申请数。

　　“点击率”图，是客户端每秒从服务器获得的总数据量。

　　3、 HTTP Status Code Summary（HTTP状态代码概要）

　　“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。

　　4、HTTP Responses per Second（每秒HTTP响应数）

　　“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。

　　5、Pages Downloader per Second（每秒下载页面数）

　　“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。

　　和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。

　　注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。

　　6、Retries per Second（每秒重试次数）

　　“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。

　　在下列情况将重试服务器连接：

　　A、初始连接未经授权

　　B、要求代理服务器身份验证

　　C、服务器关闭了初始连接

　　D、初始连接无法连接到服务器

　　E、服务器最初无法解析负载生成器的IP地址

　　7、Retries Summary（重试次数概要）

　　“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。

　　8、Connections（连接数）

　　“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。

　　借助此图，可以知道何时需要添加其他连接。

　　例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。

　　9、Connections Per Second（每秒连接数）

　　“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。

　　理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。

　　10、SSLs Per Second（每秒SSL连接数）

　　“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。

　Web Page Breakdown（网页元素细分）：“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的元素

　　1、Web Page Breakdown（页面分解总图）

　　“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。

　　“页面分解”图可以按下面四种方式进行进一步细分：

　　1)、Download Time Breaddown（下载时间细分）

　　“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。

　　2)、 Component Breakdown(Over Time)（组件细分(随时间变化)）

　　“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

　　3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）

　　“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。

　　“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。

　　4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）

　　“第一次缓冲时间细分(随时间变化)”图显示成功收到从 Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。

　　First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。

　　2、Page Component Breakdown（页面组件细分）

　　“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。

　　3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）

　　“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。

　　4、Page Download Time Breakdown（页面下载时间细分）

　　“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。

　　“页面下载时间细分”图根据 DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。

　　5、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）

　　“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。

　　“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。

　　6、Time to First Buffer Breakdown（第一次缓冲时间细分）

　　“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。

　　网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。

　　服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。

　　7、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）

　　“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。

　　8、Downloader Component Size(KB)（已下载组件大小）

　　“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。

第一部分　　软件测试策略基础

　　为什么要编写测试策略？测试策略就是如何进行软件测试的计划。测试策略的目标包括：

　　取得利益相关者（比如管理部门、开发人员、测试人员、顾客和用户等）的一致性目标；

　　从开始阶段对期望值进行管理；

　　确保“开发方向正确”；

　　确定所有要进行的测试类型。

　　1、策略与软件测试策略

　　（1）策略：在一定的政治路线指导下，根据具体条件而规定的斗争原则、方式和方法。<新华字典>

　　（2）软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

　　测试策略为测试提供全局分析，并确定或参考：

　　项目计划、风险和需求；

　　相关的规则、政策或指示；

　　所需过程、标准与模板；

　　支持准则；

　　利益相关者及其测试目标；

　　测试资源与评估；

　　测试层次与阶段；

　　测试环境；

　　各阶段的完成标准；

　　所需的测试文档与检查方法。

　　2、软件测试策略的重要性

　　（1）任何一个完全测试或穷举测试的工作量都是巨大的，在实践上是行不通的，因此任何实际测试都不能保证被测程序中不遗漏错误或缺陷；

　　（2）为了最大程度较少这种遗漏，同时最大限度发现可能存在的错误，在实施测试前必须确定合适的测试方法和测试策略，并以此为依据制定详细的测试案例。

　　3、软件测试策略的目的

　　是不是所有软件测试都要运用现有软件测试方法去测试呢？答案是否定的。依据软件本身性质、规模和应用场合的不同，我们将选择不同测试方案，以最少的软硬件、人力资源投入得到最佳的测试效果，这就是测试策略的目标所在。

　　4、软件测试策略的影响因素

　　软件测试策略随着软件生命周期的变化、软件测试方法、技术与工具的不同发生的变化。这就要求我们在制定测试策略时候，应该综合考虑测试策略的影响因素及其依赖关系。这些影响因素可能包括：测试项目资源因素、项目的约束和测试项目的特殊需要等。

5、软件测试策略的制定过程

　　（1）输入

　　需要的软硬件资源的详细说明；

　　针对测试和进度约束而需要的人力资源的角色和职责；

　　测试方法、测试标准和完成标准；

　　目标系统的功能性和技术性需求；

　　系统局限（即系统不能够提供的需求）等等。

　　（2）输出

　　已批准和签署的测试策略文档、测试用例、测试计划；

　　需要解决方案的测试项目；

　　（3）过程

　　1）确定测试的需求

　　测试需求所确定的是测试内容，即测试的具体对象。在分析测试需求时，可应用以下几条一般规则：

　　测试需求必须是可观测、可测评的行为。如果不能观测或测评测试需求，就无法对其进行评估，以确定需求是否已经满足。

　　在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求；有些补充需求将派生一个或多个测试需求，而其他补充需求（如市场需求或包装需求）将不派生任何测试需求。

　　测试需求可能有许多来源，其中包括用例模型、补充需求、设计需求、业务用例、与最终用户的访谈和软件构架文档等。应该对所有这些来源进行检查，以收集可用于确定测试需求的信息。

　　2）评估风险并确定测试优先级¤

　　成功的测试需要在测试工作中成功地权衡资源约束和风险等因素。为此，应该确定测试工作的优先级，以便先测试最重要、最有意义或风险最高的用例或构件。为了确定测试工作的优先级，需执行风险评估和实施概要，并将其作为确定测试优先级的基础。

　　3）确定测试策略

　　一个好的测试策略应该包括：实施的测试类型和测试的目标、实施测试的阶段、技术、用于评估测试结果和测试是否完成的评测和标准、对测试策略所述的测试工作存在影响的特殊事项等内容。

　　如何才能确定一个好的测试策略呢？我们可以从基于测试技术的测试策略、基于测试方案的测试策略两个方面来回答这个问题。

　　①  基于测试技术的测试策略的要点

　　著名测试专家给出了使用各种测试方法的综合策略：

　　任何情况下都必须使用边界值测试方法；

　　必要时使用等价类划分方法补充一定数量的测试用例；

　　对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，看是否达到了要求；

　　如果程序功能规格说明中含有输入条的组合情况，则已开始可以选择因果图方法。

　　②  基于测试方案的测试策略

　　对于基于测试方法的测试策略，一般来说应该考虑如下方面：

　　根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点；

　　认真研究，使用尽可能少的测试用例发现尽可能多的程序错误，避免测试过度和测试不足!

　　第二部分　　测试策略的方法

　　软件测试的策略、方法和技术是多种多样的。对于软件测试技术，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试。从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。

　　1.  静态方法与动态方法

　　所谓静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

　　动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。

　2.  功能测试与结构测试

　　（1）功能测试

　　功能测试是指在对程序进行的功能抽象的基础上，将程序划分成功能单元，然后在数据抽象的基础上，对每个功能单元生成测试数据进行测试。用这种方法进行测试时，被测程序被当作打不开的黑盒，因而无法了解其内部构造，因此又称为黑盒测试。

　　黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当接收输入数据而产生正确的输出信息，并且保持外部信息的完整性。

　　在功能测试中，被测软件的输入域和输出域往往是无限域，因此穷举测试通常是不可行的。必须以某种策略分析软件规格说明，从而得出测试用例集，尽可能全面而又高效地对软件进行测试。下面就说明几种功能测试的方法：

　　a.  等价类划分

　　所谓等价类，就是指某个输入域的集合，集合中的每个输入对揭露程序错误来说是等效的，把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例，这就是等价类划分方法。它是功能测试的基本方法。

　　b.  因果图法

　　因果图是一种形式语言，由自然语言写成的规范转换而成，这种形式语言实际上是一种使用简化记号表示数字逻辑图。因果图法是帮助人们系统地选择一组高效测试用例的方法，此外，它还能指出程序规范中的不完全性和二义性。

　　c.  边值分析

　　实践证明，软件在输入、输出域的边界附近容易出现差错，边值分析是考虑边界条件而选取测试用例的一种功能测试方法。所谓边界条件，是相对于输入和输出等价类直接在其边缘上，稍高于和稍低于其边界的这些状态条件。边值分析是对等价类划分的有效补充。

　　（2）  结构测试

　　结构测试是根据被测程序的内部结构设计测试用例的一类测试，又称为白盒测试。白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。其主要方法有逻辑驱动、基路测试等，主要用于软件验证。白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。白盒法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。

　　与功能测试不同的是，结构测试涉及程序内部结构。尽管用户更倾向于基于程序规格说明的功能测试，但是结构测试能发现潜在的逻辑错误，而这种错误往往是功能测试发现不了的。它们各有利弊，常常结合使用。

　　第三部分　　测试策略文档范例

　　●  测试目的：

　　（1） 测试的范围，哪些功能要包括在内，哪些要排除在外

　　（2） 谁是客户和最终用户，谁就是测试结果的验收者

　　（3） 测试的次序和日程安排

　　（4） 验收的条件，成功因素，限制

　　●  资源需求：

　　（1） 制定计划和运行测试需要哪些技术和经验

　　（2） 相关人员的角色和责任

　　（3） 谁将对测试工作进行全盘协调

　　（4） 谁负责测试资料管理，版本控制，错误跟踪

　　●  测试环境：

　　（1） 用于测试的系统配置怎样

　　（2） 需要什么自动化工具

　　（3） 需要哪些测试数据（数据库和输入交易），如何安装

　　（4） 您如何前调系统时钟

　　●  测试过程：

　　（1） 运行测试时要遵循哪些过程（设置、执行、记录）

　　（2） 测试案例如何制定，其标准格式是什么

　　（3） 测试案例定义的覆盖要求是什么

　　（4） 遇到问题如何决定其严重程度，对问题如何处理

　　一个人从大学毕业，即开始发生从学生时代向职业人士的过渡，这种过渡走的好，可以实现毕生宿愿，体现个人价值，不管你是否喜欢，功名、利禄尽收眼底；如果走的不好，则会误入歧途，纵有凌云壮志、万丈豪情，难免一生郁郁不得志，终归化作片片飞尘，无语对穹苍！那么如何才能顺利的完成这种过渡、踏上我们豪迈的职业旅程呢？答曰：认清自己，选择适途！战国的魏人荆轲具有“十步杀一人，千里不留行”的本领，曾向魏王献策曰：“国君，我是职业杀手，我杀人的技术很强！”魏王问：“那么你想杀谁呢？”对曰：“杀他个国君如何？”魏王大惊，慌然离去！后来荆轲离开魏国，与燕太子丹密谋，留下了“图穷匕首见”、“荆轲刺秦王”的千古佳话。荆轲，良禽也，择木而栖和太子丹合作，是他的高明之处；不过笔者认为他是一个典型的“低管理、高技能”的人才，当他紧握嬴政的脖领、持剑相逼时，他太得意忘性了，可见他没有领导的“统御力”和“决断力”，所以落了个刺杀失败、拔剑自刎的下场，虽然他的侠义与胆识流畅千古，但是终究是个“杀手”而已；当今社会下，如果“低管理、高技能”的人干工作干到丢了性命，那也真是一个笑谈了！ 
　　目前我们国家高等学历大幅度扩招，造成社会的低端人才严重过剩，大学生毕业找不到工作、或者找不到合适的工作例子鳞次栉比；但是社会各行各业对高端人才的需求又求贤若渴；那么如何解决这种矛盾呢？从大环境来说，国家应该改革教育体制、提高教学质量、重视高端人才的培养，但是，一个问题一旦上升到国家的层次，就要等它个十年八年！我们没有办法改变世界，但是我们有能力改变自己；所以我们从个人的角度来讲，讲讲我们这些软件测试的从业者们，如何“认清自己、选择适途！” 
　　纵观当今社会各行各业，对于个人的职业发展方向，从宏观上都可以划分为四个群体，即： 
　　“低管理、低技能” 
　　“高管理、低技能”  
　　“低管理、高技能” 
　　“高管理、高技能” 
　　而在IT 行业这种划分方法更为合理，sincky为其命名为“一起点-三方向示意图”： 
　　告别了象牙塔，带着对校园生活里那段风花雪月的追忆，年轻的毕业生们走上了社会；这时候的年轻人，大多数是属于“低管理、低技能”的群体，我们没有工作经验，不知道企业的工作流程，不清楚各个职业的工作技能，更不具备任何行业的管理能力；然而值得庆幸的是，人类问明发展到现在所出现的众多行业，都已经有了众多可以参考的群体，这些群体就理所当然的成了我们可以借鉴的发展方向！虽然我们的起点都是一个，但是可以选择的发展方向却是丰富多样！ 
　　高管理-低技能，即是我们通常所说的管理路线！在IT业，这个方向的成功者不乏项目经理、项目总监直至企业的最高管理层；但是走这个方向也要有技术方面的积累，因为管理者的影响力中，除了职位赋予的权力以外，还包括个人人格方面的能力和专业领域的专业能力，而后者就是技术水平！而计算机行业本身，也决定了技术底蕴对职业发展的重要影响，所以年轻的IT朋友们，如果想为自己的职业人生设计成这个路线，除了适当的技术积累外，更要有意识的锻炼自己的管理素质，下图可做参考： 
　　低管理-高技能，即通常所说的技术路线！IT业以技术为主导，对于喜欢钻研技术、探讨技术的人，可以选择该条路线，走的深入、走的彻底！只因中国对于技术与管理的认识不同，造成很多人认为做技术不赚钱、不被重视，自身误以为不过是个工程师而已，所做事情只是辅助企业的运作。实际上，在欧美发达国家，资深技术人员的薪资非常高，从业时间的周期也相当长，在Microsoft、IBM等巨头企业，不乏年龄在50岁以上的资深程序员或系统架构师，而其薪资也和高级管理者一样高！而另外一个不争的事实是，企业对于管理的职位是有限的，并且一些优秀的技术人员不愿做管理，或者不适合做管理，因此社会上出现的资深技术专家（或者类似职位），为喜好技术的从业人员提供向上的通道。 
　　高管理-高技能，即咨询方向是较为均衡、全面的路线，也是众多企业希望员工努力的方向。然而有调查结果显示，由于现实种种因素的制约，大约90％的个人是分别沿着管理方向或者专家方向发展的，真正实现在咨询方向达到一定的高度的人少之又少，而且在这为数不多的咨询方向达到又一定高度的人才，往往又会由于企业资源的限制无法将个人价值完全发挥而最终离开所在企业，成为专业培训师、咨询师；一些国际知名的咨询公司如麦肯锡、安达信乃至毕博或其他，可谓大家在个人职业生涯到达一定阶段，作为自己继续突破职业瓶颈的发展路线。 
　　那么，对于软件测试的从业者，我们的出路在哪里？我们的职业发展该如何设计？我们的发展方向又有哪些呢？这里笔者和大多数测试同行意识相同，笔者也曾在多篇文章里标明，中国的软件测试行业尚属起步阶段，其发展的步履上布满了荆棘与泥泞；然而其发展速度可谓惊人的，从笔者刚毕业时候对软件测试的“0”概念、从业同行者寥寥无几，到最近2年的各大媒体纷纷报道的中国软件测试人才缺口20万、软件测试工程师将成为未来10年最紧缺的人才之一、包括笔者所接触的众多国内外优秀企业对高端测试人才年薪10万、15万、20万的招聘需求……可见，选择软件测试这个朝阳行业的朋友，做了一个比较正确的选择！然而，如何任何事物总有它的两面性和矛盾性：2006年初在北京、上海、深圳举办的几次春季大型招聘会上，多家企业纷纷打出各类高薪招聘软件测试人员的海报，出人意料的是，收到的简历尚不足招聘岗位数的50％，而合格的竟不足30％……引起我们思考的是，我们的软件测试从业人员还有很大一部分不满足当今社会的需求；而另一层含义是，我们还有很大的提升空间！因此解决该矛盾的突破点是：每个人在这个行业里找到自己的发展方向，规划自己的职业蓝图，从而有针对性的锻炼自己的职业技能，增加个人的职业砝码！ 
　　软件测试职业发展方向，大体上与上述的通用职业发展路线图相吻合，也可以分为管理路线、技术路线、管理+技术路线；只是针对该行业本身，有其特殊性和细致性。其图示如同两个重叠的”V”字样，我们为其命名为“双V模型”；该模型适用于大多数行业性软件测试从业人员，一些特殊领域如游戏测试、嵌入式测试、硬件测试，也可作为参考。本文是三部曲之一，只介绍职业发展方向定义，在下一曲会介绍各个职业方向应该具备的知识与技能体系！ 
　　双V的底点是测试工程师，属于软件测试职业生涯的初级域，其适用范围是入行软件测试3年内的常规测试从业者，其主要工作内容是按照测试主管（即直接上司）分配的任务计划，编写测试用例、执行测试用例、提交软件缺陷，包括提交阶段性测试报告、参与阶段性评审等。初入测试行业，进入企业从事测试工作的人员，都要从该层次做起，虽然有时感觉乏味无趣，甚至迷茫困惑，但是我们可以根据个人的兴趣与特长，向上选择适合自己的路线，因为谁都不会甘心一辈子只做一个普通的测试工程师，那么大家看到这里，就可以摩拳擦掌，看看向上发展的通道中，哪一个适合自己，然后立刻从现在开始，确定自己未来5年、10年甚至一生的发展目标迈进，用笔者经常跟学员说的一句话来形容：把握现在，即刻做起，相信自己是最强的！ 
　　首先是常规路线，即双V模型的重叠线，这条发展路线要求管理与技术并重，因为软件测试的行业特点决定了这个因素：测试工程师向上晋升到测试主管、测试经理、测试总监，直至咨询域的更高方向！ 
　　测试主管是企业项目级主管，对于中小型软件公司也可以是企业级主管，属于中级发展域，适用范围是2到5年职业经验的测试从业者。其工作内容是根据项目经理或测试经理的计划安排，调配测试工程师执行模块级或项目级测试工作，并控制与监督软件缺陷的追踪，保证每个测试环节与阶段的顺利进行。严格来说，这个级别更多属于测试的设计者，因为企业的测试流程搭建是由更高级别的测试经理或相关管理者来做的，测试主管负责该流程的具体实施；而更多的工作，是思考如何对软件进行更加深入、全面的测试。因此笔者认为测试主管比较有创造性的工作内容就是测试设计，而恰恰很多公司忽略了或没有精力来执行此工作内容！应该说，在一个企业里做了3年左右测试工作的人员，很容易晋升到该职位，而之所以晋升，是与个人测试技术的过硬、测试方法的丰富，加上对测试流程的监控力与执行力的职业素质息息相关！ 
　　测试经理是更高级别的测试管理者，属于高级测试方向域。对于大中型软件公司，该职位尤为重要，并且对其职业要求也比较高，一般适合4到8年的测试从业者，在管理与技术能力双双比较成熟的情况下，可以结合具体环境晋升到该级别。测试经理负责企业级或大型项目级总体测试工作的策划与实施。随着软件行业的发展，企业对软件工程里各个角色的定位逐渐明显，测试经理完全与开发经理（一些公司也成为项目经理）平齐，除了需要统筹整个企业级或项目级测试流程外，还要对于不同软件架构、不同开发技术下的测试方法进行研究与探索，为企业的测试团队成员提供指导与解决思路，同时还要合理调配不同专项测试的人力资源（如业务测试工程师、自动化测试工程师、白盒测试工程师、性能测试工程师），对软件进行全面的测试；另外，一些企业里，测试经理还需要与客户交流与沟通，负责部分的销售性或技术支持性工作。嘿嘿，看看那些高薪招聘测试经理的企业对该职位的要求里外语口语的描述，就可见一斑！ 
　　测试总监，属于常规发展路线的最高域，如果再往上发展，那只能是咨询域了；不过笔者并没有将其在图中标记出来，因为该职位对于国内目前的大多数软件公司根本没有设立，也就没必要再在图中体现了。该职位一般在大型或跨国型软件企业，或者专向于测试服务型企业有所设立，由于其企业自身的职位定位不同，以及软件测试整体行情所处的阶段，这里不好归纳陈述；但是一般设立测试总监的企业，该职位都相当于CTO或副总的级别，是企业级或集团级测试工作的最高领导者，驾驭着企业全部的测试与测试相关资源，管理着企业的全部测试及质量类工作。而其职业要求，也是技术与管理双结合；基于目前软件测试行情看，这种高管理-高技能的发展目标，不会适合大多数人的选择，社会也不会提供如此众多的测试总监职位让我们去应征！ 
　　应该说，大多数测试从业者都不是技术与管理双优的人，而如今一些到达测试经理或测试总监级别的优秀测试人才，已经领先一步开辟了这条发展路线的先河，希望这些朋友和大家多多分享经验，让更多的朋友弥补自己管理或技术上的不足，在这条路线上有所建树，共同提高，在实现个人人生价值的同时，也自然而然的推动了软件测试行业的发展；行业发展了，测试人员不再被忽视了，待遇自然也提高了，也就不会有很多朋友迷茫的跟我说“我的日常工作只是点击按钮和按键盘”了，因为我们相信行业的不断成熟，会逐渐将软件测试职业细化，我们的从业者就可以真正的在如下的管理路线和技术路线找到自己的位置，并潜心走向深入的！ 
　　软件测试，是技术主导的职业；不管选择哪条发展路线，都是需要一定的技术沉淀，只是相对来说，管理路线对技术方面要求不高而已。那么我们就先挑重头的技术路线展开讨论。一般来说，一个普通的测试工程师刚入行，3个月左右熟悉企业的工作流程和模式，那么今后的工作内容趋于平稳。然而社会是残酷的！如果单单停留在测试工程师的阶段，若干年后，相信你再也竞争不过那个时候的应届毕业生，当你的工作技能和职业素质趋于与那些朝气蓬勃的年轻人相当时，企业会毫不留情的选择他们，而release你，因为你的成本消耗要比他们高，这是大实话！然而现实又是公平的！因为软件开发技术的不断日新月异，软件功能需求的不断丰富多样，决定软件开发这一系统工程的错综复杂，因此为了保证软件的质量，就要提高测试的水平，这也就为软件测试职业的细化起到先决因素，也是目前社会上出现招聘专项测试工程师的必然趋势！因此，这个趋势给了我们这些常规测试工程师一个空前的好机会！所谓“以毒攻毒”，软件开发靠的是技术，为了测试软件，也必须用技术；那么我们就来看一下从技术路线，软件测试职业发展有哪些方向。 
　　技术路线，笔者结合国内外软件测试行业现状，划分为三个半方向，分别是自动化测试工程师、白盒测试工程师、性能测试工程师和认证测试工程师，在“双V模型”中右侧体现；前三者适用于通用软件测试领域，认证测试工程师乃嵌入式测试领域职位，至少目前仅出现在嵌入式领域，因此以虚线标记，即“三个半”的“半”。前三条路线对技术的要求程度逐渐增加，三条曲线的斜率也依次递增（认证工程师不参与比较）。 
　　自动化测试工程师，笔者为其定义在功能测试范畴，指通常所说的依靠自动化测试工具进行软件黑盒测试的工程师。笔者接触的很多测试界朋友，尤其年轻的刚入行者，对测试工具充满了无限的兴趣，他们喜欢那种编写脚本、调试成功后的快感，喜欢看到自定义的日志里记录了本来手工测试烦琐的无聊头顶的工作、而采用自动化方式实现后如此清晰丰富的内容后的兴奋！可以理解，因为笔者也是从那段时光走过来的，现在也负责于我们学员的自动化测试教学工作。从大环境讲，自动化测试是软件测试执行阶段的必然趋势，社会对于软件测试的认可度以及对自动化测试人才的需求必将日益增加，从目前国内做自动化测试的从业者薪资情况看，也普遍高于常规测试工程师，最浅显的道理是“自动化测试比手工测试有了技术含量，^--^”虽然自动化测试在整个行业的普及不是一朝一夕，但是从个人角度讲，自动化测试可以作为个人的发展方向之一，因为如果你率先掌握了这种技术，等到社会需要时，你已成为这个职位的成熟操作者！而国内的51testing把握了时代前沿，与自动化测试工具巨头厂商Mercury（美科利）合作，在中国唯一推出Mercury自动化测试全套技能认证（CPE/SP/CPC），相比其它初等认证，它的实效性和价值性更具意义，也为测试从业者提供了一个进入自动化测试领域的快捷方式！ 
　　白盒测试工程师，笔者定位于在软件测试周期的单元测试阶段对软件进行的代码级测试的人，包括代码走读、代码功能与逻辑测试、代码内存泄漏检查、代码运行效率检查、代码测试覆盖率分析等。如果说，自动化测试只是依靠脚本语言完成测试脚本编写与调试的过程（因为自动化测试工程师的工作重点不在编写脚本），对于自动化测试工程师的技术要求要相对偏低的话，那么白盒测试工程师就要对大型程序开发语言的完全掌握，因此其技术要求相对偏高！而另一方面，白盒测试在目前国内软件行情下，一些公司根本不做，其成本高、代价大的特点决定了这个现状，而一些对软件质量要求非常高（如军事类、电信类、财务金融类等）的企业，也会调动开发工程师来实施此事。但是，还是那句话，测试行业在发展，测试人员能力在提升，软件的开发技术在复杂化，要对软件进行尽可能全面的测试，白盒测试不可忽视！当下专门高薪招聘白盒测试工程师的企业也比比皆是，从中我们可以感知，白盒测试工程师会是很多有开发背景、意欲进入测试行业的良好突破口，白盒测试人员的需求也会逐渐增加。 
　　性能测试工程师，即在系统测试阶段、功能测试后对软件系统性能指标进行采集分析和运行效率检测的人。笔者认为，在一个尽量压缩的测试流程里，功能测试可以手工进行，白盒测试可以不做，但是性能测试必须要做，除非该软件非网络类软件即单机版软件！这里笔者再提一个观点供大家参考：软件测试，从宏观上可以划分为三个大方面：功能测试、性能测试、安全性测试，功能测试说明软件做对了，功能测试+性能测试说明软件做好了，三者结合起来说明软件做的非常好！安全测试暂且抛之不提，这是下一个发展域的内容，但是为了把软件做好，为了真正保证软件的质量，性能测试绝不容忽视；只因目前很多企业由于时间、成本、人力条件的限制，暂且不做性能测试。性能测试工程师相对来说，是三个技术路线里技术要求最高的，因为软件的性能瓶颈归根结底落实到代码的运行效率这个问题上，因此性能测试要做好，性能测试工程师起码要懂开发；而为了发现性能问题，要懂软件开发架构；为了定位性能问题，要懂操作系统、网络协议、应用服务器乃至数据库的原理与使用；为了最终解决性能问题，要根据定位的问题有针对性的对代码、操作系统、网络架构、服务器、数据库进行优化！当然性能测试是一个系统工程师，绝对不是一两个人的事情，对于常规性能测试工程师，具备定位性能问题的能力即可。正因为性能测试工程师技术要求的高超，该职位的待遇也是目前测试技术路线最高薪的一个，实为综合技术能力较强的测试人员的明智选择！ 
　　上述四职业路线由于其技术程度的突出，一般在企业里由测试经理直接所属，与测试主管级别具有相同的待遇，并处于相同发展域。 
　　进入技术路线的高级域，根据中级域的四个路线，可以细分成五个路线，分别是资深自动化测试工程师、资深白盒测试工程师、资深性能测试工程师、安全性测试工程师、标准化工程师，这些高级技术类人才完全与常规测试经理平齐，属于软件测试职业发展高级域。 
　　资深自动化测试工程师由自动化测试工程师晋升而来。如果说常规自动化测试工程师只是负责自动化测试脚本本身的设计与开发，那么资深自动化测试工程师的工作内容就是自动化测试这项工作的实施！笔者早年在IBM公开讲座时候，讲过一篇《以RUP原则实施自动化测试》的主题，RUP里提倡自动化测试是一个庞大的系统工程，绝对不是有了技术、有了工具、有了掌握技术和使用工具的人就可以实施的，而是应该把自动化测试当成一个针对企业自身的项目来看待，需要经过引入、计划、设计、测试、执行、配置管理等环节（参加sincky的blog“天行健-君子以自强不息”），而这些自动化测试的流程搭建，就是资深自动化测试工程师的份内之事。另外，笔者要强调，按照国内外自动化测试领域的发展趋势，我们把自动化测试划分为四个发展阶段（我的blog里也有阐述）；也就是说，录制脚本-添加验证点-回放脚本只是最初始的自动化阶段，要在企业实施自动化测试，要有资深自动化测试工程师来设计数据驱动，开发测试框架，甚至一些企业内部自主开发小型测试工具（而非商业工具）的先例，这些也都是建立在资深自动化测试工程师具有深厚的技术底蕴后，主导其他人员协调完成的事情。 
　　资深白盒测试工程师，其工作内容包含常规白盒测试工程师的内容，除此之外，要协助测试经理或测试总监攻关测试方法与技术性难题，因此其技术水平更加雄厚。如果常规白盒测试工程师是停留在某种程序设计语言类型的代码级测试，那么资深白盒测试工程师就要脱离程序设计语言本身，结合不同架构、多种开发技术交互的情况下，寻找代码测试方法，并具有对代码优化的能力。由于该路线在国内很少有实例参考，这里不再赘述。 
　　资深性能测试工程师，来源于常规性能测试工程师，按照常规性能测试工程师的技术要求，资深性能测试工程师应该具备性能测试整体方案的设计能力，以及软件系统性能问题定位和性能优化的能力！初此之外，也要对主流的软件开发模式下的应用系统具有敏锐的洞察意识和感知意识。软件开发的架构会日益复杂化，软件应用的各种软硬件平台、数据库类型、服务器类型、网络协议层出不穷，不得不说，都为性能测试的从业者们提出了严峻的考验！值得庆幸的是，各种同类产品的厂商在开发产品时都遵从业内统一标准，性能测试人员结合自身的丰富经验，加上对软件性能测试技术的研究，这样的考验我们欣然面对，这样的人才则会日益增多，在软件测试行业里充当佼佼者地位。 
　　安全性测试工程师，笔者将其从性能测试工程师衍生出来，因为只有具备性能测试经验的人，才对软件的开发模式、实现架构和技术本身充分了解，才会感知和预见软件系统存在的安全漏洞，加上其本人是测试出身，才知道如何通过系统漏洞尝试攻击软件系统，达到测试的目的。目前国内软件行业对于安全性测试的认识尚未清晰，该职业也更没有普及，一般只限于军事类、机密类、防病毒类或其他高安全性软件的测试工作中。 
　　再次强调，人类进入文明社会后，任何社会活动都不是独立的个体能够实现的；在高度讲究团队合作、协同办公的今天，软件测试工作更不是测试工程师几个人就能做完所有的事情的；上述各发展路线的技能要求，只是为了增强个人职业突破的砝码，你的砝码越多，“被利用”价值越大，为企业创造利润的程度越高，企业自然给予你更丰厚的回馈！达尔文伯伯的“优胜劣汰”自然规律不会变，“多劳多得、少劳少得”的市场规律也不会变！ 
　　曾经有如此众多的测试职业发展路线放在我面前，结果我没有珍惜；等到软件测试行业发展到成熟阶段，我想入行却入不了行的时候，我才后悔莫及；尘世间干测试最大的不幸莫过于此；如果非要问sincky：再往上的发展通道是什么，那么sincky一定要告诉你，技术专家域！ 
　　在技术路线，向上继续提升的方向，我们称之为“技术专家”；如果说前面描述的技术职位的所涉范围都定位在企业内部，即企业级资深性能测试工程师，那么技术专家，我们可以看作是领域级专项人才！随着软件测试行业的职位不断细化，每个人在自己擅长的领域走向深入，都可以成为该领域的技术专家，技术专家在自已经营的领域里，具有个人独到的见解和深厚的技术实力，而这类人才可以不再从事具体的测试工作，而是提供行业性测试技术咨询、培训等，为软件测试整体行业的发展，起到了鲜明的带头作用。在一些专业的咨询、培训公司，或者IBM、Microsoft等巨型公司，不乏这样的人才；然而目前在我国，这样的人才较少，但是却可以为我们大家提供努力方向，只要我们每个在技术路线供职的测试从业者，规划好自己的职业人生，并以坚韧的毅力和顽强的斗志，若干年后，你我皆可笑谈测试人生，把酒临风，其喜洋洋者矣！而目前在国内几个IT行业发达的省市，专项于软件测试服务或一些大型软件企业，也有这样的职位暂露头角，我们深信，社会对高端人才的需求趋势是越来越大的，更多的优秀企业也会为员工提供更多、更广的发展空间，值此大好形势，就看我们个人如何充分利用这些上升通道了。 
　　在我们的软件测试从业人员里，有这样一部分群体：他们非计算机相关专业毕业，不懂软件开发，由于国内种种对软件测试人才的偏激认识，认为测试人员不需要懂开发，只要会编写文档、执行用例即可；因此很多测试工程师并不具备开发背景，并且对软件技术掌握肤浅，而对于没有技术底蕴的人强迫其走技术路线，不能不说是一种折磨！因此，这个群体里的朋友，是不是认为自己只能做一辈子常规测试工程师呢？答案是否定的，因为在“双V模型”的左侧，是软件测试职业发展的管理路线。软件测试的管理路线，与通用职业发展示意图的“高管理-低技能”并不完全相同，只因软件测试独具的行业特点，我们认为软件测试行业的非技术路线发展方向，更多的是从软件测试行业衍生出来的职位，如质量保证、配置管理。如果说软件测试职业发展的技术路线更侧重于职业技能的提升，那么这条管理路线则更侧重于职业素质的积累（笔者强调是“侧重”，并不表示不需要）；换句话说，技术路线更侧重人的智力因素，而管理路线更侧重人的非智力因素。 
　　从事了1到3年左右的常规测试工程师，在经过对个人性格特点剖析后，如果认为自己是一个倾向于“高管理-低技能”的类型，那么想要实现自己的职业提升，可以向中级发展域的配置管理工程师、质量保证工程师、业务测试工程师转型。 
　　配置管理(SCM)与质量保证(SQA)同是CMM中的关键过程域（KPA），也同是现代软件工程里的必要角色，与软件测试同属软件开发团队的重要组成部分。只因这两个角色在软件工程里的人员配比数量相对较少，还不如软件测试这样规模化乃至于形成行业，而最多是一个职业；另外一个社会现象是，企业很少直接从社会直接招聘配置管理工程师和质量保证工程师，而通常的做法是从企业内部的现有测试员工队伍里选拔，而转型后的测试工程师，就成为SCM或SQA。分析其原因，我们可以感知，SCM、SQA与软件测试工程师都是关注于软件质量的相似职位，社会对于配置管理、质量保证的定义和工作内容并未普及，与其直接从社会招聘“0”基础的人来培养，倒不如从软件测试人员里升华！一般来说，这两种职位的上报对象是项目经理或相同级别管理者。 
　　转型后的配置管理与质量保证工程师，一定要转变一个意识，那就是常规测试工程师的工作范围很大一部分（不是全部）只限于测试流程，而配置管理和质量保证的工作范围是面向整个软件开发流程，二者的职业要求都非常重视软件工程知识体系的建立和软件开发总体流程的实施能力。由于配置管理工程师除了企业配置管理流程的搭建与实施外，一般会涉及配置管理工具的管理与维护，而质量保证工程师更多的工作是软件开发流程的控制与维护，故而配置管理对技术的要求稍高于质量保证。随着我国软件行业水平的不断发展，众多软件公司纷纷通过CMM/CMMI，企业对于软件开发团队的角色配比制度也将逐渐健全，当前社会对配置管理与质量保证工程师的职位需求日益增加，种种现象表明，对于软件测试工程师出身的从业者，转型至SCM/SQA不失为突破个人职业生涯瓶颈的又一通道！ 
　　业务测试工程师，笔者定义为面向行业类软件业务逻辑与工作流测试的人员。当前软件开发类型，很大一部分是行业类软件的应用，如ERP、SCM、CRM、OA、电信、金融、财务、嵌入式、通信、手机、游戏……这就要求从事行业类软件测试的人员具备行业背景、业务知识，熟练该行业工作流程。从社会上出现的很多对此类经验要求的测试工程师招聘信息中，我们更加肯定这种趋势；所谓存在即是道理，既然社会上有了需求，那么就可以作为个人发展的方向。而另外一个特点是，业务测试工程师的工作内容主要是黑盒测试，属于功能范畴，因此对技术要求不大，设置一些大型行业类软件公司的业务测试工程师薪资丰厚，但是完全可以不懂技术，因为它的工作性质决定了不需要懂很多的技术！他们甚至连软件的界面测试都不做——交给常规测试工程师实施，而完全关注软件的业务性和易用性，由于其深厚的行业背景，可以为软件的在正式发布前提出很多建设性的意见，而这些建议正是软件开发商提高产品易用性、增加用户满意度、开拓市场、创造利润的关键因素之一！ 
　　当管理路线的中级域方向继续上升至高级域，就分别到达配置管理经理、质量保证经理、产品经理、业务专家，这类人才地位高、待遇厚，一般资深的软件工程领域专家都聚集于此。 
　　如果说配置管理工程师、质量保证工程师更加侧重于配置管理流程、质量保证流程的实施与日常管理维护，那么配置管理经理、质量保证经理就是更侧重于配置管理流程、质量保证流程的建立与改进。一般在中小软件企业，可能没有这两个角色，而全部的配置管理或质量保证工作都由工程师担当；但是大中型软件企业对资深配置管理经理、资深质保经理求贤若渴。软件系统越庞大，软件开发团队规模就越庞大，软件开发流程中出现问题的几率就越高，高效管理软件开发流程，不断改进软件质量，是每个软件公司在技术上没有顾虑后的下一个急需攻破的难关！ 
　　 业务专家，属于行业内咨询、顾问的角色，已经几乎脱离了测试工作本身，而更多为企业的产品需求分析、设计、开发、测试等各个环节提供指导工作，其目的也是提高软件的易用性和稳定性，减少后期不必要的需求变更。该职位也同样在目前热点行业的大中型软件企业有所设立。 
　　产品经理，这个职位在很多企业有所设立，笔者认为它是质保经理的派生，只是它更侧重于软件在产品化之前的质量监控工作，包括软件开发流程、软件测试等技术与管理的各个方面。由于该职位在业内没有明显定义，而根据不同企业的职位定位不同，这里无法统一陈述。 
　　管理路线的最高发展域是咨询域，与技术路线的专家域类似，在配置管理、质量保证、软件产品化、行业领域达到高深造诣的人才，他们有丰富的从业经验、深厚的管理底蕴，具有对软件工程高瞻远瞩的慧眼和胆识，往往供职在专业的咨询与培训公司，提供IT业管理类咨询与培训的服务，推动着软件行业的前进。国内外很多为软件企业进行CMM咨询和实施的公司里，就是这些人才的大本营之一！ 
　　笔者认为，在“双V模型”的管理路线里，中低级发展域的人才对技术与管理的区分较为明显，而到了高级与更高级发展域，更多的是复合型人才，软件业以技术为主导，没有一定技术积累，还是很难达到高级境界；要在管理路线练出“上乘武功”，还是希望大家在主攻管理与流程类课题的同时，多丰富下自身的技术层面，嘿嘿！ 
　　另外，笔者提倡管理与技术两条路线的平齐，而并非目前社会上认为的技术要比管理低一等，技术是靠吃青春饭，在这些人才到达最高发展域的“咨询”与“专家”层面，二者应该完全具有相同的地位和待遇，只是“称谓”不同罢了！ 
　　“双V模型”是sincky结合当前国内外软件测试行业现状提出的职业发展流程图，仅供测试从业者参考，并非一个“死”的框架，大家不要拘泥于流程图本身；其实目前国内很多上升到高级域或最高域的资深人才，很多都是跳跃式、甚至跨越式的职业发展，因为命运掌握在自己手里，任何人都剥夺不了设计自身人生蓝图的权利；而另外一个角度是，任何人都不该不珍惜为自己规划职业生涯的机会！ 
　　 软件测试，一个日出东方的国际型行业，虽然偶尔会弥漫晨雾，甚或有暴雨来袭，但是我们都该坚持！有人说：“什么叫失败？”答曰：“放弃就是失败！”每一次当我们身处逆境时，决不能用软弱的眼泪作为走向明天的见证，更不能用脆弱的感情去拴住生命的航线；是雄鹰就该搏击长空，是蛟龙就该挽起狂澜；沧海横流，方显英雄本色，疆场搏斗，可露壮士肝胆！人生没有豁免权，每位从业者只有怀着不息的斗志，乘千里长风，破万里巨浪，才能支配命运走向辉煌的明天！ 
　　 后记：sincky，网名叶赫华；在我从事软件测试培训业的1年多里，接触了国内很多除了我们学员以外的软件测试界朋友，其中新手居多。在我们的网站、论坛、我个人的blog、我的qq群乃至其他朋友以我名义建的qq群里，最让大家感冒的话题就是测试人员的职业发展！大家都在做测试工作，可以不知道明天做什么，明年做什么，或者若干年后做什么！“行有行规”，除非不在软件测试这个行业，否则就要遵守这个行业的规律！我觉得，我们的学员有职业发展培训课程，可是面对外界这些热心朋友的提问，长久以来，我一直想集中的写点东西，起码让刚入行的新手对这一行业的职业发展方向有一个直观的感性认知，我也心满意足！但是这个行业还太嫩，并没有章据可循，我搜索了几天的国外网站，可是没有成文的观点可以参考！后来决定自己来写，参照的对象就是国内现状下的测试从业者，于是在和国内各个领域的测试高手朋友们的交流后，我在2006春节前夕用了一白天的时间画出了“双V模型”图，而这篇文章的撰稿，用了我一天一夜的满满时间。在经历几次修改后，这篇文章在今天终于正式发布了，没有别的，只是希望给国内测试界朋友一个参考，欢迎大家批评、讨论，发表自己的观点！（我的msn地址：sinckyzhang@gmail.com）“双V模型”里很多职位名词在国内叫法不一，比如有人把初级测试工程师叫做测试员，我不赞同这种叫法，毕竟不是主流；而我的目的，只是通过这些职位的工作内容来告诉大家在职业定位上需要达到的高度，名字嘛，只是个代号而已！ 

   

  刚到考试院网站查了分数，居然过了，我这懒人又多了一张证书，撒花揶 ～～～  欧揶！！！

    灰盒测试： 介于黑盒和百盒之间的测试。灰盒测试关注输出对于输入的正确性，同时也关注内部表现。但对内部表现的关注不像百盒测试那样详细，只是通过表征性的现象，事件，标志来判断内部的运行状态。
 

  

   
  上午拿到卷子后就发觉今年的考题比去年难多了，硬着头皮做。。。否则对不起俺的130元大洋。汗。。。
  下午同样如此，难并不代表我不鄙视，基本上对于出卷人我还是奉上我最真诚的鄙视！卷子题目基本被干枯的理论所覆盖，出来后翻了下，很多选项基本是从教程和真提书上肌理旮旯的角落里COPY过来的，什么功能性的所有子特性，虽然我写出来了，但是这是什么出题思路？ 难道要考生把6大质量特性的子特性全都背出来吗？一共有十几个‘性’，有意思嘛！还有一道数据库模式题，题目完全没问题，但是选项实在是太油菜了! 外模概念模，外模概念模映射，概念模内模，概念模内模映射。。。实在搞不明白少映射多映射有多大区别，选项不够就硬凑，这么搞抠字眼有意思嘛！
 
  贴上上午我的答案，以便日后鞭尸。
 
  DDABC ACCDD
  AACBC ACACD
  BCCBC CDBCC
  DDCDD ADABD
  CBDBA CBBDC
  BDABB DBAAB
  ADBBB BADCA
  DCBCD

  下午有道 因果题，象棋。
  输入： ABDEGI
  输出： CFH
  11-13 ABG
  14-16 EDI(好像是这样，记不清了）
  21-23 HFC

  V(G)=4


  期待牛人有解。
 

   
软件测试基础－面试
01. 为什么要在一个团队中开展软件测试工作？
　　因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

02. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
　　我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试

03. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同04. 的测试类型的区别与联系（如功能测试、性能测试……）
　　测试类型有：功能测试，性能测试，界面测试。
　　功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

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. 请以您以往的实际工作为例，10. 详细的描述一次测试用例设计的完整的过程。
　　就说最近的这次网站功能的测试吧
　　首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
　　第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对　　这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
　　第四步：执行测试

11. 您以往是否曾经从事过性能测试工作？如果有，12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
　　是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。
性能测试类型包括负载测试，强度测试，容量测试等
　　负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
　　强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况
　　容量测试：确定系统可处理同时在线的最大用户数 
　　在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

　　Web服务器指标指标：
　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
　　* Successful Rounds：成功的请求；
　　* Failed Rounds ：失败的请求；
　　* Successful Hits ：成功的点击次数；
　　* Failed Hits ：失败的点击次数；
　　* Hits Per Second ：每秒点击次数；
　　* Successful Hits Per Second ：每秒成功的点击次数；
　　* Failed Hits Per Second ：每秒失败的点击次数；
　　* Attempted Connections ：尝试链接数；　　

13. 您在从事性能测试工作时，14. 是否使用过一些测试工具？如果有，15. 请试述该工具的工作原理，16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

17. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

18. 在您以往的工作中，19. 一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

20. 您以往所从事的软件测试工作中，21. 是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，22. 请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

23. 您认为在测试人员同24. 开发人员的沟通过程中，25. 如何提高沟通的效率和改善沟通的效果？维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么？

27. 在您以往的测试工作中，28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么？您是如何来对待这些事情的？

31. 在即将完成这次笔试前，32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

33.        你对测试最大的兴趣在哪里？为什么？
　　最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
　　刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
　　不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。
　　我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
　　第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

34. 你的测试职业发展是什么？
　　测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。

35. 你自认为测试的优势在哪里？
　　优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

36. 你以前工作时的测试流程是什么？
　　公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定 (出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

37. 当开发人员说不38. 是BUG时，39. 你如何应付？
　　开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

23．你为什么想离开目前的职务？
　　因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。

24：你对我们公司了解有多少？

25：你找工作时，最重要的考虑因素为何？
　　工作的性质和内容是否能让我发挥所长，并不断成长。

26：为什么我们应该录取你？
　　您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

27：请谈谈你个人的最大特色。
　　我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

28.白箱测试和黑箱测试是什么?什么是回归测试?

29。单元测试、集成测试、系统测试的侧重点是什么？

30。设计用例的方法、依据有那些？

31。一个测试工程师应具备那些素质和技能？

32.集成测试通常都有那些策略？

33.你用过的测试工具的主要功能、性能及其他？

34.一个缺陷测试报告的组成

35.基于WEB信息管理系统测试时应考虑的因素有哪些？

36.软件测试项目从什么时候开始，？为什么？

37.需求测试注意事项有哪些？

38.简述一下缺陷的生命周期

39.测试分析测试用例注意（事项）？
　　你在你所在的公司是怎么开展测试工作的？是如何组织的？
　　你认为理想的测试流程是什么样子？
　　你是怎样工作的？
　　软件测试活动的生命周期是什么？
　　请画出软件测试活动的流程图？
　　针对缺陷采取怎样管理措施？
　　什么是测试评估？测试评估的范围是什么？
　　如果能够执行完美的黑盒测试，还需要进行白盒测试吗？为什么？
　　测试结束的标准是什么？
　　软件验收测试除了alpha,beta测试以外,还有哪一种?
　　做测试多久了？
　　以前做过哪些项目？
　　你们以前测试的流程是怎样的？
　　<答：测试计划－测试用例设计－测试执行－测试分析报告>
　　用过哪些测试工具？
　　为什么选择测试这行？
　　<答：它是一个新兴的行业，有发展潜力，而且很锻炼人，需要掌握更多的技能，比做开发要更难>
　　为什么值得他们公司雇用？
　　如果我雇用你，你能给部门带来什么贡献？
　　如何从工作中看出你是个自动自觉的人
　　你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
　　通常你对于别人批评你会有什么样的反应
　　如果明知这样做不对，你还会依主管的指过去做吗
　　如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
　　你觉得什么样的人最难相处
　　为什么值得他们公司雇用？
　　　　帮助公司提高软件质量和测试部门的技术水平
　　如果我雇用你，你能给部门带来什么贡献？
　　　　分享我的测试经验和测试技能，提高测试部门技术水平
　　如何从工作中看出你是个自动自觉的人
　　　        自动自觉范围太广
　       1. 工作成果
       　2. 工作质量
　　你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
　　　　在有足够的资源和合理的工作量的情况下，完全可以按时完成，并能比一般人做的更好
　　通常你对于别人批评你会有什么样的反应
　　　　有错即改，无措勉之

　　如果明知这样做不对，你还会依主管的指过去做吗
　　　　在公司内部下级是否有申诉渠道？

　　如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
　　　　为什么抱怨？是怎么样的问题？
　　　　如果是客服问题，提交客服部门解决
　　　　如果是质量问题，分析原因，下一版本改进
　　你觉得什么样的人最难相处
　　　　自以为是的人

　　什么叫单元测试？
　　　　请就软件测试人员应该具备什么样的基本素质说说你的看法。

　　请就如何在开发中进行软件质量控制说说你的看法
　　 简述软件测试的意义，以及软件测试的分类

1、功能测试，性能测试，界面测试，安全测试（可以简单点，比如只涉及到COOKIES里的内容），压力测试（商业性质的网站） 等等，B/S软件也要根据其具体功能采用不同的测试策略。
2、态度、责任心、自信、敏锐的观察力、良好的发散思维
3、先设计后开发模式，加强单元测试，加强代码走查，有一套完整的白盒测试方法。关键是加强开发人员的质量意识，增进程序员向工程师水平发展。
4、意义嘛，就自己想吧。软件测试的分类，这个很多人都按各种方法去分。无明确答案给你。

对测试的理解——基本的测试知识，对测试是否认可？ 75。
      3、谈一谈过去自己的工作——了解经历、提供进一步提问的素材，表达能力 
测试技能
测试设计的方法并举例说明——测试技术的使用
测试工具——熟悉程度，能否与当前工作匹配？
如何做计划？如何跟踪计划？——日常工作能力
如果开发人员提供的版本不满足测试的条件，如何做？——与开发人员协作的能力
熟悉unix系统、oracle数据库吗？——是否具备系统知识
做过开发吗？写过哪些代码？——开发技能
阅读英语文章，给出理解说明？——部分英语能力
文档的意义——是否善于思考？（最简单的概念，不同层次的理解）
假如进入我们公司，对我们哪些方面会有帮助？——讲讲自己的特长
随便找一件物品，让其测试——测试的实际操作能力
软件测试的方法有？
软件测试的过程？
有一个新的软件，假如你是测试工程师，该如何做？

软件测试分哪两种方法？分别适合什么情况？
2。一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
3。软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
4。测试用例通常包括那些内容？着重阐述编制测试用例的具体做法
5。在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试？他们存在什么样的区别与联系？
6。在测试winform的C/S结构软件时，发现这个软件的运行速度很慢，您会认为是什么原因？您会采取哪些方法去检查这个原因？
7。描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程
你在五年内的个人目标和职业目标分别是什么？
　　分析这个问题是用来了解你的计划能力的，通过这个问题，面试人同时还可以知道你的目标是否符合企业对你的安排。
　　错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁，我认为做太多的个人计划是荒谬可笑的，不是吗？
　　评论这种回答属于令人反感的一类。首先，当有人想了解你的目标时，"将来的某个时候"这种通俗说法并不奏效。其次，认为企业很脆弱，领导者更换频繁，这种说法毫无疑问会令人反感，而且也是不合理的。最后，认为做计划可笑，看不起这个问题，而且反问面试人，这些都注定了这样的求职者最终会失败。
　　正确回答从现在起的五年之内，我希望能够在一个很好的职位上待几年，而且最好有一次晋升，然后就期待着下一步。不管是向上提升，还是在企业内横向调动，对我个人来说，我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。
　　评论这个问题没有回答得过分具体（那样可能会产生漏洞），而且它表明你有雄心，并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望，表明你是一个有灵活性的人。
　问题23　你怎样做出自己的职业选择？
　　分析 面试人提出这个问题是为了了解求职者的动机，看看他（她）应聘这份工作是否有什么历史渊源，是否有职业规划，是不是仅仅在漫无目的地申请很多工作。
　　错误回答 我一直都想在企业界工作。自孩提时代起，我就梦想自己至少也要成为大企业的副总裁。
　　评论 除了难以令人相信之外，这种回答还存在一个问题：它表明求职者会对副总裁以下的职位不感兴趣。
　　正确回答在上大学四年级前的那个夏天，我决定集中精力在某一领域谋求发展。尽管我是学商业的，但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标，想清楚了自己擅长做的事情以及想从工作中得到的东西，最后我得出了一个坚定的结论，那就是这个行业是最适合我的。
　　评论 这种回答表明，求职者认真地做过一些计划，缩小了自己的关注点，而且也认准了前进的方向。这种回答还表明，求职者理解个人职业规划的重要性，并且有能力做出认真的个人决策。
1. 你都用什么测试方法
2.怎么编写案例
3.怎么才能够全面的测试到每一个点
1. 你都用什么测试方法
针对不同的产品或者系统或者模块，有不同的测试方法。总体而言有白盒测试和黑盒测试。
2.怎么编写案例
案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
3.怎么才能够全面的测试到每一个点
测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等多个角度考虑从而定义全部的测试点。
1、谈谈软件测试技术，以及如何提高
2、谈谈软件测试职业发展，以及个人的打算
3、谈谈软件测试在企业的地位，也可以结合软件生命周期来谈
有可能清晰的思路比确切的答案更重要
在这里，主要说下笔试和面试的问题，希望大家共同参考。
       1，一般公司里实际的软件测试流程是什么样的？你们公司又是怎样的？
       2，软件工程师要具有那些素质？
       3，你会哪些测试工具？怎么操作？
       4，你能不能说下你的3到5年的职业计划（规划）
       5，你觉得你来应聘有那些优势？
其余的还好说，但就第4个问题，我感到不好说哦！希望大家给个意见
第一关：首先要自我介绍，自己的性格怎么样，目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看？还有对于软件测试有什么自己的想法。为什么会想到要做这行（因为我的简历上的工作经历没有关于测试方面的）。哦，还有期望薪资。
第二关：认为软件测试人员所要具备的基本素质，如果遇到问题会怎样处理，如果得不到研发人员的配合（就是研发说这个不是问题）你又会怎么处理？然后就是一些基本概念，比如软件测试的流程有哪些？如果我上任了，首先会怎么开始自己的工作计划。
（前两关通过了后面这个就好过多了）
第三关：像我介绍了一下公司的情况，告诉我主要针对什么内容的测试，会不会使用数据库。告诉我大概要做哪些内容，详细的可以上岗以后慢慢熟悉。
大概就这么多了，这对没有经过这一关的不知道有没有帮助，仅供参考吧
我觉得就像李波说的，关键是要给对方留下好印象:)

面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问，这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会：
你可以问：
1.           贵公司近期和远期的发展目标是什么？
2.           贵公司的主要竞争对手有哪些？
3.           贵公司有多少开发人员有多少测试人员？
4.           贵公司又进一步扩充测试人员的计划吗?
5.           如果我有幸能进入贵公司的话，我有怎么样的发展？
6.           测试人员的沟通能力很重要，贵公司有规范的沟通渠道吗？
7.           请介绍一下贵公司的福利情况。
8.           请问我什么时候能知道结果？