一、概述

　　JT项目到目前为止来看是失败的，其中不乏测试的原因。在整个测试过程中，还是存在一些问题，在测试计划、执行、进度把控以及测试质量方面都存在缺陷。

　　二、测试计划

　　1、测试计划的安排是基于整个项目的进度，虽然当时有大线表，但是开发基本上都没有按照或者接近时间点完成，导致测试工作无法提前安排，出现了要么没事做，要么加班通宵的情况。

　　2、当有测试任务的时候，没有正确估算出测试时间，或者急于出结果，导致测试不详细、不全面，连续通宵的加班和提测时无止境的等待，人员情绪低落，不能提交高质量的测试版本。

　　3、测试前期有相关文档，后期由于时间问题，没有充分了解需求，对于提测的功能也是在摸索中测试，不能准备充分测试。

　　4、当测试人员较多的时候，测试任务的分配不是很清楚，出现了“三不管”地方。

　　三、测试执行及进度

　　1、前期写好的测试用例没有高效的执行，前期的测试准备不能指导后期的测试。原因很多，包括需求的变动等。

　　2、需求的变动，使得测试出现无效工作，之前已经花费时间做过了，后期由于需求变动，又要重新测试。

　　3、在测试执行过程中，人员之间缺乏沟通，测试的结果或者测试方向错误。

　　四、测试质量

　　1、测试功能全面性：在测试过程中，发现测试会出现漏测的现象。由于前期的测试计划工作没有做好，比如没有测试用例，没有进行测试需求的挖掘，在模块提测后进行随机的测试，没有条理，容易导致漏测的现象。

　　2、测试深度：在测试过程中，只关注前台界面显示或者功能实现是远远不够的，很多隐藏的bug都是通过数据库体现出来的。比如数据库的主键设置不合理，或者是数据库信息不全面，那么在前台显示的信息也是不全面的，特别是商品详情页的相关测试。

　　3、测试广度：测试的时候容易只关注自己模块的东西，不能把整个流程都串联起来，如果是对整个流程的测试，也会发现不少问题。

　　五、测试规划

　　目前在后期的项目中会规范项目流程，测试作为项目整体中很重要的一部分，也要规范测试流程。

　　1、文档完整。

　　在现有需求文档和开发设计文档的情况下，编写测试用例并评审。测试用例作为测试执行的指导，是很有必要的，可以帮助测试人员更好更深入的理解需求及我们程序到底是要做什么，而不是在开发提交测试后测试人员边测边摸索。

　　2、测试执行及进度。

　　1)在执行测试的过程中，必须按照测试用例执行，在保证测试用例100%执行的情况下，可以自由测试。执行测试用例是保证测试质量的有效方法之一，所以必须保证用例的100%执行。在测试过程中，不管bug大小及优先级，只要是发现的bug，全部提交到bugfree中，开发可以根据优先级和严重程度来修改bug，而不是说测试的时候只提严重bug。

　　2)测试的过程中，测试人员之间要及时沟通，避免出现无人测试的地方。每个测试人员都要非常清楚的知道所有的流程，有助于测试过程理解及加强测试广度及深度。

　　3)在测试过程中，必须对数据表和和数据流转很清楚。数据的交互，一定要及时关注数据表，保证自己当前测试的模块数据存储都是正确的，关注与其他模块交互的数据字段或数据表，保证和其他模块的数据交互也是绝对ok的。

　　4)根据线表来计划测试时间，保证测试有充分的时间来执行用例和自由测试。

　　5)执行测试的过程中，及时提交bug到bugfree上，既然有bugfree就要执行。任何以文档记录的bug在最后是非常难统计的，作为以后的参考或者是项目bug统计，所有的bug都必须直接提交在bugfree上。开发人员已更改状态的bug，在修改bug的版本上测试要及时验证。

　　6)对于与开发有争议的bug，有些要确认需求是否是这样，保证提交的bug是有效的。对于开发不改的情况，可以举例示范，拿出相关文档来说服。如若还是有争议，那么可以找需求或者项目负责人来商定是否需要修改。对于某些问题的修改，可能会考虑到修改效率和成本，只要能达成一致即可。尽可能确保在发布版本前，所有的bug都被关注到并且处理。

　　3、非功能测试及建议。

　　除了功能测试外，还应该要关注web测试的其他方面，比如性能测试，数据库测试，安全测试等。鉴于目前大家掌握的技能有别，可以抽出时间分享自己掌握的测试技能，共同提高和进步，提升整个团队的素质。

　　PS：首次作为项目负责人难免会有很多失误，在以后的项目过程中一定会更加努力，避免再犯类似的错误，正确把好质量关。