2010年初，我入职**公司××部，并进入政府事业部××××项目组，作为外包测试人员我知道自己的一言一行不仅仅代表个人，更代表部门的荣誉。面对新的环境，新业务线，新的测试技术我知道我要面临的是一个又一个的挑战。
    2010年4月在××××××项目中，我负责该系统的核心模块测试工作。项目时间非常紧张，面对新的业务线我只有1周时间熟悉业务并很快上手测试，由于项目紧张，配和项目进度需求经常加班加点进行工作。由于不懈的努力，我圆满的完成了测试任务。并在项目维护测试阶段成为了该项目的测试负责人。项目试运行阶段，我带领项目组测试人员，认真仔细地对待项目中的每一项变更和新需求。认真评估系统风险，经过多重的测试策略，项目风险基本在可控范围内。测试组的专业水平得到了项目组的一致肯定。年底项目在计划时间内成功验收并上线。并在2010年年终被客户方评为“项目建设奖”。
    2011年5月由于测试能力的认可及项目的需要，我开始担任测试组负责人。开始慢慢从测试技术工作转为对测试团队的管理。同时兼顾公众项目的测试工作。由于前任工作进行过项目管理工作，有过一定的经验。所以，一切对我来说不算陌生。调查了项目的现前情况，与部门部长进行后期发展沟通交流，我制定了一系列的测试组发展方向规划，在计划中，确定了测试工作的流程规范；完善测试过程方法和途径；建立经验知识库；测试组提升方式；团队发展等。考虑到测试人员水平的参差不齐制定了一系列测试讨论会活动，有主题有方向，经验分享，问题答疑，工具培训等。得到了部长的肯定，得到了测试组成员的一致认同。团队气氛和谐而又有激情。
    2011年8月××××项目启动，该项目测试人员均为新进人员，经验较少。我把××××××项目交接给了较有经验的测试人员。开始接管××××项目。一方面培养有经验的测试人员成为测试负责人，一方面开始培养文献项目测试人员，一方面进行项目管理与沟通工作。以最新的事业部流程管理该项目，从测试申请、测试计划，测试用例设计，测试执行、测试总结，在整个过程中进行了标准的测试流程与和谐的沟通。由于新进人员测试经验不足，为了保证测试的质量，对每个测试人员专业水平进行摸底，从测试需求文档测试与评审，到测试设计、到测试执行，每一阶段前都进行测试经验分享。解决了新员工不少的疑难问题，很大的地提升了测试的工作质量和测试人员的工作热情。三轮集成测试总共发现bug800多个，发现问题的层次较深较全，得到了项目组负责人的肯定，得到了整个开发团队的认可。得到了其它项目组开发负责人的赞扬。
   2011年11月由于项目组的认可，测试组小组由原来的7人发展到18人的测试团队，全部为我部人员，且由我部人员担任测试负责人。在项目组中综合考虑各项目的工作进度，对员工工作量，以及专业技能进行全面掌握，适合的人放在适合的位置，及时根据项目的紧急情况进行人员调配工作。 得到了领导的全面支持。也得到了所有项目PM的致认可。  11月中旬**项目PM与我进行了沟通，释放他部测试人员，并申请我方测试人员及测试规范。通过一系列沟通，由我方测试人员为测试负责人，由我前期进行监督与培养。对前期项目存在问题进行总结说明，对测试过程进行改善建议，12月份的测试工作与质量明显出现改变。得到该PM的相当肯定。
    2011年12月份，已有5个项目同时进行了，自已的工作内容也由项目测试变成了对测试过程改进以及TL人员的培养了。对项目中存的问题，沟通存在问题，进行经验总结，并形成测试过程规范性总结。得到部长的认可，并同时让所有开发人员进行详细了解，以减少开发与测试沟通不和谐而存在的风险。测试过程中，由之前的全面转到各个测试环节点，对各个环节中存在问题进行总结，逐一突破，让测试流程真正规范起来：提出并实施单元测试环节，给开发人员进行了单元测试工具的简单培训，对项目组成员进行了性能测试初级培训等。为项目组以后的发展形成了较成熟的流程规范。由于自己的努力与专业，得到了项目组领导的很大信任，得到了部门领导肯定，得到了测试组成员的一致认可。。。。。
     2011年11月，北京分部划分出来，成为了独立部门，望着组织架构中自已熟悉的名字，感慨万千呀！！！
    

当前的测试工作，不是一句话可以概括出来的；

可能当前自己的工作并非很规范，所以，总感觉说出来的话没有什么底气。

唉，你说咱也是大公司呗，没进来之前听说是很规范的呢？

其实有些公司还是做得很规范，如航天科工等一些国家军工企业。

曾经看到一个报道说，航空在试飞航天火箭时，因为螺丝钉的质量不过关，而导致整个试飞失败。惨痛的教训让这些企业对测试与质量相当重视。

当然，小软件自然和人家航空火箭比不了，所以，大部分公司有测试但没有那么严谨。即使有时间也花不起那么大的代价。

所以，测试工作在当前的企业中，还是相当具有挑战性的。

初步说说，工作当中大概有以下这些问题（说得不全，大家可以补充）

领导不重视，

执行力度不够

过程不规范

文档不齐全

项目采用的是迭代式开发。没有时间让你去走所谓的测试规范流程。

项目需求一直在变，在更新。几个版本测下来，发现软件与当初描述的不是一个概念。

当遇到这些问题时，测试工作的价值与职能不能够很好的发挥出来。

同时也让我们很迷茫。

怎么文档不对呢？

怎么测试过程很不规范呢？

没有充足的时间编写和修改用例

怎么没有经过压力测试，负载测试等就上线呢？。。。。。。。。。

遇到这些情况时，大家需要做的事就是淡定。

没有为什么，因为你一时也改变不了。

就像你改变不了客户的需求随时在变。

就像你改变不了开发人员为什么不更新文档一样

就像你改变不了项目领导确定的系统上线时间，以及考虑是否进行性能测试。

过程还需要时间规范。

你可以提要求，可以提出自己的建议等。可以向领导证明过程的规范可以减小风险。

但是如果改变不了什么，那么当前所做事就是：沟通吧。

随时了解测试任务，摸透系统的业务。

提交bug后，与开发沟通时，如果争，一定要力争到底，具体的方法是，换位思考，比喻论证，你是客户。。。

项目进行中

已重新打版，测试时间5天，

已重新打版，测试时间3天

下周上线，抓紧时间测试。

OK！

go

 

从事测试工作三年了。写点东西，没事当闲聊。

测试是一个很严肃的问题。要从事好这一行，修行完全在个人了。

手工测试也好，工具测试也好，都很重要。主要是看客户的需要。

单就测试的发现问题的力度，手工测试才是王道。

工具测试现在也在使用中。个人的感觉如下：

QTP功能测试，在回归测试时，在大数据量为前提之下，可以使用其完成，否则，建议还是使用手工测试。

   1.如果系统一直在更新，在重购、在改，你所花费的维护脚本的时间代价太大。比手工还不划算。

   2.qtp如果做深了还好，使用不同的数据去驱动，包括无效与失效数据，确实可行，但是，一个系统，如果你不是程序员，那么，你90％情况之下都不知道程序员动了哪些代码。BUG已经悄然躲藏在了某个脚落。

   3.一定要明确为什么要用QTP,这会为你带来你要的什么效果。个别的很建议你用工具测试，如多个文本录入项，为了确保个文本框的有效、无效、边界，特殊字符，空格，模糊截字符，组合，多国文字。。。。；基于如此之多的录入项，使用qtp回归测试可以事半功倍。

   LR性能测试，重要吗？ 这个由客户说了算。  学习的过程，就是多和开发人员，数据组人员沟通。和专家沟通，保证了分析结果的正确性，自己也能学习到不少东西。（写完此段时，想了很久，总感觉是否说得太脱节了，在此还是决定申明一下，性能测试非常重要，但是做与不做，则要看具体情况了）

   测试工作，不是分到任务后，立马埋头苦干。自己的模块点完了，就算完事了。这样的测试，不是最终要的效果。测试人员所担任的是一个质量监控工作。你也许会说了，这是项目组长做的事。 如果项目较多，项目组长顾不了这么多呢？不要以为领导应该做什么。而是要协助领导做了什么。如此，你离组长的职务也不远了，当然，这是后话。

   曾经，在项目中就出现过：

测试已经经过4轮了，在第五轮测试时，测试人员通知可以测试后，就一扎进工作中。此轮测试原定是三天，测试进了2天。bug刷刷地往bug工具中提，偶尔的闲话当中说，这一版不怎么稳定，bug比较多。但是谁也没有去关注这一点。项目组长因为没有参加此次测试，也处在不知情的情况下，以为回归bug再打一版后，周末就可以上线了。

这种情况下，要怎么做呢？ 其它，测试人员在接到项目时，进行预测试，如果严重的脚本错误，或页面报错，应该立即停止测试，并把问题返馈给相关的测试组长，再由测试组长与开发组长沟通。 这是个比较严重的问题，具体的不一一再述。只是想说明，测试一定要抱有认真负责的态度才能做好。

http://tdj602.go3.icpcn.com/index.htm  免费点歌平台

 

 

  一个下午都在研究QC,当然啦，我是研究到现在还没有装起来呀，

数据库是正确的，登录、联接都是GOOD，可是就联不上QC，烦死我了，也不知道是哪的问题。

神呀，救救我吧！