软件测试管理续

      接上篇，我们完成了需求文档和测试用例的编写工作之后，马上就进入到Build 1的测试阶段，这个阶段我们ST Team的任务是三轮ST测试（Round 1，Round 2，Round 3）加上兼容性测试。另外有SQA Team的安全测试和PT Team的性能测试和我们同步进行，最后产出各个Team的阶段报告，ST Team的阶段测试报告由我负责编制。

      这里只说我们ST的测试内容，因为我们每天的工作内容早就在测试计划中安排好了，我们Round 1的测试时间是5天，Round 2三天，Round3一天，每个Round中间有一天的开发组的修复时间，而其实我们随时提交的Bug开发都可能随时修复，这里安排的一天时间是为了避免开发因其他事务没有来得及修改Open的Bug。我们用的缺陷管理工具是自己开发的一个工具，和QC相当类似，但是对我们这个项目来说更方便一些，其实缺陷管理工具大致都一样的，只要合适我们都可以拿来用。在提交Bug的过程中，我的经验是对于那些有争议的Bug，最好是提上去，如果开发确认不是Bug的话，最坏的结果是Closed掉了，但是如果是个Bug测试没有提上去的话，这就是测试组的失职了。还有就是关于Bug的描述，这里的Condition一定要描述清楚，在几月几日那个版本，什么环境下，一定要描述清楚，这样便于开发和测试追溯Bug，减少沟通的麻烦。在兼容性测试阶段，我们的测试目标是在遨游，火狐，IE7三种浏览器的两种分辨率下进行兼容性测试，根据最终用户可能选择的环境，分辨率的选择是800by600，1280by1024.六种情况我们用了5天时间，因为在ST阶段我们用的都是IE71280by1024一种环境，剩下五种环境我们用5天时间测试。

      兼容性测试结束，有两天时间进行测试的阶段总结，对于我来说，之前每天给客户提交的测试报告就派上了大用场，我们的Daily Report是我们发挥主观能动性开发出来了，个人感觉非常全面，不但包括每天出现的Bug总数，而且还细化到各个模块发现几个Bug，这些Bug的严重级别，还有Case的执行情况，Case的通过率等等，最后还要有Bug总数趋势图，各个Bug严重级别分布图等。这些实时的测试数据是测试阶段报告的精华，有了这些，能够帮助测试人员更好的分析系统。最后我们ST的测试阶段报告受到了客户的表扬，得到了领导的认可，我认为在测试的执行阶段，最关键的还是执行力，尽可能翔实的记录我们每天的测试数据，以文档的形式表现出来，就一定能够实现我们测试的价值。