有效的单元测试.ppt

单元测试培训
主讲人：梁之刚

单元测试培训内容
1. 如何进行单元测试
2. 如何从客户的角度测试软件
3. 测试经验分享
4. 测试时间不够如何测试

如何进行单元测试
1. 为什么要进行单元测试
（1）、单元测试是程序员的基本职责，也是程序员的基本职
业素质能力，必须对自己编写的代码认真负责，能力的高
低直接影响到程序员的工作效率与软件质量
（2）、在编码的过程中进行单元测试花费是最小的，而回报
却特别的优厚。在编码中考虑测试问题，得到的将是更优
质的代码。因为这时候对代码做什么最清楚，如果一直等
到某个模块崩溃了，您可能忘记了代码是怎样工作的了，
那时即使在强大的工作压力下，也要重新把它弄清楚，这
又要花费许多时间。往往更正的不那么彻底，可能更加的
脆弱！

2、什么是合格的代码
合格的代码具有正确性、清晰性、规范性、
一致性、高效性等性质（根据优先级别排序）
（1）、正确性是指代码逻辑必须正确，能够实现预期的功
能
（2）、清晰性是指代码必须简明、易懂，注释准确没有歧
义
（3）、规范性是指代码必须符合企业或部门所定义的共同
规范包括命名规则，代码风格等等
（4）、一致性是指代码必须在命名上（如相同功能的变量
尽量采用相同的提示符）、风格上都保持统一
（5）、高效性是指代码不但要满足以上性质，而且要尽可
能降低代码的执行时间

3、单元测试的步骤
单元测试工作主要分为人工静态检查和动态执行跟
踪两个步骤
（1）、人工静态检查是测试的第一步，这个阶段主要是保
证代码算法的逻辑正确性（尽量通过人工检查发现代码
的逻辑错误）、清晰性、规范性、一致性、算法高效性。
并尽可能的发现程序中没有发现的错误
（2）、通过设计测试用例，执行待测程序来跟踪比较实际
的结果与预期的结果来发现错误。经验表明，使用人工
静态检查法能够有效的发现30%~70%的逻辑设计和编码
错误。但代码中仍然会有大量的隐性错误无法通过视觉
检查发现，必须通过跟踪调试法细心分析才能够捕捉到。
所以，动态跟踪调试法也成了单元测试的重点与难点

4、人工静态检查
通常人工检查执行以下项目的活动
（1）、检查算法的逻辑正确性：确定所编写的代码算法、数
据结构定义（如队列、堆栈等）是否实现了模块或方法所
要求的功能
（2）、模块接口正确性的检查：确定形式参数个数、数据类
型、顺序是否正确；确定返回值类型及返回值的正确性
（3）、输入参数有没有做正确性检查：如果没有做正确性检
查，确定该参数是否的确无需做参数正确性的检查，否则
请加上参数的正确性检查。经验表明：缺少参数检查的代
码是造成软件系统不稳定的主要原因之一

（4）、调用其他方法接口的正确性；检查实参类型的正确与
否、传入的参数值正确与否，个数正确与否，特别是具有
多态的方法。返回值正确与否，有没有误解返回值所表示
的意思。如果被调用方法出现异常或错误程序应该给予反
馈，并添加适当的出错处理代码
（5）、出错处理：模块代码要求能预见出错的条件，并设置
适当的出错处理，一旦程序出错时，能对出错做重新安排，
保证其逻辑的正确性这种出错处理应当是模块功能的一部
分。出现下列情形之一的，说明模块的错误处理功能还有
错误或缺陷：出错的描述难以理解；出错的描述不足以对
错误定位，不足以确定出错的原因；显示的错误信息与实
际的错误原因不符；对错误条件的处理不正确；对错误处
理之前，错误条件已经引起系统的干预等

（6）、保证表达式、SQL语句的正确性：检查所编写的SQL语句
的语法、逻辑的正确性，对表达式应当保证不含二义性，
对于容易产生歧义的表达式或运算符优先级（如：《、
=、》、&&、||、++、--等）可以采用括号“（）”运算符
避免二义性，既能保证代码正确可靠，又可以提高代码的
可读性
（7）、检查常量或全局变量的使用的正确性；确定所使用的常
量或者全局变量的取值和数值、数据类型；保证常量每次
引用同它的取值、数值和类型的一致性
（8）、表示符定义规范的一致性：保证变量命名能够见名知意，
并且简洁但不宜过长或过短、规范、容易记忆、最好能够
拼读。并尽量保证用相同的表示符代表相同的功能，不要
将不同的功能用相同的表示符表示

（9）、程序风格的一致性、规范性：代码必须符合企业的规
范，保证所有成员的代码风格一致、规范、工整。例如对
数组的循环，不要一会采用下标变量从下到上的方式（如：
for(I=0;I++；I<10) ）一会又采用从上到下的方式（如：
for(I=10;I--；I>0) ）,应尽量采用统一的方式。
（10）、检查程序中使用到的神秘数字是否采用了表示符定义：
神秘的数字包括各种常数、数组的大小、字符位置、变换
因子以及以及程序中出现的其他文字形式写出的数值。在
程序的源代码中，一个具有原本形式的数对其本身的重要
性或作用没提供任何指示性信息，它们也导致程序难以理
解和修改。对于这类神秘数字必须采用相应的标量来表示；
如果该数字在整个系统中都可能用到，务必将它定义为全
局变量

（11）、检查代码是否可以优化、算法效率是否可以提高：如
SQL语句是否可以优化，是否可以用一条SQL语句代替程序
中多条SQL语句的功能，循环是否必要，循环中的语句是否
可以抽出到循环之外等
（12）、检查你的程序是否清晰简洁容易理解：注意冗长的程
序并不一定不是清晰的
（13）、检查方法内部的注释是否完整；是否清晰简洁；是否
正确的反映了代码的功能，错误的注释比没有注释更糟糕；
是否做了多余的注释；对于简洁的一看就懂的代码没有必
要注释

（14）、检查注释文档是否完整；对包、类、属性、方法功
能、参数、返回值的注释是否正确且容易理解；是否会
落了或多了某个参数的注释，参数类型是否正确，参数
的限定值是否正确。特别是对于形式参数与返回值中关
于神秘数值的注释，如：类型参数，应该指出 1.代表
什么，2.代表什么，3.代表什么等。对于返回结果集
（Result Set)的注释，应该注释结果集中包含哪些字
段及字段类型、字段顺序等

5、动态执行跟踪
对于单元测试来说主要采用白盒测试法对每个模块
的内部作跟踪检查测试。对于单元白盒测试应该对程序
模块进行如下检查：
1.对模块内所有的独立的执行路径至少测试一次
2.对所有的逻辑判定，取“真”与“假”的两种情况
至少执行一次
3.在循环的边界和运行界限内执行循环体
4.测试内部数据的有效性等等

单元白盒跟踪测试，通常需要做如下三项工作：
1. 设计测试用例
2. 设计测试类模块
3. 跟踪调试

测试用例的设计
设计测试用例的思路
可以从以下五方面考虑：
1. 为系统运行起来而设计测试用例
单元测试方案中第一个测试用例最有可能用最简单
的方法使被测单元运行起来。当第一个测试用例可以
正常运行，至少知道测试环境和被测单元是可用的
2.为正向测试而设计测试用例
测试用例的设计者应当通读设计文档，每一个测试
用例，就是针对测试说明书中的一项或者多项内容来设
计的
正向测试的测试用例是用来验证设计说明书中的功
能项或者明确的性能指标能否实现

3. 为逆向测试而设计的测试用例
逆向测试的测试用例是用来验证被测的软件单元有
没有做它不应该做的事情
4.满足特殊需求而设计测试用例
从系统性能、安全性、保密性的角度来设计测试用
例也是十分必要的，尤其对于安全和保密性要求很高的
系统，在测试方案中，特别表明用来进行安全及保密验
证的测试用例是很有好处的

5. 为漏测语句而设计的测试用例
设计好的测试用例可以保证较高的代码覆盖率
不幸的是，在被测代码中有很复杂的判断条件、循
环以及分支语句，因此在执行测试用例的过程中，覆盖
率的目标有可能无法达到。这种情况下，有必要分析其
原因：不可能的路径或条件，不可达的或者冗余的代码，
不充分的测试用例等等原因。为了达到特定的测试覆盖
率目标，可能需要补充一些测试用例

测试用例的设计—总结
 为系统运行起来而设计的测试用例
 为正向测试而设计的测试用例
 为逆向测试而设计的测试用例
 为满足特殊需求而设计的测试用例
 为漏测语句而设计的测试用例
通过以上五个方面考虑设计出来的测试用
例集，大多数情况下，对于一个单元，能够提
供比较全面的测试

测试用例设计方
法

测试用例的设计方法---规格导出法
规范导出的测试是根据相关的规范描述来设计测试用例
每一个测试用例测试一个或者多个规范陈述语句
举例：求实数的平方根
功能描述：当输入0或比0大的数时，返回其正的平方根；
输入小于0的数时，显示错误信息“平方根非法－
输入<0”，并返回0；
输入：实数
输出：实数
这个规范中，可以用2个测试用例来对应：
用例1：输入4，输出2
用例2：输入－10，返回0，输出“平方根非法－输入<0”

测试用例的设计方法---等价类划分
把所以可能的输入数据，划分成若干部分，然后从
每一部分中选取少数有代表性的数据作为测试用例。对
每一个划分中的所有输入，被测单元有相同的行为
等价类分为两种情况：
 有效等价类：对应程序的规格说明来说是合理的数据
数据构成的集合，利用有效等价类可检验程序是否实
现了规定的功能。
 无效等价类：相反，使程序经受意外考验

从划分出来的等价类中设计测试用例：
 为每一个等价类规定一个唯一的编号；
 设计一个新的测试用例，使其尽可能多的覆盖尚
未被覆盖的有效等价类，重复这一步，知道所有
的有效等价类都被覆盖为止；
 设计一个新的测试用例，使其仅覆盖一个尚未被
覆盖的无效等价类，重复这一步，知道所有的无
效等价类都被覆盖为止；

例：输入3个整数作为3边的边长构成三角形，分别计算其
……
用等价类划分法对程序的构成三角形部分进行测试用例设计
分析题目中给出和隐含的条件

 整数
 3个数
 非零
 正数
 应满足两边之和>第三边
 等腰
 等边

只列出有效等价类
输入条件有效等价类编号
输入3个
整数
整数 1
3个数 2
非零数 3
正数 4
一般三角
形
a+b>c 5
b+c>a 6
a+c>b 7
等腰三角
形
a=b 8
b=c 9
c=a 10
等边三角
形
a=b=c 11

覆盖上述有效等价类的用例集
输入条
件
有效等价类编号
输入3
个整数
整数 1
3个数 2
非零数 3
正数 4
一般三
角形
a+b>c 5
b+c>a 6
A+c>b 7
等腰三
角形
a=b 8
b=c 9
c=a 10
等边三
角形
a=b=c 11
(a,b,c) 覆盖有效等价类
编号
(3,4,4) 1-7
(4,4,5) 1-7,8
(4,5,5) 1-7,9
(5,4,5) 1-7,10
(4,4,4) 1-7,11

测试用例的设计方法---边界值分析法
 是等价类划分的补充。长期的经验证明，错误更多
的出现在边界上。
 着重测试输入、输出等价类的边界值，应当选取刚
好等于、刚刚大于、刚刚小于边界的值作为测试数据。
测试用例的设计方法---错误推测法
 基于经验和直觉推测程序中可能存在的错误，从而
有针对性的设计测试用例的方法。可以根据以前产品测
试中经常出现问题的方面针对性的进行。

测试用例的设计方法---状态迁移测试法
 适合于以状态机作为模型或设计为状态机的软件。
测试用例通过能导致状态迁移的事件来测试状态之间的
转换
测试用例的设计方法---因果图法
 适合于描述多种条件的组合、相应产生多个动作的
形式的测试用例设计方法。
 步骤：
 分析规格中哪些是原因，哪些是结果，并对原因和结
果赋予一个标识
 找出原因和结果、原因和原因之间的对应关系
 把因果图转换成判定表
 把判定表中的数据拿出来作为依据，设计测试用例

2. 测试类的设计
一个模块或一个方法（Method）并不是独立的程序
，在考虑测试它时要同时考虑它和外界的联系，用些辅
助模块去模拟与所测模块相联系的其他模块。这些辅助
模块分两种：
（1）.驱动模块（driver）：相当于所测模块的主程序。它
接收测试数据，把这些数据传送给所测模块，最后再输
出实际测试结果
（2）. 桩模块（Stub）：用于代替所测模块调用的子模块
。桩模块可以进行少量的数据操作，不需要把子模块所
有功能都带进来，但不允许什么事情也不做

测试类的设计
 编写桩模块是困难费时的，可以在项目进度管理时
将实际桩模块的代码编写工作安排在被测模块前编写即
可。这样可以提高实际桩模块的测试效率从而有效的保
证产品的质量。
 对于每一个包或子系统我们可以根据所编写的测试
用例来编写一个测试模块来做驱动模块，用于测试包中
所有的待测试模块。而最好不是在每一个类中用一个测
试函数的方法，来测试跟踪类中所有的方法。好处在于
 能够同时测试包中所有的方法或模块，也可以方便的测试跟踪
指定的模块或方法。
 能够联合使用所有测试用例对同一代码执行测试，发现问题

测试类的设计
 便于回归测试，当某个模块修改之后，只要执行测试类就可以
执行所有被测的模块或方法。方便检查跟踪所修改的代码，使修改
引进的错误得以及时发现。
 复用测试方法，使测试单元保持持久性，并可以用既有的测试
来编写相关测试
 将测试代码与产品代码分开，使代码更清晰、简洁；提高测试
代码与被测试代码的可维护性

跟踪调试
跟踪调试不但是深入测试代码的最佳方法，而且也
是程序调试发现错误根源的有力工具。程序员可通过对
程序执行过程中各种状态的判别进行程序错误的识别、
定位、及更正。排错时应该采用的方法策略：
(1)断点设置：断点设置除了根据经验与错误信息来设置外，
还应重点考虑以下几种类型的语句.
1)、函数调用语句。子函数调用的语句是测试重点，
一方面由于在调用子函数可能引起接口引用错误，另一
方面可能是子函数本身的错误
2）、判定转移/循环语句。判定语句常常会由于边界
值与比较优先级等问题引起错误或失效而作出错误的转
移。因此，对于判定转移/循环语句也是一个重要测试
点

跟踪调试
3）、SQL语句。对于数据库的应用程序来说，SQL
语句常常会在模块中占比较重要的业务逻辑，而且比较
复杂。因此，它属于比较容易出现错误的语句
4）、复杂算法段。出错的概率常与算法的复杂度
成正比。所以越复杂的算法越需要做重点跟踪，如递归、
回溯等算法。
（2）、可疑变量查看，在跟踪执行状态下当程序停止在某
条语句时可以查看变量的当前值和对象的当前属性，通
过对这些变量当前值与预期值可以轻松的定位程序根源。

跟踪调试
（3）、SQL语句执行检查，在跟踪执行或运行状态下将疑
似错误的SQL语句打印出来，重新在数据库SQL查询分析
器中跟踪执行可以较高效的检查纠正SQL语句错误
（4）、注意群集现象，经验表明测试后程序中残存的错
误数目与程序中发现的错误数目或检错率成正比。根据
这个规律，应当对错误群集的程序段进行重点测试，以
提高测试投资的效益。如果发现其一段代码似乎比其他
程序模块更多的错误倾向时，应当花费较多的时间和代
价测试这个程序模块

如何从客户的角度测试

如何从客户的角度测试软件
1、提供正确的应用软件
测试工作具有一些不同的方面。一方面就是去验证
最终的产品达到所认可的要求。测试工作要求测试人员
确保所有所要求的功能和特性都已经给出并可用。然后
，确保这些功能和特性以所期望的方式工作。这种测试
方式并没有错，但是你还需要更进一步。

2、试着作为一个用户去打破应用软件
很多开发人员所欠缺的地方是，他们以他们所期望
的用户的反应方式为基础进行测试工作。他们没有进行
足够的思考，离开惯常的途径进行测试。例如，比方说
你有一个Web应用软件，其中有大量的在线处理过程，
如果第一个页面要求输入用户名和密码，那么我一开始
就什么值都不输入，然后看一看会发生什么。我能不能
进入？有没有错误出现？有些时候是不是屏幕会静止不
动？这时，应用软件就该将其视为一个非法的响应并返
回恰当的错误信息。

3、用户会向所有可能位置输入任何值
当我进入应用软件界面时，我会输入各种各样奇怪
的值。如果这里需要输入的是字母，那么我就输入一个
数字，然后我会输入类似于“(*&%$’的特殊字符。很多
次，应用软件都会发生问题。我对所有的区域都做了相
同的测试，如果一个区域包含一个drop-down列表，我
就会试着键入一个值。如果某些区域是事先制定的，我
就会改变他们。如果一些值是数据库的关键字而不能动
，我就会改变他们。我还试着通过在区域中加入页面所
允许的足够多的数字或字符，让他们溢出。然后我就会
点击可选的按钮和链接看一看会发生什么。

3、用户会向所有可能位置输入任何值
同样的，我还试着搞乱所有的预制定区域。因此要
对开发人员说，如果你不希望一个区域被改变，那么你
就不要允许用户将指针放在上面和键入。我向你保证，
如果你将一个区域设置为开放的可以输入，那么就一定
会有某些人在某些时候，出于某种原因试图向其中键入
数值。
用户为什么会向一个需要输入数字的区域键入特殊
字符呢？问题在于他们或许不会有意去这样做，然而，
键入错误进去却随时都会发生。如果你向用户给出一个
数字区域，那么随着时间的过去，错误的键入就会导致
在任何的区域之中输入任何的字符。我认为这样的问题
应该现在就找出来，而不是让一个Web应用软件在用户
手中出问题。

4、用户会尝试逻辑流的所有组合
除了一些简单的编辑性错误之外，还要尝试每一个
逻辑流的组合。当我看到一个Web页面时，我会尝试每
一个超链接看一看结果是什么。开发人员会看着我纳闷
为什么用户会这样做。再说一次，问题是他们可能不是
有意去这么做，然而，你应该设想每一个逻辑组合都可
能会在某个时间被尝试。
5、看一看外观
着眼的最后一件事就是整体的视觉和感觉。试图确
保屏幕有一个漂亮的外观，漂亮的字体，而且他们是协
调一致的。例如，如果你在列表中一些项目的最后放置
一个句号，那么他们都应该带有句号，否则就都没有，
这取决于你的编辑上的习惯。同样，字体也应该保持一
致，如果在一个区域的标题的字体是14，那么他们都应
该是这个大小。这样做都是为了使应用软件看起来具有
专业性。

6、做最坏的准备
在项目团队中，开发人员做出了很好的工作，确保
他们的应用软件以所指定的方式工作。很多情况下，他
们没有从一个客户的角度做出足够的测试工作。他们应
该关注于确保应用软件的坚固可靠。用户在百分之九十
的时间之内，会像你所期望的那样对应用软件进行操作
，然而，剩下的百分之十的时间里，他们就会做一些奇
怪的事情。当发生这样的事情时，你的应用软件就需要
对其妥当并成功地进行处理。你不希望一个很棒的应用
软件在用户第一次输入12位数字的社会保障号码而不是
9位数字时就垮掉。你要确保进行了测试工作保证你的
应用软件如宣传的那样进行工作。还有，尽可能地对意
外因素的组合进行多种测试。你需要确保没有任何的错
误数据或处理流程致使用户得到任何意料之外的系统信
息

测试经验
1、项目测试内容
A、权限测试：各功能的使用权限
B、页面测试：对页面表单填写修改、页面链接、页面文
字、特殊效果进行测试
C、功能测试：以“系统是充满错误的”为思考基点，寻
找各种测试方法，寻找错误点，直到无法发现为止

测试经验
2、集成测试内容
A、集成测试：以“系统是正常运行的”为思考基点，以
正确的流程运行系统，直至发现错误为止
以正确的数据运行整个流程，验证数据传输情况。
B、集成测试步骤
（1）以一个正确的数据，完成一个尽量长的正确的流程
（2）验证
（3）测试异常的流程

测试经验
3、功能测试案例编写方案
方案一：按照测试内容编写，第一部分为权限测试、第二部
分为页面测试、第三部分为功能模块测试（适用于完整
系统的测试，可以通过第一、二部分快速的统揽全局）
方案二：按照功能模块编写，每部分包括权限测试、页面测
试、功能模块测试（适用于相对独立的功能模块测试，
接收一个模块，测试一个模块）

测试经验
4、功能测试案例编写中对可能出现的错误预测
A、页面部分
（1）页面：每一个功能包含的页面
（2）页面元素：页面中包含的内容，包括文字、图片
、按钮、链接以及其他输入框、列表框、单选复选框等
等
（3）页面元素容错性：对页面元素的检查，部分容错
性在页面中进行，部分容错性涉及到后台
（4）页面特效：页面中实现的特殊效果
1 、页面清单是否完整（是否已经将所需要的页面
全部都列出来了）
2 、页面是否显示（页面是否存在）
3 、页面是否显示正确

测试经验
4、页面元素清单（为实现功能，是否将所需要的元
素全部都列出来了）
5 、页面元素是否显示（元素是否存在）
6 、页面元素是否显示正确（主要针对文字）
7 、页面元素的外形、摆放位置
8 、页面元素基本功能是否实现
9 、页面元素的容错性列表
10、页面元素的容错性是否存在
11、页面元素的容错性是否正确
12、页面特殊效果列表
13、页面特殊效果是否显示
14、页面特殊效果是否正确
15、其他错误

测试经验
B、功能部分
（1）数据初始化：从何处取得数据
（2）数据处理：对数据有何操作
（3）数据保存：将数据保存在何处
（4）对其他功能影响：由那些功能要调用处理后的
数据
1、数据初始化是否执行
2、数据初始化是否正确
3、数据处理功能是否执行
4、数据处理功能是否正确
5、数据保存是否执行

测试经验
6、数据保存是否正确
7、是否对其他功能有影响
8、造成的影响是否正确
9、其他错误
C、提示信息
（1）成功失败提示
（2）操作结果提示
（3）确认提示
（4）危险操作、重要操作提示
（5）返回页面：提示后显示的页面

测试经验
D、容错性
（1）非空
（2）唯一行
（3）字长
（4）格式：数字、邮政编码、金额、电话、电子邮
件
（5）特殊字符：（对数据库）英文单、双引号，&
符号
E、权限部分
（1）功能权限：指定用户可以使用哪些功能，不能
使用哪些功能
（2）数据权限：指定用户可以处理哪些数据，不可
以处理哪些数据。可以合并到功能测试
（3）操作权限：在逻辑关系上，操作前后顺序、数
据处理情况。可以合并到功能测试

测试经验
（4）权限变化：可以合并到功能测试
1、功能权限是否存在
2、功能权限是否正确
3、数据权限是否存在
4、数据权限是否正确
5、操作权限是否存在
6、操作权限是否正确
7、引起权限变化的功能列表
8、功能权限变化还是数据权限变化，或两者
兼有
9、权限变化是否正确

测试经验
F、键盘操作
（1）Tab键的使用
（2）上下方向键的使用
（3）Enter键的使用
（4）系统设定快捷键的使用

测试经验
G、其他
（1）完整性：是否是一个整体，没有功能缺损
（2）易用性：使用是否方便
（3）一致性：类似的问题用类似的方法处理
（4）提示信息：提示信息是否完整、正确、详细
（5）帮助信息：是否提供帮助信息，帮助信息的表
现形式（页面文字、提示信息、帮助文件），帮助信息是
否正确、详细兼容性包括操作系统兼容和应用软件兼容，
可能还包括硬件兼容可扩展性，是否有升级的余地，是否
保留了接口稳定性？运行所需的软硬件配置，占用资源情
况，出现问题时的容错性，对数据的保护运行速度运行的
快慢，带宽占用情况

测试经验
5、功能测试
列出功能模块的所有功能，进行排列组合，测试所有情况
如：某一功能模块具有最基本的增删改查功能，则需要进
行一下测试
单项功能测试（增加、修改、查询、删除）
增加——>增加——>增加（连续增加测试）
增加——>删除
增加——>删除——>增加（新增加内容与删除内容一
致）
增加——>修改——>删除
修改——>修改——>修改（连续修改测试）
修改——>增加（新增加的内容与修改前内容一致）
修改——>删除

测试经验
5、功能测试
修改——>删除——>增加（新增加的内容与删
除内容一致）
删除——>删除——>删除（连续删除测试）
查询功能分为两种情况，验证操作结果：
一是打开页面时自动显示结果，则不特别强调；
二是需要手工操作进行查询，则每次在其他功能完成
后进行。

时间不够如何测试
如果测试时间不够，可优先考虑以下部分
1、对项目目标的达成最重要的的功能；
2、用户最常见的功能；
3、对系统安全性影响最大的功能；
4、和“钱”最有关系的功能；
5、软件中对用户来说最重要的部分；
6、软件中在开发过程早期就可以测试的部分；
7、代码最复杂的部分；
8、开发得最匆忙的部分；
9、前一版本或类似项目中造成问题的部分或相关部分
；

时间不够如何测试
如果测试时间不够，可优先考虑以下部分
10、类似项目中花费大量维护费用的部分或相关部分
；
11、需求或设计中不清晰的部分；
12、开发人员认为最可能有问题的部分；
13、一旦有问题会造成客户最大损失的部分；
14、一旦有问题会造成最大维护成本的部分；
15、风险/时间比最大的部分。

应注意及避免的问题
1、代码规范
问题：客户曾发现系统能够实现功能要求，却代码编
写未按原定要求编写的情况
建议：项目开始前对新进组的开发人员做好培训。
2、测试流程规范
问题：测试流程不规范，内部基本只有一次测试便
交付
建议：需按公司要求，尽量在开发前充分了解需求
，学习设计文档，编写测试用例，再进行开发
3、测试用例过于简单
问题：单元测试只进行正例测试，未考虑各种反例
情况
建议：参考测试组的通用测试库，丰富测试用例

应注意及避免的问题
4、回归测试
问题：多次发现经修改某些功能后会影响到原来成功
的功能出现错误
建议：修改Issue后需对原系统走一遍基本的测试用
例
5、版本交付
问题：曾多次发现文件发漏的情况
建议：需对测试环境及VSS更新就行限制跟踪

单元测试注意点
1、权限验证
功能权限验证：指定用户能使用哪些功能，不能使用
哪些功能（需关注模块间的切换）
数据权限验证：指定用户可以处理哪些数据，不能处
理哪些数据（需关注模块间的数据引用）
操作权限验证：指定用户逻辑关系上操作前后顺序，
数据处理情况

单元测试注意点
2、错误提示验证
测试用例中需要对应的用例测试系统中各种提示信息
3、重复操作验证
单元测试时除按系统流程执行外，还需注意一下特殊
的情况的用例，如多部操作后，再试试原来功能是否能
用

有效的单元测试.ppt

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a 有效的单元测试.ppt

Semelhante a 有效的单元测试.ppt (20)

有效的单元测试.ppt