探索式测试--笔记1

第2章 手工测试

 

• 软件缺陷的根源

   软件缺陷（bug， 也称隐错）的根源来自于软件开发本身。本书中主要讨论两种缺陷：程序员引入的缺陷和运行环境所致的的缺陷。

• 缺陷预防和检测

   因为错误是不可避免的，所以需要讨论一下如何尽可能地把缺陷排除在软件开发周期之外，以便尽量减少错误并提高软件质量。事实上，这主要有两大类技术：分别是缺陷预防与缺陷监测。

   ××缺陷预防

   缺陷预防一般是从软件开发人员的角度来说的，包括编写更好的设计规范，实施代码审核制度（code review)，运行代码静态分析工具（static analysis tool)，运行单元测试（unit testing)(往往是自动化单元测试)。所有这些缺陷预防技术都有一些根本问题，一一列举如下：

   问题1：“开发人员只能是个糟糕的测试者”

   因为开发人员是从编写程序的角度出发，所以他们必然会有盲点。测试人员拥有的那种“如何才能攻破这个功能”的态度和开发人员那种“如何才能实现这个功能”的态度是相辅相成，缺一不可的。并不是说开发人员不需要做任何测试，像格式化，数据验证和异常处理都需要在开发工程中被及时发现处理。

   问题2：“处于静止状态的软件”

   如果程序不在真实的运行环境中运行起来，很多缺陷不会被触发。

   问题3：”缺乏数据“

   软件需要接收输入和数据，才能覆盖程序中的各个代码路径。具体执行的是哪些代码路径由程序获得的具体输入、当前软件的内部状态（内部个个数据结构和变量的值）、外部因素（如数据库和数据库文件）来共同决定。往往会出现这种情况，当软件运行一段时间后，当数据量累积到一定的程度，软件出现故障了。这是因为开发时的测试一般要起在短时间内容必须完成，所以开发时往往不能覆盖这样的情况。

   ××缺陷检测

   测试人员一般有两种形式的动态测试：自动化测试（通过编写代码来测试一个应用程序）和手工测试（使用程序的用户界面，手工输入数据进行测试）。

对于自动化测试的评价可以说是毁誉参半。一方面，自动化测试可以执行无数次测试用例，尤其在做回归测试的时候，自动化可以被重复运行多次。但是自动化测试的脚本也是需要很大的精力去维护的，这个时间的花费也是相当大。

 手工测试

手工测试（manual testing) 顾名思义就是需要由人来动手进行测试。有人来进行手工测试，可以最大限度的发挥人的主观能动积极性，设计出真实的用户情况，在真实的用户环境中使用真实的用户数据，同时可以识别出那些显而易见的缺陷和那些比较难以察觉的缺陷。如果想发现与应用程序业务逻辑相关的缺陷，手工测试是最理想的选择。业务逻辑一般比较复杂，这里使用自动化测试一般不能获得理想的效果。

探索式测试

测试人员在测试应用程序中可以天马行空地想怎么测就怎么测，利用应用程序所提供的信息自由发挥，没有限制，不受任何约束地探索程序的各种功能。

用于记录探索式测试结果的最佳工具就是那些截屏软件和记录击键的软件。探索式测试的缺点在于测试人员有可能在测试中没有重点，从而漫无目的地尝试各种情况来试图发现软件缺陷，这会浪费大量的时间。如果不充分准备，没有条理，缺乏方针就盲目测试，就会对某些功能重复测试多次，导致测试效率低下，在有多个测试人员或测试团队共同测试的时候，该情况就更为严重了。这里要强调指导方法的重要性。探索式测试有两种指导方法，他们都可以帮助测试人员做具体决策。一种称为局部探索式测试法（exploratory testing in the small）, 它辅助测试人员在测试过程中即时做出决定。另一中称为全局探索式测试法（exploratory testing in the large）, 它用于帮助测试人员设计整体测试计划和测试策略。最后，如果把探索式测试的实质和使用脚本的手工测试合并起来，就可以得到第三种探索式测试法。