软件测试方法

从测试设计方法分类

测试名称	测试内容
Black box黑盒测试	把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。从软件的行为，而不是内部结构出发来设计测试.
White box白盒测试	设计者可以看到软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。
Gray box.  灰盒测试	介于黑盒和白盒之间

 总结：   实际工作中，对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试，很少有做白盒测试的。 因为白盒测试对软件测试人员的要求非常高，需要有很多编程经验。做.NET程序的白盒测试你要能看得懂.NET代码。做JAVA程序的测试，需要你能看懂JAVA的代码。 如果你都能看懂了，你还会做测试么

从测试是手动还是自动上分类

测试名称	测试内容
Manual Test 手动测试	测试人员用鼠标去手动测试 （测试GUI）
Automation 自动化测试	用程序测试程序 （测试API）

对于项目来说， 手动测试和自动化测试同等重要，都是保障软件质量的方法。 目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化， 所以自动化测试无法取代手动测试。

对于软件测试人员个人发展来说， 做自动化测试是个挑战，也是测试人员发展的一个方向，  需要测试人员学习大量的开发知识（开发的知识真是学无止境啊）。 从长远角度来看，自动化测试肯定是越来越吃香的。

而手动测试比较适合刚工作不久的人，手动测试最大的缺点就是技术含量低，单调乏味，容易废人。

总的来说，手工测试胜在测试业务逻辑，而自动化测试胜在测试底层架构。

如果被测试的程序可测试性比较好， 很有必要做成自动化测试。 能做自动化的尽量做成自动化， 下面这些情形是可以做自动化的

1.   测试存储过程。  例如用C#去测试存储过程

2.   测试Web servies. 例如： 用SoupUI工具，或者C#,Java 去测试Web servies。

3.   界面和业务逻辑分离的系统，比如，MVC，MVP架构， 或者WPF 程序。 可以用测试脚本去测试这些程序的API。

从测试的目的分类

功能测试

测试的范围从小到大，从内到外， 从程序开发人员（单元测试）到测试人员，到一般用户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也提供了很多性能测试的工具. 要求测试人员对低层协议非常理解和编写脚本

性能测试非常有技术含量， 很有发展前途， 是软件测试人员的一个职业发展方向。

 

安全性测试

安全性测试的内容很广， 非常有难度啊。 我只接触过XSS（跨站脚本攻击）和SQL注入攻击。

安全性测试非常有技术含量， 我认为也是软件测试人员的一个职业发展方向

 

按测试的时机和作用分类

在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否畅通。

测试名称	测试内容
Smoke Test	“冒烟”–如果测试不通过，则不能进行下一步工作
Build Verification Test（BVT）	验证构建是否通过基本测试。
Acceptance Test	验收测试，为了全面考核某功能/特性而做的测试

 

BVT测试是一种Smoke Test, 指Build生成好之后，自动运行的自动化测试脚本来检查这个Build的基本功能。 如果BVT测试失败了，需要开发人员马上修改，重新生成Build

按测试测策略分类。

测试名称	测试内容
Regression Test 回归测试	对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有退化 (regression)
Ad hoc Test 探索性测试	随机进行的，探索性的测试。
Sanity Test	粗略的测试， 只需要执行部分的测试用例

Regression Test 回归测试：　　

对软件测试人员来说就是重复测试，所以回归测试最好是自动化的，　否则测试人员就要一遍又一遍地重复测试，　

1. 开发人员做些小改动，就需要测试人员做回归测试。确保现有的功能没有被破坏

2. Bug Fix 也需要回归测试，确保新的代码修复了Fix, 也确保现有的功能没有被破坏

3. 项目后期，需要做一个完整回归测试， 确保所有的功能都是好的

Ad hoc Test 探索性测试： 

平常我最喜欢做随机测试了， 抛开test case.  自己按照自己的思路，随便点点。 如果测试GUI，Ad hoc能发现大量的bug. 

软件测试人员应该居安思危

每当经济不好，公司业绩不好的时候，公司都可能进行裁员。 首先裁的就是测试人员。 因为测试人员的技术水平相对来说比较低，容易被替代，招起来也比较容易。 公司往往先拿测试人员开刀。

身为测试人员，虽然我们平常的工作大部分都比较安逸。 但是千万不能温水煮青蛙。 应该自强不息， 要像开发人员一样， 不断学习，提高自己的编程水平。这样就算被裁也能很快找到新的工作。

测试人员应该比开发人员更熟悉业务需求

测试人员的水平主要体现在测试用例的设计上。 要设计出全面，覆盖广的测试用例，需要测试人员对自己所测试的项目的业务需求非常熟悉，甚至要比开发人员还要熟悉。

如果是测试银行系统，通信行业，或者ERP软件。 这些业务知识非常有用的，学习起来比较有激情。

要做到精通业务需求谈何容易。

1. 要熟读功能需求文档， 任何有疑问的地方都要去和PM确认。

2. 把自己当成最终用户， 经常使用自己所测试的软件。模拟用户的行为。

3. 熟记软件的每个功能。 

假如倒霉碰到一些又没用，又繁琐的软件， 真的是不想去学习它的业务（出了这个公司就再也用不到的业务）

学会如何跟开发人员相处

测试人员必须跟开发人员密切合作， 所以跟开发人员搞好关系是相当重要的。

1. 和开发人员成为朋友。

 熟悉了干啥都方便

2. 不要打扰开发人员

看到开发在聚精会神写代码的时候，千万不要去打扰人家。 写代码需要集中精力，如果被打扰，就会中断思考。 

3. 集中问问题。

把需要问的问题都总结起来， 集中起来问开发，这样能节省大量的时间。

4. 写好Bug，不被开发人员烦。

如果开发人员看到一个Bug 描述不清楚，还无法重现，他肯定会骂测试人员。 所以测试人员一定要写好Bug，描述精确，简洁，没有歧义，详细简洁的重现步骤，加截图。

测试人员应该懂一些基本的编程

你的产品是用C# 开发的，那测试人员应该有C#的入门知识。  你测试web程序，你起码要了解HTML,CSS, Javascript, Jquery吧，否则你测了一两年web程序，都不知道这东西是怎么做的，悲剧了吧。

只有懂代码你才能和开发人员交流，不被开发鄙视。

测试人员搭建开发环境

产品的代码是最好的学习资料了，我们不能总跟在开发屁股后面做测试，不能老是等开发build一个版本后，我们就测试这个版本，开发check in了什么代码，测试人员一点都不知道。偶尔我们应该了解下产品代码是怎么设计的，了解下开发人员是如何修复bug的。说不定编程水平高了，还能帮开发做code review.

使用源代码工具把产品代码check out到本机。 经常看看代码，经常看看开发修复bug时候提交的代码.

写文档是测试人员的核心能力

我记得我以前的test lead说，之所以她能当lead, 是因为她很会写文档发邮件。 写文档需要总结归纳的能力，还要逻辑清晰。 她非常擅长分析几十页的Spec，写出几十页的测试计划。 她还非常擅长汇总测试报告。 每天将完整，清晰，漂亮的测试报告发给各个组， 让公司所有的人都能清晰的看到测试组的工作。

在她的带领下，我们总结出很多文档，比如，"New hire checklist",   "on boarding traning", 测试工具使用的文档，等等。

写多了博客后我发现我写文档能力提高了很多。

测试后期应该做两天交叉测试

 交叉测试，就是指两个测试工程师，互相交换下测试的项目。 这样做有很多好处。

1. 有利于找出bug, 测试工程师测久了自己的项目，容易形成眼盲。会对一些Bug熟视无睹。 

2. 有利于知识和业务共享，避免人员离职，请假，造成无人测试的情况。

3. 测试思想不一样，可以互相找出很多问题

测试人员的瓶颈

手动测试工作做个两三年，基本上就能掌握测试需要的大部分知识，如果没有爬到test lead的位置， 很多人就感觉到发展瓶颈了，每天重复测试，学不到东西，很快就会对测试工作失去激情。

学不到东西，技术水平低下，是测试这个行业最大的毛病。

如何突破瓶颈？ 我也不知道。

尽量实现自动化

一点要抽时间尽量把自己的测试工作实现自动化，可以节省测试的时间，提高自己的技术水平，也可以避免老是重复测试。

自动化测试VS手动测试

现在很多公司招测试的要求越来越高，很多好公司招senior QA,都要求5年工作经验以上，掌握一门编程语言，有丰富的自动化测试经验。当然自动化测试的待遇也会比手动测试好很多。

自动化是趋势， 只会做手动测试的人，以后肯定会失去竞争力。

自动化测试的技术和开发用到的技术相差太远

以前很多同事想由测试转开发，现在几年过去了，还是没转成，他们原先想利用自动化测试的技术积累，转去做开发。哪知道自动化测试用到的技术跟开发用到的技术相比，实在是相差太远。

测试转开发？ 难

努力学习编码，然后用于测试，才是正道

做测试最郁闷的是无法听懂开发人员讨论技术

有时候跟开发人员一起开会， 会议上开发人员都热烈讨论。 而我做为测试人员基本上听不懂这群开发在说什么，根本插不上话。 很多会议我甚至都没说过一句话。

优秀的测试人员非常稀少

想把测试做好非常不容易， 优秀的测试人员需要很广的知识面，良好的沟通能力（不但要和开发人员和项目经理打交道，还要跟其他组的人交流）。  丰富的测试经验，对测试工作有极大的热情， 耐心。还需要测试人员有丰富的业务知识，还要会写代码。

代码写得好的人，肯定就不会做测试，而是做开发去了。

大部分的测试经理都是有开发背景的

我发现我的几任上司都是由开发转来做测试的。 他们都是有几年的开发经验，然后不知道什么原因转行做测试经理了。他们既能开发又能测试，啥都会，能给手下的测试人员提供技术支持。

假如一个测试经理啥技术都不懂，对内hold不住手下的人，对外其他组的人不鸟你。

软件测试的确非常枯燥，需要花费大量精力

不可否认测试工作需要耗费大量的精力，所以欧美才会把大量的测试职位外包给中国， 一遍又一遍的重复测试，不停地执行测试用例， 测得天昏地暗， 头发晕。

我还记得我以前测试过一个程序的各个版本在Windows update中的升级，  先安装老版本的程序，然后Windows update 重启后看看有没有升级，最后卸载。 然后又安装，又卸载。最后测的差点吐血。

英语是测试人员的救命稻草

技术上已经不如开发了。 在英语上一定占有一些优势。

同等的技术水平下，英语好的测试人员可以进外企，比一个英语不好的测试人员的待遇要高不少。

尽量少用UI自动化测试，多使用单元测试，接口测试

能找到bug的自动化测试，才是有用的，否则就是个噱头

UI自动化测试比较不稳定，对于测试结果的分析也困难。 而且UI改动也大。 所以应该尽量多做一些底层的的自动化测试，比如ASP.NET MVC 中UI和逻辑分开了，针对逻辑的自动化测试就比较好做了。