注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Fly to the Sky!

很多人因为寂寞而错爱一个人,更多人因为错爱一个人而寂寞一生。

 
 
 

日志

 
 

我的测试工作小小感悟  

2009-10-26 11:37:14|  分类: mywork |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

1. 测试开始之前沟通很重要,用于沟通的信息文档是测试工作开始的重要依据。

测试开始之前,尤其是接口测试应该与开发人员有充分详细的沟通,包括直接交流或者详尽的接口说明文档,该文档是设计测试用例唯一依赖的数据。对接口正确的充分的理解,是保证测试用例正确性的先决条件。在rp-mms测试过程中就遇到这种问题,因为对某个接口理解的错误或者偏差,导致测试用例的错误。

2.  在项目开始阶段,测试用例不宜太多、太细、太具体,应该随着项目的不断深入,逐渐地增加测试用例的数量、覆盖的广度和具体程度。

之所以这样,是因为项目的初始阶段,产品或者项目有太多内容和因素无法确定下来,过多的测试用例只会增加后面维护和修改用例的成本。项目的初期,容易把本可以简单的工作做的很复杂和过于精致。等到项目做完的时候,再回首项目初期时所做的“精致”的东东,多半早已被删减的所剩无几或者是改动的面目全非。浪费了大量的时间以及精力。在rp-mms测试中深刻体会到了这点的重要性。

3. 单个测试用例的测试步骤不要太多,6/7步足以。

过多的步骤只会带来执行、实现和分析的难度。可创建多个小的测试用例,考虑用它们的组合来实现更复杂的测试。另外小的测试用例可具备较高的原子性,可使得测试用例反复执行,很容易发现Bug以及重现Bug

4. 对于自动化测试用例而言,其每一个执行和验证步骤都应该有详细的结果输出到日志文件中。

  自动化测试用例在提高测试执行效率的同时,也引入了很多需要人工辅助的地方。自动化测试用例在执行完毕后,需要人工去分析运行的结果,失败的结果有可能会有比手工测试更多因素造成,包括:产品缺陷、测试框架缺陷、测试用例缺陷、测试执行环境设置问题。没有详细的输出日志文件,你很难快速的分析和定位出测试用例失败的原因。

5. 测试人员不应该被手工测试用例或者自动化测试用例限制手脚和广阔的思路。

  已经写好的测试用例只能够帮你覆盖住已明确的功能和缺陷,无法帮你发现新的产品问题。测试的目的是去发现更多的问题,不要把自己限制在测试用编写的常规工作中,应该多留些时间去想客户还会怎样使用你产品,多些天马行空想象力。

6. BUG管理需要一个合理而清晰的方式。

   rpmms测试以及外部服务接口测试工作中,都遇到这样一个问题:

测试的过程中发现了BUG,但是并没有一个公共的合理的方式提交给开发人员,而是私下交流。这样存在的问题是:如果当时开发人员没有解决或者反馈,时间一长就忘记了。可能使一些BUG发现了但并不能确认解决。也不能及时管理该Bug的完成状态。

如果花时间整理成文档也存在一些问题:浪费时间,而且不能及时反馈给开发人员,实时交流。因此,寻找一种快速有效的Bug管理方式很重要。

  评论这张
 
阅读(589)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017