遇到的紧急事件：
Q:
1. 突然需要交付单元测试用例和单元测试报告；
2. 需要交付接口测试用例和接口测试报告；
3. 平时测试没有维护过用例，造成交付时时间紧急，不能及时交付；
4. 不能很好的激励同事去学习新东西，导致很多问题需要自己亲手处理，造成工作量增加；
5. 不能合理规划好时间，随时掌握项目动态，不能及时了解项目的进展，造成测试局面很被动；
6. 对测试质量，没有办法评估，没有形成测试体系；
7. 如何管理好测试用例质量？
8. 如何进行测试分享
9. 每个人都要在成长中，学会读代码、写代码，拥有自动化测试的能力
A:
1。 每个项目在最开始介入时，就会给出一份需求文档，也许需求文档内容不是很完整，但可以粗略的提炼出需要涉及到的测试内容，比如：功能测试、接口测试、性能测试、单元测试等等，对于管理者而且，需要明确测试内容和需要的人力，比如要用到的测试技能，需要谁才是最合适的，如果恰当技能人员的时候，需要及时的提醒或者给出相应培训和要求，要成员在相应的时间内达到某种水平。比如上面提到的单元测试和接口测试，成员中，没有人曾涉及到相应的测试内容，在短时间内给出结果时，会造成压力和反感，何不每周给予成员一点工作内容，让 他在周报或者哪里体现他所学习到的技能呢。在项目从需求介入研发时，总在某个时间段内，测试处于没有太多事情的阶段，这个时候要把握好测试资源的分配，在工作和技能培训中合理、同时进行，合理利用人力资源。不要过分觉得成员是否学习、是否提升是他自己的事情，人都具有惰性、没有很好的自律性，从某种程度上来说 ，需要一定的监督。
2. 在测试过程中，对于用例是需要维护的，每一周测试人员进行了哪些模块、哪些项目进行了测试，需要进行罗列，涉及到了多少的用例和bug,最好也有所体现，这其中产生了什么问题，测试后，用例是否维护，用例的维护最好在测试过程中进行，不能完全脱离实际的软件。毕竟，想完全按照需求完成的软件，是少之又少的。
3. 测试用例质量。每份用例，曾经也许是直接copy ,或者直接在网上摘抄，很多都不能构成自己测试的思维，导致测试水平没有一个明显的提高，停留在初级的测试水平，只会墨守成规的点点，没有新鲜的血液。在编写测试用例的时候，要融入自己的思路，也就是 测试思路。设计测试用例采用了什么方法。写出的测试用例有什么漏洞，自己可以多阅读，多思考，并将测试用例进行等级划分，那些是严重的，哪些是不严重，严重的测试用例设置为优先级高，不严重的设置为优先级低。
4. 在项目一开始，可以给程序员或者项目经理告知，程序员常犯的bug，并希望程序员在写程序的时候可以避开类似的情况。比如：必填项校验、边界长度、超长字符串校验、界面的美观整齐等。
5. 每个测试项目完成之后，最好是测试人员能进行一些技能分享或者心得体会的总结，也许这样的分享留于表面，但是确能在某些方面能刺激到愿意学的人去尝试，从而挖掘一些人力资源。
注：所有暂时的不测试，不代表不进行测试，要保持能进行相应测试的能力