系统测试(Functional testing )，也称之为behavioral testing(行为检测)，依据商品特点、实际操作叙述和客户计划方案，检测一个商品的特点和可实际操作行为以明确他们达到设计方案要求。

今日boss问大家针对企业当今系统测试是不是有健全建议，忽然感觉这一话题讨论离大家非常近，却总来没深层次汇总过。还行规定明日上缴汇报，先在这里做些汇总，那时候组装下给boss.

触碰检测三年了，从软件测试到检测小组长兼sepg，随后换工作再次软件测试。一路出来都是在跟要求跟业务流程相处。搞好检测*要搞好要求、了解业务流程，这一无需多讲了，坚信很多人都汇总过。自然也听见过一些观点“换企业了，那业务流程并不是不起作用了”，换企业后，业务流程不起作用它是必定的，因为我是以易制毒换到当今的税收，但有一点全是跟*府行业，实际上我们要做的是探索和汇总怎么才能获得和把握新业务流程，內容不一样，但方式 是能够通用性的。

针对要求解决，就我触碰的有下列三种状况。

A、有要求表明，无设计文档。

B、有需求分析报告文本文档，快过去进行时临时性填补设计文档。

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

A这类状况一般职责分工并不是很确立的小精英团队都是会发生，要求来源于为顾客或是地区在线客服(特性是太简易了没历经获取，或是太自我了，难以完成)，此刻在没有标准的全过程也会弄一次要求探讨。

这个时候检测尽量要*这一点——争得参与要求探讨大会，无需讲话，只需听就可以。由于这儿沒有写文本文档的习惯性，许多检测规范、要求解决细点都是会在口口声声反映，你得眼明手快，参加会议非常好的一点便是检测全过程中，遇到不一致的地区，能够有充足的重语调让开发设计改动，由于你有直接证据，而无需去问开发设计这一点是否要改，怎样完成。

B这类状况实际上是最头疼的，在時间紧和维护保养新项目中经常会出现。软件开发需求作用在页面上面完成了，但开发设计仅仅考虑到实现需求，却沒有把要求与当今业务流程(别的控制模块的逻辑性)，后台管理数据处理方法(比如某一字段名升级)这种弄好。由于系统测试时，测试工程师通常会跑步骤或是数据库测试，此刻模糊不清无规范的难题就来了，头疼。

此外一些开发者便会以作用完成，进到检测、或是边设计方案边改，检测就大劳动量了。这个时候检测有这种能够扭曲一些局势——版本号工程验收步骤、开发者给测试工程师学习培训。版本号工程验收：像前边明确提出的，设计方案不全方位等，非常容易造成 只进行要求，毁坏了原来作用或步骤作用，在取得版本号后，开展基本的关键步骤工程验收，能够降低许多检测劳动量。

开发者解读学习培训：这一非常好的解决了因为没设计文档造成 的检测不了解內部，处于被动，此外也是给开发设计工作压力，逼她们做模块和集成化测试，从这当中检测还可以提出问题，不必感觉它是混日子，益处你试了才知道。我很坏，呵呵呵。

C这类状况一般推行Cmmi3以后的公司都很标准。这儿我讲下自身的好多个方式 ，更强的了解要求：控制模块间逻辑图、数据流分析向图、要求测试用例引流矩阵。控制模块间逻辑图：实际上就usecase图、流程表，只需能让自身摸清楚控制模块间的业务洽谈就可以，给自己的业务流程功能测试做准备。数据流分析向图：目地是弄清楚，该某一作用涉及到什么表、sql语句，数据分析表见关联怎样，实际上有些像数据库查询实体模型的中小型版，许多难题在页面上完成了，但后台管理sql解决却有不正确。例引流矩阵这一主要是对普及率开展校检，实际上便是一个execl，对于某一要求点有什么测试用例。

这种文本文档我稍候上转。此外在阅读文章要求时，多写一些为何(比如：文本文档上写着某文本框有初始值，那么你标明下：初始值能够改动吗?)

也许你们感觉让检测参加会议，让开发设计解读这种有点儿难，但记牢一点：做检测的一定要“积极”。

在做系统测试全过程中，常常会遇到别的的难题。比如：针对web，常用控制的ie兼容模式，标识值表明文件格式、长短，信息提示设计风格、內容，按键尺寸，名字等这种，当今新项目和开发者都习惯性最终解决。大量情况下检测跟开发设计还不可以达成一致，维护保养时也有“它是之前开发者弄的，当今未予改动这种。”

一些通用性的页面规定能够定下规范并维护保养，这一基本难得话，在新项目测试流程里能标明下，并达到统一。那样防止新项目中后期，开发者修改，测试工程师因为对工作中承担又得所有检测一遍，降低劳动量。

系统测试，抓住主杆，在测支系它是稳定的标准。但怎样健全系统测试这一非常值得探讨，检测前怎样剖析要求，撰写测试用例，完成检测规则。检测中明确检测版本号，挑选测试用例，检测优先。新项目中后期的检测剖析，测试用例提升这些。