关键词：

测试类型：

1. 单元测试
2. 不变条件测试（断言等）（SIT)
3. 功能测试
4. 压力测试
5. 性能测试
6. 可伸缩测试
7. 基于用户的负载测试
8. 场景测试

提升测试覆盖率:

1. 应用和开发工具提升测试覆盖率

2, 开发模拟器提升测试覆盖率

3, 复杂技术系统：重现低概率的defect

4. 复杂技术系统：发现的长尾浮现的稀有defect

5. 复杂银行业务测试：100% 覆盖是可行；重点是建立测试矩阵，挖掘业务需求，跟踪业务测试

测试系统：支撑测试架构，产品业务特性， 测试技术平台

使用其中的任意一个技巧都可以把MemSQL带到一个新的水平。

1. Transforms

MemSQL拥有许多Transforms，这里列了几个：

• 复制Transform
• 子查询Transform
• 备份恢复Transform

2. 随机生成查询

这里有一些力量倍增器用来随机生成查询：

• 产生许多不同的查询，但结果一样。
• 创建智能生成器，来逐步增加生成测试的复杂性。
• 发现bug后会自动降低查询的复杂性，并且创建一个最小的可再生测试用例。

3. Functional Stress

4. 堆栈散列器

5. 生成故障

6. 通过代码审查来提高透明度和代码质量

使用一个好的代码审查工具乃是必须的，比如像Phabricator，它可以集成工作流，并且使用起来非常轻松有趣。

索林根的软件度量指南

索林根的软件度量指南：十大方针
软件度量专家索林根(Van Solingen)在《聚焦产品的软件过程改善》(Product Focused Software Process Improvement)中详细阐述了软件度量项目工程(Measurement program engineering)，提出软件度量的十大方针，如下所示。
1. 准备让软件开发者参与软件度量项目；
2. 开始软件度量工程前了解软件产品的质量目标、过程模型和学习目的；
3. 软件度量项目工程为目标导向，确保具备有限但相关的度量设定；
4. 指定期望值(假设)；
5. 由具有实际度量经验的人员按照规则对度量数据作出分析和解释；
6．将度量数据的分析和解释聚焦于：详细而精确的过程行为、全局过程、或者产品质量目标，但是决非聚焦于个人绩效；
7. 执行专门资源(人员)来支持度量项目工程的开发团队；
8. 评价实际产品质量和目标产品质量的差距；
9. 评价过程行为的影响(产品质量方面)；
10. 将特定情景中过程行为的知识存储到经验数据库中。
高尔发的关键成功因素：九大要素
品质与生产力管理集团(Q/P Management Group)总裁斯科特·高尔发(Scott Goldfarb)在《建立有效的度量体系》(Establishing a Measurement Program)中认为，建立并实施有效软件度量体系的关键成功因素包括如下：
1. 确定度量目标和计划；
2. 获得高层管理者的支持；
3. 拥有专属资源；
4. 面向员工的培训、教育和营销推广；
5. 日常工作中的度量一体化；
6. 聚焦于项目团队的结果；
7. 度量不要针对个人；
8. 有效定义数据以及实情报告制度；
9. 推动度量自动化。
软件工程研究所的软件度量规则：二十八条规则
美国卡内基·梅隆大学软件工程研究所在《软件度量指南》中列出了如下软件度量的规则：
1. 理解软件度量方法只是达到目的的手段，而其本身并不是目的；
2. 以应用度量结果而不是收集数据为中心；
3. 理解度量的目标；
4. 理解如何应用度量方法；
5. 设定期望值；
6. 制定计划以实现早期成功；
7. 以局部为重点；
8. 从小处着手；
9. 将开发人员与分析人员分开；
10. 确信度量方法适合要实现的目标；
11. 将度量次数保持在最低水平；
12. 避免浮夸度量数据；
13. 编制度量工作成本；
14. 制定计划使数据收集速度至少是数据分析和应用的3倍；
15. 至少每月收集一次关于工作投入水平的数据；
16. 明晰关于工作投入水平数据收集的范围；
17. 仅收集受控软件的错误数据；
18. 不要指望准确地度量纠错工作；
19. 不要指望找到界定完善的放之四海而皆准的过程度量方法；
20. 不要指望找到过程度量的数据库；
21. 理解高级过程的特征；
22. 应用关于生命周期阶段的简单定义；
23. 用代码行表示规模；
24. 明确将哪些软件纳入度量范围；
25. 不要指望使数据收集工作自动化；
26. 使提供数据的工作更容易；
27. 使用商业上可用的工具；
28. 认为度量数据存在瑕疵、不精确也不稳定。
帕克的目标驱动软件度量原则：四大原则体系
帕克(Robert E. Park)、哥特(Wolfhart B. Goethert)和弗罗哈克(William A. Florac)在1996年的《目标驱动软件度量指导手册》(Goal-Driven Software Measurement—— A Guidebook)中提出软件度量的原则如表5-10所示：
表5-10 帕克的目标驱动软件度量原则
1. 部门管理者的度量原则

—— 设立清晰的目标；
—— 让员工协助定义度量手段；
—— 提供积极的管理监督：寻求和使用数据；
—— 理解员工报告的数据；
—— 不要使用度量数据来奖赏或者惩罚实施度量的员工，并确信他们知道你和其他任何人都遵守这一规则；
—— 建立保护匿名的惯例，对匿名提供保护将建立起信任并培育起可靠数据的收集机制；
—— 如果员工的报告基于对组织有用的数据，支持他们；
—— 不要强调那些排斥其他度量方式的某种度量方式或者指标。

2. 项目管理者的度量原则

—— 知晓组织的战略性焦点并强调支持该战略的度量手段；
—— 在追踪的度量手段上与项目组获得一致，并在项目计划中定义这些度量手段；
—— 向项目组提供规则有序的关于其所收集数据的反馈；
—— 不要私人单独地进行度量。
3. 项目组的度量原则

—— 尽最大努力报告准确而及时的数据；
—— 协助在管理中将项目数据聚焦于改善软件过程；
—— 不要使用软件度量夸耀自身的优秀，否则这将鼓励其他人使用其他数据展示其反面。

4. 通用原则

—— 软件度量本身不要成为一个战略；
—— 在软件过程改善的全局战略中整合软件度量，为此应该拥有或者开发一种这样的战略来联合软件度量计划；
—— 带着共同目标与课题从点滴做起；
—— 设计一种持续的软件度量过程，以使其：
? 与组织目标与宗旨相联系
? 包括严格的定义
? 持续实施；
—— 在广泛实施所设计的度量手段和过程之前进行测试；
—— 对软件度量手段和度量活动的效果进行度量和监控。
弗罗哈克的实用软件度量原则：十大原则
弗罗哈克(William A.Florac)、帕克(Robert E.Park)和卡尔顿(Anita D.Carleton)在《实用软件度量：过程管理和改善度量》(Practical Software Measurement：Measuring for Process Management and Improvement)中提出成功的过程度量原则如下。
1. 过程度量受商业目标驱动；
2. 过程度量手段源自软件过程；
3. 有效度量需要明确阐述的可操作性的定义；
4. 不同的人拥有不同的度量观点和需求；
5. 度量结果必须在产生结果的过程和环境中检验；
6. 过程度量应当跨越整个生命周期；
7. 保持的数据应当提供分析未来的实际基线；
8. 度量是进行客观沟通交流的基础；
9. 在项目内部和项目之间对数据进行总计和比较需要细心和规划；
10. 结构性的度量过程将强化数据的可靠性。

软件度量的要点：来自实战的教训
软件度量这一作业本身比较难以在实际的软件开发中顺利操作，也难以在软件开发改善中产生立竿见影的效果，甚至会让人觉得这是枯燥无味的无用功。这往往会形成妨碍实施软件度量的阻力，挫伤软件度量人员的积极性和热情。那么，如何有效地推动软件度量，就成为软件度量作业的重点课题。下面是软件度量作业的要点，可以作为推动软件度量作业的参考。
1. 从点滴开始。与其采用声势浩大的软件度量运动，还不如从点滴开始：让员工逐渐进入度量状态，避免因为大规模运动带来的不适和阻力。从点滴开始，从小规模的简单的度量项目开始，从能够吸引员工并能让其接纳的度量项目开始，保证软件度量能在避免受挫的情况下得以逐渐推进，同时尽可能提高软件度量的自动化程度。
2. 解释为什么。这是消除抵制情绪和消解阻力的重要环节，因为人们不会切实地践行那些他们没有真正理解和接纳的理念和措施。需让员工明白，使用度量将比没有任何度量要好；度量将在一定程度上增进对软件开发的理解、预测、评估、控制和改善；软件度量仅仅针对软件产品、项目和过程，而不针对个人；等等。
3. 根据项目实情加以具体实施。不同的项目拥有不同的产品、流程、环境、目标和顾客，顾客、软件开发人员、项目组甚至经营者对项目的需求也不同，必须聚焦于解决该项目在产品、流程等方面的问题，而不是直接套用以前曾经实施或者已经模式化的度量标准。
4. 共享数据。度量数据的共享这一行为本身具有四大好处：一则可以让员工感受到度量的切实性，即行动正在按照计划进展；二则可以为员工提供度量的反馈信息，以改进现状；三则可以通过比较，寻找最佳实践，实施标杆学习；四则可以通过数据共享增进信任，消除软件度量可能带来的误解。
5. 保持简单易懂。简单易懂这一点对于降低度量过程中的理解成本、沟通成本和实施成本都不可或缺。因为软件开发人员没有必要成为软件度量理论、统计方法以及度量技术的专家，他们仅仅需要知道软件度量与解决问题之间的关系，知道如何简单高效地实施度量。
6. 塑造度量文化。在软件开发中有意识地塑造一种重视记录、亲近数据、偏好图表、基于度量进行作业的习惯或者说文化，将判断、分析和决策立基于可预测性、可控制性、可改善性之上。
软件度量的陷阱：直面铜板的反面
就像铜板的正反两面，软件度量也具有正反两个方面的影响：正面效用在于通过度量获得定量化的可控过程，负面影响在于其过度滥用带来的危害，比如：
1. 软件开发的量化指标替代了开发目标。软件开发管理中定量化极为重要，这当然是指有目的的、毫无浪费的、明确的定量化。如果视软件度量为目的，那么软件度量就会陷入可悲的误区：纯粹的量化指标替代了目标，数据淹没了宗旨，任务迷糊了方向，软件度量成为软件开发过程的目标而不是手段，成为应付考核和评价的功利性工具。指标仅仅是个反光镜，而不是行进的指向标。如果不能理解软件度量在商务上的目标，那么就会出现这样的情况：收集了错误的数据，以及数据没有被正确使用。要想接近目标，双眼必须注视前方。
2. 软件开发的度量方法取代了度量理念。软件度量不仅仅包含着丰富多样的度量方法，更包含着博大精深的度量理念；不仅仅需要理解软件度量的方式方法，更要践行软件度量的理念。如果仅仅拘泥于软件度量的方式方法而忽略更为本质、更为精髓、更为深刻的理念，那么软件度量对于软件开发的意义就不再重要，因为这种情况下的软件度量虽然获得了看似完美的躯壳，却丢失了灵魂。
3. 软件开发的度量结果成为奖惩的根本依据。软件度量的结果如果成为考核和奖惩的根本依据，那么就偏离了软件度量的用途：软件度量只针对项目、产品和过程，用于对软件项目、产品和过程进行理解、分析、预测、评估和改善；软件度量从不针对个人，既不用于评估个人的能力，也不用于评估个人的绩效，更不用于作为个人奖惩的根据，这样才能保持数据的可靠性、客观性和准确性。如果软件度量针对个人，这将从根本上影响个人的态度和行为，并危害团队的绩效。永远不要让软件度量成为软件开发人员心理上的负担。
过程影响公司的首席咨询顾问卡尔·威格在其《软件度量的十大陷阱》一文中总结了软件度量应该避免的十大陷阱：
1. 缺乏管理承诺；
2. 度量得太多太早；
3. 度量得太少太晚；
4. 度量了错误的事项；
5. 度量定义不严密；
6. 度量用于评估个人；
7. 度量用于激励而非理解；
8. 仅仅收集但不使用数据；
9. 缺乏沟通和培训；
10. 曲解度量数据。
软件度量并非神话，从其诞生之日起就没有预言过任何神话。软件度量仅仅是增进软件理解、预测、评价、控制和改善的富有助益的路径。如果仅仅寄希望于以统计为基础的软件度量来获取软件开发的所谓“银弹”，就需要重温那句富有讽刺意味的名言：谎言有三种，即谎言、该死的谎言、统计数据。

单元测试与集成测试三种发展阶段。

初始阶段一：

刚实施或从未实施白盒测试的发展阶段，一个企业内只有零星的单元测试或集成测试实践，缺少成功案例。重要特点，公司成员普遍对白盒测试缺少概念，大致知道代码审查、单元测试、集成测试该怎么去做，但一涉及具体场景，对某模块实施单元测试或跨模块、跨子系统实施集成测试时，通常茫无头绪，不知从何下手。

发展阶段二：
白盒测试过程也逐渐融入研发流程，典型的例子：将白盒测试发现的问题纳入统计，研发过程中会以缺陷密度（每千行代码发现多少BUG）作为衡量白盒测试是否充分的指标，另外还会以覆盖率指标作为检查个人是否充分测试的依据。个体行为难以转化为组织行为。

开始认识到单元测试该由开发人员去做
多数尚处于混沌境界的企业会认为，单元测试应由测试人去做，可能会觉得开发人员自己编码又自己测试会陷入惯性思维，测试效果不佳。但让测试人员现实操作几次，又会冒出几个难以逾越的问题，首先是测试效率，测试人员不熟悉代码，他上手把源码读懂然后想办法做测试，要知道，单元测试面对众多琐碎的函数，随意一个开发人员一天就能写一堆新函数，所以，测试人员若把单元测试做好，通常要比开发人员自测多付10倍的精力，这一情况很致命，单元测试必然难以为继。其次，测试人员做单元测试，经常不能断定某种现象是不是问题，还得找相应开发人员去定位，问题定位了，修正问题又是个麻烦，测试人员不拥有给产品编码的权限，大量时间又浪费在反复沟通上。

会发现只拿覆盖率评估测试是否充分是不够的
不同员工做白盒测试，效果差别巨大
这种现象是每个公司都会遇到的，在白盒测试推行初期表现尤为明显。能力强的就是很少漏测，很少遗漏问题到后续阶段，能力差的，尽管他很努力的想把每件事做好，漏测总还很多。

会有白盒测试无用论产生
产生白盒测试无用论，多半不是从理论上反对白盒测试，而是实践走不通，做了不少单元测试，效果不佳，发现问题留于表面，深层次逻辑问题或接口问题发现不了，所以就认定白盒测试没多大用处。

白盒测试能否成功很大程度上依赖于牛人经理或牛人QA
白盒测试推行初期经常，执行力强一些的经理或QA，白盒测试可以推行成功，执行力弱一些的就不成功。不少企业因为尝试几次单元测试都失败了，就全盘放弃白盒，只做黑盒测试了。

有一些企业坚持下来，在一两个项目组取得成功，然后针对性的优化组织机构，比如设置专门工作推动组，建设白盒测试专家资源池，为各个项目提供测试引导人员，进一步优化流程，把白盒测试的监控点纳入流程来控制。当一个企业的组织机构与流程逐步完善，白盒测试能否成功就较少依赖于个别牛人了。

阶段化实施白盒测试，测试用例无法维护
集中一段时间编码，编码完了再集中一段时间做单元测试，单元测试完了开始集成，这时又集中时间做一次集成测试，这是多数企业实施白盒测试的模式。这一模式下，单元测试或集成测试只是特定时间段内（比如一个版本周期内的一两星期中）才实施的活动，但产品修改代码却是时时刻都在进行的，毫无疑问的会带来一个深刻问题：用例维护与产品代码维护不同步！所以，大家就经常会看到，某个产品的第一个版本可以把单元测试完整实施一遍，而此后时不时为解决问题改代码，或为追加功能改代码，单元测试很难继续，常导致单元测试只在V1版本做一遍，其后V2、V3等版本无法再做。

或许有人会觉得，为让白盒测试在版本周期内坚持做下去，不见非得引入持续集成吧？试想一下，从编码到版本进入维护，开发人员独立无干扰的编码时间有多少？而从两两开始集成之后，又占去多少时间？无疑后者占去大部分时间。如果开始集成后的每次版本修改都有测试跟进，大家岂非天天写测试用例，这不是持续集成是什么？如果不想天天补充用例，隔周、隔月，或隔一个版本补充用例，怎知你增补的用例会覆盖全部变动过的代码？

嵌入式产品的单元测试该不该上单板？这个问题更多的可归结为实践上可不可行，从理论上讲没人规定单元测试就不能上单板。但现实操作中，通信产品上单板做单元测试大部分都失败。依据实践的推论，通信软件的单元测试应在仿真环境下按纯软件的方式去做，集成测试倒是可以上单板，在真实环境下去做。

成熟阶段三：
设计用例的效率提高了，做测试不再是沉重负担。开发人员自测也上升到个人意愿，即使领导不强制，流程也不限定白盒测试必须要做，开发人员仍自愿去做测试。白盒测试已成员工的普遍行为与自发行为。

一批白盒测试专家，他们很清楚哪些被测对象是可以做白盒测试的，哪些不大容易做。即使处于白盒测试最高境界，也并非所有系统都适合完整的做测试，尤其那些严重依赖特定硬件环境的软件层，当白盒专家识别出哪些模块不宜做单元测试或集成测试后，他会考虑替代方案，比如加强代码审查、加强同行评审、为特定接口追加模拟器设计等。

总结
核心焦点是要解决测试效率的问题，只要效率提高了，接着通过组织结构与流程措施的优化，巩固已有成果，然后着重解决持续测试与深入测试的问题

为了公司急需上一项新的Linux服务的关键应用，最近一直在给部门同事做培训。非常感谢我的一位资深的同事林，培训中他的一些非常深入和尖锐的问题把整个培训质量引入了相当的高度。

我深切的感触到在技术上的挑战和质疑，对一个复杂项目的实施成功有着关键作用，同时促使我们快速的进步。

记得深圳office的总监在一次平台设计分析和算法论证会议强调的“我们的系统设计需要考虑来自庞大用户群和复杂的用户行为的技术挑战”，那一次会议公司最终决定引入成熟的第三方技术。

往往，我们在学习的过程就缺少应用带给我们的挑战，导致我们学习效果不理想。

1. 安全测试要求更高。由于涉及关键数据众多，在用户输入验证、输出展现、安全交互、权限系统设计方面的要求更高。防止SQL注入、命令注入、XSS、缓冲区溢出、整数溢出等主要安全问题围绕整个软件生命周期。

2. 流量、资源消耗、计费等监控粒度更加细致。

3. demo应用程序以及API函数说明书。

4.部署模式测试。

   API部署范围不应局限于在PC/PC Serer上， Open API也应该部署在流行的google application engine平台以及Amazon AWS上进行测试，以满足不同层次的开发商需求。

5.类与方法(函数)测试.

6.界面UI TEST.

7.发掘待测系统的信息:

阅读说明文档

研究待测系统的源码

编写试验性的stub 程序

研究中间语言的代码

使用反射技术做界面测试