我对测试的感悟 - 2009/10/18 （转）

http://blog.csdn.net/quicknet

今天下午去复旦大学参加了5ETesting组织的一个测试人员的交流活动，该活动主要是介绍了E测中国团队和他们现阶段的一个项目和产品。其中重点介绍了QTP项目，活动之前我对QTP是完全不了解，通过期间的介绍我才知道它是QuickTest Professional的缩写，是个自动化测试的框架。其实参加这个活动并不是想去了解某个具体的框架，是难得有个这样一个测试的人员的聚会，想借此结识一下更多从事测试工作的朋友，了解他们对测试的看法、体会和经验。

    也是难得能从自己所从事的测试工作中闲暇下来，跳出自己的测试圈子，听听别人对实际工程中测试工作的感悟，所以我也利用听讲座的机会反思了一下自己这些年来的测试经验，简单总结如下：

 

1.   在项目开始阶段，测试用例不宜太多、太细、太具体，应该随着项目的不断深入，逐渐地增加测试用例的数量、覆盖的广度和具体程度。 

解释：之所以这样，是因为项目的初始阶段，产品或者项目有太多内容和因素无法确定下来，过多的测试用例只会增加后面维护和修改用例的成本。但往往项目的初期，大家群情激昂跃跃欲试，容易把本可以简单的工作做的很复杂和过于“精致”。等到项目做完的时候，再回首项目初期时所做的“精致”的东东，多半早已被删减的所剩无几或者是改动的面目全非。那么项目的初期的，测试人员应该做些啥呢？多了解项目的背景、用户的需求，熟悉和改进已有测试框架和流程。

 

2. 对于自动化测试用例而言，其每一个执行和验证步骤都应该有详细的结果输出到日志文件中。 

解释：自动化测试用例在提高测试执行效率的同时，也引入了很多需要人工辅助的地方。自动化测试用例在执行完毕后，需要人工去分析运行的结果，失败的结果有可能会有比手工测试更多因素造成，包括：产品缺陷、测试框架缺陷、测试用例缺陷、测试执行环境设置问题。没有详细的输出日志文件，你很难快速的分析和定位出测试用例失败的原因。如果每次都需要很费劲的才能分析出测试失败的原因的话，那引入自动化测试用例的优点何在呢？

 

3. 寻找适合自己项目的手工测试用例和自动测试用例的合理比例关系。 

解释：2:8还是8:2，或者其它的比例关系。没有去给自己的项目设置一个别人的经验值，多花点是时间研究一下自动化测试在自己项目中的可行性、实现的难度和成本、执行的必要性和可靠性，逐步去摸索得到。理论上自动化测试用例比例越高越好，但如果你的自动化测试框架不稳定、难于开发和维护，那还是越少越好。

 

4.  测试用例更需要注释，而且是需要更为详细的注释，详细到何种程度呢？应该让你的手动测试用例描述、自动化测试用例的脚本或者代码足以取代项目经理的产品功能说明。 

解释：认真观察一下软件开发从始至终整个过程中产生的各种“副产品”: 项目需求说明、邮件、详细设计、开发人员的产品代码、测试用例、缺陷描述等等，这其中那些是在随着产品的开发过程在不断地更新、始终准确描述了产品的最新功能呢？ 应该只有两个：产品代码和测试用例。其它的呢？它们实际上都是匆匆的“过客”，服务于开发过程的某个特定的时间片段，服务于对产品代码和测试用例的更新。试想一下你在产品初期编写的需求，和产品实现完成之后功能还一样吗？绝对是不一样的。而产品代码实现了产品功能，但是它的结构复杂，很难从它直接描述出产品的功能。测试用例则不同，其结构工整，组织有序，是天生的用来描述产品的材料。

 

5.  测试工作不只是要测试代码，更可以提前到去测试一下项目早期的文档。 

解释：测试人员应该在早期就去测试一下项目早期的各种文档，去读去想这些文档，发现其中不完善的逻辑、不清晰的描述、混乱的定义、哪怕是错别字和拼写错误。这样做是为了能够更早期发现项目的问题，集思广益，同时也是让测试人员更早更深的了解项目。

 

6.  测试人员不应该被手工测试用例或者自动化测试用例限制手脚和广阔的思路。 

解释：已经写好的测试用例只能够帮你覆盖住已明确的功能和缺陷，无法帮你发现新的产品问题。测试的目的是去发现更多的问题，不要把自己限制在测试用编写的常规工作中，应该多留些时间去想客户还会怎样使用你产品，多些“天马行空”想象力。

 

 

 

8.  减少UI界面测试用例的数量，多一些单元测试和模型测试。

解释：UI界面测试的框架都还不是很稳定，执行时间长测试结果分析困难。

 

9.  任何测试框架等应该考虑它所依赖的软件生命周期（ALM）管理工具。

解释：现在的软件开发更为复杂，更强调协作，单独的任何工具已经不再适应这样的需求了，测试工具和框架也是如此，需要喝ALM工具相结合，以促进开发过程不同角色的沟通和协作。

 

10. 单个测试用例的测试步骤不要太多，6/7步足以。

解释：过多的步骤只会带来执行、实现和分析的难度。可创建多个小的测试用例，考虑用它们的组合来实现更复杂的测试。

 

11. 软件产能品的复杂性和多样性，决定了不可能有一种简单万能测试方法和自动化测试框架能聪明到把它们都覆盖住。

 

        随便总结了一下，没想到写了这么多。有些还仅是些初步的项目，有待进一步的完善和补充。希望这些个人的测试工作实际体验能够给大家以帮助！不早了，11:00PM，要休息了！身体是继续更好测试的本钱！ 

 

7.  调动测试人员的热情提高它们在团队中话语权。

解释：很多人来做测试并不是真正喜欢，而是因为门槛低，在别无其他可选择的情况只好做测试了。在实际的工作中，很多更是只想把测试作为进入这个行业的“驿站”或者“敲门砖”，时刻等待着机会去转为开发人员或者管理人员。造成这样的结果也是必然，国内这个行业从对测试人员的认识和待遇就是这样一个现状，多半是道理上把你说的很重要，实际工作中测试人员总是在从属地位难有真正的话语权，很少能有自发的热情。所以自然而然的，测试人员也就时刻“居安思危”。 对于一个公司而言如何来改善这种状况呢？高层领导的认知很重要；测试过程不要死气沉沉，多谢Bug Bash和Application Building这样的活动；产品经理/项目经理/开发组长等应该注意聆听测试人员的意见，团队例会时请给你的QA优先发言权；加强软件生命周期工具（如Visual Studio Team System, IBM Rational等）在测试中的应用，这样可以增强测试过程的规范性、增加测试成果的可度良性和透明性，避免开发和测试人员之间“用嘴喊”的原始合作方式，用文档/邮件来记录发现的产品缺陷、记录测试用例、测试工作项，只会让人觉得测试是一个没规范、随机的过程；发现的任何测试本身的问题，如：测试用例缺陷、测试框架缺陷等，也要以同产品Bug一样对待并记录下来，由测试人员来修复。