市活动从提交测试到上线，大约持续了一个多月的时间，这其中包括因为不确定上线时间而搁置的时间。而整个市活动期间一直伴随着需求的变更，需求敲定且开发人员开发完全结束的时间是2013年7月9日，正式提交稳定版本测试的时间也是2013年7月9日，而上线日期定在10号，这样整个项目预留的测试时间有些仓促，测试人员只能偏重于主体功能的测试。测试结束后，能保证主体功能都已实现，所有的活动流程可以走通，页面不会报A级错误。
此次测试共执行80个测试点，发现bug112个。其中严重级别17个，无效bug6个，平均每个功能点1.4个bug。 1. 整个项目的bug数量
整个项目共发现112个bug。
2. 每天新增的bug数量
6月5日提交第一版测试，到6月14号第一版基本稳定，暂且搁置，等待上线时间。6月27日到7月3日，需求变更，开发边改测试人员同时跟踪测试。7月4日需求再次变更，直到7月9日开发完全完成，提交测试。在这几个时间点，bug相对集中。
3. 每天解决的bug数
每天解决的bug数量的高峰出现在每天提交的bug数量之后。
4. 每天关闭的bug数量
每天关闭bug数量的高峰出现了每个“阶段性稳定版本”发布之后。6月13日关闭第一个版本的bug，7月8日关闭第一次需求变更的bug，7月10关闭第二次需求变更的bug。
5. 每人解决bug数量
参与解决bug的开发人员有郑伟，马延昭，贾昊，武帅等。
6. bug的解决方案
bug基本都已解决。其中，不予解决的bug是按之前需求提出的bug，后需求已经变更，故解决方案为不予解决。
无法重现的bug因为当时的测试环境在253，代码不稳定，所以出现无法重现，代码稳定后已反复验证，不会再出类似问题。
7. bug的状态统计
已经关闭的bug108个。处于激活状态未解决的bug3个，这3个bug因为时间仓促来不及改，但不影响使用，会在后期维护中慢慢修复。1个已解决未关闭的bug，这个bug涉及学校端创建班级的逻辑问题，改动较大，故解决方案为延期处理，待解决后，才会关闭。
8. 项目存在的风险
（1） 项目测试周期短，未经过大量数据反复测试，直接投入给用户使用存在一定的
风险。
（2） 核对姓名功能可能会出现帐号混乱，目前系统未做“过滤特殊字符”的校验，
如输入特殊符号，数字，英文字符等系统是予以通过的。如果有家长恶意输入，我们无法阻止，在后期的竞赛成绩统计时可能会带来麻烦。
再如果班级存在孩子重名的现象，两个家庭的家长在输入“相同的”孩子姓名时，会造成两个家庭的帐号变成了一个帐号。
（3） 发布安全隐患文章加分，每周加100分，上限800这个功能。需要开发配合改
动时间才能完成测试，时间仓促，未来得及测试。待项目上线后，会密切关注这个功能。
（4） 测试资源少。目前只有一个测试人员，这本身是一种风险，面对测试点较多的
项目，测试周期短，又兼顾多个测试任务，可能会出现漏测的情况。
9. 测试总结
（1）我的收获：市活动成功上线，目前运行良好，暂时未出现问题。我想这是给测试人员最好的安慰。
虽然这次的工期压的很紧，压力很大，但是也让我收获了很多。首先它让我学会如何去面对压力，排解压力，把自己调整到一个最佳的状态。其次也让我学会如何应对突发的情况，如何在短时间内高效率的工作，把风险隐患压到最低。然后就是团队合作，只有把自己融入这个团队，与大家默契配合才能高效率高质量的完成自己的工作。最后就是责任感，我会希望从我手中经过的产品能不出问题或者尽量少出问题，把客观因素的影响压到最低，尽自己的全力去把好最后这一道关。
（2）测试不足：虽然项目已经上线，但是测试仍存在不足。比如测试面覆盖的不够广，测试的力度也不够大，会在以后的工作中会慢慢完善。
（3）存在的问题：这次项目的确让我压力很大，需求变更是一方面原因，然而，更主要的原因是项目进度安排不清晰。我发现这种“突袭”上线的情况特别多，而影响最直接的就是测试这个环节，往往到最后压缩的几乎没有测试的时间了，而这种情况下要保证项目不出问题或者尽量少出问题，测试人员的压力会特别大，很容易会出现漏测的情况。
（4）我的意见：我希望每个项目立项时，能清晰的安排好项目进度：产品设计时间，开发时间，测试时间都能确定下来，接下来各个阶段的工作人员会按照项目时间，合理安排好自己的工作，这样项目才能有条不紊的进行。我认为这也是保证产品质量的一个重要前提。
因为目前只有一个测试人员，所以我希望各个项目的上线时间能错开，争取每个项
目都能预留出给我的测试时间。如果多个项目同时要求上线，我一个人兼顾不过来，会出现漏测或测试力度不够的情况。或者，请领导考虑再招一个测试人员，以解决目前的状态，确保以后产品的质量。
因篇幅问题不能全部显示，请点此查看更多更全内容