1.测试工具
LoadRunner-负载压力测试：预测系统性能。
JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制功能测试：通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。
Junit：白盒测试工具：针对代码测试
测试管理工具：对测试需求、计划、用例、实施进行管理
测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备
负载压力测试：LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。
功能测试： QTP(quicktest professional):自动测试工具
白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试）
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
测试辅助工具：SVN
2.测试分类
2.1按开发阶段分
（2）集成测试
集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作。集成测试也叫组装测试、联合测试、子系统测试或部件测试。
确认测试的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般有第三方测试机构进行。
（4）系统测试
软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，
目的在于与系统需求比较，发现问题
（5）验收测试
以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。
不是对系统进行全覆盖测试，而是对核心业务流程进行测试。
| 测试阶段 | 测试方法 | 评估基准 | 对应阶段 |
| 单元测试 | 白盒测试：单元内部的数据结构，逻辑控制，异常处理等 | 逻辑覆盖率 | 详设 |
| 集成测试 | 灰盒测试：模块间接口以及模块组合后的整体功能 | 接口覆盖率 | 概设 |
| 系统测试 | 黑盒测试： | 测试用例对需求的覆盖率 | 需求 |
2.2 按测试设计方法分类
2.3 按是否自动分类
（1）手动测试
测试人员用鼠标去手动测试 （测试GUI）
（2）自动测试
用程序测试程序 （测试API）
对于项目来说， 手动测试和自动化测试同等重要，都是保障软件质量的方法。 目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化， 所以自动化测试无法取代手动测试。对于软件测试人员个人发展来说， 做自动化测试是个挑战，也是测试人员发展的一个方向， 需要测试人员学习大量的开发知识（开发的知识真是学无止境啊）。 从长远角度来看，自动化测试肯定是越来越吃香的。而手动测试比较适合刚工作不久的人，手动测试最大的缺点就是技术含量低，单调乏味，容易废人。总的来说，手工测试胜在测试业务逻辑，而自动化测试胜在测试底层架构。
如果被测试的程序可测试性比较好， 很有必要做成自动化测试。 能做自动化的尽量做成自动化， 下面这些情形是可以做自动化的：
1. 测试存储过程。 例如用C#去测试存储过程
2. 测试Web servies. 例如： 用SoupUI工具，或者C#,Java 去测试Web servies。
3. 界面和业务逻辑分离的系统，比如，MVC，MVP架构， 或者WPF 程序。 可以用测试脚本去测试这些程序的API。
自动化测试工具的分类：
a) 基于GUI的功能测试工具QTP（现UFT）
b) 基于IDE的自动化测试，比如开源的selenium/eclipse/visual studio selenium是开源框架，eclipse需要需要插件
c) 基于纯脚脚本的自动化测试 shell/perl/ruby/python
以下是详细的自动化测试的优缺点：
优点：
a) 节省人力，只要代码维护的好，不需要那么多人就可完成测试
b) 节省时间，测试脚本可以晚上或者是周末跑测试脚本
c) 优化资源分配，在运行测试脚本的同时，QA可以做其他事，比如设计新测试用例
d) 方便regression，极大提高效率
e) 增加软件的可信度，测试是机器执行的，排除了手工测试时因人为情绪而发生的随意性或疏忽性，测试结果更可信
f) 能完成手工不易控制的工作，比如采集系统cpu占有率信息，手工计算很复杂，还要进行数据比对，使用脚本更简单，更方便。
缺点：
a) 脚本维护成本高，尤其是版本变动比较大，对项目来说，是潜在的风险
b) 不易发现新bug
2.4 按测试目的分类
（1）功能测试
测试的范围从小到大，从内到外， 从程序开发人员（单元测试）到测试人员，到一般用户Alpha/Beta测试
| 测试名称 | 测试内容 |
| Unit Test 单元测试 | 在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员做的) |
| Functional Test 功能测试 | 验证模块的功能 （测试人员做的） |
| Integration Test 集成测试 | 验证几个互相有依赖关系的模块的功能 （测试人员做的） |
| Scenario Test 场景测试 | 验证几个模块是否能完成一个用户场景 （测试人员做的） |
| System Test 系统测试 | 对于整个系统功能的测试 （测试人员做的） |
| Alpha 测试 | 软件测试人员在真实用户环境中对软件进行全面的测试 （测试人员做的） |
| Beta 测试 | 真实的用户在真实的用户环境中进行的测试, 也叫公测 （最终用户做的） |
一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“Quality of Service requirement”服务质量需求。没有软件的功能，这些特性都无从表现出来，因此，我们要在软件开发的适当阶段-基本功能完成后做这些测试。
| 测试名称 | 测试内容 |
| Stress test 压力测试 | 验证软件在超过负载设计的情况下仍能返回正确的结果，没有崩溃 |
| Load test 负载测试 | 测试软件在负载情况下能否正常工作 |
| Performance test性能测试 | 测试软件的效能，是否提供满意的服务质量 |
| Accessibility test | 软件辅助功能测试-测试软件是否向残疾用户提供足够的辅助功能 |
| Localization/Globalization | 本地化/全球化测试 |
| Compatibility Test | 兼容性测试 |
| Configuration Test | 配置测试-测试软件在各种配置下能否正常工作 |
| Usability Test | 可用性测试 –测试软件是否好用 |
| Security Test | 软件安全性测试 |
性能测试要求测试人员熟练性能测试工具，比如QTP, LoadRunner, Jmeter。 Visual Studio也提供了很多性能测试的工具. 要求测试人员对低层协议非常理解和编写脚本
2.4按测试的时机和作用分类
在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否畅通。
| 测试名称 | 测试内容 |
| Smoke Test | “冒烟”–如果测试不通过，则不能进行下一步工作 |
| Build Verification Test（BVT） | 验证构建是否通过基本测试。 |
| Acceptance Test | 验收测试，为了全面考核某功能/特性而做的测试 |
BVT测试是一种Smoke Test, 指Build生成好之后，自动运行的自动化测试脚本来检查这个Build的基本功能。 如果BVT测试失败了，需要开发人员马上修改，重新生成Build。
2.5 按测试测策略分类
| 测试名称 | 测试内容 |
| Regression Test 回归测试 | 对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有退化 (regression) |
| Ad hoc Test 探索性测试 | 随机进行的，探索性的测试。 |
| Sanity Test | 粗略的测试， 只需要执行部分的测试用例 |
Regression Test 回归测试：
对软件测试人员来说就是重复测试，所以回归测试最好是自动化的， 否则测试人员就要一遍又一遍地重复测试，
1. 开发人员做些小改动，就需要测试人员做回归测试。确保现有的功能没有被破坏
2. Bug Fix 也需要回归测试，确保新的代码修复了Fix, 也确保现有的功能没有被破坏
3. 项目后期，需要做一个完整回归测试， 确保所有的功能都是好的
3软件测试关键问题
（1）谁来执行测试
很显然，表现在程序中的故障，并不一定是编码所引起的。很可能是详细设计、概要设计阶段，甚至是需求分析阶段的问题引起的。及时针对成程序进行测试，所发现故障的根源也可能在开发前期的各个阶段。解决问题、排除故障也必须追溯到前期的工作。世界上，软件雪球分析，设计和实施接段是软件故障的主要来源，因此雪球分析。概要设计。详细设计以及程序编码等各个阶段索得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序都应成为软件测试的对象。
当殷进度人力物力等原因，不可能对软件的每一部门进行完全测试时，应采取什么样策略来设计测试用例呢？是随机生成测试用例？还是测试软件中常用的功能或搞风险的部分？不言而喻，将精力花在系统的常用功能或高风险的部分是适当的。
（3）什么时候测试
测试是一个开发想并行的过程们还是当开发取得一定性成果之后的活动或者开发结束后的活动？也就是会所，模块开发结束后可以进行测试，也可以推迟至各模块装配成一个完整的程序之后再进行测试。实践表明，随着开发的深入，并进行测试的模块对整个软件的签字破坏作用就越明显。
那么应该在什么时候进行测试才是恰当的呢》？有时测试只需在开发过程即将结束时进行，也就是说，系统测试或验收测试是对阮籍的唯一正式的测试。在开发者的数量相对少的时候，这种方法还可行。单对大多数开发过程来说是不适合的。人们已经开始认识到：测试开始的是每天都进行测试，一旦软件模块开发出来就对他们测试，这样显然又会延缓早期开发的进度。不过，它能够大大减少将所有模块装配到项目中以后出现问题的可能性。
（4）怎样进行测试
软件规范说明了软件本省应该达到的目标，程序实现则是一种对应各种输入如何产生输出结果的算法。简言之，规范说明一个软件要做什么，二程序实现则规定了软件应该怎样做。对软件进行测试就是用根据软件的功能规范说明和程序实现，利用后续各章介绍的各种测试方法。生成有效测试用例，对软件进行测试。
（5）测试停止的标准是什么
从现实和经济的角度来看，对软件进行完全测试是不可能的，那么什么时候停止测试呢？因为无法潘丹当前歘出的故障是否为最后一个故障，所以决定什么时候停止测试是一件很困难是事情。测试完成串通标准是分配的测试时间用完了或完成了所有的测试又没有检测出故障，，单这个两个完成标准都没有什么实用价值，实用的停止测试标砖应该给予一下几个因素：成功地采用了具体的测试用例设计方法，每一类覆盖的覆盖率。故障检出率，检测出故障的具体数量或消耗的具体时间等。
4.自动化测试前提条件
1) 需求变动不频繁
测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。
2) 项目周期足够长
自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。
3) 自动化测试脚本可重复使用
如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
