本节案例主旨：测试管理/质量平台
实践案例读一读
第五篇 测试管理/质量平台
使用JS创建测试文化
JS是用于Web开发中最主要的客户端编程语言，写出优异的JS代码并非容易的事情：语言复杂，不同浏览器之间的差异，缺乏工具支持。测试为新代码提供快速反馈对已有代码进行回归验证，并形成文档以展现代码的意图。谷歌开发人员通常会在测试工程师指导和反馈下编写大量自动化代码，更多开发人员都倾向于用他们平常用的开发语言来编写测试代码。
如何针对JS创建测试文化：
如何编写单元测试，Jasmine测试框架，行为驱动要求编写测试的风格是要求测试作者描述测试代码应该做什么，测试本身被称为规格。行为驱动测试的好处是让非工程师也能够阅读并验证测试用例。Jasmine提供功能是单元测试工程师所期望的，比如setup/ teardown方法BeforeEach/afterEach，关键在于匹配器，包括toEqual、toBe、toMatch等。Spies是Jasmine对测试替身（模拟和桩）的实现，可以自动为任何函数建立桩，并跟踪对函数的调用，以及将调用转向真实实现。
如何执行JS测试。最为简单的情形是将它们托管到Web页面上，页面以JS中〈script〉块的形式被加载，然后直接通过打开和刷新Web浏览器运行测试。应用程序变得越来越复杂：首先多个浏览器中执行测试，以验证应用程序对每个测试是否执行正确；其次多数现代的正规JS应用都依赖于各种第三方和开源JS库，并且它们必然会被合理加载，用以测试应用。Jasmine自身拥有测试运行器，给测试人员留下乏味的工作，例如在测试上下文包含Jasmine自身及其它库，并在测试之前初始化Jasmine。Karma JS测试运行器，其目标是让JS的单元测试更快速、便捷及充满乐趣。
如何执行端到端功能测试？WebDriverJS需要一个测试框架提供启动/销毁测试、断言等功能。jasmine-node，Promise代理。
基于JS产品的TA框架的六次改进－支付宝无线统一测试平台
支付宝无线统一测试平台承载整个支付宝无线应用研发质量控制体系，提供字节码测试、monkey测试、遍历测试、UI自动化测试、适配测试、设备管理、真机访问、性能监测、安全扫描等。
核心模块划分－基础组件（用户管理、权限管理、任务调度等）、统一控制中心（与移动设备交互层）、应用提测、设备管控、应用评价中心、自动化测试等，鉴于集团共建，本平台主要开源技术体系Spring mvc& mybatis&velocity&mysql.
核心模块剖析：字节码测试、安装启动卸载升级测试［秒级、耗时统计、结果多角度分析］、性能监测［设备管控、应用管控、采集引擎］－性能监测－用户场景管控、嵌入式性能SDK、性能代码扫描［内存、流量、CPU、电量操作、响应时间、网络响应速度、客户端Crash率］－实时获取当前手机屏幕截图［使用adb本身提供的截图命令screencapcap、使用开源的C程序gsnap生成截图］、自动化测试［文件服务、测试工程、用例管理、设备管理、配置管理、数据准备－计划管理、调度管理、CQ集成、报表管理、OpenAPI］、其它测试［monkey测试、遍历测试、基于代码级安全扫描、应用自动打包、一体化质量报告体系］
垂直化协作研发模式，专人、专职的One Rule控制模式。统一化［在开发模式、url组织、静态资源、编码规范、数据库设计规范、工程结构成员对其它模块的快速掌控能力］、One Rule和同行评审、进行7快速原型验证和方案确认，加快特定方案的可行性研究步伐、螺旋式迭代［快速交付］、线上与线下部署［统一发布部署流程，每日构建，两套环境］、源码控制［主干与分支管理，强化模块级别同行评审］、架构与数据库设计［由技术架构师统一负责模块解耦设计以及数据库设计，并强化组员评审与方案解读］、研发资源共享［采取统一的三层架构研发模式与标准的模块工程，强化基础组件研发，提升整个系统研发层面的组件复用力度］－无线测试平台建设，业界案例或现实问题，借鉴同行，垂直化研发，团队独当一面以及整体把控方案（从需求到交付）能力，提升整个测试工具研发团队技术沉淀与研发能力，为统一化平台建设奠定了基石。
从25个月到10个月－移动终端产品的精益方法质量保证实践
通过精益方法对质量保证流程进行改进，实施了迭代开发模式、单件流水作业模式、测试活动上游化到开发团队内，缩短研发周期，用户满意度上升，维修率明显下降。
与项目干系人和用户迭代交互，每个迭代交付符合质量要求的软件。质量要求并不限于质量文档规定的内容，而是广泛内嵌在项目干系人和用户需求中，是功能需求和非功能需求不可分割的一部分。
只有正确地理解项目干系人和用户需求，才能保证研发的产品满足质量要求，两周一迭代，每次发布后的反馈意见加入下一个周期的待办事项列表。
实施单件流水线作业，加速上下游反馈循环。创建产品代办事项列表、开发、集成发布、系统测试、终端用户测试、认证测试、区域接收测试等，包含多个环节。
测试活动上游化，尽可能把功能测试、系统接收测试和非功能测试提前到研发团队内进行，研发团队内做测试－团队内开发或测试人员与产品负责人沟通设计出有深度和广度的测试方案，完全覆盖需求。每当研发工程师提交一个单件产品代办事项后，研发团队就可以马上执行测试活动，不需要等到软件发布才可能开始测试，发现的问题可以迅速反馈给开发人员去处理，极大加速了反馈周期。
实施企业级单件产品代办事项的质量要求，规范代办事项完成定义，上升为企业级定义。规定任一可交付的产品代办事项，所有产品研发团队必须完成的最少测试活动及达到的质量要求。每个研发团队在企业级完成定义基础上，可以添加自己特定的要求。
低于质量控制线以下时，暂停生产线。密切监视系统测试结果，稳定性和性能指标下降立即分析和纠正。低于控制线以下时，提请管理组，暂停相关功能开发，彻底分析根本原因，启动纠正方案避免再次发生，修改代码缺陷，然后再继续开发。
结语：突破传统质量管理思维，质量远不止使产品符合各项质量文档要求或零缺陷，要与项目干系人及用户迭代式交互，确保交付产品符合他们质量要求，最大化交付用户价值。突破传统质量保证方法，质量远不止测试。应将质量內建在研发流程和产品内，采取各种措施预防缺陷，而不是事后测试，每开发一小步就开始测试，迅速捕获缺陷。必要时，可暂停研发生产线相关功能开发，直到发掘根本原因，恢复缺陷，避免类似缺陷再次发生。
接口自动化测试方案与平台－飞信项目接口测试实践
如何在最短时间提供更高质量的产品，包括多架构并存，多种开发模式并存，分省运营、灰度发布［及早获得用户意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围］。
测试金字塔：UI层面［功能验证测试、兼容性与用户测试］、业务逻辑层［客户端模拟测试、对外接口测试、SDK接口测试］、数据处理层［单元测试、代码评审］
接口测试：客户端模拟接口测试－版本分类抽象出一个或几个版本接口测试，而客户端测试仅仅需要在UI进行核心功能验证和适配测试、多系统集成项目接口测试－模拟测试，整理分析被测系统前置条件和发送的请求消息；模拟系统接收到请求消息后按照预先约定信息发通知给被测系统，被测系统接收到消息处理后到下一步模拟、通用接口测试和自定义对象格式接口测试－按照协议规范设置输入输出参数，按照约定格式发送请求，最好使用测试工具、强交互类系统接口测试－mock或者把被测系统接口作为关键字。
接口收获与经验：自动化测试提高测试覆盖率、测试效率［核心测试用例和单功能用例覆盖率、重要功能覆盖率、总体覆盖率］、自动脚本整理，可描述业务逻辑，成为公司资产库。
保证测试结果正确性：测试脚本评审［尽可能让评审业务相关测试人员参与，每次不超过一小时，谁提出问题谁负责审查］、定时任务检查［通过评审场景加入定时任务，连续监控其正确性，连续执行一个月，每日安排固定人员对结果验证分析］、与测试版本同步、测试交付［交互标准］、自动化和手工测试用例统一管理［测试计划自动生成］。
敏捷的web UI自动化测试框架
自动化测试：学习成本高、测试脚本维护困难、断言机制呆板-适应变化。
提供用户话语法，降低脚本维护成本：易学易用、稳定性高、封装成本低。PageObject
降低断言成本，提高断言的有效性：像用户使用软件一样进行自动化测试。
采用面向对象的分析方法，对被测软件，在页面、面板、控件级别进行面向对象封装，而不是从业务角度封装；提供易于使用，基于UI对象的Automation Library，使得测试人员专注于测试用例而不是技术细节；Automation Library本身提供自检机制，统计覆盖率、浏览器addin自动扫描生成代码等。
使用人工智能技术：测试用例-分析器（正则表达式对文字解析）-解释器-操作器。测试自动化由云端机器人程序的开发团队提供给测试团队使用：集中式图形化测试内容管理（管理用例，测试过程监控，测试结果管理），升级维护，集成不同语言不同浏览器测试数据管理，测试公告板
启示：团队积极参与是确保成功的关键、打破开发和测试界限，紧密合作［开发良好架构设计，代码规范，对复杂问题的解决；测试从客户角度理解功能，良好的用例设计，探索性测试］、管理团队的持续关注。
多层次自动化拦截体系
系统套件可以从即时拦截、长时拦截、协同监测等多个层次进行功能正确性保证和质量反复拦截，并针对归生产、受限、对外、内测等不同用途的版本，进行不同时长覆盖，实现基本及完全质量保障，拦截多样性隐藏问题。基本功能套件（全面快速，覆盖粒度较低）、功能全集测试套件（全面，功能测试为主，组合、异常、互通测试为辅，及时问题拦截，推动手工/自动化测试融合-运行周期长，测试资源消耗大）、继承性确认测试套（含小特性变更、重大网上问题同步-完全重现及快速验证）、压力测试套（晚上无人看护测试）、规格确认测试套、自动化测试工具、开发中后期规划。测试效率评估、资源投入降低、研发周期缩短、测试长效积累。
多层次自动化拦截体系的经验总结：必须专注，必须不断的积累、整合和创新。具体实践经验如下：需要根据产品实际与风险分布进行顶层设计，并进行长期规划；多层次自动化拦截体系的形成必须循序渐进，逐步落实，形式主义要不得；必须依托版本变更分析，将自动化优化与规格变更无缝对接；坚持自动化无差别拦截，唯有质疑才可靠；自动化价值在于高效快速的质量评估以及即时的质量反复拦截；必须坚持自动化测试与手工测试融合，并不断强化互补；只有持续投入才能保持生命力；避免对脚本绝对数量的追求，自动化存在的根本价值是拦截质量反复和可靠评估，而非发现大量问题。
自动化运用模式看测试的攻与守。具体而微的测试始终面临两个命题，一是如何更有效地挖掘价值问题，二是如何确保质量无反复。功就是测试人员依托自身的技术能力和经验，进行测试分析设计，挖掘深层次缺陷，设计高价值高可靠性方案的能力-攻的核心是高水平的测试设计能力，依赖于人，取决于人对协议、实现和应用的综合把握；守则是重复覆盖，监控质量反复，确保修改引入问题第一时间发现。守的核心是可靠可信的执行力-守的最有效手段是自动化，且必须是有生命有思想的自动化。测试管理的过程，就是不断提高攻守水平的过程，守是根基，守的水平越高，战略空间越大，方可投入更多的力量分析、积累和提高，提升攻的能力；攻提升，测试更深入理解协议、实现和应用，反作用于测试分析设计，挖掘更多深入缺陷。空间-动力，如何提升测试能力以及测试竞争力。能力为基，竞争力为果-内力，创新，自我激励，勇于在组织活动中承担更大的责任。
构筑系统的web安全性测试体系
安全问题分类：境内感染网络病毒的终端数上百万，被篡改网站，国家信息安全漏洞共享平台-包括敏感信息泄露、重要数据被破坏、业务系统被非法控制、商业恶意言论攻击。两大主要安全问题：存在核心利益竞争，容易遭受外界攻击-漏洞攻击/网络攻击/信息截取、缺乏完善的安全测试体系，很难系统化保证产品的安全-安全在产品构思阶段（安全需求）、计划阶段（准备测试）、开发阶段（编码规范）、稳定阶段（安全检测）、部署阶段（安全措施）都要有相应的安全措施，达到安全上线标准，才能保证产品的系统化安全。包括业务安全、应用程序安全、客户端安全、数据安全、服务主机、网络等方面安全，又体现在数据传输、数据存储、数据的交互等。
安全体系的建立：基于安全重要性和企业面临的两大安全问题，安全性测试深入软件生命周期的全过程，从需求分析调研开始介入，通过量化分析，得出需求阶段存在的问题，反馈需求设计可能存在的安全隐患以及可能产生的影响。深入介入软件测试阶段及运行维护阶段的安全性测试分析及迭代测试过程，以产品安全性提高为目标开展各种安全性测试活动，推演出一套可用易用的安全性测试模板及案例。安全性测试体系：
方案设计-掌握系统的威胁类型及威胁等级，针对各种威胁类型划分测试模块及根据被测系统采用的技术来确认可能的测试种类，如数据库用SQL注入漏洞。根据实际情况选择手工［测试用例］、工具扫描［选择测试工具和扫描规则］、模拟攻击测试及具体的测试环境，确认测试通过标准。
安全访谈是第一步，具体操作是向研发人员了解系统架构威胁、系统前景、组件级系统调用威胁、用户需求、异常处理、加密逻辑等内容；向测试人员了解测试不充分的地方、系统缺陷涉及到的安全bug、已知问题等内容；向运维人员了解运营部署、服务平台漏洞、安全审核机制及杀毒机制等内容。访谈结束后形成一个安全访谈工作表，内容涉及到测试系统的安全目标、整体架构、技术路线及运营方式。然后根据访谈工作表进行威胁建模。
威胁建模采用SDL Threat Modeling Tool工具进行建模，过程包括：标识信任边界-分解出从何处发起的对系统的请求是可信任的；标识数据流-分解出系统的数据流向，特别要注意跨信任边界数据流；标识入口点-入口可以是web应用程序，也可以是其它监听接口；标识特权代码-例如访问DNS、本地目录等相关功能的代码；记录安全配置列表文件-列出各个易受攻击区域需要考虑的安全性问题。
安全测试－安全方案设计完成后，需要遵循安全测试矩阵
矩阵内容包括web安全、接口安全、源代码安全、数据安全等。矩阵包括分类、测试项目、测试方法指导、是否测试（例如web安全/接口安全/敏感数据与加密、使用web漏洞扫描工具对产品web应用和web服务器进行扫描测试，系统无异常、使用Appscan/ WVS对系统web应用和web服务器进行扫描测试，扫描结果是否于高风险级别漏洞，Yes）。
XXX安全测试技术框架-源码/应用程序/数据库/服务器/业务逻辑：结合测试（源代码扫描技术、威胁建模技术、业务安全技术、web应用程序/接口服务扫描技术、web服务平台扫描技术、服务器开放端口扫描技术、数据库扫描技术）+渗透（DDoS攻击技术、漏洞扫描技术、暴力破解技术、SQL注入攻击技术、挂马攻击技术、数据包截取技术、社会工程学攻击技术）。安全测试从整体系统架构、安全编码、安全测试覆盖性、安全度量等多个因素去考虑问题，提出的解决方法是逐步帮助客户引入安全开发过程，提供相应的工具支撑，目标是最后让客户提升业务系统自身实质性安全问题；渗透测试考虑以黑客方法，从单点上找到利用途径，证明应用有问题，帮助客户提高认识，也能解决紧迫的一些问题，但无法也不能去针对系统做完备的安全测试。
风险闭环。风险评估是对信息系统及由其处理、传输和存储信息的保密性、完整性和可用性等安全属性进行科学、公正的综合评估活动过程。它要评估信息系统的脆弱性、信息系统面临的威胁以及脆弱性被威胁源利用后所产生的实际负面影响，并根据安全事件发生的可能性和负面影响的程度来识别信息系统的安全风险。
一般工作步骤：风险评估准备工作、识别并评价资产、识别威胁和威胁可以利用的脆弱性、考虑控制措施、识别和评价控制措施、分析可能性和影响、分析风险大小、编写风险评估报告、风险处理。风险等级=可能性*影响。
风险处理方面可选择的控制措施包括：减缓风险，即采取适当措施将风险减到可以接受的状态；接受风险-一是风险低没有控制的必要、二是采取控制措施的代价过大，盲目处理必然陷入为安全而安全的错误状态；规避风险-直接关闭危险服务，不是不可或缺的；转移风险，将风险转移给运维或者安全设备运营商。
安全监控，没有永远安全的产品，只有更安全的产品。安全测试通过已有的安全测试工具，执行经验总结的安全测试用例，并不能找出系统的所有风险，而风险管理和控制措施本来也存在风险，安全监控作为系统安全的一个补充，却也是必不可少的安全措施。
安全监控能够实现实时的监控，内容包括：对网络故障进行监测，如网络是否连通，网络响应时间的监测等；对系统内容匹配进行监测，如被测系统内容是否被恶意修改，系统是否被挂马等；对网络攻击进行监测，如攻击性监测、大量访问监测等。
监测的主要方式是通过不良请求首次过滤、用户鉴权再次阻拦、权限设置确保受限和日志行为分析跟踪的措施来时刻关注系统的安全，在监测到安全问题后，系统需要遵循闭开原则，及时对监测到的问题进行分析并处理解决。
体系实践及产出：根据安全测试体系，推演出一套可用易用地安全性测试工作流程。
安全访谈-威胁建模-方案设计-安全检测-系统监测
不足和思考
安全访谈-系统安全性目标、系统安全性风险、系统架构设计、系统部署方案：接收到安全测试任务后，首先需要对测试的环境、范围、目标、重点等信息进行了解。针对程序经理、开发人员、测试组长、测试人员、运维人员不同角色的特点，设计侧重点不同的安全访谈内容列表。再结合项目实际情况综合选取出本次访谈的适用内容，形成一份安全访谈表并最终分别与相关人员进行安全访谈，得到结果供后续威胁建模以及其他测试步骤时参考使用。
威胁建模－系统利益攻击点分析、常规漏洞分析、编码引入风险分析、测试风险分析、运行安全审核：安全访谈结束，我们对测试对象就有了清晰的了解，直接利用这些信息，通过威胁建模工具SDL进行建模，最终列出系统可能产生的问题点。
方案设计－安全性手工测试用例设计、安全性配置检查表设计、安全性测试工具选择、安全性测试工具扫描方案设计：确定好系统的威胁点，结合已有的安全测试方案模板从安全性测试资源库中选择合适本次项目的扫描工具、业务测试用例、配置参考项及需要人工重点渗透的模块等，最终形成本次测试的方案内容，包括：时间点、人员分工、测试内容、测试方法以及参考资料地址。根据此方案，安全性测试小组以及项目组测试人员即可开展项目的安全测试工作。技术安全用例：XSS漏洞、SQL漏洞、CSRF漏洞、重定向、文件上传、信息泄露、框架配置；业务安全用例：登录、注销、验证码、文件上传下载、用户注册、找回密码、重要信息、搜索查询、授权验证、留言评论、购买和其他功能。
安全检测－安全性测试手工用例执行、安全性测试自动化工具扫描、安全性测试配置项检查：测试方案完善后就可以指导我们的安全检测。安全性小组可以与项目组进行分工测试，部分安全用例可以由项目组在日常的测试工作进行执行时并及时反馈给安全小组。安全性小组结合用例执行结果，针对被测对象进行扫描分析以及人工渗透，最终提供完整的测试结论。结论中会根据系统的使用情况以及本次测试结果等内容综合分析出被测系统的安全风险，再结合风险评级系统对风险大小进行评级。风险评级系统可以形成安全评估报告，不会忽略小风险而忽略大风险，还会提供具体缺陷的修复建议协助项目组完成安全问题的修复，以达到风险闭环。系统上线指标来决定系统是否允许上线（安全高优先级指标通过率100%，中优先级通过率60%，低优先级不做强制性修复），以保证漏洞漏测率不高于5%。
系统监测－网络攻击监测、服务器挂马监测、异常请求监测、异常情况通知：OSSIM包括资产（服务器、网络设备、网段等）探测管理，网络弱点扫描，网络行为实时分析，威胁数据图表形式展现及报表生成，威胁点修复跟踪流程化，安全知识库等。系统监测可以实时监测到系统产生安全问题，并且提供每个安全问题产生原因、修复方法等信息，同时管理员可以将每个安全事件通过邮件方式指派到相应的负责人进行处理。
不足和思考：完善的安全测试体系能够有效地指导安全测试人员进行系统化安全测试，并保证系统安全上线，在系统上线后我们通过系统监测能够实时关注系统的安全。是如果系统遇到攻击，我们该怎么办？是否有事前防护策略，是否有安全应急小组？是否有安全指挥专家？我们能否有相应的紧急措施、过度措施、根治措施来应对攻击呢？肯定需要，必须正确地面对系统的安全事件，做到事前、事中、事后的有效安全处理，简称“三部曲”-需要在安全实践中不断学习、积累和总结。
事前：安全风险分析和评估、安全应急策略、安全运营监控告警
事中：安全应急领导小组、安全监控分析体系、应急安全防护办法
事后：安全问题分析总结会、模拟攻击应急演练、安全审查与审计、经验分享与交流
基于持续交付的移动互联应用测试平台
分层测试技术，自动化和基于风险策略，构建基于移动互联应用的快速交付框架层，实现移动互联应用在终端上的快速开发、部署和测试，以及大促的一体化过程。
技术要点分析：应用特性+仿真实验室环境+协议互操作+兼容性、安全性、稳定性等方面，形成完整的测试解决平台。
一体化交付方案：产品的需求是源头，内容是代码，交付给用户的是产品。把产品实现过程中的源头，代码和产品过程串联起来，通过人员、流程和工具的整合，加快产品化过程，更快地响应市场的变化。
分层测试框架：面向底层和接口的测试，面向需求的功能测试以及面向用户的使用过程和场景构成了平台的分层测试内容。分层体现了不同层次的测试重点，对应不同层次的测试，也意味着不同的测试方法和测试用例。
用户化的自动化测试：测试效率提升，版本发布周期变短。用例的自动化生成和测试执行能够提供更快的测试验收过程，使版本发布效率更高，同时交付给下一段版本质量更高。
分布式的测试资源：测试资源不足是测试团队面临的最常见困难分布式测试资源即插即用，利用闲置资源，通过此思路让远程触发测试执行变得更容易，测试对列的建立也为资源的使用提供了简单有效的使用模型。
让用户更好地参与：用户早期的参与和讨论可以让产品更具生产力，如何向最终用户传递版本是一个需要解决的问题。版本既不能差到无法正常使用，又要能够以一定的频率不断更新来修复使用过程中发现的缺陷，自动化应用可以部分解决这个难题。
真实的使用场景：用户在真实环境中使用产品，而不是坐在实验室里面。分布式测试环境和基于云的测试服务，让真实的环境触手可及。
技术要点回顾：版本端到端快速发布，从开发生成版本到终端集成版本，从底层网络协议到上层最终用户使用的全面覆盖。
平台的交付和使用：开发、测试、决策模型。持续交付平台，测试云。
首先是持续，基于持续集成中心的概念设计，以项目研发过程中的构建信息、代码变更信息和分层测试信息为基础，进行数据分析挖掘，从项目看板、测试看板多个纬度给项目开发和测试团队提供可视化的项目状态和信息。一旦进行提交代码，系统自动进行代码规范检查、编译构建、版本下载、自动化测试验证和版本发布。
然后是交付，可交付的版本代表产品达到可用的状态。开发、测试、决策，直至版本发布，全自动化到下一流程入口，终端，体验用户等不同目标客户的交付。此过程中，通过分层测试、用户场景化的模拟等技术实现版本质量的保证。
对应用功能、兼容性、性能、安全等方面进行全方位的自动化测试并生成测试报告。并通过云的方式将分布在系统各地的多台测试服务器的移动终端进行整合，一个统一的用户入口，根据不同测试策略将应用在不同终端进行测试。
通过系统架构优化，该平台可以作为测试云的一部分来对内外部使用者提供服务。支持快速有效发现安卓应用兼容性问题，有效帮助解决OS系统碎片化问题；可对应用的性能、功能、安全进行自动化测试。
TCL嵌入式测试技术在网络设备测试中的应用
TCL是一种解释执行的脚本语言，是业界主流的自动化测试语言，修改后不需重新编译，TCL解释器直接执行。TCL嵌入式测试是将TCL语言解释器植入被测系统，并通过TCL扩展命令调用被测系统模块内部接口，以构成测试条件达到测试目的。测试类型属于灰盒测试，测试阶段类似于集成测试，测试手段利用TCL语言编写测试脚本进行更为细致的模块接口测试、子模块功能测试。常用黑盒测试，搭建测试环境，分析设计和开发出对应的用例及自动化测试对脚本进行测试，包括配置、功能、性能、压力、组合、一致性、异常功能测试等。但有些问题：部分模块外在表项很少，纯黑盒测试可测内容不多，测试覆盖不全；部分测试项目虽然不大，改动不多，从功能角度涉及范围广，黑盒测试投入大；测试结果观察手段有限，一般从用户接口（通过业务流量、表项错误、断言、DA观察），模块调用不一定能马上表现出来，后续操作才能发现问题；异常测试条件、特定时序事件触发条件不方便构造。几个典型的模块测试模型及应用：
1. 模块接口测试：通常业务模块提供给用户命令行接口，遍历接口参数情况
2. 测试各模块之间的交互细节：多个模块协同工作，模块间需要传递数据和消息，如果数据和消息没有遵循设计约定将导致错误。截获模块之间交互的数据和消息，在模块间打开一扇窗户。
3. 方便构造难以切入的点：临界资源保护问题，模拟各种失败。
内部性能规格压力测试，消息队列最大长度、内部计数最大值等黑盒测试盲点，调用模块接口进行。
测试工具开发。获取进程数据，调用可见外部接口，模拟用户操作，直接调用内部模块处理流程。
安全性测试。文件权限，动态加载测试，常见风险分析-缓冲区溢出、格式化字符串攻击等。
网友评论