上一篇畅所欲言了一遍开发，今天继续聊聊测试，其实我一直脑补的是这样的画面：

测试小姐姐千娇百媚的走到你的面前，娇滴滴的说：

小A，怎么这里又这样啦？人家今天还要跑很多的测试用例，总这样可能完成不了任务哦，想想办法嘛。

我们的开发工程师小A听到以上言语，立马由大猪蹄子变身为超级暖男外加担当男人，心中充满无限自责，立志善待每一行代码，胸脯拍的DuangDuang响：

你放心，以后绝对不可能出现这种问题，要是再出我一定吃点什么。

从此以后，我们的小A开启职业生涯，遇神杀神，见招拆招，走向人生巅峰。

画面很美，美的都不敢看，现实很骨感，硌的我肋骨疼。大猪蹄子之所以成为大猪蹄子，是因为他永远不靠谱，最靠谱的还是得靠自己，那么测试该怎么做呢？

前些日子听人说书，里面有个关于测试部门的定位，我倒是觉的挺好的。测试这个部门，日常的工作其实就是验证开发出的应用程序是否符合需求，是否能够达到上线的标准，保证项目的顺利完结。但是执行起来却各有定位，比如小点的团队，1-2个测试人员，就是拿着鼠标凭经验一通乱点；稍有改进的，写一写测试用例，一个测试团队按照测试计划，分工明确，有条不紊的完成测试工作，基本上还是点点点；高大上一些的，就会搞搞自动化测试工具了，一些固定的套路全都先用工具跑一遍，然后再点点点。除了点点点，还有没有其它的工作能够保障产出的应用程序符合上线标准呢？说书的给出了答案，往大了做，向全生命周期质量保证上靠，制定一系列规则制度、工作流程保证项目或产品的正常产出。

那接下来，就之前的各种摩擦，说说我对于测试部门日常工作落地的想法：

1. 积极参与需求评审。测试很重要，那就更应该有担当；测试对于找茬很有经验，那就应该从开始就找茬。发现潜在的危险，指出之后测试面临的问题，这都对整个团队的日常工作大有好处。因为测试在项目流程中处于末尾，普遍的现象是测试接收到的信息要比需求、设计、开发人员晚，信息的不畅通，导致很多的冲突，尤其是与上游开发人员的冲突。所以积极的参与需求评审，更早的达成统一共识，对日后的工作有的很大的意义，至少能够减少扯皮的时间。

2. 尽所能了解设计结构。因为测试不是开发，不太可能让他们详细的了解整体项目的架构，但是尽可能多的了解，是对测试人员日常工作有好处的。比如了解前端和后端的通讯协议，他们就可能更好的做安全和响应时间的测试；再比如了解前端页面的构建方式，他们可能更好的做浏览器兼容性和相关的布局测试。

3. 基于需求规格的测试用例。测试们都知道写测试用例，不过测试用例的详尽程度和覆盖情况有时候就不是那么理想了。所以这时候就需要一份详尽的需求规格说明书，至少基本功能的拆解、边界值的设定、异常的处理、操作的提示都应该有注明。如果没有这份需求规格说明书，要么让相关人员去补，要么测试自己去补。我倾向于测试自己先补，因为在这过程中，又会再了解一遍需求，同时跟需求、设计、开发人员的沟通确定，也会使测试人员更加理解他人的想法。再说，求人不如求几，我先做典范，喷起他人也硬气。

4. 自动化测试工具。人力有穷时，这是肯定的，就算加班加班，一天撑死了10个小时不错了。光靠着垒人，显然是不现实的。适时的引入自动化测试工具，把枯燥的重复的一堆破事交给机器去做，腾出手来去干一些有意义的事情岂不是更加开心。当然，引入的时机也需要拿捏好，不可能只有2-3个测试人员，1-2个月的小项目，还专门去鼓捣一下自动化测试，得不偿失。你要非得说，我就是有志向，我愿意不睡觉也得去鼓捣，那我只能说：嗯，我支持你，放飞自我吧，少年。

5. 定制度定流程。测试就是个挑茬的部门，哪天挑不出茬了就证明有问题了。质量控制嘛，不能光靠嘴上说，还得实际去操作。控制控制，就是让人失去自由，当然了也不是禁锢，而是在一个合适的范围内折腾，跳出圈的全部都得打屁屁。所以得定制度定流程，而干这事的非测试莫属，谁让你们是挑茬的，谁让你们最容易吃尾气，谁让你们是最终产出物的最后一道闸。需求，你得有评审团，你得通过签字了才能搞，这是定范围。设计，你得有，不然开发小年轻全都放飞自我了，瞎忙乎，所以我得看你有没有设计这道工序。开发，走查你得有个报告吧，送测你得有个送测单吧，就相当于签字画押，开发保证我这块真没问题了，要是有问题就吃点啥。测试，没测试用例看天吃饭肯定完蛋，没有测试计划也得完蛋，没有测试报告谁知道发生了什么。所以嘛，定制度，定流程，要有追求，要参与到整个项目中去，要哭天喊地让领导给你权力，不给就一哭二闹三上吊，最后别说这是我教的。

6. 风险控制。这个吧，其实不单单是测试的事，这是整个团队的事，识别风险，规避风险，是项目执行的有效保证。风险这东西，方方面面，比如中间核心成员离职了怎么办？比如团队成员集体吃坏了肚子怎么办？再比如技术储备确实不够怎么办？这里提出来不是让测试去识别风险，而是让测试去在各个流程环节提醒团队相关负责人和成员去识别风险，做到风险可控，项目才能够顺利的到达测试，才能够顺利的开展测试，同时测试也能够识别出隐藏的坑，去针对性的加大测试力度，保证最终产出物的稳定。

7. 各种报告。从我做起，《阶段性测试报告》、《最终测试报告》的产出，让我们有证据可依。没有阶段性的测试报告，开发的小年轻们就会很嚣张：“我们做的东西没有问题，我们写的代码很完美。”没有最终测试报告，就永远不知道项目耗费的时间成本，也就没有办法总结项目的成功和失败，汲取不了经验，下一个项目仍旧避免不了鸡飞狗跳。在测试做出报告的同时，督促各相关小组在流程节点进行总结，其实也是保证质量的一部分。如果开发人员能够在每个里程碑总结一次，也就不至于总是跳坑里面，至少总犯低级错误的人显而易见，容易被啪啪打脸，引起注意。如果设计本身有缺陷，那也许就还有修正的空间，总比硬着头皮胡搞乱搞强。所以，报告很重要，是成果的体现，也是经验的总结，更是指明团队行进方向的明灯。

8. 持续改进。作为最后一道闸，要想要自己更专注于工作而不是嘴炮，就要依据过往的总结，优化已经制定规则、流程，为上级领导提供意见，争取不停的改进工作习惯、方式，让整个团队总是有一个远大的目标和上升的空间。这样，既能保证开发出的东西越来越精益求精，也能保证自身有所发展，否则固化思维和目标，只能原地踏步了。

说了那么多，其实我觉的就是明确测试的地位，开发人员重要，但是测试人员也很重要，而且测试人员自己也要有更远大的目标和理想，才能更好的去查漏补缺，也才能更好的去挑茬，才能帮助团队避开各种危险顺利前行。开发人员也不要害怕被挑茬，毕竟人无完人，要怕的是自己没有改进的动力。互相理解，互相帮扶，整个团队才能顺利的前行，个人价值也才能够更好的体现。