软件测试杂谈

 

软件测试杂谈

在国内做过项目管理，做过架构，做过开发，也做过测试，一直在反思每一种类型的工作本质到底是什么？应该怎么做才是最优秀的？这里想总结一下在软件测试这个领域个人的一些心得。

 

软件测试就是为了保证软件项目的工程质量而从事的一系列测试行为，本质上来说，寻找产品的缺陷，分析产品的性能，保证产品的功能符合需求，评估产品的易用性等等，都是测试人员应该做的。我们经常看到的一个测试人员的工作流程是：

1.分析理解产品的需求

2.设计Test Scenario和Test Case

3.构建Test Plan -> 执行测试

4.总结缺陷和质量评估报告

 

在笔者从事的公司所体会到的这个流程中最容易出现的误区和问题主要有这么几个：

1.       Tester设计的Test Case是否有质量？能否高效的测出产品的功能质量？

要写出高质量的Test Case，当然首先要对产品有非常深的理解，知道某个功能的作用，甚至了解此功能的核心技术是什么。笔者见到最容易犯的错误，就是设计场景和用例的人是完全根据自己的经验和能力来思考，很多时候他已经默认了这个用例最后是自己来执行，所以会按照自己能理解的范畴来描述步骤，并且主观上判断某些方面的测试做不到，或者凭现有的环境、测试人员的技术（更多的时候以自己做参考），达不到更深入测试的要求，所以就会自然而然的降低用例的繁琐程度或者测试执行的难度。

 

真正优秀的测试用例设计者应该牢牢把握客户的需求是什么，体现在产品功能上的要求是什么。应该回避思考测试的执行者，回避现有测试环境和技术的瓶颈，站在客户的角度，描述希望看到产品这块功能能做什么，期望的性能怎样？可能出现的情况有哪些？这并非说测试用例的设计是夸夸其谈，而是充分尊重客观实际的原则。当然测试人员可以根据自己的经验来改变测试步骤，突出某些侧重点。但侧重点的不同一定是根据对需求的理解来引导的。

 

2.       Test Plan构建出来是否合理，覆盖率，侧重点是否合理？

做过测试的人都知道，测试要想100%的覆盖是不可能的，那么每次新功能的发布，版本的更新，又如何来引导测试覆盖范围和各个模块功能路径覆盖的比例呢？每次发布周期也不会完全相同，有的三个月，有的半年，有的甚至1年之久，即使预计了周期，在未来也可能发生变化，那么Test Plan又如何灵活的设计来适应可能出现的任何情况呢？

 

笔者认为，Agile的一些思想可以帮助我们找到办法。开发在每个短暂的周期里（sprint），交付一些可以使用的功能，测试的覆盖面积，应该围绕着每个短暂周期里交付的功能来定义。当然最好的效果是测试对产品的架构也有一定的了解，通过以往积累起来的经验，或者和开发的沟通，来了解交付的功能对其他模块的影响，这样就能果断而且正确的减少不必要的测试。原则上，系统中已经存在的功能（或者说代码），被测试验证过正确健康之后，在未来的测试中可以降低覆盖率和测试粒度，把更多的精力和主要的资源用在频繁改动和新出来的功能上。

 

当然，要完美做到这一点，Agile的思想也提到，最好能让自动化测试更早的介入项目中。对于已经交付的功能，应该尽早的编写自动化测试，把更具有经验结合判断的手工测试资源更早的释放出来在当前和未来要交付的功能上。（另外，如果开发能做到TDD，测试驱动开发，其实对于质量的保障会更加稳妥）

 

3.       整个测试周期的人员安排，时间安排和测试任务量，是否科学？在出现变化的时候，整体策略是否灵活？

过早的去构想未来的计划，是最不明智的。当项目的周期很长的时候，我们应该合理的把整个schedule划分更小的sub schedule，然后为最近的这个sub schedule来制定计划，安排资源。

 

笔者见过这么一种做法，具有经验的测试人员把该有的测试都准备好，定义为一个个的task，无论哪一次发布，都会把这些task几乎不漏的一个接一个来完成。时间紧的时候，可能做得粗糙一些，时间充裕的时候，就使劲细化每一个task。这样容易给测试人员带来一种，一阵不变的气氛，就比如在大学的生活三点一线：寝室->食堂->教室->食堂->寝室，往复循环…

 

笔者不想去否认这种做法，但个人觉得这一定不是最好的做法。当今软件的发布，产品的更新换代，瞬息万变，没有什么流程是可以一沉不变的走下去的。为了能最好的适应整个周期项目的变化，应该时刻保持从客户那里，产品负责人那里，甚至销售那里，聆听有价值的信息，然后合理的调整资源。在每个task开始之前，都应确保几件事：

1.       已经传达了收集起来的所有信息给大家

2.       大家也都认真思考过接下来的一个短暂周期里，开发要交付的，测试要关注的功能有哪些

3.       之前申请的资源，包括人力、机器，现在看来还是否够用？需要调整的，应该尽快着手准备

 

最后，再保证每个短暂的周期里，参与测试的人员都能留有一部分时间来反思，对完成某些功能的测试所需要的技术，包括产品的核心技术上，是否还有提高的空间？而某些测试的策略是否还可以改善，以便在下一个短暂的周期里，能够让测试小组受益（实际上整个项目也会因此受益）

 

End

笔者只是谈谈自己对测试的一些看法，一直认为没有什么理论是完美的，理论再先进，如果不能跟每个公司实际的情况充分结合进而演化，那么先进的理论也只不过是象牙塔石碑的文字，毫无用处。