北京急招手机软件测试工程师

li40482964

sdfsdafas

snipereye

敢情有人拿这个帖子做压力测试啊。职位很一般，是多少年经验的水平？

galano

已发送。mynameisiloveu@gmail.com

li40482964

10101

li40482964

1        迷惑
去年六月我从泰国开局回来后，自认为开局工作还算让人满意，当时老大曾富贵问了我一个问题：“开局成功是你的本分。你认为开局没出问题就是做好了吗？”让我深感惭愧。从此我一直带着一个疑问投入工作：“做到这些到底是我的本分，还是真正做好了？”在寻求答案的过程中，遇到的问题越来越多，我心里的迷惑也越来越多。迷者，米生足，奇也；惑者，心多或（可能），惘也。真佩服老祖宗的造字智慧，字形里就包含着睿智的概括。
经历了几个月痛苦的挣扎，心里的迷惑终于有一小部分逐渐找到答案，在这个过程中，曾富贵、章文峰、赵钢、朱卓莉和周从洋给我很多指导和帮助。他们是我的主管和老师，在平时我也不好意思开口说谢谢，今天借这篇小文章，表达谢意。季度末很多同学都开始总结，分享经验。我也趁这个机会将自己的迷惑和收获分享出来，希望为同样处在迷惑中（如果有的话）的同学提供借鉴参考。

li40482964

2        最难测试的系统是自己
测试人员都知道，开发人员之所以不能像我们一样发现问题，主要原因在于代码是他们自己编写的，他们跳不出自己设定的框框。同样的，我们的思维习惯、工作习惯是自己“开发”的，因此，找出自己工作存在的问题，尤为困难。
下面每节都将用问题作为标题。建议有兴趣“修炼”的同学记下你的第一反应，和再次思考后的想法，前后对比，你会发现其乐无穷。^_^
正所谓事无定法，我不愿、也没有能力对下面的问题给出所谓的“答案”，因为那相当于将我个人的思维限制强加于各位同学，这有违本文的本意：突破工作中常见的思维限制。因此，对下面列举的各个问题，我将用将其进一步分解为多个小问题的方式，来从侧面“回答”。而事实上，真正的答案在各位同学心里。:-)

li40482964

3        测试＝发现问题？
测试＝发现问题？
关于这个问题，相信我们所有测试同仁都会Say No，而且觉得好笑。我也有同感。
去年看Batman Begins这部电影的时候，有一句台词让我印象深刻：It’s not what you say defines you, it’s what you behave defines you. 从这句台词可以看到西方人思维方式的一个缩影。McDonald的创始人Ray Kroc说：“运作有序的经营很大程度基于良好的定义。每个人必须知道自己是什么，要做什么。”
现在我们回到刚才的问题——测试＝发现问题？并进一步问：测试不等于发现问题，那么，测试是什么？要做哪些事情？相信很多同学不会觉得好笑了。这是一个严肃的问题，而且，是一个很难回答的问题。如上节所述，本人才疏学浅，无力给出任何正面答案，只能将问题进一步分解。
    在之后的部分，我们将讨论如下问题，请注意，这些是测试工作的一部分，而不是全部：
        我们真的做到主动了吗？
        好产品是测出来的吗？
        我们组织的会议有效率吗？
        人人都知道的二八原则？
        如何做好一次培训？
        写用例时我们心里有客户吗？
        我们做好测试过程记录了吗？
        测疲了＝测完了？
        广度优先 VS 深度优先？

li40482964

4        我们真的做到主动了吗？
记得入职的第一天，XXX部长就指导过我们：在公司做事，第一条是主动。此后的日子，每每听到，也每每给新员工转述这个字眼。然而，我们真的做到主动了吗？请看下面这张图：

li40482964

5        好产品是测出来的吗？
在公司一直有一个争论：好产品是测出来的吗？开发的兄弟多偏向于好产品是做出来的，测试的兄弟则偏向于好产品是测出来的。
您认为呢？
个人以为，这个争论的重点不在于结论，而在于问题基于这样一个淳朴而美好的共同愿望：无论是开发还是测试，都希望做出好产品。
来看看IPD-CMM流程对好产品的定义：
“质量符合客户需求的产品。”
有一次我在汇报WAN组网测试进度时章文峰提到：“不要管什么功能点、性能点，总之用户怎么用，我们就怎么测，凡是不符合用户需求或者使用习惯的，都算不通过。”我才发现，我的思维受测试点分类的限制很大：配置、功能、性能、异常、组合、对接等。在做组网测试的时候，虽然路由规划是“模拟”现网需求，流量是“模拟”现网流量，但在实际操作的时候，往往不自觉的按上面六类划分，而没有真正做到“从用户需求角度看问题”。
请问您在测试中总是从用户角度看问题吗？如果您不确定，请回答以下问题：
        我了解所测模块在网上的典型组网吗？
        我了解所测模块在网上运行良好所需要具备的性能指标吗？用户经常对哪些指标进行组合应用？
        我考虑到用户由于不熟悉命令而出现的乱序配置吗？
        我所测试的模块是否有些用户可能需要但是没做的命令行？
        我所测试的模块配置方便、符合逻辑吗？提示信息清晰明了吗？
        我所测模块在异常后是否能够自动恢复？
        我所测试的模块在出问题且无法恢复后是否给用户提供一个便捷的方式收集信息并足够研发分析定位？而不是繁琐的调试手段？
        我所测试的模块对应的文档是否清晰、富有条理？是否写清楚了需规避事项？
…… ……
打住！有同学会问了，为什么老兄总是说测试自己的问题啊，产品的质量开发的同学也有责任啊。我们经常可以听到开发的兄弟说这样的话：
        用户不会这么用的
        用户又不懂技术
        这个太难改了，不改了吧
        没必要做这个命令吧？
…… ……
这是谁的责任？
这是我们测试的责任！为什么？请看下图：

Jeo

是啊，我个人也认为，很多人对测试的理解有偏差。
测试，不是为了找出问题，还是让产品的问题减到最低。
测试和开发的关系很重要，在这个过程中，测试就像一个爱唠叨的太太，不停的诉说丈夫的缺点。。
但这个太太一定要让丈夫知道，她是爱他的。。。