#81 楼 @dongdong 我也就是懂个 10 来个，其他的就是知道也用不好。不过这东西用处很大的。我熟悉的这 10 来个我全用的上

#80 楼 @dongdong 我也觉得他不错的。。。我文中也写了可惜了么。 只是我和老大都希望是既懂开发，也懂测试的人。可能我们都受 Google 软件测试之道的毒害太深了吧。

#18 楼 @sigma 别期望太大~~其实没多少内容。这些其实只是没人整理一下。其实明白了形式。你研究研究就都实现了。

#16 楼 @sigma 是这样的，找不到就不验证。找到了就验证

#34 楼 @yuweixx 我就不明白了，为什么一个失败重跑的问题，他能纠结成这样

#34 楼 @yuweixx 不是一个维度的问题，不讨论了

#77 楼 @elduh 额。为啥我觉得设计模式才是编程基础。。。。应用开源框架才是进阶。。。。写出维护性更好的框架难道不重要么？ 我见过我以前同事写过的框架，我也接手过别人的框架。想往里加点功能，修改个功能真难。

#11 楼 @sigma 不是啊。写代码显示的调用是最常用的。不过我们当时没几个会写代码的。所以我就搞成这样给他们用了

#68 楼 @success 额。可是他们便宜啊。我要是老大也这么想的。只是写写脚本的话也用不着那么厉害的

#69 楼 @sordar 额没准是真的呢哈哈

#30 楼 @quqing 指望开发 debug 测试脚本。想多了

#30 楼 @quqing 这种就是出了问题不管三七二十一直接扔给开发的工作思路。

#64 楼 @success 这个可能是我没说清楚。我们老大的意思是要么招特别厉害的。要么就招比较菜的。两种职位。

#65 楼 @eraser 这个。。。。一开始我就说了。我们老大的要求。要么特厉害的。要么特菜的

#59 楼 @skytraveler 虚心接受你的建议和批评。其实他的简历里写了设计过框架，开发功底足我才问设计模式的。不过我的观点确实偏激了点

#60 楼 @wonew1228 虚心接受你的批评。

#55 楼 @simple 发帖之前我就想过实名发这种帖子会不会成为众矢之的。最后还是选择实名了。匿名不解气吧可能。我以前是被前辈坑过。接手一个同事的代码的时候发现我根本接不了。各种 if else，for 循环的都挤在一个方法里。最深的 4，5 层循环嵌套。一个方法白行以上代码。没注释没文档。虽然功能都实现了但我实在接手不了这样的代码。随便动哪块我都不确定会不会出现大 bug。所以从那之后我面试的时候就开始注重考察设计模式了。我就是觉得不应该留给后辈一个烂摊子

#38 楼 @sandman 我写帖子的时候带着点情绪。观点表达的偏激了。勿怪

#45 楼 @nancy123 我写帖子的时候带着情绪。有点偏激。勿怪

#50 楼 @simple 我带情绪写的帖子。有点偏激。勿怪

#22 楼 @quqing 我理解在持续集成环境中要求保存数据当作证据给开发人员的。都是不管三七二十一只要脚本失败了就扔给开发的工作模式

#25 楼 @quqing 我的观点是不需要保留数据的。因为这世界上有种东西叫 debug。首先如果测试脚本失败了。作为测试人员肯定要去分析一下原因。为什么失败了，环境错误？网络问题？case 之间互相影响了？还是脚本本身的 bug？起码要 debug 一下看看到底怎么回事对吧？如果这件事无法达成共识那么也不用聊了。如果最后排出这些原因。怀疑是开发的问题，那么分析是哪部分代码出的问题。UI 自动化失败的话那就看一下对应的接口测试报告。确认是前端的 bug 还是 server 的 bug。去代码库看看相应路径，是不是有代码变化。什么变化引起的 bug。自己分析下原因后发现是自己搞不定的才提交给开发。bug 管理工具中提出完整的重现步骤。这是一个测试开发起码要做的。这个可以达成共识对吧。
那么再说开发追踪 bug 的问题。如果你们是异步合作模式，开发去 bug 管理工具上获得详细的重现步骤。如果根据步骤不能重现问题，有可能是测试没写好。也有可能是双方环境不一致。如果开发一定要在测试环境中看一下测试结果。根据之前测试人员 debug 的结果。会没有数据保留么？debug 的时候在数据清除之前就打断很难么？就算测试人员忘了保留数据。我们都是自动化的，跑一边脚本几秒钟的事很难么。所以我们需要在框架里特意的保存数据么？

#22 楼 @quqing 测试失败了。不尝试找原因直接扔给开发的我也是醉了

#29 楼 @monkey 我其实有点能理解他们不懂测试。。。他们起家那些年。。确实没啥测试技术。。偏见已然形成 l。现在他们的级别已经使得他们不想去关注这些问题了。挺可怕的。外行领导内行

#31 楼 @jamesparagon 好的