-
2009年软考软件评测师考试大纲
2009-02-25 10:11:46
-
cmmi_3级软件过程改进方法与规范
2009-02-25 09:16:13
-
QA的工作职责
2009-02-24 15:58:13
质量保证工程师（QA）岗位职责
一、工作摘要
负责所分配项目质量保证计划的制订、项目开发过程中的质量保证的审计、组织阶段评审（含技术评审，决策评审，里程碑评审）、项目风险识别、预警。研发流程的执行监督、反馈、数据收集。运用规范的流程引导项目全员参与。对不符合项进行报告/追踪解决。负责度量数据的收集、文档维护、培训支持等。
二、工作职责
No.
类别
职 务
责 任
1
项目质量保证
制订具体项目的质量保证计划及执行
Ø 根据公司质量目标及项目实际情况，制订项目的质量保证计划，计划应当明确定义开发各阶段的质量保证活动和项目质量目标；严格执行质量保证计划。
Ø 依据质量保证计划审计项目是否按照过程要求执行了相应活动，是否按照过程要求产生了相应工作产品，并对工作成果的合理性进行审计；并按时提交项目的质量报告。
Ø 对不符合项有权发出不符合问题报告，并要求项目组分析原因采取措施预防再次发生，同时跟踪直到验证解决。
2
评审
评审的组织
Ø 根据项目计划，适时组织项目阶段评审（含技术评审，决策评审，里程碑评审）；
Ø 审核评审材料的正确性、前后关联性、规范性；
Ø 评审结果形成报告，提交相关领导审核，OA上提交；
Ø 跟踪直至所有评审中发现的缺陷已被关闭；
3
风险控制
项目风险识别、预警
Ø 识别项目风险，组织进行风险等级评估以及可能会对项目的影响，督促项目经理采取风险预防措施；
Ø 督促项目经理更新项目进度计划，使其包含与所采用的风险措施；
Ø 监督项目风险预防或缓解措施的执行；
Ø 定期对已识别的项目风险组织重新评估以确定风险状态是否已发生变化。
4
度量数据
参与项目考核和产品效益考核
Ø 根据考核制度收集项目过程绩效数据，并对项目奖考核、产品效益奖考核提供考核数据，形成记录；
Ø 按项目类型，逐步建立不同类型项目的过程能力基准数据（进度计划达成率，生产率、工作量分布等）；
Ø 分析过程能力基准数据的变化，度量过程改进实际效果
5
研发流程
研发流程的执行监督、反馈、数据收集
Ø 研发流程，发现存在的问题并及时反馈，识别流程优化的机会点并提出可行的优化解决方案；
Ø 搜集项目组反馈，不断根据公司发展改进优化现有流程。
Ø 定期向流程组提供项目中流程执行情况及有关数据；
6
质量事故
负责产品研发质量事故的原因调查
Ø 对于研发过程中，因人为因素造成产品出现严重质量事故，由QA进行跟踪调查，分析其根本原因，并向组织通报质量事故。QA在下次执行同类项目时，及早提醒项目经理采取预防措施。
7
文档维护
项目文档维护管理
Ø 妥善存放项目开发过程中的管理文档；
Ø 阶段评审通过的项目资料提交配置管理工程师入基线库；
Ø 项目验收后的纸质开发文档列文档清单后提交文控中心存档；
8
培训支持
相关培训支持
Ø 对外提供项目管理、质量保证、项目管理工具方面的培训
-
质量体系建立的步骤
2009-02-24 14:44:57
建立、完善质量体系一般要经历质量体系的策划与设计，质量体系文件的编制、质量体系的试运行，质量体系审核和评审四个阶段，每个阶段又可分为若干具体步骤。一、质量体系的策划与设计
该阶段主要是做好各种准备工作，包括教育培训，统一认识，组织落实，拟定计划；确定质量方针，制订质量目标；现状调查和分析；调整组织结构，配备资源等方面。
（一）教育培训，统一认识
质量体系建立和完善的过程，是始于教育，终于教育的过程，也是提高认识和统一认识的过程，教育培训要分层次，循序渐进地进行。
第一层次为决策层，包括党、政、技（术）领导。主要培训：
1.通过介绍质量管理和质量保证的发展和本单位的经验教训，说明建立、完善质量体系的迫切性和重要性；
2.通过ISO9000族标准的总体介绍，提高按国家（国际）标准建立质量体系的认识。
3.通过质量体系要素讲解（重点应讲解“管理职责”等总体要素），明确决策层领导在质量体系建设中的关键地位和主导作用。
第二层次为管理层，重点是管理、技术和生产部门的负责人，以及与建立质量体系有关的工作人员。
这二层次的人员是建设、完善质量体系的骨干力量，起着承上启下的作用，要使他们全面接受ISO9000族标准有关内容的培训，在方法上可采取讲解与研讨结合，理论与实际结合。
第三层次为执行层，即与产品质量形成全过程有关的作业人员。对这一层次人员主要培训与本岗位质量活动有关的内容，包括在质量活动中应承担的任务，完成任务应赋予的权限，以及造成质量过失应承担的责任等。
（二）组织落实，拟定计划
尽管质量体系建设涉及到一个组织的所有部门和全体职工，但对多数单位来说，成立一个精干的工作班子可能是需要的，根据一些单位的做法，这个班子也可分三个层次。
第一层次：成立以最高管理者（厂长、总经理等）为组长，质量主管领导为副组长的质量本系建设领导小组（或委员会）。其主要任务包括：
1.体系建设的总体规划；
2.制订质量方针和目标；
3.按职能部门进行质量职能的分解。
第二层次，成立由各职能部门领导（或代表）参加的工作班子。这个工作班子一般由质量部门和计划部门的领导共同牵头，其主要任务是按照体系建设的总体规划具体组织实施。
第三层次：成立要素工作小组。根据各职能部门的分工明确质量体系要素的责任单位，例如，“设计控制”一般应由设计部门负责，“采购”要素由物资采购部门负责。
组织和责任落实后，按不同层次分别制定工作计划，在制定工作计划时应注意：
1.目标要明确。要完成什么任务，要解决哪些主要问题，要达到什么目的？
2.要控制进程。建立质量体系的主要阶段要规定完成任务的时间表、主要负责人和参与人员、以及他们的职责分工及相互协作关系。
3.要突出重点。重点主要是体系中的薄弱环节及关键的少数。这少数可能是某个或某几个要素，也可能是要素中的一些活动。
[NextPage]
（三）确定质量方针，制定质量目标
质量方针体现了一个组织对质量的追求，对顾客的承诺，是职工质量行为的准则和质量工作的方向。
制定质量方针的要求是：
1.与总方针相协调；
2.应包含质量目标；
3.结合组织的特点；
4.确保各级人员都能理解和坚持执行。
（四）现状调查和分析
现状调查和分析的目的是为了合理地选择体系要素，内容包括：
1.体系情况分析。即分析本组织的质量体系情况，以便根据所处的质量体系情况选择质量体系要素的要求。
2.产品特点分析。即分析产品的技术密集程度、使用对象、产品安全特性等，以确定要素的采用程度。
3.组织结构分析。组织的管理机构设置是否适应质量体系的需要。应建立与质量体系相适应的组织结构并确立各机构间隶属关系、联系方法。
4.生产设备和检测设备能否适应质量体系的有关要求。
5.技术、管理和操作人员的组成、结构及水平状况的分析。
6.管理基础工作情况分析。即标准化、计量、质量责任制、质量教育和质量信息等工作的分析。
对以上内容可采取与标准中规定的质量体系要素要求进行对比性分析。
（五）调整组织结构，配备资源
因为在一个组织中除质量管理外，还有其他各种管理。组织机构设置由于历史沿革多数并不是按质量形成客观规律来设置相应的职能部门的，所以在完成落实质量体系要素并展开成对应的质量活动以后，必须将活动中相应的工作职责和权限分配到各职能部门。一方面是客观展开的质量活动，一方面是人为的现有的职能部门，两者之间的关系处理，一般地讲，一个质量职能部门可以负责或参与多个质量活动，但不要让一项质量活动由多个职能部门来负责。目前我国企业现有职能部门对质量管理活动所承担的职责、所起的作用普遍不够理想总的来说应该加强。
在活动展开的过程中，必须涉及相应的硬件、软件和人员配备，根据需要应进行适当的调配和充实。
二、质量体系文件的编制
质量体系文件的编制内容和要求，从质量体系的建设角度讲，应强调几个问题：
1.体系文件一般应在第一阶段工作完成后才正式制订，必要时也可交叉进行。如果前期工作不做，直接编制体系文件就容易产生系统性、整体性不强，以及脱离实际等弊病。
2.除质量手册需统一组织制订外，其它体系文件应按分工由归口职能部门分别制订，失提出草案，再组织审核，这样做有利于今后文件的执行。
3.质量体系文件的编制应结合本单位的质量职能分配进行。按所选择的质量体系要，素，逐个展开为各项质量活动（包括直接质量活动和间接质量活动），将质量职能分配落实到各职能部门。质量活动项目和分配可采用矩阵图的形式表述，质量职能矩阵图也可作为附件附于质量手册之后。
4.为了使所编制的质量体系文件做到协调、统一，在编制前应制订“质量体系文件明细表”，将现行的质量手册（如果已编制）、企业标准、规章制度、管理办法以及记录表式收集在一起，与质量体系要素进行比较，从而确定新编、增编或修订质量体系文件项目。
[NextPage]
5.为了提高质量体系文件的编制效率，减少返工，在文件编制过程中要加强文件的层次间、文件与文件间的协调。尽管如此，一套质量好的质量体系文件也要经过自上而下和自下而上的多次反复。
6.编制质量体系文件的关键是讲求实效，不走形式。既要从总体上和原则上满足 ISO9000族标准，又要在方法上和具体做法上符合本单位的实际。三、质量体系的试运行
质量体系文件编制完成后，质量体系将进入试运行阶段。其目的，是通过试运行，考验质量体系文件的有效性和协调性，并对暴露出的问题，采取改进措施和纠正措施，以达到进一步完善质量体系文件的目的。
在质量体系试运行过程中，要重点抓好以下工作：
1.有针对性地宣贯质量体系文件。使全体职工认识到新建立或完善的质量体系是对过去质量体系的变革，是为了向国际标准接轨，要适应这种变革就必须认真学习、贯彻质量体系文件。
2.实践是检验真理的唯一标准。体系文件通过试运行必然会出现一些问题，全体职工立将从实践中出现的问题和改进意见如实反映给有关部门，以便采取纠正措施。
3.将体系试运行中暴露出的问题，如体系设计不周、项目不全等进行协调、改进。
4.强信息管理，不仅是体系试运行本身的需要，也是保证试运行成功的关键。所有与质量活动有关的人员都应按体系文件要求，做好质量信息的收集、分析、传递、反馈、处理和归档等工作。
四、质量体系的审核与评审
质量体系审核在体系建立的初始阶段往往更加重要。在这一阶段，质量体系审核的重点，主要是验证和确认体系文件的适用性和有效性。
1.审核与评审的主要内容一般包括：
（1）规定的质量方针和质量目标是否可行；
（2）体系文件是否覆盖了所有主要质量活动，各文件之间的接口是否清楚；
（3）组织结构能否满足质量体系运行的需要，各部门、各岗位的质量职责是否明确；
（4）质量体系要素的选择是否合理；
（5）规定的质量记录是否能起到见证作用
（6）所有职工是否养成了按体系文件操作或工作的习惯，执行情况如何。
2.该阶段体系审核的特点是：
（1）体系正常运行时的体系审核，重点在符合性，在试运行阶段，通常是将符合性与适用性结合起来进行；
（2）为使问题尽可能地在试运行阶段暴露无遗，除组织审核组进行正式审核外，还应有广大职工的参与，鼓励他们通过试运行的实践，发现和提出问题；（3）在试运行的每一阶段结束后，一般应正式安排一次审核，以便及时对发现的问题进行纠正，对一些重大问题也可根据需要，适时地组织审核；
（4）在试运行中要对所有要素审核覆盖一遍；
（5）充分考虑对产品的保证作用；
（6）在内部审核的基础上，由最高管理者组织一次体系评审。
应当强调，质量体系是在不断改进中行以完善的，质量体系进入正常运行后，仍然要采取内部审核，管理评审等各种手段以使质量体系能够保持和不断完善。
-
测试计划模板
2009-02-24 13:23:40
-
测试用例检查单
2009-02-24 11:51:39
1. 是否涵盖了需求文档上的每个功能点
2. 是否涵盖了需求文档上的每条业务规则说明
3. 是否覆盖了输入条件的各种有意义组合
4. 是否覆盖了业务操作的基本路径和异常路径
5. 是否考虑了重要表单字段的数据合法性检查
6. 是否考虑了其他的测试类型（对某个功能很重要，但未在需求文档中提及的，如安全测试、周期性测试和故障恢复等方面）
7. 是否考虑了对其他模块/功能的影响
8. 是否使用了项目组的标准用例模板
9. 用例是否覆盖了测试设计中定义的所有场景
10.用例编号是否统一、规范
11.用例名称是否简洁、明了
12.目的字段是否准确地描述了对应场景的测试输入的特征（不同数据，操作，配置等）
13.前提条件字段的条目是否充分、准确，操作上是否不依赖于同组之外的其他用例
14.对应的需求编号字段是否填写正确
15.用例粒度、预估出的执行时间是否适当
16.同组用例中，仅数据不同的，是否实现了测试步骤的重用
17.某个功能点的第一个用例是否是基本流的
18.操作步骤的描述，是否清晰、易懂
19.操作步骤是否充分和必要，并具有可操作性
20.测试用例的检查点是否明确、充分和可操作
21.单个用例步骤或检查点中是否不再存在分支
22.测试数据的特征描述是否准确，有条件的情况下，是否给出了一个当前环境下的可用参考值
23.文字、语法是否准确；布局、格式是否统一
-
安全测试的检查点
2009-02-24 11:05:29
. 不登录系统，直接输入登录后的页面的url是否可以访问2. 不登录系统，直接输入下载文件的url是否可以下载，如输入http://url/download?name=file是否可以下载文件file
3. 退出登录后按后退按钮能否访问之前的页面
4. ID/密码验证方式中能否使用简单密码。如密码标准为6位以上，字母和数字混合，不能包含ID，连续的字母或数字不能超过n位
5. 重要信息（如密码，身份证号码，信用卡号等）在输入或查询时是否用明文显示；在浏览器地址栏里输入命令javascrīpt:alert(doucument.cookie)时是否有重要信息；在html源码中能否看到重要信息
6. 手动更改URL中的参数值能否访问没有权限访问的页面。如普通用户对应的url中的参数为l=e，高级用户对应的url中的参数为l=s，以普通用户的身份登录系统后将url中的参数e改为s来访问本没有权限访问的页面
7. url里不可修改的参数是否可以被修改
8. 上传与服务器端语言（jsp、asp、php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行
9. 注册用户时是否可以以'--,' or 1=1 --等做为用户名
10. 传送给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符（','and 1=1 --,' and 1=0 --,'or 1=0 --）时是否可以正常处理
11. 执行新增操作时，在所有的输入框中输入脚本标签（<scrīpt>alert("")</scrīpt>）后能否保存
12. 在url中输入下面的地址是否可以下载：http://url/download.jsp?file=C:\windows\system32\drivers\etc\hosts,http://url/download.jsp?file=/etc/passwd
13. 是否对session的有效期进行处理
14. 错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等
15. ID/密码验证方式中，同一个账号在不同的机器上不能同时登录
16. ID/密码验证方式中，连续数次输入错误密码后该账户是否被锁定
17. 新增或修改重要信息（密码、身份证号码、信用卡号等）时是否有自动完成功能（在form标签中使用autocomplete=off来关闭自动完成功能）
-
性能测试的要点
2009-02-24 11:02:05
1、明确用户的性能需求（显示的和隐式的），性能测试点，找出瓶颈1）用户直接需求的和使用过程中（行业经验）可能遇到的性能瓶颈点必须测试和分析到。当然，客户不需要的，也没有必要去花时间和精力。
2）从中获取相应的性能测试参数，峰值和平均值。
3）客户的性能容忍度和系统所能承受的容忍度同样重要。
4）确认系统运行的最低硬件环境要求（虽然硬件便宜的多了，但客户能不能改造自己的环境还得客户说了算）
5）如果可以的话，将系统的容错性做为性能测试的一部分进行测试
2、测试对象和性能负载分布
1）基本的3个对对像：C/S、B/S中的客户端和服务器，其中还有网络进行连接或中间件。
2）服务端可能分为数据端、业务端和服务容器。
3）跟据实际的测试结果合理的进行相应的性能负载分布。
3、负载、容量和压力测试逐一进行（如果需要）
1）更多的情况下，性能测试中出现的问题是最初的设计时应存在的问题。如果可能，建议对相应的性能提前做测试和优化。
2）够用就好，不是所有的系统都要进行性能测试，一切以客户需求和实际需要为准。
4、测试点
1）CPU和内存使用（系统自身的原因）。是否可以正常的使用和释放，是否存在内存溢出。
2）访问的速度（客户需求或是实际的应用要求说了算）
3）网络。网络传输速度，网络传输丢包率。（找些工具，有免费的）
4）服务器。指令、服务应答响应时间，服务器对信息处理的时效性，服务器对峰值的处理（建议进行服务器优化或是进行服务负载均衡，有大量的文档对此进行描述）
5）中间件。中间件在信息传递中的处理性能及信息处理的正确性。
5、测试和监控数据
1）均值下的持续运行（通过分析对整体的性能进行预测和评估）
2）短时间的峰值运行（分析系统的处理能力）
3）最低配置和最佳配置下的性能对比
4）多用户。同时访问，同时提交。
5）对 4 中的数据进行记录和监控
6、选择测试工具
现有的测试工具太多了，不在一一列举。
适用就好，推荐开源的工具。
-
搜索引擎测试要点
2009-02-24 10:59:49
包括关键字搜索.完全匹配.有效字符.无效字符等1,空内容点击搜索，看其有没有LINK
2,输入过长查询数据，看其有没判断，报错
3,输入各种符号，特别是空格，看其能否正确判断
4,输入各种字符，譬如输入范围是0~9，A~Z的看输入中文是什么效果
5,输入正确数据，看其的查询后数据的完整性
6,注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方
7,在输入结束后直接按回车键,看系统处理如何,会否报错
8,反复输入相同的数据（5次以上）看是否报错
9,各国文字/字符的输入/粘贴能正确显示 退格键等操作显示正常 超过支持的最大长度有相应的提示 混合的多种语言也能正确显示
10,显示&接收；能进行下一步处理
11,其他的 包括能删除 能剪切等（我也不确定要不要包括 有点奇怪 显示语言是字符库支持的问题 而且如果是面向对象程序设计语言做的文本框 删除什么的功能也不用测对被测试点进行分解，把测试用例分解为多个测试场景
场景编号 场景描述 预期结果 场景一 页面检查 正确 场景二 默认条件搜索 查询结果正确 场景三 修改可选条件搜索 查询结果正确 场景四 修改输入条件搜索 查询结果正确 场景五 修改区间条件搜索 查询结果正确 场景六 组合可选、输入条件搜索 查询结果正确 场景七 操作后检查搜索条件及查询结果 查询结果正确 场景八 错误、空记录搜索 查询结果为空 测试步骤描述
按照已经分解的测试场景顺序，逐个描述测试场景的测试步骤
测试场景一：
步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 界面共性测试 3 退出 测试场景二：
步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 点击“搜索”按钮，显示查询结果列表 3 检查查询结果列表，每页显示记录条数正确、文字折行显示正确、页面布局美观 4 检查查询结果列表，列标题项、列显示内容、排序方式符合需求定义 5 检查查询结果列表，符合默认查询条件结果集 6 点击查询结果列表链接、复选框、全选框响应正确 7 退出 测试场景三：
步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 逐一选择各个查询条件可选项，如：“全部”、“类别1”等，点击“搜索”，查询结果正确 3 组合各个查询条件可选项，如：价格＋产品，点击“搜索”，查询结果正确 4 退出 测试场景四：
步骤编号 具体描述 1 进入搜索（高级搜索）页面 2 逐一输入文本域条件，模糊查询值，点击“搜索”，查询结果正确 3 逐一输入文本域条件，完全匹配值，点击“搜索”，查询结果正确 4 逐一输入文本域条件，中文值，点击“搜索”，查询结果正确 5 逐一输入文本域条件，字母大、小写值，点击“搜索”，查询结果正确 6 逐一输入文本域条件，数字类型值，点击“搜索”，查询结果正确 7 逐一输入文本域条件，全角、半角值，点击“搜索”，查询结果正确 8 组合各个文本域查询条件，点击“搜索”，查询结果正确 9 退出 -
功能测试要点
2009-02-24 10:56:33
1.页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。可以使用一些工具，如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码；HTML Link Validater只能测试以Html或者htm结尾的网页链接；Xenu无需安装，支持asp、do、jsp等结尾的网页，xenu测试链接包括内部链接和外部链接，在使用的时候应该注意，同时能够生成html格式的测试报告。如果系统用QTP进行自动化测试，也可以使用QTP的页面检查点检查链接。2.相关性检查：
Ø 功能相关性：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确，常见的情况是，增加某个数据记录以后，如果该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形。
Ø 数据相关性：下来列表默认值检查，下来列表值检查，如果某个列表的数据项依赖于其他模块中的数据，同样需要检查，比如，某个数据如果被禁用了，可能在引用该数据项的列表中不可见。
3.检查按钮的功能是否正确：如新建、编辑、删除、关闭、返回、保存、导入，上一页，下一页，页面跳转，重置等功能是否正确。常见的错误会出现在重置按钮上，表现为功能失效。
4.字符串长度检查:输入超出需求所说明的字符串长度的内容,看系统是否检查字符串长度。还要检查需求规定的字符串长度是否是正确的，有时候会出现，需求规定的字符串长度太短而无法输入业务数据。
5.字符类型检查:在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。
6.标点符号检查:输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格当作一个字符，而在查询的时候空格被屏蔽，导致无法查询到添加的内容。
7．特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。常见的错误是出现在% ‘ \这几个特殊字符
8.中文字符处理:在可以输入中、英文的系统输入中文,看会否出现乱码或出错。
9.检查信息的完整性:在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。要注意检查的时候每个字段都应该检查，有时候，会出现部分字段更新了而个别字段没有更新的情况。
10.信息重复:在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。
11.检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。如果有多页，翻页选，看系统是否都正确删除，并且要注意，删除的时候是否有提示，让用户能够更正错误，不误删除。
12.检查添加和修改是否一致:检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
13.检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
14.重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否做了处理。对于Web系统来说，可以通过浏览器返回键或者系统提供的返回功能。
15.检查多次使用返回键的情况:在有返回键的地方,返回到原来页面,重复多次，看会否出错。
16.搜索检查:有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确，搜索的时候同样要注意特殊字符，某些系统会在输入特殊字符的时候，将系统中所有的信息都搜索到。
17.输入信息位置:注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。
18.上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。下载文件能否打开或者保存，下载的文件是否有格式要求，如需要特殊工具才可以打开等。上传文件测试同时应该测试，如果将不能上传的文件后缀名修改为可以上传文件的后缀名，看是否能够上传成功，并且，上传文件后，重新修改，看上传的文件是否存在。
19.必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加“*”；对必填项提示返回后，焦点是否会自动定位到必填项。
20.快捷键检查：是否支持常用快捷键，如Ctrl+C、Ctrl+V、Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
21.回车键检查:在输入结束后直接按回车键,看系统处理如何,会否报错。这个地方很有可能会出现错误。
22．刷新键检查：在Web系统中，使用浏览器的刷新键，看系统处理如何，会否报错。
23．回退键检查：在Web系统中，使用浏览器的回退键，看系统处理如何，会否报错。对于需要用户验证的系统，在退出登录后，使用回退键，看系统处理如何；多次使用回退键，多次使用前进键，看系统如何处理。
24．直接URL链接检查：在Web系统中，直接输入各功能页面的URL地址，看系统如何处理，对于需要用户验证的系统更为重要。如果系统安全性设计的不好，直接输入各功能页面的URL地址，很有可能会正常打开页面。
25．空格检查：在输入信息项中，输入一个或连串空格，查看系统如何处理。如对于要求输入整型、符点型变量的项中，输入空格，既不是空值，又不是标准输入。
26．输入法半角全角检查：在输入信息项中，输入半角或全角的信息，查看系统如何处理。如对于要求输入符点型数据的项中，输入全角的小数点（“。”或“．”，如４．５）；输入全角的空格等。
27．密码检查：一些系统的加密方法采用对字符Ascii码移位的方式，处理密码加密相对较为简单，且安全性较高，对于局域网系统来说，此种方式完全可以起到加密的作用，但同时，会造成一些问题，即大于128的Ascii对应的字符在解密时无法解析，尝试使用“uvwxyz”等一些码值较大的字符作为密码，同时，密码尽可能的长，如17位密码等，造成加密后的密码出现无法解析的字符。
28．用户检查：任何一个系统，都有各类不同的用户，同样具有一个或多个管理员用户，检查各个管理员之间是否可以相互管理，编辑、删除管理员用户。同时，对于一般用户，尝试删除，并重建同名的用户，检查该用户其它信息是否重现。同样，提供注销功能的系统，此用户再次注册时，是否作为一个新的用户。而且还要检查该用户的有效日期，过了有效日期的用户是不能登录系统的。容易出现错误的情况是，可能有用户管理权限的非超级管理员，能够修改超级管理员的权限。
29．系统数据检查：这是功能测试最重要的，如果系统数据计算不正确，那么功能测试肯定是通不过的。数据检查根据不同的系统，方法不同。对于业务管理平台，数据随业务过程、状态的变化保持正确，不能因为某个过程出现垃圾数据，也不能因为某个过程而丢失数据。
30．系统可恢复性检查：以各种方式把系统搞瘫，测试系统是否可正常迅速恢复。
31．确认提示检查：系统中的更新、删除操作，是否提示用户确认更新或删除，操作是否可以回退（即是否可以选择取消操作），提示信息是否准确。事前或事后提示，对于Update或Delete操作，要求进行事前提示。
32．数据注入检查：数据注入主要是对数据库的注入，通过输入一些特殊的字符，如“’”，“/”，“-”等或字符组合，完成对SQL语句的破坏，造成系统查询、插入、删除操作的SQL因为这些字符而改变原来的意图。如select * from table where id = ‘ ’ and name = ‘ ’，通过在id输入框中输入“
33．刷新检查：web系统中的WebForm控件实时刷新功能，在系统应用中有利有弊，给系统的性能带来较大的影响。测试过程中检测刷新功能对系统或应用造成的影响（白屏），检查控件是否回归默认初始值，检查是否对系统的性能产生较大影响（如每次刷新都连接数据库查询等）。
34．事务检查：对于事务性操作，断开网络或关闭程序来中断操作，事务是否回滚。
35．时间日期检查：时间、日期验证是每个系统都必须的，如2006-2-29、2006-6-31等错误日期，同时，对于管理、财务类系统，每年的1月与前一年的12月（同理，每年的第1季度与前一年的第4季度）。另外，对于日期、时间格式的验证，如
36．多浏览器验证：越来越多的各类浏览器的出现，用户访问Web程序不再单单依赖于Microsoft Internet Explorer，而是有了更多的选择：Maxthon、Firefox、Tencent Traveler等，考虑使用多种浏览器访问系统，验证效果。
37．安装测试：对于C/S架构的系统，安装程序的测试是一个重要方面，安装程序自动化程度、安装选项和设置（验证各种方案是否都能正常安装）、安装过程中断测试、安装顺序测试（分布式系统）、修复安装及卸载测试。
38．文档测试：主要是对用户使用手册、产品手册进行测试，校验是否描述正确、完整，是否与当前系统版本对照，是否易理解，是否二义性等。
39．测试数据检查：事实告诉我们，测试数据比代码更有可能是错的，因此，当测试结果显示有错误发生的时候，怀疑代码错误前要先对测试数据检查一遍。
40．请让我的机器来运行：在某些项目中，出现一个病态的问题：系统没有问题呀，它在我的机器上是能够通过的。这就说明了其中存在着和环境相关的BUG。“是否所有的一切都受到了版本控制工具的管理？”、“本机的开发环境和服务器的环境是否一样？”、“这里是否存在一个真正的BUG，只不过是在其他的机器里偶然出现？”。所有的测试必须在所有系统要求的机器上运行通过，否则的话，代码就可能存在问题。
41．Ajax技术的应用：Ajax有很多优点，但也有很多缺点，如果利用优点、避免缺点，是我们对新的Web2.0应用的一个挑战。而Ajax的应用最直接的问题就是用户体验，用户体验的效果直接关系到是否使用Ajax技术。“会做，并不意味着应该做、必须做”，这就是对Ajax技术的很重要的注解。
42．Ajax技术的应用：Ajax采用异步调用的机制实现页面的部分刷新功能，异步调用存在异常中断的可能，尝试各种方法异常中断异步的数据调用，查看是否出现问题。在这里遇到的一个问题就是对日期控件的操作，已经如果页面数据较多的时候的刷新。
43．脚本错误：随着Ajax、IFrame等异步调用技术的发展，Javascrīpt技术也越来越受到开发人员的重视，但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题，因此在Web系统中，可能会出现脚本错误。同时，脚本错误造成的后果可大、可小，不能忽视。
-
数据库测试点
2009-02-24 10:52:38
包括测试实际数据(内容)以及数据完整性,已经确保数据没有被误用以及规划的正确性,同时也对数据库应用(例如,Sql处理组件)进行功能性测试.通常会用到SqL脚本进行数据库测试.尽管不是所有的数据库都是适合Sql的,但是通过Sql数据库可以支持绝大部分数据操作,大多数的Web应用程序也是如此。通常有两类由数据库错误引发的问题，它们是数据完整性错误以及输出错误。输出错误是在数据提取和操作数据指令过程中发生的错误引起的，这时源数据是正确的。
通常，数据操作包含了以下一些活动：
首次活动（例如安装过程）
1.连邮菘夥衿?2.创建新数据库 3.创建表格、默认值和规则；填入默认数据。 4.编译存储过程和触发器
在成功安装过程完成之后，对数据库的使用由以下活动组成：
1.连接数据库 2.执行Sql语句、存储过程以及触发器 3.释放与数据库的连接
在数据库活动中所包含的错误主要有以下几种常见类型：
1.连接数据库失败，引起该类失败的许多潜在问题包括：
a.非法的用户名、密码或两者皆非法 b.对于某些数据活动，如创建表和存储过程，用户拥有不适当的权限。
c.非法或错误的DSN d.与拥有必要的DSN文件的服务器连接失败
指令（存储过程、触发器等）中常见错误包括：
1.数据库被配置为区分大小写的，但是代码却没有
2.在Sql语句中使用了保留关键字，例如 Select user from mytable。user为保留关键字
3.NULL被传递给不接受NULL的记录字段
4.在字符串字段中对单引号（‘）的错误处理。
5.在整型字段中对逗号（，）的错误处理。
6.数值对于字段大小来说过大，字符串对于字段的长度来说过长。
7.超时---数据库执行完某个过程所用时间长于脚本中所设定的超时值。
8.非法或错误拼写的字段、列、表或者视图的名称，未定义的字段、表或视图的名称，非法或错误拼写的存储过程名称
9.调用错误的存储过程。
10.缺少关键字。
下面为实际例子介绍：
1.缺少关键字的： create view student_view select * from student_tbl。其中语句缺少as关键字
数据库测试
随着软件业的迅猛发展，我们的开发也从以前的单层结构进入了三层架构甚至现在多层架构的设计，而数据库从以前一个默默无闻的后台仓库，逐渐成为了数据库系统，而数据库开发设计人员成为了炙手可热的核心人员。以前我们往往把数据库操作写在应用层，从而提高各个模块的独立性和易用性，而现在越来越多的数据库操作被作为存储过程直接放在数据库上进行执行来提高执行效率和提高安全性。数据库开发既然在软件开发的比重逐步提高，随之而来的问题也突出。我们以前往往重视对代码的测试工作，随着流程技术的日益完善，软件质量得到了大幅度的提高，但数据库方面的测试仍然处于空白。我们从来没有真正将数据库作为一个独立的系统进行测试，而是通过对代码的测试工作间接对数据库进行一定的测试。随着数据库开发的日益升温，数据库测试也需要独立出来进行符合自身特点的测试工作。数据库开发和应用开发并没有实质上的区别，所以软件测试的方法同样适用于数据库测试。
从测试过程的角度来说我们也可以把数据库测试分为：
系统测试
传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证改修改是否落实到数据库上。
这个阶段我们的测试主要通过数据库设计评审来实现。
集成测试
集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说，需要考虑的是：
数据项的修改操作；
数据项的增加操作；
数据项的删除操作；
数据表增加满；
数据表删除空；
删除空表中的记录；
数据表的并发操作；
针对存储过程的接口测试；
结合业务逻辑做关联表的接口测试；
同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试。单元测试侧重于逻辑覆盖，相对对于复杂的代码来说，数据库开发的单元测试相对简单些，可以通过语句覆盖和走读的方式完成系统测试相对来说比较困难，这要求有很高的数据库设计能力和丰富的数据库测试经验。而集成测试和单元测试就相对简单了。
而我们也可以从测试关注点的角度对数据库进行分类：
功能测试
对数据库功能的测试我们可以依赖与工具进行。DBunit
一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验。QTP
大名鼎鼎的自动测试工具，通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒。DataFactory
一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试。数据库性能
虽然我们的硬件最近几年进步很快，但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的，如此庞大的数据量在大量并发连接操作时，我们不能像以前一样随意的使用查询，连接查询，嵌套查询，视图，这些操作如果不当会给系统带来非常巨大的压力，严重影响系统性能。
性能优化分4部分：
1.物理存储方面
2.逻辑设计方面
3.数据库的参数调整
4.SQL语句优化我们如何对性能方面进行测试呢，业界也提供了很多工具。
通过数据库系统的SQL语句分析工具，我们可以分析得到数据库语句执行的瓶颈，从而优化SQL语句。
Loadrunner
这个不用多说，我们可以通过对协议的编程来对数据库做压力测试。Swingbench（这是一个重量级别的feature，类似LR，而且非常强大，只不过专门针对oracle而已）
数据库厂商也意识到这点，例如：
oracle11g已经提供了real application test，提供数据库性能测试，分析系统的应用瓶颈。
还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。
软件日益复杂，而数据又成为了系统中重中之重的核心，从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端。自从SQL 注入攻击被发现，冒失万无一失的数据库一下从后台变为了前台，而一旦数据库被攻破，整个系统也会暴露在黑客的手下，通过数据库强大的存储过程，黑客可以轻松的获得整个系统的权限。而SQL的注入看似简单缺很难防范，对于安全测试来说，如何防范系统被注入是测试的难点。业界也有相关的数据库注入检测工具，来帮助用户对自身系统进行安全检测。
对于这点来说业界也有标准，例如ISO IEC 21827，也叫做SSE CMM 3.0，是CMM和ISO的集成的产物，专门针对系统安全领域的另外一方面，数据库的健壮性，容错性和恢复能力也是我们测试的要点，我们也可以发现功能测试，性能测试，安全测试，是一个由简到繁的过程，也是数据库测试人员需要逐步掌握的技能，这也是以后公司对数据库测试人员的要求
-
界面测试常见bug
2009-02-24 10:46:12
录入界面
1.1 输入字段要完整，且要与列表字段相符合（参照数据库进行检查）
1.2 必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）
1.3 字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息
（1） 长度校验
（2） 数字、字母、日期等等的校验
（3） 范围的校验
1.4 录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示
1.5 下拉框不选值的时候应该提供默认值
1.6 相同字段的录入方式应该统一（手动输入 、点选 、下拉选择、参照）
1.7 录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）
1.8 日期参照应该既能输入，又能从文本框选择
界面格式
2.1 字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性
2.2 文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性
2.3 所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致
2.4 不同界面显示相同字段的一致性（如列表界面和编辑界面）
2.5 界面按钮显示要求（查询、新增、删除顺序）
2.6 列表的顺序排列应该统一（按照某些特定条件排序）
2.7 下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定
2.8 所有弹出窗口居中显示或者最大化显示
2.9 信息列表中如果某个字段显示过长用“…”或者分行显示
2.10 人员、时间的缺省值一般取当前登录人员和时间
2.11 对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”
功能问题
3.1 按钮功能的实现（如返回按钮能否返回）
3.2 信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示
3.3 所有有提交按钮的页面都要有保存按钮（每个界面风格一致）
3.4 凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮
3.5 没有选择记录点击删除/修改按钮要提示“请先选择记录”
3.6 选择记录后点击删除按钮要提示“确实要删除吗？”
3.7 需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容
3.8 界面只读的时候（查询、统计、导入）等，应该不能编辑
查询问题
4.1 查询条件缺少一些可以查询的字段
4.2 有些查询条件需要支持模糊查询
4.3 需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）
4.4 查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一
4.5 不同模块相同字段的查询方式应该统一（手动输入 、点选 、下拉选择）
4.6 出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么
4.7 对于范围的查询采用全闭的形式（如 [2006-1-1,2006-12-30]）
-
编写测试用例方法心得体会
2009-02-24 10:35:05
编写背景：一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。
编写测试用例方法心得体会
在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：
１、一个测试用例要写到什么程度才比较好?
３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？
下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？
这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^
在我测试工作中，碰上的测试类型我自己划分成这么４种：项目的测试，产品的测试，产品个性化的测试，第三方验收测试。项目的测试指的是我所测试的软件是一个项目，是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品，是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时，提出了特殊的功能，针对这些新功能，对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了，这里就不需要做解释了。
对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。
第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？
我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。
现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。
最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^
你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？
我的体会：
１、测试用例要根据测试大纲来编写
２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
４、熟悉系统，对编写测试用例很有帮助。
５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。
-
测试度量的指标
2009-02-24 10:08:35
.1 度量的目的度量活动首要考虑的是目的，测试中的度量一般有如下目的：
a) 判断测试的有效性
b) 判断测试的完整性
c) 判断工作产品的质量
d) 分析和改进测试过程
1.2 度量内容
度量的数据构成一个层次化的体系，就是度量框架。框架的上层是度量指标(Factor)，下层是直接度量(Metrics)。度量指标表示产品或过程的特征，需要从直接度量计算而来。而直接度量是可以直接收集到的数据。下面分别说明系统测试中需要测量的度量内容，注意区分其中的度量指标和直接度量。
a) 计划的测试开始、结束时间
b) 实际的测试开始、结束时间
c) 执行测试用例的时间。
1. 计划投入测试的工作量(人时)
2. 计划投入测试的资金
3. 实际投入测试的工作量(人时)
4. 实际投入测试的资金
5. 评审投入的工作量（人时）6. 缺陷修正成本（提交缺陷、研究缺陷、改正缺陷、验证等所需时间）
7. 累积测试时间。对每一个发布的版本，累积测试时间等于该版本在演变过程中经历的所有测试的测试时间之和。包括完整测试、验证测试和回归测试。
1. 被测对象的规模（功能点、代码行（有效代码行，注释行）等）
2. 系统需求数目3. 测试用例数目（总用例数、计划执行数、实际执行数）
1． 测试覆盖率
a)需求覆盖率： 需求覆盖率=至少被测试用例覆盖一次的需求数/系统总需求数 b)测试用例覆盖率： 测试用例覆盖率=计划执行的测试用例数/测试用例总数 c)测试用例执行率： 测试用例执行率=实际执行的测试用例数/计划执行的测试用例数
d)测试用例通过率：测试用例通过率＝(实际执行的测试用例数-测试执行不通过的测试用例数)/实际执行的测试用例数2． 缺陷检测率对某一版本，某一个环节（阶段）的缺陷检测率＝(A/（A＋B）)*100％。
其中：
A:测试人员查找出的不包括重复缺陷的数量。
B：用户（包括下一环节的部门）报告的不包括重复缺陷的数量。
3． 测试过程能力
单位缺陷开销＝测试投入的工作量（人时）/缺陷总数
1. 版本发布前缺陷数
2. 版本发布后缺陷数
3. 评审发现的缺陷数
4. 缺陷修正率：缺陷修正率＝发布前已修正的缺陷数/发布前已知的缺陷总数。
5. 缺陷密度：千行代码缺陷率＝测试和评审中发现的缺陷数/被测目标的代码的规模（KL）
-
测试过程改进的大致内容
2009-02-24 10:00:24
测试过程改进的大致内容：
1.重视测试软件的需求分析：
在测试过程改进中要特别注意这一点，很多公司的测试人员都不太重视测试需求分析，由于时间紧或测试人员有限，不得不看了一部分需求，就开始编写相应的测试用例，这也不是什么大惊小怪的事了。我建议：首先，了解获取需求的渠道，保证测试需求比较全面准确。
其次，可以罗列出功能测试或业务测试需求点，让用户和项目组成员评审确认，避免测试后期由于时间原因而导致漏测。
2.提高测试计划的可执行性：
很多时候，测试部门测试经理在项目测试初期，编写了一个测试计划以后，后面不管是发生了什么情况，测试计划都不会做相应的调整，这就导致测试计划成了摆设，应付领导检查了事的文档，没有真正发挥测试计划的指导性作用。不知道大家是否有同感。我的做法：把测试计划分成大计划和小计划。先写大计划，后编写小计划。大计划通过估算一旦确定后，基本上改动不大。小计划要跟随项目的测试情况，随时调整或修改，当然这就对“测试经理”预估测试工作量的能力要求比较高。预估不准那就每周改计划吧，呵呵！
3.合理安排测试活动的顺序：不合理的测试顺序，可能会引起务工，测试效率低下。如果不立即采取相应的措施，到后来还会导致测试进度失控。比如说一个项目中，哪些测试活动必须有先后顺序，哪些测试活动能够并行开展，哪些测试活动可以合并，作为测试Leader必须要非常清楚。不明白测试活动的顺序，让测试活动自由发展，何谈测试过程改进？
4.优化测试文档设计： 测试文档的优化，也不是一蹴而就的事情，需要我们不断提高测试文档的编写能力，循序渐进逐步提高。我们尽量保证测试文档的可读写高，任何人都能够看懂，都能够执行，也许这是一个理想化的境界吧，呵呵！！在这个前提下，尽量保证较少的测试用例，覆盖较多的需求内容，可能这一点实施难度比较大。
5.强化测试资源的最优配置：
软件测试是一个非常复杂的过程，需要人力资源、测试设备、测试环境等多个因素密切相关。比如说测试设备配置多少个为最佳？每个模块配置的测试人员的能力水平需要达到什么程度？需要多少个测试人员？等等问题。我们必须给出一个最优的资源配置方案。
6.参与部分开发文档的讨论：
一般情况下，不懂开发的测试人员，很难发现深层次、严重等级较高的缺陷。比如说Web测试，如果你不懂Oracle数据库设计文档，你很难确定页面显示的结果是否是真实的数据。不了解详细设计文档，很多业务流程可能就不会太清晰，这也就是为什么第一轮测试时，测试人员老是去问开发人员的原因？如果在测试前期，参与了部分开发文档的讨论，尽量了解每个数据库中每个字段的意思，对开发了解深入一些，可能测试深度就不一样了。
7.全面分析测试结果，确定合理的测试度量标准：
全面分析阶段测试结果，总结测试经验和系统缺陷，分析测试过程中存在的问题，提交有价值的测试报告，推动相关高层管理人员予以关注，促进问题和缺陷得到有效的解决，这才能够起到关键性的作用。同时，要确定一个比较合理的测试度量标准，不断实践、不断总结、不断改进，提出符合公司实际情况的测试过程改进措施。
8.兼顾成本的前提下，尽量保证测试的覆盖率：
在保证测试成本的前提下，我们要尽可能的提高测试的覆盖率。其中测试覆盖：包括测试内容覆盖、测试技术覆盖和测试过程覆盖。我们可以通过测试用例覆盖率来提高测试的质量，保证较多的缺陷在版本发布以前被测试组发现。也可以通过提高测试技术覆盖率，用实践来验证，不能够轻易相信部分行业人士的一面之词，而误入歧途。在保证公司盈利的情况下，尽量提高测试的覆盖率，提高测试质量。
测试过程改进的注意事项：
1.切忌“好高骛远”脱离公司实际：
很多时候，软件公司大家都一窝蜂的赶时髦。我们一提到测试过程改进，大家都想像“测试规范”一样弄得非常全面，大部分都停留在理论上，花了大量的人力和物力，往往脱离了公司的实际情况，得不丧失，结果可想而知。
2.测试过程改进不能盲目跟风，切不可赶潮流：
一个公司近年来的发展方向一旦确定，那就要坚持走下去。如果定位不一样，那对测试过程改进的要求也就不一样。比如说一个小公司，本来测试人员都很少，测试资源都有限，正常测试都无法保证，那你觉的谈“测试过程改进”还有意义吗？再比如说小公司有测试过程改进的经济实力，那也无法和大公司相比，毕竟企业也要赚钱、盈利、生存。所以，测试改进时，一定要考虑测试部门的规模、公司的商业机会、企业经济实力等等方面的因素，更不应该盲目跟风。合适的才是最好的！过程改进，切不可赶潮流！
3.测试过程改进最好由专人负责：
在中国，很多时候，一个人干多个人的事情，拿到的工资与付出不成正比，亏呀！！！比如说在我们公司，凡是涉及到软件测试的工作，都由测试经理负责，包括“测试过程改进”、“测试规范制定”、“测试模板制定”、“自动化测试”呀？什么的，都一个人干，甚至包括QA的工作，都快被累死了，呵呵！！最主要是一个人干几个人该做的事情，很容易分散精力，并且考虑也不会很周到，也没有一个人专业了。建议由专人来负责测试过程的改进比较好，测试过程改进成功的几率会大很多。
4.测试过程改进并不等于花费大量资金
大部分的测试公司，在测试过程改进上都是走走过场，为得都是应付客户。有的公司是请一些测试专家进行咨询，不仅花费大量的时间，还耗费的大量的资金。有的公司是买一些测试工具、缺陷工具，当然开销也不小。我觉得：如果条件允许的情况下，各方面都可以跟上，那样比较理想。如果公司经济条件有限，我建议针对公司的实际情况，合理利用测试部门的集体智慧，改进测试过程方为良策。
5.测试过程改进不能够急于求成：
软件测试过程改进，作为软件测试的一个阶段，我们只能够循序渐进，不能急于求成。我们应该正确处理好测试和测试过程改进的主次关系，一步一步用实践验证来完善。相信只要经过测试部门的不断努力，测试过程改进一定会取得成功.
-
ORACLE导入导出的方法
2009-02-23 17:11:59
导出表:
expscott/tiger@mycontables=(dept,emp) file=tab1.dmp
导出用户:
expsystem/manager@myconōwner=scott file=usr1.dmp
导出数据库:
1.完全导出
expsystem/manager@myconfull=y inctype=complete file=full1.dmp
2.增量导出
expsystem/manager@myconfull=y inctype=incremental file=inc1.dmp
3.累积导出
expsystem/manager@myconfull=y inctype=cumulative file=cum1.dmpimp example:
导入表:
impsystem/manager@myconfile=c:\tab1.dmp tables=(dept,emp) touser=scott
导入用户:
impsystem/manager@myconfile=usr1.dmp fromuser=scott touser=scott
导入数据库:
1.全库导入
impsystem/manager@myconfile=full1.dmp full=y
2.增量导入
1)导入数据库最新信息
impsystem/manager@myconinctype=system full=y file=inc7.dmp
2)导入最近完全导出文件
impsystem/manager@myconinctype=restore full=y file=full1.dmp
3)导入所有累积导出文件
impsystem/manager@myconinctype=restore full=y file=cum1.dmp
4)导入最近一次增量导出的文件
impsystem/manager@myconinctype=restore full=y file=inc1.dmp -
测试网站大全
2009-02-23 17:00:20
51Testing测试网---www.51testing.com
测试时代----------www.testage.net 焦点测试----------www.testfocus.com.cn
3Atesting----------www.3atesting.com
CSDN测试频道------testing.csdn.net
希赛网测试频道----testing.csai.cn
中国软件测试联盟--www.iceshi.com
一起测试网--------www.17testing.com
北大测试----------www.btesting.com
中国软件测试基地--www.cntesting.com
中国软件评测中心--www.cstc.org.cn
中国软件质量网----www.rjzl.gov.cn
软件工程专家网----www.51cmm.com
中国软件测试在线--www.softtest.cn
天天软件测试网----www.tttest.com/
365testing--------www.365testing.com
中国测试员--------www.cntester.comhttp://www.sawin.cn/SawinPilot/saSubTech.asp?SubClass=Test
http://www.io.com/~wazmo/qa/
http://www.mtsu.edu/~storm/
http://www.qaforums.com
http://www.faqs.org/faqs/software-eng/testing-faq/电子书下载网址
http://www.itpub.net/325522,1.html
测试书籍的推荐:
http://www.cntesting.com/hphtml/?thread-7346.html
软件测试好书下载和推荐:
http://www.51testing.com/recommend.htm -
SQL语句
2009-02-23 16:52:28
一、基础
1、说明：创建数据库
CREATE DATABASE database-name
2、说明：删除数据库
drop database dbname
3、说明：备份sql server
--- 创建备份数据的 device
USE master
EXEC sp_addumpdevice 'disk', 'testBack', 'c:\mssql7backup\MyNwind_1.dat'
--- 开始 备份
BACKUP DATABASE pubs TO testBack
4、说明：创建新表
create table tabname(col1 type1 [not null] [primary key],col2 type2 [not null],..)
根据已有的表创建新表：
A：create table tab_new like tab_old (使用旧表创建新表)
B：create table tab_new as select col1,col2... from tab_old definition only
5、说明：删除新表
drop table tabname
6、说明：增加一个列
Alter table tabname add column col type
注：列增加后将不能删除。DB2中列加上后数据类型也不能改变，唯一能改变的是增加varchar类型的长度。
7、说明：添加主键： Alter table tabname add primary key(col)
说明：删除主键： Alter table tabname drop primary key(col)
8、说明：创建索引：create [unique] index idxname on tabname(col....)
删除索引：drop index idxname
注：索引是不可更改的，想更改必须删除重新建。
9、说明：创建视图：create view viewname as select statement
删除视图：drop view viewname
10、说明：几个简单的基本的sql语句
选择：select * from table1 where 范围
插入：insert into table1(field1,field2) values(value1,value2)
删除：delete from table1 where 范围
更新：update table1 set field1=value1 where 范围
查找：select * from table1 where field1 like '%value1%' ---like的语法很精妙，查资料!
排序：select * from table1 order by field1,field2 [desc]
总数：select count as totalcount from table1
求和：select sum(field1) as sumvalue from table1
平均：select avg(field1) as avgvalue from table1
最大：select max(field1) as maxvalue from table1
最小：select min(field1) as minvalue from table1
11、说明：几个高级查询运算词
A： UNION 运算符
UNION 运算符通过组合其他两个结果表（例如 TABLE1 和 TABLE2）并消去表中任何重复行而派生出一个结果表。当 ALL 随 UNION 一起使用时（即 UNION ALL），不消除重复行。两种情况下，派生表的每一行不是来自 TABLE1 就是来自 TABLE2。
B： EXCEPT 运算符
EXCEPT 运算符通过包括所有在 TABLE1 中但不在 TABLE2 中的行并消除所有重复行而派生出一个结果表。当 ALL 随 EXCEPT 一起使用时 (EXCEPT ALL)，不消除重复行。
C： INTERSECT 运算符
INTERSECT 运算符通过只包括 TABLE1 和 TABLE2 中都有的行并消除所有重复行而派生出一个结果表。当 ALL 随 INTERSECT 一起使用时 (INTERSECT ALL)，不消除重复行。
注：使用运算词的几个查询结果行必须是一致的。
12、说明：使用外连接
A、left outer join：
左外连接（左连接）：结果集几包括连接表的匹配行，也包括左连接表的所有行。
SQL: select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c
B：right outer join:
右外连接(右连接)：结果集既包括连接表的匹配连接行，也包括右连接表的所有行。
C：full outer join：
全外连接：不仅包括符号连接表的匹配行，还包括两个连接表中的所有记录。
二、提升
1、说明：复制表(只复制结构,源表名：a 新表名：b) (Access可用)
法一：select * into b from a where 1<>1
法二：select top 0 * into b from a
2、说明：拷贝表(拷贝数据,源表名：a 目标表名：b) (Access可用)
insert into b(a, b, c) select d,e,f from b;
3、说明：跨数据库之间表的拷贝(具体数据使用绝对路径) (Access可用)
insert into b(a, b, c) select d,e,f from b in '具体数据库' where 条件
例子：..from b in '"&Server.MapPath(".")&"\data.mdb" &"' where..
4、说明：子查询(表名1：a 表名2：b)
select a,b,c from a where a IN (select d from b ) 或者: select a,b,c from a where a IN (1,2,3)
5、说明：显示文章、提交人和最后回复时间
select a.title,a.username,b.adddate from table a,(select max(adddate) adddate from table where table.title=a.title) b
6、说明：外连接查询(表名1：a 表名2：b)
select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c
7、说明：在线视图查询(表名1：a )
select * from (SELECT a,b,c FROM a) T where t.a > 1;
8、说明：between的用法,between限制查询数据范围时包括了边界值,not between不包括
select * from table1 where time between time1 and time2
select a,b,c, from table1 where a not between 数值1 and 数值2
9、说明：in 的使用方法
select * from table1 where a [not] in ('值1','值2','值4','值6')
10、说明：两张关联表，删除主表中已经在副表中没有的信息
delete from table1 where not exists ( select * from table2 where table1.field1=table2.field1 )
11、说明：四表联查问题：
select * from a left inner join b on a.a=b.b right inner join c on a.a=c.c inner join d on a.a=d.d where .....
12、说明：日程安排提前五分钟提醒
SQL: select * from 日程安排 where datediff('minute',f开始时间,getdate())>5
13、说明：一条sql 语句搞定数据库分页
select top 10 b.* from (select top 20 主键字段,排序字段 from 表名 order by 排序字段 desc) a,表名 b where b.主键字段 = a.主键字段 order by a.排序字段
14、说明：前10条记录
select top 10 * form. table1 where 范围
15、说明：选择在每一组b值相同的数据中对应的a最大的记录的所有信息(类似这样的用法可以用于论坛每月排行榜,每月热销产品分析,按科目成绩排名,等等.)
select a,b,c from tablename ta where a=(select max(a) from tablename tb where tb.b=ta.b)
16、说明：包括所有在 TableA 中但不在 TableB和TableC 中的行并消除所有重复行而派生出一个结果表
(select a from tableA ) except (select a from tableB) except (select a from tableC)
17、说明：随机取出10条数据
select top 10 * from tablename order by newid()
18、说明：随机选择记录
select newid()
19、说明：删除重复记录
Delete from tablename where id not in (select max(id) from tablename group by col1,col2,...)
20、说明：列出数据库里所有的表名
select name from sysobjects where type='U'
21、说明：列出表里的所有的
select name from syscolumns where id=object_id('TableName')
22、说明：列示type、vender、pcs字段，以type字段排列，case可以方便地实现多重选择，类似select 中的case。
select type,sum(case vender when 'A' then pcs else 0 end),sum(case vender when 'C' then pcs else 0 end),sum(case vender when 'B' then pcs else 0 end) FROM tablename group by type
显示结果：
type vender pcs
电脑 A 1
电脑 A 1
光盘 B 2
光盘 A 2
手机 B 3
手机 C 3
23、说明：初始化表table1
TRUNCATE TABLE table1
24、说明：选择从10到15的记录
select top 5 * from (select top 15 * from table order by id asc) table_别名 order by id desc
三、技巧
1、1=1，1=2的使用，在SQL语句组合时用的较多
"where 1=1" 是表示选择全部 "where 1=2"全部不选，
如：
if @strWhere !=''
begin
set @strSQL = 'select count(*) as Total from [' + @tblName + '] where ' + @strWhere
end
else
begin
set @strSQL = 'select count(*) as Total from [' + @tblName + ']'
end
我们可以直接写成
set @strSQL = 'select count(*) as Total from [' + @tblName + '] where 1=1 安定 '+ @strWhere
2、收缩数据库
--重建索引
DBCC REINDEX
DBCC INDEXDEFRAG
--收缩数据和日志
DBCC SHRINKDB
DBCC SHRINKFILE
3、压缩数据库
dbcc shrinkdatabase(dbname)
4、转移数据库给新用户以已存在用户权限
exec sp_change_users_login 'update_one','newname','oldname'
go
5、检查备份集
RESTORE VERIFYONLY from disk='E:\dvbbs.bak'
6、修复数据库
ALTER DATABASE [dvbbs] SET SINGLE_USER
GO
DBCC CHECKDB('dvbbs',repair_allow_data_loss) WITH TABLOCK
GO
ALTER DATABASE [dvbbs] SET MULTI_USER
GO
7、日志清除
SET NOCOUNT ON
DECLARE @LogicalFileName sysname,
@MaxMinutes INT,
@NewSize INTUSE tablename -- 要操作的数据库名
SELECT @LogicalFileName = 'tablename_log', -- 日志文件名
@MaxMinutes = 10, -- Limit on time allowed to wrap log.
@NewSize = 1 -- 你想设定的日志文件的大小(M)
-- Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size
FROM sysfiles
WHERE name = @LogicalFileName
SELECT 'Original Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
(DummyColumn char (8000) not null)DECLARE @Counter INT,
@StartTime DATETIME,
@TruncLog VARCHAR(255)
SELECT @StartTime = GETDATE(),
@TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
-- Wrap the log if necessary.
WHILE @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired
AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)
AND (@OriginalSize * 8 /1024) > @NewSize
BEGIN -- Outer loop.
SELECT @Counter = 0
WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
BEGIN -- update
INSERT DummyTrans VALUES ('Fill Log')
DELETE DummyTrans
SELECT @Counter = @Counter + 1
END
EXEC (@TruncLog)
END
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
FROM sysfiles
WHERE name = @LogicalFileName
DROP TABLE DummyTrans
SET NOCOUNT OFF
8、说明：更改某个表
exec sp_changeobjectowner 'tablename','dbo'
9、存储更改全部表
CREATE PROCEDURE dbo.User_ChangeObjectOwnerBatch
@OldOwner as NVARCHAR(128),
@NewOwner as NVARCHAR(128)
AS
DECLARE @Name as NVARCHAR(128)
DECLARE @Owner as NVARCHAR(128)
DECLARE @OwnerName as NVARCHAR(128)
DECLARE curObject CURSOR FOR
select 'Name' = name,
'Owner' = user_name(uid)
from sysobjects
where user_name(uid)=@OldOwner
order by name
OPEN curObject
FETCH NEXT FROM curObject INTO @Name, @Owner
WHILE(@@FETCH_STATUS=0)
BEGIN
if @Owner=@OldOwner
begin
set @OwnerName = @OldOwner + '.' + rtrim(@Name)
exec sp_changeobjectowner @OwnerName, @NewOwner
end
-- select @name,@NewOwner,@OldOwner
FETCH NEXT FROM curObject INTO @Name, @Owner
END
close curObject
deallocate curObject
GO10、SQL SERVER中直接循环写入数据
declare @i int
set @i=1
while @i<30
begin
insert intotest(userid) values(@i)
set @i=@i+1
end
小记存储过程中经常用到的本周，本月，本年函数
Dateadd(wk,datediff(wk,0,getdate()),-1)
Dateadd(wk,datediff(wk,0,getdate()),6)
Dateadd(mm,datediff(mm,0,getdate()),0)
Dateadd(ms,-3,dateadd(mm,datediff(m,0,getdate())+1,0))
Dateadd(yy,datediff(yy,0,getdate()),0)
Dateadd(ms,-3,DATEADD(yy, DATEDIFF(yy,0,getdate())+1, 0))
上面的SQL代码只是一个时间段
Dateadd(wk,datediff(wk,0,getdate()),-1)
Dateadd(wk,datediff(wk,0,getdate()),6)
就是表示本周时间段.
下面的SQL的条件部分,就是查询时间段在本周范围内的:
Where Time BETWEEN Dateadd(wk,datediff(wk,0,getdate()),-1) AND Dateadd(wk,datediff(wk,0,getdate()),6)
而在存储过程中
select @begintime = Dateadd(wk,datediff(wk,0,getdate()),-1)
select @endtime = Dateadd(wk,datediff(wk,0,getdate()),6) -
测试报告编写指南
2009-02-23 16:14:12
测试报告编写指南
1 摘要
测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。本文提供测试报告模板以及如何编写的实例指南。
1.1 关键字
测试报告 缺陷
1.2 正文
测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。
下面以通用的测试报告模板为例，详细展开对测试报告编写的具体描述。
2 首页
2.1 页面内容：
密级，通常，测试报告供内部测试完毕后使用，因此密级为中，如果可供用户和更多的人阅读，密级为低，高密级的测试报告适合内部研发项目以及涉及保密行业和技术版权的项目。
XXXX 项目/系统测试报告
报告编号
可供索引的内部编号或者用户要求分布提交时的序列号
部门经理 ______项目经理______
开发经理______测试经理______
XXX 公司 XXXX 单位 （此处包含用户单位以及研发此系统的公司）
XXXX 年 XX 月 XX 日
2.2 格式要求：
标题一般采用大体字（如一号），加粗，宋体，居中排列
副标题采用大体小一号字（如二号）加粗，宋体，居中排列
其他采用四号字，宋体，居中排列
2.3 版本控制：
版本 作者 时间 变更摘要
新建/变更/审核
3 引言部分
3.1 编写目的
本测试报告的具体编写目的，指出预期的读者范围。
实例：本测试报告为 XXX 项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到 XXX 功能目标） 预期参考人员包括用户、。测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。
提示：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告 XXX 页 XXX 章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。
3.2 项目背景
对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。
3.3 系统简介
如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。
3.4 1.4 术语和缩写词
列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。
3.5 参考资料
1．需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。
2．测试使用的国家标准、行业指标、公司规范和质量手册等等
4 测试概要
测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分）
4.1 测试用例设计
简要介绍测试用例的设计方法。例如：等价类划分、边界值、因果图，以及用这类方法(3-4句)。
提示：如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念，顺便说一句，在这里写上一些非常规的设计方法也是有利的，至少在没有看到测试结论之前就可以了解到测试经理的设计技术，重点测试部分一定要保证有两种以上不同的用例设计方法。
4.2 测试环境与配置
简要介绍测试环境及其配置。
提示：清单如下，如果系统/项目比较大，则用表格方式列出
数据库服务器配置
CPU：
内存：
硬盘：可用空间大小
操作系统：
应用软件：
机器网络名：
局域网地址：
应用服务器配置
…….
客户端配置
…….
对于网络设备和要求也可以使用相应的表格，对于三层架构的，可以根据网络拓扑图列出相关配置。
4.3 测试方法(和工具)
简要介绍测试中采用的方法(和工具)。
提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。
5 测试结果及缺陷分析
整个测试报告中这是最激动人心的部分，这部分主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。对于不需要过程度量或者相对较小的项目，例如用于验收时提交用户的测试报告、小型项目的测试报告，可省略过程方面的度量部分；而采用了 CMM/ISO 或者其他工程标准过程的，需要提供过程改进建议和参考的测试报告－主要用于公司内部测试改进和缺陷预防机制－则过程度量需要列出。
5.1 测试执行情况与记录
描述测试资源消耗情况，记录实际数据。（测试、项目经理关注部分）
5.1.1 测试组织
可列出简单的测试组架构图，包括：
测试组架构 （如存在分组、用户参与等情况）
测试经理（领导人员）
主要测试人员
参与测试人员
5.1.2 测试时间
列出测试的跨度和工作量，最好区分测试文档和活动的时间。数据可供过程度量使用。
例如 XXX 子系统/子功能
实际开始时间－实际结束时间
总工时/总工作日
任务 开始时间 结束时间 总计
合计
对于大系统/项目来说最终要统计资源的总投入，必要时要增加成本一栏，以便管理者清楚的知道究竟花费了多少人力去完成测试。
测试类型 人员成本 工具设备 其他费用
总计
在数据汇总时可以统计个人的平均投入时间和总体时间、整体投入平均时间和总体时间，还可以算出每一个功能点所花费的时/人。
用时人员 编写用例 执行测试 总计
合计
这部分用于过程度量的数据包括文档生产率和测试执行率。
生产率人员 用例/编写时间 用例/执行时间 平均
合计
5.1.3 测试版本
给出测试的版本，如果是最终报告，可能要报告测试次数回归测试多少次。列出表格清单则便于知道那个子系统/子模块的测试频度，对于多次回归的子系统/子模块将引起开发者关注。
5.2 覆盖分析
5.2.1 需求覆盖
需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到 100％的目标。
需求/功能（或编号） 测试类型 是否通过 备注
[Y][P][N][N/A]
根据测试结果 ，按编号给出每一测试需求的通过与否结论。P 表示部分通过，N/A 表示不可测试或者用例不适用。实际上，需求跟踪矩阵列出了一一对应的用例情况以避免遗漏，此表作用为传达需求的测试信息以供检查和审核。
需求覆盖率计算 Y 项/需求总数 ×100％
5.2.2 测试覆盖
需求/功能（或编号） 用例个数 执行总数 未执行 未/漏测分析和原因
实际上，测试用例已经记载了预期结果数据，测试缺陷上说明了实测结果数据和与预期结果数据的偏差；因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差，列表的目的仅在于更好的查看测试结果。
测试覆盖率计算 执行数/用例总数 ×100％
5.3 缺陷的统计与分析
缺陷统计主要涉及到被测系统的质量，因此，这部分成为开发人员、质量人员重点关注的部分。
5.3.1 缺陷汇总
被测系统 系统测试 回归测试 总计
合计
按严重程度
严重 一般 微小
按缺陷类型
用户界面 一致性 功能 算法 接口 文档 用户界面 其他
按功能分布
功能一 功能二 功能三 功能四 功能五 功能六 功能七
最好给出缺陷的饼状图和柱状图以便直观查看。俗话说一图胜千言，图标能够使阅读者迅速获得信息，尤其是各层面管理人员没有时间去逐项阅读文章。
图例
5.3.2 缺陷分析
本部分对上述缺陷和其他收集数据进行综合分析
缺陷综合分析
缺陷发现效率 ＝ 缺陷总数/执行测试用时
可到具体人员得出平均指标
用例质量 ＝ 缺陷总数/测试用例总数 ×100％
缺陷密度 ＝ 缺陷总数/功能点总数
缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷最多，从而在今后开发注意避免并注意在实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。
测试曲线图
描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向
重要缺陷摘要
缺陷编号 简要描述 分析结果 备注
5.3.3 残留缺陷与未解决问题
残留缺陷
编号：BUG 号
缺陷概要：该缺陷描述的事实
原因分析：如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因
预防和改进措施：弥补手段和长期策略
未解决问题
功能/测试类型：
测试结果：与预期结果的偏差
缺陷：具体描述
评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响
6 测试结论与建议
报告到了这个部分就是一个总结了，对上述过程、缺陷分析之后该下个结论，此部分为项目经理、部门经理以及高层经理关注，请清晰扼要的下定论。
6.1 测试结论
1. 测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
2. 对测试风险的控制措施和成效
3. 测试目标是否完成
4. 测试是否通过
5. 是否可以进入下一阶段项目目标
6.2 建议
1. 对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响
2. 可能存在潜在缺陷和后续工作
3. 对缺陷修改和产品设计的建议
4. 对过程改进方面的建议
-
bugfree2.03在windows下的搭建
2009-02-23 15:27:30
全新安装bugfree2.03在安装BugFree之前，需要首先安装Apache, PHP, Mysql支持软件包，例如XAMPP或EASYPHP等。
下面以XAMPP为例进行说明。请先访问http://www.apachefriends.org/zh_cn/xampp.html 下载并安装最新的XAMPP版本。1. 下载BugFree2.0.3安装包，解压后复制到XAMPP系统的htdocs子目录下
如果是Linux系统，安装路径一般为/opt/lampp/htdocs/bugfree; Window系统的安装路径一般为C:\xampp\htdocs\bugfree2. 进入bugfree的安装目录，复制文件Include/Config.inc.Sample.php为新文件Include/Config.inc.php，编辑新创建的文件，修改数据库链接设置：
/* 3. Define the username and password of the BugFree database. */
$_CFG['DB']['User'] = 'root'; // 数据库登录用户名
$_CFG['DB']['Password'] = ''; // 数据库登录用户密码
$_CFG['DB']['Host'] = 'localhost'; // 数据库服务器地址
$_CFG['DB']['Database'] = 'bugfree2'; // 指定BugFree数据库名称
$_CFG['DB']['TablePrefix'] = 'bf_'; // 数据库表前缀，默认为bf_。除非有冲突，不建议修改或为空
$_CFG['DBCharset'] = 'UTF8'; // 数据库编码设置，保留默认值
3. 如果是Linux 系统，修改下列目录和文件的权限；如果是Windows系统，跳过这一步
a) chmod 777 Data/TplCompile/
b) chmod 777 BugFile/
c) chmod 777 Include/Config.inc.php
4. 在浏览器访问http://<servername>/bugfree。如果设置的数据库不存在，按照提示创建数据库，再点击继续安装
5. 点击“安装全新的 BugFree2”。
6. 安装成功后，显示首次登录的默认管理员帐号和密码，按照提示首先使用默认管理员用户名和密码登陆BugFree
