马上就到新公司上班了，但面试的时候，老总提出两点想法1：构建测试架子和测试流程；2：搞起自动化测试及持续构建。发现坛子里也有同学也碰到类似的需求。
目前关于构建测试架子和流程，思路比较乱，请教各位大牛。
下面是个人的一些想法：
- 关于测试流程
- 识别项目组目前采用的开发模式，根据开发模式，选取相应的测试流程，一般简单项目流程大体是：需求评审-测试计划-测试用例设计-测试用例编写-测试用例评审-测试用例执行-回归测试-测试报告-测试总结
- 需求是否可测
- 测试计划是否得当
- 用例设计是否完备
- 测试执行是否全面
- 回归测试是否遗漏
- 测试报告是否真实
- 测试总结是否有效
- 关于测试架子：
- 主要应该是根据项目的大小，项目的时间紧张程度，测试的压力程度来决定是否招聘新的员工，扩大测试团队。
上面两项在实施过程中需要注意哪些地方，或者有哪些坑不得不踩，希望各位大牛多多指教。
@monkey @seveniruby @lihuazhang @chenhengjie123 @gaopeng1106 @xiaoxin @tom_ma
看到大牛们在测试管理中有讨论，特@。
- 规范：规范测试流程，并得到实施。
- 文档：需求文档和开发文档
- 持续集成：比如自动打包之类，节省重复工作的时间
#1 楼 @niweyzhuce
你说的规范，是指些什么，每个阶段都有文档，评审之类的吗？
额。。项目是移动无线 app 的项目么？？
个人认为搭测试的架子和搭自动化是两回事，你老板这么说就表示他更希望一步到位。
- 关于测试流程
Monkey:这个真的很难讲了。基本上每个公司都不同，但是粗颗粒度来讲就是你上面说的那样。流程本身差别不大。主要还是前期的需求评审和测试用例的设计，包括需求，代码上的分析。其实从真实情况来看的话，测试流程更灵活了。
但其实更多的应该是项目整体的流程应该有个把控。
要有制度控制需求的变更，包括功能需求以及 UX 和 UI 的变动。这个一直变会是很大的灾难
自动化中 API 自动化要严格的保证覆盖率，业务和代码都是。而 UI 的话可以不做，或者做的话最多就是 smoke test。基本上是这样的一个方向。千万不要想着录制，或者做的很重，基本上一年，两年就要废
另外就是考虑角度的话不要只看测试，看质量。测试在快速迭代中已经不足以保证移动无线 app 的质量了。质量其实就需要一个体系。这个体系就不只有测试了。包括
不过不同 app 应该也不会太相同。但是两点是重点，框架不要求重，但要灵活。其次要看质量，不要看测试
谢邀请，题主的问题有点虚，老板就是和你扯扯皮，他懂测试就应该明白因地制宜。你应该先观察一段时间，然后再来落实方针，而不是带着自己一套想法来硬落地。
另外，没人你说蛋啊！一个人做不了流程。:feelsgood:
题主，你们老板这是希望你一个人去干几个人的活啊。。。
#6 楼 谢@monkey 项目算是传统行业，本是想把互联网行业的一些流程带过去，但看了@lihuazhang 的评论，应该是先去看看，看老总是否真的想把控质量，项目组是否适合互联网的好的流程。
#7 楼谢 @lihuazhang， 先去踩踩点，看看情形，在论后事吧。
#9 楼 @lylyliuyu 我想老板画的饼也比较大，我被大饼诱惑了。。。
一个人还整什么流程啊 。一个人最好的办法就是天天和开发混在一起，一来积累一点技术和项目经验，二来了解开发的尿性为未来建立测试体系打基础。既然就你一个测试 那么看事情的角度就要高一点，从项目的角度去考虑测试的方法，别整虚的流程，项目搞不好老板才会抓你流程 这是个恶性循环。
我是我们部门的测试第一人，我入职后第一件事是读了所有提测服务的代码，并整理出业务文档，所有环境都自己搭了一遍，包括监控。我的经验是要对要测的服务了如指掌，才能设计出合理的自动化测试框架和测试流程。仅供参考。
