随着软件的公司的不断发展和壮大, 公司内容软件代码的管理也就显的很重要了.在我所遇到的公司中,很少有公司真正去关心和做这一件事情.

   代码特别是核心的代码,对一个公司相关的重要,它是一个核心的竞争力.如果这个核心失去了,我想结果是可想而知的.

    我现在在这家公司, 其实代码的安全性问题基本上都没有人关心和关注这个问题.不是大家没有想过.我也造成这方面的原因可能有如下:

   1.公司不规范:

    老板只重视最终项目是否可以成功.对于代码的安全性和代码的管理没有一个清楚的认识,没有自己的版本控制流程,没有自己的配置管理员,代码随便的放置,版本控制意识十分的差.

   2.领导不重视:

     有可能是领导没有想到也有可能是领导没有意识到问题的严重性

   3.代码技术含量低:

     这个问题也有一种情况就是这个公司的代码没有技术含量,本公司可以写,别的公司也可以写的.

其实不管理是那一种情况,我感觉从公司的领导层次来看这个问题,都应该是一个很机密,很严肃的事情,也是一个很重要的事情.

   但是很少有公司领导对代码的安全提出一个合理的,科学的管理.本人提出自己的看法,希望可以帮助大家来管理代码的安全性

  1.项目分工明细:

   每一个人接触的功能模块不一样,那么他们看到的代码和编写的代码只是自己相关的那一部分;其它都不允许查看到编写 ;

  2.部署问题:

     要指定特别的人来部署问题,不是每一个人都可以部署.对操作系统的权限分配也要根据不同人的权限来分配

  3.版本控制

      只有配置管理员,可以更新和查看版本,项目经理如果需要版本的话,必须通过配置管理员来控制.

  4.签订协议:

     对公司内部的代码安全性都要制定自己的保密协议,要求每一个员工都签一分.如果真的出现重大的损失,有一定的法律保护.

   一家之言... 还希望大家都说说自己的办法...将代码的安全性提高.

  

  其实从事测试就一定会关心一个问题,如果保证产品的质量.一般的测试人员,可能只会保证其中一部分的质量,因为他只负责这一个功能模块.

  但是做为一个公司测试领导,你还有只关心这一个部分吗? 但是如何保证产品的质量呢? 100家公司,可能有100种自己的管理方法,都不一样的.

   我在公司也有自己的管理方法:今天写出来与大家分享:总结一句话: 一个杆子,4根线.

1.一个杆子:指的是基本的流程

   测试计划-->测试方案--->-->功能点核对-->测试用例的编写-->执行测试用例-->写测试报告

2.4根线

 第一根:

     评审工作: 这个工作在我们公司是没有的. 根本原因是老板的不重视,开发的藐视测试的重要性.所以很难行的通.这是很可怕的事情.如果功能设置本身就存在问题,后面的开发及测试都是会浪费时间.质量就可想而知了.

     版本控制: 这一部分就是开发出来的版本要做一次管理,保证测试的版本与开发的版本是一致的. 如果不一致,测试可能就没有意义和价值,甚至会造成很大的误会.质量保证就可想而知了.

     需求变更控制: 这一部分在我们公司就是糟糕透了.由于我们和客户沟通的很少的.一般只有项目经理才会与客户交流.所以我们全部的需求来源都是项目经理的.需求的确认也是经理来进行的. 这样的就会造成如果经理不告诉我们,开发和测试都会做许多没有意义和价值的事情.质量的保证从何谈起.

     BUG管理: 一部分也我进入公司第三天就开始做的事情.这一个平台必要要有.如果没有,开发和测试就很难实现及时的交流和沟通.及时和开发说了,如果开发没有及时修改,明天可能就会忘记的.

  总结: 我已经实现了版本的控制和BUG管理两个方面,对于评审和需求变更控制做起来比较困难的.

   下半年,打算把评审工作,做起来. 对于需求的变更控制,建议有项目经理写记录,通过发邮件的方式来通知大家,将需求文档及时更新.

   本人的感觉:前期的需求调研相当的重要,这一部分一般都是我们项目经理做的事情.但是这样就会有许多的问题,项目经理如果水平差,做的需求文档如果有许多问题,或是分析的不到位,理解偏差等原因,我们的项目就会很被动的.

   现在这个项目就是处于这样一个情况,感觉公司的用人还是很不到位的.什么人做什么事情,还是没有做到位.建议有专业的人员来从事需求分析和调研.这样最后做开发和测试人员来评审这样的需求...

   唉......

   无语.... 项目做成这样,真是可悲啊....

其实这个问题? 有一个技术总监问过我这个问题.
 我后来想了想,感觉从以下几个方面可以保证测试用例的高效性..
  1.细心的分析需求. 吃透需求.这是最难做到的,也是必须要做到的,没有需求的支持,我的用例就显的那么苍白   无力,就没有什么意义与价值了.
  2.自己的用例让别人执行: 这样有几个好处:
   A.可以增强我们的责任感.对自己,对别人负责.
   B.可以保证用例的,执行的高效性,在执行中,发现用例还没有覆盖到的需求部分.
  3.多人陪审需求
    这个方法,不是太好的..太费时间了,再说了,也没有那么多的精力搞这个用例的评审.所以,这个评审,我感觉    还不如讲下,自己设计用例的思想与方法,从那几个方面来思考问题的.
其实上面 每一点做到都很难的,我们遇到一个项目,每一天都有可能要更新一个版本,但是每一次修改一个问题,就会有出现两个新的BUG, 你说让人头痛不? 我们能按用例来执行吗? 如果按用例来跑,我们的进度可以保证吗? 所以说,理论是一方面的,实际的工作也是一个方面的.