1.测试的组织形式

　　早期微软的开发团队中没有独立测试组，那时通常由几百个人做几个项目，程序员写完程序自己测一下就算完。后来项目越来越大，开发的软件也越来越复杂，编码和测试

并行的进行，于是渐渐的产生了独立的测试组。在研发团队多少合适，视情况而定。微软是1:3，Google是10:1，百度是5:1,究竟多少合适要根据系统的复杂度，公司对产品的

质量要求有关，也和团队开发、测试工程师的素质有密不可分的关系。

 

2.最简单的软件测试组织

　　最简单的软件测试组织形式就是没有任何组织形式的测试，几个人把所有软件测试工作做完，这样没有任何分工，没有任何层次结构。

　　缺乏测试组织，导致工作无计划进行，测试人员疲于应付各项突如其来的测试任务，测试经验也得不到很好的总结。

 

　　测试组织形式分类：

　　　　按测试人员参与程度分为专职和兼职，按照测试人员从属关系可分为项目型和智能型两大类。

　　　　（1）专职 VS 兼职

　　　　　　小型规模的企业往往没有专职的测试人员。在做测试时还要兼顾软件开发、配置管理、技术文档编写、用户教育、系统部署实施工作等。

　　　　　　测试工作本身的要求就是知识面广，而这些工作有助于从不同层面、不同角度、不同角色的位置考虑软件的相关问题。

　　　　（2）项目型 VS 职能型

　　　　　　项目型的测试组织是指测试人员作为项目成员之一紧密地结合到项目中，与项目组其他人员紧密合作，一般是从头到尾跟着项目走。　　　　　　　　　　　

　　　　最终报告的对象都是项目经理，因此项目经理是负责测试资源调配和测试计划的主要人员。项目的组织结构如图2.1：

 

　　　　　　　　　　　　　　　　　　　　

　　　　　　 如图2.2

　　　　　　　　　　　　　　　

　　　　　　

　　　　　　　

　　　　　　

　　综合性测试组织：

　　　　一个理想的软件测试组织可以是综合和兼容了几种结构方式的组织，测试部门的测试人员分为常规项目测试人员和专项测试人员。

　　常规项目测试人员即参与到项目组中的测试人员，专项测试人员一般由性能测试工程师、自动化功能测试工程师、界面及用户体验测试工程师、

　　安全测试工程师等负责专门测试领域的人员构成，这些测试资源在项目发生专门的测试需求时，被调到项目组，与常规项目测试人员一起工作，

　　重点是解决专项的测试问题。还可以根据需要设置专门的培训中心，负责对测试人员的内部培训，负责收集和整理各个项目的测试经验和测试知识。

　　如图2.3

　　　　　　　　　

3.融入测试组织

　　如何让自己快速融入项目团队是成功实现软件测试的第一步！

　　根据开发模式判断自己的测试定位

　　　　（1）不同的开发模式，测试的角色定位也不一样。

　　　　　　传统开发模式，软件测试人员仅仅完成系统测试任务就可以了。 而在敏捷开发模式中，则可能需要更多的单元测试。与开发人员紧密配合，找出Bug根源。

　　　　（2）MSF模型中的测试中的测试角色。如图2.4

　　　　　　　　　　　　　　　　

　　　　　　　　MSF组队模型的核心和基础是沟通和协作！

　　　　（3）敏捷测试角色

　　　　　　在敏捷项目中，测试人员角色进一步地细分，如图2.5所示。

　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　4种测试角色的意义和内涵存在很大的不用。

　　　　“支持编码的测试”与“批判产品”的测试

　　　　　　通过写代码来阐明关于问题的思考！

　　　　　　另一方面，测试是关于暴露主要错误和遗漏，也就是对产品“批判”。

　　　　“面向业务”的测试 与 “面向技术”的测试

　　　　　　“面向技术” 是指测试人员跟关注测试过程中技术的正确实现，应用到很多的专门技术来测试。例如：性能测试、安全测试、可用性测试。

　　　　　　“面向业务” 是指测试人员测试过程中更关注产品对业务实现的正确性。需要根据需求和用户的实际应用场景来测试。 例如：产品对需求的满足程度，探索性测试。

 

　　　　面向技术的支持编码角色是指测试人员使用单元测试代码来检查开发人员的编码。并且编写一些“保护性”的代码。

4.如何融入一个项目团队

　　一个非常正要的前提条件是要做好本职工作。需要注意的因素如图2.7

　　　　　　　　　　　　　　　　

　　学习组建团队

　　　　首先建立起一个学习、培训的机制，例如：定期的测试交流，技术演讲，年度测试技术活动。

　　　　一些外企会提供测试人员两条线如图2.8

　　测试规范

　　　　测试规范是一个公司的测试标准，既是测试人员的准则，同时也是测试人员与开发人员达成的契约。规范应该包括内部和全局的！

　　　　（1）内部规范。

• 　　软件测试方法指南：规范化的要求，例如：安装包测试，一定包含安装、卸载、重安装的过程，一定检查注册表和文件改变是否符合要求。通过规范的制订，避免不同人员进行同类测试时出现很大的测试效果偏差。
• 　　测试用例设计规范：一般包含测试用例的模板及测试用例的实际要求。例如：每个测试用例必须包括测试用例执行的估计时间，测试用例的优先级别等。
• 　　缺陷录入规范：规范测试人员的Bug录入过程，包括Bug的录入格式、Bug录入的要素、Bug录入需要注意的地方。
• 　　测试计划规范：包括测试计划模板及测试计划的要求，例如：测试进度和时间安排根据什么来定。
• 　　测试报告规范：包括测试报告模板及测试报告要求， 例如：测试报告需要哪些要素，测试报告的分析需要注意哪些方面的问题。
• 　　测试工具使用规范：指测试人员在什么时候使用哪些工具。工具参数 设置需要注意哪些方面的问题。例如：对于自动化测试工具 TestComplets,要求统一使用哪种脚本语言。

　　　　（2）全局规范

• 　　缺陷分类规范：指把Bug进行归类，归类有利于缺陷分析统计，以及产品质量的评估，测试时人员按照缺陷分类指定Bug类型。
• 　　缺陷等级划分规范：是Bug的严重程度标识和优先级标识的依据，按照规范来衡量某个Bug应该属于什么级别的缺陷。缺陷的等级划分有利于开发计划的优先级别划分，有利于产品质量的评估。
• 　　测试提交流程规范：是开发人员提交某项完成的功能模块给测试人员测试时应该遵循的流程，如图2.9
  • • • • 　　　　　　　　
• 　　缺陷状态变更规范：要求项目组不同权限的人对Bug状态的修改和更改应该遵循的流程。 例如：规定开发人员不能私自把Bug状态改为“Rejected”状态或“Delay”状态。必须测试经理和测试组长同意才允许。　　　　

 

　　#BVT的全称是Build Verification Test。可以说这个全称就是BVT的定义了。

　　　　BVT只验证build构建的成功与失败，不深入测试构建好的build的功能、性能等等。

　　　　BVT是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。

　　　　如无大的问题，就可以进行相应的功能测试。BVT优点是时间短，验证了软件的基本功能。缺点是该种测试的覆盖率很低。因为运行时间短，不可能把所有的情况都测试到。

 

　　#在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。

　　　　在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

 

　　　　

 摘自：《软件测试技术大全》