整整浪了一个月，今天最后一个工作日，与某公司X君、Z君聊了聊测试，回想反思了半个多小时，最主要的心得，没有新意，就是实践操作与学习的掌握程度不一，以下没有顺序，本文没有观点，仅记录此刻内心的一些想法。
Z：怎么会允许你投入这么多测试人员(研发测试接近1：3)
这是一个经典的问题，我大约答复，业务较多，包含许多其他内容，单元测试，部署等等各种事情，没有过分纠结。
现在回想，当时聊昏了头脑，应当简洁回复一句：测试人数根据测试任务多少、时间多少实际情况而定
过分的追究研发测试几比几、KPI、人力成本控制等等，已让大家已经丧失最基本的判断，
其实道理与依据很简单：
测试任务=测试人数*时间a.测试任务 恒定，时间 短，人数 多
b.测试任务 恒定，时间 长，人数 少
c.测试任务 多，时间 短，人数 更多
补充：人员能力参差不齐，也是影响人数增加的因素
X：快速迭代如何提高测试覆盖率
我大约建议，看工作量与实际情况，研发测试1：1或者N:1结对投入，同步编写代码与测试用例（自动化测试用例），采用代码覆盖率工具统计覆盖率。
答复其实不全面，测试覆盖率(Test Coverage)应该包含两个部分：
需求覆盖率代码覆盖率
需求覆盖率：一般会作为测试准出标准的一个指标，但是在快速迭代，需求不一定是确定的，所以很难界定需求的覆盖率，
快速迭代提高需求覆盖率是一个难点， 但可以退求其次，需求变更前时间段内的需求覆盖率，短时间内的需求覆盖还是可以统计。
代码覆盖率：其实这应该算白盒测试的内容，各类语言都有相关统计工具，比如JAVA的EMMA
Z：我认为产品质量提升主要在性能测试
我直接忽略了这个话题，第一关他的注点不一样，第二今天扯淡时间太长了，该结束话题了。
一直在思考的俩个问题是：a 如何跟测试小白介绍测试; b 如何跟专业的同行探讨测试。
其实这两种还好说，一个用大白话聊，一个用专业术语聊。但最要命的是，懂一点点的还装X小白...
咳咳咳..扯远了，回到这个话题，最开始第一反应是想反驳，真的，测试职业病，质疑导致习惯性反驳（现在方式比较柔和），
这个见解本身不存在什么问题，给个前提就行了：
a.需求一定时间稳定b.需求均已实现
c.业务功能不存在BUG
鉴于以上几点确实只有从性能、安全、代码等其他测试维度去发现问题提高质量
思考：业务测试与通用技能学习的重要性
测试主要依赖于公司相关业务开展测试，因此本职工作就是做好业务相关联的测试工作，也许通常一般大约，
加薪、考核70%是业务相关（业务熟悉度、有效缺陷、漏测等），还剩30%是技能提升之类的（开发语言、性能、安全、分享）。
然后30%决定你以后能走多远、多高。所以这里一直存在的一个矛盾点就是： 如何平衡业务测试时间与学习通用技能？
先别急着回答，比如业务测试过程中也可以学习通用技能？同学好天真哦...听我扯淡
拼命型公司：如创业型公司，变幻莫测的需求，无比繁重的测试工作量，加上"牛逼的"快速迭代（or敏捷开发），ALL time全部耗在业务相关工作，比如
理需求-->写计划-->写用例-->评用例(沟通)-->部环境-->提BUG-->修用例-->验BUG-->验BUG...-->新需求（再来一遍）理需求-->写计划-->写用例-->需求变更（再来一遍)...-->评用例(沟通)-->部环境-->提BUG-->修用例-->验BUG...-->新需求（再来一遍）...
养老型公司：朝九晚五的，时间充足。一天开3、5个会，duang一天过了；写几个会议纪要，duang，1、2个小时过去了；搞几个业务分享，duang时间又没了。
所以时间不在开会，就在开会的路上。当然这类公司一般会组织有一些技能分享应付KPI，但比较浅，重复度很高且以介绍工具使用为主(不信数一数，80%)。
鉴于以上不靠谱的总结，咱在回想一个问题：
责任心很强的你，是不是总是很迷茫，天天忙、但面试时感觉什么也不会？
对的，面试面的是通用技能，项目熟悉程度，不是你提交的BUG数与编写的用例数。
因此：如果你想有所成长，那么你一定要“不务正业”，抽时间学习、实践。
I have a dream....咳咳..一直有一个想法，做一个测试百科，简化测试理论、测试方法、最基本的示例、测试管理、相关模板、面试题等拿来可即用的内容，
一系统的梳理，便于快速理解相关测试基础知识的理解；
二迫使自己学习总结；
三便于查询与普及测试 ；
但鉴于才浅学疏、解决温饱、各类观念的纠结，想法止步不前，今年梳理了部分知识点，最近才注册了相关域名，期待明年能落实。