| UML软件工程组织 | |||
| |
|||
|
|||
软件测试演义——第一部分
作者：朱少民 出处：CSDN
测试方法软件测试的众多方法是辩证统一的，它们相互依赖而存在，相互对立又相互补充，任何一种测试方法都有其优点，在特定的测试领域能得到充分发挥。同时，任何一种测试方法都不能覆盖所有测试的需求，在某些场合存在一定的局限性和不足。这种测试的辩证统一，从下面这些相对应的测试方法就得到很好的印证。
1. 白盒测试方法和黑盒测试方法 黑盒测试方法，不考虑程序内部结构和内部特性，而是从用户观点出发，针对程序接口和用户界面进行测试，根据产品应该实现的实际功能和已经定义好的产品规格，来验证产品所应该具有的功能是否实现，是否满足用户的要求。 所以，黑盒测试方法技术相对要求低，方法简单有效，可以整体测试系统的行为，可以从头到尾（end-to-end）进行数据完整性测试。黑盒测试方法适合系统的功能测试、易用性测试，也适合和用户共同进行验收测试、软件确认测试。黑盒测试方法不适合单元测试、集成测试，而且测试结果的覆盖度不容易度量，其测试的潜在风险比较高。 由于白盒测试方法，已知产品的内部工作过程，针对性很强，可以对程序每一行语句、每一个条件或分支进行测试，测试效率比较高，而且可以清楚已测试的覆盖程度。如果时间足够多，可以保证所有的语句和条件得到测试，测试的覆盖程度达到很高。白盒测试方法所以适合单元测试、集成测试，而不适合系统测试。白盒测试方法准备的时间很长，如果要覆盖全部程序语句、分支的测试，一般花费比编程更长的时间。 白盒测试方法所要求的技术也较高，相应的测试成本要大。对于一个应用的系统，程序的路径数可能是一个天文数字，即使借助一些测试工具，白盒测试法也不可能进行穷举测试，企图遍历所有的路径往往是做不到的。即使，穷举路径测试，也不能查出程序违反了设计规范的地方，不能发现程序中已实现但不是用户所需要的功能，可能发现不了一些与数据相关的错误或用户操作行为的缺陷。所以白盒测试方法也存在一定的局限性。 2. 静态测试和动态测试 静态测试是通过对软件的程序源代码和各类文档或中间产品（产品规格说明书、技术设计文档），采用走查、同行评审、会审等方法来查找错误或收集所需要的度量数据，而不需要运行程序，所以相对动态测试，可以更早地进行。 静态分析的查错和分析功能是其他方法所不能替代的，静态分析能发现文档中问题（也只能通过静态测试实现），通过文档中问题或其他软件评审方法来发现需求分析、软件设计等问题，而且能有效地检查代码是否具有可读性、可维护性，是否遵守编程规范，包括代码风格、变量/对象/类的命名、注释行等。静态测试已被当做一种自动化的、主要的代码校验方法。 动态测试是通过观察程序运行时所表现出来的状态、行为等发现软件缺陷，包括在程序运行时，通过有效的测试用例（对应的输入 / 输出关系）来分析被测程序的运行情况、或进行跟踪对比，发现程序所表现的行为与设计规格或客户需求不一致的问题。 动态测试是一种经常运用的测试方法，无论在单元测试、集成测试中，还是在系统测试、验收测试中，都是一种有效的测试方法。但动态测试不能发现文档问题，必须等待程序代码完成后进行，发现问题相对迟得多，一旦发现问题，必须重新设计、重新编码，必然增大不良质量的成本。 3. 手工测试和自动化测试 手工测试是指通过测试人员自身对系统进行操作来完成操作，而自动化测试是通过计算机运行测试工具和测试脚本自动进行。自动化测试具有很多优点，如执行速度高而缩短测试周期、可以多次重复运行相同的测试而减少测试的单调性、真实反映测试结果、二十四小时不知劳累运行等等，所以在测试工作中，我们尽力实现测试自动化、或扩大自动化测试的覆盖范围。但是自动化测试前期投入大，对被测对象要求高以及存在其它的局限性。 软件测试自动化绝不能代替手工测试，它们两者有相应的测试对象和范围： 1) 工具本身并没有想象力和灵活性，根据业界统计结果，自动测试只能发现15-30%的缺陷，而手工测试可以发现70-85%的缺陷；所以自动化测试有其局限性，不适合软件的新功能测试，而特别适合回归测试，可以保证对已经测试过部分进行测试的准确性和客观性。 2) 在系统功能的逻辑测试、验收测试、适用性测试、涉及物理交互性测试时，也很难通过自动化测试来实现，多采用黑盒测试的手工测试方法； 3) 单元测试、集成测试、系统负载或性能测试、稳定性测试、可靠性测试等比较适合采用自动化测试； 4) 当界面、需求变化比较频繁时、开发周期很短的软件、或做一次性软件开发项目（而不是做软件产品）时，自动化测试吃力不讨好，投入大而产出小。 5) 有些测试工具只能运行在Windows平台上，不能运行在Mac/Unix等平台上。 多数情况下，手工测试和自动化测试相结合，以最有效的方法来完成测试任务。 4. 有计划测试和随机测试 在测试执行前，我们一般都进行测试的策划、计划，分析测试的重点和范围，精心设计测试用例，来做好测试执行前的准备，通过测试计划和测试用例进行的测试是有计划的测试，而不通过事先计划或不借助测试用例，完全凭感觉、猜测而进行自由、灵活的测试，被称作随机的测试或ad-hoc test。有计划的测试效率高、针对性强，可以很好地达到测试目标，但由于用户使用软件的情景很多、千变万化，测试用例很难覆盖各种情况，特别是一些边界和特殊的操作。根据经验和历史数据统计，对于大型系统软件测试用例的覆盖度一般在90%到95%之间。所以，必须借助一些自由的ad-hoc test，充分发挥测试人员最大的灵动性、创造性，进行各种猜测和试探，去发现一些相对隐藏比较深或偏僻的软件缺陷。ad-hoc test另外一个作用是帮助测试人员尽早地熟悉产品，改进测试用例。 5. 新功能测试和回归测试 即使在开发一个新软件（第一个版本），在进行系统测试还是功能测试时，总会发现一些严重的缺陷而需要修正，这时就要构造一个新的软件包(Full Build)或新的软件补丁包(Patch),然后进行测试。这时的测试不仅要验证被修复的软件缺陷是否真正被解决了，而且要保证以前所有运行正常的功能依旧保持正常，而没有受到这次修改的影响。对于检验原有正常功能没有出现回归的缺陷而进行的测试，称为回归测试。对于开发第二、三个版本或以后的版本，这种回归测试所占的比重越来越大。所以，一个完整的测试，可以看作新功能或新修改的测试，加上回归测试的组合。 在软件产品实现过程中，新功能的实现固然重要，可以增强产品的亮点和竞争力，增加市场份额，但是不能正常工作的已有功能所引起的客户抱怨可能更大，因为客户已经习惯地使用已有功能了，而对于新功能，客户还没怎么使用（没尝到甜头）或者客户可能不知道这个新功能，甚至我们可以在客户知道前去掉这个功能。所以，从这个意义上说，回归测试显得更为重要。 前面我们曾谈到测试执行中一种有效性策略，实际就是一个典型例子，显示了有效性和风险性之间的矛盾和统一。测试方法有效性和风险性的这种关系，实际表现在整个测试周期，存在整个开发周期。 1. 有效性和风险性, 首先体现在一种测试理念的较量上。虽然，当我们问一个测试工程师，测试是什么？她/他可能会毫不犹豫地说，测试是发现缺陷。当她/他管理一个测试项目或进行测试时，总是想证明所有功能是正常的，而大大降低测试的效率。至少，在心里进行不断的斗争，结果可能会去冒一些风险，可能会牺牲一些效率。 2. 在制定测试策略、测试计划时，有效性和风险性的矛盾可能更突出，即确定测试的质量标准、测试范围和测试重点。“如何减少测试范围、抓住测试重点”是具有技巧性和经验性，技巧和经验提高测试有效性，有时也往往引起一些容易忽视的风险。质量标准（产品特性的具体要求）也具有策略性，是市场(marketing requirements) 和工程 (Engineering ) 的一种斗争的结果，也极具平衡的艺术。 3. 设计测试用例时，我们也常常为测试用例的“颗粒度”而伤神。如果把测试用例设计得很细，照顾到每一个数据输入、每一个条件、每一个环境、每一个路径，那么测试用例的数量将是巨大的，虽然风险很小很小，但是测试效率会很低，并且测试执行没有思考的空间，可能使测试执行人员变得呆板（除非全部测试自动化），不需要创造力、思考。测试用例设计很粗，测试效率可能比较高，测试人员有一个发挥的空间，使测试更有趣，但这依赖于个人的责任感和能力，风险大得多。 4. 在执行时，这种关系也比较突出，前面谈得较多，请参考： http://blog.csdn.net/kerryzhu/archive/2006/06/14/796881.aspx 测试自动化在自动化测试引入和应用中，我们清楚一些基本的原则：
但有一个问题困扰着我们，即采用下面哪种模式更好？ 1.专门的TA团队，负责自动化模块开发，开发完后交给进行功能测试的队伍。人为增加了一个交接工作、沟通层次，但TA团队全心再Scipting, 开发效率高，而且有利于留住TA engineer 2.将产品的部分模块承包给TA团队，TA开发好了，他们手工测试就少了，让TA团队自己Drive自己，效果应该不错，但开发效率可能会低，或TA团队感觉压力太大，或不喜欢手工测试，容易被逼走去做开发。 测试自动化的开展，不仅需要具有很好编程经验的工程师，而且也需要测试工程师的合作，两者需要合作。理想的话，两者合而为一。但是，如果所有测试工程师都具有良好的编程经验，其招聘工作比较难、团队的稳定性也值得担心或者成本也相对大的多。功能测试（特别是适用性、逻辑性等）测试，还是需要手工测试，需要人的直觉和经验，技术特别好的工程师做功能测试，肯定不投入，做不好。 测试自动化需要一个良好的框架，从开发到运行，层次清楚，操作方便，比如通过Web方式提交任务、查看结果等，和测试执行、Bug跟踪系统的集成。 测试工具的选择也是直观重要的，可能要更多去选择Open Source Tool. 测试自动化的应用，也需要建立相应的流程和规范，TA工程师如何和测试工程师、开发工程师的合作和交流，也需要积极引导。 测试自动化的脚本管理，当然可以象代码一样管理，也有Check-in/check-out, 用CVS等系统。在脚本编写时，也不能Hard code, 需要积极创造条件构造数据驱动的脚本、结构化脚本，... 测试自动化的完整解决方案的详细内容，请参考 http://gotoSQA.com/uploads/4-others/TA.pdf 测试自动化，对于系统性能测试、负载测试等效果是明显的，而且我们也不得不为之。我们知道，没有测试工具进行负载模拟，要通过手工测试完成系统测试任务，几乎是不可能的。但在功能测试中，情况就大不一样了。 手工测试在功能测试中的优势还是比较大的，我在“测试方法的辩证统一（之二）”已做了讨论，工具本身并没有想象力和灵活性，而人对界面美观性、逻辑合理性，容易作出判断。所以功能测试自动化主要的应用在回归测试中，而且产品的界面(UI)和功能变化较大，自动化的脚本（Script）维护成本较大，投入和产出往往变成我们最关心的问题，在功能测试中实现测试自动化究竟是否合算？ 举个例子：假如一个功能测试用例，手工运行需要10分钟，而为此测试用例开发脚本需要4个小时，即240分钟，那么意味着这个测试脚本要被运行24次收回成本，如果在加上测试脚本的维护工作量（10％），需要重复运行40－50次，才收回成本。如果在产品的一个版本中要进行2－3轮测试（一般是需要的），这个产品需要发布15－20个版本才收回成本。所以业界常说，产品发布7个版本才收回成本。 如何降低成本、可以相对增加产出或者说更快地收回成本？关键是提高脚本开发速度、提高脚本运行的稳定性和降低维护脚本的工作量，主要方法有：
下表也部分说明了这个问题。也希望得到您更好的想法。
对测试工具能够发挥作用，大家都已经了解并认可了，但是很多引入自动化测试工具的软件公司并没有能够让测试自动化发挥应有的作用，其主要原因有以下几个方面： 1. 不正确的观念或不现实的期望 没有建立一个正确的软件测试自动化的观念，或操之过急，或认为测试自动化可以代替手工测试，或认为测试自动化可以发现大量新缺陷，或不够重视而不愿在初期投入比较大的开支等。多数情况下，对软件测试自动化存在过于乐观的态度、过高的期望，人们都期望通过这种测试自动化的方案能解决目前遇到的所有问题。而同时测试工具的软件厂商自然会强调其工具的优势、有利的或成功的一面，可能对要取得这种成功所要做出持久不懈的努力和困难却只字不提。结果，最初的期望，便得不到实现。 2．缺乏具有良好素质、经验的测试人才 有些软件公司舍得花几十万元去买测试工具软件，但缺乏具有良好素质、经验的测试人才。软件测试自动化并不是简简单单地使用测试工具，还需要有良好的测试流程、全面的测试用例（Test case）等来配合脚本的编写，这就要求测试人员不仅熟悉产品的特性和应用领域、熟悉测试流程，而且很好地掌握测试技术和编程技术。 3．测试工具本身的问题影响测试的质量 通过自动测试工具测试的Test Case是不需要再进行手工测试的，将自动测试与手工测试有效的结合，并在最终的测试报告中也体现自动测试的结果，是比较正确的做法。 4．没有进行有效的、充分的培训 人员和培训是相辅相成的，如果没有良好的、有效的、充分的培训，测试人员对测试工具了解缺乏深度和广度，从而导致其使用效率低下，应用结果不理想。这种培训是一个长期的过程，不是通过一两次讲课的形式就能达到效果。而且，在实际的使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也需要有专人负责解决，否则的话，会严重影响测试工具的使用积极性。 5. 没有考虑到公司的实际情况，盲目引入测试工具 有一点很明确，不同的测试工具面向不同的测试目的、具有各自的特点和适用范围，所以不是任何一个优秀的测试工具都能适应不同公司的需求。某个公司怀着美好的愿望花了不小的代价引入测试工具，半年一年以后，测试工具却成了摆设。究其原因，就是没有能够考虑公司的现实情况，不切实际地期望测试工具能够改变公司的现状，从而导致了失败。 例如，国内多数软件公司是针对最终用户进行项目开发--工程性质的软件，而不是产品开发。项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求和用户界面变动较大，这种情况下就不适合引入黑盒测试软件，因为黑盒测试软件的基本原理是录制/回放（虽然通过修改，形成结构化测试脚本），对于不停变化的需求和界面，可能修改和录制脚本的工作量大大超过测试实施的工作量，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。这种情况下可以考虑引入白盒测试工具，以提升代码质量。 6. 没有形成一个良好的使用测试工具的环境 建立良好的测试工具应用环境，需要测试流程和管理机制做相适应的变化，也只有这样，测试工具才能真正发挥其作用。例如，对于基于 GUI 录制/回放的自动测试来说，产品界面的改变对脚本的正常运行影响较大。再者，白盒测试工具的一般在单元测试阶段使用，而单元测试在多数公司是由开发人员自己完成，如果没有流程来规范开发人员的行为，在项目进度压力比较大的情况下，开发人员很可能就会有意识地不使用测试工具，来逃避问题。所以，有必要将测试工具的使用在开发和测试的流程中明确起来，如在项目各个里程碑所提交的文档中，必须包含某些测试工具生成的报告，如集成测试时DevPartner工具生成的测试覆盖率报告、Logiscope生成的代码质量报告等。 7．其它技术问题和组织问题 软件测试自动化所需要的测试脚本其维护量很大，而且软件产品本身代码的改变也需要遵守一定的规则，从而保证良好的测试脚本使用重复性，也就是说测试自动化和软件产品本身不能分离。 其次，提供软件测试工具的第三方厂家，对客户的应用缺乏足够理解，很难提供强有力的技术支持和具体问题的解决能力。也就是说，软件测试工具和被测试对象—软件产品或系统的互操作性会存在或多或少问题，加之技术环境的不断变化，所有这些对测试自动化的应用推广和深入，都带来很大的影响。 还有安全性的错觉，如果软件测试工具没有发现被测软件的缺陷，并不能说明软件中不存在问题，可能测试工具本身不够全面的问题或测试的预期结果设置不对。 介绍 Selenium 是 ThoughtWorks 专门为 Web 应用而开发的自动化测试工具，适合进行功能测试、验收测试,其最大的优势有几点：
更多的讨论： http://forums.openqa.org/index.jspa Selenium 命令 Selenium 命令分成两类 —— 操作（action） 和断言（assertion）：
在 Selenium 网站上可以找到可用命令的完整列表。通过 Selenium 命令，脚本编写者可以描述 browser bot 在浏览器中所执行的操作 组成
支持的平台
部署Selenium 下载地方：http://www.openqa.org/selenium/ selenium目录下的内容： devtests：试验性功能 dom-images: 查看DOM用图片 如果想要测试自己开发的发布在服务器端的页面，需要把selenium配置在同一个服务器下： Apache ：直接将selenium目录拷贝至htdocs（Apache的确省根目录）目录下，然后启动Apache，用地址http://server：8080/selenium/TestRunner.html访问例子。 Tomcat ：直接将selenium目录拷贝至webapps目录下，启动Tomcat，用地址http://server：8080/selenium/TestRunner.html访问例子。： IIS：建立一个虚拟目录selenium，将该虚拟目录直接指向实际的selenium目录，用地址http://server/selenium/TestRunner.html访问例子 Test runner 脚本开发模式 清单 1. Selenium 测试用例的结构 (HTML格式)
test runner 脚本使用与 xUnit 框架相同的测试套件（test suite）和测试用例概念。测试用例和命令按照它们在测试套件和测试用例中出现的顺序依次执行。在 清单 1 中：
Test runner 脚本通常与所测试的应用程序（AUT）部署在同一个服务器上。这是因为 browser bot 使用 JavaScript 来模拟用户操作。这些脚本在一个受限制的沙箱环境中运行。如果需要绕过这些限制，可以使用一个代理。 driven 脚本开发模式 driven Selenium 脚本是用多种受支持的编程语言(Java, .NET, Perl, Python 和 Ruby)中的一种编写的。这些脚本在浏览器之外的一个单独的进程中运行。驱动程序的任务是执行测试脚本，并通过与运行在浏览器中的 browser bot 进行通信来驱动浏览器。驱动程序与 browser bot 之间的通信使用一种简单的特定于 Selenium 的连接语言 Selenese。 driven 脚本比 test runner 脚本更强大、更灵活，可以将它们与 xUnit 框架集成。driven 脚本编写和部署更复杂些，它必须执行以下任务：
driven 脚本更依赖于应用程序运行时环境。例如，Java 驱动程序使用一个嵌入式 Jetty 或 Tomcat 实例来部署所测试的应用程序，如将 Selenium 集成到 Ruby on Rails 中。 开发测试用例 测试用例开发涉及四类文件 主文件： TestRunner.html/TestRunner.hta(.hta文件是html application，windows平台特有)；
这四类文件中，除了引擎库以外，其他三类文件都是可以根据具体情况去修改的。selenium 部署完毕后，可以打开浏览器来通过url来访问TestRunner.html文件。初始的时候，TestRunner.html文件中的 TestSuite是链接到tests目录下的TestSuite.html文件，TestCase的frame(上部中间)中打开了 TestSuite.html文件中的第一个Test Case “TestOpen.html”。 可以直接修改TestSuite.html文件，让其指向自己开发的Test case html文件。我们也可以建立另外一个目录，然后将自己的TestSuite文件和Test
case文件都保存在这个目录中。如果使用后一种方式，那么在打开TestRunner.html的时候需要传递一个参数，例子如下：
下面就是开发测试用例——即编辑测试用例的表格。无论Test Suite还是Test Case，表格的第一行都是描述性文字，selenium的引擎是不会处理这一行的内容的。实际内容都是从第二行开始的。Test
case的表格列数一定不能少于3列，否则Selenium会出错。而基本的三列组成是： 清单 2就是四个测试用例的例子，将执行以下操作：
清单
2.
在测试用例中使用命令和断言的例子
测试套件 要达到对应用程序的完全测试覆盖，通常需要不止一个测试用例。这就是 Selenium 使用测试套件的原因。测试套件用于将具有类似功能的一些测试用例编成一组，以便让它们按顺序运行。 测试套件和测试用例一样，都是用简单的 HTML 表编写的。Selenium 执行的缺省测试套件的名称是 TestSuite.html。测试套件使用一个只包含一列的表，表中的每一行指向一个包含某个测试用例的文件。 对于一个有着多个功能模块、组件的web应用，编写的测试脚本html必然比较多。因此，应该建立一个合理的目录结构来组织这些脚本，一般按web服务、模块、功能来组织，形成层次性结构。 非常Cool! 值得一看。盼望已久的测试工具： http://a3.v14853d.c14853.g.vm.akamaistream.net/5/3/14853/v003/1a1a1a72db3eb01f9 测试执行对于大型项目，软件测试的执行，除了需要很好的测试范围分析、测试计划制定和测试资源的分配与组织之外，还是有一个容易被大家忽视的策略问题。 对于大多数应用项目（非国防、载入飞船上天、净室工程等），我们都知道，测试不是为了证明所有的功能能正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的问题，也就是说，测试的一般工作就是发现缺陷 (detect bug)，当然这些缺陷包括需求分析、设计等的缺陷，不仅仅是程序中的运行。测试的启动和项目启动是同时发生的，测试的重要工作是在测试用例的设计，这是随后测试执行的基础。同时，我们应该承认，测试的主要工作是在测试的执行，当自动化测试工具在功能测试中发挥作用比较困难时，测试执行的工作量还是很大的。 如何更早地发现缺陷又不增加风险？测试的本质是什么，发现缺陷还是风险评估？如何引导大家向着一个目标——产品及时高质量发布努力？ 1. 首先就要向测试人员灌输一个概念——“测试的一般工作就是发现缺陷 (detect bug)”，达成共识，这是很重要。这样，测试人员，就知道什么是自己真正的工作。这一点，不仅在测试执行时发挥作用，而且在设计测试用例时更能发挥作用。 2. 测试执行阶段可以划分为两个子阶段，前一个阶段的目的非常清楚，就是发现缺陷，督促大家就是找出缺陷。测试用例的执行，应该是帮助我们更快地发现缺陷，而不是成为“发现缺陷”的障碍——使发现缺陷的能力降低。从理论上说，如果缺陷都找出来了，质量也就有保证了。所以在这一阶段，要不顾风险，就是发现缺陷，这样不仅对开发团队也非常有利，能尽早地修正大部分缺陷；对测试有利，测试效率高，后面的回归测试也会稳定，信心更充分。 3. 在代码冻结或产品发布前的稍后的子阶段，目的是减少风险，增加测试的覆盖度，这时测试的效率会低一些，以损失部分测试效率以极大降低风险、获得更高质量的收益。 4. 在前一阶段，测试用例的执行速度要低一些，测试人员多思考，多做些ad-hoc 测试，这样又帮助提高测试用例的质量，从而对随后的回归测试提供了更有力的保障。 5. 测试执行要进行有效监控，包括测试执行效率（缺陷数/KTC, KTC = 1000 test cases）、Bug历史情况和发展趋势等。根据获得的数据，必要时对测试范围、测试重点等进行调整，包括对测试人员的调整、互换模块等手段，提高测试覆盖度，降低风险 6. 测试总是是有风险的，正是始终存在的风险，使之测试更具有艺术性。 虽然我们都认为，有效的测试计划是指导测试用例设计、测试执行的指导性文件，是成功测试的前提和必要条件，测试用例设计是测试工作的核心，测试用例的成功设计已经完成了一半的测试任务，但是测试的执行是基础，是测试计划和测试用例实现的基础，严格的测试执行使测试工作不会半途而废。而且，测试执行的管理相对复杂些，在整个测试执行阶段中，我们需要面对一系列问题，如： 如何确保测试环境满足测试用例所描述的要求？
要实现上述目标，得到一个真实、符合要求的执行过程，需要很好地全程跟踪测试过程、过程度量和评审、借助有效的测试管理系统等来实现。主要的方法和措施有： 1. 执行前，动员会是必要的，如同打战，要鼓舞士气，更重要阐述策略，回答大家的问题，使测试计划、测试范围和所有测试项目的定义都十分清楚。 2. 严格审查测试环境，包括硬件型号、网络拓扑结构、网络协议、防火墙或代理服务器的设置、服务器的设置、应用系统的版本，包括被测系统以前发布的各种版本和不定包、以及相关的或依赖性的产品。 3. 将要执行的所有测试用例进行分类，基于测试策略和历史数据的统计分析，包括测试策略和缺陷的关联关系，构造有效的测试套件（Test Suite），然后在此基础上建立要执行的测试任务，这样任务的分解有助于进度和质量的有效控制，减少风险。 4. 所有测试用例、测试套件、测试任务和测试执行结果，都通过测试管理系统进行管理，使之测试执行的操作、过程记录在案，具有良好的可跟踪性、控制性和追溯性，容易控制好测试进度和质量。 5. 要确保每一个测试人员理解测试策略、测试目标，对测试进程进行审查(Audit)，确保测试策略得到执行，可以通过一些奖励手段进行引导。测试经理、组长要用于承担风险，使之测试人员有发挥、想象的空间，但同时也要给予适当的压力，提高工作效率和责任心。 6. 缺陷的跟踪和管理一般由数据库系统来执行，容易对缺陷进行跟踪、统计分析和趋势预测，并设定一些有效的规则和流程来配合测试执行，如通过系统自动发出邮件给相应的开发人员和测试人员，使得任何缺陷都不会错过，并能得到及时处理。而且事先建立基于缺陷跟踪系统的缺陷报表、缺陷趋势曲线，对各模块、各测试人员、整体项目等进行实时跟踪。 7. 进行常规的缺陷审查，如Daily Bg review, bug scrub meeting,包括Bug的严重性、Bug的描述、Bug修正的反应速度等，及时发现问题、纠正问题，使整个测试进程在控制轨道上发展。 8. 对每个阶段的测试结果进行分析，保证阶段性的测试任务得到完整的执行并达到预定的目标。 9. 良好的沟通，不仅和测试人员保持经常的沟通，还要求和项目组的其他人员保持有效的沟通，如每周例会，可以及时发现测试中问题或不正常的现象。 |
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
