-
如果你负责系统测试如何跟踪需求?
2020-08-02 21:01:25
按照CMMI的操作，实际有需求跟踪矩阵，原始需求、需求规格、设计、测试等等都在需求跟踪矩阵中一一对应。
此文档虽然没有基线，但是基线文档变更的时候，需要同步更新此文档，保证此文档是最新的。
而基线文档变更在cmmi中是挺麻烦的事情，实际没有人会没事就去变更基线。
当然了，cmmi是最理想的情况，现实中很难做到，但是一定要了解理想下的情况应该如何做，这样才可以参考现实，努力往理想的方向去做。
现实中，大部分情况下，文档要不缺失，要不和最终的实际软件不一致，这些都是很常见的情况。
所以很多时候，测试人员只能努力的跟上开发的进度，有周例会之类的能参加就参加，了解项目组最新的情况。
或者和需求人员处理好关系，有什么风吹草动的就知会一声。
更多情况下，还是以实际软件为准，记录和需求不一致的问题，询问需求和开发人员。
-
为什么大家都觉得做软件测试工程师很容易？
2020-08-02 20:57:40
这两天在看《乐队的夏天2》，在知乎看了不少的讨论，有一个知乎网友@大红 的回答有点意思，如何评价《乐队的夏天》第二季第一期（上、下）？ - 大红的回答引用里面的一些内容：
重点是我们怎么来看音乐及做音乐的人 这个矛盾就很像乐评人和普通乐迷之间的矛盾问题是，乐评人你他娘的也不是精神食粮的生产者啊，你BB这些，有啥用？ 丁太升，我一直觉得他很像许知远，窦文涛，之类的人，但是他有个问题，本身的知识储备没法支撑起他的人设，所以说话特别蠢，没啥文化，既浅薄，又刻薄，好像菜市场霸市的老娘们。 丁太升就是乐评人的代表每一个乐评人，都没讲到重点，还没丁太升讲得好。之所以觉得有意思，乐评人实际和测试人有类似的地方啊。
无论上一季还是这一季的乐评人，在大众看来，都是愚蠢的代名词，但是乐评人是否有存在的必要呢，这是一个问题。
乐评人和测试人有些相似的地方在于：
1.两者都没有实质产出
2.两者都依附于别人存在
3.两者都是报忧多于报喜
4.两者的门槛都低于产品生产者
5.两者在业界的口碑都不怎么好
6. ┉┉
当然了，实际两者也有很大的区别，比如测试有需求等参考文档，有自己的测试体系和工作方法，这些都是乐评人没有的。
所以说道乐评人，主要是希望能从另外的角度来看看测试。
为什么乐评人被人诟病的那么多，就是因为他们很多不专业啊，满口跑火车，很多时候从自身的感觉而不是客观的事实来评价。
乐队可以专门的设置一个方向研究，我只要面向同一个风格的乐曲，吸取养分，顶多在涉及相关的领域即可，没有必要方方面面都考虑到。
乐评人不同，乐评人面对的是各种风格的歌曲，总不能说我只评价摇滚->朋克->后朋克->joy division，他们我爆熟，听2小节就知道哪支歌曲。但是现在流行核啊，你评价不，你还想恰饭不，核的东西全听真的很难很难，任何的细分流派其实能搞明白就很不容易了。
黑刀丁太升算是乐评人的顶流吧，包含在知乎的自称最好乐评人的梁源等等，他们自己感觉良好，实质上也比普通的歌迷确实水平高太多太多，但是如果他们的观点符合大家想的，众口一词的称赞；他们的乐评和我听到的感觉不一样，恐怕大部分的人感觉，要不收钱了，要不就是这样的水平也能当乐评人？？
说回软件测试，在IT也内部，恐怕测试也就比运维、美工地位好点，和开发人员的地位比低的很；在外面人的看法更是测试是谁啊。遇到软件问题，第一口大锅毫不犹豫的就扣到测试人员身上了。
而测试人员内部，其实大部分水平确实不足，开发能力比程序员弱很多，测试理论和实践其实花费的时间并不太多，但是软件测试能成为一个独立的职业，实际仍然需要掌握很多的工作知识，只是这些工作内容和工作价值，很多情况下并不为人所理解和知道。
既然选择了这样的职业，那么只能继续，或者换一个更好的跑道，人无论是否愿意，总是需要前进。
-
测试人员不会判断问题是前后端怎么办
2020-08-02 20:51:16
从根本讲是公司流程方面的问题，和测试人员关系不算太大。
测试人员的主要工作内容是发现缺陷，只要测试人员根据需求写全测试用例，测试过程中执行了全部测试用例，提交的缺陷记录清晰明了没有问题，也很少遗漏缺陷，那么就可以说是一个基本合格的测试人员。
缺陷记录的一个属性项就是发现缺陷的模块，测试人员有义务和责任，表明此条缺陷记录发现在哪个模块，如何发生，但是提交的内容是否正确，测试人员本身其实很多时候是很难确定的。
比如题目中说的一个缺陷是前端问题还是后端问题，在知乎我看到很多开发人员吐槽这件事情了，但是这件事情真的和测试人员关系不算太大，你们是开发人员，一眼能看出来一个缺陷大概发生在哪里，因为什么原因发生的，是否应该由自己还是别人负责，但是测试人员不知道啊。
对于测试人员来说，仅仅是根据测试用例执行，软件预期结果和实际结果不一致，所以发现了一个缺陷，我按照职责记录了下来，至于问题发生真实原因是什么，谁负责处理，who care。当然了，优秀的负责的测试人员会关心相关的问题，会去看源码定位问题，把应该改哪个文件哪行代码都给开发人员标识出来，开发人员只要按照测试人员的记录，直接就把缺陷处理掉了。但是，第一，测试人员的工作也是很繁忙的，不一定有时间帮你们定位问题；第二很多测试人员就是混口饭吃，没有必要把工作做得那么精细；第三很多测试人员的能力也不行，不会定位问题；第四大部分和开发人员的关系也没有到这份上；第五等等等等等。
总之，大部分的测试人员还是只做自己工作责任内的内容，当然了，如果一个公司规定说，测试人员发现的问题测试人员自己处理，我也有自己的开发项目，其实也是自己测试自己维护的。
话题稍微有点远了，我们拉回来看看这件事情应该如何处理。
我开始就说了，这个就是简单的研发流程问题，其实每一个测试人员提交的缺陷，本来就是不应该直接到最终处理问题的人手里面，中间最好有一个确认的过程，这个确认缺陷记录的人，可以是测试Leader，可以是项目经理指定的开发人员，或者由测试人员和指定开发人员协同处理。
缺陷确认需要做以下的内容：
第一：此条缺陷是否是真正的缺陷。比如测试人员理解错误，或者需求变更了等等等，不是缺陷由提交缺陷的测试人员确认后关闭。
第二：此条缺陷是否内容明确。很多测试人员提交的问题，别人看不懂。无法理解的，打回让测试人员补充内容。
第三：此条缺陷是否需要修改。有些问题虽然是缺陷，但是可以不修改，那么经过开发人员和测试人员协商，打上标签，不需要提交給开发人员处理。
第四：此条缺陷处理人员。其实这条就对应了问题，确定缺陷发生的真实模块和处理人员，比如可能一个缺陷表面发生在A模块，但是实际可能B模块的原因，那么把此条缺陷让B模块的开发人员处理。也就顺便确定了前端还是后端等等。
第五：此条缺陷的严重性。严重性从职责讲是由测试人员确定的，但是很多时候严重性可能会和其他的一些什么有的没的东西挂钩，可能会有争议，就需要由更高层次的人协商确认。
第六：此条缺陷的优先级。此条就是由开发人员决定的，就是缺陷的处理顺序。可以由开发leader或者修改缺陷的人决定。
第七：此条缺陷的的类型。这个可以在测试过程完毕后处理，也可以提前处理，就是缺陷真正发生的原因是什么，引入阶段在哪里，就是缺陷类型，缺陷起源，缺陷来源等等。比如是开发人员的需求理解错误，还是就是代码写错了，或者干脆需求就是错误的。在缺陷确认处理的好处是可以查看缺陷聚集情况，查看其他类似地方是否存在类似的问题。
其实大家可以看看我在知乎关于测试方面的回复，基本都归结于各种开发流程而不是具体的人，我个人还是愿意相信大家的职业操守，只要在一个好的合适的适合本单位的开发流程里面，可以尽量的避免个人的因素影响。
大概就是这些。
-
做软件测试需要强势吗？
2020-04-13 12:54:30
作者：鹿鸣
链接：https://www.zhihu.com/question/303675694/answer/1143576945
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。测试仅仅是一个工作，和性格关系不大，更关键的是所在公司的流程。
需求评审，测试本来就应该提出自己的看法和意见，你无法提出意见更多应该是你的水平不到，无法看到文档里面更深入的问题，这个更需要的是多多学习和思考，和性格无关。
迭代排期也一样，关注进度，主要还是项目经理和质量保证方面的责任，当然了，很多公司的测试会兼顾一些QA的职责，但是看你的描述无法确认是否测试有QA的职责权限。
公司的流程如果正常，本来就应该有周例会或周报之类的，各个角色说明当前的项目进度，并不需要测试人员去督促进度，测试人员本身的职责和范围，通常也并没有进度监控这项内容。
而且你们没有项目计划和测试计划的吗？为什么需要测试人员去询问什么时间测试，测试人员只需要按照测试计划，在需要测试的时候，去配置库提取测试版本。
感觉你们没有项目经理去管理项目，或者开发人员认为并不需要测试就可以发布。
至少从你描述，我看不出来工作和性格有什么关系，只是表明你的公司的流程有问题，所以需要员工自己去调整工作，应该是没有项目经理，只有开发人员和测试人员，所以需要大家商量着来，结果开发人员更强势，控制了话语权，测试人员被逼随着开发人员的节奏步调进行工作。
所以你需要做的，建议公司设立开发标准流程，建立项目经理负责制，找真正可以做主的人员，不要有事没事和开发人员说进度之类的事情，这个本来就不是开发人员管的。测试工作上，坚持专业技能，只做应该自己做的，时刻提醒自己，我仅仅是测试人员，测试才是我的工作范围，测试以外的事情，我只有建议权，没有决策权，所以该是哪里的问题，找相应的负责人解决。
坚信自己是技术人员，一切以技术说话，尽量避免性格因素对于工作的影响。
大概就是这样。
-
测试工程师的核心竞争力是什么？
2020-04-13 12:51:19
这几天在知乎总能看到一个问题给我推送：
假如我是一名能100%修复所有bug的程序员，我能在编程领域混成什么地位？其实测试人员也可以提出类似的问题：假设我是一名能100%发现所有缺陷的测试工程师，我能在测试领域混成什么地位？
企业为什么需要测试，本质上是为了保证产品的质量，所以如果企业对产品质量没有任何的要求，那么完全没有必要设置质量相关岗位。当然了，实际因为现实的种种原因，即使企业真的不重视质量，除非是小作坊，企业规模到了一定的程度，只要存在需要提供产品，那么一定需要有质量人员存在，这个人员也许是质检，也许是品质，也许是QA，也许是测试，也有可能是其他角色人员。
企业的根本目的是生存发展，这些离不开金钱，所以需要计算投入产出，只有一个角色企业认为产出超出了投入，才可能有相关的角色人员存在。
测试在产品生产甚至是质量链条上，并不一定是必要的存在，所以需要考虑的是自身存在的价值和意义。
测试总体来说，是质量的度量，实际是提供一个阈值，衡量产品是否低限满足客户需求。
那么就很容易得出结论，其实测试的能力和企业的要求并无太多的关联性，企业招募人员一定希望最低的成本完成最有价值的事情，测试的价值就是提供质量情况，谁能越多的满足此种企业需要，谁和企业的匹配度越高。
其实吧，可以认为我上面的内容都是废话，企业很多时候面试的时候考的造火箭，进去大部分时候还是在敲钉子。
-
如何看到软件测试技术带来的价值？
2020-03-28 10:59:34
测试不是创造价值，而是提升价值。
创造价值的一定是开发人员，但是开发人员做出来的产品质量未知。
谁能判断一个产品的质量是否优异，除了客户，就是质量人员。
质量人员的范围很大，比如技术专家、比如QA、比如开发、比如测试等等质量相关或者项目干系人都可以说是狭义或者广义上的质量人员。
测试的目的是发现产品中存在的问题，以此定义产品的质量。
质量的好坏和产品的价格非正相关，以客户的判断为最终标准。
所以如果客户觉得一个产品的质量不优异也可以接受，那么质量相关的投入可以减少。
测试过程仅仅是质量环节的一个部分，身为测试人员，保持自己的立场即可。
-
去哪里找系统来进行测试
2020-03-28 10:56:06
有一个误区，虽然说软件测试的工作产品之一是通过测试过程发现的缺陷，但是此工作产品的产出并不是单单直接测试获得的。
一个产品需要测试，拿过来直接测试通常并不能获得一个好的结果，通常需要了解很多的内容才能更好的完成此测试过程。
比如此产品的需求是什么，需要进行哪些方面的测试，哪些内容是要重点测试的，测试的工作时间是多久，需要安排多少的工作量。
在软件开发中，也并不是拿过来一个点子就开始写代码吧，需要进行需求调研，整理客户需求，写需求规格说明书，评审，项目计划，概要设计说明书，界面设计，数据库设计，详细设计等等等等，这些都做好了，才开始正式的写代码。即使是敏捷过程，同样有story，站立会议等等，也并不是拿过来都直接做的。
测试过程类似，参与需求评审，写测试计划，参与项目例会，写测试方案，写测试用例 ，根据计划做接口测试、功能测试、性能测试、安全测试、回归测试等等等等。
所以说，测试不仅仅是发现缺陷，而是通过软件测试的过程，让项目相关人员了解当前软件的质量情况，最终给发布的软件以信心支持。
回到问题，你想通过一个具体的软件了解测试，那么建议通过以下的途径进行：
1.软件确认。随便找一个软件，比如你常去的论坛，比如知乎，比如豆瓣等等等等，软件是什么不重要，重要的是测试的思路。
2.测试内容。通常功能比较多，可以拆分一些简单的功能模块进行测试，比如登录，比如发帖，比如查询等等。
3.测试范围。这个其实如果有需求应该是对于需求的分析，但是既然没有需求，那么就参考具体的程序，把上面的功能拆分出来，比如登录就可以列出功能分解：创建新账号，老用户的登录，使用QQ、手机、微信第三方登录等等。这里需要对测试的范围进行确定，具体测试哪些功能。
4.测试类型。接口测试，功能测试，性能测试等等。
5.测试计划。简要写一个就可以，主要说明测试的范围，测试的类型，测试用例的编写等等，具体看测试计划相关内容，确认需要做的工作。
6.测试用例。具体内容应该都学习过的吧，等价类、边界值、场景法等等，能用上的都用上，多分析多写，尽量考虑更多种类的正常和异常的情况，这个才是测试人员最基本最基本的基本功。真正工作中，即使不写测试用例，但是头脑中一定也要有一个测试用例列表，我现在应该做什么，接着做什么，实际按照此列表进行。软件测试绝对不是随便点点的胡乱测试，是有理论和实践支持的科学工作方法。
7.执行测试。按照测试用例去测试。在测试的过程中，可能需要随时补充调整测试用例，这个是正常现象，发现缺陷就记录下来。
8.缺陷分析。发现的缺陷进行整理分析，比如是否可以重复出现，测试步骤是否可以简化，是否其他地方存在类似的问题等等。测试缺陷通常有群集的现象，一个地方发现的问题多，那么说明这个地方一定会有更多的问题等待发现。
按照上面的流程，至少你可以对别人有信心的说，这个软件我成功的进行了测试，即使没有发现任何的缺陷，至少在测试用例的范围之内，我已经尽力了。
--------------------------
补充内容：
测试人员的基本技能是发现缺陷，这个是正确的，但是这个并不是全部。
任何的工程，都需要考虑成本、进度、质量，测试过程同样不例外。
确实很多人可以发现别人无法发现的问题，而且测试人员作为专业人士，发现的缺陷本来就应该比开发或者客户等外行多且正规，这个是测试人员的工作。
但是发现缺陷，同样需要考虑很多的时间和成本问题，而最好的控制手段就是进行规划，也就是计划和用例，保证测试的投入产出比。
当然了，作为学习阶段，并不需要考虑这些，就像是开发面试，一定会考一大堆的堆栈算法等问题，但是实际真正工作用到的，大部分人还是CRUD居多。
书上和培训的知识内容，更多是理论的框架，实际工作要复杂很多，在一个不断进化的行业，人员也是需要不停学习的，理论的扎实是很重要的部分，还是一切的基础。
努力学习和工作吧。
-
未来方向软件测试，有什么可以指点提醒的?
2020-03-28 10:53:51
不清楚你大专学习的什么专业，是否IT相关。个人更建议学习编程，当程序员比测试人员要好很多，而且现在对于测试人员的要求也逐步在提升，没有开发背景的测试人员，上限未必会太高。
工作用的电脑不是应该工作单位给配置的么。总体来说，测试人员的电脑没有太高的配置要求，因为顶多用个loadrunner，基本对于电脑没有要求。测试人员不比开发人员，开发人员需要使用Visual Studio或者IDEA、Eclipse这样的开发工具，同时搭配类似Oracle数据库才需要高配置的电脑，测试人员也许更需要Android模拟器或者VMware这样的虚拟机。当然还是电脑配置越高越好用。其实测试人员更需要的是多样的测试环境，比如各种分辨率显示器，各种操作系统的机器，各类常用的Android手机等等，但是没有也可以虚拟代替使用。具体还是在工作过程中看你测试的软件，还有公司对于测试方面的资源倾向。
测试工作总体来说是大杂烩，什么都要求会一点，但是很多没有必要精通。个人觉得比较根本的有两点，第一是测试方法测试思路，落实到测试用例的编写上，测试人员是否水平足够，看测试用例编写即可。第二就是业务的熟悉。测试人员的工作目的还是为了发现缺陷，要发现缺陷就要对业务和软件熟悉，才能更广泛更深层次的发现问题。业务需要在具体工作中了解，所以如果想成为一个优秀的测试人员，努力练好基本功，多分析软件，多写写使用各种测试方法的测试用例。
从我个人的角度，分析一下你手打的内容，觉得有些违和的地方，意见仅供参考，不需要完全相信。
1.原文：全面的深入进行数据库、代码、接口非功能等方面的测试。
这句过于的杂揉。测试人员分很多种，常见的功能测试人员，接口测试人员，自动化测试人员，性能测试人员，测试开发等等。我这里默认角色是人数最多的黑盒功能测试人员。数据库不需要测试，数据库通常不在测试人员的测试范围内。代码不需要测试，代码基本都是单元测试、TDD、接口测试等等，这个是开发人员的责任，基本代码是不需要测试人员管的，测试人员通常只需要测试编译打包后的可执行程序。接口和非功能是两个东西。非功能指的的是性能、安全、界面等内容，接口应该归于功能测试。
2.原文：可以协助需求、设计以及开发人员做很多补充和完善的测试。
需要记住一点，你是测试人员，测试方面你才是专业的，你才是专家。所以测试相关的内容，不是协助其他人做测试，而是其他角色人员协助测试人员做专业测试。测试人员需要做的工作是对需求文档、设计文档、开发文档等做测试方向的评审，比如需求文档中是否存在矛盾冲突、无法测试的地方，设计文档是否和需求文档功能一致，或者指导开发人员，除了正常的路径，还需要考虑各种异常情况，这才是测试人员的工作。测试人员在整个项目开发过程中处于辅助地位，但是在测试方面，一定是测试人员做主导。
3.原文：数据库，增删改查，迁移存储优化（mysql）
还是身份定位的问题，你是测试人员，不是DBA，迁移存储有DBA、运维，优化有DBA、程序员，哪家公司会叫测试人员做这些工作。测试人员的独立得益于社会化大生产分工，其实没有测试人员，程序员也可以当全栈从头干到尾，为什么还需要需求人员、设计人员、项目经理、DBA、运维等等等等，因为每个专业既然分出来，一定是有其专业化和时间成本分配原则。测试人员只需要做好自己份内的工作。当然了，如果想转行做别的，当然是学的越多越好，但是实际上，任何一个可以独立分工的职业，想学习明白都是要花费很多时间精力的，看你个人的选择如何。
别的就没有什么了，证书个人觉得ISTQB是坑，看你的公司是否需要，否则看看教程即可，测试人员的理论知识并不算太多。最好的证书一定是信息系统项目管理师，建议优先考这个证。
-
33岁学软件测试来得及吗？
2018-06-09 11:12:34
内容为：之前一直在工厂上班，看不到希望。已经33岁了，想转学软件测试来得及吗？我给出了下面的回复，大家可以去给出不同的回复。------回复正文-------我看题主的个人资料，你在12个月前关注了测试话题，但是在知乎一直没有进行过操作，今天提出这样的问题，因为对你的信息没有太多的了解，所以只说些自己能分析判断出来的，可能和题主的实际情况不一致，如果看到能补充更多信息更好。
看题主问题有几点：
1.工厂上班
2.没有希望
3.33岁
4.希望学软件测试。
不清楚12个月前为什么你关注了测试的话题，是否你周围的人有在从事相关的工作，可能和你沟通的时候，表达了测试入门门槛低，待遇不错的信息。而你在工厂的工作不是很顺利，33岁不清楚是否有家庭的压力，所以想换一个更有前途的工作。
因为工厂的职业有很多，所以不清楚你现在的工作是什么，也不清楚你的学历以及是否做过学过做过IT相关的工作，只是从一个测试人员的角度给你一些看法和建议。
1.测试的入门门槛
其实不是测试的入门门槛，而是很多公司本来就对员工有入门要求。比如学历，比如相关工作经验。除非你是应届毕业生，公司认为你有培养的价值，所以会降低相关的要求，否则进入公司的那一关就很难。
2.测试的发展前途
测试现在的发展趋势都是程序员化，就是一是质量方面要求程序员负担起更大的责任，同时测试人员的技能要求在向程序员发展。所以对于想入测试的人，通常建议先去做程序员，实在对测试感兴趣再从程序员转成测试人员。
3.年龄限制
现在的IT行业，整体还是在拼人力。996了解一下，虽然不是全部公司都这样，但是大部分的IT公司加班出差等都是常态。33岁在IT行业真的很大了，很多公司初级人员都是要年轻的，最好吃住都在公司，30岁以后基本都是资深开发或领导一个小组了。33岁真的大部分公司不会需要的。
4.测试技能。
软件测试还是需要基础的，测试即使相对开发简单，想入门也需要花费一定量时间和大量的金钱，建议你去咨询一下相关的培训公司。
所以从你的情况，个人建议不要转职测试，除非你有对口的单位可能会需要测试人员，职位给你保留。
-
开发对于测试的误解问题回复
2018-05-27 15:25:01
原文在https://zhuanlan.zhihu.com/p/37288095，格式更清晰些，紫色部分为原文引用。
今天看到一篇文章《关于质量保障部（测试）人员的测试管理及KPI工作的思考与讨论》，感觉里面对于测试方面的看法基本都是错误的，但是其中的一些观点很有代表性，就详细回复解答了一下，在这里重新做一下整理和记录。
因为研发管理不可避免的和测试打交道，会深入到测试管理的种种利弊中，所以今天因为一个问题和测试争论很久。
故事是这样的：今天团队的一名新人截图告诉我说，测试提的bug，他标记外部原因后给测试，测试又打回来，并回复“请修改状态为已解决”。
新人就表示了不理解，因为bug的本身是因为研发中需求变更导致产生的历史错误数据干扰，上线后不会有这个情况，严格的说也确实不应该是研发的开发bug。
但是测试缺认为，虽然你是历史数据，但是我确实发现了问题，你标注外部原因，是对我工作的否定。
经过沟通，确认了问题的核心是，测试对BUG数量，BUG等级，BUG有效率进行了绩效管理和考核，而《外部原因》这个状态的bug不会算在有效BUG统计中。
也就是说，开发和测试对这个BUG的状态共识并不一致。
测试角度释疑：
个人一直不建议测试人员和开发人员对于缺陷是否需要修改直接进行交流，因为太容易产生文中的矛盾。个人觉得比较理想的状态是缺陷提交后有一个确认过程，比如通常每天测试完成，个人习惯找项目经理确认当天发现的缺陷，确认哪些是缺陷哪些不是缺陷，或者确认是缺陷但是项目经理认为可以暂时不修改，因为不涉及具体的修改缺陷的开发人员，所以即使开发人员有意见认为不需要修改，请先去找项目经理沟通，项目经理确认后再和测试负责人重新对缺陷进行确认。这样通过中间人不易产生矛盾。
开发人员可以说测试人员提交的缺陷不是bug，这是很正常的行为。但是对于一个问题是否是缺陷测试人员有自己的标准，此标准不会以开发人员的看法改变。当缺陷出现争议的时候应以测试人员为准，因为缺陷为测试人员提交，需要测试人员确认验证后才能关闭，开发人员责任仅限于缺陷修改。
对于文中的历史遗留问题，开发方既然知道是问题，那么在测试的角度就是缺陷。测试通常没有必要理会缺陷发生的原因，缺陷存在就是存在，开发人员的职责是把缺陷处理掉，至于开发人员说上线等非技术手段就能处理的问题，在测试这边是不存在的。因为太多情况下开发人员都是在应付，即使到线上环境，此问题也未必会解决。测试人员遇到过太多类似的事情，所以很多时候不会信任开发人员的解答，只有修改并经过测试人员验证过的缺陷才能关闭。
定义
探讨这个问题，我觉得首先要定义清楚两个个事情：
1、BUG其实是要分两种类型的。
即 生产BUG 和 测试BUG。
这两个问题应该单独管理并分开讨论。很多公司对于这两种问题从工具到认知都是分开处理的。
2、定义一个名词《真实bug》，也就是开发完成交付后，测试拿到的研发成功他客观真实存在的真实bug数目。
这个不等于测试提交的bug数目。
生产bug越少，测试bug越接近真实bug。
测试bug完全等于真实bug时，生产无bug。测试角度释疑：
测试人员的工作是发现缺陷，无论什么样的缺陷，和缺陷数量无关，和缺陷质量无关，缺陷就是缺陷。
对于测试人员来说，并没有区分什么生产BUG、测试BUG、真实BUG的必要性。测试人员都了解缺陷具有无尽性，只要有时间，总能发现新的缺陷。
项目需要考虑进度、成本、质量，测试过程同样需要考虑这些内容，需要在有限的时间内发现尽可能多的缺陷和影响比较大的缺陷，这才是一个测试人员体现价值的地方，所以才会有需求评审、测试计划、测试用例等等。
总之，生产BUG、测试BUG、真实BUG在测试人员这里没有必要区分，因为定义本身就是有问题的。
什么是质量保障工程师
我们再来明确下一名质量保障工程师的定义，测试人员都喜欢叫自己质量保障工程师，部门叫质量保障部，那么顾名思义，测试 就是进行质量保障的。而保障的质量，当然是上线的质量，而不是开发后，那是开发的事，测试能决定吗？
所以一名合格的测试，首先要保障上线后的bug数目小于预期。上线后能够尽可能的没有bug。
也就是说，测试工作的究极目标，就是要上线后没有bug，至于需求分析、用例编写、测试、回归，沟通，管理，这些过程，都是为了实现最终目标的手段和方法，那么这个过程中产生的bug数目，即测试bug，还有意义吗？什么才是有意义的呢？测试角度释疑：
没有质量保障这个叫法，通常说的是质量保证。质量保证是QA（Quality Assurance），QA主要工作是检查流程是否符合预定目标，比如项目计划说要有需求，那么QA人员会在计划时间检查是否需求人员完成了需求文档，需求文档是否进行了评审。测试主要工作针对产品，发现产品中的缺陷。
虽然很多非测试人员都认为质量保证和测试两者是一样的工作，但实际是不同种类的工作。一个测试人员通常不会叫自己质量保证工程师的，我们只会叫自己测试工程师。
现在在很多公司，确实不区分QA和Test，工作内容也同时包含两者，但是两者实质确实不同的工作内容。
质量是产品的内附属性，可以认为无论是QA还是Test主要是为产品的质量目标服务。产品开发出来，质量上限实际就已经决定了，Test可以通过工作使产品努力达到质量上限目标；但是开发和QA可以提升这个质量上限，比如QA可以要求开发做单元测试和集成测试，而测试通常是没有这样的权利的。
测试的工作内容是尽可能的发现产品的缺陷，对产品上线后的问题通常并不关心。这里有一个测试清除率的概念，就是测试的缺陷没有在当前期间发现，遗留到了下一个阶段，这个可以对测试做一个考核目标，但是并不是测试人员关心的问题。测试人员只会关心当前阶段如何尽可能多的发现缺陷。
测试可以认为是对质量属性的一种度量，通过测试发现的缺陷，可以了解当前产品的质量情况。比如测试发现的缺陷较多，可以认为产品的质量较差，并不是缺陷全部处理了，就认为产品质量好了。因为发现的缺陷越多，可以认为没有发现的问题更多，产品本身质量就有问题。还是那句话，提升质量更多靠的是开发人员和QA，到测试这里，一切都已经太晚了。
传统kpi的参数分析
1、bug的数量和bug的级别
我认为，测试过程中的bug数目，bug等级，统统没有任何意义。因为各个需求复杂度不同，各个需求开发人员不同，开发周期不同，开发质量不同，这些会决定真是存在的BUG总数就不同。
比如需求A ，到交付时，真实BUG数目是100个，测试测了60个，其他40个上线了，这算成功吗？
比如需求B，到交付时，真实BUG数目是10个，测试测了10个，其他0个上线，这算失败吗？
结论：比较两个分别负责需求A和B的人员 产生的bug数量和bug级别，没有任何意义。因为你也不清楚真实bug数目，并且无法预估。测试角度释疑：
只要在测试用例的覆盖范围内，测试发现了多少缺陷就是多少缺陷，即使测试阶段测试人员发现了10个问题，到客户那边发现了1000个问题，也无法说测试人员是失败的，因为测试人员可能已经在他的工作范围内尽力了，测试人员都清楚并不能用缺陷数来度量测试成功或失败。
在通常情况下是可以对缺陷进行预估的，比如CMMI到4级后，度量数据都应该限定在一个比较确定的区间范围内，缺陷数据也不例外。无论是测试缺陷还是现场用户缺陷，都是可以在计划阶段就预估的，只是需要很**的开发流程和一定量的成本。
2、bug的有效率
有效率的定义应该是 bug是否是有效的，所谓有效，那其实就是 bug是否是bug，这个当然是有意义的。但是其实对于中高级以上的测试，既然提出了bug，很少是使用方式，或者执行流程造成的不是bug的无效bug，所以这儿数值，能力达到一定程度，变化并不会特别大。
另外这个值其实从统计学上，仍然具有缺陷，即数据量样本越大，也就是越大的需求，越复杂的需求，出现无效bug的概率越高，有效率月低，所以并不能完全说明什么。
结论：bug有效率，有一定程度的意义，kpi占比可以较低。测试角度释疑：
这段我从头到尾都没有看懂什么意思。缺陷就是缺陷，没有是否有效的区别，每一条缺陷都是有意义的。
感觉答主对中高级测试有误解，中高级测试是可以用更好的手段发现更多的缺陷。举个例子大概说明一下，比如初级测试人员的工作可能只是执行测试用例，中级测试人员负责编写测试用例，高级测试人员可以通过开发测试工具、优化测试流程、通过对业务的熟悉编写较少的测试用例发现更多的问题等等。无论初中高级测试，绝对没有什么高级测试发现的缺陷就一定比中级的好。还是那句话，高级测试可能发现初级测试发现不了的缺陷，但是就缺陷本身没有高低贵贱之分，缺陷本身没有有效无效之分。
对于缺陷，测试人员通常使用严重性来区分，比如一个缺陷，可能对于产品质量影响比较大，不修改此功能就无法继续使用，那么可能就是一个严重缺陷；比如仅仅是一个文字问题，开发人员连续使用5个叹号做强调，我可能就会提一个轻微缺陷，告诉开发人员最好一个叹号都不要用，也不要用红色之类的提示，所有的提示要统一风格，避免引起客户的不适感。
开发人员对缺陷的区分主要是优先级，就是修改的顺序。比如一个缺陷，对于测试人员来说可能严重性很高，但是开发人员认为其他缺陷更紧急，测试人员发现的缺陷虽然引发的后果很严重，但是客户很难触发这个缺陷，那么可能就放在最后修改，开发人员会优先修改客户容易发现的缺陷。
应该怎么做？
大家发现，所以一个质量保障工程师（测试），最重大的产出都不具备考核价值，那么我们应该如何考核测试的KPI呢？
根据上文的例子，我们很容易发现，其实关键的问题是需求A开发完成后，他的真实BUG数目是不可预估的，高质量的开发和设计过后，充裕 的时间过后，他的真实存在的bug可能很少，甚至不存在。
相反，低级工程师、不了解业务的人员开发，时间过渡紧迫加班赶工，等诸多因素可能让真实bug较多。
在这种情况下，我们要保障的是 尽可能的发现真实bug，尽可能的让自己发现的bug数目接近或者等于 真实bug数目。
所以，我们为此付出的努力，工作方式，流程，才是我们考核的更重要的部分。测试角度释疑：
缺陷度量数据是可以预估的。
每个公司进行大量的项目后，只要有一定的测试数据收集和分析，新的项目根据规模、类型等至少可以在数量级范围内对相关数据进行预估。测试工作也都是在一定时间和成本下进行的，所以测试一定也会考虑投入产出比。
1生产bug预期达成比
回到最初关于 “质量保障的定义”，很简单，我们首先要衡量的是一名合格的工程师有没有达到保障质量的目标，即如果上文提到的《生产bug》超出预期，那么工作其实是不合格的。
但是bug预期是一个较为抽象难以量化的东西，只能根据用例复杂度和需求复杂度等具体的需求表述，根据以往经验和团队能力配比，以及时间投入相关，由产品、研发、测试共同制定一个尽可能客观的预期bug数目标准。
比如一个10人/日的需求 ，bug预期是3 ，计算预期达成比。
所以在KPI考核中，生产bug的数目可以占到绩效占比的很大程度.测试角度释疑：
生产BUG超出预期，可能是因为需求没有做好，产品和客户要的不一样；生产BUG低，可能是因为客户忍耐性高或者水平不足或者你们的产品客户买来根本就没有用。所以生产BUG不建议作为度量目标，因为你无法预期客户的行为。
度量目标通常是在可控的范围内制定，无法受控的度量目标就是在给自己挖坑，有过实际经验的兄弟姐妹都应该懂。
2、用例编写
详细的用例会覆盖客户的各种实用场景，保证在测试过程中尽可能的发现所有的真实bug，而优秀的用例编写又能让测试用最少的时间，完成测试。所以符合规范的、考虑全面的，有逻辑条例的用例编写，是kpi考核的关键参数。
这条其实会和很多人认为的bug级别有关联，有些管理者认为能够发现高级、严重bug的工程师是优秀的，实际上，如果程序真实bug没有严重bug，你又何谈发现呢？但是不管有没有，你的用例应该覆盖的到严重bug，也能考虑到各种复杂场景，这个才是更重要的。测试角度释疑：
测试过程也是有时间和成本制约的。
测试人员写用例，也需要考虑花费的时间。而且前期的需求、设计文档是否真的和实际产品一致，在测试用例上的投入是否值得。这个话题太大，我也很难细说。
从我的实际经验来看，开发人员写的文档很多都是用处不大的。根据开发文档写测试用例很多时候很难做到，而照着软件写用例，同样的实际我可以发现更多的缺陷。所以测试用例的编写在实际工作中很多还是在测试人员的揣度思考下进行，既要符合KPI的要求，又不要太费时间，还要对得起自己的职业道德，总之不是实际遇到此情况的人员，很难具体的评论说明。
3、bug描述与定义
发现了BUG如何第一时间周知相应开发，如何清晰的表达清楚bug内容，如果简介的描述出bug复现的场景。
如何总结出导致bug的真实操作原因和背景。这些是一个测试人员能力高低的重要标准。
优秀的工程师对于非必现问题的定位高效，排除无效操作，去除掉障眼法，找出真正必现的使用流程，问题的本质，大大提高了bug的解决周期。
举个例子 初级工程师“点击下单报错”高级工程师“在选择多规格产品，有优惠的情况下，选择下单报错”测试角度释疑：
测试人员发现缺陷通常会第一时间提交到缺陷库中，具体的分析处理是事后的事情。测试很多时候一天发现几十个的缺陷，不可能每一个都和开发人员沟通确认，通常只有在缺陷过于严重，无法继续测试的情况下，才会联系开发人员。
我通常不会去理会缺陷发生的原因和背景。因为我主要做的黑盒手工测试，产品对于我来说就是一个无法探知内部细节的黑匣子，我只能通过一些操作，感知发生的回馈，此回馈如果和测试用例的预期不符，那么就是缺陷。至于为什么发生，那应该是开发人员关心的事情。
测试人员更关心的是发生了这个缺陷，是否其他模块同样会发生，是否进行不同的操作会发生同样的缺陷，是否此缺陷会引发其他的缺陷发生等等。测试人员更关心如何通过发生的缺陷找到更多的问题，而不是去关心缺陷为什么发生和如何修复。
初级测试和高级测试，对于同一个问题的提交应该是一致的，这个是测试人员的基本能力。不要认为一个问题不同的测试工程师会有不同的提交，缺陷本质都应该一样，缺陷发生的模块，操作过程，严重性，截图等等。
我个人不建议测试人员对缺陷提出处理意见，比如打印有问题，测试人员应该提出的是无法打印，可以说打印控件无法加载。如果更进一步的提出使用A打印控件更好个人就认为有些过了，因为测试人员的关注点一定是缺陷本身，说多错多，只能给开发人员留下测试人员开发能力不行的借口。
4、BUG生命周期跟踪与推进
对每一个BUG的产生、经过、结果都有良好的沟通，并了解问题的真正原因，记录归纳并协助其他团队总结分析。测试角度释疑：
测试有操作不明白的地方可以询问开发人员，开发人员对于发现的缺陷有不明白的地方可以问测试人员。了解问题的真正原因个人认为应该是开发人员而不是测试人员的责任，因为通常测试人员并不会负责处理缺陷，所以真实原因只有开发人员知道。通常一次系统测试过程，会发现百级甚至千级数量的缺陷，分析过程实际是一个很大的工作量。
5、需求审核
作为整个研发中心的一员，在需求评审阶段给出合理性建议，提出需求遗漏的问题或者逻辑错误或者质量风险，都是一名高级工程师必备的能力。也是有效降低后期真实bug数目。
6、测试报告
定期整理需求测试报告，分类、总结，风险预估。有效的保障整个需求能够持续，安全顺利的进行是高级工程师重要的考核方向，给开发团队和产品团队做kpi数据支撑以及需求总结。
7、工作效率管理
如何有设立自己工作的时间计划、优先级安排，以及排期后准时达成，时间预期排期的准确性等情况。测试角度释疑：
至少在我的经验里面，需求大部分并不能提供太有效的信息，顶多知道有什么功能，大概内容是什么。我主要做系统测试，系统测试的参考就是需求规格说明书，但实际对我来说，绝大部分项目需求并不能给测试人员一个很好的参考，需求评审只能发现一些比如性能指标不合理啊，功能说明在各个地方不一致，数据库设计有问题等等，对于最后的测试过程并不能起到决定性的作用。当然了，可能其他的公司会有需求写的很好的，可以对测试人员的测试过程起到很大的指导作用。
总结：
上文有些东西是不好量化的，但是不能因为不好量化，就去量化没有意义的量化，用bug数目考核。
上文只是从有没有好处的角度分析bug数目。并没有说统计坏处，这个大家可能都有经验。不提也罢。
反是保障测试中发现的bug尽可能接近 真实bug的有效手段和方式 ，是值得考核和提升的。
最后：
经过这个事，详细的思考总结了下测试工作内容及绩效管理，对自己是一个记录和成长，也希望对大家有帮助，引起讨论，更希望大家给些意见。测试角度释疑：
测试的KPI是很多测试人一直的考虑的问题。测试出数据的地方通常只有测试用例和缺陷，所以从度量角度只能从这两者考虑，里面还划分很多的属性，比如严重性等，不是测试人员通常没有必要了解这些内容。
在测试的角度，从来不存在真实bug。我想也不会有哪个公司用真实BUG去考核测试人员。
其他的就不多说什么了。
其实写这么多，主要是太多的开发人员对于测试人员的工作不理解，此文就是，所以希望看到此文的无论开发人员还是测试人员还是其他过客，能了解测试人员多一些就多一些吧。
另外，很多的回复内容仅以自己的工作经验为准，个人并不保证全部正确，每个人对于同一个事件有自己的角度和看法是很正常的，工作不同，具体工作内容不同，对事物的看法不同也很应当，本人只是说明了自己的工作实践和自己对于测试工作的一些思考。
就是这样。
over。
-
别人对我的测试评价
2018-05-27 15:23:36
很久没有更新了，现在主要在知乎，链接 https://www.zhihu.com/people/qqrrm ，欢迎大家去访问。
正文：
大前年的时候，公司离职的同事，给我推荐了他所在的公司，说要招测试管理，问我是否有兴趣，我就去面试了。当时还是比较急的，当天下午给他们发了我的电子简历，接着我打车就去面试了，没有怎么准备，而且当天有点感冒，状态算不上太好。
那是一家小公司，开发不到10个人吧，做什么忘记了，但是待遇相当不错，我的同事去那里工资翻了一倍，就是会很辛苦。
到那里有两个人面试我，一个应该是老总之类的，一个应该是开发主管。当时聊了两个小时左右吧，反正最后我出来的时候渴的不行，在他们的写字楼下买了一瓶水。大概的过程有些忘记了，我应该说了一些自己的测试理念，他们两个人感觉对于测试都不是很懂，总要往自动化测试上说，认为自动化测试才是测试，可以解决大部分问题，而我的观念是应该给开发更多灌输测试观念，测试只能保证保底的质量，开发或QA才能真正的提高质量。测试过程要一步一步来，不要一开始就想着做自动化测试，从黑盒测试开始，慢慢提升，一下子到自动化测试效果未必好。当时的自我感觉作为十年加的测试人员，当时聊的都是干货和自身体悟，没有什么忽悠的成分。
第二天的时候，老同事告诉我面试没有过，我询问原因，给出了下面的答复。
－－－－－－－－－－－－
XX说你这10多年没有属于自己真正的知识体系，没有系统的研究过测试方面的技术，还停留在对工作的应付上，不积极主动。
－－－－－－－－－－－－当然了，也许我是实话说多了，比如我承认在当前公司测试工作不多，测试处于辅助位置质量的主力是开发，出现问题应该职责分摊，这些内容也许在开发那边的看法都是减分项吧。自认体系之类的个人还算不错，2007年软件评测师刚出来就考了，市面上的测试书籍也是看到基本就买了，软件项目管理师也考下来，公司本身CMMI3、ISO9000之类的也都熟悉，javaeye，51testing，infoQ也是基本每天都看，但是在别人那里还是评价这么差，这就是自我感知和他人看法的区别吧。
最后仍然给了他们公司一些建议，不知道是否他们找到了合适的测试人员。
－－－－－－－－－－－－
不积极主动的锅我可以背一半。但是测试体系和技术，自认还是够测试人员的行业标准的。昨天感觉X老师他们更多的关注于自动化测试等方面，但是在没有体系和公司积累的情况下，自动化测试是不可能开展的。外人觉得自动化测试等很高大上，但是昨天就和他们说了很多了，小公司还是从头来，建立研发体系，加强质量控制，最后才是开展更高级的内容，测试是需要成本的。有时间可以和X老师他们建议一下，首先建立开发规程，先找几个测试人员，把现有程序稳定后，再涉及更多方面的测试内容。
了解测试的开发人员不多，昨天的X老师他们也未必知道测试是应该如何进行的，等以后有你们公司有开展相关测试工作了，慢慢我想他们会了解测试方面的内容的。测试和开发还是有很多不同的地方的。
－－－－－－－－－－算是一个记录吧，本文结束。
-
签到1000天了
2017-07-15 22:33:28
-
太原小吃
2016-09-27 20:35:44
去年接了一个项目来过太原，但是当时的客户太精明，天天早上7:30接，晚上18:00放回来，一直没有时间出去逛逛。
今年有个项目没人，第二次来太原了。这次我的事情不多，每天有大量的时间，可以到处看看了。
在大众点评看了很多的太原美食帖子，花了两天把自己感兴趣的小吃吃了一遍，做一下记录吧。
太原的小吃基本在柳巷、帽儿巷食品街附近，很方便就能在一起吃到，就是住的地方离的有点远，每次只能吃几样。自己的肚子还是太小啊。
未完待续。
-
发红包怎么测试？
2016-09-20 10:17:40
在论坛看到有人问“发红包怎么测试”，就随便写了写，仅供参考。
下面是原文回复：
很麻烦的啊。
参考微信红包随便说说，只能是一个大概的思路，而且我基本不怎么用微信，所以更具体的，还是应该参照开发人员的需求设计文档。
一、向单人发红包
发的人：
1.单红包。就是等价类了，比如限定数字，0，随机数值，最大值，小数点后几位等。
2.留言。不录入，最大录入，超长录入，特殊字符等等。
3.出钱相关。比如超过零钱怎么办，领取后是否扣钱等等。
4.发送的信息的保留，接收后的显示处理
5.一些异常处理，比如网络断了
6.安全
收的人：
1.是否及时能看到。看到的内容是否和发的信息一致
2.放置不动，最后超时处理
3.接收后的效果等等
4.收的钱是否进入了钱包等等。
二、群红包
更多的内容，比如最多多少人，平均分配还是随机分配，随机分配是否是真随机，随机后是否确实把全部的钱都正确的分割了。等等等等。
我说的比较简略，但是慢慢写，写个千级的测试用例应该不算太难。
其实没有需求文档照产品测试总会遗漏的，我想红包这样的需求，不会在需求文档中只有一条“需要有红包功能”就完事了吧。
PS：真的有这样的需求。我在测试一个移动版软件，标书里面真的就一句“软件应该有离线采集功能”，但是离线采集应该采集哪些东西，采集的数据如何整合到产品里面去，都木有了。现在开发在做离线采集功能，我这边写测试用例和测试一下移动框架，顺便来这里灌点水。答案仅供参考。
-
记一次性能测试过程
2016-01-30 20:59:55
去年的时候,一个项目经理生小孩,公司待遇不好新人都跑光了,老人手里都一堆的项目忙不开,实在没有人了,最后找我接手了此项目.
去年下半年,就和一个开发一样,写代码,见客户,现场实施维护,做需求.测试的工作几乎都放下了.
当然了,公司测试方面有事情,还是需要找我们测试处理的.
上周五下午,突然说要测试一个项目,还说老总很重视,周一就要结果.
这个事情本来和我无关,是我们集团的另外一个G子公司负责的,他们主要开发硬件,对软件不了解,所以最后这个活儿还是需要我来做.
东西不很麻烦,就是测试一个webservice接口的性能,开发人员是我们的部门副经理L,他主管研发中心技术方面的工作,我开发方面有问题,也经常询问他.我原先测试过类似的接口,所以觉得这个应该不算麻烦.
接口说明文件给我了,客户的要求很简单,50并发3秒内就可以,那就测试吧.
但是实际做的不算很顺利,本来想在G公司的的机器上安装一个lr,用他们的机器测试,但是lr怎么都安装不上,换了win7/win8/虚拟机都不行.最后没有办法,用我的笔记本测试.因为我们子公司公司要求网络物理隔离,所以网管不给我开通网络,最后没有办法使用他们的wifi走无线进行测试.
开始测试的时候,文档写的是https接口,但是我访问网址没有wsdl内容,去问L,L说https的不行,我给你http的吧,http访问就没有问题了.这个时候已经下午4点了,我还以为周六周日要加班,问他们的经理说加班能打车不,她既然说不是有公交吗.我当时就想骂人了,外面零下20多度,我个人义务给你们帮忙,打个车都不行(公司很偏,公交半小时一趟,有两次都是等车太冷,最后我都打车走的).好在后来他们的研发副总说,接口测试需要调第三方的接口,那个需要花钱的,所以尽量少测试.
那就好办了,原先按照测试的要求,需要慢慢持续压的,但是要求少测试,那就50并发一次完事.这样加了会班,晚上7点弄完了,大概只用了200多次接口调用吧,基本符合客户要求.写测试报告,给一圈领导检查,没问题了,回家,耶~~.
事情这么简单结束,我就不用写这么多了.这件事情我们老总还是很重视的,一直督促着,客户那边也有测试,突然告诉我说,客户那边的测试结果很糟糕,根本不满足需要.
既然事情是我做的,所以最后还得是我来处理.
客户给我们的邮件有错误说明,但是我既然看不懂,最后和客户建了一个QQ**流了一下,发现他们用的是java vuser.我知道lr可以使用java和vb,但是第一次看到真的有人用java写lr脚本.有交流就好办了,两方把lr测试脚本交换,大家都用对方的测试,果然我这边测试也出现了同样的问题.
其实出现问题的原因很简单,他们使用的https的网址,我使用http的.我问了我们的部门经理,到底使用http还是https的,结果他告诉我必须使用https的,因为客户就是这么要求的,那么当时测试的时候怎么不告诉我啊.
lr的c风格的vuser测试https还是比较简单的,感觉lr直接调用了系统的证书;客户那边的java vuser就很麻烦,必须进行证书转换,好在有baidu,还是能搞定的.
测试过程也总出问题,lr不能使用线程压,一用线程就组件错误,只能用进程压,但是进程方式vuser就经常会崩掉,在网上找了很多的内容,改了一堆的参数都没有解决.其实这样也是很正常的,进程方式,比如我用50并发,就是50个mmdv.exe,一个大概3~5%cpu,5~15M内存,我的笔记本烂的很,还是酷睿2,一跑cpu就瞬间100%,应该使用多台机器做负载,但是我嫌麻烦懒得弄,就这么坚持测了.最后的解决方法就是出错就手动继续run进程,反正就是保持50在线并发,磕磕绊绊的过来了.
L还总在质疑测试方法是否对,lr是否有问题,说他用程序写测试没有问题.我最后告诉L,所有的测试人员都是这么测试的,即使我说测试通过了,客户那边使用同样的方法测试,结果还是不会通过的.
反正最后测试的结果,我们调用的第三方接口速度就很慢,结果给了客户,那边也没有说什么,继续怎么样就不清楚了.
其实从测试过程说,一个很简单的接口,lr的代码不超过20行,但是周围一大堆的问题很难处理,比如网络总坏,客户那边还总在催,开发人员还不信任测试结果.一个很简单的东西,弄的麻烦死了.
年前应该没什么事情了,年后总觉得这件事情还会继续.
-
缺陷就是缺陷,不是其他
2015-11-13 23:08:30
http://bbs.51testing.com/thread-1047880-1-1.html
看到过很多的观点,认为缺陷有分类,比如从严重性分类,比如从优先级分类,比如从阶段分类,比如从属性分类等等.
但是,实际在我看来,缺陷就是缺陷,缺陷的属性很单一,就是到客户那里,认为这里有问题,就是缺陷,其他都是开发/测试等附加上去的含义,从客户角度并没有太多的意义.
比如很多人问过,无法重新的问题怎么处理,其实在我看来,并无太多的处理意义,还是看是否可能对客户有重大影响,测试人员可以发现这样的问题,客户也可以 发现,但是很好解释,让客户重现一次,无法重新就应付过去;等客户再次发现的时候,再处理也不迟,如果客户发现了不再提出,说明他不重视,所以从成本角度 看,可以不处理;如果用户反复提出,那么说明客户重视,自然要花时间和精力去处理.其实本身来说,,无法重现的问题,很多时候即使测试人员发现了,开发说 修改了,也无法确认是吧.想想微软的蓝屏,大家心里就应该清楚应该怎么办了.
还有人说发现了别人没有发现的问题,所以这个测试人员的水平很高.其实呢,这个是两说的问题,第一就是测试人员经验到了,可能发现一些新手没有发现的问 题;或者就是测试人员灵机一动,或者就是随机测试发现了而已,这样的问题,测试人员都很难发现,除非有大量的用户在用,否则我想客户发现的几率比专业的测 试人员会更小.当然了,这样的问题会让测试人员自己心里很爽的,<测试之美>第一篇就说的这个问题,真的很符合啊.
当然了,我说这么多,并不是否定大家对缺陷管理的意义,产品的质量还是需要测试人员尽可能的保证的.只是给大家提供另外一个客户考虑的视角,缺陷的严重性/优先级等等都是承建单位确定的,甲方真的未必会在乎这些东西.
一个缺陷,对于测试和客户的意义不同 .比如发现一个严重的问题,但是也许步骤很复杂,发生几率很小,客户几乎不会触发缺陷,那么对客户的意义也许不大;测试人员一个建议,到客户那里也许就是 需求;一个文字上的轻微缺陷,客户可能就认为是你对他的极其不尊重,软件都直接给你废掉.
优先级也一样,开发人员的优先级和客户的优先级是两个东西.
缺陷其他的附属也有同样的问题存在.
测试、开发视角不同,所以会有严重性、优先级的区别,但是客户的视角没有一个统一的定义.客户提交的缺陷,也许经过测试/开发一分析就没有掉了.
当然了,大部分的情况下,测试发现的问题未必会到用户那里,而且现在beta版横行,也解决了很多的类似问题.
这个仅仅给大家一个思考,每个角色,对自己的工作都是有观点、有阶级的,一些事情未必较真.
近期公司刚完成CMMI,其实有很多想写的,也写了一个框架,但是没有心情整理,有时间再说吧.
-
测试回复集(一)
2015-11-13 23:06:51
其实一直发现自己挺阴暗的,喜欢吐槽,回黑暗向帖子,收集一下自己的回复吧.
<如何让别人看懂自己的测试用例>
让看的人先写一个他自己看得懂的,你再按照他写的模式扩展.
<怎么给公司搭建缺陷管理平台>
随便找一个搭上就可以了，麻烦的是让开发人员用。
<项目多大才适合做自动化测试>
主要看成本和收益,比如你的软件只需要测试一次,那么就没有必要测试自动化;如果软件变更不多,需要进行多次测试,从成本收益比看,自动化测试可能就更合适.
自动化测试个人感觉主要不是为了发现问题,而是保证在软件变更后,不会影响原有功能.
<软件测试与售后>
售后很麻烦的,就是客户的出气筒,而且要经常出差,发展前景也不好,其实觉得售前比售后好,但是也要出差.
<独立去客户测试需要测试哪些内容>
谁让你干活的,向谁要需求,没有需要至少要操作手册,再没有去问开发人员业务流程.
了解需求后,根据需求写测试用例.实际测试过程中对用例进行补充.
测试那些方面的内容,请去和项目经理确认,比如功能/安全/性能等.
具体的测试用例内容,论坛里面很多,多找找多看看就可以.
业务方面除非开发过或测试过的人,否则没有人可以帮你的.
<验收用例怎么写>
我自己写验收用例的时候,不考虑异常,只考虑常用场景和正常的操作,分支也根据需要不用全部走到,但是需求规格和合同要求要全部覆盖到.
用例粒度可以粗一些,最好详细说明操作步骤和录入数据,因为操作的人可能不是乙方而是甲方人员.
总之,一切以安全简单高效为主,只要客户通过验收即可.
验收用例这种东西吧,还是看客户的,有的要求的多些就多写,少的就随便写点对付过去.
其实,验收用例本来就应该是甲方或第三方提供的吧.
<测试用例执行结果和编写不一致怎么办>
简单的就是提交缺陷,复杂的参考下面的内容,仅仅作为参考.
1.判断是否预期结果是错误的
2.再次进行验证,包括各种环境,条件,试出各种错误出现的方式,并了解引发错误最简洁方式.
3.如果原先的用例没有问题,提交缺陷.
4.再次进行思考,是否可能会有其他的地方出现问题,探索性测试,需要的时候补充用例.
5.打开编译器,把bug改了
6.缺陷自己验证关闭
7.告诉程序员,you can't,i do.
<如何确保测试用例已覆盖全面>
用例评审,找各个方面的人去审核用例,大家都说没有问题了,签字盖章打基线.
谁敢说不全,没有覆盖到,喏,你的签名在上面呢.
是否覆盖到,很多时候不是一个技术问题,需求全/设计全/单元测试什么都全,到自己这里,想不全都很难的吧.
<缺陷单是否需要给质量部门>
你不给质量部数据,质量怎么能改进啊.
对一个程序来说,QA对质量的把握更宏观全面些.
<面试题:A+B写测试用例>
需要确定a和b是什么,那个+符号代表什么,接着就是不同的玩法了.
比如a,b有nil或等价的东西.a,b超长,a,b非对应类型,不同的客户端同时发a,b,a,b发送后断掉,发a后隔很久发b等等等等.
主要从几个方面
1.正常
2.数据异常
3.客户端异常
4.服务器异常
5.网络相关
6.多用户相关
等等等等,慢慢想,能想出很多东西的.
<面试题:进行资料收集整理>
应该是让你google或百度出来xenu和loadrunner的资料给他们发过去.
是否他们想用这两个工具,所以干脆让招聘的人做整理.
-
测试转开发一样不爽的吧
2015-11-13 23:05:35
http://bbs.51testing.com/thread-1073876-1-1.html
看到很多人说开发转测试不适应,其实测试转开发也一样的.
当年单位大裁人,20个测试只留下2个,我只做了一年测试,当然在18人之列.
当时找了面试通过了两份工作,一个Linux下c开发,一份继续做测试.我贪图熟悉就继续做测试了.
说真的,现在看,开发的前途应该更好些,测试一直有些不死不活的样子,反正10多年也一直混下来了,而且还有继续下去的样子.
近期有一个项目,项目经理生小孩,公司待遇太差,人走的太多,其他开发人员都忙,没有办法,项目交给我了.
测试的好处一是压力小,二是不出差.在公司10多年,就出差过1次,结果为了这个项目,两个月出差了两次,每次去的时候说3天5天,结果都半个月.
程序到处都是问题,客户到不错,每天请客,但是我不喝酒啊,而且也基本不会和人打交道,还要和人到处赔笑脸累死人了.
好容易客户应付过去了,回单位还要修改一大堆的问题.客户提交的新需求,自己搞不定,还要求别人帮忙做几个模块.
原先每天工作个半天,看看小说就打发过去了,现在每天忙的和狗似的,总有问题要处理,一天客户打10多个电话,还要随时和领导汇报进度情况.
想来混日子,还是测试好.开发更合适有进取心的人.
现在每天都在学一大堆的东西,感觉再过几个月,等项目经理回来,自己大概就能当一个合格新手程序员了.
-
这几天的程序员生活
2015-08-06 23:20:33
一直做测试，开发的活儿也干过，比如写个嵌入式OCX，做个演示程序之类的。
这几天修改一个程序，弄的我彻底混乱了。
需求是车间提出的，XX部需要定期传我们公司的产品信息到他们那里，简单说，就是他们分给我们公司一些认证码，我们公司的产品有产品码，还有一个sam码，程序需要把这三个码（产品码、认证码、Sam码）关联，公司记录产品生产记录（消耗三码）以及销售记录，定期把记录生成标准xml文件上传。
原先公司有人写过程序，但是生成的xml不符合标准，所以上面就给了我们一个程序，但是程序本身有问题，比如销售过的记录，仍然可以重复销售，车间反映程序不好用，每个月生产大量的产品（几百到几万），一个一个录入太费事。希望能用条码枪扫描的方式快速录入。
正好这段时间我没有什么事情做，领导就安排我做了。
程序是用python的，使用的pylons框架。原先我只是大概的了解python，并没有具体的写过程序，这次刚好熟悉一下。
程序有setup的安装包，安装是好用的，里面使用了nginx。领导不知道从哪里弄来的src，行，就分析改吧。
第一步就坑了我，src文件根本无法运行，查找了很多的资料，最后都无法从源码执行。好在setup的是好用的，我就只能在src中修改，再发布到安装程序中。后来他们说，src的版本是比较旧的，但是也没有办法，因为安装文件中是pyo的，看不到源码什么样，我后来也去网上找了反编译插件，但是都是linux下的，算了，不费事了，版本旧就旧吧，干活要紧。
接着就是大概的分析程序，了解pylons的都知道，这个就是一个胶水MVC框架，基本只负责model、controller、routing等内容，我用的程序View部分采用的Extjs。
一通下资料学习，好在程序逻辑不是很复杂，就是几个mysql数据库的表，对应几个js页面功能。使用fiddler很容易就能知道哪个部分对应什么页面。剩下的就是动手修改了。
里面的坑就不说了，反正有源码，主要就是照葫芦画瓢，弄出来再说。很快第一版发布了。
安装到车间，第二天就来找了，IE6下不好使。我都用Firefox的，大家都知道，用firebug调试很方便，没有出问题啊。结果我在IE下一用，真的有问题，可能是我原先复制的ext控件，firefox支持，IE6不支持，重新把控件写了一遍，这次可以了。
接着发布，人家又来了。说用扫描枪不好使，每次扫描后，没有保存扫描的记录，而是保存的下拉框中第一条记录。
我开发的时候，没有用扫码枪，因为我知道扫码枪的最后有一个Enter事件，所以我都是用键盘Enter替换扫码枪，在我这里是没有问题的。赶紧借了一个扫描枪测试，确实有问题。
接着就是调试，弄了一天都没有弄好，Combo控件本身就应该是存在问题的，Ext对combo的控制本来就很乱来，每次扫码枪扫完后，焦点我都挪走了，但实际combo上还是有焦点，而且焦点是最后的鼠标位置，后来我实在搞不定，就听了别人的意见，把combo换成了text，这样就不会有问题了。
接着继续发布，结果人家检查的时候立刻就打脸了，比如原先1234的产品码，用扫码枪扫描，自动关联获取sam码和认证码，我测试的时候，都是随便输入比如aa之类的没问题，但是人家检查的时候，用12录入就获取到了，靠，我马上想到了，当时对ext不熟悉，使用了data.store.find，这个是带正则匹配的，换成findExtra就没问题了。
现在车间还在用，其实如果没问题，应该还是比较好用的。
只是在这个过程中，发现自己还是遗漏了太多的内容。如果从测试人员的角度，这样一个程序，写测试用例，一点点的测试，根本不会出现这样的问题。但是自己当了程序员，就第一时间想着把功能完成，最后并没有按照系统的方式去测试，都是随便大概的跑跑就那么样的，结果就不停的有小问题存在。
看来开发和测试的差异还是蛮大的。一个很小的程序的修改，我觉得5天应该可以搞定，但实际10天了，还是可能会有新需求、新问题存在。
纪念自己的程序员之旅。
PS.
现在一周过去了,没有人来找我,应该大概不会有什么新问题了.
-
关于《××社保系统》测试的一些想法和建议（2003年1月）
2014-12-23 17:53:58
2003年初，到了现在的公司，那个时候公司还没有测试人员，所以就下到了项目组中做测试，不到2周后，根据项目组的项目，写了这份总结文档。
现在看来，那个时候我的一些想法和现在几乎一样，10多年过去了，其实感觉测试并没有太多的发展，至少在我的角度，看不到测试有进一步的可能，也许测试人员终将消亡，全栈工程师取代一切。
直接copy会出错，感兴趣下载看吧。
测试总结.doc(80.5 KB)社保系统。
标题搜索
我的存档
数据统计
- 访问量: 70127
- 日志数: 47
- 图片数: 2
- 文件数: 2
- 建立时间: 2006-11-24
- 更新时间: 2023-01-29
