3、测试人员编写测试用例不能把握编写的粒度，到底写到哪个程度用例应该算恰到好处的。（建议：测试人员首先应根据项目组的要求，允许投入的时间及不同类型的业务系统去着手编写测试用例，其次测试人员每针对一个需求点编写测试用例的时候，尽量从以下几种测试类型去考虑测试点的覆盖：用户界面、数据的初始化、数据的同步性、数据的一致性、数据的有效性、出错处理测试、关键功能点、权限检查、业务数据流、业务状态转换、系统间接口集成、可用性、安全性、性能。因为测试用例的粗细同样决定着后续的测试执行工作以及测试用例维护工作的投入时间，不能因为测试用例而导致整个测试工作的后延。）
4、测试人员编写的测试用例没有注意到每种测试用例类型的排列先后顺序，以及测试用例执行的连贯性，同时没有与实际的测试执行结合起来。（建议：一个需求所扩展出来的测试用例应尽量按照一定的顺序进行排列，如：界面显示检查 -> 数据内容检查 -> 功能点的出错处理检查 -> 功能点的正常处理检查 -> 业务流程的检查 -> 权限检查，这样可以让用例看起来条理清晰，可读性较强。同时测试用例更应该与测试执行时所做的操作相吻合，比如测试人员首先登录系统，进入某一个页面，先检查界面文本显示，然后查看数据内容是否正确，接着检查某个功能是否进行了出错处理，它是否达到了正常的可用性，最后提交数据，检查业务流程流转是否正确等。所以用例应该根据上面的这些检查操作来编写，通过一连串测试用例来实现这些操作。） 5、一旦测试任务较多时，测试人员不能较好的把握测试的主次及优先顺序。不知道业务集中在哪些地方，哪些场景用户操作比较多。（建议：测试人员应该了解业务人员的基本操作习惯以及业务集中区域，对于业务人员经常操作的模板及业务，或者业务人员依赖性很强的功能点，测试人员应该重点对待，认真测试，比如：创建合同，邮件通知等。同时对于的不同的业务流程，测试人员应该与需求人员进行咨询，得出测试的优先级，比如：在某系统里，合同的业务单数最多，其次为开票，站点。）
6、测试过程中提交问题单的占用的时间过多，导致测试的时间不够。 （建议：测试人员在前期提单尽量标准化，规范化。随着测试的深入以及工作量的增加，测试人员可以通过标题准确来描述问题单，让开发人员通过标题就可以知道问题所在。其次测试人员对于比较容易重现的问题单或者容易理解的，可以尽量忽略问题描述，但还是需要提供截图。对于组合操作发现的问题单，描述里面需要写明重现步骤及测试数据与条件。） |
7、问题单的严重级别定义不准确。在测试过程中，测试人员往往对于系统权限，流程错误等问题单给予提示或一般的严重级别，这样可能导致开发经理在分发问题的时候产生误导，或者导致项目质量分析报告中出现误差。（建议：测试人员应该根据缺陷给用户所带来的影响，以及与业务操作的关系等多方面去考虑，实事求是的给出准确的定义。bug严重级定义请参考缺陷填写规范V0.2.doc）
8、测试人员的沟通积极性不足。测试人员在整个软件开发生命周期里需要跟各种不同的角色进行沟通，比如需求人员，开发人员，开发经理，项目经理，架构师，运维人员及编辑人员等，与各种不同角色的人员进行沟通可以更好的支撑测试人员顺利的完成测试工作。（建议：测试人员在熟悉需求及编写用例的时候，应该主动与需求人员进行沟通，明确需求，解答需求疑惑。主动与开发人员进行沟通，咨询系统原型，获取开发人员的开发思路，从而完善测试用例，更全面的覆盖测试执行；应主动向项目经理或开发经理，提出风险问题或者自己的建议，如测试的面太广，测试时间不够等问题。性能测试人员更应该向系统架构师咨询系统的设计与架构，为后面的性能测试打下结实的基础，尽早的发现测试过程中的难点与问题点） |
不错的文章 收藏了
