总结测试开发中常见的程序设计问题，这篇的主要内容是关于断言的使用。如果有任何有疑问，欢迎指出和讨论，感谢。
一、断言和容错设计的使用
1、可以用static_assert执行编译时的断言检查
如：static_assert(sizeof(char *) == 8, "不是64位模式")
2、避免用断言去检查程序错误：
1）外部不可靠的数据，应该做严格检查才能放到系统内部，这个时候它是守卫，提前检验和过滤不合理的数据和参数，应该使用错误检查处理代码（如KGLOG_COM_PROCESS_ERROR等），
而不是用断言来做检查
*外部不可靠的数据：是指如不合理的用户输入、或其他模块传入到该模块的消息或数据，
有点像是对项目组外的员工，要动用项目组的资源，是需要经过审核的
2）系统内部的交互数据（如程序内部的调用），可以用断言来检查意想不到的错误，或者程序内部的假设。（即检查它的潜规则、逻辑边界、隐形假定、输出或内部状态是否如预期）
*因为系统内的调用者一般情况下是有义务负责传递给自己内部的数据是合理正常的数据
就像项目内的员工，对于使用项目组的资源的门槛就会低很多
*可理解为assert和出错处理是对所写程序建立不同的信用级别，也方便在Release版可以性能更好的运行程序
3）推荐针对public的函数或接口的入口处对参数做严格的错误检查；对于Private的函数或者只有这个模块能看到的，可以用assert
3、容错性程序设计常常要解决的是：现实中，防止用户数据丢失或程序崩溃而采取的措施。只是除此之外，也许可以适度考虑：
*我们是否希望在进行容错性程序设计时，错误要不要被隐瞒？
*实现程序时，如果有错误（特别是意料之外的错误）发生时，
1）我们有线索吗？能得到什么？怎样更好的定位和处理它？
2）需要报警方案吗？
3）有预案吗？
4）可能的影响大吗？
4、避免断言中使用改变环境的语句：
如不正确的代码：
int Test(int i)
{
assert(i++); //debug版和release版的i值就会不一样
return i;
}
int main()
{
int i = 1;
int nValue = Test(i);
printf("%d\n", nValue);
return 0;
}
合理的形式：
int Test(inti)
{
assert(i);
return++i;
}
注：与改变环境的语句类似的行为是宏定义。
*请尽量不要在assert中调用宏，以防止宏的副作用
以谦卑的心感受，以感恩的心生活
