测试随感

1 系统测试人员应该是杂家。

 

   大概梳理下测试NG-RNC所涉及的知识：

  

   硬件: MIPS  BootRom  ROM/RAM区别 格式CF卡并写入系统 做串口线~

 

   操作系统：  Linux shell ，不知道类Unix的环境搭建辅助设备能否算在里面~

 

   网络：TCP/IP：配置IP/ROUTE  配置Broadcom的交换机  VLAN  Trace

            3G      ：信令消息

 

   各种工具使用，包括FTP Telnet Excel Wireshark ~~

 

   最后还要猜测 没有说明书参考的内部通信，到底哪里出了问题~

 

   SQL和指针C一直没碰到~

 

2 测试人员的素质要求

   面试中经常会被问道：你觉得测试人员最重要的品质是什么？ 这个没标准答案的问题，我倾向于“好奇心和宽广的知识面”。

   后来，我反思我的工作过程和工作产出，到底，哪些行为是最影响效率的。

   我发现，好奇心和知识面，只适用于新东西，类似于我们的mcrnc，想玩起来要补一大堆的课，万事开头难，什么都没有什么都要自己琢磨的时候，要完成测试，前面要搞懂一堆根本不存在任何测试指导书上的东西，这个时候，一个positive的人和一个negative的人，效率差距可能要以十倍记。我很喜欢这些有些挑战，能树大旗的工作，这些时间相对自由，能获得成就感的工作。

   但是，这不是测试的全部，或者说，这不是测试的主要部分。更多的时候，软件是增量开发的，环境是现成的，方法是继承的，这个时候，到底什么最影响效率？

   在常规的情况下，仔细、耐心以及责任心都比好奇心要来的实用的多，负责任的完成重复的劳动，把发现的问题提交上去，然后跟踪解决状况，从问题单数量上一般都会很好看。尤其是，当问题的根源没找到，修改一次，反而多一种bug现象的时候，问题单的数量增长更加可观。没错的，测试人员付出了劳动，工作应该得到承认，特别是，当测试的工作成绩需要定量分析的时候。

   分离的开发和测试部门，常常听到的抱怨是：开发人员认为测试人员的问题定位太浅，使他们很难猜出问题在哪里；测试人员认为开发人员的测试包发的太频繁，只是在应付。开发人员有自己的考核机制，问题处理的速度，以及解决方案的效果。缺乏沟通的开发测试往往会成为冤家对头，测试人员重复的提出bug，而开发人员用无用的测试包来搪塞，block issue像个幽灵不时的窜出，商用版本交付时间不停delay。烂软件，没错，太烂了，所有的研发都很忙，付出了大量的努力，只是，但是，软件还是太烂了。

    其实，缺乏的是，沟通，一种极少被认同为工作量的工作，却是解决软件忙而烂的囧境的办法。从我的经验来看，对于bug，只需要讨论的圈子扩大一些，多一些分析，哪怕是猜测，多激活一下邮件，并且，更快速的反馈测试包的结果，问题的解决速度会大不同。当测试人员不停留在发现问题，提出问题和被动的跟踪解决进度的时候，当测试人员把自己当成解决问题的driver，愿意对缺陷修正负责任的时候，问题的解决速度会大大的不同。开发人员不想拆东墙补西墙，说不清哪天又被人扯掉内裤。做起来并不会像说的那么容易，测试人员要花更多的心思，还可能减少bug的数量。只有测试人员，把解决问题和发现问题放在差不多的地位上，才可能这么做。测试人员的责任是什么？发现问题，更早的发现问题，还是，解决问题？换一个问法，作为一个对交付件负责的team player，你的责任是什么？ 提供满足需求的可靠的交付件。

    那么，一个主动沟通、愿意为问题的解决负责任的测试人员，他有什么好处呢？他会慢慢的积累下一笔财富，开发人员会记得他的名字，他的问题会被优先解决，他会得到尊重。同理，一个愿意沟通，分享定位思路，响应快速的开发人员，也会更容易得到测试人员的信任，得到更多的定位信息。

    那么对一个测试人员，最重要的素质是什么？善于同开发人员沟通，愿意共同解决问题。

 

3 一个大型系统，应该测什么。

 

    从测试的对象分： 平台测试 功能测试 性能测试 （稳定性测试）

    从测试的阶段分： 单元测试 集成测试  系统测试 解决方案测试

    从测试的手段分： 自动化测试  手动测试