Make Silverlight 3, WCF and Azure work together

Recently, I'm working on a project which is composed of a Silverlight 3 Application and a WCF service, hosted by Windows Azure. I encountered a bunch of issues and it's very hard to find the solution. The process is painful, but eventually I solved all of them. Maybe there will be some new issues coming up, but it's good so far. I want to list the major issues and related solutions in case others may look for them as well.

1. At the very beginning, I saw this.

Warning 1 The element cannot contain white space. Content model is empty. D:\Azure\SilverlightApplication1\SilverlightApplication1\ServiceReferences.ClientConfig 7 99 SilverlightApplication1

Warning 2 The element 'httpTransport' cannot contain child element 'extendedProtectionPolicy' because the parent element's content model is empty. D:\Azure\SilverlightApplication1\SilverlightApplication1\ServiceReferences.ClientConfig 8 26 SilverlightApplication1

http://localhost:63165/Service1.svc" binding="customBinding"

bindingConfiguration="CustomBinding_Service1" contract="ServiceReference1.Service1"

name="CustomBinding_Service1" />

I got the solution from Jimmy Lewis.

Gary, I think it's due to the section:

Can you try removing the element and making the element self-closing? I haven't figured out what causes this to be generated incorrectly yet.

2. Generating proxies

Out of the box, using Add Service Reference or svcutil to generate a proxy to a service hosted either in the development fabric or the cloud fabric will fail. The following workaround can be used:

1. Host the service either in the Visual Studio ASP.NET Development Server or your local IIS instance
2. Use that instance to genereate a proxy
3. Modify the endpoint address of the generated proxy to point to the correct location (either in the development fabric or the cloud fabric)
   
   

3. Address filter mismatch

At runtime, WCF services may return the following error: The message with To 'http://127.0.0.1:81/Service.svc' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree. The error can be corrected by applying the following attribute to the service class.

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

4. Specifying a relative service address

Normally when adding a service reference, Silverlight will generate a .clientConfig file containing the address of the service. This config file gets pacakged as part of the Azure service and cannot be edited as the service moves from the development fabric, to staging in the cloud fabric, to production in the cloud fabric. This poses a problem since the hardcoded service address will change between these three locations. To use a relative address, you can use the following workaround:

1. Delete the .clientConfig file
2. Recreate the appropriate binding in code, for example: Binding customBinding = new CustomBinding(new BinaryMessageEncodingBindingElement(), new HttpTransportBindingElement());
3. Use this method to specify a relative service address: EndpointAddress address = new EndpointAddress(new Uri(App.Current.Host.Source + "/../../Service.svc/binary"));
4. Pass the binding and address to the proxy constructor: ServiceClient proxy = new ServiceClient(customBinding, address);

Enjoy.

Facebook邯郸学步失败

今天打开Facebook却吃惊地发现页面变了，找不到Live Stream了，这也说明了Facebook模仿Twitter失败了。我早就说过Facebook的新页面只是完成了Twitter的一小部分功能，有其形而没有其神，引起无数用户的抱怨。我还说过，如果Mark真的认为颠覆性公司听取客户意见是愚蠢的话，那么Facebook也快完蛋了。

从这次事件来看，Facebook的创新能力出现了严重的真空。F8平台开放以后引起世界的瞩目，后来页面改版差强人意，Online聊天工具也没什么人使用，到现在纯粹模仿Twitter，我实在是担心Facebook的前途问题了。我一直关心的两个问题，一个是Online Storage，另外一个是站内搜索，Facebook怎么就不做呢？要是做了这两块，Facebook还得牛一大截。如果一年之内不实现其中之一，我可能也考虑退出了。没有新意的公司实在是不能让我长期关注。

召集志愿测试员

听到很多测试人员抱怨没有机会去进行自动化测试，白盒测试这些相对手工，黑盒测试技术要求比较高的工作。我一直提倡应该自己去创造机会，但是我发现很少有人能够做到。因此，我准备启动一个开源的项目TwitterBEIS，给大家创造一些这样的机会，希望有能力和想法的测试人员参加。

Qualifications:

• Good English writing skills: we will be developing a software using some kinds of new techniques. We need to communicate with foreign communities. So English is very important. Also all documents, code comments and communication will be in English.
• Coding skills: you have to be able to write code since you will work on automation, code review, debugging etc.
• Quick learner: some techniques are new, you must ramp up quickly.
• Willing to learn advanced testing technologies.

Advantages:

• Development will deploy the second model I mentioned in my blog. That means you will do lots of code review and debugging.
• Other than that, you will be working on unit test, white box, automation so on and so forth. They all help to build your professional resume.
• Possibly change to a dev role once your coding skills are good enough.
• Use modern Web2.0 technology to work together as a startup.
• Directed by me in real project rather than articles.

Disadvantages:

• No payment: everything is volunteered and completely depends on fun, interests and learning.
• It will take you bunch of spare time.

For all details, visit http://code.google.com/p/twitterbeis/.

微软与Google的战争已败

昨天听到不少微软的内部人士说喜欢Live search，不喜欢Google, 我也赞同。这两年Live Search还是有了明显的进步，和Google的差距也越来越小，虽说市场份额没啥变化，可是搜索质量跟Google相差并不大，而界面感觉更胜一筹。一般来说，英文搜索Live Search基本还是够用了。很多次我发现Live Search搜不到，去了Google也照样搜不到。我一直对微软还是抱很大期望的，有的时候也批评一下Google，而有些人就问我是否真正使用过Google。前一段时间认真研究了一下Google的各项服务，结果发现微软基本不可能打败Google了。

首先，微软对Google的战争应该是全方位的，search并不是全部，只能是重点。由于Google是靠Search起家，而直到现在的盈利也基本是靠Search，给人一种印象就是微软只要打败Search就打败Google了。我一直是这样认为，相信到现在微软的领导层也是这样认为，因此在Search上投入大量的资金与期望。可是我在使用了Google的各项服务之后，发现微软是全方位的落后，只是把Search作为突破口击败Google在现实上是很难行的通的。目前微软的IM虽然占有绝对的优势，但是由于IM是客户端，对于Search的份额几乎起不到任何的影响，并且IM本身也不赚钱，看看Skype都成了Ebay的鸡肋了，所以这个优势对微软和Google的战争没太大影响力。另一方面，Hotmail对比Gmail目前还具有一定的优势，可是Gmail发展迅速，Hotmail客户流失严重，很可能在短期就被超过。我就想不明白，微软Search肯花那么多钱，干嘛非得在Hotmail上放那么大一个烦人的广告呢？这能挣几个钱呢？本来用户跑的就厉害，现在开放了POP3，使得用户可以把Hotmail导入到Gmail中去，跑得会更厉害。反正我用了Gmail以后发觉确实比Hotmail好用多了。Skydrive虽说Google还没有推出Gdrive，因此是微软的一个特有产品，可是发展也太慢了，跟桌面的整合没有，跟其他服务的整合没有，并且还跟很多类似的产品共存，搞得用户晕头转向不知道该用哪个。难道非得Gdrive推出来以后微软才知道进步？其他的产品就完全是Google占有绝对优势了。Blog上blogger比Live Space要强多了，连微软自己的minimsft就在blogger上。Photo上，picasaweb比Live Photos也强多了，很多msn的用户都是通过它来共享照片，视频上Youtube绝对统治地位，微软的soapbox还有人记得吗？Google reader微软没有，iGoogle比live个性化主页也强很多吧？后者已经很久没有更新过了。Google的AdSense, Webmaster tools, Analytics 都非常好用，而微软则刚刚关闭了自己的Analytics。Google的blog search微软没有，Google Docs微软也只是有个浏览的功能，Google groups, Google calendar， 微软也是最近才开发好，已经太晚了。还不只这些，Google还有很多小服务微软没有，而且Google还在不断推出或购买各种创新的服务，比如最近announce的Google Voice，又引起来一片关注。想想看，大家一个个用着Gmail, Google Docs，Picasweb，Youtube，Blogger，Google reader等等，你微软Live search做的再好，我为什么要去用你呢？这也解释了我一直想不明白的问题，为什么Live Search越做越好可是份额却没有提高，即使白给用户钱。这就好比大家用着Windows上一些列的应用程序，Linux没法跟微软竞争一样，同样的道理，大家都在用着Google的服务，Live Search怎么跟Google竞争呢？

其次，微软的Live战略处在了非常迷惘的状态。 最新的Messenger我就不想提来，总之一片反对之声，我也早习惯了逆来顺受了。Live的Wave3到底做了点什么东西呢？搞了半天无非就是模仿Facebook，可是连Facebook自己都要模仿Twitter。这下可好，Twitter牵着Facebook的鼻子走，而Facebook牵着微软的鼻子走。微软搞得都不是二手货了，而是三手货了。这次之后，我对微软的Live创新能力彻底地失望了，我相信微软的Live根本不可能满足我个人的需求。再说Live Search，经过了这两年的折腾也有点不知道该往哪里走了，搞来搞去就搞出个Kumo出来。我个人对这个改名非常的反感，虽然这也没有最后定。首先，本来就是换汤不换药，除了名字和界面改动之外，我没有觉得有什么太大不同。虽然加了一点新的东西，这些我现在也不想讨论，毕竟没有公开。其次，Kumo是什么？说是日文的蜘蛛和网的意思。我就不明白你搞个日文名干嘛？太让我莫名其妙。总之，我觉得Kumo没什么戏。

再次，Live Search非常地保守。本来保守也不一定是坏事，但是要想击败Google,不具备大胆创新的精神怎么成呢？下面就是Live Search对最新的实时搜索技术的态度：

类似于search.twitter.com“实时搜索”（Real Time Search）服务可能会开始流行起来，但是有一个产品不会部署该服务：微软即将发布的搜索引擎Kumo。微软搜索引擎部门主管Stefan Weitz称，Kumo团队正在考虑进行小部分调整，而类似于实时搜索功能不会出现在Kumo中，它还需要一个进化的过程。

Stefan还称：“微软不想因为作太大的改变而吓跑用户，而搜索引擎的界面在12年里也没有太大改变。”那么Kumo还带来什么新的特性呢？微软计划使搜索结果更加人性化，简化搜索过程，专注于用户的“关键任务”比如旅行，地方化信息等。

综上所述，我认为微软与Google的战争已败。（我个人很喜欢韩信，韩信在鸿门宴上就料定项羽没戏，我这次也大胆断言一下）

聊聊#Twitter

最近Twitter特别火，整天出新闻，先是拒绝Facebook的五亿美金的收购，又是推出所谓的实时搜索，到这个星期Facebook推出新的主页与其竞争。这样的宣传力度让我不得不要去亲自尝试一下了。其实我很早以前就已经注册了，只是我跟很多人一样，实在是发现不了它有什么用。这次用了快一个星期了，我发现它确实是牛。为什么牛呢？没别的就是一个实时性，这是目前任何其他网站/服务所不能提供的。也就是说你在Twitter上得到的是“现在正在发生什么？”。照我来看，目前Google的搜索技术根本实现不了这个功能。Google的crawler一定需要一些时间进行index，不可能实时查询，这也是为什么有人把Twitter称作Google killer的原因。而Facebook虽然加入了Live stream的功能，也只是实现了Twitter的一小部分功能而已，远远达不到Twitter的强大，所有也有人把Twitter称作Facebook killer。Anyway，我今天就想随便谈谈自己的使用感受。

Twitter的几个特点：

• 实时性：实时性体现在两点，第一是实时地知道自己的朋友或者自己感兴趣的Twitter帐号的动态。第二是可以实时查询自己感兴趣的话题。Facebook的Live steam顶多是实现了第一点，而我一直想不明白的就是Facebook为什么不开发或者跟Live Search合作进行站内的搜索的开发。目前Facebook的搜索功能做得实在是糟糕，更不要说什么实时搜索了。没有实时搜索的Facebook怎么可能打败Twitter呢？
• 开放性：Twitter出奇的开放，因此围绕Twitter产生了大量的第三方的应用或服务。我一直对Facebook担心的一点就是Facebook的封闭性。虽然Facebook开放了F8平台，但是之上的应用必须要在Facebook上运行，而Facebook的实名和过多个人隐私的特点也使得Facebook不可能像Twitter那样地开放。
• 方便性：Twitter跟很多设备或服务都结合地很好。比如你可以通过手机短信来发布tweets，这也是为什么很多事件都是Twitter最先报道的原因。而你在Twitter上的tweets可以自动地发布到Facebook，MySpace，Blogger，微软的Live Profile上。也就是说你在各种网络上的朋友可以同步得到你在Twitter上的更新。
• 灵活和小巧：很多人喜欢Twitter的原因就是因为它小巧，简单，灵活。而Facebook则变得越来越复杂，死板。这也使得Twitter比Facebook显得更酷。
• 单向关系：虽然Facebook的Pages也是单向关系，但是个人账户则是双向关系。这样的话你只能follow你的好友或者Pages的更新，而在Twitter上你可以follow任何人，只要你想。而你甚至也可以跟你不follow或者没有follow你的人交谈。比如你在Facebook上想跟比尔盖茨交流，一定要通过他的许可才行，而在Twitter上则没有任何限制。

如果你现在对Twitter产生了兴趣想尝试一下的话，你一定会有几个问题问自己：

1. 我为什么要用Twitter？我想对于follow别人的人来说，基本上就是想得到一些自己感兴趣的信息。而使用Twitter search的人也是想了解当前正在发生的事情，而其他途径都还来不及得到或者信息不全面的时候。而对于发布信息的人就比较复杂了，比如有些公司就是发布公司的最新情况，有些名人也发布自己的情况，并且和自己的fans交互。有些可以利用Twitter查询自己产品的用户反馈情况。比如最近的Facebook的主页更新，我发现大概90%都不喜欢，而Google最新发布的Voice服务则是一片叫好之声。对于个人用户来说用处也是很多，比如可以随便发发牢骚，发表一下自己的观点，看法，问问题，或者就是无聊地告诉大家自己正在做什么，等等。
2. 我应该follow谁？首先，如果你有好友已经在上边的话，你应该follow他们。其次，你可以follow一些你感兴趣的账户。比如，我follow一个本地的电台可以得到本地最新的一些新闻；follow Google可以得到Google最新的更新；我还follow了Facebook创始人的帐号，感觉Facebook不爽的时候就跟他发发牢骚，等等。
3. 谁会follow我？同样也首先是你的朋友，其次如果你follow某些账户，这些账户会自动follow你。如果想让不认识的人follow你还不是一件很容易的事情，除非你是名人。你应该提供有用的信息给大家，别人才可能follow你。反正我用了这几天基本上没有人主动follow我。因此，我觉得个人用户来说follow别人还是更主要的功能，当然search应该是更重要的功能。

一些有用的使用技巧

• # hashtag: 你可以在tweets里的关键词前加上#，这样有利于你的tweets被搜索。我发现我有些没有#的tweets是搜索不到的，而加了#之后全部可以搜索到。
• @username: 可以发tweets给某个用户
• d username：可以发私信给某个用户
• translate: 有些人的tweets不是英文，可以应用translate把他们变成英文。虽然不知道翻译效果如何，总比不认识的语言要强多了。

一些目前的问题

• 中文支持太差，关键词不支持中文，#不支持中文，发布的中文tweets很难被搜索到。
• 只能follow账户而不能follow topic。发现一个非官方命令track可以实现，可是只能用于IM和手机。现在Twitter也不支持IM了，而我也没跟手机绑定，所以对我来说基本没用。
• 还有一些需要加强的功能，比如可以直接播放视频，像Facebook的Links的功能一样。对Tweets可以进行分类等等，就不多说了。

总而言之，Twitter是专注于这个领域的，很难被别人打败。就像微软是软件霸主，Internet打不过Yahoo。而Yahoo是门户霸主，Search打不过Google。而Google在社交则打不过Facebook一样，Facebook也不太可能打败Twitter。因此，我觉得Twitter还是很有大发展的，不知道微软是否会考虑买下。

考虑把你自己变得unique

经常有人跟我提起“我们公司的测试就是这个样子”，“中国的测试就是这个样子”等等。我昨天收到一个recruiter的来信，深有一些感触。我想问“为什么你不想把你自己变得unique呢？”为什么目前的测试环境如此你就随波逐流呢？

记得上大学和刚刚工作不久自己心中总是有一句话“不一样的人要过不一样的生活”。是的，我从小不喜欢随大流，别人都喜欢的东西我往往不喜欢，而我自己喜欢的东西其他人也常常不喜欢。简单来说，我算比较独特一些吧。这也在很大程度上使我自己的工作态度和大家有所区别。

我觉得一个人发展到一定程度是一定要有自己特点的，总是跟在被人后边是很难会有很大发展的。现在我的有些东西，我都觉得是只可意会而不可言传的。所以我希望大家能够开始思考这个问题。

附录recruiter的部分来信，请大家注意particular, unique, hard to find这几个词。我建议每个人都应该朝这几个方向发展。

I realize you work at XXX, so a contract opportunity wouldn't be too enticing for you! Rather, I'd like to tap into your network. I'm looking for a particular skill set and background like yours, which is unique and hard to find. :)

Work smartly or 偷懒

在我发表了Code Review+Debugging的文章之后，看到了一个很典型的comment，我想简单回应一下。

很赞同你的看法，但是目前绝大多数的test都是第一种模式（包括Microsoft的大部分team），因为tester要负责automation，test case。

如果我没有理解错的话，意思是tester要负责automation, test cases, 因此没有时间去搞code review和debugging。不巧的是，我的工作也主要在test cases和automation上，甚至很多manual tests, 但是我还是有时间去搞code review和debugging。那是为什么？

其实我也面对类似的问题。在我要往下一阶段发展的情况下，领导对我的要求是要proactively地工作，要看到别人看不到的，别人没想到的，要做一些创造性地工作，要做一些对整个team有帮助的工作。而具体做什么？怎么做？则完全要靠自己。我就问了类似的问题，我说工作太忙，没那么多时间去想这些问题。领导的回答是要work smartly。是的，我后来分析自己可能一直也算是work smartly, 只是自己形容自己的行为是“偷懒”。虽然我对于自己下一阶段的发展也还处于摸索阶段，但是我想我还是可以回答这个comment, 因为我已经通过work smartly or 偷懒经过了这个阶段。

首先我想说一下公司的工作和个人的发展很多情况下是互相矛盾的。很多人总是想依赖公司去发展，我觉得这是个误区，真正地，起决定性作用的还是要靠自己。比如comments里的这个问题：tester要搞test cases, automation, 怎么去搞code review和debugging呢？那么我的答案就是偷懒，有原则地偷懒。

对于测试来说，我们的目的是用户使用产品的过程中不会遇到问题，而实现这个目的的手段就是找bug，而具体怎么找bug确是非常灵活的，这就是测试工作最大的魅力之一。你从事测试的工作千万不要拘泥于什么测试理论，测试方法等等，一定要有自己的主张和特点。比如有些人的工作是黑盒测试，他就认定了自己不能用白盒测试方法。有些人是手工测试，就认定了不能采用自动化。非得要跳槽找一个白盒，或者自动化的工作才能够开始从事。这是不对的，对于你所负责的模块，只要能找到bug，你应该可以采取任何的测试方法，而即使是专门的白盒测试人员也不能拒绝使用黑盒测试方法，专门从事自动化测试的人员也不能排斥使用手工测试的方法。因为，每种方法自然有它的特点，优势和擅长的地方。只有最适合的测试方法，并不存在最好的测试方法。

由于测试工作是如此地灵活，因此我就可以进行偷懒了，当然我是有bottom line的，那就是一定要保证自己负责的模块不出大问题，就算出大问题一定要有一个合理的理由。而我偷懒也不是真正的偷懒，我是要用省出的时间去进行自我提升以及从事更高技术含量的工作。比如，我在test cases和automation上省出来的时间可以进行code review和debugging, 以及pentest等等。这样的话就发生了很多有趣的现象。有的人追求100% automation, 而我只实现60-70%; 有的人test tool 要写的perfect, 连help都写进去，而我只写最核心的代码；有的人test code 写的很fancy，好像水平很高，而我则认为他是把简单东西搞复杂了，而我更喜欢把复杂的东西简单化。总而言之，在他们尽心尽力做好本职工作的时候，我却把一些精力放在了其他地方。这样长期下来，大家的差别可能就会显现出来。

以上只是个人理解，也许这不是领导所指的work smartly，只是给大家点建议，以及回应这个comment。最后说一下，code review+debugging刚开始是需要花些额外的时间，因为毕竟有learning curve在里边，但是以后的话，这种模式以我自己的经验来看并不比传统的模式更花时间，甚至可能更省时间。这个我可以以后再谈。

越来越rely on Code review and Debugging （一）

有的时候觉得有些不好意思，因为作为一个刚刚具有中级title的我来说，却给大家讲高级测试的内容。自己也想了想，其实自己目前的工作还是处于中级阶段，并没有什么太多高级的内容，包括Security testing也不算什么高级。

我现在觉得测试的初级阶段测试specific的内容占了很大的比重，中级阶段则是dev的内容占了很大的比重，而高级阶段是应该超越test和dev的阶段，从而test和dev合一而更强调的是impact, influnce和leadership。在我的初级阶段，我跟很多人争论自动化测试的重要性等等，而在我的中级阶段我自然地就不去争论这个话题了，从而争论dev的重要性。到了目前的阶段，我也不会再跟其他人争论什么automation, coding这些内容了，因为他们太基本了，已经不是我所应该关注的内容了。对于初级测试人员的提问，我觉得最好去我的那本书中寻找答案，我觉得我已经把我的观点完全表达清楚了。而以后我的文章还是会集中在中级测试的内容，因为我离高级测试还是有不小的差距，希望过两年能弥补上。既然我说过中级测试阶段dev的内容占了很大的比重，因此我的文章某种程度来说对开发人员也有一定的意义。

在我的安全测试文章系列，我本来想在第三篇文章介绍一下fuzzing test，这个在安全测试最常用的测试方法。可是在我还没有时间开始写这篇文章的时候我就对他失去了兴趣，因为我发现了更efficient的方法就是Code review+Debugging。举个例子，有一个安全漏洞我通过code review大概在两个小时的时候发现的，而我通过fuzzing是在60多个小时发现的。Fuzzing的要求是运行48小时，而这个bug是在48小时以外发现的，也就是说如果我只运行48小时是发现不了这个bug的。无独有偶，在一个presentation上，在大家都讨论dumb和smart fuzzing的时候，我们team唯一的senior测试发表的fuzzing with brain的言论，就是利用code review和debugging来进行安全测试的。

下面我想先谈谈Code review和Debugging在测试中的重要性。

Code Review: 我们知道无论你手工测试用例设计的多好，无论你的自动化测试多么优秀，你的code coverage都不可能达到100%。我们CC的要求是70%，有些binary是很难达到这个要求的，而有些binary则可能接近90%，根据我的个人经验。也就是说，无论你如何测试，你至少都会有10%以上的code不能被cover，不能被test到。而Code Review则是一个很好的补充，从而可以使得产品得到更全面的测试，尤其是安全测试方面。记得《Writing Secure Code》的作者去一个公司做咨询schedule了一个小时的code review的meeting。在这个meeting之前，他们的dev manager就跟他说，这一个小时是浪费时间，因为他们雇佣了最聪明的程序员，他们自己进行了几轮的code review，没有发现一个bug。而作者说既然已经schedule好了就先开15分钟的会，看看情况再决定是否继续开下去。结果是在这15分钟里，作者通过code review抓出了10几个security的bug，最后这个会议延长了几个小时，而这个公司的员工觉得学到了很多的东西。可见对于一个有经验的测试人员来说，通过code review测试是多么的efficient。我自己最近也发现，我code review总会很容易地发现一些bug，而这些bug是在手工测试和自动化测试很难或者不可能发现的。

Debugging：我们设想一下目前最典型的test和dev的工作模式。

1. Tester: find a bug
2. Tester: try to repro
3. Tester: find repro steps
4. Tester: file a bug
5. Dev: try to repro
6. Dev: communicate with tester if non-repro
7. Dev: debug，investigate and find root cause
8. Dev: fix bug

我们有一定经验的测试人员可能都深有体会，在step2和3中，有时候非常麻烦。有些bug很难repro，有些bug甚至就发生过一次，你根本没有办法完成3。从而即使file了bug，dev也没法进行step7的工作。而由于test和dev的工作环境，机器设置等等的不同，dev往往不能repro要跟test交涉，也就是step6往往要浪费大家很多的时间和精力，甚至搞得test和dev关系出现紧张和裂痕。那么我们如何建立一个更加efficient的工作模式呢？这就要靠tester的debugging能力了。目前我的工作模式如下：

1. Tester: find a bug
2. Tester: debug, investigate and find root cause
3. Test: file a bug
4. Dev: fix bug

由于tester负责debug和investigate的工作，从而repro steps就不是那么重要了，因为dev面对的bug里就会列出root cause。甚至tester可以给出fix suggestions。而由于tester帮助dev进行了大量的琐碎工作，dev也会非常appreciate it的，从而加强了双方的合作与信任。通常dev的fix也会邀请tester来做code review的。

有的人会说，我们公司的工作模式就是前一种，你提到的后一种根本不用，也不现实。而我的回答是，你们整个公司不用不带表你不可以用，也没有人可以阻止你使用，自己的技术发展，自己的职业规划最终还是要靠自己。