|
若我面试时,估计回答的跟楼主回答的异样了,回答工作流程了.
看来,面试的时候,还是要准备哈理论知识
引自:<<由国内项目的软件测试流程感悟到的>>
http://www.51testing.com/?action_viewnews_itemid_79016.html
对日项目的时候:
项目开始2个月前,我们会有项目启动会议。会得到项目的TTSJ等需求文档,客户与开发之间协商的可开发,不可开发的最终成果文档。我们会了解这个项目的总体流程。
项目开始一个半月之前,我们会得到项目的系统详细设计和概要设计文档。大家利用这些文档进行测试系统的熟悉,测试点的划分,测试case的抽取,设计,测试case的评审。并且开发方会定期将系统设计变更的文档予以公布,供我们进行备案,以及对测试点的修改(一般来说,成型的测试case很少进行改动,而是会进行notes添加,在后续测试中才会针对notes和设计文档对测试case进行修订)
项目开使之后,会维持部分模块的稳定性,比如当前测试A模块的时候,A是绝对不允许开发人员在测试中进行修改,而是在既定的测试完成之后,开发才可以进行修改,并且提出修改文档,回馈测试方,声明修改了哪些部分,供测试人员进行retest
测试人员发行bug之后,相关的开发人员会进行修改,修改的记录和测试员后续测试的记录会追加在bug表上。在测试员进行retest确认关闭后,开发的负责人要给予该bug关闭的原因。项目结束后,这些原因也会成为软件质量的评价因素之一。
软件项目完成后,项目组需要书写评价报告,包括软件的质量总体评价,负责测试的模块中出现问题的几率,原因分析等。
国内项目:
至少我参与过的国内项目,测试员会在实际测试开始2周内参加测试,这期间包括了对系统的熟悉,测试式样的设计。而且一般的测试项目,因为项目实际开发与需求的脱节性,加上开发人员时间的紧迫性以及没有形成良好的文档约束性。测试人员基本在项目开始的时候是拿不到设计文档,包括详细设计和概要设计文档。能得到的只是很久之前的或者无效或者部分有效的一份比较模糊的需求文档。。
我不太清楚,这里面的原因到底在哪里,但是我清楚的知道,这样的需求文档,能到导致的问题是:测试人员需要跟开发以及需求人员去核实一些重要信息。这在很大程度上取决于测试人员的主观能动性和测试的经验,而且由于对测试系统的熟悉程度不够,也很难做到没有遗漏。。。直接导致的后果就是测试的效果下降,测试出来的产品留有或多或少对后期有影响的bug。
bug这一块,国内项目往往开发和测试出现重跌,也就是说,我刚刚测试过的模块,可能转瞬就被改过了,导致测试量的浪费。不得不进行无规则的重复的测试。
而且国内的开发人员很少会有这样一个习惯,对bug进行针对性的定位和反馈。在他们看来,自己的开发模块都忙不过来,能抽出时间来进行修改已经是给了测试人员天大的面子,哪里有时间进行反馈,有什么必要?殊不知,这样的想法在很大程度上造成了测试管理的滞后,导致系统整体的质量受到影响。 |
|