洒家是只猫
1、从是否关心内部结构来看
（1）白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。
（2）黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。
（3）灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。
2、从是否执行代码看
（1）静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
(2)动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。
3、从开发过程级别看
（1）单元测试：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。
(2)集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。
（3）系统测试：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
在系统测试中，对于具体的测试类型有：
（1）功能测试：对软件需求规格说明书中的功能需求逐项进行的测试，以验证功能是否满足要求。
（2）性能测试：对软件需求规格说明书的功能需求逐项进行的测试，以验证功能是否满足要求。
（3）接口测试：对软件需求规格说明中的接口需求逐项进行的测试。
（4）人机交互界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的需求。
（5）强度测试：强制软件运行在异常乃至发生故障的情况下（设计的极限状态到超出极限），验证软件可以运行到何种程序的测试。
（6）余量测试：对软件是否达到规格说明中要求的余量的测试。
（7）安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，
（8）可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能（其输入覆盖和环境覆盖一般大于普通的功能测试）
（9）恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况，逐一进行的测试。
（10）边界测试：对软件处在边界或端点情况下运行状态的测试。
（11）数据处理测试：对完成专门数据处理功能所进行的测试。
（12）安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。
（13）容量测试：检验软件的能力最高能达到什么程度的测试。
（14）互操作性测试：为验证不同软件之间的互操作能力而进行的测试。
（15）敏感性测试：为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。
（16）标准符合性测试：验证软件与相关国家标准或规范（如军用标准、国家标准、行业标准及国际标准）一致性的测试。
（17）兼容性测试：验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。
（18）中文本地化测试：验证软件在不降低原有能力的条件下，处理中文能力的测试。
4、从执行过程是否需要人工干预来看
（1）手工测试：就是测试人员按照事先为覆盖被测软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输 入执行，包括与被测软件进行交互（如输入测试数据、记录测试结果等），然后观察测试结果，看被测程序是否存在问题，或在执行过程中是否会有一场发生，属于比较原始但是必须执行的一个步骤。
（2）自动化测试：实际上是将大量的重复性的测试工作交给计算机去完成，通常是使用自动化测试工具来模拟手动测试步骤，执行用某种程序设计语言编写的过程（全自动测试就是指在自动测试过程中，不需要人工干预，由程序自动完成测试的全过程；半自动测试就是指在自动测试过程中，需要手动输入测试用例或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试）
5、从测试实施组织看
（1）开发测试：开发人员进行的测试
（2）用户测试：用户方进行的测试
（3）第三方测试：有别于开发人员或用户进行的测试，由专业的第三方承担的测试，目的是为了保证测试工作的客观性
6、从测试所处的环境看
（1）阿尔法测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试
（2）贝塔测试：是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本，并要求用户报告
扩展资料
软件测试的内容：
1 得到需求、功能设计、内部设计说书和其他必要的文档
2 得到预算和进度要求
3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )
4 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制
5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
6 确定对测试环境的要求 ( 硬件、软件、通信等 )
7 确定所需的测试用具 (testware) ，包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等
8 确定对测试的输入数据的要求
9 分配任务和任务负责人，以及所需的劳动力
10 设立大致的时间表、期限、和里程碑
11 确定输入环境的类别、边界值分析、错误类别
12 准备测试计划文件和对计划进行必要的回顾
13 准备白盒测试案例
14 对测试案例进行必要的回顾 / 调查 / 计划
15 准备测试环境和测试用具，得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据
16 得到并安装软件版本
17 进行测试
18 评估和报告结果
19 跟踪问题 / 错误，并解决它
20 如果有必要，重新进行测试
21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
参考资料：百度百科-软件测试
如何做好软件测试管理工作
人才流失是一定要控制的，当然如何评判是不是人才这是门学问，有道是千里马常有而伯乐不常有，本文不展开此问题。而正常的人员流动是很有必要的，吐故纳新并不一定是坏事，所以我们才有轮岗才有末位淘汰。我想任何老板都不希望自己团队成为养老部门。测试工程师有别于其他技术人员的一个明显点是对于技术广度的掌握，这是工作性质所决定，必须先了解待测产品的各种背景才能正常开展测试活动。有鉴于此，我们应该多鼓励测试人员的流动，也可以进行更多的虚线管理。核心思想，我们不用过多关注工作到底是由谁来完成，应更关注我们有哪些工作这些工作有没有被完成。用个简单的图形描述下，看着有点像工单系统：对于测试团队来说，人员流动除了传统的轮岗、转岗等等之外，更需要的是模糊开发与测试的界限，也就是说不仅仅是人的流动，更多的是工作内容的流动。我们不能只着眼于传统测试工作的范围，更要站在整个质量管理的角度看待问题。我们并非鼓动测试去做开发的工作去和开发比拼技能，而是测试本就具备这样的能力，说白了就是复合型，反之开发也亦然。个人认为未来技术团队里不会专门区分开发、测试的工作，或许在某一领域有偏重，但整体上的职位名称应该是？？开发测试工程师。很多主管喜欢打感情牌，喜欢把团队氛围营造成亲人朋友一般，吃饭要在一起活动要在一起差点上厕所也要在一起，大家一起放声歌唱我们是相亲相爱的一家人。我想问一句，你真的想传递公司就是我的家这种思想吗？你真的想把团队氛围打造成家庭氛围吗？先不说能否做到，做到之后会有什么弊端考虑过吗？家人之间的相处之道和同事之间的有何不同？这还用问吗？团队中30%的骨干人员有丰富的工作经验，较强的工作能力，并对团队有极高的忠诚度；团队中有正常的人员流动，不断的有新鲜血液补充保持团队活力，有发泄负面情绪的正常渠道，在工作中能持续保持激情；团队中上行下效，令行禁止，谋议资于众人，决断归于一将，信息及时共享并尽可能透明，保证较高的公平公正；还有最最重要的，测试人员一般都有点自卑感，认为测试不如开发，某种程度上讲这话没错，团队能让测试人员直视此问题，不用委曲求全自怨自艾，更不用做过多的事情来刻意表明测试并不比开发差，自谦过头就是自傲，自傲过头就是自卑，牢记这点。这是一种什么团队？这是一种什么氛围？成熟的团队，成熟的氛围。我们需要为团队打造一种绵绵然而富有激情的氛围，真的勇士敢于直面惨淡的人生敢于正视淋漓的鲜血，心里素质不过硬内心不够强大能指望着打硬仗吗？遇到点挫折就怨天尤人摔倒了就爬不起来，即使能力再强要你何用？这世界天才是少，但大家就更少，有多少天才在成为大家的路上就早早夭折了？我们需要心智成熟的团员，组成素质过硬的团队，简单讲，我们要组建熟男熟女的团队，而不是幼齿团队。注意，这与年龄无关，白活几十年的人多了去了。在互联网企业，在年青人较多的团队，活力肯定有，同时浮躁也难免，所以营造成熟的团队氛围就显得更加重要。至于如何一步步的建立并最终达到此目标，因篇幅所限故本文不做探讨，有兴趣的可私下找我。最后，现在知道为什么很多人叫我大叔了吗？还不知道开扁的啊。这问题有太多人探讨，网上随便一搜一大把。大致汇总有以下几点：l 按能力：会不会编码写脚本会不会开发测试工具会不会各种类型的测试会不会写文章会不会演讲反正上天入地电光霹雳有你不会的没。简单粗暴点的按结果居多，管你三七二十一线上有多少故障，超出预订目标就砍你。复杂点的把各种指标放一起加减乘除还要加上各种权重。无论哪种都有个核心问题，如何收集数据？特别是准确的收集？所以想要公平客观的考核测试人员首先必须拿到准确的评估数据，这也是为什么我一直强调测试数据报表重要性的原因。当然，测试报表的作用远远不止用于考核，更多是为制定未来测试发展方向所用，最近我一直在整理我们需要哪些报表怎样的算法才更精准，本文不做深入探讨，有兴趣的单独找我。有些数据可以收集但有些数据需要主观判断，尤其是综合素质方面，难以量化。所以我认为考核的思路应该是一个中心两个基本点，以产品建设的最终结果为中心，坚持高效的研发过程，坚持小规模作战的思想。产品发布后是否达到预订目标甚至超过预期，这是我们最关注的，你测试做的再好任你说的天花乱坠，最终产品目标没达成那就是扯淡。所以我反复强调不要仅站在测试的角度看问题，要不得。互联网产品出故障不可怕，可怕的是故障迟迟得不到修复。出个P1故障我一秒甚至是一毫秒就修复了，影响能有多大？此观点很多人论述过了在这我不重复。所以在产品建设的过程中，我们第一考虑的是高效，如何才能高效，凡是阻挡高效的一律扫除。天下武功无坚不摧唯快不破，测试工作如何能更快的进行完，这是我们优先考虑的。不要把团队无限制的扩大，更不要认为人多就好办事。咱们国家为啥要搞计划生育？用最少的人办更多的事，这才是王道。当然，出于某些个人利益考虑而做出的选择请无视我说的。垂直化的测试团队与传统结构的测试团队有何区别？看完这么多FAQ你还不清楚那我也没办法了，传统结构的测试团队基本不会这么做。垂直化测试团队有个瓶颈，资源较少，测试人员的发展空间容易受限，特别是往管理方向发展的测试人员。所以不管是纵向还是横向发展，最好是走技术与业务相结合这条路，这也是我们一直说的，跳出测试的条条框框，站在垂直的层面看问题。至于是垂直结构好，还是传统结构好，仁者见仁智者见智吧。
如何进行有效的软件测试外包项目的管理
首先，在项目准备阶段，项目调研工作要尽可能地圈定责任，应该在项目正式启动前，尽可能多的了解、熟悉系统设计、系统构架，然后签订一个比合同更加详细的书面的和约，确定双方在项目开发中所承担的责任和义务，要让国外发包方分析、设计人员将设计结果的各个子项目的定义、规则、意义进行详尽的阐述，务必让项目组人员对整个项目的概况及具体实现细节有一个清楚的认识，然后再进入具体的项目实施阶段。否则，往往会由于发包方在项目过程中进行过多的需求变更而导致接包方工作量和费用的增加，从而极易导致纠纷，或者是国内那些接包企业对固定费用合同项目的害怕，并且就认为这种外包项目还是以“包工制”形式比较可靠，利润比较稳定，从而形成目前国内企业多数以“包工制”形式合作并且多数争取建立长期合作关系。因此，对于外包项目的准备工作要比一般的项目做的更详细更全面更到位。
其次，应该在项目早期和发包方协商项目的验收方案，当然，项目早期确定项目的验收方案不是那么好确定，但至少应该有个大概的且要双方认可且达成一致的验收约定。项目验收的谈判不能仅仅只是对项目交付期的谈判，外包项目相比起一般项目来，更应该注意具体验收方案的谈判。
第三，外包项目对语言培训比一般项目更加重要，在沟通管理中语言培训更应该花大力气。语言能力是影响软件外包项目质量的一大因素。由于语言障碍导致的理解错误从而导致返工、误工的情况在外包项目中比比皆是，因此必须注重对员工语言方面的培训。
第四，外包项目比一般项目更应该加强时间管理，对项目进度应该严格控制，项目经理更需要有效地监控项目的进度和风险，才能避免项目的延误，避免额外付出的开发费用。项目经理拿到外包商交来的项目计划后，要详细地进行审核并制定自己项目组的项目计划，并且需要进一步比较和分析二者后不断修改项目计划，使之既不发包方的项目计划冲突，又有利于自己的企业。通过这些活动和过程，项目经理从而进一步了解外包商对整个项目的流程、内容、估计的工作量和资源的安排是否与项目本身的要求吻合。明显的差异都需要及时澄清并建立共识。确认了外包商的项目计划后才能够正式地启动项目，开始对项目进行监控。还有一个好的办法就是项目经理在制定时间计划时，除了要给项目留足缓冲时间外，最好是稍微让项目往前赶，但是不要把项目往前提的太多。项目经理博客
第五，服务性质强的外包项目，比如软件测试服务，专家咨询服务，这类外包项目的产品是“软”产品，其项目输出、项目的质量等都是过程性为主的，而且工作量等也很不好量化，因此，对于这类项目的项目管理，而且是这类项目的外包管理，难度在很多方面更难。这种专业性很强但又是服务性很强的项目，首先要求这类公司有丰富的项目管理经验，而且要求这类公司在专业服务上对其提供的“子服务”进行分类，对每类“子服务”要进行尽可能地明确清晰的定义、量化和服务验收方案的标准化，做到条块分明，即市场与服务一致，“子服务”类型定义清晰。除此之外，对于流程建立等类型的“子服务”，因为完全是过程性质的，因此必须有客户代表(最好是由于代表性的领导)参与，与自己的项目组组成一个项目小组，这个客户代表将来对整个项目过程都起非常关键的作用。
软件测试的流程是什么？bug具体是什么？怎么提交？
简单跟你讲下吧，
1.软件测试流程，一般是这样：需求了解——测试计划——测试设计——测试用例编写——测试执行——bug管理跟踪——测试报告生成
2.bug就是测试过程中发现的程序缺陷，可以指需求上的，也可以指功能、性能上的
3.bug提交有多种方式，可以通过测试管理工具来管理bug，比如QC等
4.bug的生命周期： 发现bug（open）——修复bug（fixed）——关闭bug（closed）
软件测试BUG管理方面求指导
您好，我看完你的说明大概理解是这样的，不知道理解的对不对，如果有不对的地反国庆及时纠正我，我在回答：你们是想在二期的时候开始执行统计重先bug的情况吗？想要个方法对么？
你们可以在测试开始的时候，只要要有bug需要上报就必须搜一下这个bug之前是否报过（其实这个一个报bug的必须流程，最起码避免bug的dup)，如果已经报过，那么Close了没有，Close了是怎么close的，真的是code change Fixed的吗。。。这些不知道对你来说是不是废话，就不多说。那么，你搜索这个bug如果之前已经报过了的话，现在这个bug又reproduce了，那么在你新报的bug上做个标记，例如 Rep之类的，这个你去查一下有没有标准（这个标记必须是统一的，所有这种类型的bug你都需要用这个标记）之后的话你做bug统计什么的就方便多了，直接搜关键词就可以了。 如有疑问请再哈。。更多
哦，您的意思是，每次登录BUG的时候都要检查一遍是否已经登过此BUG，之前有登过的就标注一下，之后统计时好统计，这个意思把。
问题点：，假如 第一论 提交400个BUG（没有重复），并且全部Close了， 开始进入第二轮测试，登BUG的时候第二轮BUG List上是可以检查是否有重复的BUG，可是考虑到第一轮的话，还得从第一轮CloseBUG的List上再找一遍重复BUG才行，
你的意思是统计第二轮与第一轮重复的bug（这个统计第二轮的重复的buglist）,然后还要统计第一轮与第二轮重复的bug吗（这个统计第一轮重复的bug list)？是这个意思吗？这样的话你只能第二轮你登bug的时候就开始去列这个list，专门做个tracking list，每次登bug的时候去更新。或是定时去更新这个tracking list。 不管是bug 管理还是软件测试，大量的tracking 表是很有必要也很重要的。
一般bug管理流程的话，你第一轮测试算是正常的测试，本身就不用统计什么dup的bug， 我不知道你们统计这个有什么意义，第二轮的话因为是regression 的测试，所以统计之前不发生现在发生或是之前发生然后已经解了现在又发生的bug才有意义。而我说的做标记其实也不是我想的办法，是正常规范的bug管理方法。
说实话，我还是不太明白你做这个的意义，若你可以解释的具体一点，我可以给你更详细的解释哈。
哦 呵呵 太感谢你了，最后想问一下，
（所以统计之前不发生现在发生或是之前发生然后已经解了现在又发生的bug才有意义。） 我要统计的就是这个，
关于这个能否简单的说明下，具体怎么统计方法吗？（理论是不用，就是如何统计这方面的就行） 麻烦了。
Excel是灰常强大的，excel也是软件测试各种trackinglist的媒体，根据你需要统计的信息，然后去创建一个适合自己的tracking表来跟踪各种测试数据，这个作为管理者需要掌握的，之前不发生现在发生或是之前发生然后已经解了现在又发生的bug这是两种情况，你需要分开来统计，在登bug的时候也是需要分开来做标记的，因为软件测试一般都是涉密的，所以我没有办法告诉你我们是怎么样去tracking什么的，这些我觉得你可以去一些软件测试网上看一下。 关于这些tracking 表，你可以刚开始弄简单表格去跟踪，之后根据你的经验慢慢去完善哈，但是起码最简单的那些信息（bugid summary status submit date close date 等等）都需要统计进去哈，你创建完了以后怎么样比较清晰明了，你就怎么弄，平时多学习一下excel和PPT的运用，对于软件测试非常非常有用。这些都是切身感受哈
需求获取的常用方法有哪些？25.说明软件测试和调试的目的有何区别
需求获取的常用方法有哪些
1）用户访谈
用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组合议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照——定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列以一个粗糙的想法，根据访谈的民体情况来进行发挥。
2）用户调查
在进行用户防谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项日涉及的客户面较广。不可能——一访谈。因此，就需要借助用户调杏的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求倍息，这样就可以克服上述的问题。
用户调查最大的不足就是缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。
3）现场观摩
俗话说，百闻石如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之合效的方法。现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随用户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记；建造软件系统不仅仅只是为了模拟客户的手下操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界而等作为软件设计的目标。
4）文档考古
文档考古是指对历史存在的—些文档进行研究，从带有数据的文件、表单、报表等文档中获取所需信息的过程。对于一些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。
5）建立联合分析小组
在系统开发时，系统分析员和用户之间由于知识结构的差异，难免存在难逾越的交流鸿沟。
用广提供的需求信息，在系统分析员看来可能是零散和片面甚至无法理解的。因此，为了能够减少交流上的问题，就需要一个领域专家来帮助进行沟通，即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获地。
6）原型法
原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个祖糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方向上存在缺陷。建造这样一个系统的目的是为了看，考察某一方面的可行性。如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于文物的有效沟通，从而帮助人们尽早解决软件开发个存在的各种不确定性。
7）模型驱动
前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系统，尤其是对于复杂的系统而言，它们的需求获取任务绝不是可以通道一两次这样简单的获取行为就能够完成的。为了能够使得获取行为相互配合、减少不必要的精力耗费和防止出现获取信息的遗漏，可以采用模型驱动的方法。
8）基于上下文的方法
软件系统是作为一个整体存在的，它通过和环境的交互来解决用户的问题，满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境，因此，要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识。基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比，它更加注重用户在—定环境下表现出来的行为，通过分析用户的行为得到信息。
说明软件测试和调试的目的有何区别
1、目的不同
软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务.调试的目的是为了证明程序的正确，因此它必须不断地排除错误.它们的出发点不一样。前者是挑错，是一种挑剔过程，属于质盘保证活动。后者是排错，是一种排除过程，是编码活动的一部分.
2、任务不同
既然软件测试属于质量保证活动，因此它贯穿于整个开发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试，软件测试阶段要进行集成软件测试、系统软件测试等，直到产品交付。只要有修改就有软件测试，产品交付后同样。它是比较有规律的活动，有系统的方法、原则作指导。
而调试是编码活动的一部分，因此有编码就有调试.它的任务主要就是排错。调试的方法经常与使用的开发工具有关，例如:解释型的开发工具可以交互式调试，编译型开发工具就很难较好地查错。当然它有一些启发式的方法，它是一种比较依赖开发人员经验的活动。
3、指导原则和方法不同
软件侧试是一种有规律的活动，有一系列软件软件测试的原则.其中主要是制订侧试计划，然后严格执行.其次是一种挑剔性行为，因此它不但要侧试软件应该做的，还需要侧试软件不应该做的事情。调试所遵循的规律主要是一些启发式规则，是一个推理过程。例如使用归纳法、演绎法、回溯法等。
软件测试的输出是预知的，其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的，需要调试者去解释、去发现产生的原因。
4、操作者
因为心理状态是软件测试程序的障碍，所以执行软件测试的人一般不是开发人员，以使软件测试更客观、更有效，而调试人员一般都是开发人员.
从软件测试转项目管理有什么优势吗
有，最起码了解项目进程及项目阶段性的进展过程。另外在软件测试中遇到的问题，在项目管理中可以提前规避。
软件测试中如何实现一个最简单的操作系统
软件测试中如何实现一个最简单的操作系统软件测试方法
关键字：操作系统 Linux
这里为了简单，就不考虑可移植性开求，不从BOOT部分来接收参数，也不对硬件进行检测，也不需要进行DATA段，代码段的重定位。我只是读了Linux内核相关部分，并未自己去实现一个操作系统，所以我以下所说的只是概念性的东西：
1.接管系统的中断处理，由于BOOT部分的代码决定了那个中断向量表，从而决定了系统中断之后进入的内存位置，但BOOT并不知道操作系统的中断处理函数位置所在啊，怎么办呢?有几种方法，其一是：如果你的板子可以重映射地址，也就是可以将内存条所在的位置重映射成0x0开始，那么在链接内核的时候，就将操作系统自己的中断向量表定位在0x0处并且在BOOTLOADER引导结束时就完成映射操作，并让CPU跳转到0x0处执行;如果没有重映射功能，我就不晓得怎么办了，不过我想到一个折衷的办法，就是在BOOTLOADER启动完成时(也就是将CPU控制权交给操作系统内核时)，重新改写FLASH的0x0区域，就是将操作系统的内核的中断向量表写入FLASH区的0x0处，比如，当一个IRQ发生时，CPU决定了会跳入0x18(假设这里FLASH占用地址总线0x0至0x0fffffff,内存占用0x20000000至0x2fffffff)，而BOOTLOADER在最后将0x18处的代码修改成了0x20000000加上0x18的地址处的代码，而这个地址就是内核的中断向量表中的相关跳转指令，就相当于跳转进了内核所关联的IRQ处理函数的地址上去执行中断处理函数了，而这样的不好之处在于：当系统重新上电之后，BOOT的中断向量表已经被修改，除非BOOT本身不使用中断，呵，在这样简单的系统中，BOOT是不需要中断功能的
2.这里为了简单，所以没有使用分页内存管理，就不需要建立页表等操作，直接进行操作系统的堆栈设置，同BOOT一样的设置过程一样，接着就进行BSS段清零操作，这里的BSS段是指操作系统自身的BSS段，与BOOT的BSS段是同一个含义只是用在了不同的地方了，接着就跳入了MAIN函数
3.为了最大可能的简单，采用静态建立任务结构数组，比如只建立十个任务，那么首先要为这十个任务结构分配段内存，可以在堆上分配(这个分配的内存直到操作系统结束才会被释放，当然也可以指定一片操作系统的其它地方都用不到的内存区域，不过这样写的话就有点外行的味道了，而符务结构数组的指针却是全局变量，存放在BSS段或者DATA段)，
由于在上一步中已经分配了一个系统堆栈，那么我们这十个任务就分享这总体的堆栈区域这里的重点就是如果定义每个任务结构数组里面的结构，可以参照Linux的相关部分设计
4.中断处理：在第一步中已经确定了CPU进行相关的几类型的中断跳转地址，而相同类型的中断却只有一个入口地址，这里的中断处理就会完成以几个动作：其一：入栈操作，包括所有寄存器入栈，至于这个栈，就是在第二步中所设置的IRQ栈，其二：屏掉所有中断，呵，这里为了简单起见，所以在处理中断时不允许再次发生中断其，三：读取中断相关的寄存器，判别是发生了什么中断，以至于跳进相关的中断处理函数中去执行(在这里只包括两种中断，一是时钟中断，另一个是SWI中断，也就是所谓的系统调用时需要用到的)其四：等待中断处理完成，然后就开启中断并出栈，恢复现场，将CPU控制权交给被中断的代码处
注意：
其一：在MIAN中必须首先确定整个系统有哪些需要处理的中断，也就是有哪些中断处理函数，然后才编写这里的中断处理函数
其二：本操作系统不处理虚拟内存，其至连CPU异常都不处理(一切都为了简单)
转载请注明出处51数据库 » 软件测试过程管理办法 软件测试的方法一共有几种
