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