自古悲情最销魂
软件测试中什么是白盒测试 黑盒测试
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
采用什么方法对软件进行测试呢？常用的软件测试方法有两大类：静态测试方法和动态测试方法。
其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。
其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。
语句覆盖每条语句至少执行一次。
判定覆盖每个判定的每个分支至少执行一次。
条件覆盖每个判定的每个条件应取到各种可能的值。
判定/条件覆盖同时满足判定覆盖条件覆盖。
条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
路径覆盖使程序中每一条可能的路径至少执行一次。
＂白盒＂法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
＂白盒＂法是穷举路径测试。
在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。
贯穿程序的独立路径数是天文数字。
但即使每条路径都测试了仍然可能有错误。
第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。
第二，穷举路径测试不可能查出程序中因遗漏路径而出错。
第三，穷举路径测试可能发现不了一些与数据相关的错误。
如何挑选白盒测试工具 白盒测试目前主要用在具有高可靠性要求的软件领域，例如：军工软件、航天航空软件、工业控制软件等等。
白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件的测试、测试的可视化等。
对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。
但是对于不同的开发语言，测试工具实现的方式和内容差别是较大的。
目前测试工具主要支持的开发语言包括：标准C、C++、Visual C++、Java、Visual J++等。
代码的覆盖深度：从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖。
·语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。
因此语句覆盖（Statement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。
语句覆盖是很弱的逻辑覆盖。
·判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖（Decision Coverage）。
判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
·条件覆盖 在设计程序中，一个判定语句是由多个条件组合而成的复合判定。
为了更彻底地实现逻辑覆盖，可以采用条件覆盖（Condition Coverage）的标准。
条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
·多条件覆盖 多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。
显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
·修正条件判定覆盖 修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。
这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。
它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的布尔条件，每个条件对于判定的结果值是独立的。
不同的测试工具对于代码的覆盖能力也是不同的，通常能够支持修正条件判定覆盖的测试工具价格是极其昂贵的。
嵌入式软件的测试：对于嵌入式软件的测试，我们还需要一方面进一步考虑测试工具对于嵌入式操作系统的支持能力，例如DOS、Vxworks、Neculeus、Linux和Windows CE等；另一方面还需要考虑测试工具对于硬件平台的支持能力，包括是...
软件测试中RBT(Risk Business Test)思想具体指的是什么呢？
测试人员的首要职责是找bug，但是最重要、最根本的职责应该是在软件产品发布前确保公司的软件产品满足顾客的需求。
测试组采用RBT(Requirements-based testing)，基于需求的测试方法会使测试更加有效，因为它使测试专注于质量问题产生的根源.RBT三大最佳实践1、 Test early and often.尽早测试，频繁地测试确认需求的业务价值。
各利益相关方应该对需求进行评审。
通过用例检查需求的完整性应用语言分析技术确保需求文档清晰一致，不会引起同一问题不同人有不同的解释。
2、 Test with your head, not your gut.不要单凭经验测试不要依赖测试人员的经验来设计测试用例，应该采用系统、严格的测试用例设计方法，而不是依赖有经验的测试人员的技巧。
通过这样的方式来增加测试覆盖的有效性。
格式化、结构化的需求文档有助于测试人员评估需求的测试覆盖率。
通过测试用例评审来检查测试用例存在的错误，并且找出需求的不足之处。
3、 Test with measurement and improvement in mind.测试过程中要保持度量在使用基于需求的测试方法的过程中，保持对需求的可追踪性非常重要。
保持需求与测试用例及测试之间的可追踪性有助于监视进度、度量覆盖率，当然也有助于控制需求变更。
通俗的来说，首先需要得到大家的认可的是，要承认测试工作的要做的好并不是掌握了多少测试技术，学习了多少测试理论和行业知识，而是在林林总总的测试任务前自己是否有一个清晰的思路，要知道自己为什么要做这个测试，都测试哪些内容作哪些类型的测试，在哪里以及什么时候开始测试，都有谁和这个测试相关，怎么做这些测试，这些问题的答案中蕴含着测试思想。
测试思想的产生可能是一个人智慧，也可能是多个人思想碰撞出的火花，这要视我们测试工程师水平和测试对象的复杂程度而定。
测试思想是融合了测试理论，测试技术，行业知识以及项目管理等等诸多领域的知识后而形成的，测试思想会体现在具体测试工作的方方面面，任何一个具体的测试工作都要有思想作为指引才能做到有的放矢。
测试同其他学问一样，非常之博大精深，即使是一个非常简单的程序，如果要进行比较完整的测试也包含非常多的测试理念和测试技巧在里面。
可想而知由几百人甚至几千人合作开发的大型系统要测试起来如果没有好的思想作为指导，其结果将是多么的可怕。
测试思想更应该是游离在不同行业之外的，无论你在测试是什么行业的产品，基于哪种语言和技术开发的这些思想都应该是适用的。
在软件测试中UT,IT,ST,UAT分别是什么意思
1。
软件测试工程师岗位职责是什么 答：你可以去看看招聘网站上很多公司的招聘公布，都有岗位职责，看起来感觉离你自己还有一段距离。
你可以看看我们公司的网站，上面有很多关于软测方面的视频和资料。
加入我们后，会有视频和资料赠送，每天都会有直播互动答疑帮助你去提升。
相信你肯定可以胜任软测这份工作的。
2。
软件测试工程师需要学习哪些知识 答：如果你想当一个初级测试工程师，建议你学习第一阶段的课程，掌握软件测试基本知识，完全可以胜任；如果你想在这个行业走地更远，想要进一步地提高，建议你学习我们的全部课程。
我想每个人都希望在自己的岗位上走地更远，能有个更好的发展。
所以是希望你能够学完全部的课程，全部的课程包括软件测试基础理论知识，数据库，Java基础，后端技术，移动端测试，web测试，自动化测试，性能测试以及现在越来越普及的接口测试。
你学习完这个课程之后，你的工资不用想肯定很高的，具体你可以去招聘网站上看看。
（举例说明学员找到工作后工资） 3。
自动化测试会使用工具就行了吗 答：什么是自动化测试呢？自动化测试是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
自动化测试工具也有很多种，像QTP、selenium、winrunner、Rational Robot等，除了录制脚本还要会编写脚本。
QTP的脚本是VB script，简称VB，你也要去学会的。
加入我们的课程都会有老师教你，而且每天都会直播互动答疑。
软件测试中如何做单元测试呢？
常用的软件测试工具一般是：QTP+LoadRunner+QC软件测试中还需的工具如下：功能测试工具：QTP(HP),WinRunner(MI),Robort(IBM),QARun(Compuware)性能测试工具：LoadRunner(HP),WAS(MS),Robort(IBM)【必须下载相应的插件才支持性能方面的测试】，QALoad(Compuware)测试管理工具：TestDirector/Quarlity Center【这两个工具一个横版一个竖版，功能完全一样】，Rational TestManager缺陷跟踪工具：Bugzilla、Mantis其他：Rational Purify、Rational PureCoverager一般测试流程：需求分析阶段：只要就是对业务的学习，分析需求点。
测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。
《测试方案》编写完成后也需要进行评审。
测试方案阶段：主要是对测试用例和规程的设计。
测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。
这时开始编写用例才能保证用例的可执行和对需求的覆盖。
测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。
其中操作步骤和预期结果需要编写详细和明确。
测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。
同样，测试用例也需要评审。
测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档
什么是软件测试,软件测试一般需要多少步骤
需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。
可能有些人认为测试需求分析无关紧要，这种想法是很不对的。
需求分析不但重要，而且至关重要。
一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。
其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。
比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。
那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。
总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。
测试计划 测试计划（Test Plan）一般由测试负责人来编写。
测试计划的依据主要是项目开发计划和测试需求分析结果而制定。
测试计划一般包括以下一些方面：1. 测试背景 a. 软件项目介绍；b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。
2. 测试依据 a. 软件需求文档；b. 软件规格书；c. 软件设计文档；d. 其他，如参考产品等。
3. 测试资源 a. 测试设备需求；b. 测试人员需求；c. 测试环境需求；d. 其他。
4. 测试策略 a. 采取测试方法；b. 搭建哪些测试环境；c. 采取哪些测试工具以测试管理工具；d. 对测试人员进行培训等。
5. 测试日程 a. 测试需求分析；b. 测试用例编写；c. 测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。
6. 其他。
测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。
计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。
如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。
所以，这些就要求测试负责人能够从宏观上来调控了。
在变化面前能够做到应对自如、处乱不惊那是最好不过了。
测试设计 测试设计主要包括测试用例编写和测试场景设计两方面。
一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。
关于测试用例编写，请参见前面写的《也谈测试用例》一文，里面有详细阐述。
测试场景设计主要也就是测试环境问题了。
测试环境搭建 不同软件产品对测试环境有着不同的要求。
如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。
而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。
当然测试中对于如手机网络等环境都有所要求。
测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的断。
为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。
有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。
不管如何，我们的目标是测试软件问题，保证软件质量。
测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。
测试执行 测试执行过程又可以分为以下阶段：单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。
从测试的角度而言，测试执行包括一个量和度的问题。
也就是测试范围和测试程度的问题。
比如一个版本需要测试哪些方面？每个方面要测试到什么程度？从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。
当然还要考虑以下问题：1. 当测试人员测试的执行不到位、敷衍了事时该如何解决？2. 测试效率问题，怎样提高测试效率？3. 根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？4. 当测试过程中遇到一些偶然性随机问题该怎样处理？5. 当版本中出现很多新问题时该怎样对待？测试停止标准？
转载请注明出处51数据库 » 软件测试中什么是TEST？
