软件测试入门教程 on 重定向学院

软件测试实质

Tue, 17 Jun 2025 17:29:15 +0800

Ron Patton所著的《软件测试》2002年的中文版，已经十五年了，但它对“软件的实质”的解释仍然是经典，这里摘录与大家分享。

实质，哲学中的本质，又称为“实质”是指某一对象或事物本身所必然固有的。说的通俗点也就是说软件测试的本来的面目。

#### 软件缺陷的定义

来看一下Ron Patton 为我们的软件缺陷所下的定义。

1、软件没有实现产品的说明书所描述的功能。

2、软件实现了产品说明书描述不应有的功能。

3、软件执行了产品说明书没讲的操作。

4、软件没有实现产品说明书没讲但应该实现的功能。

5、从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。

为什么一个定义要这么多条来描述？这个“缺陷”的定义有这么复杂么？不，它其实并不复杂，作者只是想更加全面的来给“缺陷”下定义。

下面我们来以建一栋房子为例，来说明一下每一条定义的意思。需要说明的是没有十分完美而且一成不变的产品说明说，而且在实际项目中，它可能非常简陋，模棱两可，甚至经常变动。

1、软件没有实现产品说明书的描述的功能。房子的主人希望有一个落地的大窗户，让阳光更好的照进屋子里，而且他特意在房子的设计图纸中画出来，并且还加以说明。结果，他看到的是四面全是墙壁，只有一个小门的房子。那么对于测试人员来说，他就是一个缺陷。

2、软件实现了产品说明书中描述的不应有的功能。由于房子的主人生活在南方，天气温暖，而请来的泥瓦匠是北方的，结果给主人建造的房子具然有一个大大的取暖的烟筒，而且主人特意在房子的设计图纸中说明，自己的房子不要烟筒。那么对于测试人员来说，这也是个缺陷。

3、软件执行了产品说明书没讲的操作。与第二条类似，不同的是第二条是主人已经明确说了自己不要烟筒，而这一条强调的是在主人没说的情况下。泥瓦匠自作聪明的加了一个烟筒上去。对于测试人员来说，画蛇添足的功能同样被视为缺陷。

4、软件没有实现产品说明书没讲但应该实现的功能。房子的主要对屋子的高度、格局，材料，颜色描述的非常清楚。泥瓦匠在建造房子的时候发现，主人没有提地基这回事，为了使房子牢固，所以，所有的房子都是必须要先打地基的，虽然主人没有说，但地基的功能必须要做。如果因为没有描述没有去做，但这又一件必须去做的事。对于测试人员来说，也可以视其这缺陷。

5、从软件测试员的角度看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。软件测试员是软件除了测试软件运行的缺陷，同样是作为一个用户在再对软件进行使用。如果感觉自己都很难使用，或软件效率非常低且界面丑陋等情况，也可以认为其存在缺陷。或者是最终用户拿到产品时发现这根本不是自己想要的东西，也可以现其为缺陷。当然，用户说不是自己想要的东西，也不能凭借一面之词，可以拿合约，产品说明书来评估。

#### 完全测试程序的可能性

初做软件测试者可能认为拿到软件后就可以进行完全测试了，找出所有软件缺陷，并使软件完美。遗憾的是这是不可能的，我们无法对一个软件进行完全测试，即使最简单的程序也不行。主要原因如下：

输入量太大
输出结果太多
软件实现的途径太多
软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同

以上的“太多”的可能性加在一起，致使测试条件难以确定。

以126邮箱为登录测试为例，其用户长度为50个字符，密码确实不太好计算（因为都是*号），所以这里也按50个字符来计算。

在输入正确用户名的情况下：

1、输入正确的密码名是还否可以登录，

2、那么错误输入0 呢？1呢？2呢？......直到

99999999999999999999999999999999999999999999999999 ，

3、如果密码不是数字，而是字符呢，a 、b、c ... aa、bb 、cc .....

4、如果是大写呢 A 、B、C.... AA 、BB、CC.....

5、如果是大小写呢 Aa、Ab ....

6、如果是小写+数字呢 1a 、1b 、1c ....2a 、2b 、2c.....

7、如果是大写+数字呢 1A 、1B 、1Cc....2A 、2A 、2A.....

8、如果是大写+小写+数字呢 1Aa 、1Bb 、1Cc ....1Aa 、1Bb 、1Cc.....

9、如果有特殊字符呢 @#￥%……&*

10、如果输入字符有空格呢 a b、adbc ee......

11、如果是其它字符+大小写字母+数字呢+空格呢 ！@#&+123AIBKIkklzcb ......

......

12、再换正确的密码，错误的文件名再来一次。

13、用错误的用户名和密码再把上面的情况验证一次。（这样会匹配到所有的用户名密码）

14、什么都不输，直接点击登录

这样穷举下去，就算是计算机也可能需要运行很久。如果觉得某些测试条件是重复的或者是无必要的，而将其剔除，那么就不能称为完全测试。

软件测试分类

Tue, 17 Jun 2025 17:29:15 +0800

软件测试领域名词颇多，许多测试新手容易混淆概念。因为从不同的角度对软件测试有不同的分类方法，所以，这里汇总常见软件测试的相关名词，让读者对软件测试领域有个概括性了解。
#### 根据项目流程阶段划分软件测试

是一个典型的“V”模型软件开发流程，各项软件测试工作是在项目开发流程中循序渐进进行的。下面将介绍各个阶段测试的含义。

单元测试：单元测试（或模块测试）是对程序中的单个子程序或具有独立功能的代码段进行测试的过程。
集成测试：集成测试是在单元测试的基础上，先通过单元模块组装成系统或子系统，再进行测试。重点是检查模块之间的接口是否正确。
系统测试：系统测试是针对整个产品系统进行的测试，验证系统是否满足需求规格的定义，以及软件系统的正确性和性能等是否满足其需求规格的要求。
验收测试：验收测试是部署软件之前的最后一个测试阶段。验收测试的目的是确保软件准备就绪，向软件购买者展示该软件系统能够满足用户的需求。

#### 白盒测试、黑盒测试、灰盒测试

白盒测试与黑盒测试，主要是根据软件测试工作中对软件代码的可见程度进行的划分。这也是软件测试领域中最基本的概念之一。

黑盒测试

黑盒测试，指的是把被测的软件看作一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。它只检查程序呈现给用户的功能是否按照需求规格说明书的规定正常使用、程序是否能接收输入数据并产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

白盒测试

白盒测试，指的是把盒子打开，去研究里面的源代码和程序执行结果。它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条逻辑路径是否都能按预定要求正确工作。

灰盒测试

灰盒测试介于黑盒测试与白盒测试之间。

可以这样理解，灰盒测试既关注输出对于输入的正确性，同时也关注内部表现。但这种关注不像白盒测试那样详细、完整，它只是通过一些表征性的现象、事件、标志来判断内部的运行状态。有时候输出是正确的，但内部其实已经错误了，这种情况非常多。如果每次都通过白盒测试来操作，效率会很低，因此需要采取灰盒测试的方法。

#### 功能测试与性能测试

从软件的不同测试面可以划分为功能测试与性能测试。

功能测试

功能测试主要检查实际功能是否符合用户的需求，因此测试的大部分工作也是围绕软件的功能进行。设计软件的目的就是满足用户对其功能的需求，如果偏离了这个目的，则任何测试工作都是没有意义的。

功能测试又可以细分为很多种：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等。

性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的测试。

软件的性能包括很多方面，主要有时间性能和空间性能两种。

时间性能：主要是指软件的一个具体的响应时间。例如一个登录所需要的时间，一个商品交易所需要的时间等。当然，抛开具体的测试环境，来分析一次事务的响应时间是没有任何意义的，它需要在搭建好的一个具体且独立的测试环境下进行。

空间性能：主要指软件运行时所消耗的系统资源，例如硬件资源，CPU、内存、网络带宽消耗等。

#### 手工测试与自动化测试

从对软件测试工作的自动化程度可以划分为手工测试与自动化测试。

手工测试

手工测试就是由测试人员一个一个地去执行测试用例，通过键盘鼠标等输入一些参数，并查看返回结果是否符合预期结果。

手工测试并非专业术语，手工测试通常是指我们在系统测试阶段所进行的功能测试，为了更明显地与自动化测试进行区分，这里使用了手工测试这种说法。

自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计测试用例并通过评审之后，由测试人员根据测试用例中描述的规则流程一步步执行测试，把得到的实际结果与期望结果进行比较。在此过程中，为了节省人力、时间和硬件资源，提高测试效率，便引入了自动化测试的概念。

自动化测试又可分为：功能自动化测试与性能自动化测试。

功能自动化测试：是把以人为驱动的测试行为转化为机器执行的一种过程。通过测试工具（或框架）录制/编写测试脚本，对软件的功能进行测试，并验证测试结果是否正确，从而代替部分的手工测试工作，达到节约人力成本和时间成本的目的。

性能自动化测试：通过性能工具来模拟成千上万的虚拟用户向系统发送请求，从而验证系统的处理能力。

#### 冒烟测试、回归测试、随机测试、探索性测试和安全测试

这几种测试出现在软件测试的周期中，既不算具体明确的测试阶段，也不是具体的测试方法。

冒烟测试

是指在对一个新版本进行大规模的系统测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。

引入到软件测试中，就是指测试小组在正式测试一个新版本之前，先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有运行通过，则打回开发组重新开发。这样做的好处是可以节省时间和人力投入到不可测的项目中。

回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改后没有引入新的错误或导致其他代码产生错误。

回归测试一般是在进行第二轮软件测试时开始的，验证第一轮软件测试中发现的问题是否得到修复。当然，回归也是一个循环的过程，如果回归的问题通不过，则需要开发人员修改后再次进行回归，直到所有问题回归通过为止。

随机测试

是指测试中的所有输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

趣谈软件需求分析

Tue, 17 Jun 2025 17:29:15 +0800

什么是需求分析？

通俗的讲，对用户的意图不断揭示和验叛的过程，要对经过系统可行性分析所确定的系统目标做更为详细的描述。

假如你是个建筑工程师，有个客户找你建一个鸡窝，这个时候要需要与客户沟通，来确定客户到底想要一个什么样子的鸡窝。我们应该注意三点：

1、准确的理解和描述客户需要的功能。

客户说，我的鸡窝要三层的，带电梯，饮水池，厕所，饮水池要自动判断水位供水，电梯要可以同时乘坐10只鸡….客户滔滔不绝的讲了一大堆，你也都非常忠实的按照自己的理解再一一的向客户描述一遍，以便于确认客户的需求是否正确。

2、帮助客户挖掘需求。

等客户把自己的需求说完了，你发现客户没有说鸡的卧室，于是，你向客户提议说：“你看，这鸡的卧室要什么样子的？”，客户连连的拍着脑门说，我差点给忘记了，鸡们啊喜欢晚上在一起聊天，所以呢，需要一个长而大的卧室，但一定要舒适。

3、分析客户需求的可行性。

客户临走时又说，最近啊，黄鼠狼很多，我这个鸡窝啊，一楼就不用盖了，直接盖二楼和三楼吧！以免晚上遭遇黄鼠狼的攻击。你这么一分析，客户这要求，按照目前的技术可没法建啊，于是，你向客户提议，一楼采用坚固架子来支撑二三楼的建筑。

#### 需求分析困难在哪儿？

有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。

1、客户说不清楚需求

有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多政府机构在搞网络建设，这些单位的领导和办公人员大多不清楚计算机网络有什么用，反而要软件系统分析人员替他们设想需求。这类工程的需求是如此的主观，以致产生很多贪污腐败现象。

有些客户心里非常清楚想要什么，但却说不明白。你可能很不以为然。就举日常生活的事例吧，比如说买鞋子。我们非常了解自已的脚，但没法说清楚脚的大小和形状。只能拿鞋子去试，试穿时感觉到舒服才会买鞋（居然也有神通广大的售货员，看一眼客户的手，就知道应该穿什么样的鞋）。

如果客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。如果客户全不懂软件，但信任软件开发方，这事也好办。分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。

2、需求自身经常变动

唐僧曾说：“妖要是有了仁慈之心，就不再是妖，是人妖。”（《大话西游之大圣娶亲》）

连妖都会变心，别说人了。所以喜新厌旧乃人之常情，世界也因此变得多姿多彩。

软件的需求会变化吗？

答：据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。[Cline 1995]

让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。明白“需求会变动”这个道理后，在进行需求分析时就要留点神：

尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。
在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。要防止象韩复渠那样，在别人请他喝酒吃饭时他什么都点头（人家就更加献殷勤），吃完了他就宣布刚才答应的事都不算数，便扬长而去。

3、分析人员和顾客理解有误

有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”

软件系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。我读中学时候最怕写作文逃题，如果逃题了，不管作文写得多长，总是零分。所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。

由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。

有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处，客户听得津津有味。最后，心动的客户对软件人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”

需求分析的分类

需求分析一般可分为功能需求、非功能需求和领域需求

1、功能需求

功能需求主要说明了系统实际应做到什么。这是用户最直观也是最主要的需求，如系统的输入输出、系统能完成的功能以及其它相关处理等；

2、非功能需求

非功能需求又称“约束”，它主要从各个角度对系统起约束和限制作用。如响应时间、存储效率、报表的规格和界面的样式等

3、领域需求

领域需求的来源不是用户，而是系统应用的领域，其主要反映了该领域的基本问题。例如勤工俭学管理系统，其领域需求就涉及到诸如应聘合同书、酬金发放及劳工考核等相关内容，如果这些需求得不到满足，系统就无法正常运行。值得一提的是，领域需求可能是功能需求，也可能是非功能需求。

如何进行需求分析

进行需求分析不象情人之间的浪漫做法——“让我摸摸你的头发，感觉它是什么颜色。”我们需要了解需求分析的渠道和过程。

需求分析的过程：

（1）可行性研究

它指明现有的软件、硬件技术能否实现用户对系统的要求，从业务角度来决定系统开发是否可行以及在预算范围内能否开发出来。可行性研究的结果是清楚的回答：该系统是否值得开发

（2）需求导出和分析

这是一个通过对现有系统分析、与潜在客户讨论、进行任务分析等导出系统需求的过程，也可能需要开发一个或多个不同的系统原型，以帮助分析员了解所要描述的系统。

（3）需求描述

需求描述就是把在分析活动中收集的信息通过分析整理之后以文档的形式确定下来。该文档中有两类需求：用户需求是从客户和最终用户角度对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。

（4）需求有效性验证

主要是通过评审、验证等一系列活动来找出需求文档中的错漏并加以改正。

（5）需求管理

需求管理需求管理是一种系统化方法，可用于获取、组织和记录系统需求并使用户和开发方在系统变更需求上始终保持一致

#### 需求分析的方法

1、功能分析方法

一个bug的生命周期

Tue, 17 Jun 2025 17:29:15 +0800

又一篇测试技术普及文章，希望你在被各种技术吸引的同时，能时常来整理和总结软件测试最基本的知识。
#### Bug的属性 ---- __Bug重现环境__

这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。

操作系统

这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。对于不同的操作系统，其可能存在差异（如：win xp 与 win 7）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。

浏览器

对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。

不同的浏览器之间（IE、 firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug前提条件之一。

其它（这个“其它”非常重要）

对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。

对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。

问题类型

根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题（其实，他只是将bug做为一子类而已）。

JIRA系统缺省提供的问题类型（大部分的系统都可以自定义类型的，这样就增加了灵活性。）

Bug : 测试过程、维护过程发现影响系统运行的缺陷。（这就是一般测试人员所提交的bug）
New Feature : 对系统提出的新功能。（单个的小需求可以，如果大的话，就相当于一个需求，放到这里是不合理的。）
Task : 需要完成的一任务。（开发或测试任务指派。）
Improvement : 对现有系统功能的改进。（一般产品经理或产品体验师做的事）

当然，不同的公司，他们的人员定位与职责是不太相同的，按照上面的分类，JIRA就不是简单的缺陷管理系统了，它涵盖一项目（或产品）所需要处理的任务、需求与缺陷。

Bug 类型

这里缩小范围，单指我们测试人员在测试过程中发现的缺陷，发现产品缺陷其实就是测试人员工作的主要目的。当然，你要确定一个问题的类型，也需要对项目（或产品）有比较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分，当然，这个划分，对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。

下面看一些常见的分类：

划分方式一：

　　* 代码错误

　　* 设计缺陷

　　* 界面优化

　　* 配置相关

　　* 安装部署

 * 性能问题

　　* 标准规范

　　* 测试代码

　　* 其它

划分方式二：

　　* 功能类（function）

　　* 性能类（performance）

　　* 界面类（UI）

　　* 易用性类（usability）

　　* 兼容性类（compatibility）

　　* 其它（else）

这个分类当然是可以自定义的，具我接触的缺陷管理都是可以自定义的，既然是对问题的管理，那么你当然可以拿来做特定环境下的系统来使用，或我就想用这个系统来指派任务，那么我的自定义类型为前端任务、后端任务、测试任务、配置部署…

浅谈测试用例

Tue, 17 Jun 2025 17:29:15 +0800

#### 一、什么是测试用例？ ---- 测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。

#### 二、写测试用例有什么好处？ ---- * 理清思路，避免遗漏

这里是我们认为最重要的一点，假如我们测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。

跟踪测试进展

通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。

历史参考

在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。

重复性

我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。

#### 三、测试用例的方法 ---- 好吧，咱知道啥是测试用例了，也是知道为什么要写测试用例了，那到底应该怎么写？无从下手啊。我们在写测试用例之前，先学习几种方法，它是我们写测试用例的指导思想。

等价类划分

等价类是指某个输入域的一个特定的子集合，在该子集合中各个输入数据对于揭露程序中的错误都是等效的，也就是说，如果用这个等价类中的代表值作为测试用例未发现程序错误，那么该类中其他数据（测试用例）也不会发现程序中的错误。

有效等价类： 输入满足程序输入的要求（来自规格说明书），通俗的说就是正确的输入。

无效等价类： 输入不满足程序输入的要求，即异常输入，需要系统对此有一定的容错性。

例如：

一个输入框要求输入1-10000的数字

有效等价类：可以输入1-10000之间的数来验证，如：2、5、99、8495……

无效等价类：可以输入1-10000之外的任意字符验证，如：0、10001、字母、下划线、特殊符号、空格、回车…..

边界值

边界值是对等价类的补充，测试工作经验告诉我们，大量的错误是出在输入输出的边界价上。我们还拿上面的例子，一个输入框要求输入1-10000之间的数。我们要测它有没有超出这个范围，如：0、-1、-2、1000、10001…..等等，来判定是否超出了我们的范围。

因果图

因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。举个例子：原因：A=0，B=0，结果我就可以判定：A=B。确切的说他是一种因果关系思想。它会无形中指导这我们的测试。当然了，我们为了以免遗漏，可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。呵呵。

错误推测法

基于经验和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法。

其它

设计测试用例的方法有很多，我们常用就上面几种，其它的方法还有：状态迁移图、流程分析法、正交验证法等等。

#### 四、测试用例的格式与要素 ---- 一个测试用例应该包括：编号，标题，测试场景，测试步骤，预期结果。

当然还可加入一些它选项，如：优先级、测试阶段….

编号：

标题:

测试环境：

测试步骤：

预期结果：

关于测试用例的存放管理：

1、项目管理系统自带的用例管理，一般用例会与项目挂钩，有固定的格式，搜索、修改等功能，使用起来非常方便。如：禅道项目管理、QC、bugfree 等等都带的有用例管理功能。

2、通过world\Excel文档形式管理，这样的好处就是自己定义测试用例的格式。

面来看一个具体的测试用例。我们会有更深刻的认识。

编号：001

标题: 系统登录测试用例

测试环境：
Windows 10/Chrome 58


测试步骤：
1、打开浏览器，输入系统网站，打开登录页面。
2、用户名密码为空，点击登录按钮
3、输入用户名，密码为空，点击登录按钮。
4、用户名为空，输入密码，点击登录按钮。
5、用户名正确，密码错误，点击登录按钮。
....


预期结果：
1、成功打开首页。
2、系统提示：用户名密码不能为空。
3、系统提示：密码不能为空。
4、系统提示：用户名不能为空。
5、系统提示：用户名或密码错误。
....

__最后__ ，写好测试用例，除了掌握基本的测试方法之外，最重要的是，要去深入理解业务需求。从需求文档中抽出测试点；另外善于总结以往测试中发现的bug，完善测试用例。

原始封面

软件测试分工

Tue, 17 Jun 2025 17:29:15 +0800

按照本文的主题还是来谈谈软件测试人员的分工吧！主要来谈传统软件测试过程中的测试分工。

集体测试

也许专业测试里讲这种方式，很可能不叫“集体测试”。因为我根据的自己的理解起了大概符合意思的名词叫集体测试“集体测试”。

这种测试模式就是，公司里所有的测试人员抱成一团儿，来一个项目，所有测试人员就集中测试一个项目。

先说这种分工方式的优点：

1、因为测试团队的中每个成员有都有优缺，人员在工作之中相互取长补短。可以很快的找出软件中的缺陷。三个臭皮匠顶一个诸葛亮，一个经验再丰富的测试不一定有三个水平一般的测从员发现的问题多。

2、人多的另一个好处是测试项目能可以在更快的时间内发现更多的缺陷。总结一下就是更短时间内发现更多的问题。

再来说说这种方式的缺点：

1、一个人员一张嘴，人力成本很高（人员工资，人员平均时间投入，测试机等硬件资源投入）。

2、当同时需要测试多个项目中时，不好意思，按顺序来，请在后面排好队。（并发能力不足）

3、工作重复，同样一个缺陷，很可能同时被所有测试员发现，或者叫重复率很高。

4、人员水平难以区分，在一个项目测试过程中，有的测人员可能一个缺陷也没找到，有的测试人员却发现了几乎所有的问题。也许这个项目一个缺陷也没找到的测试员在下个项目中却发现了很多缺陷。（混入南郭先生）

5、发现了漏测现象是整个测试团队的责任。（这也不是明确的缺点，要看团队的氛围是积极的还是消极的。）

好吧！集体测试缺点太多，就像国家成立初期的“吃大锅饭”，肯定是阻碍发展的。那我们来看看几种分工方式。

#### 按测试内容分工 ---

一个项目的测试包括文档测试，易用性测试，逻辑功能测试，界面测试，配置和兼容等多个方面。我们可以根据人员的特点为每个人员分配不同的测试内容。

内容分工方式的优点：

1、分工明确，每位人员都清楚自己的测试的内容重点。

2、责任到位，通过漏测的缺陷就可明确是谁的责任。

#### 按测试流程划分 ----

我们的项目测试流程一般需要，制定测试计划，编写测试用例，执行测试用例，输出测试报告等工作，我们可以根据流程中的各个阶段来进行划分。

不同的测试人员负责不同测试阶段的工作。

优点：

1、流程清晰，就像瀑布试项目开发流程，不同阶段的工作由不同的人员担任。

2、划分流程的每个阶段难易程度和所需要的技能。

编写测试计划人员需要对整个项目的工作时间、资源分配，测试内容，实施过程有整体的把控能力。

用例辨析人员，需要对项目需求，测试方法，测试点有深入的了解。

用例执行人员需要细心，使用缺陷系统，沟通，协助研发定位缺陷。

输出测试报告人员需要对项目的测试过程，缺陷数量，类型，分布。用例执行请况等进行统计。也可以由测试执行人员担任。

#### 按项目模块划分 ---- ![](http://img.testclass.net/module_test.png)

对中大型的项目，这种划分就非常必要了，项目的模块非常多，功能也非常多。不同的测试人员负责不同模块的功能测试，这样会使用测试工作变得更加清晰。

1、人员利用率高，为什么这么说呢? 不同的人员负责的功能不一样。工作就不会存在交叉与重复。

2、更容易挖掘深度缺陷，假如A人员今天测试这个功能，明天测试那个功能，他就不可能对被测功能内部逻辑与业务有深入有了解。找到的也只是很表面的缺陷。那么如果一个人员长期负责一个模块的功能，那么就会更容易发现更有深度的缺陷。而往往深度的缺陷是致命的。

#### 按照测试类型分工 ----

我们知道软件除了功能需要测试以外，软件在编码阶段需要单元测试，接口测试等，在系统测试阶段，为提高功能测试的效率，可能对某些模块进行功能自动化，我们还要考虑软件的性能、安全性等问题。这些类型也是我项目中最常见的分类。我们可以根据这些类型为测试人员分配测试工作。当然，其专业性对测试人员的要求也比较高。

测试投入与产出

Tue, 17 Jun 2025 17:29:15 +0800

在测试人员分工中，我介绍了各种分工方式，在选择使用哪一种分工方式时，还需要考虑投入的人员数量，投入的时间，与发现缺陷的数量。

#### 投入时间与发现缺陷的关系： ---- ![](http://img.testclass.net/time_and_bug.png)

在人员一定的情况下，投入的时间越多，发现的缺陷越多。但有一个规律，越到后期发现的新缺陷越少。假设软件总缺陷为100个，第一周发现50个问题，第二新发现20个，第二周可能只发现10个新缺陷。而且一个必然的结果是，测试不可能发现所有的缺陷。

#### 投入人员数量与缺陷的关系： ---- ![](http://img.testclass.net/personnel_and_bug.png)

在时间一定有的情况下，投入的人员越多，发现的问题越多，从图中可以看出，投入的人员越多，人员发现缺陷的重叠度越高。当然，你可以说，把每个人员要测试的内容划分清晰就不会重叠了。做为一个系统的各个功能模块，他们之间肯定存在必然的联系。有可能A人员在测试时会涉及到B人员测试的功能，并且发现了问题，不管是告诉B缺陷还是A人员直接提交缺陷（当然，你也可以装作没看到，等着B去发现），这都算不可避免的重叠。

当然，划分更清晰的任务有效的降低重叠度。同步也降低了发现缺陷的数量，提高项目风险。除非投入更多的时间测试。这之间的关系，需要测试管理者认真去权衡。

在项目不紧急测试时间充分的情况下，可以投入更少的人员，延长测试时间发现更多的缺陷。在项目紧急的情况下，需要投入更多的人员测试，以便尽快的发现更多的缺陷。在项目质量要求很高的情况下需要投入更多的人员与时间进行测试。在测试时间少，项目质量要求不高的情况下，可以投入较少的人员与时间进行测试。

原始封面

软件测试流程

Tue, 17 Jun 2025 17:29:15 +0800

如果想让测试在公司的项目中发挥出它最大的价值，并不是招两个测试技术高手，或引入几个测试技术，而是测试技术对项目流程的渗透，以及测试流程的改进与完善。虽然，当然测试行业前景乐观，许多中小企业也都在引入测试，但一百个公司就有一百种测试，每个公司对测试的看法不同，公司对测试的定位也不完全一样。

#### 简陋的测试流程

先说我入职的第一个家公司，我是第一个入职的专职测试人员，相信一两个测试的公司还是不少的，入职后各种项目都在进行当中，上面给我的定位是并没完全融入到项目中去。而通过指派任务的方式。

下面是简陋的流程图：

需求分析与架构设计：

我们做的是某一移动公司内部使用的项目，需求分析与架构全部由项目经理完成，之后由项目经理给具体某个开发人员分配任务，具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高，他既然担任了需求分析师，又担任架构师的角色。

程序员编码：

因为我们开发语言用的是JAVA 语言，IDE用MyEclipse中自带的CVS版本管理工具，开发人员完成代码后，提交到版本库中。

测试：

我入职后的第一个任务是搭建缺陷管理工具，禅道项目管理，通过推广对发现的问题进行跟踪。后来正明效果并不好，因为对于一个六七人的开发团队项目，开发人员更喜欢测试人员能当面反馈，这样更能提高效率。对一个小 bug 通过当面交流的方式就可以将问题修复。

对于当时的环境，并没有测试环境。开发人员在本机上将项目进行部署运行。测试人员通过局域网访问开发人员的机子进行测试。或在测试人员本机上进行部署测试。这也是一个致命的缺点。因为开发人员测试人员使用的电脑存在太多不稳定因素，这些都会造成问题的出现，有时候难以判定是系统问题还是环境问题。

上线：

经过测试人员测试通过后，开发人员部署上线。

A程序员流程

你会发现在流程图中，A程序员是先发上线之后，再进行测试。这是我们一个面向大众用户的网站，上面给于测试人员的定位是测试兼用户体验，测试将发现的bug和体验问题提交到缺陷管理系统，由经理对问题进行分析，指派开发人员解决。定期对系统进行更新。

流程分析：

这个流程唯一的优点，就是能快速的发现并修复问题。

缺点就非常多了，相信许多小软件公司也有类似的流程。

这个流程中，项目经理是核心，项目经理也确实是有多年开发与项目经验的牛人，他喜欢不定期分享上些前沿的技术。

对于测试来说，需求很不明确，测试文档与用例也是可有可无的产物，没有需求文档，或非常简陋，根据需求文档根本无法编写用例。我只能收集一些通用的测试用例，如登录、文件上传下载、列表翻页、日期选择、输入框验证、搜索等有一些“通用型”用例，以便在测试过程中做参考。功能测试的多了，拿到一个功能，测试思路也就出来了。

#### 规范的测试流程 ----

放弃上份悠闲的工作，感谢那个带我入行公司，我想了解真正的测试在公作中如何进行的。所以，来到了现在这家公司。我很欣喜的是这测试有自己的团队，专业（对当时的我来说）的流程，以及与开发等同的地位。

现在的测试流程：

需求分析：

需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。

需求评审：

这里会叫上所有参与项目人员进行，开发人员、测试人员、QA人员。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责人也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人，所以也需要了解需求

开发人员编写排期：

开发人员需要根据需求功能点进行排期。然后将开计划转交给测试人员。

测试计划排期：

测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。

编写测试用例：

根据详细的需求分档，开始进行用例的编写。

用例评审：

在用例进行评审期间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。

然后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进行把握等等。

提交基线：

开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。

具体测试流程：

开发人员对于基到测试线的功能进行测式，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮基线。

测试人员完成第一轮测试后，需要写测试结论，发到相关人员。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。

测试通过：

经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。

验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求会更高，除了关心功能，还需要关心整体流程与质量。

流程分析：

对于刚接触这个流程的我来说，这个流程是规范的，测试真正融入了整个流程，而且还担任了很重的角色，从而也有效的保证了软件产品的整体质量。

软件测试人员定位

Tue, 17 Jun 2025 17:29:15 +0800

工作已将近三年了，虽然这三个年头里我都在积极的学习着与测试相关的技术；但是能沉淀的东西很少。相信测试同学都有类似的感觉。

不要为了测试而测试

前几天做一个测试的PPT，就是讲项目中要用到的测试技术，总结了半天其实实际的产品中没用到什么技术含量的技能，熟悉需求，并转化成用例，待项目上线后验证功能就 OK了；对一个自身质量要求不高的项目，我们有时候为了体现自己价值，非要在一些不痛不养的问题上用力过猛。

举个不恰当例子，某钢琴高手开了一个补习班教钢琴，家长送来一孩子目的只是让孩子学学钢琴；钢琴高手为了体验自己的价值（牛B），硬是按照贝多芬的标准去培养，孩子弹不会《XX交响曲》不让孩子走。先不说孩子有没有贝多芬的钢琴天资，也许孩子压根就不想成为贝多芬。

当然了，如果你办的是“中国音乐家钢琴协会”，你有责任要求会员达到国际超一流水平，为国家和个人赢得荣誉。

有时候不要为了测试去测试，或为了体现自己的价值去做一些对整个项目贡献不大的事儿。当然，我在这里不是让测试人员放弃自己的原则。要知道不管是产品、开发、测试都是围绕着产品的发展贡献。

为贡献产品的发展测试远比为了测试了测试所带来的价值大得多；所以站在产品的发展上去看待测试工作更能体现自己的价值。

记得去年的总结自己对测试流程的理解。随着工作年龄的加长对这些问题也有进一步的看法；所以，再拿来炒一炒，希望能炒出新的味道。

没有最好的开发测试流程，只有最适合项目的开发测试的流程；

去年的一篇说软件测试流程，严格规范的测试流程一定比没流程好，敏捷的流程一定比传统的瀑布流程先进。这个观点没有大的错误，但是我们忽略了所做的产品这个“对象”；忽略了产品的特点与阶段。

例如两三个开发合伙开发一个项目（或产品），这时你让他们建立一套规范的流程，按流程实施，显然是不现实，我想摆在他们面前最主要的问题是，如何快速的把客户需要的功能开发出来换成money ，维持生计以及公司运作。

例如一个各种功能已经成熟的项目，有着庞大的用户群，以维护为主的更新，它的版本功能的上线必须要建立严格的发布流程，经过充分的测试才能上线；用户群越大，暴露的问题越多，问题带来的影响也会越大。

同样是一个Web产品，笔者目前所做的项目流程完全不是这样；我们的发布流程很简单，测试流程也很简单，不去写的规范又复杂的测试用例，放弃了使用缺陷管理工具来反馈问题；

沟通变得尤为重要；我不否认这样做会给产品带来了一定的风险；对于严重的问题，我们可以通过快速的版本回滚，对于轻微的问题，我们很快会在下个版本迭代中修复。是不是有点敏捷的味道在里面。

为什么会这样？因为这个产品属于前期开发阶段，很多功能还没上线。整个团队都在贡献着产品的发展；需要快速的将需求转化成功能给用户使用。

所以，没有最好的开发测试流程，只有最适合项目与阶段的开发测试的流程。

#### 产品质量与用户容忍度 ----

之前看过不少人讨论到底需不需要测试人员；我想说测试人员N年后不管是被重视了还是被淘汰了“测试的行为”永远不会消失；因为没有质量的产品基本上等于没有价值（也就是说没存在的意义），至于对产品质量的要求是由用户容忍度决定的。

Facebook 没有测试人员！但是测试行为一直都在。开发找需求，开发、自测、发布，获得用户反馈，决定功能下线还是上新的功能—相当于一条龙的服务。因为用户的容忍度允许他这么做。

微软不能这么干，修复一个 Windows 的 bug 成本很高，而且用户是花钱买的，也许用户是用来创造价值的（办室、存储、管理），也许一个文件丢失，系统崩溃会给用户带来巨大损失；所以，微软需要很多的测试员。

拿修复成本与用户容忍度做标准，Web 产品优于客户端产品；在 Web 产品中也要分行业；用户对银行系统、火车票、购物网站的容忍度显然要低一些，反过来说也就是对产品的质量要求更高，因为与钱挂钩。就算同一个产品，会员与免费用户的容忍度也是不一样的；因为会员用户有权得到更好质量与服务。

所以，关注分析用户的容忍度的测试才不会把自己变得格格不入。

#### 提升自己的贡献 ----

前面的东西貌似都在“弱化”测试存在的价值；俺本来就不被重视，所以俺就需要更加认真和努力找问题来提升自己存在的价值，你现在说，有些产品不需要太指着的去测试；那你说俺还能干啥？

当我们把测试看成是为开发和产品服务时，也许情况会完全不一样。我们可以提供哪些服务？

用测试发现产品的不可以测试性

前面已经提到队团不管是否有测试人员，但测试行为一定会存在；如果一个产品都不可测试，如何去发现并修复bug ，如何去维护与扩展？尤其对于web产品来讲，不可维护与扩展的产品无疑是致命的。（可以通过项目重构再解决）

建立产品质量的评估方法

为项目团队提供每个版本的bug趋势分析数据，让项目中的每个人都了解项目当前的状态

通过分析bug数据来建立或完善各种 Checklist，帮助项目团队更好的完成需求评审、设计评审以及代码评审，减少bug出现的机会。同时，可以定期将多个项目的Checklist进行合并，使单个项目的经验可以通过Test Team快速的流动起来，及时的作用于其他项目

主动为Architect Team提供每个项目的性能测试数据，帮助他们获取更多的实际项目信息，减少踏入“陷阱”的几率

建立可持续运行的测试框架

建立自动化测试测试框架；构建持续集成，使版本的迭代与更新得到快速的反馈。

建立关注开发质量的开发文化

没有测试人员自测节省人力的了，尤其在单元测试层面。产品的质量应该由开发与测试共同承担。（现实中的责任到人，让团队很难形成这种文化）

原始封面