工作总结之测试

记得我刚工作的时候，还完全不明白测试是怎么回事，现在要说测试倒也能一套一套的说了。

测试分很多种，UT，IT，AT，场景测试...

还可以这么分，自测，他测，依据测试设计书测试，Free测试...

UT可以利用很多工具，比如NUnit+代码测试覆盖率工具。

NUnit，广受好评，可以过滤掉大量的bug，不过我在工作中运用不多。

代码测试覆盖率工具，可以统计出有多少分支会被跑到，有多少分支没被跑到，可以一目了然的看出来，分支走没走全。

IT，结合测试，但目前我工作中的IT没有达到结合测试的目的，本来是应该跟系统中的其他业务进行连接，测本身业务的同时测试两者之间的联系，能发现些业务设计冲突，矛盾的问题，早发现，早根治。

AT，验收测试，只是关注功能实现，用户使用，不会注意小的细节

场景测试，整个系统内部关联业务关联一起测试，验证数据流，业务流有没有问题，有没有设计漏洞，有没有接口设计错误等。

为了保证质量，测试一般都会进行几轮，所有的Case都会在修正bug的基础之上来全面测试。但其实在不知道bug是怎么样修改的情况下，如果开发人员改完自测没有做好，埋下了雷，想要扫出来，还是挺困难的。

近几天公司总是在说测试，用了那么多工时，却没有发现那么多问题，在最终用户那里还是出现了如此之多的bug，天天分析为什么，以及对策，还要加强场景测试。不过个人觉得，这个时侯，做场景测试，没有什么必要，因为这些bug都是在IT放过，或者在集成埋下，再不然改bug造成bug，无非也就是这几种，跟场景没有什么关系，虽然在最终客户那里，发现的bug，操作都很简单，也都是基本逻辑，出错是不能原谅的，但都基本不是业务间的bug，而是内部bug。为什么会归咎于场景测试不够呢，因为在用户使用看来，就是那几个场景，没有什么特殊的，但其实，操作简单，数据复杂，每天假设有100次某一个操作，这100次的数据都是不一样的，所以才会出错，而这100次的数据，在IT的时候，没有进行数据设计，没有详尽的说明，没有人想到，测到，就变成bug，影响到了用户评价。如果非要归因于测试，还是一个原因，数据不够多样，没有想到会出现此类数据。最终还是归咎到人，测试人员水平不够...

 

前几天看人月神话，里面有一句话，虽然软件工程管理在不断的探讨人和管理，一直想抛开人的因素，或者不让人成为主要因素，但每隔一段时间，就还是会返回到人是根本因素这个结论上。

测试当然也是不能跟人分割开的，测试人员的资质，水平，经验都决定了测试结果的好坏，发现bug的多少，有效bug的多少，最终决定项目的质量。

那么，怎么才能让一个刚进入项目的人测出问题来？

首要条件是这个人，要有兴趣去了解项目是在做什么。也就是我们说的进行深入的业务学习

其次，要有一个系统的观念，哪些是测试重点，哪些可以后面再细抠。一般每个阶段的测试目的也是不一样的，所以，每个阶段对某些问题的重视程度也是不一样的。

接着，划分完测试重点，当然就是设计测试用例，编写测试式样书，这个阶段需要特别注意，不是任何人都可以写测试式样书，详略要得当，做到简明扼要不是一件容易的事，而且同时要将所有的排列组合都列出来，衡量哪些要写，哪些能让人发散思维

但是，仅仅通过测试用例，测试式样书来保证测试的质量是不够的，这时候就跟人有很大的关系了，如果测试人员有相关项目经验，自然会想到一些可能出错的地方，通过free测试来挖出bug，如果测试人员没有相关经验，也许就会抓着一句话研究半天，最终还是没找到重点。这时就需要人去引导，而不是让他们自己去研究，可以通过讨论，把不明白的先弄明白，就我个人看来，如果文档写的好，能引发共鸣，能让人从测试中理解业务，能让人发散思维，这样对人的帮助是很大的，可能测完一遍，测试人员就能明白业务目的，流程等，自己就能想到要测什么。系统的写测试式样书也是一个待研究的课题。