我经常考虑作为测试人员职责到底多宽，经过看一些资料，还有我自己的体会对软件测试的职责作了下总结：

¶ 在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。

¶ 编写合理的测试计划，并与项目整体计划有机地整合在一起。

¶ 编写覆盖率高的测试用例。

¶ 针对测试需求进行相关测试技术的研究。

¶ 认真仔细地实施测试工作。

¶ 进行缺陷跟踪与分析。

¶ 提交测试分析报告。

当然具体到某个角色的职责又有所不同，一般测试组内有测试经理、测试员两个角色。

Y 测试经理:组建测试组;协调测试组内部的沟通；代表测试组与其他角色组进行沟通（其他角色是指项目经理、开发人员）；编写测试计划；测试报告分析。
Y 测试员：编写测试用例（有很多情况测试用例是由测试经理来编写的）；实施测试用例；执行测试。

软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

用户认证安全的测试要考虑问题：

1.         明确区分系统中不同用户权限

2.         系统中会不会出现用户冲突

3.         系统会不会因用户的权限的改变造成混乱

4.         用户登陆密码是否是可见、可复制

5.         是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）

6.         用户推出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统

系统网络安全的测试要考虑问题

1.         测试采取的防护措施是否正确装配好，有关系统的补丁是否打上

2.         模拟非授权攻击，看防护系统是否坚固

3.         采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ）

4.         采用各种木马检查工具检查系统木马情况

5.         采用各种防外挂工具检查系统各组程序的客外挂漏洞

数据库安全考虑问题：

1.         系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）

2.         系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）

3.         系统数据可管理性

4.         系统数据的独立性

5.         系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

测试的目的是显示存在错误，而调试的目的是发现错误或导致程序失效的错误原因，并修改程序以修正错误。调试是测试之后的活动。 [Beizer, 1984] 认为，测试和调试在目标、方法和思路上都有所不同，如下：

1 、测试从一个已知的条件开始，使用预先定义的过程，有预知的结果。调试从一个未知的条件开始，结束的过程不可预计。

2 、测试过程可以实现设计，进度可实现确定。调试不能描述过程或持续时间。

3 、测试是显示错误的行为。调试是推理的过程。

4 、测试显示开发人员的错误。调试是开发人员为自己辩护。

5 、测试能预期和可控。调试需要想象，经验和思考。

6 、测试能在没有详细设计的情况下完成。没有详细设计的信息调试不可能进行。

7 、测试能由非开发人员进行。调试必须由开发人员进行。

在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则：
1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。
3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。

很多实时系统的时间依赖性和异步性给测试带来新的困难－－时间！测试用例的设计者考虑的不仅是白盒和黑盒测试用例，而且包括事件处理（如中断处理）、数据的时间序列以及处理数据的任务（进程）的并发性。很多情况下，提供的测试数据有时使得实时系统在某状态下可以正常运行，而同样的数据在系统处于不同状态时有时又会导致错误。

另外，实时系统的软件和硬件之间的密切关系也会导致测试问题，软件测试必须考虑硬件故障对软件处理的影响，这种故障很难实时仿真。由于实时系统的特殊性和复杂性，还没有一个完善的综合性的测试用例设计方法，但是，大致可以分为以下四个步骤：

1 、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例，并在测试时执行每个任务。任务测试能够发现逻辑和功能错误，但是不能发现时间和行为错误。

2 、行为测试。利用 CASE 工具创建软件模型，就可能仿真实时系统，并按照外部事件的序列检查其行为，这些分析活动可作为创建实时系统时设计测试用例的基础。

3 、任务间测试。在隔离了任务内部和系统行为错误以后，测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务，看任务间的同步是否会产生错误。另外，测试通过消息队列和数据存储进行通讯的任务，以发现这些数据存储区区域大小方面的错误。

4 、系统测试。集成软件和硬件，并进行大范围的系统测试，以发现软件 / 硬件接口间的错误。

测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板－我们可以把特定的测试用例方法放置进去的一系列步骤。

人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征：
· 测试开始于模块层，然后 “ 延伸 ” 到整个基于计算机的系统集合中。
· 不同的测试技术适用于不同的时间点。
· 测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。
· 测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。

软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。

任何管理敏感信息或者能够对个人造成不正当伤害的计算机系统都是不正当或非法侵入的目标。侵入包括了范围很广的活动：只是为练习而试图侵入系统的黑客；为了报复而试图攻破系统的有怨言的雇员；还有为了得到非法的利益而试图侵入系统的不诚实的个人。

安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。引用 Beizer 的话来说： “ 系统的安全当然必须能够经受住正面的攻击 —— 但是它也必须能够经受住侧面的和背后的攻击。 ”

在安全测试过程中，测试者扮演着一个试图攻击系统的个人角色。测试者可以尝试去通过外部的手段来获取系统的密码，可以使用可以瓦解任何防守的客户软件来攻击系统；可以把系统 “ 制服 ” ，使得别人无法访问；可以有目的地引发系统错误，期望在系统恢复过程中侵入系统；可以通过浏览非保密的数据，从中找到进入系统的钥匙；等等。

只要有足够的时间和资源，好的安全测试就一定能够最终侵入一个系统。系统设计者的任务就是要把系统设计为想要攻破系统而付出的代价大于攻破系统之后得到的信息的价值。

中层经理人不论是作为一名执行者、还是一名领导者，都必须通过别人来完成任务。要做个“服众”的经理人，应该有意识地提高以下八项能力：

1. 领悟能力
    做任何一件事以前，一定要先弄清楚上司希望你怎么做，然后以此为目标来把握做事的方向，这一点很重要，千万不要一知半解就开始埋头苦干，到头来力没少出、活没少干，但结果是事倍功半，甚至前功尽弃。要清楚悟透一件事，胜过草率做十件事，并且会事半功倍。

2. 计划能力
    执行任何任务都要制定计划，把各项任务按照轻、重、缓、急列出计划表，一一分配部属来承担，自己看头看尾即可。把眼光放在部门未来的发展上，不断理清明天、后天、下周、下月，甚至明年的计划上。在计划的实施及检讨时，要预先掌握关键性问题，不能因琐碎的工作，而影响了应该做的重要工作。要清楚做好20%的重要工作，等于创造80%的业绩。

3. 指挥能力
    无论计划如何周到，如果不能有效地加以执行，仍然无法产生预期的效果，为了使部属有共同的方向可以执行制定的计划，适当的指挥是有必要的。
    指挥部属，首先要考量工作分配，要检测部属与工作的对应关系，也要考虑指挥的方式，语气不好或是目标不明确，都是不好的指挥。而好的指挥可以激发部属的意愿，而且能够提升其责任感与使命感。要清楚指挥的最高艺术，是部属能够自我指挥。

4. 控制能力
    控制就是追踪考核，确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉，然而企业的经营有其十分现实的一面，有些事情不及时加以控制，就会给企业造成直接与间接的损失。但是，控制若是操之过急或是控制力度不足，同样会产生反作用：控制过严使部属口服心不服，控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制，就是让部属通过目标管理方式实现自我控制。

5. 协调能力
    任何工作，如能照上述所说的要求，制定完善的计划、再下达适当的命令、采取必要的控制，工作理应顺利完成，但事实上，主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调，也包括与外部客户、关系单位、竞争对手之间的利益协调，任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。

6. 授权能力
    任何人的能力都是有限的，作为高级经理人不能象业务员那样事事亲历亲为，而要明确自己的职责就是培养下属共同成长，给自己机会，更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子，也是延伸自己智力和能力的载体，要赋予下属责、权、利，下属才会有做事的责任感和成就感，要清楚一个部门的人琢磨事，肯定胜过自己一个脑袋琢磨事，这样下属得到了激励，你自己又可以放开手脚做重要的事，何乐而不为。切记成就下属，就是成就自己。

7. 判断能力
    判断对于一个经理人来说非常重要，企业经营错综复杂，常常需要主管去了解事情的来龙去脉因果关系，从而找到问题的真正症结所在，并提出解决方案。这就要求洞察先机，未雨绸缪。要清楚这样才能化危机为转机，最后变成良机。

8. 创新能力
    创新是衡量一个人、一个企业是否有核心竞争能力的重要标志，要提高执行力，除了要具备以上这些能力外，更重要的还要时时、事事都有强烈的创新意识，这就需要不断地学习，而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的，它要求大家把工作的过程本身当作一个系统的学习过程，不断地从工作中发现问题、研究问题、解决问题。解决问题的过程，也就是向创新迈进的过程。因此，我们做任何一件事都可以认真想一想，有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限，唯有创新，才能生存。

领导力更需提升
    一个部门经理提高完成任务执行力的过程，其实也就是提高自身对部门员工领导力的过程。因为要提高执行部门的执行力，不是光靠经理一人所能完成的，而是要靠带领部门所有员工的共同努力才能完成的。
   说到底，对上提高执行力、对下就要提升领导力。
    那么，怎样才能提升领导力呢？除了提高以上八项能力之外，还有最重要的两点：
1. 学会用老板眼光看企业。
    在老板看来，管理很简单，就是两件事：一是扩大业务范围，增加业务收人；另一件事就是降低管理成本，控制运作费用。其实这两件事，最终是一件事，收入减去成本，减去费用，就是利润。所以归根到底老板是看利润的，利润要从管理中来。
2. 从被领导中学习领导。
    在领导人看来，领导也很简单，就是两件事：一是用人，内圈用德、外圈用才，用人所长、容人所短；二是激励，解人之难、记人之功，通过正面激励，引导下属往前跑，通过负面激励，推着下属往前走。要知道，任何领导都是从做下属开始的，谁都不可能一步登天当领导。在每个人的成长过程中，你会经历大大小小许多领导，只要你用心学习，不管是好领导、还是坏领导，你都可以从正反两方面学到经验和教训，这对你将来当好领导是十分珍贵的。

除了以上各种能力外，测试技能不能丢，通过技术服众可以保证管理的有效执行。

一、测试计划：
对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。
二、测试方案：
描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。
三、测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。
四、测试方案是技术层面的文档，从技术的角度度一次测试活动进行规划。
五、测试计划要明确的内容：
1、明确测试组织的组织形式
1测试组织和其他部门关系，责任划分。
2测试组织内的机构和责任安排。
2、明确测试的测试对象（明确测试项，用于后面划分任务,估计工作量等）
3、完成测试的需求跟踪
4、明确测试中需要遵守的原则
1测试通过/失败标准
2测试挂起和回复的必要条件
5、明确测试工作任务分配是测试计划的核心
1、进行测试任务划分
2、进行测试工作量估计
3、人员资源和物资源分配
4、明确任务的时间和进度安排
5、风险的估计和规避措施
6、明确测试结束后应交付的测试工作产品
六、测试方案的具体内容：
1、明确策略
2、细化测试特性（形成测试子项）
3、测试用例的规划
4、测试环境的规划
5、自动化测试框架的设计
6、测试工具的设计和选择
七、测试方案需要在测试计划的指导下进行，测试计划提出“做啥”，而测试方案明确“咋做”。
八、详见测试计划模板和测试方案模板。

1、安装SQL, 登录用户名一定要SA
2、设置MS-SQL的数据库连接：对数据库的“客户端网络实用工具”进行配置。选择协议Named Pipes与TCP/IP，别名设置最好选择本机计算机名。对数据库的安全性设置--身份验证，设置为SQL Server和WINDOWS。
3、在服务器上安装TD，安装过程选择SQL数据库
4、设置与SQL连接在Site Administrator--DB Servers中，先新建一个数据库，Server Alias为你的计算机名，DB user 为SA ,DB Passwoed为SQL的SA密码一样建立成功以后，Ping一下，通过则认为数据库与TD建立连接成功
5、项目移植将ACCESS中的项目在TD中建立，数据库选择SQL；之后进入SQL数据库，在相应数据库项目单击右键选择“所有任务—导入数据”，进入导入数据向导，数据源选择“ODBC数据源”，用户、系统DNS新建一个“文件数据源”，按照向导提示一步一步做下去，这样就将ACCESS中的数据移植到SQL中
6、移植完成登录到TD，就可以看到移植后的项目数据，移植成功

注：从ACCESS移植到SQL，中间也许会出现问题，造成数据丢失（是不可避免的）

在SqlServer数据库中插入10万条数据:

declare @i int
set @i=0

while  (@i<100000)
begin

   insert into table values(字段1,字段2……)
   set @i=@i+1
end

在TD的查询条件中可以使用以下通配符：

* 星号 代表任意字符（可以是单个，也可以是多个）
   如 abc    xabcd   xxabcdxx
   查询条件   *abc* 则可以查询出 abc    xabcd   xxabcdxx

_ 下划线 代表占位符（一个下划线占一个字符）
   如 abc    xabcd   xxabcdxx
   _abc* 则只能查询出 xabcd 的记录。__abc* 则只能查询出 xxabcdxx的记录
   注意：_下划线要与*星号配合使用才有效。如果只用 _abc_ 查询的话，查询不出任何记录。

[ ] 中括号 代表范围（查询时可模糊配置该字段的取值范围）
   如   a1bcd、a2bc、a3dd 、abcd
    a[1-9]bc* 则查询出的结果为： a1bcd a2bc a3dd 等
注意：_下划线要与*星号配合使用才有效。如果只用 _abc_ 查询的话，查询不出任何记录。

每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的 I/O 操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。

在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。

回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：
· 能够测试软件的所有功能的代表性测试用例。
· 专门针对可能会被修改影响的软件功能的附加测试。
· 针对修改过的软件成分的测试。

在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。

单身的路
是这样的孤单无助
在北京漫步
身边的美女无数
却没有属于我的爱慕
这是什么缘故
不是我没有风度
我常常硬是把不愿过路的大爷也搀过了马路
更不是我没才赋
你瞧瞧我那手指甲的长度
哦!好像找到问题的眉目. 

安全测试（Security test）是指：在测试软件系统中对程序的危险防止和危险处理进行的测试，以验证其是否有效

Ø         部署与基础结构
网络是否提供了安全的通信
部署拓扑结构是否包括内部的防火墙
部署拓扑结构中是否包括远程应用程序服务器
基础结构安全性需求的限制是什么
目标环境支持怎样的信任级别

Ø         输入验证
如何验证输入
是否清楚入口点
是否清楚信任边界
是否验证Web页输入
是否对传递到组件或Web服务的参数进行验证
是否验证从数据库中检索的数据
是否将方法集中起来
是否依赖客户端的验证

Ø         身份验证
l 是否区分公共访问和受限访问
l 是否明确服务帐户要求
l 如何验证调用者身份
l 如何验证数据库的身份
l 是否强制试用帐户管理措施

Ø         授权
l 如何向最终用户授权
l 如何在数据库中授权应用程序
l 如何将访问限定于系统级资源

Ø         配置管理
l 是否支持远程管理
l 是否保证配置存储的安全
l 是否隔离管理员特权

Ø         敏感数据
l 是否存储机密信息
l 如何存储敏感数据
l 是否在网络中传递敏感数据
l 是否记录敏感数据

Ø         会话管理
如何交换会话标识符
是否限制会话生存期
如何确保会话存储状态的安全

Ø         加密
如何使用特定的算法
如何确保加密密钥的安全性

Ø         参数操作
是否验证所有的输入参数
是否在参数过程中传递敏感数据
是否为了安全问题而使用HTTP头数据

Ø         异常管理
是否使用结构化的异常处理
是否向客户端公开了太多的信息

Ø         审核和日志记录
是否明确了要审核的活动
是否考虑如何流动原始调用这身份

Ø         应用及传输安全
WEB应用系统的安全性从使用角度可以分为应用级的安全与传输级的安全，安全性测试也可以从这两方面入手。
应用级的安全测试的主要目的是查找Web系统自身程序设计中存在的安全隐患，主要测试区域如下。
l 注册与登陆：现在的Web应用系统基本采用先注册，后登录的方式。
A.必须测试有效和无效的用户名和密码
B.要注意是否存在大小写敏感，
C.可以尝试多少次的限制
D.是否可以不登录而直接浏览某个页面等。
l 在线超时：Web应用系统是否有超时的限制，也就是说，用户登陆一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
l 操作留痕：为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进入了日志文件，是否可追踪。
l 备份与恢复：为了防范系统的意外崩溃造成的数据丢失，备份与恢复手段是一个Web系统的必备功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段，如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求，某些实时系统经常会采用双机热备或多级热备。除了对于这些备份与恢复方式进行验证测试以外，还要评估这种备份与恢复方式是否满足Web系统的安全性需求。
传输级的安全测试是考虑到Web系统的传输的特殊性，重点测试数据经客户端传送到服务器端可能存在的安全漏洞，以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。
l HTTPS和SSL测试：默认的情况下，安全HTTP（Soure HTTP）通过安全套接字SSL（Source Socket Layer）协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别，但从某种意义上来说，安全性的保证是以损失性能为代价的。除了还要测试加密是否正确，检查信息的完整性和确认HTTPS的安全级别外，还要注意在此安全级别下，其性能是否达到要求。
l 服务器端的脚本漏洞检查：存在于服务器端的脚本常常构成安全漏洞，这些漏洞又往往被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
l 防火墙测试：防火墙是一种主要用于防护非法访问的路由器，在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题。这里所涉及的只是对防火墙功能、设置进行测试，以判断本Web系统的安全需求。

外连接
 [例]外连接实例
create table students
   (
          st_id    varchar(20),
          name  varchar(10),
          age      int,
          tol_score  int
    );

    insert into students values('973231','wangbindu',22,501);
    insert into students values('973232','zhuzhijing',21,538);
    insert into students values('973233','gaojing',21,576);

 

  create table student_skill
   (
      st_id  varchar(20),
      skill    varchar(20)
   );

    insert into student_skill values('973231','篮球');
    insert into student_skill(st_id) values('973232');
    insert into student_skill values('973233','足球');

   select a.* , b.skill from students a,student_skill b where a.st_id=b.st_id
order by a.st_id;

select students.st_id , students.name , students.age , students.tol_score , student_skill.skill from
students,student_skill where students.st_id=student_skill.st_id;

将子查询(as subquery)或in或exists当成where的一个条件的一部分,这样的查询称为子查询
  .where中可以包含一个select语句的子查询
  .where中可以包含in,exists语句
  .最多可以嵌套16层
  .层次过多会影响性能
  [例]简单子查询实例
   create table univ_subject
    (
       name            varchar(12) not null,
       per_id          int    not null,
       dept_name       varchar(20)            
      );

insert into univ_subject  values('gaoqianjing',1001,'信息工程系');
insert into univ_subject  values('wangbing',1002,'物理系');
insert into univ_subject  values('liming',1003,'化学系');

 create table  colle_subject
  ( colle_name    varchar(20),
    per_id         int);

  insert into colle_subject values('电子研究所',1001);
  insert into colle_subject values('物理研究所',1005);

查询两表中字段 per_id 内容相同的
select name,per_id,dept_name from univ_subject where per_id in
(select per_id from colle_subject);