C/C++单元测试理论精要（五）
第二章 征服可测性难题
2.1 可测性问题详解（1）
单元测试效益特别高，方法也很简单，但却尝试的企业很多，成功实施的企业很少，为什么呢？主要原因就是难于突破可测性问题。“可测”这个词，意思已经很明白了，如果不“可测”的话，那就是不能测，没法测，就是做不下去，或者困难太多，成本太重，热情被逐渐消磨，最后做不下去。所以可测性问题是单元测试的关键，是我们首先要解决的。
可测性问题是指代码的可测性很差，导致测试很困难，这是单元测试的关键阻碍。为什么代码的可测性会很差呢？原因是什么？一般来说，这些原因导致了代码的可测性差：项目很复杂，开发流程不规范，耦合度很高。耦合是指代码之间的互相依赖，例如一个函数调用另一个函数，就是耦合。
一般的建议是改进开发流程，提高代码可测性。但从实践来看，这是不现实的。可测性差在企业项目中普遍存在，有其客观原因，很难改变。首先，企业项目本身就多是很复杂的，这是需求决定的，改不了。其次，程序并不是虚无的，程序是客观事物的反映，客观事物本身是互相关联，互相纠缠的，必然形成代码间的耦合。第三，流程改进是一个长期的、渐进、困难的过程，不可能短期内实现飞跃，更不是引进几个工具或者规范就可以做到的。这方面我有过教训，几年前，我也认为可以通过流程改进来提高可测性，也给客户推荐过相关的解决方案，结果都差不多：劳民伤财。所以，可以说，可测性差有其必然性，这是客观现实。
那么，如何解决可测性问题呢？只有从测试技术的角度来考虑，才有可能找到真正有效的途径。要解决问题，我们首先要对问题有充分的了解，现在来看看可测性问题具体包含什么。
一个函数要“可测”，要做到两方面：第一是能够独立运行，第二是要能够覆盖输入分类。为什么要覆盖输入分类呢？因为单元测试的目标是覆盖代码单元的功能逻辑，要做到覆盖功能逻辑，就要覆盖输入的所有分类。如果代码可测性差，又没有办法解决的话，要么没法独立运行，要么做不到覆盖输入。这两点有一个做不到，就是不可测，或者达不到预期效果。
我们先来看看独�
相关文档：
1.引言
本文的写作目的并不在于提供C/C++程序员求职面试指导，而旨在从技术上分析面试题的内涵。文中的大多数面试题来自各大论坛，部分试题解答也参考了网友的意见。
许多面试题看似简单，却需要深厚的基本功才能给出完美的解答。企业要求面试者写一个最简单的strcpy函数都可看出面试者在技术上究竟达到� ......
试题5：编写一个函数，作用是把一个char组成的字符串循环右移n个。比如原来是“abcdefghi”如果n=2，移位后应该是“hiabcdefgh”
函数头是这样的：
//pStr是指向以'\0'结尾的字符串的指针
//steps是要求移动的n
void LoopMove ( char * pStr, int steps )
{
//请填充...
}
� ......
题外篇：单元测试难于长期坚持的原因与解决探讨
上一篇《单元测试效益》，有网友评论说：“单元测试的好处基本人人知道，就是难坚持！”。这一评论严重提醒了我，不错，“难坚持”也是一个普遍现状。如果不能坚持，那一切都是白搭。因此，这里插入一个题外篇，探讨单元测试难于长� ......
输出斐波那契数列前N个合数，四个一行，N由使用者输入，介于10到30之间。
#include<stdio.h>
#include<math.h>
int fab(int);
int judge(int);
int main()
{
int a[30]={0};
int i,n,t=0;
do
{
printf("Input the number\n");
scanf("%d",&n);
}
while(n>3 ......
第二章 数据类型
一、数据类型分类
1 联合类型
2 函数类型
3 数量类型
3.1算术类型
① 基本数据类型
整型（包括char）
浮点型 ......
