|
测试流程是什么，流程在词典上的解释是“工艺程序,从原料到制成品的各项工序安排的程序”，那测试流程就是指从软件测试开始到软件测试结束经过的一系列准备、执行、分析的过程。所以测试流程并不是只存在于有完整测试团队的公司，它分布在每一个对软件执行测试的公司中，哪怕这个公司只有一个测试人员。
软件测试想要在一个公司中从无到有进而逐步完善，也需要公司上层领导、开发人员等人从接受到理解、支持到尊重的一个过程。要想完成这个目标并不容易，需要公司外部整个软件测试行业和公司内部软件测试工作的双重影响。而整个软件测试行业实际上又是由各个公司内部的软件测试团体组成的，归根结底要让大家都接受软件测试还是要靠每个公司内部软件测试工作的影响。只有合适的测试流程才能快速的显示出测试工作的作用，才能让大家更快的接受测试工作，主动配合测试工作，进而完善测试工作，达到良性循环的作用。
制定合理的测试流程需要考虑的因素很多，毕竟它是大家进行测试工作的依据，又需要理清和需求人员、开发人员、市场人员等多方人员的关系，而且公司不同侧重点又有所不同，所以在这里不可能面面俱到列出所有因素，只是根据自己的经验列出认为比较重要的几点。
制定测试流程首先要清楚自己所在的公司正处在什么发展阶段，是处在最初的创业期还是已经度过了创业期，希望通过测试来提高产品质量，以便取得更多的业务创造更大的效益。可能有的同行会觉得奇怪，软件测试是做技术的只管做好本职工作，为什么制定流程时要这么重视公司的发展情况呢。其实公司的情况和制定测试流程有非常大的联系，公司的情况直接决定着公司对产品的要求，而测试部门一般来说是产品投入市场的最后一个关口，这也就等于公司的发展情况决定了公司对测试部门的要求。开发软件前要先了解软件的需求，制定测试流程前当然也要了解清楚公司对测试部门的需求。了解了公司的情况和要求后，就要根据这些要求结合制定者的测试知识和经验，制定即符合公司要求又能起到软件测试目的的软件测试流程。当然这样做并不是说让软件测试向公司的一些不利于开展软件测试工作的现实情况妥协，只是根据公司的实际情况制定一些可以马上改变公司测试工作现状的流程。
一般正在创业期的公司面临的是公司生存的问题，它需要和其他公司抢市场，这时公司为了配合市场的要求不光要求软件产品的质量更要求整个项目的进度，但是对一些在软件测试过程需要的文档和产生的文档却不是特别在意。而且这样的公司开发人员往往都是测试人员8倍10倍，经常是软件代码已经快写完了，测试人员才会进入项目。这样制定测试流程时就要注意软件测试工作的重点是执行测试，虽然前期的一些测试准备对以后的执行测试工作有很大的指导性作用，但前期准备工作如测试用例的写作等也会增加软件测试的时间，尤其是软件测试人员在软件已经开发出来才进入项目的时候，如果还要花大量时间去准备软件测试，更会让不了解软件测试的人误认为是软件测试拖延了整个项目的进度，让软件测试的推广工作受到更多的阻碍。这样就可以适当删减一些前期的准备工作，如减去用例评审工作，减少一些测试文档的写作工作，对一些测试文档的写作要求适当放宽等，更具体的就是可以不要求测试用例将操作步骤描述的很详细，但是要记录测试的思路可以简化为测试方案，达到对测试工作的跟踪目的就可以。但测试用例最好不要省略因为这个文档可以为以后再测试类似功能的产品做好经验的积累。
如果公司已经度过最初的生存期，这时公司会对产品的质量有更高的要求并且体现到对软件开发过程的要求。而且公司从软件开发计划制定、进度跟踪、项目管理等都有了一定的经验也有了一些历史数据可以参考。这样对软件测试的一些前期准备工作也会有所考虑，并适当满足，这时软件测试流程可以加强前期测试准备工作、后期测试分析工作。具体可以要求软件测试从需求介入以便尽早了解产品，制定独立的软件测试计划并将软件测试时间纳入整个项目进度中，细化测试用例写作的力度，增加后期对缺陷分析的工作进而逐步提高整个软件测试团队的技术力量，让软件测试渗透到整个软件过程中。
其实公司内软件测试一片空白或者测试流程比较完善的公司流程制定和执行相对来说都会比较容易一些，如果是一片空白你可以完全按照自己的想法去建立软件测试流程，剩下的困难只是如何去说服领导和开发配合这个流程。如果软件测试流程已经比较完善，大家对软件测试已经有了一定的支持和理解并且现阶段运行良好，你只需要在一些小节上进行一些修改，如果的确有利于工作会得到大多数人的支持。最难制定的是软件测试刚刚起步有了一些不成型的测试流程，也许不太符合你的想法也许不太适合公司的实际情况但的确在公司运行了一段时间，如果想改变不光要说服测试部门以外的人还要说服测试工作人员，增加了工作的难度，如果公司是这种情况请大家在制定软件测试流程前更要慎重考虑，详细了解公司的情况。
制定软件测试流程时可以参照一些比较完善的软件测试流程，但切忌不可照搬这些流程。经常会遇到这样的情况，如果在测试工作过程中碰到一些问题有人会说如果在微软或IBM公司是这样处理的，我们公司也可以这样。但是工作环境和这些公司是不一样的，测试的思想已经深入贯穿到他们开发的每一个步骤中，而目前大多数公司的软件开发过程并没有达到这样的程度，大多需要解决的是在测试思想还没有贯彻彻底的公司怎么处理这个问题。无论是软件测试刚刚起步还是已经有了一定软件测试团队规模有多年软件测试经验的公司，都有一些属于自己公司特定的测试方法和流程，就是完善的软件测试流程也各有各的不同，IBM和微软在测试流程肯定是有所差别的。如果将他们的流程照搬过来，没有给公司同事一个慢慢接受消化的过程，很容易适得其反甚至引起公司同事的抵触情绪。这里并不是说这些测试流程不好，只是这些测试流程也不是一开始就建立起来的，而是通过多年的经验和教训逐步完善一步一步慢慢建立的，并且现在它们仍在进一步完善中。不仅要学习这些完善的软件测试流程是什么样的，更要学习为什么制定这套软件测试流程。给人金子不如给人点金术，也就是这个道理。那些软件测试流程比较完善的公司走在了前面，SQA人员就要学习他们这一路走来的经验和教训，避免走他们走过的弯路，缩短完善公司流程的时间。
制定软件测试流程要明确测试部门的职责。经常会有测试人员抱怨自己在公司里就是一个打杂的，什么工作都要做，其实这就是职责不明确引起的问题，这样会很大程度打击测试人员的工作积极性影响工作情况进而影响大家对软件测试工作的看法。一些如写用户手册、给用户培训等工作在公司里如果没有专门的部门来做，就很容易推给软件测试人员来做，但是都没有明文规定而且在对软件测试人员进行工作考核时又很容易疏忽这些工作，而且这些工作有时候看起来不太起眼，但是需要耗费大量的时间。所以要明确制定软件测试部门的职责、软件测试人员担任的工作内容，其他一些工作如果由测试人员来做，就要在制定软件测试计划中明确写出这些工作需要的时间，以防止这些工作占用测试时间，使测试人员陷于被动之中。
制定软件测试流程不光要制定软件测试部门内部的工作流程，更要制定与开发部门、需求部门等外部部门的接口工作的流程，一旦项目在进度、功能上有了变化要及时和测试部门沟通，不要让测试部门成为最后一个知情人。
另外在具体执行测试流程时要注意执行的效果，将测试工作落实到实处，而不是为了走过场证明测试工作已经达到了某种程度，否则再好再适合的流程也不能起到它的作用。例如大家都一致认为测试应该从需求开始介入，但是从需求开始介入并不是测试人员参与了需求评审会议提出一些问题就达到了目的。而是要求测试人员在开发把产品开发出来前就要了解这个产品都要实现什么功能，虽然不知道开发怎么去实现这些功能，但是要知道实现了哪些功能。因为在产品在开发提交测试之后往往由于产品一些基本功能没有实现，使测试人员很难深入的对产品进行业务流程的测试，所以一些重大的流程问题往往在测试的后期发现，但是这时可能离产品提交用户的时间很近了，开发人员修改这个问题很可能会引发其他的问题增加产品的风险，而且一些开发还会抱怨为什么测试不早发现这些问题，还有可能使公司怀疑测试人员的能力，让测试工作的开展受到一定的阻碍。只有越来越熟悉产品才会发现越来越深入的问题，这是一般的发展规律难以改变。但是如果前期对产品需要实现的功能有很深的了解，前期就可以提前设计一些业务流程上的问题，一旦产品基本功能完成就马上进行业务流程的测试，使这个过程大大缩短。
本文件根据本公司目前的实际情况，由原来比较比较松散的测试流程过渡到比较严格的测试流程而进行编制，这个版本目前只考虑一些比较粗的线路和一些具体问题，在以后实施过程中逐步完善更新。
一旦流程被执行起来，各方面人员应该严格遵守，但可以提出不同的意见或建议，好的意见建议SQA人员会在以后的版本中进行修正。
该文件适用于软件开发工程师、软件测试工程师以及技术支持工程师。
冒烟测试（Smoking Test）
冒烟测试是指开发团队提交给测试团队进行测试的前期，测试团队检查产品的主要功能是否实现，是否有影响产品正常运行的错误。如果存在这些问题，测试团队有权退回测试任务给开发组，开发组重新组织单元和集成测试。
又叫衰竭测试，测试人员对已经测试过的内容进行重新测试的活动。因为经过一轮测试以后测试组发现一些缺陷，开发人员在修改这些缺陷的同时势必会引起其他缺陷的发生，回归测试主要就是测试这些新缺陷的活动。
对已经提交上去的缺陷经过开发人员修改或确认后，进行再次核实，确认问题是否仍旧存在。
基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件
不是基于内部设计和代码的任何知识，而是基于需求和功能性。
最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试桩。
一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。集成方法由自上而下，自下而上，混合三种方式。
用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。
基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件
测试不运行的部分————只是检查和审阅。
通常意义上的测试————运行和使用软件。
Alpha测试(Alpha Test)
指正规测试完毕后由公司内部人员充当客户进行测试；
Beta测试(Beta Test)
指产品在推出之前，给一些友好客户使用，让他们来进行测试。
把问题分为缺陷，新功能，以及改进。缺陷为经常说的程序中的错误；新功能一般由用户需求提出或者由研发部统一认为应该增加的新功能；改进是测试人员应该改进的一些问题。
适用于所有软件产品的整个开发周期。
|
BUG
|
测试过程，维护过程发现影响系统运行的缺陷
|
|
New Feature
|
对系统提出新功能（由开发提出）
|
|
Task
|
需要完成的任务（建议不使用）
|
|
Improvement
|
对现有问题的改进
|
把缺陷分成不同等级的目的是为了方便错误的确认、控制和希望避免将来再发生。也为了以后对缺陷分布密度进行统计提供依据
适用于所有软件产品的内部测试和外部测试。
|
Blocker：（危急）
|
阻碍其他工作正常进行，系统不能登录，比如系统无法登录；
|
|
|
系统无法编译
|
|
Critical：（严重）
|
基本功能未完全实现,不能完全满足系统要求.系统崩溃或挂起导致系统不能继续运行，比如普通用户登录后，菜单无法操作
|
|
|
对操作系统造成严重影响，比如操作造成系统死机，被测程序挂起，不响应，进程没有关闭等
|
|
|
操作造成数据库死锁
|
|
|
程序中发现死循环
|
|
|
造成重大安全隐患情况（如机密性数据的泄密）
|
|
|
某一模块功能没有实现或者实现错误，影响系统使用，而这一模块也是用户一定要求使用的，比如没有实现LDAP功能
|
|
|
系统性能慢，大多数用户对此无法接受
|
|
|
程序运行过程中造成内存泄露或者指针溢出
|
|
|
造成现有数据错误、丢失且不可恢复的,或者系统当机
|
|
|
操作造成数据通讯错误
|
|
Major：（一般）
|
功能基本实现，但在特定情况下导致功能失败。比如扫描功能，在多用户同时扫描下，功能发生错误
|
|
|
在经常使用的系统中运行正常，但是在特出的操作系统，网卡等情况下无法使用
|
|
|
导致输出的数据错误（数据内容出错、格式错误、无法打开等）。比如导出的面板图片无法打开
|
|
|
导致其它功能模块无法正常执行。比如A，B两个模块，单独执行都可以，但是执行完毕A后，再执行B运行就发生错误
|
|
|
功能不完整或者功能实现不正确。比如功能要求增加，修改，删除，只有增加删除没有实现修改功能
|
|
|
导致数据最终操作结果错误，比如由于运算错误，造成最后的结果不正确
|
|
|
界面错误对用户使用造成误导
|
|
|
界面链接错误或者链接到一个不存在的界面
|
|
|
实现的功能不符合需求或有遗漏
|
|
|
业务流程不正确
|
|
|
报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误）
|
|
Minor：（次要）
|
功能部分失败，对整体功能的实现基本不造成影响。比如输入过长的字符串系统没有报错，但没有导致系统死机。
|
|
|
系统出错提示不正确或没有捕获系统出错信息。比如邮编输入非数字字符，系统提示为输入系统调用接口错误
|
|
|
删除操作没有提示，所有的删除操作必须有提示
|
|
|
系统风格不一样，比如必须填写字段，有的地方是红色的*，有的地方是黑色的*
|
|
|
提示窗口文字未采用行业术语
|
|
|
打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误）
|
|
|
可输入区域和只读区域没有明显的区分标志
|
|
|
滚动条无效
|
|
|
键盘支持不好，如在可输入多行的字段中，不支持回车换行；或对相同字段，在不同界面支持不同的快捷方式
|
|
|
界面不能及时刷新，影响功能实现
|
|
Trivial：（轻微）
|
产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等
|
|
|
测试人员的建议
|
缺陷分级打分标准
Blocker：5
Critical：4
Major：
3
Minor：2
Trivial：1
把缺陷分成不同等级的目的是为了方便错误的确认、控制和希望避免将来再发生。也为了以后对缺陷分布密度进行统计提供依据
适用于所有软件产品的全部生命周期。
状态
|
Open
|
问题提交有待人确认
|
|
In progress
|
问题在处理过程中，还没有确认
|
|
Resolved
|
问题已经解决，但是没有经过问题提出者确认
|
|
Reopen
|
问题复测失败，问题仍旧存在
|
|
Closed
|
问题复测成功，问题被关闭
|
解决
|
Unresolved
|
没有解决的问题
|
|
Fixed
|
问题已经解决
|
|
Won’t fix
|
没有办法解决的问题
|
|
Duplicate
|
已经提交过重复的问题
|
|
Incomplete
|
问题描述不够完全（建议不使用，遇到这样的问题开发人员及时与测试人员联系，测试人员把问题书写清楚）
|
|
Cannot Reproduce
|
问题重现失败，没有足够的信息重现
|
|
suspend
|
目前不处理的缺陷
|
|
Temporarily Solution
|
临时解决
|
|
Reject
|
非缺陷
|
开发部门认为自己修改完毕可以提交测试;
测试部门认为产品可以进行测试（达到复测标准：Open，Reopen个数*缺陷级别<=50）见缺陷分级打分标准。
1.
如果是开发人员提出测试申请跳转到6步
2.
如果是测试人员提出测试申请交给开发部门
3.
开发部门进行考虑是否可以提交测试
4.
如果不可以，流程结束
5.
否则接受申请
6.
开发人员将代码check in到SVN中，打上Tag标记
7.
开发部门提交送测清单，见附录A 送测清单
8.
测试人员进行建立安装程序
9.
测试人员对新版本程序按照冒烟测试用例进行冒烟测试工作以及单元集成测试抽查
10.
测试人员进行测试评估
11.
如果有符合退测标准，退回测试，流程结束。参见退测标准
12.
否则进行测试工作(新版本交付一份给技术部，同时浙大147机器上换用新版软件)
先对上次测试的fixed的缺陷进行复测
然后重点测试送测清单中本次解决的问题
最后进行回归测试（如果非里程碑版本这步可不作）(理论上应该先进行回归测试，再对新功能进行测试，考虑目前情况，两者颠倒)
退测标准
l
10%以上（含10%）的冒烟测试用例没有通过或者
l
新发现有5个以上（含5个）Blocker或Critical级别的缺陷或者
l
单元测试核心代码覆盖率>=80%(含80%)
l
l
版本发布的命名规则
“V”+m+”.+n+”.”+o+”.”+yyyymmdd
m:产品的大版本，比如目前为5
n：0/1 版本是否送交用户， 0：不送交客户，仅供内部测试用
，1：送交客户
o：0/1 里程碑版本，0非里程碑，供内部测试用
，可以不进行回归测试，1里程碑，大的模块或者新的版本完成，需要进行回归测试
yyyymmdd：年月日
l
原则上每周五下班前提交新版本
当测试工程师在测试过程发现一个新问题
1.
测试工程师发现新问题，提交到JIRA,，书写格式参考附录B, 缺陷书写规范
2.
测试经理对提交的缺陷进行抽查
3.
测试经理如果认为提交的缺陷有问题，通知测试人员进行协商
4.
否则保留测试工程师的纪录
5.
开发工程师处理缺陷（测试人员提交上来的缺陷都要进行处理，处理没有解决的标记状态In progress）
6.
将处理后的缺陷标示类型
7.
开发经理与开发人员对Won’t fix，suspend，Reject的问题进行核实
8.
核实通过，保留开发人员的状态，流程结束
9.
否则修改状态为Reopen
10.
测试工程师对fixed, Temporarily Solution的问题进行复测
11.
如果fixed的问题已经解决，关闭缺陷
12.
如果Temporarily Solution的问题已经解决，保持不变
|