读51testing论坛"给经理关于测试方案及测试用例的建议"一帖有感

原帖的地址为：http://bbs.51testing.com/viewthread.php?tid=75739&extra=&page=1

 

rice_mouse(1#):

"1、根据公司项目的现有情况，我建议系统测试方案编写应侧重场景流程的描述，而测试用例则重在针对测试具体功能点时所使用输入的测试数据。我们可以重在编写测试方案，在测试方案中根据需求详细的描述分为i主成功场景与分支流，要求覆盖所有功能与业务规则，达到功能的100%覆盖。而测试用例在测试任务较紧张的时候可以暂不编写，由测试人员根据经验自行判断在测试活动中应该运用何种数据。在测试任务较轻松的时候，测试组成员可依照统一标准共同编制一个测试用例库，将公用的、常用的数据建立数据库，可重复调用，逐渐积累，将会很大程度上减轻测试用例的编写工作。

2、测试方案的评审现在为测试组内评审，我建议此评审可在项目组内进行。原因一，项目组成员更熟悉系统需求，比测试组内评审对项目而言更具针对性，也容易在早期发现实现可能出现的问题与遗漏，BA和开发人员可以及早确认解决；原因二，测试方案可以辅助开发人员关注开发要点，毕竟我们测试是为了发现BUG而是为了预防BUG。

3、测试方案及测试用例的完成可以作为一轮测试完成的标准。现在的处理方式大多是由时间来决定测试是否结束。如果时间不足，部分测试要点会有遗漏；如果时间很充裕，测试人员可能会反复测试这个项目。测试方案及测试用例可以方便的统计出测试的执行率和通过情况。这样既不会遗漏测试要点，也不会重复测试，可以辅助测试活动的统计和管理"

 

个人体会：

1、业务逻辑的优先级确实比功能点的优先级要高，其100%的逻辑覆盖是需要的。最终的客户能接受某些细节上存在bug，但是绝不能接受业务逻辑的流程上存在问题。对每个业务逻辑设计详细的场景覆盖个人认为在项目即使非常紧的情况下也是需要的。此类场景其实在每次build出来后都应该进行相应的回归测试，可考虑采用自动化测试。

 

2、测试方案的项目组评审的确不现实，我们当前的项目组内的开发经理连给测试培训业务逻辑的时间都没有，显然要求开发组全部参人员加一个测试组安排的评审会议显然是不现实的。我当前的做法是先将每个的业务逻辑事先写好场景的matrix，其中包含前置条件，操作步骤，最终现象等内容。采用Excel表格是个非常不错的主意，一目了然，场景和场景之间各个列之间的区别。完成场景设计后实现通过mail或会议的形式在测试部内容进行查漏补缺；测试组内部意见一致通过后，将场景设计发给开发经理进行相应的确认；我们的开发经理对产品质量直接负责，所以也是非常认真的对待这些场景的设计覆盖度，他会转发给相应的开发人员进行最终的确认。一旦得到最终的开发组全体确认，就可以将此类场景的matrix作为正式的测试文档加以存档。

 

3、对于第三点中提到的何时结束项目的测试，想再仔细想想并总结后单独再写一篇文章

 

4、关于测试用例库的好处就是在添加了新feature set后，选择和组织新的测试用例将带来方便

 

rice_mouse(8#):

"以统一标准建立bug库，测试组在某个周期内进行统计，将常见缺陷以邮件方式发送给开发组（软件部），不仅可以帮助开发组预防类似缺陷，同时bug库对于测试组也是宝贵的财富，可以用于测试组成员同行学习、总结、提高。"

个人体会：

Bug库的缺陷分类统计暂时没有涉足，除了上述所说的非常有用的两点，有时间探索一下。