//感谢论坛L.CeKSys的创作与分享，原帖发布于卡饭论坛 国外杀毒软件讨论区 ，更多精彩讨论请见原帖//

1.文件分为文本文件和二进制文件﹐不过本质都一样﹐都是些01。

2.计算机存储设备存储的0或1﹐称为计算机的一个二进制位(bit)。

3.二进制文件的0和1有专门的应用程序来读﹐所以它们没有什么乱不乱码的问题﹐只要该程序认得就行。(像doc,xls,exe,dll等)

4.文本文件就不一样了﹐notepad要认识它﹐vs.net要认识它,UE也要认识它...所以它们就要有一个标准。这个标准的原理其实很简单﹐就是把所有的字符都给它一个序号﹐然后根据这个序号来找字符就可以了。这个东东就是编码表,也叫字符集(charset)。

5.文本文件存的都是字符﹐如﹕A,?,@,x。很明显一个bit不能表示﹐刚好计算机的存储单位--字节(byte)就是多个字节(1个byte=8个bit),因此用byte来表示字符就理所当然了。

6.第一个编码表--ASCII码很快产生﹐很简单﹐就是用一个byte来表示一个字符(最高位置0),总共能存储128(2^8)个字符。如A用 65表示﹐存在计算机中就是01000001(65)﹐为了书写方便﹐我们一般记作0x41(16进制),97则表示小写的a,存在计算机中就是 01100001(97)﹐记作0x61。?用63表示,记作0x3F。

7.英语国家的大小写字母加起来才52个字符﹐再加上数字﹐符号和一些特殊字符﹐已经足够使用。所以ASCII刚开始非常流行(谁叫计算机不是咱中国发明的... )

8.随着计算机的普及﹐当非英语系的国家开始使用时﹐ASCII已经明显不能满足了(总不成天天使用xiao sheng来表示"小生"吧),所以这些国家(地区)就开始制订自己的标准。

9.中国大陆制订了简体汉字的字符集(GB2312)。和英语国家不同﹐我们的汉字远远不止128个﹐所以一个byte肯定不能表示完﹐那就多加个 byte,16位(65536)总可以了吧。不过这样虽解决了位数不够的问题﹐但是原来的英文文件怎么办?总不成又全部拿出来改成双字节吧。幸好﹐居然发现原来的ASCII的第一位居然是0﹐那我们把第1位改成1不就OK了吗?以后凡看到0开头的就读1个字节﹐1开头的就读2个字节。(而且128*128 表示所有的简体字也足够了)

10.因此在GB2312标准中,"小"的序号是0xD0A1,表示成11010000 10100001,而A还是表示成01000001,这就是为什么简体操作系统读ASCII文件不会乱码﹐而反之则不然的原因。

11.目前来说﹐情况还比较好﹐中国大陆的计算机运行正常。

12.看到中国大陆制订了一个标准﹐其它国家和地区也不甘示弱﹐纷纷亮出自己的字符集,于是乎什么BIG5(中国台湾),shift_jis(日本),ks_c_5601-1987(韩国)都闪亮登场﹐一时间百鸟争鸣,百花齐放。

13.每个国家都想与ASCII保持兼容﹐理所当然﹐后面的字符就完全不一样了﹐因此﹐同样的0xD0A1,在GB2312中是"小"字﹐而在BIG5中却是"苤"字。你想想﹐这样不乱才怪。

14.到了这时候﹐总有人会想到﹐再这样继续下去是肯定不行的﹐于是它们就想到了﹐如果有一个标准﹐能包括所有字符那不就OK了吗?

15.于是"大哥大"标准就出来了﹐这就是unicode,为了能够足够表示世界上的所有字符这样光荣而又伟大的任务﹐这家伙用了四个字节来表示 (2的32次方到底是多少﹐我也懒得算了),这下好了﹐天下太平了﹐再也不会有麻烦了﹐耳根清静了...(打住﹐你小子这么这么罗嗦呀)

15.不过unicode好是好﹐但是毕竟四个字节表示一个字符"浪费"太大了(我那破猫上网容易吗﹐电信黑呀﹐说好是2M﹐就给我 200K...)﹐而且大家"惊奇"地发现﹐居然世界上一些"较强大"的国家的字符刚好集中在前65536位前﹐呵呵﹐结果unicode也分成了 unicode-16和unicode-32了﹐自然﹐前者只用两个字节表示(所以只能表示前65536位喽,欧亚国家大部分字符都OK了﹐什么﹐你们那个@$Y$%字符没有﹐呵呵﹐不管我什么事,找标准协会﹐都是那帮家伙弄的...)

16.虽然标准出来了﹐可是好歹ASCII也用了这么久﹐那些英语国家也在那里嚷嚷﹐这倒好﹐搞个什么破标准﹐我们又没有得到什么好处﹐反而让我们原来的程序都运行不了了(为什么呀﹐你想想﹐原来我们的程序字符都是一个字节一个字节认﹐现在倒好﹐全改成2个一起认﹐这还怎么跑呀?)﹐况且我们凭白无故了用了这么多0﹐真别扭(unicode中的前128位还是ASCII标准﹐只不过在前面加了8个0)﹐由于那些国家"势力"比较大﹐所以这个问题不容忽视

17.这个世界上的牛人总是这么多﹐这个问题很容易就被小意思地解决了。

18.想想GB2312怎么解决与ASCII兼容的问题的(1开头的就读2个字节﹐0开头的就读1个字节)﹐同样﹐UTF也这样﹐0开头的读1个字节(ASCII码)﹐110开头的读2个字节﹐1110开头的读3个字节﹐这就是伟大的UTF-8(当然还有UTF-16,原理一样﹐xx开头的读4个字节﹐xx开头的读5个字节﹐xx开头的读6个字节)

19.当然UTF-8没GB2312这么简单﹐读完之后不能直接查编码表﹐多加一个步骤﹐按照模板提取一下字符再查就OK了

以下就是UTF-8的模板
0x0000 - 0x007F用一个字节表示 0xxxxxxx
0x0080 - 0x07FF用两个字节表示 110xxxxx 10xxxxxx
0x0800 - 0xFFFF用三个字节表示 1110xxxx 10xxxxxx 10xxxxxx
举个例子吧,
如果你遇到了11100110 10110001 10001001 01000001 这样的字节流﹐首先你看第一个字节以1110开头﹐即读3个字节并按模板提取得到 0110 110001 001001(去除模板标志﹐再四字节四字节读即0x6c49),查unicode编码表就是"汉"字,而最后一个以0开头就一定是一个字节了﹐0x0041,也就是"A"。

20.好了﹐上面是原理﹐再来谈谈简繁体操作系统转换时的乱码问题吧

21.按照我的想法﹐windows操作系统应该有一个默认的系统字符集﹐如简体操作系统应该是GB码﹐繁体操作系统则是BIG5,英文操作系统是ASCII。系统内的软件(notepad)默认都是使用这个字符集。

22.所以我在繁体操作系统默认存储的文本文件就是BIG5了﹐当这个文件到了简体系统里﹐它的notepad程序则使用自己的默认编码(GB)来读取﹐这样就乱了。

23.因此如果在保存时就使用utf-8来保存﹐应该在两系统切换时就不会有问题了。

24.而要解决这个问题其实也很简单﹐只要知道这个文本文件原来的编码就可以了﹐使用它读出来﹐再转成unicode即可。

上面的东东都是我用自己的理解来解释的﹐当然有些东西我避开了﹐主要是想让大家更容易理解原理﹐想要更正式的内容大家到网上随便一搜就出来了。

在证明那些东东之前﹐首先把.net中关于处理encoding,二进制,16进制,byte等相关类别和方法罗列一下。

1.byte与string(那些255以内的整数)的相互转换(各种进制之间的相互转换)
使用System.Convert类别
string to byte
Convert.ToByte(string,base)
base:2表示二进制,8表示八进制,10表示十进制,16表示十六进制(你要输入33,呵呵﹐异常)
这样可以把字符串的(0--255)转成一个byte
Convert.ToByte("01000001",2)转成 65
Convert.ToByte("255",10)转成255
Convert.ToByte("42",16)转成66

同理﹐byte to string也是Convert类
Convert.ToString(byte,base)
同样可以转成相应的进制表示的字符串

通过这两个方法﹐我们要进行2,8,10,16进制的相互转换就容易了

2.char,int,long,boolean等与byte[]之间的相互转换(这些数据在内存中的存储状况)
使用System.BitConverter类别
我们都知道char,int,long等基本类型是以字节形式存在内存中的﹐所以要查看其内存存储方式则直接使用BitConverter.GetBytes()就可以了
然后再使用BitConverter.ToString(byte[])就可以以string方式查看了(如:f9-03表示2个字节)

string是由char组成的﹐只要foreach(char in string)就可以看到string的存储方式了(实验表明﹐string在内存中是以unicode编码存在的,下有示例)

3.各种Encoding之间的转换
使用System.Text中的Encoding相关的类别就可以了
包括Encoding,ASCIIEncoding,UTF8Encoding等,当然也可以通过Encoding.GetEncoding()来获取不同的编码。
然后再通过GetBytes(string)方法﹐就可以获取string的不同编码的byte数组了
通过GetString(byte[])方法﹐就可以把某种编码的byte数组转成字符串.
如"I am 小生,hello world!"的各种bytes编码测试

using System;
using System.Collections;
using System.Text;

public class MyClass
{
 public static void Main()
 {
  string tmp = "I am 小生,hello world!";
  WL("内存中存储的字节数组﹕");
  
  foreach(char c in tmp)
  {
   byte[] b = BitConverter.GetBytes(c);
   Console.Write(BitConverter.ToString(b) + "-");
  }
  WL("");
  WL("unicode字节数组﹕");
  byte[] bs1 = Encoding.Unicode.GetBytes(tmp);
  WL(BitConverter.ToString(bs1));
  WL("utf8字节数组﹕");
  
  byte[] bs2 = Encoding.UTF8.GetBytes(tmp);
  WL(BitConverter.ToString(bs2));
  WL("default字节数组﹕");
  byte[] bs3 = Encoding.Default.GetBytes(tmp);
  WL(BitConverter.ToString(bs3));
  WL("big5字节数组﹕");
  byte[] bs4 = Encoding.GetEncoding(950).GetBytes(tmp);
  WL(BitConverter.ToString(bs4));
  RL();
 }
 
 private static void WL(string text, params object[] args)
 {
  Console.WriteLine(text, args); 
 }
 
 private static void RL()
 {
  Console.ReadLine(); 
 }
 
 private static void Break() 
 {
  System.Diagnostics.Debugger.Break();
 }
}

在下面开始之前﹐先摘录一段关于BOM的知识

-----------------------------------------------------------------
UTF的字节序和BOM

UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。

这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

----------------------------------------------------------

好了﹐这些问题解决后﹐我们就来做单纯的文本文件的编码识别﹐读取与写入测试吧。
以windows的notepad为例(其它的文本文件读取软件的原理应该也差不多﹐只是会多一些特殊的判断算法而已)。

notepad默认有四种编码来存储和读取文本文件。分别是﹕
ANSI,Unicode,Unicode-big-endian和UTF-8。
首先来讲ANSI吧﹐这个是windows操作系统在区域与语言块设置的编码(也就是系统默认的编码)﹐因此像繁体操作系统就是big5,而简体操作系统则是GBK。

而Unicode和UTF-8这两种格式相信大家已经有所了解(当然前者是unicode-16)

而Unicode-big-endian是什么意思呢﹐它与Unicode几乎一样﹐只是它把高位放在前面(而后者则刚好相反)
上面的摘录已经有所说明﹐这里再解释一下﹕
如同样是字符"A"﹐在以下几种格式中的存储形式分别是﹕
UTF-16 big-endian : 00 41
UTF-16 little-endian : 41 00
UTF-32 big-endian : 00 00 00 41
UTF-32 little-endian : 41 00 00 00

好了﹐大家想一想﹐文本文件在硬盘中是以字节形式存储的﹐如果不知道文本文件的编码﹐那是无论如何也不能正确读出文本文件显示给用户看的(乱码了只有人才知道﹐程序则认为一切正常)

根据BOM的规则﹐因此在一段字节流开始时﹐如果接收到以下字节﹐则分别表明了该文本文件的编码。
UTF-8: EF BB BF
UTF-16 : FF FE
UTF-16 big-endian: FE FF
UTF-32 little-endian: FF FE 00 00
UTF-32 big-endian: 00 00 FE FF
而如果不是以这个开头﹐那程序则会以ANSI,也就是系统默认编码读取。

所以现在我们来做个测试就可以很清楚地对以上的东东进行验证了。
1.用notepad输入"汉A"这2个字符﹐然后分别保存成ANSI,Unicode,Unicode-big-endian和UTF-8,名字分别取为ansi.txt,unicode.txt,unicode_b.txt,utf8.txt,并且放在c盘根目录下

2.用以下程序进行验证

using System;
using System.Collections;
using System.IO;

public class MyClass
{
 private static void writefile(string path)
 {
  FileStream fs = null;
  try{
   fs = new FileStream(path,FileMode.Open);
   byte[] bs = new byte[fs.Length];
   fs.Read(bs,0,bs.Length);
   WL(BitConverter.ToString(bs));
   SixTTwo(BitConverter.ToString(bs));
  }
  catch(Exception ex)
  {
   WL(ex.ToString());
  } 
  finally
  {
   if(fs!=null)
    fs.Close();
  }
 }
 
 public static void Main()
 {
  string path;
  WL("ANSI文件格式的字节流﹕");
  path = "c:\\ansi.txt";
  writefile(path);
  
  WL("Unicode文件格式的字节流﹕");
  path = "c:\\unicode.txt";
  writefile(path);
  
  WL("Unicode-big-endian文件格式的字节流﹕");
  path = "c:\\unicode_b.txt";
  writefile(path);
  
  WL("utf-8文件格式的字节流﹕");
  path = "c:\\utf8.txt";
  writefile(path);
  RL();
 }
 
 public static void SixTTwo(string sixstr)
 {
  string[] tmp = sixstr.Split(new char[]{'-'});
  foreach(string s in tmp)
  {
   

Console.Write(Convert.ToString(Convert.ToByte(s,16),2).PadLeft(8,'0')+ " 

");
  }
  WL("");
 }
 
 private static void WL(string text, params object[] args)
 {
  Console.WriteLine(text, args); 
 }
 
 private static void RL()
 {
  Console.ReadLine(); 
 }
 
 private static void Break() 
 {
  System.Diagnostics.Debugger.Break();
 }
}

3.以下是输出格式﹕
ANSI文件格式的字节流﹕
BA-BA-41
10111010 10111010 01000001
Unicode文件格式的字节流﹕
FF-FE-49-6C-41-00
11111111 11111110 01001001 01101100 01000001 00000000
Unicode-big-endian文件格式的字节流﹕
FE-FF-6C-49-00-41
11111110 11111111 01101100 01001001 00000000 01000001
utf-8文件格式的字节流﹕
EF-BB-BF-E6-B1-89-41
11101111 10111011 10111111 11100110 10110001 10001001 01000001

从以上结果可以很容易的看到BABA正是"汉"字的gb2312编码﹐当然我的操作系统是繁体的﹐如果我直接双击打开﹐则可以看到"荦A"﹐这是乱码﹐因为我的系统baba查的是big5﹐而baba的big5码正是"荦"

然而还有其它很多程序﹐像IE呀,它可以使用meta标签来识别文件的编码,xml也是可以通过encoding属性来说明文件的编码的﹐所以这些程序的识别方法和普通的又有些不同罢了。

同样﹐写一个文本文件时﹐先写入这些标记符﹐则也会帮助notepad识别这些文件的编码(当然.net专门提供了一些类别﹐如StreamWriter﹐可以直接存成某种编码的格式)。

至于各种encoding之间的转换﹐我想也不必多说了﹐通过Encoding类的Convert,GetBytes和GetString方法是很容易进行转换的。

(转)国内软件测试工程师职业发展瓶颈分析

l 从企业方面：多数企业较难招聘到满意的测试工程师，尤其在软件测试外包企业，人才问题成了这类企业的发展瓶颈，这些恰恰反映了整个测试行业的发展遇到了瓶颈；
l 从个人方面：很多测试人员薪资和职位到了一定阶段就很难得到提升，例如很多测试工程师做到测试经理后，几年内得不到提升。
职业发展尤其体现在待遇方面。下表是北京市一些IT企业测试工程师的月薪数据。这些数据主要从一些网站收集，由一些测试工程师发布。

通过上面的数据，我们可以看出：
（1） 企业规模越大，越重视测试，而测试人员的待遇也越高；
（2） 掌握测试工具的测试人员待遇往往高于那些只能进行手工测试的工程师；
（3） 测试技术越熟练，待遇越高，而具备一定领导能力的测试工程师待遇会更高些；
但是我们就整个IT行业来看，尤其是与开发人员相比，测试工程师的待遇显得很低。就作者掌握的资料来看，同一级别的开发工程师要比测试工程师高1～2K（人民币），甚至更多。
与开发人员相比，测试工程师的职业目标则很少，主要下面几类：
l 测 试组长（也可称之为测试负责人、测试经理）：这类测试人员通常是测试项目负责人，既要具备较高的测试技术能力，还要具备一定的管理能力。主要职责是制定测 试与编写测试计划、监控和管理整个测试过程。测试组长职位之所以受青睐，是因为测试组长可以向上发展为测试部门经理、质量经理，也可以横向发展为项目经 理，因此通常待遇相对高些。
l 测试分析师：主要职责是对系统的测试结果进行综合的分析，例如缺陷分析、性能分析等。测试分析师不但测试技术能力较强，还要具备数据库、操作系统等多方面的技术知识。这类职务的发展空间也不错，可以发展成系统设计师等。
l 自动化测试工程师、测试开发工程师：主要职责是编写测试程序、执行自动化测试任务。这类职位的测试人员至少要达到初级程序员的能力，因为经常和程序打交道。发展空间也不错，甚至可以发展为程序员。（在国外，这类工作多由具有开发背景的测试人员来负责。而国内的IT公司不重视测试，程序员不愿意去做待遇较低的测试工作，因此测试人员在具有一定的开发能力后，将会考虑转行去做开发。）
但是，国内的测试人员多数在测试圈子“打转转”，很难进入到开发领域。多数测试人员发展成测试经理/高级测试工程师后，职业化几乎到了尽头。于是，出现了一些大企业的测试人员自己去创业的情形，但这种情形更是少之又少。
实际上，这一切的根本原因是由测试工程师的能力水平决定的。国内测试工程师普遍根基不牢，自然难获得较大的发展。下面将从测试工程师的基本素质谈起：只有那些基础知识扎实、潜质较好的测试工程师才是合格的工程师.
后面紧接着分析了测试工程的一些必备的素质和知识,还是比较全面和客观的:
（1）. 计算机专业技能

l 测试专业技能
l 软件编程技能
l 网络、操作系统、数据库、中间件等知识：
（2）. 行业知识
（3）. 个人素养
除了具有前面的专业技能和行业知识外，测试人员应该具有一些基本的个人素养，即下面的“五心”。
专心：主要指测试人员在执行测试任务的时候要专心，不可一心二用。经验表明，高度集中精神不但能够提高效率，还能发现更多的软件缺陷，业绩最棒的往往是团队中做事精力最集中的那些成员。
细心：主要指执行测试工作时候要细心，认真执行测试，不可以忽略一些细节。某些缺陷如果不细心很难发现，例如一些界面的样式、文字等。
耐心：很多测试工作有时候显得非常枯燥，需要很大的耐心才可以做好。如果比较浮躁，就不会做到“专心”和“细心”，这将让很多软件缺陷从你眼前逃过。
责任心：责任心是做好工作必备的素质之一，测试工程师更应该将其发扬光大。如果测试中没有尽到责任，甚至敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果。
自信心：自信心是现在多数测试工程师都缺少的一项素质，尤其在面对需要编写测试代码等工作的时候，往往认为自己做不到。要想获得更好的职业发展，测试工程师们应该努力学习，建立能“解决一切测试问题”的信心。
“五心”只是做好测试工作的基本要求，测试人员应该具有的素质还很多。例如测试人员不但要具有团队合作精神，而且应该学会宽容待人，学会去理解“开发人员”，同时要尊重开发人员的劳动成果——开发出来的产品。
对于测试职业的发展展望,最后给出了国外的通常的一个职业发展路径:

实际上，测试工程师如果按照前面的要求打好基础，职业前景是非常广阔的。我们可以借鉴一下国外测试工程师的职业发展历程，很多时候，国内的软件都是跟着国外的发展趋势，测试行业也一样，国外至少比国内起步早15到20年。
与国外的专业测试工程师相比，国内测试工程师突出特点是晋升非常快，2-3年可能走完了国外10年的路。实际上有很多测试（部）经理也就2到3年的工作经验，而在国外，测试工程师很多至少会有5年以上的开发经验。在国外，通常测试工程师会经过下面的职业发展历程：
1．初级测试工程师
主要是计算机相关专业的本科生或具有一些手工测试经验的个人，主要工作内容是开发测试脚本并开始熟悉测试生存周期和测试技术。我们国内的大多数工程师都在这个水平上，这也是我们软件质量上不去的一个重要原因。
2．测试工程师/程序分析员
具有1-2年经验的测试工程师或程序员，主要职责是编写自动测试脚本程序并担任测试编程初期的领导工作，进一步拓展编程语言、操作系统、网络与数据库方面的技能。国内的高级测试工程师的水平比这个级别还要略低些。
3．高级测试工程师/程序分析员
具有3-4年经验的测试工程师或程序员。帮助开发或维护测试或编程标准与过程，负责同级的评审，并为其它初级的测试工程师或程序员充当顾问。继续拓展编程语言、操作系统、网络与数据库方面的技能。其能力相当于国内的测试负责人。
4．测试组负责人
具有4-6年经验的测试工程师或程序员。负责管理1至3名测试工程师或程序员。担负一些进度安排和工作规模/成本估算职责。更集中于技能方面。
5．测试/编程负责人
具有6-10年经验的测试工程师或程序员。负责管理8至10名技术人员。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。开发一些特定领域的技术专长。
6．测试/质量保证/开发（项目）、经理
具有10多年的工作经验。管理8名或更多的人员参加的1个或多个项目。负责这一领域（测试/质量保证/开发）内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工。
7．计划经理
具有15年以上开发与支持（测试/质量保证）活动方面的经验。管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任。
国内测试工程师早期的发展和国外有些类似，基本遵循从初级测试工程师到中级、高级测试工程师，再从测试负责人到测试经理。但是接下来就很难提升，很少有测试工程师发展成为IT企业的技术总监，主要原因就是技术能力不够。
 

软件测试职业生涯阶段发展方向 软件测试技术
由于国内软件测试行业目前的发展迅速、需求旺盛，在国内的软件测试职位晋升一般要比国外快，但因行业本身太年轻，大家对软件测试中软件测试职业的发展了解不够，从而导致许多有志在此发展的年轻人举步不前。所以下面介绍一下海外公司成熟的软件测试行业职位分布情况，我国一些在软件测试行业中处于前端的公司与之也相仿，这可以作为软件测试职业规划的参考，给新人一个导向。
　　第一阶段：(测试员)初级测试工程师
　　自身条件：初入行具备计算机专业学位或一些手工测试经验的个人。
　　具体工作：执行测试用例，记录bug，并回归测试，通过qtp等测试工具录制回归测试脚本，并执行回归测试脚本。
　　学习方向：开发测试脚本并且开始熟悉测试生存周期和测试技术。
　　第二阶段：(测试工程师)程序分析员
　　自身条件：有1~2年工作经验的测试工程师或程序员。具有初步的自动化测试能力，完善自动化测试脚本。
　　具体工作：设计和编写测试用例，编写自动测试脚本程序且担任测试编程初期的领导工作。
　　学习方向：拓展编程语言、操作系统、网络与数据库方面的技能 。
　　第三阶段：(高级测试工程师)程序分析员
　　自身条件：有3~4年经验的测试工程师或程序员。具有一定的行业业务知识，储备系统分析员的能力。
　　具体工作：帮助开发或维护测试或编程标准与过程，分析软件需求，获得测试需求。确定测试需求相应的测试方法，获得测试策略方案。参与同行的评审（软件需求，软件测试计划等），并为其它初级的测试工程师或程序员充当顾问。
　　学习方向:继续拓展编程语言、操作系统、网络与数据库方面的技能。
　　第四阶段：测试组负责人
　　自身条件：有4~6年经验的测试工程师或程序员。具有丰富的行业业务知识，具有系统分析员的能力，专长性能测试。
　　具体工作：负责管理1~3名测试工程师或程序员。集中于技能方面，担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因，为开发团队提供bug解决策略。
　　学习方向：性能测试，测试技能
　　第五阶段：（资深安全或性能测试工程师）测试/编程高级负责人
　　自身条件：有6~10年经验的测试工程师或程序员。
　　具体工作：负责管理8~10名技术人员。性能测试整体方案设计，软件系统性能问题定位和性能优化，内存优化及分析数据溢出等，分析系统的安全漏洞等。 负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。
　　学习方向：开发一些特定领域的技术专长
　　第六阶段：测试/质量保证/开发（项目）、经理
　　自身条件：有10多年的工作经验。
　　具体工作：管理8名或更多的人员参加的1个或多个项目。负责这一领域（测试/质量保证/开发）内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工
　　第七阶段：（公司级质量总监）计划经理
　　自身条件：有15年以上开发与支持（测试/质量保证）活动方面的经验。
　　具体工作：管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任。

文件和文件夹命名规则

　　一般情况下，所有的汉字和英文字母都可以作为文件和文件夹的名字或是其中的一部分，有少数特殊的符号和被保留的字母组合不能被用作文件和文件夹名字或是其中一部分。

　　不能将文件和文件夹命名为“.”或“..”。例如，像 ..sql 这样的文件名是不正确的。另外，文件和文件夹也不能包含以下字符：
井号 (#)。

百分号 (%)。

“&”符

星号 (*)。

竖线 (|)。

反斜杠 (\)。

冒号 (:)。

双引号 (")。

小于号 (<)

大于号 (>)

问号 (?)。

斜杠 (/)。

前导或尾随空格 (' ')。这样的空格将被去除。

为  Windows  或  DOS  保留的名称（“nul”、“aux”、“con”、“com1”、“lpt1”等）。

在Windows XP中,当你尝试使用CON, LPT1等IO设备接口关键词命名文件夹,会出现失败,诸如此类的关键词还很多，CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN 和 NUL都是,主要是为了防止系统识别混淆.另外,在你建立文件的时候,“CON”, “CON.”. “.CON”都是不被允许的.

　　在Windows Vista中已经被确认这些关键词是可用的,毕竟,Dos时代已经过去了....