项目总结

这个项目从4月中下旬介入，并从4月底开始着手，5月份正式开始。最开始听到是几个项目，由我们两个测试进行测试时，感觉有些恐惧很担心，几次都去找了测试经理进行了沟通，也及时的跟他进行协调，5月份就介入了另一个测试，从而每个人负责两个系统，顿时轻松了许多。但在这个项目中自己也存在多种失误。

当项目下来，首先要了解的是了解项目的情况，如规模，项目周期和计划、人员配置、研发计划等，不能茫然的根据项目系统的多少来决定需要多少个测试人员。

最好的就是给一个测试进度、测试策略，明确项目的功能模块，测试的难易程度。

项目情况：

1.      需求阶段

每个项目在本公司来说都有一个特点，经常都是需求模糊的情况下进行开发，先开发，再跟客户进行沟通，导致会做多余的工作量，这个时候测试要做的最重要的就是读需求文档、数据库设计、UI界面，了解这个项目到底要做什么，要实现些什么，了解系统的业务线，一个业务系统几天的时间来了解需求应该是做不到的，需要充分的掌握和挖掘需求。越细越好。在最开始的时候，项目没有明确具体的内容，只有参照已有的经验，尽可能去挖掘了。

2.      确定项目的人员安排

根据几个点：项目周期、项目规模、研发团队的构成、人员特点、测试内容，比如项目周期短、规模大、研发团队大，这时必须增加测试人员，对于手工测试来说，功能测试都是人手胜过其他的工具。每个测试人员或多或少都有自己的特点，有的比较细心、有的执行力强、有的除了会功能测试还会其他测试，如性能测试、安全测试等等，要根据项目特点、人员特点，可以给每个人机会去接触新的技能，一定要保证现在项目质量的前提下，再学习新技能，如果时间比较紧，内容又多，估计交给一个新手用新技能去测试，会担一定的风险，这个时候就要控制风险，估计风险的大小。并根据风险制定策略，毕竟没有无风险的事情。

3.      测试产出尽早明确

根据很多项目的情况，当在需求阶段的时候，一般都不对测试进行评估，需要多少时间，需要交付什么文档，文档有什么要求，这个时候测试介入，就需要把这些问题阐明，并给出具体的措施。

4.      测试文档的编写

1)        测试文档首先最好根据文档模板的来编写，若模板没有，后期再改的话，所需要的时间是非常多的。

2)        测试用例、测试计划、测试报告、测试策略等，在编写的过程中才能发现问题和矛盾。

3)        写文档之前，要明确测试范围、测试点、测试点的优先级、测试难易点、测试准备条件。

4)        测试用例编写时，内容不能模糊，一定要实例化，比如不能出现正确等主观词汇，一定明确具体的测试数据。所以在写文档时，前期一定要与开发确定好，看下数据库设计文档，用例一定是别人拿着就可以执行的文档，不用去参考其他的文档

5)        一个系统的用例，最后写在一个文档里，不分开写

6)        对于研究所项目要求的文档，尽量先写个文档给他，让他们查看后，再进行更新

7)        测试用例编写后，尽量进行内部评审，头脑风暴。

8)        测试用例里一定要标注优先级，方便后期测试。

注意：开发的前期，即写用例的时候，一定要与开发进行比较细致的沟通，一定要明确测试范围

 

5.      项目过程安排

1)        需求变更，需要发邮件进行确认，不能口头转述

2)        能够文档化的东西尽量文档化，方便查阅

3)        尽可能参加开发的会议，能旁听也是可以的，尽可能第一时间获取项目的进展及项目的风险和变更情况

4)        项目过程中，遇到困难，能在项目组里解决的就在项目组解决，不能解决的再写进周报，上报给部门，通过部门进行协商解决

6.      工作量安排

1)        测试文档的安排，自己估计一个人写一个模块需要多少用例，一条用例多长时间，但在团队里，就按测试项来划分。每个人多少个测试项。

2)        到后期测试执行的工作量，一天一个人执行多少条测试用例，总共多少用例，就可以算出需要多少时间；需要分配多少人

3)        测试用例工作量分配：测试需求需要多少时间，一般按1人月计算，一个月21.75天，21.75*2人=45人月，再除以3个系统，就是每个系统9天/人。同理可以推算测试用例的时间。

4)        测试执行中遇到大的问题，导致交付或者项目延期的问题，一定要提前写在周报里，请项目经理和测试经理知晓，并采取相应策略。

 

7.      测试过程安排

1)        测试执行在每周都去跟进项目进度、测试进度、测试问题

2)        测试问题或者工作量不协调，内部进行沟通在进行任务分配

3)        测试过程中从一个版本迭代到另一个版本，要做两步操作：1. 根因分析，是bug漏测、需求变更、改bug引发的新问题。2. 用例维护，一定在测试的时候维护用例，其实也花不了多少时间。

4)        每个版本来了，首先测基本功能、再回归、最后测新增功能，在项目紧张的情况下，要保证功能点没问题，可以忽略一下小问题。在业务系统里，首先要保证的是业务流程必须跑通，一个业务必须完整顺畅进行。

5)        测试过程中，首轮测试是很重要的，一定要测全。

6)        在时间紧迫的情况下，用例来不及写，都至少要写一个详细的测试用例标题。

 

 

这个项目后的更新的知识点：

1.      性能测试不一定要全部开发完整后，再进行测试，可以在该功能文档后，就进行测试。

2.      产品质量并不是测试能保证的，是开发保证产品质量，比如开发提交版本时，里面又100个bug，我们需要尽可能的找到这些bug ，其他的我们无法保证。

3.      根据公司项目的需求，时不时的补充新的技术技能，每个项目在哪个点投入人、投入多少、整个过程中的解决方案要心里有数。

4.      经常跟组员进行沟通，积极的思想洗脑。

5.      在项目中，一定要有前瞻性，考虑的更高更远，把可能的问题都先考虑到。

6.      时刻警惕人员的流失，对项目造成的影响，以及应对策略

7.      提高自己的沟通、表达能力。