软件测试的工作内容：
一、需求评审
在整个团队拿到需求之后的第一件事是进行需求分析，看看要这个软件要实现哪些需求。需求分析的后一步就是需求评审了，这个环节需要软件测试工程师与产品需求人员、开发人员、QA人员共同进行参与，评审这些需求能不能够实现。
二、写测试计划
接下来在开发人员编写开发计划的同时，测试人员要写测试计划，就是哪些人要在什么时间做哪些测试工作，最后产出什么工作结果也就是提交哪些文档。
三、编写测试用例
测试用例就是指导测试工作进行的文档，比如要测试系统的登录功能、购买功能等，会通过测试方法和策略来设计测试用例。所以编写测试用例是软件测试工程师进行测试之外最重要的工作了。
四、用例评审
用例评审就是评价和审查测试方法和测试内容是否合理全面。不能只做基础的测试工作就可以，还得全面进行可能会出现各种各样错误的测试，尽可能把bug降到最低。
五、执行测试、提交bug
执行测试自然不必多说，就是测试工程师真刀真q地进行测试工作，找出了bug之后会进行提交，让软件开发人员进行修改。
六、回归测试、编写测试总结报告
回归测试就是对开发人员改好bug的软件再次进行测试，看bug是否都已经修改好。待bug都修改好之后，测试人员要编写测试总结报告，阐述软件的质量如何，软件才可以上线发布。
总结范文如下：
X项目的测试工作到今天算是全部结束了，除了后期维护必要的一些回归测试和用户使用手册的撰写外，整个测试阶段告一段落。
从10月底进入项目，在测试经理的帮助下开始学着写项目测试文档，到根据文档的每日功能测试及回归测试，再到整个项目进行迭代后对测试文档的重新架构及整体回归测试，直至最后的统一交付测试，我个人提交总BUG数为244个。
在这244个BUG的提交和回归过程中，在测试文档的写作及修订中，我对整个项目的逻辑及架构逐步清晰，对项目之间所需的复杂交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰。
从性质、时间、形式等角度可划分出不同类型的总结，从内容分主要有综合总结和专题总结两种。综合总结又称全面总结，它是对某一时期各项工作的全面回顾和检查，进而总结经验与教训。专题总结是对某项工作或某方面问题进行专项的总结，尤以总结推广成功经验为多见。
总结也有各种别称，如自查性质的评估及汇报、回顾、小结等都具总结的性质。写作分为标题、正文、落款。标题又分公文式的，一般由单位名称、时限、内容、文种组成；文章标题式的、双标题；正文由前言、主体、结尾组成；结尾又分自然收尾和总结全文；落款由单位名称和时间组成。
软件测试的心得篇1
写在前面：找工作真不容易，来北京呆了一个多月，都没找到一个合适的工作
大三的时候，一次计算机等级考试，由于考c，数据库，都没过，就报了个四级软件测试工程师。抱着试试看的态度学了一个月做了几套题，就拿下了一个四级证书。当时想的是，这都行，水分有点大吧。
本来想找一份网站开发的工作，技术不够硬，一直在北京飘着飘着啊。通过一个学姐，得到了一个软件测试面试的机会。于是半只脚踏入了软件测试的大门，因为我现在刚开始写测试用例，还没有真正的融入到团队中去。
实习生，直接领导给我安排了一个实习计划，严格按照实习计划执行。首先就是看公司软件的手册，要了解产品，知道软件的基本 *** 作流程，不会了就问带我的师傅。就这样学了一个礼拜，不同于用一款软件，在用的过程中要去思考，这个功能为什么有，这个功能要实现什么。忘了说了，现在产品做的是功能测试，比较简单，所以分到了这个组里。一周之后带我的师傅检查了一下我的学习成果，具体 *** 作、实现软件的一些功能，然后就几个主要的功能点以及一些需要特别注意的关键词，给我做了详细的讲解。
然后给我了两个功能界面，让我写一些测试用例，开始感觉没什么可写的，这两个功能实现起来很容易的。第一天试着写了几个，然后拿给师傅看，因为不知道从哪方面入手，虽然看了一些以前的测试用例，但是亲手写还是第一次，所以有些拿不准。
就这样，写了几天的测试用例，一个功能点一个功能点的细分。写的差不多了，就开始看一些技术类的博客，尤其是软件测试中功能测试用例的写法。看着博客中提到的一些东西，对比自己写的测试用例，看看是不是满足要求。就这样自己一点一点的修改。
其实压力还是蛮大的，由于要测试的系统需要测试多个不同的数据库，以及不同的 *** 作系统是软件的执行，所以有了各种学习目标，但是还是没有清晰的目标。努力吧，既然踏入了这个行业，就要努力的去汲取知识，不断学习，不断进步！
软件测试的心得篇2
通过这次课程设计的实训，增加了我学习软件技术的兴趣，虽然还不明确软件技术包含的具体内容，但从c++语言这门课程开始，已发现程序设计的乐趣，在学习c++语言的过程中也学到了许多计算机应用基础知识，对计算机的机体也有了一个大体的了解。在实际 *** 作过程中犯的一些错误还会有意外的收获，感觉实训很有意思。在具体 *** 作中对这学期所学的c++语言的理论知识得到巩固，达到实训的基本目的，也发现自己的不足之出，在以后的上机中应更加注意，同时体会到c++语言具有的语句简洁，使用灵活，执行效率高等特点。发现上机实训的重要作用，特别是对数组和循环有了深刻的理解。
通过实际 *** 作，学会c++语言程序编程的基本步骤、基本方法，开发了自己的逻辑思维能力，培养了分析问题、解决问题的能力。深刻体会到“没有做不到的，只有想不到的”，“团结就是力量”，“实践是检验真理的标准”，“不耻下问”的寓意。
在此希望以后应多进行这样的实训，加长设间，培养学生独立思考问题的能力，提高实际 *** 作水平。
通过本次项目实训我要感谢学校领导给我们提供了这次机会，让我们自己有出去体会生活，自己做项目的深刻体会。这次实训让我明白我自己之前的学习还是差很多，只有不断的努力，才能学好。还要感谢达内公司对我的指导，我自己的努力固然重要，但是达内的优秀教师给我做的培训，讲的理论都让我受益匪浅，让我对软件有了一个新的概念新的理解。
软件测试的心得篇3
这个暑假惠普派人到我们学校来开展软件测试培训。老师说机会难得所以我就参加了，说实话每天在教师从早晨坐到下午，中间只有一个半小时休息时间，这样还是相当累人的。我们第一天开始就觉得这个简直比平常上课还累啊。
不过 看到老师讲得如此认真，看到惠普如此强大，我看在座的学员都听得非常认真。所以向我这种上课从来不听讲的这回都听得认真得不得了，呵呵。
前两天确实还是有点累，讲的也是理论课，而且以前我们从来没有接触过测试这个行业，所以听得也嘿吃力。但是老师给我们讲了不少他们的工作经验和惠普这种世界五百强美国十强的企业文化，鄙人是深受教育啊。
后两天我们每个人带一个笔记本进行上机 *** 作了。我们的第一个任务就是安装软件，那个软件好大啊 ，整整2个g。我们考啊考啊考了好久才考完。软件叫qtp，就是惠普的快速测试专业版。确实是一个强大的软件，呵呵 大家用了就晓得了!
有 了电脑自然好耍了，我们休息的 时候就上网啊，我看猫和老鼠都看得差不多了。不过那个软件毕竟是大软件， *** 作还是比较复杂，而且全英文版，对我这种英语水平的人确实有点难以接受a。不过 呢，我还是在老师的敬业精神鼓励下学到了不少知识 受益匪浅啊，单词也记到了不少!离六级又近了一步!!
四天的培训在今天就彻底的结束 了，下午老师给我们开 座谈会，问我们有什么问题，结果呢我们一点问题都没得。老师教得好啊 呵呵!我们没得问题 老师又只有给我们说他的光辉历史了撒 。什么当年大学毕业了差点工作都没找到啊，什么当年英语学得最撇啊，还有找不到工作在网吧郁闷打游戏啊 呵呵。
我记得老师说得最有感情的一句话就是“社会是黑暗的啊”。我们对这句话都是深信不疑!所以以后呢，要好好努力啊，不管社会有 好黑暗你都能找到光明，生活就是如此，时间本就平凡。好好干好好干!
软件测试的心得篇4
软件测试在整个软件周期中的重要性，它存在于整个项目周期，在项目开始之初需求调研的时候就开始了，在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重，能主导整个项目的走向，成败与否全在于开始阶段的决策。
体会一：软件测试的真正意义在于发现错误，而不在于验证软件是正确的。
再严密的测试也不能完全发现软件当中所有的错误，但是测试还是能发现大部分的错误，能确保软件基本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。
体会二：在系统性能测试方面需要重视。
经过这次培训中多个案例的讲解，让我了解到系统在上线之后会有很多不能预知的性能问题，需要在上线之前实现进行模拟，以规避风险，包括大数据量访问，高并发数等等。
当然也有很多应对手段，没有哪种手段可称为最完美，只有最合适的，需要灵活掌握，综合运用以达到最优程度，这是个很值得研究的领域。
下面是本人的几点想法：
想法一：加强系统上线前的性能测试。
目前我们在项目建设过程中对性能压力测试的重视程度还不太高，厂家也很少有雇佣第三方的测试机构。而是在现网进行试用，遇到问题再解决，可能会产生滞后问题，影响客户使用。希望以后能在性能测试方面提高重视程度，加大人力投入，以保证系统上线后能够稳定运行。
想法二：适当介入相关项目研发
对于快速响应这块，我们不能一味依赖厂家，而希望自己就能快速响应，及时将问题解决。这也是一个比较长远的问题，需要加强研发力量的投入。
我个人是做开发出身，有此类经验，当时是在客户现场，因为了解系统内部结构，能够在第一时间排查解决客户所反馈问题。
现在系统完全由厂家开发，很难了解内部结构，或许会造成后期维护困难。所以，是否应该针对某些项目介入厂家研发工作，比如请厂家提供源代码等相关要素，以增进维护人员对系统的了解。
最后再次感谢公司提供的平台，感谢领导的信任，让我有机会得到更深层次的学习以及展示自己能力的机会，我也会尽我所能来完善工作的系统，提高整体工作效率，为南方电网的发展建设提供更坚实，优秀的支撑服务平台。
软件测试的心得篇5
在支付宝测试分析的角色和系统分析的角色是对应的，只不过一个是测试类的另外一个是开发类的。系分下面会有相应开发，测分下面会有相应的测试用例编写和执行人员。也就是说测试分析文档是对测试执行人员的一个指导(在我原来的理解方式上，觉得测试分析人员应该是用例编写人员;而在这里测试分析人员是从业务上去分析的，用例是用例执行人员来写并且执行的)。
而通过这次的这次分析觉得自己的测分还存在以下的问题：
1、太关注开发的内部实现逻辑。建议：将开发内部实现逻辑看成一个黑盒子，测试分析要从这个黑盒子的输入和输出上去看开发内部实现逻辑是不是有问题，而不应该先去了解开发的实现逻辑然后按照他们的思路去分析。
2、分析文档写的过于详细，甚至将用例的步骤都写了出来。建议：测试分析要从全局上去看问题，细节的东西即便是知道的，也要留给之后的用例编写人员去了解(就像系分之后的开发需要去写详细设计的道理一样)，这样后面的人才会自己主动去想问题。
3、分析文档要考虑维护性问题，不要出现类似比如还款中状态为“r”这种具体的数据内容。因为我的分析是对后续用例编写人员的一个指导性的文档，所以如果侧分这么写很有可能导致用例也照着这么写，其实不管侧分和用例都不应该具体写到r这么细节，否则的话开发稍作变动我们就要相应变动我们的用例
4、没有明确测试目的。review用例的时候，没有提出每个用例需要明确一个测试目的，让别人来看这个用例的时候能明白到底是怎么回事。
总结：
1、以后写测试分析文档，依据仅仅是prd文档，必须抛开开发实现逻辑部分(即不去看系分文档)，待测分出来之后，再去看系分文档，互相看看彼此考虑的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去互相明确更细节的东西。
2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析，细到看输出的时候会关注到数据库表的一个变化。但是除了以上部分，其实还少了对整体流程的关注，需要增加业务流程的各条路径的一个覆盖，在针对路径的用例中不需要关注到数据库表级那么细。
3、在做流程路径覆盖之前应该画一个路径图，这个图的画法考虑各个入口的不同分开画流程图，分别进行路径覆盖。
软件测试的心得篇6
软件测试方法和技术》这门课程，还是由张建东老师教我们的。在张老师的讲解下，我深刻的体会到软件测试是很有必要的。一个软件，从最开始的可行性分析、需求分析、概要设计、详细设计、编写代码。这一系列的开发之下。千辛万苦的，花费了大量的人力物力、金钱时间，终于把软件给做出来了。你试着想一下，要是送到客户的手上，客户突然发现，软件用不了，或者是软件存在很大的缺陷。导致软件不好用、甚至比原先没有这个软件，还麻烦了。客户是很愤怒的。客户一愤怒，就导致客户不会付钱。这最终，项目失败，造成资源的大量浪费，所以说软件测试还是很有必要的。再者就是，软件测试可以发现软件的缺陷，从而通知编程人员不断改进软件。在这样不断测试，不断改进的情况下。将软件性能不断提高，软件变得越来越好用。
软件测试，旨在发现软件的缺陷。可以这样说，软件测试就是以发现软件缺陷，为最终目的的测试活动。它通过软件测试方法，白盒的、黑盒的、静态的或是动态的。借助软件测试工具，来找到缺陷。然后在缺陷评审和确认之后将缺陷记录下来，并用缺陷管理工具管理，详细描述，关注软件缺陷的发生周期。对它的严重性、和优先级下一个定义。书写软件缺陷报告，具名缺陷的重现步骤、测试的期望结果与实际结果、还有相关、文字资料。提交给软件编程人员，来完成软件缺陷的修复。
软件测试的方法，包括：白盒测试和黑盒测试。其中，白盒测试之中，有含有：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖、等方法。黑盒测试方法中，有：等价类划分法、边界值分析法、判定表法、因果图法等。软件测试方法，按照是否运行代码来看，可以分为：静态测试和动态测试。其中静态测试有，对代码的走查和评审。动态测试，则是要通过运行代码来执行。白盒测试多用于软件的 单元测试 上，黑盒测试多用于功能性测试上。代码的静态测试和动态测试，则是每一个软件项目都必须的。
单元测试，多构造桩函数或是驱动程序来测试。一般借助与各种软件测试工具。软件测试，或者说程序测试。一般先是进行单元测试。单元测试，修改完单元之中的缺陷、错误之后，就是集成测试。集成测试多针对程序功能进行测试，看程序的各项功能是否达到要求，是否齐全。集成测试之后就是系统测试。系统测试是针对整个软件系统的。看软件系统是否达到性能的要求。从而改进代码，以求达到系统的严格要求。最后就是验收测试，这个测试，一般都分成两半来做。一半是，程序员模拟客户环境，进行测试。而，另一半则是，真正的客户参与的测试。最大程度的体现客户的真实环境。客户在试运行的情况下，看是否会发现，平时发现并且以前的环境发现不了的问题。
验收测试，包含对界面的测试和软件可用性的测试，运用尼尔森十大原则，来测试软件是否好用。软件是否达到用户的对软件界面的需求。
无论是软件编写，还是软件测试，都需要相应的文档管理。还有针对软件测试制定的测试计划，软件测试执行等。
通过本学期的学习，我感受到软件测试是一门非常需要学习的课程。即使作为考察课程，它也是软件行业人士所必须了解的知识。它对软件工程项目的作用是至关重要的。现在，作为学生的我所做的项目虽然都是一些小的项目，但是在小组共同开发的时候还是需要用到
项目的测试。如今这门课程我学的还不是很好，但我相信在今后的实训及工作当中，能够更好的体验和感受到项目测试的精髓，对软件项目测试有更深入的了解。我也希望，学校的老师能够在今后的教学当中重视软件项目测试课程，多让学生了解实例，去感受、体会软件项目测试所遇到的问题和解决方案，理解软件项目测试的精髓。
软件测试的心得篇7
虽然一如继往地写读书笔记，笔墨也浪费了不少。但真正坐下来利用大段的时间将自己的思路理清还没有过。因为最近有了一定的时间,更因为狠狠地泡了一段时间测试论坛,下载学习了该网站的电子测试杂志之后，自己的思路终于开始清晰起来，朦朦胧胧地开始看清了远方的路,麻着胆子去分析一下自己,也学着展望一下未来了,毕竟摸黑走路的感觉很不好。
我觉得学习软件测试的通用技术与针对某类软件的测试技术外,还有一个重要的与技术无关的方面:业务知识没有具体的业务知识很难发现软件中潜在的逻辑错误甚至是需求上的错误,当然需求要依据特定的软件,但软件测试人员对需求理解的深入程度不应低于软件开发的人员因为软件测试所有的依据来自于需求,而所有的需求来自于客户,甚至是我们的全部都来自于客户识别需求后还必须转化为测试上的需求,毕竟测试人员看需求的角度和开发人员还是有区别的。
关于学习，我知道我并非计算机专业的学生,初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。但是,总该知道如何去学习，然而我认为，学习总该有必要的方法。
1 找个好师傅
这是最重要的一条了,也是公司提供的最好的一个条件刚进来的时候,td,测试案例都有一个pm细心的和你讲,案例有什么方法来设计要注意哪些错误软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，一大堆的东西马上够你头晕的了呵呵,还好,悟性不错,都囫囵吞枣地吞下去了。
2学会读书
无论是神马专业，我始终确信，万变不离其宗，我知道，我不是这个专业的，但这个并不代表这我就不了解这个，再怎么不济，我也是从书本中走出来的，我相信，只要我努力地吧书本啃熟，我能够灵活地融入到这个职业中去，从书本中找寻解决问题的方法。标记出自己所错误的。
3与前辈们一起讨论，多说
总有一天，我们会成为一位前辈，不过不是现在，至少现在我们应该好好的向别人学习，所以，我觉得，前辈是我们前进道路上不可或缺的一部分，他会成为引领我们前进的发动机，给我们指点，跟我们道工作的经验。然而，我们也应该多说，我知道，前辈们给我们讲解，已经是很辛苦的事情，毕竟，这不是他们的义务。我们也应该多多说说我们的观点，这样既能够让人家了解我们的水平，也方便老师前辈们对我们进行指导。
这些天的学习，我也有了一点自己的心得体会
体会一：软件测试在整个软件周期中的重要性。
它存在于整个项目周期，在项目开始之初需求调研的时候就开始了，在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重，能主导整个项目的走向，成败与否全在于开始阶段的决策。
体会二：软件测试的真正意义在于发现错误，而不在于验证软件是正确的。
再严密的测试也不能完全发现软件当中所有的错误，但是测试还是能发现大部分的错误，能确保软件基本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。
软件测试的心得篇8
将近一个月的假期实习生活结束了，告别了这一次短暂的实习生活，这段时间也让我感概万分，有欢乐，也有苦累，也许这就是实习生活所必须经历的吧。似乎尝到了校园中所不能经历的辛酸苦累，所以，这段时间里我学到了很多，也都成为了我人生中的宝贵财富，也迈向了社会中重要的一步，是非常值得珍惜的。
这次实践主要就是学会使用公司软件部门所开发的应用软件和各种产品设备，熟悉和了解一贯的 *** 作方法和可能出现的问题，并就如何解决问题向老员工请教方法。教我的是一位年纪稍大的老员工，先与我说了一下要点，然后让我自已看，遇到不懂的就问。初次接触，发现它并不像书本那样的有条有序，许多信息夹杂在一起，令人眼花缭乱，而有不同的种类，要做到随便一看就知是什么单是不行的，因为看过一点有关软件测试的书籍，所有有点了解，但是这些根本不够，于是接来的几天我就踏踏实实的坐在哪里认真的看产品介绍和说明书，熟悉它的大致结构。
熟悉了相关软件和硬件的 *** 作和基本故障诊断之后，我也成为工作之中的一员，开始尝试解决客户应用产品中出现的一些问题。在这一段时间里，主要任务有巩固之前所学的，对常见的错误要一看便知，并养成认真仔细的工作习惯。在工作的过程中我也遇到了一些棘手的问题，但是经过大家的共同努力也一起解决了。经过了这些之后我也感觉到光靠培训听讲是不那么管用的，有时候也要自己试着去解决问题去亲自动手测试一些东西，在实际的应用过程中去发现问题和解决问题，做任何事都是一样要实事求是。
结合之前的培训，了解我现在的任务就是熟悉各种软件的 *** 作和数据结构，然后在此基础上尽一切可能的去模拟、去思考现实使用环境中的应用可能性和预测可能出现的状况再对比一出现故障的概率等等，在这样的一个环节之后我要做的更细致的活儿就是做好各种测试计划和测试报告，然后对这些报告做一个准确和客观的评估然后将我所获得的结果反馈给软件或者硬件开发人员。
经过了将近一个月时间学习，了解到自己还有许多的不足，首先是缺乏工作经验，因为自己缺乏经验，很多问题而不能分清主次，还有些培训或学习不能找到重点，然后工作态度仍然不够积极，在工作中仅仅能够完成布置的工作是不够的，若没有工作做时可能就会松懈，不能做到主动学习。在工作中，不允许丝毫的马虎，严谨认真是时刻要牢记的。同时，学术上不够钻研，这是由工作性质决定的，也是我自己选择的，因为在我看来，只有被市场认可的技术才有价值，，但我毕竟是大三在校生，对科研技术进展方面都不了解，所以还需要更多的锻炼机会。
经过这一次的实践与学习，我才慢慢开始真正了解了软件测试工作，实习是一个开端，一个让自己学会成长的地方，不管是从工作技能上还是为人处事上，我都感觉到了自己有很大的提高。
首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信自己一定能克服。作为软件测试工作者要善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生，别人认为是对的，我却认为不是对的。有时候，往往某些质疑才是关键。保持一个良好的心情，否则很可能无法把测试作好，一定不能把生活中的不愉快的情绪带到工作中来。在工作技能上，因为从事的是测试工作，自己又没有经验，所以一切需要我从头开始，而且更需要自己的努力、耐心和细心。这些都是自己欠缺的，但是在工作了这几个月后，真的发现自己有了很大的改善。其次，让自己成熟了许多。虽然不能用语言来描述，但是确实可以从生活中的点点滴滴感觉得到。经历使人成长，只有经历过，才可以让自己真的成熟起来。
程序员的高薪一直是被大众津津乐道的话题，几乎每一段时间都能再次成为话题讨论的中心。在前几天，关于程序员薪资的话题又一次在知乎上火了， “月薪2万到3万的程序员的一天是怎么样度过的？” 的帖子一度冲到了热度前十。作为可观薪酬的岗位之一，不少人都表示好奇，月薪2万到3万的程序员是种什么体验？
其实对程序员来说，月薪一万，可能是一些有名的互联网公司校招程序员的批发价。而工作三到五年基本就能达到月薪2万的程度，并不算很难。
但在高薪的背后，究竟真的如传闻中一般，无止境的加班，还是存在另一种生活态度？贴子下面的很多回答，给许多网友呈现了程序员所不同的一面，也让我们发现了，其实高薪背后，有大众所看不见的另一种生活。
下面我给大家整理了几个测试员的回答，还没到达这个月薪的小伙伴可以比照着看一下。
@Bigder
7:30:7点的闹钟，摁掉又再响已经7:30
8:00:公交转地铁，一路狂奔到地铁站 。等了2班终于挤上去了。
9:00:有惊无险、地铁上打到了卡
9:15:晨会开始了。产品、开发、测试每个人说一下昨天的进度、今天的目标、遇到的问题
9:30 :晨会结束了。吃完刚刚没吃完的包子。
10:00:
1、打开邮箱、邮箱又满了。得清理一下了。
2、打开钉钉，看看有没有@我的消息
3、打开禅道系统，催开发改bug、回归已经修改的bug
4、打开昨天没测完的模块 ，执行用例、测Bug 、验Bug、激活bug
11:40:感觉还没做什么 ，到饭点了、热饭、美团搜新开的店有没有优惠、喊部门的几个不带饭的一起去。
13:30:被同事们收床和外放打电话、讨论的声音吵醒。迷迷糊糊好像没也没睡着。
14:00 - 16:00
继续10:00后的工作，收到钉钉消息下午有新的需求评审。
已经订了会议室，赶紧吧不然今天提测的又验收不了多少进度、还得参加新需求评审、但愿产品能把需求都拆解清楚、不然又要再评审N次。
18:00:下班了、开发说早上说的问题和遗留问题都改好了、项目经理又来问进度了。
走吧，找几个同事，一起吃晚饭 。
18:30 - 20:00
吃完晚饭 ，回到到公司，开始测试新提测没测完的模块（让我先完成第一轮） 、bug明天统一关闭吧，不然又要测新功能、又要关闭bug
不到22:00、打车没有报销、我再继续学会软件测试知识、没提升可不行。
22:00
写测试日报
打车回家、次数也不能太多了。太多了报销不了。
22:40
到家了，洗漱下收拾家务，没追完的剧再追一下，睡觉 。
00:30
该睡了。不睡起不来，知乎刚刚又推了熬夜的危害。
7:30：7点的闹钟，摁掉又再响已经7:30
画外音：每个早晨多睡的半个小时，是测试员最后的倔强
@王大宝
710 ：起床刷牙洗脸配穿搭+吹头发
730：出门，楼下有单车就骑单车赶到地铁站最近的公交车站，没有就慢悠悠的赶到那
750：公司班车到了，排队上车，大概四十分钟到公司，一般路上都会在车上睡着
840：到达公司楼下排队上电梯，日常人脸打卡来到11楼工位上拿着水杯接上一杯温水
900：九点前都在工位上玩玩手机，九点就要开始一天的工作了，先将昨天的工作内容，遗留事项列出来，等一下早会要讲，然后再排一下今天的工作内容
930：开始早会，各自依次讲自己昨天的工作内容以及遗留事项，老大会根据每个人所讲的提出一些问题，大概半小时内解决
1000：这时候就开始工作了，我上午安排工作一般都是容易解决的，比如说设计测试用例跟熟悉需求文档，包括自己整理所有测试文档
1200: 下去公司食堂吃饭，一般都需要排队十分钟左右，饭菜虽然是广东口味但是也挺好吃的，吃完午饭就上去工位上玩一会手机到一点
1300：弄好床准备开始午休了，午休到下午两点
1400：下午的话不出意外一般都会有一个小时的会议，无论是需求澄清还是用例评审还是别的一些内容都需要靠开会来解决，在大公司一般都是白天开会晚上加班谁也不例外
1800：这时候就到了吃晚饭的点了，如果晚上不加班这时候是不允许去吃饭的，需要工作到六点半才能回家，但是我们加班的就需要去吃饭回来继续加班了
1900：夜晚加班生活刚刚开始，就是一直测接口压测接口，测前端，空余时间用来自己技术水平的提升
2100：打卡下班
画外音：这个公司在哪里，我也想去…
@乘风
每天9点打卡 18:00下班标配和普通上班族差不多。
很多时候跟开发和产品撕, 流程不规范, 边界不清晰, 目标模糊 经常需要强制加班, 在上线前, 加班到晚上2,3点是常事。
画外音：原来月入2W的测试大佬也还是需要和开发扯头花…
在看了上述测试大佬的回答后，我们发现，高薪并没有想象中的那么简单，更多的是由测试员们日日夜夜学习拼搏出来的结果，只要脚踏实地的干，相信月入2W至3W并不是很难达成的目标。
当然，作为软件测试工程师，我们也可以从以下几点出发来提升自己，快速成为月入过万的一份子。
1）提升逻辑思维、学习能力
软件测试对于逻辑思维、学习能力、反应要求很高，是否有严密的思维和逆向思维也非常重要，所以想要进阶到下一个层级，这方面对于自己的要求就显得十分重要了。
比如笔者之前在一个有5、6个人的小组工作，组内有一半的BUG是我找到的，这与我数学专业毕业有关，这是因为在平时我就很注重逻辑思维的培养，在面对问题时，我会更善于找出各方面的因素。
2）要考虑到所有出错的可能性
这是所有测试员都应该谨记的一点，在做测试的时候，我们时常要做一些不合常理，奇怪的举动。 除了漏洞检测，测试还应该考虑性能问题，也就是要保证软件运行得很好，没有内存泄漏，不会出现运行越来越慢的情况；在不同的使用环境下，考虑软件的兼容性同样重要。软件测试同产品的规模也有很大的关系，因为软件的bug往往出在大型软件的连接处。
3）需要时刻抱着怀疑的态度
做测试需要时刻怀抱着怀疑的态度，因为有的时候开发人员的想法和我们并不同，作为测试员需要策略性的准备各种数据，抓住细节，设计不同的应用场景，而开发却喜欢找一些有利于自己程序执行的数据，这时候很容易产生假定数据可行的情况。
这也是为什么开发和测试这么容易起口角的原因，测试这个岗位慢慢晋升之后你会沟通能力也是很重要的一环，经常和开发人员沟通，能够使得项目推进速度跨上一倍多，同时也能收获更多的增长。
写在最后
有很多网友曾发表言论，表明程序员的薪资过高，但细看这份工作，不仅需要技术含量，还经常会面临加班的问题，很多人只看到了他的高薪，却没有看到其背后的付出与努力。
高薪的背后一定是与技术与足量的项目经验挂钩的，因此无论哪个行业，想要提升薪资的最佳途径还是努力学习，增加自己的职场竞争力。给你一个模版XXX公司 文档编号 项目版本 密级
XXX项目 共13页
XXX项目
系统测试报告
拟制： 日期： yyyy/mm/dd
审核： 日期： yyyy/mm/dd
批准： 日期： yyyy/mm/dd
修订记录
日期 修订版本 描述 作者
目 录
第一章节:概述 5
第二章节:测试时间、地点及人员 5
第三章节:环境描述 5
第四章节:总结和评价 6
41测试过程统计 6
411 用例数统计 6
412 用例对需求的覆盖度 6
413 用例的稳定性 6
414 用例的有效性 6
415 测试执行工作量统计 7
416 测试执行的效率 7
417 版本缺陷统计 7
418 测试过程综合评价 7
42 被测系统质量评估 7
422 缺陷个数 7
423 缺陷严重等级评估 8
424 缺陷原因分布 8
425 测试用例的通过率 8
426 软件质量评价 8
43 测试总结和改进建议 8
第五章节: 遗留问题报告 9
第六章节: 附件 9
11 交付的测试工作产品 9
关键词：
摘 要：
缩略语清单：
缩略语 英文全名 中文解释
第一章节:概述
项目的一些概述
第二章节:测试时间、地点及人员
版本名称 测试时间 测试人员 测试地点
起始时间 结束时间
第三章节:环境描述
硬件环境 软件环境
名称 型号 大小 个数 名称 版本号
CPU *** 作系统
内存 应用软件
硬盘 数据库
第四章节:总结和评价
41测试过程统计
411 用例数统计
模块 规模(KLOC) 用例数 用例数/KLOC
合计
412 用例对需求的覆盖度
需求id 用例数
合计
413 用例的稳定性
模块/特性 用例数 变更用例数 变更用例数/用例数％
合计
414 用例的有效性
模块特性 用例数 发现的缺陷数 缺陷数/用例数
合计
415 测试执行工作量统计
模块特性 规模 投入人时 投入人时/KLOC
合计
416 测试执行的效率
模块特性 执行用例数 发现缺陷数 人时 执行用例数/人时 发现缺陷数/人时
合计
417 版本缺陷统计
模块特性 版本1(缺陷个数) 合计(缺陷个数)
合计
418 测试过程分析
（这里主要根据以上的统计数据和日常小组的工作情况，对测试过程中的异常情况，如测试延期，测试质量不高等问题进行说明，并适当分析原因，给出改进的建议。）
42 被测系统质量评估
422 缺陷个数
模块 规模(KLOC) 缺陷数 缺陷数/KLOC
合计
423 缺陷严重等级评估
模块特性 致命 严重 一般 提示 合计
合计
424 缺陷引入阶段分布
缺陷原因 致命 严重 一般 提示 合计
需求
设计
编码
合计
425 测试用例的通过率
模块特性 OK项 NOK项 BLOCK项 NA项 合计 用例通过率％
合计
426 软件质量评价
测试对象的整体质量：B
备注：A：质量稳定，适合大规模使用。
B：存在少数非严重问题，但有规避措施，可以局部使用。
C：基本功能可用，但严重问题较多，不能发布。
D：基本功能不可用
43 测试总结和改进建议
（这里主要根据以上的数据从测试过程，软件质量，以及各个团队在该项目中的协作进行整体的总结和评价，暴露项目中出现的问题，并积极提出改进的建议）
第五章节: 遗留问题报告
表1 遗留问题统计表
问题总数 致命问题 严重问题 一般问题 提示问题 其他统计项
数目
百分比
遗留问题详细信息参见《XXX项目遗留问题表》
第六章节: 附件
交付的测试工作产品
1测试用例
2测试日报
3测试报告
4测试记录
5缺陷报告
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）