TC工作明细及规划
新项目PTT已启动，作为此项目的TC，本人从开始接到项目就进入思索中。首先要宏观看本次项目，仍就是windows mobile操作系统下的手机项目开发任务，对比于上个项目eSpace客户端，此项目的某些模块与之有相似处，这对于项目组来说是件好事情，大家可以吸取上个项目的研发经验，结合自身的开发或测试的特点在此次项目的更好的发挥，扬长避短。
微观看，此项目的难度加大，界面功能减少了，更多的涉及到接口与协议，这对于开发与测试来说也是机遇与挑战。接合上一项目来看，本项目一些功能的开发是可以仿照的，这对于开发与测试来说，虽然会得心应手，但难免也会“审美疲劳”，所以此次项目毕然给人树立新的目标，大家的精力是完全的投入。对于测试来说sip协议，rfc协议等都是从来没接触过的，所以学习并很好的理解，并贯彻测试的理念与思维是较难的瓶颈，当然只有返复的理解
并与开发及接口人的沟通，一定能攻克这个难关。
作为此项目的TC，我有自己的工作明细与规划：
首先制定全面的测试计划，测试计划作为测试任务的先提条件，既是计划书又是指导书。从阐述项目的背景到测试范围，这里包括：功能测试、性能测试、压力测试、兼容性测试等；到测试环境的布署到测试人员的安排到阶段性任务流程（例如测试计划阶段要输出哪些文档等）；到sdv阶段测试入口\出口条件（入口：转SDV的checklist是否通过，所有系统测试用例全部基线等，出口：所有测试用例全部覆盖，问题是否收敛达到90%等）；到测试角色与职责任（TC：协调测试工作，编写测试计划和测试报告，编写系统测试方案及用例，执行测试用例，对项目测试工作和质量负责。TE：评审测试计划及测试方案，编写系统测试用例，执行测试用例，对项目测试工作和质量负责。）；最重要的是测试进度与计划（把每一阶段的计划时间全部初步拟定出），测试计划拟定后，还要返复调整，据项目实际动工与完成任务量重新拟定测试计划版本。
测试计划拟定后是项目组成员评审，输出Review文档，接着就是据开发拟定的srs，参加并指导TE评审，这项工作很重要。为什么这么说，往往很多项目都是是开发评审需求，测试直接拿到需求写方案，这样做直接导致测试前期工作不到位，对需求的把握与理解不到位，写出的测试方案也漏洞百出。所以本次项目，测试尽可能的较早投入工作量来，进行需求评审。当然评审力度在哪里，我会定时召开测试人员会议，出FAQ文档。
当需求评审完毕后，就是测试方案的编写，本次方案，我考虑实际工作量，准备是TC与TE都参加进来，把需求中每个测试点搞清楚，写明白，然后组织交叉评审，让每个测试人员理解所有的模块，再分配交叉写用例。
写测试用例是最关键一步了。这里我拟定近半月多的时间，测试组所有成员按分配的任务量估算自己的编写时间，然后上报给我，严格按着测试计划时间执行。写用例时，对于公共用例的编写，提前做到心中有数，对于二级用例的编写也要做出准备。定期找个时间点检查编写用例力度，召开会议商讨遗留问题并给予解决，实再解决不了，要及时和DE,PM,接口人商讨；最后不要忘了组内评审，至少经过两轮。将缺陷问题归类，输出到Review文档。
评审完用例后，就是配合开发进行系统测试，本次系统测试我拟定三个时间点，严格计划来走，在每阶段输出测试报告，当所有用例覆盖测试点后，才能转sdv测试。
sdv测试及功能发散测试\随机测试，要求所有测试人员全部投入，为了防止准备不充分，据系统测试阶段大家的测试量来分配sdv的任务，做到有理有据，大家都能保质保量完成任务。
下面是如何归避风险
从上一项目来看，问题单收敛较慢，这块是因前期工作没开展好造成的。本次项目测试要配合好开发，严格地认真的投入时间与精力到测试中，我会定期抽查每个TE的工作评估。
其次每阶段的代码量估算要准确，避免用例数不足，导致测试不完整。
每阶段不要QA主动来找我进行沟通，而是我亲自与QA交流，学习规避风险的策略与方法，并指导TE们更好的完成工作。
对于项目组一些骨干人员，防止人员流失。要知道人员流失对于我们来说是最大的损失，所以争取给表现好的员工，申请奖励制度，让他/她们感到每个人都关心他/她们，是个大集体。 :lol 学习！ 学习了。。
不过，就这些文档工作就够你自己做的了，何况你自己也要承担部分测试工作呢，计划还是计划啊。目前偶也担任华为D项目TC，采用敏捷开发模式，好多文档工作都来不及做。杯具.. 执行起来应该比较难最前提是要有充足的时间，而后人员要有充足的精力去做 谢谢，目前自己担任项目测试组组长，如何建立一个反应迅速的测试团队是目前我重点考虑的问题，也请大家帮我出出主意
页:
[1]
