我的功能测试分析思路

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

我的功能测试分析路

个人工作方法,借机总结,持不同意见者comments。(单纯从测试角度考虑,不要多想项目过程的流程把控)

早阶段过程:PRD熟悉分析àUC分析à测试设计和用例编写,单纯从功能出发à测试执行。

现阶段过程:PRD熟悉分析àUC分析,系统设计分析à测试设计和用例编写,不仅从功能出发,更重要的是从系统框架上考虑à测试执行

对比这两个阶段,测试过程中多关注了系统设计和系统框架。在经历了这么多项目功能测试后,感觉从系统角度考虑功能测试意义重大,能够更大程度更细致的发现问题,并且节约很多测试时间,提高测试的效率—前提,需求本身贯穿始终。

目前淘宝系统拆分,C/M分离,还有非常多独立的应用平台,原来一个Denali应用现在不知道拆成了几个C/M。这种情况下,对一个涉及多应用平台的项目来说,大多数开发关注的仅仅是某个CorM的功能,或者与其他平台的接口交互,至于接口返回内容,常常认为是对方开发范围内,并不属于自己的管辖。但对于我们测试人员来说,我们是站在整体功能角度上,不能够仅仅是某个CorM功能正确,更应该保证系统性的功能交互正确。因此,在功能测试时光了解功能是远远不够的,从系统角度把握才能够真正了解功能实现的内在。

以大家知道的发布宝贝过程为例,从类目选择到发布完成,可能涉及Catserver,Forest,IM,IC,SC等众多应用。若不了解这些应用之间的交互,对测试人员来说功能测试就太过于表面化,并且不能够自己排查定位问题,从而提高问题跟踪解决效率。自己排查定位问题的最直接利益表现:不需要询问开发人员bug的原因,而是直接告诉开发人员这个bug可能是由于什么判断or调用引起,让他直接查改就行。Look,多屌!我们还可以摆脱单方面被开发忽悠的窘状,提高测试人员在实践面前的地位。

注重系统设计和框架,并不表示要若化其他因素,这也仅是我在工作中的模式,因人而异。每个人需要做的是找个适合自己的工作方式,好好工作,享受生活!

相关文档
最新文档