请简述网站开发的流程,霸州 网络 网站建设,网站建设机构培训,怎么把网站黑掉文章目录
前言
一、“原始”阶段
二、“小打小闹”阶段
三、“小米加步枪”阶段
四、“摩托化部队”阶段
五、“骑兵连”阶段
六、“海军陆战队”阶段
七、“社区型组织”阶段 前言 近期公司的测试团队需要重新组织安排#xff0c;本着谦虚谨慎的态度#xff0c;我从…文章目录
前言
一、“原始”阶段
二、“小打小闹”阶段
三、“小米加步枪”阶段
四、“摩托化部队”阶段
五、“骑兵连”阶段
六、“海军陆战队”阶段
七、“社区型组织”阶段 前言 近期公司的测试团队需要重新组织安排本着谦虚谨慎的态度我从网上翻找了一下相关的资料高质量的资料比较少看到的大部分是比较宽泛的谈论。于是便想着梳理一下自己这几年的工作经历把经验教训摘出来然后再加一些同行的先进办法搞一套完善一点的测试体系。这一梳理才发现自己已经走过的了一条曲折的测试道路现在把它分享出来希望对读到的人有所裨益。 一、“原始”阶段 这个阶段可以追溯到最早的校内实验室阶段。自己当时还是本科生最有代表性的项目是全国大学生电子设计竞赛。那时候脑子里还没有专业测试相关的概念整个项目就是老师讲一个大体的方案然后学生一个设计电路板、一个写代码然后两个人一起调试功能功能出来了基本上也就到时间该提交东西了最后小组一起去演示考评。 这个阶段的测试还仅限于功能体调试和演示所以用现在的眼光从专业测试的角度来看这是单个的设计人员自己做测试我把它比喻成测试架构演进过程中的最“原始”阶段。 二、“小打小闹”阶段 这个阶段还是在校内的实验室。比较典型的是一个大创项目当时是要设计一套编程工具。这时候团队的稳定人员已经达到的6个以上了大家就会交叉着做一些测试工作。比如我刚用开发出来的工具实现了一个电子节气门的功能这时候就会让另外一个人过来看一看试一试收集一些评价。虽然说在单个设计物上面做到了设计人员和测试人员的分立但是这个“测试人员”毕竟还是设计人员中的一个也没有明确的测试立场和独立的测试思维。这种测试模式我把它比喻成测试架构演进过程中的“小打小闹”阶段。 三、“小米加步枪”阶段 这个阶段是在一个企业的研发部门。自己当时研究生还没有毕业作为一名测试工程师参与了几个控制器的开发项目。这时候跟我一起的还有另外三、四个测试工程师已经形成了一个专门的测试小组核心的工作就是做测试。这时候的测试工作从横向和纵向展开的矩阵如下所示 这个阶段的测试人员虽然形成了小组有了专门的工作内容但是毕竟还存在于设计部门内部大部分工作都依设计规划而定没有自己的工作流程。而且小组内部没有具体分工也没有专门的设备设施做支撑更没有测试角色的话语权所以只是一种最初级的测试架构。这个阶段的测试模式我把它比喻成“小米加步枪”式的测试架构。 四、“摩托化部队”阶段 这个阶段的测试部门是在企业的质量中心下面。当时自己作为测试团队的一员亲历了测试架构从第三阶段向第四阶段演进的始末。这个时候原本位于几个设计部门的测试小组分别走出来共同合并为了一个大约15人的测试部门归入质量中心。这个阶段的测试工作矩阵如下 这时候测试人员的工作内容有了更细致的划分工作流程也规范了一些有了专门的设施设备做支撑也有了测试角度的话语权算是一种比相对较高级的测试架构所以可以比喻成一个“摩托化部队”。这个阶段还有一个重要的特征是测试团队中出现了管理者的角色。这个角色从测试执行的试验任务中解放了出来开始思考整个测试工作的发展问题承担起了培养测试团队、写企业标准、画故障树、写FEMA、做性能仿真、挖掘设计薄弱、做回归分析、打测试补丁、研究电子可靠性、机械可靠性、做测试系统分析等工作。正是这个管理者角色的工作把整个测试架构的形态推上了更高的一个台阶。但是由于质量工作的定位与设计部门拉开了太大的距离过度和衔接出现了一些问题一部分原本来自设计部门的技术人员离开后早期在测试上面的规划和设想便不了了之了。 五、“骑兵连”阶段 这个阶段的测试团队是企业设计部门中的一个测试小组是介于前面第三阶段和第四阶段之间的一种中间形态。工作特点和组织形式兼备了设计部门的技术性和质量部门的严谨性团队规模也是15人左右。这个阶段的测试工作矩阵如下 这时候的测试工作在横向和纵向都拓宽和拉长了很多测试工程师也开始细分。做软件测试的人就不去搞硬件测试做测试开发的人就不去做测试执行。其中最重要的测试管理的人也不去搞很发散的东西而是专注于项目测试的框架、测试团队培养、测试设备建设、测试数据库维护、测试流程规范化、测试标准集编纂、新测试标准引入、新测试板块导入、新测试项开发、新测试技术培训、可靠性工程宣贯、等等这些非常内化的东西。这样的测试团队因为工作更具象了所以也更专注了虽然不是很高大上但是效率还是比较高的所以可以比喻成一个“骑兵连”。 六、“海军陆战队”阶段 这个阶段是未来要长期规划的一个新形态期望的目标是测试工作既不依附于设计部门也不拘泥于质量部门一种独立的第三方形态。测试团队内部的稳定规模至少要达到25人以上每个产品类型的测试团队中需要具备一名测试架构工程师每个模块的测试小组中需要具备一名测试开发工程师和若干名测试工程师每个人都有自己明确的分工和要求。如果某个产品类型与已有的产品有重叠的测试模块就可以与其他产品线共用测试小组但是至少要有一名专门的测试架构工程师。大体的测试架构应该是如下这样的三维状态 这种形态的测试部门要求有足够的设施设备资源做基础支撑测试团队的每个人员对产品的原理和应用要有足够深入的理解对相应的法规和标准要足够的熟悉并持续维持高度的技术专业性。这种宽领域的知识和技能储备我把他比喻成了“海军陆战队”。测试团队的管理者要有足够的话语权能够争取到上级的足够重视和支持投入能协调到足够的外部配合能建立一套科学的人才考核制度来推动整个部门的发展车轮向前滚动。 这样的测试架构才能够保持自己的正常节奏真正发挥出测试的本质作用——早期充分挖掘问题提高产品可靠性最大程度降低后期风险。 七、“社区型组织”阶段 未完待续… 版权声明原创文章转载请注明出处与链接违者必究
