Fix 协议的简单介绍

层级介绍

（应用程序层）Application level Messages
（会话层）Session Level  Messages
（通信层）Communication  Protocol  (i.e. TCP/IP)

通信层（Communication）是基础平台。

Fix协议 session level和app level都是基于通信层的信息传输。(TCP/IP相关协议信息略)

Session level基本包括的内容：

sequence number-信息传输时的信息序号管理

logon/logout process管理

test request,resend request, sequence reset, reject..

Heatbeat..

Application Level是业务层。定义了客户真正为了传输业务而存在的一些信息。包括了固定的general level的一些信息和用户个性化的信息。

Fix相关的测试在绝大多数cover的都是app level的东西。对于Session level会在server测试里面涉及。特别是full测试和新客户加入fix engine时的必要测试。比如说会话的创建，取消。中断，恢复等等。

对于app类别的测试就要取决于客户的一些具体的需求了。其中对于参数的类别测试（界限值等），参数的逻辑测试和业务rule的测试是必须掌握的重点，而这一切的基础都是对于客户业务的一些了解。

fix 里面常常会测试的一些基本参数

tag55->symbol

tag40->ordertype(MRK,LMT...)

Tag44->Px

Tag59->Time in Force

Tag58->Text

Tag54->Side

Tag15->Currency

Tag37->OrderID

..

此外还有52，62，49,56,128,126，

某些参数可以根据不同的版本在fix协议网站上查找。

http://www.fixprotocol.org/FIXimate3.0/

当然真正在测试它们的时候是基于业务的。

比如说某一类数据的传输，在client基于逻辑规则如何转成fix可以识别的字符串，然后在fix engine里面读取的是否正确，所有的tag值是否正确。而某些格式是否符合了规定的local exchange/currency的规则。等等。

对于supprot Fix protocol的金融证券软件来说，Fix engine的利用， Fix protocol的测试是必须的组成。

Fix engine一般都是配置在交互的双方server用于信息传输的。它们之间所使用的也都是Fixprotocol。

Fix protocol金融交换协议。

百度一下可以得到如下解释：

融信息交换协议(FIX，Financial Information exchange)协议是适用于实时证券、金融电子交易开发的数据通信标准。 它是由国际FIX协会组织提供的一个开放式协议，目的是推动国际贸易电子化的进程，在各类参与者之间，包括投资经理、经纪人，买方、卖方建立起实时的电子化通讯协议。Fix协议的目标是把各类证券金融业务需求流程格式化，使之成为一个个可用计算机语言描述的功能流程，并在每个业务功能接口上统一交换格式，方便各个功能模块的连接。

Buy Side -----Sell Side以及证券交易所(exchange)之间进行信息联通的，世界标准即Fix protocol。

由于它是一个标准性的协议，所带来的好处就是投资人/投行涉及到更换Broker(券商，证券公司)的时候，也包括很多证券公司合并倒闭之类的事件发生的时候，可以做到无缝对接。

中国目前还没有应用Fix 协议。也因为历史的原因和“特色”的原因。中国差不多80%的股民是散户，只有10-20%属于机构投资客。

应用Fix协议的软件和没有应用的有什么区别呢？

从证券的历史来讲，最开始的stock trading是起源于tel,mail的方式来预约需要买卖的股票，特点是：小，散，慢。证券的第二阶段是各自为营。其实就是我们目前国内证券业所处的时代，机构也好，个人也罢，如果想买卖股票的的前提就需要去找到一个broker（券商，证券公司），然后注册自己的账户，然后拿到一个这个公司开发的软件安装在自己的电脑上，然后进行DMA的trading。但是每一个broker都有自己的优势和劣势，也不是所有的broker包含所有的stock 信息，如果你在BrokerA处买不到相应的股票，只能去brokerB那里再开一个账户，再安装一个BrokerB的软件。然后进行trading..所以对于投资量大的机构投资者来说，这样对于管理是极为不便的。

这个背景之下，Fix协议应运而生。它的缔造者是富达，最初也是为了欧美的几大股市的方便应用和整合。而今已经辐射到亚洲除了大陆A股以外的地区。

Fix协议所支持的系统，由于使用的是同一种协议语言，所以在可以很方便的进行内外通信。在系统迁移等变化时也非常的方便。同时市场上也出现了提供支持Fix协议，链接多家支持Fix协议的broker的软件。可以做到一头连接buyside，一头链接不同的broker。让buy side们可以自由选择自己想要trading的broker。

PS:据说上市也进入了FIX协议，不过修修改改，美其名曰本土化，实际上还是把国际通行的FIX 协议搞成了一个残次品。

而一般

以往对我们来说，QA的一部分职责是提交issues,retest.至于修正标准如果spec没有依据的话，应该让developer去跟对应负责人来说。然后确定一个方案来回馈给我。

而现在，不知道什么时候开始，便成了我需要把各个没有明确依据的issue去跟澳洲的负责人去讲，然后拿来解决方案告诉developer如何去改。如果澳洲的负责人不确定，往往愿意问我：How do you like the behavior?How do you think?

让我觉得有一些压力。万一我的修改意见牵涉面太大，价值太小怎么办？最近总被这样的事情纠结着。有些时候，其实判断价值，风险不是一个很明确的可度量的东西。

我尽量的去跟developer沟通，了解一些修改可能引起的风险，进而决定是否需要修缮一下自己的解决方案或者跟澳洲研发中心的Top们去讨论一下。

偶尔觉得自己不知道是level提升了还是错位了。。。

这样的转变其实很多时候我还是有些开心的。因为很多基于业务的理解，我可以有依据的去指导开发人员去做成一个什么样的东西以便于达到客户的要求。但是有些时候，没有明确依据的时候，往往就会担心。我这样的想法是不是真的可行，会不会引起别的问题？

以往在ibm，这样设计方面的修正或者功能上的改善，或者没有明确依据的问题的修改，我们都会提交给专门的consultant/Architect来进行评估，防止有预期之外的风险存在。

也曾很羡慕那个高高在上的consultant，希望有一天自己可以成为那样的人。

今天似乎触摸到了consultant的一些零星小事，才发现，其实很多事情，简单的决策背后需要拿出的勇气和付出的努力是别人所无法估量的。

悉尼那边这样的人有，但是去忙别的product去了。于是那个原本只是开发层面上的负责人接管了一部分这样的工作。除非他觉得这样的问题自己不确定，否则会按照我提供的方案去进行修正。但是偶尔，我发现，他的方案也有自相矛盾的地方，所以这样的隐忧越来越多。

How i can do to solve the problem?

测试人员需要为产品质量负责吗？
这句话其实可以这样问
医生需要为病人的病情负责吗？
答案是肯定的。
一个产品从测试人员手中走过，测试人员需要对它进行有目的的有效的测试，确保尽早的发现产品内在的缺陷，从而在最短的时间内促使开发人员完成对产品的修复，减少企业因此而将要承受的损失。
这需要测试人员的责任心。面对一个测试任务，需要的是细心，耐心以及自我的分析。知道成本和效益的关系，了解客户最大的需求，知道面对的这个任务，自己的轻重缓急在哪里，不能磨磨蹭蹭，以至于耽误了最佳的测试时间。
如果测试产品从测试人员手中流过，却没有被检测出隐含的最大的问题，那么就是测试人员的失职。就如同一个医生面对一个病人，经过一番检查，却没有任何的诊断抑或遗漏了最大的病患。。
但是反过来讲，测试人员不能对产品的任何瑕疵都负责任，不可能为产品的质量去100%买单。测试人员只对测试的质量去买单，只为测试的成果负责。
测试人员虽然尽心尽力的对产品进行了最为有效的测试，但是因为客户的决定，或者开发人员的推委，导致产品的已发现的重大的问题没有被解决掉。面对这部分，测试人员不需要去负责。

但是也不要因此就影响了士气。虽然，很多时候，人们总说，一个软件做好了，是开发人员的功劳；做得不好，使测试人员的不是。也有很多人，因为这个原因而离开了测试队伍。因为觉得自己跟“替罪羔羊”一样的无奈和无辜。
其实，很多时候，任何角落，都有一些前台的和幕后的英雄，并不是站在领奖台上的人才是最光荣的。无论是设计者，开发者还是测试人员，都是软件生命周期中不可或缺的重要组成人员，大家共同的努力才成就了软件的上市以及企业的盈利和良好信誉。每一个都要为自己的存在而感到自豪。自己的地位靠自己的努力来不断的得到证明，自己的能力不需要别人的证明。金子在沙地也是金子，沙子在金堆也总是沙子。如果你觉得自己被轻视了，那么，不要放弃，请你努力！相信吧，自己今天的努力一定会换来你更美好的明天。

测试人员在面对测试任务之前一定学会思考，从客户，从市场，从软件本身的特点去方方面面的思考，知道自己该如何把握，该怎样策划你的测试用例。该如何更加有效的去发现更有价值的bug.
很多测试人员都觉得很郁闷，当他们的bug被开发的以不需要修复为由而拒掉。但是这个时候抱怨没有用的。开发人员这样做，你要找到理由。开发人员绝对不会贸贸然把一个可能导致软件崩溃的bug置之不理。如果是这样的bug，那么，可能时间已经不够，修复的风险太大，这个时候你要理解，而且要帮助他们出主意，看看怎样解决才是最好。如果你的bug无足轻重，而还有一大堆的问题你都没有去发掘，那么，坐冷板凳是应该的。这个时候，你能做得最好的事情就是，自己多去想，有效地发现出更多更有效的更重要的bug来。

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

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

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

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

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

我无语。。

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

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

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

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

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

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

1.沟通能力。

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

2.移情能力。

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

3.技术能力。

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

4.自信心。

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

5.外交能力。

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

6.幽默感。

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

7.很强的记忆力。

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

8.耐心。

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

9.怀疑精神。

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

10.自我督促。

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

11.洞察力。

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

从二月份的春寒料峭到8月的桃李芬芳，我的项目居然也作了半年。

8。15，一个历史的纪念日，中国抗日战争胜利63周年纪念日。

我也告别了这个项目.

回想起半年多来的这个项目，真是感慨万千。

每个人都需要学习，在他经历的每一件事情里面。

在这个项目里面，我学到最深刻的东西就是，协作。感受最多的是合作。

测试工作需要太多的沟通和合作，任何一个人的不合作都会导致整个项目的失败。从业4年来，也深刻的体会这一点。

这个项目，属于我第一个参与的，国际化的项目，开发，设计，测试，沟通和管理都由不同地域和国家的人来组成。对我来说，新鲜感十足！：）同时，也因为大家来自不同的地域，不同的国家，工作的习惯包括交流的方式都是不同的。所以，要格外的注意至少不要用对方无法接受的方式与对方沟通。这一点，好在我从头贯彻到尾。

这个项目，我做得很累，但是很开心。

不仅仅是因为到了项目的后期，我一个人可以承担起整个中华区的沟通和测试作业，让我足足满足了一把。

也不仅仅因为跟我沟通的美国客户对我赞赏有加。。

从对日改到欧美，这个项目让我真实地感受到，我真的没有选择错，我就应该在这样的空气里面生存。

在对日的项目中，即使我在力求完美，却无时无刻不在担心日本客户吹毛求疵般的review我提交上的东西，然后发过来一堆指摘。。我感觉自己的每一根神经都在通过他们的审查之前，崩的快要断了。。半夜都会梦到自己测试的结果，提交的周报出了问题。。

我确实从对日项目的三年经验里面学了很多规范的流程，严谨的态度。这些让我至今收益。。但是我不愿意再去过那样的近似于自我摧残的生活。

每当我发行一个bug,我第一个念头不是考虑这个bug的详细分析，不去考虑是不是可以给开发人员提供更多的帮助，让他们可以尽快地找到问题点，更快地解决这类问题。。而是格式是否正确？资料是否齐全，如何搜寻到更多的证据来证明自己发行的确实是个bug。。

欧美的项目中，我依然也需要为发行一个bug提供若干的资料和数据，但是类似的行为却又不一样的目的。我会受到的不再是质疑，指摘而且友好的询问和感谢。然后让我帮助他们分析，是否在什么地方进行了某个操作，他们为什么会如此推断。。让我也加入到这个分析中来。。

从某种意义上讲，我第一次真切地感受到了自己的价值，第一次感觉的自己和他们是平等的。

我所作的项目是一个关于中国古老文化的项目，作为根本不懂中国文化的海外同事，每每因为文化差异的不同理解错了某个场景的设计，我们都会在文化的交流上得到一番新的感受。第一次知道自己熟知的那些文化礼仪，原来在西方人的眼中是那个样子。。

8。15，项目宣告结束了。准确说，是我撤出了这个项目，因为经费不足，也因为这个项目的负责人虽然在后期认识到了测试人员的重要性却无力回天。。

美国的客户，虽然我们在项目过程中因为彼此工作习惯的不同有过几次摩擦，却给与我了一个很高的评价。最后一天工作，负责沟通的那个美籍台湾人说，when i told the developers that 8/15 is your last date of this projects, they all very happy..see how great job you have did..You are great helper. We helped them too much in the project, and you did most of it. Thanks all your help...

不可否认的，因为这个评价，我美了一天。。那种感觉，似乎比接到她从大洋彼岸给我寄来的礼物还要兴奋很多。。

我不知道以后的项目还会遇到些什么事情什么人，会不会再一次遇到如她这样nice的人，但是我知道，我的工作还会继续。。我也会更加努力的去实践testing life is part of my life的诺言

外派，一个在IT领域一点都不陌生的词汇。外语一般称之为on-site

在中国已经有一段时间的历史了。

外派，最初对于所有人来说都是一个美丽的梦

因为门槛或者技术或者外语等等限制，想到世界top级别公司上班却无法去的人，可以作为某一个外派公司员工的身份，可以以技术，外语以及门槛略低的条件进入那样的公司工作。如果表现突出，则可以找到合适的时机，成为梦想中的公司的正式员工。

外派，走到了今天，又几乎成了很多人的一个伤痛

因为外派，工作地点不在自己的公司，除了当初找自己进门的hr,公司小的领导会认识你，公司大的领导都不会知道你这个人的存在，除非你惹出了大的麻烦。。公司的福利待遇，公司的免费培训，公司的员工的归属感，优越感。。等等都与你天生没有关系。。

而你派往的那家公司，即使知名度很高，既是薪资待遇很高，福利很高，对员工很人性化，跟你也没有关系。因为你不是他们的员工，他们的待遇几乎可以说是天经地义的跟你没有任何关系。虽然你在为他们干活。

劳动力成本在上升，公司在缩减成本第一个想到的就是把项目到期，后续项目没有消息的你，开出去。。

于是，你回到了似乎陌生又似乎熟悉的自己的公司。

面对的是公司老总一张阴沉不定的脸。良久，告诉你说，因为你没有项目了，暂时无法给公司创造价值。所以经过公司领导的商议，决定给你开基本工资-800抑或1000，等你找到项目，工资再行调整。。

于是，你无语问苍天，于是，你终于知道，外派，原来是这样的一个过程。。

这不是开玩笑，是真实的发生在我身边很多外派同仁的故事。

写到这里，我想说，如此的待遇，如果你是外派员工，你还会以外派的身份工作多久？还能坚持多久？

同样，秉承着有项目有待遇，只能从员工汗水中榨取剩余价值，却无法为员工分担风险的外包公司？你的路还能走多远？

一个很古老的话题

每一本书都会有自己的解释，无论作者有多少的测试体会

每一个人都会有自己的觉悟，而不论有多少的经验

民间的包括所谓官方的（IEEE）,如果你愿意，可以在网络上都到成千上万也不同的说法。

软件测试的目的到底是什么？

相信每一个步入测试领域的人都曾经问过或者想过这样的问题

这个问题也曾在我学习的过程中困扰了我许久许久。

最终，至少在理论上我们可以找到这样的答案：

软件测试的目的在于通过各种手段来验证需求的正确性

软件测试的目的在于尽早的发现bug..

但是实际的测试中，我们发现，我们测试的目的其实是两者兼有的。

如果说测试的目的在于验证需求的正确性，没有什么不对。验证的方法也多种多样，比如静态/动态的测试，比如通过性和破坏性测试，比如黑盒测试和白盒测试，比如手动测试和自动化测试。。

只不过，验证需求的正确性作为目的话似乎也不全面。原因在于，1.发行bug一定程度上可以激发测试人员的测试积极性。在很多的公司，也是考核测试人员绩效的一个很重要的数据。2.用最少的测试用例，在最短的时间内发现迄今为止没有发现出来的bug，特别是对系统影响深远的bug对于一个产品的成败有着很大的意义，对于客户的修复成本也有重要的意义。如果仅仅因为验证需求，有一些潜在的问题就不会有人有那么大的兴趣去挖掘。最终的结果就会导致，测试的质量在某种程度上难以保证。

但是发行bug也绝对不是软件测试的唯一目的。其道理很简单。一味的强调bug的重要性，发行bug作为测试的唯一目的势必导致测试人员盲目的为了发行defect而偏离了测试的重心。

所以软件测试的目的应该是双方面的，通过各种手段验证软件的需求，并且尽早的发现bug以促使软件得到尽快的修复。

首先，保证了第一方面，验证软件的需求，可以保证测试的覆盖率，客户关注的功能可以不被忽视。尽早的发现和发行bug,可以促使问题可以得到早日的解决，对于客户来说，也可以节约大量的修复成本。

测试之路，路漫漫，其修远兮，吾将上下而求索。。

前几日，和同事讨论起这个问题，偶有所感

1。 何谓测试同化现象

所谓同化现象，一方面是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。这是从主观上讲，也就是说从人的主观能动性上来讲这个现象。

此类同化现象的发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。可是这种没有问题却真正的意味着软件风险的扩大。

从另外一方面来讲，测试同化现象也被称之为“杀虫剂现象。术语“杀虫剂现象”（1990年，Boris Berizer在其《software testing techniques》中杜撰了“杀虫剂怪事”）用来描述软件测试越多，其对测试的免疫力就越强的现象。同样的事情发生在对昆虫使用杀虫剂上。如果你总是用同样一种农药，害虫最后就有了抵抗力，杀虫剂将不再发挥作用。

这样的现象是从客观角度来看。不是因为人为的疏忽而是一种客观无法回避的事实。

2。如何避免测试的同化

很多人建议说，应该多发布测试版本，应该多招聘新的测试人员来避免这样的事情。而实际上，这不是能解决这个问题的根本。

从主观来说，主观方面造成测试同化的原因是在于人的因素。是习惯了开发人员思维，并且相信了开发人员解说的人造成的一部分测试同化。对于这样的原因，用招聘新的测试人员来觉得其实是不明智的。

首先要加强测试人员的自我修养，让他们认识到测试的原则在哪里，而且要挖掘自己的怀疑精神（怀疑精神是测试人员的必要的素质之一），不能轻易相信开发人员似是而非的理论。要学会一切用事实证据说话，没有证据证明的东西不要轻易的去相信。

另外要加强测试员之间的互动，不能由一个测试员总是测试相同的测试项目/模块。而是要时常进行轮换，这样一方面可以避免之前被遗漏的点尽快地被找出来，也会避免因为太熟悉而忽略某个测试的严格度。当然对于主观上确保降低测试同化，也起到很大的作用。

对于客观方面成就的测试同化，测试员应该养成从多角度来观察问题的习惯。并且在自己之前设计的测试用例，几轮之后已经无法测试出bug的时候，要学会补充设计新的测试用例，从而从别的角度发现新的问题。

这个题目的书写，主要是因为我在实际的测试过程中遇到两次的“思想对抗”

一个是关于测试结果的评价标准

一个是关于defect的更改状态标准。

到今天真是感慨万分，想当初，这个问题要是能及时地理顺了，哪里会有着许许多多的纠缠不清呢。

一个项目启动，一般的都会注意到这几个方面，测试环境，是否搭建完成；系统开发到什么程度，是否有QA系统；测试数据，是否有，没有的时候怎么准备；测试的case书写的标准，包括在哪里写，defect在哪里写。。诸如此类的，还有就是测试的人员配备以及测试的进度表。

诚然，这些都是大块。一个测试项目必不可少的东西。

其他的呢，自然还有。只是一开始，大家很少能想到

比如说，测试成果的提交，Fass, Failed,Bloced,Implement;还是OK,NG,Bloced,NA,NT?

这两种我都遇上过。

还有，测试中，什么样的结果为Failed,某个case运行失败，且排除其他原因，肯定为failed或者NG,那么跟这个case相关的呢，缺少一步或者多走一步产生的问题呢？是否标注这个case为fail?如何处理？

什么样的结果为block?没开完？测试数据不具备？还是因为某个fail导致的一些case没有办法测试下去？

这样的问题，细致讨论起来，要很久，不同的标准都有道理。测试的管理者往往考虑了大块，没有注意到人。

没有注意到这些细节方面的规则。他们并不知道，这些小小的细节会对以后的进展造成怎样的影响。

每个加入到新项目中的人都有他自己的背景。都曾经被约束在某一个规则中。但是当初的规则和现在的，未必合拍，如果没有经过重新的定位，他依然会按照自己已经习惯的规则去走。那边，结果是什么呢？

大家的作业乱七八糟，什么标准什么格式都有。后期的整理就会有问题。因为没有共同的认知。尤其是交接工作的两个人的工作习惯迥异的时候，没有统一的规则，会给后来的人造成很大的麻烦。

defect,怎么确认一个问题是defect，一般控制比较严格，那么，如何close一个defect?如果经过测试，defect本身出现的问题被修复了，但是出现了别的问题，这个defect是否必须被保留？是否可以重新开一个新的defect,关掉这个？

我之间的规则是，关掉旧的，在旧的defect上写上备注，重新开启一个。但是新型的规则，就需要把一个defect弄成烂婆娘的又臭又长的裹脚布。。

所以，经历到现在，我知道了，测试管理的前提，还需要做好一些细节性的东西，比如，以上这些。。

其实也不是局限于电子产品，只不过电子产品这个问题突出一些。

现在很流行的趋势，电子产品一般只要你买得起的，大家一般都不会选择去买国货。尽管广告天天在打，可是很多消费者并不认可。原因何在？产品的质量有问题，产品的售后也不好。这说明了什么，生产开发这些产品的人有问题，质检的人也没有起到很好的作用。恶性循环的结果是这个厂家失去了市场和受众的信赖。

还是拿手机来说，同样的价位，国产的手机肯定销量远远小于nokia，为什么，因为几乎所有的人都认可nokia的质量，却无法给国产手机以同等的信赖。也说明了这个道理。

一个企业赖以生存的是信誉，是产品的质量。所以你如果去过车间，都会看到很大的一个条幅，上面写着“质量是企业立足之本”。这句话没有错，但是在实际上，中国人的中庸哲学和理论却无法，至少在很多时候，没有保证真的把这句话落到实处。为什么？成本。一文钱瘪倒英雄汉，更何况你为了某个产品需要花大价钱开请高手？

我没做过nokia手机的测试，我曾经做过3年左右的日系手机的软件测试。他们的手机品质不错。我们使用的对比机就是nokia的手机。企业的目标就是同样的问题，nokia不出现的，我们的手机出现了，就是问题。当然如果nokia也出现了，值得提交的问题也要提交。

我很感恩那段日子，虽然每天都处在“辐射”的阴影里，我在那段日子里学了很多。学到至少日本企业的那种严格的管理和缜密的思维以及规范化的流程。

这在后面的参加的国内，国际项目中是没有遇到过的。“一叶知秋”，做习惯国内项目的人很少有人能去做日本项目，原因是觉得他们“跟变态似的没事找事”。但是我要说的是，没有严谨或者说过于严苛的工作习惯，出来的东西到底自己有多少把握？安全性如何？易用性如何？性能如何？

举个简单的例子，我在日企做手机测试提交的bug分为五个等级。每一个bug的提交都要自己的初步分析，精简操作步骤，横向纵向对比（不同的硬件操作确认排除硬件问题，不同版本的软件操作确认出现问题的那个版本，不同类型但是有一定关联的相关程序或者格式文件的操作缩小范围），log文件的提交等一系列的过程。当然还需要找到依据，做任何事情都要有根据，发行bug也不例外。没有根据的只限于手机死机，重启这样的问题。然后才能够进行提交。提交之后的处理也是慎之又慎。会有专人来进行这些问题的后续retest把关，并且把处理的结果及时与测试部负责人进行沟通，便于测试人员进行及时的retest。程序员和测试员只有确认的义务，没有处置的权利。一旦发行错了bug或者本来没有修复的给确认成了TestOK，会受到很严厉的处罚。

在项目进行结尾的时候，对所有的问题和所有的项目都要进行一一排查。

严谨而有序的工作流程造就了高质量的产品。付出和获得始终是成正比的。

国内项目倒是鲜少遇见这样的事，导致我一开始去做的时候还不习惯。总有人抱怨我，你发一个bug整那么多对比信息干嘛？倒是让我哑口无言。很多事情没有根据。我们在测试的时候，开发人员在随时的进行更改，经常发生我们测试过的东西一转眼就被改掉了不得不重新测试的问题。

做国内项目很苦。因为很多的开发人员很随意。他们对自己很看重，觉得自己是太阳，测试人员是为他们服务的。他们为了赶进度，只能随时改，而你测试的，也就只能随着他们的步骤去做。测试人员提交了bug，他们给你面子才会很快的处理，处理完了基本上也不会告诉你。我当时的感觉就是，恍然大悟。我终于明白了国内的产品为什么PK不过外国的。或许说这话有人会有意见。所以我声明，我希望我只是看到了最灰暗的一角。其他的都是好的：）

同事说，国内项目很多都是这样的。然后我发现，浸泡在这样环境中的他们，做事情也是很随意。或许这就是近墨者黑的另一种体现。

一个很好的思维，一个很好的习惯造就一套很好的流程，一个很好的可控的严谨的流程可以缔造一个高质量产品的生命。

为了我们的国货，国内的软件开发流程还有很长的路要走。中国的劳动力成本在上升，中国的劳动力已经不是优势。而我们是不是也该好好想想，如何和国外那些同行们在质量上PK，取得一席之地？

我只想说，做开发的，全局来考虑一下，做测试的，把好自己的门，有责任心的去面对你测试出来的东西，不要管别人怎么看。因为，你是最后一道关。。

***不过说实话，做对日项目，严苛的管理制度是一种很沉重的折磨，虽然受益良多，但是不想再去做。hoho。。

编外：

不是说买国货就是爱国，不买国货就是不爱国，虽然总有人在争论这个东西。也不是说爱国非要说国货的好，关起门来，我们要想的是如何从心理真正的认同，甚至是世界认同我们的质量。这需要所有人的努力。诚然，世界都充满了“Made in China”，也并不能说明，中国的质量如何好，因为中国是世界工厂，廉价的劳动力吸引了太多人来中国投资办厂。如今，中国的劳动力优势渐渐失去了，中国的未来靠什么取胜？质量！只有质量提高了，才能真正的做到全世界使用中国的东西是因为质量好而不仅仅是便宜。

这个问题

我记得我在感悟软件测试这个帖子里面说过，只是不明确

诚然，我也不是大家，说的话也没有权威性，只是说明一下自己的感悟。

测试需要懂编程知识。但是不是所有的测试都会用到编程知识。

要是你想要做自动化测试，编脚本是基本的能力，所以你要会脚本语言以及协议
一个不懂得脚本语言的人，是不够资格去做自动化测试的。因为你除了简简单单的录制脚本之外，需要设置的东西很多。需要你用脚本语言进行控制。

msn测试中国里经常有人问，为什么他录制的lr跑不了？很多原因在于脚本控制有问题。比如，对于web里面随机弹出的某个窗口的控制。你在录制的时候可能没有，但是回放的时候出现了。那你的脚本自然就跑不下去了。解决这样的问题，怎么能缺了脚本语言的基本功？

还有，为什么我录制了，看不到脚本？很多的时候是因为协议选择错误。要了解其中的原因，自然也是需要了解一些协议方面的知识了。

要是你要做白盒测试，一定要知道白盒测试的几种基本方法。因为方法决定了你要会的东西。

静态白盒测试，需要做的任务是检查设计和代码，主要就是静态的检查，审查和走查；动态白盒测试主要是让程序运行起来，然后进行相关代码的检查。主要手段有数据覆盖，代码覆盖（条件覆盖，分支覆盖）等。

理解了这些，就不难知道，要想做白盒测试，懂得测试的程序，至少保证能看懂和能改，能够进行代码注入是应该具备的能力。自然，根据不同的项目要求，需要具备的编程能力就不同。

黑盒测试，很多人说，这是最没有前途的测试种类。我不这样认为。黑盒测试，对于测试员的要求，业务的理解，客户需求的理解绝对要高于一切。也就是说，用户需要什么，你的关注点就在那里。比如说，手机测试，你就要保证等到用户拿到这个手机的时候，使用的时候，是满意的。不能有任何的问题，至少是让用户无法容忍的问题出现。奔着这个目标，自然就知道自己该关注的问题是什么。至于你测试的这个程序是用什么语言编写的，有哪些实现的方法，并不重要。重要是这个东西，能用，好用，易用，安全，可靠，然后用户满意。

此外，还有对于测试全局的把握，不能做好手头的那一块就完事了。这是和开发人员最大的区别。你必须从更高的角度来看待问题。了解更多，发现更多。比如说你测试A模块，但是发现了B模块的问题，发不发这个bug在其次，你一定要让负责B模块的人知道哪里出现了什么问题。你不是在抢他们的生意，也绝对不可以视而不见。因为你的这一个“忽略不计”，可能会给这个产品带来隐患，导致这个厂家以后会蒙受巨大的打击。你也必须对得起在你身后，付了钱的，等着使用的用户们。因为你在为他们将要使用的产品负责。

至于测试工具，数据库，我觉得脑袋聪明一点，学习能力好一点的，这些东西，会一种顺手的就可以了。剩下的，都是工具嘛，用到了在学其实才是学习最快的方式。

最后还是自己写过的那些话：

软件测试从立项到出厂，也是一条长长的流水线，我们都是关注其中某一段的人。虽然说软件测试全程关注，但是也少有人少有项目组从头到尾都在参与。一般会有不同的人不同的项目组参与不同的阶段。在某一段，某一个领域，你成为资深的专家已经够让你学习一辈子。这样理解的角度来看，其实如何一种有这种全程质量思想，认为软件质量高于一切的人，都可以胜任这份工作，区别就是你发展的空间有多大而已。

如果我说，我就想做一辈子黑盒测试，那么我一点编程也不会，但是懂很多的业务，比如银行的软件，通信的软件，sap等，我熟悉所有的流程和业务体系。也可以啊。你会编程，会数据库。但是你不懂业务，我们一起去应征，我敢说，除非他们需要白盒测试，否则他们会要我不要你。。因为很简单，客户是上帝，我诠释的很好。而你未必可以。

不过，要是以上你都会，就可以成为“武林高手”了。不过，目前的江湖缺少秘籍，不知道要你学多久

很可恨，不会有游泳。据说在游泳的时候，尽量把自己放松，沉下去的人才能浮上来。

大学的时候有这样一首歌谣，大一的时候，知道你不知道，大二的不知道你不知道，大三的时候不知道你知道，大四的时候，知道你知道

其实也算是人生的一段缩略箴言，可以让人在某些时刻想起它感慨良多。。

很喜欢的一部由苏友朋，贾静雯等主演的《倚天屠龙记》，俊男靓女的组合让我耳目一新。很多东西也是让我感触颇深。记得关于有一场张三丰临阵教授太极剑法给张无忌的。。。张无忌刚开始全都记住了，后来忘记了一小半，又过一会儿忘记了一大半，最后全都忘记了。。然后赢得了胜利。片中的张无忌是个武学奇才，又有机遇，总有令人想象不到的机遇。

但是那一段我印象很深，也总在以后的工作中时时想起。虽然不知道为什么会在全部忘记的情况下才能挥洒自如，也不知道何时自己在软件测试这个领域也能有如此的造诣。

时间回首4年前，自己刚刚踏入软件测试这一行，真的是什么都不知道。在实际的工作中，点点滴滴从头学起，也才发现，很多东西原来如此妙不可言。

很多人都说，测试这个东西没有技术含量。说这话的人更多的是有些开发经验的，但是却做不成开发，“不得不转入“测试队伍里来的人。那个时候也曾迷茫过，特别是朝朝暮暮面对着同样的流程，同样的步骤，总是在不停的重复的同样的工作的时候。。

后来，越来越多的人在随声附和那个声音，测试没有前途，测试没有技术含量，尤其是黑盒测试，到大街上随便抓一人来，一个礼拜的学习，准可以干测试。。

我开始思索，我是不是真地走错了路？是不是真得如此没有前景。

感谢这个时代，让我可以在网络上找到很多我需要的资料。然后我发现，不是没有技术含量，而是因为我不懂，我们的不懂，我们陷入了误区，盲区，才会永远在那个巴掌大的地方挣扎着。。

于是我开始学习，利用工作之余的时间进行学习，然后我发现，很多的思维都在悄悄改变，很多的方法与之前不同，我开始知道，自己原来是如此的适合这个行业。

随后的日子里，我的收获开始让更多的人受益，我开始对管理和测试的流程提出自己的见解而且颇有成效，我开始根据实际的工作情况，对项目组进行培训，让我们大家共同成长。

然后我发现了，我知道得越多，不知道得越多。。

我开始烦躁，开始不知道该怎么办？

那一天，偶尔看到了一篇人生哲理，以学习游泳作为比喻，沉下去，浮上来。恍然大悟。

是的，只有沉下去，踏踏实实，才能浮上来，越走越宽。。

于是，我在众人的不解与迷茫中辞掉了之前的testing leader的工作，不舍得挥别了我亲手带出来的子弟兵，来到了另外一个公司，从一个测试员开始，踏踏实实，重新做起。

这里有着丰富的资源，我可以学到更多

这里有着众多的机会，我可以体验更多

这里有着众多活的资源，我可以成长更多

我相信，我的努力不会白费

我的明天，一定会更加明朗。。

记得高中的时候，曾经有位高高帅帅的学长，在我们学习最为艰苦的时候，前来探班

现在已经不记得他的名字和长相，只记得他说了一句话。

“如果你的世界只有碗口那么大，你不懂也只有碗口那么多；如果你的世界变成了圆盘那么大，你不懂的也会变多。。”当时有些似懂非懂，此刻倒是明白了很多。

软件测试，04年，带着一份新奇，一份感悟，一份兴趣，我加入了这个行业，至此已经将近四载岁月。

最初的一无所知，懵懵懂懂；后来的略有所知，似懂非懂。。我对这个行业的理解也在这跌跌撞撞中不断的加深。

软件测试，据说某些测试培训学校说，不需要会编程，不需要外语很强，不需要。。只要3-6个月强化培训，便可成为软件测试“精英”，月薪8000.。

我不知道为什么会有人会相信。但是我明白，诱惑的力量。我更加知道，这是不可能的。

有句话说的很不错，适用于任何行业：你的价值与你的可替代率成反比。比比皆是的软件测试培训学校，出来的人有几个人说，我无可替代？那么，既然别人随时都可以替代你，我为什么要给你那么多的钱？很容易理解的道理，确实让很多人迷茫。。

软件测试，测试的理论，测试的经验，测试的思想，测试的工具以及必要的计算机知识都是测试员不可或缺的东西。

理论，如今是百花齐放，不亚于春秋战国的百家思想，只是国内的权威的比较少。空理论的比较多。很多“著作”翻翻看看，都差不多。这也算一大悲哀。

经验，需要实践来积累，理论和实践相结合，这是我们学到的知识。但是理论应用于多变的实践，往往会有不一样的效果，如何去甄别？如何去看待？这需要时间，需要积累。不能被同一块石头绊倒。

思想，某种程度来说，这属于天赋的一部分，就如有些人善于理，有些人喜好文，没有理由。软件测试也是一样，没有测试的思想，对它只有功利的想象，没有真心的投入和理解。。。。。。无论如何，你都捅不破那层窗户纸。测试实践中，遇到的瓶颈会特别多，然后，你会放弃，也意识到，自己对这个行业，其实真的没有兴趣。到头来，不过是浪费了时间和精力，还有宝贵的青春。

工具，某种程度上讲，工具是个死东西，熟能生巧。区别于项目的需求不同，策略不同。所以我觉得某种程度上讲，招聘信息上写，精通XX工具，其实有些可笑的。因为昨天不代表今天，今天不代表明天。潜力和人品才是最重要的考核标准。

计算机知识，很多人问我，测试需要会编程吗？很多网站上也会纷飞着这个帖子，加上很多人“一千人眼中一千个哈姆雷特的解释”。我也只能说，看你自己的选择。

软件测试从立项到出厂，也是一条长长的流水线，我们都是关注其中某一段的人。虽然说软件测试全程关注，但是也少有人少有项目组从头到尾都在参与。一般会有不同的人不同的项目组参与不同的阶段。在某一段，某一个领域，你成为资深的专家已经够让你学习一辈子。这样理解的角度来看，其实如何一种有这种全程质量思想，认为软件质量高于一切的人，都可以胜任这份工作，区别就是你发展的空间有多大而已。

无论怎样，软件测试的目前还是这样一个状态，很多良莠不齐的人在参与，很多的风险在暴露；很多人在讲它如何重要，很多人在软件风险的切实体会中知道真的要去培养专业的队伍。。

我还在学习，在实践，也在观察。希望看到有一天，软件测试也有明媚的春光。

这个行业，这个行业中的我们，都是艺术以及创造艺术的人。

做国内测试项目的若干感悟

谈到这个话题，就会想起若干年前，柏杨先生的一篇让国人为之痛骂的《丑陋的中国人》

我觉得，一个国家一个民族的个性真的可以体现在各个方面。

比如：我做的测试项目，从对日测试到欧美测试，就感触颇深。

日本人的等级森严，阶级尊卑的传统体现在他的工作中就是非常严格而规范的流程。项目中的每一个参与者都有其确定的身份，也就有其确定的权限和责任。

符合项目制定的规范，严格按照既定的逻辑和标准去做事，成为日本项目的一大特点。

在工作中，你发现了一个问题，你会明确的知道应该向谁汇报而不能越级。一旦出现问题，会进行责任的层层追究，考勤，考核都有严格的流程。。

而相对而言，非常崇尚自由和个性化的欧美项目，就会有着相对宽松的氛围。在工作中，你发现了一个问题，你 可以有更加宽泛的范围去选择汇报和询问的对象。只要能保质保量的完成工作的内容，没有人在乎你是提前来了半个小时还是早走了15分钟。。

国内项目，我觉得就是比较尴尬的一个现象。一方面，归根于中国几千年来的封建等级制度，有一种层层汇报的制度。但是每个组成部分却不能像日本项目一样界限分明，于是当问题出现的时候，不知道找谁。似乎是对日本规范的一种抵制，国内大多项目不喜欢制定严格的规范和流程。表面是充斥着各种的自由和个性，但是却缺乏后期很好的维护。以至于在破烂不堪的表面，残存着若干或大或小的问题。

做国内项目，只有2个词的感受：上火~

我也衷心的希望，这只是个案。。

对日项目的时候：

项目开始2个月前，我们会有项目启动会议。会得到项目的TTSJ等需求文档，客户与开发之间协商的可开发，不可开发的最终成果文档。我们会了解这个项目的总体流程。

项目开始一个半月之前，我们会得到项目的系统详细设计和概要设计文档。大家利用这些文档进行测试系统的熟悉，测试点的划分，测试case的抽取，设计，测试case的评审。并且开发方会定期将系统设计变更的文档予以公布，供我们进行备案，以及对测试点的修改（一般来说，成型的测试case很少进行改动，而是会进行notes添加，在后续测试中才会针对notes和设计文档对测试case进行修订）

项目开使之后，会维持部分模块的稳定性，比如当前测试A模块的时候，A是绝对不允许开发人员在测试中进行修改，而是在既定的测试完成之后，开发才可以进行修改，并且提出修改文档，回馈测试方，声明修改了哪些部分，供测试人员进行retest

测试人员发行bug之后，相关的开发人员会进行修改，修改的记录和测试员后续测试的记录会追加在bug表上。在测试员进行retest确认关闭后，开发的负责人要给予该bug关闭的原因。项目结束后，这些原因也会成为软件质量的评价因素之一。

软件项目完成后，项目组需要书写评价报告，包括软件的质量总体评价，负责测试的模块中出现问题的几率，原因分析等。

国内项目：

至少我参与过的国内项目，测试员会在实际测试开始2周内参加测试，这期间包括了对系统的熟悉，测试式样的设计。而且一般的测试项目，因为项目实际开发与需求的脱节性，加上开发人员时间的紧迫性以及没有形成良好的文档约束性。测试人员基本在项目开始的时候是拿不到设计文档，包括详细设计和概要设计文档。能得到的只是很久之前的或者无效或者部分有效的一份比较模糊的需求文档。。

我不太清楚，这里面的原因到底在哪里，但是我清楚的知道，这样的需求文档，能到导致的问题是：测试人员需要跟开发以及需求人员去核实一些重要信息。这在很大程度上取决于测试人员的主观能动性和测试的经验，而且由于对测试系统的熟悉程度不够，也很难做到没有遗漏。。。直接导致的后果就是测试的效果下降，测试出来的产品留有或多或少对后期有影响的bug。

bug这一块，国内项目往往开发和测试出现重迭，也就是说，我刚刚测试过的模块，可能转瞬就被改过了，导致测试量的浪费。不得不进行无规则的重复的测试。

而且国内的开发人员很少会有这样一个习惯，对bug进行针对性的定位和反馈。在他们看来，自己的开发模块都忙不过来，能抽出时间来进行修改已经是给了测试人员天大的面子，哪里有时间进行反馈，有什么必要？殊不知，这样的想法在很大程度上造成了测试管理的滞后，导致系统整体的质量受到影响。

说到这里，都似乎忘记了自己写这篇文字的初衷。

虽然，我们大家都说，全面质量管理，都说，测试和开发都是软件生命周期中不可或缺的重要一环，但是到目前为止，至少在国内，很多的企业，重视的依然是开发，对于测试，特别是独立的第三方测试，依然是不重要的补充。依然是开发后期才能参与进来的。

没有人不重视食物的质量，因为攸关人命，一种不合格的罐头可能会导致成百上千人的中毒以及死亡。所以食品企业的质管员责任重大。他们监督着流水线上的每一个环节。没有人不重视建筑的质量，尽管在当今，由于利益的驱动，这份责任在被淡化，进而出现大桥坍塌，住宅小区裂缝等质量问题，关乎民生。。而在软件这个领域，虽然人们说了很多年，软件质量，软件质量，但是对于软件测试的重视程度依然还在低水平徘徊。开发的没有高超的技能，做不了开发了，就以为一定能做好测试，一个个培训机构，几个月就要“培养出”月薪8000的“测试精英”。。我倒是想问，测试，软件测试，到底在你们这些人眼中，意味着什么？没有测试的灵魂，没有测试的信念，只为了追风，只为了薪水而进入测试行业的人，到底会给我们的测试行业，带来什么？？

******************************************************************************

这篇文章本来写在csdn，感谢51test的兄弟把它转载到了这里，并且成为精华。

于是努力找回密码，再次开始我的51test生涯：）