软件工程——个人总结

回想开学初对于软件工程这门课的期望，总结本课程对你带来的提升：#

学会了使用如下的工具或软件：##

Git仓库；
如何搭建自己的Git仓库，Git命令操作。Git的结构等。
EA；
用EA画用例图，类图，流程图等。
博客园；
Markdown编辑器的使用。

学习和掌握的新语言、新平台##

UBUNTU系统；
学习了一些常用的系统命令，学会了如何用命令行的方式对系统进行操作。
Git命令语言。对Git仓库进行操作。
Lintcode；
学会了如何利用Lintcode锻炼自身编程能力。
Coding；
如何利用Coding搭建自己的项目工程，以及团队项目工程。如何上传代码控制Git仓库等。

统计一下，你在这软件工程实践中，完成了多少行的代码#

包括Lintcode代码，中间结对编程和最终的大作业。大约1400代码。

学习和掌握的新方法#

软件开发的方法：从个人开发到团队开发，从需求分析，到规格说明书到功能说明书到代码规范，到软件设计与实现的方法，到选择合适的团队开发模型到用户体验，功能变更，再到软件的测试与
质量保障，再到最后的软件的发布与维护。以及其中涉及到的结对编程，和一些高效的团队开发模型。软件测试的方法，软件设计的方法，如何获取用户需求，设计工能等。

总结与展望#

总的来讲，这门课程的内容十分的概念化，所学到的都是前人的经验与教训的总结，涉及到的理论知识太多了。现在开发经验很少的我，还不能彻底的理解软件工程所带来的帮助，仅仅开括了自己的
知识面，至少在之后的个人开发或者团队开发中不再迷茫，不知道如何下手了，我想这也是这本书最基础的目的吧，对于书中提到的专业的测试人员，开发人员以及团队的PM，相信只有足够多的开发经验之后才能有所理解和想法。不过也学到了一些实质性的东西，比如VS工具中的测试方式，帮助对软件进行优化与DEBUG。
展望的话，希望自己将来可以尝试开发更多的项目，将这本书中的内容再详细的利用一次，从而真正的掌握它。

记录自己在软件工程课程上的经验总结#

在实战中运用知识才能更快的理解和掌握，不要怕枯燥，不要嫌弃写文章，虽然真的很难受，要知道一份优秀的说明文档将给开发带来巨大的收益。

对于下一届的学弟学妹你有什么建议和告知呢？#

首先这门课程十分枯燥，主要在于理论性东西太多，建议边做项目边学习，还有就是真正理解你自己的软件，或者说你真的要开发什么东西，想清楚了，越详细越好，这样在将来的开发中，不会再迷惑。

分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段，你们团队经历过么？最后到达了哪一阶段？#

首先经历了结对编程，第一次享受到了团队的优势，再到，对软件设计的过程中的讨论，从需求分析，到用例说明文档，绘制类图，再到整个的需求规格说明书。软件开发阶段，选择合适的团队模型，讨论编写设计文档，代码规范设计，任务分配，时间限制等。软件测试阶段，首先发布，测试使用问题，进行再编写，然后详细的进行黑盒测试。最终有了一个未发布的版本，因为微信认证的问题，暂时只能走到这一步。

关于构建之法的五个问题：

page7和150页：

（书上多次提到客户反馈的相关问题）客户反馈具有重大的影响与作用，但是客户也是人，也有可能犯错，在诸多的客户反馈中，我们应该怎样做到择优选择与处理呢？比如很多用户对一个APP的反馈都涉及到一个使用习惯的问题，然而并没有很明显的区分，又该如何判断呢？
答案查询自网站资料：（以下是个人见解和专业答案）
首先选择软件缺陷问题进行处理，对于一些改进类的反馈之后选择性的进行处理，调查之后再进行改进。
对于软件缺陷问题，进行如下处理：
1）DDP

　　首先，测试人员可以根据用户反馈的缺陷数目，来判断和分析测试人员在测试过程中的测试有效性。通常来说，在测试过程中判断测试人员的测试有效性是很困难的。但是通过用户反馈的缺陷数目，却可以直观的说明测试人员是否遗漏了比较多的问题，从而反映测试人员的测试有效性。

　　缺陷检测百分比DDP（Defect Detection Percentage）就是基于这样的目的进行定义的，它可以用来评判软件测试生命周期内某个阶段的测试有效性，它以百分比的形式进行计算[1]。其计算公式为：

　　DDP = [R1 / (R1 + R2)] * 100%

　　其中：

　　°R1指的是被评估阶段发现所发现的缺陷数目；

　　°R2是被评估阶段之后所发现的所有的缺陷数目；

　　注意：DDP计算公式的分母并不是发现的总的缺陷数目，而是指该阶段之后所有发现的缺陷数目（包括该阶段的缺陷数目）。另外，采用DDP作为测试有效性的评估指标，存在的一个问题是需要在产品发布一段时间之后才能进行，例如：产品发布之后3个月。
2）过程改进

　　用户反馈的缺陷，是进行过程改进的重要输入。通过收集和分析从用户使用现场反馈的缺陷，可以回答“为什么这些缺陷会遗漏到用户现场”这样的问题。假如测试人员可以找到这个问题的答案，那么就可以将该分析结果应用到下个项目的测试过程中，以尽量减少此类问题再次遗漏到用户现场，从而达到过程改进的目的。

　　下面是笔者在对用户反馈的缺陷进行分析过程中，对遗漏到用户现场的原因进行的分类。对用户反馈的缺陷进行分类，可以更好的帮助测试人员查找遗漏该缺陷的原因，从而为过程改进提出更加明确和直接的建议和方案。缺陷遗漏到用户现场的主要原因可以是多样的，例如：

　　（1）需求的原因

　　通常来说，软件产品或者系统开发和测试的基础是需求，因此需求定义的质量直接决定了测试对象的质量。而测试人员经常面对的需求是不全的、模糊的，甚至是不正确的。

　　在分析某个产品用户反馈的缺陷过程中，发现用户针对系统R1.0版本配置的数据库，并不能直接在升级之后的R2.0版本中使用，用户认为这极大的浪费了客户的配置时间，也对该产品的易用性产生了某些怀疑。项目利益相关者对该类型的缺陷分析之后，发现测试人员并没有针对这样的场景进行测试，而更深层次的原因是系统的需求中并没有定义可移植性的非功能特性。

　　分析了该类用户反馈的缺陷之后，项目团队将可移植性非功能特性作为评审软件工作产品的检查表的一个检查点，以避免在将来的项目开发过程中遗漏该质量特性。

　　（2）测试设计问题

　　有些缺陷遗漏到用户现场的原因，是由于测试人员在测试设计技能方面的欠缺。测试设计技术和方法是有效开展测试用例设计的基础，测试人员掌握的技术和方法越多，就越有利于他们设计更好的测试用例。

　　在分析某个产品用户反馈的缺陷过程中，发现IGMP协议在有些情况下不能和其他产品的IGMP功能协调工作，并且最后定位是由于我们产品的IGMP协议方面存在问题。后来在系统人员、开发人员和测试人员的共同努力之下，分析得知是由于IGMP的状态转换存在问题，特别是状态在进行连续几个转换之后容易出现问题。主要的原因是测试人员在设计IGMP状态转换测试用例的时候，由于没有掌握状态转换测试技术，导致其测试覆盖率偏低，从而使得该类问题遗漏到用户现场。

　　对于这样的问题，测试团队需要经常的进行合适的测试技术和方法的培训，例如：针对上面的案例，测试团队后来开展了状态转换测试的深入的学习和培训，并在后续的类似状态转换测试中，每个测试人员都可以熟练的应用0-Switch和1-Switch的状态转换技术。

　　（3）测试资源问题

　　有些用户反馈的问题，既不是需求定义的遗漏或者不明确，也不是测试人员没有合适的测试用例设计，而是由于测试资源方面的问题导致的。

　　用户在实际的网络使用环境中，发现并不能达到2000个IGMP用户同时进行视频点播的性能要求，从而提交了一个严重程度比较高的缺陷。在分析该缺陷的过程中，发现该产品的需求定义中有明确的规定要求达到2000个用户同时点播的要求，而在测试用例规格中，也有相应的测试用例存在。但是由于测试资源的限制，测试人员无法执行该测试用例，使得该产品发布的时候，该用例还是处于block状态。

　　对于此类测试资源的问题，一个解决方案是购买能够模拟2000个IGMP用户的测试仪表，另一个可行的方案是测试团队自己开发IGMP用户的模拟器。

　　（4）回归测试问题

　　有些用户反馈的问题，是由于修改某些缺陷之后新引入的，或者由于修改某些缺陷触发了其他潜在的缺陷。导致此类问题的主要原因是，在选择回归测试用例的时候，其修改的影响分析和风险风险做的不仔细和不完善。

　　对于这些问题，也就要求测试人员更加深入的学习和理解被测对象的内部结果，以及对失效模式和影响分析、风险分析等技术提出了更高的要求。通过学习和培训，可以逐步提高测试人员在这些方面的能力。

　　（5）测试环境和使用环境的不同

　　用户反馈的缺陷是由于测试环境，和用户实际的产品使用环境存在较大差距而引起的。例如：测试人员在测试产品的图形化用户接口GUI的时候，一直采用的浏览器是IE7.0。而在用户的使用环境在有FoxZilla、IE5.0等，导致产品的兼容性出现问题。

　　因此，在高级别的测试执行中（比如系统测试和验收测试），要求测试环境能够尽量贴近用户的使用环境。尽量模拟用户使用环境，一方面可以在我们的测试执行过程中，发现我们的软件产品和其他协同工作的产品之间的兼容特性，避免软件发布给用户之后才发现这些问题；另一方面，也可以用来检验我们的产品是不是用户真正需要的产品。

　　为了达到这些目标，测试团队必须了解用户的软件产品使用环境，比如用户使用该软件产品的操作系统、和我们软件产品对接的产品是什么、用户使用该产品可能的网络拓扑结构是什么（用户使用该软件产品的主要用户场景等）。因此，我们的测试团队在了解和熟悉我们的系统需求和实现之外，也需要去掌握和发现用户可能的使用场景，以及其他竞争对手产品的一些功能和特征属性。另外，在可能的情况下，邀请产品的潜在用户参与我们测试环境的搭建，或者征询用户在环境搭建方面的一些要求和建议，帮助我们来模拟用户的使用环境，从而减少可能和用户使用环境背离太多而导致的风险，提高我们的测试效率和测试质量。

　　（6）穷尽测试是不可能的

　　穷尽测试是不可能的，因此，测试团队在有限的时间、资源的情况下，无法发现测试对象中的所有缺陷，也就是说遗留到客户现场的缺陷是不可避免的。而我们能做的是，如何不断完善我们的需求、背景知识、测试技术、测试环境等，从而不断提升我们的测试能力，不断提高我们的DDP。

　　上面是我们分析用户反馈的缺陷过程中，经常采用的缺陷分类。但该缺陷分类并不是全面的，需要我们在测试过程中不断的修改和更新，从而不断完善我们的缺陷分类。
个人理解：客户反馈可以被区分为一下几类，反馈软件缺陷，可能是某些功能没有完善，比如支付功能的缺陷，也有可能是缺少了某些功能，比如作为锻炼身体的记录软件却不能连接手环。其实就是用户找出来的BUG。软件设计问题，比如用户可能觉得界面不美观，不符合常用的类型，很难找到一些按钮，等。也有可能是希望增加某些功能。相对来讲，游戏软件更多得会面临这些反馈。这些问题一般在测试中很难发现，或者容易被忽视掉。所以用户反馈在软件开发后期具有很重要的意义，用户反馈的问题也不一定都必须解决，或者采用，根据一些自定义的标准来选取，比如，是否影响软件的使用，是否影响软件的安全，是否影响绝大多数用户的使用体验。进行详细合理的测试很帮助减少这些情况。

page106：

我看了书上关于敏捷流程的第三步“冲刺”书上这样写道：“一切交流只能通过Scrum大师来完成。这一措施较好的平衡了“交流”和“集中注意力”的矛盾”，而在112页中书中这样
写道“一个好的Scrum大师能在两种语境间自如的翻译和切换，事实上是一个强有力的项目经理”，后面还提到“敏捷对团队的要求很简单但很难做到”是不是承认了敏捷开发流程是
那些非常优秀的团队才可以使用的，一般的或者缺乏优秀的可以担当Scrum Master的团队，不适合使用这种流程呢？
以下是网上我比较赞同的一个回答。

当项目成员越多，我越不推荐敏捷开发，原因在于「当连自己要做什么事、为什么这样做、这样做为了解决什么问题」都搞不清楚前，就跳下去玩敏捷开发，那和比通灵还惨，通灵起码还有个目标物在前面，搞不清楚状况的人只能陪他跳世界迷雾开地图了 。

敏捷开发 – MBA智库百科 最下方有段「对敏捷开发的误解」。可顺便参考 敏捷软件开发 – 维基百科。

误解一：敏捷对人的要求很高

说高不高啦，撇开实作技术不谈，你觉得要找到清楚项目开发流程、知道每位项目成员的工作内容、职责范围、产出，并清楚项目目标、需求、用户需要的开发人员（含设计师）很容易吗？

如果上述条件无法达成，又怎么确定运用敏捷开发方式后，所有项目成员方向都是正确的？就因为这种人太难找，所以会产生「对人要求很高」印象。

连在有企划书、规格书、用户研究报告的文件情况下都还不知道自己要干嘛、同事在干嘛，能谈敏捷吗？

误解二：敏捷没有文档，也不做设计

文件撰写与否和敏捷开发一点关系也没有，敏捷开发强调「适应性而非预见性」，并没有强硬规定。虽然有一句「可用的软件：重于 详尽的文件」，但它没有叫你不要写文件。

先想看看写文件是为了解决什么问题？如果不写文件会产生什么问题？

以 UI 设计师来讲，交出 UI Flow、Wireframe 这种文件是为了解决什么问题？要敏捷开发嘛就不用写了跳过，直接出 Mockup 吧。因为发现出包有漏改来改去改到死，和找到产品问题改良，是两回事啊！

敏捷开发不是没文件没流程的包装纸。

wireframe-grid-rule-of-thirds

误解三：敏捷好，其他方法不好

敏捷开发就是一直小幅度改啊改啊改啊，可以增加工作效率，让大家工作更顺利喔～～（就算是瀑布流式的传统开发流程，设计师也是一直改啊改啊改啊，效率了什么、顺利了什么啊！？）

先承认有问题，才能找出问题，之后找解决方法。而不是先有方法，再想这个方法能解决什么问题。敏捷开发只是一种「方法」，方法论用在敏捷开发上，要回答两个问题：

现有模式为何不能满足你的需求？
敏捷式开发为什么可以？
敏捷开发不是万灵丹，先找到问题点、知道为什么要采取敏捷，重点是卡在哪里需要敏捷这个「方法」来解决。设计师改来改去是为什么解决什么问题？敏捷 开发的小幅度改来改去、和现况设计师的改来改去有什么不同？如果都一样为什么要采取敏捷？（不要跟我说因为软件开发主力是 RD 所以忘记算上设计师。）

wireframe-kit-v22

现实的扭曲

个人与互动：重于流程与工具

开会是非常烧钱的行为，如果项目成员一多，要用什么方式降低沟通落差、尽量让每个人理解到的都相同？怎么确保部门和部门间的信息交流顺畅？靠出张嘴沟通就能办到吗？

可用的软件：重于详尽的文件

有文件产生/解决什么问题？没有文件产生/解决什么问题？不写文件最爱用「我们是敏捷开发」当借口了，不会写就不会写、不知道文件写来干嘛就老实承认，少拿这个当说词。

与客户合作：重于合约协商

如果客户没有在好的引导下一起合作，现实状况会变成「最后一次-确定最终版-说好不改了-V21.psd」。嗯？改来改去不就是敏捷开发吗？（喂）

回应变化：重于遵循计划

这不是改来改去改到死的好理由！为什么要「变化」，变化是为了解决什么问题？没有问题改它干嘛？完全不代表可以没计划就上啊！

结论

敏捷开发宣言里各种许愿…拔掉敏捷二字不也是所有项目开发的理想？所以为了解决什么问题而采用敏捷式开发？为了改善工作流程加快效率？

那设计师修改到死的工作情况在敏捷开发里要怎么被改善？

我觉得敏捷开发适用「头脑清楚」的人，只是这种人往往是大神级的了。和大神 PM、大神 Planner、大神 RD 合作，都清楚知道自己在干嘛、别人在干嘛，还能 Cover 一点别人的领域，知道解决这个问题可以往目标更进一步，这种合作模式才有办法做到「敏捷」，而不是因为抓漏抓虫在修改。是啦这也算朝目标迈进，但「创新改 良产品」和「让产品看起来洞没那么大」的改来改去本质上是两回事啊！敏捷开发只是个方法，不是万灵丹。

敏捷式开发就是改来改去？
原文地址：blog.akanelee.me

作者：@Akane_Lee
个人见解：敏捷开发模型也是亲前人总结的一种开发经验，没有完美的方法来解决一个问题，只有较为合适的，在当今很多软件开发方面，敏捷开发流程得到的市场的广泛认可，但是并不意味着无论做什么都选择它，在某些软件开发方面，面的不同的情况，依旧要进行客观的分析判断再进行开发模式的选择。若如果是一个成熟的面向市场的开发机构，那么在面对很多软件的开发时，敏捷开发的确对这些来讲是最好的选择，对于一个刚刚成立的，仅仅只是一个开发团队雏形的情况下，可以使用一些其他的模型如，明星开发模型等。避免上述的几个误区，不要太过偏执，在选择时客观分析，便可以避免很多因开发模式没有选对而带来的后果。

page150：

很少有用户会正真的填写关于APP的调查问卷，多数问卷真实性也很难判断，比如bilibiliAPP和有道词典APP会询问用户的反馈，如何提高用户的反馈率呢？
看了很多博客，知乎回答，没有一个统一的回答，个人总结如下。
1）抓住反馈的时机，你不能在别人第一次打开软件就弹出希望反馈的窗口吧，也不能从头到尾，用户都不知道怎么反馈，一点提示也没有，所以时机也很重要，很少有用户回会仔细去看使用说明，帮助什么的。
2）设计合适的反馈问卷。
3）亲近用户的软件才能让用户亲近，所以软件的设计要足够的合理。

page188：

PM在风险预测与处理中扮演着重要的角色，占比最多的问题是没有实际的市场需求，都说一个创意很难，早我看来，不是创意难，而是好创意难，那么对于PM如何在概念层面正确的分析市场需求呢？从哪几个方面入手？
软件市场需求
　　1、在建基础建设对软件产业的需求
　　我国当前正处于大规模公共信息基础设施的建设阶段，这些建设包括电力行业、金融行业、电信行业等，除此之外，还包括公共交通信息系统、社保、医保等信息系统的建设，这些对软件都有着极大的需求，据IDC预计，未来5年，我国软件市场将以48.3%的速度高速增长。
　　2、政府部门对信息技术及软件的需求
　　从当前世界信息发展来看，政府部门办公自动化、电子化、网络化，信息共享已是大势所趋，同时，联合国经济会事务部把推进发展国家政府信息化作为今年的重点，希望通过信息技术的应用改进政府组织，重组公共管理，最终实现办公自动化和信息资源的共享，并将提升政府效率及便民服务作为重点，以更有效率的行政流程，为人民提供更广泛的、更便捷的信息及服务。
　　政府运用信息技术及通信技术打破了行政机关的组织界限，并成功建构了一个电子化的虚拟机关，使人们可以从不同的渠道获取政府的信息及服务，而不是以书面审核的传统作业方式，从而提高了政府的行政效率，加强与人们的联系。据不完全统计，"七五"期间，政府投资200多亿元，先后建成12个国家级政府信息系统；有40多个部委成立信息机构，开发各类数据库800多个。自1993年，我国陆续启动了以"金"字命名的一系列国家级电子信息应用的重大工程，到了1997年，先行启动实现金桥、金卡、金关、金税工程的初期目标，并将其投入应用建设中。
　　3、企业对信息技术的大规模的需求
　　当前，企业的生存和发展离不开信息技术，在竞争中生存并取胜，就必须要建立一个科学的管理系统，而现代企业的管理系统企必须有信息系统来支持。所以，基于计算机的管理信息系统则是现代企业中不可或缺的部分。
　　据国家相关部门统计，在中国拥有近15000个大中型企业和大约1000万个中小型企业，而根据IDC的统计，截止到去年年底，在中国只有2051个企业安装了企业资源管理软件（ERM）系统。与世界500强企业中60%都装有ERM系统相对照，在中国的前500强企业中只有2%安装了ERM系统，这在某种意义上说明中国的企业将会是多种软件产品的最大购买者。
　　4、教育软件和家用对软件的需求
　　我国有1000多所大专院校、几十万所中小学、二亿多在校学生，教育系统信息化和教育软件的需求十分庞大。此外包括娱乐在内的家用软件市场需求目前更是难以简单用数字来表达需求的规模。
　　所以，综上所示，当前我国市场对软件的需求还是相当庞大的。
软件开发的原则及对策
　　软件开发必须围绕软件设计、软件支持以及软件管理这三方面开发，笔者根据此提出了以下四条基本原则：
　　（1）选取适宜的开发模型
　　该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其它因素间是相互制约和影响的，经常需要权衡。因此，必需认识需求定义的易变性，采用适当的开发模型，保证软件产品满足用户的要求。
　　（2）采用合适的设计方法
　　在软件设计中，通常需要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件的目标。
　　（3）提供高质量的软件工程支撑
　　工欲善其事，必先利其器。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。
　　（4）重视软件工程的管理
　　软件工程的管理直接影响可用资源的有效利用，生产满足目标的软件产品以及提高软件组织的生产能力等问题。因此，仅当软件过程予以有效管理时，才能实现有效的软件工程。
　　如下图一所示为是某公司软件产品一个版本的开发流程，整个开发大概持续一年左右。从图中可以看出，流程中的大多数活动都是串行进行。这样的一种类似瀑布的开发流程，前提是需求在产品的初始阶段就完整的被捕获并正确的分析，这样才能保证最后交付的产品是客户所需要的产品，但通常这样的理想状况很难实现，所以，一般情况下，图二的开发流程更适合软件产品的开发，其优势有如下几点：
　　1、市场和需求驱动，拥抱变化
　　在开发的过程中，产品的业务人员和售前可时刻保持与产品开发团队的沟通和工作，保证开发出来的产品是符合业务需求。
　　2、充分利用资源和时间
　　这种方式可迭代开发、强调沟通、缩减文档，在每个迭代初期就可以充分地利用开发、测试人员的时间，达到效率最大化。
　　3、每日交付
　　产品开发过程中，可自动化Build，并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。
　　所以，这种方式能够帮助团队开发出更加符合市场需求的产品。
　　总体来说，在开发软件时一定要先确定软件工程的可行性，估算完成该工程所需资源和成本，制定合理的工程进度表，以及时顺利完成整个软件工程开发工作。■
个人理解：当今社会，形形色色的软件层出不穷，适用于大众，公司，学生，专业人士，医疗等等，以及广泛的游戏领域。抓住用户需求，是一个软件的成功的基础条件，所以对用户的分析也至关重要，这也是为什么许多已存在的软件大规模的搜集用户信息进行分析处理的原因，讲你的用户进行合理的分类，分析不同类的用户的需求，选择重要的，合适的，书写需求规格说明书，再进行软件的设计。软件市场的分析，个人认为，说到底就是软件需求的分析，不过对象不再是已经存在的可以直接面对的用户，而是客观存在，却隐藏在市场中的软件需求，也可以认为是在挖掘用户吧。

page154：

软件测试方式如此之多，我们该如何选择，如何针对性的处理不同的软件项目呢？还是说都要进行一遍？

软件测试是一个极其严肃的过程，因为一个完整的软件测试不仅仅关系到软件投入市场能否受到欢迎，同时也关系到开发商的利益问题。由于软件测试的方法有许许多多，不同的软件适合不同的软件测试方法，这也就使得软件测试方法的抉择成了软件开发者心中的一大难题。接下来我们就来说说，应该要按照怎样的测试原则去选择合适的软件测试方法。 进行软件测试，需要遵循的原则有以下几条：一，测试应该尽早进行，最好在需求阶段就开始介入，因为最严重的错误不外乎是系统不能满足用户的需求。二，程序员应该避免检查自己的程序，软件测试应该由第三方来负责。三，设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，如网络异常中断、电源断电等。四，应该充分注意测试中的群集现象。五，对错误结果要进行一个确认过程。一般由A测试出来的错误，一定要由B来确认。严重的错误可以召开评审会议进行讨论和分析，对测试结果要进行严格地确认，是否真的存在这个问题以及严重程度等。六，制定严格的测试计划。一定要制定测试计划，并且要有指导性。测试时间安排尽量宽松，不要希望在极短的时间内完成一个高水平的测试。七，妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。 一般情况下，我们进行软件测试首先要按照测试原则来选择软件测试方法，将不符合测试原则的方法排除在外。而后再根据软件的特性，来在合理的软件测试方法中选择佼佼者。比如人们常用的冒烟测试，英文是Smoke testing，就有着很鲜明的软件测试特征。冒烟测试的对象是新编译的每一个需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。
原创链接: http://gonglue.epwk.com/165893.html
个人理解：不同的项目有不同的测试方式，不一定能找到最好的，但是可以找到较为合适的，选择什么样的方式进行测试取决你的软件的测试要求，例如对于一个媒体社交网站，毫无疑问，访问量，网页跳转速度，数据库容量都很重要，所以性能测试，压力测试都是必须的，如果要开发的是个人的网页，则没有必要进行压力测试，访问量很低，性能测试可以选择性的进行测试。通过上述几方面的理解以及多次的实战经验，相信在测试方面遇到的问题都可以迎刃而解。