做软件测试工作的感悟（范文模版）

第一篇：做软件测试工作的感悟（范文模版）

不知不觉间做软件测试已经将近两年了，这两年间在QA这个工作岗位上学到了不少东西。下面是我对软件测试一点感悟。

相对于开发，软件测试通常给人的印象是：技术含量低，枯燥乏味，大量的重复工作，将来的职业发展局限性大⋯⋯的确软件测试工作存在这样的问题。但是任何事情都是相对的，要把软件测试这份工作做到出色也并非易事。软件测试需要工程师掌握广泛的知识面，发散思维，以及对新知识的快速学习能力。

以我的亲身体验来讲，入行前我对软件测试的理解就是找出软件中的bug。入行后，才发现软件测试工程师要参与到项目的各个阶段：需求分析，文档review，FC，Beta，RC，GM，直至最后产品的release，以及release后产品各个版本的升级。对于每个feature的理解程度，甚至项目架构的了解程度决定了软件测试工程师所找出的bug的质量和数量。同时与Dev的沟通和交流也有利于找出和narrow down出bug，以及最后的fix bug。养成阅读release note及组里面其他人报的bug，尤其是高手所报的bug的习惯非常有利于软件测试工程师的成长。

之所以说软件测试工程师需要掌握广泛的知识面，是因为软件开发设计操作系统，底层的数据存储，前端的设计，以及用户体验。作为一名软件测试工程师或多或少都要对这些知识有所了解。有一段时间我做安全测试，在此期间我了解了安全测试的基本概念，学会了XSS，JS攻击等安全测试手段。在做自动化测试时，需要学习一些脚本语言以及自动化测试工具。

项目的不同阶段对于测试的要求的侧重点有所不同，如FC和Beta Accept之前，需要深入的测试所有的feature，尽可能的dig出所有的bug。到了RC和GM阶段测试则要最广的范围，保证产品的稳定性。这时候设计良好的测试用例就发挥作用了，它能帮你从之前遗忘或忽略的角落里找出bug。定期的回归测试也能起到保证产品稳定性的作用。

以上便是到目前为止我对软件测试的一些浅显的感悟。我相信随着今后工作的进一步深入我对软件测试会有更深刻的理解。

转自:领测软件测试网[

第二篇：软件测试学习感悟

学习软件测试的感受及体会

这学期学习了赵培英老师教授的软件测试这门计算机专业的专业课，我们学院又开设了刘老师的关于这方面的讲座，更彻底的使我们加深了对软件测试的认识。所以我想谈谈关于软件测试的体会及学到的一些知识。

作为计算机专业的一门很重要的课程，在计算机领域占据着不可替代的角色，随着人类社会的进步，各种领域计算机的普及，计算机软件也越来越多的出现在各个场合，为人们的办公，生活，学习，休闲等提供了前所未有的方便。软件测试，其目的是：第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。作为计算机专业的学生，我想以我自己的观点来阐述一下我对软件测试的理解。

以前，就是在我没有认真了解测试行业之前，我也一直认为测试应该是不重要的，甚至认为有必要有专门的测试职业吗？认为软件主要是开发人员的事，软件的成果也是由开发人员决定的，当我学了软件工程这门课，真正的了解到它的必要性，事实上真的不是那么一回事哦。软件无处不在，然而，软件是人编的——所以不完美。

我还查阅了一些资料就是不注意软件测试的案例：

1、迪士尼的狮子王（1994～1995）软件在少数系统中能正常工作，但在大众使用的常见系统中不行。后来证实，迪士尼公司没有对市场上投入实用的各种pc机型进行正确的测试。

2、英特尔奔腾浮点除法软件缺陷（1994）英特尔为自己处理软件缺陷拿出4亿美元支付更换坏芯片的费用。导致付出如此昂贵的代价，其主要原因是发现了软件缺陷没有正确的处理。

3、美国航天局火星极地登陆（1999）该项目使用前有经过测试，两个测试小组双方独立工作都很好，但从未走在一起。

4、爱国者导弹防御系统（1991）一枚导弹在多哈击毙28名美国士兵，症结在于一个软件缺陷：一个很小的系统时钟错误累积起来就可能拖延14小时，造成跟踪系统失去准确度。在多哈袭击战中系统被拖延100小时。

5、千年虫（大约1974）估计世界各地更换或升级该系统程序解决原有2000年错误的费用已经超过数亿美元。

这就是不注重测试的一些严重后果，因此我们发现了软件测试的必要性！在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则，包括： 1、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。、Pareto 原则应用于软件测试。简单地讲，Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。

5、为了达到最佳效果，应该由独立的第三方来构造测试。“ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。

6、不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现.。

还有就是关于软件测试的分类：从是否需要执行被测软件的角度，可分为：

－静态测试

－动态测试

从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为 ：

－白盒测试

－黑盒测试

关于静态测试和动态测试：（1）静态测试是指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。

其中包括代码测试、界面测试和文档测试3个方面。对于代码测试，主要测试代码是否符合相应的标准和规范。对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。对于文档测试，主要测试用户手册和需求说明是否符合用户的实际要求。

（2）动态测试是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以，我们判断一个测试属于动态还是静态测试，唯一的标准就是看是否运行程序。

关于黑盒测试和白盒测试 ：（1）黑盒测试

指的是把被测软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子，只关心软件的输入数据和输出结果。

黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误: • 是否有不正确或遗漏了的功能?

• 在接口上，输入能否正确地接受? 能否输出正确的结果? • 是否有数据结构错误或外部信息(例如数据文件)访问错误? •性能上是否能够满足要求? • 是否有初始化或终止性错误?

用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。

黑盒测试的测试用例设计 •等价划分法 •边界值法 •错误推测法 •因果图法（2）白盒测试

指的是把盒子盖打开，去研究里面的源代码和程序结构。白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。

白盒测试的主要方法：

•逻辑驱动测试

•基本路径测试

主要用于软件验证。

使用程序设计的控制结构导出测试用例。

逻辑驱动测试：

主要是测试覆盖率，以程序内在逻辑结构为基础的测试。包括以下6种类型：

•语句覆盖

•判断覆盖

•条件覆盖

•判定-条件覆盖

•条件组合覆盖

•路径覆盖

白盒测试的主要目的

• 保证一个模块中的所有独立路径至少被执行一次；

•对所有的逻辑值均需要测试真、假两个分支；

•在上下边界及可操作范围内运行所有循环； •检查内部数据结构以确保其有效性

测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）；第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息；第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。

经过这一门课程的学习和老师的给我们的讲座，意识到测试并非是我想像的从客户角度任意使用软件产品，从而发现有无质量问题，它有它的理论和实践体系。软件测试是一项严谨的工作，软件测试员一个基本的素质是打破砂锅问到底。喜欢找出那些深藏不露的系统冲突，乐于处理最复杂的问题，外表上热衷於来回奔忙，追求尽善尽美，为征服系统而额手称庆。

最后特别感谢老师对我们的课程学习的讲授，让我们了解到计算机更多的知识，也让我们了解到求职关于计算机方面的岗位，应具备哪些专业知识，谢谢老师！

第三篇：软件测试工作周报

周一：熟悉工作环境，接受部门主管分配的任务，熟悉目前公司正在进行的项目软件的相关内容。

周二：学习项目相关内容，主要看软件需求规格说明书

周三：学习项目相关内容，主要看了软件详细规格说明书，了解到UML使项目各个功能模块更加地清晰。

周四：继续学习项目文档，同时学习软件缺陷跟踪记录软件和AVN。了解并学会应用专门记录软件缺陷，以及跟踪软件缺陷的软件工具-Bugfree.周五：测试了开发项目的基础指标模块，编写测试用例，同时学习项目管理工具SVN的使用。

周一：继续测试基础指标模块，编写测试用例，同时学习项目管理工具SVN的使用。周二：画数据流图，测试没有测完的模块，学习下一个模块的相关文档内容。

周三：回归测试之前的模块，测试用户数据模块，继续学习下一个模块的相关内容。

周四：测试系统管理模块，回归测试之前的模块，部门知识分享。初审测试文档，修改文档的相关内容，测试报表中心模块，回归测试各相关模块。周五：复审测试文档，修改文档的相关内容，办理任务交接。总结：两周以来对技术方面的相关知识、软件测试有了新的认识。

第四篇：软件测试（推荐）

一、简答5*6’

1.为什么不让时间有余的人做测试工作

表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。2.软件测试风险主要体现在哪里

我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。因此，我们要尽可能的选择最合适的测试量，把风险降低到最小 3.所有软件测试缺陷都需要修复吗

从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，修改缺陷可能引入新的缺陷。

-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。4.如何减少测试人员跳槽带来的损失 建议我们从以下两个方面做起：

-加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。

-管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。

5.验收测试的注意点有哪些 测试要注意下面的事项：

（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。（3）永远不能欺骗用户，蒙混过关。6.完全测试程序是可能的吗

实际上完全测试是不可能的。主要有以下原因：-完全测试比较耗时，时间上不允许；

-完全测试通常意味着较多资源投入，这在现实中往往是行不通的；-输入量太大，不能一一进行测试；-输出结果太多，只能分类进行验证；-软件实现途径太多；

-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；因此测试的程度要根据实际情况确定 7.是不是发现的缺陷越多就说明软件缺陷越多 其中的原因主要如下：

-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。

“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。8.软件测试就是QA吗

软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。9.测试产品和测试项目区别

习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：

-质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。项目最后要和用户共同验收测试，这是产品测试不具有的特点。此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作 10.如何编写提交给用户的测试报告

测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况,一般外部测试报告要满足下面几个要求：

根据内部测试报告进行编写，一般可以摘录；不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；报告上面的内容尽量要真实可靠；整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。总之，外部测试报告要小心谨慎的编写。

二、论述2*12’

1.请论述为什么要进行软件测试，并列举历史上2~3个著名软件测试（缺陷）案例，说明测试重要性

软件测试的目的,第一是确认软件的质量，其一方面是确认软件做了你所期望做的事情（，另一方面是确认软件以正确的方式来做了这个事情。第二是提供信息，比如提供给开发人员或程序经理的回馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件软件产品本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此，软件测试的第三个目的是保证整个软件开发过程是高质量的。

爱国者导弹防御系统把“枪口”对准了自己人 美国迪斯尼公司的狮子王游戏软件的兼容性问题 售票系统性能问题

2.论述软件测试科学的发展历程 1957年之前－调试为主 20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本身也远远没有现在这么复杂多变，相当于开发人员一人承担需求分析，设计，开发，测试等所有工作，当然也不会有人去区分调试和测试。

1957–1978－证明为主 当时计算机应用的数量，成本和复杂性都大幅度提升，随之而来的经济风险也大大增加，测试就显得很有必要了，这个时期测试的主要目就是确认软件是满足需求的，也就是我们常说的“做了该做的事情”。

1979–1982－破坏为主 我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。

1983–1987－评估为主 人们提出了在软件生命周期中使用分析，评审，测试来评估产品的理论。软件测试工程在这个时期得到了快速的发展.1988–至今－预防为主 预防为主是当下软件测试的主流思想之一。测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。3.论述软件缺陷的由来

软件缺陷的产生主要是由软件产品的特点和开发过程决定的。

软件本身：①需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。②系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。③对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。④对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。⑤没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。⑥系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。⑦由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。⑧新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。

团队工作：系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。不同阶段的开发人员相互理解不一致。对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。项目组成员技术水平参差不齐技术问题。算法错误：在给定条件下没能给出正确或准确的结果。语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。计算和精度问题：计算的结果没有满足所需要的精度。系统结构不合理、算法选择不科学，造成系统性能低下。接口参数传递不匹配，导致模块集成出现问题。

项目管理的问题：缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难。开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。文档不完善，风险估计不足等。4.软件测试V模型

①绘制示意图

②阐述每个步骤是做什么 需求分析

即首先要明确客户需要的是什么，需要软件作成什么样子，需要有那几项功能

概要设计

主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。详细设计

对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等。软件编码

按照详细设计好的模块功能表，编程人员编写出实际的代码。单元测试

按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同。集成测试

经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。系统测试

经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞，等。验收测试

主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。

第五篇：软件测试工作的心得体会

很久没有写点东西了，今天给大家聊些我在软件测试领域的心得体会。接触计算机程序设计已经快7年了，从事专门的软件测试也快四年了，强子也是在阴差阳错中踏入软件测试领域，一开始只想做一个特牛的程序设计师，可是毕业后找工作却找了个软件测试的工作，在一些彷徨与犹豫中接受了这个职业并且到现在也做得挺开心，也是由于那时我们这个业务刚成立不久，由于表现还不错所以一个阴差阳错的机会被升为team leader，到现在也还在同一家公司做着测试的工作。

先讲讲做manager的一些体会，其实具体做什么事真的不是那么重要，关键是做事的方法，做人的章法，特别是对一个manager来说，方法比技术更重要，真的是这样，当然我也很喜欢研究技术，技术能让我找到更多的自信和成就感，但是面对着手下一帮兄弟姐妹，一个人的技术就显得有些力不从心了，这个时候得把你的知识share给大家，当然形式多种多样，比如写一份文档，做一个正式的training，给大家营造一种不耻下问的环境或者大家一起讨论一些难题等等。当然还有很重要的一点，一定不能说“我不知道”，作为一个头，如果你真的不知道，那你得想办法通过一些手段与员工一起把这个问题解决了，坚决不能说“我不知道，你自己看着做吧“等，本来员工是很尊重你的，这些话将直接导致其鄙视你。

另外就是做头的，特别像咱这种中低层的头，不像中高层的领导，咱们考虑事情的角度不一样，当这种小头儿的最重要的两件事：把事情做对做好，与员工打成一片。首先得确保把事情做对咯，然后带领大家朝着这一个对的方向前进进而把事情做好，在99%的时间里，你是和你的兄弟姐妹们呆在一起而不是和老板，所以这个过程中的与员工的关系一定要融洽且单纯，不能让员工对你有隔阂感，经常一起吃饭，摆摆龙门阵，唠唠家常，开开玩笑，不要摆架子，在一个公司里最不能摆架子的就是这种小头儿(或称之为leader或者manager一类)，这就像个村官一样，小样的，还真把自己当回事儿呢？

做开发还是做测试？很多人讨论甚至争吵，强子认为之所以会有这样的问题是因为中国还没有把软件行业普及好，大家还停留在江民时代，求伯君时代，认为做开发的才是牛人，才有前途。而事实上，现在的软件是一个系统工程，缺开发，缺测试，缺文档都不行，都可能直接导致失败，谁最牛？强子认为写文档的人最牛，那咱们都去写文档？不过从强子面试的很多人当中来看，还是有更多的人愿意做开发，这不能不说是一大遗憾，强子无能，也只能聊以文字来表达自己对测试的热爱。测试犹如开发一样，也是一门深不见底的大学问，咱以后慢慢讨论。

关于项目管理，这又是一门大学问，强子在这几年当中也经历过无数次的版本更新，版本发布或者一些内部的项目，对项目管理略知一二，有空时强子自会附上一些体会。我想项目管理最本质的一点：保护项目团队，保护项目经理，去除杂音。项目经理这活，不好干，要职位没职位，要资金没资金，做好了皆大欢喜，做不好就卷铺盖走人，挺难，不过咱有咱的方式方法，怕啥？

今天先写这些，以后咱慢慢叙......