如何做好和完善功能测试总结

做好测试首先要做好需求、理解业务，这个不用多说了，相信很多人都总结过。如何做好和完善功能测试主要分以下三种情况。

一、有需求说明，无设计文档。

这种情况一般分工不是很明确的小团队都会出现，需求来源为客户或者区域客服(特点是太简单了没经过提取，或者太自我了，很难实现)，这时候在不规范的过程也会弄一次需求讨论。这个时候测试务必要做到这点，争取参加需求讨论会议，不用发言，只要听就可以。因为这里没有写文档的习惯，很多测试标准、需求处理细点都会在口头上体现，你得眼疾手快，参加会议很好的一点就是测试过程中，碰到不一致的地方，可以有足够的重语气让开发修改，因为你有证据，而不用去问开发这点是不是要改，如何实现。

二、有需求分析文档，快完成时临时补充设计文档。

这种情况其实是最头痛的，在时间紧和维护项目中经常出现。软件需求功能在界面上都实现了，但开发只是考虑实现需求，却没有把需求与当前业务(其他模块的逻辑)，后台数据处理(例如某个字段更新)这些弄好。因为功能测试时，测试人员大都会跑流程或者数据库测试，这时候模糊无标准的问题就来了，头痛。另外一些开发人员就会以功能实现，进入测试、或者边设计边改，测试就大工作量了。这个时候测试有这些可以扭转一些局面，版本验收流程、开发人员给测试人员培训。版本验收：像前面提出的，设计不全面等，很容易导致只完成需求，破坏了原有功能或流程功能，在拿到版本后，进行初步的重要流程验收，可以减少很多测试工作量。开发人员讲解培训：这个很好的解决了由于没设计文档导致的测试不了解内部，被动，另外也是给开发压力，逼他们做单元和集成自测，从中测试也可以提问，不要觉得这是浪费时间，好处你试了才知道。

三、有需求分析文档和设计文档。

这种情况一般实行Cmmi3之后的企业都很规范。这里我讲下自己的几个方法，更好地理解需求：模块间逻辑图、数据流向图、需求用例矩阵。模块间逻辑图：其实就usecase图、流程图，只要能让自己摸清楚模块间的业务联系即可，为自己的业务测试用例做准备。数据流向图：目的是搞清楚，该某块功能涉及哪些表、存储过程，数据表现关系如何，其实有点像数据库模型的小型版，很多问题在界面上实现了，但后台sql处理却有错误。例矩阵这个主要是对覆盖率进行校验，其实就是一个execl，针对某个需求点有哪些用例。这些文档我稍后上转。另外在阅读需求时，多写一些为什么(例如：文档上写着某输入框有默认值，那你注明下：默认值可以修改吗?)

在做功能测试过程中，经常会碰到其他的问题。例如：对于web，所用控件的ie兼容性，标签值显示格式、长度，提示信息风格、内容，按钮大小，名称等这些，当前项目和开发人员都习惯最后处理。更多时候测试跟开发还不能达成一致，维护时还有“这是以前开发人员弄的，当前不予修改这些。” 一些通用的界面要求可以定个标准并维护，这个初步要求的话，在项目测试计划里能注明下，并达成统一。这样避免项目后期，开发人员改动，测试人员由于对工作负责又得全部测试一遍，减少工作量。

功能测试，先抓主干，再测分支这是恒定的原则。但如何完善功能测试这个值得讨论，测试前如何分析需求，编写用例，测试通过准则。测试中确定测试版本，选择用例，测试优先级。项目后期的测试分析，用例优化等等。

以上内容为大家介绍了如何做好和完善功能测试，本文由多测师亲自撰写，希望对大家有所帮助。https://www.duoceshi.com/xwzx-hydt/1229.html