//感谢论坛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时代已经过去了....

新手的答案：为什么想做测试，测试是做什么的，你要做哪种测试，那你怎么看待测试呢？

前段时间接了一个客户报上来的bug, 因为涉及到与操作系统相关的安装问题，修复该bug可能要涉及到架构的一些变化，所有产品的安装component都会受到牵连，所以最终选择了在read me文档中添加说明项来解决用户使用过程中遇到的不便。

文档测试，说起来很简单，就是因为其简单的表象，很容易使测试人员心里麻痹而忽视一些细节。从直觉判断，我觉得这个看似简单的问题也不能简单的对待，于是查阅了一些书籍，对文档测试进行了一些深入的理解。

作为一个软件测试人员，一定要具备宏观的质量意识，不仅仅是专注于业务和技术。随着软件产品的日趋复杂化，文档已经成为软件产品的重要组成部分之一，其中包括：

1.Package text and graphics.
2.Marketing material, ads, and other insert.
3.Warranty/registration.
4.EULA- end user license Agreement.
5.Labels and stickers.
6.Installation and setup instructions.
7.User's manual.
8.Online help.
9.tutorials, wizard, and CBT(computer base training).
10.Samples, examples, and templates.
11.Error messages.
所有的这些item都是大部分专业客户在使用过程中密切关注的，如果任何一项出现错误或者低可用性，都会严重影响客户的使用感，从而对我们的产品质量产生不好的感觉。因此，文档测试必须和代码测试，功能测试等一样同等重视。

那么，一个好的文档测试可以给软件产品带来什么好处呢？ 首先，提高了软件的可用性；其次，提高了软件稳定性；最后，降低了技术支持的成本。
为什么这么说呢？如果客户在文档中找不到软件使用的说明，那么势必会对使用产生一些疑惑，或者因为错误使用而导致不可预知的结果。最终客户将会致电客服技术支持来寻求解决。如果在一开始文档就有比较完善的测试，就不会导致上面一系列的结果。

就像software testing里面所说：A very effective approach to testing it is to treat it just like a user would. Read it carefully, follow every step, examine every step, examine every figure, and try every example. If there is sample code, type it in and make sure it works as described. With this simple real-world approach, you'll find bugs both in the software and the documentation.

基于这些理解，最终我是怎么来测试这个read me文档的呢？

1.可用性测试：我首先重现了这个客户报上来的bug，并且理解了问题的原因，然后仔细阅读了read me文档里面添加的内容，按照里面所描述的逻辑进行操作，看问题是否被修复了。
2.进行了拼写检查，和描述清晰度检查，考虑是否有第二种理解，或者歧义，然后根据第二种或者第三种理解进行操作，看是否会出现不可预知的错误；
3.检查文档是否安全，是否带有威胁性的病毒或者不安全因素；
4.检查所有的问题都被描述到，并且在制定的build里面已经包含了该文档；

最后我发现这个添加的描述存在理解歧义，客户容易产生疑惑，并且不能很快的解决问题。我试图和文档开发人员进行了沟通，最终他认可了我的建议，将这段文字进行了修改。

似乎整个过程表面上看起来略显繁琐，有点吹毛求疵的嫌疑。但是我觉得作为一个软件测试人员，就是需要将质量意识贯穿到每一个日常工作中，才能够提高客户满意度，建立真正的“customer driven”意识。

从年前开始做一个产品新build的regression 测试，因为是第一次接触产品，之前没有时间去了解功能，着实花了很多时间，连续加班半个月，还是有点累人的。在这里总结一下这大半个月的工作，从中学到知识得到成长。

结合实践，我希望对regression有更加透彻的理解，以帮助日后的工作：

查了一些资料，先从原理来理解。

Regress 的英语定义是：  return  to  a  worse  or  lessdeveloped state

而Regression test 的意义在于：在新版本上运行所有已通过测试的case，从而验证新版本的稳定性。

在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。

在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准（Baseline）。

如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因）引起的，那么测试用例的基准就要修改，以便和新的功能保持一致。

针对一个Bug Fix，我们也要作Regression Test。

（1）验证新的代码的确把缺陷改正了。

（2）同时要验证新的代码没有把模块的现有功能破坏，没有Regression。

回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。

结合上面的原理，我总结有以下几点：

1.       Regression测试主要目的是验证模块和功能是否出现倒退，以前修过的bug是否重新复发；

2.       Regression测试除了围绕上面两个工作展开，还需要进行测试用例baseline的维护工作：

a)         模块功能的正常变化所引起的不符合，需要及时更正case；

b)         把上一个版本所出现并且修复的缺陷及时的引入到case库里面；

c)         把功能的变更和名称的改动及时地反映到case里面；

3.       Regression测试中也会遇到以前版本里面本来就存在但没有被发现的缺陷，但这些缺陷不应该作为重点验证的部分，因为regression测试的主要目的是发现因为修改而出现的倒退现象；

4.       为了节省时间和精力，节约成本，regression测试应该重点侧重于分析因为上一版本所改动部分可能引起的问题并重点验证，而不要过多的集中于一些边缘测试和性能测试等；

杀毒软件性能检测代码

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

把上面这段代码复制到记事本里，保存为文本文件，然后静观杀毒软件之变。

特等:复制完代码后便提示内存有病毒

优等:刚保存完就提示病毒(或者直接删除)

中等:保存后几秒提示病毒(或者直接删除)

下等:需自己启动病毒扫描查杀才提示病毒(或者直接删除)

劣等:无论怎么扫描都无法提示病毒(或者直接删除)

今天有人问我PPB和PPM，我发现我还真的不知道，上网查了一下~~~~

统计思维的基础和公理
　　所有的产品开发和服务都是由一系列相互关联的过程组成。所有的过程都是动态和可变的，理解了这些变化是基于事实管理和系统改进的基础。而统计学思维的核心就是理解过去，控制现在和预测未来。
　　在CMMI中过程被定义为一系列能够被识别和在实践中执行的活动。但是过程要能够最终产出产品和服务，不可避免要涉及到人，材料，设备，工具等一系列的要素。
　　关于产品和服务的性能所涉及到的实际的过程表现，必须在做起决定之前进行充分的理解。回答以下问题有利于我们找出实际的过程表现:

　　1.什么是正常的和固有的过程偏差?

　　2.哪些固有的误差来源于异常的偏差?

　　3.造成异常偏差的根源是什么?

　　统计学提供了我们需要的方法和工具，来度量和分析过程行为，得出结论并执行后续的改进步骤。在OPP中我们首先需要建立过程能力基线PPB，PPB的建立首先要要确定组织的目标，找出影响组织目标的关键子过程，然后收集子过程的数据进行分析。而PPB的作用仅仅是理解过去和控制现在，为了预测未来我们必须要建立PPM过程性能模型。有了PPM我们就可以根据项目的基础信息和模型来预测项目的进度，成本和质量情况。可以使用的模型的类型主要有:

　　1.基本的统计和预测模型

　　2.蒙特卡洛模拟和优化模型(what-if分析等)

　　3.过程模拟模型

　　4.系统动态模型(基于实时的反馈)

　　5.概率模型(根据概率论而不是统计来进行预测)

　　6.可靠性成长模型(通过失败数据测试来预测未来失败情况)

　　如何使用PPB和PPM去选择过程和一个指标来进行改进。假设组织的目标的改进产品的质量，希望把现场缺陷密度DD(Defect Density) <0.4个/KLOC。而这个目标在我们原来发布的产品和版本中很多都没有达到，组织希望对此进行改进。为了达到这个目标，需要遵循以下步骤进行改进:

　　1.建立影响DD的评价准则(贡献度，潜在变革，潜在成本和风险)。

　　2.识别影响DD的影响因子(通过回归分析确定RV,DC和QC三个贡献因子)。

　　3.建立回归分析模型(DD = 389 + 2.12RV + 5.32DC -24.1QC)。

　　4.通过建立的评价准则评价因子(可使用蒙特卡洛模拟或敏感性分析)

　　建立了PPM后就需要考虑如何去改进影响因子以达到我们需要的质量目标，对于RV,DC和QC组织都可能已经有相应的过程能力基线数据，比如DC的上下限为(15,30)，均值为20。根据对多个项目的历史数据分析，可以知道DC大致的概率分布曲线。然后我们根据蒙特卡洛模拟可以得出DD的概率值(比如90%的置信区间下的DD的值为0.42)。
　　有了这些数据我们可以看到，现在的实际情况是无法达到我们的改进目标的，因此我们准备对DC进行改进，将DC的上下限范围进行缩小，并减小DC的均值。究竟要改进到多少，我们就可以进行what-if分析，通过模型可以得出结论是将DC均值减小为18,上下限为(12,25)的时候可以达到目标要求。

    与软件质量密切相关的因素有很多：软件工程方法、需求管理、配置管理、测试、同行评审。

    开展同行评审的步骤有：1、计划同行评审并编写计划文档；2、依据文档化规程实施同行评审；3、记录同行评审的实施和结果数据。

    同行评审在CMMI中有着重要的意义，其目的是尽早地和有效地从软件工作产品中消除缺陷。它是通过工作产品作者的同行对软件工作产品的系统化检查，来识别产品的缺陷和其中需要进行更改的地方。什么是缺陷呢？缺陷是在生产软件工作产品中的错误，它违背了工作产品的规格说明书或工作产品必须遵守的标准。

    如果缺陷存在于某个工作产品则会产生错误的结果，含糊或者不清楚，遗漏规格说明书中要求的特性，包含了规格说明书中不需要的额外的特性。

    怎么样描述缺陷呢？通常缺陷从以下几个方面进行描述：

    1、来源：在开发过程中的哪里产生了缺陷？

    2、种类：是什么类型的缺陷？

    3、严重性：缺陷的影响程度有多大？

    缺陷的来源：客户需求分析、软件需求分析、概要设计、详细设计、编码、开发测试计划、用户文档

    缺陷分类：遗漏Missing、错误Wrong、多余Extra、模糊/不清楚的Ambiguous/Unclear、违背标准Standards Violation、未知的Unknown

    选择合适的评审方法：

    1、基于风险：工作产品包含缺陷的可能性、缺陷发生可能造成的负面影响

    2、有错误倾向（Error-Prone）的模块：有425个模块中，客户报告的缺陷中有58%集中在31个模块中、20-80原则

    3、产生原因：时间压力过大、培训不够或经验不足、需求蔓延导致大量变更

待续......

世界是一个班级， 美国是班长 中国就是团支书 35国（真经典啊）
1、美国班长，学习好，家里有钱，人高马大，好打架。班里没几个人敢惹他。和副班长关系不好。

2、俄罗斯副班长，成绩优异，全班最高大，上学期光和班长顶着干。后来家里出事：分家！现在做事很消极，但在班级里有一定的影响力。

3、中国 团支书。幼儿园学习成绩很好。小学时由于体质差常被欺负，没事爱吹牛，由副班长罩着。

4、英国 学习委员，学习成绩好。家里也很富。班长的跟屁虫，做事没主见，啥都听班长的。前些天和班长把伊拉克打了一顿。

5、瑞士 班花。学习成绩好，清高。不跟人勾肩搭背拉帮结派

6、奥地利 音乐课代表，早熟，在两性观念上特别开放，经常因为乱搞男女关系被同学非议。

7、阿富汗职务无。不爱学习。身材矮小。上学期被副班长打，班长帮忙付医药费。前几天把班长家的最高的两个家具砸了，被班长揍个半死，现在失忆中。

8、伊拉克无职务。幼儿园时学习好，现在学习差。但人高马大，上学期排全班第四。嘴硬，上学期欺负同桌被群殴。前些天被班长和学习委员冲进他家揍个稀巴烂。

9、印度 好玩电脑，成了电脑课代表。经常和同桌巴基斯坦为一块课桌吵架。

10、巴基斯坦 职务无。成绩一般。和团支书关系不错，经常和印度吵架。

11、德国 班级活跃分子，人高马大，擅长数理化。有野心，由于上学打了2架所以现在暂无职务。但认错态度较好。

12、日本 无职位，成绩不错。思想品德很差。上学期刚被班长和团支书等人揍。现在还惦记着班长家的鱼缸。

13、越南 无职位。人品有问题,瘦弱。上学期被班长揍，幸好有副班长和团支书撑腰。后又挑衅团支书，被狂揍。

14、朝鲜 无职位。有个性。和团支书关系好。近期和班长闹矛盾，班长扬言要揍他。

15、韩国，无职务，品行比日本还差，样貌丑,整容整了数十次,终于发现原来基因不好,怎么整都没用,于是决定不要脸了.现在班里公认的心灵与长相一样欠扁.喜欢偷团支书东西，偷完了还不知廉耻拿出来炫耀。由班长罩着。

16、巴西 体育委员，家里杂草丛生。

17、法国宣传委员，班级活跃分子，从小喜欢闹事，追求时尚，被班里有钱男生认为是内涵型气质美女。最近他和一帮同学把团支书惹毛了，被团支书当作出头鸟教训。

18、蒙古 特困生，但刚出生时是个巨婴，曾大哭大闹，弄得还在上幼儿园的全班同学不得安宁。

19、意大利上幼儿园时收拾了周围几十个比自己小的骠悍小朋友，后来被众小朋友合伙打残，失忆，醒来后加入了打他的那群骠悍小朋友，大一点后发现自己又能记起一点失忆前的东西，把它们教给众小朋友后，众小朋友变得比自己学习还要好，且大多成为班干部。

20、希腊上幼儿园时特聪明，教会了周围一大帮同学数理化政史地，后来被自己教出来的意大利打残，抓到家里，意大利又被打失忆后，希腊为了避免步其后尘，对意大利旁边那群骠悍小朋友躲得远远的，但终于还是被几伙同***番欺负。

21、土耳其小学时骠悍，打了不少人，还不知好歹地收拾了早慧少年希腊，结果被那群更骠悍而且有钱的小朋友收拾了，现在正在乞求那群彪悍小朋友收留他。

22、格鲁吉亚 副班长的小弟弟，前不久才转进班里，现在正在挨哥哥揍。

23、埃及 早慧儿童，可惜幼儿园毕业后失忆，幸好一系列家传古董还在。

24、以色列早慧儿童，智商极高，但童年不幸，曾经被很多同学轮番欺负，却都挺过来了，没有失忆。成为班长的铁杆朋友后，开始不那么低调了。

25、丹麦 小学时很凶，喜欢抢别人钱，后来不耍脾气了，成了人见人爱的娃娃脸。

26、墨西哥 幼儿园时聪明，但大多数同学不知道，知道后直接把他打残，失忆，醒来后发现原
来班长住在自己家旁边，后来班长半买半抢拿了他家一半的东西走。

27、西班牙幼儿园时全家被人强光，小学时便成专抢别人的，发现了一块新地盘，收保护费时被后来的学习委员狠狠揍个半死，手下人全部走掉。

28、葡萄牙经历与西班牙类似，但是体质比较弱，更早就被收拾了，最近的一件大事是把小学一年级时抢的现在团支书的一点东西还给了他。

29、阿根廷和墨西哥一样，原来是西班牙的手下，后来溜了，最近为了争一点吃的，跟学习委员打了起来，被打个半死。现在只敢跟巴西争争体委的位置。

30、委内瑞拉 原西班牙手下，最近突然变得很有个性，自立门户，和几个哥们一起，跟班长对着干。

31、古巴 班长邻居，有个性，由委内瑞拉等一帮哥们，还有副班长（有时还有团支书）撑腰，跟班长对着干了一个学期。

32、加拿大 全班第二高大，是班长的邻居，除了最近要和班长、副班长等抢几个冰棍外，基本上是班长的助手。

33、伊朗 无职位，做事却很高调，引起班长等的极度反感，扬言要好好教训他一顿。

34、前南斯拉夫诸国本来自成一派，不听班长话，也不听副班长话，后来分家，各自加入班长或副班长的圈子。其中有不少被认为“不适宜上学”者整天闹着要上 学，原来一个叫黑山的小子被同学们接纳了，最近闹的是一个叫科索沃的小P孩，班长带头的十几名同学已经同意他入学，但副班长不肯。

35、联合国班主任，穷，身子弱，地位低，没几个学生把自己当一回事，同学们还算有点良知，分摊了他的生活费，但作为交换条件，班主任的管理权交给了五个班干部。

    CMMI推进过程是一个长期而艰辛的工作，最终目标就是提高产品质量，有效提升生产效率。但是在实现这些目标之前，首先要确保人员接受这些思想，才能为推进工作开辟道路。
    理论上讲，凡是对软件工程有深刻理解的人都希望推行CMMI，特别是产品经理们，他们更加希望通过软件成熟度集成模型来减轻其工作压力。在实际工作中，顶着巨大的产品出货压力，CMMI推行初期不论是产品经理和研发人员都是顾不上过程规范的，更谈不上静下心来和QA谈如何改进质量的问题，因为在他们看来迫在眉睫的事情就是：出货。然而，越是不愿意停下来理清质量问题，越是得继续在一团乱麻中追赶schedule。因此，我觉得要解决这些问题就应该推进CMMI过程改进的同时提高人员的质量意识。

    怎样提高人员的质量意识呢？

    一个人的意识在很大层面上将直接影响着随之而来的行为活动，并对其活动结果产生重大的改变。意识伴随着我们一路同行，并不时提醒我们对工作的严谨、对生活的憧憬、对需求的渴望……那么究竟什么是“意识”呢？意识是人的头脑对于客观物质世界的反映，是感觉、思维等各种心理过程的总和，是人们内心活动的一种过程。意识的高低体现在人们的一切活动之中，意识越高则对活动结果的影响越积极。企业要发展，产品质量要提升，离不开对人的意识教育和培训。从现代质量管理的角度来看，意识就是一种内化的心理活动标准，是人们对显性行为的一种评价方式。因此，要提高企业的产品质量，则首先要从提高员工的“质量意识”开始。
    质量的发展经历了一个漫长的过程，从“质量检验”到“统计质量控制”再到“全面质量管理”，人们对质量的认识从上世纪五六十年代“好的质量”到八十年代的“符合要求”再到21世纪的“顾客满意”都充分说明了一个问题，质量越来越被人们所重视，其重要性在市场竞争中得到了证实，并且将是未来市场竞争的关注焦点。质量已走出狭义的范围，延伸到更广阔的空间，如：服务质量、工作质量、学习质量、直至人们的生活质量等等。正如质量管理大师朱兰博士提出的“即将到来的世纪是质量的世纪”一样，质量无所不在。这一发展趋势再次说明了，市场的竞争将以“质量竞争”为前提，因而如何提升产品质量又再次成为质量管理的一大课题。此外，从“人、技术和管理”的三大质量管理要素及“人、机、料、法、环”等质量问题分析来看，“人”都处于主导地位，起着决定性的作用。因此对企业员工的质量意识提升就显得更为重要。
     企业员工质量意识的提升可从多个方面进行，如企业文化、管理的标准化、标准的执行、工作行为及教育培训等等。但它需要企业全体员工的参与，特别是高层管理人员的加入，因为高层管理人员的关注将明确企业对质量的重视程度，他们的身体力行将告诉所有员工质量的提高势在必行，同时也告诉所有员工领导的态度与决心。对于质量意识的管理，我们不能简单地停留在只喊口号或不加度量的定性概念层面上，而没有评价、没有检查。如果没有一套有效的监督、检查和评价体系，只凭一贯的思想教育、宣传来进行质量意识的提升，将难以避免其工作的盲目性以及实际操作的无序性。在多少次的质量投诉与质量问题的发生中，我们都得到了深刻的教训，也清醒地认识到提高质量意识的重要性。但我们的管理人员、管理干部有没有认真思考过这一问题，要如何进行控制与改善！笔者认为，要完成任何一件事情、任何一项工作，首先其目的必须十分明确；其次要达到什么样的效果，要如何去做；最后完成情况如何，并及时总结补充存在的不足，再进入下一循环。因此，质量意识的提升要让所有参与人员明白其目的是什么，在一段时期内要达到什么样的目标，具体要如何去操作，并且在出现问题时会受到什么样的处罚，取得成绩时受到什么样的奖励。要使质量意识的优劣与员工切身利益挂钩，使所有员工在工作中能不时的感觉到工作的压力与动力，从而尽量保证任何细微的产品缺陷都不流入下道工序，进而增强其可操作性。
     为了防止实际操作的执行不力情况，管理人员要定时与不定时地进行监督、检查。对于表现优秀的员工要及时进行表扬与奖励，对于存在不足的员工要进行工作指导，对于存在不执行或执行不力的员工进行处罚，真正做到奖罚分明。让所有员工在质量管理四项基本原则（质量的定义即符合要求，质量系统的核心在于预防，工作标准是零缺陷，质量是用不符合要求的代价来衡量）的指引下实现质量意识的真正提高。
     质量意识的管理就是让无形的质量意识与有形的工作质量结合起来，让模糊的质量意识与员工的绩效结合起来，让质量意识的管理体制起到实质性的作用，最终为企业的发展培育出有高质量意识的员工，进而为产品质量的提升打下坚实的基础。

    测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
    目前的功能测试用例都需要首先进行需求理解，再进行用例设计，这些过程都是基于人工实现的。尤其是测试用例的测试输入部分需要人来理解需求并组合测试步骤，测试用例的预期结果业需要人工来提取。人工撰写功能测试用例，不仅耗费大量时间在需求理解阶段，而且也需要花费大量人力和时间撰写。尽管这样，撰写出来的测试用例仍然存在覆盖度不均衡，依赖用例撰写者的经验和能力，以及不能够完全的的复现需求的问题。

一、需求文档分析
通过分析需求文档的章节排版和内容格式，将需求分解成一个个Feature、Sub Feature、case的描述。
比如例1：
***********************************************
1 Place a call .................................Feature1
1.1 Dialling........................................Sub Feature1
Phone number: “0~9”
Case 1
Tap the keyboard then input the correct phone number or select the phone number from contacts or select it from the call history, then tap the “Dial” button, can make a call. The dialing main interface is as below:
*Interface image*
Case 2
Tap the “End call” button……
1.2 Incoming Call...................................Sub Feature2
1.3 XX..........................................Sub Feature3
2 Calendar reminder.....................Feature2
3 XX.............................................Feature3
***********************************************

产生出以下的编号和子功能 case描述：
Data format：Phone number[0~9]
F1_SF1_C1 ：
Tap the keyboard then input the correct phone number or select the phone number from contacts or select it from the call history, then tap the “Dial” button, can make a call. The dialing main interface is as below:
*Interface image*
F1_SF1_C2 ：
Tap the “End call” button……
F1_SF2........：

二、测试需求分析

测试需求分析就是将前面提取出来的case描述逻辑词汇识别出来，画出逻辑关系图，再使用决策表或者因果图的用例设计方法，一个功能点尽可能全面的覆盖尽可能多的测试用例：

举例如下：（个人观点，仅供参考，讲得不对也请指出来）
1、 将子功能Case描述中的逻辑关键字提取出来，如：或\或者（or）、和（and）、与（and）、并且（and）、然后（and）、否（not）、不（not）、非（not）、反之（not）、当（if）、如果（if）等，建立起步骤间的逻辑关系。
2、 将子功能Case描述中的句法和语义进行分析，将条件、动作和结果分别识别出来。
比如，F1_SF1_C1就可以被分解成：
<Tap> the keyboard (then) <input> the correct phone number (or) <select> the phone number from contacts (or) <select> it from the call history, (then) <tap> the “Dial” button, [can] make a call.
根据例1，可以画出测试步骤逻辑关系。
  因为例一较简单，所涉及的逻辑层次只有两层，对于有三层以上的情况，将会有更加复杂的逻辑关系图。

用例设计
根据

    测试第一步应是文档先行,而不是拿到软件就开始盲目测试!   

    软件测试的原则之一就是“尽早的进入到软件开发周期中进行测试”。在产品需求设计阶段，测试人员就应该开始介入，一方面是为了参与产品需求设计的验证和确认，从而在软件开发初始阶段降低软件缺陷的发生；另一方面是尽早的理解产品需求，为测试计划的定制和测试用例的设计做准备。

    因此，需求确认阶段的测试用例很大程度上来自于对于产品需求设计文档的理解和解析。但是，由于软件开发面向需求的特性，使实现过程中软件需求不断升级、细化、变更和增加，其所伴随的测试例等也必须随之升级以适应，导致测试任务难度加大，风险升级。

    把握好测试用例的上游产品——需求说明书的质量，就能够尽早的发现问题；通过对需求规格说明书特性的分析，以及测试用例与需求说明书之间关系的分析，就能够很好的建立起测试用例与需求之间的关系，增加测试覆盖率，提高需求文档的编写质量。

需求规格说明书的特点如下：

1.    不含糊的／无歧异性：

   最终产品的每一个特性只用某一术语描述，使用正规化的需求说明语言。

2.    可追踪性

   每一个需求的来源是清楚的

   具有「向后的追踪能力」：每一个需求皆明确的参照到他先前文件的来源

   具有「向前追踪能力」：每一个在SRS中的需求皆具有独一的命名或参照号码。

3.    可验证性

4.    完整性

   对于所有有效或无效的输入值皆必须明确说明软件的响应

   所有在SRS中的图片、表格与图例皆必须具有完整的标示与参照，并且必须定义所有的名词与衡量单位

5.    一致性

   各个需求的描述不矛盾。即所谓的内部一致性

   一个SRS 是具有内部一致性的，则表示没有个别需求描述的子集合是互相冲突的

   SRS 中可能发生的冲突：真实世界的对象的具体特性可能发生冲突；在二个被叙述的行动之间可能有逻辑上的或时间上的冲突；二个或较多的需求可能描述相同的真实世界对象，但却使用不同的术语

6.    可修正性

   SRS的结构和风格是可以修正的

   任何需求的变化皆可以容易地、完全地、和一致地进行，并且保持原有的结构风格具有一个一致、易使用且包含目次 , 索引, 和明确的前后参照的组织不是多余的分开地表达每个需求，而不是与其它的需求相混合。

需求说明书的低级测试技术

完整。是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？

准确。解决方案正确吗？目标明确吗？有没有错误？

精确、不含糊、清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？

一致。产品功能描述是否自相矛盾？与其它功能有无冲突？

贴切。描述功能的陈述是否必要？有没有多余信息？功能是否原来的客户要求？

合理。在特定预算和进度下，以现有人力、物力和资源能否实现？

代码无关。是否坚持定义产品，而不是定义其所依赖的设计、架构和代码？

可测试。特性能否测试？测试员建立验证操作的测试错误程序是否提供足够的信息？

需求说明书7个用语检查清单

1.总是、每一种、所有、没有、从不。

看到此类绝对或肯定的切实认定的叙述，可以着手设计针锋相对的案例。

2.当然、因此、明显、显然、必然。

这些话意图诱使接受假定情况。不要中了圈套。

3.某些、有时、常常、通常、经常、大多、几乎。

这些话太过模糊。“有时”发生作用的功能无法测试

4.等等、诸如此类、依此类推。

以这样的词结束的功能清单无法测试。功能清单要绝对或者解释明确。

5.良好、迅速、廉价、高效、稳定。

这些是不确定的说法，不可测试。如果在产品说明书出现，必须要求进一步指明含义。

6.已处理、已拒绝、已忽略、已消除。

这些说法可能会隐藏大量需要说明的功能。

7.如果...那么...（没有否则）。

缺少配套的否则，想一想，“如果”没有发生会怎样呢？

     从上面我们可以看出，需求说明书的这些特定用语都带有逻辑和程度的语义，测试工程师可以通过分析这些语义逻辑关系，再结合因果图和决策表的用例设计方法设计出测试用例来。

     更加深入探究的话，如果一份严格按照一定的规则编写的需求说明书，就能够通过计算机对自然语言的逻辑分析，再结合因果图和决策表的用例设计方法，自动产生出测试用例来。

三颗猫饼干

   我第一次听到《三颗猫饼干》就被它纯净的钢琴、甜美的童声深深打动了。时而欢快、时而沉静的音乐，仿佛把你带到了没有烦恼的童话世界。

   第1颗猫饼干：
     让我们在悲伤的时候，找到心灵的依伴！
   第2颗猫饼干：
     让我们在春、夏、秋、冬四季的迭替中，发现时间是疗愈伤痛最好的药方。
   第3颗猫饼干：
     让我们在人生的经历中，学会面对，才能继续拥抱生活。

   童年时光，是每个人都埋藏在心灵深处的一片净土......音乐仿佛在给我讲述一个故事，带我进入到小女孩和三颗猫饼干的心灵之旅：

   一只猫和三颗许愿的猫饼干，化解了悲伤，不再孤单、不再寂寞，重新的拥有了爱和关怀。
   在这个真实空间里，爱让梦想还存在！ 一份最温暖的心灵礼物，一个触动人心的音乐童话
   每个大人的内心都住着一个小孩，每副坚强的外表下都藏着一颗脆弱受伤的心。三颗带着希望的猫饼干，一段单纯唯美的奇遇，让你在37℃的橘色温度里，停止眼泪，不再背负伤感 。
   一个十岁的小女孩，和爸爸妈妈及唯一的哥哥住在一个拥有一大片橘树的山上，那里有她十岁以前的幸福。一场意外，带走了她的哥哥、带走了她的幸福与和快乐，也同时将她带离了那个只剩孤单的家。小女孩的流浪旅程里出现了一只猫，这只猫让她的孤单得到了出口，她不再寂寞。而一位老婆婆的出现，不但让她得到实现愿望的满足，也同时让她找回了爱和关怀。
   带着悲伤离家的小女孩回家了，带着在旅途中感受到的爱和关怀，以及学会的分享回到了家中，重新的拥有了幸福。随着音乐徜徉在一个童话世界里，我们看见自己的影子在画面的流动中，进行一场关于爱的探索。 
   随着流动的音符穿越整个故事情节，何真真透过春、夏、秋、冬四季的变换，在光阴与自然时序的交替中，描绘出人的心情起伏变化，也记录下不同的季节氛围里带给我们的信息。

   春天，粉彩缤纷的花瓣散落一地，同时让人计画着该以什么姿态跃入新的开始？
   夏天，海天一色的大海，把所有心事都消融在纯真无暇的湛蓝里，一个需要轻盈的脚步才能尝到清新空气的季节！
   秋天的温度，则让人忆起孩提时光，微凉的空气里弥漫着大地将要荒无的气息，却也让我们学习面对万物之自然消长。
   冬天，树木裹在透明的冰晶下，提醒我们要永远保有心灵的澄澈干净，才听得清楚、看得远。 

    当我们长大了，「复杂」的思维成为一种必然，很多简单的事物开始变得沉重——后来一天，才发现要回到过去的单纯并不容易。很多孩子长大了，必须挺起胸来面对成人世界的种种。我们原始纯真的面貌逐渐模糊，很多简单的事物开始变得复杂而沉重。

    我想把这一份心灵礼物送给每一个朋友，希望透过音乐中丰富的情绪和哲理，抚慰每个人内在需要被呵护、被关爱的那个部分，让我们在温暖的空间里，得以保藏孩子般软润的心。
    三颗猫饼干 —— 夏天的风吹在蓝色的海上，白色的云随着风自在的飘逸，我躺在绵绵的白云上，听着鲸鱼的呼吸，看着海鸥飞过，这一幕让我想起童年的笑声。其实每个大人心里都住着一个小孩，只要静静的听就会找到那最自在，纯真，平静的自己，Soul is free 自由的心才有真实的爱。爱是一种探险，等待对方付出，不如自己先去实践；爱是一种自由，可以在任何时间进入心门，没有阻碍；爱是一种满足，在一起的时候，不说话也很自在；爱是一种欢迎， 当非同类出现的时，大方的邀请他加入；爱是一种魔法，在真实的空间里，还有梦存在的地方。 


专辑曲目：

01.Opening 心植桂冠http://mail.tses.tcc.edu.tw/~christin/MP3/01.mp3
02.Spring in pink 粉红色的旋舞（春）http://podcache.cctv.com/published1/2007/11/16/pub1195145350022.mp3
03.Summer`s blue 贝壳里的心事（夏）http://podcache.cctv.com/published1/2007/11/16/pub1195145349086.mp3 
04.Silent love 微笑的弧度http://podcache.cctv.com/published1/2007/11/16/pub1195191062627.mp3
05.Autumn breeze 起风前的相遇（秋）http://podcache.cctv.com/published1/2007/11/16/pub1195191063188.mp3
06.A wish 礼物http://podcache.cctv.com/published1/2007/11/16/pub1195191063942.mp3
07.Crystal winter 透明的灵魂（冬）http://podcache.cctv.com/published1/2007/11/16/pub1195191064644.mp3 
08.If You were by my side 桔色温度http://podcache.cctv.com/published1/2007/11/16/pub1195191067929.mp3 
09.Frozen tears 晶冻的眼泪（冬）http://podcache.cctv.com/published1/2007/11/16/pub1195191067476.mp3
10.Loving is a splendid thing 爱是绚烂的事http://podcache.cctv.com/published1/2007/11/16/pub1195191066669.mp3
11.Soul is free 永不停止的愿望http://podcache.cctv.com/published1/2007/11/16/pub1195191065924.mp3

   算算从今年4月CMMI项目开案到现在我作QA工作有4个多月时间了，一直有心写一些心得体会来记录自己的成长历程，今天终于下定决心

   我们公司是做个人消费电子产品，研发中心的项目永远在追赶市场，出货大过天。虽然是出货很紧急的消费电子，但是质量仍然很重要，因为质量塑造品牌，客户就是上帝！！

   我们公司在硬件生产方面还是很牛的，去年10月份才成立了这第一家软件研发中心，而我就是这个新生的软件研发中心的质量和测试部门的一名新人。在过去的4个月中，我加入到推进软件成熟度集成的工作中，的确是一个挑战。

   过程质量和低bug率共同决定了产品的质量，而我们QA就是保证软件过程质量的这样一个职位。虽然过程质量不能在短期内给公司来带明显的经济效益，但却能够提供一个长期的可持续发展的机制保证公司不断成熟成长，最终实现所有项目过程和行为可量化可控制，有经验可循。

   今天，我被安排整理QA的工作内容列表，一是为了结合公司实际明晰QA的工作内容；二是为了量化QA的工作，更好的统计QA绩效。这个工作我正好适合，因为我平时都有做工作笔记的习惯，于是我就将我的工作笔记进行了简单的整理，列出QA工作内容：（工作经验有限，一定存在漏洞和问题，请各位指导）

立项准备阶段：（QA准备介入项目）

1)      与高层成员有一次交流，了解高层对该项目质量所寄予的期望和指导；

2)      QA提前与项目主要成员认识，相互了解；

3)      在可行性分析阶段学习和熟悉项目业务；

4)      确认并确保项目经理已经掌握足够的项目信息：包括项目成员，难度，项目压力，该项目和其他项目的关系，自主力度，资源分配……

5)      从项目经理处获得上述项目信息；

6)      确认和确保项目经理根据所收集的项目信息进行预估和分析：项目类型分类，项目生命周期类型定义，人员经验和意愿情况分析，资源情况分析；

7)      与项目经理讨论关于项目情况和预期达到的品质标准，启动并确保项目经理拟定了项目周会的方式和时间；

8)      确认和确保项目经理已经对项目风险进行了充分的识别、分析和提供解决方案；

9)      收集项目过程类培训需求，对相关人员进行培训；

10)   从模板基线库挑选和准备相应过程文档模板，并保证其正确性；

11)   立项报告完成后，得到里程碑，根据对项目的了解分析和检查其合理性；

需求设计阶段：（QA正式介入项目）

12)   检查项目经理在进入需求设计阶段一个工作日内填写了项目文档列表；

13)   定期检查里程碑和项目文档列表的吻合度；

14)   确保各成员会用文档模板，请他们按照里程碑定义准备需要的文档；

15)   项目详细时间表出来前按照里程碑的时间定期检查文档完成情况和评审过程实施情况；

16)   定期收集整理项目组所使用的模板情况，多少是标准模板？多少是试运行模板？

17)   指导项目组走模板维护流程；

18)   协助指导并评审相关职能部门所产生的流程

19)   按照评审过程指南，抽查评审效率，及时发现评审过程问题并指导；

20)   收集项目数据：如文档工作量，评审工作量，人数，时间等；

21)   需求文档评审QA必需参加，并且根据Spec check list进行评估，确保下游顺利交接；

22)   需求文档评审通过后，请各成员根据需求估计工作量，并出附属计划；

23)   工作量估计粒度适度，充分沟通保证项目成员主动接受该任务；

24)   完成QA计划，和项目经理讨论具体对那些过程需要进行质量评估，项目经理在组织项目组实施过程的时候就可以通知QA参加。QA计划中需要定义在过程产生的几个工作日内进行QA的审计和评估工作。

25)   确保和保证项目经理集成所有附属计划；

26)   确保项目经理在项目进行过程中实时更新和跟踪风险管理任务；

27)   QA在审计和评审过程中，发现不符合项和预警内容，需及时highlight，保证高层及时了解项目进展；

28)   参加pre kick-off会议，检查和确认当前状态符合kick-off要求；

29)   确认在pre kick-off完成的两个工作日内进行项目kick-off；

Design&Coding阶段：

30)   需求文档评审通过，立即提前了解并确定HLD设计模式，单份文档还是多份文档？设计模式？

31)   在需求文档评审通过的5~6个工作日内，检查HLD设计完成情况和评审过程；

32)   在需求文档评审通过的5~6个工作日内，检查TCS设计完成情况和评审过程；

33)   检查TC完成情况和评审过程；

34)   定期审计评审过程，评估评审方式的实用性，指导评审过程；

35)   定期抽查文档完成情况（需求文档定稿版、HLD、TP、TCS），抽查文档质量；

36)   定期抽查项目组内部各成员所掌握的文档一致性；

37)   收集需求和设计变更次数，抽查变更过程与标准化流程吻合度；

38)   定期核对开发组、测试组的Schedule，要求细化到3天以内，保证项目经理及时发现延迟并分析原因；

39)   参加项目周会，从QA视角评估本周状态，并及时收集项目状态；

40)   QA在审计和评审过程中，发现不符合项和预警内容，需及时上报，保证高层及时了解项目进展；

Alpha & Beta 阶段：

41)   定期检查测试流程和标准化流程的吻合度；

42)   定期检查debug流程和标准化流程的吻合度；

43)   定期检查debug状态；

44)   定期检查TR，并分析其与项目质量目标的吻合度；

45)   定期检查项目release流程按照标准化流程进行；

46)   发现严重质量缺陷及时发起Pending；

Deliver阶段：

47)   完成QA summery report；

48)   整理项目度量数据，为过程改进提供建议；

49)   参加项目summery report；

50)   收集整理项目文档、模板、流程、经验；