近期工作内外的一点思考

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

做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. 测试用例执行及测试用例维护的难点

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

4. 稳定性测试的关注点

做稳定性测试也有好多次了，以前测试很少关注数据库方面的问题，大家都是自己测试自己的或者考虑相关联的模块。被测系统长时间运行，数据库数据（如报警信息等）会不断增加，导致数据库操作运行缓慢甚至安装CMS的服务器出现卡死现象，这个以前是没有关注的，我们只关注报警有没有上传处理有没有写入数据库，而没有关注整个平台的其它功能。最近在思考测试中是不是应该关注这方面的问题，稳定性测试不应该只关注测试的一个点，既然是模拟现场使用场景的长时间运行是不是应该关注长时间运行后整个平台的运行情况（各方面），这个也是自己以后要关注的。

5. 资源耗尽问题

最近测试时遇到系统资源耗尽问题，没有安装被测软件之前PC机空跑几周没有问题，安装被测系统之后跑几天就会出现资源耗尽问题，理论上讲是被测系统导致资源耗尽的，但是有以前几个诡异的情况：
1>.各进程资源消耗都正常，包括被测软件进程，总CPU,内存，句柄，非页面缓冲区等等都正常，找不到是哪个进程消耗了系统资源
2>.通过任务管理器强制杀掉被测软件进程，还是出现资源耗尽情况，资源没有释放（如果是被测软件引起的，杀掉进程后应该会释放系统资源）
3>.已通过各种软件杀毒，可以排除是病毒引起的问题
现在开发和我们测试这边找不出具体问题出现在哪里，开发说是电脑问题，我们又拿不出有力证据（该问题在该版本其它Build中也出现过，共出现四次，每次电脑都不一样，操作系统也不一样），该问题也在一直找答案，初步判断是与金山毒霸有些东西不兼容引起的，待确定。

6. 不同的测试人员提交同一个问题，处理结果不一样

这个现象也是自己最近在考虑的，同一个问题为什么不同的人上报得到的处理结果不一样，总结出了以下几个原因：

1> 是不是bug

2> 开发人员的工作负荷。

3> 开发人员自身和心情决定的。

4> 项目所处的阶段（如临近发布和首轮测试）

5> 测试领导的支持

6> 测试人员的沟通及交流

7> 测试人员杂开发人员心中的印象

8> 问题反馈给领导，让领导沟通

以上也是跟同事交流和自己工作时得出的，针对这个问题，更多的是作为测试人员，我们怎么去行驶好自己的责任，哪些原因是自己导致的，这也是自己思考的，属于自己的工作职责，有问题一定要反馈沟通交流，不断反思改进整个测试过程，不应该得过且过，对于小问题不理不看的态度，时刻对问题保持新鲜感，这样才能不断的培养自己的测试感觉和经验的积累，更重要的是提高产品质量和用户体验。

以上只是自己的一点看法，由于我也是个菜鸟，对有些问题可能理解的还不够深刻，欢迎交流探讨。

写于2013-01-09     没翅膀的飞鱼