现在测试工作大多以项目为纬度，那么你对自己的项目得有一个计划，每天到什么程度得有一个预期。
再者测试通过的标准，这个不同公司都有各自的标准的，有的是允许带个别不影响主要功能 bug 上线的。

我是觉得单靠测试很那把问题都找出来，没法保证测完了就没有问题

尽人事,听天命

测试工作做得好 就是完成覆盖度高 测试案例
至于有没有问题 是质量管理体系的 问题

完成覆盖率高如何体现？我个人觉得很难除了单纯的代码覆盖率，场景覆盖这种很难说是否覆盖完全，假设有 10 个场景，然后测试全部覆盖了，但其实还有一个场景没想到- - 那这个场景覆盖率应该不算 100% 吧- -

还有，我觉得是否能上线应该有一项很重要的标准就是 bug 收敛率吧？如果 bug 持续收敛，然后遗留问题修改得差不多了，我觉得是可以达到上线标准了。

衡量工作项目体量，测试深度：功能、接口、性能等等，特别对于互联网企业敏捷模式版本快速迭代的现网 BUG 反馈最重要指标没有之一。

为什么要衡量测试工作做得好不好呢？ 因为：因为测试工作做的好的话，进度与质量都是符合项目进度标准
怎么衡量进度与所负责项目质量的标准呢？ 可以从接受需求对项目的前期准备的是否充实，对自己负责部分的了解情况，评估合理准确性可以增加对项目了解的详细，对项目进度有多维度评估，增加准确性。对于质量而言可以再测试前了解所负责的功能逻辑，知道做了哪些新功能，改动了老功能，保证不漏测新功能，不遗漏老功能回归。

上线的标准是否适合，应该从多方面去考虑，比如你的项目是属于项目性质还是产品性质，针对的客户的性质以及数量大小，使用的频率等等，另外功能的后期影响的大小。根据这些东西，然后综合判断当前测试项目的 bug 情况，再提出是否具有上线的能力，至于说衡量自己的工作完成情况，完成是一方面。完成的质量是另一方面。说个真的，测试的工作很难量化和成果化

和楼主有一样的同感，每次迭代出新的版本，验证下修复问题后，再简单地跑一下测试用例就完事。 但总感觉根本就谈不上质量

1、线上质量监控
2、缺陷根因分析（测试 + 线上）
3、过程数据侧面度量——各种数据的绝对值、比重、比例（密度）以及趋势发展动态

简单说下我的意见吧

1. 如果你身处一个大厂/大公司，那么你每天的测试任务基本是固定的，前期的单元测试开发人员应该也都完成了。而且你还有可能长期测试同样的功能。那么通过你这期间不断的学习和经验积累，除了所谓的需求覆盖/场景覆盖，你会产生一定的 “敏感度”，可以用于探索性测试。正是因为大公司里面流程完善，所以完成某个流程后，会有相应的规则指引去评估一个版本的风险，侧面的去协助你评价测试是否做的好。

2. 如果身处规模小一些的公司，那么可能就是身处瀑布，追求敏捷。及时响应新的功能和新迭代的验证。正因为如此，在每次迭代提测的前期，测试要充分的理解需求（Story），然后设计用例，提前发出评审，让相关人员都看下是否有补充的，场景是否有遗漏。开发阶段争取让开发人员完成单元测试，然后到正式的测试阶段去覆盖场景和用例，到迭代后期主要以回归测试为主，在代码保证的前提下，全量回归如果没有问题的话即达到了版本上线标准。（虽然很多传统的测试对这一点并不认同）