在TeleNav做测试之功能测试

一.[b]概述[/b]
所在的项目组主要是做web开发，大部分项目是对公司原有网站系统的维护升级，也有一部分是全新的项目，主要采取比较传统的软件开发方法。
项目组主要由developer，tester 跟PM组成，其中PM主要负责写需求文档（MRD），developer跟tester各有一个leader，人员比例大致3:1，三种角色并没有等级高低之分。
在测试过程中，用到的文档主要有：
MRD：市场需求文档
Test Plan：测试计划
Test Case: 测试用例

二.[b]项目启动[/b]
在项目最开始的时候,会有一个项目总的的目标:我们将在某月某日,将某个产品,或者功能正式上线,然后直至需求文档MRD出来后,tester就开始有事情可干了,直至这个项目完成.

三.[b]需求分析[/b]
在需求分析阶段,参与者包括项目组的所有成员,其中ＰＭ是负责人，developer跟tester一起对ＭＲＤ进行评审,记下所有的问题,然后项目组会举行Review Meeting,向PM提出自己的问题,由ＰＭ来决定是否修改需求，在经过几次评审之后，需求将最终定稿.

在所有人对文档进行评审之前,PM会先向所有成员详细介绍新的需求.

四.[b]测试计划[/b]
在需求文档定稿之后,developer会开始写Development plan,在这个plan中,会写明开发结束已经测试开始的时间,但是这个时间往往是需要developer leader跟tester leader协商决定.时间订好之后,Test team可以开始写测试计划.
测试计划最主要的内容包括:
[list]
[*]测试环境要求
[*]测试策略,包括进入退出标准
[*]测试人员与测试进度安排
[/list]
对于测试计划,公司会有模板,根据项目的需求,填上相应的内容即可.在测试计划中也会详细写明测试用例完成,测试用例评审已及各个不同环境的测试开始时间

四.[b]测试用例及评审[/b]
在最开始大家都是用excel管理用例,后来采用开源的testlink.
测试用例完全是遵照MRD写的,在写测试用例过程中,会发现文档中以前没有发现的问题,比如需求文档对一些异常输入没有就行处理.此时可以Email给PM,CC给所有的成员,如果意见被采纳,ＰＭ会在某个时间更新ＭＲＤ．
在测试用例完成之后，会进行test case review会议,所有的项目组成员包括测试,开发,PM都会参加,tester会向大家介绍几乎所有的test cases.Developer亦会提出自己的意见当他发现test case中有什么遗漏的.会议之后,Tester需要根据大家的反馈,更新test case.

五.[b]测试阶段[/b]
测试开始之前,大家先会定个规矩,大概几天时间会发布一个新的版本.但是这个计划往往不会完全会被遵守.
如果是一个老的项目,已经有了自动化测试的脚本,先会运行脚本.手工测试的重点是去验证新增加的功能.
对于新项目来说,最开始一轮的测试,要运行所有的测试用例.以后的每次测试,首先要做的事情,应该要去验证当前版本所修正的bug,是否都被修复了.如果都已经被修复了.在重新进行回归测试.
一旦有bug在测试中被发现,应当及时的新增加一个test case去覆盖这个bug.如果developer对bug的有效性有争议的话,可以开bug review meeting, 由PM来判断bug是否有效

PS:在上Production环境之前的一轮测试,最好在所有的测试通过之后,发布一个测试报告.

六.[b]测试环境[/b]
在Telenav,测试环境包括,Dev,CN Testing, Us Testing, Production,各个测试环境所连接的数据库是不同的.Dev环境只供Developer使用,Production环境只能进行少数有限的测试.CN Testing跟US Testing有网络的区别,但都可以进行测试的测试.

七.[b]总结[/b]
这一套流程在公司运转良好,发布的产品少有出现bug.在我看来没有最好的流程,只有最合适的流程.对于大的项目而言,如果每一个build都要做彻底回归测试,再发布测试报告,无疑需要太多的劳动力.具体怎么实施,要根据项目的实际情况去权衡