在TeleNav做测试之功能测试

所在的项目组主要是做web开发，大部分项目是对公司原有网站系统的维护升级，也有一部分是全新的项目，主要采取比较传统的软件开发方法。
项目组主要由developer，tester 跟PM组成，其中PM主要负责写需求文档（MRD），developer跟tester各有一个leader，人员比例大致3:1，三种角色并没有等级高低之分。
在测试过程中，用到的文档主要有：
MRD：市场需求文档
Test Plan：测试计划
Test Case: 测试用例
二、项目启动
在项目最开始的时候，会有一个项目总的的目标:我们将在某月某日，将某个产品，或者功能正式上线，然后直至需求文档MRD出来后，tester就开始有事情可干了，直至这个项目完成。
三、需求分析
在需求分析阶段，参与者包括项目组的所有成员，其中ＰＭ是负责人，developer跟tester一起对ＭＲＤ进行评审，记下所有的问题，然后项目组会举行Review Meeting，向PM提出自己的问题，由ＰＭ来决定是否修改需求，在经过几次评审之后，需求将最终定稿。
在所有人对文档进行评审之前，PM会先向所有成员详细介绍新的需求。
四、测试计划
在需求文档定稿之后，developer会开始写Development plan，在这个plan中，会写明开发结束已经测试开始的时间，但是这个时间往往是需要developer leader跟tester leader协商决定。时间订好之后，Test team可以开始写测试计划。
测试计划最主要的内容包括:
测试环境要求
测试策略，包括进入退出标准
测试人员与测试进度安排<对于测试计划，公司会有模板，根据项目的需求，填上相应的内容即可。在测试计划中也会详细写明测试用例完成，测试用例评审已及各个不同环境的测试开始时间五、测试用例及评审在最开始大家都是用excel管理用例，后来采用开源的testlink。测试用例完全是遵照MRD写的，在写测试用例过程中，会发现文档中以前没有发现的问题，比如需求文档对一些异常输入没有就行处理。此时可以Email给PM，CC给所有的成员，如果意见被采纳，ＰＭ会在某个时间更新MRD．在测试用例完成之后，会进行test case review会议，所有的项目组成员都会参加，tester会向大家介绍几乎所有的test cases。Developer亦会提出自己的意见当他发现test case中有什么遗漏的。会议之后，Tester需要根据大家的反馈，更新test case。六、测试阶段测试开始之前，大家先会定个规矩，大概几天时间会发布一个新的版本。但是这个计划往往不会完全会被遵守。如果是一个老的项目，已经有了自动化测试的脚本，先会运行脚本。手工测试的重点是去验证新增加的功能。对于新项目来说，最开始一轮的测试，要运行所有的测试用例。以后的每次测试，首先要做的事情，应该要去验证当前版本所修正的bug，是否都被修复了。如果都已经被修复了。在重新进行回归测试。一旦有bug在测试中被发现，应当及时的新增加一个test case去覆盖这个bug。如果developer对bug的有效性有争议的话，可以开bug review meeting， 由PM来判断bug是否有效PS:在上Production环境之前的一轮测试，最好在所有的测试通过之后，发布一个测试报告.七、测试环境在Telenav，测试环境包括，Dev，CN Testing， Us Testing， Production，各个测试环境所连接的数据库是不同的。Dev环境只供Developer使用，Production环境只能进行少数有限的测试。CN Testing跟US Testing有网络的区别，但都可以进行测试的测试。八、总结这一套流程在公司运转良好，发布的产品少有出现bug。在我看来没有最好的流程，只有最合适的流程。对于大的项目而言，如果每一个build都要做彻底回归测试，再发布测试报告，无疑需要太多的劳动力。具体怎么实施，要根据项目的手机情况去权衡