.moduleSingleImg01 img{border:1px solid #D1E3F4}
作者：ITPUB论坛&&&【IT168 技术文章】　　一.方法简介　　1.定义　　是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。　　2.划分等价类：　
　等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值
的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结
果。等价类划分可有两种不同的情况：有效等价类和无效等价类。　　1)有效等价类　　是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。　　2)无效等价类　　与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。　　设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。　　3.划分等价类的标准：　　1)完备测试、避免冗余;　　2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;　　3)并是整个集合：完备性;　　4)子集互不相交：保证一种形式的无冗余性;　　5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。　　4.划分等价类的方法　　1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；　　　　2)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；　　3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。　　4)在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。　　例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。　　5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；　　6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。　　5.设计测试用例　　在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：　　1)为每一个等价类规定一个唯一的编号；　　2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；　　3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。　　二.实战演习　
　1.某程序规定："输入三个整数 a 、 b 、 c
分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算 …
"。用等价类划分方法为该程序进行测试用例设计。（三角形问题的复杂之处在于输入与输出之间的关系比较复杂。）　　分析题目中给出和隐含的对输入条件的要求：　　（1）整数 （2）三个数 （3）非零数 （4）正数　　（5）两边之和大于第三边 （6）等腰 （7）等边　　如果 a 、 b 、 c 满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一：　　1)如果不满足条件（5），则程序输出为 " 非三角形 " 。　　2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。　　3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 " 。　　4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。　　列出等价类表并编号　　　　覆盖有效等价类的测试用例：　　a b c 覆盖等价类号码　　3 4 5 （1）--（7）　　4 4 5 （1）--（7），（8）　　4 5 5 （1）--（7），（9）　　5 4 5 （1）--（7），（10）　　4 4 4 （1）--（7），（11）　　覆盖无效等价类的测试用例：　　　　2.设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。　　1)划分等价类并编号,下表等价类划分的结果　　　　2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：　　测试数据 期望结果 覆盖的有效等价类&&& 200211 输入有效 ①、⑤、⑧　　3)为每一个无效等价类设计一个测试用例，设计结果如下：　　测试数据 期望结果 覆盖的无效等价类&&& 95June 无效输入 ②&&& 20036 无效输入③&&& 2001006无效输入 ④&&& 198912 无效输入 ⑥&&& 200401 无效输入 ⑦&&& 200100 无效输入 ⑨&&& 200113 无效输入 ⑩&　
　3.NextDate 函数包含三个变量：month 、 day 和 year ，函数的输出为输入日期后一天的日期。 例如，输入为
2006年3月 7日，则函数的输出为 日 。要求输入变量 month 、 day 和 year 均为整数值，并且满足下列条件：&&& ①1≤month≤12&&& ②1≤day≤31&&& ③1920≤year≤2050 &　　1)有效等价类为：　　 M1＝{月份：1≤月份≤12}&&& D1＝{日期：1≤日期≤31}&&& Y1＝{年：1812≤年≤2012}&　
　2)若条件 ① ~ ③中任何一个条件失效，则 NextDate 函数都会产生一个输出，指明相应的变量超出取值范围，比如 "month
的值不在 1-12 范围当中 " 。显然还存在着大量的 year 、 month 、 day 的无效组合， NextDate
函数将这些组合作统一的输出： " 无效输入日期 " 。其无效等价类为：&&& M2＝{月份：月份&1}&&& M3＝{月份：月份&12}&&& D2＝{日期：日期&1}&&& D3＝{日期：日期&31}&&& Y2＝{年：年&1812}&&& Y3＝{年：年&2012}&&& 弱一般等价类测试用例&&& 月份 日期 年 预期输出&&& 6 15 年6月16日&　　强一般等价类测试用例同弱一般等价类测试用例　　注：弱--有单缺陷假设；健壮--考虑了无效值　　(一)弱健壮等价类测　　 用例ID 月份 日期 年 预期输出&&& WR1 6 15 年6月16日&&& WR2 -1 15 1912 月份不在1～12中&&& WR3 13 15 1912 月份不在1～12中&&& WR4 6 -1 1912 日期不在1～31中&&& WR5 6 32 1912 日期不在1～31中&&& WR6 6 15 1811 年份不在中&&& WR7 6 15 2013 年份不在中 &　　(二)强健壮等价类测试&&& 用例ID 月份 日期 年 预期输出&&& SR1 -1 15 1912 月份不在1～12中&&& SR2 6 -1 1912 日期不在1～31中&&& SR3 6 15 1811 年份不在中&&& SR4 -1 -11912 两个无效一个有效&&& &&& SR5 6 -1 1811 两个无效一个有效&&& SR6 -1 15 1811 两个无效一个有效&&& SR7 -1 -11811 三个无效　　4.佣金问题等价类测试用例，它是根据佣金函数的输出值域定义等价类，来改进测试用例集合。&&& 输出销售额≤1000元 佣金10％　　1000&销售额≤1800 佣金=100+(销售额-1000)*15%　　销售额&1800 佣金=220+(销售额-1800)*20%　　测试用例 枪机(45) 枪托(30) 枪管(25) 销售额 佣金&&&& 1 5 5 5 500 50&&& 2 15 15 15 &&& 3 25 25 25 &　　根据输出域选择输入值，使落在输出域等价类内，可以结合弱健壮测试用例结合。
　　一.方法简介
　　1.定义
　　是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。
　　2.划分等价类：
　 　等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值
的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结 果。等价类划分可有两种不同的情况：有效等价类和无效等价类。
　　1)有效等价类
　　是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
　　2)无效等价类
　　与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。
　　设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。
　　3.划分等价类的标准：
　　1)完备测试、避免冗余;
　　2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;
　　3)并是整个集合：完备性;
　　4)子集互不相交：保证一种形式的无冗余性;
　　5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。
　　4.划分等价类的方法
　　1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；
　　2)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；
　　3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
　　4)在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
　　例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。
　　5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；
　　6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
　　5.设计测试用例
　　在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：
　　1)为每一个等价类规定一个唯一的编号；
　　2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；
　　3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。
　　二.实战演习
　 　1.某程序规定："输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算 … "。用等价类划分方法为该程序进行测试用例设计。（三角形问题的复杂之处在于输入与输出之间的关系比较复杂。）
　　分析题目中给出和隐含的对输入条件的要求：
　　（1）整数 （2）三个数 （3）非零数 （4）正数
　　（5）两边之和大于第三边 （6）等腰 （7）等边
　　如果 a 、 b 、 c 满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一：
　　1)如果不满足条件（5），则程序输出为 " 非三角形 " 。
　　2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。
　　3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 " 。
　　4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。
　　列出等价类表并编号
　　覆盖有效等价类的测试用例：
　　a b c 覆盖等价类号码
　　3 4 5 （1）--（7）
　　4 4 5 （1）--（7），（8）
　　4 5 5 （1）--（7），（9）
　　5 4 5 （1）--（7），（10）
　　4 4 4 （1）--（7），（11）
　　覆盖无效等价类的测试用例：
　　1)划分等价类并编号,下表等价类划分的结果
2.设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。
　　2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：
　　测试数据 期望结果
覆盖的有效等价类
&&& 200211 输入有效 ①、⑤、⑧
　　3)为每一个无效等价类设计一个测试用例，设计结果如下：
　　测试数据 期望结果
覆盖的无效等价类
&&& 95June 无效输入 ②
&&& 20036 无效输入③
&&& 2001006无效输入 ④
&&& 198912 无效输入 ⑥
&&& 200401 无效输入 ⑦
&&& 200100 无效输入 ⑨
&&& 200113 无效输入 ⑩
　 　3.NextDate 函数包含三个变量：month 、 day 和 year ，函数的输出为输入日期后一天的日期。 例如，输入为 2006年3月
7日，则函数的输出为 2006年3月8日
。要求输入变量 month 、 day 和 year 均为整数值，并且满足下列条件：
&&& ①1≤month≤12
&&& ②1≤day≤31
&&& ③1920≤year≤2050
　　1)有效等价类为：
　　 M1＝{月份：1≤月份≤12}
D1＝{日期：1≤日期≤31}
&&& Y1＝{年：1812≤年≤2012}
　 　2)若条件 ① ~ ③中任何一个条件失效，则 NextDate 函数都会产生一个输出，指明相应的变量超出取值范围，比如 "month 的值不在 1-12 范围当中 " 。显然还存在着大量的 year 、 month 、 day 的无效组合， NextDate 函数将这些组合作统一的输出： " 无效输入日期 " 。其无效等价类为：
&&& M2＝{月份：月份&1}
&&& M3＝{月份：月份&12}
&&& D2＝{日期：日期&1}
&&& D3＝{日期：日期&31}
&&& Y2＝{年：年&1812}
&&& Y3＝{年：年&2012}
&&& 弱一般等价类测试用例
&&& 月份 日期 年 预期输出
&&& 6 15 1912 1912年6月16日
　　强一般等价类测试用例同弱一般等价类测试用例
　　注：弱--有单缺陷假设；健壮--考虑了无效值
　　(一)弱健壮等价类测
　　 用例ID 月份 日期
年 预期输出
&&& WR1 6 15 1912 1912年6月16日
&&& WR2 -1 15 1912 月份不在1～12中
&&& WR3 13 15 1912 月份不在1～12中
&&& WR4 6 -1 1912 日期不在1～31中
&&& WR5 6 32 1912 日期不在1～31中
&&& WR6 6 15 1811 年份不在1812～2012中
&&& WR7 6 15 2013 年份不在1812～2012中
　　(二)强健壮等价类测试
&&& 用例ID 月份
日期 年 预期输出
&&& SR1 -1 15 1912 月份不在1～12中
&&& SR2 6 -1 1912 日期不在1～31中
&&& SR3 6 15 1811 年份不在1812～2012中
&&& SR4 -1 -11912 两个无效一个有效
&&& SR5 6 -1 1811 两个无效一个有效
&&& SR6 -1 15 1811 两个无效一个有效
&&& SR7 -1 -11811 三个无效
　　4.佣金问题等价类测试用例，它是根据佣金函数的输出值域定义等价类，来改进测试用例集合。
&&& 输出销售额≤1000元 佣金10％
　　1000&销售额≤1800 佣金=100+(销售额-1000)*15%
　　销售额&1800 佣金=220+(销售额-1800)*20%
　　测试用例 枪机(45) 枪托(30) 枪管(25) 销售额 佣金
&&& 1 5 5 5 500 50
&&& 2 15 15 15
3 25 25 25 2500
　　根据输出域选择输入值，使落在输出域等价类内，可以结合弱健壮测试用例结合。
天地玄黄，宇宙洪荒；所谓光阴似箭，因为一转眼滚滚的历史车轮就将人类文明推进了二十一世纪的信息时代！葛大爷有对白曰：“二十一世纪最宝贵的是什么？”对曰：“人才！”何为人才？sincky曰：“适应时代潮流，把握社会需求，并为我中华老大帝国创造社会价值的人！”哎哟，不诹了，其实今天笔者在这里要和大家探讨的，是软件测试的职业发展问题，重点要阐述的是软件测试从业者的职业发展方向，欢迎大家按enter键换行，继续浏览！
一个人从大学毕业，即开始发生从学生时代向职业人士的过渡，这种过渡走的好，可以实现毕生宿愿，体现个人价值，不管你是否喜欢，功名、利禄尽收眼底；如果
走的不好，则会误入歧途，纵有凌云壮志、万丈豪情，难免一生郁郁不得志，终归化作片片飞尘，无语对穹苍！那么如何才能顺利的完成这种过渡、踏上我们豪迈的
职业旅程呢？答曰：认清自己，选择适途！战国的魏人荆轲具有“十步杀一人，千里不留行”的本领，曾向魏王献策曰：“国君，我是职业杀手，我杀人的技术很强！”魏王问：“那么你想杀谁呢？”对曰：“杀他个国君如何？”魏王大惊，慌然离去！后来荆轲离开魏国，与燕太子丹密谋，留下了“图穷匕首见”、“荆轲刺秦王”的千古佳话。荆轲，良禽也，择木而栖和太子丹合作，是他的高明之处；不过笔者认为他是一个典型的“低管理、高技能”的人才，当他紧握嬴政的脖领、持剑相逼时，他太得意忘性了，可见他没有领导的“统御力”和“决断力”，所以落了个刺杀失败、拔剑自刎的下场，虽然他的侠义与胆识流畅千古，但是终究是个“杀手”而已；当今社会下，如果“低管理、高技能”的人干工作干到丢了性命，那也真是一个笑谈了！
目前我们国家高等学历大幅度扩招，造成社会的低端人才严重过剩，大学生毕业找不到工作、或者找不到合适的工作例子鳞次栉比；但是社会各行各业对高端人才的
需求又求贤若渴；那么如何解决这种矛盾呢？从大环境来说，国家应该改革教育体制、提高教学质量、重视高端人才的培养，但是，一个问题一旦上升到国家的层
次，就要等它个十年八年！我们没有办法改变世界，但是我们有能力改变自己；所以我们从个人的角度来讲，讲讲我们这些软件测试的从业者们，如何“认清自己、选择适途！”
　　 纵观当今社会各行各业，对于个人的职业发展方向，从宏观上都可以划分为四个群体，即：
　　 “低管理、低技能”
　　 “高管理、低技能”
　　 “低管理、高技能”
　　 “高管理、高技能”
　　 而在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结合当前国内外软件测试行业现状提出的职业发展流程图，仅供测试从业者参考，并非一个“死”的框架，大家不要拘泥于流程图本身；其实目前国内很多上升到高级域或最高域的资深人才，很多都是跳跃式、甚至跨越式的职业发展，因为命运掌握在自己手里，任何人都剥夺不了设计自身人生蓝图的权利；而另外一个角度是，任何人都不该不珍惜为自己规划职业生涯的机会！
　　 软件测试，一个日出东方的国际型行业，虽然偶尔会弥漫晨雾，甚或有暴雨来袭，但是我们都该坚持！有人说：“什么叫失败？”答曰：“放弃就是失败！”每
一次当我们身处逆境时，决不能用软弱的眼泪作为走向明天的见证，更不能用脆弱的感情去拴住生命的航线；是雄鹰就该搏击长空，是蛟龙就该挽起狂澜；沧海横
流，方显英雄本色，疆场搏斗，可露壮士肝胆！人生没有豁免权，每位从业者只有怀着不息的斗志，乘千里长风，破万里巨浪，才能支配命运走向辉煌的明天！
　　用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：
　　1、 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
　　2、 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
　　3、 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（或文件）的完整。
　　4、 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
　　5、 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
　　6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
　　7、 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。
　　8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
　　9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
　　10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
　　11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
　　12、可移植性：在不同及硬件配置情况下的运行性。
　　13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员 已经解决，进行下一轮的测试。
　　14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较 。
　　说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同。
　　1、 其中第1、2、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、都涉及并重点测试的方面。
　　2、 单元（模块）测试（组件、控件）测试：重点测试第5项。
　　3、 组合（集成）测试：重点进行接口间数据输入及逻辑的测试，即第4项。
　　4、 系统测试：重点测试第3、7、10、11、12、14项。
　　5、 其中压力测试和可移植性测试如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试即可。
　　6、 GMPS基础测试用例设计完成后，的测试项目只编写设计与之不同部分的测试用例。
　　7、 对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。
在软件开发过程中，需求分析是最开始的工作，需求分析如果做得不够详细或者是偏离用户需求的话，往往会给项目带来灭绝性的灾难。因此如何保证需求分析的正确性，不偏离用户的需求就成了决定软件项目成败的关键。
需求工程师取得用户的显性需求后，要仔细的分析用户到底要求软件实现什么功能，用户的表达和需求工程师的理解有时间并不会一致，这样会导致用户所想的和需
求说明书上所描述的有偏差。并且需求工程师取得用户的需求后必须做仔细透彻的分析，有时候用户的需求并不一定正确，可能是用户忽然的想法，并不可行。如果
需求工程师不能对用户提出的需求进行判断的话，可能辛辛苦苦的实现了用户需求，结果被用户自己否决掉。用户绝对不会将责任揽到自己身上，他们只会说“你们
是专家，怎么能怪我呢？”。
网上有一幅漫画形象地描述了信息在传递过程中产生的误差。
需求分析师是项目中直接与客户接触的人，需求做的好不好决定项目成败，因此对于需求规格说明书的正确性必须进行彻底的验证，将错误在开工前就消灭。 通常有两种手段来检查需求的正确性，分别是需求评审和需求测试。
软件开发网
求评审可以分为正式评审与非正式评审，在需求规格说明书完成后，需求组必须自己对需求做评审。如果需求组递交的需求规格说明书在指导后面的工作的时候出现
很明显的错误，我想拿高工资的需求分析人员是无法向老板交差的。为了需求分析人员的名誉，他们自己会对自己提交的内容进行审核，直到他们认为自己的工作成
果足够好，才会将需求规格说明书提交给正式评审组。
正式评审组的成员一般由公司内经验最丰富，技术最牛的人（技术总监）来担任，当然参加评审的人中间还应该有项目经理、QA人员、测试人员、架构师，他们仔细阅读需求规格说明书，并针对自己将要开展的工作内容进行检查，并提出问题。
正式评审是最后一关，如果正式评审通过了，将进入系统设计阶段，如果在系统设计阶段再跨里程碑来修改需求的话，所花费的代价将大大增加。因此正式评审将是一个“鸡蛋里挑骨头”的过程，只有所有的人都认为需求已经没有什么可挑剔评审才能通过。
以认为需求评审也属于需求测试范围，但是这里提的需求测试和评审不同，它是测部门来测试需求是否符合用户的要求。显然这是有难度的，传统的测试工作都是从
单元测试开始，编码之前全部做得都是计划性工作。测试人员对需求分析进行测试？那么前提条件是测试人员必须熟悉需求分析，这对测试人员的要求提高了。将需
求测试人员作为测试人员中的特殊种类来培养，能够对需求是否正确进行检查，这样就能够在需求阶段就引入测试。当然需求测试人员可以是经过培训的需求分析人
员，但是他必须脱离需求组，加入测试部门，这样才能保证测试不是自己人测自己，以保证测试的效果。需
求测试不等同于后面阶段集成测试或者系统测试，后面的测试都是软件已经编写完成的条件下，判断软件是否会出错。而需求测试，只是验证需求是否真的是用户
的。对于需求的功能测试，可以用RAD工具建立界面原型，用户通过原型的操作来确定是否需求跟他的期望相同。对于那些用户不合理的需求，测试人员要能够分
辨出来，并跟用户进行核对，确定用户的真实需求。可以说需求测试是需求测试人员和用户共同来执行的。
之所以将需求测试和需求评审并行进行，是因为需求评审是项目的各方干系人共同进行的检查工作，评审工作关注的焦点是分散的，很难将偏离用户的需求检查出
来，并且涉及的人很多，因此不可能耗费太长时间。而需求测试执行的时间可以比评审时间长，有专门的关注方面，能够检查出不合理的需求分析，在项目前期进行
错误纠正，往往比实现后纠正要节约几百甚至几千倍的成本。
【IT168 技术文章】&&& 从一月份到现在，面试了二十个左右的研究生，满意的很少，我开始去思考，到底是自己的要求过高，还是自己的面试方法有问题，抑或真的是现在的研究生的素质越来越低了？&&&&&&& &&&
我理想的人选，首先，我希望他对测试感兴趣，有测试的感觉，测试并不是一件很有创造性的工作，但其中的乐趣，是很多coding高手所无法体会的，但需要
发现其乐趣，必须要喜欢上测试，才会更有效地发现软件存在的隐藏问题。其次，我希望他有一定的技术基础，对于在校的研究生的技术水平，我的要求不高，只需
要掌握最基本的SQL语句，会简单得Linux命令，懂得用Java或C写一个简单的程序，这些知识，是需要在项目中使用到的技术，同时也是学校的基础课
程上的东西。最后，是他的态度和性格，我希望他是一个责任心很强、具有良好沟通能力和团队精神的人，测试根软件开发最大的不同是，开发工程师可以只关心自
己所负责的模块或功能，而测试则要把握全局，需要跟不同的人去沟通，发现问题需要协助不同的人去定位和解决，测试是一个团队的工作，我希望招聘进来的人，
能够很快地融进我们的团队中，谦虚地学习，踏实地工作。&&&
我的这三个要求，似乎真的很高，因为当我以这三个标准去衡量我的candidate的时候，我总是满怀希望地开始跟他们交谈，而又失望地与他们告别。首先
是笔试的题目，至少有一半人，最基本的SQL和Linux命令都是没有把握地写进卷子的。“这份题目你觉得怎样啊？”我笑着问他们。“都是在学校学过的，
不过忘记了，只要给我时间，我很快就会学会的。”果然都是名牌大学的研究生，那样的自信。“我们的工作要求有一定的JAVA/Oracle/Linux技
术基础，如果给你时间，你要多长时间可以掌握呢？”“一两周就可以了。”“我们的招聘要求里面有些清楚这些要求吗？”“有。”“你从发简历到面试，大约多
长时间了呢？”“两周左右。”“那你为什么不利用这两周把招聘要求中的技术都好好温习一下呢？”我仍然笑着问，只是接下来大多都是沉默。我发觉这个问题，
真的能问倒所有人。其实，我不是想为难他们，只是，他们都是名牌大学研一或研二的学生啊，这些基础我当年大学三年级就已经可以灵活运用了，这些命令我也经
常会忘记，但是，每次自己去面试之前，都会花些时间认真地复习一下招聘要求中的技术，有备而战。其实，我想看的是这个来面试的人，是否在来之前有认真地准
备，我只是想看他对这个机会的态度。插一条记录到数据库中，居然有人用add，真叫我心疼！同事批评我说，别总拿态度来作要求，只要你给他培训两个月，什
么技术不会？用add还是用insert
into有什么关系？只要他足够聪明就可以了。态度真的不重要吗？我真的不需要他们有技术基础吗？他们真的可以没有任何基础就进来，这些技术，我两周的培
训就可以让他们掌握，只是，他们的态度，我没信心让他们在两周之内扭转。当他们可以很高效地干活的时候，恐怕他们又要马上回学校去了。如果我培训的成本，
已经远远高于我自己做的成本，那么，我宁愿自己辛苦一些。不要怪我以态度作为评判的准则。&&&
简历，是用人单位初步刷选的一份资料，有些简历看上去就像一份草稿，或者是所展示的资料并不符合我们的要求，通常我们都会放弃进一步去了解。有些人的简历
做得很漂亮，好像什么都会，而且还有很多的项目经验，看上去似乎很有吸引力，但简历给人的印象未必就是真实的。每个公司都希望招聘进来的人可以有一定的项
目经验，因为这意味着他们一进来就可以给公司干活了，可以节省很多的培训成本。我也喜欢有项目经验的人，我还很喜欢跟他们聊他们曾做过的一两个项目，因为
在在这个互动的过程中，你可以看出他的思维、表达和技术。简历中的项目经验可以是假的，但在面试的时候就不能假了，在面试过程中的交流足以让我们判断出这
个人的技术水平和思维能力。很多人，在简历中写着正在做的项目或一两个月之前做的项目，当我们问他有关系统的框架或某个功能的流程时，表达起来却是不够清
晰，再深入一些去追问，回答就差强人意了。我在想，是因为他们不善于表达，还是他们本身没有深入理解过自己所做的项目，甚至是自己根本上就没有这些项目经
验？企业或者也应该思考一下，是否应该给没有项目经验的人一些平等的机会，以免他们投其所好，将简历粉饰得很漂亮，但事实上又没有那样的真实。我可以理解
他们，因为简历写上如果连项目经验都没有，可能他们就连面试的机会也没有了，只是，有了面试机会，但如果没有把握这个机会的实力或者没有做好把握机会的准
备，有了也是白有。&&&
我最看重的，是这个人是否具有测试的感觉以及兴趣，我希望他对自己的发展和选择是清晰的，我希望他能清楚自己为什么来应聘，如果他来只是纯粹的找一个工作
机会，或是冲着公司的名气而来，而对于测试是什么，自己所选择的这个测试机会是否有利于自己的长远发展都不清楚，只是为了工作而工作，是否能够将他的潜力
挖掘出来呢？我没把握。而这样的candidate，偏偏又不少。
　　选定发展方向　　1999年，我在开始读研时就给自己确定了以后的发展方向。　　当时有两个方向：网络，数据库技术。因为在2000年之时，网络大热，市场上拥有CCNP、CCIE证书的人特别牛。所以我当时也考下了CCNP证书，但后来发现网络方向涉及很多硬件层面的东西，这些都对厂商的依赖性太强，个人发挥空间不大。而我喜欢钻研，所以慢慢开始转向专攻数据库技术。　　在认准数据库这个方向后，我开始深入学习数据库理论方面的知识。当时，人大王珊教授的《数据库系统原理教程》一书，我读了几十遍。在学习数据库理论的同时，我开始接触并深入学习DB2和Oracle，并从1999年开始使用DB2 V5.2。那时，市场上关于DB2方面的技术书籍几乎没有，互联网也不像现在这么发达。因为我的导师做一个课题需要用到DB2数据库，但是我只能依靠查看 DB2随机文档来学习。那时，我还自己兼职，通过帮别人做些小软件赚钱，外加课题稿费，以支付考OCP认证和DB2认证的费用。　　到现在为止，我一直认为考认证是一个很好的学习动力。因为考试费用不菲，如果不想浪费钱只能拼命看书。我在读研的2000年就通过了OCP 8i认证，后来又陆续通过DB2 V5.2认证。这些认证极大地增强了我的自信。同时，在帮助导师用PB、Delphi等编程工具做应用开发时，我有意识地增强对SQL的学习，这对我后来的性能调优工作非常有帮助。　　这里我想说的是，做好一个时期的人生规划非常重要。我们首先要有一个明确的努力方向和规划，然后有意识的往这个方向努力。这种积极主动的学习要比被动学习效率高很多。　　第一次做培训　　“机遇偏爱于有准备的头脑”，这句话虽是老生常谈，却是人生真谛。记得2000年底，我在网上看到一个帖子说需要一个人去安装DB2数据库，差旅报销，每天500元，我喜出望外。因为这项工作需要有DB2认证才能去，而我那时DB2高级系统管理和应用开发的认证都有，所以很快就通过了对方的审核。但是当我到客户现场时才发现，不是安装DB2而是要给客户讲课，当时我就傻眼了，因为讲课需要的知识远比安装配置数据库要难得多，更何况我之前根本没有讲过课。没办法，压力也是动力，只能前一天夜里看教材备课到凌晨5点。短短睡了两个小时后，8点半去讲课。四天讲课下来，我总共休息了12个小时。还好自己毕竟有 DB2应用开发经验和DB2认证做基础，总算勉强应付了过去。只是没想到的是，这次并不算顺利的培训，竟是我未来几年培训生涯的开始。　　将培训当学习的动力　　经过第一次讲课后，我看到了自己的差距，知道仅有认证是不够的。客户的很多问题，书本上没有答案，需要自己在实践经验上做努力。另外，讲课前讲师需要把一些原理、概念性的东西弄清楚，也需要对数据库进行深入学习。　　后来，IBM培训部通过一些渠道知道我能讲DB2且拥有相关证书，就找我讲授DB2系列课程。所以，从2001年开始，我就经常作为IBM官方讲师讲授 DB2系列的所有课程。我自认为讲课是一个很好的学习过程，因为课前要深入了解概念，对于自己的理论深入学习有很大帮助。同时，课堂上学员的实际操作问题也会强迫自己做更深入的研究。　　我对培训有这样的认识：学员听你讲三个小时，要远远胜过自己看3小时的书。如果把一堂课的内容比喻成一杯水，那老师至少应该提前储备一桶水。所以，在讲课之前，我精心准备实验，深入和学员交流。我讲课从不照本宣科，而是自己准备了很多教材外比较实用的知识来扩展教材内容。同时争取上课过程中把一些概念用浅显易懂的例子来讲解。要想做到这些，首先自己必须对这个概念有深刻的理解才行，这一切都在客观上促进了自己的学习。　　随着培训的增多，有部分客户开始找我做实际的调优工作。记得我第一次去为客户现场调优是2001年，去大连大通证券解决锁等待问题。客户环境用的是AIX和CICS。当时虽然问题解决了，但自己心里还是比较虚，因为对AIX和CICS不了解，万一是这两个方面有问题，自己就没办法搞定了;这让我认识到一个复杂系统的调整往往需要具备多方面的知识。这件事之后，我在网上买了一个140的IBM工作站小机，自己安装AIX并开始学习。　　数据库学习Tips　　根据我对数据库的理解，目前市场上虽然有 Oracle，DB2，Informix，Sybase和SQL Server数据库，但Informix数据库已经被IBM收购，而Sybase数据库在技术和市场上正走向没落，占据市场主要份额的就是 Oracle，DB2和SQL Server数据库。SQL Server数据库非常好，但是很遗憾的是只能在Windows平台使用。所以如果你深入研究SQL Server数据库，我只能说获取高薪的概率稍低，而且坦白的说，使用SQL Sever数据库的企业一般是中小企业居多。而国内做Oracle数据库的人太多，如果你想在Oracle领域出人头地，难度极大。但是，做DB2数据库的人反而不太多，物以稀为贵。况且，DB2数据库广泛应用在银行、电信、制造行业、零售行业、保险行业等“高薪”领域中，所以我强烈建议学习DB2数据库，做IBM技术一般获取高薪的概率相对会大一些。我们的时间精力是有限的，所以必须选择好方向然后努力为之。除了SQL Server，这几个数据库我都在使用，我个人感觉除了功能外，对于运行稳定而言，相对于Oracle不太稳定的优化器，DB2无疑是最稳定的，它的优化器无比强大。如果能在锁方面再有更先进的技术，那么DB2将是完美的。　　这期间，我一边学习，一边通过了AIX的全部认证。记得非常清楚的是，为了做HA的实验，我花费了很大工夫。因为那时小型机不像今天这么普及，无法搞到7133阵列。后来我又学习了CICS、WebSphere、MQ和存储。就这样，在我培训的过程中，发现自己哪方面薄弱并且感觉这个方向有前途，我就会开始学习。不过，那时我的技术主要还是围绕IBM产品为主。由于自己对培训比较用心且颇受客户好评，找我做培训的国内培训机构开始变多。这个期间我自己的技术水平也增长很快。　　2002年11月，我参加了首届 “IBM DeveloperWorksLive! China 2002”大会，并获得IBM首次在国内评选的“杰出软件技术专家”奖，当时在6名获奖者中名列第2。这个奖项客观上对我在客户群的拓展方面起到很大帮助。找我解决问题的人更多了，所以年也成了我技术提升最快的两年。　　这两年内，我陆续学习了HP-UX、WebSphere和MQ并通过认证。我自己的感觉是，如果你把一门技术研究得非常深、非常透，由于触类旁通的缘故，再去学习另一门技术时就很轻松。所以，我在学完AIX再去学习HP-UX时，感觉非常轻松。同样，在学习ORACLE和DB2后再去学习 Informix也同样很容易。通过这种纵向的深入和横向的比较，各种产品的所长所短也会非常清楚，自己的技术视野无意间更加全面化。而且通过对一个产品的深入，你往往能够发现这个产品的缺点和需要改进的地方。就拿DB2来说，每次版本更新的新特性,在新版本未上市前我就可以猜得差不多了。这主要有三个原因：一是我贴近真实用户，了解他们的真正需求;二是自己一直在用且不断总结思考;三是这些特性别的数据库有，而DB2没有，那在下个版本就会增加。所以相对来说，我自身对新版本的新特性学习就非常轻松了。就DB2而言，我拥有DB2 V5.2 、V7.1、V8.1和DB2 V9的全部认证，而且我应该是国内第一个把DB2 V8认证全部通过的人，当然，这其中也有巧合的成分。　　重要的一点是：学习过程中，要不断地把实践和理论融合，知其然更知其所以然，这样提升就会快很多。　　现场救援“赶场”记　　年是我最忙碌的两年，那时候找我讲课的培训机构和需要性能调优的客户非常多，基本上整天在天上飞。培训机构找我讲课常常需要提前一个月预约。那两年内，除了过年几天，其他时间都是在做培训和诊断、调优，足迹遍及国内主要城市。我自己基本上是国内六大银行开发中心和数据中心培训的指定讲师，并为北京银信科技、山东农信、广东农信，交行大集中IBP等项目做数据库技术顾问。　　那时的我年轻、精力充沛。记得最刺激的一次是 2004年9月的一天，上午9点为上海移动IT部门做AIX动态逻辑分区(DLPAR)培训，结束时是17点。之后，立刻坐出租车前往扬州，于20点到达扬州供电局并协助他们进行电力负荷控制系统项目上线，一直奋战到凌晨3点半。接着，又连夜乘出租车赶往上海，在凌晨6点到达酒店。休息两小时后，8点出发，准时出现在上海移动培训现场。那时我对报酬不太在意，想的主要是用心积累技术经验和客户资源。在我看来，能够不断通过实践让自己成长是第一要义。而且，去的客户现场越多，处理的问题就越多，也就越多地发现自己的不足，然后再拼命学习，不断积累、总结和思考，进入了一个良性循环。　　至今我仍然怀念那段充实、紧张而充满激情的光辉岁月。2004年和2005年，一方面因为以独立咨询顾问的个人身份无法出具发票;另一方面，项目越做越大，尤其是很多银行的数据库架构和维护项目涉及合同金额也越来越大，需要签订正式公司合同。于是，我就分别在上海、北京注册了公司。当然这些年我并非都是一帆风顺，也犯过一些重大错误，例如：我曾经在日把海南美兰机场的数据库调死，导致机场航班信息管理系统瘫痪。早期也曾经因为调整某证券系统宕机而影响股民交易，这些都对客户造成了影响，但这些都是成长必须要走的路。经过这两次事件后，我自己也思考、总结了很多，在之后的调优工作中我基本上再没有犯过错误。　　我的秘诀：学习、积累、规划　　2006年8月我获得“2006年中国首届杰出数据库工程师”称号，算是对我多年学习数据库的一个总结。自2007年开始，我专注于做一些大客户的运维工作，并相应减少了培训次数。2008年，我被建设银行以年薪217万聘请为资深技术专家来维护Oracle和Informix数据库。就做技术而言，以一己之力能挣到年薪几百万常常令我感到自豪，也让我感受到技术的魅力，觉得自己多年来对技术的钻研得到了认可。　　之所以讲述我的技术之路，主要目的是给大家一些参考，尽可能多地去了解社会的需求，有意识给自己制定人生规划。我自己认为，多年来能取得这样的成绩，勤奋、努力和坚持一直是我最看重的。因为有了这些，才不至于当机遇光顾时，你却不知所措。　　现在很多年轻人，恰恰缺少的就是这样的忘我与痴迷，在我熟悉的数据库技术领域，很多年轻人越来越早地将注意力集中在薪水和职位上，这是很不明智的行为。其实，往往那些将诸如高薪与职位忘怀的人反而能更快地取得成功。“不经一番寒彻骨，安得梅花扑鼻香?”这样的道理人人都懂，可能够真正去实践的人却并不多。结合我的学习经验与感悟，我总结有16字要诀：去除浮躁，认真学习，不断积累，寻找机遇。　　最后，我用这句话与大家共勉：古之成大事者，不唯有超世之才，亦唯有坚韧不拔之志也!
　　1 在windows xp比较流行的上是否可以识别（装了驱动后是否可以）
　　2 在电脑上显示的盘符是否正确
　　3 总空间，可用空间，已用空间是否显示正确
　　4 u盘中是否可以拷入各种格式的各类文件（图片，视频，文档，网页...）
　　5 是否可以拷入拷出大文件
　　6 正常操作拷入的文档等是否显示乱码
　　7 拷文件的过程中是否可以取消
　　8 拷文件的过程中拔掉u盘后，u盘是否损坏
　　9 拷文件的过程中电脑关机后，u盘是否损坏
　　10 u盘的开关是否起作用
　　12 正常操作，拷入的文件是否会丢失
　　13 空间已满是否有提示信息
　　14 是否支持格式化
　　15 u盘在各个状态时是否有相应的led灯提醒
　　兼容性测试：
　　1 在windows 98,windows 2000,windows me,windows 2000 server,windows 2003 server,windows xp,windows vista...是否可以识别
　　2 在usb1.0,usb2.0上是否能够识别
　　3 在本上，台式电脑，服务器上是否可以识别
　　1 一次性拷贝删除多个文件，u盘是否正常
　　2 u盘连续使用比较长的时间，u盘是否正常
　　3 u盘摔地上多次后，是否正常&& 4 传输速度测试
　　界面测试：
　　1 设计是否美观大方
　　2 图案，log是否正确显示
&&& 每一个测试经理都面临这样的问题，如何对测试人员进行绩效考核。因为测试人员参与的工作不单一，需要的技能也各种各样，考核测试人员的绩效似乎不是很容易的事，除了一般需要考核的对工作的态度，工作的责任心，积极性这些方面以外，还有一些其它方面的内容。&&& 要想对测试人员进行考核，就需要开始工作的时侯明确测试人员的职责，对测试人员的期望等，一个团队中不同的测试人员可能职责不同，比如测试负责人，测试设计人员，自动化测试人员，普通测试人员等，那么对这些人的期望也是不同的，进行绩效考核的时候需要根据对测试人员的期望进行考核，而这些职责和期望测试人员也是很明确的。&& 测试人员可能参与不同的软件开发过程，比如需要参与需求和设计的评审，那么也需要对这些工作进行考核，比如需求评审时可以从测试人员对需求的理解上，测试人员对需求提出的问题的质量上等作出评价。&&& 如果需要测试人员准备测试文档，如测试用例等，那么可以通过评审测试文档来考核一个测试人员的能力。如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段一个测试人员的能力。&& 对于执行测试的测试人员来说，可以从测试人员所发现的问题对测试人员进行评价。测试人员所发现的问题是复杂的还是简单的，是隐藏比较深的，还是一些表面的问题。还可以从问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。或者测试人员书写的问题是否是自己的操作问题，一个问题是否写多遍等。&&& 而对于已经发布的产品，也可以从用户反馈的问题来考核测试人员的绩效，但是这个可能需要的时间比较长。&&& 测试人员的沟通能力也是考核的一个方面，无论是书面的还是口头的，测试人员都应该有较好的沟通能力。&&& 另外测试人员的接受指示，把握细节的能力也应该进行考核，测试经理希望把任务分配给可以按照指示完成的人来完成，如果测试人员自行其事，即使技术能力比较强也对工作无益。&&& 当然我想不同的公司的绩效考核制度不同，不能一概而论，自己总结而已。
作者：g_win 来源：　博客　日什么是升级测试？比如说你们公司开发的产品现已经发布的是V1.0，由于被发现存在缺陷，这时就需开发Patch或Hot Fix，并进行升级测试，然后发布V1.1。
　　升级测试听起来似乎挺平常的，但它其实也是中比较重要的一部分，它通常包括以下内容：
　　● 安装测试
　　● 数据库测试
　　● 应用测试
　　● 文档测试
　　安装测试
　　当发布一个系统的新版本时，程序代码肯定是被修改过了，安装测试的目的是确保安装完成后修改过的文件被复制到了正确的位置，比如说某个文件夹包含了所有更新的文件，这时就要检查相关的CSS文件夹下的文件是不是更新了，如果只更新了HTML而没更新CSS，那么相应的颜色/字体就不能正确地显示。
　　如果公司研发过程比较规范，安装测试通常是在员
的配合下完成的。首先，是文件夹级的测试，检查安装过程中复制到系统中的文件夹的时间戳是否变化；其次，检查被修改过的文件的大小，并和之前的版本进行比
较，当然，这分两种测试，如果是白盒测试，测试人员要打开相应的文件确认新代码和改过的代码，如果是黑盒测试，那就要检查文件大小应与旧版本的不同。
　　数据库测试
　　很多情况下，系统的升级都是伴随着数据库脚本的更新，数据库测试通常也是由DBA人员或在DBA的配合下进行。升级前要停止数据库并做备份，然
后执行升级脚本，之后测试人员需要查看数据库日志，并检查库中被修改的记录是否正确。如果升级脚本是在库中创建一个新的Table或是新的
Relation，那么数据库测试应该关注对空库的测试，比如先建一个空库V1.0，只包含一些空的Table和Relation，而不包含任何数据，然
后测试人员执行升级脚本，并查看日志文件里是否有报错，如果没有报错一切ok，则通过应用程序连到数据库上执行一些功能测试用例来确保数据的Inset或
Update都是正确的。
　　应用测试
　　当安装测试和数据库测试都通过之后，进行应用测试，有两种方法：
　　方法一：先配一个空的数据库（即除了一些必需的初始化数据再没有其他数据），然后把应用程序升级一下，执行业务流程测试看系统是否能够正常运行。
　　方法二：也是先配好数据库，但库里存有一些实际数据，然后把程序升级一下（比如从V1.0升至V1.1），运行应用程序，检查那些已有的数据在V1.1上是否也能被正确的展现和使用，最后执行业务流程测试看系统是否能够正常运行。
　　有的时候升级完后还要手工修改库中已有的记录，比如一个网上银行的系统，它里面有很多支付或转帐的数据，在做升级测试时，就可能要修改那些在上一版本中生成的数据，因为它们可能涉及到多个表之间的数据转换或一二级约束。
　　文档测试
&文档测试主要是验证相关的版本说明或者安装手册等文档是否和系统升级相匹配，这点很重要，因为客户通常都是根据版本说明和安装手册进行系统的安装或升级。
　　进行文档测试必须理解详细的升级步骤，比如文档中应建议用户升级前要备份数据库、数据文件、配置文件等，再比如升级需要复制某些文件到特定目
录，应当在版本说明中有所体现，总之，升级时任何必要的说明都应当在版本说明或安装手册内阐述清楚，安装时可以做什么以及不可以做什么都应在版本发布前得