QA
- 软件测试周期分为如下的阶段：
Planning 计划阶段 Analysis 分析阶段 Design 设计阶段 Construction 书写阶段 Testing Cycles 测试阶段 Final Testing 完成阶段 Implementation 执行阶段
--------------------------------------------------------------------------------
Planning
This is the product definition phase 这是产品测试概念定义的阶段。我觉得这部分的工作主要是管理人员在做，然后让测试组员进入某些活动。 包含的工作是： High Level Test Plan 制定一个高级别的测试计划，应该就是测试大纲了，包含多个测试周期的设定等等。 Quality Assurance Plan 制定测试的目标，质量参数，beta测试的验收标准等等。 Identify when review will be held 制定各个阶段进行review的时间。这个review应该是对上阶段的情况进行分析和总结，以调整计划。也应该有一些讨论测试覆盖率或者某些Test case或者人员的不足啊之类的东西吧。 Problem Reporting Procedures 制定错误报告的流程。比如说那些问题要报，那些问题暂时不用报。书写的格式，跟踪的方法等等。 Identify Problem Classification 制定错误报告的类型。比如说那些是UI的，那些是功能的，那些是性能的等等。 Identify Acceptance Criteria 制定软件可接受标准。比如说错误率在多少，那些错误可以暂时不修改，测试多少轮，覆盖率多少，测试深度多少等等。 Identify application testing databases 制定程序测试数据库。这个可能是模仿用户需求的数据库模型是什么，或者也可能是一个包含需要测试的数据的库。 Identify measurement criteria制定错误的优先级别。分为紧急啊，一般啊，较高啊之类的级别。用来给开发人员参考，那些需要先修改。 Identify metrics for the project 制定项目的跟踪。比如一些跟踪文档，每周提交的weekly report之类的。例如在周报里面包含着本周新写多少个问题，解决了多少个问题，有多少问题是无效的，运行了多少个测试用例，通过率是多少等等。 Begin overall testing project schedule 制定详细项目计划表。包括每个阶段的具体时间了，需要的人数了，需要的资源了等等。 Review Product Definition Document 复检产品定义文档。主要是重新对设计文档进行阅读，对现在开发的产品进行检验，防止出现误差。并且对一些设计提出用户角度的观点等等。这个应该不用所有测试人员参与。生成的应该是设计文档的一个修改和一个会议记录之类的文档。 Plan to manage all test cases in a database, both manual and automated. 设立一个数据库将手工测试和自动测试用例放到一起管理。我觉得不如只输入编号，然后剩下得字段用于记录每个测试用例在不同软件版本时的情况。例如，是否通过，还是阻塞了和有那些问题报告等等。
--------------------------------------------------------------------------------
Analysis
This is external document phase 这是一个外部文档阶段。之所以说是外部文档，是因为这个阶段的工作主要都是从客户和开发组得到的文档。在这个阶段，对这些外部文档进行分析和总结。根据得到的信息，去创建测试的框架和文档。所以本阶段主要的工作是完成分析，搭出框架，书写大纲等。并不是要所有的文档工作都在本阶段内完成。 包括的主要工作是： Develop Functional validation matrix based on Business requirements 制定功能验证矩阵，基于商业要求。嗯，我觉得这里应该是根据设计说明书来划分需要测试的功能区域，每个区域内要测试的元素和功能逻辑。这样就是建立了一个可以被测试用例和问题分类使用的功能验证表格。而且可以检验测试的覆盖度。 Develop Test Case format 制定测试用例格式。就是制定一系列的文档格式。对于UI，功能，性能，自动化测试脚本等应该都有不同的格式规范。然后给出测试优先级别，这样优先级别低，对系统影响小，一般都比较稳定的一些测试用例就可以减少测试频率和周期次数。然后最好给每个测试用例估计一个时间，这样便于统计和管理人力资源。 Develop Test Cycles matrices and time line 制定测试轮次和时间线。这时候应该是根据写好的测试用例估计的时间，按照对系统的不同测试点制定测试轮次。然后每个轮次之间有个时间点。例如在刚刚收到产品时，做的都是简单的功能的验证测试。这时候可以设置一个测试目标，选择一批测试用例。然后在测试目标达到后（比如，测试用例通过率达到85％）就可以进行复杂的功能测试。这个就可以称之为一个轮次。是以测试用例走完一遍为测试轮次的。当然也可以设置，一周或一个月为一个轮次。因此我们看到，找个实际上考验的是一个领导者制定计划和管理执行计划的能力。好的管理人员就能够制定有效的针对具体系统不同的计划，而不是一成不变，老是用一套方法。 Begin writes Test Case based on Functional Validation matrix 根据功能验证矩阵书写测试用例。 这个就没什么好说了，以前写过一个怎么写测试用例的文档。总之一句话，测试用例书写的标准就是满足需要，而不是硬套模板。 Map baseline data to test cases to business requirements 将用户需求中的设定测试数据和测试用例链接。有些用户，需要你对某些特殊的数据结构或者数据类型等等进行测试，这时候就需要将那些数据独立出来，以便能够复用。 Identify test case to automate 标示出能够使用自动工具的测试用例。将一些能够使用自动化测试的用例做一个标示，这样，在人力资源较少的时候，或者需要快速回归的时候就可以使用自动工具了。有些测试用例是直接就写成测试脚本使用测试工具测试的。有些是事先写为手工测试测试用例，可以通过使用已有的自动测试脚本快速的编制成自动测试用例的。毕竟手工测试和自动测试各有利弊。 Automation team begins to setup variable files and high-level scripts in Auto tester. 对于自动化测试组来说，这个时候就要做一些基本的工作了。像一些公用的文件和一些一些基础的公共函数和方法。 Define area for Stress and Performance testing 制定出要进行压力测试和性能测试的区域。并书写测试用例。 Begin setup the test cycles 根据已经完成的测试用例，开始制定测试轮次中包括的测试用例，总轮次，测试时间等等。 Review the documents 不断的复查文档，防止出现偏差。这个工作可以有一个固定周期，比如一个月内有几次，分别查看那些文档等等。 Review test environments 检查测试环境。包括软件，硬件，人力等等。
--------------------------------------------------------------------------------
Design
This is architecture document phase 本阶段是完成测试内部文档的阶段，这些文档大部分都是在分析阶段形成了大体的组织结构和大纲的文档，像测试用例之类的都有了一些基本的描述，本阶段主要的工作就是完成这些文档的最终书写。在本阶段后，基本上测试计划，测试时间表，测试数据，各种相关文档都应该处于完成阶段。当然，仍然可以通过设计的危机处理机制进行更新。 但是特别要指出的是，测试用例并不能够在本阶段完成。由于新功能的添加，具体功能的实现方法，修改功能等因素，测试用例只能不断的更新。 Revise Test plan base on changes 根据具体的变化重新调整测试计划。 Revise Test Cycle matrices and timelines 根据计划的调整，调整各个测试轮次的内容和时间。 Revise Functional Matrix 根据变化调整功能设置。 Verify that test case and test data 确认已有的测试用例和测试数据仍然有效。 Continual write test cases and add new test cases base on changes 继续书写已经设定的测试用例和添加新的测试用例。一个测试用例，在本文中在上个阶段书写的时候可能只有一个简单的描述，具体的测试步骤需要后面填写。有的时候，有些测试用例事先没有考虑到，有些是重复的，所以需要删改。 Develop Risk Assessment Criteria 设置风险评估标准。通过设置风险评估，可以有效的帮助我们灵活的调整计划。比如，某个测试轮次是需要50个小时完成，而我们风险评估标准将这类测试设定为时间值应该设置为150％，也就是说，在计划中应该填写75小时为实际设定完成时间。 Finalize test cycles 最终完成各个测试轮次的设置。在本阶段结束后，除非有其他的特殊情况，通过预先设置的危机处理方法处理外，不再修改。 Finalize Test plan 完成测试计划。 Estimate resource to support development in unit testing 评估支持开发人员进行单元测试的可行性。有些项目，需要测试人员去帮助开发人员进行单元测试。
--------------------------------------------------------------------------------
Construction
This is unit and model testing phase 本阶段是在开发人员编码的同时，最终完成系统预先设置的各种测试用例的阶段。本阶段的很多工作其实在上个阶段就已经涉及到了。本阶段完成后，进入测试的主要阶段，对产品进行实现设定的各种测试。 Complete unit testing 完成单元测试 Complete all test case manual 完成所有的手工测试用例。随着系统不断开发，在拿到一个完整的软件版本之后，基本上手工测试用例都能够完成书写。 Complete auto testing tools 完成自动测试工具的开发。这个阶段可以设计编写一些专用的自动测试工具。 Complete Stress test case 完成压力测试用例 Complete performance test case 完成性能测试用例 Review the functional matrix 重新复检功能表 Complete auto test case 完成自动测试用例
--------------------------------------------------------------------------------
Test Cycle
This is phase that to run Test Cycle(s), report bugs, verifies Bug fixes etc. 这个阶段就是最费时间的阶段了。按照实现制定好的计划，利用各种资源，工具，依循实现书写的测试用例对系统进行一轮轮的测试，直到代码冻结阶段。本阶段也包含了不断设置的回归测试。 1) Test Cycle 1, run first set of test cases 2) Report bugs 3) Bug Verification 4) Revise test cases as required 5) Add test cases as required 6) Test Cycle II 7) Test Cycle III .............. Final testing This is code freeze phase 本阶段是代码冻结后的测试阶段。这个时候需要进行的是最后的验证测试。本轮主要是完成最终的性能，压力，文档测试和UI等测试过程，开始形成系统说明书和用户手册。 Execution of all front to end test case – manual and automated Execution of all back to end test case – manual and automated 上面是在最后进行产品gold的时候，进行的测试，主要是一些大的功能的传测，测试用例一般是对主要功能的一些验证。防止出现最终打包出错等认为因素。 Execute all Stress test Execute all Performance test Execute all UI test Execute all documents test Do the last cycle regression test 以上测试就是最终的功能测试，这个时候一般不在去修改主要的源代码，只是对外观和界面的错误进行修复。只是对现有的一些问题进行跟踪和管理，必要的时候准备出版hot fix版本。
--------------------------------------------------------------------------------
Implementation
This is review entire project phase 本阶段是对整个项目进行总结的阶段。主要是书写一些最终的报告。例如，错误分析报告，包括一共有多少个，有效率是多少，分布情况如何等等。这个阶段主要是将好的经验总结下来，对不足进行思考，为下个项目做准备的放松的阶段。
从上面的叙述来说，这些阶段并不完全的各自独立的阶段。划分的主要依据是根据主要的工作目标而来。各个阶段不但相互影响，而且有时候时间上还会彼此交叉和颠倒。但是，最大的好处就是能够让测试人员更好的理解各项工作的目标和作用。而不是独立的去写测试用例，不管为什么。个人认为，这样把开发的生命周期概念融合进来，尽管这样划分有待讨论，但是可以让那些不熟悉测试的开发人员和测试人员对测试工作有个整体上的感受。所以，本文就是一个入门的普及读物吧。
负面测试(Negative Testing) 用于验证软件不执行其不应该完成的工作。
这一步骤主要依赖于错误猜测，需要依靠测试设计者的经验判断可能出现问题的位置。
适合的技术有： 错误猜测 边界值分析 内部边界值测试 状态转换测试
更多问题，可以查看以下内容：
- Could you tell me two things you did in your previous assignment (QA/Testing related hopefully) that you are proud of?
- List 5 words that best describe your strengths.
- What are two of your weaknesses?
- What methodologies have you used to develop test cases?
- In an application currently in production, one module of code is being modified. Is it necessary to re- test the whole application or is it enough to just test functionality associated with that module?
- Define each of the following and explain how each relates to the other: Unit, System, and Integration testing.
单元测试和白盒测试是不同的，虽然单元测试和白盒测试都是关注功能，他们都需要代码支持，但是级别不同。白盒测试关注的是类中一个方法的功能，是更小的单位，但是完成一个单元测试可能需要 N 多类，所以说作单元测试需要写驱动和稳定桩，比如查询单元是一个查询包，包括 N 多的测试类、测试数据，运行他需要提供数据的部分，输入参数和发出命令的驱动等等，是比类大的一个整体进行的。 另一个明显的区别是白盒测试不会关注类接口，但是单元测试主要的内容就是类接口测试。
系统测试：在功能实现的基础上，可以加入兼容性，易用性，性能等等。
集成测试：分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。 集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。
- Define Verification and Validation. Explain the differences between the two.
验证(Verification)与确认(Validation)的区别
验证：验证检查某样东西是否符合之前已定好的标准，如：文档评审，要检查的东西是文档，检查标准就是文档的评审标准，又如：测试软件，要检查的东西就是软件，检查的标准就是软件的规格说明，包括功能说明，性能要求等。
确认：检查软件在最终的运行环境上是否达到预期的目标。一般来说，就是调试、验收测试等，这些工作都是在真正的软件需要运行的环境上进行的，在最终环境上运行软件，确保软件符合使用要求。
- Explain the differences between White-box, Gray-box, and Black-box testing.
. 黑盒测试
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。"黑盒"法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。"黑盒"法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
2. 白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
3. 灰盒测试
灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。
- How do you go about going into a new organization? How do you assimilate?
- Define the following and explain their usefulness: Change Management, Configuration Management, Version Control, and Defect Tracking.
配置管理(Configuration Management，CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。其最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。
配置管理系统应该具备以下主要功能：
并行开发支持：因开发和维护的原因，要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制；
修订版管理：跟踪每一个变更的创造者、时间和原因，从而加快问题和缺陷的确定 ；
版本控制：能够简单、明确地重现软件系统的任何一个历史版本 ；
产品发布管理：管理、计划软件的变更，与软件的发布计划、预先定制好的生命周期或相关的质量过程保持一致；项目经理能够随时清晰地了解项目的状态 ；
建立管理：基于软件存储库的版本控制功能，实现建立（build）过程自动化 ；
过程控制：贯彻实施开发规范，包括访问权限控制、开发规则的实施等 ；
变更请求管理：跟踪、管理开发过程中出现的缺陷（Defect）、功能增强请求（RFE）或任务（Task），加强沟通和协作，能够随时了解变更的状态 ；
代码共享：提供良好的存储和访问机制，开发人员可以共享各自的开发资源
What is ISO 9000? Have you ever been in an ISO shop?
- When are you done testing?
- What is the difference between a test strategy and a test plan?
- What is ISO 9003? Why is it important
ISO 9003 质量体系——最终检验和试验的质量保证模式
- What are ISO standards? Why are they important?
- What is IEEE 829? (This standard is important for Software Test Documentation-Why?)
软件测试文书
- What is IEEE? Why is it important?
- Do you support automated testing? Why?
- We have a testing assignment that is time-driven. Do you think automated tests are the best solution?
- What is your experience with change control? Our development team has only 10 members. Do you think managing change is such a big deal for us?
- Are reusable test cases a big plus of automated testing and explain why.
- Can you build a good audit trail using Compuware's QACenter products. Explain why.
- How important is Change Management in today's computing environments?
- Do you think tools are required for managing change. Explain and please list some tools/practices which can help you managing change.
- We believe in ad-hoc software processes for projects. Do you agree with this? Please explain your answer.
- When is a good time for system testing?
- Are regression tests required or do you feel there is a better use for resources?
- Our software designers use UML for modeling applications. Based on their use cases, we would like to plan a test strategy. Do you agree with this approach or would this mean more effort for the testers.
- Tell me about a difficult time you had at work and how you worked through it.
- Give me an example of something you tried at work but did not work out so you had to go at things another way.
- How can one file compare future dated output files from a program which has change, against the baseline run which used current date for input. The client does not want to mask dates on the output files to allow compares. - Answer-Rerun baseline and future date input files same # of days as future dated run of program with change. Now run a file compare against the baseline future dated output and the changed programs' future dated output.
Interviewing Suggestions
- If you do not recognize a term ask for further definition. You may know the methodology/term but you have used a different name for it.
- Always keep in mind that the employer wants to know what you are going to do for them, with that you should always stay/be positive.
Preinterview Questions
- What is the structure of the company?
- Who is going to do the interview-possible background information of interviewer?
- What is the employer's environment (platforms, tools, etc.)?
- What are the employer's methods and processes used in software arena?
- What is the employer's philosophy?
- What is the project all about you are interviewing for-as much information as possible.
- Any terminologies that the company may use.
============
黑盒测试的测试用例设计方法·等价类划分方法
·边界值分析方法
·错误推测方法
·因果图方法等价类划分:
是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.
1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
无效等价类:与有效等价类的定义恰巧相反.
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.2）划分等价类的方法:下面给出六条确定等价类的原则.
①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.
④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.
⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:
输入条件 有效等价类 无效等价类
... ... ...
... ... ...
然后从划分出的等价类中按以下三个原则设计测试用例:
①为每一个等价类规定一个唯一的编号.
②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.边界值分析法
边界值分析方法是对等价类划分方法的补充.
（1）边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
（2）基于边界值分析方法选择测试用例的原则:
1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.
2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.
3）根据规格说明的每个输出条件,使用前面的原则1）.
4）根据规格说明的每个输出条件,应用前面的原则2）.
5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.
6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.
7）分析规格说明,找出其它可能的边界条件.错误推测法
错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.
因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
利用因果图生成测试用例的基本步骤:
(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.
(2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.
(3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.
(4) 把因果图转换为判定表.
(5) 把判定表的每一列拿出来作为依据,设计测试用例.
从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.除了上述几种黑盒测试的测试用例设计方法之外其他方法还包括判定表驱动分析方法、正交实验设计方法、功能图分析方法等