《构建之法》一周小结

软件测试

团队统一思想要从基本名词开始。bug：软件的缺陷  test case：测试用例（测试用例描述了一个完整的测试过程，包括环境测试、输入、期望的结果等）。  test suite：测试用例集（即一组相关的测试用例）。

bug可以分解为：症状（symptom）、程序错误（fault）、根本原因（root cause）。

症状：即从用户角度看，软件出了什么问题。

程序错误：即从代码的角度看，代码的什么错误导致了软件问题。

根本原因：错误根源，即导致代码错误的根本原因。

按测试设计的方法分类，测试分类有两类方法：黑箱（black box）和白箱（white box）。

这只是软件的入门知识。所谓黑箱|白箱，是指软件测试设计的方法，不是软件测试的方法。

黑箱：指的是在设计测试的过程中，吧软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计（Be-havioral Test Design），即从软件的行为，而不是从内部结构出发来设计测试。

白箱：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。

在实际工作中，我们不应画地为牢，严格只用某一种测试设计方法。我们对系统的了解当然是越多越好。所谓“灰箱”的提法，正反映了这一点。有些测试专家甚至希望我们忘记全部的“箱子”及其颜色。

进一步说，我们并不是要禁止懂得程序内部结构的人员来进行黑箱测试设计，只不过是在设计时有意不考虑软件的内部结构。例如，在测试程序内部基本模块时（单元测试），通常要求由对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且对内部基本模块的“行为”通常没有明确的定义。另一个例子是软件的“易用性测试”，在设计此类测试时，没必要纠缠于程序的内部结构，而是应着重于软件的界面和行为。但是软件易用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和“白箱”没有简单的难度高低之分。测试用例写出来之后，大家可以忘了它们是从哪种颜色的箱子里出来的，使用就行了。

更重测试方法：

单元测试、构建验证测试、验收测试、“探索式”测试、回归测试、场景|集成|系统测试、伙伴测试、效能测试、压力测试、内部|外部公开测试、易用性测试’

 

转载于:https://www.cnblogs.com/qianhongzhang/p/6940914.html