正式测试执行　--7月13日日报（用例正式测试，周春江老师）

    今天的主要任务是进行第二个版本的正式测试。由于有两位组员临时请假，原来进行系统管理的人力一下子就拮据起来。所以我就临时加入系统管理的测试。

    在实际的测试中也遇到一些问题：

1.在Testlab中创建测试用例集的以后，从Testplan中导入测试用例，由于测试用例集相当于原来的二级需求，的范围较大。导入用例后就会发现，许多三级的测试需求下的用例名称相同，在用例集中不容易区分。导致测试效率下降。

2.在Testlab中执行，要查看每个用例的Description，需要好几步操作。而同时再添加缺陷时也有几步，在用例比较多时，也是比较耗费时间的。

这两个问题之前吴晓红老师提到过，建议我们在Testplan中直接执行和提交缺陷，在这个纯手工测试的情况下，应该会提高比较多的效率。

    作为一名组长，在今天的测试执行后与别的组长比较，也发现自己的一些不足：虽然规定了缺陷提交的在QC中的操作方式，但是对于缺陷的描述没有明确的规定，导致风格不一致，这样的缺陷在提交给开发后会造成开发Fix的效率降低。

    另外，周春江老师还给我们讲了如何更深入的设计用例

1.从功能在系统内部实际机制角度设计用例。

   比如TP登陆功能测试，理解登陆的机理，TP客户端与TP服务器之间数据传递方式。可以用软件来截取传递的数据，验证是否正确，还可以运用SQL注入的方式来验证登陆的安全性。

2.从功能、数据相关性来设计用例

   我们在设计用例时，主要关注的是SRS中的单个功能，而交互的多是两个功能，没有对业务有一个整体的把握。而很多情况下，仅仅就功能来说是没有问题的，但是业务逻辑上却是有问题的。这就需要对业务有一个深入的理解，才能设计出合适的用例。

   在交互方面多用户可以考虑：A用户添加与B用户添加，A用户变更与B用户变更，A用户变更与B用户删除；单用户可以考虑：部门删除与项目管理，职务管理与用户管理，角色变更与职务管理。