常用软件测试工具有哪些 软件测试方法
软件测试有哪些常用的测试方法？
(1)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);
(2)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )作为测试人员，审核重点是检查文本对用户需求定义的完整性严密性和功能设计的可测性. 在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果要尽早的开始测试，不要等待到功能完全做好才开始 产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来 2. 测试计划，测试用例 2.1 编写计划测试用例 在敏捷开发的过程中由于是根据每个user story来估算时间的开发人员将对本次迭代所需要的完成的user story进行评估开发人员可以和客户直接沟通，来确定每个user story的优先级 好处： 客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级 问题： 在user story的时间估算上，开发人员常会估算过少引起版本无法按时发布或者必须进行加班才能进行发布 分析： 由于版本更新很快，任务的时间都是以小时来进行估算的开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等 举个例子： 开发人员估算某个user story编码的时间需要1.5天，开发人员自己估算了其他时间为半天于是开发人员给的估算时间是2天开发阶段实际的花费时间如下，每天花费开例会的时间在例会中项目的其他成员需要技术上的支持于是发费了3个小时进行帮助在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时(也许更多)需要处理一些公司突发性的事务等等所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2-3倍听起来很吓人，但是实际的过程中，的确需要这么多的时间 测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例在前面提到的三种文本中，功能设计文本是主要依据测试的这两个文本也要被项目经理和开发人员审核 2.2 测试用例的审核 为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix(Test Case跟踪矩阵)，其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足(如某个重点Feature的Test Case不够)的地方能够及时给出意见 另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展 在迭代后期测试要抽时间更新test case 3. 实施运行测试 在敏捷方法中，测试有两种：单元测试和接收测试单元测试是由开发人员来完成的，接收测试是由客户代表来完成 由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方需要修改的地方将在下一个发布完成 单元测试 在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点Unit test 做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面 验证测试 测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程这一阶段的测试必须在周密的计划下进行这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分(组件，构件)做完整的测试接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试 3.1 每日提供bug趋势 为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug， 对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免 测试需要考虑:探索性测试用例的编写 3.2 测试用例的维护 在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug(比如从Beta客户报告来的)，没有被现有测试用例所覆盖当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁)，所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步 3.3 根据项目不断补充Common Sense 在项目进行过程中，测试人员需要不断积累经验，不断补充完善各类目的Common Sense标准例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现在保证项目质量的同时，不断积累新的经验 3.4 控制中间版本 为更好地保证软件质量，规避风险，必须加强对中间版本的控制例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证 3.5 发布版本前编写Release Note 在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然Release Note主要包括三方面的内容：Fixed，New Features，Known Problems其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善;或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成 4. 需求管理 采用敏捷开发模式的项目中，客户对于需求的变更很频繁因此，需求管理是十分必要和重要的工作整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步 问题： 客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能，结果做完以后又觉得不好，于是让去掉这个功能后来又由于一些原因，有需要加上在整个过程中可能来回修改了很多次那一定要记录下变更的内容和日期可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过了吗?这时这些记录才是解决客户疑虑的最好证明说白了，是有证据证明我们做了很多的变更大家可能觉得，怎么会有这个问题其实当一个项目长达半年以上，也许大家的记忆力都不可靠了(:p) 建议： 目前采用的是vss工具，对每天的Email中提到的需求变更做一次backup，文档以当天收到Email的日期命名 5. 项目开发末期开展bug大扫除 在项目开发的末期，可以开展bug大扫除活动划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug注意以下要点：
(1)尽管这是一个测试活动，但参与者并不仅限于测试人员项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员目的是要集思广益;
(2)要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug;
(3)为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励
(4)可以分专题展开，比如安全性用户界面可用性国际化和本地化等等 (随机推荐阅读本站500篇优秀文章点击前往：500篇优秀随机文章)
随着软件技术的不断发展，越来越多的人开始关注软件测试，软件测试的方法有很多种，最重要的是选择适合的软件测试方法选择是非常关键的，只有选择到合适的才能在工作中起到事半功倍的作用那么软件测试的方法有哪些呢？下面电脑培训为大家具体介绍
一白盒测试
白盒测试也称为结构测试，是根据程序内部的逻辑结构和代码结构，设计测试数据，完成测试的测试方法白盒子测试的直接优点是，知道所设计的测试用例在代码上的哪个地方被忽视IT培训认为其优点是测试人员能够增加代码的覆盖率，提高代码实行的整体质量，帮助发现代码中的隐藏危险
二黑盒测试
黑盒测试也称数据传输测试，作为不能够看到测试对象的黑匣子，完全不需要考虑程序内部结构和处理过程的情况，北大青鸟发现测试人员可以根据程序功能的要求规格，确定测试用例，并推断测试结果的测试方法
三灰盒测试
灰盒测试主要是一种综合的测试方法，它居于程序运行的外部表达同时，根据内部逻辑结构设计用例，执行程序采集路径执行信息和外部用户界面结果
四集成测试
集成测试是一种组装测试，是在单元测试基础上的一种有序测试其主要的目的是验证软件单元间的接口关系，通过测试发现各软件单元接口间的问题，北京北大青鸟非常期待最终测试的单元构成符合设计要求的软件
(1)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);
(2)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )作为测试人员，审核重点是检查文本对用户需求定义的完整性严密性和功能设计的可测性. 在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果要尽早的开始测试，不要等待到功能完全做好才开始 产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来 2. 测试计划，测试用例 2.1 编写计划测试用例 在敏捷开发的过程中由于是根据每个user story来估算时间的开发人员将对本次迭代所需要的完成的user story进行评估开发人员可以和客户直接沟通，来确定每个user story的优先级 好处： 客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级 问题： 在user story的时间估算上，开发人员常会估算过少引起版本无法按时发布或者必须进行加班才能进行发布 分析： 由于版本更新很快，任务的时间都是以小时来进行估算的开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等 举个例子： 开发人员估算某个user story编码的时间需要1.5天，开发人员自己估算了其他时间为半天于是开发人员给的估算时间是2天开发阶段实际的花费时间如下，每天花费开例会的时间在例会中项目的其他成员需要技术上的支持于是发费了3个小时进行帮助在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时(也许更多)需要处理一些公司突发性的事务等等所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2-3倍听起来很吓人，但是实际的过程中，的确需要这么多的时间 测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例在前面提到的三种文本中，功能设计文本是主要依据测试的这两个文本也要被项目经理和开发人员审核 2.2 测试用例的审核 为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix(Test Case跟踪矩阵)，其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足(如某个重点Feature的Test Case不够)的地方能够及时给出意见 另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展 在迭代后期测试要抽时间更新test case 3. 实施运行测试 在敏捷方法中，测试有两种：单元测试和接收测试单元测试是由开发人员来完成的，接收测试是由客户代表来完成 由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方需要修改的地方将在下一个发布完成 单元测试 在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点Unit test 做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面 验证测试 测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程这一阶段的测试必须在周密的计划下进行这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分(组件，构件)做完整的测试接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试 3.1 每日提供bug趋势 为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug， 对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免 测试需要考虑:探索性测试用例的编写 3.2 测试用例的维护 在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug(比如从Beta客户报告来的)，没有被现有测试用例所覆盖当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁)，所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步 3.3 根据项目不断补充Common Sense 在项目进行过程中，测试人员需要不断积累经验，不断补充完善各类目的Common Sense标准例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现在保证项目质量的同时，不断积累新的经验 3.4 控制中间版本 为更好地保证软件质量，规避风险，必须加强对中间版本的控制例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证 3.5 发布版本前编写Release Note 在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然Release Note主要包括三方面的内容：Fixed，New Features，Known Problems其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善;或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成 4. 需求管理 采用敏捷开发模式的项目中，客户对于需求的变更很频繁因此，需求管理是十分必要和重要的工作整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步 问题： 客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能，结果做完以后又觉得不好，于是让去掉这个功能后来又由于一些原因，有需要加上在整个过程中可能来回修改了很多次那一定要记录下变更的内容和日期可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过了吗?这时这些记录才是解决客户疑虑的最好证明说白了，是有证据证明我们做了很多的变更大家可能觉得，怎么会有这个问题其实当一个项目长达半年以上，也许大家的记忆力都不可靠了(:p) 建议： 目前采用的是vss工具，对每天的Email中提到的需求变更做一次backup，文档以当天收到Email的日期命名 5. 项目开发末期开展bug大扫除 在项目开发的末期，可以开展bug大扫除活动划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug注意以下要点：
(1)尽管这是一个测试活动，但参与者并不仅限于测试人员项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员目的是要集思广益;
(2)要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug;
(3)为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励
(4)可以分专题展开，比如安全性用户界面可用性国际化和本地化等等 (随机推荐阅读本站500篇优秀文章点击前往：500篇优秀随机文章)
来源：本文由易搜IT博客原创撰写，欢迎分享本文，转载请保留出处和链接！
