软件测试的阶段划分可以从三个角度来将软件测试划分为多个阶段： 1. 面向软件测试操作类型的划分，如调试、集成、确认、验证、组装、验收、操作； 2. 面向软件测试对象粒度的划分，如语句、结构、单元、部件、配置项、子系统、系 统、大系统； 3. 面向软件测试实施者的划分，如开发者、测试者、验收者、使用者。 软件测试阶段的步骤 每个软件测试阶段都要经历以下步骤：测试需求分析、测试过程设计、测试实现、测试 实施、测试评价、测试维护。 测试需求分析 测试需求是整个测试过程的基础； 确定测试对象以及测试工作的范围和作用。 用来确定 整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需 求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测 试需求。 所以我现在的理解是测试需求是一个比较大的概念， 它是在整个测试计划文档中体 现出来的，不是类似的一个用例或者其他 . ◆ 测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依 据； ◆ 测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的 设计测试用例； ◆ 测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； b 测试过程设计：包括测试计划 , 测试策略制定，测试时间安排用，测试用例编写 等 c 测试实现：环境配置好了，新的版本也收到了，人员也都培训好了等等 d 测试实施：已经按照测试计划进行展开了，比如手工测试，自动化测试等 e 测试评价：对版本测试覆盖率，测试质量，人员测试工作以及前期的一些工作制定 情况进行评价，评估 f 测试维护：对测试用例库，测试脚本， bug 库等进行维护，保证延续性等 软件测试步骤软件测试步骤 输 入 输 出 软件测试计划： 1. 软件测试的方法与规范 2. 软件需求规格说明 3. 软件设计说明（概要设计说明和 详细设计说明） 1) 软件测试的定位 2) 软件测试线索 3) 软件测试环境的定义 4) 软件需求的追踪矩阵 1. 软件测试的方法与规范 测试过程设计 2. 软件测试计划 1) 软件测试步骤 软件测试说明：测试需求分析2) 软件测试基准 3) 测试线索的追踪矩阵 软件测试的实现配置： 1. 软件测试的方法与规范 测试实现 2. 软件测试说明 3. 软件测试工具 3) 测试基准的计算机表示 软件测试记录： 1. 软件测试的方法与规范 测试实施 2. 软件测试说明 3. 软件测试的实现配置 1) 测试运行结果的计算机表示 2) 测试比较结果的计算机表示 3) 测试日志 4) 软件问题报告 1. 软件开发文档 软件测试报告： 2. 软件测试文档 测试评价 3. 软件测试配置 2) 测试结果的分析 / 评判 4. 软件测试记录 1. 软件测试配置管理项的标识管理 测试配置管理项： 2. 软件测试配置管理项的存储管理 1) 软件测试的描述性表示（测试文 测试配置管理 档 / 文件） 3. 软件测试配置管理项的引用控制 1) 测试结果的统计信息 1) 软件测试环境 2) 测试步骤的计算机表示（用于回 归测试的测试代码 / 测试数据）2) 软件测试的计算机表示（测试代 4. 软件测试配置管理项的版本控制 码 / 数据 / 结果） 5. 软件测试配置管理项的更动控制 1. 测试配置管理项的使用报告 测试维护 测试配置管理 2. 测试配置管理项的软件问题报告 3. 测试配置管理项的更动控制文件软件系统的测试流程 显示了大型复杂软件系统的软件测试流程。 可以看到，结合测试操作类型和测试对象粒度的划分角度，软件测试阶段可分为：单元 测试、部件集成、部件确认、配置项组装、配置项确认、系统综合和系统验收等。每个阶段都要经历测试需求分析、测试过程设计、测试实现、测试实施、测试评价、测试维护的六个 步骤。 说明各测试阶段的定义标识 单元测试 部件集成测试 被测对象 UT CI 目 的 单元 单元、 三级部件、 二级部件 三级部件、 二级部 CV 件 二级部件、 一级部 II 件、 配置项 配置项、 子系统 完成后产品状态 获得可组装的单元 集成单元成部件 可执行的单元 二级部件环境中可执行的 部件 二级部件环境中满足文档 要求的部件 二级部件环境中满足文档 要求的部件 模拟环境中满足软件需求 的配置项部件确认测试确认将被组装的部件配置项组装测 试 配置项确认测 试 系统综合测试 IV组装部件成配置项确认配置项的功能和性能SI子系统 系统 子系统 系统 关键动态协调开发环境下的各 仿实际运行环境中满足用 子系统 确认系统的功能和性能 户需求的子系统 仿实际运行环境中满足用 户需求的系统系统验收测试SA配置项 关键部件?测试用例评审有效性衡量标准1.Major Defects Per Test Case Review 每个经评审的测试用例发现的主要缺陷 2.Minor Defects Per Test Case Review 每个经评审的测试用例发现的次要缺陷 3.Total Defects Per Test Case Review 每个经评审的测试用例发现的缺陷总数 4.Ratio of Major to Minor Defects Per Test Case Review 每个经评审的测试用例发现的主要缺陷与次要缺陷的比例 5.Total Defects Per Test Case Review Hour 每一个小时评审的测试用例发现的缺陷总数 6.Major Defects Per Test Case Review Hour 每一个小时评审的测试用例发现的主要缺陷 7.Ratio of Major to Minor Defects Per Test Case Review Hour 每一个小时评审的测试用例发现的次要缺陷 8.Number of Open Defects Per Test Review 每个经评审的测试用例发现的处于 Open 状态的缺陷个数 9.Number of Closed Defects Per Test Case Review 每个经评审的测试用例发现的处于 Closed 状态的缺陷个数 10.Ratio of Closed to Open Defects Per Test Case Review 每个经评审的测试用例发现的处于 Closed 状态的缺陷个数与处于 Open 状态的缺陷个数 的比例 11.Number of Major Open Defects Per Test Case Review 每个经评审的测试用例发现的处于 Open 状态的主要缺陷个数 12.Number of Major Closed Defects Per Test Case Review每个经评审的测试用例发现的处于 Closed 状态的主要缺陷个数 13.Ratio of Major Closed to Open Defects Per Test Case Review 每个经评审的测试用例发现的处于 Closed 状态的主要缺陷与处于 Open 状态的主要缺陷 的比例 14.Number of Minor Open Defects Per Test Case Review 每个经评审的测试用例发现的处于 Open 状态的次要缺陷个数 15.Number of Minor Closed Defects Per Test Case Review 每个经评审的测试用例发现的处于 Closed 状态的次要缺陷个数 16.Ratio of Minor Closed to Open Defects Per Test Case Review 每个经评审的测试用例发现的处于 Closed 状态的次要缺陷与处于 Open 状态的次要缺陷 的比例 17.Percent of Total Defects Captured Per Test Case Review 每个经评审的测试用例发现的总缺陷个数占缺陷总数的百分比 18.Percent of Major Defects Captured Per Test Case Review 每个经评审的测试用例发现的主要缺陷个数占缺陷总数的百分比 19.Percent of Minor Defects Captured Per Test Case Review 每个经评审的测试用例发现的次要缺陷个数占缺陷总数的百分比 20.Ratio of Percent Major to Minor Defects Captured Per Test Case Review 每个经评审的测试用例发现主要缺陷的百分比与次要缺陷的百分比之间的比例。 21.Percent of Total Defects Captured Per Test Case Review Hour 每一个小时评审的测试用例发现的缺陷数占总缺陷数的百分比 22.Percent of Major Defects Captured Per Test Case Review Hour 每一个小时评审的测试用例发现的主要缺陷数占总缺陷数的百分比 23.Percent of Minor Defects Captured Per Test Case Review Hour 每一个小时评审的测试用例发现的次要缺陷数占总缺陷数的百分比 24.Ratio of Percent Major to Minor Defects Captured Per Test Case Review Hour 每一个小时评审的测试用例发现的主要缺陷的百分比与次要缺陷的百分比之间的比例 25.Percent of Total Defect Residual Per Test Case Review 每个经评审的测试用例未能发现的缺陷的百分比 26.Percent of Major Defect Residual Per Test Case Review 每个经评审的测试用例未能发现的主要缺陷的百分比 27.Percent of Minor Defect Residual Per Test Case Review 每个经评审的测试用例未能发现的次要缺陷的百分比 28.Ratio of Percent Major to Minor Defect Residual Per Test Case Review 每个经评审的测试用例未能发现的主要缺陷的百分比与次要缺陷的百分比之间的比例 29.Percent of Total Defect Residual Per Test Case Review Hour 每一个小时评审的测试用例未能发现的缺陷的百分比 30.Percent of Major Defect Residual Per Test Case Review Hour 每一个小时评审的测试用例未能发现的主要缺陷的百分比 31.Percent of Minor Defect Residual Per Test Case Review Hour 每一个小时评审的测试用例未能发现的次要缺陷的百分比 32.Ratio of Percent Major to Minor Defect Residual Per Test Case Review Hour 每一个小时评审的测试用例未能发现的主要缺陷的百分比与次要缺陷的百分比之间的 比例33.Number of Planned Test Case Reviews 计划要评审的测试用例的个数 34.Number of Held Test Case Reviews 计划要评审但未评审的测试用例的个数 35.Ratio of Planned to Held Test Case Reviews 计划要评审的测试用例个数与计划要评审但未评审的测试用例的个数之间的比例 36.Number of Reviewed Test Cases 评审过的测试用例的个数 37.Number of Unreviewed Test Cases 未评审的测试用例的个数 38.Ratio of Reviewed to Unreviewed Test Cases 评审过的测试用例的个数与未评审的测试用例的个数之间的比例 39.Number of Compliant Test Case Reviews 评审通过的测试用例的个数 40.Number of Non-Compliant Test Case Reviews 评审不通过的测试用例的个数 41.Ratio of Compliant to Non-Compliant Test Case Reviews 评审通过的测试用例的个数与评审未通过的测试用例的个数之间的比例 42.Compliance of Test Case Reviews 通过的评审次数 43.Non-Compliance of Test Case Reviews 不通过的评审次数 44.Ratio of Compliance to Non-Compliance of Test Case Reviews 通过的评审次数与不通过的评审次数之间的比例?软件测试对于 HR 软件的作用一般来说， 测试主要分为两个层次， 一方面是开发过程中的软件测试， 另一方面是第 三 方的确认测试和验收测试。 开发过程中的软件测试 开发过程中的测试是软件产品开发商进行的测试，包括单元测试、集成测试、系统测试 三个主要的环节，其目的主要在于发现软件的缺陷，并及时修改。我们可以把它看作产品出 厂前进行的质量保证的手段。 单元测试： 单元测试的主要目的是针对编码过程中可能存在的各种错误， 例如用户输入 验证过程中的边界值的错误。 在人力资源软件的开发中也就是对各个功能模块进行的白盒测 试。 集成测试： 集成测试主要目的是针对详细设计中可能存在的问题， 尤其是检查各单元与 其它程序部分之间的接口上可能存在的错误。 系统测试： 系统测试主要针对概要设计， 检查了系统作为一个整体是否有效地得到运行， 例如在产品设置中是否达到了预期的高性能。 系统测试是开发商对于人力资源软件产品的最 后的质量保证阶段。 确认测试和验收测试 人力资源开发商的质量保证由于受诸多因素制约（如：思维定式、自我保护等） ，存在 一定程度的局限性， 因此需要第三方软件测试机构对于人力资源软件的质量进行测试和评估， 其主要的测试类型就包括了确认测试和验收测试。确认测试： 确认测试是第三方测试机构根据软件开发商提供的用户手册， 对人力资源软 件进行的质量保证测试， 主要目的在于测试软件的功能是否满足了软件开发商对于用户的承 诺，是否符合国家相关标准法规，系统运行是否安全可靠等。目前，中国软件评测中心进行 的确认测试主要从功能、兼容性、安全可靠性、易用性、资源利用率、效率、用户文档等方 面对软件的质量进行测试和认证。 与验收测试不同的是为了评估软件的实施能力， 需要对软 件的易实施性、 易扩展性进行重点测试， 主要目的在于评估软件的二次开发能力和对于不同 企业的适应能力，以便满足人力资源软件在不同企业中实施的需要。 验收测试： 验收测试是第三方软件测试机构根据最终用户的需求， 对人力资源软件的质 量进行测试， 主要目的是对软件实施后的质量替用户进行验收， 由于验收测试是在特定的环 境、特定需求下的测试，因此测试的重点在于软件的功能是否满足用户需求，功能是否符合 国家标准法规，软件系统是否安全可靠等。 第三方测试的意义 第三方测试以合同的形式制约了测试方，使得它与开发方或开发人员存在某种&对立& 的关 系，所以它不会刻意维护开发方或开发人员的利益，保证了测试工作在一开始就具有 客观性。 第三方测试不同于开发方的自测试。 由开发人员承担的测试存在很多弊病， 除去自身利 益驱使带来的问题外，还有许多不客观的毛病，主要表现在思维的定势上。因为第三方测试 的目的就是为尽量多地发现程序中的错误而运行程序的过程，可以更多的发现问题。此外， 随着系统越做越大， 客观上讲开发人员也无精力参与测试， 同时也不符合大生产专业分工的 原则。 第三方测试不同于用户的自测试。 用户是应用软件需求的提出者， 应该来说对于软件的 需求最为理解，因此比较适合对软件的正确功能和流程进行测试。但是我们也应当看到，大 部分的用户很难对系统的内部实现过程进行深入的分析。 对系统的全面测试， 功能测试仅仅 是一个方面，还要包括并发能力、性能等多种技术测试。这些测试对技术有很高的要求，必 须由计算机的专业人员才能完成。?软件测试到底要不要追究 BUG 发生的原因软件测试到底要不要追究 BUG 发生的原因呢？这个问题的争议很多，有人认为寻找 BUG 的原因是开发的事情， 软件测试只要能发现 BUG 就够了； 还有人认为软件测试可以尽 自己所能尽可能的去寻找 BUG 的原因。到底哪个观点正确？我个人认为这个问题是仁者见 仁，智者见智，站在一个产品不同的层面看，会有不同的看法。这里所谈到的观点，也仅代 表个人看法。 要搞清楚这个问题，先要明确几个定义，首先要明确什么是 QA？简单从字面上理解是 Quality Assure（质量保证） ，CMM 对 QA 的要求主要有下面几点：保障制度体系；促使过 程改进；指导项目实施；增加透明度；评审项目活动；审核工作产品；协助问题解决；提供 决策参考；进行缺陷预防；实现质量目标。其次什么是软件测试，软件测试是根据软件开发 各个阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期结 果） ，并利用这些测试用例去执行程序，以发现程序错误的过程。 而软件测试人员就是这一过程的执行者。 从上面的定义可以看到，QA 重点关注的不仅仅是质量，而是整个软件过程，保证的首 先是过程和体系，也就是说只有规范了过程和体系，才有可能做出好的产品。而软件测试就 是通过自己的活动，来给 QA 人员提供尽可能的有效的信息和数据，使他们能够发现过程上 的异常或者制度上的不妥之处。 可见软件测试的任务不仅仅是测试， 还要把项目的异常情况 向 QA 报告，所以只能报出 BUG 是不够的。其实 QA 和软件测试的目的都是一样的， 就是尽可能的使发布出去的产品更加符合用户 的需要，尽可能的没有 bug。不同之处只是一个关注的是整个软件过程，一个只是关注最终 的质量。 所以为了搞清楚软件测试要不要追究 BUG 发生的原因， 先要明确的是弄清楚 BUG 发生的原因对整个软件过程有什么好处，或者说对最终的质量有什么好处？ 对于开发来说，一般是能够重现这个 BUG 就够了，这样对于那些发生几率在 100％的 bug 来说，软件测试人员只要详细清晰的描述出 bug 发生的步骤，写明 bug 的发生条件，执 行这些操作的用户的角色以及权限， 使用的操作系统和浏览器， 然后写清楚实际结果和期望 结果，基本上就差不多了，开发根据这些描述能够知道是如何出现的问题，并且知道应该改 成什么样。到时候软件测试人员（可能不是原来报 BUG 的那个人了）进行回归测试时根据 BUG 的描述，也可以很清楚的知道这个 BUG 是否真的改好了。但是如果一个 BUG 的发生 几率不是 100％，或者说在某些特定的条件下的发生几率是 100％，但是一般情况下都不存 在。测试人员可能只是偶然发现这个问题，却会认为是 100％出现，报 BUG 时也就没有指 明这个问题出现的条件，开发看到这种 BUG，根本无法重现，再打给测试人员，如此反复 几次，虽然最终问题得以解决，但是对于整个项目来说，却是浪费了很多的时间。如果在发 现问题时。能够多试几下，或者换个环境试试，可能就会找到发生几率不是 100％的原因， 比如非法数据，特殊字符，特殊用户权限，特殊日期，或者在系统中还有其他自己不知道的 参数的影响，或者是操作系统的问题，又或者是浏览器的设置问题，还有可能是浏览器的版 本问题等等， 寻找这些原因的过程， 是一个自我提高的过程， 也是积累自己测试经验的过程， 同时也是证明测试角色重要的过程，是证明测试人员价值的过程。 当然目前国内的软件公司中测试人员的水平还不是很高， 想看懂开发的代码并且进行测 试难度还比较大，所以我也不主张去看着开发的代码进行测试，只需要在测试的时候，多考 虑一下，尤其是出现问题的时候，多想想这个问题为什么会发生，会影响到系统中其他什么 地方，还会有其他哪些地方有可能存在这样的问题，这样等到开发修改好之后，提交测试进 行回归检测时也可以做到有的放矢， 尤其是在回归测试时间很短的情况下， 如何进行有效的 回归测试，并且保证不漏掉重大隐患，我想和开发水平固然有关，但是关系最大的还是测试 人员对系统的熟悉程度，以及是否具有软件开发的思想。 追究 bug 的原因，不是一朝一夕的事，需要长期的摸索和总结，开始会很烦，可能还会 很郁闷， 但是慢慢的你会发现其中的乐趣， 想一想当你报给开发一个 Bug 的时候， 随着 bug 的报告还有一个详尽的发生这个 bug 的条件数据， 以及测试平台等数据， 开发根据这些很容 易重现这个问题， 会对测试人员的专业度有很大的认可， 那时我想自己心里的成就感不是几 句话可以说完的了！?黑盒测试如何保证测试的覆盖率？在黑盒测试中要保证测试的覆盖率，主要要做好测试需求分析 测试需求分析分两步： 1，测试需求的获取 需求的来源：显式需求（1）原始需求说明书（2）产品规格书（3）软件需求文档（4） 有无继承性文档（5）经验库（6）通用的协议规范 隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析 2，需求的分析 ，产生测试需求文档 将不同的需求来源划分成一个个需求点，针对每一点进行测试分析， （1）界定测试范围 （2）利用各种测试设计的方法产生测试点 黑盒测试如何保证需求的覆盖度？假设需求是不变的。 我们只需要使用黑合测试的策略 用等价类、边界值、错误推测、因果图、判定表驱动、正交试验、功能图、场景法等测试就能保证需求的覆盖度。当然这是理想的情况。但是，在真实的项目中需求是在变化的。这就 要求做好需求管理。如用 TD 记录需求的变更，及对需求的管理。就以得到比较高的需求覆 盖。个人认为管理好需求，是保证需求的覆盖度的关键点。 在测试方法方面，可做如下注意： 其一，分析出口入口。从入口分析，将可能出现的环境，条件，操作等内容分类组合， 然后根据各位测试达人的方法进行整合，逐一验证。从出口分析，将可能出现的结果进行统 计， 根据结果的不同追根溯源， 再找到不同的操作以及条件等内容， 统计成文档， 逐一验证。 其二，多种测试手法的学习和使用。大家可能更多的关心测试方法，但是具体操作的手 法也是需要注意的。毕竟测试方法比较容易找到，各位达人都很熟悉。如果将每个人不同的 测试手法总结出来并在自己的测试实施中加以使用，可能会收到意想不到的成果。 在测试流程方面，可作如下注意： 其一，初期要做好需求分析。将需求逐渐细化到小功能点，针对每个功能点进行测试设 计。对于完成的测试设计文档，经过项目相关人员的检查评审，做成所需要的初稿。 其二， 在测试过程中， 根据需求变更和具体测试执行过程中遇到的问题完善测试设计文 档。 其三，测试执行结束后，对于出现的问题进行总结。其中包含自己本身发现的问题，也 可能会有客户提出的问题。 将总结出来的结果融合到测试设计当中去， 进一步完善测试设计 文档。 对于一次测试，是不可能有覆盖度全面的测试的。需要多次去总结积累，才会使测试越 来越全面。 在测试流思维方面，可作如下注意： 其一，测试全面不等于全面测试。不同阶段对于软件测试有不同的要求，比如在 0.8 版 本以前，对于不重要的画面问题或是细小的功能问题就不需要关心。但是在验收阶段，这些 内容可能更需要注意。 其二，学无止境，只有不断的去学习不断的去思考，才能使自己测试的能力更强，测试 对象的全面性也更完整。?软件测试:C/S 结构的应用程序的性能测试虽然 B/S 结构愈来愈成为流行模式， 但基于 C/S 结构的应用程序还广泛地应用于各种行 业。 对于某些应用软件， 其承受大用户量并发访问的能力常常是应用者重点考虑的一个方面。 最好的方法是用测试工具来模拟多个客户端同时访问服务器， 并使用性能监测工具获得关于 服务器、数据库等用户关心的性能指标。中国软件评测中心在多年的测试历程中，使用过多 种性能测试工具，而对于 C/S 结构的应用程序，也总结了不少性能测试经验和方法。下面以 中国软件评测中心经常用到的一种压力测试工具 QALoad 为例，说明这类性能测试需要注 意的地方。 1、首先分析压力测试中最容易出现瓶颈的地方，从而有目的地调整测试策略或测试环 境，使压力测试结果真实地反映出软件的性能。例如，服务器的硬件限制、数据库的访问性 能设置等常常会成为制约软件性能的重要因素， 但这些因素显然不是用户最关心的， 我们在 测试之前就要通过一些设置把这些因素的影响调至最低。 2、测试脚本至关重要。对于某些应用，如 ADO、ODBC 等等，QALoad 可以录制/回放 脚本， 这给测试工作带来极大的便利， 但用这样采集来的脚本直接作为压力测试的脚本往往 会导致错误的结果。 我们需要对原始的脚本进行修改， 根据应用程序的实际情况和用户可能 的操作情况调整脚本的结构，从而使脚本更符合实际情况。比如，我们录制一个用户登录、 操作和注销的过程，实际情况是多数用户只登录一次，然后进行多次操作，这时我们只需在脚本中把登录和注销部分转至循环（即脚本中的 Transaction 部分）外即可。 3、选用不同的加载策略可以反映不同状况下的性能。QALoad 可采用的策略有： （1）并发用户数和每个模拟用户运行的事务数都为固定值； （2）并发用户按固定的时间间隔递增，每个模拟用户数运行的事务数不限； （3）以类似于批处理的方式顺序运行不同并发数的模拟用户，每个模拟用户运行的事 务数 固定； （4）并发用户数固定，运行事务数不限，在一定的时间范围内持续运行脚本，然后手 动停止； （5）不同模拟用户运行不同的脚本，模拟真实的访问情况。 另外，QALoad 还提供设 置数据变量和数据池， 设置操作之间的间歇时间等功能， 我们在运行脚本时可以充分利用这 些策略和功能。 4、寻求多种性能指标的获取方法。由 QALoad 本身提供的性能指标是每个“检查点”的 响应时间，这些响应时间可以通过统计分析以获得更直观的结果，如平均响应时间、响应时 间方差等等，但这些远远不能满足我们压力测试的需要。对于基于 Windows 系列平台的应 用，QALoad 可以添加 Windows 服务捕获的性能指标，前提是在服务器上安装 QALoad 的 Agent 组件并启动服务器上的 SNMP 等服务。对于如 UNIX 的其他平台，我们可以借助专用 性能监测工具，如 MAX、 ECOTool，以获取更有价值的性能数据。 大多数性能测试， 特别是基于 C/S 结构的应用软件的性能测试只有借助于测试工具才能 完 成，另一方面，也需要测试工程师灵活的运用才能让测试工具充分发挥作用。?软件测试:.Net 下测试的相关知识属性 TestDriven.NET 支持多种单元测试框架，像 NUnit，MbUnit，MS Team System，这里 我选择了最为经典的 NUnit 单元测试框架来介绍 TestDriven.NET 所支持的一些重要的属性。 TestDriven.NET 其实已经支持大部分 NUnit 的属性，但是有些属性现在还不支持。 在我们使用 TestDriven.NET 测试前， 项目必须引用框架的程序集， nunit.framework.dll， 即 并 且在每 个包含测 试的源 文件中 必须使用 using 语句引 用该程序 集，像 这样： using NUnit.F 在 NUnit 中，所有的属性都包含在 Nunit.Framework 命名空间里。 首先我们依次熟悉一下这些属性。 1.TestFixtureAttribute 这个属性用来修饰测试类， 表示这个类包含了测试方法。 注意一下使用这个属性修饰类 有一些限制：这个类必须是 public，必须有一个缺省的构造函数。 using S using NUnit.F namespace TestDrivenNET { [TestFixture] public class YJingLeeFixture { //...... } } 2.TestAttribute 这个属性标记类的某一方法为一个测试方法，此类已经标记为一个 TestFixture。一个测试方法的签名定义如下： [Test] public void TestMethod() { }注意这个方法必须没有参数。如果程序员将测试方法标记为不正确的签名，它不会运 行。 3.SetUpAttribute 这个属性用来修饰方法， 修饰后这个方法在每个测试方法被调用之前运行的， 我们可以 用它来重新设置一些变量，在每个方法运行之前赋值。 [SetUp] public void Init() { } 4.TearDownAttribute 这个属性用来修饰方法， 说明这个方法是在每个测试方法被调用完之后运行的， 我们可 以用来释放一些暂存的变量。 [TearDown] public void Dispose() { } 5.SetUpFixtureAttribute 这个属性这个属性用来修饰类，这个类包含了 SetUpAttribute 或者 TearDownAttribute 属性，必须是 public 和一个缺省的构造函数。只要使用这个属性，在其命名空间下，运行测 试 则 首 先 运 行 其 中 SetUpAttribute 修 饰 的 方 法 ， 在 运 行 测 试 结 束 则 运 行 其 中 TearDownAttribute 修饰的方法。注意一个命名空间下只有一个 SetUpFixtureAttribute，如果 这个属性在整个程序集下定义，则在整个程序集下有效。我们常常用它来设置全局的条件。 [SetUpFixture] public class MySetUpClass { [SetUp] public void RunBeforeAnyTests() { } [TearDown] public void RunAfterAnyTests() { } } 6.TestFixtureSetUpAttribute 这个属性用来修饰方法，修饰后这个方法在 fixture 任何测试执行之前运行，我们常常 用来初始化一些对象等，类似于类中的构造函数。 [TestFixtureSetUp] public void FixtureInit() {} 7.TestFixtureTearDownAttribute 这个属性用来修饰方法，修饰后这个方法在 fixture 任何测试执行之后运行，我们常常 用来释放一些资源。 [TestFixtureTearDown] public void FixtureDispose() { }?软件测试:测试用例的复审测试用例的设计是整个软件测试工作的核心， 测试用例反映对被测对象的质量要求和 评估范围，决定测试的效率和测试自身的质量。 所以对测试用例的评审，就显得非常重要。测试用例设计完之后，要经过非正式和正式 的复审和评审。在测试用例审查、评审过程中，主要检查下列内容： * 测试用例设计的整体思路是否清晰， 是否清楚系统的结构和逻辑从而使测试用例的结 构或层次清晰，测试的优先级或先后次序是否合理； * 测试用例设计的有效性，测试的重点是否突出，即是否抓住修改较大的地方、程序或 系统的薄弱环节等； * 测试用例的覆盖面，有没有考虑到产品使用中一些特别场景（scenario） 、考虑到一些 边界和接口的地方； * 测试用例的描述，前提条件是否存在、步骤是否简明清楚、期望结果(Criteria)是否符 合产品规格说明书或客户需要； * 测试环境是否准确，测试用例有没有正确定义测试所需要的条件或环境； * 测试用例的复用性和可维护性， 良好的测试用例将会具有重复使用的功能, 保证测试 的稳定性； * 测试用例是否符合其他要求，如可管理性、易于自动化测试的转化等。 测试用例在评审后，根据评审意见做出修改，继续评审，直至通过评审。在以后的测试 中，如果有些被发现的缺陷，没有测试用例，应及时添加新的测试用例或修改相应的测试用 例。和软件缺陷相关的测试用例是更有效的测试用例，其执行的优先级也高。通过测试用例 所发现的缺陷占所有软件缺陷的比值，是衡量测试用例质量和有效性的方法之一。?软件测试：对文档编制的质量要求为使软件文档能起到多种桥梁的作用，使它有助于程序员编制程序，有助于管理人员监 督和管理软件的开发， 有助于用户了解软件的工作和应做的操作， 有助于维护人员进行有效 的修改和扩充，文档的编制必须保证一定的质量。 如果不重视文档编写工作， 或是对文档编写工作的安排不当， 就不可能得到高质量的文 档。质量差的文档不仅使读者难于理解，给使用者造成许多不便，而且会削弱对软件的管理 (难以确认和评价开发工作的进展情况)，提高软件成本(一些工作可能被迫返工)，甚至造成 更加有害的后果(如误操作等)。 (1)针对性：文档编制以前应分清读者对象。按不同的类型、不同层次的读者，决定怎 样适应他们的需要。例如，管理文档主要是面向管理人员的，用户文档主要是面向用户的， 这两类文档不应像开发文档(面向开发人员)那样过多使用软件的专用术语。 (2)精确性：文档的行文应当十分确切，不能出现多义性的描述。同一课题几个文档的 内容应当是协调一致，没有矛盾的。(3)清晰性：文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性。 (4)完整性：任何一个文档都应当是完整的、独立的，它应自成体系。例如，前言部分 应做一般性介绍，正文给出中心内容，必要时还有附录，列出参考资料等。 同一课题的几个文档之间可能有些部分内容相同， 这种重复是必要的。 不要在文档中出 现转引其他文档内容的情况。例如，一些段落没有具体描述，而用“见× 文档 x× ，的方 × 节， 式，这将给读者带来许多的不便。 (5)灵活性：各个不同软件项目，其规模和复杂程度有着许多实际差别，能一律看待。 1)应根据具体的软件开发项目，决定编制的文档种类。 软件开发的管理部门应该根据本单位承担的应用软件的专业领域和本单位的管理能力， 制定一个对文档编制要求的实施规定。主要是：在不同条件下，应该形成哪些文档?这些文 档的详细程度?该开发单位每一个项目负责人都应当认真执行这个实施规定。 对于一个具体的应用软件项目， 项目负责人应根据上述实施规定， 确定一个文档编制计 划。其中包括： 应该编制哪几种文档，详细程度如何。 各个文档的编制负责人和进度要求。 审查、批准的负责人和时间进度安排。 在开发时期内各文档的维护、修改和管理的负责人，以及批准手续。 有关的开发人员必须严格执行这个文档编制计划。 2)当所开发的软件系统非常大时，一种文档可以分成几卷编写。例如， 项目开发计划可分写为：质量保证计划、配置管理计划、用户培训计划、安装实施计划 等。 系统设计说明书可分写为：系统设计说明书、子系统设计说明书。 程序设计说明书可分写为：程序设计说明书、接口设计说明书、版本说明。 -操作手册可分写为：操作手册、安装实施过程。 测试计划可分写为：测试计划、测试设计说明、测试规程、测试用例。 测试分析报告可分写为：综合测试报告、验收测试报告。 项目开发总结报告也可分写成：项目开发总结报告、资源环境统计。 3)应根据任务的规模、复杂性、项目负责人对该软件的开发过程及运行环境所需详细程 度的判断，确定文档的详细程度。 4)对国标 GB8567―88《计算机软件产品开发文件编制指南》所建议的所有条款都可以 扩展，进一步细分，以适应需要;反之，如果条款中有些细节并非必需，也可以根据实际情 况压缩合并。 5)程序的设计表现形式，可以使用程序流程图、判定表、程序描述语言(PDI，)、或问 题分析图(PAD)等。 6)对于文档的表现形式，没有规定或限制。可以使用自然语言、也可以使用形式化的语 言。 7)当国标《计算机软件产品开发文件编制指南》中所规定的文档种类不能满足某些应用 部门的特殊需要时， 可以建立一些特殊的文档种类要求。 这些要求可以包含在本单位的文档 编制实施规定中。 《软件产品开发文件编制指南》中给出了一个例子，利用求和法综合衡量 12 种考虑因 素，来确定应编制文档的种类。使用这个方法的具体过程如下： a.针对表所列的 12 种衡量因素，考察所开发的软件。对每一种因素给出一个分值，其 范围从 1 到 5。 b.把衡量所得的各个因素的值相加，得总和之值。c.根据总和之值，对表表进行查找，确定应编制的文档的种类。 其中， 数据要求说明书栏用**表示应当根据所开发软件的实际需要来确定是否需要编制 这个文档。测试分析报告栏用*表示这个文档应该编写，但不必很正规。 (6)可追溯性：由于各开发阶段编制的文档与各个阶段完成的工作有密切的关系，前后 两个阶段生成的文档，随着开发工作的逐步延伸，具有一定的继承关系，在一个项目各开发 阶段之间提供的文档必定存在着可追溯的关系。 例如， 某一项软件需求， 必定在设计说明书、 测试计划、甚至用户手册中有所体现。必要时应能做到跟踪追查。?软件测试:微软测试工程师面试题1. 你如何在 pocket pc 上 TEST 你的程序. 你考虑了哪些方面. 2. 如果将你的程序的语言扩展到非英语,例如中文, 你如何测试. 3. 给你一个 COCAN, 你如何测试(解释说就是罐装的可口可乐). 4. 当你的程序遇到 BUG 的时候，你选择怎样处理. 5. 你如何 isolation 你程序里的 BUG. 6. 给你一个产品有 10 个 functionality,如果时间紧迫, 只能测其中的 5 个, 你如何选择. 其它相关： 如果别人问我这些题目， 我想我会大致这样回答， 各位从事软件测试的同志们帮我看看 回答的怎么样。 01. 为什么要在一个团队中开展软件测试工作？ 答： 软件测试在整个一个团队中占有非常重要的地位， 具体来说就是测试是一个发现软 件错误的过程，执行软件测试会以最少的人力和时间，系统的找到软件存在的缺陷和错误， 建立起开发人员和使用者对软件的信心。 02. 您是否了解以往所工作的企业的软件测试过程？如果了解， 请试述在这个过程中都 有哪些工作要做？分别由哪些不同的角色来完成这些工作？ 答：软件测试部门配合系统分析人员软件需求分析讨论，并根据需求说明书制定《项目 测试计划》 ，编写测试用例，建立测试环境。 软件测试人员负责软件开发部门的新产品测试及原有产品的升级测试， 负责软件问题解 决过程跟踪， 负责软件开发文档开发工作的规范化及管理开发部门的产品文档， 制作用户手 册及操作手册，负责产品的上线测试，监督软件开发过程的执行，提高产品质量。 03. 您是否了解以往所工作的企业的软件开发过程？如果了解， 请试述一个完整的开发 过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？ （对于软件测试部分， 可 以简述） 答：需求人员连同系统分析人员&测试人员开会讨论需求。系统分析人员写出需求分析 说明，并连同系统分析人员&测试人员&需求人员开会讨论可行性。系统分析人员写出详细 设计说明书，程式人员编码，给出系统流程图。交与测试人员，测试人员给出 Bug 统计表。 04. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？ 答：从事过 write test plan，creation of test case，进行功能测试，性能测试，编写测试工 具，文档的管理等，比较擅长与写测试用例和进行功能测试。 05. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别 与联系（如功能测试、性能测试……） 答：有功能测试，性能测试，可靠性测试，安全性测试，负载测试，压力测试，安装/ 卸载测试，启动/停止测试，兼容性测试，互连测试，文档测试，恢复测试，回归测试，可 使用性测试，容量测试。 功能测试只对软件的功能是否满足用户需求来做测试。 性能测试需要和压力和负载测试联合起来。 06. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试 的区别与联系。 黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性，只 依据程式的需求说明书来检查程式的功能是否满足它的功能说明。 白盒测试： 把测试对象当成一个透明的盒子， 允许测试人员利用程序内部逻辑结构及相 关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。 单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。 集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。 系统测试：在所有都考虑的情况下，对系统进行测试。 验收测试：第三方进行的确认软件满足需求的测试。?软件测试:网站安全测试的两个部分个人认为网站安全测试应分为两部分：安全体制测试和应用与传输安全测试。以下为简 单说明： 一.安全体制测试 1.部署与基础结构 网络是否提供了安全的通信。 部署拓扑结构是否包括内部防火墙。 部署拓扑结构中是否包括远程应用程序服务器。 基础结构安全性要求的限制是什么。 目标环境支持怎样的信任级别。 2.输入验证 是否清楚入口点 是否清楚信任边界 是否验证 web 页输入 是否对传递到组件或 web 服务的参数进行验证 是否验证从数据库中检索的数据 是否依赖客户端的验证 应用程序是否易受规范化问题的影响 应用程序是否易受 SQL 注入攻击 应用程序是否易受 XSS 攻击 3.身份验证 是否区分公共访问和受限访问 是否明确服务帐户要求 是否在网络中传递明文凭据 是否实现自己的用户存储 是否使用表单身份验证 是否使用 SQL 身份验证 是否使用进程帐户 是否使用服务帐户 是否考虑使用匿名 Internet 用户身份 是否使用原始用户身份 如何保存数据库连接字符串是否强制使用强帐户管理措施 4.授权 是否使用深层防御策略 使用了哪些网关守卫 是否使用基于角色的方法 角色是否提供足够的特权隔离 设计是否使用代码访问安全性 应用程序使用哪些身份 5.配置管理 是否支持远程管理 是否保存配置存储的安全 是否隔离管理员特权 6.敏感数据 是否存储机密信息 是否在网络中传递敏感数据 是否记录敏感数据 7.会话管理 如何交换会话标识符 是否限制会话生存期 如何确保会话状态存储的安全 8.加密 是否开发自己的加密技术 是否使用合适的密钥大小来应用正确的算法 如何确保加密密钥的安全性 9.异常处理 是否使用结构化的异常处理 是否向客户端公开太多的信息 10.审核和日志记录 是否明确了要审核的关键活动 是否考虑过如何流动原始调用者身份 二.应用及传输安全 1.注册与登录 2.在线超时 3.操作留痕 4.备份与恢复 5.HTTPS 和 SSL 测试 6.服务器端的脚本漏洞检验 7.防火墙测试?软件测试:自动化测试框架 STAF 的使用因为工作关系，两年前本人曾调研过 STAF 软件，当时想为 VcTester 工具构造一个具有 对等通信关系的 IPC 组件，尽管最终还是弃用 STAF，改用自行开发的 SRPC 组件，不过仍 觉得 STAF 是不错的自动化控制框架， 尤其是跨机控制， 用起来比较方便， 而且它是开源的。 关于 STAFSTAF（TheSoftwareTestingAutomationFramework）是发端于 IBM 的自动化测试框架， 如果我没记错的话，2000 年的时候 STAF 就有版本了，不过那时的 STAF 比较简单，做不了 多少事情。过去这么多年，STAF 现已发展成一个庞大体系了。 STAF 主页（http://staf.sourceforge.net/）对该软件介绍如下： STAF 是开源、跨平台、支持多语言的自动化测试框架，它围绕于组件重用的理念，通 过服务调用（比如处理调用、资源管理、登陆、监视等）帮助大家省去繁琐的自动化架构建 设工作，大家只需集中精力在自身自动化实施上。STAF 为自动化测试建立了基础，在高层 解决方案提供一种可插拨的机制，支持多种平台与多种语言。 使用 STAF 可快速构造自动化测试环境，STAF 的服务调用系统也让大家创建自动用例 与管理自动用例更加方便。STAF 在功能级别实施服务调用，各个服务端点（称作 STAF 客 户端） 是对等的， 从一个端点可直接调用另一端点 （在另一台机器运行的程序） 提供的服务。 换另一个角度看，STAF 是一种分布式远程调用体系，它具有如下特色： ? 将环境需求最小化（包括硬件与软件） ? 在各种语言中都很容易使用，包括 Java，C/C++，Rexx，Perl，TCL，及命 令行 shell 环境 ? 易于扩展，让用户能方便的创建一个服务插入到 STAF 体系中 STAF 比较适应需要构造复杂测试环境的场合，复杂测试环境通常是分布式的，通过 STAF 将测试任务分发到不同的测试环境去执行，可以方便的测试机的测试脚本，可以方便 的收集测试结果， 另外， 执行引擎 STAX （SoftwareTestAutomationeXecutionEngine） STAF 让 的使用变得更简单，测试人员只需要配置 XML 文件便实现 STAF 任务管理。 几个概念 服务（Services） ： STAF 是基于服务（Services）来构建自动化框架的，服务就是 STAF 的可重用组件，服 务还是一系列功能的集合。 如何理解 STAF 与服务的关系？STAF 是一个小巧的后台程序，在 STAF 中使用的所有 组件都是服务，STAF 提供轻量级分发机制，负责将请求转发给这些服务。 STAF 中服务分两种：Internal（内部服务）和 External（外部服务） 。内部服务被集成进 STAFProc，提供一些关键性的功能，比如数据管理与同步，外部服务则由 STAFProc 动态装 入，通过共享库(sharedlibraries)来访问。 STAF 中常见服务有： ? ProcessService：这是内部服务，用来调用外部程序 ? FileSystemService：这是内部服务，可以对文件进行复制、删除、查看等操 作 ? LogService：这是外部服务，用于日志的记录和查看 ? ResPoolService：这是外部服务，提供查看、创建、删除等针对资源池的管 理或操作 ? MonitorService：这是外部服务，提供运行监控功能 ? SemService：这是内部服务，提供 mutex 和 event 信号量操作 ? ZipService：这是外部服务，提供压缩与解压 ? PingService：这是内部服务，用来检测远程 STAF 是否在运行 请求/响应： STAF 的服务以字符串形式表达，每个请求都有三个参数（系统、服务、参数） ，第一 个参数指示目标 STAF 系统，该参数由 STAFProc 解析以便确定是在本地处理还是发送到远 端 STAF 系统，第二个参数指示调用哪个服务，第三个参数运行服务的参数。当服务处理结束将返回两类数据，一是表示服务处理结果的返回码，二是服务返回特定数据。 执行引擎： STAX 是基于 STAF 的执行引擎，它采用 XML 格式描述。在 XML 文件中可定义测试 工作流，可以实现并行执行、嵌套测试用例、控制运行时间等，STAX 支持 Java 和 Python 模块。 STAF 与 VcTester 前两年我们调研 STAF 是想拿它构造本机跨进程的通信机制，后来发现 STAF 无法满足 我们的要求，在本机的 IPC 我们要求更精细，进程之间要支持更实时的响应能力，通信包 可能很小，也可能很大，我们需要一种能平滑自适应系统，对大消息通信，还应自动改由文 件方式传递，此外，跨进程服务的启动与关闭、重起等操作，我们有更精细要求。所以，我 们就自行开发一种基于共享内存通信的 SRPC 组件，在它之上再叠加跨进程 MVC 机制，这 就是大家使用 VcSmith 或 VcTester 看到的 RemoteUI 功能。 当然，这里我讲的是 STAF 的本地服务，STAF 的跨机测试控制无疑非常强大，适应平 台与编程接口都很丰富。所以，后续 VcTester 版本在向自动化测试延伸后，我们将考虑提 供基于 STAF 插件结构的服务调用机制。?软件测试:如何有效制定测试计划？说实话，刚看到同行在论坛里提这个问题时，感觉这个问题问的太大了，真是不知道该 怎么帮助这位同行，今天想想，就从一些硬件方面着手说说吧，我这里说的硬件指的是大概 把握点；软件方面是指如何有效灵活应用，由于各种情况太多，个人能力有限，这里就只谈 谈要把握的几个基本点。 测试计划的制定， 要考虑的因素确实很多， 但要抓住最主要的就可以避免大的测试执行 风险。 为了有效的制定测试计划， 首先要清楚， 制定这个测试计划的目的是什么， 作用是什么。 考试大认为测试计划的主要作用是：明确工作内容、工作完成时间、工作资源、工作风 险等、最终目的是提高测试的工作效率，作为保障测试工作顺利、保质保量完成。 那么，如何有效制定测试计划？ 第一：根据自身实际情况的项目、团队管理情况，要有个合适的测试计划文档模块用于 编写测试工作的测试计划、便于向项目中的其它成员告知测试工作是如何安排和进行的。 测试计划文档现在在网上有一堆，看了好几个，自己综合后整理了一个，最终认为测试计划 文档大纲要包含如下内容： ------目录 ------1. 简介 ----------1.1 编写目的 ----------1.2 编写背景 ----------1.3 使用范围 ----------1.4 参考资料 ------2. 测试说明 ----------2.1 测试项说明 --------------2.1.1 系统名称 --------------2.1.2 应测试项 --------------2.1.3 非测试项 ----------2.2 测试资源 --------------2.2.1 硬件设备--------------2.2.2 软件设备 --------------2.2.3 人员安排 --------------2.2.4 测试工具 ----------2.3 测试安排 --------------2.3.1 测试培训 --------------2.3.2 测试进度 ----------2.4 测试文档 ------3. 系统风险 ------4. 测试优先级 ------5. 测试策略 ----------5.1 接口测试 ----------5.2 集成测试 ----------5.3 数据和数据库完整性测试 ----------5.4 功能测试 ----------5.5 用户界面测试 ----------5.6 性能测试 ----------5.7 负载测试 ----------5.8 强度测试 ----------5.9 容量测试 ----------5.10 安全性和访问控制测试 ----------5.11 故障转移和恢复测试 ----------5.12 配置测试 ----------5.13 安装和反安装测试 ------6. 评价准则 ----------6.1 范围 ----------6.2 尺度 --------------6.2.1 测试覆盖率 --------------6.2.2 质量评测 --------------6.2.3 缺陷报告 --------------6.2.4 性能评测 上面这些内容大家看起来会觉的很多很全， 这个模板适合大的测试项目， 个人用着感觉 不错；可能，有的人会问，我可能只是做功能的测试，我只是做一个数据迁移的测试，可能 涉及的测试项根本没有那么多，那么我该怎么写我的测试计划呢？ 第二：根据具体测试工作任务情况编写测试计划，剪裁适合自己的测试计划模板 上面给的都是在写测试计划中要考虑的点， 就像在执行测试时都要执行的测试用例点有 哪些。具体在写测试计划中，那些信息是需要考虑的，那些东西是不需要考虑的，可以根据 自己项目的具体情况进行裁剪和设计即可。 模板只是起到提醒作用，提醒在测试前需要注意考虑的信息都有哪些？在具体编写中， 如果没有经验， 要适当请教公司内部有经验人士给予评价和指导， 便于制定出来的计划是可 行的并没有遗漏重要点。 下面是通常非常小的测试任务中， 我用过的感觉非常好的测试计划模板表格， 供大家参 考：第三：测试计划不是一层不变的，随着项目的进行，会由于各方面的因素（如：提交测 试的程序版本质量低、bug 量大修改慢、需求变更等等）导致测试计划无法按原计划执行， 这时要适当的调整测试计划。 关于如何有效制定测试计划， 我只是范范的写这么几点， 不知道是否会给大家一些启发； 最后还想补充点：在制定测试计划时，关于人员分工这部分，要根据每个人对系统的熟悉程 度以及能力情况进行分配，让大家的能量都能得到最大化的发挥。?用例执行百分比=项目完成百分比？时常会有人通过用例执行的百分比来宏观的去看一个项目的测试进度情况。 但是遇到这种情况的时候测试工程师会说， 用例的执行的百分比不足以展示一个项目的 测试进度。 为什么会有这种矛盾呢？ 其实这个等式成立有一定的前提条件， 那就是测试工程师写的测试用例的测试粒度是否 合理 怎样的粒度才是合理？ 1、测试粒度不宜过细，测试用例分解的测试粒度过细会给测试工程师带来成倍的额外 工作量，对于项目管理来讲，这样是不合算的。 2、测试粒度不宜过粗，这是因为如果一个测试用例，里面包含了太多验证点。比如在 写取钱的用例时， 要检查余额查询， 用户最大额度查询类似的本可以单独一个用例的东西都 硬拼到了一起， 那么用例的执行进度和项目的进度肯定不能划等号。 简单说就是有的用例简 单有的用例复杂，所以有的也许要验证半天，有的只需要 10 分钟。这样的话，文章开头的等式就当然不相等了。 粒度过粗还有个麻烦就是， 发现很多 bug 都对应着一个用例。 这样给缺陷管理和统计起 来也带来麻烦。在项目后期的报告中不能清晰的统计缺陷。 如何划分测试粒度？ 1、使用功能点划分，细化每个功能点，到这个功能点不能再拆分。 2、所要测试模快对该系统的整体影响.看其重要性。 3、最好在用例编写前，项目的测试工程师可以讨论出一个适合项目的统一测试粒度。?并发用户数、系统用户数和同时在线用户数假设有一个 OA 系统，该系统有 2000 个使用用户――这就是说，可能使用该 OA 系统 的用户总数是 2000 名，这个概念就是“系统用户数”，该系统有一个“ 在线统计”功能（系统 用一个全局变量记数所有已登录的用户） ，从在线统计功能中可以得到，最高峰时有 500 人 在线（这个 500 就是一般所说的“同时在线人数”） ，那么，系统的并发用户数是多少呢？ 根据我们对业务并发用户数的定义， 500 就是整个系统使用时最大的业务并发用户数。 这 当然，500 这个数值只是表明在最高峰时刻有 500 个用户登录了系统，并不表示实际服务器 承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这 500 个“同 时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中 40%的用户在较有兴 致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的） ，20%的用户在填 写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写 过程是不对服务端构成压力的） 20%部分用户在发呆 ， （也就是什么也没有做） 剩下的 20% ， 用户在不停地从一个页面跳转到另一个页面――在这种场景下，可以说，只有 20%的用户 真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取 决于业务并发用户数，还取决于用户的业务场景。 在实际的性能测试工作中， 测试人员一般比较关心的是业务并发用户数， 也就是从业务 角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务 并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。 （1） 计算平均的并发用户数： C = nL/T （2） 并发用户数峰值： C? ≈ C+3 根号 C 公式（1）中，C 是平均的并发用户数；n 是 login session 的数量；L 是 login session 的 平均长度；T 指考察的时间段长度。 公式（2）则给出了并发用户数峰值的计算方式中，其中，C?指并发用户数的峰值，C 就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的 login session 产生 符合泊松分布而估算得到的。 实例： 假设有一个 OA 系统，该系统有 3000 个用户，平均每天大约有 400 个用户要访问该系 统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为 4 小时，在一天 的时间内，用户只在 8 小时内使用该系统。 则根据公式（1）和公式（2） ，可以得到： C = 400*4/8 = 200 C?≈200+3*根号 200 = 242?做好测试计划和测试用例工作测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导， 但是， 现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性， 在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭 借自己的经验在执行测试活动，对此，你有什么样的看法？ 个人认为做好测试计划的编写工作应该从以下几个方面考虑问题： 1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。 编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、 时间资源、 人力资源等等， 准确地说是要分析执行时所能够调用的一切资源以及受各种条件 限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是 “如何编写测试计划”。 2、要坚持“5W1H”的原则，明确测试内容与过程。 明确测试的范围和内容（WHAT） ； 明确测试的目的（WHY） ； 明确测试的开始和结束日期（WHEN） ； 明确给出测试文档和软件册存放位置（WHERE） ； 明确测试人员的任务分配（WHO） ； 明确指出测试的方法和测试工具（HOW） 。 3、采用评审和更新机制，确保测试计划满足实际需求。 因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化， 测试计划也需要及时地进行变更。 之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估， 以保证测试的质量。 4、测试策略要作为测试的重点进行描述。 测试策略是测试计划中的重要组成部分， 测试计划是从宏观上说明一个项目的测试需求、 测试方法、测试人员安排等因素，而测试策略则是说明世纪的测试过程中，应该怎样具体实 施。因此，测试策略一定要描述详尽并且重点突出。 打个不太恰当的比喻， 你可以认为测试计划就是测试工作的预期输出， 而测试执行是测 试工作的实际输出，在预期输出！=实际输出的情况下，您会认为这样的测试合格么？ 至于测试用例工作， 我认为我们首先要明确测试用例在整个测试工作中的地位及其作用。 个人认为，测试用例在整个测试工作中的地位和作用主要体现在以下几个方面： 1、测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表 现形式； 2、测试用例是团队内部交流以及交叉测试的依据； 3、在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工 作效率； 4、测试用例便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪， 以及测试人员的工作量的跟踪和考核； 5、在测试工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性； 6、测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验 收的依据。 当我们认识到测试用例在政工测试工作中的地位及其作用之后， 相信大家都已经认识到 了测试用例对测试工作的重要性和必要性， 那么， 我们就来讨论一下如何有效的保证测试用 例的质量。 1、做好测试人员的项目培训（主要指对需求分析、软件设计、测试计划的认知程度） 工作。 要想发挥团队中每一个成员的所有能力， 最好的办法就是让他们每一个人都清楚这个 项目中的所有细节，以及自己要在这个项目中所承担的责任。2、尽可能的利用以往其他项目的测试用例；并将该项目中类似模块进行归类，按类编 写测试用例，再根据每个模块的特点进行修改，要充分利用测试用例的可重用性。 3、在时间资源紧张的情况下，可以按照测试的关键路径编写测试用例，针对关键路径 的测试用例一定要详尽， 其他边缘模块的测试用例可以考虑仅通过性测试 （既仅证真测试） 。 4、采用针对测试用例的模块化编写。个人建议将测试用例和测试数据分开，测试用例 中的操作步骤应主要体现于业务流程的检验， 而测试数据主要体现于针对系统的数据处理结 果的检验。考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关 联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期， 提高工作效率。 以上是针对“做好测试计划和测试用例的工作的关键是什么”的问题的个人见解， 如有不 同意见，请大家及时指出和补充。?论性能测试中的“响应时间”1，“系统响应时间”如何定义？是指“客户端接收到响应所消耗的时间”还是“接收到最后 一个字节数据所消耗的时间。”？ 2， 书中提到“可以使用技巧在数据尚未接收完成时进行呈现来减少用户感受到的响应时 间”，这一句话是什么意思？ 先回答第一个问题，书中找到了原文： 而“系统响应时间”指应用系统从请求发出开始到客户端接收到数据所消耗的时间。 这里确实有不明确的地方，更确切的说法应该是：而“系统响应时间”指应用系统从请求 发出开始到客户端接收到所有数据所消耗的时间。 这样，“系统响应时间”加上“呈现时间”，才是完整的用户感受到的响应时间。 对于第二个问题，倒是有些可以讨论的内容： 我们在定义响应时间的时候，是从应用的使用者/客户的角度出发的。考试,大提示从这 个角度出发，响应时间被定义成“对请求做出响应所需要的时间”。我们以一个 web 应用为 例，假设 web 应用有一个“提交用户留言”的功能，考察这个功能的响应时间，就应该是“从 用户填写完留言，点击提交按钮开始，到页面刷新完成，用户看到完整的返回页面为止”所 消耗的所有时间――这个定义非常完整， 但若从用户的实际感受来看的话， 这里还是有一点 模糊的地方。 我们可以把上文提到的交互过程细化一下： 用户点击“提交”按钮-》请求被发送到服务器-》服务器处理-》服务器返回页面-》浏览 器接收服务器的返回并 render 页面 模糊之处在于最后一个环节：“浏览器接收服务器的返回并 render 页面”， 如果我们坚定 的认为“只有当页面完整的显示完成， 才是响应时间的结束”， 这不会是一个问题。 但实际上， 对大多数用户来说， 看到页面上开始显示数据或是图片， 用户就会认为“我已经得到了响应”， 从这个角度来说，用户感受到的响应时间实际上是“从请求发出开始，到用户看到页面开始 呈现出的内容结束”所需要的时间。 那为什么我们不采用“从请求发出开始， 到用户看到页面开始呈现出的内容结束”这样一 个定义方式呢？关键在于这里涉及到用户的认知行为， 带有主观色彩， 不完全是客观的标准， 因此不适合作为一个需要被度量的性能指标。另一方面，不同的浏览器有不同的行为（例如 parse 的方式和 render 的方式）如果需要把这些浏览器本身的行为都考虑到性能测试中的话， ， 我们很难为所有的系统建立统一的测试模型――实际上，现在的主流性能测试工具（例如 JMeter，LoadRunner，Webload 等）都完全不考虑客户端的呈现过程。?软件测试:你怎么看待缺陷漏测？如果产品在用户那里出现问题，产生的后果是非常严重的。在软件开发过程中，缺陷越 早被发现，发现和解决缺陷所花的成本就越小。 漏测的定义 所谓漏测， 是指软件产品的缺陷没有被测试组发现而遗漏到了用户那里， 却最终被用户 所发现。如果产品在用户那里出现问题，产生的后果是非常严重的。在软件开发过程中，缺 陷越早被发现， 发现和解决缺陷所花的成本就越小。 如果缺陷是在测试组测试中发现的而不 是被用户使用时发现的， 那么所花的成本将小得多。 如果缺陷是被开发组在开发过程中发现 的，那么所花的代价将更小。因此，进行漏测分析、预防漏测、促使缺陷尽可能在开发过程 的早期被发现，是非常有意义的，它有利于降低软件产品成本、提高软件产品质量。 漏测分析的目的 进行漏测分析的目的是为了促进软件质量和开发测试过程得到持续改进。 具体来讲， 就 是通过分析开发和测试过程中漏测的缺陷， 制定相应的预防措施以避免今后再发生类似的漏 测。 测试过程的持续改进将提高测试环境的效果和测试执行的效率、 降低遗留到用户处的缺 陷数和缺陷解决成本，从而提升软件的质量、声誉和销售。在软件产品开发过程中重视漏测 分析并参与到漏测分析工作中的团队越多， 漏测分析的效果就越好。 如果开发和测试团队都 重视漏测分析、并密切配合进行漏测分析工作的话，漏测分析将取得非常好的效果。?软件测试:如何更有效大家知道,软件测试对软件的测试是有限的，而在项目进度比较紧，测试人员、时间有 限的情况下，要进行充分的测试更是不可能！所以，如何在资源、时间有限的情况下测试的 更有效，成了我们要思考的一个重要问题。以下以实例进行有关说明，大家对都用过手机， 对手机的功能都不陌生，所以本文将全部用手机来做实例阐述！ 例 1．电话接打功能测试 对于电话接打这项手机最基本的功能， 在实际测试中测试人员可能要进行上千次的测试， 确保手机接打电话功能稳定可靠。 对于这种功能的验证测试， 有的测试人员可能每次测试的方法都相同， 如同样的电话呼 入后立刻接听， 如此反复， 测试几百次， 检测软件的可靠性！ 电话呼出时， 也是不变的方式， 不断地重拨，重复几百次！ 分析：上述测试方法，当然可以，但是效率高吗？能够发现更多的问题吗？答案是否定 的！ 测试思路： 对于这种问题，一定要注意拓展自己的思路，灵活进行，争取测试的效率和广度！ 对于来电，可以从以下角度进行测试： 第一，在接听电话时，可以注意在不同时间点接听，如刚刚响铃时接听，响铃一段时间 后接听，响即将结束时接听！这样可能会发现更多的问题！ 第二，来电时，可以在手机不同状态下来电，如手机进行菜单浏览、短消息查看等，不 同状态下来电； 第三， 注意来电的时间间隔， 如间隔时间很短的情况下来电和间隔一段时间的情况下来 电； 第四，注意来电情况，如电话本中联系人来电和非电话本联系人来电；座机来电、移动 电话来电和小灵通来电等； 第五，在不同情景模式下，如静音模式、会议模式、标准模式等模式下来电。第六，不同的接听方式，如设置成按任意键接听、应答键接听等不同接听方式. 对于呼叫，在拨打电话时，可以从以下角度考虑： 第一，直接输入数字进行拨打电话； 第二，从电话本中选择联系人呼叫； 第三，从通话记录中选择联系人进行呼叫； 第四，从短消息中提取号码进行呼叫。 另外，在进行这种电话接打测试的时候，可以考虑使用测试机对测试机器来进行，这样 下来，一组电话接打功能的测试，测试覆盖率提高了很多！ 例 2．短信查看+来电 这也是最基本的一种测试，多任务测试。 分析： 这里的来电，可以是固定电话，也可以是小灵通，也可以是手机；来电可以是电话本中 的联系人， 也可以是陌生电话来电。 对此， 如果能够把每种情况都测试一下当然最好不过了， 但如果时间紧迫，无法一一测试，我们该如何测呢？ 测试思路： 本项主要是短消息模块和电话模块之间的干扰问题， 我们在测试时， 可以选择电话本中 联系人来电，进行测试，这是因为在来电时，来电有多出了一个对电话本模块的查询、调用 功能，如果这种情况下没有问题，那么非电话本中号码来电时，一般不会有问题，相应地我 们就可以少进行一项测试。 例 3．录像+来电 现在手机功能越来越强大， 具有录像功能的手机不在少数， 所以录像时来电测试也是少 不了的一项，进行这项测试时，我们可以从以下角度考虑。 测试思路： 录像时， 电话本中联系人来电→接听来电→结束通话→查看、 播放录像→录像播放时来 电→接听、通话→结束通话 这项我们在测试时进行了拓展， 蓝色部分为拓展的测试项。 这样做可以省去在录像播放 时来电再进行录像这个环节，提高了效率，同时也检测了录像时来电对录像的干扰情况。 例 4．短信编辑+来电 分析：进入短信编辑的方式很多，有直接进入短信菜单进行编辑，有回复短消息时进入 短信编辑状态，有从电话本联系人中选择相应菜单进入短消息编辑。 测试思路： 我们测试时，此项测试主要是测试来电对短信编辑模块的影响。在测试时，可以直接选 择回复短信的方式进入短信编辑模块，来电则为电话本中联系人来电。 例 5．屏保与锁键盘测试 基本都有屏保功能吧，也都有锁键盘功能吧。既然有这些功能，那么就需要对这些功能 进行测试。那我们该如何对他们进行测试呢？ 分开测试，各测各的！先在屏保下进行一系列的测试，如屏保启动时间、屏保显示界面 以及屏保下来电， 接收短消息的等一系列复杂的测试， 一项一项测试完成大概需要半天的时 间，测试完毕后再去测试锁键盘功能，如锁键盘启动时间、界面提示信息，锁键盘情况下来 电、短信等等项。等全部测试完成大概又需要半天的时间。 其实，我们可以思考一下：这两项我们是否可以合并起来，一起测试呢？ 答案是肯定的！ 两项中的很大一部分内容都可以合并起来一起测试！ 即在屏保以及键盘锁同时启动的情 况下进行测试， 如果两者同时启动的情况下都是正常工作的， 那么我们可以认为其在另一者关闭的情况下功能也一定是正常的！我们要明白一点：越是在复杂的情况下，手机出问题的 可能性越大！ 其实，我们还可以进一步拓展一下，我们同时启动 LCD 背光等项，将其合并起来一起 测试！这种情况下在单位时间里不但增加了测试内容，而且更容易发现软件中的一些问题。 另外，鉴于锁键盘以及屏保、LCD 背光等，它们都有不同的启动时间，我们是否该将所有 这些的排列组合全部测试一遍呢？这样的话， 那你就等着累死或被老板解雇吧！ 在这里要注 到测试的等价性. 太多了，更深入的就不说了！ 小结： 在提高测试效率上， 我们一定要抓住懂得哪些测试可以合并一起来测， 哪些项出问题的 可能性比较大，也一定要知道哪些地方是重点！ 如何在人力资源紧缺的状态下， 如何在有限的时间里发现更多的问题和更广的测试是值 得我们深入思考的！ 宏观上而言， 一个版本先测哪些后测哪些和不测哪些可以说是一个战略 问题， 而具体到测试时， 如何在有限的时间里发现一个测试项所存在的问题则又是一个战术 问题。 战略和战术如何有效地配合？如何更有效的测。?软件测试:实施自动化测试的筹备工作测试筹备活动用于在整体自动化测试活动执行开始前，判断项目可能达到的自动化率、 分析项目的手工测试现状、协调资源初步建立自动化测试小组，应该包括以下内容。 (一) 确定实施自动化测试的应用系统对象 测试管理部门接受来自业务部门和开发部门的自动化测试的申请 测试管理部门主动提出对某个已上线运营系统自动化测试的要求 (二) 确定可能达到的自动化率目标 计划控制经理使用自动化率分析模型判断自动化测试的可能达到的自动化率目标， 编制 《自动化测试的自动化率目标分析报告》 (三) 分析手工测试的现状 计划控制经理使用手工测试现状分析模型分析项目的当前手工测试状态， 判断手工测试 现状是否存在影响自动化测试可行性的情况，编制《自动化测试的手工测试现状分析报告》 (四) 初步建立自动化测试小组 计划控制经理根据自动化测试小组组长的可用资源指定自动化测试小组组长， 《自动 将 化测试的自动化率目标分析报告》和《自动化测试的手工测试现状分析报告》传递给自动化 测试小组组长 计划控制经理与自动化测试小组组长共同确认：启动“项目级自动化测试流程”。?软件测试:比较手工测试和自动化测试争论的焦点在于何时选取哪种测试方法， 以及何种情况下手工测试更合适或自动化测试 更合适。有种观点认为自动化测试更适合回归测试和 API 测试，手工测试更适合做验收测 试和 GUI 测试。我觉得这种简单化的看法使我们偏离了真正的问题。 觉得问题的本质与 API 还是 GUI，回归还是功能都没有关系。我们应该从代码是业务 逻辑相关还是基础性代码出发。因为这正是这点区分了手工测试和自动化测试。 业务逻辑代码对应投资人或用户掏钱买的那些功能。 是实际完成工作的。 基础性代码则 确保业务逻辑代码运行在合适的环境中。 基础性代码使得业务逻辑代码可以用于多用户， 更 安全，本地化等等。这是支撑业务逻辑干活的平台。 很明显，两种代码都要测试。直觉上，手工测试更适合测业务逻辑，因为这部分人类学习起来要比交给自动化容易。觉得这个直觉太对了。 手工测试者最适合成为领域专家， 他们可以把相当复杂的业务逻辑存在最强力的测试工 具――大脑里。而且手工测试速度比较慢，测试者就有时间可以观察分析细微的逻辑问题。 速度虽然慢些，但是比较容易。 自动化则胜在测试底层的细节。自动化可以测试崩溃、挂起、错误返回值、返回码、异 常和内存使用等等。速度快但是也困难些。想对业务逻辑进行自动化测试比较困难，风险也 大。事后想想，我觉得 Vista 就有这个问题，太依赖自动化测试了。如果能加多一些手工测 试人员，效果会更好。 所以不管你是要测 API 还是 GUI，回归测试还是头次测试，所选择的测试方法取决于 你想要发现什么样的 bug。当然会有例外，但总的来说，手工测试胜在测试业务逻辑，而自 动化测试胜在测试底层架构。 这就是个人的观点，根据具体情况选择合适的方法。?软件测试:剖析软件测试中的压力测试概念之一【压力测试】来自 VisualStudio.NET 设计分布式应用程序可靠性测试：是指模 拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。 对每个单独的组件进行 压力测试后， 应对带有其所有组件和支持服务的整个应用程序进行压力测试。 集中测试从最 基础的功能测试开始。 您需要知道编码路径和用户方案、 了解用户试图做什么以及确定用户 运用您的应用程序的所有方式。测试脚本应根据预期的用法运行应用程序。例如，如果您的 应用程序显示 Web 页，而且 99%的客户只是搜索该站点，只有 1%的客户将真正购买，这使 得提供对搜索和其他浏览功能进行压力测试的测试脚本才有意义。 当然， 也应对购物车进行 测试，但是预期的使用暗示搜索测试应在测试中占很大比重。 概念之二【压力测试】来自.NET 应用程序性能测试：压力测试用来评估在超越最大负 载的情况下系统将如何运行。压力测试的目标就是发现在高负载的条件下应用程序的缺陷 (BUG)。包括：synchronizationissues,raceconditions,andmemoryleaks（内存泄漏） 。压力测试 能让您识别程序的弱点和在极限负载下程序将如何运行。 概念之三【压力测试】压力测试主要是为了发现在一（任意）定条件下软件系统的性能 的变化情况。 通过改变应用程序的输入以对应用程序施加越来越大的负载 （并发， 循环操作， 多用户）并测量在这些不同的输入时性能的改变，也就是通常说的概念：压力测试考察当前 软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。 其实这种测试也可以称为 负载测试， 但是负载测试通常描述一种特定类型的压力测试――增加用户数量以对应用程序 进行压力测试。 网上可能还有多于以上三种所描述的对压力测试这个名词的定义。 比较赞同第一种概念， 压力测试应该是指模拟巨大的工作负荷以查看应用程序在峰值使 用情况下如何执行操作。扩展开来说，其一压力测试应该是较短时间的，其次是模拟巨大的 工作负荷的，再次压力测试是要使应用程序的使用达到峰值。对这三点继续补充，对第一点 长时间的压力测试就转变成了负载测试；对第二点，对应用程序施加的压力是超负荷的，所 以要不断地加压；第三点，使应用程序的使用达到峰值，如果超过这个界限则应用程序会崩 溃或错误率激增，这个峰值是针对某一时刻来说的，也是针对某个临界的压力来说的，转变 为场景设置中的说法就是能够支持的最大并发用户数。 在最近的一次测试中定义了测试的目的是：需要了解 AUT（被测应用程序）一般能够 承受的压力， 同时能够承受的用户访问量 （容量） 最多支持有多少用户同时访问某个功能。 ， 在 AUT 中选择了用户最常用的五个功能作为本次测试的内容，包括登录。大概的需求就是 这样。接下来我 AUT 的登录说一说怎么用 LoadRunner 和 Jmeter 来实现场景的设置达到测试 的目的。 （注：对服务器的检测不是本次测试的重点，本次测试主要收集并发访问用户数和 发生错误用户数） 首先是对脚本的要求： 1、录制脚本（注意所有的脚本都应录制到 Action 中） ，自定义事务，事务从提交用户 名和口令的脚本之前开始； 2、在定义事务开始的脚本前加入集合点； 3、在脚本中加入检查点，以登录成功的页面出现登录用户的 ID 即可； 4、参数化登录用户的身份； 其次是对场景设置的要求： 1、因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变 用户数来确定； 2、建议修改运行时设置，优化对服务器的访问； 3、计划的设置，每 x 时间后加载 10 用户（根据总用户数设置） ，完全加载后持续运行 不超过 5 分钟（根据需要设置） ； 4、集合策略，当运行中的用户数 100%达到集合点时释放； 5、注意事项，需要注意几个时间： 1）服务器响应超时时间； 2）登录事务迭代一次所使用的时间； 3）集合点等待超时时间； 4）计划中设置的间隔时间。在我的测试中事务运行一次的时间不超过 30 秒，通过修改 脚本使它的运行时间达到一分钟左右，服务器响应超时时间、结合点等待超时时间、计划中 设置的间隔时间都设置为了 2 分钟。 这样场景开始运行后运行用户数呈阶梯增长， 另外在每个上升点新增的用户都会随原来 已经运行的用户并发访问服务器。 通过多次的运行和对测试结果中正在运行用户数与错误用户的对比， 然后根据定义可接 受错误率就可得到该功能的最大并发访问的用户数。 以上测试中排除了对网络、 客户端等的要求。 在实际测试中首先要保证这些资源是足够 的。 使用 Jmeter 也能够达到上述描述的场景的测试，并且更加的便捷。?需求模式之开发考虑和测试考虑“开发考虑”一节目的是帮助设计和实现软件的开发人员满足这种类型的需求。 它提供了 提示和建议，指出不要忘记的一些事情。“开发考虑”一节应该以开发人员的语言编写。 本节可以看成是一个非常资深的开发人员给予一个年轻开发人员的一种指导。 如果一个 初出茅庐的工程师向一个头发花白， 纵观全局的工程师请教如何实现这种类型的需求， 他们 会如何说呢？每个需求模式所说的数量会有极大的差别。 一些情况下， 需求是不需要解释的； 另外一些情况，有各种各样的隐患需要指出。 本节也指出开发人员在评审需求时需要注意的地方。 一个需求是否合理？如果可能在实 现上不切实际，要求变更需求。 测试考虑 需求模式部分的用处在于可以解释如何测试这种类型的需求。本节的目标是测试人员。 它主要是为了用户验收测试而编写， 因为这种测试直接可以对应到需求。 但是它也可以用于 其他类型的测试。由于需求本质上有极大的差别，测试需求的方法也变化极大。每个“测试考虑”部分目的 是传达三类信息： 1. 评审这类需求时需要注意的地方。如果测试这个需求可能很困难，建议如何重新组 织使得测试更容易。 2. 总体上指导如何测试这种类型的需求。 3. 提醒一些应该注意的事项以及（如果可能）提示如何处理。 通用的需求模式只可能大致的讨论测试――因为模式不知道一个特定组织的测试实践， 使用的测试工具，系统运行的环境特征，以及系统的特征。 一个组织可能会发现“测试考虑”一节值得裁剪――或者完全重新编写， 以适应自己的测 试方式（特别是考虑测试所使用的任何工具）以及测试人员的专业知识和文化氛围。确实， 考虑组织的特定情况后， 可能使本节不仅仅是测试的考虑； 它可以变成是如何测试这类需求 的指南。如果想这样做的话，可能把“测试考虑”一节放在一边，加上（或者替换成）自己的 “测试指南”会更有用。也可以加上测试这种需求时使用的一些交付件（artifacts） ，例如编写 测试用例的经过裁剪的表格。?如何计算自动化测试的投资回报？要估算自动化的效益，必须根据本公司的实际情况建立一个模型，前面几位大佬提的就 是经典的估算模型，我根据自己的实践给个简化的： 基本公式：手工执行成本+脚本建立成本+脚本维护成本+脚本执行成本 x 执行次数+其 他相关成本&手工执行成本 x 执行次数 解释： 成本的计算单位大多上可以用时间， 对于有些用货币估计的应当折算成有效工时。 由于脚本执行可以在夜间进行，应当乘以一定的折扣，甚至于可以忽略不计。最难计算的是 维护成本，同时也是自动化测试风险比较集中的一块。它由多重因素决定，比如开发流程的 类型，自动化介入的时机，需求和设计的稳定程度，工具的选择，测试人员的能力（直接决 定了脚本质量） ，测试框架的质量，测试对象的可测试程度…… 其他相关成本包括： 做决定 （通常会有很多会议） 、自动化测试计划、 框架实施、研究、 额外软硬件等，多为一次性投资； 脚本建立成本和手工执行成本可以比较容易地从历史统计数据得出； 这仅为参考模型， 实际应用中由于风险的存在， 当自动化测试的收益难于估计或估计收 益不大时，很多公司会选择放弃（本人也一样： ） 其他因素：当人力无法取代自动化，如大规模性能测试?软件测试:QTP 对象识别的核心技术在些先声明，如果触犯到了 HP 的利益，实属无心。 迫于 QTP 对自定义控件的识别局限， 和项目的需要， 无奈之下对 QTP 做了全面的体检， 安装目录下的每个文档都研究了一遍，只为了找出 QTP 识别自定义控件的根本方法，经过 一些努力，有所收获，在些拿来和大家分享一下，也要感谢陈能技大哥的那篇文章：QTP 对.NET 自定义控件的扩展。 其实 QTP 的对象识别核心思想，分成两种，一种是封装好的 DLL，另一种是 XML 标 记语言描述，这两种文件里面都是封装的一些标准控件，各种插件安装后也是如此，QTP 先会读取这些文件，然后会把它里面的对象类别加载到一个文件，每次 QTP 启动的时候， 根据选择的 ADD_IN 去加载控件支持，在录制和回放脚本的时候拿这些对象属性去对比获 得的对象属性，如果属性和方法相同则能识别，介于这个思想，我们就不用再对 QTP 的插 件保持它的神秘感了，对于 9.5 以下的版本，QTP 安装插件都需要插件有权限，所以我们其实可以在 QTP 自带的对象描述文件夹中，把没有权限的插件的对象描述 COPY 进去，或者 也可以自己开发插件，然后对 QTP 的文件进行修改就行了，而对于自定义的控件，我们也 可以在 XML 文件里面增加或修改控件描述，让 QTP 识别它，就说这些吧，还有些具体的 技术细节没有搞清楚，等都 OK 了再进行补充。?软件测试:关于用户名密码的测试方法别小看了这个用户名密码这么简单的输入框。可测试的内容还是很多的，并且引发的问 题也有很多种类。下面就说一说测试方法。考试大祝各位 2008 年下半年全国计算机软件资 格考试取得优异成绩！ 一．用户注册 只从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题， Email，出生日期，地址，性别等等一系列的格式和字符要求，那就都要写用例测了~ 以等价类划分和边界值法来分析 1.填写符合要求的数据注册: 用户名字和密码都为最大长度（边界值分析，取上点） 2.填写符合要求的数据注册 :用户名字和密码都为最小长度（边界值分析，取上点） 3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据 （边界值分析， 取内点） 4.必填项分别为空注册 5.用户名长度大于要求注册 1 位（边界值分析，取离点） 6.用户名长度小于要求注册 1 位（边界值分析，取离点） 7.密码长度大于要求注册 1 位（边界值分析，取离点） 8.密码长度小于要求注册 1 位（边界值分析，取离点） 9.用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就 行了,如含有空格，#等，看需求是否允许吧~） 10.密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就 行了） 11.两次输入密码不一致(如果注册时候要输入两次密码，那么这个是必须的） 12.重新注册存在的用户 13.改变存在的用户的用户名和密码的大小写，来注册。 （有的需求是区分大小写，有的 不区分） 14.看是否支持 tap 和 enter 键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符 号显示 备注：边界值的上点、内点和离点大家应该都知道吧，呵呵，这里我就不细说了~~ 二．修改密码 当然具体情况具体分析哈~不能一概而论~ 实际测试中可能只用到其中几条而已， 比如银行卡密码的修改， 就不用考虑英文和非法 字符，更不用考虑那些ＴＡＰ之类的快捷键．而有的需要根据需求具体分析了,比如连续出 错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数限制等等。 1.不输入旧密码，直接改密码 2.输入错误旧密码 3.不输入确认新密码 4.不输入新密码 5.新密码和确认新密码不一致 6.新密码中有空格7.新密码为空 8.新密码为符合要求的最多字符 9.新密码为符合要求的最少字符 10.新密码为符合要求的非最多和最少字符 11.新密码为最多字符-1 12.新密码为最少字符+1 13.新密码为最多字符+1 14.新密码为最少字符-1 15.新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符 号等） 16.看是否支持 tap 和 enter 键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符 号 17.看密码是否区分大小写，新密码中英文小写，确认密码中英文大写 18.新密码与旧密码一样能否修改成功 另外一些其他的想法如下： 1 要测试所有规约中约定可以输入的特殊字符，字母，和数字，要求都可以正常输入、 显示正常和添加成功 2 关注规约中的各种限制，比如长度，大否支持大小写。 3 考虑各种特殊情况，比如添加同名用户，系统是否正确校验给出提示信息，管理员帐 户是否可以删除，因为有些系统管理员拥有最大权限，一旦删除管理员帐户，就不能在前台 添加，这给最终用户会带来很多麻烦。比较特殊的是，当用户名中包括了特殊字符，那么对 这类用户名的添加同名，修改，删除，系统是否能够正确实现，我就遇到了一个系统，添加 同名用户时，如果以前的用户名没有特殊字符，系统可以给出提示信息，如果以前的用户名 包含特殊字符，就不校验在插入数据库的时候报错。后来查到原因了，原来是在 java 中拼 SQL 语句的时候，因为有&_&，所以就调用了一个方法在“_“，前面加了一个转义字符，后来 发现不该调用这个方法。所以去掉就好了。所以对待输入框中的特殊字符要多关注。 4 数值上的长度 之类的，包括出错信息是否合理 5 特殊字符：比如. / ? & \ &/html& 这些是否会造成系统崩溃 6 注入式 bug：比如密码输入个 or 1=1 7 登录后是否会用明文传递参数 8 访问控制（不知道这个算不算） ：登录后保存里面的链接，关了浏览器直接复制链接 看能不能访问.?虚拟用户数和并发用户数的联系例如 OA 系统使用用户是 100 个，这个就是系统用户数，该系统有一个统计查询功能， 最高峰在线 50 人，那么系统的并发数是多少？ OA 系统使用用户是 100 个，这个就是系统用户数。 最高峰值 50 人同时在线，只表明同时登录了这个模块，并不表示实际服务器承受的压 力。因为服务器承受的压力还与具体的用户访问模式相关。这 50 人在线，有可能开着电脑 溜达去了，有的看的别的模块等等。 并发用户：是同