做好测试首先要做好需求、理解业务，这个不用多说了，相信很多人都总结过。当然也听到过一些言论“换单位了，那业务不是没用了”，换单位后，业务没用这是必然的，我也是从易制毒换到当前的税务，但有一点都是跟政府行业，其实我们要做的是摸索和总结如何快速获取和掌握新业务，内容不同，但方法是可以通用的。

对于需求处理，就我接触的有以下三种情况。

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

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

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

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

B这种情况其实是最头痛的，在时间紧和维护项目中经常出现。软件需求功能在界面上都实现了，但开发只是考虑实现需求，却没有把需求与当前业务（其他模块的逻辑），后台数据处理（例如某个字段更新）这些弄好。因为功能测试时，测试人员大都会跑流程或者数据库测试，这时候模糊无标准的问题就来了。另外一些开发人员就会以功能实现，进入测试、或者边设计边改，测试就大工作量了。版本验收流程、开发人员给测试人员培训。

版本验收：像前面提出的，设计不全面等，很容易导致只完成需求，破坏了原有功能或流程功能，在拿到版本后，进行初步的重要流程验收，可以减少很多测试工作量。

开发人员讲解培训：这个很好的解决了由于没设计文档导致的测试不了解内部，被动，另外也是给开发压力，逼他们做单元和集成自测，从中测试也可以提问，不要觉得这是浪费时间，好处你试了才知道。我很坏，呵呵。

C这种情况一般实行Cmmi3之后的企业都很规范。这里我讲下自己的几个方法，更好的理解需求：模块间逻辑图、数据流向图、需求用例矩阵。

模块间逻辑图：其实就usecase图、流程图，只要能让自己摸清楚模块间的业务联系即可，为自己的业务测试用例做准备。

数据流向图：目的是搞清楚，该某块功能涉及哪些表、存储过程，数据表见关系如何，其实有点像数据库模型的小型版，很多问题在界面上实现了，但后台sql处理却有错误。

例矩阵这个主要是对覆盖率进行校验，其实就是一个execl，针对某个需求点有哪些用例。这些文档我稍后上转。另外在阅读需求时，多写一些为什么（例如：文档上写着某输入框有默认值，那你注明下：默认值可以修改吗？）

或许你们觉得让测试参加会议，让开发讲解这些有点难，但记住一点：做测试的一定要“主动”。

在做功能测试过程中，经常会碰到其他的问题。

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

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

  学IT 首选苏州风云教育

风云教育-苏州园区国企，专注java软件开发培训、软件测试培训、VR/AR人才培训、企业人才定制培养的高端IT教育软件培训机构。选择风云教育，不止高薪更是高起点！

      了解更多请咨询：0512-69172205

      微信咨询：wxm1519541769

      QQ咨询：2375604912

      网址：www.fy1010..com