功能测试经验

　　功能测试经验  软件测试

　　今天boss问我们对于公司当前功能测试是否有完善意见，突然觉得这个话题离我们很近，却总来没深入总结过。还好要求明天上交报告，先在此做些总结，到时候拼装下给boss.

　　接触测试三年了，从测试工程师到测试组长兼sepg,然后跳槽继续测试工程师。一路下来都在跟需求跟业务打交道。做好测试首先要做好需求、理解业务，这个不用多说了，相信很多人都总结过。当然也听到过一些言论“换单位了，那业务不是没用了”，换单位后，业务没用这是必然的，我也是从易制毒换到当前的税务，但有一点都是跟政府行业，其实我们要做的是摸索和总结如何快速获取和掌握新业务，内容不同，但方法是可以通用的。

　　对于需求处理，就我接触的有以下三种情况。A、有需求说明，无设计文档。B、有需求分析文档，快完成时临时补充设计文档。C、有需求分析文档和设计文档。A这种情况一般分工不是很明确的小团队都会出现，需求来源为客户或者区域客服(特点是太简单了没经过提取，或者太自我了，很难实现)，这时候在不规范的过程也会弄一次需求讨论。这个时候测试务必要做到这点——争取参加需求讨论会议，不用发言，只要听就可以。因为这里没有写文档的习惯，很多测试标准、需求处理细点都会在口头上体现，你得眼疾手快，参加会议很好的一点就是测试过程中，碰到不一致的地方，可以有足够的重语气让开发修改，因为你有证据，而不用去问开发这点是不是要改，如何实现。 B这种情况其实是最头痛的，在时间紧和维护项目中经常出现。软件需求功能在界面上都实现了，但开发只是考虑实现需求，却没有把需求与当前业务(其他模块的逻辑)，后台数据处理(例如某个字段更新)这些弄好。因为功能测试时，测试人员大都会跑流程或者数据库测试，这时候模糊无标准的问题就来了，头痛。另外一些开发人员就会以功能实现，进入测试、或者边设计边改，测试就大工作量了。这个时候测试有这些可以扭转一些局面——版本验收流程、开发人员给测试人员培训。版本验收:像前面提出的，设计不全面等，很容易导致只完成需求，破坏了原有功能或流程功能，在拿到版本后，进行初步的重要流程验收，可以减少很多测试工作量。开发人员讲解培训：这个很好的解决了由于没设计文档导致的测试不了解内部，被动，另外也是给开发压力，逼他们做单元和集成自测，从中测试也可以提问，不要觉得这是浪费时间，好处你试了才知道。我很坏，呵呵C这种情况一般实行Cmmi3之后的企业都很规范。这里我讲下自己的几个方法，更好的理解需求：模块间逻辑图、数据流向图、需求用例矩阵。模块间逻辑图：其实就usecase图、流程图，只要能让自己摸清楚模块间的业务联系即可，为自己的业务测试用例做准备。数据流向图：目的是搞清楚，该某块功能涉及哪些表、存储过程，数据表见关系如何，其实有点像数据库模型的小型版，很多问题在界面上实现了，但后台sql处理却有错误。例矩阵这个主要是对覆盖率进行校验，其实就是一个execl，针对某个需求点有哪些用例。这些文档我稍后上转。另外在阅读需求时，多写一些为什么(例如：文档上写着某输入框有默认值，那你注明下：默认值可以修改吗?)

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

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

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

　　下午公司给我们培训cmmi4，午觉都没得睡。哎，只好将boss吩咐的对与公司当前功能测试改善意见的报告缩水了。

　　以下是报告的内容：

　　一、通用的界面要求、操作要求可以定个标准文档并加以维护，做为软件界面性的统一。前期较难形成具体文档时，可以在项目初期的设计文档中或者维护小组中达成一个统一。

　　当前经常碰到诸如以下这些问题，web类的控件选用和兼容性;模块中有些保存后显示保存的记录，有的还原为初始化;各个模块提示信息风格、字体、标签长度，按钮大小不统一;维护项目中出现界面问题认为是前期开发人员做好的，这次不修改。有些自定义控件各个项目的共享，例如内管系统的区域自动联想等。当前这里对于界面类修改都是放在后期进行，开发人员各自有自己习惯，例如时间填写、加注释都不统一。其实这个可以慢慢做个标准，在不刻意修改中提升起来。就可以避免验收测试或者需求经理提出问题时，大都是界面导致的问题。

　　业务类软件的界面对齐方式，提示信息风格、字体类型、控件的选用和共享，保存后是否显示结果、按钮名称等这些可以先做起标准，基本上相同业务领域下区别不会很大。避免后期修改，界面标准模糊，是否改，可能改了还需对模块回归。

　　二、对于维护项目中需求变动情况下，出现用例修改情况，建议规程化操作。例如，新增用例存放的方式，命名规程是否跟之前的用例一致。修改用例时在描述中增加修改日志等。

　　当前在做维护单时碰到以下几个问题：有些后期新增的用例以维护单的名称命名，写的用例存在针对本次需求改动，如果出现多次维护单修改同一的模块，可能会出现在跑用例时需求覆盖率是不全的。

　　三、对于遗留问题，特别是维护单，后续的处理流程如何?

　　在做维护单时碰到过，对A模块进行维护，在测试中,发现B模块的问题，或者同时处理两个问题，但由于时间紧，优先处理重要问题然后结单。对于这些问题，提单人一般说先把问题记上，结单后就不知道如何处理，并且平台里不关闭问题，还无法结单。

　　以前碰到该类问题，除了本次任务的测试报告外，会增加一份遗漏问题分析，写明相应情况，得到提单人、测试主管、客服同意后并决定遗漏问题处理方案后，再发布成果。并且有相应的地方汇总遗漏问题。

　　可能你们看到会觉得奇怪，用例、单子这些本应该是测试管理中最基本，为什么还有问题，主要是因为测试管理软件、任务发放系统等集成平台是公司自己做的。

原文转自：http://www.ltesting.net