|
学习过程中的笔记，希望和大家一起交流，不断更新ing…
1 测试综述
1.1 软件
定义：程序+数据+文档。
按层次划分：系统软件、应用软件；
按组织划分：开源软件、商业软件；
按结构划分：单机软件、分布式软件。
1.2软件缺陷
1.2.1 软件缺陷定义
缺陷（Defect）：对软件预期属性的偏离现象。
失效（Failure）：因软件失效所表现出来的现象。
差错（Bug）。
出错（Error）。
bug组成：
bug编号、发现日期、发现人、指派人、bug所属模块、测试环境、bug描述、附件截图、优先级、严重程度、修复状态、回归结果。
软件缺陷判断标准：
1）软件未实现产品说明书要求的功能；
2）软件出现了产品说明书指明不应该出现的错误；
3）软件实现了产品说明书未提到的功能；
4）软件未实现产品说明书虽未明确提及但应该实现的目标；
5）软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户会认为不好。
1.2.2 软件缺陷分类
按照类型分类（By Type）
需求缺陷、涉及缺陷、功能缺陷、界面缺陷、编码缺陷、易用性缺陷
按照严重程度（By Severity）
一级：不能完全满足系统要求，基本功能未完全实现。
二级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。
三级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。
四级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
五级：其他错误。
按照优先级（By Priority）
致命错误blocker
常规操作引起系统崩溃，死机、死循环、闪退
造成数据泄露的安全性问题
涉及金钱计算，引起公司重大损失
阻塞性bug，使测试工作无法进行，如系统无法登录
权限问题，VIP权限
严重错误critical
重要功能不能实现
错误影响到其他重要功能的使用
非常规操作导致的程序崩溃、死机、死循环、闪退
难以接受的界面缺陷
密码明文显示
偶现的致命性bug
一般错误major
次要功能不能实现
操作界面错误（如操作定义）
查询错误、数据显示错误
简单的输入限制未放在前端进行控制
删除操作未给出提示
偶现的严重级bug
细微错误minor
界面不规范
辅助说明描述不清楚
提示窗口文字未采用行业术语
界面存在文字错误
改进建议enhancement
提高产品质量的建议
1.2.3 缺陷生命周期
**bug的生命周期：**一个bug被发现到这个bug被关闭的过程。
1）发现bug
2）确认bug：防止环境问题，操作问题等外因
3）提bug给开发
4）开发确认bug：分为重复、无效、无法复现、不予解决、延期。
重复bug（duplicated）：开发备注重复bug的编号；
无效bug（invalid）：需求理解不一致；
问题：如果开发认为不是bug而自己认为是bug，该怎么办？
从用户角度出发尝试说服开发，然后找产品或者项目经理。如果是bug则开发修复，如果不是bug则不纠结，留好证据（邮件截图）。
无法复现bug（un-reproduced）：开发复现：确认测试环境再复现出来；测试和开发都无法复现：尝试跟踪几个版本，按步骤进行跟踪（记录复现次数、跟踪版本数后关闭）。
不予解决bug（wontfix）：bug级别低。1、说服开发；2、产品确认（备注留证据，关闭bug）
延期bug（delayed）：建议性bug或者在上线之前修复影响比较大。分析bug对用户影响大小和严重级别，由产品和项目经理最后确认。
5）开发修复bug
6）测试验证bug并回归测试：已修复（resolved-fix）、已验证（verify）、未修复重新打开（reopened）。
7）关闭bug（closed）
1.2.4 缺陷管理工具
zentao（禅道）：开源
bugzilla、jira：搭建麻烦，国外用的比较多
bugfree
readmine
easybug：免费开源、在线网站类型
Mantis
1.3 软件测试
1.3.1 软件测试定义
在规定的条件下对程序进行操作，从而发现错误，对软件质量进行评估的一个过程。
IEEE（电气和电子工程师协会）定义的软件测试： 在规定条件下运行系统或构件的过程：观察和记录结果，并对其的某些方面给出评价；分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特性。
1.3.2 软件测试目的
究极目标：尽可能早地找出软件缺陷，并确保其得以修复。
以最少的人力物力和时间找出软件中潜在的各种错误和缺陷，保证各种错误和缺陷得以修复，避免软件发布后由于潜在的软件错误和缺陷造成的隐患带来的商业风险。
同时利用测试过程中得到的测试结果，作为后续项目开发的测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误。
1.3.3 软件测试原则
要以用户需求为标准；
要尽早执行测试；
要贯穿整个软件生命周期；
要严格执行测试用例：排除测试的随意性；
要记录软件缺陷，保管一切测试相关文档（测试用例、测试计划、测试报告）；
要注意回归测试的关联性：修改了旧代码后要确认有没有引入新的问题；
要遵循Pareto原则：软件中80%错误起源于20%的代码中；
要遵循Good-enough原则：穷举测试是不可能的。
1.4 软件生命周期
软件生命周期：可行性研究、需求分析（需求规格说明书）、软件设计、编码、测试（测试报告）、验收、发布、维护。
常见模型包括瀑布模型、螺旋模型、迭代模型和敏捷开发模型。
1.4.1 瀑布模型
瀑布模型：最早提出的软件开发的过程模型，自上而下。包括需求分析、设计、编码、测试、运维。
缺点：没有体现出测试贯穿于软件生命周期的原则；测试介入项目晚，回溯成本非常高。项目周期长，效率很低。
1.4.2 螺旋模型
螺旋模型：开发和测试同时进行。系统测试用例根据需求说明书编写出来。
优点：引入了其他模型不具备的风险分析。测试介入早，可以提前对需求进行评审和测试，回溯成本减少；测试可提前准备测试用例，可以节约文档准备时间，提高项目效率。
1.4.3 迭代模型
迭代模型：是最常见的模型。包括产生产品发布的全部开发活动和要使用该发布必须的所有其他元素，强调开发的深入。
优点：降低了在一个增量的开支风险，使产品更快进入市场，加快了整个开发工作的进度，更适应需求的变化。
1.4.4 敏捷开发模型
以人为核心，快速迭代、循序渐进的方法，把大任务分为多个相互联系、但可独立运行的小项目，此过程中软件一直是可使用状态。迭代项目都是敏捷开发模型。
特点：个体和互动高于流程和工具，弱化文档、强化沟通。
1.5 软件测试流程
项目立项
需求分析
编写测试用例
评审测试用例
搭建测试环境
部署测试包
冒烟测试
执行测试用例
bug跟踪处理
回归测试
编写测试报告
1.5.1 V模型
V测试流程：用户需求、需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试
V模型揭示了开发过程与测试过程中各阶段的对应关系。
缺点：忽视了测试对需求分析和系统设计的验证，需求的满足情况一直到后期才被验证，未体现”尽早和不断地进行软件测试”的原则。
1.5.2 W模型
W模型流程：
开发：用户需求、需求分析与系统设计、概要设计、详细设计、编码、集成、实施、交付；
测试：验收测试设计、系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试。
W模型：由两个V字型模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系。
优点：测试的活动与软件开发同步进行；测试对象不仅仅是程序，包括需求和设计；尽早发现软件开发的成本。
缺点：在W模型中，需求、设计、编码等活动被视为串行的，这样就无法支持灵活的迭代。
1.5.3 H模型
H模型流程：测试准备、测试就绪点、测试执行。
H模型将测试活动完全独立了出来，将测试准备活动和测试执行活动清晰地体现出来。其揭示了软件测试是一个独立的流程。指软件测试要尽早准备，尽早执行；只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动可以按照某个次序先后进行，也可以反复进行。
1.5.4 X模型
X模型是对V模型的改进，针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。并且还定位了探索性测试。
2 测试类型
2.1按测试阶段划分
2.1.1 单元测试
单元测试（Unit）：又称模块测试，是针对软件设计的最小单元实施的测试，由开发人员负责测试每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现模块的内部结构可能存在的各种错误。
驱动程序（Driver）：是在单元测试和集成测试中，用来模拟测试模块的上一级模块，协调输入和输出的测试程序。
稳定桩（Stub）：是模拟被测模块工作过程中所被调用的模块。
2.1.2 集成测试
集成测试（Integration）：又称组装测试。通常在单元测试的基础上，将所有的程序模块组装进行有序的、递增的测试。集成测试是检验程序单元间的接口以及功能是否正常，逐步集成为符合概要设计要求的系统。
2.1.3系统测试
系统测试（System）：在真实的运行环境下，测试软件能否和系统（硬件、外设、网络和系统软件等）正确配置、连接，并最终满足用户的所有需求。
2.1.4 验收测试
验收测试（Acceptance）：对程序的功能、性能，以及可移植性、兼容性、可维护性、错误的恢复功能等进行确认。运用黑盒测试的方法，验证所测试的软件是否满足需求规格说明书列出的要求。
验收测试包括正式的验收测试、非正式的验收测试或Alpha测试、Beta测试。
Alpha测试：软件的开发商自己进行的交付前的测试。
Beta测试：是软件的多个用户在实际使用环境下进行的测试。
2.2 按测试技术划分
2.2.1 黑盒测试
黑盒测试也叫功能测试，把测试对象看做一个黑盒子，从用户角度出发，完全不考虑程序内部的逻辑结构和处理过程，只依据需求规格说明书，检查程序的功能是否正确。
打桩（Stub）：黑盒测试的一个常用技巧，用在隔离测试中，用以消除其他程序对被测程序的影响。当被测程序调用其子模块时，可以使用模拟法，此时被测程序并没有真正调用其他模块，而是从桩模块处得到一个所需的值。
缺点：代码覆盖率大约只能达到总代码量的30%。
2.2.2 白盒测试
白盒测试：又称结构测试。充分利用软件内部逻辑结构来设计测试用例，侧重于代码审查。对路径、控制结构、数据流等进行覆盖测试。
插装：插装又称软件探针，由测试工具自动加入，用于反馈软件的执行信息，通过插装检查程序状态，确定是否与预期一致。插装不影被测程序的运行。
从程序的结构入手，计算模块的复杂程度：圈复杂度（基本路径数）可以通过程序流图得出。
基本路径测试：典型的白盒测试，是结构测试的理论基础，其他路径都可以由基本路径组合得到。确认模块的一组基本路径，再根据这些基本路径设计测试用例，做到基本路径覆盖。
优点：增加代码覆盖率，提高代码质量。
缺点：程序运行会有很多不同的路径，不可能测试所有的运行路径；基于代码，可能会漏掉一些功能需求；系统庞大时，测试开销大。
2.2.3 灰盒测试
介于白盒测试与黑盒测试之间，大概知道代码逻辑实现，不需要看懂所有代码，主要是接口测试。
2.3 按代码运行划分
2.3.1 静态测试
测试不运行的部分可能存在的错误，包括文档测试、代码测试、界面测试。
优点：
实施方便，无需执行程序；
早期介入，代价小，见效快；
有利于降低动态测试的难度；
有利于养成良好的编程习惯。
2.3.1.1 文档测试
文档测试：主要测试用户手册和需求说明书是否真正符合用户的实际需求。
软件文档类型包括：
包装文字和图形；
市场宣传材料、广告以及其它插页；
授权、注册登记表；
最终用户许可协议；
标签和胶条；
安装和设置向导；
用户手册；
联机帮助；
样例、示例和模板；
错误提示信息。
文档测试的检查内容主要如下：
读者对象：主要是文档的内容是否能让该级别的读者理解；
术语：主要是检查术语是否适合读者；
内容和主题：检查主题是否合适、是否丢失、格式是否规范等；
图标和屏幕抓图：检查图表的准确度和精确度；
样例和示例：是否与软件功能一致；
拼写和语法；
文档的关联性：是否与其它相关文档的内容一致，例如与广告信息是否一致。
2.3.1.2 代码测试
代码测试：主要测试代码中的类型、引用、参数传递以及表达式等；另有空指针赋值、下标越界、命名规则等是否符合编程的标准和规范。
2.3.1.3 界面测试
界面测试：主要测试软件的实际界面与需求中的说明是否相符。
2.3.2 动态测试
动态测试：验证软件功能最直接、最有效的手段。通过运行被测程序验证其功能、性能是否符合需求，检查代码的执行情况。
特点：与静态分析相辅相成；需要事先设计详细、完备的测试用例；工作量较大、较枯燥。
2.4 按软件特性划分
2.4.1 功能测试
功能测试：是黑盒测试的一种，检查实际软件的功能是否符合用户的需求。包括界面测试、易用性测试、安装测试、兼容性测试。
2.4.1.1 界面测试
界面测试主观性强，根据需求文档（原型图）进行测试。
用于与软件程序进行交互的方式称为用户界面或者UI，个人计算机有复杂的图形用户界面（GUI）。
优秀UI的7要素
符合标准和规范：把软件所运行的平台的标准和规范作为产品功能说明书的补充内容；
直观性：用户界面是否统一、美观、不拥挤；界面布局是否合理，重点内容和热点内容是否突出；有多余的功能吗；
一致性：快捷键和菜单选项、术语命令、听众、按钮位置和等价的按键；
灵活性：状态跳转、状态终止和跳过、数据输入和输出方式，控件是否正常使用；
舒适性：与使用者风格恰当、错误处理、性能；
正确性：市场定位、语言和拼写、媒体、所有支持图标、图像、声音和视频；
使用性：是否有实际价值，是否有致于用户执行软件设计的功能。
2.4.1.2 易用性测试
比较主观，设计是否人性化，符合用户使用习惯。
例如：Windows提供了以下辅助选项：粘滞键、筛选键、切换键。
2.4.1.3 安装测试
是否能正确安装？安装后操作是否正确？
2.4.1.4 兼容性测试
概念：指检查软件之间是否按照用户预期的方式进行交互和共享信息。
兼容性测试的核心内容：
1）软件是否能在不同的操作系统平台上兼容；
2）软件是否能在同一操作系统平台的不同版本上兼容；
3）是否能向前或者向后兼容；向下兼容是测试软件新版本保留它早期版本功能的情况；交错兼容是验证共同存在的两个相关但不相同的产品之间的兼容性；
4）软件能否与其它相关的软件兼容；
5）兼容性测试，主要是指数据能否共享。
2.4.2 性能测试
性能测试的目的是测试并发多用户和大数据量操作时服务器的资源、CPU、内存是否正常工作、响应时间、并发性、吞吐量、处理精度。
性能测试一般从以下三个方面考虑：压力测试、负载测试、强度测试。
2.4.2.1 压力测试
针对压力负载设置测试场景，主要判断长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃。压力测试是对服务器的稳定性以及负载能力等方面的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。
2.4.2.2 负载测试
负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。实际上压力测试和负载测试没有明显的区分，应该站在关注整体性能的高度上来对系统进行测试。
2.4.2.3 强度测试
强度测试是为了确定系统在最差工作环境的工作能力，也可能是用于验证在标准工作压力下的各种资源的最下限指标。
压力测试是在标准工作环境下，不断增加系统负荷,最终测试出该系统能力达到的最大负荷；而强度测试则是在非标准工作环境下，甚至不断人为降低系统工作环境所需要的资源，如网络带宽，系统内存，数据锁等等，以测试系统在资源不足的情况下的工作状态，通过强度测试，可以确定本系统正常工作的最差环境。
强度测试和压力测试的测试指标相近，大多都是与时间相关的指标，如并发量（吞吐量），延迟（最大/最小/平均）以及顺序指标等。
强度测试需要对系统的结构熟悉，针对系统的特征设计强度测试的方法。
2.4.3安全性测试
验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的千扰。
包括：基本的登录功能的检查；
是否存在溢出错误，导致系统崩溃或者权限泄露；
关于开发语言的常见安全性问题检查，比如程序、数据库安全性测试。
用户认证安全测试要考虑的问题：
区分系统中不同用户权限；
系统中会不会出现用户冲突；
系统会不会因用户的权限的改变而混乱；
用户登陆密码是否可见、可复制；
是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）；
用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统；
系统网络安全测试要考虑的问题：
测试采取的防护措施是否正确装配好，有关系统的补丁是否打上；
模拟非授权攻击，看防护系统是否坚固；
采用成熟的网络漏洞检查工具检查系统相关漏洞（黑客攻击工具，现在最常用的是NBSI系列和IPhacker IP）；
采用各种木马检查工具检查系统木马情况；
采用各种防外挂工具检查系统各组程序的外挂漏洞。
数据库安全测试要考虑的问题：
系统数据是否机密（针对银行系统等）；
系统数据的完整性；
系统数据可管理性；
系统数据的独立性；
系统数据可备份和恢复。
2.5 其他测试类型
2.5.1 回归测试
回归测试（Regression）：是指对软件的新版本测试时，重复执行之前某个重要版本的所有测试用例。
目的：验证之前版本产生的所有缺陷已全部被修复；确认修复这些缺陷没有引|发新的缺陷。
2.5.2冒烟测试
冒烟测试（Smoke）：是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
2.5.3 自由测试
自由测试（Free）：是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。
3 测试用例
3.1 测试用例概述
3.1.1 测试用例定义
测试用例是为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的一组在测试时输入和输出的标准，是一份关于具体测试步骤的文档，用于指导测试的实际操作。测试用例可以是纯文本的说明文档，也可以是用脚本语言或高级语言编写的一段代码。
3.1.2 测试用例组成
测试用例应该包含：编写人、编写日期、用例编号、用例标题、优先级、测试目的、预置条件、测试步骤、预期结果、实际结果。
用例编号：由测试设计过程说明和测试程序说明引用的编号。
预置条件：是指执行测试用例必要的硬件、软件、测试工具、人员等。
测试目的：描述测试的目的。
测试步骤：说明执行测试用例的所有输入内容或者条件。
预期结果：描述进行测试用例预期的结果。
实际结果：通过和失败。
3.1.3 测试用例作用
有效性：测试用例是测试人员测试过程中的重要参考依据。
可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率。
易组织性：即使是小的项目，也可能会有几干甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用。
可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
可管理性：测试用例也可以作为检验测试人员进度、工作量以及工作效率的标准。
3.1.4 用例编写原则
不要设计"穷举测试用例" ；
在详细测试用例与有效测试时间中找到平衡点；
好的测试用例应该多关注“反向测试问题” ；
测试用例库应该不断更新和维护；
测试用例可以复用，但要注意数据有效性与环境变化；
多学习经验丰富的测试工程师所设计的测试用例；
针对不同的需求类型和测试对象，灵活采用不同的测试用例设计方法。
3.2 黑盒测试用例设计方法
测试数据选择：等价类划分法、边界值分析法。
测试步骤设计：因果图法、判定表法、正交实验法、功能图法、场景法。
3.2.1 等价类划分
**等价类划分定义：**不完全、不彻底是软件测试的致命缺陷，任何程序只能进行少量而有限的测试。穷举测试是不可能的，为了节省时间和资源、提高测试效率，把输入域划分成若干个有效等价类和无效等价类，从中选取具有代表性的数据作为测试的输入数据。
优点：等价类划分可以通过较少的测试用例达到尽量多的功能覆盖，提高效率，解决不能穷举测试的问题。
缺点：只考虑输入域的分类，没有考虑到输入域的组合。
等价类划分原则：
1）若输入条件规定了取值范围或值的个数，可以确立一个有效等价类和两个无效等价类；
2）若输入条件规定了输入值的集合或者规定了必须遵守的规则，可以确立一个有效等价类和从不同角度违背该条件的多个无效等价类；
3）若输入条件是一个布尔量，可确立一个有效等价类和一个无效等价类；
4）若规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
等价类划分步骤：
1）划分等价类和列出等价类表
从有效等价类、无效等价类的角度分析；
2）确定测试用例
为每个等价类规定一个惟一的编号；
设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步， 最后使得所有有效等价类均被测试用例所覆盖；
设计一个新的测试用例，使其只覆盖个无效等价类。 重复这一步使所有无效等价类均被覆盖。
3.2.2 边界值分析法
边界值分析法是对等价类划分法的一个补充，是与取值范围相关或规定了取值个数的等价类。
边界值通常是等价类的界限，以正好小于、等于和大于界限的值作为边界值。大量的错误发生在输入或者输出范围的边界上，利用边界值法可以查出更多的错误。边界值分析法分为两点法、三点法（中间值）、四点法（次边界值）。
常见的边界值：
报表的第一行和最后一行；
屏幕光标最左上和最右下；
数组的的一个和最后一个；
循环的第0次、第1次、倒数第1次、倒数第2次。
边界值分析法的选择原则：
1）若输入条件规定了取值范围，则用该范围的边界值以及刚超越边界的值作为测试数据；
2）若输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的数作为测试数据；
3）若规格说明书中提到的输入是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试数据；
4）若程序中使用了一个内部数据结构，则用这个内部数据结构的边界上的值作为测试数据。
3.2.3 因果图法
等价类划分和边界值着重考虑输入条件，未考虑输入条件之间的组合。
因果图法特别适用于被测程序具有多种输入条件，程序的输出又依赖于输入条件的各种情况。根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，并借助图形来设计测试用例的方法。因果图法最终生成的是判定表。
因果图法设计步骤
1）根据功能说明书中规定的原因和结果之间的关系，分析所有可能的输入和可能的输出；
2）找出输入与输出之间的关系，画出因果图，并根据功能说明书在因果图中加上约束条件，其中互斥、包含、唯一、要求是对原因的约束，屏蔽是对结果的约束；
互斥（exclude）：表示不同时为1,即a, b, c中至多只有一个1
包含（include）：表示至少有一个1，即a, b, c中不同时为0
唯一（only）：表示a, b, c中有且仅有一个1
要求(required）：表示若a=1,则b必须为1。即不可能a=1且b=0
屏蔽（masked）：表示若a=1,则b必须为0
3）把因果图转换成判定表，并对应到每一个测试用例。
因果图法优缺点
优点：容易发现设计中的不足。
缺点：当原因和结果很多的时候，因果图的可读性会变差。
3.2.4 判定表法
判定表法用来分析和表达多逻辑条件下执行不同操作的情况。它由条件桩、动作桩、条件项和动作项组成：
条件桩(ConditionStub) ：列出了问题的所有条件。通常列出的条件的次序无关紧要。
动作桩(ActionStub) ：列出了问题规定可能采取的操作。这些操作的顺序没有约束。
条件项(ConditionEntry) ：列出针对它左列条件的取值。在所有可能情况下的真假值。
动作项(Action Entry) ：列出在条件项的各种取值情况下应该采取的动作。
实现步骤
1）分析分析各种条件的组合数量：如果有n个条件，每个条件有成立和不成立两种情况，那么一共有2^n种结果；
2）列出所有条件桩和动作桩，指定初始判定表；
3）简化，合并相似规则或者相同动作，排除一些不可能出现的情况。
4）将判定表的每一列（条件项和对应的动作项）作为测试用例的操作步骤和对应的预期结果。
适合使用判定表设计测试用例的条件：
1）规格说明以判定表的形式给出，或很容易转换成判定表；
2）条件和规则的排列顺序不影响哪些操作；
3）当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；
4）如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。
4、正交法
正交法的目的是为了减少用例数量，用尽量少的用例，覆盖输入的两两组合。
5、错误推测法
基于经验和直觉推测程序中的所有可能存在的错误，从而针对性地设计测试用例。该方法用于辅助其他方法进行补充。先进行通过测试，再采取手段进行失败测试找出缺陷。
6、状态图法
通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件。
7、大纲法
大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。大
纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一
个特定的输入条件集合。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。
8、场景法
在场景中采用基本流和备选流表示经过用例的每条路径。通过不同场景描述业务流程，包括代码实现逻辑，设计用例来遍历场景，验证系统软件功能的正确性。
比较类似因果图，但执行深度和可行性更好。
为什么引入用例场景
现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行。
好用例的要求？
一个好的测试用例是在于它能发现至今未发现的错误。一个成功的测试是发现了至今未发现的错误的测试。
使用测试用例的好处
在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断改进其效率也不断攀升。
测试用例的设计过程
1、需求分析
2、提取测试点
3、测试用例设计
4、测试用例评审
测试点的确定
ISO质量体系：在概要设计或详细设计中应明确指出每个单元模块的测试要点、指标和方法。
CMM质量体系：在系统的用例模型描述中应明确指出每个用例模型的优先级及用例工作流程，每一个用例模型为一个测试点，用例模型中每一个测试需求至少应有两个测试用例。
理解上的误区
测试用例应由测试设计员或分析设计员来制定，而不是普通的测试员。
测试点应由分析设计员确立，与测试人员无关。
测试工作展开于项目立项后，而不是代码开发完成之后。
测试对象不仅仅是源代码，还包括需求分析、需求规格说明书、概要设计、概要设计说明书、详细设计、详细设计说明书、使用手册等各阶段的文档。
使用用例场景设计测试用例
测试用例设计步骤
1、确定测试用例
测试需求：来源于需求规格说明书。在测试计划中明确。
每一个测试需求至少确定两个测试用例：正面，负面。
2、确定输入输出
输入是指在执行该测试用例时，由用户输入的与之交互的对象、字段和特定数据值（或生成的对象状态）。
输出即预期结果，是指执行该测试用例完毕后得到的状态或数据。
3、编写测试用例
测试用例编号为：TC_测试需求标识。
测试需求标识：测试计划中的测试需求标识。
测试目标状态和测试数据状态：执行此用例前系统应具备的状态。
输入(操作)：为各输入数据（操作）的组合。
输出(预期结果)：测试用例执行后得到的状态或数据。
4、评审测试用例
测试用例检查表
是否每一个需求都有其对应的测试用例来验证？
是否每一个设计元素都有其对应的测试用例来验证？
或事件顺序，它能够产生唯一的测试目标行为？
是否每个测试用例都阐述了预期结果？
是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？
测试用例是否包含了所有的单一边界？
测试用例是否包含了所有的业务数据流？
是否所有的测试用例名称，ID都与测试工件命名约定一致？
参加人员：项目经理、系统分析员、测试设计员、测试员
5、跟踪测试用例
需求管理: 需求-〉测试用例：测试用例是否覆盖了需求
需求-〉测试需求-〉测试用例：测试用例执行率、通过率
测试用例-〉测试用例执行结果
常用测试用例设计方法
黑盒测试用例设计方法的选择策略
在确定输入和输出参数时，我们采用以下原则：
1、首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变为有限测试。这是减少测试量最有效的方法。
2、在任何情况都必须使用边界值分析法，此方法设计的测试用例发现程序错误的能力最强。
3、可以用错误推测法追加一些测试用例。
4、对照程序的逻辑，检查已设计测试用例的逻辑覆盖度，进行补充。
5、如果程序的功能说明中含有输入条件的组合情况，一开始就可以用因果图法。
6、对于业务流清晰的系统，可以利用场景法贯穿整个测试。
白盒测试常用方法
1、逻辑覆盖法
1）语句覆盖：每条语句执行一次；
2）判定覆盖：每个判定分支至少执行一次；
3）条件覆盖：每个判定条件应取到各种可能的值；
4）判定/条件覆盖：同时满足判定和条件；
5）条件组合覆盖：每个判定条件的每一种组合各出现一次；
6）路径覆盖：每一条可能的路径至少执行一次。
2、循环覆盖
3、基本路径测试法
基于程序圈复杂度产生的测试方法，画出控制流程图，算圈复杂度，找到独立路径并压缩为基本路径集合，根据集合中每条路径设计用例。把复合逻辑表达式拆成单个表达式。
圈复杂度用于计算程序的基本的独立路径数目（每条新的独立路径都必须包含一条新的有向边，从入口到出口互不相同的路径数）
圈复杂的V(G) = e - n + 2p【边-节点+2*连接区域数，连接区域p通常为1】=P+1【判定节点数+1】
一般来说，一个单元模块的最大复杂度V(G)<10
如果把覆盖的路径数压缩到一定限度内，例如程序中的循环体只执行0次和1次，就成为基本路径测试，通过导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次。
5、按测试内容分类
配置测试
软件配置；硬件配置
软件配置包括：配置项识别、工作空间管理、版本控制、变更控制、状态报告、配置审计。
配置测试的核心内容就是利用各种硬件来测试软件的运行情况，一般包括：
配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。
（1）软件在不同的主机上的运行情况，例如Dell和Apple；
（2）软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况；
（3）不同的外设；
（4）不同的接口；
（5）不同的可选项，例如不同的内存大小；
容量测试
使软件经受大数据量的考验，以确定达到限制时是否引发软件失败。
稳定性测试
1、长时间运行及各种操作下，软件的稳定性以及各种性能指标的劣化趋势。
2、多进程或多线程运行时的稳定性。
3、不同操作系统，在不同软件下运行的稳定性。
Web测试
所有用户在一个客户端，需要考虑服务器的带宽，可能需要使用IP SPoof来绕过服务器对单一IP地址最大连接数的限制，但是不必靠分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机的用户，同时还需要给予相应的权限配置和防火墙设置。
如何对web系统进行全面测试？
从功能、性能、可用性、兼容性、安全性方向测试。
1、功能测试
1、超链接测试
超链接测试必须在整个web应用系统的所有功能全面开发完成之后进行。
1）测试所有链接是否按指示的那样确实链接到了改链接的页面
2）所链接的页面是否存在
3）保证web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
2、表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、ActiveX、VBScript或Perl等也要进行验证。
5、数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
2、性能测试
1、连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟)，用户就会因没有耐心等待而离开。 另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2、负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线?如果超过了这个数量，会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?
3、压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。 压力测试的区域包括表单、登陆和其他信息传输页面等。
3、可用性测试
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。
通过考虑下列问题，可以决定一个Web应用系统是否易于导航：
导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助? 在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。 导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。 Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。
图形测试的内容有：
(1)要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
(2)验证所有页面字体的风格是否一致。
(3)背景颜色应该与字体颜色和前景颜色相搭配。
(4)图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。 信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的拼音与语法检查功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓相关文章列表。
4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致? 对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。 对所有的易用性测试来说，都需要有外部人员的参与，最好是最终用户的参与。
4、兼容性测试
1、平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
5、安全性测试
Web应用系统的安全性测试区域主要有：
(1)现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
(2)Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内(例如15分钟)没有点击任何页面，是否需要重新登陆才能正常使用。
(3)为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
(4)当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
(5)服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
6、其他测试类型
冒烟测试
定义：来源于硬件测试，电路板通电后由于短路冒烟被烧了。
进行具体测试之前验证基本核心流程是否正确。
回归测试
回归测试有两类：用例回归和错误回归。
软件更动后重新进行的测试，既要测试变更部分,也要测试受影响部分，关键在决定哪些测试必须被重复。保证测试工作的可重现性。尽量利用工具，提高回归测试的自动化水平。
验证bug及其他没被修改的有联系的模块也要进行测试，产品上线之前进行多轮回归测试。
自由测试
路径测试
试图覆盖软件中所有路径称为路径测试：尽量将语句、分支和条件覆盖
六、测试实例
登录界面测试用例设计
一、界面测试
1、界面的设计风格是否与UI的设计风格统一；
2、界面中的文字简洁易懂；
3、界面中没有错别字；
二、用户名与密码测试：
1、正确/错误/空的用户名与正确/错误/空的密码；
2、用户名的前/中/后含有空格；
3、密码的前/中/后含有空格；
4、用户名与密码使用的字符范围及位数限制的测试（等价类及边界值）；
5、验证码，要考虑文字是否扭曲过度导致辨认难度大，考虑颜色，刷新或换一个按钮是否好用。
三、安全性测试：
1、密码是否隐蔽显示；
2、输入特殊字符串、输入脚本函数；
3、不能直接输入，就copy，是否数据检验出错；
还要准确定位每一个输入框的功能，每一种错误情况下，出现的错误提示要准确或者合适。
四、兼容性测试：
1、不同浏览器测试
2、浏览器不同版本测试
五、其他测试点：
1、输入框之间考虑tab键是否支持；
2、登录按钮要考虑回车键是否支持；
3、取消后的默认位置（一般为空白的用户名输入框）；
4、登录后的跳转页面是否正确（一般为首页）；
5、多次点击登录和取消按钮的界面反应；
6、考虑是否支持多用户在同一机器上登录；
7、考虑一用户在多台机器上登录；
8、登录页面中的注册等链接是否正确。
用户名密码测试
测试方法：最有效的方法是采用等价类划分的方法，其中要考虑：
（1）是否区分大小写
（2）是否允许重名
（3）用户名长度测试：有效长度、无效长度
（4）信息有效性测试：特殊字符、正常字符、空字符、非法字符
（5）密码输入限制次数
权限测试
根据需求等相关文档，查看程序设置权限级别是否正确，即每一级别的用户所能执行的功能是否分配正确测试方法：建立不同权限级的用户进入系统，查看菜单、操作命令有效、无效设置是否正确。
还要考虑程序访问数据库的权限设置，在源程序中不要有默认的用户名和密码连接数据库。
对于单个的权限进行测试问题不大。主要的问题还是在于权限的分级与交叉权限，如果按照排列组合进行权限的交叉将会是一个无比庞大的测试用例。关键在于权限组合－－这个价类如何来划分。
在进行权限测试的时候，优先执行和模拟用户日常使用的权限，也就是使用最频繁的操作。
考虑哪些权限在使用过程中风险比较大，模拟进行测试。
易漏点
1、认知问题
开发知识和产品知识的认知局限，造成某些功能没有测试到。
2、前后台测试
对于一些运行于Linux环境下的产品，为了定位问题的方便，往往采用前台启动服务，而交付给客户后却是后台启动。前台启动测试OK并不能能保证后台启动也是OK的。
3、安装部分
在测试的时候只是按照开发提供的文档去安装和配置，却并没有对安装进行测试，忽略了可安装和易用性的测试;
4、输入框的以及输入法(ctrl+c/ctrl+v)
在我们的测试中，某个输入法输入会造成客户端退出
5、软件版本
测试任务下达后，按照测试申请中的提到的软件版本和路径去下载相应的软件，核对安装，在系统中敲命令去查看版本。
覆盖率（Coverage rate）：语句覆盖率、测试用例执行覆盖率，测试需求覆盖率等的总称。
八、测试工具
CasePlayer：面向嵌入式开发的程序规格说明书制作工具
CasePlayer2是一种可以解析汇编、C语言（ANSI C或非ANSI C）的源代码，并且制作流程图以及模块规格说明书的制作工具
PRQA：代码规则检查工具，英国Programming Research公司出品
代码规则检查：分别针对C, C++, FORTRAN、JAVA，支持MISRA C/C++等国际标准，及用户自定义的编程规范
PRQA能发现违背程序编写标准的问题；发现程序中不安全,不明确和模糊的部分；找出程序中不可移植部分；违背程序编译格式的问题；但不可以检测程序的实际功能的正确性。
PRQA还能提供多达44种业界广泛接受的度量；提供多种可视化输出，包括函数结构图、函数调用树、外部参考、头文件关联、统计度量分析。
QAC/C++：代码规则检查：规则可以选择、定制、汉化；简单易用，见效快。
Tessy：自动单元测试。公司：德国Hitex/Razorcat
C/C++语言目标系统的单元测试（动态测试）
分析源代码识别变量和类型，提供输入和输出的接口
自动生成驱动和打桩
管理测试用例，支持回归测试
标准的测试报告
测试驱动是基于Master/Slave结构，允许无限多的用例和很少的目标系统资源
各种数据类型智能分析，包括指针的支持
批处理功能可以在GUI和命令行下完成
与嵌入式开发环境的无缝集成，占用资源很小
支持MC/DC测试
支持低端单片机
McCabe IQ——结构化测试/质量分析：美国McCabe & Associates公司出品
McCabe IQ适用于软件测试的不同阶段，主要架构：McCabe QA（质量分析）；McCabe Test（追踪与测试）；McCabe Reengineering（再工程）。
Cantata++：单元测试/集成测试，英国IPL公司出品
Cantata++ for C/C++
AdaTEST for Ada83/95
主要功能
动态测试 Does the code meet its specification？
静态分析 Does the code meet coding and complexity standards?
覆盖分析 How much of the code been tested?
主要特点
自动脚本技术，自动生成驱动程序和桩模块
独特的Wrapping技术，完全控制程序的接口，做到真正的逆向测试
同时进行动态/静态/覆盖测试。用户可自定义通过/失败标准
可支持中文界面
支持嵌入式软件测试
Klocwork：软件缺陷检查。加拿大Klocwork公司出品
能够分析C、C++、C#和Java代码；
能够发现的软件缺陷种类：软件质量缺陷；安全漏洞方面的缺陷；对软件架构、编程缺陷的违反情况
对软件进行可视化的架构分析、优化
对软件进行各种度量分析
能够提供与多种主流IDE开发环境的集成
能够分析上千万代码行的超大型软件
按测试活动分：
测试计划
测试设计
测试开发
测试执行
评估和缺陷追踪
按功能：
获取数据
静态度量
动态度量
模拟性
测试管理
白盒：也被称为结构工具，依赖于代码、规格说明或其它源资料的信息
黑盒：依赖于测试环境下应用的需求说明或功能描述
1.5 软件质量模型
软件质量：软件产品的特性可以满足用户的功能、性能需求的能力。
软件质量模型（ISO/IEC9126）：
六大特性：功能性、可靠性、易用性、效率、可维持性、可移植性。
软件质量模型保证（SQA）：
建立一套有计划有系统的方法来向管理层保证拟定方法可以准确地被项目采用。目的是使软件过程对管理人员可见。包括需求文档评审、代码控制、代码评审、变更管理、配置管理、版本管理和软件测试。
QC：检验产品的质量。保证产品符合客户需求。
QA：审计过程的质量。确定项目按照计划进行。
测试策略
1、先静后动，从小到大，由黑到白
先静态，后动态
从代码规则检查做起，测试开展得越早，付出的代价就越小。静态分析简单、方便，成本低、见效快，为动态测试打下良好基础，大大降低了测试的成本。
先单元，后集成
单元测试是集成测试的基础，单元测试得越好，集成测试的工作量就越小
先黑盒后白盒
先验证软件功能是否满足需求，后验证程序覆盖率，补充测试
质量分析，事半功倍
2、充分应用结构测试技术
结构测试：从结构入手分析代码的复杂程度。软件模块的圈复杂度和逻辑结构能客观地反映软件的质量：复杂度与代码出错的关联性非常强，逻辑越“复杂”，就越容易出错。结构越“良好”，代码就越可靠。通过改善代码的结构来分析、改进软件的质量逻辑复杂度定量化；客观；有理论基础。
3、交叉测试，因地制宜
4、选好工具，抓好管理
工欲善其事，必先利其器。根据测试需要和工具的特长进行选择。
使用测试工具带来的好处
客观，准确，无感情色彩；可长时间工作，不会疲劳；高效、权威；工具不能完全代替人。
测试需要管理：测试要长期化、常态化、系统化；测试需要维护、更新；回归测试；过程管理；缺陷追踪
|