软件测试测试策略

软件测试策略有哪些？

软件测试策略把软件测试用例的设计方法集成到一系列已经周密计划过的步骤中去，从而使得软件的开发得以成功的完成。

同样重要的是，软件测试策略为软件开发人员、质量保证组织、和客户提供了一个路线图——这个路线图描述了测试的步骤，以及当这些步骤在计划和实施的过程中，需要多少工作量、时间、和资源。

因此，任何测试策略都必须和测试计划、测试用例设计、测试执行、还有测试结果数据的收集与分析结合在一起。

一种软件测试策略应当具备足够的灵活性，这样在必要的时候它能够有足够的创造性和可塑性来应付所有的大软件系统。

与此同时，软件测试策略还必须保证足够的严格，这样才能保证对项目的整个进程进行合理的计划和跟踪管理。

Shooman[SHO83]对这个问题进行了探讨：在许多情况下，测试是一个独立的过程，不同的测试类型的数量和不同的开发方法是一样多。

许多年以来，我们对付程序出错的唯一武器就是谨慎的设计，以及程序员个人的智慧。

我们现在处于这样的一个时代——现代设计技术（和正式的技术复审）正在帮助我们减少代码中存在的初始错误。

类似地，不同的测试方法正在开始聚合为有限的几种方法和思想。

这些方法和思想就是我们所说的策略。

在第16章中，我们已经介绍了软件测试技术①。

在本章中，我们将会把注意力放在软件测试策略上。

测试策略和测试计划的区别？

区别在于：测试策略相当于指导思想，测试计划相当于实践方法。

详细区别：测试计划定义：”一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。

它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。

”内容：产品概述、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等。

注意项：1. 明确测试的目标，增强测试计划的实用性；2. 坚持“5W”规则，明确内容与过程。

利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）;3. 采用评审和更新机制，保证测试计划满足实际需求；4. 分别创建测试计划与测试详细规格、测试用例。

测试策略定义：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

内容：实施的测试类型和测试的目标、实施测试的阶段、技术、用于评估测试结果和测试是否完成的评测和标准、对测试策略所述的测试工作存在影响的特殊事项等内容。

注意项：a.基于测试技术的测试策略的要点：著名测试专家给出了使用各种测试方法的综合策略：任何情况下都必须使用边界值测试方法；必要时使用等价类划分方法补充一定数量的测试用例；对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，看是否达到了要求；如果程序功能规格说明中含有输入条的组合情况，则已开始可以选择因果图方法。

b.基于测试方案的测试策略：对于基于测试方法的测试策略，一般来说应该考虑如下方面：根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点；认真研究，使用尽可能少的测试用例发现尽可能多的程序错误，避免测试过度和测试不足。

软件测试方法有哪些？

软件测试方法一般分为两大类：动态测试方法和静态测试方法。

1、静态测试是指被测程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。

动态测试是指通过运行程序发现错误。

一般意义的测试多指动态测试。

2、动态测试分为黑盒法和白盒法两种。

（1）黑盒法，是指测试人员完全不考虑程序的内部结构和处理过程，只在软件接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。

这个猪是健康的，正常的。

我们的测试不去理会猪的内部有什么花花肠子，怎么把食物变成肉的。

这就是黑盒测试法。

（2）白盒法，是指测试人员须了解程序内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。

按测试步骤和策略来分的软件测试种类有？

BVT (Build Verification Test) BVT是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。

如无大的问题，就可以进行相应的功能测试。

BVT优点是时间短，验证了软件的基本功能。

缺点是该种测试的覆盖率很低。

因为运行时间短，不可能把所有的情况都测试到。

Scenario Tests（基于用户实际应用场景的测试）在做BVT、功能测试的时候，可能测试主要集中在某个模块，或比较分离的功能上。

当用户来使用这个应用程序的时候，各个模块是作为一个整体来使用的，那么在做测试的时候，就需要模仿用户这样一个真实的使用环境，即用户会有哪些用法，会用这个应用程序做哪些事情，操作会是一个怎样的流程。

加了这些测试用例后，再与BVT、功能测试配合，就能使软件整体都能符合用户使用的要求。

Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况。

Smoke Test 在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。

这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。

在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。

Smoke Test优点是节省测试时间，防止build失败。

缺点是覆盖率还是比较低。

此外，Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。

Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。

其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等。

软件测试策略和测试软件有哪些

第三，它可以做函数等的条件覆盖，黑盒；其中白盒又能按方法分，路径覆盖等，比如数据流测试策略很多。

还可以按动态和静态分，好比代码走读算静态，手动执行算动态。

还能按流程分，它可以走数据流。

各种不同的策略也不是单一存在的，看你从什么角度了。

比如按阶段分可以分单元测试，集成测试，看你做功能还是性能了。

基本都是录制回放加验证，没什么大花头，首先它是单元测试阶段，其次，系统测试；按可见度分可以分白盒，再者，它是动态测试的一种等等。

建议你去读下软件工程的书，比如不同的覆盖率：条件覆盖，是几种并存的。

好比你用Nunit做单元测试，业务流测试，它就包含了几种策略，先做一个入门。

测试软件很多...

软件测试方法的安全测试

安全测试，英文是Security Testing。

安全测试是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。

这可能需要复杂的测试技术。

安全测试检查系统对非法侵入的防范能力。

安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。

例如：①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。

理论上讲，只要有足够的时间和资源，没有不可进入的系统。

因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。

此时非法侵入者已无利可图。

软件测试方法的文档测试

文档测试的英文是documentation testing，测试关注于文档的正确性。

文档测试有三大类分别是开发文件、用户文件、管理文件。

1. 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。

2.用户文件：用户手册、操作手册。

3.管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

软件测试中的文档测试主要是对相关的设计报告和用户使用说明进行测试，对于设计报告主要是测试程序与设计报告中的设计思想是否一致；对于用户使用说明进行测试时，主要是测试用户使用说明书中对程序操作方法的描述是否正确，重点是用户使用说明中提到的操作例子要进行测试，保证采用的例子能够在程序中正确完成操作。

一般来说，文档是软件的重要组成部分，因此文档测试也是软件测试的主要内容。

在软件的整个生命周期中会出现很多文档，通常可以把文档粗略地分为三类：开发文档，管理文档和用户文档。

由于文档与代码不同，不能直接运行，对于文档的测试通常只能以文档审查的方式进行。

对于管理文档和审查通常归属于管理范畴，而不是软件测试范畴，因为对于管理文档审查的目的不是为了发现和消除用户所看到的软件中的缺陷，而是为了更好地管理软件开发的过程。

对于开发文档，由于这些文档本身体现了所在开发阶段的软件实际形态，对于这些文档的测试实际上是早期软件测试的主要活动。

用户文档是那些随程序一起交付给用户的文档，它们实际上是交付给用户的软件的重要组成部分。

对于这些文档的测试是对最终软件产品测试的一部分。

软件测试的优先策略,一种是深度优先策略,另一种是

展开全部 1、按是否查看程序内部结构分为：（1）黑盒测试（black-box testing）：只关心输入和输出的结果（2）白盒测试（white-box testing）：去研究里面的源代码和程序结构2、按是否运行程序分为：（1）静态测试（static testing）：是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档可能存在的错误的过程。

静态测试包括：对于代码测试，主要是测试代码是否符合相应的标准和规范。

对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。

对于文档测试，主要测试用户手册和需求说明是否真正符合用户的实际需求。

（5）动态测试（dynamic testing），是指实际运行被测程序，输入相应的测试数据，检查输出结果和预期结果是否相符的过程3、按阶段划分：（1）单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。

桩模块（stud）是指模拟被测模块所调用的模块，驱动模块（driver）是指模拟被测模块的上级模块，驱动模块用来接收测试数据，启动被测模块并输出结果。

（2）集成测试（integration testing），是单元测试的下一阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部门。

集成测试就是用来检查各个单元模块结合到一起能否协同配合，正常运行。

（3）系统测试（system testing），指的是将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。

系统测试的主要依据是《系统需求规格说明书》文档。

（4）验收测试（acceptance testing），指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。

验收测试又分为a测试和beta测试，其中a测试指的是由用户、测试人员、开发人员等共同参与的内部测试，而beta测试指的是内测后的公测，即完全交给最终用户测试。

4、黑盒测试分为功能测试和性能测试：1）功能测试（function testing），是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。

包括逻辑功能测试（logic function testing）界面测试（UI testing）UI=User Interface易用性测试（usability testing）：是指从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。

兼容性测试（compatibility testing）：包括硬件兼容性测试和软件兼容性测试2）性能测试（performance testing）软件的性能主要有时间性能和空间性能两种时间性能：主要指软件的一个具体事务的响应时间（respond time）。

空间性能：主要指软件运行时所消耗的系统资源。

软件性能测试分为：一般性能测试：指的是让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。

稳定性测试也叫可靠性测试（reliability testing）：是指连续运行被测系统检查系统运行时的稳定程度。

负载测试（load testing）：是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。

压力测试（stress testing）：是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。

（Validate the system or software can allowed the biggest stress.）5、其他测试类型：回归测试（regression testing）是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。

（When a new build or release is deployed, repeat all the test cases which has executed in the last build or release.）冒烟测试（smoke testing），是指在对一个新版本进行大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。

（validate the major function is deployed or not in software of system when a new build or release is implement.）随机测试（random testing），是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

（means or all the test data is random, to validate the some edge bugs.）

软件测试的目标和准则是什么？有哪些测试方法？测试步骤有哪些

展开全部具体地讲，测试一般要达到下列目标： 1、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。

产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。

所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。

从长期利益看，这是很不划算的。

领测认为接触过的软件产品，很少有向方正这样大大的产品、薄薄的文档。

当然，书面文档的编写和维护工作对于使用快速原型法（RAD）开发的项目是最为重要的、最为困难，也是最容易被忽略的。

最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。

2、确保产品满足性能和效率的要求使用起来系统运行效率低（性能低）、或用户界面不友好、用户操作不方便（效率低）的产品不能说是一个有竞争力的产品。

用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好处。

也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。

3、确保产品是健壮的和适应用户环境的健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。

另外就是不能假设用户的环境（某些项目可能除外），如：报业用户许多配置是比较低的，而且是和某些第三方产品同时使用的。

测试的原则---Good Enough 对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。

我们的操作困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。

目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。

最明显的例子就是FIT3.0中文报版的产品测试。

测试的规律----木桶原理和80-20原则 1、木桶原理。

在软件产品生产方面就是全面质量管理（TQM）的概念。

产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。

应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。

反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

2、 Bug的80-20原则。

一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。

因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

软件测试的方法：1、按是否查看程序内部结构分为：（1）黑盒测试（black-box testing）：只关心输入和输出的结果（2）白盒测试（white-box testing）：去研究里面的源代码和程序结构2、按是否运行程序分为：（1）静态测试（static testing）：是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档可能存在的错误的过程。