软件测试通过标准
`
软件测试通过标准
1．编制目的
本文件作为软件测试过程中各阶段的通过标准，旨在合理有效的对软件阶段质量进行控制，同时为软件测试的深度选择和资源投入的决策提供参考。
2．主要内容与适用范围
2.1主要内容
本标准规定了软件测试中缺陷、错误、故障等问题的分级方案及分级说明；各阶段测试通过需遵循的标准；以及把常见问题按分类编写了分级说明。
2.2适用范围
本标准适用于浙江美科MKxxxx的全部模块的α测试（含模块测试和联调测试）、β测试、Release测试等测试阶段，以及阶段内里程碑的控制。上述阶段的测试属于黑
盒测试。
特别需要申明的是：软件一旦进入开发阶段，测试就同步开始了，对于开发过程中的程序员自测、单元测试等属于白盒测试范畴的，本标准不能适用。
【注①：黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打
开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进
行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适
当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的
完整性。】
【注②：白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部
的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它
的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。】【注③：如无特殊说明，本文下面所说的测试均指软件产品的黑盒测试。】3．问题分级规则
3.1分级方法及简要说明
本标准将测试过程中产生的问题按严重程度分成四级，①严重问题：在流程、数据或安全方面存在重大问题，导致软件不具可用性，或核心功能项无法使用；②一般问题：由于设计的缺陷，导致软件使用中存在较明显的障碍，或者局部功能错误，但可以采取其他变通的操作实现；③轻度问题：由于编码不够完善，使某个小功能无法使用，或者对特殊的操作与要求不能支持；④细微问题：存在某些细微的缺陷，但不影响程序正常应用。
3.2从软件规范化角度说明
①严重问题：严重不合理，核心功能完全违反软件规范或业务规范，可能
导致用户强烈的反感。
②一般问题：一般不合理，即使用户经过较长时间的熟练依然有错误操作的可能，
或者使用者始终无法较流畅的操作，可能会导致用户的抱怨。
③轻度问题：轻度不合理，存在歧义，需要反复和用户说明，即使如此，也有可
能在使用中感到不便；界面设计存在缺陷、凌乱或不友好。
④细微问题：虽有不尽人意之处，但不影响用户操作；或用户使用频率较低，并
且不会造成错误；局部界面不够美观。
3.3从软件功能实现角度说明
①严重问题：由于需求、设计错误导致流程和流程控制存在重大错误，与现有政
策法规或实务惯例的规定（约定）有明显冲突；由于设计错误严重削弱软件处理事务的能力；由于编码错误导致骨干流程不可用。
②一般问题：局部功能无法正常使用，但不影响软件整体流程的实现；无法满足
可以预料到的特殊应用；软件功能的实现过程中弹出未控制的系统错误提示，导致流程中断。
③轻度问题：功能虽然能够正常使用，但由于实现过程中缺乏容错性，不能对设
计边界以外（甚至边界本身）的数据或操作做出正确的响应，导致程序整体不稳定；
运行过程中弹出未控制的系统提示，但不影响流程继续。
④细微问题：处理过程中出现的对实现功能没有影响的缺陷；经过说明，用户可
以较容易理解并且不影响用户使用的；实质上与软件实现需求无关的。
3.4从软件数据准确性角度说明
数据准确性实质上衡量一个管理软件功能实现方面最重要的尺度，考虑到数据问题极可能导致软件质量危机，在此标准中单独说明。
①严重问题：由于设计及编码错误导致的各种报表数据统计结果错误；由于设计
疏漏导致流程中数据控制失败；数据计算过程中的四舍五入错误；通过接口转移出现数据错误；各种系统操作（如月结年结、备份恢复等）导致的数据错误，以及其他本文中未列出的数据出错。
②一般错误：由于表格边界设置不当导致数据位数显示错误；报表与报表之间同
种指标数据不一致而没有说明或说明不清楚；报表经过重新排序刷新后出现数据不一致现象；特殊数据未参与统计而没有说明或说明不清楚；各种辅助项目属性修改导致统计出错。
③涉及数据错误的问题不存在轻度或细微状态。
3.5从软件安全性和严密性角度说明
①严重问题：在不依赖后台数据库和解密程序的情况下能够非法登录系统；权限
体系存在重大缺陷足够导致安全隐患；对一些可能对信息安全或数据完整造成威胁的操作缺少强制备份、强制更换操作员、强制重新启动程序等控制。
②一般错误：权限设置存在逻辑上的错误；显而易见的权限控制失败；备份数据
未经处理可直接打开。
③轻度问题：存在隐含的安全漏洞，可以利用快捷方式、成批处理，以及权限的
组合应用中的安全漏洞进行未经授权的操作。
④细微问题：默认状态权限设置不合理；没有遵循逐级授权的原则。
4．通过标准
针对目前软件市场推广和销售工作的特点和相关部门的操作方法，提出几个分阶段的，具备一定里程碑概念的测试通过标准，贯穿于整个软件（系统）测试过程，以下所有的标准细则是一个递进的约束，每一阶段的测试必须通过才能进入下一阶段。4.1可提供新产品演示标准（单向）
4.1.1 标准适用范围
本标准细则中所提到的产品演示仅限于新产品在市场推广时期向用户阐述软件思想和处理方法，广义的新产品包括新设计的产品、老产品的最新升级版本、经过技术改造的产品、新的产品组合方案等。
以下产品演示不在本节标准约束内：提交测试之前基于产品概念的演示、已正式发版产品或解决方案的售前演示、系统实施时的相关培训。
4.1.2 标准内容
具备以下所有条目，可以作为新产品演示版本提供给市场相关部门作推广用：
?：基本流程能够通畅的完成，核心功能可以体现；
?：对具备分支的流程，确保有一种分支可以持续使用，另外几种要求可以体现设置方法和直接效果，否则就应暂时屏蔽分支功能；
?：基本界面符合术语规范，不存在错误或明显歧义；所有可使用的流程中的界面设计工作必须完成；
?：按照标准流程没有出现各种非正常提示；
?：关键流程和流程中的基本数据备份恢复没有问题；
?：所有报表能够在基本数据的基础上正确生成。
4.2典型用户试运行标准
4.2.1 标准适用范围
本标准细则所提到的用户试运行特指以下情况：已经和用户正式签单，并且制定了实施计划，在软件产品测试阶段尚未结束之前需要交付运行，用户将在运行过程中提出一些需求和功能改动意见，产品仍处于不断完善的过程中。
在新产品的研发过程中，选取目标用户群中有一定代表性、并且具备一定规模的用户作为典型用户，通过双方的配合，不断的优化功能，尽可能地摸索出一套比较完美的、有比较广泛适用面的解决方案，对于企业管理软件供应商而言，是一个必须的流程。
在典型用户提出的需求和缺陷在一定程度上得到解决，软件功能更完善、更适合用户实际应用的前提下，可以考虑扩大试运行用户的数量，以更广泛地收集用户的意见，为产品批量销售提供帮助。
产品正式发版后对外发放的短期使用版不在本标准细则的约束中。
4.2.2典型用户试运行标准内容（3以内）
具备以下所有条目，可以作为试运行版本提供给典型用户使用：
?：基本流程各分支确保可以持续使用，每种流程均能够执行到最后环节；
?：所有界面设计都已完成，各种提示信息设置完成；
?：所有流程中没有各种非正常提示；
?: 备份恢复能够正常使用；
?：报表数据基本正确，能够初步满足使用；
?：在少数数据库上得到验证。
4.2.3 少量用户试运行标准内容（15以内）
本节内容除必须遵循典型用户试运行标准外，考虑到用户量的增大，技术支持的力度较典型用户可能减弱，因此对软件稳定性要求更强，更便于用户自学。
?：帮助文件基本完成，对骨干流程有较详细的说明；
?：界面友好，提示内容清晰明了；
?：安装过程流程，数据库连接方便易懂；
?：90％需求和详细设计都已落实到功能中；
4.3紧急放行标准
4.3.1 标准适用范围
本标准细则适用于测试后期，由于市场原因，必须提前交付某一个或几个用户使用，测试结果需保证用户指定使用的功能没有任何问题，允许有少量要解决而未解决的需求和测试中已发现的错误未完成。在软件发版后给用户替换正式版。
4.3.2 标准内容
除用户指定的需求或以前版本中使用中的缺陷及错误必须完善外，按照测试中发现而未解决的问题的数量控制，控制指标如下
严重问题：
一般问题：
轻度问题：
细微问题：
4.4模块测试通过标准
4.4.1 标准适用范围
此处的模块指软件（系统）可拆分的最小单元。本标准细则主要约束了模块过程测试，可提交批量发行的过程质量。
4.4.2模块测试目标说明
由于黑盒测试实质上是一种穷举输入测试，穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的。当然就不能够保证被测试程序中不存在遗留
的错误。模块测试目标是充分利用有限的人力和物力资源，高效率、高质量地提交可
批量销售的软件模块。
4.4.3标准内容
对需求及设计的覆盖面达到100％，执行的测试用例和用例比例超过3：1。必须
支持软件设计中涉及到的所有数据库。
除以上几点在测试中必须注意实现的，按照测试中发现而未解决的问题的数量控制，控制指标如下。
严重问题：
一般问题：
轻度问题：
细微问题：
4.5联调测试通过标准
4.5.1 标准适用范围
联调测试指将若干个已通过模块测试标准达到批量销售质量要求的模块集成在一套或几套系统中，进行安装调试及测试工作。
4.5.2 联调测试目标说明
联调测试主要目标：一方面对系统性能、接口处理、整体安装效果、系统风格与各模块风格的一致性等做出评判，另一方面再次抽测系统内所有新发版模块，以确保整个测试工作的质量。
4.5.3标准内容
㈠系统测试通过的标准：要求整体安装流畅、各子系统或模块选择方便，增删模块的操作顺利，数据库连接和切换正常，系统间各模块界面风格协调，符合界面设计规范。
㈡模块方面抽测通过标准：按照模块测试计划利用TestManger随机抽取测试点进行测试，在加上联调测试人员按照经验对某些功能制定测试方案进行测试，发现而未解决问题的数量控制和模块测试标准相同。
5．常见问题分类中的分级细则
为了进一步规范测试通过标准，有必要对测试中发现的问题归类并标识每一种问题的严重程度，使阶段质量的控制有一个可以实际执行的细则。下面的内容就是集测试人员长期工作实践中整理出的问题及其严重程度的描述。
软件测试中常见问题分类说明
一、规范化问题
包括软件规范和业务规范两大类，软件规范问题主要指操作过程中显而易见的错误或缺陷，非人性化设计、友好度较差等；业务规范问题主要指使用非标准或非惯例的业务术语、以及概念错位等。
㈠软件规范问题
1、操作指示不明确
提示存在二意性、提示操作项“忽略”、“取消”、“退出”等含义不明确。（轻度）
2、简单界面规范问题
①按钮图片丢失、按钮图片不配套、按钮大小排列不美观；（轻度）
②在引用数据窗口的下拉框中，没有根据实际数据来调整下拉框显示的%的大小和垂
直滚动条，导致文本只显示了一部分；（一般）
③界面中存在色块；（轻度）
④菜单排列顺序有误；（轻度）
⑤窗体最小化以后在屏幕上找不到了，无法恢复原窗体；（轻度）
3、操作过程缺乏人性化考虑
①选项过于烦琐且不必要、设置不合适导致使用者遗漏、常规按钮排列顺序不一致（轻
度）
②常用功能不支持键盘操作。（一般）
③单据处理中当由于存在空行时，提示用户输完其余内容，而没有自动删除空行。（一
般）
4、帮助文件规范问题
①联机帮助字体、背景风格不统一；（细微）
②点击“？”按钮打开帮助文件，没有直接定位到内容；（细微）
③内容定位错误；（轻度）
④帮助文件内部链接没有做全；（细微）
⑤文档内容排版错误；（一般）
⑥其他帮助错误。（轻度）
5、软件风格规范问题
①控件的切换顺序有误、DataWindow的切换顺序有误；
（视控件使用频繁程度设为（一般）和（轻度））
②DataWindow内容的对齐方式不正确（数值右对齐、日期中对齐、文字左对齐）；（细
微）
③数值的EditMask（掩膜）设置有误、日期的EditMask（掩膜）设置有误、日期的
默认格式非YYYY.MM.DD、默认日期存在1900.00.00现象或其他不合理的值（轻度）
④弹出窗口不在屏幕中间位置、退出系统缺少提示；（细微）
⑤重大操作（月结、恢复、修复等）缺少提示、重大操作没有自动弹出备份提示；（轻
度）
⑥快捷按钮定义不准确、快捷字母或数字重复、工具栏快捷键定义错误（轻度），工
具栏常用快捷键缺少（细微）；
⑦违反窗口录入标准（一般可录入内容为白底蓝字、不可录入内容为白底黑字或灰
底）、主窗口关闭后未关闭下属窗口；（轻度）
⑧进入界面缺少焦点、焦点位置不合理、回车键切换焦点顺序错误、记录或条件选择
不方便；（一般）
⑨窗口标题、版本号、版权标识、系统图片不统一；（细微）
⑩补丁、紧急放行版未加PN号；（细微）
⑾存在无明显用途或不必要的消息窗。（轻度）
㈡业务规范问题
1、业务术语规范问题
概念偷换、业务名词混用、业务术语出现错别字、生造业务术语、同一功能指向使用
不同术语、多个功能指向使用同一术语。（轻度）
2、操作提示用语不规范
缺少必要的提示、提示语句描述不规范、语序随意、叙述风格不统一、口语化、对操
作的必然后果或可能产生的后果没有提示、提示有误。（轻度）
3、用例错误
引用业务规范错误、引用政策法律相关数据过时、引用相关公式错误、报表格式不符合业务规范或过时、报表或查询窗口中条目或款项设计不全导致信息失真或不可用。
（严重）
4、默认设置不规范
数量或金额长度不符合日常应用、默认编码方案不可行或不科学、系统建表后自动插
入的数据错误、各种默认的数据或编码体系彼此不统一。（一般）
二、常规录入错误
主要指数据录入、修改、保存、删除等常规操作过程中出现的各类弹出式出错信息，数据控制疏漏、数据编辑无效、设置无效等。
㈠数据编辑无效
1、由于建表失败导致的无法设置现象。（严重）
2、各种设置完成后立即查询发现设置有不符现象。（一般）
3、数据编辑保存后，在其他相关功能中查询此数据，不符。（严重）
4、数据经过变动、保存后，在其他功能中查询，变动没有及时体现。（严重）
5、出现如“按！定位”等变量没有替换的错误、定位或搜索不可用。（一般）
㈡出现Data Window Error
1、出现主键冲突导致的错误提示。（试图存入已存在的代码，数据库弹出提示未被程序接
管。）（一般）
2、由于字段类型和赋值范围控制疏漏导致的Data. Window Error。（录入界面允许n+m
位，字段实际宽度为n位，或由于数值掩膜设置出错导致数据库弹出错误提示未被程
序接管。）（一般）
3、由于建表错误导致数据无法保存产生Data. Window Error。（严重）
4、在同一操作界面中反复进行修改、查询、删除等编辑操作使驻留内存的数据与数据库
中的数据不对应导致的Data Window Error。（一般）
5、极限数据录入产生的Data Window Error。（一般）
6、其他操作出现的Data Window Error。（一般）
㈢出现非法操作提示（WIN98）或应用程序错误提示（WIN2000）
1、报表或查询的条件录入中由于使用％、（、）等特殊符号产生的非法操作提示。（轻度）
2、对某一功能、某一组功能的常规操作出现非法操作提示。（严重）
3、对某几个功能的组合操作、或一个功能较复杂的应用出现非法操作提示。（一般）
㈣ .NET错误
包含所有的Microsoft Visual Studio .NET 2003 Error、或表现为“第××行代码错误”
的提示。此类提示在程序任何地方都可能出现。（普通操作就出现的（严重），复杂操作出
现的（一般）
㈤残留的编译信息未及时清除
主要是开发员在开发过程中方便观察程序运行状态而留下的一些提示窗口，表现形式往往
是弹出一个或几个标注感叹号（！）、问号（？）的消息框。（一般）㈥出现WINDOWS 系统提示
比如：文件删除失败、内存不够、无法执行此项任务、Out of Memory等（严重）㈦系统停止响应
在没有并发操作的前提下出现程序停止响应状况、或者长时间停顿，需要点击
Ctrl+Alt+Delete中止的现象（海量数据恢复除外）。（严重）
㈧非正常的失败或操作错误提示
1、操作过程中出现本不应该有的失败提示，如“数据库已被改乱，请到核算单位重新再
建”、“数据保存失败”、“处理失败，请重试”等（严重）
2、提示与出错的实际原因牛头不对马嘴，实际是A错误，显示B提示。（一般）
三、流程错误
主要指程序运行过程中由于需求分析、功能设计中对产品功能缺少深入的考虑、或者在编码过程中的疏漏等原因，产生的逻辑控制错误或失败、数据控制错误等。
㈠逻辑控制错误
1、初始通过时没有自动检测初始化设置的核心内容、或者检测错误。（严重）
2、该禁止的操作流程未被禁止、不该禁止的操作流程被禁止。（严重）
3、对已使用的条款、或存在记录的类别可以作删除操作。（如删除有固定资产的部门、删
除已有员工发薪的员工大类等）。（严重）
4、编码缺少必要的分级政策，直接导致后面流程取数及统计工作的正确性。（严重）
5、数据恢复前未强行关闭当前工作窗口。（严重）
6、初始化前事关流程走向的选项在初始化完成后仍旧可以改动。（严重）
7、流程环节设计不合理、不规范。（一般）
8、流程设计缺少重要的数据出口。
9、对应可能出现的流程中意外情况，缺少可行的解决办法。（如不支持作废、重开、冲红
等）。（一般）
10、设计中对特定的流程及相应的单据缺乏检查、追踪及统计的功能。（一般）
11、单据的处理流程前后因果关联错误。（如修改、审核、删除、作废之间的关系）（严重）
12、公式设置出现闭环、或几个公式间出现互为因果的现象，而能够设置成功。（严重）
13、公式保存没有必要的合法性检查。（一般）
14、短期使用版未控制（严重）或控制时间过长（一般）、正版有时间限制（严重）。
15、软件无法安装或安装失败。（严重）
㈡数据控制错误
1、取上一环节数据出错。（严重）
2、下一环节取数后反填错误。未将所取的值记录下、未加上已取数的状态标志，出现统
计出错、取数无限制、无法继续取剩余值等错误。（严重）
3、下一环单据变动后反填错误。如对于单据删除、作废、修改等变动，上一环节未同步
变动。（严重）
4、公式设置出现闭环。（一般）
5、公式计算出错。（严重）
6、单据录入四舍五入错误。（严重）
7、上下流单据处理中四舍五入错误。（如订单开提货单、提货单开发票等一对一、一对多
处理过程。）（严重）
四、报表和查询出错
1、报表取数错误。（严重）
2、对报表进行过滤、筛选等操作，出现数据错误。（一般）
3、报表分级汇总错误。（严重）
4、报表分类统计错误。（严重）
5、报表非数据元素显示错误。（如表头、制表日期、相关部门等）（一般）
6、项目属性修改导致统计错误。（比如业务员的部门转移、部门的调整、固定资产摊销部
门的变化等统计条件变更导致计算错误。）（严重）
7、部分报表可以通过单击字段名排序，在此过程中出现的界面刷新错误、合计汇总错误
等。（一般）
8、表与表之间同种指标数据不统一。（由于统计口径不同导致。）（一般）
9、初始数据未计算到相关报表。（一般）
10、报表数据四舍五入错误。
①由单据（或其他数据录入界面）汇总计算而来。（一般）
②从其他报表取数或计算而来。（一般）
③报表自身元素计算而来。（严重）
11、对报表某一记录、元素深入查询出错。（比如在总表下查询明细表等，主要针对报表
界面中的其他查询按钮）（严重）
五、打印及打印相关操作错误
在程序中，用到打印功能的相当多，由于许多打印用类库处理，因此错误有较大的相似性，打印相关操作主要涉及打印机设置、打印字体设置、宽度设置、纸张设置。打印包括打印预览、套打、分页打印、满页打印、普通打印等
㈠打印相关操作出错。
1、打印机及打印纸设置有误。（一般）
2、打印页面参数设置无效。（轻度）
3、打印页面参数保存无效。（轻度）
4、打印格式选择无效。（一般）
5、套打格式设置无效。（一般）
6、打印效果转换输出无效。（轻度）
7、打印标题及表头、表尾设置无效或错误。（一般）
8、同样的内容在不同打印机上显示效果不同（指数据正确的前提下）（细微）
㈡打印预览和打印问题
通常情况下，打印预览和打印的现象是一致的，如果非特殊指明的，下面的问题包含打印及预览两个方向。（所有打印必须在两种或两种以上打印机上通过测试。）
1、表头消失或错位。（轻度）
2、表格线不全。（细微）
3、信息打印表格出边界、打印内容有重叠效果。（一般）
4、打印标题与报表查看不一致。（轻度）
5、报表打印时其他信息与查看不一致。（轻度）
6、存在焦点时，打印效果异常。（比如选中区域为黑色、焦点不能预览或打印。）（细微）
7、打印预览工具条和查看窗口操作后切换有问题。（如停止响应等）（细微）
8、查看窗口退出后，打印工具条仍然可以使用。（细微）
9、实际打印时跳行、走纸。（一般）
10、打印预览中能够编辑。（细微）
11、页码打印错误。（轻度）
12、打印实际效果与预览有差异。（细微）
13、满页打印错误。（一般）
14、鼠标拖拉报表列头使之调整宽度、或隐藏某列后预览及打印效果出错。（细微）
15、同样的内容在不同打印机上显示效果不同（指数据正确的前提下）（细微）
16、先预览后打印和直接打印数据或内容不同（严重）
六、接口及数据转移中的问题
1、各模块之间生成单据错误。（严重）
2、各模块之间可以重复取数、或放弃取数（取数失败）后不能再取（严重）
3、各模块交叉查询数据出错。（严重）
4、各模块之间传入传出、导入导出、汇入汇出错误。（数据传出与导入效果不同）（严重）
5、传出到第三方的数据格式不符合要求。（一般）
6、第三方数据导入不能完全接收、或接收错误。（严重）
8、切换网络服务器过程中产生的错误。（一般）
9、不同数据库之间的数据查询失败或错误。（严重）
10、其他网络、数据库之间通讯失败。（一般）
七、权限及安全问题
1、匿名登录成功。（严重）
2、明码登录。（严重）
3、重大系统操作不强制重新登录。（如恢复数据完成、切换年度、年结完成等）（严重）
4、对不可逆的操作缺少安全性提示。（如改动资产月末计提）（一般）
5、没有遵循逐级授权的原则。（细微）
6、权限设置中存在互为因果的同级项目、存在逻辑错误。（一般）
7、某操作员没有某权限，但依然能够进行该种操作。（一般）
8、只有针对一部分对象的权限，但能够进行全部对象的操作。（如部门权限失效等）（轻
度）
9、只有查询权的情况下，可以编辑成功。（一般）
10、没有某权限，但通过快捷菜单能够绕开。（轻度）
11、对权限进行多种组合，出现控制出错的现象。（轻度）
12、默认状态下权限设置不合理。（细微）
13、数据成批处理没有考虑到与权限设置存在冲突。（轻度）
14、缺少必要的权限。（严重）
15、备份出来的数据未经压缩或加密，利用计事本就可以打开文件查阅信息。（一般）
八、备份与恢复问题
1、极限宽度的数据备份恢复失败。（严重）
2、备份恢复数据比较，设置内容不正确。（严重）
3、备份恢复数据比较，存在记录丢失现象。（严重）
4、在各个数据库中，数据小数位长度不一。（严重）
5、数据库中原有数据的，恢复后部分数据未覆盖。（严重）
6、备份恢复过程中产生其他出错信息。（严重）
7、集中备份恢复与普通备份恢复结果不同。（严重）
8、大数据量备份恢复记录条数丢失。（严重）
九、并发问题
并发错误指两人或多人同时对同一流程、同一单据（或相关流程、相关单据）操作所引起的存取错误、系统停止响应等问题。（视相关单据和流程的重要性和并发操作的可能性划分问题严重程度）
1、多人同时录入同类单据，出现单据号重复现象或出错提示。
2、多人同时对同一张单据进行同一流程处理，出现数据控制失败现象或出错提示。
3、多人同时对同一单据作不同操作（如审核、修改、删除、作废等），出现控制失败或
出错提示。
4、按上问题，继续查询此单据，出现错误提示。
5、多人同时录入、编辑同一记录，出现出错信息、或数据保存错误。
6、由于并发产生的提示错误。
7、在不同流程（不同单据）的同步处理中，由于操作涉及同一数据（表）导致的并发问
题。
8、在不同模块的操作中，由于操作涉及同一数据（表）导致的并发问题。（如销售和库
存同时调取存货结存数量）
十、 升级问题
1、恢复以前版本数据没有出现“正在调整数据库”提示。（一般）
2、由于版本之间表结构差异造成的数据无法恢复。（严重）
3、以前版本数据恢复内容不全。（严重）
4、在以前版本上覆盖安装之后无法进入程序、或进入程序后出错。（严重）
5、在以前版本上覆盖安装，进入程序后没有出现“调整数据库”提示。（一般）
6、升级完成之后核对后台表数据，出现表内容丢失现象。（空表或记录不全）（严重）
7、升级完成之后核对后台表数据，出现数据错误现象。（严重）
低 中 高 重要性 可能性 低 中 高 细微 严重 严重 严重 轻度 轻度 一般 一般 细微 严重
软件测试试题
软件测试试题 一、判断题 1. 软件测试就是为了验证软件功能实现的是否正确，是否完成既定目标的活动，所以软件测试在软件工程的后期才开始具体的工作。（?）分析：软件测试人员应在需求阶段就加入到开发过程中。因为软件的质量问题会随着软件开发周期的不断展开而不断放大的，而更正质量问题的成本也是不断放大的，也就是说在需求阶段出现的小问题，到开发完成后缺陷可能成几何倍数放大，而修改所需要的成本也会不断的放大，如果测试工程师能够尽早的加入其中的话可以尽早的找出问题，及时发现，避免问题最后放大到不可收拾。 2. 发现错误多的模块，残留在模块中的错误也多。（??） 分析：开发人员能力参差不齐，当发现某模块bug数越多，修改的bug越多，则引入新的bug就会越多，那么这些新的bug发现的难度要比修改前发现bug要大的多，其隐藏未发现的bug数量就越多，那么相应的模块质量也就越差。代码复用也可能造成该模块的bug比较多。 3. 测试人员在测试过程中发现一处问题，如果影响不大，而自己又可以修改，应立即将此问题正确修改，以加快、提高开发的进程。（?）分析：正确流程应提交错误缺陷，此时开发组人员会有记录，并修改此问题。如果测试人员自己修改，会导致开发人员无记录，容易出现冗余系统版本，并不清楚哪个为最终版本。 4. 单元测试通常应该先进行“人工走查”，再以白盒法为主，辅以黑
盒法进行动态测试。（??） 5. 功能测试是系统测试的主要内容，检查系统的功能、性能是否与需求规格说明相同。（??） 6. 软件质量管理即QM是由QA和QC构成，软件测试属于QC的核心工作内容。（??） 补充： QA（Quality Assurance）品质保证； QC（Quality Conterller）品质控制员 7. 软件测试只能发现错误，但不能保证测试后的软件没有错误。（??） 8. 软件就是程序。（?） 概念：软件是计算机程序，程序所用的数据以及相关文档资料的结合。软件又分为系统软件和应用软件两大类。 9. 测试只要做到语句覆盖和分支覆盖，就可以发现程序中的所有错误。（?） 分析：白盒测试用例设计6种覆盖方法： a. 语句覆盖 b. 判定覆盖 c. 条件覆盖 d.判定/条件覆盖 e. 组合覆盖 f. 路径覆盖 软件测试的目的是发现软件中的错误，但不能保证软件没有错误。10. I18N测试是指对产品做出具有国际性的规划，而L10N测试则是指软件做出符合本地的工作。（??） 补充：
软件测试详细标准
软件测试标准 前言 前一版的《软件测试标准》，在测试工作中发挥了很好的指导作用。本次修改在原标准基础上，提出了新的测试理念、工作方法、组织方式，使之更贴近实际工作，真正起到纲领的作用。 一、软件测试 1、软件测试的目的 软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为：验证软件产品的实现状态以及实现质量。 2、软件测试相关概念 2.1白盒测试 指基于程序结构的测试，测试目标是检查程序内部逻辑结构和逻辑路径，是代码级的测试。 2．2黑盒测试 基于程序功能的测试，根据输入输出的关系推断程序功能的正确性。 2．3测试用例 测试方案，包括数据输入和相应的期望输出。依据测试用例来执行具体操作。 2．4预防性测试 其原理为：只要测试在生命周期中进行得足够早，就能够提高待测软件的质量。 2．5测试风险分析 其目的为：确定测试对象、测试的优先级、测试的深度。 2.6软件测试模型 公司目前采用V模型，实现测试与软件开发的同步进行。
2.7等价类划分 将测试对象按某种约定划分为有限个组成部分，提高测试的有效性。 2.8边界值分析 分析测试对象的所有边界值及边界附近的临界值。 二、测试工作流程 需求分析审核需求分析，编写验收测试部分用例 实地调研重点收集客户实际业务资料、操作习惯，并与需求分析作出对比 概要设计审核概要设计，从用户角度提出问题 编写集成测试用例 详细设计 审核详细设计报告，与需求分析、概要设计进行比对编写单元测试用例编写用户手册总体框架单元测试阶段提出测试计划 审核测试用例 执行测试 测试总结 集成测试阶段验收测试阶段 补充测试用例资料归档 修改测试 审核修改计划程序员提供修改清单编写测试用例执行测试 测试总结 复测测试报告复测测试用例复测 三、开发—测试流程
软件测试标准及方法
软件测试方法 β测试_Beta测试 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。 α测试_Alpha测试 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。 可移植性测试 可移植性测试，英文是Portability testing。又称兼容性测试。 可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。 用户界面测试-UI测试 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息(Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入
软件测试怎么测试 谈软件测试常用方法和测试流程
摘要软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件开发过程的重要组成部分，是软件质量保证的关键步骤。软件测试的方法可分为人工测试和机器测试，人工测试包括个人复查、走查和会审，机器测试可分为白盒测试和黑盒测试。软件测试虽然是一个独立的阶段，但在实际工作中，测试的流程主要包含单元测试、组装测试、确认测试、系统测试四个阶段。 关键词软件测试；白盒；黑盒；单元测试；组装测试；确认测试；系统测试 一、软件测试的常用方法 软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件开发过程的重要组成部分，是软件质量保证的关键步骤。采用面向对象技术进行软件开发产生了两个结果一是开发出功能更强大更便于用户使用的软件产品，二是生成规模庞大的程序代码和文档，这也必然导致更大规模的软件测试和维护工作。因此，规范化的软件测试势在必行。规范化不只是测试的需求（有效代码量、结构/逻辑的复杂性、高性能/高精确性/高可靠性需求）和消耗资源（人力/时间/测试频度）规模化，更要求在面对规模庞大的软件测试需求，在合理的资源消耗基础上，实施有效的测试。 下图描述的是常用的一些测试方法
1、人工测试的方法 （1）个人复查 个人复查是指程序员自行设计测试用例，对源代码、详细设计进行仔细检查，并记录错误、不足之处等。个人复查主要包括检查变量的正确性、检查标号的正确性、检查子程序、宏、函数、常量检查、标准检查、风格检查、比较控制流、选择、激活路径、对照详细说明书，阅读源代码和补充文档等方面的测试内容。 （2）走查 走查是指测试人员先阅读相应的文档和源代码，然后人工将测试数据输入被测试程序，并在纸上跟踪监视程序的执行情况，人工沿着程序的逻辑走查运行一遍，跟踪走查运行的进程来发现程序的错误。走查的具体测试内容包括模块特性、模块接口、模块的对外输入或输出、局部数据结构、数据计算错误、控制流错误、处理出错和边界测试等方面。 （3）会审 会审是指测试人员在会审前仔细阅读软件的有关资料，根据错误类型清单（根据以往的经验、对源程序的估计等，并在以后测试中给以丰富补充）填写检测表，提出根据错误类型要提出的问题。会审时，由程序设计人员讲解程序的设计方法，
软件测试规范标准[详]
软件测试规 1目的 确保软件产品质量，使产品能够顺利交付和通过验收的一项重要措施。 2适用围 适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 ?项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ?项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。 ?测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ?项目负责人组织测试环境的建立。 ?项目经理审核负责控制整个项目的时间和质量。 ?研发人员确认修改测试人员提交的bug。 4工作流程 4.1 测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2 制订《测试方案》 在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下容：
?测试目的； ?所需人员及相应培训要求； ?测试环境、工具和测试软件； ?测试用例、测试数据和预期的结果。 4.3 单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的部结构出发设计测试用例。多个模块可以独立进行单元测试。 ?单元测试容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； ?单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； ?单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4 集成测试 编码开发完成，项目组部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。 集成测试过程应填写《问题报告及维护记录》，测试结果应形成《测试报告》。 4.5 系统测试 在项目开发完成之后，应对整个系统软件和硬件进行系统测试。对性能、可靠性、健壮性、压力承受力等方面分别进行评价，以验证系统是否满足
谈软件测试常用方法和测试流程.
摘要:软件测试就是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件开发过程的重要组成部分,是软件质量保证的关键步骤。软件测试的方法可分为人工测试和机器测试,人工测试包括个人复查、走查和会审,机器测试可分为白盒测试和黑盒测试。软件测试虽然是一个独立的阶段, 但在实际工作中,测试的流程主要包含单元测试、组装测试、确认测试、系统测试四个阶段。 关键词:软件测试;白盒;黑盒;单元测试;组装测试;确认测试;系统测试 一、软件测试的常用方法 软件测试就是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件开发过程的重要组成部分,是软件质量保证的关键步骤。采用面向对象技术进行软件开发产生了两个结果:一是开发出功能更强大更便于用户使用的软件产品,二是生成规模庞大的程序代码和文档,这也必然导致更大规模的软件测试和维护工作。因此, 规范化的软件测试势在必行。规范化不只是测试的需求 (有效代码量、结构 /逻辑的复杂性、高性能 /高精确性 /高可靠性需求和消耗资源(人力 /时间 /测试频度规模化,更要求在面对规模庞大的软件测试需求,在合理的资源消耗基础上,实施有效的测试。 下图描述的是常用的一些测试方法 : 1、人工测试的方法 (1个人复查 个人复查是指程序员自行设计测试用例 ,对源代码、详细设计进行仔细检查,并记录错误、不足之处等。个人复查主要包括检查变量的正确性、检查标号的正确性、检查子程序、宏、函数、常量检查、标准检查、风格检查、比较控制流、选择、激活路径、对照详细说明书,阅读源代码和补充文档等方面的测试内容。 (2走查
走查是指测试人员先阅读相应的文档和源代码,然后人工将测试数据输入被测试程序,并在纸上跟踪监视程序的执行情况,人工沿着程序的逻辑走查运行一遍,跟踪走查运行的进程来发现程序的错误。走查的具体测试内容包括模块特性、模块接口、模块的对外输入或输出、局部数据结构、数据计算错误、控制流错误、处理出错和边界测试等方面。 (3会审 会审是指测试人员在会审前仔细阅读软件的有关资料,根据错误类型清单(根据以往的经验、对源程序的估计等,并在以后测试中给以丰富补充填写检测表,提出根据错误类型要提出的问题。会审时,由程序设计人员讲解程序的设计方法,由程序编写人员逐个讲解程序代码的编写,测试人员需要逐个审查, 提问,讨论可能出现的问题。会审对程序的功能、结构、逻辑和风格都要进行审定。会审的测试内容与“ 走查” 的内容相同。 2、机器测试 (1定义 机器测试的目的是检查程序的动态性能,检查程序在执行过程中存在的错误。尤其是发现程序在实现功能、逻辑通路、数值计算、数据处理、边界处理、错误处理等方面存在的错误。机器测试分为白盒测试和黑盒测试。 (2黑盒测试 黑盒测试即功能测试 ,这种方法是把软件看成一个看不见里面内容的黑盒,在完全不考虑程序内部结构和特性的情况下,测试软件的外部特性。根据软件的需求规格说明书设计测试用例,从程序输入和输出特性上检查程序是否满足设定的功能。黑盒测试常采用的方法是设计适量有效和无效的输入数据进行测试, 以期用最小的代价发现最多的错误。 (3白盒测试
软件测试完成标准
软件测试完成标准 目录 1.简介 (2) 1.1目的 (2) 1.2范围 (2) 1.3文档结构 (2) 1.4词汇表 (2) 2.软件测试完成标准 (2) 2.1软件测试暂停、完成标准 (2) 2.2单元测试停止标准 (3) 2.3集成测试停止标准 (3) 2.4确认测试停止标准 (3) 2.5系统测试停止标准 (3) 2.6安装测试停止标准 (4) 2.8验收测试停止标准 (4) 2.9缺陷修复率标准 (4) 2.10覆盖率标准 (4) 2.11缺陷等级分类 (5)
1.简介 1.1目的 本文档的目的是为软件单元测试、集成测试、确认测试、系统测试、安装测试、验收测试提供停止标准。 1.2范围 本文档适用于虹信软件股份有限公司所有项目及产品的测试活动。 1.3文档结构 第一部分： 简介，介绍软件停止标准的目的，本标准的适用范围，以及在本文档中使用的词汇的解释。 第二部分： 描述软件单元测试、集成测试、确认测试、系统测试、安装测试、验收测试停止标准。 第三部分： 列出本标准使用的参考文献。 第四部分： 附录 1.4词汇表 缺陷（Defect）：缺陷是对软件产品预期属性的偏离现象。 覆盖率（Coverage rate）：语句覆盖率、测试用例执行覆盖率，测试需求覆盖率等的总称。 2. 软件测试完成标准 2.1 软件测试暂停、完成标准 1)软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现紧急错误 大于等于严重级别错误暂停测试返回开发。
2)软件系统经过单元、集成、确认、系统、安装、验收测试，分别达到单元、集 成、确认、系统、安装、验收测试停止标准。 3)软件系统通过验收测试，并已得出验收测试结论。 4)软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。 5)软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测 试应随之暂停或终止，并备份暂停或终止点数据。 2.2 单元测试完成标准 1)按照单元测试计划完成了所有规定单元的测试 2)达到了测试计划中关于单元测试所规定的覆盖率的要求 3)软件单元功能与设计一致 4)在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准 2.3 集成测试完成标准 1)按照集成构件计划及增量集成策略完成了整个系统的集成测试 2)达到了测试计划中关于集成测试所规定的覆盖率的要求 3)被测试的集成工作版本每千行代码必须发现至少2个错误（不含优化级别错误） 4)集成工作版本满足设计定义的各项功能、性能要求 5)在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 2.4 功能测试完成标准 1)功能测试用例设计已经通过评审 2)按照功能测试计划完成了功能测试 3)达到了功能测试计划中关于功能测试所规定的覆盖率的要求 4)系统达到详细设计定义的各项功能，性能 5)在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准 2.5 系统测试完成标准 1)系统测试用例设计已经通过评审 2)按照系统测试计划完成了系统测试 3)达到了测试计划中关于系统测试所规定的覆盖率的要求 4)被测试的系统每千行代码必须发现至少1个错误（不含五级错误） 5)系统满足需求规格说明书的要求 6)在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准
软件测试基本流程及要求
软件测试基本流程与要求（提纲） 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试--测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
软件测试规范
软件测试标准规范 1目的 为了确保软件产品质量，使产品能够顺利交付和通过验收，特编写本文档，以作参考 2适用范围 本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 ?项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ?项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护 记录》。 ?测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ?项目负责人组织测试环境的建立。 ?项目经理审核负责控制整个项目的时间和质量。 ?研发人员确认修改测试人员提交的bug。 4工作流程 4.1测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2制订《测试方案》
在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容： ?测试目的； ?所需人员及相应培训要求； ?测试环境、工具和测试软件； ?测试用例、测试数据和预期的结果。 4.3单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。 ?单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； ?单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； ?单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4集成测试 编码开发完成，项目组内部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。
软件测试笔试题目
测试人员考试试卷（考试时间90分钟，满分100分） 一、判断题（每题1分，12 分，正确的√，错误的╳） 1．软件测试的目的是尽可能多的找出软件的缺陷。（√） 软件测试的目的就是为了发现软件中的缺陷，从这个意义上面说上面的这个论断是正确的。不少人会认为软件测试可以保证软件的质量，其实这个观点是错误，测试只是软件质量控制中的一个角色，其活动并不能达成软件质量保证的效果。所以不要认为一个公司里面如果有了软件测试人员，产品的质量就会好起来。 2．Beta 测试是验收测试的一种。（╳） Beat测试和验收测试是两种不同的测试。验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标，该类测试的不是以发现缺陷为主要目的。beta测试是一模拟真实的使用环境从而发现缺陷的一种测试。所以两者之间的是非包容关系。 3．验收测试是由最终用户来实施的。（╳） 上面说到了验收测试的目的和目标，所以验收测试也可是是软件生产的企业内部人员来实施。例如产品经理。当软件以项目的形式出现，那么验收测试由最终用户来实施的情况是比较长见的。但是对于产品形式的软件，生产企业内部的验收测试会更多。 4．项目立项前测试人员不需要提交任何工件。（） 应该说这道题目没有明确的答案，在项目立项前测试人员是不是要把一些准备工作以工件的形式给记录下来是完全取决于该企业的软件开发过程的要求。同时不同企业，立项前要达成的一些必要条件也是大相径庭的。应该说这一题目出的不是很好，如果你是出题人这家企业的测试工程师，那么就应该有一个明确的答案。 5．单元测试能发现约80%的软件缺陷。（） 同样这一题目也没有标准答案。因为该数据的来源和其统计的方法，样本都没有一个工业标准。这样出来的数据同样不具有权威性。这里我可以说一个简单的例子，在用ASP,php这类脚本语言开发网页的时候是根本没有复杂的单元测试。那么这样的数字应用在网站开发上面是否有意义，还是值得商榷的。所以这道题目出的不好，没有明确的答案 6．代码评审是检查源代码是否达到模块设计的要求。（） 代码审查是一种静态技术，从这个意义上说代码复查是需要和其他的一些动态测试技术配合才能检查代码是否符合设计的要求 7．自底向上集成需要测试员编写驱动程序。（） 这道题目大家看下top-down 和 down-top的集成测试示意图就能得出明确的答案。这里需要了解的是什么是驱动测试程序，什么是桩程序。如果集成组件数量众多，多关系层次，那么不论是什么类型的集成测试。驱动程序和桩程序都是需要开发的。 8．负载测试是验证要检验的系统的能力最高能达到什么程度。（） 9．测试人员要坚持原则，缺陷未修复完坚决不予通过。（） 10．代码评审员一般由测试员担任。（x） 如果测试员有这个水平，那么当然是可以参加的。不过大多数的企业不会让普通的测试人员参与代码的评审。 11．我们可以认为的使得软件不存在配置问题。（x） 首先大家先搞清楚什么是配置管理什么是软件配置，从这道题目中看不出出题人想问的是关键工程中的配置管理还是单纯的软件配置。但是可以肯定的是不论是何种情况，答案均是否定的。
软件测试规范
测试工作规范版本记录： 文件状态：[√] 草稿[ ] 正式发布[ ] 正在修改当前版本：1.1 作者：** 完成日期：2004-9-15签收人： 签收日期： 1编写目的 本文档是测试团队的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作。测试技术和策略等问题不在本文档描述范围内。 2测试团队构成 2.1职责 测试是软件开发过程中的重要组成部分，肩负着如下责任： 在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。 编写合理的测试计划，并与项目整体计划有机地整合在一起。
编写覆盖率高的测试用例。 针对测试需求进行相关测试技术的研究。 认真仔细地实施测试工作，并提交测试报告供项目组参考。 进行缺陷跟踪与分析。 2.2角色划分 在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。角色名称相关主要责任 测试经理组建测试组 协调测试组内部的沟通 代表测试组与其他角色组进行沟通编写测试计划 测试报告分析 测试用例设计工程师编写测试用例{可以由测试经理兼任}测试实施工程师实施测试用例，执行测试 技术支持工程师为测试工作提供技术支持 3工作流程及规范
3.1计划与设计阶段 在项目组成立的同时，测试组也将同时成立。团队成立的工作与责任如下：
图表 2
划。测试计划中应该至少包括以下关键内容： 测试需求——需要测试组测试的范围，估算出测试所花费的人力资源和各个测试需求的测试优先级 测试方案——整体测试的测试方法和每个测试需求的测试方法 测试资源——本次测试所需要用到的人力、硬件、软件、技术的资源 测试组角色——明确测试组内各个成员的角色和相关责任 里程碑——明确标准项目过程中测试组应该关注的里程碑 可交付工件——在测试组的工作中必须向项目组提交的产物，包括测试计划、测试报告等等 风险管理——列举出测试工作所可能出现的风险 测试计划编写完毕后，必须提交给项目组全体成员，并由项目组组中各个角色组联合评审。 测试计划由项目组评审通过. 在项目开发过程中，要适时的对测试计划进行跟踪，以评估此计划的完整性、可行性，在项目结束时还要最后
软件测试工作流程()
软件开发与测试配合 工作流程 XXX软件股份有限公司质量部 目录 1．简介 本流程文件旨在规定一个简单的可使开发人员和测试人员在软件开发的编码阶段相互配合工作的工作流程，其中包括测试与开发的配合、送测单和BUG单的填写、测试循环的结束等部分。开发阶段与测试循环的关系、测试模块的组合与测试原则、BUG的分类评级原则等也在本流程文件中有相关的描述。 鉴于公司的技术要求，目前质量部的测试人员不仅要完成黑盒测试工作，而且还要进行白盒测试中的“代码走查”工作。其它的白盒测试工作，目前还不在测试人员的工作职责之内。 由于公司已经为质量管理部开发完成“辅助测试系统1.0”，因此本测试流程的制定就建立在辅助测试系统之上，如果辅助测试系统有了新的版本，质量部将根据其变化适当调整测试流程。 2．适用范围 本流程文件适用于公司开发软件并需要测试服务的任何软件开发项目组、软件开发人员，以及任何测试人员。
当项目组在辅助测试系统中注册以后，公司领导可以使用本系统查询了解所有在本系统中注册的项目的测试信息，项目的质量管理员可以使用本系统查询了解项目的当前测试进展情况。程序员和测试员都可以使用本系统查询到自己产生的送测单和BUG单。 3．术语、名词定义 3.1 送测软件 送测软件包括一切软件执行必须的文件、数据、数据库配置等。开发人员必须提供所有的详细的资料以保证测试人员可以像客户一样的运行被测软件。 3.2 开发文档 开发人员提供给测试人员的开发文档至少包括以下几种：用户需求，概要设计，详细设计，用户手册等。开发人员应当在开发每阶段完成后三天内就向测试人员传送本阶段完成的开发文档，以利于测试人员的工作。 3.3 测试文档 测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护，也属于开发文档的一部分。
软件测试基本流程与要求要求规范
软件测试基本流程与规范 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试 --测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。
软件测试技术-软件测试管理试题
软件测试技术-软件测试管理试题
第三章软件测试管理 简答题 1.你是如何理解测试的层次和主要的管理活 动？ 在软件测试的管理中，以下内容的定义反映测试工作的组织策略： a、软件测试遵循的标准； b、软件测试的工作范畴； c、软件测试环境； d、软件测试产品； e、适用于软件测试活动的软件资源标识规则； f、软件测试的进度安排。 软件测试遵循的标准 组织者在指定范围内选择软件测试遵循的标准，并结合本软件系统的具体要求，使之贯彻到整个软件测试的计划、实现和管理过程之中。根据标准，需要被明确的内容包括：测试阶段和测试文档类型。 可以从三个角度来划分测试阶段：面向测试操作类型的阶段划分、面向测试操作对象的阶段划分、面向测试实施者的阶段划分。测试操作类型包括：调试、集成、确认、验证、组装、验收、操作等。测试操作对象可以是：单元、部件、配置项、子系统、系统等。测试实施者可以是：开发者、测试者、使用者、验收者等。各类标准从不同角度定义测试评审阶段，而测试组织者可以在符合所选标准的同时，结合多个划分因素规定本系统的测试阶段。
各标准规定的测试文档类型也不尽相同。如国标《软件产品开发文件编制指南》规定了两类测试文档：测试计划、测试分析报告；国标《计算机软件测试文件编制规范》定义了八类测试文档：测试计划、测试设计说明、测试用例说明、测试规程说明、测试项传递报告、测试日志、测试事件报告、测试总结报告；《XXXX软件工程化技术文件》定义了三类测试文档：测试计划、测试说明、测试报告。我们认为最后这种规定较易操作：因为，太少的测试文档类型不利于有步骤有层次地定义测试内容，也不利于测试用例和测试例程的良好表达；太多的测试文档类型易使测试组织陷入到繁杂的文档规范和编制中去；而第三种定义较为适中。其中：测试计划在系统分析/设计阶段提交，着重定义测试的资源、范围、内容、安排、通过准则等；测试说明在测试计划明确后开始编制，针对软件需求和设计要求具体定义测试用例和测试规程；测试报告分析和总结测试结果，测试日志是其必要附件。 2.在实际项目中，如何对软件测试进行有效管 理？ 我们的项目的生命周期大致分为以下几个阶段：需求阶段、设计阶段、编码阶段、系统测试阶段和客户测试阶段，规定各阶段的流程并指定责任人。按照规程和项目实际情况确定个项目的里程碑，设置多个检验点，由QA监督个检验点评审过程。 通过CMM2的六个关键域职称项目管理以CMM为目标和支撑进行项目的管理。在国内软件开发行业一片混乱中，决定走国际化的标准轨
软件系统测试规范
上海兴汉科技公司软件测试规范
目录
一.概述 本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范，以有效保证软件产品的质量。
1.什么是软件测试 无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。我们力求在每个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；但是，经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终日的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。 2.软件测试的目标 下面这些规则也可以看作是测试的目标或定义： (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功的测试是发现了至今为止尚未发现的错误的测试。 从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。 由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外，应该认识到测试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。
软件测试题与答案
软件测试中期测试答案 判断题(10分) 软件测试只能发现错误，但不能保证测试后的软件没有错误。（√） 软件测试就是为了验证软件功能实现的是否正确，是否完成既定目标的活动，所以软件测试在软件工程的后期才开始具体的工作。（×） 测试人员说：“没有可运行的程序，我无法进行测试工作”。（×） 单元测试通常应该先进行“人工走查”，再以白盒法为主，辅以黑盒进行动态测试。（√）功能测试属于白盒测试的技术范畴。（×） 黑盒测试的测试用例是根据程序内部逻辑设计的。（×） 白盒测试仅与程序的内部结构有关，完全可以不考虑程序的功能要求。(√) 集成测试也叫做组装测试，通常在编码完成的基础上，将所有的程序模块进行有序的、递增的测试( ×) 第三方测试是在开发方与用户方的测试基础上进行的验证测试( ×) 验收测试是由最终用户来实施的。（×） 多项选择题（5分） 从是否需要执行被测软件的角度，软件测试技术可划分的类型是：（AC ）。 A、静态测试 B、黑盒测试 C、动态测试 D、白盒测试 下面选项中可能导致软件缺陷的原因有（ABD ）。 A、软件需求说明书编写的不全面，不完整，不准确，而且经常更改 B、软件设计说明书编写不准确 C、软件使用人员的水平 D、开发人员不能很好的理解需求说明书和沟通不足 IIS提供的服务有（ABCD ） A. FTP B. WWW C. SMTP D. NNTP VSS是一款配置管理工具，它提供了完善的版本和配置管理功能，VSS中我们处理的所有文档都称为文件，VSS对文件的常用操作有（ABC ） A. check out B. check in C. undo check out D. copy 典型的瀑布模型的四个阶段是：（BCDE） A、需求调研 B、分析 C、设计 D、编码 E、测试 F、实施 单项选择题（15分） 单元测试主要针对模块的几个基本特征进行测试，该阶段不能完成的测试是（ A ）。 A. 系统功能 B. 局部数据结构 C. 重要的执行路径 D. 错误处理 以下关于需求测试的描述中，不正确的是（D ） 需求测试是要检测需求规格说明书中设计的软件需求是否符合用户的要求。 需求测试只是验证需求是否真的是用户所需要的。 需求测试不等同于后面阶段的集成测试或系统测试。 需求测试是需求测试人员来执行的，与用户无关。 对程序的测试最好由由来做，对程序的调试最好由来做。（ B ） A.程序员第三方测试机构 B.第三方测试机构程序员
软件测试与软件开发是什么关系
软件测试与软件开发是什么关系？ 我来说两句(0) 复制链接 打印 大中小 软件测试工程师：查找bug、管理bug、质量保证 软件开发工程师：系统设计、编码、修改bug 薪水收入对比： 软件开发：跨度非常大，1000-4、5万/月不等 软件测试：薪资稳定，一般为2000-6000/月 职业年限长度： 软件开发：3-5年 软件测试：有可能做到退休(如果你自己希望的话) 职业发展比较： 软件开发：做了3-5年开发后，仍未升为项目经理，考虑转行 软件测试：随着项目经验的增加及对行业背景了解的加深，越老越吃香测试工程师与开发工程师目标一致、行为对立、并行工作，有生产就必然有质检，二者的工作相辅相成，开发人员和测试人员的主要矛盾就集中在对bug的定义上。测试人员辛辛苦苦发现软件中有问题，报了一个bug。这时就会出现两种状况。第一种，开发人员工作很忙，压力很大，外加心情不好，就会说出 如下几类话： a.你会不会用软件呀？ b.你使用了最bt的方法发现了用户永远也不可能发现的问题 c.由于我使用了XXX技术，YYY方法和受到了ZZZ的约束，所以只能出现这样的问题，所以就不是 bug d.上次都说过了，是你们测试的问题，先保证测试用例的正确性再来测试 而如果开发人员比较闲，也许会仔细斟酌一下，做出下列答复： e.这确实是个问题。但是是由于我的一个小小的疏忽所致，也不至于报的这么严重吧？ f.老兄，老板们急着要release，我看我们就。。。 也许大家还会碰到别的情况，但是我们测试人员和开发人员总在和这些bug打转，相互打口水丈，所 以关系就一直很紧张。 大家也许要问如何解决紧张的关系，我想到了几个方面，也欢迎大家补充。 首先我要为测试人员说说好话，因为我们通常被认为是最不重要的一群人。 1）开发人员通常把软件看成是程序，他们这种认识上的误区会排斥程序以外的其它因素，例如相关的 文档。 2）开发人员通常把软件的质量等同于软件功能性方面的质量。ISO/IEC9126标准中定义了6大质量特性，我们做测试的人员不应该让开发人员钻其它五项的空子。 3）测试人员通常关注的软件的行为，也就是外在表现，是对外部质量的评价。而开发人员通常是关注软件的实现细节，也就是内部构成，即内部质量。外部质量和内部质量是不等价的，也就是说开发人员犯的错误会引入缺陷，而缺陷在特定的使用下才会产生失效。所以我们应该统一和测试人员关于bug的理解 和认识，避免分歧的不断涌现。