今天在MSN上遇到了前不久MSN上遇到的人（感觉像是while…done）。
今日得知
1、美女。
2、QA
且不谈论美女，来谈QA。
我一直都很喜欢作QA的人，WHY?因为我喜欢精品，然而QA就是保证精品的人。同时QA的管理体系很成熟，我认为要比运维理论成熟，所以一直都想能从QA的管理理念里学习一些道理来。我想最主要的是要学习QA的思维模式或者方法，一个好的思维模式远远比好的技术强。与此类同的是中国结，玩中国结其实也是在学习一种思考的方式。
今天在网上找了找一些QA的定义单词，得到以下摘录。保存下来没准哪天有用。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
首先看到了如下讨论：
http://www.maiweb.net/ask/other/ask109744.htm
什么是白盒测试，什么是黑盒测试，有几种测试得方法。
简单的说：
白盒就是看代码
黑盒就是测试功能
所谓白盒测试就是要求测试人员在测试的时候，需要知道程序的那个部分出了问题，需要具体到代码的函数或类中。
而黑盒测试却不要求测试人员懂得编程的知识，只是按照程序的功能一项一项的测试，并将有问题的功能点找出来就可以了。所以黑盒测试又叫傻瓜测试。
据我所知，测试方法共有21种之多。你可以到UMLCHINA.com中去查找相关的资料。
单元测试 — 看源代码 分析程式内部逻辑结构
集成测试 — 对设计的检测
系统测试 — 测试功能
交接测试 — 即确认测试 测试是否符合用户需求
黑盒测试法：一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性.
白盒措施法:一般用来分析软件的内部结构,对软件的逻辑路径进行测试.
一般在单元测试时采用白盒,而确认测试时采用黑盒.
你是说单元测试吗？白盒
呵呵 与我想的答案不同 呵呵 静态测试主要是 输入 输出 应该是黑盒 单元测试不一定就要叫白盒 呵呵 可能是个人的出发点不同吧 看封装的角度不同
软件缺陷—-软件中含有符合下面5 条规则之一的问题称为软件缺陷：
软件未达到产品说明书标明的功能。
软件出现产品说明书指明不会出现的错误。
软件功能超出产品说明书指明的范围。
软件未达到产品说明书未指出但应达到的目标。
软件测试人员或用户认为软件难以理解，不易使用，运行速度缓慢等问题。
测试案例—-测试用例的别名
黑盒测试—-指测试人员通过各种输入和观察软件的各种输出结果来发现软件的缺陷，而不关心程序具体如何实现的一种测试方法。
静态测试—-指测试不运行的部分，例如测试产品说明书，对此进行检查和审阅.
静态白盒测试—–指在不执行的条件下有条理地仔细审查软件设计，体系结构和代码，从而找出软件缺陷的过程。有时称作结构分析。
动态测试—-通过运行和使用软件进行测试。
探索测试—-通常用于没有产品说明书的测试，这需要把软件当作产品说明书来看待，分步骤逐项探索软件特性，记录软件执行情况，详细描述功能，综合利用静态和动态技术来进行测试。
等价区间—-指测试相同目标或者暴露相同软件缺陷的一组测试用例.
测试设计—-提炼测试方法，明确指出设计包含的特性和相关测试。如果要求完成测试还明确指出测试案例和测试程序，指定特性通过/失败的规则。
软件QA—-QA= Quality Assessment 质量评价。防止软件缺陷称为软件QA。
TQM 或者TQC 原理—-TQM(全面质量管理)或者TQC(全面质量控制)。其原理是，用集中的质量评判团队来负
责质量是不实际的，因为工作的人不负责质量，所以他们不会设法实现质量评判目的。
要想制造高质量产品，需要创立从管理开始自上而下的质量意识，使全体成员共同承担
质量责任。
SQC—-软件质量控制(SQC)是测试团队很常用的名称。该名称来源于制造行业，其中QC 检验
员对生产线上的产品进行采样、检测，如果测试失败，他有权停掉生产线或者整个工厂。
测试团队很少有这种授权。
Murphy 法则—永远不会有足够的时间把事情做好，但是总有时间返工。软件开发小组需要遵循一个过
程，花费一些时间，变得有条理，一开始就设法作对。
其次看到了对白盒测试的更多定义：
http://www.enet.com.cn/article/2006/1101/A20061101279923.shtml
什么是白盒测试
白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
1）保证一个模块中的所有独立路径至少被使用一次；
2）对所有逻辑值均需测试true和false；
3）在上下边界及可操作范围内运行所有循环；
4）检查内部数据结构以确保其有效性。
“我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？”答案在于软件自身的缺陷：
·逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。
·我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。
·笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。
正如Beizer所说的：“错误潜伏在角落里，聚集在边界上”，而白盒测试更可能发现它。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
摘录完毕。
