软件的安装与卸载的常用测试点
1.不同的系统配置下，安装花费的时间。
2.使用系统工具为一些基本配置创建系统镜像。
3.多次安装。
4.不同路径安装。
5.版本迭代安装。
6.硬盘空间检查。
7.强制中断安装。
8.确保卸载后所有写入硬盘的文件都会被移除，
……………………………………………………………………………………………………………………………………………………………………
文件上传和下载的常用测试点
文件上传：
页面审查
页面美观性、易用性（键盘和鼠标的操作、tab跳转的顺序是否正确）
按钮文字，说明文字正确性
正确/错误的提示文字是否正确
提示当前位置是否正确，并且和其他页面保持一致格式
必填项的标示是否正确
基本功能
路径是否可以手工输入（手工输入的时候有没有限长）
上传文件超过最大值是在提交前校验还是提交后校验
上传文件格式是否全部支持（图片：gif/jpg/bmp…文档：doc/sxw/xls…压缩包：zip/rar…安装文件：exe/msi）
上传文件是否支持中文名称
文件名称的最大值、最小值、特殊字符（包含空格）、使用程序语句是否会对其造成影响、中文名称是否能正常显示
对于是否发布的设置是否正确（前台校验）
简介最大值、特殊字符、使用程序语句是否会对其造成影响
按钮
1.保存按钮：对输入项有错误提示后光标提示是否正确/对输入项的错误提示是否描述正确/对必添项是否进行校验
2.清空按钮：是否清除（或还原）了填写内容
3.返回按钮：是否返回上一页面
文件下载：
页面
当前位置的提示是否现实正确
页面美观性、易用性（键盘和鼠标的操作、tab跳转的顺序是否正确）
按钮文字是否正确
说明性文字是否正确
正确/错误的提示文字是否正确
功能
右键另存为是否可以正确下载文件，并且记录下载次数
工具下载是否正确，并且记录下载次数
单击下载是提示下载还是在页面打开
直接打开是否显示正确
对于本机没有安装工具的文件是否能够打开，是否能给出正确的提示
对于直接在页面内打开的内容是否能够显示正常，页面美观性
保存到本地是否能正确显示
取消下载是否会纪录下载次数
下载次数是否被正确记录
后台没有发布的文件是否在前台可以找到并下载
后台设置了下载权限的文件是否可以被正确看到、是否可以下载
按钮
返回按钮是否回到上一页面
……………………………………………………………………………………………………………………………………………………………………
性能测试介绍
性能测试（或称多用户并发性能测试）、负载测试、强度测试、容量测试是性能测试领域里的几个方面，但是概念很容易混淆。下面将几个概念进行介绍。
性能测试（Performance Test）：通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。
关注点：how much和how fast
负载测试（Load Test）：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。
关注点：how much
强度测试（Stress Test）： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括
Spike testing：短时间的极端负载测试 Extreme testing：在过量用户下的负载测试 Hammer testing：连续执行所有能做的操作
容量测试(Volume Test)：确定系统可处理同时在线的最大用户数
关注点：how much（而不是how fast）
容量测试，通常和数据库有关，容量和负载的区别在于：容量关注的是大容量，而不需要表现实际的使用。
性能测试工具
LoadRunner——性能测试和负载测试
LoadRunner是一种预测系统行为和性能的负载测试工具，通过模拟实际用户的操作行为进行实时性能监测，来帮助测试人员更快的查找和发现问题。LoadRunner适用于各种体系架构，能支持广泛的协议和技术，为测试提供特殊的解决方案。企业通过LoadRunner能最大限度地缩短测试时间，优化性能并加速应用系统的发布周期。
LoadRunner提供了3大主要功能模块：
VirtualUser Generator（用于录制性能测试脚本），
LoadRunner Controller（用于创建、运行和监控场景），
LoadRunner Analysis（用于分析性能测试结果）既可以作为独立的工具完成各自的功能，又可以作为LoadRunner的一部分彼此衔接，与其他模块共同完成软件性能的整体测试。
Apache JMeter
JMeter作为一款广为流传的开源压测产品，最初被设计用于Web应用测试，如今JMeter可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP服务器等等，还能对服务器、网络或对象模拟巨大的负载，通过不同压力类别测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能测试和回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
JMeter的特点包括对HTTP、FTP服务器、数据库进行压力测试和性能测试；完全的可移植性；完全 Swing和轻量组件支持包；完全多线程；缓存和离线分析/回放测试结果；可链接的取样器；具有提供动态输入到测试的功能；支持脚本编程的取样器等。在设计阶段，JMeter能够充当HTTP PROXY（代理）来记录浏览器的HTTP请求，也可以记录Apache等WebServer的log文件来重现HTTP流量，并在测试运行时以此为依据设置重复次数和并发度（线程数）来进行压测。
3
CloudTest
CloudTest 是一个集性能和功能测试于一体的综合压力测试云平台，专为现代网络和移动应用测试而设计开发，CloudTest可以图形化实现判断、循环，整体减轻了测试开发的工作量，缩短了开发时间。CloudTest基于内存的分析引擎，可以实时收集和展示数据，所有数据在3秒内汇聚显示。CloudTest采用虚拟化技术，完美的配合公有/私有云计算技术，无需过多的硬件，带宽资源的投入，人力维护成本几乎为零，测试按需获得，远程接入，适合多团队协作。各种规模的模拟成本均远远优于传统工具，同时大大缩短了测试周期
BUG管理工具的跟踪过程
用BugZilla为例子，
1.测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员
2.开发接口人员将BUG分配给相关的模块的开发人员，状态修改为已分配
3.开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。
4.如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。
5.测试人员在新版本中测试，如果发现问题依然存在，则拒绝修改；如果已经修复，则关闭BUG。
逻辑覆盖的六种常见类型
逻辑覆盖包括：语句覆盖、判定覆盖、条件覆盖、判定／条件覆盖、条件组合覆盖、路径覆盖。
语句覆盖是指设计若干测试用例，使程序中的每个可执行语句至少执行一次；
判定覆盖是指设计若干测试用例，使程序中的每个判断真假的分支至少遍历一次；
条件覆盖是指设计若干测试用例，使程序中的每个条件的可能取值至少满足一次；
判定／条件覆盖是指选择足够的测试用例，使得同时满足判定覆盖和条件覆盖
条件组合覆盖是指选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的每一种可能组合结果都至少被执行一次；
路径覆盖是指选择足够的测试用例，使得程序中所有的可能路径都至少被执行一次。
web测试用例编写方法:
1界面审查
2基本功能
3业务逻辑
4综合场景
如何测试一只笔
首先，软件测试按照阶段来分可以分为单元测试、集成测试、系统测试、回归测试；
按照测试的关注点来分可以分为功能测试、性能测试、易用性测试、外观测试、安全性测试和适配性测试
对应到一支笔的测试中，按照阶段，分为单个零部件（外壳、圆珠笔的弹簧、笔帽、笔芯（笔芯又包含笔油、圆珠、笔芯的管））测试，组装测试，整体测试。
按照测试关注点来分，功能测试，例如能否正常书写，是否有笔油泄露，笔帽能否正常按下、弹起，等等；
性能测试，例如一支笔可以用多长时间，写出的字是否褪色等；
易用性测试，例如笔的长短粗细是否趁手，一根笔芯用完了是否容易更换（对应于软件是否容易部署、掌握使用方法）；
外观测试，例如外形是否美观、时尚、有趣；安全性测试，例如笔油是否含有害化学物质，笔尖是否容易伤到人，笔油或墨水的保质期多长、过了保质期是否产生有害物质；
适配性，例如在不同的温度、气压、重力环境下能否正常使用，在不同的纸质、书写力度下写出的结果如何。
软件缺陷：
1）软件未实现产品说明书要求的功能
2）软件出现了产品说明书指明不应该出现的错误
3）软件实现了产品说明书未提到的功能
4）软件未实现产品说明书虽未明确提及但应该实现的目标
5）软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户会认为不好
对软件测试的理解：
为了发现软件产品中的各种缺陷，而对软件产品进行验证和确认的活动过程，此过程贯穿整个软件开发生命周期。 简单的说，软件测试是以发现错误为目的而执行的一个程序或系统的过程。
软件测试的目的：
验证软件需求和功能是否得到完整实现
验证软件是否可以发布
尽可能多的发现软件中的bug
尽可能早的发现软件中的bug
对软件质量做出合理评估
预防下个版本可能出现的问题
预防用户使用可能出现的问题
发现开发过程中的问题和风险
软件测试的原则：
所有测试的标准都是建立在用户需求之上 。
合理控制测试深度与广度，完全测试不可能，测试的投入与产出要均衡。
80-20原则，软件中80%的bug可以在分析、设计与评审阶段就能被发现与修正，16%的缺陷在系统的软件测试中发现，最后剩下的4%是用户长期使用的过程中才能暴露出来。
尽可能早的开展测试，越早发现错误，修改的代价越小。
发现错误较多的程序段，应进行更深入的测试。
软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试 。
软件开发人员即程序员应当避免测试自己的程序
严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作
优秀测试人员应具备的素质：
1）沟通能力与表达能力 2）好奇心与怀疑精神 3）责任感与抗压能力 4）自信心，坚持自己的观点
5）耐心与细心 6）逆向思维的能力 7）善于学习与总结 8）团队协作精神 9）文档编写能力
优秀测试人员应具备的技能：
1）精通业务知识 2）具备软件编程能力，比如C,C++,JAVA等。 3）可以用脚本语言编写小测试工具
4）主流操作系统应用与网络知识，可以搭建测试环境 5）熟练掌握各种数据库知识 6）精通软件测试理论与方法
7）掌握常用测试与开发工具的使用 8）优秀的文档编写能力
软件开发流程（软件生命周期）：
计划-》需求分析-》设计-》程序编写-》测试-》运行/维护
软件测试流程：
测试计划-》需求分析-》测试用例-》测试用例执行-》提交bug-》回归测试
软件开发模型：
瀑布模型：
适用于需求很明确的项目，分阶段向下进行，无法回溯
迭代模型：
需求不明确，迭代版本系统
敏捷开发模型：
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中，软件项目被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
测试驱动开发模型：
先编写测试代码，再写开发代码
软件测试模型：
V模型：反映了测试与开发阶段之间一一对应的特点，测试在开发之后，出错后回归测试量大
W模型：测试伴随整个开发周期，测试与开发同步进行，有利于尽早发现问题
H模型：软件测试活动完全独立，与其他流程并行
单元测试内容（参考详细设计说明书）
单元测试还要以功能点测试为主，统计测试的覆盖率，同时测试模块的输入/输出接口是否正确，内部的数据流是否正确等。
（1）功能点测试 一般要求功能覆盖100%
（2）覆盖率 一般要求统计语句覆盖和分支覆盖率，也称路径测试，很难达到100%
（3）模块接口测试
1）在单元测试的开始，应对所测模块的数据流进行测试。如果数据不能被正确的输入和输出，就不能进行其他测试
2）对模块接口可能需要进行下面的测试项目：调用所测模块的输入参数与模块的形式参数，测试它们在个数、属性、顺序上是否匹配。
3）所测模块调用子模块时，它输入给子模块的参数与子模块的形式参数在个数、属性、顺序上是否匹配
4）是否修改了只做输入用的形式参数
5）输出标准函数的参数在个数、属性、顺序上是否正确
6）全局变量的定义在各模块中是否一致
7）是否限制通过形式参数来传送
8）模块对外部文件、数据库进行输入/输出时，必须对文件操作进行测试，例如缓冲区大小、是否在读写文件前打开文件，在结束前关闭文件等。
（4）内部数据流测试
1）不正确或不一致的数据类型说明
2）使用尚未赋值或尚未初始化的变量
3）错误的初始值或错误的缺省值
4）变量名拼写错误或书写错误
5）不一致的数据类型
（5）异常/错误处理
比较完善的模块设计要求能预见异常或出错的条件，并设置适当的异常处理和出错处理的方法，以便在程序出现异常或错误时，能对出错程序重做安排，保证逻辑上的正确性。重点应考虑：
异常或出错的描述是否可以理解？
异常处理是否合理、出错后对错误定位是否准确？
提示的错误与实际的错误是否一致？
对错误条件的处理是否正确？
单元测试用例设计
可以采用所学的所有测试用例设计方法，基本过程如下：
（1）设计一个能使系统运行的测试用例：该测试用例一般使用最简单的方法测试被测单元。通过这个测试用例，能够确定测试环境和测试单元是否具有可用性。
（2）设计测试功能的正向测试用例（通过性测试）：阅读相关的设计说明，每一个测试用例都是有针对行的测试说明书中的一项或者多项内容，用以验证设计说明书所对应的功能是否能实现。
（3）设计测试功能的反向测试用例（失效性测试）：用可能导致模块功能失效的无效数据，测试模块对无效数据的反应是否合理，对异常或错误的处理后，模块反应如何，验证模块是否做了不应该做的工作。
（4）设计其他的测试用例，验证设计对模块的要求。例如：性能、可恢复性、安全性等。
（5）加载测试用例运行程序，查看和记录测试结果，尤其注意测试结果与预期结果不一致的情况。
（6）补充测试用例，执行前面测试用例运行没有覆盖到的分支和语句。
集成测试的内容：（参考概要设计说明书）
1.连接各模块时数据是否丢失，
2.一个模块的功能是否对另一个模块的功能产生影响。
3.各个子功能结合起来是否到达预期要求的功能。
4.全局数据结构。
静态白盒测试中的检查代码
1.检查设计和代码：在不执行软件的前提下有条理地仔细审查软件设计，又称为结构化测试。
2.正式审查：确定问题（就事论事）->遵守规则（不该管的不要管）->准备（做什么，怎么做）->编写报告（书面总结报告）
2.1同事审查 小组相互审查。
2.2走查：编写代码的程序员向小组中的其它程序员和测试人员组成的小组做正式陈述。
2.3检验：表达代码的人不是原来的程序员，要求每一个参与者都接受训练，其余参与者成为检验员。
3.编码标准与规范：标准是必须遵守的规则，规范是建议的最佳做法。
例如代码的可靠性 可读/可维护性 可移植性。
动态白盒测试中的单元测试
在底层进行的测试可以成为单元测试（模块测试），是对软件基本组成单元进行的测试，基本测试可以说函数，类，类的方法，也可以是任何具有明确的功能，规格定义，明确的接口定义，并且其规模较小。
单元测试的重点在于发现程序设计或者程序实现中的逻辑错误，使问题及早地暴露并且使其得到定位解决。
必须为每个测试单元开发驱动程序和桩程序。驱动程序是一个主程序，他接受测试用例数据，将这些数据传递给将要测试的构件。
桩程序作用是替换那些从属于被测物减或其被调用的模块。
白盒测试的优点：
1、程序代码中如果存在着一些内存泄露，在黑盒测试中短时间运行并不能发现问题，但是在系统长时间运行后，由于内存泄露的积累，可能导致整个系统内存消耗殆尽，最后瘫痪。而此类问题在白盒测试中着可以被发现。
2、程序中往往存在着很多的异常处理分支语句，在黑盒测试时，可能并没有测试到，没有测试到的代码不能保证其运行正确，在系统运行过程中，如果执行到这些分支语句，很可能出现问题。而执行白盒测试着可以避免此类情况的发生。
3、在白盒测试过程中，执行了多少逻辑，可以作为衡量测试是否完整的一个指标。
4、有时在实验室条件中很难搭建真实的测试环境，这时需要用白盒测试方法分析源代码，何时能够触发这些代码运行，触发条件是否合理，能否达到要求。例如通讯中干扰的现象，宇宙飞船和航天飞机、卫星等在太空中受电磁辐射等。
白盒测试与黑盒测试的联系：
1、在用白盒测试来验证单元的基本功能时，经常要用黑盒测试的思考方法来设计测试用例；
2、在黑盒测试中使用白盒测试的手段，常被称为“灰盒测试”。例如根据被封装单元的规格说明编写测试函数来验证该单元的功能，手工通过数据库客户端或者其他底层的方式查询黑盒测试用例的运行结果等。
3、白盒测试需要对程序的内部实现十分熟悉，而黑盒测试是完全基于对系统需求的了解。这两种测试方法也应用于软件开发的不同阶段。
4、仅仅通过白盒测试，或者仅仅通过黑盒测试都不能系统的全满的测试一个软件。
要做好白盒测试，需要在测试时间中不断累积经验，如果被测试软件有源代码，最好把黑盒测试发现的错误定位到源代码上，这样日积月累，就会知道代码容易犯错误的地方，那些地方要着重分析代码等。
静态黑盒测试：测试产品说明书
对产品说明书进行高级审查：
1.假装自己是客户
2.研究现有的标准和规范
3.审查和测试类似软件
产品说明书低层次测试技术：
1.产品说明书属性检查清单。
2。产品说明书术语检查清单。
动态黑盒测试：戴上眼罩测试软件
通过性测试和失效性测试
数据测试：
1.等价类划分 细化（例如负数，零钱，数字特别大，特殊字符，带零头的数额）
把测试用例缩减成可以控制并且仍然是测试软件的小范围
2.边界条件：软件运行在计划操作界限的边界的情况。
次边界条件：ASCLL，默认，空白，空值。零值，无。 非法 错误，不正确和垃圾数据。
状态测试：测试软件的逻辑流程
1，建立状态转换图：
1》.软件可能进入的每一种独立状态。
2》从一种状态转入到另一种状态所需的输入以及条件。
3》进入或退出某种状态设置条件以及输出结果。
2.减少要测试的状态以及转换数量
1》每种状态至少访问一次
2》测试看起来是最常见和最普遍的状态转换，
3》测试状态之间最不常用的分支
4》测试所有错误状态以及返回值。抛出异常是否处理等
5》测试随机状态转换。
失效性状态测试：
重复测试 不断执行同样的操作（QTP快速测试）
检测是否存在内存泄露
压迫测试：使软件在不够理想的状态下进行。
重负测试：尽量提供条件任其发挥。
其它黑盒测试技术：
1.随机无经验操作，笨拙用户。
2.在已经找到缺陷的地方再找找。
3/像黑客一样考虑问题
4.凭借经验，直觉，和预感。
一条软件缺陷记录都包含哪些内容
bug 编号
bug 发现人
bug 发现时间
bug 状态
bug 严重程度
bug 所属版本
bug 所属模块
bug 处理人
bug 修改日期
bug 简单描述
bug 详细描述
bug 相关附件
bug 初步分析
软件的安全性应从哪几个方面去测试
（1）用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
（2） 加密机制
（3）安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
（4）数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
（5）防病毒系统
黑盒测试和白盒测试的定义
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
等价类划分的方法编写三角形测试用例:
