dc project 测试总结

上一篇 / 下一篇  2011-08-25 11:04:15

由03月22日至08月21日,跟dc project整整五个月了,由最初的需求模型到最终的产品实现,经历着一个windows project的诞生全过程,个中的点点滴滴都能让我回味浓远。

这篇post主要回忆下dc project的整个测试过程,及详细说说我在流程中每个stage的得与失,顺便带些我对测试的自己的思考,算是自己的经验总结吧。

产品需求确认:
  很幸运能参加该project一系列的需求讨论会,参加这样的会议能让我更深入并且实时贴切地理解用户业务需求。我们都知道在软件生命周期中发现问题得越早,给整个项目带来的风险及损失就越少,在需求确认阶段就让测试人员介入,测试人员能为用户提出一些有建设性的功能上或业务处理上的意见,能深挖掘一些用户需求中考虑不到的:或是更好的需求,或是需求中的欠缺、风险。因此,让测试人员尽早地介入项目是非常值得的,这也是我们项目组做得非常好的一点。测试人员能尽早地介入一个项目,是一个项目的良好开端。
  
  由于个人项目经验、理论知识的缺乏,在这一系列的需求讨论会中,我并没能像一个优秀测试工程师那样能给用户提出更多更好的意见与建议。这是我比较欠缺的方面,在以后的测试中,我会不断地有意识地培养自己在需求缺陷的预分析这方面的能力。我自己把这个阶段叫需求前测试。

测试需求分析:
  由于以往的测试工作中,个人没有涉及到测试需求分析这方面的工作,主要是根据自己以往的测试经验、同事的帮助及网上相关资料的学习才不完美地完成了这个阶段。在文字描述的简略精确方面做的不够好,以及在做测试需求分析评审的时候,语言概括能力非常缺,在日常生活中需要有意识地却培养自己这方面的能力。
  
  在做测试需求分析的时候,测试人员应该对业务需求、业务流程有个非常深入的理解,特别是那些逻辑性非常强非常复杂的流程,一定要亲自动手至少画一遍业务需求的流程图,对流程进行一个二叉树式的解剖(),将各个节点可能引发的子节点一一罗列,也有必要对流程图的逻辑合理及效率性进行仔细分析。再就是根据以往的测试经验对各个功能进行测试分析,最好能与测试同事一起讨论、分析,互相交换见解,一定会有所收获的。

测试用例设计:
  这也是我初次进行测试用例的设计,主要是学习别人设计测试用例的方法(例如等价类、边界值、因果图等),以及根据自己以往的测试经验。在这个阶段让我深有体会的就是文青山同学介绍的树型分析方法。在进入功能测试阶段,会发现有些用例设计与实际业务需求会有所的偏差,且用例远远不够用,用例的测试重点也有所偏差,未能满足产品需求。

功能测试 | 集成测试 | 系统测试 | 回归测试 | 验证(发布)测试:
  这几个阶段,在跑用例的同时,还要有意识地去探索用例中未能覆盖到的测试点,并及时补充到用例中。在发现缺陷时,要运用以往的经验去分析去猜测问题的根源,做出大胆的设想、去判断程序员对该功能的处理方式,并能提出解决该问题的可靠的处理方式的建议,并详细描述到bug单中。在这个阶段,在遇到与程序员有争议的问题时,应该主动让项目经理,测试主管,用户参与进来一起讨论,这方面的处理能力有待提升。
  
  可以有意识地与其他测试人员针对某些bug进行讨论,同时,有必要抽出时间多看看其他测试人员提交的bug单,在这个过程中可以发现自己的不足,及学习到别人思考问题的思路,
  
  有机会的话,要向开发要到自己测试部分的源代码,在工作之余去仔细阅读代码,一方面可以了解自己测试部分功能的实现思路,让自己对该部分功能的测试更有针对性,或许可以挖掘到一些黑盒测试所不那么容易发现的隐藏的缺陷,另一方面可以学习别人好的编码思路。遗憾的是,我未能要到源码。

客户端性能测试阶段:
  这部分工作是另外一个同事在做。为了弥补自己在这块的不足,在工作之余,我学习了用QTP进行简单的自动化测试,初级地学习了White、NUnit、Selenium等UI自动化测试的优秀的开源框架,用White+NUnit搭建框架来编写UI自动化测试脚本。在反复无味的黑盒测试工作中,阅读源码能给你带来快感,学习别人优秀的开源框架能让工作更加有趣,也能让你在测试这个行业走得更深更久

服务端性能测试阶段:
  这方面知识也是我锁缺乏的,在做性能测试期间,反复录制脚本,反复阅读书籍,不断解决问题,分析问题,特别是在学习lr函数的时候,也是能让人收获良多的。
  
找找自己的bug:
  为了一个项目的质量,花了五个月时间测试,从对其进行需求分析,测试用例设计,到功能测试,再到性能测试。为了一个人的质量,需要花多少时间?去确立你要成为怎样的人,对这样的人需要具备的素质进行分析,设计一个个衡量指标,开始有意识地培养自己所缺乏的素质,坚持下去。
  
  静观我个人。性格方面,太过固执,有时会坚持一些自认为正确的错误,没能从个人观念到整体思想的一个解脱;太过直率,在处理问题的能力上所有欠缺;知识层面,在软件测试这个行业还年轻,经验不足,理论知识缺乏,需要加强计算机及网络知识,及扩展知识面;技术能力,编程水平较低,自学能力有待提高,逻辑思维也有待提高。


TAG:

sophie_wang 引用 删除 sophie_wang   /   2011-09-22 11:39:18
3
 

评分:0

我来说两句

Open Toolbar