这个星期和静姐、明 哥一起被拉到了做功能测试，虽然来到测试部门将近半年了，但一直研究安全测试方面。对功能测试还没真正理解。
因为那天研究安全测试抓包问题，错过了测试用例评估过程。后来询问静姐主要是根据系统中的各种子模块，估计测试用例，根据经验，评估大概需要多少人天，这一般是测试小组长做的事情。按照我们公司的web系统，一般是五人五天，这个系统流程比较麻烦，估算五人五天，还不包括性能测试。但开发方太抠门了，死掐时间，一定要测试部门两人五天完成。这个项目开发方报价4万，所以不希望分测试很多。最后在测是部门高层主管和开发PM商量下，测试部门协助开发完成项目，虽然用的人力依然是五人五天，但报价给开发方是两人五天。
第一天了解流程，发现自己静不下新，还是只对自己的模块流程比较熟悉，没有认真了解其他人员的测试流程，导致后来执行测试用例的时候，后面的模块需要我负责模块的数据，我也不知道，我负责的模块主要是数据的入口。
第二天编写测试用例，主要是以需求分析书，开发详细设计文档，开发概述设计文档为依据，由于此系统涉及到很多数据和表格，所以对于哪个模块能产生哪个表格要非常熟悉，发现自己编写测试用例的技能需要很大的提高，看了明哥的测试用例，才发现自己有很多问题考虑不周到。这部分自己有待于慢慢积累经验。编写测试用例一共用了两天的时间。
第三天，开发给系统，搭建测试环境，由于数据的原因，系统整整搭了一整天。本来预算是半天的，这真是风险了，浪费了很多时间。
第四天才开始执行测试用例，毕竟是我负责的第一个功能测试，自己挺认真的，由于涉及到身份证的严重问题，所有的身份证号码必须是正确的，并且你鞥严重年龄和出身年月等关系。所有自己花了半天的时间找身份证号码和导入初步数据。自己做的还有很多没有考虑到的地方，应该先把数据准备好，好方便后续模块的测试人员，这样才能发挥团队的作用。因为之前没有用过mantis，所以提报缺陷也是一步步跟着学的，提报给开发方的缺陷描述不够详细，并且有时是一个缺陷，才会引发多个错误现象，自己没有认真分析，就把缺陷提报上去了，这做的比较仓促，没有考虑周全，还好开发方是我认识的人（王），沟通起来也还算是方便，没有遇到刁难的开发方。
由于需要大量数据，明哥帮忙用QTP导入数据，省去了我手动添加数据的麻烦和重复性工作。后续就是执行的过程。
测试用例执行到了第二天了，缺陷提报了很多，发现编写的测试用例很多程度影响着测试执行进度，和缺陷的深度。在执行用例的过程中，严重的发现自己的思路很狭窄。自己以后一定要在写测试用例之前，熟悉整个系统流程，尽量提高测试用例的覆盖度。
缺陷是提报上去了，可在描述缺陷上，很不到位，我总是用测试步骤和出现的结果来描述缺陷，感觉提报的缺陷很不精练。缺陷应该有类似性，可以把相同原因的缺陷提报在一个缺陷编号上。省的开发方再次来找你，这样大家也省心点。发现一个问题不要急于就提交，要再次测试他的深度，有可能这个缺陷提报上去，开发方不认为这个是缺陷，所以要把所有可能的步骤执行一遍，从而达到不同广度，重现缺陷。
缺陷提报上去了，开发方可能会让你重现缺陷，有些开发方负责人会纠结于为什么这个缺陷是这个等级等问题，当然这也是开发方的责任，毕竟他们的绩效和工作成果是要向上级交代的。我也碰到这个问题，开发方觉的我提报的缺陷等级过于严重。但是开发方的负责人打电话和我沟通这个问题。对方是个不容许别人插话的人，当时可能他感觉到我的不耐烦的态度。就责问我‘是不是不想干了’，虽然当时很生气，后来下午对他上午说的那句责问回应了一句。发现自己很幼稚。现在想想，自己也有错，不应该表现不耐烦的态度。就算和开发方发生问题或者对缺陷等级纠缠的问题。应该先和测试小组长沟通。然后让他去沟通。如果只是自己去沟通，可能考虑问题方面不够，会给开发方不好的印象。当然如果我是测试小组长，我的属下被开发方这样说，只能是先安慰手下，然后和开发方问清楚这个问题，了解事情原委之后，在开发方面前，要有维护自己手下的意识。不应该是让自己手下让其他人说，否则以后管理方面难以服众，更谈不上管理了。
所以在当自己对缺陷等级不确定的情况下，先和测试小组长讨论或者问有经验的测试人员。然后再提报上去，如果开发方再找你重现缺陷，有理有据，不要害怕，畏缩。自己有道理就要坚持，再不行，或者交给测试小组长处理。
总结：沟通很重要！