软件系统的测试流程.docx

软件测试的阶段划分可以从三个角度来将软件测试划分为多个阶段：1. 面向软件测试操作类型的划分，如调试、集成、确认、验证、组装、验收、操作；2. 面向软件测试对象粒度的划分，如语句、结构、单元、部件、配置项、子系统、系统、大系统；3. 面向软件测试实施者的划分，如开发者、测试者、验收者、使用者。软件测试阶段的步骤每个软件测试阶段都要经历以下步骤：测试需求分析、测试过程设计、测试实现、测试实施、测试评价、测试维护。测试需求分析测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他 . 测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； 测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； 测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖；b 测试过程设计：包括测试计划 , 测试策略制定，测试时间安排用，测试用例编写等c 测试实现：环境配置好了，新的版本也收到了，人员也都培训好了等等d 测试实施：已经按照测试计划进行展开了，比如手工测试，自动化测试等e 测试评价：对版本测试覆盖率，测试质量，人员测试工作以及前期的一些工作制定情况进行评价，评估f 测试维护：对测试用例库，测试脚本， bug 库等进行维护，保证延续性等 软件测试步骤软件测试步骤 输 入 输 出 测试需求分析 1. 软件测试的方法与规范 2. 软件需求规格说明3. 软件设计说明（概要设计说明和详细设计说明）软件测试计划： 1) 软件测试的定位 2) 软件测试线索 3) 软件测试环境的定义 4) 软件需求的追踪矩阵 测试过程设计 1. 软件测试的方法与规范 2. 软件测试计划软件测试说明： 1) 软件测试步骤 2) 软件测试基准3) 测试线索的追踪矩阵 测试实现 1. 软件测试的方法与规范 2. 软件测试说明3. 软件测试工具 软件测试的实现配置：1) 软件测试环境 2) 测试步骤的计算机表示（用于回归测试的测试代码 / 测试数据）3) 测试基准的计算机表示 测试实施 1. 软件测试的方法与规范2. 软件测试说明 3. 软件测试的实现配置 软件测试记录：1) 测试运行结果的计算机表示 2) 测试比较结果的计算机表示3) 测试日志4) 软件问题报告 测试评价 1. 软件开发文档 2. 软件测试文档 3. 软件测试配置4. 软件测试记录 软件测试报告：1) 测试结果的统计信息2) 测试结果的分析 / 评判 测试配置管理 测试配置管理项： 1) 软件测试的描述性表示（测试文档 / 文件）2) 软件测试的计算机表示（测试代码 / 数据 / 结果） 1. 软件测试配置管理项的标识管理 2. 软件测试配置管理项的存储管理 3. 软件测试配置管理项的引用控制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.Framework; 在NUnit中，所有的属性都包含在Nunit.Framework命名空间里。首先我们依次熟悉一下这些属性。1.TestFixtureAttribute这个属性用来修饰测试类，表示这个类包含了测试方法。注意一下使用这个属性修饰类有一些限制：这个类必须是public，必须有一个缺省的构造函数。using System;using NUnit.Framework;namespace TestDrivenNETTestFixturepublic class YJingLeeFixture/.2.TestAttribute这个属性标记类的某一方法为一个测试方法，此类已经标记为一个TestFixture。一个测试方法的签名定义如下：Testpublic void TestMethod()注意这个方法必须没有参数。如果程序员将测试方法标记为不正确的签名，它不会运行。3.SetUpAttribute这个属性用来修饰方法，修饰后这个方法在每个测试方法被调用之前运行的，我们可以用它来重新设置一些变量，在每个方法运行之前赋值。SetUppublic void Init()4.TearDownAttribute这个属性用来修饰方法，说明这个方法是在每个测试方法被调用完之后运行的，我们可以用来释放一些暂存的变量。TearDownpublic void Dispose()5.SetUpFixtureAttribute这个属性这个属性用来修饰类，这个类包含了SetUpAttribute或者TearDownAttribute属性，必须是public和一个缺省的构造函数。只要使用这个属性，在其命名空间下，运行测试则首先运行其中SetUpAttribute修饰的方法，在运行测试结束则运行其中 TearDownAttribute修饰的方法。注意一个命名空间下只有一个SetUpFixtureAttribute，如果这个属性在整个程序集下定义，则在整个程序集下有效。我们常常用它来设置全局的条件。SetUpFixturepublic class MySetUpClassSetUppublic void RunBeforeAnyTests()TearDownpublic void RunAfterAnyTests()6.TestFixtureSetUpAttribute这个属性用来修饰方法，修饰后这个方法在fixture任何测试执行之前运行，我们常常用来初始化一些对象等，类似于类中的构造函数。TestFixtureSetUppublic void FixtureInit()7.TestFixtureTearDownAttribute这个属性用来修饰方法，修饰后这个方法在fixture任何测试执行之后运行，我们常常用来释放一些资源。TestFixtureTearDownpublic void FixtureDispose() 软件测试:测试用例的复审测试用例的设计是整个软件测试工作的核心，测试用例反映对被测对象的质量要求和评估范围，决定测试的效率和测试自身的质量。所以对测试用例的评审，就显得非常重要。测试用例设计完之后，要经过非正式和正式的复审和评审。在测试用例审查、评审过程中，主要检查下列内容：* 测试用例设计的整体思路是否清晰，是否清楚系统的结构和逻辑从而使测试用例的结构或层次清晰，测试的优先级或先后次序是否合理；* 测试用例设计的有效性，测试的重点是否突出，即是否抓住修改较大的地方、程序或系统的薄弱环节等；* 测试用例的覆盖面，有没有考虑到产品使用中一些特别场景（scenario）、考虑到一些边界和接口的地方；* 测试用例的描述，前提条件是否存在、步骤是否简明清楚、期望结果(Criteria)是否符合产品规格说明书或客户需要；* 测试环境是否准确，测试用例有没有正确定义测试所需要的条件或环境；* 测试用例的复用性和可维护性，良好的测试用例将会具有重复使用的功能, 保证测试的稳定性；* 测试用例是否符合其他要求，如可管理性、易于自动化测试的转化等。测试用例在评审后，根据评审意见做出修改，继续评审，直至通过评审。在以后的测试中，如果有些被发现的缺陷，没有测试用例，应及时添加新的测试用例或修改相应的测试用例。和软件缺陷相关的测试用例是更有效的测试用例，其执行的优先级也高。通过测试用例所发现的缺陷占所有软件缺陷的比值，是衡量测试用例质量和有效性的方法之一。 软件测试：对文档编制的质量要求为使软件文档能起到多种桥梁的作用，使它有助于程序员编制程序，有助于管理人员监督和管理软件的开发，有助于用户了解软件的工作和应做的操作，有助于维护人员进行有效的修改和扩充，文档的编制必须保证一定的质量。如果不重视文档编写工作，或是对文档编写工作的安排不当，就不可能得到高质量的文档。质量差的文档不仅使读者难于理解，给使用者造成许多不便，而且会削弱对软件的管理(难以确认和评价开发工作的进展情况)，提高软件成本(一些工作可能被迫返工)，甚至造成更加有害的后果(如误操作等)。(1)针对性：文档编制以前应分清读者对象。按不同的类型、不同层次的读者，决定怎样适应他们的需要。例如，管理文档主要是面向管理人员的，用户文档主要是面向用户的，这两类文档不应像开发文档(面向开发人员)那样过多使用软件的专用术语。(2)精确性：文档的行文应当十分确切，不能出现多义性的描述。同一课题几个文档的内容应当是协调一致，没有矛盾的。(3)清晰性：文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性。(4)完整性：任何一个文档都应当是完整的、独立的，它应自成体系。例如，前言部分应做一般性介绍，正文给出中心内容，必要时还有附录，列出参考资料等。同一课题的几个文档之间可能有些部分内容相同，这种重复是必要的。不要在文档中出现转引其他文档内容的情况。例如，一些段落没有具体描述，而用“见文档x节，的方式，这将给读者带来许多的不便。(5)灵活性：各个不同软件项目，其规模和复杂程度有着许多实际差别，能一律看待。1)应根据具体的软件开发项目，决定编制的文档种类。软件开发的管理部门应该根据本单位承担的应用软件的专业领域和本单位的管理能力，制定一个对文档编制要求的实施规定。主要是：在不同条件下，应该形成哪些文档?这些文档的详细程度?该开发单位每一个项目负责人都应当认真执行这个实施规定。对于一个具体的应用软件项目，项目负责人应根据上述实施规定，确定一个文档编制计划。其中包括：应该编制哪几种文档，详细程度如何。各个文档的编制负责人和进度要求。审查、批准的负责人和时间进度安排。在开发时期内各文档的维护、修改和管理的负责人，以及批准手续。有关的开发人员必须严格执行这个文档编制计划。2)当所开发的软件系统非常大时，一种文档可以分成几卷编写。例如，项目开发计划可分写为：质量保证计划、配置管理计划、用户培训计划、安装实施计划等。系统设计说明书可分写为：系统设计说明书、子系统设计说明书。程序设计说明书可分写为：程序设计说明书、接口设计说明书、版本说明。-操作手册可分写为：操作手册、安装实施过程。测试计划可分写为：测试计划、测试设计说明、测试规程、测试用例。测试分析报告可分写为：综合测试报告、验收测试报告。项目开发总结报告也可分写成：项目开发总结报告、资源环境统计。3)应根据任务的规模、复杂性、项目负责人对该软件的开发过程及运行环境所需详细程度的判断，确定文档的详细程度。4)对国标GB856788计算机软件产品开发文件编制指南所建议的所有条款都可以扩展，进一步细分，以适应需要;反之，如果条款中有些细节并非必需，也可以根据实际情况压缩合并。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.部署与基础结构网络是否提供了安全的通信。部署拓扑结构是否包括内部防火墙。部署拓扑结构中是否包括远程应用程序服务器。基础结构安全性要求的限制是什么。