Sugar项目回顾（十五）

个人总结： 

这次测试是从4。3号开始，而我是做为一名Leader对SUGARCRM这个软件做了一次系统测试。
在14号之前，先搭建环境。对人员进行分组。
根据质量模型结合用户手册及各方面信息和资料制定需求说明书。
16号第一个版本的需求规格说明书
18号第二个版本的需求规格说明书
21号进行并组（分功能（四小组）性能（一小组）GUI（一小组）数据库（一小组））
21号第三个版本的需求规格说明书（此时掌握业务流）
23号补充了GUI和性能还有数据库方面生成4.0
25号补充了功能模块的opportunities需求生成5.0
21号制定了初步测试计划
23号完善了测试计划
23--28号开始编写测试用例（此期间输入到QC时出现了巨大状况，导致差点耽误工期）
执行分三个阶段（预测试1.0---正试测试2.0---回归测试5.0）5.5号---5.11号
从5号基本下所有人员全部投入到功能模块的测试。
12号，总结并输出测试报告缺陷报告。

在这次项目中，我学会了如Dreamvawer,LoadRunner,Project,xeru,power designerMymanager,snagIt等工具的使用，
加强了Word,Excel。熟练使用了SVN，QC，SQL SERVER2000，QTP。
知道如何从业务流去分析一个系统，如何编写系统测试用例，如何作计划；如何提高团队人员工作热情。
加强了对风险的意识和处理能力，如在执行过程中一定要记得及时备份数据，以免工作成果丢失。
这次测试不足之处有：评审不够规范，对每个成员工作量的跟踪不及时、不够细，服务器经常出问题。
版本控制不是太合理，正式使用的文档也较少。比如需求评审没有文档输出。

点评个别同学的个人能力：
有同学弄了一个php脚本，捕获了对前台操作时软件向数据库后台中发送的sql语句。

在这次测试项目中，我一共写了214条测试用例，发现了5个严重级别为高的BUG。全团队一共有几千条用例，发现三位数以上的BUG。
该产品主要业务实现，但存在隐患，不建议发布。数据库方面表的关系非常混乱，数据库缺乏必须的合法输入检验。
性能指标也不高，当然这个系统对访问量的要求也不必太高。GUI方面有些小毛病。

与此同时，我还了解到评定一次测试成败可从这几个角度去评估：
多少条用例覆盖了需求？执行了多少条用例？发现了多少BUG？跟预期进度相比？出口准则是否满足？

最后，我总结一下：
项目前期的分析非常重要，好的测试还是要建立在懂业务知识的基础之上。一个项目的成败，关键在于计划是否合理。用例的生成及执行不能带有半点主观意识。另外，要敢于做一个有担当的人。