个人工作月总结范文
一、需求测试总结
加入到产品化项目组已有两个月之多，参加过完整的需求测试模块-我的云盘，对于需求测试的认识有了较大转变。刚开始认为需求文档仅是我们测试人员熟悉系统的文档，方便后期用例框架和用例的编写，我们应该严格按照需求标准去评判对错，认为需求是产品人员独立定下来的和开发人员以及测试人员无关。但是真正的经历过一个完整的项目周期后，会发现之前的认识是很片面的。对于一个产品来说，需求很可能是不断变化的，不是每个需求都是有效的，更不是每个需求开发都能实现的，项目后期一个小小的变更都要付出较大的人力和时间，因此我们有必要对需求进行严格的测试和把关，争取做到每个需求都是有效并且可以实现的。目前，我们产品化项目组采用的是敏捷开发模式，这就要求测试人员能够快速应对新的需求，短时间内熟悉功能并提出需求疑问。
对待提出的需求疑问不能坐以等待，作为敏捷测试人员，我们应该是主动去推动产品进行需求答疑，及时组织好需求传递工作。主动性在敏捷模式中显得尤为重要，有新的需求就应该主动积极的`了解并去思考与它有关联的模块，会不会对已用功能产生影响，会产生怎样的影响等等。功能需求、非功能需求都应该是可验证的，需要将需求中有二义性和需求不够明确的都提出来，解决需求中所有不明确的地方。
真正的了解需求才有资格做测试，如果你不知道什么是正确的，那你提BUG的依据又在哪里?你提的BUG又怎么让开发人员心悦诚服地接受并修改呢？话又说回来，只有明确了需求，也才能真正提出隐藏在软件内部，深层次的BUG，提出那些让开发人员觉得受益的BUG，也会受到开发人员的尊重与欢迎，也才能体现我们测试的价值。否则，不明确需求，在界面上点点，提一些边边角角的缺陷，让开发人员不开心，觉得测试人员没水平，竟提些无关痛痒的BUG，浪费他们的时间，领导也会觉得测试的意义不大。
二、测试能力的提高
从需求测试—用例框架—用例设计，测试的基本能力相比之前有了较大提高。用例框架我是写了又改，重复了很多次，期间很感谢组内的小伙伴给我的指导和意见。记得学科资源后台管理用例框架改了不少于10次，这个也是我第一次接触的较为完整的系统框架，刚开始各功能点很零散，没有一个测试主线。学习到一个检查用例好坏的方法，就是自己执行一遍自己的用例，感受一下效果，你会发现很多用例中不合理的地方。测试从UI到功能都需要有一条完整的线路，沿着一条主线走，不至于写出的测试点看起来很混乱。框架的主体有了之后，就需要向里面注入详细内容，结合测试模块的特点，将其细化成一个个用例点。框架有血有肉之后，用例就可水到渠成了，需要注意的是用例语言的描述，一些语言的描述尽量做到大家熟知，用例描述详细的基础上尽量做到简洁明了。用例的描述对于我们新人来说往往是矛盾的，既要做到所有人都能看懂并会去执行它，同时又要做到步骤清晰明了，没有冗余描述。这其中的技巧绝不是一时半会就可实现的，需要我们不断的去练习，不断的去思考，不断的去学习。
三、个人总结
分配到资源平台项目组这段时间，让我对测试工作有了更全面的了解。书本的知识到实际运用中会有许多差距，但是有一些本质的东西还是不变的。《软件工程》中许多关于测试知识当时很难明白，尤其是一个项目中代码开发的工作量确不到工作总量的30%，把很多问题都花费在文档编写、需求分析等等。软件开发不就是写代码实现功能吗，为何做哪些无用功呢？当我参加了项目的实施后，就逐渐的明白了这其中的道理。
目前，还存在许多欠缺的地方：1.根据指导人分配的阶段性任务，不能很好的安排每日工作计划，导致实际工作于预期差距较大，需要从每日的计划中吸取经验，逐步完善。2.工作的效率不高，缺乏主观能动性，需要在今后的工作中逐步克服。3.测试技术的极度缺乏，自动化测试、安全测试、性能测试这些都是大数据时代的主流测试方向，学会这些必须掌握测试技术，至今为止还没接触过。需要利用课余时间自主学习，另外可利用公司的培训增加自己的测试技能。
【个人工作月总结范文】相关文章：
金店销售个人工作月总结11-10
出纳月个人工作总结09-18
教师一月个人工作总结范文01-08
教育实习月个人工作总结08-02
安全生产月个人工作总结08-24
12月班主任个人工作总结范文12-14
二月份个人工作总结范文03-26
12月保险公司个人年终工作总结范文12-20
幼师实习月总结范文_幼师工作总结范文08-25
园长月的工作总结范文07-07