下面谈谈最近工作外遇到的几个现象：

　　做51testing新人上路版主也一段时间了，以下总结一些大家常问的问题及现象并附上自己的看法，希望给大家一点帮助，如有异议，欢迎交流：

　　1、问：黑盒测试没有技术含量，该怎么办？如何提高测试技术？

　　答：问这个问题的大多是新人，我以前也问过，如果大家留意可能会发现前辈的留言多数说黑盒测试是最有技术含量的技能，为什么？因为黑盒测试是其它测试方法及技能应用的基础，如现在很热的自动化测试，探索式测试等等都是建立在黑盒测试的基础之上的，如你连基本的测试用例设计都不会、业务流程都不熟悉，会使用测试工具但不知道该模拟哪个场景该测试哪个点又有什么用？当你还在因为这个问题而纠结时，问问自己我真的很了解测试模块的各个业务流程吗？我能独立完成一个模块或者项目的测试任务吗？我熟练掌握了需求分析、需求提取、测试分析、测试用例设计、测试计划编写、测试方案编写、测试执行策略、测试结果分析、测试报告整理等等每一个点吗（如果工作中没有这些阶段是不是可以考虑增加呢）？我跟开发的关系处理的好吗？缺陷单的编写还需要优化吗？等等，如果没有，我建议你先了解了上面这些，再去考虑学习有技术含量的东西。

　　2、问：以前做XX，现在想转测试行业，行不行？

　　答：问这个问题的工龄一般都比我的大，都是我的前辈，可能不能给出满意的回答，但是还是要说说我的看法，只说一点：你对测试真有兴趣吗？已经入测试行业的都知道做测试有些时候枯燥、工作内容重复。最近对兴趣的理解尤其强烈：最近在测试一个项目，该项目已经是第9轮测试了，持续半年之久，每轮测试持续1周以上，由于项目的特殊性又不能使用工具做回归测试，每轮都要进行主要功能测试验证性测试有时是详细测试，最近发现同组的同事都处在麻木状态了，就是bug验证一下，干其它事情去了，主要功能都懒得跑了，更不用说学习新技术应用于测试中增加场景、覆盖率等等。如果你不知道有没有兴趣，我可以提供个方法，仅供参考：找一份登录模块的测试用例（越详细越好），执行10遍，看看执行过程中你是什么心态？

　　3、由于经常写总结，也可能由于是51testing版主，常常被别人加QQ问问题（可能有些同仁认为我很牛叉，其实我很菜），大多数上来就问我做哪方面测试的，是不是做自动化的，是不是做性能的等等之类，当我说：主要以系统测试为主，有时做做稳定性测试和性能测试，对QTP和LR不熟，有时会用一些简单的工具辅助测试时，貌似大多都很失望，感觉我是做系统测试的就没有交流下去的必要了（遇到这样的同仁，有时我也感觉没有交流下去的必要了），我最近也在思考原因，是大家对黑盒的误解，还是太浮躁，抑或是随大流。自动化热我去学，探索式测试热我也去学，手机端测试兴起我也去学。就像我在2012年度总结中说的，我也浮躁过，测试技术很多，各种技术的诱惑很大，但是我们是不是应该考虑下哪些适合我们，哪些不适合呢？（这也是自己近期一直思考的）

　　4、YY培训兴起，各个测试社区或者网站都在搞各个主题的YY培训，几乎每天都有，看到好多同仁只要有就报名。引用mike老师的一句话就是：靠YY想来提升自己的技能几乎不可能。说下我的观点：YY培训对于我们这些收入低微的人来说真的不错：不收费。但是YY培训只是前辈老师给我们指的一个方向或者是对某个主题的大致介绍，如我想了解下手机方面的测试，我可能回去听Monkey老师的一次YY培训，大致了解下手机测试特点以及与我们一般的桌面软件测试有什么不同，具体有哪些不同，还需要我们自己去找资料，自己在实践中对比。说了这么多就想阐述一点：选择适合自己的YY培训主题，不要太迷恋YY培训，所有的技能提升归结到最后还是靠我们自己去获取自己去研究自己去实践（也是提醒自己）。

　　前阶段在进行系统测试和稳定性测试时发现了一些问题，也思考了一下，做个简单的总结吧：

　　1、测试用例设计

　　这个季度进行的测试用例评审和测试用例整理，增加了自己用例设计能力和发散思维能力。也总结出了自己的一套流程和方法：拿到一个待测模块时，先熟悉相关文档，按照小功能模块逐级细分，然后在针对单个小功能或单个属性进行用例设计（各种测试用例设计方法的应用：域分析法，等价类划分等等）；然后在针对几个关联属性，设计组合场景（可使用正交，状态图，流程路径覆盖等测试用例设计方法，注意一点的是设计用例时使用正交，大家可能有点头疼，几种组合的正交会致使测试用例较多，其实正交设计方法的优点也恰恰是其缺点：等概率，没有考虑一些特殊的场景和用户常使用的场景，我们在使用正交时可以把场景考虑进去，然后筛选测试用例）；最后站在各个模块的角度用业务流的思路补充场景，主要考虑各模块的交互（用的比较多的是经验法，最近对自己报的bug分析发现，模块间的交互恰恰是自己缺失的，没有很好的站在更高的角度看待一个产品，也是以后自己需要加强）。在以上过程中可以使用思维导图理清自己的思路，不断扩展自己的思维，增加场景覆盖。

　　2、测试用例评审

　　用例评审主要是通过其他同事指出测试用例的不足以及增加用例覆盖率，在这个过程中收获最大的是：当同事指出自己测试用例不足时，可以思考下为什么自己设计用例时没有考虑到，是自己测试技能不足，实践不足，还是自己的测试思维有盲点，有针对性的去补充完善自己的测试知识体系及提高思维的缜密度。

　　3、测试用例执行及测试用例维护的难点

　　这个问题也是在近期系统测试时发现的（尤为强烈）：该轮用的测试用例基本上都是更新过的，用例颗粒度较细，用例数庞大（几万条吧）；如果测试时间得不到保证的话，按照测试用例走，测试进度肯定会受到影响（特别是该轮也进行稳定性测试），只能采用其它用例执行策略。由于测试用例设计的颗粒度较细，导致测试模块有较小变动时，维护起来较困难，如一个简单的添加界面变动，导致有大量的测试用例要更新，这在测试时间不足的情况下更显的困难，这个以后应该注意颗粒度的问题。