心是平静的还是有种冲动?

测试是评估产品的质量?

还是对测试工具的不断追求?研究代码?

花很多的时间去做自动化测试?(个人理解:自动化测试应该节省企业成本做更多有效的事情!)

所花的时间是否值得?

测试一定掌握全面的知识才容易测试,你从事某方面的测试,就会用心花一些时间去学习和积累自己的经验!

有些东西需要测试,有些是要通过自己的理解,和公司和有关人员制定有关标准,有度而不是无限地测试,让产品更加完善!

写得很乱了,暂时也就这么一点儿了!

如何制定完美的测试计划
“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求 说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。

　　 产品基本情况调研：

　　这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。

　　 具体的要点有：

　　 目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置，粗略的估计测试大致需要的周期和最终测试报告递交的时间。

　　 变更：说明有可能会导致测试计划变更的事件。包括 测试工具 改进了，测试的环境改变了，或者是添加了新的功能。

　　技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的 数据库 等等。

　　 产品规格：就是制造商和产品版本号的说明。

　　 测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。

　　 项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。

　　 测试需求说明：

　　这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有：

　　功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。

　　 设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

　　 整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。

　　 测试的策略和记录：

　　 这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、 性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下：

　　公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。

　　 测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的 回归测试 留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。

　　 特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。

　　 经验判断：对以往的测试中，经常出现的问题加以考虑。

　　 设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。

　　 测试资源配置：

　　项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。

　　 计划表：

　　 测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以 软件测试 的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。

　　 问题跟踪报告：

　　在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境 。

　　 问题描述尽可能是定量的，分门别类的列举，问题有几种：

　　 1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。

　　 2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。

　　 3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。

　　 测试计划的评审：

　　又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。

　　 结果：

　　计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。

软件测试用例的设计
一、测试用例是软件测试的核心

　　软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

　　影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

　　因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。

　　二、什么叫测试用例

　　测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

　　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

　　三、编写测试用例

　　着重介绍一些编写测试用例的具体做法。

　　1、测试用例文档

　　编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。

　　软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

　　测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

　　2、测试用例的设置

　　我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。

　　按功能测试是最简捷的，按用例规约遍历测试每一功能。

　　对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

　　但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

　　3、设计测试用例

　　测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

　　设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。

　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

01. 为什么要在一个团队中开展软件测试工作？
　　因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

02. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
　　我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试

03. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同04. 的测试类型的区别与联系（如功能测试、性能测试……）
　　测试类型有：功能测试，性能测试，界面测试。
　　功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
　　区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

04．您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

05.     请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

　　黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
　　白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
　　1、是否有不正确或遗漏的功能？
　　2、在接口上，输入是否能正确的接受？能否输出正确的结果？
　　3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
　　4、性能上是否能够满足要求？
　　5、是否有初始化或终止性错误？

　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
　　1、对程序模块的所有独立的执行路径至少测试一遍。
　　2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
　　3、在循环的边界和运行的界限内执行循环体。
　　4、测试内部数据结构的有效性，等等。

　　单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

　　单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

　　集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

　　系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

　　系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

　　验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

06. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
　　软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

07. 您认为做好测试计划工作的关键是什么？
　　1. 明确测试的目标，增强测试计划的实用性
　　编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
　　2．坚持“5W”规则，明确内容与过程
　　“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
　　3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
　　4. 分别创建测试计划与测试详细规格、测试用例
　　应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

08. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
　　1．等价类划分
　　划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　2．边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3．错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4．因果图方法
　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

09. 请以您以往的实际工作为例，10. 详细的描述一次测试用例设计的完整的过程。
　　就说最近的这次网站功能的测试吧
　　首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
　　第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对　　这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
　　第四步：执行测试

11. 您以往是否曾经从事过性能测试工作？如果有，12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
　　是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。
性能测试类型包括负载测试，强度测试，容量测试等
　　负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
　　强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况
　　容量测试：确定系统可处理同时在线的最大用户数  
　　在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

　　Web服务器指标指标：
　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
　　* Successful Rounds：成功的请求；
　　* Failed Rounds ：失败的请求；
　　* Successful Hits ：成功的点击次数；
　　* Failed Hits ：失败的点击次数；
　　* Hits Per Second ：每秒点击次数；
　　* Successful Hits Per Second ：每秒成功的点击次数；
　　* Failed Hits Per Second ：每秒失败的点击次数；
　　* Attempted Connections ：尝试链接数；　　

13. 您在从事性能测试工作时，14. 是否使用过一些测试工具？如果有，15. 请试述该工具的工作原理，16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

17. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

18. 在您以往的工作中，19. 一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

20. 您以往所从事的软件测试工作中，21. 是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，22. 请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

23. 您认为在测试人员同24. 开发人员的沟通过程中，25. 如何提高沟通的效率和改善沟通的效果？维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么？

27. 在您以往的测试工作中，28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么？您是如何来对待这些事情的？

31. 在即将完成这次笔试前，32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

33.        你对测试最大的兴趣在哪里？为什么？
　　最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
　　刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
　　不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。
　　我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。
　　第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

34. 你的测试职业发展是什么？
　　测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。

35. 你自认为测试的优势在哪里？
　　优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

36. 你以前工作时的测试流程是什么？
　　公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

37. 当开发人员说不38. 是BUG时，39. 你如何应付？
　　开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

23．你为什么想离开目前的职务？
　　因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。

24：你对我们公司了解有多少？

25：你找工作时，最重要的考虑因素为何？
　　工作的性质和内容是否能让我发挥所长，并不断成长。

26：为什么我们应该录取你？
　　您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

27：请谈谈你个人的最大特色。
　　我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

28.白箱测试和黑箱测试是什么?什么是回归测试?

29。单元测试、集成测试、系统测试的侧重点是什么？

30。设计用例的方法、依据有那些？

31。一个测试工程师应具备那些素质和技能？

32.集成测试通常都有那些策略？

33.你用过的测试工具的主要功能、性能及其他？

34.一个缺陷测试报告的组成

35.基于WEB信息管理系统测试时应考虑的因素有哪些？

36.软件测试项目从什么时候开始，？为什么？

37.需求测试注意事项有哪些？

38.简述一下缺陷的生命周期

39.测试分析测试用例注意（事项）？
　　你在你所在的公司是怎么开展测试工作的？是如何组织的？
　　你认为理想的测试流程是什么样子？
　　你是怎样工作的？
　　软件测试活动的生命周期是什么？
　　请画出软件测试活动的流程图？
　　针对缺陷采取怎样管理措施？
　　什么是测试评估？测试评估的范围是什么？
　　如果能够执行完美的黑盒测试，还需要进行白盒测试吗？为什么？
　　测试结束的标准是什么？
　　软件验收测试除了alpha,beta测试以外,还有哪一种?
　　做测试多久了？
　　以前做过哪些项目？
　　你们以前测试的流程是怎样的？
　　<答：测试计划－测试用例设计－测试执行－测试分析报告>
　　用过哪些测试工具？
　　为什么选择测试这行？
　　<答：它是一个新兴的行业，有发展潜力，而且很锻炼人，需要掌握更多的技能，比做开发要更难>
　　为什么值得他们公司雇用？
　　如果我雇用你，你能给部门带来什么贡献？
　　如何从工作中看出你是个自动自觉的人
　　你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
　　通常你对于别人批评你会有什么样的反应
　　如果明知这样做不对，你还会依主管的指过去做吗
　　如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
　　你觉得什么样的人最难相处
　　为什么值得他们公司雇用？
　　　　帮助公司提高软件质量和测试部门的技术水平
　　如果我雇用你，你能给部门带来什么贡献？
　　　　分享我的测试经验和测试技能，提高测试部门技术水平
　　如何从工作中看出你是个自动自觉的人
　　　        自动自觉范围太广
　       1. 工作成果
       　2. 工作质量 
　　你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
　　　　在有足够的资源和合理的工作量的情况下，完全可以按时完成，并能比一般人做的更好
　　通常你对于别人批评你会有什么样的反应
　　　　有错即改，无措勉之

　　如果明知这样做不对，你还会依主管的指过去做吗
　　　　在公司内部下级是否有申诉渠道？

　　如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
　　　　为什么抱怨？是怎么样的问题？
　　　　如果是客服问题，提交客服部门解决
　　　　如果是质量问题，分析原因，下一版本改进
　　你觉得什么样的人最难相处
　　　　自以为是的人

　　什么叫单元测试？
　　　　请就软件测试人员应该具备什么样的基本素质说说你的看法。

　　请就如何在开发中进行软件质量控制说说你的看法
　　 简述软件测试的意义，以及软件测试的分类

1、功能测试，性能测试，界面测试，安全测试（可以简单点，比如只涉及到COOKIES里的内容），压力测试（商业性质的网站） 等等，B/S软件也要根据其具体功能采用不同的测试策略。
2、态度、责任心、自信、敏锐的观察力、良好的发散思维
3、先设计后开发模式，加强单元测试，加强代码走查，有一套完整的白盒测试方法。关键是加强开发人员的质量意识，增进程序员向工程师水平发展。
4、意义嘛，就自己想吧。软件测试的分类，这个很多人都按各种方法去分。无明确答案给你。

对测试的理解——基本的测试知识，对测试是否认可？ 75。
      3、谈一谈过去自己的工作——了解经历、提供进一步提问的素材，表达能力  
测试技能
测试设计的方法并举例说明——测试技术的使用
测试工具——熟悉程度，能否与当前工作匹配？
如何做计划？如何跟踪计划？——日常工作能力
如果开发人员提供的版本不满足测试的条件，如何做？——与开发人员协作的能力
熟悉unix系统、oracle数据库吗？——是否具备系统知识
做过开发吗？写过哪些代码？——开发技能
阅读英语文章，给出理解说明？——部分英语能力
文档的意义——是否善于思考？（最简单的概念，不同层次的理解）
假如进入我们公司，对我们哪些方面会有帮助？——讲讲自己的特长
随便找一件物品，让其测试——测试的实际操作能力
软件测试的方法有？
软件测试的过程？
有一个新的软件，假如你是测试工程师，该如何做？

软件测试分哪两种方法？分别适合什么情况？
2。一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
3。软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
4。测试用例通常包括那些内容？着重阐述编制测试用例的具体做法
5。在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试？他们存在什么样的区别与联系？
6。在测试winform的C/S结构软件时，发现这个软件的运行速度很慢，您会认为是什么原因？您会采取哪些方法去检查这个原因？
7。描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程
你在五年内的个人目标和职业目标分别是什么？
　　分析这个问题是用来了解你的计划能力的，通过这个问题，面试人同时还可以知道你的目标是否符合企业对你的安排。
　　错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁，我认为做太多的个人计划是荒谬可笑的，不是吗？
　　评论这种回答属于令人反感的一类。首先，当有人想了解你的目标时，"将来的某个时候"这种通俗说法并不奏效。其次，认为企业很脆弱，领导者更换频繁，这种说法毫无疑问会令人反感，而且也是不合理的。最后，认为做计划可笑，看不起这个问题，而且反问面试人，这些都注定了这样的求职者最终会失败。
　　正确回答从现在起的五年之内，我希望能够在一个很好的职位上待几年，而且最好有一次晋升，然后就期待着下一步。不管是向上提升，还是在企业内横向调动，对我个人来说，我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。
　　评论这个问题没有回答得过分具体（那样可能会产生漏洞），而且它表明你有雄心，并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望，表明你是一个有灵活性的人。
　问题23　你怎样做出自己的职业选择？
　　分析 面试人提出这个问题是为了了解求职者的动机，看看他（她）应聘这份工作是否有什么历史渊源，是否有职业规划，是不是仅仅在漫无目的地申请很多工作。
　　错误回答 我一直都想在企业界工作。自孩提时代起，我就梦想自己至少也要成为大企业的副总裁。
　　评论 除了难以令人相信之外，这种回答还存在一个问题：它表明求职者会对副总裁以下的职位不感兴趣。
　　正确回答 在上大学四年级前的那个夏天，我决定集中精力在某一领域谋求发展。尽管我是学商业的，但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标，想清楚了自己擅长做的事情以及想从工作中得到的东西，最后我得出了一个坚定的结论，那就是这个行业是最适合我的。
　　评论 这种回答表明，求职者认真地做过一些计划，缩小了自己的关注点，而且也认准了前进的方向。这种回答还表明，求职者理解个人职业规划的重要性，并且有能力做出认真的个人决策。
1. 你都用什么测试方法
2.怎么编写案例
3.怎么才能够全面的测试到每一个点
1. 你都用什么测试方法
针对不同的产品或者系统或者模块，有不同的测试方法。总体而言有白盒测试和黑盒测试。
2.怎么编写案例
案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
3.怎么才能够全面的测试到每一个点
测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等多个角度考虑从而定义全部的测试点。
1、谈谈软件测试技术，以及如何提高
2、谈谈软件测试职业发展，以及个人的打算
3、谈谈软件测试在企业的地位，也可以结合软件生命周期来谈
有可能清晰的思路比确切的答案更重要
在这里，主要说下笔试和面试的问题，希望大家共同参考。
       1，一般公司里实际的软件测试流程是什么样的？你们公司又是怎样的？
       2，软件工程师要具有那些素质？
       3，你会哪些测试工具？怎么操作？
       4，你能不能说下你的3到5年的职业计划（规划）
       5，你觉得你来应聘有那些优势？
其余的还好说，但就第4个问题，我感到不好说哦！希望大家给个意见
第一关：首先要自我介绍，自己的性格怎么样，目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看？还有对于软件测试有什么自己的想法。为什么会想到要做这行（因为我的简历上的工作经历没有关于测试方面的）。哦，还有期望薪资。
第二关：认为软件测试人员所要具备的基本素质，如果遇到问题会怎样处理，如果得不到研发人员的配合（就是研发说这个不是问题）你又会怎么处理？然后就是一些基本概念，比如软件测试的流程有哪些？如果我上任了，首先会怎么开始自己的工作计划。
（前两关通过了后面这个就好过多了）
第三关：像我介绍了一下公司的情况，告诉我主要针对什么内容的测试，会不会使用数据库。告诉我大概要做哪些内容，详细的可以上岗以后慢慢熟悉。
大概就这么多了，这对没有经过这一关的不知道有没有帮助，仅供参考吧
我觉得就像李波说的，关键是要给对方留下好印象:)

面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问，这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会：
你可以问：
1.           贵公司近期和远期的发展目标是什么？
2.           贵公司的主要竞争对手有哪些？
3.           贵公司有多少开发人员有多少测试人员？
4.           贵公司又进一步扩充测试人员的计划吗?
5.           如果我有幸能进入贵公司的话，我有怎么样的发展？
6.           测试人员的沟通能力很重要，贵公司有规范的沟通渠道吗？
7.           请介绍一下贵公司的福利情况。
8.           请问我什么时候能知道结果？

嵌入式软件测试的10大秘诀

摘要　　1.懂得使用工具；2.尽早发现内存问题；3.深入理解代码优化；4.不要让自己大海捞针；5.重现并隔离问题；6.以退为进；7.确定测试的完整性；8.提高代码质量意味着节省时间；9.发现它，分析它，解决它；10.利用初学者的思维

　　在嵌入式软件开发过程中，一般来说，花在测试和花在编码的时间比为3:1(实际上可能更多)。这个比例随着你的编程和测试水平的提高而不断下降，但不论怎样，软件测试对一般人来讲很重要。很多年前，一位开发人员为了对嵌入式有更深层次的理解，向Oracle询问了这样的一个问题:我怎么才能知道并懂得我的系统到底在干些什么呢　Oracle面对这个问题有些吃惊，因为在当时没有人这么问过，而同时代的嵌入式开发人员问的最多的大都围绕“我怎么才能使程序跑的更快”、“什么编译器最好”等肤浅的问题。所以，面对这个不同寻常却异乎成熟的问题，Oracle感到欣喜并认真回复了他:你的问题很有深度很成熟，因为只有不断地去深入理解才有可能不断地提高水平。并且Oracle为了鼓励这位执着的程序员，把１０条关于嵌入式软件开发测试的秘诀告诉了他:

1.懂得使用工具
2.尽早发现内存问题
3.深入理解代码优化
4.不要让自己大海捞针
5.重现并隔离问题
6.以退为进
7.确定测试的完整性
8.提高代码质量意味着节省时间
9.发现它，分析它，解决它
10.利用初学者的思维
　　这十条秘诀在业界广为流传，使很多人受益。本文围绕这十条秘诀展开论述。

１.懂得使用工具

　　 通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导致灾难性的后果，即使是非安全性系统，由于大批量生产也会导致严重的经济损失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备，对门益复杂的嵌入式软件进行快速有效的测试愈加显得重要。

　　 就象修车需要工具一样，好的程序员应该能够熟练运用各种软件工具。不同的工具，有不同的使用范围，有不同的功能。使用这些工具，你可以看到你的系统在干些什么，它又占用什么资源，它到底和哪些外界的东西打交道。让你郁闷好几天的问题可能通过某个工具就能轻松搞定，可惜你就是不知道。那么为什么那么多的人总是在折腾个半死之后才想到要用测试工具呢？原因很多，主要有两个。一个是害怕，另一个是惰性。害怕是因为加入测试用具或测试模块到代码需要技巧同时有可能引入新的错误，所以他们总喜欢寄希望于通过不断地修改重编译代码来消除bug,结果却无济于事。懒惰是因为他们习惯了使用printf之类的简单测试手段。下面来介绍一些嵌入式常用的测试工具。

.源码级调试器[Source-level Debugger]

这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能，是嵌入式调试最根本有效的调试方法。比如VxWorks TornadoII提供的gdb就属于这一种。

.简单实用的打印显示工具[printf]

printf或其它类似的打印显示工具估计是最灵活最简单的调试工具。打印代码执行过程中的各种变量可以让你知道代码执行的情况。但是，printf对正常的代码执行干扰比较大(一般printf占用CPU比较长的时间)，需要慎重使用，最好设置打印开关来控制打印。

.ICE或JTAG调试器[In-circuit Emulator]

ICE是用来仿真CPU核心的设备，它可以在不干扰运算器的正常运行情况下，实时的检测CPU的内部工作情况。像桌面调试软件所提供的：复杂的条件断点、先进的实时跟踪、性能分析和端口分析这些功能，它也都能提供。ICE一般都有一个比较特殊的CPU，称为外合(bond-out)CPU。这是一种被打开了封装的CPU，并且通过特殊的连接，可以访问到CPU的内部信号，而这些信号，在CPU被封装时，是没法“看到”的。当和工作站上强大的调试软件联合使用时，ICE就能提供你所能找到的最全面的调试功能。但ICE同样有一些缺点：昂贵；不能全速工作；同样，并不是所有的CPU都可以作为外合CPU的，从另一个角度说，这些外合CPU也不大可能及时的被新出的CPU所更换。JTAG(Joint Test Action Group)虽然它最初开发出来是为了监测IC和电路连接，但是这种串行接口扩展了用途，包括对调试的支持。AD公司为Blackfin设计的 Visual Dsp++就支持高速的JTAG调试。

.ROM监视器[ROM Monitor]

ROM监控器是一小程序，驻留在嵌入系统ROM中，通过串行的或网络的连接和运行在工作站上的调试软件通信。这是一种便宜的方式，当然也是最低端的技术。它除了要求一个通信端口和少量的内存空间外，不需要其它任何专门的硬件。并提供了如下功能：下载代码、运行控制、断点、单步步进、以及观察、修改寄存器和内存。因为ROM监控器是操作软件的一部分，只有当你的应用程序运行时，它才会工作。如果你想检查CPU和应用程序的状态，你就必须停下应用程序，再次进入ROM监控器。

.Data监视器[Data Monitor]

这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容，还可以收集并以图形形式显示各个变量的变化过程。

.OS监视器[Operating System Monitor]

操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。一方面，这些监视器能够为你呈现事件之间的关系和时间联系；另一方面，还可以提供对信号量优先级反转、死锁和中断延时等问题的诊断。

.性能分析工具[Profiler]

可以用来测试CPU到底耗在那里。profiler工具可以让你知道系统的瓶颈在那里、CPU的使用率以及需要优化的地方。

.内存测试工具[Memory Teseter]

可以找到内存使用的问题所在，比如内存泄露、内存碎片、内存崩溃等问题。如果发现系统出现一些不可预知的或间歇性的问题，就应该使用内存测试工具测测看。

.运行跟踪器[Execution Tracer]

可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。这种工具主要用于测试代码逻辑，可以在大量的事件中发现异常的那些。

.覆盖工具[Coverage Tester]

主要显示CPU具体执行了那些代码，并让你知道那些代码分支没有被执行到。这样有助于提高代码质量并消除无用代码。

.GUI测试工具[GUI Tester]

很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试足根掘用户输入响应时间进行的。GUI测试工具可以作为脚本工具有开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程(Rational公司的robot和Mercury的 Loadrunner工具是杰出的代表)。很多嵌入式设备没有GUI，但常常可以对嵌入式设备进行插装来运行GUI测试脚本，虽然这种方式可能要求对被测代码进行更改，但是节省了功能测试和回归测试的时间。

.自制工具[Home-made tester]

在嵌入式应用中，有时候为了特定的目的，需要自行编写一些工具来达到某种测试目的。本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上帮了大忙,帮公司找到了几个隐藏很深的bug

２.尽早发现内存问题

　　 内存问题危害很大，不容易排查，主要有三种类型:内存泄露、内存碎片和内存崩溃。对于内存问题态度必须要明确，那就是早发现早“治疗”。在软件设计中，内存泄露的“名气”最大，主要由于不断分配的内存无法及时地被释放，久而久之，系统的内存耗尽。即使细心的编程老手有时后也会遭遇内存泄露问题。有测试过内存泄露的朋友估计都有深刻地体验，那就是内存泄露问题一般隐藏很深，很难通过代码阅读来发现。有些内存泄露甚至可能出现在库当中。有可能这本身是库中的bug，也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。

　　 在很多时候，大多数的内存泄露问题无法探测，但可能表现为随机的故障。程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是很高，那么重启系统问题也不大；但，如果用户对系统稳定很高，那么这种故障就有可能使用户对产品失去信心，同时也意味着你的项目是个失败的项目。由于内存泄露危害巨大，现在已经有许多工具来解决这个问题。这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。每个工具都有利有弊，不过总的来说，用要比不用好。总之，负责的开发人员应该去测试内存泄露的问题，做到防患于未然。

　　 内存碎片比内存泄露隐藏还要深。随着内存的不断分配并释放，大块内存不断分解为小块内存，从而形成碎片，久而久之，当需要申请大块内存是，有可能就会失败。如果系统内存够大，那么坚持的时间会长一些，但最终还是逃不出分配失败的厄运。在使用动态分配的系统中，内存碎片经常发生。目前，解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首，然后改进相应的部分。

　　 由于动态内存管理的种种问题，在嵌入式应用中，很多公司干脆就禁用malloc/free的以绝后患。

　　 内存崩溃是内存使用最严重的结果，主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。这种内存崩溃造成系统故障是随机的，而且很难查找，目前提供用于排查的工具也很少。

　　 总之，如果要使用内存管理单元的话，必须要小心，并严格遵守它们的使用规则，比如谁分配谁释放。

３.深入理解代码优化

　　 讲到系统稳定性，人们更多地会想到实时性和速度，因为代码效率对嵌入式系统来说太重要了。知道怎么优化代码是每个嵌入式软件开发人员必须具备的技能。就象女孩子减肥一样，起码知道她哪个地方最需要减，才能去购买减肥药或器材来减掉它。可见，代码优化的前提是找到真正需要优化的地方，然后对症下药，优化相应部分的代码。前面提到的profile(性能分析工具，一些功能齐全IDE都提供这种内置的工具)能够记录各种情况比如各个任务的CPU占用率、各个任务的优先级是否分配妥当、某个数据被拷贝了多少次、访问磁盘多少次、是否调用了网络收发的程序、测试代码是否已经关闭等等。

　　 但是，profile工具在分析实时系统性能方面还是有不够的地方。一方面，人们使用profile工具往往是在系统出现问题即CPU耗尽之后，而profile工具本身对CPU占用较大，所以profile对这种情况很可能不起作用。根据Heisenberg效应，任何测试手段或多或少都会改变系统运行，这个对profiler同样适用！

　　 总之，提高运行效率的前提是你必须要知道CPU到底干了些什么干的怎么样。

４.不要让自己大海捞针

　　 大海捞针只是对调试的一种生动比喻。

　　 经常听到组里有人对自己正在调试的代码说shit！可以理解，因为代码不是他写的，他有足够的理由去shit bug百出的代码，只要他自己不要写出这种代码，否则有一天同组的其它人可能同样会shit他写的代码。为何会有大海捞针呢？肯定是有人把针掉到海里咯；那针为何会掉在海里呢？肯定是有人不小心或草率呗。所以当你在抱怨针那么难找的时候，你是否想过是你自己草率地丢掉的。同样，当你调试个半死的时候，你是否想过你要好好反省一下当初为了寻求捷径可能没有严格地遵守好的编码设计规范、没有检测一些假设条件或算法的正确性、没有将一些可能存在问题的代码打上记号呢？关于如何写高质量请参考林锐的《高质量c++/c编程指南》或《关于C的0x8本“经书”》(http://blog.sina.com.cn/u/4a317b79010004mc)。

　　 如果你确实已经把针掉在海里是，为了防止在找到之前刺到自己，你必须要做一些防范工作，比如戴上安全手套。同样，为了尽能地暴露和捕捉问题根源，我们可以设计比较全面的错误跟踪代码。怎么来做呢？尽可能对每个函数调用失败作出处理，尽可能检测每个参数输入输出的有效性包括指针以及检测是否过多或过少地调用某个过程。错误跟踪能够让你知道你大概把针掉在哪个位置。

５.重现并隔离问题

　　 如果你不是把针掉在大海了，而是掉在草堆里，那要好办写。因为至少我们可以把草堆分成很多块，一块一块的找。对于模块独立的大型项目，使用隔离方法往往是对付那些隐藏极深bug的最后方法。如果问题的出现是间歇性的,我们有必要设法去重现它并记录使其重现的整个过程以备在下一次可以利用这些条件去重现问题。如果你确信可以使用记录的那些条件去重现问题，那么我们就可以着手去隔离问题。怎么隔离呢？我们可以用#ifdef把一些可能和问题无关的代码关闭，把系统最小化到仍能够重现问题的地步。如果还是无法定位问题所在，那么有必要打开“工具箱”了。可以试着用ICE或数据监视器去查看某个可疑变量的变化；可以使用跟踪工具获得函数调用的情况包括参数的传递；检查内存是否崩溃以及堆栈溢出的问题。

６.以退为进

　　 猎人为了不使自己在森林里迷路，他常常会在树木上流下一些标记，以备自己将来有一天迷路时可以根据这些标记找到出路。对过去代码的修改进行跟踪记录对将来出现问题之后的调试很有帮助。假如有一天，你最近一次修改的程序跑了很久之后忽然死掉了，那么你这时的第一反映就是我到底改动了些什么呢，因为上次修改之前是好的。那么如何检测这次相对于上次的修改呢？没错，代码控制系统SCS或称版本控制系统VCS(Concurrent Version Control,CVS是VCS的演化版本)。将上个版本check in下来后和当前测试版本比较。比较的工具可以是SCS/VCS/CVS自带的diff工具或其它功能更强的比较工具，比如BeyondCompare和ExamDiff。通过比较，记录所有改动的代码，分析所有可能导致问题的可疑代码。

７.确定测试的完整性

　　 你怎么知道你的测试有多全面呢？覆盖测试(coverage testing)可以回答这个问题。覆盖测试工具可以告诉你CPU到底执行了那些代码。好的覆盖工具通常可以告诉你大概20%到40%代码没有问题，而其余的可能存在bug。覆盖工具有不同的测试级别，用户可以根据自己的需要选择某个级别。即使你很确信你的单元测试已经很全面并且没有dead code,覆盖工具还是可以为你指出一些潜在的问题，看下面的代码:

if (i >= 0 && (almostAlwaysZero == 0 || (last = i)))

如果almostAlwaysZero为非０,那么last=i赋值语句就被跳过，这可能不是你所期望的。这种问题通过覆盖工具的条件测试功能可以轻松的被发现。

　　 总之，覆盖测试对于提高代码质量很有帮助。

８.提高代码质量意味着节省时间

　　 有研究表明软件开发的时间超过80%被用在下面几个方面:

.调试自己的代码(单元测试)

.调试自己和其他相关的代码(模块间测试)

.调试整个系统(系统测试)

更糟糕的是你可能需要花费10-200倍的时间来找一个bug,而这个bug在开始的时候可能很容易就能找到。一个小bug可能让你付出巨大的代价，即使这个bug对整个系统的性能没有太大的影响，但很可能会影响让那些你可以看得到的部分。所以我们必须要养成良好的编码和测试手段以求更高的代码质量，以便缩短调试的代码。

９.发现它，分析它，解决它

　　 这世界没有万能的膏药。profile再强大也有力不从心的时候；内存监视器再好，也有无法发现的时候；覆盖工具再好用，也有不能覆盖的地方。一些隐藏很深的问题即使用尽所有工具也有可能无法查到其根源，这时我们能做的就是通过这些问题所表现出来的外在现象或一些数据输出来发现其中的规律或异常。一旦发现任何异常，一定要深入地理解并回溯其根源，直到解决为止。

１０.利用初学者的思维

　　 有人这样说过：“有些事情在初学者的脑子里可能有各种各样的情况，可在专家的头脑里可能就很单一”。有时候，有些简单的问题会被想的很复杂，有些简单的系统别设计的很复杂，就是由于你的“专家思维”。当你被问题难住时，关掉电脑，出去走走，把你的问题和你的朋友甚至你的小狗说说，或许他们可以给你意想不到的启发。

　　总结:嵌入式调试也是一门艺术。就想其它的艺术一样，如果你想取得成功，你必须具备智慧、经验并懂得使用工具。只要我们能够很好地领悟Oracle这十条秘诀，我相信我们在嵌入式测试方面就能够取得成功。
 

用手机发短信对很多人来说肯定是家常便饭。而输入文字当然离不开输入法，手机中自带的输入法一般只能一个字一个字的输入，对于短信狂人来说，这是何等的折磨人。而使用智能手机的朋友就有福，因为我们可以安装其它更高效的输入法来代替手机自带的输入法。但是，现在手机输入法也比较多，哪一款更适合自己的拇指呢？且来观一场华山论“键”，看看几款较流行的手机输入法中谁将胜出！

擂台搭建，准备比武——如何测试

安装的中文字库和字库驱动版本的不同，不同时期版本的输入法，对中文的输入表现都会有着差异。为达到测试环境的普遍性和代表性，笔者在手机没有安装字库等的情况下以安装官方最新版本的输入法程序为准（最新版本以截稿日期为准）。通过一段时间的使用，对每种输入法的输入（选字）速度、中英数混合输入、智能联想（包括自造词、模糊音）、特殊功能等方面进行评测。

这里笔者采用官方原版的输入法为测试平台，但是某些原版输入法不是最合适的，选择一些经过高手修改后的输入法似乎更好。

摩拳擦掌，欲比高低——参评软件介绍

适用机型：基本上所有的S60机型都支持（S60第三版目前还不支持），常见的典型机型有：3230, 6260, 6600, 6630, 6670, 6680, 6681, 7610, N70, N72。
 
1、国笔输入法
 
国笔输入法是“国笔嵌入式智能文字输入系统”的简称。是由广东国笔科技有限公司开发的，在众多智能手机用户中反映良好。
 
下载地址：http://down.cbifamily.com/down/200713/guobi.rar
 
2、A4输入法
 
A4输入法是北京中天旗舰科技发展有限责任公司开发的一款手机输入法软件，推出时间并不长，算是手机输入法中的新秀。
 
下载地址：http://down.cbifamily.com/down/200713/a4.rar
 
3、掌上狂拼输入法
 
掌上狂拼输入法来自北京中文之星数码科技有限公司，中文之星可能很多朋友都听说过，这是个比较早的输入法公司了。
 
下载地址：http://down.cbifamily.com/down/200713/csfep.rar

将遇良材，棋逢对手——详细功能比拼

1、文字输入比拼
 
A、国笔输入法
 
在汉字的单字输入上与普通输入习惯没有多大区别（以拼音输入模式为例），按照拼音规则键入数字，在候选框中便列出了符合的字。我们可以通过点击“*”键或“笔形键”进行输入法模式的选择，这一点让用户觉得不习惯的问题就是“*”、“#”键的功能和我们常用的各种输入法相反，使用上感到不便。在词组和短语的输入方式上可以一次性的将词组或短句的拼音音节全部输完，然后依次选择需要的词组。该输入法具备“简拼输入”功能，只需要输入汉字拼音首字母的组合（输入＃做间隔）就可以候选最合适的词组，比如要输入“家用”，则输入“j#y”，然后通过方向键选择就可以找到“家用”两个字了（图1）。在英文输入方面，该输入法支持智能英文和传统字母输入两种方式，由于这不是我们常用的输入方式，所以在此不加以深入。

图一

B、A4输入法
 
A4输入法拼音输入时支持连续整句输入，一次最多可输入60个字符（图2）。该输入法也具有类似国笔输入法“简拼输入”的功能，不过是使用“*”键切分拼音。

图2

我们可以看到该输入法的文字候选框是跟随光标的，而不是像其它输入法那样置于底部，候选框跟随光标的方式类似电脑上的输入法，在视觉习惯上让人更容易接受。而掌上狂拼在这一方面就有缺陷了，文字多到底部时就会被候选框挡住半行，颇有不便。但是笔者个人觉得，A4输入法候选框的配色不是很好，背景为灰色，与文字的对比度不大，有时看着吃力。在英文输入方面也比较方便和智能。输入英文时会根据内置词库自动将输入的部分单词补全，而且在输入时点击手机向上键可以直接切换英文大小写。
 
C、掌上狂拼输入法
 
在常规词组和短语输入上掌上狂拼输入法没有什么特别之处，同样也支持一句话连续输入拼音。不过有一个不足的地方就是对于存在多个组合的按键输入，它要选择输入的拼音，而且输入拼音时选择待选字有些慢。在英文输入方面和以上大同小异，为了节省篇幅这里就不一一介绍了，大家可以自己体会。
 
2、中英数混合输入
 
A、国笔输入法
 
在文字输入过程中，中文、英文、数字、符号混合输入也是常有，国笔支持同屏整合输入，比如在拼音模式下要输入数字“2006”，只要按“2”、“0”、“0”、“6”键，然后点击手机向上方向键就可以完成输入，而点击“*”键则可以候选出相应的英文。点击“#”会进入到符号输入状态。值得一提的是该输入法支持智能化标点输入。
 
B、A4输入法
 
在中英数混合输入方面，该输入法支持拼音状态下直接输入英文，无候选框时，按“1”键后直接进行英文输入，有候选框时，先按“C”键退出即可。输入符号则是直接点击“*”后进行选择，不过A4的标点符号输入不如国笔输入法的标点输入来得智能。好在A4支持阿拉伯数字和中文数字快速转换，按“*”键后，可输入多种形式的数字（图3）。

图3

C、掌上狂拼输入法
 
在中英数混合输入方面，掌上狂拼表现一般，在拼音输入状态下，要输入数字，需要首先点击“1”键，然后输入所需数字，点击向上方向键方可完成数字的输入。
 
3、智能联想
 
A、国笔输入法
 
在智能联想方面，不但具备普通的单字联想，对于三字以上的词还可以连续联想，除词首第一个字要输入代码外，其它字都可以在候选行找到联想字。该输入法也支持“模糊音功能”，如“c—ch”、“z—zh”。
 
B、A4输入法
 
该输入法同样支持模糊音输入，特点的地方在于我们可以自行配置模糊音。连续输入拼音后，所输的词句即可被自动记忆。记忆后的词组可以通过简拼快速调出（图4）。

图4

C、掌上狂拼输入法
 
在智能输入方面，输入法的字词联想和短句联想的作用和上述两种输入法的联想功能是类似的，但是其联想能力要稍微弱一点。不过其对自造词快捷调用的功能也是不错的（按“1”键快捷调出中文自造词组），比如我们以短句的方式输入“家用电脑数字家庭”完成自造词的步骤。该句子中首个汉字“家”的拼音的第一个字母“j”在数字键“5”上，所以调出方法应连续按数字键“1”和“5”，便可以看到整个句子（图5）。

图5

4、特殊功能
 
A、国笔输入法
 
在特殊功能方面，其具备“同步联系人到自造词功能”，会将手机通讯簿中的联系人姓名自动添加为自造词，相当方便。
 
B、A4输入法
 
可以快速网址输入，在英文输入模式下要输入网址前缀“http://www.”，只需连续按键“488711”即可。而且有趣的是，还有专门的表情输入（图6）。最值得称道的就是该输入法可以很方便的备份用户词库，在A4输入法设置中可以进行用户词库的备份和恢复，即使格机后也不会丢失词库（自定义词库文件位置是C/System/fep/ZTA4.DAT）。

图6

C、掌上狂拼输入法
 
掌上狂拼的人性化比较好，不仅可以设置模糊音，输入法的选择也是可以自行设置的，而且“#”号键切换输入法时，其出现的先后顺序也是可以调整的（图7）。天下第一，榜上有名——横评总结 三款输入法都支持复制和粘贴，词组输入，模糊音，中英数混合输入，以及词语联想和记忆功能。但是在细微之处还是有差别的。

图7

A、国笔输入法
 
     优点：输入速度快，功能和联想记忆力都比较强大，上手也比较容易，拥有一些较实用的特殊功能。
 
     缺点：内存占用大，有些基本设置违背传统习惯。
 
B、A4输入法
 
     优点：功能较强，支持长句输入，可以备份和恢复用户词库。对数字键盘利用充分，可以不使用方向键就完成文字输入。
 
     缺点：内存占用稍大，与系统冲突问题没有在新版本中得到解决。
 
C、掌上狂拼输入法
 
     优点：人性设置较丰富，调用自造词方便，在电话本中能自动切换输入法。
 
     缺点：操作上不太习惯，输入速度一般，候选框不合理，存在系统冲突问题。

我们且来给它们的各项能力打个分，如下表。

             输入速度 联想能力   记忆功能  特殊能力     人性设置 推荐级数
国笔      ★★★★ ★★★★ ★★★★       ★★★          ★★         ★★★★
A4        ★★★★      ★★★   ★★★          ★★★          ★★★       ★★★★
掌上狂拼  ★★★   ★★★   ★★★★         ★★           ★★★★      ★★★

软件测试之7×24性能测试注意事项

一、检查并记录运行环境情况
 1、当前运行的程序（不必要的都关闭）
 2、当前内存使用情况
 3、当前磁盘使用情况
 4、web服务器日志记录设置，没有必要的话关闭日志记录或清空日志
 5、测试开始前web服务启动后不要进行访问，让服务器空转5分钟以上，并监控内存、CPU的使用状况
 6、服务器启动后进行一小段时间的访问，让服务端完成初始化工作（热身）
 7、以上工作完成、各项指标正常后再进行测试
 8、最好挂一牌子写上“正在测试，勿动，请与×××联系”
 9、如果可能测试网络环境与工作环境隔离开
 10、检查网络带宽是否足够
 11、系统中当前运行进程是否正常
 13、检查是否有计划任务，如果不需要就关闭
 14、关闭所有无关的系统服务和进程

二、用例及测试数据准备
 1、准备大量的测试数据（数据量太小的话会导致长时间运行后系统使用缓存而不进行运算）
 2、每个测试用例返回的记录数不要过大或过小，要控制返回记录数过多或为空的用例的个数
 3、用例数据会直接影响相应时间，所以应选择典型的用例数据

三、测试工具及客户端设置
 1、加大采样时间间隔
 2、不记录日志
 3、不保存临时数据
 4、保证工具有足够的临时空间
 5、设置屏幕保护
 6、执行期间锁定客户端，并最好挂一牌子写上“正在测试，勿动，请与×××联系”
 7、客户端带宽是否有限制，计算单个请求的平均流量大小并估计需要的带宽
 8、关闭所有计划任务，例如杀毒软件自动更新、自动杀毒等
 9、客户端系统分区及存放结果的分区最好为NTFS格式，否则可能由于分区格式限制导致测试停止

1、搭建独立的软件测试环境有利于重现开发环境无法重现的BUG。这样说也许会显得抽象，我们不妨举个简单的例子来说明：某个软件系统由模块A、B、C组成（对应开发人员A、B、 C）。起初开发人员比较偷懒，不想重新搭建独立的测试环境（特别是搭建过程比较复杂的情况下），而是让测试人员连到他们各自的开发机器上分别测试他们各自负责的模块。各自的模块功能很正常，但一旦整合作为一个系统向用户提供功能时，就不一定正常了，有可能在模块A录入的数据在模块B查询不到，或是模块间的接口有问题等。除此以外，还可能有其他因素妨碍开发环境重现BUG。总之，搭建一个与典型用户环境配置一致的测试环境是有效测试的重要前提。

2、搭建独立的测试环境便于开发人员并行地修复BUG。如果对开发环境进行测试，开发人员要修复BUG必须先重现BUG，然后修改相关代码，并进行程序调试。而在测试人员还未测试完系统前，开发人员是不能对程序进行修改、更新。只有等测试人员测试完后才能进行BUG修复（现实中也有这样的情况：测试员还未测试完开发人员就更新修复部份BUG的程序。这种做法比较危险，开发人员若修复得不好可能会导致程序无法运行，势必影响测试进度）。串行的工作方式也很耗费时间，甚至影响进度。正确的做法应该搭建独立的测试环境，测试人员提出BUG后开发人员在开发机上重现并修复，并验证修复后的效果，两种环境互不干扰。

3、搭建独立的测试环境可以验证安装软件的全过程。即进行安装测试，用以检查安装文件是否有错漏，软件在指定的操作系统下能否正常安装，各种配置项是否有错漏等。

4、搭建独立的测试环境可以避免环境被破坏导致测试无法进行的意外。如果选择开发环境来进行测试，开发人员进行某项误操作后发生系统崩溃或者系统不能正常运行的意外，此时测试工作也不得不停止。

1. 响应时间

我把“响应时间”的概念确定为“对请求作出响应所需要的时间”，把响应时间作`为用户视角的软件性能的主要体现。响应时间划分为“呈现时间”和“系统响应时间”两个部分。

其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间、而“响应时间”指J2EE应用服务器从请求发出开始到客户端接受到数据所消耗的时间。性能测试一般不关注“呈现时间”，因为呈现时间很大程度上取决于客户端的表现。在这里我们没有使用很多性能测试定义中的概念——“系统响应时间”定义为“应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间”，没有使用这种标准的原因是，可以使用一些编程技巧在数据尚未完全接收完成时进行呈现来减少用户感受到的响应时间，对于HNDLZCGLXT的这个项目中，我们针对C/S系统采用前者标准，对于B/S我们依然采用后一种标准。

2. 并发用户数

我把“并发用户数”与“同时在线数”进行区别对待，我的“并发用户数”的标准是：并发用户数取决于测试对象的目标业务场景，因此，在确定这个“并发用户数” 前，必须（必要）先对用户的业务进行分解、分析出典型的业务场景（也就是用户最常使用、最关注的业务操作），然后基于场景采用某些方法（有多种计算并发用户数的数学模型与公式）获得“并发用户数”。

这样做的原因是：假设一个应用系统、最高峰有500人同时在线、但这500人却不是并发用户数、因为假设在一个时间点上、有50%的人在填写复杂的表格（填写表格动作对服务器没有任何负担、只有在“提交”动作的时候才会对服务器系统构成压力）、有40%的人在不停的从一个页面跳转到另外一个页面（不停发出请求与回应、产生服务器压力）、还有10%的人挂在线上，没有任何操作在发呆：）（没有对服务器构成压力的动作）。因此只有那40%的人真正对服务器产生了压力，从这里例子可以看出、并发用户数关心的是不但是业务并发用户数、还取决于业务逻辑、业务场景。因此我们需要本文第六部分性能测试文档4、5、6。

3. 吞吐量

我把吞吐量定义为“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力，对于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。我们在以下方面利用这个指标：

（1） 用来协助设计性能测试场景，衡量性能测试是否达到了预计的设计目标、比如J2EE应用系统的连接池、数据库事务发生频率、事务发生次数。

（2） 用来协助分析性能瓶颈、参照本文第二部分总的RBI方法。

4. 性能计数器

性能计数器式描述服务器或操作系统性能的一些数据指标、例如对WINDOWS来说使用内存数、CPU使用率、进程时间等都是常见的计数器。

对于性能计数器这个指标来说、需要考虑到的不但有硬件计数器、web服务器计数器、Weblogic服务器计数器、Servlet性能计数器、EJB2的性能计数器、JSF性能计数器、JMS性能计数器。找到这些指标是使用性能计数器的第一步、关键是找到性能瓶颈、确定系统阀值、提供优化建议才是性能计数器使用的关键。性能计数器复杂而繁多、与代码上下文环境、系统配置情况、系统架构、开发方式、使用到的规范实现、工具、类库版本都有紧密的联系、在此不作赘述。

5. 思考时间

我把思考时间确定为“休眠时间”。从业务系统的角度来说，这个时间指的是用户在惊醒操作时、每个请求之间的时间间隔、从自动化测试的角度来说、要真实的测试模拟用户操作、就必须在测试脚本中让各个操作之间等待一段时间、体现在脚本上就是在操作之间放置一个Think的函数，体现为脚本中两个请求语句之间的间隔时间、不同的测试工具提供了不同的函数或方法来实现思考时间、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。
性能测试方法论

1. SEI负载测试计划过程

目标：产生一个清晰、好理解、可验证的负载测试计划

内容：关注6个区域：目标、用户、用例、生产环境、测试环境、测试场景

工具：IBM、HP、OpenSource工具都支持。需有文档配合

2. RBI方法

目标：快速识别性能瓶颈

内容：重点测试“吞吐量”指标，因为RBI认定80%的系统性能瓶颈由吞吐量造成。

按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能

工具：IBM、HP、OpenSource工具都支持。需使用分析模块、根据Weblogic、Oracle

区别有专门的工具实现RBI。

3. 性能下降曲线分析法

目标：性能随着用户数的增加而出现下降趋势的曲线分析、查看性能下降的环境点与上

下文。确定性能阀值。

内容：通过单用户区域、性能平坦区域、压力区域、性能拐点进行监控和分析。

工具：IBM、HP、OpenSource工具都支持。IBM报表功能更强。

4. HP（LoadRuner）性能分析法

特点：侧重于该厂商的性能分析方法、主要体现在需求收集、VU脚本。

缺点：没有对测试计划阶段、测试设计阶段的具体行为、方法、目的进行描述。方法局

限于LoadRuner产品的特性上。不能通用。

5. IBM（Rational UP）软件测试方法

特点：软件产品生命周期RUP的实现、侧重于迭代测试、宽广的方法论。可适合任意

测试环境及方法、工具。

缺点：需要根据测试环境进行剪裁、难以掌握、但掌握后非常成熟、高品质。

工具：涉及到IBM Rational 测试环境的所有软件、功能强大。

6. PTGM性能测试模型

内容：一个非常适合行业用户（电力、金融、政务、制造）的性能测试过程模型。规范

化的测试模型、每个环节都做到迭代测试、每一个过程的工作产品明显可察、测

试流程、测试上下文方面很优秀。包括以下环节：前期准备、工具引入、测试计

划、测试设计与开发、测试执行与管理、测试分析。

工具：可以使用任意商业工具全新部署测试流程、不限于任何厂商工具的局限、也可以

使用部分工具即可完成整个流程、或结合自己需要基于OpenSource工具进行定

制。个人倾向使用多个产品的整合、综合使用、扬长避短。

性能测试方法

1. 性能测试

性能测试方法通过模拟生产运行的业务压力量和使用场景组合测试性能是否能够满足需要。具备三个特点：

（1） 这种方法的目的是验证系统是否具有系统宣称具有的能力。

（2） 这种方法需要事先了解被测试系统典型场景、并确定性能目标。

（3） 这种方法要求在已确定的环境下运行

使用IBM Rational Performance Tester、HP Mercury LoadRuner、OpenSTA、Apache ab、Jmeter、QALoad 、TagUnit、Java Test Runner。

2. 负载测试

负载测试用来测定系统饱和状态、确定阀值。其特点有：

（1） 这种方法的目的是找到系统处理能力的极限；通过“检测、加压、阀值”手段找到如“响应时间不超过10秒”，“服务器平均CPU利用率低于65%”等指标。

（2） 这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景、另外HP Mercury LoadRuner在使用该方法进行“加压”的时候必须选择典型场景。

（3） 这种性能测试方法一般用来了解系统的性能容量，或者是配合性能调优的时候来使用。特别是该项目的Weblogic Server和Oracle数据库的性能调优。

3. 压力测试

压力测试方法测试目标系统在一定饱和状态下，例如CPU、内存等在饱和状态下、系统能够处理的session的能力，以及系统是否会出现错误。该方法需要在系统cache调优与pool优化方面着手。该方法具备以下特点：

（1） 该方法的目的是检查系统处于压力情况下的，应用的表现。如增加VU数量、节点数量、并发用户数量等使应用系统的资源使用保持一定的水平，这种方法的主要目的是检验此时的应用表现，重点在于有无错误信息产生，系统对应用的响应时间等。

（2） 该方法通过模拟负载在实现压力。这种模拟需要考虑的层面很多、首先、模拟必须是有效的，我的经验是需要结合业务系统和软件架构来定制模拟指标、我测试过一些国内生产的压力测试工具、他们使用通用的指标来考量、造成很多信息反馈有很大的水分。需要考虑的层面如：Oracle I/O、JVM GC、Conn Pool等。

（3） 该方法还可以测试系统的稳定性。这里的技巧在于“什么样的平台定义一个多长的压力测试时间让其稳定运行才是科学的？”

4. 配置测试

配置测试方式是指在测试前、测试中、测试后三个时间段通过对被测系统的软件/硬件环境的调整，了解各个不同环境对系统性能影响的程度，从而找到系统各个资源的最优分配原则。它具备以下特点：

（1） 该方法的目的是了解各个不同的因素对系统性能影响的程度、从而判断出最值得进行的调优操作。该方法不同于与“功能测试”中涉及到的“配置测试”。

（2） 该方法存在很大的灵活性、可以在测试环节的各个时间进行、但是什么时候开始、什么时候暂停、什么时候结束才是运用这个方法的关键。同时也是HNDLZCGLXT考量性能测试服务供应商的关键。

5. 并发测试

该方法通过模拟用户的并发访问，测试多用户环境并发访问同一个应用、同一个模块或者数据记录时系统是否存在死锁或者其他性能问题。该方法特点是：

（1） 可以发现应用系统的全局性性能问题。

（2） 该方法可以在开发工作的各个环节使用可以使用多个工具的配合。如：Compuware公司的DevPartner工具、EJ-Technologie公司的J Profile工具，QUEST公司的J Probe工具等。

（3） 并发测试一般关注的问题是：

问 题 类 别

问 题 描 述

内存问题

是否有内存泄露（COM+，JAVA）

是否有太多的临时对象（JAVA）

是否有太多不合理声明的超过设计生命周期的对象

数据库问题

是否有数据库死锁

是否经常出现长事务

线程/进程问题

是否出现线程/进程同步失败

其他问题

是否出现资源争用导致的死锁

是否没有正确处理异常（如超时）导致的系统死锁

6. 可靠性测试

这里说的“可靠性测试”并不等同于“获得软件的可靠性”，软件的可靠性是一个很大的命题，这里指的可靠性测试是通过给系统加载一定的业务压力（例如：资源在80%~90%的使用率），让应用系统运行一段时间、测试系统是否稳定运行。这里有三点需要注意：

（1） 在使用该测试前需要目的系统的资源使用率已经达到70%~90%。即在这样的苛刻环境下运行该应用系统。

（2） 应用系统运行起来后，加载业务压力使应用系统资源达到90%。比如：该J2EE系统中设置的JDBC数据库连接池定义为30，那么加载业务压力使连接达到27。

（3） 应用系统运行起来后结合业务情况来设定一个运行时间。比如：电力资产系统要求MTBF（平均无故障时间）达到10000小时、那么我们可以认定该系统的运行时间至少需要达到三年重新启动一次。超过这个数字我们就可以认为“不可靠”。一般情况下对于这个要求、我们让J2EE系统在资源使用率90%~100%状态连续稳定的运行3天左右没有错误就可以认定该MTBF指标已经达到。

7. 失效恢复测试

该方法是针对有HACMP等冗余备份和Edge Server for LB等负载均衡的J2EE系统设计的。该方法考量系统失效恢复的时间、用户受到多大程度、多大范围的影响，并将其量化。该方法有以下特点：

（1） 一般的关键业务都会采用双机热备或负载均衡方式来实现。

（2） 该方法回答两个问题：当问题发生的时候“能支持多少用户访问”，“有多少功能不能使用”

（3） 需要说明的是，对于HNDLZCGLXT的这个项目来说，负载均衡需要仔细考虑其实现方式，这影响到性能的调优。可以考虑使用F5等硬件技术方式、也可以考虑使用 IBM WebSphere Edge Server等商业版本的软件技术方式。否则单纯对EJB 容器Weblgoic Server作集群没有意义。
性能测试分析方法

该部分着重于PTGM方法论

1. 能力验证

能力验证一般采用这样的描述：“该系统是否能在A条件下具备B能力？”。这里强调以下内容：

（1） 充分准备以下内容：硬件设备、软件环境、网络条件、基础数据

（2） 充分准备测试场景、典型的场景包括操作序列、并发用户数量条件、用例。

该部分包括使用到上述测试方法：性能测试方法、可靠性测试、压力测试、失效恢复测试

2. 规划性能

该分析方法关心的是“应该如何才能使系统具有我们要求的性能能力”，“应该如何调整系统配置，使系统能够满足增长的用户数的需要”等问题。这个部分常常使用到的测试方法是：负载测试、配置测试、压力测试。

3. 性能调优

一个标准的性能调优过程是：

（1） 确定基准环境、基准负载和基准性能指标。

（2） 调整系统运行环境和实现方法，执行测试。

（3） 记录测试结果、进行分析

在J2EE性能测试中有很多常见的错误，比如：对于某些建立在J2EE/EJB技术上的应用，在服务启动的时候，没有注意到测试之前首先进行一段时间的预热。这是因为JAVA语言的hot-spot技术特性决定的，这种技术允许weblogic第一次运行应用的时候将字节码编译为本地代码并执行，这样在后续的执行过程中执行过程会大大加快，但第一次由于存在一个编译过程会比较慢。如果使用这个时间来作为基准那么就容易得出错误的结论。

我对第2个过程比较擅长、具体下来包括硬件环境的调优、Weblogic调优、Oracle调优。这个过程中也是使用工具最多的测试环节。

4. 发现缺陷

这个环节中是交付给用户的主要工作成果。需要多和开发人员作沟通、多次迭代发现问题、根据用户的需求定义与缺陷的涉及范围、制定一个解决缺陷的优先级。由于软件永远有BUG这一真理，所以发现缺陷不是一次就能结束的工作。比较适合作为服务外包。持续进行。

 捕捉登出时间解决方案-----java中session的正确理解收藏
        前段时间要做一个捕捉用户登入和登出时间的功能，查了很多资料，做了很多测试，总结出两套方案，其中对session有了进一步的认识。

        用户的登入时间很好做了，在用户验证成功通过后，得到当前系统时间记录就行；如果系统用的是Acegi的话，可以写一个类，继承Acegi中的AuthenticationProcessingFilter.java，并覆盖其onSuccessfulAuthentication方法，故名思意，这个方法就是acegi在对用户成功通过时进行的一个附加操作的方法，在这个方法里你可以记录当前用户id、时间、ip等等日志信息到数据库中。

        但要捕捉用户的登出时间确实是很麻烦，首先要知道是http是无状态连接协议，当用户不通过注销方法登出而直接关闭浏览器或者结束进程时，服务器根本无法捕捉这个事件，不管客户端发生了什么服务器也不知道，用户仅仅从服务器那得到了一个sessionid存储在浏览器进程的内存中或者cookie中，网上很多说用window.onunload( )等js方式来捕捉用户登出事件其实也其不通，因为用户可以直接杀死进程或者在新窗口页中打开链接，然后把原窗口关闭，这时通过js捕捉到关闭浏览器事件并发送请求告诉服务器，但其实用户还并没有离开系统，只不过换了个浏览器浏览页面。还有就是通过session过期来捕捉，但在系统正常运行下session死亡只有两种可能：

1.session的持有者(即客户端浏览器)在最大无活动等待时间(MaxInactiveInterval)内无任何响应或请求  
2.session被调用invalidate()方法强制弊而当用户关闭了浏览器后标志着session将不再发送请求到服务器，服务器也不会无缘无故调用它的invalidate()方法，这样session只能等到time-out时才会销毁，如果系统设置了session的MaxInactiveInterval为-1的话，那这个session将永远存活到服务器关闭为止。

所以session不能反应出用户的活动状态，浏览器关闭事件也不能完全得出用户一定是退出了系统。

     那这个登出时间到底怎样才能得到呢？事实如此，只能降低期望了，和老大讨论了许久，最后只有两套方案行得通，如下。

 一，以性能换精度，也是我最终采用的方案，我们可以精确地得到用户登入时间，而登出时间我们得到个大概的时间就行，不需要太精确，毕竟系统不是什么很机密性的东西。采用session监听器来实现，写一类，继承HttpSessionListener，实现其public void sessionDestroyed(HttpSessionEvent arg0) 和public void sessionCreated(HttpSessionEvent arg0) 方法，当用户session失效时会走sessionDestroyed方法，在其里面得到的当前时间就是用户的大概登出时间，前提是系统session过期时间不能设置太长，要不误差就太大了，半小时就差不多。

二，以精度换性能，b/s系统的页面一般都会带有头部、脚部页面或者是框架型的，这样我们就可以在公用的头脚或主框架页中插入一个隐藏的iframe或者代码块。里头写一段js方法，window.setInterval()之类的，每隔一小段时间（假设为2分钟）向服务器发送一个空请求，目的仅仅是让服务器知道客户端还开着我的页面，不管是以哪种方式。服务器接受这个请求后，新建一个Map对象（新建一javabean类也行，里面有用户id和请求时间两个属性），put两个元素，当前用户id为value，一约定代号为key，如“userid”，另一元素请求时间为value，同样一约定代号为key，如“requesttime”；然后再以这个对象为value，sessionid为key ，set一个attribute到session当中，当下次再收到一个请求时，再重复上部操作，这样请求时间会不断更新。做完这些之后，还需要添加一个定时调度的job，每隔一小段时间（假设为3分钟），遍历session对象，从其中的map或者javabean中取出userid 和 requesttime，判断这个请求时间和当前时间的时差是否大于三分钟，如果是则说明用户已经没有再向服务器发送请求，即没有页面再用户端打开着，用户离开了，记录最后一次请求时间，也就是用户的登出时间。

       目前还没有想到其它更好的方法，现在这种机制下好像也只能这样了，还有一点需要注意，如果采用在用户登录成功时记录登录时间的方式，在要求并发数较大的时候不可行，今天对我们项目组做的一个系统进行登录过程50、100用户并发测试时，失败率极高，而问题就出在登录时向数据库记录登入时间和更新最高访问人数时出现的sql事务死锁情况，所以后来更换了方案，在登录时将当前时间为value,sessionid为key，set到session当中，当这个session过期时，通过httpsessionlistener捕捉到该事件，从session中取出该用户的登录时间和当前时间一并存入数据库，后者作为登出时间；最高访问人数也放在了application里，这样性能上提高了不少。

        如果要得到用户的在线时间的话，需要注意的是，由于一个浏览器进程共用一个session，一个浏览器中的所有标签也是共用一个session，在用户登录成功时需要通过当前sessionid判断用户是否重复登录了，如果是则在此时就不应该将当前时间set到session中，而应该保持上次存储的登录时间。

/*********** 下面再引入一下网上比较经典的描述，更有利于理解session和cookie ************/

让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：
1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。
2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。
3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端

保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

UI测试常见BUG汇总——适用于新手

录入界面

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]）

  想雇到搞软件开发的聪明人可不容易。万一一不小心，就会搞到一堆低能大狒狒。我去年就碰到这种事了。你肯定不想这样吧。听我的，没错。在树上开站立会议门都没有。

问点有难度的问题能帮你把聪明人跟狒狒们分开。我决定把我自己整理出来的软件开发者面试百问发出来，希望能帮到你们的忙。

这个列表涵盖了软件工程知识体系中定义的大多数知识域。当然，如果你只想找出类拔萃的程序员，便只需涉及结构、算法、数据结构、测试这几个话题。如果想雇架构师，也可以只考虑需求、功能设计、技术设计这些地方。

不过不管你怎么做，都要牢记一点：

这里大多数问题的答案都没有对错之分！

你可以把我的这些问题作为引子，展开讨论。例如下面有个问题是使用静态方法或是单例的缘由。如果那个面试的就此展开长篇大论，那他很有可能是个聪明能干的家伙！如果他一脸茫然的看着你，发出这种声音，很明显这就是只狒狒了。同样，想知道一个数是不是2的乘方也有很多方法，不过要是面试的人想用mod运算符，嗯……你知道我的意思吧。（你不知道也没关系，来根香蕉？）

需求

你能给出一些非功能性（或者质量）需求的例子么？
如果客户需要高性能、使用极其方便而又高度安全，你会给他什么建议？
你能给出一些用来描述需求的不同技术么？它们各自适用于什么场景？
需求跟踪是什么意思？什么是向前追溯，什么是向后追溯？
你喜欢用什么工具跟踪需求？
你怎么看待需求变化？它是好是坏？给出你的理由。
你怎样研究需求，发现需求？有哪些资源可以用到？
你怎么给需求制定优先级？有哪些技术？
在需求过程中，用户、客户、开发人员各自的职责是什么？
你怎么对待不完整或是令人费解的需求？
功能设计

在功能设计中有哪些隐喻？给出几个成功的例子。
如果有些功能的执行时间很长，怎么能让用户感觉不到太长的等待？
如果用户必须要在一个很小的区域内，从一个常常的列表中选择多个条目，你会用什么控件？
有哪些方法可以保证数据项的完整？
建立系统原型有哪些技术？
应用程序怎样建立对用户行为的预期？给出一些例子。
如何入手设计一组数量庞大而又复杂的特性，你能举出一些设计思路吗？
有一个列表，其中有10个元素，每个元素都有20个字段可以编辑，你怎样设计这种情况？如果是1000个元素，每个元素有3个字段呢？
用不同的颜色对一段文本中的文字标记高亮，这种做法有什么问题？
Web环境和Windows环境各有些什么限制？
技术设计

什么是低耦合和高聚合？封装原则又是什么意思？
在Web应用中，你怎样避免几个人编辑同一段数据所造成的冲突？
你知道设计模式吗？你用过哪些设计模式？在什么场合下用的？
是否了解什么是无状态的业务层？长事务如何与之相适应？
在搭建一个架构，或是技术设计时，你用过几种图？
在N层架构中都有哪些层？它们各自的职责是什么？
有哪些方法可以确保架构中数据的正确和健壮？
面向对象设计和面向组件设计有哪些不同之处？
怎样在数据库中对用户授权、用户配置、权限管理这几项功能建模？
怎样按照等级制度给动物王国（包括各种物种和各自的行为）建模？
程序设计

你怎样保证你的代码可以处理各种错误事件？
解释一下什么是测试驱动开发，举出极限编程中的一些原则。
看别人代码的时候，你最关心什么地方？
什么时候使用抽象类，什么时候使用接口？
除了IDE以外，你还喜欢哪些必不可少的工具？
你怎么保证代码执行速度快，而又不出问题？
什么时候用多态，什么时候用委派？
什么时候使用带有静态成员的类，什么时候使用单例？
你在代码里面怎么提前处理需求的变化？给一些例子。
描述一下实现一段代码的过程，从需求到最终交付。
算法

怎样知道一个数字是不是2的乘方？怎样判断一个数是不是奇数？
怎样找出链表中间的元素？
怎样改变10,000个静态HTML页面中所有电话号码的格式？
举出一个你所用过的递归的例子。
在散列表和排序后的列表中找一个元素，哪个查找速度最快？
不管是书、杂志还是网络，你从中所学到的最后一点算法知识是什么？
怎样把字符串反转？你能不用临时的字符串么？
你愿意用什么类型的语言来编写复杂的算法？
有一个数组，里面是从1到1,000,000的整数，其中有一个数字出现了两次，你怎么找出那个重复的数字？
你知道“旅行商问题（Traveling Salesman Problem）”么？
数据结构

怎样在内存中实现伦敦地铁的结构？
怎样以最有效的方式在数据库中存储颜色值？
队列和堆栈区别是什么？
用堆或者栈存储数据的区别是什么？
怎样在数据库中存储N维向量？
你倾向于用哪种类型的语言编写复杂的数据结构？
21的二进制值是什么？十六制值呢？
不管是书、杂志还是网络，你从中所学到的最后一点数据结构的知识是什么？
怎样在XML文档中存储足球比赛结果（包括队伍和比分）？
有哪些文本格式可以保存Unicode字符？
测试

什么是回归测试？怎样知道新引入的变化没有给现有的功能造成破坏？
如果业务层和数据层之间有依赖关系，你该怎么写单元测试？
你用哪些工具测试代码质量？
在产品部署之后，你最常碰到的是什么类型的问题？
什么是代码覆盖率？有多少种代码覆盖率？
功能测试和探索性测试的区别是什么？你怎么对网站进行测试？
测试套件、测试用例、测试计划，这三者之间的区别是什么？你怎么组织测试？
要对电子商务网站做冒烟测试，你会做哪些类型的测试？
客户在验收测试中会发现不满意的东西，怎样减少这种情况的发生？
你去年在测试和质量保证方面学到了哪些东西？
维护

你用哪些工具在维护阶段对产品进行监控？
要想对一个正在产品环境中被使用的产品进行升级，该注意哪些重要事项？
如果在一个庞大的文件中有错误，而代码又无法逐步跟踪，你怎么找出错误？
你怎样保证代码中的变化不会影响产品的其他部分？
你怎样为产品编写技术文档？
你用过哪些方式保证软件产品容易维护？
怎样在产品运行的环境中进行系统调试？
什么是负载均衡？负载均衡的方式有哪些种？
为什么在应用程序的生命周期中，软件维护费用所占的份额最高？
再造工程（re-engineering）和逆向工程（reverse engineering）的区别是什么？
配置管理

你知道配置管理中基线的含义么？怎样把项目中某个重要的时刻冻结？
你一般会把哪些东西纳入版本控制？
怎样可以保证团队中每个人都知道谁改变了哪些东西？
Tag和Branch的区别是什么？在什么情况下该使用tag，什么时候用branch？
怎样管理技术文档——如产品架构文档——的变化？
你用什么侗剧管理项目中所有数字信息的状态？你最喜欢哪种工具？
如果客户想要对一款已经发布的产品做出变动，你怎么处理？
版本管理和发布管理有什么差异？
对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？
同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？
项目管理

范围、时间、成本，这三项中哪些是可以由客户控制的？
谁该对项目中所要付出的一切做出估算？谁有权设置最后期限？
减少交付的次数，或是减少每个每个交付中的工作量，你喜欢哪种做法？
你喜欢用哪种图来跟踪项目进度？
迭代和增量的区别在哪里？
试着解释一下风险管理中用到的实践。风险该如何管理？
你喜欢任务分解还是滚动式计划？
你需要哪些东西帮助你判断项目是否符合时间要求，在预算范围内运作？
DSDM、Prince2、Scrum，这三者之间有哪些区别？
如果客户想要的东西太多，你在范围和时间上怎样跟他达成一致呢？

编写高性能 Web 应用程序的 10 个技巧 转自微软资料
数据层性能
技巧 1 — 返回多个结果集
技巧 2 — 分页的数据访问
技巧 3 — 连接池
技巧 4 — ASP.NET 缓存 API
技巧 5 — 每请求缓存
技巧 6 — 后台处理
技巧 7 — 页输出缓存和代理服务器
技巧 8 — 运行 IIS 6.0（只要用于内核缓存）
技巧 9 — 使用 Gzip 压缩
技巧 10 — 服务器控件视图状态
小结
====================================================
使用 ASP.NET 编写 Web 应用程序的简单程度令人不敢相信。正因为如此简单，所以很多开发人员就不会花时间来设计其应用程序的结构，以获得更好的性能了。在本文中，我将讲述 10 个用于编写高性能 Web 应用程序的技巧。但是我并不会将这些建议仅局限于 ASP.NET 应用程序，因为这些应用程序只是 Web 应用程序的一部分。本文不作为对 Web 应用程序进行性能调整的权威性指南 — 一整本书恐怕都无法轻松讲清楚这个问题。请将本文视作一个很好的起点。

成为工作狂之前，我原来喜欢攀岩。在进行任何大型攀岩活动之前，我都会首先仔细查看指南中的路线，阅读以前游客提出的建议。但是，无论指南怎么好，您都需要真正的攀岩体验，然后才能尝试一个特别具有挑战性的攀登。与之相似，当您面临修复性能问题或者运行一个高吞吐量站点的问题时，您只能学习如何编写高性能 Web 应用程序。

我的个人体验来自在 Microsoft 的 ASP.NET 部门作为基础架构程序经理的经验，在此期间我运行和管理 www.ASP.NET，帮助设计社区服务器的结构，社区服务器是几个著名 ASP.NET 应用程序（组合到一个平台的 ASP.NET Forums、.Text 和 nGallery）。我确信有些曾经帮助过我的技巧对您肯定也会有所帮助。

您应该考虑将应用程序分为几个逻辑层。您可能听说过 3 层（或者 n 层）物理体系结构一词。这些通常都是规定好的体系结构方式，将功能在进程和/或硬件之间进行了物理分离。当系统需要扩大时，可以很轻松地添加更多的硬件。但是会出现一个与进程和机器跳跃相关的性能下降，因此应该避免。所以，如果可能的话，请尽量在同一个应用程序中一起运行 ASP.NET 页及其相关组件。

因为代码分离以及层之间的边界，所以使用 Web 服务或远程处理将会使得性能下降 20% 甚至更多。

数据层有点与众不同，因为通常情况下，最好具有专用于数据库的硬件。然而进程跳跃到数据库的成本依然很高，因此数据层的性能是您在优化代码时首先要考虑的问题。

在深入应用程序的性能修复问题之前，请首先确保对应用程序进行剖析，以便找出具体的问题所在。主要性能计数器（如表示执行垃圾回收所需时间百分比的计数器）对于找出应用程序在哪些位置花费了其主要时间也非常有用。然而花费时间的位置通常非常不直观。

本文讲述了两种类型的性能改善：大型优化（如使用 ASP.NET 缓存），和进行自身重复的小型优化。这些小型优化有时特别有意思。您对代码进行一点小小的更改，就会获得很多很多时间。使用大型优化，您可能会看到整体性能的较大飞跃。而使用小型优化时，对于某个特定请求可能只会节省几毫秒的时间，但是每天所有请求加起来，则可能会产生巨大的改善。

数据层性能

谈到应用程序的性能调整，有一个试纸性的测试可用来对工作进行优先级划分：代码是否访问数据库？如果是，频率是怎样的？请注意，这一相同测试也可应用于使用 Web 服务或远程处理的代码，但是本文对这些内容未做讲述。

如果某个特定的代码路径中必需进行数据库请求，并且您认为要首先优化其他领域（如字符串操作），则请停止，然后执行这个试纸性测试。如果您的性能问题不是非常严重的话，最好花一些时间来优化一下与数据库、返回的数据量、进出数据库的往返频率相关的花费时间。

了解这些常规信息之后，我们来看一下可能会有助于提高应用程序性能的十个技巧。首先，我要讲述可能会引起最大改观的更改。

===============================
技巧 1 — 返回多个结果集

仔细查看您的数据库代码，看是否存在多次进入数据库的请求路径。每个这样的往返都会降低应用程序可以提供的每秒请求数量。通过在一个数据库请求中返回多个结果集，可以节省与数据库进行通信所需的总时间长度。同时因为减少了数据库服务器管理请求的工作，还会使得系统伸缩性更强。

虽然可以使用动态 SQL 返回多个结果集，但是我首选使用存储过程。关于业务逻辑是否应该驻留于存储过程的问题还存在一些争议，但是我认为，如果存储过程中的逻辑可以约束返回数据的话（缩小数据集的大小、缩短网络上所花费时间，不必筛选逻辑层的数据），则应赞成这样做。

使用 SqlCommand 实例及其 ExecuteReader 方法填充强类型的业务类时，可以通过调用 NextResult 将结果集指针向前移动。图 1 显示了使用类型类填充几个 ArrayList 的示例会话。只从数据库返回您需要的数据将进一步减少服务器上的内存分配。

==================================
技巧 2 — 分页的数据访问

ASP.NET DataGrid 具有一个很好的功能：数据分页支持。在 DataGrid 中启用分页时，一次会显示固定数量的记录。另外，在 DataGrid 的底部还会显示分页 UI，以便在记录之间进行导航。该分页 UI 使您能够在所显示的数据之间向前和向后导航，并且一次显示固定数量的记录。

还有一个小小的波折。使用 DataGrid 的分页需要所有数据均与网格进行绑定。例如，您的数据层需要返回所有数据，那么 DataGrid 就会基于当前页筛选显示的所有记录。如果通过 DataGrid 进行分页时返回了 100,000 个记录，那么针对每个请求会放弃 99,975 个记录（假设每页大小为 25 个记录）。当记录的数量不断增加时，应用程序的性能就会受到影响，因为针对每个请求必须发送越来越多的数据。

要编写性能更好的分页代码，一个极佳的方式是使用存储过程。图 2 显示了针对 Northwind 数据库中的 Orders 表进行分页的一个示例存储过程。简而言之，您此时要做的只是传递页索引和页大小。然后就会计算合适的结果集，并将其返回。

在社区服务器中，我们编写了一个分页服务器控件，以完成所有的数据分页。您将会看到，我使用的就是技巧 1 中讨论的理念，从一个存储过程返回两个结果集：记录的总数和请求的数据。

返回记录的总数可能会根据所执行查询的不同而有所变化。例如，WHERE 子句可用来约束返回的数据。为了计算在分页 UI 中显示的总页数，必须了解要返回记录的总数。例如，如果总共有 1,000,000 条记录，并且要使用一个 WHERE 子句将其筛选为 1000 条记录，那么分页逻辑就需要了解记录的总数才能正确呈现分页 UI。

==============================
技巧 3 — 连接池

在 Web 应用程序和 SQL Server™ 之间设置 TCP 连接可能是一个非常消耗资源的操作。Microsoft 的开发人员到目前为止能够使用连接池已经有一段时间了，这使得他们能够重用数据库连接。他们不是针对每个请求都设置一个新的 TCP 连接，而是只在连接池中没有任何连接时才设置新连接。当连接关闭时，它会返回连接池，在其中它会保持与数据库的连接，而不是完全破坏该 TCP 连接。

当然，您需要小心是否会出现泄漏连接。当您完成使用连接时，请一定要关闭这些连接。再重复一遍：无论任何人对 Microsoft?.NET Framework 中的垃圾回收有什么评论，请一定要在完成使用连接时针对该连接显式调用 Close 或 Dispose。不要相信公共语言运行库 (CLR) 会在预先确定的时间为您清除和关闭连接。尽管 CLR 最终会破坏该类，并强制连接关闭，但是当针对对象的垃圾回收真正发生时，并不能保证。

要以最优化的方式使用连接池，需要遵守一些规则。首先打开连接，执行操作，然后关闭该连接。如果您必须如此的话，可以针对每个请求多次打开和关闭连接（最好应用技巧 1），但是不要一直将连接保持打开状态并使用各种不同的方法对其进行进出传递。第二，使用相同的连接字符串（如果使用集成身份验证的话，还要使用相同的线程标识）。如果不使用相同的连接字符串，例如根据登录的用户自定义连接字符串，那么您将无法得到连接池提供的同一个优化值。如果您使用集成身份验证，同时还要模拟大量用户，连接池的效率也会大大下降。尝试跟踪与连接池相关的任何性能问题时，.NET CLR 数据性能计数器可能非常有用。

每当应用程序连接资源时，如在另一个进程中运行的数据库，您都应该重点考虑连接该资源所花时间、发送或检索数据所花时间，以及往返的数量，从而进行优化。优化应用程序中任何种类的进程跳跃都是获得更佳性能的首要一点。

应用层包含了连接数据层、将数据转换为有意义类实例和业务流程的逻辑。例如社区服务器，您要在其中填充Forums 或 Threads集合，应用业务规则（如权限）；最重要的是要在其中执行缓存逻辑。

================================
技巧 4 — ASP.NET 缓存 API

编写应用程序代码行之前，一个首要完成的操作是设计应用层的结构，以便最大化利用 ASP.NET 缓存功能。

如果您的组件要在 ASP.NET 应用程序中运行，则只需在该应用程序项目中包括一个 System.Web.dll 引用。当您需要访问该缓存时，请使用 HttpRuntime.Cache 属性（通过 Page.Cache 和 HttpContext.Cache 也可访问这个对象）。

对于缓存数据，有几个规则。首先，如果数据可能会多次使用时，则这是使用缓存的一个很好的备选情况。第二，如果数据是通用的，而不特定于某个具体的请求或用户时，则也是使用缓存的一个很好的备选情况。如果数据是特定于用户或请求的，但是寿命较长的话，仍然可以对其进行缓存，但是这种情况可能并不经常使用。第三，一个经常被忽略的规则是，有时可能您缓存得太多。通常在一个 x86 计算机上，为了减少内存不足错误出现的机会，您会想使用不高于 800MB 的专用字节运行进程。因此缓存应该有个限度。换句话说，您可能能够重用某个计算结果，但是如果该计算采用 10 个参数的话，您可能要尝试缓存 10 个排列，这样有可能给您带来麻烦。一个要求 ASP.NET 的最常见支持是由于过度缓存引起的内存不足错误，尤其是对于大型数据集。

图 3 ASP.NET缓存

缓存有几个极佳的功能，您需要对它们有所了解。首先，缓存会实现最近最少使用的算法，使得 ASP.NET 能够在内存运行效率较低的情况下强制缓存清除 － 从缓存自动删除未使用过的项目。第二，缓存支持可以强制失效的过期依赖项。这些依赖项包括时间、密钥和文件。时间经常会用到，但是对于 ASP.NET 2.0，引入了一个功能更强的新失效类型：数据库缓存失效。它指的是当数据库中的数据发生变化时自动删除缓存中的项。有关数据库缓存失效的详细信息，请参阅 MSDN?Magazine 2004 年 7 月的 Dino Esposito Cutting Edge 专栏。要了解缓存的体系结构，请参阅图 3。

=======================
技巧 5 — 每请求缓存

在本文前面部分，我提到了经常遍历代码路径的一些小改善可能会导致较大的整体性能收益。对于这些小改善，其中有一个绝对是我的最爱，我将其称之为“每请求缓存”。

缓存 API 的设计目的是为了将数据缓存较长的一段时间，或者缓存至满足某些条件时，但每请求缓存则意味着只将数据缓存为该请求的持续时间。对于每个请求，要经常访问某个特定的代码路径，但是数据却只需提取、应用、修改或更新一次。这听起来有些理论化，那么我们来举一个具体的示例。

在社区服务器的论坛应用程序中，页面上使用的每个服务器控件都需要个性化的数据来确定使用什么外观、使用什么样式表，以及其他个性化数据。这些数据中有些可以长期缓存，但是有些数据却只针对每个请求提取一次，然后在执行该请求期间对其重用多次，如要用于控件的外观。

为了达到每请求缓存，请使用 ASP.NET HttpContext。对于每个请求，都会创建一个 HttpContext 实例，在该请求期间从 HttpContext.Current 属性的任何位置都可访问该实例。该 HttpContext 类具有一个特殊的 Items 集合属性；添加到此 Items 集合的对象和数据只在该请求持续期间内进行缓存。正如您可以使用缓存来存储经常访问的数据一样，您也可以使用 HttpContext.Items 来存储只基于每个请求使用的数据。它背后的逻辑非常简单：数据在它不存在的时候添加到 HttpContext.Items 集合，在后来的查找中，只是返回 HttpContext.Items 中的数据。

=====================
技巧 6 — 后台处理

通往代码的路径应该尽可能快速，是吗？可能有时您会觉得针对每个请求执行的或者每 n 个请求执行一次的任务所需资源非常多。发送电子邮件或者分析和验证传入数据就是这样的一些例子。

剖析 ASP.NET Forums 1.0 并重新构建组成社区服务器的内容时，我们发现添加新张贴的代码路径非常慢。每次添加新张贴时，应用程序首先需要确保没有重复的张贴，然后必须使用“坏词”筛选器分析该张贴，分析张贴的字符图释，对张贴添加标记并进行索引，请求时将张贴添加到合适的队列，验证附件，最终张贴之后，立即向所有订阅者发出电子邮件通知。很清楚，这涉及很多操作。

经研究发现，大多数时间都花在了索引逻辑和发送电子邮件上。对张贴进行索引是一个非常耗时的操作，人们发现内置的 System.Web.Mail 功能要连接 SMYP 服务器，然后连续发送电子邮件。当某个特定张贴或主题领域的订阅者数量增加时，执行 AddPost 功能所需的时间也越来越长。

并不需要针对每个请求都进行电子邮件索引。理想情况下，我们想要将此操作进行批处理，一次索引 25 个张贴或者每五分钟发送一次所有电子邮件。我们决定使用以前用于对数据缓存失效进行原型设计的代码，这个失效是用于最终进入 Visual Studio® 2005 的内容的。

System.Threading 命名空间中的 Timer 类非常有用，但是在 .NET Framework 中不是很有名，至少对于 Web 开发人员来说是这样。创建之后，这个 Timer 类将以一个可配置的间隔针对 ThreadPool 中的某个线程调用指定的回调。这就表示，您可以对代码进行设置，使其能够在没有对 ASP.NET 应用程序进行传入请求的情况下得以执行，这是后台处理的理想情况。您还可以在此后台进程中执行如索引或发送电子邮件之类的操作。

但是，这一技术有几个问题。如果应用程序域卸载，该计时器实例将停止触发其事件。另外，因为 CLR 对于每个进程的线程数量具有一个硬性标准，所以可能会出现这样的情形：服务器负载很重，其中计时器可能没有可在其基础上得以完成的线程，在某种程度上可能会造成延迟。ASP.NET 通过在进程中保留一定数量的可用线程，并且仅使用总线程的一部分用于请求处理，试图将上述情况发生的机会降到最低。但是，如果您具有很多异步操作时，这可能就是一个问题了。

这里没有足够的空间来放置该代码，但是您可以下载一个可以看懂的示例，网址是 www.rob-howard.net。请了解一下 Blackbelt TechEd 2004 演示中的幻灯片和演示。

=========================

技巧 7 — 页输出缓存和代理服务器

ASP.NET 是您的表示层（或者说应该是您的表示层）；它由页、用户控件、服务器控件（HttpHandlers 和 HttpModules）以及它们生成的内容组成。如果您具有一个 ASP.NET 页，它会生成输出（HTML、XML、图像或任何其他数据），并且您针对每个请求运行此代码时，它都会生成相同的输出，那么您就拥有一个可用于页输出缓存的绝佳备选内容。

将此行内容添加页的最上端

<%@ Page OutputCache VaryByParams="none" Duration="60" %>

就可以高效地为此页生成一次输出，然后对它进行多次重用，时间最长为 60 秒，此时该页将重新执行，输出也将再一次添加到 ASP.NET 缓存。通过使用一些低级程序化 API 也可以完成此行为。对于输出缓存有几个可配置的设置，如刚刚讲到的 VaryByParams 属性。VaryByParams 刚好被请求到，但还允许您指定 HTTP GET 或 HTTP POST 参数来更改缓存项。例如，只需设置 VaryByParam="Report" 即可对 default.aspx?Report=1 或 default.aspx?Report=2 进行输出缓存。通过指定一个以分号分隔的列表，还可以指定其他参数。

很多人都不知道何时使用输出缓存，ASP.NET 页还会生成一些位于缓存服务器下游的 HTTP 标头，如 Microsoft Internet Security and Acceleration Server 或 Akamai 使用的标头。设置了 HTTP 缓存标头之后，可以在这些网络资源上对文档进行缓存，客户端请求也可在不必返回原始服务器的情况下得以满足。

因此，使用页输出缓存不会使得您的应用程序效率更高，但是它可能会减少服务器上的负载，因为下游缓存技术会缓存文档。当然，这可能只是匿名内容；一旦它成为下游之后，您就再也不会看到这些请求，并且再也无法执行身份验证以阻止对它的访问了。

========================
技巧 8 — 运行 IIS 6.0（只要用于内核缓存）

如果您未运行 IIS 6.0 (Windows Server? 2003)，那么您就错过了 Microsoft Web 服务器中的一些很好的性能增强。在技巧 7 中，我讨论了输出缓存。在 IIS 5.0 中，请求是通过 IIS 然后进入 ASP.NET 的。涉及到缓存时，ASP.NET 中的 HttpModule 会接收该请求，并返回缓存中的内容。

如果您正在使用 IIS 6.0，就会发现一个很好的小功能，称为内核缓存，它不需要对 ASP.NET 进行任何代码更改。当请求由 ASP.NET 进行输出缓存时，IIS 内核缓存会接收缓存数据的一个副本。当请求来自网络驱动程序时，内核级别的驱动程序（无上下文切换到用户模式）就会接收该请求，如果经过了缓存，则会将缓存的数据刷新到响应，然后完成执行。这就表示，当您将内核模式缓存与 IIS 和 ASP.NET 输出缓存一起使用时，就会看到令人不敢相信的性能结果。在 ASP.NET 的 Visual Studio 2005 开发过程中，我一度是负责 ASP.NET 性能的程序经理。开发人员完成具体工作，但是我要看到每天进行的所有报告。内核模式缓存结果总是最有意思的。最常见的特征是网络充满了请求/响应，而 IIS 运行时的 CPU 使用率只有大约 5%。这太令人震惊了！当然使用 IIS 6.0 还有一些其他原因，但是内核模式缓存是其中最明显的一个。

===========================
技巧 9 — 使用 Gzip 压缩

虽然使用 gzip 并不一定是服务器性能技巧（因为您可能会看到 CPU 使用率的提高），但是使用 gzip 压缩可以减少服务器发送的字节数量。这就使人们觉得页速度加快了，并且还减少了带宽的用量。根据所发送数据、可以压缩的程度以及客户端浏览器是否支持（IIS 只会向支持 gzip 压缩的客户端发送经过 gzip 压缩的内容，如 Internet Explorer 6.0 和 Firefox），您的服务器每秒可以服务于更多的请求。实际上，几乎每当您减少所返回数据的数量时，都会增加每秒请求数。

Gzip 压缩已经内置到 IIS 6.0 中，并且其性能比 IIS 5.0 中使用的 gzip 压缩要好的多，这是好消息。但不幸的是，当尝试在 IIS 6.0 中打开 gzip 压缩时，您可能无法在 IIS 的属性对话中找到该设置。IIS 小组在该服务器中置入了卓越的 gzip 功能，但是忘了包括一个用于启用该功能的管理 UI。要启用 gzip 压缩，您必须深入到 IIS 6.0 的 XML 配置设置内部（这样不会引起心脏虚弱）。顺便提一句，这归功于 OrcsWeb 的 Scott Forsyth，他帮助我提出了在 OrcsWeb 上宿主的 www.asp.net 服务器的这个问题。

本文就不讲述步骤了，请阅读 Brad Wilson 的文章，网址是 IIS6 Compression。还有一篇有关为 ASPX 启用压缩的知识库文章，网址是 Enable ASPX Compression in IIS。但是您应该注意，由于一些实施细节，IIS 6.0 中不能同时存在动态压缩和内核缓存。

==============================
技巧 10 — 服务器控件视图状态

视图状态是一个有趣的名称，用于表示在所生成页的隐藏输出字段中存储一些状态数据的 ASP.NET。当该页张贴回服务器时，服务器可以分析、验证、并将此视图状态数据应用回该页的控件树。视图状态是一个非常强大的功能，因为它允许状态与客户端一起保持，并且它不需要 cookie 或服务器内存即可保存此状态。很多 ASP.NET 服务器控件都使用视图状态来保持在与页元素进行交互期间创建的设置，例如保存对数据进行分页时显示的当前页。

然而使用视图状态也有一些缺点。首先，服务或请求页时，它都会增加页的总负载。对张贴回服务器的视图状态数据进行序列化或取消序列化时，也会发生额外的开销。最后，视图状态会增加服务器上的内存分配。

几个服务器控件有着过度使用视图状态的趋势，即使在并不需要的情况下也要使用它，其中最著名的是 DataGrid。ViewState 属性的默认行为是启用，但是如果您不需要，则可以在控件或页级别关闭。在控件内，只需将 EnableViewState 属性设置为 false，或者在页中使用下列设置即可对其进行全局设置：

<%@ Page EnableViewState="false" %>

如果您不回发页，或者总是针对每个请求重新生成页上的控件，则应该在页级别禁用视图状态。

==============================
小结

我为您讲述了一些我认为在编写高性能 ASP.NET 应用程序时有所帮助的技巧。正如我在本文前面部分提到的那样，这是一个初步指南，并不是 ASP.NET 性能的最后结果。（有关改善 ASP.NET 应用程序性能的信息，请参阅 Improving ASP.NET Performance。）只有通过自己的亲身体验才能找出解决具体性能问题的最好方法。但是，在您的旅程中，这些技巧应该会为您提供一些好的指南

Web-OA工作流使用详解
一、概念篇
 随着企业管理信息化进程的不断深入，使用IT技术来规范工作流程的理念已开始为广大用户所接受。

Web-OA的工作流正是为这一需求而设计，可实现业务或公文的申请、审批管理。并实现数据的规范化录入、查询和存档。

简单来说，工作流就是把一项工作化解为多个步骤，由多人协同来完成一项工作。而在工作流中，业务数据或公文都可以通过“表单”来体现，“表单”是数据的载体，另外，表单还可以附带附件文件[磁盘附件和在线Office文档]。

Web-OA工作流的一些概念：
1、工作流：就是几个人协同完成一项工作，简单而言，就是几个人填写同一张“表单”，只是填写表单的人根据流程定义有先后之分，后面的人可以查看前面用户填写的内容。
2、表单：Web-OA用来接受用户输入的界面。由用户自行设计（一般由有权限的用户设计好），Web-OA的表单格式可以用word、Excel、网页工具等设计，设计好后复制、粘贴到“表单智能设计器”中，再添加定义各表单域就可以了。
3、流程：规定如何填写某表单的相应步骤。一个流程一般对应一个表单，也可以多个流程用同一个表单。流程分为固定流程和自由流程两种，固定流程由固定步骤组成，用户事先需定义好，包括某一步骤的可写表单域和可操作人员；自由流程无需定义流程步骤。固定流程第一个步骤的可操作人员有权新建该工作流程（道理可想而知）。
4、工作：即流程的实际运用。新建工作时，必须确定使用的流程，而流程又对应某一个表单，所以，工作就是按流程规定的步骤由多人来实现对某一表单的数据的填写过程。
5、工作监控：执行中的工作和已完成的工作，都可以对其监控。包括删除、跳过某步骤、回转到上一步骤、设置工作代办和终止工作等。有权限的监控人员可随时处理办理中的工作。
6、工作查询：在待办工作、应办工作和完成工作页面，用户可以根据工作名称关键字查询工作，在工作查询页面中，用户可以根据工作实际内容[即工作使用的表单数据]查询。

　　1、总计架构测试

　　1）瘦客户端，业务逻辑规则多数在服务器端执行。如新闻站点、门户网站、信息发布网站等。

　　2）胖客户端，安全性要求较高、交互操作频繁、业务逻辑复杂。银行系统、网络游戏、网上办公系统等。

　　2、Web架构组成部分是否满足需求

　　成本、功能、安全性要求、容量要求、传输实时性。

　　3、服务器配置分布是否满足要求

　　Web服务器、应用服务器、数据库服务器可以分布在不同物理机器上也可以分布相同的物理机器上，一般优先考虑独立数据库服务器，Web服务器、应用服务器可以在相同的机器上。

　　4、客户端设计测试

　　1）功能设置测试：信息服务、办公自动化、Internet支持；

　　2）信息组织结构测试：线性结构、分层结构、非线性结构；

　　3）页面设计测试：

　　a) 页面一致性测试

　　b) 用户界面友好性及导航直观性测试；、

　　c) 是否适合多种浏览器；

　　d) 页文件的命名；

　　e) 页面布局技术。

　　5、服务器端设计测试

　　1）容量规划测试：点击率、延迟和流量、服务器资源；

　　2）系统安全测试：

　　a) 常识性安全策略，取消不必要的协议、控制写权限、取消服务器目录浏览属性、记录日志等；

　　b) 使用加密技术；

　　c) 构造防火墙，网络级、应用级、电路级；

　　d) 构建网络防毒体系。

　　3）数据库设计测试。

　　6、Web开发测试

　　1）源代码分析，主要是使用检查工具来完成；

　　2）链接测试，主要借助工具来完成；

　　3）框架测试：

　　a) 自动调整窗口大小；

　　b) 是否提供滚动条；

　　c) 打开新页面是否正常。

　　4）表格测试，随窗体变化自动调整大小；

　　5）图形测试：

　　a) 颜色饱和度及对比度；

　　b) 链接标识；

　　c) 图形显示是否正确。

　　7、与一般应用软件相比，Web测试有以下区别：

　　第一、Web测试的侧重点是性能、安全、易用性、兼容

　　第二、测试工具有所不同，如链接测试、表单测试、界面测试

　　8、功能测试

　　1）客户端的选择，优先测试流行的客户客户端；

　　2）客户端浏览器的配置

　　3）客户端的显示设置

　　4）内容测试

　　9、链接测试

　　1）该链接将用户带到它所说明的地方

　　2）被链接的页面是存在的

　　3）保证没有孤立页面

　　工具有WEBCHECK、LINKBOT、TESTPARTNER、XENU等

 　软件开发过程中，经常遇到这个问题，所以转载下：　
    需求变更对软件开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。
　　
　　（1）明确合同约束，建立需求基线
　　需求变更给软件开发带来的影响有目共睹，所以在与客户签订合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。
　　
　　明确和树立需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（客户参与评审），建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要力保不频繁变更。例如，对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。
　　
　　（2）建立变更审批流程

　　在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低开发效率，浪费时间。正是这种观念才使需求变更变得不可控，最终导致项目的失败。因此，小的需求变更也要经过正规的需求管理流程，否则会积少成多，积重难返。
　　
　　明确需求变更审批环节、审批人员、审批事项、审批流程。这么做的目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”，一律是无效变更不予受理。
　　
　　（3）分级管理变更，定时批量处理

　　软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到客户的成本投入收益。因此，用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。
　　
　　当遇到客户提出需求，不及时处理可能会使项目不能验收通过时，也不能一味拒绝不予开发。因此，当客户坚持变更新需求时，可以建议客户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。例如，每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目进度。针对会议结果可向客户正式提交一份需求变更计划，注明变更引起的时间、成本、工期代价和增加工作量等。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱变更不做，保大局弃小变。
　　
　　（4）安排专职人员负责变更管理

　　有时开发任务较重，开发人员容易陷入开发工作中而忽略了与客户的随时沟通。因此，需要安排一名专职的需求变更联络人员，负责与客户及时交流，跟踪和汇报需求变更完成进度和情况。同时，可以成立项目变更控制小组，负责裁定接受哪些变更，小组由项目所涉及的多方人员共同组成，应该包括客户方和开发方的决策人员在内。
　　
　　（5）确认客户是否接受变更的代价

　　要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说，如果客户认为该变更是必须的（不是其上级领导拍脑袋提出的）就会接受这些后果。通过与客户协商，这样开发团队即使没有回报，也不会招致公司和客户双方的埋怨。
　　
　　如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更。
 

　　1、必须说清楚测试报告的操作系统环境：

　　比如说XX软件运行的操作系统是什么？是Windows 98、Windows2000、WindowsXP, 还是Linux操作系统等等。很多时候，大多数的软件只能够在某个系统上存在缺陷，而在其它版本的系统上可能不存在缺陷。

　　2、测试报告结果只对发布的版本和配置库的SVN号负责：

　　也许同行们都有这种尴尬，很多测试的时候，发现了Bug，并将Bug记录到Bug跟踪系统上，结果开发人员说，自己的机器上不存在这个Bug。要求测试人员重新验证Bug是否存在。一种可能是开发人员发现测试人员递交缺陷后，修改了该缺陷，还有一种情况是版本的发布不规范，开发人员忘了递交代码到配置库，结果就发布了。所以，测试报告只对特定的版本和环境负责。

　　3、指出测试的浏览器：

　　特别是Web类似的软件，不同的浏览器，测试出来的问题不一样。同样的一种浏览器，不同的版本，测试结果报告也有时候不一样，我们部门以前碰到过IE6.0和IE7.0同样的一个功能，页面显示不太一样的现象。故，Web类似软件的测试报告，最好是说明出现问题的浏览器。

　　4、测试结论和测试建议，对于一个有效的测试报告非常关键：

　　测试结论和测试建议要求简短和准确，甚至有时候决定该版本是否可以发布，特别是测试的负责人，对被测试软件的报告一定要仔细斟酌，小心为佳。

　　5、测试用例的执行情况：

　　针对软件测试报告的几种类型，如：单元测试、集成测试、功能测试、性能测试和压力测试分别编写测试报告。编写报告时，已经执行或未执行的的用例数目。用例通过的百分比，未执行的测试用例，必须说明不能执行的原因。对于测试阻塞的测试用例，必须加以说明，最好用粗体字表明，让人一看就比较清楚。

　　6、一般都要附上缺陷列表（Buglist）：

　　某个软件的测试版本，测试中共发现了多少问题，缺陷的严重等级和优先级如何，已经关闭和Fix掉的Bug有哪些？哪些问题是该版本遗留的问题？哪些是下一个版本解决的问题？哪些是重复打开的缺陷？有了Buglist，一看就一目了然，简单并且很清晰。

　　7、测试结果的图形和数据分析情况：

　　测试报告递交一定要分清递交对象，不同类型的人，递交不同版本的测试报告。如果是递交给研发部的人员，最好要附上缺陷隔离等相关方面的解释，方便开发人员迅速定位缺陷，解决问题。如果递交对象是客户，你就详细说明客户关心的功能和常用模块是否已经实现，是否存在问题即可。如果递交的对象是公司领导和客户领导，他们根本就没有很多时间来看你的文字，主要看看测试图表，最好用缺陷管理工具，如：TestDerector和QAcenter自动生成不同的图表，并且附带上各个功能模块的缺陷情况，就可以应付了，呵呵！！

　　8、测试报告也可以附带缺陷度量的相关分析：

　　如缺陷密度呀等等之类的，增加缺陷报告的技术含量.